Subject: Re: [Taps] Publication has been requested for draft-ietf-taps-minset-04

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 3 Aug 2018 17:45:29 -0500

Dear TAPsters,

I've completed my AD review for this document, and have two high-level
responses:

   - This looks good, and
   - I only have 8 pages of comments ...

Please look these over, and ask for explanations if you need them. When we
work through my comments, I'll request Last Call.

And thanks for your work to date.

Spencer

I'm looking at this text

   Because the considered
   transport protocols conjointly cover a wide range of transport
   features, there is reason to hope that the resulting set (and the
   reasoning that led to it) will also apply to many aspects of other
   transport protocols.

and wondering whether it's accurate to say "many aspects of other transport
protocols that may be in use today, or may be designed in the future"?

Part of my question is wrapped up in discussions about whether QUIC is a
one-off new transport protocol, or whether QUIC is the first example of a
new generation of transport protocols that are now worth designing because
we know how to deploy them.

This text

   For example, it does not help an
   application that talks to a library which offers its own
   communication interface if only the underlying Berkeley Sockets API
   is extended to offer "unordered message delivery", but the library
   only exposes an ordered bytestream.

read oddly to me - I think the first "only" could be removed, unless I'm
missing your point, but please take a look at that sentence for clarity.

This text

   This "minimal set" can be implemented one-sided over TCP (or UDP, if
   certain limitations are put in place).  This means that a sender-side
   transport system can talk to a standard TCP (or UDP) receiver, and a
   receiver-side transport system can talk to a standard TCP (or UDP)
   sender.

was a bit difficult for me to read, and seems to mix explaining what
"one-sided" means with the explanation that "one-sided" also applies to
UDP, if certain limitations are put in place. I wonder if it is accurate to
say

   This "minimal set" can be implemented "one-sided" over TCP.  This means
   that a sender-side transport system can talk to a standard TCP receiver,
   and a receiver-side transport system can talk to a standard TCP sender.
   If certain limitations are put in place, the "minimal set" can also be
   implemented "one-sided" over UDP.

Is "ungrouped communication" in

   For ungrouped connections, early configuration is necessary because
   it allows the transport system to know which protocols it should try
   to use.

a well-understood term? I can guess at the meaning, but I'd be guessing,
and RFCs 8095 and 8304 don't define or use either term.(Further down, I
also see "grouped communications", and I'm guessing what that means, too,
and Section 3.2.1 is even called "Connection groups", but doesn't clearly
define what that means)

I don't disagree with

  Note that this decision tree is not optimal for all cases.  For
   example, if an application wants to use "Specify checksum coverage
   used by the sender", which is only offered by UDP-Lite, and
   "Configure priority or weight for a scheduler", which is only offered
   by SCTP, the above decision tree will always choose UDP-Lite, making
   it impossible to use SCTP's schedulers with priorities between
   grouped connections.  The transport system must know which choice is
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   more important for the application in order to make the best
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   decision.  We caution implementers to be aware of the full set of
   trade-offs, for which we recommend consulting the list in
   Appendix A.2.1 when deciding how to initialize a connection.

but I'm not sure how a general-purpose transport system will know which
choice is more important for any arbitrary application. I see the Is this
advice transport system implementers can act on?

This isn't a big deal, but

  This also means that the active opening side is assumed to be the
   first side sending data.

seems really reasonable for the vast majority of (client-server)
applications, but I wonder if peer-to-peer applications will trip over a
problem here ("I open a connection to you, but you already had data queued
for me since we last connected and you sent it immediately" could be a
scenario for SMTP or DTN, I guess). But I'll let you folks think about that.

This is a nit, but

  o  A buffer limit (in bytes); when the sender has less then the
                                                         ^^^^ than

In this text,

  o  Reliability: this parameter is used to convey a choice of: fully
      reliable (!UDP), unreliable without congestion control, unreliable
      (!UDP), partially reliable (see [RFC3758] and [RFC7496] for
      details on how to specify partial reliability) (!UDP).

