Re: [Gen-art] Gen-ART review of draft-ash-gcac-algorithm-spec-03.txt

[Gerald Ash <[e-mail]>]

Hi Kathleen,
 
Thanks for your review.  We'll pick up these editorial changes as RFC Editor notes.
 
Thanks again,
Jerry


________________________________
From: "[e-mail]" <[e-mail]>
To: [e-mail]; [e-mail]; [e-mail] 
Cc: [e-mail]; [e-mail] 
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