Session-Specific Explicit Diameter Request Routing
draft-tsou-diameter-explicit-routing-05

[Ballot discuss]
The proposed note ends with: "The IESG also does not know of any
  information on record that such work is needed as a reference by
  other SDOs."  This is not strong enough.  I suggest the following:

    The IESG has checked with several other SDOs, and none of them
    indicate that this document is needed as a reference for them to
    progress their own work.  As such, if the RFC Editor chooses to
    proceed with the publication of this document, the IESG strongly
    encourages the removal of the following text from the Abstract:

      This document is being published to provide the basis for a
      standardized solution to a problem raised by some architectures
      (e.g., WLAN 3GPP IP access, 3GPP TS23.234) that use Diameter.
      The intended use will be as a reference within the non-IETF
      specification of a Diameter application that meets the needs of
      these architectures.

[Ballot discuss]
I agree with Jari's DISCUSS position.  I suggest an additional requirement (3), that the following text is removed from the second paragraph of the Introduction:

  The IETF does not endorse this
  specification because of its impact on Diameter session
  survivability, but do not object to its publication for use in
  specialized situations where the loss of robustness is acceptable.

This text makes an assumption about IETF endorsement that would be expressed more accurately by Jari's suggested text.

[Ballot discuss]
The proposed note ends with: "The IESG also does not know of any
  information on record that such work is needed as a reference by
  other SDOs."  This is not strong enough.  I suggest the following:

    The IESG has checked with several other SDOs, and none of them
    indicate that this document is needed as a reference for them to
    progress their own work.  As such, if the RFC Editor chooses to
    proceed with the publication of this document, the IESG strongly
    encourages the removal of the following text from the Abstract:

      This document is being published to provide the basis for a
      standardized solution to a problem raised by some architectures
      (e.g., WLAN 3GPP IP access, 3GPP TS23.234) that use Diameter.
      The intended use will be as a reference within the non-IETF
      specification of a Diameter application that meets the needs of
      these architectures.

[Ballot discuss]
I agree with Jari's DISCUSS position.

I also want to see this text removed from the second paragraph of the Introduction:

  The IETF does not endorse this
  specification because of its impact on Diameter session
  survivability, but do not object to its publication for use in
  specialized situations where the loss of robustness is acceptable.

[Ballot discuss]
I do not think that we should publish a document that says it is a basis
for a standardized extension, and it is particularly suspect in a
situation where we have not gotten any formal expression of requirements
from the 3GPP. They normally give us all their requirements and
references to work that they depend on ends up in the 3GPP-IETF
dependency list, which has not happened in this case AFAICT.

Given this, the proposed IESG note is too weak, IMO.

Here's a possible rewrite:

The IESG has concluded that this work is related to IETF work done in the Diameter Maintenance and Extensions (DIME) WG, but this relationship does not prevent publishing, if (1) the abstract is changed to remove the discussion of standardized solutions and (2) the following text appears either in the document body or as an IESG note:

Techniques similar to those discussed in this document were discussed in the IETF DIME Working Group. The group had no consensus that the problems addressed by such work are a real concern in Diameter deployments. Furthermore, there was no consensus that the proposed solutions would meet the architectural principles of the Diameter protocol. As a result the working group decided not to undertake the work. There has also not been any formal requests for this functionality from other standards bodies. This RFC represents a continuation of the abandoned work. Readers of this specification should be aware that the IETF has not reviewed this specification and cannot say anything about its suitability for a particular purpose or about its compatibility with the Diameter architecture and other extensions.

[Ballot discuss]
This is a Discuss-Discuss and does not require any action from the authors.

I am not an expert on this protocol and would like to IANA situation with someone with deeper understanding.

To me it looks like all AVPs are supposed to be tracked by IANA regardless of whether they are allocated for IETF standards track use, or for vendor-specific use.

At the top of the AVP registry I see...
  Registration Procedures
    Expert review with Specification
  Note
    If more than 3 are needed, IETF consensus.

The I-D only appears to need three new AVP Codes so IETF consensus is not required, but I would still expect IANA to be requested to track the AVP Codes to avoid clashes.

Furthermore, the Vendor-Id AVP value of 2011 proposed for use in the Experimental-Result AVP indicates Huawei Technology Co. This doesn't seem apporpriate to the scope of the document as set out in the Abstract and Introduction.

[Note]: '''The IESG has concluded that this work is related to IETF work done in the Diameter Maintenance and Extensions (DIME) WG, but this relationship does not prevent publishing. The DIME WG discussed a predecessor of this document. There was no consensus in the WG that the problems addressed by the document are a real concern in existing Diameter deployments, and there was no consensus that the solutions meet the architectural principles of the Diameter protocol. As a result the DIME WG decided not to undertake this work. The IESG also does not know of any information on record that such work is needed as a reference by other SDOs''.' added by Amanda Baber

[Note]: changed to ''The IESG has concluded that this work is related to IETF work done in the Diameter Maintenance and Extensions (DIME) WG, but this relationship does not prevent publishing. The DIME WG discussed a predecessor of this document. There was no consensus in the WG that the problems addressed by the document are a real concern in existing Diameter deployments, and there was no consensus that the solutions meet the architectural principles of the Diameter protocol. As a result the DIME WG decided not to undertake this work. The IESG also does not know of any information on record that such work is needed as a reference by other SDOs'.
'

[Note]: ''The IESG has concluded that this work is related to IETF work done in the Diameter Maintenance and Extensions (DIME) WG, but this relationship does not prevent publishing. The DIME WG discussed a predecessor of this document and there was not enough interest in the WG that indicated that the problems that this work try to solve are a real concern in the existing Diameter deployments, or consensus that the proposed solutions meet the architectural principles of the Diameter protocol. As a result the DIME WG decided not to undertake this work. The IESG also does not have any information on record that such work is needed as a reference by other SDOs'.
' added

The draft draft-tsou-diameter-explicit-routing-05
is ready for publication from the Independent Stream.
Please ask IESG to review it, as set out in RFC 5742.

The following is some background for this draft, please forward it
to IESG along with this request ...

This was submitted back in August 2009, I picked it up in March 2010.
I believe it was discussed in the Diameter WG, but did not gain
consensus. Jouni Korhonen reviewed it for me, and has worked with
the authors to improve it. He believes it's now ready to be
published.

Jouni also pointed out one nit:
In figure 1 the realms should really be like "r1.example.com", not
just "r1.example". I know it is going to be hard time fitting those
there but RFC2606 requires so.

I'll ask the authors to make that editorial change in their next
revision

Thanks, Nevil (ISE)