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

From: "OOGHE Sven" <[email-masked]>
Date: Tue, 14 Jul 2009 22:45:55 +0200

Ben,

Thanks for commenting on the draft. See my feedback inline.

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: maandag 29 juni 2009 23:55
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]; OOGHE Sven; [email-masked]
Cc: Jari Arkko; [email-masked]
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