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

From: "Susan Hares" <[email-masked]>
Date: Tue, 27 May 2014 19:15:32 -0400

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. 

 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

-------

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. 

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]

-----

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. 

Sue Hares

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 27 May 2014 23:39:45 -0400

Hi Sue,

Thanks for the Shepherd review.

On Tue, May 27, 2014 at 7:15 PM, Susan Hares <[email-masked]> wrote:
> Authors and TRILL WG:
>
>
> I submit for the authors and WG’s review attached review of the

Thanks.

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

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

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

> 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   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 28 May 2014 06:28:46 -0400

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:[email-masked]] On Behalf Of Donald Eastlake
Sent: Tuesday, May 27, 2014 11:40 PM
To: Susan Hares
Cc: [email-masked]; Jon Hudson; [email-masked]
Subject: Re: [trill] Shepherd's review of draft-ietf-trill-loss-delay

Hi Sue,

On Tue, May 27, 2014 at 7:15 PM, Susan Hares <[email-masked]> wrote:
>  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
> 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.
> Required Editorial Fixes [May be deleted if authors revise] =====
>
>

Thanks,
Donald

> Sue Hares

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

---

From: Tal Mizrahi <[email-masked]>
Date: Thu, 29 May 2014 21:01:44 +0300

Sue,

Thanks for the comments.
I posted an updated draft that addresses these comments.
http://tools.ietf.org/html/draft-ietf-trill-loss-delay-04

Thanks,
Tal.

-----Original Message-----
From: trill [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Wednesday, May 28, 2014 1:29 PM
To: 'Donald Eastlake'
Cc: [email-masked]; [email-masked]; 'Jon Hudson'
Subject: Re: [trill] Shepherd's review of draft-ietf-trill-loss-delay

Donald:

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

Sue             

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

Hi Sue,

Thanks.

> 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 sort of looke like a normative reference but really, I think it should be changed to something like

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.

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

> 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   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA  [email-masked]

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 29 May 2014 22:32:11 -0400

Tal:

This looks good to me.  I have adjusted the shepherds report and Donald can
forward this to the AD/IESG.

Sue 

-----Original Message-----
From: Tal Mizrahi [mailto:[email-masked]] 
Sent: Thursday, May 29, 2014 2:02 PM
To: Susan Hares; 'Donald Eastlake'
Cc: [email-masked]; [email-masked]; 'Jon Hudson'
Subject: RE: [trill] Shepherd's review of draft-ietf-trill-loss-delay

Sue,

Thanks for the comments.

Thanks,
Tal.

-----Original Message-----
From: trill [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Wednesday, May 28, 2014 1:29 PM
To: 'Donald Eastlake'
Cc: [email-masked]; [email-masked]; 'Jon Hudson'
Subject: Re: [trill] Shepherd's review of draft-ietf-trill-loss-delay

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:[email-masked]] On Behalf Of Donald Eastlake
Sent: Tuesday, May 27, 2014 11:40 PM
To: Susan Hares
Cc: [email-masked]; Jon Hudson; [email-masked]
Subject: Re: [trill] Shepherd's review of draft-ietf-trill-loss-delay

Hi Sue,

Thanks.

> 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 sort of looke like a normative reference but really, I think it should
be changed to something like

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.

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.

> 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