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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-pce-wson-routing-wavelength-15
Reviewer: Robert Sparks
Review Date: 21-Nov-2014
IETF LC End Date:
IESG Telechat date: 25-Nov-2014

Summary: Ready for publication as an Informational RFC

Nits/editorial comments:

This revision addresses my comments from IETF-LC on revision 14 (copied 
below).
Thanks!

RjS

On 10/17/14 11:33 AM, Robert Sparks wrote:
> 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-pce-wson-routing-wavelength-14
> Reviewer: Robert Sparks
> Review Date: 17-Oct-2014
> IETF LC End Date: 27-Oct-2014
> IESG Telechat date: not currently scheduled for any telechat
>
> Summary: Ready for publication as an Informational RFC but with nits 
> that should be considered before publication
>
> Nits/editorial comments:
>
> There are 6 authors listed - please double-check the guidance in 
> section 4.1.1 of RFC7322.
> If retaining all the authors still makes sense, please help Adrian by 
> providing an argument
> that he can pass to the RFC Editor.
>
> The shepherd writeup indicates a solution ID is ready. I didn't check 
> to see how the requirements
> listed here were reflected there. Would it make sense to provide a 
> reference? (While I see no harm
> in publishing the document, it's not clear how doing so will be 
> helpful if the requirements were
> uncontentious as the writeup implies. There are few enough of them 
> that adding a short list in
> the mechanism document might be more effective.)
>
> Items 2 and 3 in section 3.4 are confusing as currently written. 2 
> seems to be talking
> about the case that the current path is still optimal. Is 3 trying to 
> talk about the case
> where there is no path, not even the current path, that will work? If 
> so the "(i.e., other
> than the current path)" in 3 doesn't make sense.
>
> Should you have captured a requirement that any mechanism implementing 
> these
> requirements be extensible to allow for cases like polarization based 
> multiplexing
> when they eventually come along?
>
> Please consider reordering the sentences in section 3.5 - the last 
> sentence seems
> to be talking about the first paragraph?
>
> You say "mechanisms defined in this document" several times in section 
> 4, but this
> document defines no mechanisms.
>
>