Re: [Gen-art] [Taps] Genart last call review of draft-ietf-taps-minset-06

[Michael Welzl <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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.

Done;


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

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


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

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!


> Please check with the RFC Editor early about whether the [COBS]
> 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.


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

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


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

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