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
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
