From nobody Mon Aug 14 04:38:07 2017 Return-Path: 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 351F31321AA; Mon, 14 Aug 2017 04:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 dhPj1vH7iPCL; Mon, 14 Aug 2017 04:38:03 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B129B1321A4; Mon, 14 Aug 2017 04:38:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:Cc:To:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=DmpnEoilwiwoQ96n4RcQzpM8DiDzbYwtAzO4+D31IM0=; b=ujRepKHRKNyzYgd50VLYOvkIEk T6SLsmCTOwOwh9B8HyLAiWQqWd7ZNjLdybmCe+GFUZV8556ZT3M0h6mhs+y1BLngZzX/V2qVrSA9c N5wwkZrshDnVJWuKXW9F+l6HMjo3ezZYePmcrLTbSukmLbqXnzBhVqul+L/UusomY8yZJY/gOl4SX LG5ZYUUlXeTInsb6e8kJQlHzqSOM5rs9FsOZ9bzvp33/XXOoBe5tehxgE2dEAZf5wacAEHxvFton7 mHkSmSgZqRAd2dFBzMIefK2VpFeaCusLaJysnhBUIoQuCwIAhL7j1fQIZ6OpvTlK37FEE7JLYqS5J feknPIbA==; Received: from 6.136.199.146.dyn.plus.net ([146.199.136.6]:43850 helo=[192.168.0.2]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dhDh2-0004bA-Ds; Mon, 14 Aug 2017 12:38:00 +0100 To: michio@netapp.com, TAPS WG IETF list Cc: tsv-area IETF list From: Bob Briscoe Message-ID: <80679bf9-b708-47d9-b955-5aab181f03ad@bobbriscoe.net> Date: Mon, 14 Aug 2017 12:37:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: [Taps] Old paper related to your PASTE talk X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 11:38:06 -0000 Michio and the TAPS wg, While I was checking over DavidB's (excellent) TSVAREA minutes, the discussion of the relationship between writing to non-volatile memory and TAPS triggered an old memory. I believe this would effectively add a requirement for persistence and/or transactional semantics to the API. In the distributed systems research community, there was work on an API for persistence and transactional semantics that came up with some nice ideas in the late 1990s. They used reflection to provide app-specific information declaratively but still separate from app code. Obviously the age of the work dates some of the details (e.g. use of CORBA or Java), and there's no explicit consideration of latency, but it's still worth trying to understand the rationale for using reflection. I found these two papers, that are part of the old ANSA project site that Andrew Herbert kindly rescued from oblivion recently, and uploaded to more stable storage (irony intended): Schwiderski, Scarlet, "Design and Implementation of a Persistence Service for Java," ANSA Technical Report APM.1940.02 (January 1997) http://www.computerconservationsociety.org/ansa/97/Primary/194002.pdf Wu, Zhixue, "A Reflective Component-Based Transaction Architecture" Middleware'98 http://www.computerconservationsociety.org/ansa/ANSAhtml/98-ansa/external/9804tb/9804tran.pdf And this tech report, which I haven't read, from the Uni of Tromsø: Anna-Brith A. Jakobsen and Randi Karlsen, "ReflecTS; A Reflective Transaction Service Framework for Open Applications" https://munin.uit.no/bitstream/handle/10037/378/report.pdf;sequence=1 via https://munin.uit.no/handle/10037/378 This paper gives a good starting point: Stroud, R. & Wu, Z., "Using Meta-Object Protocols to Implement Atomic Data Types," Distributed Syst. Engineering 952(2):168-189 In: Proc. ECOOP'95 Vol.952 No.2 pp.168-189 (1995) I can't find it online, but here's a scan of a tech report with the same title and authors: https://assets.cs.ncl.ac.uk/TRs/512.pdf For those interested, try searching for some variation of "transaction OR persistence reflection metaobject middleware" Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Mon Aug 14 12:07:24 2017 Return-Path: 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 97E15132400 for ; Mon, 14 Aug 2017 12:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 AWPZe8wY-GzZ for ; Mon, 14 Aug 2017 12:07:20 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 499AE132399 for ; Mon, 14 Aug 2017 12:07:20 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id t37so56660054qtg.5 for ; Mon, 14 Aug 2017 12:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=f/Hqxki9xkAFhczU53sjwx1Z3anl5wrt462xGEgSi3I=; b=WnfR8scc8stQjhZwXBZCqjtwLI01aV9pou3ljnVD3BywyZ+6Qnu5cy6qphU6bGWxHS Q9ksTsEIoFE0VTEXrQ6/aG5jKD/0VvURWco2bzkPuBkPWhwtEoYVwh4nlxXR1ypLXrLW fkMiWHnntdD9jhAMbmatnILhtqqScNP4SELZLju+9AUKe/J0NeWJY5prhIh4iU60gngi CJbVEwz4JPRsYkBxVIDbQp3KhUrVU+p2N5Za0smFKf1Omy1HeTejr7xTmDfYYAFttrPr 0Co3WvDCxpqX3J6kDA6KDKwKzEcoTokfakKMuFQzJzQ9nptUVLHKG7VPprszT02stoNb 0ecw== 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:mime-version :content-transfer-encoding; bh=f/Hqxki9xkAFhczU53sjwx1Z3anl5wrt462xGEgSi3I=; b=cGq4gZGHN9lsX7oEQTu5wVqFDvFrPENObnErxf4edspYsw0lcW/nAn/nZfOtupoFv5 lTD3Bv4iZtXeHdIVvQWtufAQShqA78yVkIsO1IoG5OkJ3OIGE5YD8AHwgCvBEo6nHe0X ix7veV6B07o3ojKO/nxEhTrY1gtqWqSSD1O85tRr5ijT73RqmfMnJQRbZekoZ6wDR/uA 9wW2gLZCczVepSu6DeVUMuACgcbe/He4gx3q3HvS16aCtKLKRinj/ehTjGkbxG7JSQnv f+mI4tofRFJHmHqquDdSxu6yoJN+o1EQzI6N+7TU4SFY1MM9fSOhaRw2efHkGVAVOF0Y Sqzg== X-Gm-Message-State: AHYfb5iUfP02t15u2ZWHUOskcYnLWYu00e5NZ6b0WKRTideGxtGZGDsc XYGG0s413m33MgxuloU= X-Received: by 10.200.35.221 with SMTP id r29mr32843184qtr.115.1502737639032; Mon, 14 Aug 2017 12:07:19 -0700 (PDT) Received: from [172.19.38.32] ([72.246.0.14]) by smtp.gmail.com with ESMTPSA id j90sm5511623qtb.73.2017.08.14.12.07.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Aug 2017 12:07:18 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Date: Mon, 14 Aug 2017 15:07:17 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5356) Archived-At: Subject: [Taps] singapore X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 19:07:21 -0000 Hi all- My assumption is that TAPS should meet in Singapore. Anyone disagree? It’s time to put in a session / room request. —aaron From nobody Mon Aug 14 18:31:17 2017 Return-Path: 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 71261132476; Mon, 14 Aug 2017 18:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=0ByE+u1P; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=LqsXlUtQ 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 RauKGbmtFfOx; Mon, 14 Aug 2017 18:31:14 -0700 (PDT) Received: from esa5.dell-outbound.iphmx.com (esa5.dell-outbound.iphmx.com [68.232.153.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15C161321B6; Mon, 14 Aug 2017 18:31:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1502760586; x=1534296586; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5VGZ8u0TXkQUbSIAYK+TWBtJ5VG8JZGstDSafqj8/tg=; b=0ByE+u1PtNsIi2TC+65Rv6/9N+rH/HKwvztpE6QaZD+0d7egFRAo7n1v mYkb3hDhPz5abVeVwSnTDNXztWdLX3SuUbwVu+cAEbU/ilRR5HNwrzGxf 0zkc9O5G1fMjiUVrBPDfoTlGx62tonUe+DLCbFY1Hp2nHp8DmfqkChAd+ k=; Received: from esa1.dell-outbound2.iphmx.com ([68.232.153.201]) by esa5.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Aug 2017 20:29:44 -0500 From: "Black, David" Cc: tsv-area IETF list , "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa1.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Aug 2017 07:30:23 +0600 Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v7F1V8T4012701 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 14 Aug 2017 21:31:09 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com v7F1V8T4012701 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1502760670; bh=Lcw7X4v1x1rpTFkavlQGEKWEjJY=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=LqsXlUtQaA1MfuCcBZj2W4xxl7LVUUQ/f2weEhRwjEqUMQ/nOVa0UmVAKWKkp6Q3a VknR0IiMjzaM5SsJ5h7Z+FQr/EDh7awhAUscnABJMeh7MznZz/AJENRayaJ/vwGMPd vwMZiYNwMP3kmeH28fz4uLf4bfq5+WAJampudTa8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com v7F1V8T4012701 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd03.lss.emc.com (RSA Interceptor); Mon, 14 Aug 2017 21:30:18 -0400 Received: from MXHUB318.corp.emc.com (MXHUB318.corp.emc.com [10.146.3.96]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v7F1UnbY018230 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 14 Aug 2017 21:30:49 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB318.corp.emc.com ([10.146.3.96]) with mapi id 14.03.0352.000; Mon, 14 Aug 2017 21:30:49 -0400 To: Bob Briscoe , "michio@netapp.com" , TAPS WG IETF list Thread-Topic: Old paper related to your PASTE talk Thread-Index: AQHTFPHV7dZqk+kxn0m/tIMrH9/+4KKEofOQ Date: Tue, 15 Aug 2017 01:30:48 +0000 Message-ID: References: <80679bf9-b708-47d9-b955-5aab181f03ad@bobbriscoe.net> In-Reply-To: <80679bf9-b708-47d9-b955-5aab181f03ad@bobbriscoe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.105.8.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [Taps] Old paper related to your PASTE talk X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 01:31:16 -0000 Rm9yIGN1cnJlbnQgd29yayBpbiB0aGlzIGFyZWEsIHNlZTogaHR0cHM6Ly93d3cuc25pYS5vcmcv dGVjaF9hY3Rpdml0aWVzL3N0YW5kYXJkcy9jdXJyX3N0YW5kYXJkcy9ucG0NCg0KVGhpcyBpcyBh IGh5YnJpZCBvZiBhIGZ1bmN0aW9uYWwgbW9kZWwgYW5kIGFuIEFQSSwgYnV0IGlzIGluIGFib3V0 IHRoZSBzYW1lIHRlcnJpdG9yeSBpbiB0aGF0IGl0IGRlZmluZXMgdGhlIHNlcnZpY2VzIHRoYXQg YXBwbGljYXRpb25zIGFuZCBwcm9ncmFtbWVycyBjYW4gZXhwZWN0L3VzZS4NCg0KVGhhbmtzLCAt LURhdmlkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdHN2LWFyZWEg W21haWx0bzp0c3YtYXJlYS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQm9iIEJyaXNj b2UNCj4gU2VudDogTW9uZGF5LCBBdWd1c3QgMTQsIDIwMTcgNzozOCBBTQ0KPiBUbzogbWljaGlv QG5ldGFwcC5jb207IFRBUFMgV0cgSUVURiBsaXN0IDx0YXBzQGlldGYub3JnPg0KPiBDYzogdHN2 LWFyZWEgSUVURiBsaXN0IDx0c3YtYXJlYUBpZXRmLm9yZz4NCj4gU3ViamVjdDogT2xkIHBhcGVy IHJlbGF0ZWQgdG8geW91ciBQQVNURSB0YWxrDQo+IA0KPiBNaWNoaW8gYW5kIHRoZSBUQVBTIHdn LA0KPiANCj4gV2hpbGUgSSB3YXMgY2hlY2tpbmcgb3ZlciBEYXZpZEIncyAoZXhjZWxsZW50KSBU U1ZBUkVBIG1pbnV0ZXMsIHRoZQ0KPiBkaXNjdXNzaW9uIG9mIHRoZSByZWxhdGlvbnNoaXAgYmV0 d2VlbiB3cml0aW5nIHRvIG5vbi12b2xhdGlsZSBtZW1vcnkNCj4gYW5kIFRBUFMgdHJpZ2dlcmVk IGFuIG9sZCBtZW1vcnkuIEkgYmVsaWV2ZSB0aGlzIHdvdWxkIGVmZmVjdGl2ZWx5IGFkZCBhDQo+ IHJlcXVpcmVtZW50IGZvciBwZXJzaXN0ZW5jZSBhbmQvb3IgdHJhbnNhY3Rpb25hbCBzZW1hbnRp Y3MgdG8gdGhlIEFQSS4NCj4gDQo+IEluIHRoZSBkaXN0cmlidXRlZCBzeXN0ZW1zIHJlc2VhcmNo IGNvbW11bml0eSwgdGhlcmUgd2FzIHdvcmsgb24gYW4gQVBJDQo+IGZvciBwZXJzaXN0ZW5jZSBh bmQgdHJhbnNhY3Rpb25hbCBzZW1hbnRpY3MgdGhhdCBjYW1lIHVwIHdpdGggc29tZSBuaWNlDQo+ IGlkZWFzIGluIHRoZSBsYXRlIDE5OTBzLiBUaGV5IHVzZWQgcmVmbGVjdGlvbiB0byBwcm92aWRl IGFwcC1zcGVjaWZpYw0KPiBpbmZvcm1hdGlvbiBkZWNsYXJhdGl2ZWx5IGJ1dCBzdGlsbCBzZXBh cmF0ZSBmcm9tIGFwcCBjb2RlLiBPYnZpb3VzbHkNCj4gdGhlIGFnZSBvZiB0aGUgd29yayBkYXRl cyBzb21lIG9mIHRoZSBkZXRhaWxzIChlLmcuIHVzZSBvZiBDT1JCQSBvcg0KPiBKYXZhKSwgYW5k IHRoZXJlJ3Mgbm8gZXhwbGljaXQgY29uc2lkZXJhdGlvbiBvZiBsYXRlbmN5LCBidXQgaXQncyBz dGlsbA0KPiB3b3J0aCB0cnlpbmcgdG8gdW5kZXJzdGFuZCB0aGUgcmF0aW9uYWxlIGZvciB1c2lu ZyByZWZsZWN0aW9uLg0KPiANCj4gSSBmb3VuZCB0aGVzZSB0d28gcGFwZXJzLCB0aGF0IGFyZSBw YXJ0IG9mIHRoZSBvbGQgQU5TQSBwcm9qZWN0IHNpdGUNCj4gdGhhdCBBbmRyZXcgSGVyYmVydCBr aW5kbHkgcmVzY3VlZCBmcm9tIG9ibGl2aW9uIHJlY2VudGx5LCBhbmQgdXBsb2FkZWQNCj4gdG8g bW9yZSBzdGFibGUgc3RvcmFnZSAoaXJvbnkgaW50ZW5kZWQpOg0KPiANCj4gU2Nod2lkZXJza2ks IFNjYXJsZXQsICJEZXNpZ24gYW5kIEltcGxlbWVudGF0aW9uIG9mIGEgUGVyc2lzdGVuY2UNCj4g U2VydmljZSBmb3IgSmF2YSwiIEFOU0EgVGVjaG5pY2FsIFJlcG9ydCBBUE0uMTk0MC4wMiAoSmFu dWFyeSAxOTk3KQ0KPiBodHRwOi8vd3d3LmNvbXB1dGVyY29uc2VydmF0aW9uc29jaWV0eS5vcmcv YW5zYS85Ny9QcmltYXJ5LzE5NDAwMi5wZGYNCj4gDQo+IFd1LCBaaGl4dWUsICJBIFJlZmxlY3Rp dmUgQ29tcG9uZW50LUJhc2VkIFRyYW5zYWN0aW9uIEFyY2hpdGVjdHVyZSINCj4gTWlkZGxld2Fy ZSc5OA0KPiBodHRwOi8vd3d3LmNvbXB1dGVyY29uc2VydmF0aW9uc29jaWV0eS5vcmcvYW5zYS9B TlNBaHRtbC85OC0NCj4gYW5zYS9leHRlcm5hbC85ODA0dGIvOTgwNHRyYW4ucGRmDQo+IA0KPiBB bmQgdGhpcyB0ZWNoIHJlcG9ydCwgd2hpY2ggSSBoYXZlbid0IHJlYWQsIGZyb20gdGhlIFVuaSBv ZiBUcm9tc8O4Og0KPiANCj4gQW5uYS1Ccml0aCBBLiBKYWtvYnNlbiBhbmQgUmFuZGkgS2FybHNl biwgIlJlZmxlY1RTOyBBIFJlZmxlY3RpdmUNCj4gVHJhbnNhY3Rpb24gU2VydmljZSBGcmFtZXdv cmsgZm9yIE9wZW4gQXBwbGljYXRpb25zIg0KPiBodHRwczovL211bmluLnVpdC5uby9iaXRzdHJl YW0vaGFuZGxlLzEwMDM3LzM3OC9yZXBvcnQucGRmO3NlcXVlbmNlPTENCj4gdmlhIGh0dHBzOi8v bXVuaW4udWl0Lm5vL2hhbmRsZS8xMDAzNy8zNzgNCj4gDQo+IFRoaXMgcGFwZXIgZ2l2ZXMgYSBn b29kIHN0YXJ0aW5nIHBvaW50Og0KPiBTdHJvdWQsIFIuICYgV3UsIFouLCAiVXNpbmcgTWV0YS1P YmplY3QgUHJvdG9jb2xzIHRvIEltcGxlbWVudCBBdG9taWMNCj4gRGF0YSBUeXBlcywiIERpc3Ry aWJ1dGVkIFN5c3QuIEVuZ2luZWVyaW5nIDk1MigyKToxNjgtMTg5IEluOiBQcm9jLg0KPiBFQ09P UCc5NSBWb2wuOTUyIE5vLjIgcHAuMTY4LTE4OSAoMTk5NSkNCj4gSSBjYW4ndCBmaW5kIGl0IG9u bGluZSwgYnV0IGhlcmUncyBhIHNjYW4gb2YgYSB0ZWNoIHJlcG9ydCB3aXRoIHRoZSBzYW1lDQo+ IHRpdGxlIGFuZCBhdXRob3JzOiBodHRwczovL2Fzc2V0cy5jcy5uY2wuYWMudWsvVFJzLzUxMi5w ZGYNCj4gDQo+IA0KPiBGb3IgdGhvc2UgaW50ZXJlc3RlZCwgdHJ5IHNlYXJjaGluZyBmb3Igc29t ZSB2YXJpYXRpb24gb2YgInRyYW5zYWN0aW9uDQo+IE9SIHBlcnNpc3RlbmNlIHJlZmxlY3Rpb24g bWV0YW9iamVjdCBtaWRkbGV3YXJlIg0KPiANCj4gDQo+IA0KPiANCj4gQm9iDQo+IA0KPiANCj4g LS0NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBCb2IgQnJpc2NvZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBodHRwOi8vYm9iYnJpc2NvZS5uZXQvDQoNCg== From nobody Fri Aug 18 08:18:34 2017 Return-Path: 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 060AA132961 for ; Fri, 18 Aug 2017 08:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 FxMf7mTxkYQ0 for ; Fri, 18 Aug 2017 08:18:30 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C066F1320D9 for ; Fri, 18 Aug 2017 08:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1503069510; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Xszj6QWrQeC+U7ygVmwY9eJ9aR3WAFJrz9wpIZryn0k=; b=FUl2BtX20v8JWSUpwN3fhr/OiQwM5UZ3iMttFraohmyyxhrhwcVx8RWPkuUanO9p 8NsSHs6f6SD2RY3xKvJ70m0PlK3OHJ6Uim4EqP4YvL4w1yY8DjKsn48dNozFQDAQ yVXI9S5/uQ4sWxx6pZpDqztswM6CPbfeKzWegFhkMNcGxs4/CHNSAJjLwu5xKax1 PHhkX7Z+bI6QwSINTsLFNmYP+evIW9J3Dv1OeP8b2krV2r7SpsVcVbgxkG6/GfJD syfplmmT/vTmZJunTCa9YUok8ShIufIwuW6HHFoB+ERx1nhAfVMpe6VLvTa8IIww kHFhFO9nClrM+9Dj61UeOQ==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id A2.13.29949.64507995; Fri, 18 Aug 2017 08:18:30 -0700 (PDT) X-AuditID: 11973e12-a9e399c0000074fd-05-599705465e1a Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by relay2.apple.com (Apple SCV relay) with SMTP id ED.8D.09069.64507995; Fri, 18 Aug 2017 08:18:30 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.114.155.139] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170621 64bit (built Jun 21 2017)) with ESMTPSA id <0OUV00CR1ZUU6930@nwk-mmpp-sz10.apple.com>; Fri, 18 Aug 2017 08:18:30 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: Date: Fri, 18 Aug 2017 08:18:29 -0700 Cc: taps WG Content-transfer-encoding: quoted-printable Message-id: <11930EA5-2F1E-4175-82F6-A949E29EA40F@apple.com> References: To: Aaron Falk X-Mailer: Apple Mail (2.3439) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUi2FDorOvGOj3SYNZmSYu239NYLe7EODB5 7Jx1l91jyZKfTAFMUVw2Kak5mWWpRfp2CVwZkyabF7xkqXhw9SJbA+MP5i5GTg4JAROJz/ce s3YxcnEICaxmkmhc/pgJJrG54T07ROIQo8Sz19NZQRK8AoISPybfY+li5OBgFlCXmDIlF6Lm G6PErScn2EDiwgISEpv3JIKUCwvISvz9v5wdxGYTUJE4/m0D2GJOAVuJedvXgsVZBFQlHj3/ AxZnFpCWWPptMiOErS3x5N0FqLU2Ep0zZ4LFhYDsr29Xs4DYIkC9y160g62VANq19E8IyDkS AnPYJM6s6WadwCg8C8nVsxCunoVkwwJG5lWMQrmJmTm6mXkmeokFBTmpesn5uZsYQQE93U5o B+OpVVaHGAU4GJV4eF/8nBYpxJpYVlyZe4hRmoNFSZz3oi1QSCA9sSQ1OzW1ILUovqg0J7X4 ECMTB6dUA2PCAbtjOjm1hR+v/Jqydv9Hw+L5c4XO7Zn3+bK6JkfDuuNRor1HWSQKvztebI3j v3SEKenFpILUZ7+2t9V9OvT1aE+FgCxTYM76nUUJ3garP2ZH6j6OeV7d8up28ddbFT3F2Ytz OHfOvb1C4UshU+VJ6Rlen07+4PkpKbltAe80g0X7H4lUyFQrsRRnJBpqMRcVJwIAwEpdQUkC AAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42IRbCiu0nVjnR5p8GSPmEXb72msFndiHJg8 ds66y+6xZMlPpgCmKC6blNSczLLUIn27BK6MSZPNC16yVDy4epGtgfEHcxcjJ4eEgInE5ob3 7F2MXBxCAocYJZ69ns4KkuAVEJT4MfkeSxcjBwezgLrElCm5EDXfGCVuPTnBBhIXFpCQ2Lwn EaRcWEBW4u//5ewgNpuAisTxbxvA5nMK2ErM274WLM4ioCrx6PkfsDizgLTE0m+TGSFsbYkn 7y5ArbWR6Jw5EywuBGR/fbuaBcQWAepd9qIdbK0E0K6lf0ImMArMQnLoLIRDZyEZuoCReRWj QFFqTmKlkV5iQUFOql5yfu4mRnAAFjrvYDy2zOoQowAHoxIP74uf0yKFWBPLiitzgSHBwawk wivwDCjEm5JYWZValB9fVJqTWnyIsQrolYnMUqLJ+cDoyCuJNzQxMTAxNjYzNjY3MaeKsJI4 r0zR5EghgfTEktTs1NSC1CKY5UwcnFINjGlKmtK3nO36rBfeco2sMn/4hnd96K1MNfua27v2 VHAd2q2x9NkE8R1NrkZbdqzm5C0uqNU6u6Hs8lRO/bK+b2JWtfNzfvlu5Zi/YVWQcFL8NMFv t6K45Iz2x57ar3Oc1UCGMUjuzqWtB8TL8jz/rVKsv9lsYht40sJTdubtjY8V98sv2u/LrcRS nJFoqMVcVJwIAMUlC7qbAgAA Archived-At: Subject: Re: [Taps] singapore X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 15:18:32 -0000 Sounds good! We're planning on having an update to the Post Sockets = document, as well as consolidating some documents around Connection = Establishment (Happy Eyeballs + other Racing) and Policy. Thanks, Tommy > On Aug 14, 2017, at 12:07 PM, Aaron Falk wrote: >=20 > Hi all- >=20 > My assumption is that TAPS should meet in Singapore. Anyone disagree? = It=E2=80=99s time to put in a session / room request. >=20 > =E2=80=94aaron >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Mon Aug 21 08:32:03 2017 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D9A132026; Mon, 21 Aug 2017 08:32:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: aafalk@akamai.com, taps-chairs@ietf.org, spencerdawkins.ietf@gmail.com, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150332952176.6854.6196714421701467699.idtracker@ietfa.amsl.com> Date: Mon, 21 Aug 2017 08:32:01 -0700 Archived-At: Subject: [Taps] taps - New Meeting Session Request for IETF 100 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 15:32:02 -0000 A new meeting session request has just been submitted by Aaron Falk, a Chair of the taps working group. --------------------------------------------------------- Working Group Name: Transport Services Area Name: Transport Area Session Requester: Aaron Falk Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmcat aqm tsvarea quic Second Priority: webpush tcpinc nvo3 mptcp icnrg httpbis DOTS I2NSF IDEAS Third Priority: mmusic tram SACM MILE IPWAVE CFRG SAAG People who must be present: Aaron Falk Michael Welzl Spencer Dawkins Brian Trammell Zaheduzzaman Sarker Mirja Kuehlewind Tommy Pauly Resources Requested: Experimental Room Setup (U-Shape and classroom, subject to availability) Special Requests: U-shaped room would be nice, not required. --------------------------------------------------------- From nobody Thu Aug 24 13:09:56 2017 Return-Path: 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 10077132113; Thu, 24 Aug 2017 13:09:56 -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 Dlzxdrw9ctgu; Thu, 24 Aug 2017 13:09:54 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (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 08A7B13207A; Thu, 24 Aug 2017 13:09:50 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id y64so3118234ywf.1; Thu, 24 Aug 2017 13:09:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=Z+dzEvPIfJIkc+GUss1j2BgmJAkCkqSBzJ8Fl66Lv4w=; b=vM1YhfuDNmyV32uJrS79GFGheFTavLnFpi2mgf+OknJyDK2BQhS/gcwLO0eId2Qu/d uh0bo7B2WmCTNgRz8qSNU41XrSUqo7WacGIfJ7JJbYNEphjXxvjR/LGXqddPx+G0gmSQ 8dYiQj/N9g5xaJhvvvseranrXbWpe4pkdEWXgVNgNaS5DbM9RodCbNMGKcVPlvic8Vdk zyco3gTh1ABRI+VUloHFxsfXO5+9UWtAL5Vr945u5cXmMuW0AYYS66LrmrnWqpZdteFo CNKqKeREGaX8m6jX5ncm+uzn+ctfy0/pEQ+ouORIBrG+Orz7dchXmARwwIDsR3p0PsGo G83A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=Z+dzEvPIfJIkc+GUss1j2BgmJAkCkqSBzJ8Fl66Lv4w=; b=lVcFNDf6oCWi1xByrA7YGSQCXqTLNRu6MpL/TS+ChNFsKwJxUHHvFQBNuiEIYXneF+ fPUzWN88xXvHmiDr1ZKXvHWJAm1bJQyXeJaYcMOLytWKKNzj2eLL0FRX2Vzi0WQGjiDS NS2bG8YOmz1KltIaHvn+nXCYvwgxKRRZPdgqJkSd2kNvtR+hBixtlXvwgJA19//mOpcy b+2VDg3gN27YpoDpqQ/noHqUbkH9JM7g9Qp+bNEoN3pGExgTVcXsZNFGl1bif1NVFXl1 WJqJw30DWLGrRISFlyTiP1qkpZMS1/FfXxL3klki0HMdwUIQ60xCM1hn4NkHr5nFjX0y py6w== X-Gm-Message-State: AHYfb5iV6fwwRDAD4j2cfxevEb3nr/KAdOOceqHgKBzVvtCvJUSvh39B ptbEKee3KBts9AK0cJ8obNe83CQYRc3g X-Received: by 10.129.98.86 with SMTP id w83mr6145585ywb.127.1503605389868; Thu, 24 Aug 2017 13:09:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.148 with HTTP; Thu, 24 Aug 2017 13:09:49 -0700 (PDT) From: Spencer Dawkins at IETF Date: Thu, 24 Aug 2017 15:09:49 -0500 Message-ID: To: "taps@ietf.org" Cc: taps-chairs@ietf.org Content-Type: multipart/alternative; boundary="001a11470eee2545d605578569ce" Archived-At: Subject: [Taps] AD review of draft-ietf-taps-transports-usage-udp-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 20:09:56 -0000 --001a11470eee2545d605578569ce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm actually pretty positive on this draft - most of what follows is editorial. Thanks, Spencer This text This document is intended as a contribution to the Transport Services (TAPS) working group to assist in analysis of the UDP and UDP-Lite transport interface. Refers to the TAPS working group, which will conclude someday. It=E2=80=99s probably better if you say that this document provided details for the Pass 1 analysis of UDP and UDP-Lite that is used in draft-ietf-taps-transports-usage-06, or something like that. In this text Neither UDP nor UDP-Lite provide congestion control, retransmission, nor do they have support to optimise fragmentation and other transport functions. Is =E2=80=9Coptimizing fragmentation=E2=80=9D the best way to describe what= UDP is not doing there? Perhaps =E2=80=9Cassist in application-level packetization tha= t would avoid IP fragmentation?=E2=80=9D I may be very confused about this next one, but in Messages passed to the send primitive that cannot be sent atomically in a datagram will not be sent by the network layer, generating an error. Is this =E2=80=9Catomically in an IP datagram=E2=80=9D? With IP-level fragm= entation available, I=E2=80=99m not sure what =E2=80=9Catomically=E2=80=9D is tellin= g the reader. If we=E2=80=99re going to =E2=80=9Cgo there=E2=80=9D, this text The acceptable maximum packet size can be determined using Packetization-Layer-Path MTU Discovery (PLPMTUD) [RFC4821] or Path MTU Discovery [RFC1191] [I-D.ietf-6man-rfc1981bis]. Makes PMTUD sound like an equally good alternative. What ended up in -08 of [I-D.ietf-6man-rfc1981bis], and in RFC 8201, and I saw that your reference was to -06, is If ICMPv6 filtering prevents reception of ICMPv6 Packet Too Big messages, the source will not learn the actual path MTU. Packetization Layer Path MTU Discovery [RFC4821] does not rely upon network support for ICMPv6 messages and is therefore considered more robust than standard PMTUD. It is not susceptible to "black holed" connections caused by filtering of ICMPv6 message. See [RFC4890] for recommendations regarding filtering ICMPv6 messages. I know we don=E2=80=99t have a great story for discovering maximum packet s= izes, but I=E2=80=99d like to be at least as discouraging about PMTUD as RFC 8201= , and concerns about earlier versions of the text almost prevented RFC 8201 from being published as an Internet Standard, and I=E2=80=99m pretty sure being = more encouraging would gather Discusses - https://datatracker.ietf.org/doc/rfc8201/history/ is instructive. --001a11470eee2545d605578569ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm actually pretty positive on this draft - most= of what follows is editorial.=C2=A0

Thanks,
=

Spencer

This text=C2=A0
<= div>
=C2=A0 This document is intended as a contribution to th= e Transport Services
=C2=A0 =C2=A0(TAPS) working group to assist = in analysis of the UDP and UDP-Lite
=C2=A0 =C2=A0transport interf= ace.=C2=A0

Refers to the TAPS working group, which= will conclude someday. It=E2=80=99s probably better if you say that this d= ocument provided details for the Pass 1 analysis of UDP and UDP-Lite that i= s used in draft-ietf-taps-transports-usage-06, or something like that.

In this text

=C2=A0 =C2=A0Nei= ther UDP nor UDP-Lite provide congestion control, retransmission,
=C2=A0 =C2=A0nor do they have support to optimise fragmentation and other<= /div>
=C2=A0 =C2=A0transport functions.=C2=A0

= Is =E2=80=9Coptimizing fragmentation=E2=80=9D the best way to describe what= UDP is not doing there? Perhaps =E2=80=9Cassist in application-level packe= tization that would avoid IP fragmentation?=E2=80=9D

I may be very confused about this next one, but in

<= div>=C2=A0 =C2=A0 =C2=A0 Messages passed to the send
=C2=A0 =C2= =A0 =C2=A0 primitive that cannot be sent atomically in a datagram will not = be
=C2=A0 =C2=A0 =C2=A0 sent by the network layer, generating an = error.

Is this =E2=80=9Catomically in an IP datagr= am=E2=80=9D? With IP-level fragmentation available, I=E2=80=99m not sure wh= at =E2=80=9Catomically=E2=80=9D is telling the reader.

=
If we=E2=80=99re going to =E2=80=9Cgo there=E2=80=9D, this text
<= div>
=C2=A0 =C2=A0 =C2=A0 The acceptable maximum packet size = can be determined using
=C2=A0 =C2=A0 =C2=A0 Packetization-Layer-= Path MTU Discovery (PLPMTUD) [RFC4821] or Path
=C2=A0 =C2=A0 =C2= =A0 MTU Discovery [RFC1191] [I-D.ietf-6man-rfc1981bis].

Makes PMTUD sound like an equally good alternative. What ended up in = -08 of [I-D.ietf-6man-rfc1981bis], and in RFC 8201, and I saw that your ref= erence was to -06, is=C2=A0

=C2=A0 If ICMPv6 filte= ring prevents reception of ICMPv6 Packet Too Big
=C2=A0 =C2=A0mes= sages, the source will not learn the actual path MTU.
=C2=A0 =C2= =A0Packetization Layer Path MTU Discovery [RFC4821] does not rely upon
=C2=A0 =C2=A0network support for ICMPv6 messages and is therefore con= sidered more
=C2=A0 =C2=A0robust than standard PMTUD.=C2=A0 It is= not susceptible to "black holed"
=C2=A0 =C2=A0connecti= ons caused by filtering of ICMPv6 message.=C2=A0 See [RFC4890] for
=C2=A0 =C2=A0recommendations regarding filtering ICMPv6 messages.


I know we don=E2=80=99t have a great story= for discovering maximum packet sizes, but I=E2=80=99d like to be at least = as discouraging about PMTUD as RFC 8201, and concerns about earlier version= s of the text almost prevented RFC 8201 from being published as an Internet= Standard, and I=E2=80=99m pretty sure being more encouraging would gather = Discusses - h= ttps://datatracker.ietf.org/doc/rfc8201/history/ is instructive.
<= /div> --001a11470eee2545d605578569ce-- From nobody Thu Aug 24 13:18:16 2017 Return-Path: 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 8CF2113239C; Thu, 24 Aug 2017 13:18:15 -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 v--FwRDh7GSY; Thu, 24 Aug 2017 13:18:13 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::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 D9CD81321DF; Thu, 24 Aug 2017 13:18:12 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id s143so3245948ywg.0; Thu, 24 Aug 2017 13:18:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=FBrzN3UFUTljl21yeZaY95avvWlMEcrb4kkYHQFfEgo=; b=Fk2ZU0hqKpmDT/alFYrPzf8lgznNmmCaPVq8wmqudCwgBvBgDXxlbPclkaoqKkxnWc wiUQiZ8U0nV49TS9I9MEn0neHVMJggw6sRHsPNDa2ZtTCZW9GaV0kFBlZLolpLxFdNor mXe28Bkj/KmcGP6NOpJSTRPNHJ6DEY6eNYhxstrrsutbWcx474l5Oo0356Gsy0t3x7Im frsP7ncrimpcaCq9Sko8th7kgk6NhjmdPcvRK+A5BgxotwWb7h1JwIp8gDRk8oLyF0rK MIN+oO0kq5Ken/pdh8mqYxyZeaGGQosiOxrR4I9tINRofipt0ZY8fC1gIL5CiZDxHLF6 P3Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=FBrzN3UFUTljl21yeZaY95avvWlMEcrb4kkYHQFfEgo=; b=dk8ubVH9iiAkgHQAieaC3uidfK3KYnBMuDiEe41RHb9ckn90FIepFHE2ig1xhDpT4P Xz49fytJ9NQt4ti+L+6RqQCuRb/WmuG923DOE6mNsmQKH/WRhAACbIZiIa7Xi6vx7EXh YZviVmf13s9NVLqre+qsUtROKdeDZVp85B1ynR3NznaEfNNY+zNjpVecCiIPJZs6KlhR wcTGNJRhNZz+esv6grzgrYDopIiowWyaVk0DvXCsftG3m86clM9W3WwfGGwQIvlcY03z 8eTFOb7IX6omdLv2CeX5r0VVM9shV+sfSmBhPkuyVrosr5JigFufaUH4NgFkGsFVipQt XKwQ== X-Gm-Message-State: AHYfb5h6zNINqirmEy+j8mD63k7tcG6MI8OgIxVrL0P5AK3taecbcMQ2 JPdh5Wj3g74qbxKJYGr35siXJ38FCwHl X-Received: by 10.129.132.212 with SMTP id u203mr6143229ywf.311.1503605891766; Thu, 24 Aug 2017 13:18:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.148 with HTTP; Thu, 24 Aug 2017 13:18:11 -0700 (PDT) From: Spencer Dawkins at IETF Date: Thu, 24 Aug 2017 15:18:11 -0500 Message-ID: To: "taps@ietf.org" Cc: taps-chairs@ietf.org Content-Type: multipart/alternative; boundary="001a114f09c80f9ff3055785873c" Archived-At: Subject: [Taps] AD review for draft-ietf-taps-transports-usage-06 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 20:18:16 -0000 --001a114f09c80f9ff3055785873c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable These are all editorial. Thanks, Spencer A nit - in this text, Transport Protocol: an implementation that provides one or more different transport services using a specific framing and header format on the wire. one path through the "or" statement says "provides one different header", which reads oddly. Perhaps s/different//? This text The TAPS working group intends to describe an (abstract) interface for applications to make use of Transport Services, such that applications are no longer directly tied to a specific protocol. Is pointing to the TAPS working group, which will conclude someday. It=E2= =80=99s probably better to point to =E2=80=9Cthis specification=E2=80=9D, and it=E2= =80=99s probably good to think of the text as appearing in an RFC, so =E2=80=9Cintends to describe= =E2=80=9D is probably better as =E2=80=9Cdescribes=E2=80=9D (at Last Call time, intentio= ns don=E2=80=99t matter). This text Transport protocols provide communication between processes that operate on network endpoints, which means that they allow for multiplexing of communication between the same IP addresses, and normally this multiplexing is achieved using port numbers. Confused me - are any of the transport protocols you=E2=80=99re describing = not using port numbers for multiplexing? If not, s/normally// A nit - you have an =E2=80=9CSCPT=E2=80=9D in Section 3.3. In this text, The following three removed limitations directly translate into transport features that are visible to an application using SCTP: 1) it allows for preservation of message delineations; 2) these messages, do not require to be in order or reliably transferred unless the application wants it; 3) multi-homing is supported. I=E2=80=99m not parsing the description labeled =E2=80=9C2)=E2=80=9D. I THI= NK you=E2=80=99re saying =E2=80=9Cit does not provide in-order or reliable delivery unless the application wants that=E2=80=9D, but I=E2=80=99m not sure. In this sentence, Section 10 of the SCTP base protocol specification [RFC4960] specifies the interaction with the application (which this RFC calls the "Upper Layer Protocol" (ULP)). Your draft is going to be the default for =E2=80=9Cthis RFC=E2=80=9D when i= t=E2=80=99s published as an RFC. Better to say =E2=80=9Cwhich SCTP calls=E2=80=9D, I think. In this sentence, The functionality exposed to the ULP through the all these APIs is considered here. =E2=80=9CThe all these=E2=80=9D is garbled. --001a114f09c80f9ff3055785873c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

These are all editorial.


Thanks= ,


Spencer

<= span style=3D"font-size:14.6667px;white-space:pre-wrap">
<= /p>

A nit - in this text,


=C2=A0 =C2=A0Transport= Protocol: =C2=A0an implementation that provides one or more<= /p>

=C2=A0 =C2=A0 =C2=A0 different transport services u= sing a specific framing and header

= =C2=A0 =C2=A0 =C2=A0 format on the wire.


one path through the "o= r" statement says "provides one different header", which rea= ds oddly. Perhaps s/different//?


=

This text=C2=A0


=C2=A0 The TAP= S working group intends to describe an (abstract) interface

=C2=A0 =C2=A0for applications to make use of Transpo= rt Services, such that

=C2=A0 =C2=A0a= pplications are no longer directly tied to a specific protocol.


Is po= inting to the TAPS working group, which will conclude someday. It=E2=80=99s= probably better to point to =E2=80=9Cthis specification=E2=80=9D, and it= =E2=80=99s probably good to think of the text as appearing in an RFC, so = =E2=80=9Cintends to describe=E2=80=9D is probably better as =E2=80=9Cdescri= bes=E2=80=9D (at Last Call time, intentions don=E2=80=99t matter).


Th= is text


=C2=A0 =C2=A0Transport protocols

=C2=A0 =C2=A0provide communication between processes that operat= e on network

=C2=A0 =C2=A0endpoints, = which means that they allow for multiplexing of

=C2=A0 =C2=A0communication between the same IP addresses, and no= rmally this

=C2=A0 =C2=A0multiplexing= is achieved using port numbers.


=

Confused me - are any of the transpo= rt protocols you=E2=80=99re describing not using port numbers for multiplex= ing? If not, s/normally//


=

A nit - you have an =E2=80=9CSCPT=E2=80=9D = in Section 3.3.

In this text,<= /font>


=C2=A0 =C2=A0The following three removed limitations directly

=C2=A0 =C2=A0translate into transport features th= at are visible to an application

=C2= =A0 =C2=A0using SCTP: 1) it allows for preservation of message delineations= ; 2)

