[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Further comments on the draft:
Although according to the specification the allocation of RADIUS
attribute type codes has been controlled by IANA, this has not been
the case in reality. In the real world, certain vendors have grabbed
attribute type codes that they shouldn't have. The result is that
many RADIUS deployments have had to work around these attribute
collisions. Therefore, each time a new attribute type is introduced
it raises the possibility that something will break. The proposed
scheme must be impervious to this artifact.
I suggest deleting this paragraph. It duplicates some content of RFC 3575
and adds nothing to the purpose of this document, going forward.
This solution requires that the IETF be allocated Vendor-Type of zero
to the IETF.
RFC 2865, Section 5.26 says, in part:
The high-order octet is 0 and the low-order 3 octets are the SMI
Network Management Private Enterprise Code of the Vendor in
network byte order, as defined in the "Assigned Numbers" RFC .
Taken together, these sections of text might be interpreted to mean that the
IETF is assigning a Private Enterprise Code of 0 to itself. The PEN
Registry at the following URL:
Internet Assigned Numbers Authority
that 0 is reserved for IANA. Is that the same as reserved for IETF use?
Should we add clarifying text to indicate that the Vendor-Id of 0 is not
strictly a PEN?
It also requires that IANA be set up to manage the RADIUS Extended
This means that there would be a new section in the existing RADIUS Registry
dealing with IETF VSA Extended-Type field.
The allocation rules for extended RADIUS attributes align with the
rules for allocation of the standard RADIUS attributes.
Does this mean to reference RFC 3575?
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.