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

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 8 Jan 2014 11:21:35 -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.

---

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 9 Jan 2014 12:13:58 -0500

Hi Adrian,

> There is nothing of substance.

Thanks.

> helps. Also thanks for correctly catching the errata report from 6326.

You're welcome.

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

OK.

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

OK.

> that they set the values correctly. Not essential that you do this, but "strong

OK.

> See also the second figure on page 25.

I think that can be fixed by just scaling the horizontal axis and
adding tic marks (replacing "-" with "+") at every bit boundary.

> Affinity Flag is missing closing brace in figure

OK.

> Additionally, this document defines some new allocations.

OK.

Additionally, I just noticed that there is an informative reference to
draft-zhang-trill-resilient-trees. That draft has been replaced by
draft-ietf-trill-resilient trees and I believe the reference to this
work in progress should be updated.

Since the draft is in IETF Last Call, I assume a new version shouldn't
be posted until after the end of the Last Call.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 9 Jan 2014 17:41:26 -0000

Hi Donald,
Thanks for the response. All in order.

> be posted until after the end of the Last Call.

Yes, thanks. Since these changes are just nits, let's not complicate things with
an update.
(The cost of someone else also raising them is minor).

Cheers,
Adrian