=C2=A0 =C2=A0these messages, do = not require to be in order or reliably transferred

=C2=A0 =C2=A0unless the application wants it; 3) multi-homin= g is supported.


I=E2=80=99m not parsing the description labeled =E2= =80=9C2)=E2=80=9D. I THINK you=E2=80=99re saying =E2=80=9Cit does not provi= de in-order or reliable delivery unless the application wants that=E2=80=9D= , but I=E2=80=99m not sure.


In this sentence,


=C2=A0 Section = 10 of the SCTP base protocol specification [RFC4960]

=C2=A0 =C2=A0specifies the interaction with the application= (which this RFC calls

=C2=A0 =C2=A0t= he "Upper Layer Protocol" (ULP)).=C2=A0


Your draft is goi= ng to be the default for =E2=80=9Cthis RFC=E2=80=9D when it=E2=80=99s publi= shed as an RFC.=C2=A0 Better to say =E2=80=9Cwhich SCTP calls=E2=80=9D, I t= hink.


In this sentence,=C2=A0


=C2=A0 =C2=A0The functionalit= y exposed to the ULP through the all these APIs is

=C2=A0 =C2=A0considered here.


=E2=80=9CThe all these= =E2=80=9D is garbled.


--001a114f09c80f9ff3055785873c-- From nobody Thu Aug 24 13:24:18 2017 Return-Path: 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 5E55513235A; Thu, 24 Aug 2017 13:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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, T_KAM_HTML_FONT_INVALID=0.01] 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 NulwaCuf-DZr; Thu, 24 Aug 2017 13:24:15 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 4C34E13235B; Thu, 24 Aug 2017 13:24:15 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id x21so3276145ywg.2; Thu, 24 Aug 2017 13:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=w69uh3INaLnU6kRd+t5NP1SNgq35eD+/J0tUadS4SRU=; b=GKMmEjMF1167MY6bSrtgrRBDjiFUlyRVK/4cbL851BVckgD7hy1TovfqZQwMy0azPQ 60stG8/yYcycfixWPJHGJq69FDZoNXxcG5pgs111xFCJk6iwOahIX/R1VSlKK+7FSujh TIdcjUvp5JRXPJ6sog+PcqsT8RLKrHHDiMFkudU2FQYM4vutbJ7kJYDmvAPYLimh5Ups Mu/Z8/cHiUZXgUUfmcxYYtWJRsJtqDTT2fK6bXyPGd3AwUIykXSCKRZrTOep94MQBTrs I0qOyhYGAQvCocszVkGJvSkQjmVcikiXuVE4pWISKtaNdQfeucpQYzsJD49wpUZmWbGA jt0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=w69uh3INaLnU6kRd+t5NP1SNgq35eD+/J0tUadS4SRU=; b=iWJtoKNQ7zg4KscHg9JWqemiYqx6hPGdDbQ3s5mi1mwTkwAh8zSpsZcUF+AKVxsdCS a7wZ/5gEKljsIvLat1PH1LnaezWZ23xpj25lB1biWYRL4/AfYzJyHjQm2n6TmugdCWKQ xKaNddGOj3vQdZ1ANZfUFOyzDlIJ+sVRYVB3gRBFgxc7ezSQXPcLIhw9XAOWWEmn1DMp 4VAoNMAFhUSjZK/MpzZIWb+ttm326zzXYzpvE7nV4sOpGkiNIE2DqkvZY+EVLWo/2o8X T2B2Tk0BMZ/dVRf4tAOiQo+MBF5uvzwpCHYASOWUqaEeZ6tNvdLjilTCCXdPvF1A0nH2 sRSw== X-Gm-Message-State: AHYfb5idjh5cj5S4Vb5R7lBCpTkspkfpeKeGXJdxz5x6l/tdhK8vWHdg zQwzNuMIOqH/vFLBNpnZXnCP6YEMGjvd X-Received: by 10.37.36.144 with SMTP id k138mr5831112ybk.211.1503606254311; Thu, 24 Aug 2017 13:24:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.148 with HTTP; Thu, 24 Aug 2017 13:24:13 -0700 (PDT) From: Spencer Dawkins at IETF Date: Thu, 24 Aug 2017 15:24:13 -0500 Message-ID: To: "taps@ietf.org" Cc: taps-chairs@ietf.org Content-Type: multipart/alternative; boundary="001a113d5c24ab9f100557859ca4" Archived-At: Subject: [Taps] AD Evaluation on the relationship between draft-ietf-taps-transports-usage-06 and draft-ietf-taps-transports-usage-udp-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 20:24:17 -0000 --001a113d5c24ab9f100557859ca4 Content-Type: text/plain; charset="UTF-8" Just to make these documents a bit more digestible by reviewers, ADs, and readers, who will almost certainly be reading them as a set ... I'm OK with the separation of the Pass 1 analysis of UDP(-lite) into a separate draft, but I wish the relationship was a little clearer. It seems like https://tools.ietf.org/html/draft-ietf-taps-transports-usage-06#section-3.4 has more text describing UDP(-lite) than it needs, if it's just going to say "The set of Pass 1 primitives for UDP and UDP-Lite is documented in [FJ16].". If this makes sense to the working group, that description of UDP could be integrated into https://tools.ietf.org/html/draft-ietf-taps-transports-usage-udp-04#section-3, which only has a one-sentence description of UDP itself before beginning its analysis. Is there any chance that each document could provide a pointer to the other document, in the Abstract and Introduction sections, and be clearer about the relationship there? Thanks, Spencer --001a113d5c24ab9f100557859ca4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Just to make these documents a bit more digestible by reviewers, ADs= , and readers, who will almost certainly be reading them as a set ...


