Skip to main content

Last Call Review of draft-ietf-ccamp-wson-signaling-09
review-ietf-ccamp-wson-signaling-09-secdir-lc-kaduk-2015-03-19-00

Request Review of draft-ietf-ccamp-wson-signaling
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-03-18
Requested 2015-03-05
Authors Greg M. Bernstein , Sugang Xu , Young Lee , Giovanni Martinelli , Hiroaki Harai
I-D last updated 2015-03-19
Completed reviews Genart Last Call review of -09 by Francis Dupont (diff)
Genart Telechat review of -12 by Francis Dupont
Secdir Last Call review of -09 by Benjamin Kaduk (diff)
Opsdir Last Call review of -10 by Tim Wicinski (diff)
Assignment Reviewer Benjamin Kaduk
State Completed
Request Last Call review on draft-ietf-ccamp-wson-signaling by Security Area Directorate Assigned
Reviewed revision 09 (document currently at 12)
Result Has nits
Completed 2015-03-19
review-ietf-ccamp-wson-signaling-09-secdir-lc-kaduk-2015-03-19-00
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