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

From: Paul Kyzivat <[email-masked]>
Date: Sat, 28 May 2016 14:23:21 -0400

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

---

From: "Black, David" <[email-masked]>
Date: Tue, 31 May 2016 13:52:59 +0000

Paul,

Many thanks for the review.

> 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.

> 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>

> 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."

> (3) NITs

Thanks for noticing these nits - they will all be fixed.

Thanks, --David (as draft shepherd).

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Saturday, May 28, 2016 2:23 PM
> To: [email-masked]
> Cc: General Area Review Team
> Subject: Gen-ART Last Call review of draft-ietf-tsvwg-rfc5405bis
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 31 May 2016 10:08:57 -0400

> So, (as WG chair for this paragraph only), thank you for your input, but this is a single draft for very good reasons.

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.

> 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…

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

---

From: "Black, David" <[email-masked]>
Date: Tue, 31 May 2016 14:12:52 +0000

Paul,

> context that likely readers will have. I certainly won't second guess

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

> Sent: Tuesday, May 31, 2016 10:09 AM
> To: Black, David; [email-masked]
> Subject: Re: Gen-ART Last Call review of draft-ietf-tsvwg-rfc5405bis
> 
> > 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.
> >
> > 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).
> >
> > - 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."
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 31 May 2016 10:12:03 -0500

Hi, Paul,

On Tue, May 31, 2016 at 9:12 AM, Black, David <[email-masked]> wrote:

> 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>
> >
> 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 ;-).

David beat me to it, but I do want to say that (as another long-time former
Gen-ART reviewer) I'm very interested in FIRST guesses from reviewers who
haven't been involved in every discussion of every revision of the draft.

I'm sure there's a forest behind all these trees someplace :-)

Spencer