<= /span>

= I'm OK with the separation of the Pass 1 analysis of UDP(-lite) into a = separate draft, but I wish the relationship was a little clearer. It seems = like https://tools.ietf.org/html/draft-ietf-taps-transports-us= age-06#section-3.4 has more text describing UDP(-lite) than it needs, i= f it's just going to say "The set of Pass 1 primitives for UDP and= UDP-Lite is documented in [FJ16].".


If this makes sense to t= he working group, that description of UDP could be integrated into <= a href=3D"https://tools.ietf.org/html/draft-ietf-taps-transports-usage-udp-= 04#section-3" style=3D"text-decoration-line:none">https://tools.ietf.or= g/html/draft-ietf-taps-transports-usage-udp-04#section-3, which only has a= one-sentence description of UDP itself before beginning its analysis.


Is there any chance that each document could provide a pointer to the o= ther document, in the Abstract and Introduction sections, and be clearer ab= out the relationship there?


Thanks,


Spencer


--001a113d5c24ab9f100557859ca4-- From nobody Fri Aug 25 10:36:48 2017 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B66D51329AF; Fri, 25 Aug 2017 10:36:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150368259971.19682.17165490158037832513@ietfa.amsl.com> Date: Fri, 25 Aug 2017 10:36:39 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-transports-usage-07.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 17:36:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services WG of the IETF. Title : On the Usage of Transport Features Provided by IETF Transport Protocols Authors : Michael Welzl Michael Tuexen Naeem Khademi Filename : draft-ietf-taps-transports-usage-07.txt Pages : 50 Date : 2017-08-25 Abstract: This document describes how the transport protocols Transmission Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control Transmission Protocol (SCTP), User Datagram Protocol (UDP) and Lightweight User Datagram Protocol (UDP-Lite) expose services to applications and how an application can configure and use the features that make up these services. It also discusses the service provided by the Low Extra Delay Background Transport (LEDBAT) congestion control mechanism. The description results in a set of transport abstractions that can be exported in a TAPS API. For UDP and UDP-Lite, the first step of the protocol analysis -- a discussion of relevant RFC text -- is documented in [FJ16]. XX RFC ED - PLEASE REPLACE [FJ16] WITH THE CORRECT RFC NUMBER XXX The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-transports-usage-07 https://datatracker.ietf.org/doc/html/draft-ietf-taps-transports-usage-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-usage-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 25 10:45:40 2017 Return-Path: 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 0D2431321F6; Fri, 25 Aug 2017 10:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 spcqJbQd0hCG; Fri, 25 Aug 2017 10:45:36 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08F2E1321B0; Fri, 25 Aug 2017 10:45:36 -0700 (PDT) Received: from mail-mx01.uio.no ([129.240.10.26]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dlIfl-0001Mg-NZ; Fri, 25 Aug 2017 19:45:33 +0200 Received: from net-93-146-44-166.cust.vodafonedsl.it ([93.146.44.166] helo=[192.168.6.5]) by mail-mx01.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dlIfk-0008Rf-B5; Fri, 25 Aug 2017 19:45:33 +0200 From: Michael Welzl Message-Id: <83813215-67DC-4518-8909-CCC1E6B42BE3@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_D40F8BA0-D5E8-4D73-A48E-4932B747D6CD" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 25 Aug 2017 19:45:29 +0200 In-Reply-To: Cc: "taps@ietf.org" , taps-chairs@ietf.org To: Spencer Dawkins References: X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx01.uio.no: 93.146.44.166 is neither permitted nor denied by domain of ifi.uio.no) client-ip=93.146.44.166; envelope-from=michawe@ifi.uio.no; helo=[192.168.6.5]; X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 3 sum rcpts/h 5 sum msgs/h 3 total rcpts 56701 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=-0.000, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 2B57CE582AC163EA802CA59496DBFA3E8050CDFA X-UiO-SPAM-Test: remote_host: 93.146.44.166 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 7 max/h 3 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] AD review for draft-ietf-taps-transports-usage-06 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 17:45:39 -0000 --Apple-Mail=_D40F8BA0-D5E8-4D73-A48E-4932B747D6CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi! Thanks a lot - I addressed them all. Details below, in line; cheers, Michael > On Aug 24, 2017, at 10:18 PM, Spencer Dawkins at IETF = wrote: >=20 > These are all editorial. >=20 > Thanks, >=20 > Spencer >=20 > A nit - in this text, >=20 > Transport Protocol: an implementation that provides one or more > different transport services using a specific framing and header > format on the wire. >=20 > one path through the "or" statement says "provides one different = header", which reads oddly. Perhaps s/different//? done. Note that this definition is already published in RFC 8095, but I = think it=E2=80=99s a minor issue - just easier to read with your fix, = and surely not a semantic difference, so I did as you suggest. > This text=20 >=20 > The TAPS working group intends to describe an (abstract) interface > for applications to make use of Transport Services, such that > applications are no longer directly tied to a specific protocol. >=20 > Is pointing to the TAPS working group, which will conclude someday. = It=E2=80=99s probably better to point to =E2=80=9Cthis specification=E2=80= =9D, and it=E2=80=99s probably good to think of the text as appearing in = an RFC, so =E2=80=9Cintends to describe=E2=80=9D is probably better as = =E2=80=9Cdescribes=E2=80=9D (at Last Call time, intentions don=E2=80=99t = matter). Done (replacements as you proposed) > This text >=20 > Transport protocols > provide communication between processes that operate on network > endpoints, which means that they allow for multiplexing of > communication between the same IP addresses, and normally this > multiplexing is achieved using port numbers. >=20 > Confused me - are any of the transport protocols you=E2=80=99re = describing not using port numbers for multiplexing? If not, s/normally// Done > A nit - you have an =E2=80=9CSCPT=E2=80=9D in Section 3.3. Thanks, fixed > In this text, >=20 > The following three removed limitations directly > translate into transport features that are visible to an = application > using SCTP: 1) it allows for preservation of message delineations; = 2) > these messages, do not require to be in order or reliably = transferred > unless the application wants it; 3) multi-homing is supported. >=20 > I=E2=80=99m not parsing the description labeled =E2=80=9C2)=E2=80=9D. = I THINK you=E2=80=99re saying =E2=80=9Cit does not provide in-order or = reliable delivery unless the application wants that=E2=80=9D, but I=E2=80=99= m not sure. You=E2=80=99re right, and I replaced my item 2) with your text proposal > In this sentence, >=20 > Section 10 of the SCTP base protocol specification [RFC4960] > specifies the interaction with the application (which this RFC = calls > the "Upper Layer Protocol" (ULP)).=20 >=20 > Your draft is going to be the default for =E2=80=9Cthis RFC=E2=80=9D = when it=E2=80=99s published as an RFC. Better to say =E2=80=9Cwhich = SCTP calls=E2=80=9D, I think. Done > In this sentence,=20 >=20 > The functionality exposed to the ULP through the all these APIs is > considered here. >=20 > =E2=80=9CThe all these=E2=80=9D is garbled. Fixed. Cheers, Michael --Apple-Mail=_D40F8BA0-D5E8-4D73-A48E-4932B747D6CD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi!

