Hi Gorry, Thanks for the comments! I've created a pull request here: https://github.com/ietf-tapswg/api-drafts/pull/411
I am including comments inline to respond to the individual points. Best, Tommy > On Jan 11, 2020, at 3:18 AM, Gorry Fairhurst <[email protected]> wrote: > > 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. > The "BSD Socket" interface and "socket" in general is described in the first paragraph of the Introduction. That seems to introduce the notion early enough. Let me know if you don't feel that is sufficient. > --- > 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. > Made this lowercase. > --- > 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/ > Made this "The lifetime of a Connection object", to match the other text. > --- > 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). > Used "Connection" here and in other places in this paragraph. > --- > 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,/ > Used "requirements around the largest Message 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). > Used your suggested text! > --- > 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/? > Capitalized as suggested. > --- > 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./ > Used the suggested text. > --- > 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./ > I'm not sure if "communicate when there can be different network paths" is clearer here. Would receives the communication? I think it is indeed "use": not just multipath, but in terms of sending packets for racing, etc. > --- > 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. / > --- > Fixed as suggested! > > > 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 >> <https://www.ietf.org/id/draft-ietf-taps-arch-06> >> --aaron >> TAPS wg co-chair >> >> >> >> _______________________________________________ >> Taps mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/taps >> <https://www.ietf.org/mailman/listinfo/taps> > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
