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

[Bob Briscoe <[e-mail]>]

Donald,

Thank you for taking the time to review this (rather long) draft.
Apologies for not getting to your review until now.

On 06/02/2020 23:03, Donald Eastlake wrote:
> 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.
>
Done all the above
(BTW, I always baulk at having to cite RFC8174, when the following 12 
words succinctly state the sum total of its content.)

>
> Section 2. Suggest putting the Terminology entries in alphabetic order..
I haven't done this. They are more for reading through than for being 
looked up individually, most of them fall into logical little groups, 
and there are not so many that it's hard to find one.

>
> 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."
OK. I've taken on board the spirit of your edit, but changed it slightly:

    An operator can define certain
    Priority Code Points (PCPs [IEEE802.1Q]; previously 802.1p) to
    indicate non-QCN frames and an ingress bridge is required to map
    arriving not-QCN-capable IP packets to one of these non-QCN PCPs.

This is then consistent with the other references to 802.1Q, which also 
give the number of the constituent part before it was wrapped up into 
the mega-standard. If you think this is clumsy, pls say. I did it this 
way, because many people know these 802.1 drafts much better by their 
old name (well, for 'many people' read 'me', or perhaps read it as 'old 
farts like me').

>
> Section 4.4, point 1, first starred subpoint, there is something odd 
> about "the packet MAY be forwarded, but it SHOULD be dropped".
Any better (I've added some of the context for the list)?:

           If the congestion marking is the
           most severe possible, the packet MUST be dropped.  However, if
           congestion can be marked with multiple levels of severity and
           the packet's marking is not the most severe, this requirement
           can be relaxed to: the packet SHOULD be dropped, but it MAY be
           forwarded.

>
> 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).
I'm learning something new every day.

>
> Section 9. Should "the document" in the first line of this section by 
> "this document"?
Yes. Done.
>
> 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.
Yes. I discovered that (too late) last night, when the draft got 
rejected on this point!
I've added a Contributors section for her.

Thank you again.



Bob




-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/