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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <rjsparks@xxxxxxxxxxx> 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 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.
>> 
>> 
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/gen-art

<<attachment: smime.p7s>>


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]