RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt

["Glen Zorn" <glenzorn@comcast.net>]

Further comments on the draft:

Section 2.

   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.
[gwz] 
[gwz] Done.

Section 7.

   This solution requires that the IETF be allocated Vendor-Type of zero
   to the IETF.

RFC 2865, Section 5.26 says, in part:

    Vendor-Id

      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 [6].

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:
http://www.iana.org/assignments/enterprise-numbers indicates:

0
  Reserved
    Internet Assigned Numbers Authority
      iana&iana.org

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?
[gwz] 
[gwz] Actually, I think that a better idea than using 0 would be for the
radext WG to request a PEN of its own.


   It also requires that IANA be set up to manage the RADIUS Extended
   Attributes.

This means that there would be a new section in the existing RADIUS Registry
dealing with IETF VSA Extended-Type field.
[gwz] 
[gwz] Yup.

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


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