Diameter Base Protocol
draft-ietf-dime-rfc3588bis-34

[Ballot comment]
Thanks for addressing all of my comments. It seems you missed a few things in the conversion from "ABNF" to "CCF":

1.1.3 - You say "command ABNFs" when I think you mean "CCFs". If correct, you should also spell it out the first time you use it: "Command Code Format (CCF)".

1.2 - You should define "CCF".

3.2 - In the comment "avp-name", you say "command ABNFs" when I think you mean "CCFs".

These could all be done in an RFC Editor note if your AD agrees; no need for a new revision.

[Ballot comment]
Thank you for addressing my concerns about the IANA considerations. I have two other comments:

1. In Section 1.3.3, this specification has "[d]eprecated the exchange of CER/CEA messages in the open state" but "assume[s] that the capabilities exchange in the open state will be re-introduced in a separate specification". Do we really want to actively deprecate something that it's assumed will return in the not-too-distant future? Or do we want to change "will be re-introduced" to "might be re-introduced"?

2. It might be helpful to explain why the End-to-End security framework has been deprecated. Did it not work properly? Did no one implement it? Were there such significant interoperability problems that it was deemed better to scrap it? And, will it be (or does it need to be) replaced by something else?

[Ballot discuss]
revised based on -31

#1) addressed

#2) addressed

#3) addressed

#4) addressed

#5) addressed

#6) addressed

#7) addressed

#8) addressed

#9) addressed

#10) s13: The peer and routing tables use expiry time.  Certificates used in TLS/DTLS/IKE also contain expiry times.  I think a considerations that says something about checking to make sure the peer and routing table expiry times are never beyond the expiry time in certificates.  If you allow the expiry time to extend beyond the validity period in the certificate, it would be a bad thing.  If the connections are very short lived then it might not be big deal, but if they're long-lived then there's more to worry about.

Adding something in the security considerations would address this.

#11) addressed

[Ballot comment]
#18) s5.2: Name matching has proved to be a challenge for many in the TLS/DTLS environment.  A pointer to RFC 6125 would be much appreciated.

[Ballot discuss]
(Updated for -30, removing what's been addressed - we're making progress in email on these last two - thanks!)


This sentence in section 2.1 is not clear:
  For TLS [RFC5246] and DTLS [RFC4347], a Diameter
  node that initiate a connection prior to any message exchanges MUST
  run on port [TBD].
What was its intent? It could be misread to say that you cannot establish
a connection on any other port than [TBD].


The note at the end of 6.1 is very ambiguous - does "this section" mean
just 6.1, but not 6.1.1 through 6.1.9, or did it mean to include those
subsections?  Either way, it leaves the requirements language very hard
to follow.  Does this say certain implemenentations MAY ignore some MUSTs?
If so, which ones?

[Ballot comment]

In section 2, 2nd to last paragraph before section 2.1: This edit (moving
how tranparency is described) resulted in a sentence that says Diameter Relays
and redirect agents MUST support all Diameter applications. Please consider
touching it again to make it clearer that those elements MUST be transparent
to the applications, and as a result trivially support them.

(New for -30) : The edits to the first paragraph of the description of the AVP flags
help, but use two different 2119 words on the same requirement. The bis effort
decided that new applications SHOULD NOT define new AVP flag bits. Saying then
that they MAY do so muddies the requirement (MAY means "truly optional" in 2119).
Would "This does not prevent applications from creating new AVP flag bits in exceptional
circumstances, so any unrecognized bits received SHOULD be considered an error" work?

In section 6.1.2, can the document say why the hop-by-hop identifier
SHOULD be locally unique rather than MUST be?

[Ballot discuss]
Hopefully this is a no-brainer and just a simple clarification is needed.
(-30 is the same as -29 here so the point remains)

13.1 says that (D)TLS is now a MUST implement and IPsec is a MAY
and using TLS is a SHOULD and using some security is a MUST, all of
which is great. However, one question - when it says Diameter MUST
NOT be used without "some security mechanism" does that mean one of
(D)TLS or IPsec MUST be used? If so, then saying so would be good,
since otherwise someone may claim to be conforming because they're
using something home-grown which would not be good really. I think
this can be fixed by simply changing the end of the 1st para of 13.1
to "..the Diameter protocol MUST NOT be used without one of TLS,
DTLS or IPsec." If you do want to allow "some security mechanism" to
mean something else then I think you need to characterise that more
tightly.