Thanks = a lot - I addressed them all. Details below, in line;

cheers,
Michael


On Aug 24, 2017, at 10:18 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:

These are = all editorial.

Thanks,

Spencer

A nit - in = this text,

  =  Transport Protocol:  an implementation that provides one or = more
  =     different transport services using a specific framing and = header
  =     format on the wire.

one path through the "or" statement says "provides one = different header", which reads oddly. Perhaps = s/different//?
done.  Note that this definition is already = published in RFC 8095, but I think it=E2=80=99s a minor issue - just = easier to read with your fix, and surely not a semantic difference, so I = did as you suggest.


This = text 

  The = TAPS working group intends to describe an (abstract) = interface
   for applications to make use of Transport = Services, such that
   applications are no longer directly tied to a = specific protocol.

Is = pointing to the TAPS working group, which will conclude someday. It=E2=80=99= s probably better to point to =E2=80=9Cthis specification=E2=80=9D, and = it=E2=80=99s probably good to think of the text as appearing in an RFC, = so =E2=80=9Cintends to describe=E2=80=9D is probably better as = =E2=80=9Cdescribes=E2=80=9D (at Last Call time, intentions don=E2=80=99t = matter).

Done  (replacements as you proposed)


This = text

   Transport protocols
  =  provide communication between processes that operate on = network
  =  endpoints, which means that they allow for multiplexing = of
  =  communication between the same IP addresses, and normally = this
  =  multiplexing is achieved using port = numbers.

Confused me - are any of the transport protocols you=E2=80=99re= describing not using port numbers for multiplexing? If not, = s/normally//

Done


A nit - = you have an =E2=80=9CSCPT=E2=80=9D in Section = 3.3.

Thanks, fixed


In this = text,

   The following three removed limitations = directly
  =  translate into transport features that are visible to an = application
   using SCTP: 1) it allows for preservation of = message delineations; 2)
  =  these messages, do not require to be in order or reliably = transferred
   unless the application wants it; 3) multi-homing = is supported.

I=E2=80=99m = not parsing the description labeled =E2=80=9C2)=E2=80=9D. I THINK = you=E2=80=99re saying =E2=80=9Cit does not provide in-order or reliable = delivery unless the application wants that=E2=80=9D, but I=E2=80=99m not = sure.

You=E2=80=99re right, and I replaced my item 2) with = your text proposal


In this = sentence,

  = Section 10 of the SCTP base protocol specification = [RFC4960]
   specifies the interaction with the application = (which this RFC calls
  =  the "Upper Layer Protocol" (ULP)). 

Your draft is going to be the default for =E2=80=9Cthis = RFC=E2=80=9D when it=E2=80=99s published as an RFC.  Better to say = =E2=80=9Cwhich SCTP calls=E2=80=9D, I = think.

Done


In this = sentence, 

  =  The functionality exposed to the ULP through the all these APIs = is
  =  considered here.

=E2=80=9CThe all these=E2=80=9D is = garbled.

Fixed.

Cheers,
Michael

= --Apple-Mail=_D40F8BA0-D5E8-4D73-A48E-4932B747D6CD-- From nobody Fri Aug 25 10:48:07 2017 Return-Path: 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 893E3132961; Fri, 25 Aug 2017 10:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 TRN6R-NnrXty; Fri, 25 Aug 2017 10:48:03 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61D381321F6; Fri, 25 Aug 2017 10:48:03 -0700 (PDT) Received: from mail-mx04.uio.no ([129.240.10.25]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dlIi9-000Bbf-Ep; Fri, 25 Aug 2017 19:48:01 +0200 Received: from net-93-146-44-166.cust.vodafonedsl.it ([93.146.44.166] helo=[192.168.6.5]) by mail-mx04.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dlIi8-0002Kh-M9; Fri, 25 Aug 2017 19:48:01 +0200 From: Michael Welzl Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_FB94379F-BE9B-4216-A338-D641AA9FF47A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 25 Aug 2017 19:47:59 +0200 In-Reply-To: Cc: "taps@ietf.org" , taps-chairs@ietf.org To: Spencer Dawkins References: X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 93.146.44.166 is neither permitted nor denied by domain of ifi.uio.no) client-ip=93.146.44.166; envelope-from=michawe@ifi.uio.no; helo=[192.168.6.5]; X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 4 sum rcpts/h 8 sum msgs/h 4 total rcpts 56704 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=-0.006, HTML_MESSAGE=0.001, T_KAM_HTML_FONT_INVALID=0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 87E63713844FEF80E469921B0324BEB36339D1A8 X-UiO-SPAM-Test: remote_host: 93.146.44.166 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 8 max/h 4 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] AD Evaluation on the relationship between draft-ietf-taps-transports-usage-06 and draft-ietf-taps-transports-usage-udp-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 17:48:05 -0000 --Apple-Mail=_FB94379F-BE9B-4216-A338-D641AA9FF47A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 24, 2017, at 10:24 PM, Spencer Dawkins at IETF = wrote: >=20 > Just to make these documents a bit more digestible by reviewers, ADs, = and readers, who will almost certainly be reading them as a set ... >=20 > I'm OK with the separation of the Pass 1 analysis of UDP(-lite) into a = separate draft, but I wish the relationship was a little clearer. It = seems like = https://tools.ietf.org/html/draft-ietf-taps-transports-usage-06#section-3.= 4 = has more text describing UDP(-lite) than it needs, if it's just = going to say "The set of Pass 1 primitives for UDP and UDP-Lite is = documented in [FJ16].".=20 >=20 > If this makes sense to the working group, that description of UDP = could be integrated into = https://tools.ietf.org/html/draft-ietf-taps-transports-usage-udp-04#sectio= n-3 = , which only has a one-sentence description of UDP itself before = beginning its analysis. I agreed with the authors of the other document that this is the right = way forward. This text in the -usage draft consisted of 3 paragraphs, = followed by the sentence that you quote above (=E2=80=9CThe set of = =E2=80=A6=E2=80=9D). I removed these preceding three paragraphs now. > Is there any chance that each document could provide a pointer to the = other document, in the Abstract and Introduction sections, and be = clearer about the relationship there? While there was a pointer to the other document in the intro of the = -usage draft already, I agree it wasn=E2=80=99t very clear, sorry! I now added, to both the intro and the abstract: "For UDP and UDP-Lite, the first step of the protocol analysis -- a = discussion of relevant RFC text -- is documented in [FJ16].=E2=80=9D Thanks a lot for your review! Cheers, Michael --Apple-Mail=_FB94379F-BE9B-4216-A338-D641AA9FF47A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Aug 24, 2017, at 10:24 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:

Just to make these = documents a bit more digestible by reviewers, ADs, and readers, who will = almost certainly be reading them as a set ...

I'm OK with the separation of the Pass 1 analysis = of UDP(-lite) into a separate draft, but I wish the relationship was a = little clearer. It seems like https://tools.ietf.org/html/draft-ietf-taps-transports-usage-06= #section-3.4 has more text describing UDP(-lite) than it needs, if = it's just going to say "The set of Pass 1 primitives for UDP and = UDP-Lite is documented in [FJ16].".

If this makes sense to the working group, that = description of UDP could be integrated into https://tools.ietf.org/html/draft-ietf-taps-transports-usage-ud= p-04#section-3, which only has a one-sentence = description of UDP itself before beginning its analysis.

I agreed with the authors of the other document = that this is the right way forward. This text in the -usage draft = consisted of 3 paragraphs, followed by the sentence that you quote above = (=E2=80=9CThe set of =E2=80=A6=E2=80=9D). I removed these preceding = three paragraphs now.


Is there any chance that = each document could provide a pointer to the other document, in the = Abstract and Introduction sections, and be clearer about the = relationship there?

While there was a pointer to the other document in = the intro of the -usage draft already, I agree it wasn=E2=80=99t very = clear, sorry!
I now added, to both the intro and the = abstract:

"For UDP and UDP-Lite, the = first step of the protocol analysis -- a discussion of relevant RFC text = -- is documented in [FJ16].=E2=80=9D

Thanks a lot for your review!

Cheers,
Michael

