[CCAMP] AD review of draft-ietf-ccamp-rsvp-te-eth-oam-ext

"Adrian Farrel" <adrian@olddog.co.uk> Mon, 10 February 2014 23:07 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 177551A0665 for <ccamp@ietfa.amsl.com>; Mon, 10 Feb 2014 15:07:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.553
X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id OtV6uXyXrVLN for <ccamp@ietfa.amsl.com>; Mon, 10 Feb 2014 15:07:29 -0800 (PST)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com []) by ietfa.amsl.com (Postfix) with ESMTP id F3D381A040E for <ccamp@ietf.org>; Mon, 10 Feb 2014 15:07:28 -0800 (PST)
Received: from asmtp4.iomartmail.com (localhost.localdomain []) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1AN7Rql015350; Mon, 10 Feb 2014 23:07:27 GMT
Received: from 950129200 ( []) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1AN7Pgp015336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Feb 2014 23:07:26 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: draft-ietf-ccamp-rsvp-te-eth-oam-ext.all@tools.ietf.org
Date: Mon, 10 Feb 2014 23:07:25 -0000
Message-ID: <01b401cf26b4$dd4a3330$97de9990$@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: Ac8mtNX2MJbNBMcoRg6gHgyviaINnw==
Content-Language: en-gb
Cc: 'CCAMP' <ccamp@ietf.org>
Subject: [CCAMP] AD review of draft-ietf-ccamp-rsvp-te-eth-oam-ext
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 10 Feb 2014 23:07:31 -0000


Thanks to the authors for engaging with me on the implementation
status and plans for this document.

The CCAMP OAM configuration framework draft has now progressed far
enough through the system that it is appropriate to move this one
forward, so I have done my usual AD review. The purpose of the 
review is to catch some of the larger issues that might come up in
IETF last call and IESG evaluation. Catching them early helps save
everyone time, and improves the quality of subsequent reviews.

I have a few small editorial issues listed below and a request for
some careful reworking of the IANA section. This is open for
discussion if you have any concerns, but until then I have placed
the document in "Revised I-D Needed" state. When I see a new
revision I will advance the document to IETF last call.

Thanks for the work.



Section 3.1 says

"procedures are recommended as follows" and then goes on to say "MUST"

That reads oddly.
I think you can just s/are recommended as follows/are as follows/


I think you have the Length in the TLVs messed up.
For example, in 3.3 you have
   Length: indicates the total length including sub-TLVs.
"Total length implies "including the T and L fields".
And in 3.3.1 and 3.3.2 you have
   Length: indicates the total length of the TLV including padding.
which has a similar implication.
Yet in 3.3.3 while you still have
   Length: indicates the total length of the TLV including padding.
the figure shoes "Length (4)"

Please update all descriptions of Length to say (depending on your
intention) either:

   Length: indicates the total length of the TLV including padding
           and including the Type and Length fields


   Length: indicates the total length of the TLV including padding
           but excluding the Type and Length fields

And then, obviously, check any explicit values in the text.


In Section 3.3.4 you have assigned 4 bits for each of the Priority and
CCM I fields.

Yet the text describes how these may be mapped directly to the
equivalent Ethernet fields each of which is described as being 3 bits.

Why is there this discrepancy and how will the top bit be used?


The IANA section needs some work.

First I suggest you break it into subsections to clearly show each
different registry being updated.

Then we need some additional text as follows:

- The RSVP-TE OAM Configuration Registry doesn't exist yet so you need
  to provide IANA with a reference using text like "[OAM-CONF-FWK]
  includes a request for IANA to create the RSVP-TE OAM Configuration
  Registry". IANA is requested to assign an OAM Type from this
  registry as follows.

  Similar thing for the sub-TLV type.

- For the sub-TLV you need to tell IANA that the value is to be allocated
  from the technology-specific range

- You need to not state specific values unless you have a strong reason
  for doing so or the values have already been assigned through early

  Replace "1" with TBA1
  Replace "32" with TBA2
  Go through the main body of the text and make these replacements as

  Then add text that says:
    The value of 1 is suggested for TBA1
    The value of 32 is suggested for TBA2

- The term "reserved" has a special meaning in IANA registries. It means
  "do not allocate". So I think you do not want to use that term in your
  new registry!

  Well, 0 may be genuinely reserved, but "5-" should probably read

- You need to indicate the maximum legitimate value for the code points
  in the new registry. So replace "5-" with "5-x" where x is the max
  value (governed by the size of the Type field?)

- You need to state the RFC 5226 assignment policy for the new registry.
  Probably "Standards Action", but you may have other ideas. Should any
  of the code points be reserved for Experimentation?

- "OAM Problem"
  - You need to tell IANA which registry you are talking about
  - The return code doesn't exist yet, so you need to include a 
    reference to [OAM-CONF-FWK]