Re: [Gen-art] Gen-ART Last Call review of draft-ietf-tsvwg-rfc5405bis

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

Paul,

> > So, (as WG chair for this paragraph only), thank you for your input, but this is a
> single draft for very good reasons.
> > </WG chair hat>
> 
> Thanks for the explanation. The thing about genart reviews is that the
> reviewer doesn't have the context that the authors do, and maybe not the
> context that likely readers will have. I certainly won't second guess
> you on that.

And double-checking this sort of thing is one of the purposes of Gen-ART reviews (said as a long-time former Gen-ART reviewer), so thanks for bringing this topic up - if nothing else, we now have this concern and response documented in email archives for IESG review of this draft ;-).

Thanks, --David

> -----Original Message-----
> From: Paul Kyzivat [mailto:[e-mail]]
> Sent: Tuesday, May 31, 2016 10:09 AM
> To: Black, David; [e-mail]
> Cc: General Area Review Team
> Subject: Re: Gen-ART Last Call review of draft-ietf-tsvwg-rfc5405bis
> 
> On 5/31/16 9:52 AM, Black, David wrote:
> > Paul,
> >
> > Many thanks for the review.
> >
> >> (1) Major? - Scope and Audience
> >
> >> Beyond that it delves into a seeming random assortment of additional
> >> specialized uses of UDP. These may be of interest to some, but I suspect
> >> many won't find these things useful. And the topics covered seem to be
> >> simply what came to mind rather than being in some way exhaustive.
> >
> > Actually, the selection algorithm is dominated by what's come up in practice and
> merits advice - Section 3.6 on Limited Applicability and Controlled Environments is
> an excellent example.
> >
> >> After diffing this document against RFC5405 I see that it really is an
> >> incremental change that leaves the scope largely unchanged except for
> >> the addition of multicast. So perhaps I am too late to question the
> >> scope of the document. But since this *is* a bis, it might be worth
> >> considering whether the scope could be focused by splitting some of the
> >> material off into a different document(s).
> >
> > <WG chair hat>
> > Well, I think you're in the "rough" on "rough consensus" here - as this draft is
> targeted at designers and developers, there is strong WG "rough consensus" to
> put everything in one place.  To this end, multiple drafts were combined by the
> WG (e.g., the multicast requirements used to be in a separate draft).
> >
> > So, (as WG chair for this paragraph only), thank you for your input, but this is a
> single draft for very good reasons.
> > </WG chair hat>
> 
> Thanks for the explanation. The thing about genart reviews is that the
> reviewer doesn't have the context that the authors do, and maybe not the
> context that likely readers will have. I certainly won't second guess
> you on that.
> 
> >> (2) MINOR? - use of SHOULD
> >>
> >> I was struck by how much SHOULD is used in this document, and how
> >> infrequently MUST is used. And while possible justifications for
> >> violating SHOULD are sometimes provided, they often are not. In my
> >> experience there has been a growing awareness that such vagueness is
> >> problematic, because many implementers take it as free license to treat
> >> SHOULD as MAY, and just not do it.
> >
> > I concur - an author scan for use of "SHOULD" would make sense to do a couple
> of things:
> >
> > - Make sure the rationale for the strong recommendation is explained.
> > - Consider upgrading to "MUST".  Otherwise, ensure that potential
> consequences of not following the "SHOULD" are described.
> >
> > I prefer describing possible consequences to suggesting justifications for
> violation, as the latter (IMHO) encourages the (undesirable) behavior of
> designers and implementers "treat[ing] SHOULD as MAY," and the former is a
> better match to RFC 2119's definition of "SHOULD."
> 
> IMO this is still an unresolved topic in the IETF. Until (and unless) it
> is resolved, groups will treat as they see best.
> 
> As best I can understand, there is no difference between "SHOULD unless
> ..." and "MUST unless ...". So perhaps the real choice is whether to use
> SHOULD at all.
> 
> If you can identify the consequences without knowing the conditions,
> then that does seem like a good compromise.
> 
> (Note that while unexplained SHOULDs bother me, I am as guilty of using
> them as anybody else. It is just so *easy* to do rather than try to
> anticipate all the possibilities.)
> 
> 	Thanks,
> 	Paul
> 
> >> (3) NITs
> >
> > Thanks for noticing these nits - they will all be fixed.
> >
> > Thanks, --David (as draft shepherd).
> >
> >> -----Original Message-----
> >> From: Paul Kyzivat [mailto:[e-mail]]
> >> Sent: Saturday, May 28, 2016 2:23 PM
> >> To: [e-mail]
> >> Cc: General Area Review Team
> >> Subject: Gen-ART Last Call review of draft-ietf-tsvwg-rfc5405bis
> >>
> >> I am the assigned Gen-ART reviewer for this draft. The General Area
> >> Review Team (Gen-ART) reviews all IETF documents being processed by the
> >> IESG for the IETF Chair. Please treat these comments just like any other
> >> last call comments. For more information, please see the FAQ at
> >> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> >>
> >> Document: draft-ietf-tsvwg-rfc5405bis
> >> Reviewer: Paul Kyzivat
> >> Review Date: 2016-04-27
> >> IETF LC End Date: 2016-05-31
> >> IESG Telechat date:
> >>
> >> Summary:
> >>
> >> This draft is on the right track but has open issues, described in the
> >> review.
> >>
> >> Issues:
> >>
> >> (Note: I am having difficulty assigning severity levels to these issues.
> >> So take the leveling with a grain of salt.)
> >>
> >> Major: 1?
> >> Minor: 1
> >> Nits:  3
> >>
> >> (1) Major? - Scope and Audience
> >>
> >> I had difficulty understanding the intended scope of this document, and
> >> the intended audience. It seems to want to be a variety of things.
> >>
> >> * It seems to be a fine reference about congestion control for
> >> applications of UDP.
> >>
> >> * It also seems to be pretty helpful in challenging developers about
> >> whether they should be using UDP or something else.
> >>
> >> Probably everyone contemplating using UDP ought to read this for that
> >> stuff. Those topics would be a good focus for the document.
> >>
> >> Beyond that it delves into a seeming random assortment of additional
> >> specialized uses of UDP. These may be of interest to some, but I suspect
> >> many won't find these things useful. And the topics covered seem to be
> >> simply what came to mind rather than being in some way exhaustive.
> >>
> >> Also, some applicability to congestion control for non-UDP protocols
> >> (those layered directly on IP) is claimed. This seems a bit of an
> >> afterthought, and incompletely covered.
> >>
> >> After diffing this document against RFC5405 I see that it really is an
> >> incremental change that leaves the scope largely unchanged except for
> >> the addition of multicast. So perhaps I am too late to question the
> >> scope of the document. But since this *is* a bis, it might be worth
> >> considering whether the scope could be focused by splitting some of the
> >> material off into a different document(s).
> >>
> >> (2) MINOR? - use of SHOULD
> >>
> >> I was struck by how much SHOULD is used in this document, and how
> >> infrequently MUST is used. And while possible justifications for
> >> violating SHOULD are sometimes provided, they often are not. In my
> >> experience there has been a growing awareness that such vagueness is
> >> problematic, because many implementers take it as free license to treat
> >> SHOULD as MAY, and just not do it.
> >>
> >> (IIUC, in a BCP the normative language is relative to best practice. So
> >> if MUST is written and you don't do it then you aren't following best
> >> practice. But if SHOULD is written without qualification, and you don't
> >> follow it then you can probably claim that you are still following the
> >> best practice as documented by the document.)
> >>
> >> I note that most of the SHOULD usage is inherited from RFC5405, so there
> >> is some justification for just leaving it be. But it could be a helpful
> >> exercise to review all this usage, and consider whether usages of SHOULD
> >> can be changed to MUST, or if valid justifications for violating the
> >> SHOULD can be stated.
> >>
> >> (3) NITs: Section 3.1.7
> >>
> >> In the following:
> >>
> >>     The set of mechanisms requires for an application to use ECN over UDP
> >>     are:
> >>
> >> s/requires/required/
> >>
> >> In the following:
> >>
> >>     [RFC6679] provides guidance an example of this support, by describing
> >>
> >> s/guidance/guidance and/
> >>
> >> In the following:
> >>
> >>     In general, packets may be forwarded across multiple networks the
> >>     between source and destination.
> >>
> >> s/ the//
> >>
> >> (4) NIT: Appendix A:
> >>
> >> I couldn't parse the following sentence as written:
> >>
> >>     MPLS-in-UDP endpoints must check the source IPv6 address in addition
> >>     to the destination IPv6 address, plus the strong recommendation
> >>     against reuse of source IPv6 addresses among MPLS-in-UDP tunnels
> >>     collectively provide some mitigation for the absence of UDP checksum
> >>     coverage of the IPv6 header.
> >>
> >> I think it would better reflect the intent if it is changed as follows:
> >>
> >> s/MPLS-in-UDP endpoints must/The requirement for MPLS-in-UDP endpoints
> to/
> >>
> >> (5) NITs - unlinked references
> >>
> >> I found a number of cases where, in the html format, references are not
> >> hyperlinked:
> >>
> >> [RFC5405] section 1
> >> [RFC4342] section 3
> >> [RFC6679] section 3.1.7
> >> [RFC1981] section 3.2
> >> [RFC6935] section 3.4.1
> >>
> >
> >