= --Apple-Mail=_FB94379F-BE9B-4216-A338-D641AA9FF47A-- From nobody Fri Aug 25 12:09:54 2017 Return-Path: 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 CBF311329B5; Fri, 25 Aug 2017 12:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 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, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 z74u6J8wsEKJ; Fri, 25 Aug 2017 12:09:51 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 E0664132962; Fri, 25 Aug 2017 12:09:50 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id s143so4011635ywg.0; Fri, 25 Aug 2017 12:09:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vFxHO+QAY1WHzFyRvB6Is1r1YuRCmeUXCZRLuW5c0u8=; b=Epyz4cLLw6S+dMYUZpQVTCHu/VYkv8LR0z00San63Si4b49ipdy187P2grtyTHJVGC TpD8kGP1Xbi82Vw9tBVX7RgIFi0jV0WZfxIcTAd6W8VF9IsHfQW53crhSipQKIseEnD0 ZOAeh+O6AHH4HLGKjXe39goxaF+C7jK6OPDZbehkjuJjrjRq/dElRxtw+SDrS0QN/A92 T0UkqbI1vT8QnjH0PpvCGgqTZZho3f4t+z0vYptOuKrbj0W1mn+3bu8n8SU2iWzIflRv iAiNFhgHUj1UcizpAKA1ZEE7MUnvHCnfIuU6+iU5pmsBLueCwGKzTmZZAL64nqtcg0Mw HB7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vFxHO+QAY1WHzFyRvB6Is1r1YuRCmeUXCZRLuW5c0u8=; b=eu1nLpDsDKAeoyWW/koJcwg3NbcspbqZSuGFljt+Mut8bzYqkKloMtbb+yE5vDaKDB 9HAnhNG+yvwFb1hmPt4eTJ+hN1YZuQ/pXJ/sKvAAVqxBIdd0+9QEHTOmOWJtOvxhiRMX OccseNL/8XZNblxOZe8197TWBUBz46TmYICih0vG9S+NJWFiLW3FPqCNaoec4ANMr0M3 2wjgN91m9KW10Fncd3cg7NvXy44/kWtIv9dNsTqYDqgiYJ9hF++UYTtuRtyfzeJ4JNL0 YwzwflgJwsrIdxkexFgONkmIB6dWPN5lqQrLTlZ1sRb4sViMkRDw99gRxVOfzoF/APVi gMfw== X-Gm-Message-State: AHYfb5jGTqlXxruY5c6cknYv+VIQbO/mESyigiuzVGLDElPFhCTZjOMp KGwBzouJoD69kJQi2LWRGXHhZrz/QQ== X-Received: by 10.37.122.67 with SMTP id v64mr9435530ybc.170.1503688189916; Fri, 25 Aug 2017 12:09:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.148 with HTTP; Fri, 25 Aug 2017 12:09:49 -0700 (PDT) In-Reply-To: References: From: Spencer Dawkins at IETF Date: Fri, 25 Aug 2017 14:09:49 -0500 Message-ID: To: Michael Welzl Cc: "taps@ietf.org" , taps-chairs@ietf.org Content-Type: multipart/alternative; boundary="001a114bc1dc69bd16055798b0f4" Archived-At: Subject: Re: [Taps] AD Evaluation on the relationship between draft-ietf-taps-transports-usage-06 and draft-ietf-taps-transports-usage-udp-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 19:09:53 -0000 --001a114bc1dc69bd16055798b0f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Michael, On Fri, Aug 25, 2017 at 12:47 PM, Michael Welzl wrote: > > On Aug 24, 2017, at 10:24 PM, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > Just to make these documents a bit more digestible by reviewers, ADs, and > readers, who will almost certainly be reading them as a set ... > > I'm OK with the separation of the Pass 1 analysis of UDP(-lite) into a > separate draft, but I wish the relationship was a little clearer. It seem= s > like https://tools.ietf.org/html/draft-ietf-taps-transports- > usage-06#section-3.4 has more text describing UDP(-lite) than it needs, > if it's just going to say "The set of Pass 1 primitives for UDP and > UDP-Lite is documented in [FJ16].". > > If this makes sense to the working group, that description of UDP could b= e > integrated into https://tools.ietf.org/html/draft-ietf-taps-transports- > usage-udp-04#section-3, which only has a one-sentence description of UDP > itself before beginning its analysis. > > > I agreed with the authors of the other document that this is the right wa= y > forward. This text in the -usage draft consisted of 3 paragraphs, followe= d > by the sentence that you quote above (=E2=80=9CThe set of =E2=80=A6=E2=80= =9D). I removed these > preceding three paragraphs now. > > > Is there any chance that each document could provide a pointer to the > other document, in the Abstract and Introduction sections, and be clearer > about the relationship there? > > > While there was a pointer to the other document in the intro of the -usag= e > draft already, I agree it wasn=E2=80=99t very clear, sorry! > I now added, to both the intro and the abstract: > > "For UDP and UDP-Lite, the first step of the protocol analysis -- a > discussion of relevant RFC text -- is documented in [FJ16].=E2=80=9D > > Thanks a lot for your review! > > Cheers, > Michael > Oh, thank you! The fast path to IESG approval is to confuse the ADs as little as possible :-) Spencer --001a114bc1dc69bd16055798b0f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Michael,

On Fri, Aug 25, 2017 at 12:47 PM, Michael Welzl <michawe@ifi.= uio.no> wrote:

On Aug 24, 2017, at 10:24 PM, Spencer Dawkins at IETF <spencerdawkins.= ietf@gmail.com> wrote:

Just to make these documents a bit more dig= estible by reviewers, ADs, and readers, who will almost certainly be readin= g them as a set ...

<= /span>
I'm OK with the separ= ation of the Pass 1 analysis of UDP(-lite) into a separate draft, but I wis= h the relationship was a little clearer. It seems like https://tools.ietf.org/html/draft-ietf-taps-transports-usage-06#section-3.4 has more text describing UDP(-lite) than it need= s, if it's just going to say "The set of Pass 1 primitives for UDP= and UDP-Lite is documented in [FJ16].".

https://tools.ietf.org/html/draft-ietf-taps-tr= ansports-usage-udp-04#section-3, which only has a one-sentence description of UDP itse= lf before beginning its analysis.

I agreed with the authors of the other do= cument that this is the right way forward. This text in the -usage draft co= nsisted of 3 paragraphs, followed by the sentence that you quote above (=E2= =80=9CThe set of =E2=80=A6=E2=80=9D). I removed these preceding three parag= raphs now.


Is there any chance that each document could provide a pointer to = the other document, in the Abstract and Introduction sections, and be clear= er about the relationship there?

While there was a pointer to the other documen= t in the intro of the -usage draft already, I agree it wasn=E2=80=99t very = clear, sorry!
I now added, to both the intro and the abstract:

"For UDP and UDP-Lite, the first step of the pr= otocol analysis -- a discussion of relevant RFC text -- is documented in [F= J16].=E2=80=9D

Thanks a lot for your review!
=

Cheers,
Michael

Oh, thank you! The fast path to IESG approval is to co= nfuse the ADs as little as possible :-)

Spencer=C2= =A0
--001a114bc1dc69bd16055798b0f4-- From nobody Fri Aug 25 12:14:01 2017 Return-Path: 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 D2DC21329B5; Fri, 25 Aug 2017 12:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=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 c3dd18k9RLHD; Fri, 25 Aug 2017 12:13:56 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 7F1B2126E64; Fri, 25 Aug 2017 12:13:56 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id h127so3923922ywf.3; Fri, 25 Aug 2017 12:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Pv/QsVbnepLVvFFzteOgiUH1WIM95gdk28qYPyX7qlo=; b=aE4iq9CGO4EvKIVwYT63qfwad9KSBQ/iafMiCPRi/m62IZe546bHmC2wjOh9Ibb30E pQovSVvRKnAj2mSmTPeHwuGA6da1TLMAGmdM6waZCSD99BexTRJ0XI/y17xBZe9HXinH CUk/kZwocmEJ4+yTRq1kWMV9YKgNE6ACx1yNy2GdwsoGKRLNTudGccFm8JEbwe0FHpuH 2LWfHAh4wHdVVi6hru67Lbqx5OKT16sPXKmPhbfmfRNpnklRBYHAnFXqsT7MdG5rV3Cg 3UGfLqW0IfOu1vw2hE5FdiMYs/YrxlZqGTfjaDS9YxMf+rAfRe8iipa0X7q9lsS9yZ2k MMmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Pv/QsVbnepLVvFFzteOgiUH1WIM95gdk28qYPyX7qlo=; b=BQM6wt1x0ixjb6kFrR9zqjXeRgFHSDttGv35PM2S79wWFkNhAXDS3AHx4PoPKZpas8 DeOy+SJEXr2b/G+ZqUZByFkhVYlQpYaQNUy71ZuXYQ11Ot9/+TTUXezNtBbSqYAi+ocl Od21HY6CrOM7IexxmeHykZg3RZf07NnW8DmdrdC2+tP0LFT2KLyCPJo2sUHic3yOff0X fqo/0vp4sq1Z6HzWjzTb/V2SwiwDGVurCmg9dZiTUWSXTDKaZurL/7QPt3ywaRHlJ/Ct AIoCZi9D95+/ZWCHnS3BewfcszIfKAvl87y+hpg3MvmoBzbrH2XipZBX+nwupc8u7d6m sCBg== X-Gm-Message-State: AHYfb5hkIiEBE2NzrFl9yZybOrrlG4qiFK3obmWrZsrC71CnbUZh4qII txcE9hKpgqQpmuvaVasBtzEWnju9kQ== X-Received: by 10.129.132.212 with SMTP id u203mr9130679ywf.311.1503688435574; Fri, 25 Aug 2017 12:13:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.148 with HTTP; Fri, 25 Aug 2017 12:13:55 -0700 (PDT) In-Reply-To: <83813215-67DC-4518-8909-CCC1E6B42BE3@ifi.uio.no> References: <83813215-67DC-4518-8909-CCC1E6B42BE3@ifi.uio.no> From: Spencer Dawkins at IETF Date: Fri, 25 Aug 2017 14:13:55 -0500 Message-ID: To: Michael Welzl Cc: "taps@ietf.org" , taps-chairs@ietf.org Content-Type: multipart/alternative; boundary="001a114f09c80e2cdf055798bfe1" Archived-At: Subject: Re: [Taps] AD review for draft-ietf-taps-transports-usage-06 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 19:13:59 -0000 --001a114f09c80e2cdf055798bfe1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Michael, On Fri, Aug 25, 2017 at 12:45 PM, Michael Welzl wrote: > Hi! > > Thanks a lot - I addressed them all. Details below, in line; > That all looks fine to me. I'll be putting this and the UDP draft out for Last Call together, if that works for the chairs. Spencer > cheers, > Michael > > > On Aug 24, 2017, at 10:18 PM, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > These are all editorial. > > Thanks, > > Spencer > > A nit - in this text, > > Transport Protocol: an implementation that provides one or more > different transport services using a specific framing and header > format on the wire. > > one path through the "or" statement says "provides one different header", > which reads oddly. Perhaps s/different//? > > > done. Note that this definition is already published in RFC 8095, but I > think it=E2=80=99s a minor issue - just easier to read with your fix, and= surely > not a semantic difference, so I did as you suggest. > > > This text > > The TAPS working group intends to describe an (abstract) interface > for applications to make use of Transport Services, such that > applications are no longer directly tied to a specific protocol. > > Is pointing to the TAPS working group, which will conclude someday. It=E2= =80=99s > probably better to point to =E2=80=9Cthis specification=E2=80=9D, and it= =E2=80=99s probably good to > think of the text as appearing in an RFC, so =E2=80=9Cintends to describe= =E2=80=9D is > probably better as =E2=80=9Cdescribes=E2=80=9D (at Last Call time, intent= ions don=E2=80=99t matter). > > > Done (replacements as you proposed) > > > This text > > Transport protocols > provide communication between processes that operate on network > endpoints, which means that they allow for multiplexing of > communication between the same IP addresses, and normally this > multiplexing is achieved using port numbers. > > Confused me - are any of the transport protocols you=E2=80=99re describin= g not > using port numbers for multiplexing? If not, s/normally// > > > Done > > > A nit - you have an =E2=80=9CSCPT=E2=80=9D in Section 3.3. > > > Thanks, fixed > > > In this text, > > The following three removed limitations directly > translate into transport features that are visible to an application > using SCTP: 1) it allows for preservation of message delineations; 2) > these messages, do not require to be in order or reliably transferred > unless the application wants it; 3) multi-homing is supported. > > I=E2=80=99m not parsing the description labeled =E2=80=9C2)=E2=80=9D. I T= HINK you=E2=80=99re saying =E2=80=9Cit > does not provide in-order or reliable delivery unless the application wan= ts > that=E2=80=9D, but I=E2=80=99m not sure. > > > You=E2=80=99re right, and I replaced my item 2) with your text proposal > > > In this sentence, > > Section 10 of the SCTP base protocol specification [RFC4960] > specifies the interaction with the application (which this RFC calls > the "Upper Layer Protocol" (ULP)). > > Your draft is going to be the default for =E2=80=9Cthis RFC=E2=80=9D when= it=E2=80=99s published > as an RFC. Better to say =E2=80=9Cwhich SCTP calls=E2=80=9D, I think. > > > Done > > > In this sentence, > > The functionality exposed to the ULP through the all these APIs is > considered here. > > =E2=80=9CThe all these=E2=80=9D is garbled. > > > Fixed. > > Cheers, > Michael > > --001a114f09c80e2cdf055798bfe1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Michael,=C2=A0

On Fri, Aug 25, 2017 at 12:45 PM, Michael Welzl <michaw= e@ifi.uio.no> wrote:
Hi!

Thanks a lot - I addre= ssed them all. Details below, in line;

That all looks fine to me. I'll be putting this and the UDP dra= ft out for Last Call together, if that works for the chairs.

=
Spencer
=C2=A0
cheers,
Michael


= On Aug 24, 2017, at 10:18 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail= .com> wrote:

These are all editorial= .

Thanks,

=
Spencer=

A nit - in this text,

=
=C2=A0 =C2=A0Transport Protocol: =C2=A0an implementation that provide= s one or more
=C2=A0 =C2=A0 =C2=A0 different transport services= using a specific framing and header
=C2=A0 =C2=A0 =C2=A0 forma= t on the wire.

one path through the "or= " statement says "provides one different header", which read= s oddly. Perhaps s/different//?

done.=C2=A0 Note that this definition is alre= ady published in RFC 8095, but I think it=E2=80=99s a minor issue - just ea= sier to read with your fix, and surely not a semantic difference, so I did = as you suggest.


This text=C2=A0
<= font face=3D"Arial">
=C2=A0 The TAPS working group intends to describe an (ab= stract) interface
=C2=A0 =C2=A0for applications to make use of = Transport Services, such that
=C2=A0 =C2=A0applications are no = longer directly tied to a specific protocol.

= Is pointing to the TAPS working group, which will conclude someday. It=E2= =80=99s probably better to point to =E2=80=9Cthis specification=E2=80=9D, a= nd it=E2=80=99s probably good to think of the text as appearing in an RFC, = so =E2=80=9Cintends to describe=E2=80=9D is probably better as =E2=80=9Cdes= cribes=E2=80=9D (at Last Call time, intentions don=E2=80=99t matter).

Done = =C2=A0(replacements as you proposed)


Thi= s text

=C2=A0 =C2=A0Transport protocols=
=C2=A0 =C2=A0provide communication between processes that operate on = network
=C2=A0 =C2=A0endpoints, which means that they allow for= multiplexing of
=C2=A0 =C2=A0communication between the same IP= addresses, and normally this
=C2=A0 =C2=A0multiplexing is achi= eved using port numbers.

Confused me - are any= of the transport protocols you=E2=80=99re describing not using port number= s for multiplexing? If not, s/normally//

Done


<= font face=3D"Arial">A nit - you have an =E2=80=9CSCPT=E2=80=9D in Section 3.3.<= /div>

Thanks, fixed


=
In this text,

