Re: [Taps] WGLC for draft-ietf-taps-arch (Jan 7-20, 2020)

[Gorry Fairhurst <[e-mail]>]

I have some minor editorial comments from a careful reading (see below).

Best wishses,

Gorry

(P.S. I'm an editor for this document and I do think the I-D is ready to 
proceed).

---

In Section 2:
/The Socket API/
The text uses /sockets/, but previously the text in 2.1 talks about the 
Socket API.
I didn’t see a problem here while we were working on the spec, but I 
think it world be better is section 2 explicating introduced the word 
/sockets/ and defined the Socket API as a definition of the sockets 
method. At least /sockets/ needs to be explained before it is used in 
Sections 2.1 2.2, 2.3, etc.
---
In Section 3.2
/handover or failover for a Connection/
- should this use a lower case letter ‘c’ for connection. This seems to 
be before the document defines a specific meaning for a TAPS Connection.
---
In Title of Figure 4:
Title: /The lifetime of a connection/
- I think this does warrant a capital letter ‘C’ for connection? or 
alternatively a re-wording to say something abstract, like: /The 
lifetime of a connection in the TAPS archicture/
---
In Section 4.1.1.
/A Preconnection object is a representation of a
potential connection./
- Does this warrant a capital letter ‘C’ for connection? (if not then I 
think it should say a /connection to be established? or similar).
---
In Section 4.1.2.
/ requirements around the Maximum Transmission Unit (MTU) or path
       MTU (PMTU),/
- The example is OK, but the words are not really correct. I don’t think 
general purpose apps need to know about the local MTU ever, they may 
care bout the PMTU - but really they care about the maximum packet size they
can send along a path. That’s an application-layer quantity, and isn’t 
related to the ultimate size of packet emitted by an interface. In 
writing the DPLPMTUD spec we have ben encouraged to make this difference 
more explicit, and I think TAPS should also not confuse interface 
limits, network limits and application limits. Packet Size anyway have 
little bearing on transports that perform message segmentation and are 
hugely important when they don’t.
My suggested text would be:
/ requirements around the largest packet that can be sent,/
---
In Section 4.2:
/ A single stack can be simple (a single transport
       protocol instance over IP), or complex (multiple application
       protocol streams going through a single security and transport
       protocol, over IP; or, a multi-path transport protocol over
       multiple transport sub-flows).
/
- This has become quite a long and complex sentence! I’d really prefer 
to use numbers or some way to highlight the two concepts of simple and 
complex. I don’t know what is best. Another possibility could be to make 
it even longer, but more clear:
/ A single stack can be either simple (a single transport
       protocol instance over IP), or it can be complex (multiple 
application
       protocol streams going through a single security and transport
       protocol, over IP; or, a multi-path transport protocol over
       multiple transport sub-flows).
---
In Section 4.2: Candidate Path:
The clause:
/, of which there can be several./
appears in bullet two for Candidate Protocol Stack:, but not for 
Candidate Path. I expect there be multiple candidate paths also in this 
case, can we add this?
---
In Section 4.2: Candidate Protocol Selection
/represents the act of choosing one or more sets of protocol stacks/
- why not capitilised /Protocol Stacks/?
---
In Section 4.2: Remote Endpoint Racing:
/that differ based on the specific
       representation of the Remote Endpoint, such as IP addresses
       resolved from a DNS hostname./
- do we have use of singular/plural correct here, or should this be more 
like:
/that differ based on the specific
       representation of the Remote Endpoint, such as a
       specific IP address that was
       resolved from a DNS hostname./
---
In Section 4.2.3: Protocol Stack Equivalence
/The Transport Services architecture defines a mechanism that allows
    applications to easily use different network paths and Protocol
    Stacks./
- Is this /use/ , i.e. are we talking about how to use these - which looks
like just multipath, or is this better as:
/The Transport Services architecture defines a mechanism that allows
    applications to easily communicate when there can be different 
network paths and Protocol Stacks./
---
In Section 4.2.4:
/   The interface to specify these groups MAY expose fine-grained tuning
    for which properties and cached state is allowed to be shared with
    other Connections. /
- I think it would be nice if this sentence actually was self-contained, 
since it contains a RFC2119 keyword. Perhaps we could say:
/   The interface to specify a Connection Group MAY expose fine-grained 
tuning for which properties and cached state is allowed to be shared 
with   other Connections. /
---


On 07/01/2020 15:50, Aaron Falk wrote:
>
> This is notice to open working group last call for “An Architecture 
> for Transport Services”, to conclude January 20, 2020. Please review 
> this document and send comments to the list, preferably with an 
> indication of whether it is ready for publication and, if not, what 
> your concerns are.
>
> https://www.ietf.org/id/draft-ietf-taps-arch-06
>
> --aaron
> TAPS wg co-chair
>
>
> _______________________________________________
> Taps mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/taps