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

["Black, David" <[e-mail]>]

To tie off the Section 4.4 loose end, I'm ok with resolving this by stopping at ".. the packet 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.
> > As per subsequent discussion in this thread, if you are OK with
> > stopping at "... the packet SHOULD be dropped." that would certainly
> > resolve my comment.

Thanks, --David

> -----Original Message-----
> From: tsvwg <[e-mail]> On Behalf Of Bob Briscoe
> Sent: Wednesday, March 11, 2020 5:38 AM
> To: Donald Eastlake
> Cc: John Kaippallimalil; [e-mail]
> Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-ecn-encap-guidelines-13
> 
> 
> [EXTERNAL EMAIL]
> 
> Donald,
> 
> Thanks - all in my local copy, which will hopefully be uploaded shortly,
> depending on the other discussion about fragmentation.
> I'll point you at that, given you're not subscribed to the list.
> 
> 
> Bob
> 
> On 11/03/2020 01:33, Donald Eastlake wrote:
> > Hi Bob,
> >
> > On Tue, Mar 10, 2020 at 1:28 PM Bob Briscoe <[e-mail]> wrote:
> >> 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.)
> > Thanks. I understand how you feel but currently the IESG likes the
> > boilerplate with RFC 8174 reference...
> >
> >> 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.
> > OK.
> >
> >> 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').
> > I'm fine with your wording. No problem mentioning 802.1p as long as it
> > doesn't send people off looking for a current version of that but
> > rather makes it clear that the relevant material in now in 802.1Q.
> >
> >> 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.
> > As per subsequent discussion in this thread, if you are OK with
> > stopping at "... the packet SHOULD be dropped." that would certainly
> > resolve my comment.
> >
> >> 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.
> > OK, all seems good.
> >
> > Thanks,
> > Donald
> > ===============================
> >   Donald E. Eastlake 3rd   [phone] (cell)
> >   2386 Panoramic Circle, Apopka, FL 32703 USA
> >   [e-mail]
> >
> >> Thank you again.
> >>
> >> Bob
> >>
> >>
> >> --
> >>
> ________________________________________________________________
> >> Bob Briscoe                               http://bobbriscoe.net/
> 
> --
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/