= =C2=A0 =C2=A0The following three removed limitations directly=
= =C2=A0 =C2=A0translate into transport features that are visible to an appli= cation
=C2=A0 =C2=A0using SCTP: 1) it allows for preservation o= f message delineations; 2)
=C2=A0 =C2=A0these messages, do not = require to be in order or reliably transferred
=C2=A0 =C2=A0unl= ess the application wants it; 3) multi-homing is supported.
I=E2=80=99m not parsing the description labeled =E2=80=9C2)= =E2=80=9D. I THINK you=E2=80=99re saying =E2=80=9Cit does not provide in-or= der or reliable delivery unless the application wants that=E2=80=9D, but I= =E2=80=99m not sure.

You=E2=80=99re right, and I replaced my item 2) with you= r text proposal


In this sentence,

=C2=A0 Section 10 of the SCTP base protocol specificat= ion [RFC4960]
=C2=A0 =C2=A0specifies the interaction with the a= pplication (which this RFC calls
=C2=A0 =C2=A0the "Upper = Layer Protocol" (ULP)).=C2=A0

Your draft = is going to be the default for =E2=80=9Cthis RFC=E2=80=9D when it=E2=80=99s= published as an RFC.=C2=A0 Better to say =E2=80=9Cwhich SCTP calls=E2=80= =9D, I think.

<= /div>Done


In this sentence,=C2=A0

=C2=A0 =C2=A0The functionality exposed to the U= LP through the all these APIs is
=C2=A0 =C2=A0considered here.=

=E2=80=9CThe all these=E2=80=9D is garbled.

Fix= ed.

Cheers,
Michael

=

--001a114f09c80e2cdf055798bfe1-- From nobody Sat Aug 26 04:56:31 2017 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2EC1321B6; Sat, 26 Aug 2017 04:56:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150374858994.25948.5790061538932873889@ietfa.amsl.com> Date: Sat, 26 Aug 2017 04:56:29 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-transports-usage-08.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 11:56:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services WG of the IETF. Title : On the Usage of Transport Features Provided by IETF Transport Protocols Authors : Michael Welzl Michael Tuexen Naeem Khademi Filename : draft-ietf-taps-transports-usage-08.txt Pages : 50 Date : 2017-08-26 Abstract: This document describes how the transport protocols Transmission Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control Transmission Protocol (SCTP), User Datagram Protocol (UDP) and Lightweight User Datagram Protocol (UDP-Lite) expose services to applications and how an application can configure and use the features that make up these services. It also discusses the service provided by the Low Extra Delay Background Transport (LEDBAT) congestion control mechanism. The description results in a set of transport abstractions that can be exported in a TAPS API. For UDP and UDP-Lite, the first step of the protocol analysis -- a discussion of relevant RFC text -- is documented in [FJ16]. XX RFC ED - PLEASE REPLACE [FJ16] WITH THE CORRECT RFC NUMBER XXX The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-transports-usage-08 https://datatracker.ietf.org/doc/html/draft-ietf-taps-transports-usage-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-usage-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Aug 26 05:01:45 2017 Return-Path: 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 1899212EC06 for ; Sat, 26 Aug 2017 05:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 yUJ0TojpiF3x for ; Sat, 26 Aug 2017 05:01:41 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AC1B126B71 for ; Sat, 26 Aug 2017 05:01:41 -0700 (PDT) Received: from mail-mx03.uio.no ([129.240.10.15]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dlZmV-0000xV-36 for taps@ietf.org; Sat, 26 Aug 2017 14:01:39 +0200 Received: from net-93-146-44-166.cust.vodafonedsl.it ([93.146.44.166] helo=[192.168.6.2]) by mail-mx03.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dlZmU-000DEi-8l for taps@ietf.org; Sat, 26 Aug 2017 14:01:39 +0200 From: Michael Welzl Content-Type: multipart/alternative; boundary="Apple-Mail=_3B4F6733-693A-4E5B-8732-637173884582" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 26 Aug 2017 14:01:37 +0200 References: <150374858994.25948.5790061538932873889@ietfa.amsl.com> To: "taps@ietf.org" In-Reply-To: <150374858994.25948.5790061538932873889@ietfa.amsl.com> Message-Id: <75099200-003A-449A-916E-E25D60687AA4@ifi.uio.no> X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.uio.no: 93.146.44.166 is neither permitted nor denied by domain of ifi.uio.no) client-ip=93.146.44.166; envelope-from=michawe@ifi.uio.no; helo=[192.168.6.2]; X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 3 sum msgs/h 2 total rcpts 56717 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.071, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 00A0CB767E4E4FA909A54C764696438B263AFFFE X-UiO-SPAM-Test: remote_host: 93.146.44.166 spam_score: -48 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 16 max/h 4 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-usage-08.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 12:01:44 -0000 --Apple-Mail=_3B4F6733-693A-4E5B-8732-637173884582 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all, This minor update fixes a late oversight - it is a technical change, but = tiny: The draft did talk about SCTP=E2=80=99s =E2=80=9Creceive" call providing = a =E2=80=9Cdelivery number=E2=80=9D. This is, in fact, a mistake in RFC = 4960: = https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-02#section-3.3= 4 = =E2=80=A6 so, to capture this errata, we have now removed this = parameter. Cheers, Michael > On Aug 26, 2017, at 1:56 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Services WG of the IETF. >=20 > Title : On the Usage of Transport Features Provided = by IETF Transport Protocols > Authors : Michael Welzl > Michael Tuexen > Naeem Khademi > Filename : draft-ietf-taps-transports-usage-08.txt > Pages : 50 > Date : 2017-08-26 >=20 > Abstract: > This document describes how the transport protocols Transmission > Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control > Transmission Protocol (SCTP), User Datagram Protocol (UDP) and > Lightweight User Datagram Protocol (UDP-Lite) expose services to > applications and how an application can configure and use the > features that make up these services. It also discusses the service > provided by the Low Extra Delay Background Transport (LEDBAT) > congestion control mechanism. The description results in a set of > transport abstractions that can be exported in a TAPS API. For UDP > and UDP-Lite, the first step of the protocol analysis -- a = discussion > of relevant RFC text -- is documented in [FJ16]. XX RFC ED - PLEASE > REPLACE [FJ16] WITH THE CORRECT RFC NUMBER XXX >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-taps-transports-usage-08 > = https://datatracker.ietf.org/doc/html/draft-ietf-taps-transports-usage-08 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-transports-usage-08 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_3B4F6733-693A-4E5B-8732-637173884582 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear all,

This minor update fixes a late oversight - it is a technical = change, but tiny:

The draft did talk about SCTP=E2=80=99s =E2=80=9Creceive" = call providing a =E2=80=9Cdelivery number=E2=80=9D. This is, in fact, a = mistake in RFC 4960:
https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-02#= section-3.34

=E2=80=A6 so, to capture this errata, we have now removed = this parameter.

Cheers,
Michael


On Aug 26, 2017, at 1:56 PM, internet-drafts@ietf.org wrote:


A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of = the Transport Services WG of the IETF.

=        Title =           : On the = Usage of Transport Features Provided by IETF Transport Protocols
       Authors =         : Michael Welzl
=             &n= bsp;           &nbs= p;Michael Tuexen
=             &n= bsp;           &nbs= p;Naeem Khademi
Filename =        : = draft-ietf-taps-transports-usage-08.txt
Pages =           : 50
= Date =            : = 2017-08-26

Abstract:
=   This document describes how the transport protocols = Transmission
  Control Protocol (TCP), = MultiPath TCP (MPTCP), Stream Control
=   Transmission Protocol (SCTP), User Datagram Protocol (UDP) = and
  Lightweight User Datagram Protocol = (UDP-Lite) expose services to
  applications = and how an application can configure and use the
=   features that make up these services.  It also = discusses the service
  provided by the Low = Extra Delay Background Transport (LEDBAT)
=   congestion control mechanism.  The description results = in a set of
  transport abstractions that can = be exported in a TAPS API.  For UDP
  and = UDP-Lite, the first step of the protocol analysis -- a discussion
  of relevant RFC text -- is documented in [FJ16]. =  XX RFC ED - PLEASE
  REPLACE [FJ16] WITH = THE CORRECT RFC NUMBER XXX


The= IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usa= ge/

There are also htmlized versions = available at:
https://tools.ietf.org/html/draft-ietf-taps-transports-usage-08=
https://datatracker.ietf.org/doc/html/draft-ietf-taps-transport= s-usage-08

A diff from the previous version = is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-transports-= usage-08


Please note that it = may take a couple of minutes from the time of submission
until the htmlized version and diff are available at = tools.ietf.org.

Internet-Drafts are also = available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

= --Apple-Mail=_3B4F6733-693A-4E5B-8732-637173884582-- From nobody Wed Aug 30 00:36:37 2017 Return-Path: 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 1BFBD132DD8; Wed, 30 Aug 2017 00:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 ZpPxMIu58pWE; Wed, 30 Aug 2017 00:36:32 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id BF5E5132D43; Wed, 30 Aug 2017 00:36:32 -0700 (PDT) Received: from Gs-MacBook-Pro.local (at-zeroshell-1.erg.abdn.ac.uk [139.133.217.68]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id DA4FA1B0021A; Wed, 30 Aug 2017 08:35:57 +0100 (BST) Message-ID: <59A66ADF.3090707@erg.abdn.ac.uk> Date: Wed, 30 Aug 2017 08:35:59 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Spencer Dawkins at IETF CC: "taps@ietf.org" , taps-chairs@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] AD review of draft-ietf-taps-transports-usage-udp-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 07:36:36 -0000 Thanks Spencer, I have added new text which I hope addresses these issues in the next revision. Gorry On 24/08/2017, 21:09, Spencer Dawkins at IETF wrote: > I'm actually pretty positive on this draft - most of what follows is > editorial. > > Thanks, > > Spencer > > This text > > This document is intended as a contribution to the Transport Services > (TAPS) working group to assist in analysis of the UDP and UDP-Lite > transport interface. > > Refers to the TAPS working group, which will conclude someday. It’s > probably better if you say that this document provided details for the > Pass 1 analysis of UDP and UDP-Lite that is used in > draft-ietf-taps-transports-usage-06, or something like that. > > In this text > > Neither UDP nor UDP-Lite provide congestion control, retransmission, > nor do they have support to optimise fragmentation and other > transport functions. > > Is “optimizing fragmentation” the best way to describe what UDP is not > doing there? Perhaps “assist in application-level packetization that > would avoid IP fragmentation?” > > I may be very confused about this next one, but in > > Messages passed to the send > primitive that cannot be sent atomically in a datagram will not be > sent by the network layer, generating an error. > > Is this “atomically in an IP datagram”? With IP-level fragmentation > available, I’m not sure what “atomically” is telling the reader. > > If we’re going to “go there”, this text > > The acceptable maximum packet size can be determined using > Packetization-Layer-Path MTU Discovery (PLPMTUD) [RFC4821] or Path > MTU Discovery [RFC1191] [I-D.ietf-6man-rfc1981bis]. > > Makes PMTUD sound like an equally good alternative. What ended up in > -08 of [I-D.ietf-6man-rfc1981bis], and in RFC 8201, and I saw that > your reference was to -06, is > > If ICMPv6 filtering prevents reception of ICMPv6 Packet Too Big > messages, the source will not learn the actual path MTU. > Packetization Layer Path MTU Discovery [RFC4821] does not rely upon > network support for ICMPv6 messages and is therefore considered more > robust than standard PMTUD. It is not susceptible to "black holed" > connections caused by filtering of ICMPv6 message. See [RFC4890] for > recommendations regarding filtering ICMPv6 messages. > > > I know we don’t have a great story for discovering maximum packet > sizes, but I’d like to be at least as discouraging about PMTUD as RFC > 8201, and concerns about earlier versions of the text almost prevented > RFC 8201 from being published as an Internet Standard, and I’m pretty > sure being more encouraging would gather Discusses - > https://datatracker.ietf.org/doc/rfc8201/history/ is instructive. > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Wed Aug 30 02:19:24 2017 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFCF1326FE; Wed, 30 Aug 2017 02:19:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150408476360.21582.7086155403610613451@ietfa.amsl.com> Date: Wed, 30 Aug 2017 02:19:23 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-transports-usage-udp-05.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 09:19:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services WG of the IETF. Title : Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP- Lite) Transport Protocols Authors : Godred Fairhurst Tom Jones Filename : draft-ietf-taps-transports-usage-udp-05.txt Pages : 21 Date : 2017-08-30 Abstract: This is an informational document that describes the transport protocol interface primitives provided by the User Datagram Protocol (UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport protocols. It identifies the datagram services exposed to applications and how an application can configure and use the features offered by the Internet datagram transport service. RFCxxxx documents the usage of transport features provided by IETF transport protocols, describing the way UDP, UDP-Lite and other transport protocols expose their services to applications and how an application can configure and use the features that make up these services. This document provides input to and context for that document, as well as offering a road map to documentation that may be of help to users of the UDP and UDP-Lite protocols. XXX RFC-Ed Note - please replace RFCxxxx with the published RFC number for I-D.ietf-taps-transports-usage, when these documents are both published XXX. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage-udp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-transports-usage-udp-05 https://datatracker.ietf.org/doc/html/draft-ietf-taps-transports-usage-udp-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-usage-udp-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 30 02:21:26 2017 Return-Path: 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 AD9511323F7 for ; Wed, 30 Aug 2017 02:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 olonVvak7NA8 for ; Wed, 30 Aug 2017 02:21:22 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id C5D321321C4 for ; Wed, 30 Aug 2017 02:21:21 -0700 (PDT) Received: from Gs-MacBook-Pro.local (at-zeroshell-1.erg.abdn.ac.uk [139.133.217.68]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 326891B0021A for ; Wed, 30 Aug 2017 10:21:08 +0100 (BST) Message-ID: <59A68384.1010003@erg.abdn.ac.uk> Date: Wed, 30 Aug 2017 10:21:08 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: taps@ietf.org References: <150408476378.21582.12105083383759627869.idtracker@ietfa.amsl.com> In-Reply-To: <150408476378.21582.12105083383759627869.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <150408476378.21582.12105083383759627869.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Taps] Fwd: New Version Notification for draft-ietf-taps-transports-usage-udp-05.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 09:21:25 -0000 This new revision updates the draft to address AD review comments, and to align the source with ID's that have now been published as RFCs. Best wishes, Gorry & Tom -------- Original Message -------- Subject: New Version Notification for draft-ietf-taps-transports-usage-udp-05.txt Date: Wed, 30 Aug 2017 02:19:23 -0700 From: internet-drafts@ietf.org To: Tom Jones , Godred Fairhurst , Gorry Fairhurst A new version of I-D, draft-ietf-taps-transports-usage-udp-05.txt has been successfully submitted by Godred Fairhurst and posted to the IETF repository. Name: draft-ietf-taps-transports-usage-udp Revision: 05 Title: Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP- Lite) Transport Protocols Document date: 2017-08-30 Group: taps Pages: 21 URL: https://www.ietf.org/internet-drafts/draft-ietf-taps-transports-usage-udp-05.txt Status: https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage-udp/ Htmlized: https://tools.ietf.org/html/draft-ietf-taps-transports-usage-udp-05 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-taps-transports-usage-udp-05 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-usage-udp-05 Abstract: This is an informational document that describes the transport protocol interface primitives provided by the User Datagram Protocol (UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport protocols. It identifies the datagram services exposed to applications and how an application can configure and use the features offered by the Internet datagram transport service. RFCxxxx documents the usage of transport features provided by IETF transport protocols, describing the way UDP, UDP-Lite and other transport protocols expose their services to applications and how an application can configure and use the features that make up these services. This document provides input to and context for that document, as well as offering a road map to documentation that may be of help to users of the UDP and UDP-Lite protocols. XXX RFC-Ed Note - please replace RFCxxxx with the published RFC number for I-D.ietf-taps-transports-usage, when these documents are both published XXX. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Wed Aug 30 06:05:40 2017 Return-Path: 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 7BEDF132E97 for ; Wed, 30 Aug 2017 06:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 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, HTML_OBFUSCATE_05_10=0.26, 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 cFtWLQBRs0fE for ; Wed, 30 Aug 2017 06:05:36 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 A2CAC132C2E for ; Wed, 30 Aug 2017 06:05:36 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id s143so30742444ywg.0 for ; Wed, 30 Aug 2017 06:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xCBmbaveQUBunzSEY1sXd79JgjU3swdJL5yRFbK5PWs=; b=Iu2KRBHFYvKT6cG5YIz814iC5mRNj5CDhjCKauV/R74tnZDVqryrrtZahS86HjImhm H7t2GfPrJf3O5hvxwgl2BWuz1g02DJO7N11Cunw7l28jaESVigq6gJgTpA0dJQ9N2a37 PIl0f7baHwiGm5B0YG1GoylTVnqQ2POMYhRWYBY1cEVFWGbfI91ZuNqzpxU6xl09ZaE9 dDG6PliDMZhmBgpfOxHrL9bJGAMh2peo6Jcc2PTeV/PdHmwIE1gUxZp3MtR4ZOsPi5mB /6DmQdTzLTWp96RT9eaoJO2wS7akLFAXVIvUHvj0/kF0slr3QYU8aYJWMvDw6SdRNvtY MyuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xCBmbaveQUBunzSEY1sXd79JgjU3swdJL5yRFbK5PWs=; b=bArH0sG340aKLVunQwGq1M99kuhFQPM0lYTvBVv3wUB1m4M0E6HNRVlCV59iFKQtdv 8IWaZXOz7k9iqWIOxLCx+Dw8Xd8zSh01e09QI61aVSLStIif5wccUeJ0gNV3K1/qUNyJ k626yXxwqgIOxPhP/hZPSa+BmKLCNhm5u7hoI3jHX3rV7uuO7l1c6HZtPTiilhjb7Vzc MGBJZcsy4mPQye4mLoHt0s+m5955DsFKoHzBdxbliApiG0dvDYRYIdiC/eY9MLn6xDon r0BsaasH1iMDBUrsDGShqkUtrJwnJVGcqfcu6pM4xHlTBNlFnZcvveaam8eJ5/BQh36U MB5Q== X-Gm-Message-State: AHYfb5g6oXLTKzQOtCUOgjvNwVwuHJaAtrTUab4RscqoBQVRG3xmh4i9 80G+38zXYqZ6X/hhJcjFpJsURAsdLA== X-Received: by 10.37.124.71 with SMTP id x68mr1079518ybc.211.1504098335567; Wed, 30 Aug 2017 06:05:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.148 with HTTP; Wed, 30 Aug 2017 06:05:35 -0700 (PDT) In-Reply-To: <59A68384.1010003@erg.abdn.ac.uk> References: <150408476378.21582.12105083383759627869.idtracker@ietfa.amsl.com> <59A68384.1010003@erg.abdn.ac.uk> From: Spencer Dawkins at IETF Date: Wed, 30 Aug 2017 08:05:35 -0500 Message-ID: To: "gorry@erg.abdn.ac.uk" Cc: "taps@ietf.org" Content-Type: multipart/alternative; boundary="001a114bd6baffb5d80557f82e3d" Archived-At: Subject: Re: [Taps] Fwd: New Version Notification for draft-ietf-taps-transports-usage-udp-05.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 13:05:38 -0000 --001a114bd6baffb5d80557f82e3d Content-Type: text/plain; charset="UTF-8" Gorry, On Wed, Aug 30, 2017 at 4:21 AM, Gorry Fairhurst wrote: > > This new revision updates the draft to address AD review comments, and to > align the source with ID's that have now been published as RFCs. > It absolutely does. Thank you for that. I've seen updated drafts for both -transport and -transport-udp, and think they're ready for Last Call. Any objection from shepherd/chairs to me pulling the trigger? Thanks, Spencer > > Best wishes, > > Gorry & Tom > > -------- Original Message -------- > Subject: New Version Notification for draft-ietf-taps-transports-usa > ge-udp-05.txt > Date: Wed, 30 Aug 2017 02:19:23 -0700 > From: internet-drafts@ietf.org > To: Tom Jones , Godred Fairhurst < > gorry@erg.abdn.ac.uk>, Gorry Fairhurst > > > > A new version of I-D, draft-ietf-taps-transports-usage-udp-05.txt > has been successfully submitted by Godred Fairhurst and posted to the > IETF repository. > > Name: draft-ietf-taps-transports-usage-udp > Revision: 05 > Title: Features of the User Datagram Protocol (UDP) and > Lightweight UDP (UDP- Lite) Transport Protocols > Document date: 2017-08-30 > Group: taps > Pages: 21 > URL: https://www.ietf.org/internet- > drafts/draft-ietf-taps-transports-usage-udp-05.txt > Status: https://datatracker.ietf.org/ > doc/draft-ietf-taps-transports-usage-udp/ > Htmlized: https://tools.ietf.org/html/d > raft-ietf-taps-transports-usage-udp-05 > Htmlized: https://datatracker.ietf.org/ > doc/html/draft-ietf-taps-transports-usage-udp-05 > Diff: https://www.ietf.org/rfcdiff? > url2=draft-ietf-taps-transports-usage-udp-05 > > Abstract: > This is an informational document that describes the transport > protocol interface primitives provided by the User Datagram Protocol > (UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport > protocols. It identifies the datagram services exposed to > applications and how an application can configure and use the > features offered by the Internet datagram transport service. RFCxxxx > documents the usage of transport features provided by IETF transport > protocols, describing the way UDP, UDP-Lite and other transport > protocols expose their services to applications and how an > application can configure and use the features that make up these > services. This document provides input to and context for that > document, as well as offering a road map to documentation that may be > of help to users of the UDP and UDP-Lite protocols. > > XXX RFC-Ed Note - please replace RFCxxxx with the published RFC > number for I-D.ietf-taps-transports-usage, when these documents are > both published XXX. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > --001a114bd6baffb5d80557f82e3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Gorry,=C2=A0

