[Taps] IETF planning

Aaron Falk <aaron.falk@gmail.com> Mon, 19 October 2015 18:44 UTC

Return-Path: <aaron.falk@gmail.com>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D132B1B2A94 for <taps@ietfa.amsl.com>; Mon, 19 Oct 2015 11:44:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, MALFORMED_FREEMAIL=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham
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 LPJOS1wsHyTy for <taps@ietfa.amsl.com>; Mon, 19 Oct 2015 11:44:43 -0700 (PDT)
Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (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 2FA5E1B2BB1 for <taps@ietf.org>; Mon, 19 Oct 2015 11:44:42 -0700 (PDT)
Received: by qgad10 with SMTP id d10so72671542qga.3 for <taps@ietf.org>; Mon, 19 Oct 2015 11:44:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-type; bh=y1XTpRBVCDMx3XSn426mTP7vjoFMBATT3BTTAuchpQY=; b=kWOuA34v0rAcqugMjopjTGpP830Sezx07eryH5zyUYorl37lspYikTilnY0nDwf7tO r8f94z+gbKw7XkXoiyJxT8OUw74ThT4oAUMiNtwtyc19U8xqYCvHxl/9woVFwBEJ7ryM 8VXdojtZA0IW37vwzhQl9DGKCU2UauuGvmmmwMdMY+6WV0A9Yka1fR4gP8vlzl3PiilO lz4lVdnQBCBvVuifxVCLiJsPCVob96VIkUy/OsO1Zy+YyaTiRXqUyWUZKVPJzzPPysi+ khnKfC4gxCZQW3OwJVnNDsNyXxhNGMOPFrO9qnhoiQDGUG0ts7vIids7im4Toz7ua7Cs WMdw==
X-Received: by 10.140.146.66 with SMTP id 63mr10964757qhs.100.1445280281394; Mon, 19 Oct 2015 11:44:41 -0700 (PDT)
Received: from [172.30.19.28] ([72.246.0.14]) by smtp.gmail.com with ESMTPSA id u89sm14907245qkl.27.2015.10.19.11.44.40 for <taps@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Oct 2015 11:44:40 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/0.0.0.151008
Date: Mon, 19 Oct 2015 14:44:39 -0400
From: Aaron Falk <aaron.falk@gmail.com>
To: taps@ietf.org
Message-ID: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com>
Thread-Topic: IETF planning
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3528110680_1288394918"
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/S9l91dUp2mt0BW9APsFGQTYIUtg>
Subject: [Taps] IETF planning
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 19 Oct 2015 18:44:46 -0000

Hi Folks-

So, we have these two docs and a rough agreement that they are complimentary.  Gorry suggests that they both progress as responsive to milestone 1:

 I suggest the two docs against the first milestone will help us
make  progress towards the next milestone faster. (Assuming we can keep
the two aligned, which seems quite doable). I can see also how the  docs
are useful to different people. I'd like to see both mature and provide
inputs to move forward.

Is there agreement on this?  I’ve heard no objections.  Assuming so, we should move on.

First, I would ask that the authors summarize the work remaining on each doc to the list and call out any topics requiring discussion at the Yokohama meeting.

Second, let’s hear some proposals for addressing the second milestone.  

2) Specify the subset of those Transport Services, as identified 
   in item 1, that end systems supporting TAPS will provide, and 
   give guidance on choosing among available mechanisms and 
   protocols.  Note that not all the capabilities of IETF Transport 
   protocols need to be exposed as Transport Services.