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