Subject: [Taps] Genart last call review of draft-ietf-taps-minset-06

From: Robert Sparks <[email-masked]>
Date: Tue, 28 Aug 2018 14:38:39 -0700

Reviewer: Robert Sparks
Review result: Ready with Nits

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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-taps-minset-06
Reviewer: Robert Sparks
Review Date: 2018-08-28
IETF LC End Date: 2018-09-04
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as an Informational RFC, but with nits
to consider before publication.

I had to read quite a bit more than just RFC8303 to understand what
this document has to say. I  suggest moving at least the transport-
security document to normative, and probably also RFC8095.

This was a big effort, and it appears that it was helpful to the folks
working on the interface document, but it's not clear how it will be
useful to implementers. The IESG should consider  whether this, like
requirements documents, needs to be in the RFC series. The most likely
use I can see in the future would be for historians, and a different
and shorter presentation would serve them better.

If it proceeds to publication, consider the following nits:

The conclusion (section 4) would be more useful if it were moved to
the introduction (it says things more clearly than the introduction
does now).

Please check with the RFC Editor early about whether the [COBS]
reference is sufficiently stable.

And a couple of questions about the larger work for the group:

The capacity profile concept as captured in this document (page 9)
says it's a number. The interface document has the concept, with an
enumeration. Ultimately, this is going to require a registry, and you
might consider establishing it even though the interface is still
supposed to be an abstract thing. The enumeration is looking pretty
concrete.

In Appendix A.1, this document had to "slightly change" the
characterization of features  from those in RFC8303, introducing this
"ADDED" construct. That feels out of balance. Is this a warning sign
that RFC8303 needs adjusting?

---

From: Michael Welzl <[email-masked]>
Date: Fri, 31 Aug 2018 10:37:32 +0200

Hi,

Thank you very much for this careful review!  We just posted a revision ( -07 ) that, we believe, addresses these comments.

A few answers in line below:

> On 28 Aug 2018, at 23:38, Robert Sparks <[email-masked]> wrote:
> 
> Reviewer: Robert Sparks

Done;

> and shorter presentation would serve them better.

I beg to differ  :)
As much as I'd wish for that to happen, it would certainly be naive to believe that all the world is going to switch to the new and shiny TAPS API that is currently being defined.
There will always be higher-level APIs that follow their own design. We (authors) believe that the value of the minset document, aside from helping the TAPS design process, is to give implementers of such higher-level APIs advice on services that they should include (and may so far not have thought about).
From the introduction:
***
   ... The transport
   features in the minimal set in this document must be reflected in
   *all* network APIs in order for the underlying functionality to
   become usable everywhere.  For example, it does not help an
   application that talks to a library which offers its own
   communication interface if the underlying Berkeley Sockets API is
   extended to offer "unordered message delivery", but the library only
   exposes an ordered bytestream.  Both the Berkeley Sockets API and the
   library would have to expose the "unordered message delivery"
   transport feature ...
***

> the introduction (it says things more clearly than the introduction

Done. This replaces a paragraph in the introduction that essentially said the same thing as the conclusion did, but with clumsy language - so thanks, that was very useful!

> reference is sufficiently stable.

Thanks again: it probably wasn't, and now it is - we missed to include the seriesinfo tag that points at the Transactions on Networking journal.

> supposed to be an abstract thing. The enumeration is looking pretty

There is an ongoing discussion about "To registry, or not to registry?" in the TAPS list - not just about the capacity profile though. Here's the thread:
https://www.ietf.org/mail-archive/web/taps/current/msg01410.html

> that RFC8303 needs adjusting?

It isn't: different from this document, RFC 8303 does not make any changes or derive anything from the services that protocols offer - it just reflects what the protocol specifications say.

In the minset document, there are only 3 items using the "ADDED" construct, and this is only meant to streamline the derivation a little. Take "Unreliably transfer a message", for example.
This is based on (from RFC 8303) "Unreliably transfer a message, with congestion control" for SCTP, and "Unreliably transfer a message, without congestion control" for UDP(-Lite). The added "Unreliably transfer a message" leaves the choice of congestion control open, such that an application CAN simply say "Unreliably transfer a message" without having to care about the choice of congestion control (unless it wants to care, which comes at the cost of binding itself to either UDP(-Lite) or SCTP).

Cheers,
Michael

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 31 Aug 2018 12:41:57 -0500

Thanks, Robert, for the careful read, and thanks, Michael, for the quick
response. I have one thought, on Robert's last question.

On Fri, Aug 31, 2018 at 3:37 AM Michael Welzl <[email-masked]> wrote:

> Hi,
>
> Thank you very much for this careful review!  We just posted a revision (
> -07 ) that, we believe, addresses these comments.
>

...

> It isn't: different from this document, RFC 8303 does not make any changes
> or derive anything from the services that protocols offer - it just
> reflects what the protocol specifications say.
>
> In the minset document, there are only 3 items using the "ADDED"
> construct, and this is only meant to streamline the derivation a little.
> Take "Unreliably transfer a message", for example.
> This is based on (from RFC 8303) "Unreliably transfer a message, with
> congestion control" for SCTP, and "Unreliably transfer a message, without
> congestion control" for UDP(-Lite). The added "Unreliably transfer a
> message" leaves the choice of congestion control open, such that an
> application CAN simply say "Unreliably transfer a message" without having
> to care about the choice of congestion control (unless it wants to care,
> which comes at the cost of binding itself to either UDP(-Lite) or SCTP).
>

Michael, this explanation helps a lot, but since I happen to know that
Robert is out of town for the three-day weekend in the US, I'll guess on
his behalf that "ADDED" may not be the word you're looking for - at a
minimum, "transfer unreliably" in RFC 8303 being divided into "transfer
unreliably with congestion control" and "transfer unreliably without
congestion control" in this draft doesn't look like addition to me.

Is this more about "refactoring the protocol-independent definition in RFC
8303"?

But, whatever it is, if you two can figure out how to describe what's
happening, that will probably help figure you and Robert agree on an
understanding about how to handle his comment.

Spencer

---

From: Michael Welzl <[email-masked]>
Date: Fri, 31 Aug 2018 22:35:53 +0200

Hi Spencer,

See below:

> On Aug 31, 2018, at 7:41 PM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Thanks, Robert, for the careful read, and thanks, Michael, for the quick response. I have one thought, on Robert's last question.
> 
> On Fri, Aug 31, 2018 at 3:37 AM Michael Welzl <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
> > On 28 Aug 2018, at 23:38, Robert Sparks <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > Reviewer: Robert Sparks
> Michael, this explanation helps a lot, but since I happen to know that Robert is out of town for the three-day weekend in the US, I'll guess on his behalf that "ADDED" may not be the word you're looking for - at a minimum, "transfer unreliably" in RFC 8303 being divided into "transfer unreliably with congestion control" and "transfer unreliably without congestion control" in this draft doesn't look like addition to me. 
> 
> Is this more about "refactoring the protocol-independent definition in RFC 8303”? 

Yes, “refactoring” is exactly right - it’s not adding anything new. We could just as well have left this without the “ADDED” cases and then had more explanations in the “discussions” section (appendix A.3), but these are so minor that they don’t really merit a “discussion”, hence we felt that this way it’s shorter and clearer.

If that helps, I can rename “ADDED” into “REFACTORED”?

Cheers,
Michael

> But, whatever it is, if you two can figure out how to describe what's happening, that will probably help figure you and Robert agree on an understanding about how to handle his comment.
> 
> Spencer