[Ballot comment]

- The IPR declaration confuses me. RFC 3588 is dated September 2003.
The declaration says it relates to a filing from November 2003, and
3588bis doesn't seem to add anything of note other than
clarifications. But I guess since its "recriprocity" that'll just
have to go down as yet another wonder of the patent world;-)

IANA has a question about the instructions in this document.

IANA understands that, upon approval of this document, there are several
IANA Actions it must complete.  IANA also understands that the Diameter
registries and assignments put in place upon approval of RFC 3588 will
remain in place unless explicitly changed in the IANA Actions below.

First, for the AVP Codes registry in the Authentication, Authorization,
and Accounting (AAA) Parameters registry located at:

http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml#aaa-parameters-45

IANA will note that this registry is for AVP Headers where the Vendor-ID
is either absent or has a value of zero (0).

AVP Code 0 will be marked as Not Used.

AVP Codes are to be allocated following Expert Review (or Designated
Expert) with Specification Required as defined by RFC 5226. 

The note for the registry will be changed to indicate that block
allocation (release of more than 3 at a time for a given purpose) now
only require IETF Review as opposed to an IETF Consensus as defined by
RFC 5226.

Next, for the AVP flags registry in the Authentication, Authorization,
and Accounting (AAA) Parameters registry located at:

http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml#aaa-parameters-45

IANA believes that the IANA Considerations section 11.1.2 makes no
changes to the existing registry.

Next, for the Command Codes registry in the Authentication,
Authorization, and Accounting (AAA) Parameters registry located at:

http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml#aaa-parameters-45

the following changes will be made:

The command code values 256 - 8,388,607 (0x100 to 0x7fffff) are for
permanent, standard commands, allocated by IETF Review as in RFC5226.

The values 8,388,608 - 16,777,213 (0x800000 - 0xfffffd) are reserved for
vendor-specific command codes, to be allocated on a First Come, First
Served basis by IANA as defined by RFC 5226.  IANA notes that requests
for vendor-specific command codes should include a reference to a
publicly available specification which documents the command in
sufficient detail to aid in interoperability between independent
implementations.  If the specification cannot be made publicly
available, the request for a vendor-specific command code must include
the contact information of persons and/or entities responsible for
authoring and maintaining the command.
     
The values 16,777,214 and 16,777,215 (hexadecimal values 0xfffffe -
0xffffff) are reserved for experimental commands.

Next, for the Command Flags registry in the Authentication,
Authorization, and Accounting (AAA) Parameters registry located at:

http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml#aaa-parameters-45

IANA believes that the IANA Considerations section 11.2.2 makes no
changes to the existing registry.

Next, in the AVP Specific Values registry in the Authentication,
Authorization, and Accounting (AAA) Parameters registry located at:

http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml#aaa-parameters-45

the allocation rule is changed from IETF Consensus to IETF Review as in
RFC 5226.  The following subregistrires will be explicitly marked to
indicate that new values can be assigned via IETF Review as in RFC 5226:

Result-Code AVP Values
Accounting-Record-Type AVP Values
Termination-Cause AVP Values
Redirect-Host-Usage AVP Values
Session-Server-Failover AVP Values
Session-Binding AVP Values
Disconnect-Cause AVP Values
Auth-Request-Type AVP Values
Auth-Session-State AVP Values
Re-Auth-Request-Type AVP Values
Accounting-Realtime-Required AVP Values

Next, also in the AVP Specific Values registry in the Authentication,
Authorization, and Accounting (AAA) Parameters registry located at:

http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml#aaa-parameters-45

the subregistry for Inband-Security-Id AVP (code 299) will be marked
deprecated and unavailable for future assignment.

Next, IANA understands that it does not need to create a registry for
the Experimental-Result-Code AVP.

Next, IANA has a question about the instructions in section 11.4 of the
IANA Considerations Section. 
QUESTION -> In section 11.4 there is the following instructions: "The
port number [TBD] has been assigned for TLS/TCP and DTLS/SCTP." Should
this be DTLS/TCP and DTLS/SCTP?

