[CCAMP] RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt

["Joel M. Halpern" <[e-mail]>]

Hello,

I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF last call and IESG review, and 
sometimes on special request. The purpose of the review is to provide 
assistance to the Routing ADs. For more information about the Routing 
Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.

Document: draft-ietf-ccamp-otn-g709-info-model-11.txt
Reviewer: Joel Halpern
Review Date: 9-September-2013
IETF LC End Date: 19-Sept-2013
Intended Status: Informational

Summary: I have some minor concerns about this document that I think 
should be resolved before publication.

Comments:
     In general, the document needs to be consistently clear as to what 
gaps it identifies.  Many cases are quite clear, and some are not.  I 
will try to identify the less clear cases in the comments below. The 
last paragraph of section 3.2 is clear and explicit, and what I expected 
at the end of each section.  The previous paragraph ("Specific 
information could be defined") is much less helpful.

Moderate Issues:
     It is unclear if there are gaps or requirements identified by 
sections 3.1.1 or 3.1.2.
     Given that this document is about mapping to G.709, it is unclear 
what is intended by the usage of "LSP".  My guess is that it is intended 
to mean Label Switch Paths set up by GMPLS to carry OTU/UDU elements. 
It should be stated explicitly.

Minor Issues:
     All acronyms should be expanded upon first use.
     In section 2 particularly, the OCh (Optical Channel?) should also 
be clear how that relates to the OTU and ODU being discussed.
     Figure 4 uses the abbreviation TSG, which is not defined, and not 
used elsewhere.  If it is needed in the figure, it might suffice to 
follow "TS granularity" in the caption with "(TSG)".

     Section 8 on Maximum LSP Bandwdith seems to be objecting to too 
much information leading to a "waste of bits".  While possibly of 
interest to the WG, that does not seem to fit a gap analysis.
     Similarly, section 10 on Priority Support reads as implementation 
advice rather than a gap needing protocol changes.

Nit: