Re: Status of Issue 225

[Alan DeKok <aland@deployingradius.com>]

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

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

  Experience shows that without this text, people will create short
fragments, causing problems for everyone else.

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