Re: [Taps] Prague agenda planning

I don’t have a preference.  I was assuming

1. frame the topic
2. look at a few applications / use cases
3. discuss / wrestle / free-for-all

but I’m also ok with

1. example 1, 2, 3
2. abstract / summarize some questions
3. discuss / wrestle / free-for-all

I’ll leave whoever wants to take the framing talk to tell me where 
they want it.  Sounds like it’ll be Brian and have it after socket 
intents & HE.  Yes?

--aaron

On 6 Jul 2017, at 11:51, Brian Trammell (IETF) wrote:

> As did I. But if we want to separate the discussions more explicitly, 
> I'm happy to throw together five minutes of slides to frame the 
> discussion in a proposal-neutral way; I think we'll need at least 
> twenty for the discussion though.
>
> Cheers,
>
> Brian
>
>> On 06 Jul 2017, at 17:20, Mirja Kühlewind 
>> <mirja.kuehlewind@tik.ee.ethz.ch> wrote:
>>
>> I believe the idea was actually to have the policy after the socket 
>> intents talk; maybe even after HE?
>>
>> Mirja
>>
>>
>>> Am 06.07.2017 um 16:56 schrieb Aaron Falk <aaron.falk@gmail.com>:
>>>
>>> Updated. Still need a policy framing preso (#4) and timing.
>>>
>>> 	• Minimal Set of Transport Services for TAPS Systems, Naeem 
>>> Khademi (presenting for authors)
>>>
>>> 		• draft-gjessing-taps-minset-05.txt
>>> 		• What’s new: the abstract API
>>> 	• Transport Security Protocol Survey, Tommy Pauly
>>>
>>> 		• At the meeting in Chicago, the question of how security 
>>> protocols should be handled was brought up, and we suggested writing 
>>> a draft to do a survey of Transport Security protocols, similar to 
>>> the work done in RFC 8095 and the transport usage drafts. This 
>>> document goes over several common transport security protocols and 
>>> analyzes their features and interfaces, particularly with regards to 
>>> how they interact with their associated transport protocols and 
>>> applications. For consideration as a TAPS working group doc.
>>> 		• draft-pauly-taps-transport-security-00.txt: The common 
>>> features/interface presented by various security protocols
>>> 		• draft-kuehlewind-taps-crypto-sep-00.txt: The ability to 
>>> separate security handshakes from data encryption
>>> 	• Application- & System-Specified Policy & TAPS, [[XX someone 
>>> needs to frame this topic. who? Brian? Tommy? XX]]
>>>
>>> 	• Socket Intents, Concepts & Communication Granularity, Phillipp 
>>> Tiesel
>>>
>>> 		• Socket Intents allow applications to share their knowledge 
>>> about upcoming communication and express their performance 
>>> preferences in an API independent way. Therefore, thy can be used by 
>>> an OS/API to gain enough knowledge to perform access as well as 
>>> transport protocol selection and tuning.
>>> 		• draft-tiesel-taps-socketintents-00.txt: concepts
>>> 		• draft-tiesel-taps-communitgrany-00.txt: endpoint and path 
>>> selection
>>> 		• draft-tiesel-taps-socketintents-bsdsockets-00.txt: prototype
>>> 	• Happy Eyeballs update, Anna Brunstrom
>>>
>>> 		• draft-grinnemo-taps-he-03.txt
>>> 		• The interface between the HE algorithm and the policy 
>>> management
>>> 		• What should be detailed in the specification of the HE 
>>> algorithm and what should be left open for implementation?
>>> _______________________________________________
>>> 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