I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I think this document is ready with nits. The security considerations notes that this is a simple extension to existing mechanisms and is not carrying qualitatively different information compared to the existing specifications. The security considerations of RFC 3473, and RFC 5920, seem to provide adequate treatment of the security issues at play here. The nits are largely editorial in nature: 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. -Ben Kaduk