Last Call Review of draft-ietf-ccamp-gmpls-ospf-g709v3-09
review-ietf-ccamp-gmpls-ospf-g709v3-09-genart-lc-sparks-2013-10-11-00

  
  
    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-ietf-ccamp-gmpls-ospf-g709v3-09


    Reviewer: Robert Sparks


    Review Date:
    11-Oct-2013


    IETF LC End Date:
    16-Oct-2013


    IESG Telechat date: Not yet scheduled for a telechat





    Summary:
    
    This draft is basically ready for publication, but has nits that
    should be fixed before publication.





    This document is dense (as in it puts a lot of information in a
    small number of characters), but it reads clearly.


    I did not carefully review the contents of the example fields for
    editorial mistakes - please be sure someone in the group has done
    that.





    The largest issue I see is on the border of being more than a nit.
    I'm calling it a nit because it should be very easy to fix:


    The sentence "Same type of modification needs to applied to the
    IANA-GMPLS-TC-MIB at
    

https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib

" is
    not sufficient instruction to IANA to cause that registry to be
    modified. Please provide more precise


    instructions as to how this mib should change. 





    I note also that the value 40 from RFC6060 didn't make it into the
    mib.





    The rest of these are more nitty nits:





    ---


    In section 4, I think you've repeated a MUST, and risk introducing
    confusion.


    It's awkward to point to this with paragraph numbers because of the
    interspersed tables, so I'll quote the relevant block:







   When supporting the extensions defined in this document, the
   Switching Capability and Encoding values MUST be used as follows:

   - Switching Capability = OTN-TDM
   - Encoding Type = G.709 ODUk (Digital Path) as defined in [RFC4328]

   Both for fixed and flexible ODUs the same switching type and encoding
   values MUST be used.


    If I read that correctly , those are the same MUST and you're saying
    it's a MUST no matter whether you're talking about fixed or flexible
    ODUs.


    If that's correct I suggest replacing this with:







   When supporting the extensions defined in this document, for both
   fixed and flexible ODUs, the Switching Capability and Encoding values 
   MUST be used as follows:

   - Switching Capability = OTN-TDM
   - Encoding Type = G.709 ODUk (Digital Path) as defined in [RFC4328]



    (or leave out the fixed and flexible clarification altogether - I
    would not have been confused without it).  





    ---





    In section 8.2, where you say "IANA will create and maintain a new
    registry", I suggest you say "new sub-registry".





    RjS