[CCAMP] AD review of draft-ietf-ccamp-swcaps-update

["Adrian Farrel" <[e-mail]>]

Thanks for this simple document.

I have carried out my review as AD as part of the publication request
process.  The purpose of the review is to catch any issues before the
document goes to IETF last call and IESG evaluation and to improve the
quality of the document.

I have not found any thing substantial, but I have three points I would
like you to look at before we move forward.  All points are open for
discussion.

For the moment I have put the document in "Revised I-D Needed" state.

Thanks for the work.

Adrian

===

Please add a note to the IANA considerations section to request an
update to
https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib.xhtml

Possibly you should refer to it as IANA-GMPLS-TC-MIB rather than through
the URL.

---

I would prefer if the message formats were left out of section 1.1.

You could leave the paragraphs:

   The Switching Type values are carried in both routing and signaling
   protocols.  Values are identified in the IANA GMPLS Signaling
   Parameters Switching Type registry, which is currently located at
      http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-
      parameters.xml

   For routing, a common information element is defined to carry
   switching type values for both OSPF and IS-IS routing protocols in
   [RFC4202].  Per [RFC4202], switching type values are carried in a
   Switching Capability (Switching Cap) field in an Interface Switching
   Capability Descriptor.  This information shares a common formatting
   in both OSPF, as defined by [RFC4203], and in IS-IS, as defined by
   [RFC5307].

   Similarly, the Switching Type field is defined as part of a common
   format for use by GMPLS signaling protocols in [RFC3471] and is used
   by [RFC3473].

...and delete the rest without damaging the document.

My concern, as usual, is that copying normative material leads to the 
risk of error, and creates problems if material has to be revised. It
is perfectly fine to reference it in nearly every case.

---

Section 2.3...

      These values SHOULD NOT be treated as reserved values, i.e.,
      SHOULD NOT be generated and SHOULD be ignored upon receipt.

But in 3473...

   Nodes MUST verify that the type indicated in the Switching Type
   parameter is supported on the corresponding incoming interface.  If
   the type cannot be supported, the node MUST generate a PathErr
   message with a "Routing problem/Switching Type" indication.

Is it your intention to update that piece of 3473?
If so, you should call it out more clearly.
If not, there is some work needed to reconcile the text.