On Wed, Aug 30, 2017 at 4:21 AM, Gorry Fairhurst <gorry@erg= .abdn.ac.uk> wrote:

This new revision updates the draft to address AD review comments, and to a= lign the source with ID's that have now been published as RFCs.

It absolutely does. Thank you for that.
<= div>
I've seen updated drafts for both -transport and -tr= ansport-udp, and think they're ready for Last Call. Any objection from = shepherd/chairs to me pulling the trigger?

Thanks,=

Spencer
=C2=A0

Best wishes,

Gorry & Tom

-------- Original Message --------
Subject:=C2=A0 =C2=A0 =C2=A0 =C2=A0 New Version Notification for draft-ietf= -taps-transports-usage-udp-05.txt
Date:=C2=A0 =C2=A0Wed, 30 Aug 2017 02:19:23 -0700
From:=C2=A0 =C2=A0internet-drafts@ietf.org
To:=C2=A0 =C2=A0 =C2=A0Tom Jones <tom@erg.abdn.ac.uk>, Godred Fairhurst <gorry@erg.abdn.ac.uk= >, Gorry Fairhurst <gorry@erg.abdn.ac.uk>



A new version of I-D, draft-ietf-taps-transports-usage-udp-05.txt
has been successfully submitted by Godred Fairhurst and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-taps-transports-us= age-udp
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A005
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Features of the User Datagram Prot= ocol (UDP) and Lightweight UDP (UDP- Lite) Transport Protocols
Document date:=C2=A0 2017-08-30
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 taps
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 21
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-i= etf-taps-transports-usage-udp-05.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-taps-transport= s-usage-udp/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-taps-transports-usage-u= dp-05
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-taps-tra= nsports-usage-udp-05
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ta= ps-transports-usage-udp-05

Abstract:
=C2=A0 =C2=A0This is an informational document that describes the transport=
=C2=A0 =C2=A0protocol interface primitives provided by the User Datagram Pr= otocol
=C2=A0 =C2=A0(UDP) and the Lightweight User Datagram Protocol (UDP-Lite) tr= ansport
=C2=A0 =C2=A0protocols.=C2=A0 It identifies the datagram services exposed t= o
=C2=A0 =C2=A0applications and how an application can configure and use the<= br> =C2=A0 =C2=A0features offered by the Internet datagram transport service.= =C2=A0 RFCxxxx
=C2=A0 =C2=A0documents the usage of transport features provided by IETF tra= nsport
=C2=A0 =C2=A0protocols, describing the way UDP, UDP-Lite and other transpor= t
=C2=A0 =C2=A0protocols expose their services to applications and how an
=C2=A0 =C2=A0application can configure and use the features that make up th= ese
=C2=A0 =C2=A0services.=C2=A0 This document provides input to and context fo= r that
=C2=A0 =C2=A0document, as well as offering a road map to documentation that= may be
=C2=A0 =C2=A0of help to users of the UDP and UDP-Lite protocols.

=C2=A0 =C2=A0XXX RFC-Ed Note - please replace RFCxxxx with the published RF= C
=C2=A0 =C2=A0number for I-D.ietf-taps-transports-usage, when these doc= uments are
=C2=A0 =C2=A0both published XXX.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

--001a114bd6baffb5d80557f82e3d-- From nobody Thu Aug 31 08:11:46 2017 Return-Path: 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 95D461321DF for ; Thu, 31 Aug 2017 08:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=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 dSRUGeKESGe7 for ; Thu, 31 Aug 2017 08:11:43 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 88069132742 for ; Thu, 31 Aug 2017 08:11:42 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id r202so9206442wmd.0 for ; Thu, 31 Aug 2017 08:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yRNRwuiKaLTMJz15YYTnUsmw/GweAq4PsrWcWwdVOew=; b=MCBU6HFDc5XpAZzC/DkIKlKXT5UM9O9jDCo7WcmkBwpZm/DaS2gutECVEuzcKhkKuW NpKJsu8tWsK3sua8oAcXrzypfA945MMaBcJkuBgIACPCo+48nts9zjacsddim+fZxo0X ezjR1oXhQz2ZSZq2Z3uBj44Kw3K7C5q0g0k+W5qwQpUNNxEeNc9UAlZN3QhSvjYJr/w8 PMvQuRIsVwqzwfql/qJaVPJ3AJgduLHycAIAhUmHlVXkm3h+LkHFd2HbjWUPOI+ZoaZK ziJUn8kPpwzceyGJArlTJ1nKp5befTjjSHS7rtfiK0eakUtuTM8j+7CK1F6NsjXPN3hM dncg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yRNRwuiKaLTMJz15YYTnUsmw/GweAq4PsrWcWwdVOew=; b=CVOCR7iGDsYWs0qN44QEwaHefTmrikQNHA6zUujARqPpTS7qyRtWu17c77OGfqerml J00IqZEvxYIgADSh+MpBjqZ0+mtEP0bwnAeDoCf2YxtXxLU7m4PkZseWmXGXpV07mXNP yqUIaTQDOiwoHfejSf7MJkfDzCkpMfYXv+HbHa3q4iva2FZbFTilbJroNrCKgTqy2c8W 53aKeDCH3Cy5PT+fQ2aN2ro2JL/L9V5ZcaBmHARg2c5K52e0fpoSsrVQuNxvo16/2HaY xgrkofY1bYMgZxl9IMrd1OCzXvI4keuu7/N2z2fKKkHcy0EOSURmvaAiH6//tGc3raED dLXw== X-Gm-Message-State: AHYfb5i3mmXNXkML11kOMDeFxd9ncd0AJRSHPzgA0OVXvSlqoFMvVgeJ QBvj2LPhhMHtvUmmtmXEQN2tzY2R68CS X-Google-Smtp-Source: ADKCNb6sp3VX2NAW6DNsw04GN3rPlzokMljVNAhFwRiRU+uWrhnc3e+YzhLzD4kiTHoAkuPUW+TG0Bx9TJXs0cIJV7Q= X-Received: by 10.80.179.73 with SMTP id r9mr1824125edd.136.1504192301043; Thu, 31 Aug 2017 08:11:41 -0700 (PDT) MIME-Version: 1.0 References: <150408476378.21582.12105083383759627869.idtracker@ietfa.amsl.com> <59A68384.1010003@erg.abdn.ac.uk> In-Reply-To: From: Aaron Falk Date: Thu, 31 Aug 2017 15:11:30 +0000 Message-ID: To: Spencer Dawkins at IETF , "gorry@erg.abdn.ac.uk" Cc: "taps@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0e4c44c7178b05580e0fc2" Archived-At: Subject: Re: [Taps] Fwd: New Version Notification for draft-ietf-taps-transports-usage-udp-05.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 15:11:45 -0000 --94eb2c0e4c44c7178b05580e0fc2 Content-Type: text/plain; charset="UTF-8" Pull the trigger! On Wed, Aug 30, 2017 at 9:05 AM Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Gorry, > > On Wed, Aug 30, 2017 at 4:21 AM, Gorry Fairhurst > wrote: > >> >> This new revision updates the draft to address AD review comments, and to >> align the source with ID's that have now been published as RFCs. >> > > It absolutely does. Thank you for that. > > I've seen updated drafts for both -transport and -transport-udp, and think > they're ready for Last Call. Any objection from shepherd/chairs to me > pulling the trigger? > > Thanks, > > Spencer > > >> >> Best wishes, >> >> Gorry & Tom >> >> -------- Original Message -------- >> Subject: New Version Notification for >> draft-ietf-taps-transports-usage-udp-05.txt >> Date: Wed, 30 Aug 2017 02:19:23 -0700 >> From: internet-drafts@ietf.org >> To: Tom Jones , Godred Fairhurst < >> gorry@erg.abdn.ac.uk>, Gorry Fairhurst >> >> >> >> A new version of I-D, draft-ietf-taps-transports-usage-udp-05.txt >> has been successfully submitted by Godred Fairhurst and posted to the >> IETF repository. >> >> Name: draft-ietf-taps-transports-usage-udp >> Revision: 05 >> Title: Features of the User Datagram Protocol (UDP) and >> Lightweight UDP (UDP- Lite) Transport Protocols >> Document date: 2017-08-30 >> Group: taps >> Pages: 21 >> URL: >> https://www.ietf.org/internet-drafts/draft-ietf-taps-transports-usage-udp-05.txt >> Status: >> https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage-udp/ >> Htmlized: >> https://tools.ietf.org/html/draft-ietf-taps-transports-usage-udp-05 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-ietf-taps-transports-usage-udp-05 >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-usage-udp-05 >> >> Abstract: >> This is an informational document that describes the transport >> protocol interface primitives provided by the User Datagram Protocol >> (UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport >> protocols. It identifies the datagram services exposed to >> applications and how an application can configure and use the >> features offered by the Internet datagram transport service. RFCxxxx >> documents the usage of transport features provided by IETF transport >> protocols, describing the way UDP, UDP-Lite and other transport >> protocols expose their services to applications and how an >> application can configure and use the features that make up these >> services. This document provides input to and context for that >> document, as well as offering a road map to documentation that may be >> of help to users of the UDP and UDP-Lite protocols. >> >> XXX RFC-Ed Note - please replace RFCxxxx with the published RFC >> number for I-D.ietf-taps-transports-usage, when these documents are >> both published XXX. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> _______________________________________________ >> 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 > --94eb2c0e4c44c7178b05580e0fc2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Pull the trigger!

On Wed, Aug 30, 2017 at 9:05 AM Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.co= m> wrote:
G= orry,=C2=A0

=
On Wed, Aug 30, 2017 at 4:21 AM, Gorry Fairhurst = <gorry@erg.abd= n.ac.uk> wrote:

This new revision updates the draft to address AD review comments, and to a= lign the source with ID's that have now been published as RFCs.

It absolutely does. Thank you fo= r that.

I've seen updated drafts for both -tra= nsport and -transport-udp, and think they're ready for Last Call. Any o= bjection from shepherd/chairs to me pulling the trigger?

Thanks,

Spencer
=C2= =A0

