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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf