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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps

Reply via email to