AD review of GMPLS SONET documents

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

As AD I reviewed these documents:

 draft-ietf-ccamp-gmpls-sonet-sdh-05.txt
 for Proposed Standard
 draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03.txt
 for Informational.

Below are my findings that I would like to see addressed
before I request an IETF Last Call.

For both documents:

1. Need to reduce the number of authors/people on front page.
   The docs will not be considered again unless you comply 
   with the guidelines in section "Author overload" in
    http://www.rfc-editor.org/policy.html

2. I expect that RFC-Editor will reject the Acronyms in the
   title and abstract.  See also the "Choosing titles" and
   "abstract" sections in 
    http://www.rfc-editor.org/policy.html
   I believe that the RFC-Editor wants these acronyms expanded:
     SONET, SDH, SONET/SDH

for  draft-ietf-ccamp-gmpls-sonet-sdh-05.txt

1. I think that normative references are needed to documents
   ANSI T1.105 and ITU-T G.707 as I think one cannot understand 
   much of this doc if you ignore those ANSI/ITU-T documents.

2. It seems to me that this document should not reference another
   doc that specifies non-standard extensions. At least, if it
   does so, then maybe once in the iuntroduction is enough.

3. Last para on page 4.
   I do not understand this. Can you clarify?

4. On page 6 in the middle I read:
 
     This field is set to one (default value) to indicate that 
     exactly one instance of a signal is being requested. Zero is an 
     invalid value. 

   So how does the requestor know requested value has been accepted?
   And what needs the receiver do if the "invalid value zero" is
   requested?

5. Page 7 in the middle:

     Where bit 1 is the low order bit. Others flags are reserved, 
     they should be set to zero when sent, and should be ignored 
     when received. A flag is set to one to indicate that the 
     corresponding transparency is requested. 
     
   So how does requestor find out which values have been accepted?
   By the way s/Others flags/Other flags/

6. I would think that the 1st sentence on page 8 better be
   removed.

7. Middle of page 10, may want to add refrence to G.707

8. Page 10 talks about "higher ordered LSP" and "lower ordered LSP"
   Where are those terms defined? May want to explain or reference.

9. Page 13 talks about "highest part" and "lower part" of a label.
   Might be good to define what you mean by that.
   How about "lowest label"?

10. You have quite a set of values that you assign in this document.
    For various fields in the SONET/SDH paramters data structure
    and also for various parts of the labels for SONET/SDH.
    The extensions document adds additional (optional) values
    to those fields. You also suggest that other documents could
    add values fro G.832 or G.708.
    How do we keep control over such value assignments/usage?
    Is that something that IANA should control?

11. In the IANA considerations section you may want to be
    more explicit as to the name-space in which IANA
    needs to make new assignments.

less serious, but once you're at it...

11. sect 2.1 1st sentence
    s/is organized/are organized/

12. I see various use of Upper/Lower case for
    Elementary Signal/elementary signal.
    I think it may beuseful to exlain what Elementary
    Signal and Final Signal are.
   
13. Last para page 4
    s/node chosen/node has chosen/
  
14. I see the use of SONET/SDH and SDH/SONET used arbitrarily
    Would it not be better to choose one form? And let that
    be the same as in the other GMPLS documents?
 
for  draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03.txt

1. Last para on page 2 seems "marketing" that we do not need.
   
2. Top of page 3.
     This document doesn't specify how to implement these features in 
     the transmission plane but how to control their usage with a GMPLS 
     control plane. 
   My question is: Is there any document anywhere that explains
   how to implement in the transmission plane. If yes, then a
   reference to such document would be usefull.
   If not, then how can anyone create interoperable implementations.
   And if they cannot do that, then why is this document useful?

3. Security considerations.
   I think I would add a ptr to the doc(s) where the security 
   mechanisms are described, just as you did for base sonet/sdh doc.

less serious:

4. I see the use of SONET/SDH and SDH/SONET used arbitrarily
   Would it not be better to choose one form? And let that
   be the same as in the other GMPLS documents?
 
Thanks,
Bert