Subject: [Gen-art] Genart telechat review: draft-ietf-pce-wson-routing-wavelength-15

From: Robert Sparks <[email-masked]>
Date: Fri, 21 Nov 2014 14:19:44 -0600

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.
>
>

---

From: Jari Arkko <[email-masked]>
Date: Tue, 25 Nov 2014 16:51:50 +0100

Thank you Robert for the review, and thank you authors for the updates in -15! I have balloted no-obj for this document in today’s IESG telechat.

Jari

On 21 Nov 2014, at 21:19, Robert Sparks <[email-masked]> wrote:

> This revision addresses my comments from IETF-LC on revision 14 (copied below).
> Thanks!
> 
> RjS
> 
>> 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
>> 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
>> 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
>> Should you have captured a requirement that any mechanism implementing these
>> requirements be extensible to allow for cases like polarization based multiplexing
>> Please consider reordering the sentences in section 3.5 - the last sentence seems
>> You say "mechanisms defined in this document" several times in section 4, but this
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art