[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
[gwz] ...
> Does this mean to reference RFC 3575?
> [gwz]
> [gwz] Possibly; if so, I don't think it's really appropriate here since
> virtually nothing 3575 has to say about attributes seems to apply here.
I believe that if RFC 3575 does not sufficiently cover the allocation
procedures for the Extended RADIUS Attribute registry (which may be a
sub-section of the existing RADIUS Registry), then this draft needs to
contain RFC 3575 like instructions to IANA for a code-point allocation
policy.
Could you please elaborate on why what RFC 3575 has to say about the ongoing
allocation policy does not apply here?
[gwz] Everything it says is specific to the existing standard attributes.
For example: "Attribute Types have a range from 1 to 255, and are the
scarcest resource in RADIUS, thus must be allocated with care." The
Extended Attribute scheme provides an essentially unlimited type range.
Similarly, I can't think of any good reason why Extended Attributes need to
be allocated by "IETF Consensus" instead of "Specification Required".
--
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/>