ietf
[Top] [All Lists]

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

2014-11-25 10:14:01
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(_at_)nostrum(_dot_)com> 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/gen-art

Attachment: smime.p7s
Description: S/MIME cryptographic signature

<Prev in Thread] Current Thread [Next in Thread>