[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Status of Issue 225
Bernard Aboba wrote:
> During the RADEXT WG last call on the RADIUS Extended Attributes draft,
> you filed Issue 225:
> 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:
The issue that still need addressing are:
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. I suggest a MUST:
>= 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.
Experience shows that without this text, people will create attributes
that don't satisfy this criteria... and claim they're standards compliant.
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
Experience shows that without this text, people will create short
fragments, causing problems for everyone else.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.