Sorry for the late reply--this one got buried in a deluge of pre-IETF
meeting mail. Comments inline.
On Jul 14, 2009, at 3:45 PM, OOGHE Sven wrote:
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)."
Okay, I think that helps.
-- 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.
This helps--but I am skeptical that the average reader will follow up
on those references. I think a short (i.e. few paragraphs) high-level
description of the technical aspects of the wholesale model would be
useful in this draft.
-- 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."
Okay, that helps.
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.
Okay.
-- 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.
Ah, good point--I was not thinking about wildcard entries. I withdraw
the comment.
-- 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.
Okay.
-- 5th bullet:
"fast-paced" is vague--can you state something more concrete?
<Sven> I will solicit the ANCP WG for feedback.
Okay.
-- 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.
Okay.
-- 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). "
This still seems vague to me without some characterization of a
typical access node platform. I would be surprised if there are not a
broad range of device "size" for this sort of thing. I'm not looking
for precise hardware specs, but it would help to have some idea of the
typical range of CPU and memory resources you are thinking about.
-- 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.
Okay.
-- 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".
The previous paragraph talks about some deployment considerations--I
took this paragraph as suggesting that implementors allow certain
configurations, rather than that deployments should use certain
configurations. Am I misunderstanding the intent?
-- 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".
Okay. (Remember that the comment applied to other statements about
network management as well.)
-- 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."
Okay.
Nits/editorial comments:
--Section 1, paragraph 1: Please expand ONU on first use.
<Sven> ONU = Optical Network Unit
Okay
-- Section 3.1, second bullet: first sentence is a fragment.
<Sven> "Allow for a better utilization of network resources"
Okay
-- 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...
Okay
-- 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"
Okay
-- 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.
Okay
-- 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."
Okay
Missing word(s)?
-- 4,3, 2nd bullet: "... allowing to inform ..." -- missing word(s)?
<Sven> Should be edited to "...allowing the protocol to inform..."
Okay.
Thanks!
Ben.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