it took me some re-reading to figure out that "unreliable (!UDP)" meant
something besides JUST "unreliable" (because UDP is "unreliable without
congestion control"). Could this be clearer? I wonder about "unreliable
with congestion control (!UDP)", but I'm guessing that this is the
distinction you're making.

This text in 7.  Security Considerations

   Authentication, confidentiality protection, and integrity protection
   are identified as transport features by [RFC8095].  As currently
   deployed in the Internet, these features are generally provided by a
   protocol or layer on top of the transport protocol; no current full-
   featured standards-track transport protocol provides all of these
   transport features on its own.  Therefore, these transport features
   are not considered in this document, with the exception of native
   authentication capabilities of TCP and SCTP for which the security
   considerations in [RFC5925] and [RFC4895] apply.  The minimum
   security requirements for a transport system are discussed in a
   separate document [I-D.ietf-taps-transport-security].

confuses me, because I think at least two things are in play. First, I
think the point you're probably making is that the underlying transport
protocols remain unmodified, so the security considerations for each of
those protocols apply unchanged, and this document isn't doing anything to
create new security considerations. So, modulo SECDIR and SEC AD comments,
I think that's all you need to say.

Second, you guys are the experts, but I think a reference to
[I-D.ietf-taps-transport-security] isn't actually needed for this document,
because that document surveys security protocols, rather than specifying
minimum security requirements. That document might someday discuss the
minimum security requirements, in the way this document discusses the
minimum set of transport services, but at least in
https://tools.ietf.org/html/draft-ietf-taps-transport-security-02 that
document is much more comparable to RFCs 8095 and 8304 than to this
document.

In Informative References, I see

  [RFC7305]  Lear, E., Ed., "Report from the IAB Workshop on Internet
              Technology Adoption and Transition (ITAT)", RFC 7305,
              DOI 10.17487/RFC7305, July 2014,
              <https://www.rfc-editor.org/info/rfc7305>.

which is awesome (I wish more IETF people referred to IAB workshop
reports), but the only place I see it referred to is in A.3.1.  Sending
Messages, Receiving Bytes:

   For example, if an application requests to transfer fixed-size
   messages of 100 bytes with partial reliability, this needs the
   receiving application to be prepared to accept data in chunks of 100
   bytes.  If, then, some of these 100-byte messages are missing (e.g.,
   if SCTP with Configurable Reliability is used), this is the expected
   application behavior.  With TCP, no messages would be missing, but
   this is also correct for the application, and the possible
   retransmission delay is acceptable within the best effort service
   model [RFC7305].  Still, the receiving application would separate the
   byte stream into 100-byte chunks.

I was at that workshop, and it was pretty wide-ranging, so you might want
to provide a section number with this reference to give an inquiring reader
a chance of finding what you're referring to (I'm guessing the section
number is 3.5, but I'm guessing).

Just so you know - I did notice that Appendix A is two thirds of the page
count for this document, and I agree that the material belongs in an
appendix, and I think it's important for you to "show your work", in case
anyone ever needs to update the minimal set in the future. So, I support
what you're doing there.

You folks know what you actually did, but I'm hoping that

  2.  Reduction: a shorter list of transport features is derived from
       the categorization in the first step.  This removes all transport
       features that do not require application-specific knowledge or
       cannot be implemented with TCP or UDP.

was actually "cannot be implemented with TCP, SCTP, or UDP". Was that an
omission in this text, or do we need to chat?

This text,

Appendix A.  Deriving the minimal set

   We approach the construction of a minimal set of transport features
   in the following way:

   1.  Categorization: the superset of transport features from [RFC8303]
       is presented, and transport features are categorized for later
       reduction.
   2.  Reduction: a shorter list of transport features is derived from
       the categorization in the first step.  This removes all transport
       features that do not require application-specific knowledge or
       cannot be implemented with TCP or UDP.
   3.  Discussion: the resulting list shows a number of peculiarities
       that are discussed, to provide a basis for constructing the
       minimal set.
   4.  Construction: Based on the reduced set and the discussion of the
       transport features therein, a minimal set is constructed.

   The first three steps as well as the underlying rationale for
   constructing the minimal set are described in this appendix.  The
   minimal set itself is described in Section 3.

would have been clearer to me, if each step was labeled with the part of
the document where this work appears (so, step 1 would be labeled "Section
A.1", etc.), rather than providing the pointers at the end of the list. I
couldn't tell whether you meant that these were the steps you took in the
working group, or whether this was the organization of this appendix (plus
Section 3), until I got to the paragraph at the end.

Does

  Finally, some transport features are aggregated and/or slightly
   changed in the description below.  These transport features are
   marked as "ADDED".  The corresponding transport features are
   automatable, and they are listed immediately below the "ADDED"
   transport feature.

mean "aggregated and/or slightly change from [RFC8303]"?

I have the same question with

  In this description, transport services are presented following the
   nomenclature "CATEGORY.[SUBCATEGORY].SERVICENAME.PROTOCOL",
   equivalent to "pass 2" in [RFC8303].  We also sketch how some of the
   transport features can be implemented by a transport system.  For all
   transport features that are categorized as "functional" or
   "optimizing", and for which no matching TCP and/or UDP primitive
   exists in "pass 2" of [RFC8303], a brief discussion on how to
   implement them over TCP and/or UDP is included.

as I did above - is SCTP intentionally omitted from this paragraph?

(Somewhere about here, I started thinking about "automated" - I didn't see
a clear definition of this in the document. I think I understand what you
mean at a hand-waving level, but you might consider adding a definition
earlier in the document, so that's clearer without relying on context
clues.

I'm not going to list them off, but starting in Section A.1.1.  CONNECTION
Related Transport Features, I'm seeing a lot of analysis that includes some
transport protocols and doesn't include others. I'm comparing

  o  Indicate (and/or obtain upon completion) an Adaptation Layer via
      an adaptation code point
      Protocols: SCTP
      Functional because it allows to send extra data for the sake of
      identifying an adaptation layer, which by itself is application-
      specific.
      Implementation: via a parameter in CONNECT.SCTP.
      Implementation over TCP: not possible.
      Implementation over UDP: not possible.

which includes TCP, SCTP, and UDP, to something like

  o  Hand over a message to reliably transfer during connection
      establishment
      Protocols: SCTP
      Functional because this can only work if the message is limited in
      size, making it closely tied to properties of the data that an
      application sends or expects to receive.
      Implementation: via a parameter in CONNECT.SCTP.
      Implementation over UDP: not possible.

which does not mention TCP. There are a bunch of examples with this kind of
omission. Is it worth showing a complete set of "Implementation over
$Transport: not possible"s for each feature?

If this next is too much trouble, do the right thing, but I notice that

  o  Change timeout for aborting connection (using retransmit limit or
      time value)
      Protocols: TCP, SCTP
      Functional because this is closely related to potentially assumed
      reliable data delivery.
      Implementation: via CHANGE_TIMEOUT.TCP or CHANGE_TIMEOUT.SCTP.
      Implementation over UDP: not possible (UDP is unreliable and there
      is no connection timeout).

includes a parenthetical explanation of why a function is not possible to
implement on a specific transport protocol, but most "not possible" entries
don't have such an explanation. I mention this now, both because it might
reduce the number of conversations with reviewers and ADs that you have
starting with Last Call, and because you folks are likely the best equipped
to add these explanations now, rather than someone else trying to guess
what you were thinking later.

And, while I was thinking about that, I started thinking about entries like

     Implementation over UDP: Do nothing (this is irrelevant in case of
      UDP because there, reliable data delivery is not assumed).

and wondered how many of the "not possible" entries in the appendix might
be "do nothing". If you had parenthetical explanations for why something is
"not possible", or why an implementation might "do nothing", that would
probably sharpen the difference for the average reader …

And finally, at a high level, I don't understand why there are
"Implementation over $Protocol" lines so often that name $Protocols that
weren't listed in "Protocols:" at the beginning of each description. I have
several guesses about what that might mean, but I bet all of them are
wrong, so I have to ask.

To the details ...

Is this text

  o  Reliably transfer a message, with congestion control
      Protocols: SCTP
      Functional because this is closely tied to properties of the data
      that an application sends or expects to receive.
      Implementation: via SEND.SCTP.
      Implementation over TCP: via SEND.TCP.  With SEND.TCP, messages
      will not be identifiable by the receiver.
      Implementation over UDP: not possible.

saying

  o  Reliably transfer a message, with congestion control
...
      Implementation over TCP: via SEND.TCP.  With SEND.TCP, message
      boundaries will not be identifiable by the receiver, because TCP
      provides a stream service.
...

or something else?

I have the same question about the next one

  o  Unreliably transfer a message
      Protocols: SCTP, UDP(-Lite)
      Optimizing because only applications know about the time
      criticality of their communication, and reliably transfering a
      message is never incorrect for the receiver of a potentially
      unreliable data transfer, it is just slower.
      ADDED.  This differs from the 2 automatable transport features
      below in that it leaves the choice of congestion control open.
      Implementation: via SEND.SCTP or SEND.UDP(-Lite).
      Implementation over TCP: use SEND.TCP.  With SEND.TCP, messages
      will be sent reliably, and they will not be identifiable by the
      receiver.

("message boundaries"?)

In section A.2, I have the same "is SCTP out or in?" question, especially
around

  In the following list, we precede a transport feature with "T:" if an
   implementation over TCP is possible, "U:" if an implementation over
   UDP is possible, and "TU:" if an implementation over either TCP or
   UDP is possible.

I don't understand

A.2.1.  CONNECTION Related Transport Features

   ESTABLISHMENT:

   o  T: Hand over a message to reliably transfer (possibly multiple
      times) before connection establishment

Is this saying "possibly retransmitting multiple times to achieve
reliability", or something else?

---

From: Michael Welzl <[email-masked]>
Date: Mon, 20 Aug 2018 10:57:13 +0200

Hi Spencer!

Thank you so much for your detailed work and all these comments!
I'm commenting in line below, and marking my comments with "MW:".
I'm terminating my responses with a "--".

I'm attaching an update which incorporates the changes described in this email, but I'm delaying its submission until it's clear that this conversation has converged.

Cheers,
Michael

---

Dear TAPsters, 

I've completed my AD review for this document, and have two high-level responses: 
This looks good, and 
I only have 8 pages of comments ...
Please look these over, and ask for explanations if you need them. When we work through my comments, I'll request Last Call.

Spencer

I'm looking at this text

   Because the considered

and wondering whether it's accurate to say "many aspects of other transport protocols that may be in use today, or may be designed in the future"? 

Part of my question is wrapped up in discussions about whether QUIC is a one-off new transport protocol, or whether QUIC is the first example of a new generation of transport protocols that are now worth designing because we know how to deploy them.

MW: Done
--

This text

read oddly to me - I think the first "only" could be removed, unless I'm missing your point, but please take a look at that sentence for clarity. 

MW: Done (first "only" removed)
--

This text

was a bit difficult for me to read, and seems to mix explaining what "one-sided" means with the explanation that "one-sided" also applies to UDP, if certain limitations are put in place. I wonder if it is accurate to say 

MW: Done
--

a well-understood term? I can guess at the meaning, but I'd be guessing, and RFCs 8095 and 8304 don't define or use either term.(Further down, I also see "grouped communications", and I'm guessing what that means, too, and Section 3.2.1 is even called "Connection groups", but doesn't clearly define what that means)

MW: Good catch, thanks!  I added "Connection Group" to the terminology section; this text block also explains "grouped" and "ungrouped".
--

I don't disagree with 

but I'm not sure how a general-purpose transport system will know which choice is more important for any arbitrary application. I see the Is this advice transport system implementers can act on?

MW: Agreed; I removed this sentence.
--

seems really reasonable for the vast majority of (client-server) applications, but I wonder if peer-to-peer applications will trip over a problem here ("I open a connection to you, but you already had data queued for me since we last connected and you sent it immediately" could be a scenario for SMTP or DTN, I guess). But I'll let you folks think about that.

MW: I added the following paragraph at the beginning of section 3 (as the second para)
to address this issue:

   The arguments laid out in Appendix A.3 ("discussion") were
   used to make the final representation of the minimal set as short,
   simple and general as possible.  There may be situations where these
   arguments do not apply -- e.g., implementers may have specific
   reasons to expose multi-streaming as a visible functionality to
   applications, or the restrictive open / close semantics may be
   problematic under some circumstances.  In such cases, the
   representation in Appendix A.2 ("reduction") should be
   considered.
--   

This is a nit, but

MW: Done
--

In this text, 

it took me some re-reading to figure out that "unreliable (!UDP)" meant something besides JUST "unreliable" (because UDP is "unreliable without congestion control"). Could this be clearer? I wonder about "unreliable with congestion control (!UDP)", but I'm guessing that this is the distinction you're making.

MW: Good catch, thanks! And yes, that's the distinction. I changed this to the following, to be explicit about congestion control for all choices:

   o  Reliability: this parameter is used to convey a choice of: fully
      reliable with congestion control (!UDP), unreliable without
      congestion control, unreliable with congestion control (!UDP),
      partially reliable with congestion control (see [RFC3758] and
      [RFC7496] for details on how to specify partial reliability)
      (!UDP).
--

confuses me, because I think at least two things are in play. First, I think the point you're probably making is that the underlying transport protocols remain unmodified, so the security considerations for each of those protocols apply unchanged, and this document isn't doing anything to create new security considerations. So, modulo SECDIR and SEC AD comments, I think that's all you need to say. 

Second, you guys are the experts, but I think a reference to [I-D.ietf-taps-transport-security] isn't actually needed for this document, because that document surveys security protocols, rather than specifying minimum security requirements. That document might someday discuss the minimum security requirements, in the way this document discusses the minimum set of transport services, but at least in  https://tools.ietf.org/html/draft-ietf-taps-transport-security-02 that document is much more comparable to RFCs 8095 and 8304 than to this document. 

MW: I would agree about [I-D.ietf-taps-transport-security] if it didn't have section 5.
I believe section 5 in this document is an effort to do the same as minset does, here;
are you maybe asking for this section of [I-D.ietf-taps-transport-security] to use a
more authoritative tone?  Either way, as things stand now, the existence of
[I-D.ietf-taps-transport-security] is used as a justification to not include the
security related features of TCP and SCTP in the minimum set, and I think this
citation is necessary.

--

which is awesome (I wish more IETF people referred to IAB workshop reports), but the only place I see it referred to is in A.3.1.  Sending Messages, Receiving Bytes: 

I was at that workshop, and it was pretty wide-ranging, so you might want to provide a section number with this reference to give an inquiring reader a chance of finding what you're referring to (I'm guessing the section number is 3.5, but I'm guessing). 

MW: Done (and you guessed right).
--

Just so you know - I did notice that Appendix A is two thirds of the page count for this document, and I agree that the material belongs in an appendix, and I think it's important for you to "show your work", in case anyone ever needs to update the minimal set in the future. So, I support what you're doing there.

MW: Thanks :)
--

was actually "cannot be implemented with TCP, SCTP, or UDP". Was that an omission in this text, or do we need to chat? 

MW: the point was that TCP and UDP can't work as a fall-back in case e.g. SCTP isn't available. As stated at the beginning of the document, the minset can be implemented "one-sided" over TCP.  (and with some limitations, also UDP). For example: it's fine (within "best effort") to always send everything in order when an application allows out-of-order delivery - but there's simply no way to implement SCTP's out-of-band transmission of a number ("Indicate (and/or obtain upon completion) an Adaptation Layer via an adaptation code point") with TCP or UDP. If an application relies on that, TCP or UDP fall-backs become impossible. We were asked to avoid writing using the term "fall-back", for good reasons, but this particular sentence may have ended up being less clear as we simply replaced "fall-back" with "implemented with".

I changed the sentence as follows, is it better?

NEW:

This removes all transport features that do not require application-specific knowledge or would result in semantically incorrect behavior if they were implemented over TCP or UDP.
--

This text,

would have been clearer to me, if each step was labeled with the part of the document where this work appears (so, step 1 would be labeled "Section A.1", etc.), rather than providing the pointers at the end of the list. I couldn't tell whether you meant that these were the steps you took in the working group, or whether this was the organization of this appendix (plus Section 3), until I got to the paragraph at the end. 

MW: Done (and final paragraph removed)
--

Does 

MW: Yes, done. New sentence:
  Finally, some transport features are aggregated and/or slightly
   changed from [RFC8303] in the description below.
--

MW: Yes, for the same reason I gave above. I now prefaced the last sentence
with 'The "minimal set" derived in this document is meant to be implementable "one-sided" over TCP, and, with limitations, UDP. Hence, ...'
--

(Somewhere about here, I started thinking about "automated" - I didn't see a clear definition of this in the document. I think I understand what you mean at a hand-waving level, but you might consider adding a definition earlier in the document, so that's clearer without relying on context clues. 

MW: "automated" doesn't appear in the draft - I'm sure you mean "automatable".
It only appears in the appendix, where it's defined upon its first occurrence, in paragraph 5 of Appendix A.1, as follows: "The transport features of IETF transport protocols that do not require application-specific knowledge and could therefore be transparently utilized by a transport system are called "Automatable"."  - maybe you just missed this? I believe it's in the most suitable place. I now made this sentence a bit clearer now, by changing it into: "The transport features of IETF transport protocols that do not require application-specific knowledge and could therefore be utilized by a transport system on its own without involving the application are called "Automatable"."
--

I'm not going to list them off, but starting in Section A.1.1.  CONNECTION Related Transport Features, I'm seeing a lot of analysis that includes some transport protocols and doesn't include others. I'm comparing 

which does not mention TCP. There are a bunch of examples with this kind of omission. Is it worth showing a complete set of "Implementation over $Transport: not possible"s for each feature?

MW: Yes, done, for all the functional and optimizing features (as
explained in the introductory text of Appendix A.1.
--

includes a parenthetical explanation of why a function is not possible to implement on a specific transport protocol, but most "not possible" entries don't have such an explanation. I mention this now, both because it might reduce the number of conversations with reviewers and ADs that you have starting with Last Call, and because you folks are likely the best equipped to add these explanations now, rather than someone else trying to guess what you were thinking later. 

and wondered how many of the "not possible" entries in the appendix might be "do nothing". If you had parenthetical explanations for why something is "not possible", or why an implementation might "do nothing", that would probably sharpen the difference for the average reader …

MW: Done everywhere
--

And finally, at a high level, I don't understand why there are "Implementation over $Protocol" lines so often that name $Protocols that weren't listed in "Protocols:" at the beginning of each description. I have several guesses about what that might mean, but I bet all of them are wrong, so I have to ask. 

MW: maybe that's related to your confusion about the omission of SCTP, which I hope
I have addressed (as explained above). So that's answered by text that appears just before we list the transport features, which now reads:
"The "minimal set" derived in this document is meant to be implementable "one-sided" over TCP, and, with limitations, UDP. Hence, for all transport features that are categorized as "functional" or "optimizing", and for which no matching TCP and/or UDP primitive exists in "pass 2" of [RFC8303], a brief discussion on how to implement
them over TCP and/or UDP is included."
--

To the details ...

Is this text 

saying

  o  Reliably transfer a message, with congestion control
...
      Implementation over TCP: via SEND.TCP.  With SEND..TCP, message
      boundaries will not be identifiable by the receiver, because TCP 
      provides a stream service.
...

or something else?

MW: It says what you suspect, and I updated the text as you propose (although saying "byte stream" instead of just "stream").
--

("message boundaries"?)

MW: same here - I replaced "they" with "message boundaries" in the last sentence.
--

In section A.2, I have the same "is SCTP out or in?" question, especially around 

MW: I addressed this in the same way as the others above, by replacing it with:

"The "minimal set" derived in this document is meant to be implementable "one-sided"
over TCP, and, with limitations, UDP. In the following list, we therefore precede ..."
--                   

I don't understand 

   ESTABLISHMENT:

Is this saying "possibly retransmitting multiple times to achieve reliability", or something else?

MW: No, it means that a message is transferred reliably, and that it may arrive
multiple times; that's a long-winded way of saying "idempotence" for TFO.
I really don't want to change this text because it is a literal copy from
RFC 8303 - these text snippets tie these documents together.
And, even though I agree that the wording could be better, I think it's actually
clear because this is describing a service to the application.
Retransmissions to achieve reliability wouldn't be relevant to the application;
"transferring multiple times" can therefore only mean that the message really is
transferred from application A to application B multiple times, and this is what
can happen with TFO.

----

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 20 Aug 2018 08:52:00 -0500

Hi, Michael,

On Mon, Aug 20, 2018 at 3:57 AM Michael Welzl <[email-masked]> wrote:

> I'm attaching an update which incorporates the changes described in this
> email, but I'm delaying its submission until it's clear that this
> conversation has converged.
>

We're pretty darned converged. I have a couple of follow-ups below, but I
deleted everything that we're already good on (and thank you for those, in
advance).

My only significant question is on Section 7.

Spencer

> are you maybe asking for this section of
> [I-D.ietf-taps-transport-security] to use a

So, for what it's worth, I wouldn't have ever noticed that Section 5
of  [I-D.ietf-taps-transport-security] provided the equivalent of this
document, based on the Abstract and Introduction, which both talk about
surveys a lot more than minimum sets, but that's not your problem to solve
(and I'm not providing AD comments on documents that the working group is
still working on, because you guys are more likely to get stuff right than
I am, so no action required from anyone else).

But what is for you ...

At a minimum, I'd suggest qualifying the reference to
[I-D.ietf-taps-transport-security]  as "Section 5 of
[I-D.ietf-taps-transport-security] ", because I don't suppose that any
other reviewer is more likely to figure this out than I am, but ...

Quoting from the Introduction in -02 of  I-D.ietf-taps-transport-security,
what that draft is covering is

   This document provides a survey of commonly used or notable network
   security protocols, with a focus on how they interact and integrate
   with applications and transport protocols.  Its goal is to supplement
   efforts to define and catalog transport services [RFC8095] by
   describing the interfaces required to add security protocols.  It
   examines Transport Layer Security (TLS), Datagram Transport Layer
   Security (DTLS), Quick UDP Internet Connections with TLS (QUIC +
   TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with
   Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and
   WireGuard.

I may be confused about this, but I'm not seeing an obvious pattern match
between those protocols and "security related features of TCP and SCTP in
the minimum set". Is that document talking about what you hope it's talking
about?

Assuming so ... I'm probably struggling with the idea that there is no
minimal set of transport services that doesn't involve one of the protocols
listed in I-D.ietf-taps-transport-security or a near equivalent. That may
really be the right thing for the working group to say, but I wanted to
make sure that's the point that's being made, because that's what I think
you're saying, by including the reference
to I-D.ietf-taps-transport-security in your security considerations.

If the last sentence read

  The minimum {delete "security"}
   requirements for a {insert "secure"} secure transport system are
discussed in a
   separate document [I-D.ietf-taps-transport-security].

I'd agree with that statement, without anyone having to explain anything to
me!

But we'll be ready for Last Call on your next version, either way.

> MW: the point was that TCP and UDP can't work as a fall-back in case e.g.
> SCTP isn't available. As stated at the beginning of the document, the
> minset can be implemented "one-sided" over TCP.  (and with some
> limitations, also UDP). For example: it's fine (within "best effort") to
> always send everything in order when an application allows out-of-order
> delivery - but there's simply no way to implement SCTP's out-of-band
> transmission of a number ("Indicate (and/or obtain upon completion) an
> Adaptation Layer via an adaptation code point") with TCP or UDP. If an
> application relies on that, TCP or UDP fall-backs become impossible. We
> were asked to avoid writing using the term "fall-back", for good reasons,
> but this particular sentence may have ended up being less clear as we
> simply replaced "fall-back" with "implemented with".
>
> This removes all transport features that do not require
> application-specific knowledge or would result in semantically incorrect
> behavior if they were implemented over TCP or UDP.
>

I'm not entirely sure why, but this helps me a lot. Thanks for making the
suggestion. It works for me.

> It only appears in the appendix, where it's defined upon its first
> occurrence, in paragraph 5 of Appendix A.1, as follows: "The transport
> features of IETF transport protocols that do not require
> application-specific knowledge and could therefore be transparently
> utilized by a transport system are called "Automatable"."  - maybe you just
> missed this? I believe it's in the most suitable place. I now made this
> sentence a bit clearer now, by changing it into: "The transport features of
> IETF transport protocols that do not require application-specific knowledge
> and could therefore be utilized by a transport system on its own without
> involving the application are called "Automatable"."
>

Good work. Here, you guessed what *I* meant.

"Writing text is hard" - Spencer. Aaron has many examples of Spencer
proving this, dating back to us being co-chairs in PILC in the late 1990s.

But your suggested text (answers the comment I was trying to make, and)
works for me. Thanks for that.

> I have addressed (as explained above). So that's answered by text that
> appears just before we list the transport features, which now reads:
> "The "minimal set" derived in this document is meant to be implementable
> "one-sided" over TCP, and, with limitations, UDP. Hence, for all transport
> features that are categorized as "functional" or "optimizing", and for
> which no matching TCP and/or UDP primitive exists in "pass 2" of [RFC8303],
> a brief discussion on how to implement

Again, that's fixing my confusion above. Thanks for that.

---

From: Michael Welzl <[email-masked]>
Date: Mon, 20 Aug 2018 16:11:20 +0200

Hi,

Thanks again !

> On 20 Aug 2018, at 15:52, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Michael,
> 
> We're pretty darned converged. I have a couple of follow-ups below, but I deleted everything that we're already good on (and thank you for those, in advance).
> 

Great - it seems this is also the only one that calls for a change of the version that I now have. So, I'm removing the rest and just keeping this:

> So, for what it's worth, I wouldn't have ever noticed that Section 5 of  [I-D.ietf-taps-transport-security] provided the equivalent of this document, based on the Abstract and Introduction, which both talk about surveys a lot more than minimum sets, but that's not your problem to solve (and I'm not providing AD comments on documents that the working group is still working on, because you guys are more likely to get stuff right than I am, so no action required from anyone else). 
> 
> But what is for you ... 
> 
> At a minimum, I'd suggest qualifying the reference to  [I-D.ietf-taps-transport-security]  as "Section 5 of  [I-D.ietf-taps-transport-security] ", because I don't suppose that any other reviewer is more likely to figure this out than I am, but ... 
> 
> Quoting from the Introduction in -02 of  I-D.ietf-taps-transport-security, what that draft is covering is 
> 
> I may be confused about this, but I'm not seeing an obvious pattern match between those protocols and "security related features of TCP and SCTP in the minimum set". Is that document talking about what you hope it's talking about? 
> 
> Assuming so ... I'm probably struggling with the idea that there is no minimal set of transport services that doesn't involve one of the protocols listed in I-D.ietf-taps-transport-security or a near equivalent. That may really be the right thing for the working group to say, but I wanted to make sure that's the point that's being made, because that's what I think you're saying, by including the reference to I-D.ietf-taps-transport-security in your security considerations. 
> 
>    requirements for a {insert "secure"} secure transport system are discussed in a
> I'd agree with that statement, without anyone having to explain anything to me!

Can I just make this sentence replacement and be done with it?  I mean, it IS a very nice and clean solution, IMO...

Cheers,
Michael

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 20 Aug 2018 10:34:08 -0500

Hi, Michael,

On Mon, Aug 20, 2018 at 9:11 AM Michael Welzl <[email-masked]> wrote:

> > We're pretty darned converged. I have a couple of follow-ups below, but
> I deleted everything that we're already good on (and thank you for those,
> in advance).
> >
> Great - it seems this is also the only one that calls for a change of the
> version that I now have. So, I'm removing the rest and just keeping this:
>
>
> > --
> >
> > So, for what it's worth, I wouldn't have ever noticed that Section 5 of
> [I-D.ietf-taps-transport-security] provided the equivalent of this
> > Quoting from the Introduction in -02 of
> I-D.ietf-taps-transport-security, what that draft is covering is
> >
> > I may be confused about this, but I'm not seeing an obvious pattern
> match between those protocols and "security related features of TCP and
> SCTP in the minimum set". Is that document talking about what you hope it's
> talking about?
> >
> you're saying, by including the reference to
> I-D.ietf-taps-transport-security in your security considerations.
> >
> Can I just make this sentence replacement and be done with it?  I mean, it
> IS a very nice and clean solution, IMO...
>

So, here's what I'm thinking ...

I'm not sure if you saw my suggestion about qualifying the reference to
[I-D.ietf-taps-transport-security]  as "Section 5 of
[I-D.ietf-taps-transport-security]", but assuming that we're good on that
one ...

Tl;dr = Spencer wants to make sure that his suggested text isn't overriding
what the working group is thinking, but since the working group has been
copied on this e-mail thread, it's probably fine to submit an updated draft
and start Last Call.

For anyone curious ...

What I was reading into the original text was roughly

minimal transport service set = this document + Section 5 of
[I-D.ietf-taps-transport-security]

The text I offered, is roughly

minimal transport service set = this document
minimal secure transport service set = this document + Section 5 of
[I-D.ietf-taps-transport-security]

We explicitly chartered TAPS for transport services in 2014, and didn't add
responsibility for transport security until February of this year. It seems
to me that publishing a minimal transport service set has value now, and
publishing a minimal transport service set has additional value later.

If that's the intention, my suggested text would work.

If the intention was to say that the minimal transport service set requires
transport security, the original text was correct and Spencer just missed a
turn someplace, but a reasonable review question would be "if the minimal
transport service set requires transport security, why publish the insecure
part now?"

Either answer is OK with me, but what's not OK is for me as AD, is tell the
working group "I'm sure you meant THIS", in a way that doesn't invite
"Spencer, we meant exactly THIS, and your comment explains why we don't
have ADs write all the documents" :-)

And thanks for your quick responses. That's always helpful.

Spencer

---

From: Michael Welzl <[email-masked]>
Date: Tue, 21 Aug 2018 08:48:26 +0200

Hi,

In line below:

> On 20 Aug 2018, at 17:34, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Michael,
> 
> I'm not sure if you saw my suggestion about qualifying the reference to  [I-D.ietf-taps-transport-security]  as "Section 5 of  [I-D.ietf-taps-transport-security]", but assuming that we're good on that one ... 

I saw it and agree. I thought that it's not necessary for the specific sentence that you ended up proposing, but now I agree that even in this sentence it's better. I'll update it to include "Section 5 of" just ahead of this reference.

> Tl;dr = Spencer wants to make sure that his suggested text isn't overriding what the working group is thinking, but since the working group has been copied on this e-mail thread, it's probably fine to submit an updated draft and start Last Call. 

I'll submit the update with the small correction above after this email.

> minimal transport service set = this document + Section 5 of  [I-D.ietf-taps-transport-security] 
> 
> minimal secure transport service set = this document + Section 5 of  [I-D.ietf-taps-transport-security] 

I, for one, understood that and think that this is a fine solution.

Cheers,
Michael

> We explicitly chartered TAPS for transport services in 2014, and didn't add responsibility for transport security until February of this year. It seems to me that publishing a minimal transport service set has value now, and publishing a minimal transport service set has additional value later. 
> 
> If the intention was to say that the minimal transport service set requires transport security, the original text was correct and Spencer just missed a turn someplace, but a reasonable review question would be "if the minimal transport service set requires transport security, why publish the insecure part now?"
> 
> Either answer is OK with me, but what's not OK is for me as AD, is tell the working group "I'm sure you meant THIS", in a way that doesn't invite "Spencer, we meant exactly THIS, and your comment explains why we don't have ADs write all the documents" :-)  
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: "Aaron Falk" <[email-masked]>
Date: Tue, 21 Aug 2018 14:44:02 -0400

Glad to see rapid convergence on these comments.  My turn for a nit:

On 21 Aug 2018, at 2:48, Michael Welzl wrote:

> I'm not sure if you saw my suggestion about qualifying the reference 
> to  [I-D.ietf-taps-transport-security]  as "Section 5 of  
> [I-D.ietf-taps-transport-security]", but assuming that we're good on 
> that one ...
>
>
> I saw it and agree. I thought that it's not necessary for the specific 
> sentence that you ended up proposing, but now I agree that even in 
> this sentence it's better. I'll update it to include "Section 5 of" 
> just ahead of this reference.

The likelihood of an ID having it's sections renumbered is high enough 
that I don't think we should embed the section number in an RFC.  I'd 
suggest using the section name as well in case one or both changes the 
reader is likely to make the connection:  "Section 5 on Security 
Features and Transport Dependencies of ..."

--aaron

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 21 Aug 2018 15:27:44 -0500

Hi, Aaron,

On Tue, Aug 21, 2018 at 1:44 PM Aaron Falk <[email-masked]> wrote:

> sentence that you ended up proposing, but now I agree that even in this
> sentence it's better. I'll update it to include "Section 5 of" just ahead
> of this reference.
>
> reader is likely to make the connection: "Section 5 on Security Features
> and Transport Dependencies of ..."
>

I totally agree on this one. I only suggested adding the section number
because I couldn't find any mention of the minimum set in the abstract or
Introduction for [I-D.ietf-taps-transport-security], so a reader would have
to scroll through the Table of Contents to notice it. I had a nagging
feeling when I made the suggestion - thanks for fixing it.

If I might make one other observation, there are a few places visible in
https://tools.ietf.org/rfcdiff?url2=draft-ietf-taps-minset-05.txt for
Section A (I think A.1) where there seems to be a missing newline between
"Implementation over TCP:" and "Implementation over UDP:" - I saw more than
one occurrence, but I think the first one to check is under "Specify
checksum coverage used by the sender" for "Protocols: UDP-Lite". I had
thought to make that observation as a response to the Last Call
announcement, but Aaron sent his suggested change before I did that.

I'll let the shepherds/chairs decide when to submit a revision that fixes
these nits, but if you folks wanted to do that at the beginning of Last
Call, I'd be fine with that, so review teams won't all make that
suggestion. :-)

Spencer

---

From: Michael Welzl <[email-masked]>
Date: Wed, 22 Aug 2018 14:49:26 +0200

Hi,

> On 21 Aug 2018, at 22:27, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Aaron, 
> 
> The likelihood of an ID having it's sections renumbered is high enough that I don't think we should embed the section number in an RFC. I'd suggest using the section name as well in case one or both changes the reader is likely to make the connection: "Section 5 on Security Features and Transport Dependencies of ..."
> 
> 
> I totally agree on this one. I only suggested adding the section number because I couldn't find any mention of the minimum set in the abstract or Introduction for [I-D.ietf-taps-transport-security], so a reader would have to scroll through the Table of Contents to notice it. I had a nagging feeling when I made the suggestion - thanks for fixing it.

Done (in my local copy). Actually I thought of the same thing but wasn't sure for one reason or another... I should have just gone for it!

> If I might make one other observation, there are a few places visible in https://tools.ietf.org/rfcdiff?url2=draft-ietf-taps-minset-05.txt for Section A (I think A.1) where there seems to be a missing newline between "Implementation over TCP:" and "Implementation over UDP:" - I saw more than one occurrence, but I think the first one to check is under "Specify checksum coverage used by the sender" for "Protocols: UDP-Lite". I had thought to make that observation as a response to the Last Call announcement, but Aaron sent his suggested change before I did that.

I don't see this; "Implementation over UDP" seems to start on a new line everywhere. What I do see is that an extra empty line has unintentionally ended up in there in a few places. Do you mean that there SHOULD be an extra empty line?  I'd find that a bit odd, unless I add empty lines all over the place. E.g., consider the following block:

***
   o  Indicate (and/or obtain upon completion) an Adaptation Layer via
      an adaptation code point
      Protocols: SCTP
      Functional because it allows to send extra data for the sake of
      identifying an adaptation layer, which by itself is application-
      specific.
      Implementation: via a parameter in CONNECT.SCTP.
      Implementation over TCP: not possible (TCP does not offer this
      functionality).
      Implementation over UDP: not possible (UDP does not offer this
      functionality).
***

If I add an empty line above "Implementation over UDP", then I should probably also add one above "Implementation over TCP", above "Implementation", above the line beginning with "Functional" and above "Protocols: SCTP", right?  But then this gets huge...

My tendency would be to remove the extra lines.

HOWEVER: it seems that the diff you're pointing at is misleading  :(   I just checked against my local .txt file: in one case, the extra line was added in the diff because, in fact, there was a new page (new pages with headers are not shown in the diff), and in another, I don't understand where the extra line in the diff comes from - my .txt doesn't have it.

Either way, my proposal would be to go for the style of the text block I copied above. Is that ok?

> I'll let the shepherds/chairs decide when to submit a revision that fixes these nits, but if you folks wanted to do that at the beginning of Last Call, I'd be fine with that, so review teams won't all make that suggestion. :-)

I'll do it as soon as I know what to do with line feeds!

Cheers,
Michael

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 22 Aug 2018 08:20:36 -0500

Hi, Michael,
On Wed, Aug 22, 2018 at 7:49 AM Michael Welzl <[email-masked]> wrote:

> Done (in my local copy). Actually I thought of the same thing but wasn't
> sure for one reason or another... I should have just gone for it!
>
>
> I don't see this; "Implementation over UDP" seems to start on a new line
> everywhere. What I do see is that an extra empty line has unintentionally
> ended up in there in a few places. Do you mean that there SHOULD be an
> extra empty line?

I'm not sure what I'm seeing is what you're seeing. Let's talk before
asking you to type :-)

I'm looking at the bottom of page 29, top of page 30, in the HTML version.
That's for

   o  Specify checksum coverage used by the sender
      Protocols: UDP-Lite

What I'm seeing in HTML for this section, is

   o  Specify checksum coverage used by the sender
      Protocols: UDP-Lite
      Functional because application-specific knowledge is necessary to
      decide for which parts of the data it can be acceptable to lose
      data integrity.

Welzl & Gjessing        Expires February 21, 2019              [Page 29]

Internet-Draft         Minimal Transport Services            August 2018

      Implementation: via SET_CHECKSUM_COVERAGE.UDP-Lite.
      Implementation over TCP: do nothing (TCP does not offer to limit
      the checksum length, but transmitting data with an intact checksum
      will not yield a semantically wrong result).  Implementation over

So, I'm not seeing a newline before "Implementation" here.

      UDP: if checksum coverage is set to cover payload data, do
      nothing.  Else, either do nothing (transmitting data with an
      intact checksum will not yield a semantically wrong result), or
      use the transport feature "Disable checksum when sending".

But since I always use the HTML version, and that's not even the canonical
version, I checked the same thing in the TXT version, but it also looks
like

   o  Specify checksum coverage used by the sender
      Protocols: UDP-Lite
      Functional because application-specific knowledge is necessary to
      decide for which parts of the data it can be acceptable to lose
      data integrity.

Welzl & Gjessing        Expires February 21, 2019              [Page 29]
Internet-Draft         Minimal Transport Services            August 2018

      Implementation: via SET_CHECKSUM_COVERAGE.UDP-Lite.
      Implementation over TCP: do nothing (TCP does not offer to limit
      the checksum length, but transmitting data with an intact checksum
      will not yield a semantically wrong result).  Implementation over

and I'm not seeing a newline before "Implementation" here, either.

      UDP: if checksum coverage is set to cover payload data, do
      nothing.  Else, either do nothing (transmitting data with an
      intact checksum will not yield a semantically wrong result), or
      use the transport feature "Disable checksum when sending".

So I should probably ask what format you're looking at, if you're not
seeing what I'm seeing?

Thanks for chasing this nit with me, by the way.

Spencer

> I'd find that a bit odd, unless I add empty lines all over the place.
> E.g., consider the following block:
>
> ***
> If I add an empty line above "Implementation over UDP", then I should
> probably also add one above "Implementation over TCP", above
> "Implementation", above the line beginning with "Functional" and above
> "Protocols: SCTP", right?  But then this gets huge...
>
> HOWEVER: it seems that the diff you're pointing at is misleading  :(   I
> just checked against my local .txt file: in one case, the extra line was
> added in the diff because, in fact, there was a new page (new pages with
> headers are not shown in the diff), and in another, I don't understand
> where the extra line in the diff comes from - my .txt doesn't have it.
>
> > I'll let the shepherds/chairs decide when to submit a revision that
> fixes these nits, but if you folks wanted to do that at the beginning of
> Last Call, I'd be fine with that, so review teams won't all make that
> suggestion. :-)
>

