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

[Lou Berger <[e-mail]>]

Adrian,
	I'm replying as co-author.See below for responses.

On 8/21/2013 6:55 AM, Adrian Farrel wrote:
> 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.
The proposed text to be added to the end of the section is:

   A parallel change to IANA-GMPLS-TC-MIB is also required. In
   particular, under IANAGmplsSwitchingTypeTC a reference to this
   document should be added as item 3. Also the following changes should
   be made to the related values:

          deprecated(2),      -- Deprecated
          deprecated(3),      -- Deprecated
          deprecated(4),      -- Deprecated


> 
> ---
> 
> 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.
> 
> ---

While I agree with the sentiment 100% in normative text, this section is
informative and labeled as such. I just don't see there being any risk
of poor implementation as a result of this section. I do think it would
diminish the value of the section if the text was removed.  That said,
if you felt strongly about this I'd revisit the point.
> 
> 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.
> 

Yeah.  This is a case where a pointer back to the original, as you
mentioned above, is the right thing.  How about:

   These values SHOULD be treated as unsupported types and
   processed according to Section 2.1.1 of [RFC3473].

Great catch.

Thanks for the review!

Lou