Best wishes,

Gorry & Tom

-------- Original Message --------
Subject:=C2=A0 =C2=A0 =C2=A0 =C2=A0 New Version Notification for draft-ietf= -taps-transports-usage-udp-05.txt
Date:=C2=A0 =C2=A0Wed, 30 Aug 2017 02:19:23 -0700
From:=C2=A0 =C2=A0internet-drafts@ietf.org
To:=C2=A0 =C2=A0 =C2=A0Tom Jones <tom@erg.abdn.ac.uk>, Godred Fairhurst <gorry@erg.abdn.ac.uk= >, Gorry Fairhurst <gorry@erg.abdn.ac.uk>



A new version of I-D, draft-ietf-taps-transports-usage-udp-05.txt
has been successfully submitted by Godred Fairhurst and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-taps-transports-us= age-udp
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A005
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Features of the User Datagram Prot= ocol (UDP) and Lightweight UDP (UDP- Lite) Transport Protocols
Document date:=C2=A0 2017-08-30
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 taps
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 21
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-t= aps-transports-usage-udp-05.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usa= ge-udp/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-taps-transports-usage-udp-05<= br> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-taps-transpor= ts-usage-udp-05
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-tr= ansports-usage-udp-05

Abstract:
=C2=A0 =C2=A0This is an informational document that describes the transport=
=C2=A0 =C2=A0protocol interface primitives provided by the User Datagram Pr= otocol
=C2=A0 =C2=A0(UDP) and the Lightweight User Datagram Protocol (UDP-Lite) tr= ansport
=C2=A0 =C2=A0protocols.=C2=A0 It identifies the datagram services exposed t= o
=C2=A0 =C2=A0applications and how an application can configure and use the<= br> =C2=A0 =C2=A0features offered by the Internet datagram transport service.= =C2=A0 RFCxxxx
=C2=A0 =C2=A0documents the usage of transport features provided by IETF tra= nsport
=C2=A0 =C2=A0protocols, describing the way UDP, UDP-Lite and other transpor= t
=C2=A0 =C2=A0protocols expose their services to applications and how an
=C2=A0 =C2=A0application can configure and use the features that make up th= ese
=C2=A0 =C2=A0services.=C2=A0 This document provides input to and context fo= r that
=C2=A0 =C2=A0document, as well as offering a road map to documentation that= may be
=C2=A0 =C2=A0of help to users of the UDP and UDP-Lite protocols.

=C2=A0 =C2=A0XXX RFC-Ed Note - please replace RFCxxxx with the published RF= C
=C2=A0 =C2=A0number for I-D.ietf-taps-transports-usage, when these document= s are
=C2=A0 =C2=A0both published XXX.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
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
--94eb2c0e4c44c7178b05580e0fc2-- From nobody Thu Aug 31 13:39:50 2017 Return-Path: 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 8DB1F132946 for ; Thu, 31 Aug 2017 13:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=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 3rrEAe2Alxe8 for ; Thu, 31 Aug 2017 13:39:46 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 5F54A13292C for ; Thu, 31 Aug 2017 13:39:46 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id t188so3947028ywb.1 for ; Thu, 31 Aug 2017 13:39:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Coh7fVmbvGly7bWudkXAwvHMIrC5RF5nv90jrcGHdLI=; b=lkZkHGS7u2HPWNGYBMnZBn65yBzeO8N/YOMpNQufa5W8+SktlGECvQilRRDnLADr4Y /VBf655hOgZkjVN0aH2h6PzyOyutG6mzG1LVueqR12Cld8OZEpVNAhVKsnEdjg9BUibY ze3s03eJp+XNhE5slmIBoFY5VephOYo6JIHMD6gxa1G2xHY5NSsJuL2EZXGIPeHC/C1b DMCptbaJfmvSMCjvObpygNkhndozuqahKiqdZtn1dmBY8ljEe0OGP8zSQnwd9GsT+BNI DAXob1eO7UhFldLU3mViWv26ihVgeYhKiWdzAxpmhZpKJCLiZHD6O2pWRaVFYVcAo2wS zBCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Coh7fVmbvGly7bWudkXAwvHMIrC5RF5nv90jrcGHdLI=; b=bH9WF76pqAQEujK904bLivNRcXOpDXvI5trhC8LOty5Ean9D2tybkYxNh/OC5C6vro Q+ERsaSYXL8vXhNjyPPHBTFq7o/7aihB5PFtBxksUm5NDveuB17mCLngqdSZD257yt1P EwemEDThpYV4P8BnYTyj90Y7tqkKHCJxi7f4A2IDORgpCZS0cmBaUx/7iADID5eUcgb8 rbW6y5mWYZEoY5g41Nx5N7gV+ZKlhHtd88XAczokdLm7LobX2ildMJQwQOIVVQKjKzBW kxl1K61fdQGPfm01ym8KroV+KJUiRvYEth+ZbezCLF9BxXLh1ym7GN3Fhr1Psy5xfzZ+ cH+A== X-Gm-Message-State: AHYfb5j8QpZj9CNvDeTVYPpxPhxHsYxksjjpb2jre3lBNW0wtGeFM8Jq 964wEXPsJsMYPQq7B0NbWa7u1TZpuQ== X-Google-Smtp-Source: ADKCNb4jaKFqa/LnnNB+W6FnPo6H1WRH6BR1nFPO8EdwrFhb/63HUzsI0jFG/jK50tglFK19CmM1E2T/lXXUCxh5wI8= X-Received: by 10.129.122.77 with SMTP id v74mr6142986ywc.218.1504211985476; Thu, 31 Aug 2017 13:39:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.148 with HTTP; Thu, 31 Aug 2017 13:39:44 -0700 (PDT) In-Reply-To: References: <150408476378.21582.12105083383759627869.idtracker@ietfa.amsl.com> <59A68384.1010003@erg.abdn.ac.uk> From: Spencer Dawkins at IETF Date: Thu, 31 Aug 2017 15:39:44 -0500 Message-ID: To: Aaron Falk Cc: "gorry@erg.abdn.ac.uk" , "taps@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0a87d60fb10e055812a5e8" Archived-At: Subject: Re: [Taps] Fwd: New Version Notification for draft-ietf-taps-transports-usage-udp-05.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 20:39:48 -0000 --94eb2c0a87d60fb10e055812a5e8 Content-Type: text/plain; charset="UTF-8" Hi, Aaron, On Thu, Aug 31, 2017 at 10:11 AM, Aaron Falk wrote: > Pull the trigger! > Done. It's a pleasure doing business with you (and Zahed, of course). Spencer > > On Wed, Aug 30, 2017 at 9:05 AM Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > >> Gorry, >> >> On Wed, Aug 30, 2017 at 4:21 AM, Gorry Fairhurst >> wrote: >> >>> >>> This new revision updates the draft to address AD review comments, and >>> to align the source with ID's that have now been published as RFCs. >>> >> >> It absolutely does. Thank you for that. >> >> I've seen updated drafts for both -transport and -transport-udp, and >> think they're ready for Last Call. Any objection from shepherd/chairs to me >> pulling the trigger? >> >> Thanks, >> >> Spencer >> >> >>> >>> Best wishes, >>> >>> Gorry & Tom >>> >>> -------- Original Message -------- >>> Subject: New Version Notification for draft-ietf-taps-transports- >>> usage-udp-05.txt >>> Date: Wed, 30 Aug 2017 02:19:23 -0700 >>> From: internet-drafts@ietf.org >>> To: Tom Jones , Godred Fairhurst < >>> gorry@erg.abdn.ac.uk>, Gorry Fairhurst >>> >>> >>> >>> A new version of I-D, draft-ietf-taps-transports-usage-udp-05.txt >>> has been successfully submitted by Godred Fairhurst and posted to the >>> IETF repository. >>> >>> Name: draft-ietf-taps-transports-usage-udp >>> Revision: 05 >>> Title: Features of the User Datagram Protocol (UDP) and >>> Lightweight UDP (UDP- Lite) Transport Protocols >>> Document date: 2017-08-30 >>> Group: taps >>> Pages: 21 >>> URL: https://www.ietf.org/internet-drafts/draft-ietf-taps- >>> transports-usage-udp-05.txt >>> Status: https://datatracker.ietf.org/doc/draft-ietf-taps- >>> transports-usage-udp/ >>> Htmlized: https://tools.ietf.org/html/draft-ietf-taps-transports- >>> usage-udp-05 >>> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-taps- >>> transports-usage-udp-05 >>> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps- >>> transports-usage-udp-05 >>> >>> Abstract: >>> This is an informational document that describes the transport >>> protocol interface primitives provided by the User Datagram Protocol >>> (UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport >>> protocols. It identifies the datagram services exposed to >>> applications and how an application can configure and use the >>> features offered by the Internet datagram transport service. RFCxxxx >>> documents the usage of transport features provided by IETF transport >>> protocols, describing the way UDP, UDP-Lite and other transport >>> protocols expose their services to applications and how an >>> application can configure and use the features that make up these >>> services. This document provides input to and context for that >>> document, as well as offering a road map to documentation that may be >>> of help to users of the UDP and UDP-Lite protocols. >>> >>> XXX RFC-Ed Note - please replace RFCxxxx with the published RFC >>> number for I-D.ietf-taps-transports-usage, when these documents are >>> both published XXX. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> _______________________________________________ >>> 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 >> > --94eb2c0a87d60fb10e055812a5e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Aaron,

On Thu, Aug 31, 2017 at 10:11 AM, Aaron Falk &l= t;aaron.falk@gmai= l.com> wrote:
Pull the trigger!

Done. It's = a pleasure doing business with you (and Zahed, of course).

Spencer
=C2=A0

On Wed, Aug 30, 2017 at 9:05 AM Spencer Dawkins at IETF <spencerdawkins= .ietf@gmail.com> wrote:
Gorry,=C2=A0

=
On Wed, Aug 30, 2017 at 4:21 AM, Gorry Fairhurst= <gorry@erg.abdn.ac.uk> wrote:

This new revision updates the draft to address AD review comments, and to a= lign the source with ID's that have now been published as RFCs.

It absolutely does. Thank you fo= r that.

I've seen updated drafts for both -tra= nsport and -transport-udp, and think they're ready for Last Call. Any o= bjection from shepherd/chairs to me pulling the trigger?

Thanks,

Spencer
=C2= =A0

Best wishes,

Gorry & Tom

-------- Original Message --------
Subject:=C2=A0 =C2=A0 =C2=A0 =C2=A0 New Version Notification for draft-ietf= -taps-transports-usage-udp-05.txt
Date:=C2=A0 =C2=A0Wed, 30 Aug 2017 02:19:23 -0700
From:=C2=A0 =C2=A0internet-drafts@ietf.org
To:=C2=A0 =C2=A0 =C2=A0Tom Jones <tom@erg.abdn.ac.uk>, Godred Fairhurst <gorry@erg.abdn.ac.uk= >, Gorry Fairhurst <gorry@erg.abdn.ac.uk>



A new version of I-D, draft-ietf-taps-transports-usage-udp-05.txt
has been successfully submitted by Godred Fairhurst and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-taps-transports-usage-udp
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A005
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Features of the User Datagram Prot= ocol (UDP) and Lightweight UDP (UDP- Lite) Transport Protocols
Document date:=C2=A0 2017-08-30
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 taps
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 21
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-i= etf-taps-transports-usage-udp-05.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-taps-tran= sports-usage-udp/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-taps-transports-usage-u= dp-05
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-taps-transports-usage-udp-05
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ta= ps-transports-usage-udp-05

Abstract:
=C2=A0 =C2=A0This is an informational document that describes the transport=
=C2=A0 =C2=A0protocol interface primitives provided by the User Datagram Pr= otocol
=C2=A0 =C2=A0(UDP) and the Lightweight User Datagram Protocol (UDP-Lite) tr= ansport
=C2=A0 =C2=A0protocols.=C2=A0 It identifies the datagram services exposed t= o
=C2=A0 =C2=A0applications and how an application can configure and use the<= br> =C2=A0 =C2=A0features offered by the Internet datagram transport service.= =C2=A0 RFCxxxx
=C2=A0 =C2=A0documents the usage of transport features provided by IETF tra= nsport
=C2=A0 =C2=A0protocols, describing the way UDP, UDP-Lite and other transpor= t
=C2=A0 =C2=A0protocols expose their services to applications and how an
=C2=A0 =C2=A0application can configure and use the features that make up th= ese
=C2=A0 =C2=A0services.=C2=A0 This document provides input to and context fo= r that
=C2=A0 =C2=A0document, as well as offering a road map to documentation that= may be
=C2=A0 =C2=A0of help to users of the UDP and UDP-Lite protocols.

=C2=A0 =C2=A0XXX RFC-Ed Note - please replace RFCxxxx with the published RF= C
=C2=A0 =C2=A0number for I-D.ietf-taps-transports-usage, when these doc= uments are
=C2=A0 =C2=A0both published XXX.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
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

--94eb2c0a87d60fb10e055812a5e8-- From nobody Thu Aug 31 13:55:18 2017 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5C61329E3; Thu, 31 Aug 2017 13:55:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk CC: Zaheduzzaman.Sarker@ericsson.com, draft-ietf-taps-transports-usage@ietf.org, taps-chairs@ietf.org, Zaheduzzaman Sarker , taps@ietf.org, spencerdawkins.ietf@gmail.com Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150421291033.16888.1393735251987810236.idtracker@ietfa.amsl.com> Date: Thu, 31 Aug 2017 13:55:10 -0700 Archived-At: Subject: [Taps] Last Call: (On the Usage of Transport Features Provided by IETF Transport Protocols) to Informational RFC X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 20:55:10 -0000 The IESG has received a request from the Transport Services WG (taps) to consider the following document: - 'On the Usage of Transport Features Provided by IETF Transport Protocols' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-09-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes how the transport protocols Transmission Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control Transmission Protocol (SCTP), User Datagram Protocol (UDP) and Lightweight User Datagram Protocol (UDP-Lite) expose services to applications and how an application can configure and use the features that make up these services. It also discusses the service provided by the Low Extra Delay Background Transport (LEDBAT) congestion control mechanism. The description results in a set of transport abstractions that can be exported in a TAPS API. For UDP and UDP-Lite, the first step of the protocol analysis -- a discussion of relevant RFC text -- is documented in [FJ16]. XX RFC ED - PLEASE REPLACE [FJ16] WITH THE CORRECT RFC NUMBER XXX The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Aug 31 13:55:44 2017 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 40629132E23; Thu, 31 Aug 2017 13:55:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk CC: Zaheduzzaman.Sarker@ericsson.com, taps-chairs@ietf.org, spencerdawkins.ietf@gmail.com, Zaheduzzaman Sarker , draft-ietf-taps-transports-usage-udp@ietf.org, taps@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150421294325.16912.13814019575609068027.idtracker@ietfa.amsl.com> Date: Thu, 31 Aug 2017 13:55:43 -0700 Archived-At: Subject: [Taps] Last Call: (Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP- Lite) Transport Protocols) to Informational RFC X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 20:55:43 -0000 The IESG has received a request from the Transport Services WG (taps) to consider the following document: - 'Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP- Lite) Transport Protocols' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-09-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This is an informational document that describes the transport protocol interface primitives provided by the User Datagram Protocol (UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport protocols. It identifies the datagram services exposed to applications and how an application can configure and use the features offered by the Internet datagram transport service. RFCxxxx documents the usage of transport features provided by IETF transport protocols, describing the way UDP, UDP-Lite and other transport protocols expose their services to applications and how an application can configure and use the features that make up these services. This document provides input to and context for that document, as well as offering a road map to documentation that may be of help to users of the UDP and UDP-Lite protocols. XXX RFC-Ed Note - please replace RFCxxxx with the published RFC number for I-D.ietf-taps-transports-usage, when these documents are both published XXX. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage-udp/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage-udp/ballot/ No IPR declarations have been submitted directly on this I-D.