|
I have some additional comments on the document: 1. Diameter Considerations. There currently is no Diameter Considerations section. One issue that arises is how to map the Extended Attribute space into the Diameter attribute space. Since Diameter AVP numbers have been assigned with codes >255, the mapping requires an offset to be added to RADIUS Extended Attribute codes. Off the top of my head, I am clear what this offset should be. Also, I think there is the issue of how the extended grouped attributes are mapped into grouped Diameter AVPs. 2. IANA considerations. The text in the current document is minimal, and I think there is room for considerably more discussion there. Given the potential differences in treatment of attributes within the VSA space and standard RADIUS attributes, I think that the IANA considerations should indicate that Extended Attributes should initially be allocated only on request. However, as the standard RADIUS attribute space is exhausted, there will eventually be no choice but to allocate out of the extended space. The question is how attributes should be allocated. > Date: Mon, 11 Feb 2008 23:30:50 -0500 > From: gdweber@gmail.com > To: radiusext@ops.ietf.org > Subject: LC cmts: Extended Attrs > > I have some comments on: draft-ietf-radext-extended-attributes-00.txt > > * In section 5, the Ext-Length field is defined as the length of the Extended > Attribute. I think you mean it's the length of the TLV (multiple TLVs can be > in the Extended Attribute). I think that would make the value ">=3", not ">=4". > > * It's probably worth calling out any artifacts of overloading attribute 26 > which wouldn't apply to standard attributes in the original number space > (or apply to overloading a new attribute instead of 26). For example, > attribute 26 is already specifically excluded from some RADIUS message > types, e.g. CoA-NAK, so new Extended Attributes couldn't be included in > those messages, but new standard attribute could be. Also, are malformed > VSAs always treated just like malformed non-VSAs? > > * I think it would be useful to explicitly mention if recursive grouping is > allowed and that Extended Attributes cannot be grouped with non-Extended > Attributes. > > * It's probably useful to mention what happens when an Extended Attribute's > tag is non-zero and it contains multiple TLVs (this does not seem to be > excluded -as multiple TLVs are when the M-bit is on). > > * RFC2865 specifically calls out the proxies can't reorder attributes > of the same > type; does this doc need to create the same restriction for Ext-Type? > > * I actually didn't have a lot of editorial comments :-) Possibly the M-bit > could be renamed to avoid potential confusion with Diameter. > > Greg > > > On Feb 10, 2008 3:50 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote: > > > > This is a reminder of the ongoing RADEXT WG last call on the Extended > > RADIUS Attributes document, prior to sending it to the IESG for > > consideration as a Proposed Standard. The document is available for > > inspection here: > > http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-00.txt > > > > RADEXT WG last call will last until February 14, 2008. Please send comments > > to the RADEXT WG mailing list (radiusext@ops.ietf.org) in the format > > described on the RADEXT WG Issues page: > > http://www.drizzle.com/~aboba/RADEXT/ > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://psg.com/lists/radiusext/> |