Re: [Taps] Prague agenda planning

"Aaron Falk" <aaron.falk@gmail.com> Wed, 05 July 2017 16:55 UTC

Return-Path: <aaron.falk@gmail.com>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E55B131D75 for <taps@ietfa.amsl.com>; Wed, 5 Jul 2017 09:55:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWWCqHoTw6WB for <taps@ietfa.amsl.com>; Wed, 5 Jul 2017 09:55:56 -0700 (PDT)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 814DC131D72 for <taps@ietf.org>; Wed, 5 Jul 2017 09:55:56 -0700 (PDT)
Received: by mail-qk0-x22b.google.com with SMTP id p21so194888162qke.3 for <taps@ietf.org>; Wed, 05 Jul 2017 09:55:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references:mime-version; bh=3PqyU4pIrngDax+lxIJISM+0OtSMu6xTLMca87Grfo8=; b=uJlY6MxFT0OhBoF4sxaBtVGwSPO9g9grvjfuW3925yvRWXmNYOHYMurg03fKji4WgZ xW6J6cCltAuopQSwxs0OQg4lYslNmtvZaQxDWEk00KMlvG5cjPHe1LiYY6BE+czarWnA rNbYa8DC4gv2/7k8MLijcbLVbztB+vH4j4sjQ3xkVt0UaRY3VNCqH8AyLc9Off+mZ3mL huFNRUpgQRK4lqfX24P9BgGN9VYGZwM6IPiOszaPRIC4ezsEyix68ZisbQw9Wheia0lr /S/0wcPtxfb/LPXPPORsmF+3OLYHIQNxsLiA0pEwok6zZIvYMXQO33ZEfVIrpee4jsOc l5rw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version; bh=3PqyU4pIrngDax+lxIJISM+0OtSMu6xTLMca87Grfo8=; b=JGHXVQG9c2UGfAyVANnbtnYrjrNjugbv48/ci/dzki0m2VP/elMXasXTFNQimwreOH LOjQPyHmUkSrOFon1EB/Ua64gCNIiJnXvkYtV1xnatkTFnUZ7GyHRTA5DFhaWbz0kJre lNbsITUZHGVv1yBMtl/1fzbBRjk3aZSagjYTqqPVjYEapSapzVggxxDmkZJJxCQL4x/l WS8Ci5T0mr2/FRffNWTRLsnBJiMt3c60jx12wW3sJkGGjC4e9csVSYajJIFAWlEIECY3 i4jlmVg9pZFtEqI4ibvNaGDcs4lhpxSZ/UZzIZn+Cm48dqjD1q+McqSaRHoID87MJryX EKsg==
X-Gm-Message-State: AKS2vOwN8g5Ne/lx9t1al/xS/Etl1q0xcc4OhtbYjoeXu6pW2V2y2s+r AIiMAdgA5VcA+bkMpDs=
X-Received: by 10.55.146.133 with SMTP id u127mr56091411qkd.17.1499273755476; Wed, 05 Jul 2017 09:55:55 -0700 (PDT)
Received: from [172.19.37.166] ([2601:184:4980:a321:c555:fa0a:3752:abaf]) by smtp.gmail.com with ESMTPSA id 127sm16139796qkd.24.2017.07.05.09.55.54 for <taps@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jul 2017 09:55:55 -0700 (PDT)
From: Aaron Falk <aaron.falk@gmail.com>
To: taps@ietf.org
Date: Wed, 05 Jul 2017 12:55:54 -0400
Message-ID: <A9D4A0BD-CFA1-471D-A2C4-9E2AED925448@gmail.com>
In-Reply-To: <c28912d7-79a0-273b-8bc4-3206eb5a8bd8@kau.se>
References: <C582EEC8-8762-4CB6-9CA3-4E5AF92C5A68@gmail.com> <3A3686B5-FF60-448E-9E13-4B493B472C6D@gmail.com> <77C2BA95-F95B-4597-9159-7D5FC4068860@gmail.com> <c28912d7-79a0-273b-8bc4-3206eb5a8bd8@kau.se>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_6EF13ACD-7F29-4C35-B89D-0293075B0BA2_="
X-Mailer: MailMate (1.9.6r5356)
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/RoYrV3g__DF43Ul7tt9wrDo6lZc>
Subject: Re: [Taps] Prague agenda planning
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussions on Transport Services <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jul 2017 16:55:58 -0000

Updated:

1. **Minimal Set of Transport Services for TAPS Systems**  [[XX who will 
present?  XX]]
   * `draft-gjessing-taps-minset-05.txt`
   * Open issues to finalize doc

2. **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


4. **Application- & System-Specified Policy & TAPS**, [[XX someone needs 
to frame this topic.  who?  Brian? Tommy?  XX]]


3. **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

5. **Happy Eyeballs update**, Anna Brunstrom
   * `draft-grinnemo-taps-he-03.txt` (update expected)
   * 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?