Next,in the SCTP Payload Protocol Identifiers registry in the Stream
Control Transmission Protocol (SCTP) Parameters registry located at:

http://www.iana.org/assignments/sctp-parameters

two new protocol identifiers will be registered as follows:

Value: SCTP Payload Protocol Identifier      Reference      Date Assigned
====== =====================================  ==============
================
TBD2  Diameter in a SCTP DATA chunk          [ RFC-to-be ]  TBA
TBD3  Diameter in a DTLS/SCTP DATA chunk    [ RFC-to-be ]  TBA

Finally, in the S-NAPTR Application Protocol Tag registry in the
Straightforward-NAPTR (S-NAPTR) Parameters located at:

http://www.iana.org/assignments/s-naptr-parameters/s-naptr-parameters.xml

The following Application Service Tag will be registeredL

Tag:  diameter.dtls.sctp
Reference: [ RFC-to-be ]

IANA understands that these are the only actions that need to be
completed upon approval of this document.

[Ballot comment]
#1) s1, p 8: The following indentation seems to be off:

    In addition to addressing the above requirements, Diameter also
    provides support for the following:

  Capability negotiation

I think it ought to be:

  In addition to addressing the above requirements, Diameter also
  provides support for the following:

  Capability negotiation

#2) s1.1.3: It's probably worth noting that you incorporated the errata filed on RFC 3588.  Also, it seems like this version deprecates use of Application ID

#3) s1.3.1 and s1.3.2: Should "recommended" be "RECOMMENDED".  2119 language hadn't been used until 1.3.3, so maybe it should be used in 1.3.1 and 1.3.2.

#4) s2.1 and/or s12: For the Tc timer should it recommended be RECOMMENDED? i.e.,:

  r/recommended value is 30 seconds/RECOMMENDED value is 30 seconds

#5) s2.4: Should "mandatory" be "REQUIRED":

  The base protocol does not require an Application Id since its support
  is mandatory.

#6) s2.5: Need a period at the end of the following sentence:

  Additional security information, when needed (e.g., keys,
  certificates)

#7) s2.7: Need a period at the end of the following sentence:

  See Section 6.1.9 for relaying guidelines

#8) s2.7: Server Identifier must also appear in the peer table, but there's no server identifier listed in s2.6.  If server=host then that'd be good to say in s2.7.

#9) s2.8.1 and 2.8.3: Are DRL, HSM, and DRD acronyms?  Not entirely sure.

#10) s3: the reference for Command Codes in 11.3 is wrong.  I think it's supposed to be 11.2.

#11) s3: Hop-by-Hop and End-to-End identifiers paragraphs should add a pointer to RFC 4086 for guidelines on randomness.  You could also just put a catchall sentence in the security considerations (I see there's one in 6.1.9 for keys).

#12) s3.2: So this is a stupid question, but does the example add spaces?

  Example-Request ::= < Diameter Header: 9999999, REQ, PXY >

There's no space between "<" and "Diameter Header:" in the header ABNF or between "Diameter Header:" and the command-id.  There are between the r-bit, p-it, and e-bits.  ALso are there spaces needed in the ABNF for the "< ", " >", "{ ", " }", "[ ", and " ]" in fixed, optional, and qual?

#13) s4.1.1: r/The AVP Header contains one optional field./The AVP Header contains one OPTIONAL field.

#14) s4.1.1, 5.3.3, 5.3.6: The IANA Enterprise Numbers registry refers to RFC 2578 and not RFC 3232.  Shouldn't the reference in the draft match the reference in the registry to help people find it?  Better yet add a reference to: http://www.iana.org/assignments/enterprise-numbers

#15) s4.3.1: what no "aaas:" example? ;)

#16) s4.4: Indentation of the following is odd:

                          grouped-avp-def  =  "::=" avp

#17) s4.5: Are there really still space constraints?  The current table has a lot less columns than RFC 3588.  Maybe just put in an RFC editor note asking them to put the Attribute name all on one line.

#18) s5.2: Name matching has proved to be a challenge for many in the TLS/DTLS environment.  A pointer to RFC 6125 would be much appreciated.

#19) s5.2: r/Server CA/Server Certification Authority (CA)

