Ben, Thanks for commenting on the draft. See my feedback inline.
-----Original Message----- From: Ben Campbell [mailto:[email protected]] Sent: maandag 29 juni 2009 23:55 To: [email protected]; [email protected]; [email protected]; [email protected]; OOGHE Sven; [email protected] Cc: Jari Arkko; [email protected] Subject: Gen-ART LC review of draft-ietf-ancp-framework-10 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.) <Sven> The purpose of the framework is to describe use cases that will then be addressed by the ANCP protocol in protocol-specific documents. In that respect, the first part of the requirement is fairly vague. I suggest to reword the requirement so that it reads the following: "The ANCP MUST be easily extensible through the definition of new message types or TLVs to support use cases beyond those currently addressed in this document (this includes the use of Access Nodes different from a DSLAM, e.g. a PON Access Node)." -- 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? <Sven> I will add a reference to Broadband Forum TR-058, TR-059 and TR-101, which describe a DSL broadband access architecture and how it enables wholesaling. -- 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.) <Sven> I will move the reference to the normative references section, and add a statement to section 7 that "The ANCP MUST comply to the security requirements spelled out in draft-ietf-ancp-security-threats." 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? <Sven> I suggest to reword to "Policy or AAA Server" and not mention what particular protocol will be used to communicate to the AAA Server. -- 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? <Sven> Anything dat doesn't match the white or grey list, will indeed be dropped by default. An explicit black list however is still useful, e.g. in the following config: . White List entry <S=*,G=*> . Black List entry <S=*,G=g.h.i.l> In this case, the default behavior is to accept the flow (matching the catch-all entry in the white list). However, when joining group IP address g.h.i.l, the most specific match would apply and the request would be rejected. -- 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. <Sven> I will edit to clarify that it refers to ATM and Ethernet. -- 5th bullet: "fast-paced" is vague--can you state something more concrete? <Sven> I will solicit the ANCP WG for feedback. -- 6th bullet: Why 5000? What is the motivation behind that particular number? <Sven> That value was concluded after discussing with operators on a typical network deployment. -- 4.3, first bullet: Can you characterize how "limited"? <Sven> Basically, the protocol must be designed to only require a software upgrade, not a hardware upgrade. Perhaps the requirement should be reworded to the following: "The ANCP MUST be simple and lightweight enough to allow an implementation on Access Nodes that does not specifically require additional control plane resources (e.g. additional CPU and memory requirements). " -- 5th bullet: (use case negotiation) Is this limited to the use cases in this draft, or is this intended as an extensibility mechanism? <Sven> It is intended to refer to present and future use cases. I will reword. -- 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? <Sven> The purpose of this requirement is to state that there is no need to have dedicated links between the AN and the NAS just for the sake of running the ANCP protocol. This is not really a protocol design requirement, but rather a deployment guideline. I will change "SHOULD" to "should". -- 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.) <Sven> It indeed is a nodal requirement. As it is intended as a guideline, the nodal requirements always use uncapitalized "must" / "should". -- 4.6.7, 2nd bullet (also 4.7.7, 2nd bullet) Can you elaborate on the requirements to "dampen notifications"? <Sven> Proposed rewording "The Access Node should be able to avoid sending bursts of ANCP messages related to notification of line attributes or line state by spreading message transmission over time." Nits/editorial comments: --Section 1, paragraph 1: Please expand ONU on first use. <Sven> ONU = Optical Network Unit -- Section 3.1, second bullet: first sentence is a fragment. <Sven> "Allow for a better utilization of network resources" -- 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? <Sven> The notation is inspired on (S,G) and (*,G) notation for multicast. No reference exists to my knowledge... -- 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? <Sven> No, normative language is not appropriate here. I will change to "must" -- 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. <Sven> I will number the requirements. -- last bullet on page 30: "This MUST allow to retrieve... " <Sven> I will reword the second sentence to "This MUST allow a management station to retrieve statistics and alarms (e.g. via SNMP) related to the operation of the ANCP, as well as to allow it to initiate OAM operations and retrieve corresponding results." Missing word(s)? -- 4,3, 2nd bullet: "... allowing to inform ..." -- missing word(s)? <Sven> Should be edited to "...allowing the protocol to inform..." Thanks, Sven _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
