RE: [braden@ISI.EDU: Radius-related Independent submissions]

["Nelson, David" <dnelson@enterasys.com>]

Bert Wijnen writes...

> can you pls review the below 3 documents and let us know if there
> is any conflict with current (or planned) IETF work in this space?
> This is as per RFC3932.
> 
> You are also welcome to provide technical evaluation comments.
> We (or you) can feed that to the RFC-Editor and/or author(s),
> but we cannot block or mandate changes (that is RFC-editor task).

> > >   draft-zorn-radius-keywrap-10.txt
> > > 	TITLE	"RADIUS Attributes for Key Delivery"

I note that this draft contains the following header:

<quote>

Network Working Group                                            G. Zorn
Internet-Draft                                             Cisco Systems
Updates: 2865, 2866, 3576, 3579                                 T. Zhang
(if approved)                              3e Technologies International
Expires: August 29, 2006                                       J. Walker
                                                       Intel Corporation
                                                              J. Salowey
                                                           Cisco Systems
                                                       February 25, 2006
</quote>

I wonder how an individual submission Informational RFC can purport to
Update a Standards Track RFC (2865) or even other Informational RFCs
that have been through IETF Consensus?

The subject matter of this draft overlaps (substantially) with a charter
milestone of the IETF RADEXT WG, i.e. the Crypto-Agility draft.

Comments on this draft have been offered on the RADEXT WG mailing list,
but not all of them have been affirmatively addressed by the authors of
this draft.

The draft contains the following text:

<quote>
5.  Attribute Types

   Upon publication of this document as an RFC, IANA must assign
   numbers to the Key [TBD1], Random-Nonce [TBD2] and Message-
   Authentication-Code [TBD3] Attributes.
</quote>

Assignment of code points within the RADIUS registry by IANA is subject
to the provisions of RFC 3575, which provides IANA considerations for
RADIUS.  RFC 3575 says, in part, "Attributes 17, 21, 54, 56-59, 89,
101-191 may be allocated by IETF Consensus.", meaning to indicate the
range of standard attribute code points curently available for
assignment.  Thus it would appear that the IANA assignments requested in
this document require IETF Consensus.  That would seem to require (at
least) IESG review and approval.

> > >   draft-mammoliti-radius-dsl-vsa-01.txt
> > > 	TITLE	"DSL Forum Vendor-Specific RADIUS Attribute"

This draft says, in part, "It is expected that this document will be
updated if and when the DSL Forum defines additional vendor-specific
attribute, since its primary purpose is to provide a reference for DSL
equipment vendors wishing to interoperate with other vendors' products."

Contrary to the expressed objective of promoting multi-vendor
interoperability, the draft contains the following text:

<quote>
The exact syntax of the string is implementation dependant; however, a
typical practice is to subdivide it into two or more space-separated
components, one to identify the Access-Node and another the subscriber
line on that node, with perhaps an indication of whether that line is
Ethernet or ATM.
</quote>

The fact that the format (content) of the attribute is implementation
dependant would seem to give rise to the potential for interoperability
problems.

Otherwise, this draft is a straightforward informational document,
describing Vendor Specific RADIUS Attributes.

> > >   draft-zorn-radius-port-type-03.txt
> > > 	TITLE:	"Additional Values for the NAS-Port-Type Attribute"

This draft seems fine to me.  It simply requires Designated Expert
Review of the port type values prior to IANA assignment.  It appears
that the new port type values are sufficiently well defined by reference
to existing RFCs.