#20) s5.2.: Contains the following:

  Authorization can be achieved for example, by configuration of a
  Diameter Server CA.  Alternatively this can be achieved by definition
  of OIDs within TLS/TCP and DTLS/SCTP or IKE certificates so as to
  signify Diameter Server authorization.

Is configuring the CA one option - but what's the alternative?  I think you mean to say that that:

  Authorization can be achieved for example, by configuration of a
  Diameter Server CA. The Server CA issues a certificate to the
  Diameter Server, which includes an Object Identifier (OID) to indicate
  the subject is a Diameter Server in the Extended Key Usage extension
  [RFC5280].  This certificate is then used during TLS/TCP, DTLS/SCTP, or
  IKE security negotiation.

So I looked in the PKIX registry are there any actually defined?  If none are maybe add that none are defined at this time.

#21) s5.3:

r/ A Diameter node MUST cache the supported applications/ A Diameter node MUST cache the supported Application IDs ?

r/Section 7.)/Section 7)

r/Host-IP- Address/Host-IP-Address

#22) s6.1.9:
r/is distribute/is distributed
r/a keyed message digest (e.g., HMAC-SHA1) [RFC2104].
r/commonly recommended:/common recommendations:

Also need to add reference to RFC 2104

#23) s5.3.1, s5.3.2, s5.4.1, s5.4.2, s5.5.1, s5.5.2. s8.3.1, s8.3.2, s8.4.1, s8.4.2, s8.5.1., s8.5.2, s9.7.1, s9.7.2: After reading s6.7.2 and s6.11, I wonder if the sections listed should also indicate that they are "of type grouped"?

#24) s6.10: NOT RECOMMENDED is 2119 language you just have to add it to the 2119 section.  I think what you're trying to say here:

  The use of this AVP in CER and CEA messages is no
  longer recommended.

is

  The use of this AVP in CER and CEA messages is NOT RECOMMENDED.

#25) s6.10: The reference for TLS is 5246, but for DTLS it's 6083.

#26) s7.1.1 and s7.1.3: Should these sections indicate that they "MUST be used in messages whose 'E' bit is not set"?  I know it seems obvious, but I've seen people implement whacky things.

#27) s7.5: r/A Diameter message SHOULD/A Diameter answer message SHOULD

#28) s7.7: r/It is recommended that/It is RECOMMENDED that

#29) s8.4.1, s8.4.2, s8.5.1., s8.5.2: "Message Type" indentation is off.

#30) s8.8: OLD:

  Session-Id is delimited by a ";" character, and MAY be any sequence
  that the client can guarantee to be eternally unique; however, the
  following format is recommended, (square brackets [] indicate an
  optional element):


NEW:

  Session-Id is delimited by a ";" character, and MAY be any sequence
  that the client can guarantee to be eternally unique; however, the
  following format is RECOMMENDED, (square brackets [] indicate an
  OPTIONAL element):

#31) s8.9: r/Authorization- Lifetime/Authorization-Lifetime

#32) s9.3: not sure the last para should be indented

#33) s14: To avoid being Alfreded, reorder the RFC references to go from low to high.

[Ballot discuss]
#1) I'm confused by the following two statements:

from abstract:

  The Diameter base protocol as defined in this document
  obsoletes RFC 3588 and must be supported by all new Diameter
  implementations.

from s2.1:

  If the Diameter peer does not support receiving TLS/TCP and DTLS/SCTP
  connections on port [TBD], i.e. the peer complies only with
  [RFC3588], then the initiator MAY revert to using TCP or SCTP and on
  port 3868.

from s13:

  However, all Diameter base protocol implementations
  MUST support the use of TLS/TCP and DTLS/SCTP and the Diameter
  protocol MUST NOT be used without any security mechanism.

If all new Diameter applications support the TLS/TCP an DTLS/SCTP, how is an application not going to support accepting TLS/DTLS connections on port [TBD]?  Also in s2.1 would it really be the "initiator" or would it be "peers"?

#2) s1.1.1 and s11.2.1: This section mentions 5729 as part of the document set, but 5719 (which updates RFCC 3588) isn't mentioned.  Are the contents of 5719 included in this draft?  If so, shouldn't 5719 be added to the obsoletes header?

#3) s2.2 and s13.1: I support Stephen's discuss position.  I guess I'd note the same fix needs to be applied to s2.2.

