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

From: "Aaron Falk" <[email-masked]>
Date: Tue, 07 Jan 2020 10:50:55 -0500

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 11 Jan 2020 11:18:44 +0000

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:
> indication of whether it is ready for publication and, if not, what 
> your concerns are.
>
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 14 Jan 2020 13:24:40 -0800

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-masked]> wrote:
> 
> (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.
> - 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.
> - 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.

> - 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.
> - 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.
Used "requirements around the largest Message that can be sent,"
> - 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:
>       protocol instance over IP), or it can be complex (multiple application
Used your suggested text!
> 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?
> ---
Capitalized as suggested.

> - do we have use of singular/plural correct here, or should this be more like:
Used the suggested text.
>    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.
> - 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!
>> 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
>> 
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/taps <https://www.ietf.org/mailman/listinfo/taps>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 15 Jan 2020 15:23:21 +0000

Hi all,

I reviewed the draft again and think it‘s ready for publication! Thanks everybody for all the work and this well-written document!

As ones does when reviewing a doc, I did open a few small issues on github. I think most of them are nothing big and could end up in adding a sentence here and there or not.

However, I think there is one thing we need to decide before we finally move on and that’s the always exciting question about use of normative language. I think currently we don’t use normatively language very consistently. So either we make a pass and add some more MUSTs, SHOULDs, and MAYs or we decide to not use normative language at all. I also opened an issue for that, so you can also comment there is you prefer!

Mirja

From: Taps <[email-masked]> on behalf of Aaron Falk <[email-masked]>
Date: Tuesday, 7. January 2020 at 16:51
To: taps WG <[email-masked]>
Cc: Magnus Westerlund <[email-masked]>, Zaheduzzaman Sarker <[email-masked]>
Subject: [Taps] WGLC for draft-ietf-taps-arch (Jan 7-20, 2020)

--aaron
TAPS wg co-chair

---

From: Theresa Enghardt <[email-masked]>
Date: Mon, 20 Jan 2020 13:28:17 +0100

Hi all,

I reviewed the document again and I think it's ready for publication
once we have the normative language sorted out and once the remaining
minor editorial issues have been fixed, see Github.

Best,
Theresa

---

From: "Aaron Falk" <[email-masked]>
Date: Mon, 20 Jan 2020 10:43:36 -0500

Last call concludes today.  Please send recommendations to publish or 
comments requiring revision ASAP.

--aaron

On 7 Jan 2020, at 10:50, Aaron Falk wrote:

> for Transport Services”, to conclude January 20, 2020.  Please 
> review this document and send comments to the list, preferably with an

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 20 Jan 2020 09:41:00 -0800

Thanks for your review Theresa! We’ll incorporate your GitHub comments soon. As editor, I think this document should be ready to publish with these minor changes added in. 

Thanks,
Tommy

> On Jan 20, 2020, at 4:28 AM, Theresa Enghardt <[email-masked]> wrote:
> 
> 
> Hi all,
> 
> I reviewed the document again and I think it's ready for publication once we have the normative language sorted out and once the remaining minor editorial issues have been fixed, see Github.
> 
> Best,
> Theresa
> 
>