RE: Status of Issue 225

["Glen Zorn" <glenzorn@comcast.net>]

> Bernard Aboba wrote:
> > During the RADEXT WG last call on the RADIUS Extended Attributes
> draft,
> > you filed Issue 225:
> > http://www.drizzle.com/~aboba/RADEXT/
> >
> > The editor of the document, Glen Zorn, has now listed Issue 225 as
> > resolved.  However, before
> > closing this issue, we wanted to get your consent.   Please send a
> note
> > to the RADEXT WG
> > mailing list indicating whether Issue 2225 is in fact resolved to
> your
> > satisfaction, and if not,
> > what portion of the issue remains outstanding.  The latest version of
> > the Extended Attributes
> > document is available for inspection here:
> > http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-05
> 
>   The issue that still need addressing are:
> 
> --
> Section 4:
> ...
>  I suggest also noting that "Extended-Length = Length - 6".  Otherwise,
> it becomes theoretically possible for them to have conflicting values
> ---
> 
>   It is not *ridiculously* clear from the current document that
> "Length"
> and "Extended-Length" are strongly related.  

Maybe not to you...

> I suggest a MUST:
> 
> --
>    Ext-Len
> 
>       >= 3.  The length of the Type-Length-Value tuple in octets,
>       including the Ext-Type, Ext-Len and Value fields.  The contents
>       of the Ext-Len field MUST be 6 less than the contents of the
>       Length field.  That is: Ext-Len = Length - 6.
> --
> 

This would disallow the presence of multiple AVPs in a single attribute.
Are you claiming "WG Consensus" for this massive change?  

>   Experience shows that without this text, people will create
> attributes
> that don't satisfy this criteria... and claim they're standards
> compliant.

This comment is fascinating.  What, exactly, is the "experience" you are
talking about?  Are there already multiple implementations of the extended
attributes?  Have you perfected time travel?  

> 
> --
>   Also, attributes generated by a client or server MUST NOT be
> fragmented at boundaries other than 246 octets.  Doing so would
> decrease
> the efficiency of packing.  Robust implementations SHOULD support
> receiving attributes fragmented at non-246 octet boundaries.
> --
> 
>   The only reference to 246 octets in the document says that attributes
> *can* be fragmented at 246 octets.  It doesn't forbid fragments smaller
> than that.
> 
>   Experience shows that without this text, people will create short
> fragments, causing problems for everyone else.

More "experience".  Where does this "experience" come from?  The only
problems caused will be for those who wrote code that can't handle fragments
< 246 in length.

> 
>   Alan DeKok.
> 
> --
> 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/>


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