Subject: [Taps] IETF100 meeting agenda uploaded

From: Zaheduzzaman Sarker <[email-masked]>
Date: Sat, 4 Nov 2017 22:14:21 +0000

Hello WG,

The agenda for IETF100 has been uploaded https://datatracker.ietf.org/meeting/100/materials/agenda-100-taps/

Any comments?

BR

Zahed

===============================================================================
ANM ZAHEDUZZAMAN SARKER
Ericsson Research

Ericsson
Laboratoriegränd 11
97128 Luleå, Sweden
Phone +46 10 717 37 43
Mobile +46 76 115 37 43
Office +46 76 115 37 43
Fax +46 920 996 21
[email-masked]
www.ericsson.com<http://www.ericsson.com/>
===============================================================================

---

From: Michael Welzl <[email-masked]>
Date: Sun, 5 Nov 2017 08:49:52 +0100

Hi,

It seems to me that this charter contains three items that relate to the API:
1) draft-trammell-taps-post-sockets-03
2) draft-tiesel-taps-socketintents-01
3) draft-fairhurst-taps-neat-00

...which are currently charter items 3, 4 and 6 (an unrelated - no less important! because it describes the implementation! - item takes position 5). Moreover, for the first one, it says "expected adoption call targeting charter item 3”.

I think it would make more sense to first hear all three proposals and then discuss the possible adoption of one of them?

Cheers,
Michael

> On Nov 4, 2017, at 11:14 PM, Zaheduzzaman Sarker <[email-masked]> wrote:
> 
> Hello WG,
>  
> The agenda for IETF100 has been uploaded https://datatracker.ietf.org/meeting/100/materials/agenda-100-taps/ <https://datatracker.ietf.org/meeting/100/materials/agenda-100-taps/>
>  
> Any comments?
>  
> BR
>  
> Zahed
>  
> [email-masked] <mailto:[email-masked]>
> www.ericsson.com <http://www.ericsson.com/>
> _______________________________________________
> Taps mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/taps <https://www.ietf.org/mailman/listinfo/taps>

---

From: Tommy Pauly <[email-masked]>
Date: Sun, 05 Nov 2017 12:44:14 -0800

One quick thought on this: I think that the charter item 3 (the recommended mechanisms for deploying a TAPS system) can and should certainly include multiple documents. These documents we'll be talking about are in no way mutually exclusive, so I don't think we should be thinking of it as "hear all three and choose one of them". We may well want to adopt all of them, or some other combination of documents, to cover item 3. Specifically, from the charter item, we see that the idea is plural: "Specify experimental support mechanisms ...".

One proposal for approaching the charter item is to ultimately have documents like this:
- A top-level API document (like post sockets, as informed by the specific implementation example that Gorry gives in the NEAT document)
- A document on application preferences interacting with system policy (like the socket intents draft)
- A document on racing connection establishment (like draft-pauly-taps-guidelines-01 + draft-grinnemo-taps-he-03)

These different aspects don't necessarily make sense to combine, and have different audiences for implementers.

The agenda order could be modified, but since there doesn't need to be any mutual exclusivity between the items, the current order should be fine too.

Thanks,
Tommy

> On Nov 5, 2017, at 12:49 AM, Michael Welzl <[email-masked]> wrote:
> 
> Hi,
> 
>> On Nov 4, 2017, at 11:14 PM, Zaheduzzaman Sarker <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hello WG,
>>  
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Michael Welzl <[email-masked]>
Date: Sun, 5 Nov 2017 21:57:57 +0100

Hi,

I almost agree  :-)    I agree that there should be several documents, along the lines of what you write - but I do think there should be only one API…

Cheers,
Michael

> On Nov 5, 2017, at 9:44 PM, Tommy Pauly <[email-masked]> wrote:
> 
>> On Nov 5, 2017, at 12:49 AM, Michael Welzl <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi,
>>

---

From: Tommy Pauly <[email-masked]>
Date: Sun, 05 Nov 2017 13:21:10 -0800

Indeed! But, as far as I can tell, drafts like draft-tiesel-taps-socketintents-01 are not trying to propose a top-level API, but rather an aspect of the API.

Even when we discuss the draft for what I'm referring to as the "top-level API", I think we need to (in the spirit of the charter) not be specifying a specific set of language-specific API calls, or a specific framework, but the shape that instances of an API should take. My goal coming out of TAPS would be to change the approach implementers take when designing transport APIs, to make sure that the resulting APIs not only support the flexibility TAPS was designed for, but also can be standard and cross-compatible across all operating systems. Thus, we want the documents to encompass API principles and concepts, but leave the semantics flexible and as an exercise to the reader. Perhaps in the examples, even give several options in different language styles, and show how code can be easily translated between the approaches.

