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

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 21 Aug 2013 11:55:52 +0100

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.

---

From: Lou Berger <[email-masked]>
Date: Wed, 21 Aug 2013 18:25:09 -0400

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

> Possibly you should refer to it as IANA-GMPLS-TC-MIB rather than through
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

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 22 Aug 2013 13:04:00 +0100

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:[email-masked]]
> Sent: 21 August 2013 23:25
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-swcaps-update
> 
> Adrian,

---

From: t.petch <[email-masked]>
Date: Thu, 22 Aug 2013 18:21:27 +0100

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

---

From: Lou Berger <[email-masked]>
Date: Fri, 23 Aug 2013 09:38:20 -0400

Tom,
	See below.

...

>> On 8/21/2013 6:55 AM, Adrian Farrel wrote:
...

> to the whole TC) yes, label no. (Don't you love SNMP?)

Looks like you're right.

Perhaps the following is the "right" middle ground:
Existing:
                  psc2(2),      -- Packet-Switch-Capable 2
                  psc3(3),      -- Packet-Switch-Capable 3
                  psc4(4),      -- Packet-Switch-Capable 4
Revised:
                  psc2(2),      -- Deprecated [This.document]
                  psc3(3),      -- Deprecated [This.document]
                  psc4(4),      -- Deprecated [This.document]

Adrian,

Do you agree with the above?  This is a bit different than your request.

Much thanks,
Lou

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 23 Aug 2013 15:16:19 +0100

Really good catch, Tom.

What Lou suggests looks the best way to handle it.

A

> Sent: 23 August 2013 14:38
> To: t.petch; [email-masked]

---

From: Lou Berger <[email-masked]>
Date: Fri, 23 Aug 2013 11:21:41 -0400

> What Lou suggests looks the best way to handle it.

Great.  Look for the publication announcement in a few minutes.

Lou

---

From: t.petch <[email-masked]>
Date: Fri, 23 Aug 2013 17:37:22 +0100

----- Original Message -----
From: "Lou Berger" <[email-masked]>
To: <[email-masked]>
Cc: "'t.petch'" <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Friday, August 23, 2013 4:21 PM

> Great.  Look for the publication announcement in a few minutes.

Yes.

I would prefer that the Switching Types portion of the GMPLS Signaling
Parameters was handled in a comparable manner, as for example
http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml#ic
mp-parameters-types
does so that PSC-2 PSC-3 PSC-4 still appeared in the registry but with
'deprecated' alongside each of them.  Given the updated reference to
whatever RFC this I-D becomes, then it will be relatively easy to follow
that link and see what these deprecated entries once were so it is a
minor consideration.

Tom Petch