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

[t.petch <[e-mail]>]

----- Original Message -----
From: "Lou Berger" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>;
<[e-mail]>
Sent: Wednesday, August 21, 2013 11:25 PM
> 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

Mmmmm RFC4181 says

"Therefore, labels of named numbers and named
  bits MUST NOT be changed when revising IETF MIB modules (except to
  correct typographical errors), and they SHOULD NOT be changed when
  revising enterprise MIB modules.
"

so I do not think that you can do that.  Change of STATUS (which applies
to the whole TC) yes, label no. (Don't you love SNMP?)

Tom Petch

> > ---
> >
> > I would prefer if t
he 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