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

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 21 August 2013 10:56 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1496E11E81FA for <ccamp@ietfa.amsl.com>; Wed, 21 Aug 2013 03:56:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.572
X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id na+uEYcVLRga for <ccamp@ietfa.amsl.com>; Wed, 21 Aug 2013 03:55:57 -0700 (PDT)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com []) by ietfa.amsl.com (Postfix) with ESMTP id E1D0111E8128 for <ccamp@ietf.org>; Wed, 21 Aug 2013 03:55:56 -0700 (PDT)
Received: from asmtp2.iomartmail.com (localhost.localdomain []) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7LAttsj017153; Wed, 21 Aug 2013 11:55:55 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com []) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7LAtsYv017143 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Aug 2013 11:55:54 +0100
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <draft-ietf-ccamp-swcaps-update.all@tools.ietf.org>
Date: Wed, 21 Aug 2013 11:55:52 +0100
Message-ID: <00a501ce9e5d$017b7ba0$047272e0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac6eXPt4rBZeUUS6Sf+PiLTjktojNQ==
Content-Language: en-gb
Cc: ccamp@ietf.org
Subject: [CCAMP] AD review of draft-ietf-ccamp-swcaps-update
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
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: Wed, 21 Aug 2013 10:56:16 -0000

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

For the moment I have put the document in "Revised I-D Needed" state.

Thanks for the work.



Please add a note to the IANA considerations section to request an
update to

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

   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

   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.