[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: RADEXT charter for comment...

It was not clear to me (and may not be clear to other readers in the future) that this line in the charter is intended to refer to the structure of vendor specific attributes. In fact, in looking at 2865 for a context for the line, the definition of VSAs was one part I assumed was not intended.

Yours,
Joel M. Halpern

At 11:53 AM 3/11/2004 -0500, Nelson, David wrote: 
> - Sub-attributes MUST be utilized only in a manner compatible with RFC
>   2865.

The relevant text from RFC 2865 is:

      "It SHOULD be encoded as a sequence of vendor type / vendor length
      / value fields, as follows.  The Attribute-Specific field is
      dependent on the vendor's definition of that attribute.  An
      example encoding of the Vendor-Specific attribute using this
      method follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |  Length       |            Vendor-Id
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Vendor-Id (cont)           | Vendor type   | Vendor length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Attribute-Specific...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

      Multiple subattributes MAY be encoded within a single Vendor-
      Specific attribute, although they do not have to be."

So the "SHOULD" (above) is being promoted to a "MUST" for work within
the scope of RADEXT, correct?  Is it clear from this snippet of RFC 2865
that the nesting of sub-attributes is only one layer deep?  That is my
interpretation.



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