To be specific, I would imagine that whatever API examples we have in the various documents we write will not necessarily be part of any specific implementation. Rather, various implementations will conform to the principles and patterns of the API description. Apple's transport APIs would match it, NEAT's APIs would match it, Android APIs would match it, Windows APIs would match it, etc, etc.

Thanks,
Tommy

> On Nov 5, 2017, at 12:57 PM, Michael Welzl <[email-masked]> wrote:
> 
> Hi,
> 
>> On Nov 5, 2017, at 9:44 PM, Tommy Pauly <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Michael Welzl <[email-masked]>
Date: Sun, 5 Nov 2017 23:42:24 +0100

Hi,

> On Nov 5, 2017, at 10:21 PM, Tommy Pauly <[email-masked]> wrote:
> 

I agree with everything you say here. About draft-tiesel-taps-socketintents-01, okay - I wasn’t so sure where this is heading … but both draft-trammell-taps-post-sockets-03 and draft-fairhurst-taps-neat-00.txt describe an abstract API.

> Even when we discuss the draft for what I'm referring to as the "top-level API", I think we need to (in the spirit of the charter) not be specifying a specific set of language-specific API calls, o…

Yes - and these principles (also in the spirit of the charter) should be based on the analysis of existing transports and the definition of a minimal set of services that TAPS systems should support. I made an effort to be reasonable in the minimum set that we’ve derived:
- avoid getting stuck in a corner (being tied to only one protocol)
- allow for one-sided deployment, with a fall-back to TCP or UDP ( (D)TLS TBD - I think that was a very reasonable request)
- not miss out on functionality that can never be offered unless it’s put in the API

> To be specific, I would imagine that whatever API examples we have in the various documents we write will not necessarily be part of any specific implementation. Rather, various implementations wil…

I agree with all that.

To be clear, this is not me arguing for or against one specific API. I’m only keen on ensuring that the result matches the principles I used for the minset, as listed above (or, if folks disagree with them, we should discuss them).  I only want TAPS to be implementable, useful and deployable (where I think that allowing one-sided deployment is a big deal).

Cheers,
Michael

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 06 Nov 2017 08:37:22 +0000

It seems to me there are many ideas that could come forward if the work 
in TAPS progresses.

To me the three IDs we currently have are quite different - and they 
seem to have different design goals. I suggest if the group is thinking 
of accepting work against the third item in the charter that it would be 
good to spend a little time to look at these proposals and then to 
explore how the various proposals fit with the "subset of Transport 
Services" resulting from the second charter item.

Best wishes,

Gorry

On 05/11/2017, 07:49, Michael Welzl wrote:
> ...which are currently charter items 3, 4 and 6 (an unrelated - no 
> less important! because it describes the implementation! - item takes 
> position 5). Moreover, for the first one, it says "expected adoption 
> call targeting charter item 3”.
>
> I think it would make more sense to first hear all three proposals and 
> then discuss the possible adoption of one of them?
>
> Cheers,
> Michael
>
>
>> On Nov 4, 2017, at 11:14 PM, Zaheduzzaman Sarker 
>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hello WG,
>> The agenda for IETF100 has been 
>> uploaded_https://datatracker.ietf.org/meeting/100/materials/agenda-100-taps/_
>> Any comments?
>> BR
>> Zahed
>> *===============================================================================*
>> *ANM ZAHEDUZZAMAN SARKER
>> *Ericsson Research
>>
>> *Ericsson
>> *Laboratoriegränd 11
>> 97128 Luleå, Sweden
>> Phone +46 10 717 37 43
>> Mobile +46 76 115 37 43
>> Office +46 76 115 37 43
>> Fax +46 920 996 21
>> <mailto:[email-masked]>
>> _www.ericsson.com_ <http://www.ericsson.com/>

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Tue, 7 Nov 2017 09:04:14 +0000

Hi,

Thanks for your comments and thoughts, it is a good discussion going on here. I think we can continue the discussion at the meeting as we have more time according to the current agenda time. The proposal is to have a separate slot at the IETF100 meeting to discuss how to address the charter item 3 – multiple documents, multiple implementations etc.

Based on the discussion here I will keep the presentation order as it is. The initial thinking behind the order was that Tommy would talk about racing condition and fall-backs and Gorry would tell about what policies and API options NEAT took to address the similar aspects. Hence, they kind of fit together.

Updated agenda here https://datatracker.ietf.org/meeting/100/materials/agenda-100-taps/ 

BR

Zahed 

On 2017-11-06, 09:38, "Gorry Fairhurst" <[email-masked]> wrote:

    
    Best wishes,
    
    Gorry