[Isis-wg] Progressing draft-ietf-isis-rfc6326bis

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 08 January 2014 11:21 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808E11AE2DC for <isis-wg@ietfa.amsl.com>; Wed, 8 Jan 2014 03:21:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7WQsCjO0rNB for <isis-wg@ietfa.amsl.com>; Wed, 8 Jan 2014 03:21:44 -0800 (PST)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id A3D521AE18B for <isis-wg@ietf.org>; Wed, 8 Jan 2014 03:21:43 -0800 (PST)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s08BLXDH010911; Wed, 8 Jan 2014 11:21:33 GMT
Received: from 950129200 (AGrenoble-651-1-603-115.w90-52.abo.wanadoo.fr [90.52.59.115]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s08BLVOB010848 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Jan 2014 11:21:32 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: draft-ietf-isis-rfc6326bis@tools.ietf.org
Date: Wed, 08 Jan 2014 11:21:35 -0000
Message-ID: <02c501cf0c63$cb34bb40$619e31c0$@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: Ac8MY8N4aOy2H7SxTpunpWntSWVKxg==
Content-Language: en-gb
X-TM-AS-MML: No
Cc: isis-wg@ietf.org
Subject: [Isis-wg] Progressing draft-ietf-isis-rfc6326bis
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jan 2014 11:21:46 -0000

Hi authors,

I have just issued the IETF last call. Along the way I read the draft and have a
few comments that I hope you will fix as part of the IETF last call process.
There is nothing of substance.

BTW Thanks for the detailed notes on the differences from RFC 6326: that really
helps. Also thanks for correctly catching the errata report from 6326.

Thanks,
Adrian

===

idnits reports..
  ** You're using the IETF Trust Provisions' Section 6.b License Notice from
     12 Sep 2009 rather than the newer Notice from 28 Dec 2009.  (See
     http://trustee.ietf.org/license-info/)
Although the text you have included starts with identical boilerplate, I believe
the difference is that it is no longer necessary to include:
   The definitive version of
   an IETF Document is that published by, or under the auspices of, the
   IETF. Versions of IETF Documents that are published by third parties,
   including those that are translated into other languages, should not
   be considered to be definitive versions of IETF Documents. The
   definitive version of these Legal Provisions is that published by, or
   under the auspices of, the IETF. Versions of these Legal Provisions
   that are published by third parties, including those that are
   translated into other languages, should not be considered to be
   definitive versions of these Legal Provisions.  For the avoidance of
   doubt, each Contributor to the IETF Standards Process licenses each
   Contribution that he or she makes as part of the IETF Standards
   Process to the IETF Trust pursuant to the provisions of RFC 5378. No
   language to the contrary, or terms, conditions or rights that differ
   from or are inconsistent with the rights and licenses granted under
   RFC 5378, shall have any effect and shall be null and void, whether
   published or posted by such Contributor, or included with or in such
   Contribution.

While this is not critical, it would be nice to clean it up.

---

Please update the reference to RFC 5342 to refer to RFC 7042.

---

In general I think it would help IANA avoid accidents if you labelled each TBD
differently (TBD1, TBD2, etc.) That way IANA and the RFC editor can make sure
that they set the values correctly. Not essential that you do this, but "strong
advice".

---

The figure in Section 2.2.1 is mildly confusing because the Type field marks off
the 8 bits in the octet, but the bit flags in the last four octets take up a bit
and a half each on that diagrammatic convention. Consequently, the two following
12-bit fields look to be only 10 bits. The text makes this all relatively clear,
but I have a pictorial view of the world so the figure derailed me. Anything you
can do? The figure at the top of page 23 has a way of handling a similar issue.
See also the second figure on page 25.

---

Section 2.3.10
Affinity Flag is missing closing brace in figure

---

I think section 5 could usefully start with a short statement about allocations
already made for RFC 6326. This document restates those allocations in full, and
IANA is requested to update all of them to reference this document and to delete
the reference to RFC 6326 from the registries.

Additionally, this document defines some new allocations.

---