Signaling Extensions for Wavelength Switched Optical Networks
draft-ietf-ccamp-wson-signaling-12

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/