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

t.petch <ietfc@btconnect.com> Thu, 22 August 2013 17:23 UTC

Return-Path: <ietfc@btconnect.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4CC921F9C69 for <ccamp@ietfa.amsl.com>; Thu, 22 Aug 2013 10:23:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.349
X-Spam-Level:
X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+kPhJfRmD+c for <ccamp@ietfa.amsl.com>; Thu, 22 Aug 2013 10:23:21 -0700 (PDT)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 5029811E8106 for <ccamp@ietf.org>; Thu, 22 Aug 2013 10:23:20 -0700 (PDT)
Received: from mail168-co1-R.bigfish.com (10.243.78.253) by CO1EHSOBE012.bigfish.com (10.243.66.75) with Microsoft SMTP Server id 14.1.225.22; Thu, 22 Aug 2013 17:23:20 +0000
Received: from mail168-co1 (localhost [127.0.0.1]) by mail168-co1-R.bigfish.com (Postfix) with ESMTP id 08270AC03A2; Thu, 22 Aug 2013 17:23:20 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -17
X-BigFish: PS-17(zzbb2dI98dI9371I542I1432I1447Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah1de096h8275dh1de097hz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h)
Received: from mail168-co1 (localhost.localdomain [127.0.0.1]) by mail168-co1 (MessageSwitch) id 1377192167918929_23013; Thu, 22 Aug 2013 17:22:47 +0000 (UTC)
Received: from CO1EHSMHS031.bigfish.com (unknown [10.243.78.244]) by mail168-co1.bigfish.com (Postfix) with ESMTP id DD0B490021C; Thu, 22 Aug 2013 17:22:47 +0000 (UTC)
Received: from AM2PRD0710HT001.eurprd07.prod.outlook.com (157.56.249.213) by CO1EHSMHS031.bigfish.com (10.243.66.41) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 22 Aug 2013 17:22:47 +0000
Received: from AMXPRD0310HT004.eurprd03.prod.outlook.com (157.56.248.133) by pod51017.outlook.com (10.255.165.36) with Microsoft SMTP Server (TLS) id 14.16.347.3; Thu, 22 Aug 2013 17:22:34 +0000
Message-ID: <025701ce9f5c$185bcc80$4001a8c0@gateway.2wire.net>
From: t.petch <ietfc@btconnect.com>
To: Lou Berger <lberger@labn.net>, <adrian@olddog.co.uk>
References: <00a501ce9e5d$017b7ba0$047272e0$@olddog.co.uk> <52153E45.1030505@labn.net>
Date: Thu, 22 Aug 2013 18:21:27 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.248.133]
X-OriginatorOrg: btconnect.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: draft-ietf-ccamp-swcaps-update.all@tools.ietf.org, ccamp@ietf.org
Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-swcaps-update
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Aug 2013 17:23:26 -0000

----- Original Message -----
From: "Lou Berger" <lberger@labn.net>
To: <adrian@olddog.co.uk>
Cc: <draft-ietf-ccamp-swcaps-update.all@tools.ietf.org>rg>;
<ccamp@ietf.org>
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