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

["Susan Hares" <[e-mail]>]

Donald:

I agree that the normative reference [OAM-FRAMEWK] (now [RFC7174]) can be changed to an informative
reference, which would avoid the down reference.

On the textual "4.4.1 ", if it is easier - let the RFC Editor fix the final form.  I will note the RFC editor should watch for it, and remove the editorial comment for the authors. 

On the IANA suggestion,  I agree that IANA should not have control over the registries that IEEE 802.1 has. The question is whether IANA should track the non-IETF specifications that IETF drafts includes.  Unless someone objects, I will remove this comment from the shepherds report. 

I'll see if anyone else has comments on the shepherds report today until 3pm ET, and then change it. 

Sue             

-----Original Message-----
From: trill [mailto:[e-mail]] On Behalf Of Donald Eastlake
Sent: Tuesday, May 27, 2014 11:40 PM
To: Susan Hares
Cc: [e-mail]; Jon Hudson; [e-mail]
Subject: Re: [trill] Shepherd's review of draft-ietf-trill-loss-delay

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

_______________________________________________
trill mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/trill