#4) s2.6 and s2.7: What's the format for the expiration time?  MUST it be the format specified in 4.3.1 or is up to an implementation?  If it's the former, a pointer s4.3.1 is needed.

#5) s1.3.4, s2.4, s3, s6.11: There's no application IDs in Section 11.3.  Is the section missing!?  RFC 3588 had a section for Application Identifiers in the IANA section - this draft does not.

#6) s5.2 and 11.6: This draft needs to normatively reference http://datatracker.ietf.org/doc/draft-ietf-dime-extended-naptr/ for the S-NAPTR application service tags 'diameter.tcp', 'diameter.sctp', 'diameter.tls.tcp'.  They're not defined in the this document and they don't appear to be in RFC 3588.

#7) s6.1.2 and s3: s6.1.2 includes the following text:

  The Hop-by-Hop Identifier SHOULD be set to a locally unique value.

s3 contain the following text

  The sender MUST ensure that the Hop-by-Hop identifier in a request
  is unique on a given connection at any given time, and MAY attempt
  to ensure that the number is unique across reboots.

don't these contradict each other?  Seems like in s6.1.2 r/SHOLD/MUST ?

#8) s11: If this document is obsoleting RFC 3588 shouldn't all the information found in RFC 3588's IANA section be included here?  If not an implementer is going to need to pull out RFC 3588 + 5917, doesn't it make much more sense to have one standalone document for implementers?

#9) s11.2: The contents of the RFC 5719 IANA considerations are mostly included but the first paragraph isn't the same - should they be the same?

#10) s13: The peer and routing tables use expiry time.  Certificates used in TLS/DTLS/IKE also contain expiry times.  I think a considerations that says something about checking to make sure the peer and routing table expiry times are never beyond the expiry time in certificates.  If you allow the expiry time to extend beyond the validity period in the certificate, it would be a bad thing.  If the connections are very short lived then it might not be big deal, but if they're long-lived then there's more to worry about.

#11)



I'm hoping the answer to this is yes, but I had to ask because I didn't see it in the proto write-up:

This document doesn't have a pre-5378 disclaimer and the author set is not the same as RFC 3588.  Have Erik and Pat granted the rights to the IETF Trust to allow the document to be published without the pre-5378 disclaimer?

[Ballot comment]
1. In Section 1.3.3, this specification has "[d]eprecated the exchange of CER/CEA messages in the open state" but "assume[s] that the capabilities exchange in the open state will be re-introduced in a separate specification". Do we really want to actively deprecate something that it's assumed will return in the not-too-distant future? Or do we want to change "will be re-introduced" to "might be re-introduced"?

2. It might be helpful to explain why the End-to-End security framework has been deprecated. Did it not work properly? Did no one implement it? Were there such significant interoperability problems that it was deemed better to scrap it? And, will it be (or does it need to be) replaced by something else?

[Ballot discuss]
RFC 3588 used DNS SRV Proto values of 'tcp' and 'sctp' for the SRV Service of 'diameter'. 3588bis seems to add two more Proto values: 'tls' and 'dtls'. However, RFC 6335, which defines updated rules for the ports and services registry, allows only TCP, UDP, SCTP, and DCCP as transport protocols. Furthermore, this specification does not register the 'diameter' SRV Service value in accordance with RFC 6335. Because these values were not defined or registered by draft-ietf-dime-extended-naptr, I think they need to be defined here.

[Ballot comment]
Overall - It took quite a while (I think until I was well into section 6) for me to figure out that the document means two different things by "ABNF". There's the *real* ABNF that appears in (e.g.) section 3.2, and then there's the Command Code syntax, which you also refer to later as "ABNF". This was very confusing. Maybe this use is so entrenched now that it's not worth changing, but "CCBNF" for the latter might be nice.

Section 3.2:

  command-def      =  "::=" diameter-message

As far as I can tell, the angle brackets around "command-name" are incorrect.

  diameter-name    = ALPHA *(ALPHA / DIGIT / "-")

Just confirming: You do allow "z----------" as a legal diameter-name?

  diameter-message = header  [ *fixed] [ *required] [ *optional]

The square brackets are superfluous. The leading asterisk already means zero or more. It also looks to me like the fixed ones always must be right after the header and the required and optional can be in any order after that. What you probably want is:

  diameter-message = header *fixed *(required/optional)