---

From: Michael Welzl <[email-masked]>
Date: Wed, 22 Aug 2018 15:50:38 +0200

> On 22 Aug 2018, at 15:20, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Michael, 
> > I'm not sure if you saw my suggestion about qualifying the reference to [I-D.ietf-taps-transport-security] as "Section 5 of [I-D.ietf-taps-transport-security]", but assuming that we're good on that one ....
> > 
> > 
> I don't see this; "Implementation over UDP" seems to start on a new line everywhere. What I do see is that an extra empty line has unintentionally ended up in there in a few places. Do you mean that there SHOULD be an extra empty line? 
> 
> I'm not sure what I'm seeing is what you're seeing. Let's talk before asking you to type :-)
> 
> I'm looking at the bottom of page 29, top of page 30, in the HTML version. That's for 
> 
> But since I always use the HTML version, and that's not even the canonical version, I checked the same thing in the TXT version, but it also looks like 
> 
> So I should probably ask what format you're looking at, if you're not seeing what I'm seeing?

When I talked about extra empty lines, I was looking at exactly what my browser gives me when following the URL that you included:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-taps-minset-05.txt
... which is a side-by-side diff.

But now I found it!  The problem was that I did a text search for "implementation over UDP", which failed to show me these cases due to the line break *within* the phrase  :-)

