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