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

[Donald Eastlake <[e-mail]>]

Hi Adrian,

On Wed, Jan 8, 2014 at 6:21 AM, Adrian Farrel <[e-mail]> wrote:
> 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.

Thanks.

> 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.

You're welcome.

> 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.

OK.

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

OK.

> ---
>
> 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".

OK.

> ---
>
> 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.

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

> ---
>
> Section 2.3.10
> Affinity Flag is missing closing brace in figure

OK.

> ---
>
> 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.

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   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]