Signaling Extensions for Wavelength Switched Optical Networks
RFC 7689

Note: This ballot was opened for revision 10 and is now closed.

Deborah Brungard Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Comment (2015-05-27)
No email
send info
I'm a bit startled that the WavelengthSelection sub-TLV has a used value of 8 bits (really 1 bit plus a handful of the 127 values) but has a length of 4 which thus forces 2 octets of padding.   I expect that there are implementations and this isn't a flaw - just wasteful.

(Ben Campbell) No Objection

Comment (2015-05-26)
No email
send info
The security considerations say this document differs from 3473 only in "specific information communicated". In general, a change in the information carried can make a huge difference. I infer that the working group believes that this specific information does not (I hold no opinion on that), but it would be good to state that explicitly.

(Benoît Claise) No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2015-05-26)
No email
send info
Just wondering: does this (or some other document) provide me
with a way to say that node X should take an input lambda and
replicate it out twice? (I.e. forking the traffic) If so, then
that probably ought be noted somewhere as it'd enable forms of
monitoring that might otherwise require a visit to the physical
node.

(Brian Haberman) No Objection

Barry Leiba No Objection

Comment (2015-05-21)
No email
send info
I think the choice of registration policies for the new registries -- Standards Action or Specification Required -- is a good one, and provides good flexibility.  Thanks for that.

(Kathleen Moriarty) No Objection

Comment (2015-05-27)
No email
send info
Thanks for addressing the SecDir review comments.  I didn't see the follow up thread, but do see the adjustments in the draft.
https://www.ietf.org/mail-archive/web/secdir/current/msg05537.html

Alvaro Retana No Objection

(Martin Stiemerling) No Objection

(Adrian Farrel) (was Yes) No Record

Comment (2015-03-19 for -10)
No email
send info
OPS and Sec Dir reviews from Tim Wicinski and Benjamin Kaduk raised a number of nits that should be handled:

> -- The draft header indicates that this document updates RFC6205, 
>    but the abstract doesn't seem to mention this, which it should.
>
> == Outdated reference: draft-ietf-ccamp-rwa-info has been published as
>      RFC 7446
>
> Reference Comment:
>
> Under Informative References RFC6163 is listed as 
>    "work in progress: draft-bernstein-ccamp-wavelength-switched-03.txt,
>      February 2008"
>
> It's the only RFC reference that looks off.  

| The list of WSON Signal Characteristics introduces the acronym FEC and
| includes its expansion in the body, but does not explicitly define the
| term.  That could be done in the Terminology section.
|
| In section 3.2, the term "3R regeneration" is used, but it is not
| mentioned in the Temrinology section.  (As not a routing person, I had to
| look it up.)
|
| In section 4.1, I think that an "in the" or "by the" (or similar) is
| missing prior to "Generalized Label Request object".
|
| Section 4.2 claims that the requirements for signaling to indicate to a
| particular node what type of processing to perform are given in section
| 3.2, however, I see no such requirements in section 3.2; is a different
| section intended?
|
| Also in section 4.2, the term "WSON Processing HOP Attribute TLV" is 
| used.  Is HOP an acronym?  I do not see it in the RFC Editor's list of
| abbreviations
| (https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt) 
| and I am not entirely sure that I understand its meaning.
|
| The artwork for the contents of that TLV immediately follows.  The
| subsequent descriptive text indicates that there may be padding after
| the 'Value' field, to align the end of the record to a four-octet boundary.
| It might be useful to include some padding in the artwork.
|
| The text description for the "Length" field says that the included length
| is four plus the length of the value field in octets, but the artwork has
| only one octet for each of the Type and Length fields, which would make
| the constant two, not four.  (Perhaps those two fields were changed from
| two octets to one octet in some revision of the document?)
|
| Likewise, the description of the WavelengthSelection sub-TLV in the table
| with Name/Type/Length indicates that 3 octets of padding would be needed
| after the 1 octet of 'Value' contents.  However, if the Type and Length
| fields are only one octet each, only one octet of padding would be needed,
| not three.
|
| In section 4.2.1, it is said that "No more than two ResourceBlockInfo
| sub-TLVs SHOULD be present."  However, the RBNF for the WSON Processing
| HOP Attribute allows at most two, so any more than two would be
| noncompliant with the RBNF.  It is unclear to me if this incongruity is
| actually a cause for concern; it probably depends on why SHOULD is used
| instead of MUST.

The IANA review of this document leads to the following changes in Section 6

Old:
http://www.iana.org/assignments/rsvp-te-parameters/rsvp-te-parameters.xhtml
New: 
http://www.iana.org/assignments/rsvp-te-parameters/

Old: 
http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml
New:
http://www.iana.org/assignments/rsvp-parameters/