Telechat Review of draft-ietf-ccamp-flexible-grid-ospf-ext-08
review-ietf-ccamp-flexible-grid-ospf-ext-08-genart-telechat-resnick-2017-02-10-00

Request Review of draft-ietf-ccamp-flexible-grid-ospf-ext
Requested rev. no specific revision (document currently at 09)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-02-14
Requested 2017-02-06
Authors Xian Zhang, Haomian Zheng, Ramon Casellas, Oscar de Dios, Daniele Ceccarelli
Draft last updated 2017-02-10
Completed reviews Rtgdir Telechat review of -07 by Ben Niven-Jenkins (diff)
Opsdir Telechat review of -07 by Bert Wijnen (diff)
Secdir Last Call review of -07 by Catherine Meadows (diff)
Genart Last Call review of -07 by Pete Resnick (diff)
Genart Telechat review of -08 by Pete Resnick (diff)
Assignment Reviewer Pete Resnick 
State Completed
Review review-ietf-ccamp-flexible-grid-ospf-ext-08-genart-telechat-resnick-2017-02-10
Reviewed rev. 08 (document currently at 09)
Review result Ready with Nits
Review completed: 2017-02-10

Review
review-ietf-ccamp-flexible-grid-ospf-ext-08-genart-telechat-resnick-2017-02-10

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-ccamp-flexible-grid-ospf-ext-08
Reviewer: Pete Resnick
Review Date: 2017-02-10
IETF LC End Date: 2017-01-31
IESG Telechat date: 2017-02-16

Summary: Ready with Nits

A couple of nits that I mentioned in my earlier review that you might want to address, but none of them are essential. (You may have decided that I was wrong; that's OK too.) I didn't bother Cc'ing the IETF list on this, since they're both very minor.

Major issues: None

Minor issues: None

Nits/editorial comments: 

3.1:

   A set of non-overlapping available frequency ranges MUST be 
   disseminated in order to allow efficient resource management of 
   flexi-grid DWDM links and RSA procedures which are described in 
   Section 4.8 of [RFC7698]. 

Those MUSTs look weird to me. I think instead of "MUST be" you mean
"are", since it doesn't look like an implementation really has a
choice here.

3.2:

   Hence, in order to support all possible applications and 
   implementations the following information should be advertised for
   a flexi-grid DWDM link:
   
Is that "should" in there meant to be normative? That is, do bad
things happen if I don't advertise one of those items? Or do you just
mean "the following information is advertised..."?