That's more precise in what you want.

  Example-Request ::= < Diameter Header: 9999999, REQ, PXY >
                      { User-Name }
                    * { Origin-Host }
                    * [ AVP ]

I am confused as to what "* { Origin-Host }" could mean. How can something be both required and have a "*", which means "zero or more"? Can there actually be zero of a required AVP?

Section 4.3.1:

      FQDN              = Fully Qualified Host Name

Here I think there you want:

      FQDN              =

Section 4.4: See comments on 3.2. Same sorts of issues.

[Ballot comment]
In section 1.3.1's second paragraph, starting the second sentence with
"Typically," is likely to introduce confusion about the allocation policy.
Why is the word needed in this sentence?

In section 2, 2nd to last paragraph before section 2.1: This edit (moving
how tranparency is described) resulted in a sentence that says Diameter Relays
and redirect agents MUST support all Diameter applications. Please consider
touching it again to make it clearer that those elements MUST be transparent
to the applications, and as a result trivially support them.

In section 2.1, 3rd paragraph when discussing reverting to TCP or SCTP,
please consider pointing out that section 2.2 still requires _SOME_ security
mechanism be used.

The edits to the first paragraph of the description of AVP flags left
the sentence "Unrecognized bits SHOULD be considered an error." unsupported.
It's not clear (without looking at the diff to 3588) what bits might
possibly be unrecognized.

In section 6.1.2, can the document say why the hop-by-hop identifier
SHOULD be locally unique rather than MUST be?


NITS:
In section 1.3.1 paragraph 1, the reference to 11.4 should be 11.3.

Section 2.7 Realm Name: s/that is MUST/that MUST/

Section 6.1.9: s/list of commonly recommended/list of common recommendations/

Something is wrong with this line in section 7.2
(The line is unchanged from 3588, but if this is a bug, it should be
addressed at some point).
      ::= < Diameter Header: code, ERR [PXY] >
That has either one too many or one too few commas in it.

The following is a pedantic nit, but please consider addressing it.
In several places (both in text from 3588 and new text introduced as
part of this effort), the text refers to the definitions of commands
in the representational language defined in section 3.2 as ABNF. For
example:
  The Grouped Data field has the following ABNF grammar:

        Proxy-Info ::= < AVP Header: 284 >
                        { Proxy-Host }
                        { Proxy-State }
                      * [ AVP ]

That is not ABNF. Instead, it is a well formed message in a language described
by the ABNF in section 3.2. It would be better to say something like
"The Grouped data field has the following Command Code specification:".

[Ballot discuss]
The document reflects the change of the name of the Well-Known
IANA policy definition from "IETF Consensus" to "IETF Review", but
seems to state that this is a change of policy rather than a change
of the policy name (as explained in RFC5226).  Specifically, it says
"now only require IETF Review as opposed to an IETF Consensus".
Has the working group captured what it intended?

This sentence in section 2.1 is not clear:
  For TLS [RFC5246] and DTLS [RFC4347], a Diameter
  node that initiate a connection prior to any message exchanges MUST
  run on port [TBD].
What was its intent? It could be misread to say that you cannot establish
a connection on any other port than [TBD].

In the new text on dynamic agent discovery, Section 5.2 part 3 -
should an element that's looked up SRV records as specified in this
item follow all of the requirements in RFC 2782 if multiple SRV records
are returned (in particular, following the balancing algorithm over
records with the same Priority)? Shouldn't this section reference RFC 2782?

In the new text on the Election Process, "lexicographically succeeds" needs
additional description.

The note at the end of 6.1 is very ambiguous - does "this section" mean
just 6.1, but not 6.1.1 through 6.1.9, or did it mean to include those
subsections?  Either way, it leaves the requirements language very hard
to follow.  Does this say certain implemenentations MAY ignore some MUSTs?
If so, which ones?

[Ballot discuss]
Hopefully this is a no-brainer and just a simple clarification is needed.

13.1 says that (D)TLS is now a MUST implement and IPsec is a MAY
and using TLS is a SHOULD and using some security is a MUST, all of
which is great. However, one question - when it says Diameter MUST
NOT be used without "some security mechanism" does that mean one of
(D)TLS or IPsec MUST be used? If so, then saying so would be good,
since otherwise someone may claim to be conforming because they're
using something home-grown which would not be good really. I think
this can be fixed by simply changing the end of the 1st para of 13.1
to "..the Diameter protocol MUST NOT be used without one of TLS,
DTLS or IPsec." If you do want to allow "some security mechanism" to
mean something else then I think you need to characterise that more
tightly.

