Re: [trill] Shepherd's review of draft-ietf-trill-loss-delay

[Donald Eastlake <[e-mail]>]

Hi Sue,

Thanks for the Shepherd review.

On Tue, May 27, 2014 at 7:15 PM, Susan Hares <[e-mail]> wrote:
> Authors and TRILL WG:
>
>
> I submit for the authors and WG’s review attached review of the
> draft-ietf-trill-loss-delay-03.txt
>
>
> Sue Hares
> -----
>
>
> Document Quality
>
>
> The written text of this document is high.  The performance monitoring
> issues clearly specified with clear descriptions of the mechanisms.
>  This document is a pleasure to read with only 3 editorial issues mentioned
> Below, and one IANA suggestion.

Thanks.

>  The document has been co-authors by two groups implementing the
>  code for deployment (Cisco and Huawei).  The careful attention to
> operational issues have shows in this draft.   No specific announcement
> of the release date for  these TRILL PM implementations has been
> made.  An implementation survey planned for June so a better
> understanding of the deployments may align with the IESG review.
>  Other vendors have indicated consideration of the PM specification.
>
>
> Required Editorial Fixes [May be deleted if authors revise]
> =====
>
>
> draft-to-RFC updated needed:
>
>
> 1) Outdated reference: draft-ietf-trill-oam-framework has been
>      published as RFC 7174
>
> 2) Outdated reference: draft-ietf-trill-fine-labeling has been
> published as RFC 7172

Yes, these need to be updated.

> -------
>
> downref: Normative reference to informational draft
>
>
>      draft-ietf-trill-oam-framework (ref. 'OAM-FRAMEWK')
>
>
> As a shepherd, I find this to be correct technically.  However,
> WG chairs/AD should review this down ref.

I'm not sure. There is a lot of interesting background in the
framework document, but do you actually have to look at it to
implement this draft? The closest I can find to that is the following
text in the draft:

      This document does not define procedures for packet loss
      computation based on counting user data. For further details see
      [OAM-FRAMEWK].

This sort of looke like a normative reference but really, I think it
should be changed to something like

      This document does not define procedures for packet loss
      computation based on counting user data for the reasons given in
      Section 5.1 of [RFC7174].

So, unless I'm missing something, I think the normative reference to
[OAM-FRAMEWK] (now [RFC7174]) can be changed to an informative
reference, which would avoid the down reference.

> Suggested Technical changes
>
> [pages 24-25: Is the reserved field zero? If so, please indicate.
> If not, please indicate that it is unspecified.
>
> Editorial:
>
> "4.1.1 ,"  to "4.4.1,"
> [this seems to be an artifact of the word processing]

I'm slightly confused. There seem to be two occurrences of "4.1.1" but
neither looks like that and there seem to be zero occurrences of
"4.4.1"...  Near the beginning of Section 4.1.1 there is a "3.2.1.  ,"
(with two spaces).  Typically I think that sort of thing is due to
weirdness with MS Word adding a space. It may be hard to fix if the
original is in that form, but the RFC Editor can clear such stuff up.

> -----
>
> IANA suggestion:
>
> It may be worth considering if IANA should keep a record assignments of the
> Y.1731 defined in 6.4.  This will be useful if there is ISO/IETF
> collaboration discussion.

IANA registries for the OpCodes and TLV Types values that are
available for IETF assignment are being set up by
draft-eastlake-iana-cfm-considerations which is currently in IESG
ballot. However, this draft doesn't need to allocat any additional
values. IEEE 802.1 is in charge of these code points and has allocated
blocks to ITU-T, for Y.1731, and to IETF for TRILL and other IETF
uses.  I'm not sure that IANA having informative duplicative of code
points in this space that are not on IANA control is such a good idea.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> Sue Hares