Remote Authentication Dial In User Service (RADIUS) Protocol Extensions
draft-ietf-radext-radius-extensions-13

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.

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.

- 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.