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

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

OK, two out of three ain't bad (as Jim Steinman wrote)

Can you post a new revision and we'll move forward.

Thanks,
Adrian

> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: 21 August 2013 23:25
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-swcaps-update
> 
> 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