Sharon Chisholm <mailto:[EMAIL PROTECTED]> supposedly scribbled:

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

Why?  

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

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.

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

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

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

Our mistake.

> My understanding is that this namespace was not defined within this
> document, but within RFC 2434. 

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

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

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

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

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

Fine.

> 
> Sharon Chisholm
> Nortel
> Ottawa, Ontario
> 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

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

Reply via email to