[Ballot comment]
- 5.2 says that "OIDs within...certificates" can be used to "signify
Diameter Server authorization" - have those been defined since 3588?
If so, then a reference here would be good. If not, that's a pity...

- The IPR declaration confuses me. RFC 3588 is dated September 2003.
The declaration says it relates to a filing from November 2003, and
3588bis doesn't seem to add anything of note other than
clarifications. But I guess since its "recriprocity" that'll just
have to go down as yet another wonder of the patent world;-)

[Ballot discuss]
Hopefully is a no-brainer and just a simple clarification is needed.

13.1 says that (D)TLS is now a MUST implement and IPsec is a MAY
and using TLS is a SHOULD and using some security is a MUST, all of
which is great. However, one question - when it says Diameter MUST
NOT be used without "some security mechanism" does that mean one of
(D)TLS or IPsec MUST be used? If so, then saying so would be good,
since otherwise someone may claim to be conforming because they're
using something home-grown which would not be good really. I think
this can be fixed by simply changing the end of the 1st para of 13.1
to "..the Diameter protocol MUST NOT be used without one of TLS,
DTLS or IPsec." If you do want to allow "some security mechanism" to
mean something else then I think you need to characterise that more
tightly.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Diameter Base Protocol) to Proposed Standard


The IESG has received a request from the Diameter Maintenance and
Extensions WG (dime) to consider the following document:
- 'Diameter Base Protocol'
  as a Proposed Standard

The document was already last-called, but because of the extensive and
non-editorial changes it went through, the editors, document shepherd
and Area Director decided to submit it again to broad IETF review.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-09-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The Diameter base protocol is intended to provide an Authentication,
  Authorization and Accounting (AAA) framework for applications such as
  network access or IP mobility in both local and roaming situations.
  This document specifies the message format, transport, error
  reporting, accounting and security services used by all Diameter
  applications.  The Diameter base protocol as defined in this document
  obsoletes RFC 3588 and must be supported by all new Diameter
  implementations.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1437/

State changed to AD is watching::Revised ID Needed from Waiting for AD Go-Ahead.
At IETF-79 the WG decided to include in this version of Diameter support for Diameter over SCTP and asked for the document to be updated and brought up again to WG and IETF consensus before it is submitted to IESG evaluation.

IANA has a question about the IANA Actions related to this document.

In Section 11, the IANA Considerations section, there is significant
discussion of IANA registries. However, it is not clear to us what the
relationship between these IANA actions and the existing registries
located at

http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml

should be.

Specifically:

- is this a request for IANA to replace the registries at
aaa-parameters.xhtml?

- if not, where the registrations in this document represent a subset of
the current registrations, what should IANA do with the remaining
registrations?

- is this a request to simply update the references and registration
procedures for these existing registries to refer to the RFC-to-be and
update (where needed) the registration procedures?

- the only "new" registration appears to take place in section 11.6 the
S-NAPTR Application Service Tag and Protocol Tags. Is this correct?