Oh my   :)

Now I did a search for "UDP:" instead, and with that, I only find precisely the two cases that you quote above.  So I think that's it - I'll fix and submit.

> Thanks for chasing this nit with me, by the way.

No, thanks to *you* for finding and telling !

Cheers,
Michael

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 22 Aug 2018 09:29:27 -0500

Hi, Michael,

On Wed, Aug 22, 2018 at 8:50 AM Michael Welzl <[email-masked]> wrote:

> one ....
> > > I totally agree on this one. I only suggested adding the section
> number because I couldn't find any mention of the minimum set in the
> abstract or Introduction for [I-D.ietf-taps-transport-security], so a
> reader would have to scroll through the Table of Contents to notice it. I
> had a nagging feeling when I made the suggestion - thanks for fixing it.
> >
> > > If I might make one other observation, there are a few places visible
> in https://tools.ietf.org/rfcdiff?url2=draft-ietf-taps-minset-05.txt for
> > But since I always use the HTML version, and that's not even the
> canonical version, I checked the same thing in the TXT version, but it also
> looks like
> >
> When I talked about extra empty lines, I was looking at exactly what my
> browser gives me when following the URL that you included:
> But now I found it!  The problem was that I did a text search for
> "implementation over UDP", which failed to show me these cases due to the
> line break *within* the phrase  :-)
>
> Oh my   :)
>
> Now I did a search for "UDP:" instead, and with that, I only find
> precisely the two cases that you quote above.  So I think that's it - I'll
> fix and submit.
>

Excellent. We're already in Last Call, so no action needed from me, I think.

> No, thanks to *you* for finding and telling !

I'm glad I could help.

Spencer