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

Re: 6rd attribute compromise?

Jiangsheng wrote:
> The format design of this 6rd attribute was to be the same with 6rd DHCPv4 Option, please see section 7.1.1 of RFC 5969.

  Please see RFC 6158, Section 3.2.4.  If you are transporting a
pre-defined data type in RADIUS, then don't re-define it in RADIUS.
Instead, just say "this attribute has the format as described in RFC
5969 Section 7.1.1"

> However, if this is not compatible with RADIUS, we would like to accept any suggestion from RADEXT WG. So, the first question is whether our current 6rd attr design is NOT acceptable by RADIUS.

  It does not follow the guidelines set down in RFC 6158.

> If the answer is NO, Peter's suggestion looks good for us except why a Reserved byte.

  I think using TLVs for this attribute would be a good choice, but not
necessarily better than referring to a pre-existing data format.

> We do not understand Alan's third approach. Could Alan explain a little bit more, "An alternative approach would be to publish a "new data types" RFC,
> containing just TLV and 64-bit integer data types." And how this relevant to our 6rd attribute?

  You could use the new data types in the document, rather than
inventing a data type which is incompatible with existing RADIUS practice.

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