(1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

        --
Jouni Korhonen (jouni.korhonen@nsn.com, jouni.nospam@gmail.com)
        is the Document Shepherd, Dime co-chair. He has done a review
        on the document and believes it is ready to be forwarded to
        IESG for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

        --
The document has had an extensive review by the DIME WG and
        the larger community interested in Diameter.

The shepherd has reviewed the document himself and has no
issue with it. Nor the shepherd has issues with the reviews
done by others.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

        --
No.


  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

        --
No.


  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

        --
        The consensus behind the document is solid and a result of
        a long process. The document spent quite few years in the WG.
        Therefore, if someone in the WG had real concerns those have
        been heard and addressed.


  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

        --
        No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

        --
        The shepherd has checked the document with the idnits tool.
        No errors are reported. Warnings reported are due the
        indits tool misinterpreting some abbreviations as references
        or editorials that can only be fixed manually. Comments
        have similar indits reports as warnings.

        The document does not need MIB doctor review. Possible
        media and URI types are directly lifted from the existing
        RFC 3588, thus not needing any further reviews.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

        --
        References are split accordingly and there are no references
        to documents with unclear status or are in progress.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol

        --
        Yes.

        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If

        --
        Yes. Care should taken by IANA when verifying IANA
        considerations as this document is a bis to RFC 3588 and
        therefore most of the IANA registries have already been
        created.

        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

        --
        For the Expert Review members of the AAA Doctors should be
        appointed to the review process.


  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

        --
        Yes. Note that the RFC 3588bis uses a modified ABNF, which
        means the online ABNF checker tool will report an error
        e.g. for Grouped AVPs.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary

        --
        This document is a bis version of RFC 3588 and will eventually
        obsolete RFC 3588. The document corrects a number of known
        errors and flaws in RFC 3588, and deprecates some feature
        that are known to be unusable. For a detailed list of
        changes refer to Section 1.1.3. of this document.


    Working Group Summary

        ---
        The document spent almost four years in the WG, which is
        unreasonably long time. This was not a result of large
        controversy, but rather ensuring nothing important breaks
        in backwards compatibility.

    Document Quality

        ---
        FreeDiameter (www.freediameter.net) implements -21 version
        of the specification.

        A number of vendors have indicated interest on implementing
        the specification due it correcting several known flaws.

        There has been no MIB Doctor or Media Type reviews as those
        were not seen relevant for the bis version of the specification.
        There has not been explicitly requested expert reviews outside
        the WG as we believe most if not all important technical experts
        are already represented in the WG and its mailing list. The
        document has received multiple reviews while in WGLC.

[Note]: '(1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

         --
Jouni Korhonen (jouni.korhonen@nsn.com, jouni.nospam@gmail.com)
         is the Document Shepherd, Dime co-chair. He has done a review
         on the document and believes it is ready to be forwarded to
         IESG for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

         --
The document has had an extensive review by the DIME WG and
         the larger community interested in Diameter.

The shepherd has reviewed the document himself and has no
issue with it. Nor the shepherd has issues with the reviews
done by others.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

         --
No.


  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

         --
No.


  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?  

         --
         The consensus behind the document is solid and a result of
         a long process. The document spent quite few years in the WG.
         Therefore, if someone in the WG had real concerns those have
         been heard and addressed.


  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

         --
         No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

         --
         The shepherd has checked the document with the idnits tool.
         No errors are reported. Warnings reported are due the
         indits tool misinterpreting some abbreviations as references
         or editorials that can only be fixed manually. Comments
         have similar indits reports as warnings.

         The document does not need MIB doctor review. Possible
         media and URI types are directly lifted from the existing
         RFC 3588, thus not needing any further reviews.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

         --
         References are split accordingly and there are no references
         to documents with unclear status or are in progress.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol

         --
         Yes.

        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If

         --
         Yes. Care should taken by IANA when verifying IANA
         considerations as this document is a bis to RFC 3588 and
         therefore most of the IANA registries have already been
         created.

        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

         --
         For the Expert Review members of the AAA Doctors should be
         appointed to the review process.


  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

         --
         Yes. Note that the RFC 3588bis uses a modified ABNF, which
         means the online ABNF checker tool will report an error
         e.g. for Grouped AVPs.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

     Technical Summary

         --
         This document is a bis version of RFC 3588 and will eventually
         obsolete RFC 3588. The document corrects a number of known
         errors and flaws in RFC 3588, and deprecates some feature
         that are known to be unusable. For a detailed list of
         changes refer to Section 1.1.3. of this document.


     Working Group Summary

         ---
         The document spent almost four years in the WG, which is
         unreasonably long time. This was not a result of large
         controversy, but rather ensuring nothing important breaks
         in backwards compatibility.

     Document Quality

         ---
         FreeDiameter (www.freediameter.net) implements -21 version
         of the specification.

         A number of vendors have indicated interest on implementing
         the specification due it correcting several known flaws.

         There has been no MIB Doctor or Media Type reviews as those
         were not seen relevant for the bis version of the specification.
         There has not been explicitly requested expert reviews outside
         the WG as we believe most if not all important technical experts
         are already represented in the WG and its mailing list. The
         document has received multiple reviews while in WGLC.
' added by Amy Vezza