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

[Jari Arkko <jari.arkko@piuha.net>]

Agreed.

Nelson, David wrote:

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