Subject: [tsvwg] Comments on draft-ietf-tsvwg-ecn-encap-guidelines-13

From: Donald Eastlake <[email-masked]>
Date: Thu, 6 Feb 2020 18:03:12 -0500

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.