Remote Authentication Dial In User Service (RADIUS) Protocol Extensions
RFC 6929

Note: This ballot was opened for revision 09 and is now closed.

(Benoît Claise) Yes

(Barry Leiba) Yes

Comment (2013-02-05 for -11)
No email
send info
I had an excellent set of exchanges with Alan Dekok, in which he sorted out all my issues (reflected in the -11) version.  There remain a couple of minor things we disagree on, but that will happen, and they are minor.  Thanks very much to Alan for the quick turnaround and good work.

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2013-02-18 for -11)
No email
send info
- p9, typo, missing "with" in 2nd last para, should say
"compatible with RADIUS"

- p15, suggest s/Use of non-standard data types SHOULD NOT be
done./Non-standard data types SHOULD NOT be used within TLVs./

- p16, saying multiple TLVs are "a set or list of values" is
maybe a bit misleading, e.g. ASN.1 SETs are unordered lists
whereas SEQUENCE OF are ordered. I don't care which you want or
if you don't want to pick, but saying what you do mean about
ordering would be good.

- p17, I wondered is String values are allowed to be or are
typically null terminated or not.

- p22, seems odd to me that a TLV can contain an invalid
attribute, but itself not be invalid. But I guess you have
reasons. That does seem to create meaningful attributes inside
TLVs with e.g. zero length, so I'm surprised you don't say that
that is now allowed. 

- p54, I wondered why you didn't include references to RFC 6614
and 6151 where you talk about MD5 weakness. I think both would
be useful.

(Brian Haberman) No Objection

(Russ Housley) No Objection

(Pete Resnick) No Objection

Comment (2013-02-19 for -12)
No email
send info
2.1, 2.2, 3.1-3.6: 

      The Value field is one or more octets.  Implementations not
      supporting this specification SHOULD support the field as
      undistinguished octets.

So are you really expecting implementations not to support this specification but still make changes to treat these fields as undistinguished octets? If so, then I'd reword to:

      The Value field is one or more octets. An implementation that
      does not fully implement the remainder of specification SHOULD
      still treat the field as undistinguished octets.

Or did you mean by "SHOULD support" that "we believe they should be able to support"? It's just a strange sentence.
  
6.4:

   * The "integer64" data type MAY be used in any RADIUS attribute.
     The use of 64-bit integers is NOT RECOMMENDED by [RFC6158], but
     their utility is now evident.

I would avoid the use of NOT RECOMMENDED in there; it is potentially confusing. 6158 said it was not recommended, but you are now changing that requirement.
     
6.6:

There are assorted silly uses of 2119 language throughout the document, and I wish you would go through and review them to make sure they meet the requirements of 2119. That said, this one was especially silly:

   * Discretion is RECOMMENDED when requesting allocation of attributes.
     The new space is much larger than the old one, but it is not
     infinite.

A requirement on discretion seems a bit overdone.

(Robert Sparks) No Objection

Comment (2013-02-21 for -12)
No email
send info
RECOMMENDED is an alias for SHOULD. When you say "Discretion is RECOMMENDED when requesting allocation of attributes." you are saying that requests SHOULD show discretion. When would it be ok to _not_ show that discretion. I suggest rewriting this as guidance to authors and not use the 2119 keyword.

(Martin Stiemerling) No Objection

(Sean Turner) No Objection