Subject: Re: [Gen-art] Gen-ART LC review of draft-ietf-ancp-framework-10

From: Ben Campbell <[email-masked]>
Date: Tue, 30 Jun 2009 16:58:10 -0500

(Oops, forgot to copy the gen-art list. Sorry for the repeat)

On Jun 29, 2009, at 4:55 PM, Ben Campbell wrote:

> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: draft-ietf-ancp-framework-10
> Reviewer: Ben Campbell	
> Review Date: 2009-06-29
> IETF LC End Date: 2009-06-29
> IESG Telechat date: (if known)
>
> Summary:
>
> This draft is on the right track, but has issues that need work  
> prior to publication.
>
> Major issues:
>
> -- Section 4.1, first bullet:
>
> I am concerned that a catchall "address all the use cases"  
> requirement is too vague. For the most part, the use cases are not  
> in "requirements language". It's going to be hard to gauge  
> compliance without analyzing the use cases to extract concrete  
> requirements, either now or in the future. (I note that you have  
> requirements breaking down some of the use cases, but not all.)
>
> -- 4.7.8:
>
> The draft should describe (or reference a description of) the  
> wholesale model, how it differs from other models, and what the  
> relationship between wholesalers and retailers. This sounds like a  
> business model, but what does it mean technically?
>
> -- 7 (security requirements)
>
> This draft depends almost entirely on draft-ietf-ancp-security- 
> threats for its security requirements. The security requirements in  
> that draft are substantial. However, this draft only mentions that  
> document in passing, as an informational reference. I think that  
> needs to be a normative reference, with explicit language in this  
> draft stating that those requirements are incorporated. (I  
> understand this draft is informational track, but it's stating  
> requirements on protocol design.)
>
> Minor issues:
>
> -- Section 2.4: The document seems to assume RADIUS is the only AAA  
> protocol. Is RADIUS the only such protocol in scope? That is, no  
> DIAMETER or other potential AAA protocols?
>
> -- Section 3.4.1, paragraph 6:
>
> I sounds like anything not on the white or grey list is effectively  
> on the black list, right? Then why have an explicit black list at all?
>
> -- section 4,1, second bullet:
>
> This is vague--can you enumerate or reference the "various  
> technologies"? Even if they are mentioned elsewhere in the doc, it  
> would be good to reference them.
>
> -- 5th bullet:
>
> "fast-paced" is vague--can you state something more concrete?
>
> -- 6th bullet:
> Why 5000? What is the motivation behind that particular number?
>
>
> -- 4.3, first bullet:
>
> Can you characterize how "limited"?
>
> -- 5th bullet: (use case negotiation)
>
> Is this limited to the use cases in this draft, or is this intended  
> as an extensibility mechanism?
>
> -- 4.6.2, 1st bullet:
>
> SHOULD use, or SHOULD be able to use? If the former, why? What harm  
> is done by using separate facilities?
>
> -- 4.6.3:
>
> Is this reasonably in scope? This sounds more like a product  
> requirement than a protocol requirements. (This comment replies to  
> several other requirements concerning interactions with network  
> management.)
>
> -- 4.6.7, 2nd bullet (also 4.7.7, 2nd bullet)
>
> Can you elaborate on the requirements to "dampen notifications"?
>
>
> Nits/editorial comments:
>
>
> --Section 1, paragraph 1: Please expand ONU on first use.
>
> -- Section 3.1, second bullet: first sentence is a fragment.
>
> -- Section 3.4.1, White, Black, and Grey list entry descriptions:
>
> Is this notation (e.g. <<G=g.h.i.l> ) well known? Is there a  
> description that can be referenced?
>
> -- section 3.4.2, paragraph 3: "...AN and NAS MUST ensure admission  
> control..."
>
> Does it make sense to use normative language in a use case  
> description?
>
> -- section 4 and subsections, general:
>
> There are enough bulleted requirements in section 4 that it would be  
> really helpful to have them numbered. Otherwise, you're going to  
> have to talk about "The nth bullet in section X.Y.X" when you  
> discuss specific requirements.
>
> -- last bullet on page 30: "This MUST allow to retrieve... "
> Missing word(s)?
>
> -- 4,3, 2nd bullet: "... allowing to inform ..." --  missing word(s)?
>
>
>
>
>