Hi Kathleen,
Thanks for your review. We'll pick up these editorial changes as RFC Editor
notes.
Thanks again,
Jerry
________________________________
From: "kathleen(_dot_)moriarty(_at_)emc(_dot_)com"
<kathleen(_dot_)moriarty(_at_)emc(_dot_)com>
To: gen-art(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org;
draft-ash-gcac-algorithm-spec(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org
Cc: gash5107(_at_)yahoo(_dot_)com; dave(_dot_)mcdysan(_at_)verizon(_dot_)com
Sent: Wednesday, January 4, 2012 11:03 AM
Subject: Gen-ART review of draft-ash-gcac-algorithm-spec-03.txt
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ash-gcac-algorithm-spec-03.txt
Reviewer: Kathleen M. Moriarty
Review Date: 1/4/12
IETF LC End Date: 1/11/12
IESG Telechat date: 1/19/12
Summary: The draft is essentially ready with nits. The last nit could be a
minor issue, but has a simple resolution. The security considerations section
points out possible attacks and should also require logging of events tied to
the users/groups responsible for those actions.
Major issues:
Minor issues:
Nits/editorial comments:
The last line of the abstract should be on the previous line.
On the second to last paragraph of page 8, the following acronym is listed:
emergency traffic (ETS), should there be something for the "S"?
The second to last sentence of the same paragraph:
Consider changing from:
"Several
assured forwarding (AF) queues may be used for various data traffic,
for example, premium private data traffic, premium public data
traffic, and a separate best-effort queue is used for the best-effort
traffic."
To: "Several
assured forwarding (AF) queues may be used for various data traffic,
for example, premium private data traffic, premium public data
traffic, and a separate best-effort queue for the best-effort
traffic."
First paragraph of section 3: Consider removing "however", it doesn't add
anything:
Change from: "Requiring nodes to expose detailed and
up-to-date CAC information, however, may result in unacceptably high
rate of routing updates."
To: "Requiring nodes to expose detailed and
up-to-date CAC information may result in unacceptably high
rate of routing updates."
Second paragraph of Section 3: Consider removing "and cannot" - it is
unnecessary:
Change from: "This common
interpretation is in the form of an MPLS GCAC algorithm to be
performed during MPLS LSP path selection to determine if a link or
node can or cannot be included for consideration."
To: "This common
interpretation is in the form of an MPLS GCAC algorithm to be
performed during MPLS LSP path selection to determine if a link or
node can be included for consideration."
Section 3.2: Consider breaking the first sentence into two:
"The assumption behind the MPLS GCAC is that the ratio between BWMck,
which represents the safety margin the node is putting above the
SBWck, and the standard deviation of the SBWck defined below does not
change significantly as one new aggregate flow is added on the link."
Security Considerations:
I think a requirement for logging should be specified here as well. If an
attack were to occur, you will want the user/group and actions taken to be
logged to trace the attack. Without this, the other enforcement mechanisms are
inadequate.
Sentence that spans page 17-18 should be broken into multiple sentences
(readable, but long - as is the following sentence):
"For
example, if aggregate flow requests are made for CT LSP bandwidth
that exceeds the current DSTE tunnel bandwidth allocation, the GEF
initiates a bandwidth modification request on the appropriate LSP(s),
which may entail increasing the current LSP bandwidth allocation by a
discrete increment of bandwidth denoted here as DBW, where DBW is the
additional amount needed by the current aggregate flow request."
There is an extra line in the second line of A.1.
Thanks,
Kathleen
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf