Subject: LC cmts: Extended Attrs

From: "Greg Weber" <[email-masked]>
Date: Mon, 11 Feb 2008 23:30:50 -0500

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 <[email-masked]> 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 ([email-masked]) in the format
> described on the RADEXT WG Issues page:
> http://www.drizzle.com/~aboba/RADEXT/

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 11 Feb 2008 22:18:37 -0800

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: [email-masked]> To: [email-masked]> 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 <[email-masked]> 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 ([email-masked]) in the format> > described on the RADEXT WG Issues page:> > http://www.drizzle.com/~aboba/RADEXT/> > --> to unsubscribe send a message to [email-masked] with> the word 'unsubscribe' in a single line as the message text body.> archive: <http://psg.com/lists/radiusext/>

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 12 Feb 2008 20:18:10 +0700

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.   
Why don't you think that section 9.6.2 of RFC 4005 applies here (w/the
possible exception of setting the Mandatory bit)?.  
 
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.  
I disagree.  It seems to me that the new, empty space should be used
first whenever possible; it is conceivable that some application might
absolutely require a legacy standard attribute when they're all gone.
In addition, I think that phasing in extended attributes slowly might
lessen the chance that implementors will ignore them until the last
minute.  OTOH, I'm not religious about it.
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: [email-masked]
> To: [email-masked]
> Subject: LC cmts: Extended Attrs
> 
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attribute
s-00.txt