Subject: [Gen-art] Gen-art review of draft-zorn-radius-port-type-03.txt

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 28 Mar 2006 15:22:25 -0500

I was selected as General Area Review Team reviewer for this
specification (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Document:

http://www.ietf.org/internet-drafts/draft-zorn-radius-port-type-03.txt

Summary: 

This draft has serious issues,  described in the review, and needs to be
rethought.

Comments:

1. Where can the complete and most up to date list of NAS-Port-Type
Attribute values be found? At www.iana.org or in an update to this
proposed-RFC? The document does not say. If it is the latter, do we
actually need to publish this as an RFC? If it is the former, this
should be clearly stated in the document.

2. I am assuming that the appropriate 'designated experts' have approved
the content in section 2.

3. Now that this is ready for publication, is the third paragraph in
section 1 which says 'Discussion of this draft may be directed to the
authors' still appropriate? 

4. Section 3 is problematic and requires removal or rewriting. I
recommend deleting it and replacing it will appropriate call outs to RFC
2434 and 3575.

4.1 This document was requesting new values from IANA, but section 3.0
says 'This section explains the criteria to be used by the IANA for
assignment of numbers within namespaces defined within this document.'
My understanding is that this namespace was not defined within this
document, but within RFC 2434. Discussion of how to manage this
namespace is given in RFC 3575.

4.2 Section 3.1 repeats text from RFC 3575 on how this namespace is to
be managed. What happens if RFC 3575 gets updated? I would suggest just
removing this text from the document and pointing people to RFC 3575 for
rules on how this namespace is to be managed.

4.3 Delete the sentence that says 'The values given have already been
implemented by Cisco Systems.' as it isn't relevant and will quickly
become an obsolete list of implementations.

5. In section 1, second paragraph and again in section 3.1 second
paragraph, there is an extra space between 'to act as' and 'a request
for allocation'.

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Tue, 28 Mar 2006 13:43:37 -0800

> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).  

Why?  

> This draft has serious issues,  described in the review, and needs to
> be rethought. 
> 
> Comments:
> 

So, what is not clear about "This document is intended to act as  a request for allocation of the designated numbers by IANA in the appropriate registry [RADTYP]."?  What would possibly lead you to believe that "most up to date list of NAS-Port-Type Attribute values" would be found in a non-existent update to this document?

> 
> 2. I am assuming that the appropriate 'designated experts' have
> approved the content in section 2. 

Correct; it is my understanding that that was the only review required.

> authors' still appropriate?  

Maybe change "draft" to "document"?  This is not a WG document.  To whom should discussion be directed, except the authors?

> recommend deleting it and replacing it will appropriate call outs to
> RFC 2434 and 3575. 
> 
> 4.1 This document was requesting new values from IANA, but section
> 3.0 says 'This section explains the criteria to be used by the IANA
> for assignment of numbers within namespaces defined within this
> document.'   

Our mistake.

> document, but within RFC 2434. 

Your mistake: it's actually defined in RFC 2865.

> Discussion of how to manage this
> 4.2 Section 3.1 repeats text from RFC 3575 on how this namespace is
> to be managed. What happens if RFC 3575 gets updated? 

Nothing, since this text is fairly obviously in the nature of a justification for this document.

> I would suggest
> just removing this text from the document and pointing people to RFC
> 3575 for rules on how this namespace is to be managed. 

Fine.
  
> become an obsolete list of implementations.  

It is extremely relevant as justification for the allocation of exactly the numbers listed (as opposed to the next 5 available numbers, which would be 27-31).

> paragraph, there is an extra space between 'to act as' and 'a request

Fine.

> Canada

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel