MIME-Version: 1.0
References: <CAF4+nEGu9XEiXypPw0NK+f2N9QbBwyTJKXbViKWVScJhOW=vUA@mail.gmail.com>
In-Reply-To: <CAF4+nEGu9XEiXypPw0NK+f2N9QbBwyTJKXbViKWVScJhOW=vUA@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Thu, 6 Feb 2020 18:03:12 -0500
Message-ID: <CAF4+nEEB2-pz4ugW-m1-3gq9KH-fyt93sLZ9WFh4BkJqQPX7PA@mail.gmail.com>
To: tsvwg@ietf.org
Content-Type: multipart/alternative; boundary="000000000000aaee40059df047d6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/rRKJUKWl9V8mFH0opAHg--6qHy8>
Subject: [tsvwg] Comments on draft-ietf-tsvwg-ecn-encap-guidelines-13
Precedence: list

--000000000000aaee40059df047d6
Content-Type: text/plain; charset="UTF-8"

Hi,

I'm not subscribed to the tsvwg mailing list but I have reviewed
draft-ietf-tsvwg-ecn-encap-guidelines-13 and though you might be interested
in my comments.

Overall, this is a very clear and well-written draft. The comments below
are minor. Whether or not they are incorporated into the draft, I hope that
it can be advanced soon.

Section 1. I suggest just deleting the one occurrence in the draft of
"[RFC1323]" and the corresponding reference section entry. It seems
unnecessary and just leads to a nits checker warning which will have to be
explained, etc.

Section 1.1. Very minor but I believe the usual way, inside a draft, to
refer to the RFC which that draft might become is "[this document]"
(without the double quotes) rather than "[RFCXXXX]". Changing to the more
common notation would, I believe, enable the RFC Editor note to be removed
as "[this document]" is well understood by the RFC Editor.

Section 2. The initial paragraph on implementation keywords should be
updated to the following as per RFC 8174:

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] [RFC8174]
when, and only when, they appear in all capitals, as shown here.


Section 2. Suggest putting the Terminology entries in alphabetic order.

Section 4.2, page 18. "802.1p" has been merged into 802.1Q ages ago. Values
of the priority field are commonly referred to in IEEE 802.1 as Priority
Code Points (PCPs) and in any case this seems a bit inconsistent to the way
that the merger of 802.1ah into 802.1Q is recognized in the draft. Perhaps
the last sentence of Section 4.2 could be: "An operator can define certain
[IEEE802.1Q] Priority Code Points to indicate non-QCN frames and an ingress
bridge is required to map arriving not-QCN-capable IP packets to one of
these code points."

Section 4.4, point 1, first starred subpoint, there is something odd about
"the packet MAY be forwarded, but it SHOULD be dropped".

Section 7. It doesn't matter much but IANA would prefer that sections
saying there are no IANA actions be left in the final RFC (see Section 9.1
of RFC 8126).

Section 9. Should "the document" in the first line of this section by "this
document"?

Appendix A. I did not review this update history.

Authors' Addresses: I don't think Pat Thaler can be listed as a front page
"author" in the RFC sense unless at least an email address is listed for
her. All authors should be pollable about IPR they know and when the draft
gets to the AUTH48 state before RFC publication, the RFC editor must be
able to contact all the authors. If no email address is known, she should
be moved to a "Contributors" section or the like.

--000000000000aaee40059df047d6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div dir=3D"ltr" class=3D"gmail_signature" data-smart=
mail=3D"gmail_signature">Hi,<br></div></div><div class=3D"gmail_quote"><div=
 dir=3D"ltr"><div><br>I&#39;m not subscribed to the tsvwg mailing list but =
I have reviewed draft-ietf-tsvwg-ecn-encap-guidelines-13 and though you mig=
ht be interested in my comments.<br><br>Overall, this is a very clear and w=
ell-written draft. The comments below are minor. Whether or not they are in=
corporated into the draft, I hope that it can be advanced soon.<br><br>Sect=
ion 1. I suggest just deleting the one occurrence in the draft of &quot;[RF=
C1323]&quot; and the corresponding reference section entry. It seems unnece=
ssary and just leads to a nits checker warning which will have to be explai=
ned, etc.<div><br>Section 1.1. Very minor but I believe the usual way, insi=
de a draft, to refer to the RFC which that draft might become is &quot;[thi=
s document]&quot; (without the double quotes) rather than &quot;[RFCXXXX]&q=
uot;. Changing to the more common notation would, I believe, enable the RFC=
 Editor note to be removed as &quot;[this document]&quot; is well understoo=
d by the RFC Editor.<div><br>Section 2. The initial paragraph on implementa=
tion keywords should be updated to the following as per RFC 8174:<br></div>=
</div></div><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"=
><div><div><div>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot=
;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;,</div></div></div=
><div><div><div>&quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMEND=
ED&quot;, &quot;MAY&quot;, and &quot;OPTIONAL&quot; in this</div></div></di=
v><div><div><div>document are to be interpreted as described in [RFC2119] [=
RFC8174]</div></div></div><div><div><div>when, and only when, they appear i=
n all capitals, as shown here.</div></div></div></blockquote><div><div><div=
><br>Section 2. Suggest putting the Terminology entries in alphabetic order=
.<br><br>Section 4.2, page 18. &quot;802.1p&quot; has been merged into 802.=
1Q ages ago. Values of the priority field are commonly referred to in IEEE =
802.1 as Priority Code Points (PCPs) and in any case this seems a bit incon=
sistent to the way that the merger of 802.1ah into 802.1Q is recognized in =
the draft. Perhaps the last sentence of Section 4.2 could be: &quot;An oper=
ator can define certain [IEEE802.1Q] Priority Code Points to indicate non-Q=
CN frames and an ingress bridge is required to map arriving not-QCN-capable=
 IP packets to one of these code points.&quot;</div><div><br></div><div>Sec=
tion 4.4, point 1, first starred subpoint, there is something odd about &qu=
ot;the packet MAY be forwarded, but it SHOULD be dropped&quot;.=C2=A0</div>=
</div><div><br></div><div>Section 7. It doesn&#39;t matter much but IANA wo=
uld prefer that sections saying there are no IANA actions be left in the fi=
nal RFC (see Section 9.1 of RFC 8126).</div><div><br></div><div>Section 9. =
Should &quot;the document&quot; in the first line of this section by &quot;=
this document&quot;?</div><div><br></div><div>Appendix A. I did not review =
this update history.</div><div><br></div><div>Authors&#39; Addresses: I don=
&#39;t think Pat Thaler can be listed as a front page &quot;author&quot; in=
 the RFC sense unless at least an email address is listed for her. All auth=
ors should be pollable about IPR they know and when the draft gets to the A=
UTH48 state before RFC publication, the RFC editor must be able to contact =
all the authors. If no email address is known, she should be moved to a &qu=
ot;Contributors&quot; section or the like.</div><div><br></div><div><br></d=
iv><div><br></div></div></div>
</div></div>

--000000000000aaee40059df047d6--