From nobody Fri Sep 1 02:44:32 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 9608D133051; Fri, 1 Sep 2017 02:44:25 -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: <150425906557.4549.782078220807235623@ietfa.amsl.com> Date: Fri, 01 Sep 2017 02:44:25 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-transports-usage-udp-06.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, 01 Sep 2017 09:44:26 -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-06.txt Pages : 22 Date : 2017-09-01 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-06 https://datatracker.ietf.org/doc/html/draft-ietf-taps-transports-usage-udp-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-usage-udp-06 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 Tue Sep 5 04:20:49 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 F276413293F; Tue, 5 Sep 2017 04:20:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Roni Even To: Cc: ietf@ietf.org, draft-ietf-taps-transports-usage.all@ietf.org, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150461043596.28616.17788381104851881245@ietfa.amsl.com> Date: Tue, 05 Sep 2017 04:20:35 -0700 Archived-At: Subject: [Taps] Genart telechat review of draft-ietf-taps-transports-usage-08 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: Tue, 05 Sep 2017 11:20:36 -0000 Reviewer: Roni Even Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-taps-transports-usage-?? Reviewer: Roni Even Review Date: 2017-09-05 IETF LC End Date: 2017-09-14 IESG Telechat date: 2017-09-14 Summary: The document is ready with nits to be published as informational RFC Major issues: Minor issues: Nits/editorial comments: 1. I think it will be better to have the introduction as section 1 and the terminology as section 2 2.In section 3.1 in "open" I did not understand the following sentence "more than TCP's maximum segment size (minus options used in the SYN)" 3. in section 6 "The views expressed are solely those of the author(s)" suggest removing the sentence since this document expresses the views of the WG. 4. A general readability comment when describing primitives in pass 2 the structure is PRIMITIVENAME.PROTOCOL: Pass 1 primitive / event: Parameters: Returns: Comments: but it will be easier to read if there is for example a line space between the paragraphs. look for example at CONNECT.TCP: it is difficult to see where parameters finish and comment starts From nobody Mon Sep 11 07:14:05 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 76D1B1326ED; Mon, 11 Sep 2017 07:13:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-taps-transports-usage@ietf.org, Zaheduzzaman Sarker , taps-chairs@ietf.org, Zaheduzzaman.Sarker@ericsson.com, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150513923847.9634.7623954738882816912.idtracker@ietfa.amsl.com> Date: Mon, 11 Sep 2017 07:13:58 -0700 Archived-At: Subject: [Taps] Eric Rescorla's No Record on draft-ietf-taps-transports-usage-08: (with COMMENT) 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, 11 Sep 2017 14:13:58 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-taps-transports-usage-08: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have not yet completed my review of this document, but I note that it is targeted for Informative but also contains RFC2119 normative language, e.g., "TCP implementations MUST NOT use TFO by default, but only use TFO if requested explicitly by the application on a per-service-port basis." If the intent is that this is to be Informational then this should be removed, and if it's to be BCP, then it needs to go back to IETF-LC for that From nobody Mon Sep 11 07:23:29 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 BC3E113309E; Mon, 11 Sep 2017 07:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 od25ORIzDi0M; Mon, 11 Sep 2017 07:23:14 -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 277C413309C; Mon, 11 Sep 2017 07:23:11 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id E584B1B0017A; Mon, 11 Sep 2017 15:22:42 +0100 (BST) Message-ID: <59B69C32.60306@erg.abdn.ac.uk> Date: Mon, 11 Sep 2017 15:22:42 +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: Eric Rescorla CC: The IESG , draft-ietf-taps-transports-usage@ietf.org, taps-chairs@ietf.org, Zaheduzzaman.Sarker@ericsson.com, taps@ietf.org References: <150513923847.9634.7623954738882816912.idtracker@ietfa.amsl.com> In-Reply-To: <150513923847.9634.7623954738882816912.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Taps] Eric Rescorla's No Record on draft-ietf-taps-transports-usage-08: (with COMMENT) 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, 11 Sep 2017 14:23:22 -0000 Hi Eric, The text you mention is the final para of section 3 of RFC 7413. I suspect the most appropriate correction would be to identify the section number in the text, as done for other cited RFCs, e.g. Section 3 of RFC7413 states that a TCP implementations MUST NOT use TFO by default, but only use TFO if requested explicitly by the application on a per-service-port basis. Gorry On 11/09/2017, 15:13, Eric Rescorla wrote: > Eric Rescorla has entered the following ballot position for > draft-ietf-taps-transports-usage-08: No Record > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I have not yet completed my review of this document, but I note that it is > targeted for Informative but also contains RFC2119 normative language, e.g., > > "TCP implementations MUST NOT use > TFO by default, but only use TFO if requested explicitly by the > application on a per-service-port basis." > > If the intent is that this is to be Informational then this should be removed, > and if it's to be BCP, then it needs to go back to IETF-LC for that > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Mon Sep 11 07:26:32 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 7320B13309E; Mon, 11 Sep 2017 07:26:30 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 5fvE9euBP61e; Mon, 11 Sep 2017 07:26:28 -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 D8DC41326ED; Mon, 11 Sep 2017 07:26:27 -0700 (PDT) Received: from mail-mx05.uio.no ([129.240.10.49]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1drPfN-000Dfe-J6; Mon, 11 Sep 2017 16:26:25 +0200 Received: from [160.80.103.171] (helo=[192.168.0.103]) by mail-mx05.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1drPfN-000AUk-0B; Mon, 11 Sep 2017 16:26:25 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Welzl In-Reply-To: <150513923847.9634.7623954738882816912.idtracker@ietfa.amsl.com> Date: Mon, 11 Sep 2017 16:26:27 +0200 Cc: The IESG , draft-ietf-taps-transports-usage@ietf.org, Zaheduzzaman Sarker , taps-chairs@ietf.org, "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <58B1BCCC-0550-4E53-8B85-D70D7F25DA61@ifi.uio.no> References: <150513923847.9634.7623954738882816912.idtracker@ietfa.amsl.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx05.uio.no: 160.80.103.171 is neither permitted nor denied by domain of ifi.uio.no) client-ip=160.80.103.171; envelope-from=michawe@ifi.uio.no; helo=[192.168.0.103]; X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 1 sum rcpts/h 7 sum msgs/h 1 total rcpts 56998 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 4A7B731AACD4EFD96E01A72DE8C7C6A73D56A0DF X-UiO-SPAM-Test: remote_host: 160.80.103.171 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 16 max/h 5 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] Eric Rescorla's No Record on draft-ietf-taps-transports-usage-08: (with COMMENT) 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, 11 Sep 2017 14:26:30 -0000 Hi, Sorry for the noise and for my ignorance regarding IETF style here - this is indeed a mistake, in that the statement that you mention about = TFO was supposed to be a quote from RFC 7413, but doesn=E2=80=99t stand = out as such (so, good catch, thanks!). How do I make this clear enough to avoid a procedural problem - e.g., = would this be ok? *** TCP implementations MUST NOT use TFO by default, but only use TFO if requested explicitly by the application on a per-service- port basis [RFC7413]. *** Or would it have to be, e.g.: *** [RFC7413] states that TCP implementations MUST NOT use TFO by default, = but only use TFO if requested explicitly by the application on a per-service- port basis [RFC7413]. *** Thanks again, cheers, Michael > On Sep 11, 2017, at 4:13 PM, Eric Rescorla wrote: >=20 > Eric Rescorla has entered the following ballot position for > draft-ietf-taps-transports-usage-08: No Record >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I have not yet completed my review of this document, but I note that = it is > targeted for Informative but also contains RFC2119 normative language, = e.g., >=20 > "TCP implementations MUST NOT use > TFO by default, but only use TFO if requested explicitly by the > application on a per-service-port basis." >=20 > If the intent is that this is to be Informational then this should be = removed, > and if it's to be BCP, then it needs to go back to IETF-LC for that >=20 >=20 From nobody Mon Sep 11 08:00: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 4D7771330AE for ; Mon, 11 Sep 2017 07:59:59 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.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 yupFcFm2E9KC for ; Mon, 11 Sep 2017 07:59:58 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94ABB132D48 for ; Mon, 11 Sep 2017 07:59:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=u6TNrnEcBEwRZD8xBsqL1GjbXlGf3P/WZnRFCNFQ1BkL5UyQyIl9jCr3vBSks0me2SL5pnN8bmUYig98zDrQPRmV4j/gNNtyLgaep5oNB0l9zQ9m7K6xRktXCaFS83kd/aNmyZR+8fH6AdGxJKCPIty0YnNqkAH8qA3df/PWYmM=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 13583 invoked from network); 11 Sep 2017 16:53:14 +0200 Received: from pd9e11f83.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (217.225.31.131) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 11 Sep 2017 16:53:14 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <58B1BCCC-0550-4E53-8B85-D70D7F25DA61@ifi.uio.no> Date: Mon, 11 Sep 2017 16:53:12 +0200 Cc: Eric Rescorla , draft-ietf-taps-transports-usage@ietf.org, taps-chairs@ietf.org, The IESG , Zaheduzzaman Sarker , "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <080A5C38-FE57-431D-B35A-638DA5258639@kuehlewind.net> References: <150513923847.9634.7623954738882816912.idtracker@ietfa.amsl.com> <58B1BCCC-0550-4E53-8B85-D70D7F25DA61@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20170911145314.13573.3270@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [Taps] Eric Rescorla's No Record on draft-ietf-taps-transports-usage-08: (with COMMENT) 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, 11 Sep 2017 14:59:59 -0000 Hi Micheal,=20 I also just caught that, assuming is was an copy-and-past left over; I = think the best options are either: *** [RFC7413] states that TCP implementations "MUST NOT use TFO by default, = but only use TFO if requested explicitly by the application on a = per-service-port basis" [RFC7413]. *** -> explicit citation or=20 *** TCP implementations can not use TFO by default, but only use TFO if = requested explicitly by the application on a per-service-port basis = [RFC7413]. *** -> no normative language Mirja > Am 11.09.2017 um 16:26 schrieb Michael Welzl : >=20 > Hi, >=20 > Sorry for the noise and for my ignorance regarding IETF style here - >=20 > this is indeed a mistake, in that the statement that you mention about = TFO was supposed to be a quote from RFC 7413, but doesn=E2=80=99t stand = out as such (so, good catch, thanks!). >=20 > How do I make this clear enough to avoid a procedural problem - e.g., = would this be ok? > *** > TCP implementations MUST NOT use TFO by default, but only > use TFO if requested explicitly by the application on a per-service- > port basis [RFC7413]. > *** >=20 > Or would it have to be, e.g.: > *** > [RFC7413] states that TCP implementations MUST NOT use TFO by default, = but only > use TFO if requested explicitly by the application on a per-service- > port basis [RFC7413]. > *** >=20 > Thanks again, >=20 > cheers, > Michael >=20 >=20 >=20 >> On Sep 11, 2017, at 4:13 PM, Eric Rescorla wrote: >>=20 >> Eric Rescorla has entered the following ballot position for >> draft-ietf-taps-transports-usage-08: No Record >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> I have not yet completed my review of this document, but I note that = it is >> targeted for Informative but also contains RFC2119 normative = language, e.g., >>=20 >> "TCP implementations MUST NOT use >> TFO by default, but only use TFO if requested explicitly by the >> application on a per-service-port basis." >>=20 >> If the intent is that this is to be Informational then this should be = removed, >> and if it's to be BCP, then it needs to go back to IETF-LC for that >>=20 >>=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Mon Sep 11 08:44: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 43D5E1330C2; Mon, 11 Sep 2017 08:44:17 -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 F1djbDyoyvgN; Mon, 11 Sep 2017 08:44:15 -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 8582F1326FE; Mon, 11 Sep 2017 08:44:15 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id r85so22406716ywg.1; Mon, 11 Sep 2017 08:44:15 -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=riNtZmuxddBBOzk+x8VAYXOZl7QVnAHbEGQ4LVaUsCI=; b=Cm9PgRMueGD30Dh5939BiA+ZQoa6dpO5NpUzezVC4uqx6SYdzGw2NR1tdcQV67dab6 heq9gifuQsRHY7ISuBRO0zFoFu3+qVz0CLesciXQpGjIaGrSmYsv3yH3izdGE+bQWbWn kxXhtXMaNESe69JbI1lTzMWLeGZTC1I0OxZC/UfzMQotK3/dXk/1Hw1n9nQ37MYs0AdQ ZoKE0s9mOvsGgjS4Im+83iDH8wSNvUNT11fek2AcLQRkvOsjOIPfyReHlLtSKL67eEiS qZ/4u9MIflRZLjL5RfHPlaqHooRZmbX0a4/lTswPM+kVzPHbFg5EChWm6YmEDxNTYoDD de8A== 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=riNtZmuxddBBOzk+x8VAYXOZl7QVnAHbEGQ4LVaUsCI=; b=QN6b6U/N9gzK8ItXW3rWMrtknBzj3rfrNWTFk4ggmIiBjU3pHi3knmNtY5C4QiQZ08 MZH4uFgAyOR2mZHIMC8VLvNQcmas2nbQ7Na95zo3ryHljhz16lVQMkAKVno78S8fRDhi tLkrSIy32lkq5IQ/Tt7E6mIu2yT7YFmeVBON/kxKHE3sdHYM4ODYEoL27bpAVN+Asu+r UlwRlUrdQHKLyWjmu5UgSr8Kgp7lpM7CyMM8/f0Aa/VHp4UOlTqigYzJQ+k01dFmPLPk 2b0pwMUhswRMhagvxHGgJ2DM5AA/VyZydB9kcuIX1qD73+dTX/y4sWkyNwBUvMbxISLR 3row== X-Gm-Message-State: AHPjjUinx+cnFhZN2C1D6fathubRgNZj7UxxMuNVl4nptOWgWAgT0IC9 fVbsb6RNYcrxpCWLcSGBaL/zVZSPdA== X-Google-Smtp-Source: AOwi7QDmAta1Xx0lyhlfSUbs8y/AYbWKNDyvgyG/JCuiA7Qkk7l6gP1kYoAYCZcI+/DUwcc9DzpP8cALVqXUJLRluo0= X-Received: by 10.129.148.129 with SMTP id l123mr10728479ywg.339.1505144654482; Mon, 11 Sep 2017 08:44:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.15 with HTTP; Mon, 11 Sep 2017 08:44:13 -0700 (PDT) In-Reply-To: <080A5C38-FE57-431D-B35A-638DA5258639@kuehlewind.net> References: <150513923847.9634.7623954738882816912.idtracker@ietfa.amsl.com> <58B1BCCC-0550-4E53-8B85-D70D7F25DA61@ifi.uio.no> <080A5C38-FE57-431D-B35A-638DA5258639@kuehlewind.net> From: Spencer Dawkins at IETF Date: Mon, 11 Sep 2017 10:44:13 -0500 Message-ID: To: "Mirja Kuehlewind (IETF)" Cc: Michael Welzl , Eric Rescorla , taps-chairs@ietf.org, draft-ietf-taps-transports-usage@ietf.org, Zaheduzzaman Sarker , The IESG , "taps@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c07b5107750ba0558ebccf6" Archived-At: Subject: Re: [Taps] Eric Rescorla's No Record on draft-ietf-taps-transports-usage-08: (with COMMENT) 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, 11 Sep 2017 15:44:17 -0000 --94eb2c07b5107750ba0558ebccf6 Content-Type: text/plain; charset="UTF-8" FWIW, On Mon, Sep 11, 2017 at 9:53 AM, Mirja Kuehlewind (IETF) < ietf@kuehlewind.net> wrote: > Hi Micheal, > > I also just caught that, assuming is was an copy-and-past left over; I > think the best options are either: > > *** > [RFC7413] states that TCP implementations "MUST NOT use TFO by default, > but only use TFO if requested explicitly by the application on a > per-service-port basis" [RFC7413]. > *** > -> explicit citation > > or > > *** > TCP implementations can not use TFO by default, but only use TFO if > requested explicitly by the application on a per-service-port basis > [RFC7413]. > *** > -> no normative language Either of these would work. My suggestion is that the document use the first option, because it's perfectly accurate, and likely more accessible for future readers, but I'm happy to support either option for this text. Spencer --94eb2c07b5107750ba0558ebccf6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FWIW,

On Mon, Sep 11, 2017 at 9:53 AM, Mirja Kuehlewind (IETF) <ietf@kueh= lewind.net> wrote:
Hi Miche= al,

I also just caught that, assuming is was an copy-and-past left over; I thin= k the best options are either:

***
[RFC7413] states that TCP implementations "MUST NOT use TFO by default= , but only use TFO if requested explicitly by the application on a per-serv= ice-port basis" [RFC7413].
***
-> explicit citation

or

***
TCP implementations can not use TFO by default, but only use TFO if request= ed explicitly by the application on a per-service-port basis [RFC7413].
***
-> no normative language

Either of these= would work. My suggestion is that the document use the first option, becau= se it's perfectly accurate, and likely more accessible for future reade= rs, but I'm happy to support either option for this text.
Spencer=C2=A0
--94eb2c07b5107750ba0558ebccf6-- From nobody Mon Sep 11 08:48:56 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 65AD5133133; Mon, 11 Sep 2017 08:48:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-taps-transports-usage@ietf.org, Zaheduzzaman Sarker , taps-chairs@ietf.org, Zaheduzzaman.Sarker@ericsson.com, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150514493541.9712.4517222531106973475.idtracker@ietfa.amsl.com> Date: Mon, 11 Sep 2017 08:48:55 -0700 Archived-At: Subject: [Taps] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-taps-transports-usage-08=3A_=28with_COMMENT=29?= 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, 11 Sep 2017 15:48:55 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-taps-transports-usage-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Fully editorial comments: - First paragraph in intro: s/underlying TAPS system/underlying Transport Services (TAPS) system/ - This should not use normative language: "TCP implementations MUST NOT use TFO by default..." (see comment from EKR) - Also there is half a sentence missing in the same paragraph: "more than TCP's maximum segment size (minus options used in the SYN)." - s/Differentiated Services (diffuser)/Differentiated Services (diffserv)/ or s/Differentiated Services (diffuser)/Differentiated Services (DiffServ)/ - I (still) don't understand why draft-ietf-taps-transports-usage-udp was kept in a separate document, given there is even a separate empty section in this doc. You basically have to stop reading there, go to the other doc, read it, and come back. That doesn't make sense to me. From nobody Mon Sep 11 09:05:34 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 4E281133133; Mon, 11 Sep 2017 09:05:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-taps-transports-usage-udp@ietf.org, Zaheduzzaman Sarker , taps-chairs@ietf.org, Zaheduzzaman.Sarker@ericsson.com, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150514592831.9770.11967079209247120832.idtracker@ietfa.amsl.com> Date: Mon, 11 Sep 2017 09:05:28 -0700 Archived-At: Subject: [Taps] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-taps-transports-usage-udp-06=3A_=28with_COMMENT=29?= 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, 11 Sep 2017 16:05:28 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-taps-transports-usage-udp-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage-udp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Question: Given this is pass 1 (describing the (abstract) API as defined in the spec), why is there a LISTEN for UDP? From nobody Mon Sep 11 10:38:43 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 2DE83133190 for ; Mon, 11 Sep 2017 10:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 y_pS8H7U2Ugs for ; Mon, 11 Sep 2017 10:38:39 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 B294F133194 for ; Mon, 11 Sep 2017 10:38:30 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id v36so18109371ioi.1 for ; Mon, 11 Sep 2017 10:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wv6uYHchAu/XcEk8qLqQt0zKjaTzJ63LzXovit7aznI=; b=dat4M9ejvQiDLRXIBkbsfW4EYjAs5lVDBJDE7OEFamH1A0BwJxtXBKopr3sgxVsICT Sr3aiEJ4KSGpQG5DlPy/AZ8kg1DVixZ4h+xj6MGXgYVeF9n/iTaB2BmTd76wTUOZQ87+ MIy/0G8FexeBmp/WC+sXqAgA8T7Yyp8j5MqxBd5TGEKFrjZi7rYKdk6bOUEQ0eSjLmCY hybpkRsIJ8qE+lfA5ImYU/rgA7I7Lvrwntj5+1R6OlvY/KPgKcSAenRKuftbYoxhwYdL /+8pYpvTV+JyQIkKRn/APBiAPMiKvG7NGdxY+oU4rwzTbEWKceCk+a4uylNMipSNhRMz eIww== 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=wv6uYHchAu/XcEk8qLqQt0zKjaTzJ63LzXovit7aznI=; b=S+aLXk/KjFslyY2A9JmnK8bCnYSzLuQuysXV7oQiAjFi1jaqukRYPy0QCPzFwRSgYA be9owjh2bgXOkhVg+y/1H0FO8pKVVvnyCk6yzb1E03nyg/o6lGt+NbHmvR8lNSwC9wA7 aKFV88mfuXWtBmnxLPx95U+QP177ZfhCHAvZmaRK9VdFTZn71vgLECEx3hjUjyQXyojn x3DWO4J27NN1zX1AvbBKZtCWchBn7PY75yhXhBUmeqSAqJcxNnbltULLe0aK6haayZNY VYGwuZfsIfnZwlaZ03WH95bjSD3XdoPnj7KDVz7FnrQeUT+Imkchs/qgB5EzxMXdNKD3 dgEg== X-Gm-Message-State: AHPjjUj6JHGtDp0a3FCEahO6RfOyKUXnr7XFbd2nUXZdskEmiZ9NPNTy aVKYIkvlUXYuh9hw8Pa2g/KL53hoNttQ X-Google-Smtp-Source: AOwi7QBzK8qF4ltdOf+RvwIyukFTlEOcEfLrf2UwZQPcpnuxKmBlSai0dReDhBD3bu+hyfkjWzrCtAVJKXFg7dziB7M= X-Received: by 10.202.224.130 with SMTP id x124mr10888857oig.100.1505151509876; Mon, 11 Sep 2017 10:38:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.10.71 with HTTP; Mon, 11 Sep 2017 10:37:49 -0700 (PDT) In-Reply-To: References: <150513923847.9634.7623954738882816912.idtracker@ietfa.amsl.com> <58B1BCCC-0550-4E53-8B85-D70D7F25DA61@ifi.uio.no> <080A5C38-FE57-431D-B35A-638DA5258639@kuehlewind.net> From: Eric Rescorla Date: Mon, 11 Sep 2017 10:37:49 -0700 Message-ID: To: Spencer Dawkins at IETF Cc: "Mirja Kuehlewind (IETF)" , Michael Welzl , taps-chairs@ietf.org, draft-ietf-taps-transports-usage@ietf.org, Zaheduzzaman Sarker , The IESG , "taps@ietf.org" Content-Type: multipart/alternative; boundary="001a113d376a1469260558ed65ce" Archived-At: Subject: Re: [Taps] Eric Rescorla's No Record on draft-ietf-taps-transports-usage-08: (with COMMENT) 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, 11 Sep 2017 17:38:41 -0000 --001a113d376a1469260558ed65ce Content-Type: text/plain; charset="UTF-8" That WFM On Mon, Sep 11, 2017 at 8:44 AM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > FWIW, > > On Mon, Sep 11, 2017 at 9:53 AM, Mirja Kuehlewind (IETF) < > ietf@kuehlewind.net> wrote: > >> Hi Micheal, >> >> I also just caught that, assuming is was an copy-and-past left over; I >> think the best options are either: >> >> *** >> [RFC7413] states that TCP implementations "MUST NOT use TFO by default, >> but only use TFO if requested explicitly by the application on a >> per-service-port basis" [RFC7413]. >> *** >> -> explicit citation >> >> or >> >> *** >> TCP implementations can not use TFO by default, but only use TFO if >> requested explicitly by the application on a per-service-port basis >> [RFC7413]. >> *** >> -> no normative language > > > Either of these would work. My suggestion is that the document use the > first option, because it's perfectly accurate, and likely more accessible > for future readers, but I'm happy to support either option for this text. > > Spencer > --001a113d376a1469260558ed65ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That WFM

On Mon, Sep 11, 2017 at 8:44 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
FWIW,
On Mon, Sep 11, 2017 at 9:53 A= M, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:
Hi Micheal,

I also just caught that, assuming is was an copy-and-past left over; I thin= k the best options are either:

***
[RFC7413] states that TCP implementations "MUST NOT use TFO by default= , but only use TFO if requested explicitly by the application on a per-serv= ice-port basis" [RFC7413].
***
-> explicit citation

or

***
TCP implementations can not use TFO by default, but only use TFO if request= ed explicitly by the application on a per-service-port basis [RFC7413].
***
-> no normative language

Either o= f these would work. My suggestion is that the document use the first option= , because it's perfectly accurate, and likely more accessible for futur= e readers, but I'm happy to support either option for this text.
<= span class=3D"HOEnZb">

Spencer= =C2=A0

--001a113d376a1469260558ed65ce-- From nobody Tue Sep 12 09:33:14 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 F3569133076; Tue, 12 Sep 2017 09:33:06 -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 uGb-eTjgRyhn; Tue, 12 Sep 2017 09:33:04 -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 4ABF213308D; Tue, 12 Sep 2017 09:33:04 -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 90BE31B00040; Tue, 12 Sep 2017 17:32:35 +0100 (BST) Message-ID: <59B80C23.80803@erg.abdn.ac.uk> Date: Tue, 12 Sep 2017 17:32:35 +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: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= CC: The IESG , draft-ietf-taps-transports-usage@ietf.org, taps-chairs@ietf.org, Zaheduzzaman.Sarker@ericsson.com, taps@ietf.org References: <150514493541.9712.4517222531106973475.idtracker@ietfa.amsl.com> In-Reply-To: <150514493541.9712.4517222531106973475.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-taps-transports-usage-08=3A_=28with_COMMENT=29?= 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, 12 Sep 2017 16:33:07 -0000 On 11/09/2017, 16:48, Mirja Kühlewind wrote: > Mirja Kühlewind has entered the following ballot position for > draft-ietf-taps-transports-usage-08: No Objection > > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > > - I (still) don't understand why draft-ietf-taps-transports-usage-udp was kept > in a separate document, given there is even a separate empty section in this > doc. You basically have to stop reading there, go to the other doc, read it, > and come back. That doesn't make sense to me. > > > _______________________________________________ > Taps mailing list > TapIs@ietf.org > https://www.ietf.org/mailman/listinfo/taps I'll speak only to the last comment which was discussed in IETF-96. The WG looked at this and there were pro's and con's in both a single document, and two separate documents. In the end, the decision by the WG was to publish the initial datagram analysis (UDP and UDP-L) as a separate document, which cut them into smaller pieces and was more managebale, but the WG would request the RFC-Ed to publish the two documents as a pair. I see another advantage: Much of the API requirements for UDP is scattered across various RFCs - and some implicit (RFCs that state a need to allow the stack to do something, but do not indicate how it will be done). It was thought a separate datagram document may have further utility for people as a informative single reference on how to present a datagram API, beyond its input to the TAPs transport design. Gorry From nobody Tue Sep 12 14:16: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 4C46C13314F for ; Tue, 12 Sep 2017 14:16:15 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.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 UPafG0y5Q22F for ; Tue, 12 Sep 2017 14:16:13 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D54E3126DD9 for ; Tue, 12 Sep 2017 14:16:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=pijM/sCN7zlGHmdSqrRDJjpmA3lnQ1c/9Ti4c9TQUte7B7vD/ZevX4rm31Txa4rhcQVEIz4oHp5Y07gT7nl0dhuKm1IsJiFRW2eT7r003DgMNykzOi5LEm+2hL0qpcb771i5/zXQbnGrH9pMjD/H2lBoCbZvCa9a/3iUBu6z8ts=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 24036 invoked from network); 12 Sep 2017 23:16:11 +0200 Received: from 178-83-155-34.dynamic.hispeed.ch (HELO ?192.168.220.145?) (178.83.155.34) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 12 Sep 2017 23:16:10 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <59B80C23.80803@erg.abdn.ac.uk> Date: Tue, 12 Sep 2017 23:16:09 +0200 Cc: The IESG , draft-ietf-taps-transports-usage@ietf.org, taps-chairs@ietf.org, Zaheduzzaman.Sarker@ericsson.com, taps@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <40E8A7BB-54B7-4E90-9386-31DEBA51B0CC@kuehlewind.net> References: <150514493541.9712.4517222531106973475.idtracker@ietfa.amsl.com> <59B80C23.80803@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20170912211611.24027.61775@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [Taps] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-taps-transports-usage-08=3A_=28with_COMMENT=29?= 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, 12 Sep 2017 21:16:15 -0000 Hi Gorry,=20 see below. > Am 12.09.2017 um 18:32 schrieb Gorry Fairhurst : >=20 > On 11/09/2017, 16:48, Mirja K=C3=BChlewind wrote: >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-taps-transports-usage-08: No Objection >>=20 >> >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> >>=20 >> - I (still) don't understand why draft-ietf-taps-transports-usage-udp = was kept >> in a separate document, given there is even a separate empty section = in this >> doc. You basically have to stop reading there, go to the other doc, = read it, >> and come back. That doesn't make sense to me. >>=20 >>=20 >> _______________________________________________ >> Taps mailing list >> TapIs@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > I'll speak only to the last comment which was discussed in IETF-96. >=20 > The WG looked at this and there were pro's and con's in both a single = document, and two separate documents. In the end, the decision by the WG = was to publish the initial datagram analysis (UDP and UDP-L) as a = separate document, which cut them into smaller pieces and was more = managebale, but the WG would request the RFC-Ed to publish the two = documents as a pair. I just made the experience that I started reviewing = draft-ietf-taps-transport-usage, then had to stop in the middle, read = draft-ietf-taps-udp-usage and then return to the first one. The main = problem is that draft-ietf-taps-transport-usage is so closely coupled to = the other draft that is does not make sense stand-alone. >=20 > I see another advantage: Much of the API requirements for UDP is = scattered across various RFCs - and some implicit (RFCs that state a = need to allow the stack to do something, but do not indicate how it will = be done). It was thought a separate datagram document may have further = utility for people as a informative single reference on how to present a = datagram API, beyond its input to the TAPs transport design. I=E2=80=99am actually not sure if there is any additional value in = having this draft as a stand-alone draft, compared to just advise people = to only read those sections they are interested in of a combined draft. = The problem is, while the udp draft may make sense as a stand-alone = draft, that=E2=80=99s not the case for this draft = (draft-ietf-taps-transport-usage).=20 I didn=E2=80=99t had a strong opinion about this before but now that = I've read both draft as a whole together, I found it really = uncomfortable to have this split up in two. However, this is only a = comment and the authors/wg needs to decide. Mirja >=20 > Gorry >=20 From nobody Wed Sep 13 13:01: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 2065A132D45; Wed, 13 Sep 2017 13:01:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-taps-transports-usage@ietf.org, Zaheduzzaman Sarker , taps-chairs@ietf.org, Zaheduzzaman.Sarker@ericsson.com, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150533290212.30455.669282290285389506.idtracker@ietfa.amsl.com> Date: Wed, 13 Sep 2017 13:01:42 -0700 Archived-At: Subject: [Taps] Ben Campbell's No Objection on draft-ietf-taps-transports-usage-08: (with COMMENT) 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, 13 Sep 2017 20:01:42 -0000 Ben Campbell has entered the following ballot position for draft-ietf-taps-transports-usage-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive: - General: There's a smattering of 2119 keywords in this draft. Other than when used in direct quotes,I assume they describe pre-existing requirements. If so, then please use descriptive language without 2119 keywords. (Otherwise, see Ekr's comment.) -8, first paragraph: Doesn't QUIC provide those features "on its own"? I realize it is not in RFC form yet, but it is standards track. Editorial: - Abstract: The abstract should not contain citations. - 2, first paragraph: "This specification describes an (abstract) interface" Why is "abstract" in parentheses? - 3.1, definition of TFO, "allows to immediately hand over": I suggest either "allows to immediately hand over" or "allows the immediate handover". -3.4: I agree with other comments that the UDP/UDP-lite draft should be included here. There may have been reason to separate them at one time, but since they are progressing together it no longer seems to make sense. While it may be inconvenient to recombine them at this point, keeping them separate just pushes that inconvenience off on the readers. -4: I find this section very hard to read due to the formatting of the primitive descriptions. Please consider either using complete sentences, or reformatting them into something that looks less like a blob of text. From nobody Wed Sep 13 13:07:56 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 6B342132ED2; Wed, 13 Sep 2017 13:07:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-taps-transports-usage-udp@ietf.org, Zaheduzzaman Sarker , taps-chairs@ietf.org, Zaheduzzaman.Sarker@ericsson.com, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150533326941.30550.17416106163194777298.idtracker@ietfa.amsl.com> Date: Wed, 13 Sep 2017 13:07:49 -0700 Archived-At: Subject: [Taps] Ben Campbell's No Objection on draft-ietf-taps-transports-usage-udp-06: (with COMMENT) 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, 13 Sep 2017 20:07:49 -0000 Ben Campbell has entered the following ballot position for draft-ietf-taps-transports-usage-udp-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage-udp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - general: As I mentioned in my review of the general transport-usage draft, I think the two drafts should be combined. -2: "It uses common terminology defined in that document and also refers to the terminology of RFC 2119 [RFC2119], but does not itself define new terms." Why does this draft need to refer to 2119? It should not be using 2119 keywords outside of direct quotes. (If it does need to use 2119 keywords, please use the boilerplate from 2119 or 8174 .) -3.1, 2nd paragraph: "should be able to create receive, source, and destination ports and addresses (setting the source and destination ports and addresses)," Is there a missing word after "create"? - 3.1, last paragraph: "[RFC6935] and [RFC6936] defines an update..." s/defines/define From nobody Wed Sep 13 16:12:59 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 3C09E12421A; Wed, 13 Sep 2017 16:12:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-taps-transports-usage-udp@ietf.org, Zaheduzzaman Sarker , taps-chairs@ietf.org, Zaheduzzaman.Sarker@ericsson.com, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150534437823.12565.1499220167114271596.idtracker@ietfa.amsl.com> Date: Wed, 13 Sep 2017 16:12:58 -0700 Archived-At: Subject: [Taps] Suresh Krishnan's No Objection on draft-ietf-taps-transports-usage-udp-06: (with COMMENT) 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, 13 Sep 2017 23:12:58 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-taps-transports-usage-udp-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage-udp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 1 "The UDP and UDP-Lite sockets API differs from that for TCP in several key ways." I was expecting the document to at least briefly describe the differences following this. The socket option text that follows does not really fit the bill. e.g. SO_REUSEADDR applies to TCP as well as UDP. From nobody Wed Sep 13 21:47:08 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 4A46613309A; Wed, 13 Sep 2017 21:47:07 -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 v1O5AsIQQsos; Wed, 13 Sep 2017 21:47:06 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 0A1C912895E; Wed, 13 Sep 2017 21:47:06 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id v72so4871867ywa.3; Wed, 13 Sep 2017 21:47:06 -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=PGozoywb/hreZRMjwFfw2uXgn5hXIXYmCquQ6uSzOyc=; b=bwFoUQ2rB+7WoPCLu0LNpbVHw6ZcuDq4ZgimcGfikFtz7N/9ecRbXc9XsU+vsFxNV9 iBEKwjZCIPhJ7enpaipqFKHvw4wHc/N42u+JACnDbJlz49dpmFz91c6NvGQJaZQfNBt+ jtxcpCIYuzFGaAGJw8PlFwmH+k3QC7RJ07/LoCgty6RjHGEmhCYT7KuX1hnPYBLcEy/c qmfU5JwvKMmaBH1fp6S1rAAKpsoxAJXi6Ne1ufJvYgbQiFNJMHvkZCwNHIPo7OLEn/SK +wERt8XWpr/Gty6s+qkqx6bYiLwbT+BBZIyq3CfQwXzhZCug1Nwg1zCiX68dnKNs5qdu /0jg== 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=PGozoywb/hreZRMjwFfw2uXgn5hXIXYmCquQ6uSzOyc=; b=ZzY37ZBNUbsNcb9A/1H+2SHM/yBszmw/AXHwmbzNq8K4Whee9ftXGfqaUqX/EUXxKV V59CgUu1sR8SLfvdKsdxoRG4/jJLTMhvEN3X709Dy6jn+GCtTxZsB1/mNdpzUdBpsmP5 aStaXiOeu3aNdjg6YbFfqoD8BWbfL/RdDKAxjfo5tWRm7tKuKRVJ9caoWYRjiZIF9hWf S+pVz4Kboxtng/wICilMDogohGvHxtwafbdJTgXLUD5aHyowvkow0gwf3njDbBBzbIr/ +xWR3FOzz2sCgJ8Dj54f4r6+pfjeUCK34AphbU9Y0hPCLRyKoD3AWYxny1swwOocGpcU Gr9Q== X-Gm-Message-State: AHPjjUgDHqAs/IVQUSckPEub5faLI2QxEXF7+T5XN5dZa/Xdk4ZaEkqg iOas3reE7Rm1/IRx0Hf7aUsUPjNxA8HXTScmAaA= X-Google-Smtp-Source: ADKCNb6nIR8UZrmvhFkc/uC/1reEYuVhkghetpDyBsyDYBKLFLbxdnLHkmVbFmlcnQk253K5RNNXA5X6zcjlrIdhVSE= X-Received: by 10.129.167.67 with SMTP id e64mr10629897ywh.85.1505364424950; Wed, 13 Sep 2017 21:47:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.15 with HTTP; Wed, 13 Sep 2017 21:47:04 -0700 (PDT) From: Spencer Dawkins at IETF Date: Wed, 13 Sep 2017 23:47:04 -0500 Message-ID: To: "taps@ietf.org" Cc: taps-chairs@ietf.org Content-Type: multipart/alternative; boundary="94eb2c146c7ece872905591ef77c" Archived-At: Subject: [Taps] One RFC, or two, for draft-ietf-taps-transports-usage and draft-ietf-taps-transports-usage-udp 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, 14 Sep 2017 04:47:07 -0000 --94eb2c146c7ece872905591ef77c Content-Type: text/plain; charset="UTF-8" Dear TAPS working group, Multiple ADs have asked why these two drafts aren't a single draft, in their ballots. Those are non-blocking comments, but I'd like to explore that, before making a decision about what should happen, and when. It occurs to me that these ADs are reading both drafts pretty much back-to-back in preparation for balloting during IESG Evaluation. If people reading the two drafts back-to-back find the split to be a distraction, I'd like to understand the views of the working group as to how often you expect people to read both drafts, in order to do TAPS. I could imagine that people working on complete TAPS APIs might need to read both drafts. What about other folks you expect to read these documents? Do you expect that some communities only need to read one of them? Thanks in advance for any thoughts you can share. Spencer, as responsible AD for TAPS --94eb2c146c7ece872905591ef77c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear TAPS working group,

Multiple ADs h= ave asked why these two drafts aren't a single draft, in their ballots.= Those are non-blocking comments, but I'd like to explore that, before = making a decision about what should happen, and when.

<= div>It occurs to me that these ADs are reading both drafts pretty much back= -to-back in preparation for balloting during IESG Evaluation.
If people reading the two drafts back-to-back find the split to= be a distraction, I'd like to understand the views of the working grou= p as to how often you expect people to read both drafts, in order to do TAP= S.

I could imagine that people working on complete= TAPS APIs might need to read both drafts.=C2=A0

W= hat about other folks you expect to read these documents? Do you expect tha= t some communities only need to read one of them?

= Thanks in advance for any thoughts you can share.

= Spencer, as responsible AD for TAPS
--94eb2c146c7ece872905591ef77c-- From nobody Thu Sep 14 03:20:27 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 BAE2013301A; Thu, 14 Sep 2017 03:20:19 -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 crO0aLQc3N2M; Thu, 14 Sep 2017 03:20:18 -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 217B3132FA0; Thu, 14 Sep 2017 03:20:15 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id C92681B000FA; Thu, 14 Sep 2017 11:19:56 +0100 (BST) Message-ID: <59BA57CB.1000708@erg.abdn.ac.uk> Date: Thu, 14 Sep 2017 11:19:55 +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: Suresh Krishnan CC: The IESG , Zaheduzzaman.Sarker@ericsson.com, taps-chairs@ietf.org, draft-ietf-taps-transports-usage-udp@ietf.org, taps@ietf.org References: <150534437823.12565.1499220167114271596.idtracker@ietfa.amsl.com> In-Reply-To: <150534437823.12565.1499220167114271596.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Taps] Suresh Krishnan's No Objection on draft-ietf-taps-transports-usage-udp-06: (with COMMENT) 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, 14 Sep 2017 10:20:20 -0000 Thanks Suresh, please see below. On 14/09/2017, 00:12, Suresh Krishnan wrote: > Suresh Krishnan has entered the following ballot position for > draft-ietf-taps-transports-usage-udp-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage-udp/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > * Section 1 > > "The UDP and UDP-Lite sockets API differs from that for TCP in several key > ways." > > I was expecting the document to at least briefly describe the differences > following this. The socket option text that follows does not really fit the > bill. e.g. SO_REUSEADDR applies to TCP as well as UDP. > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps I see, that wasn't quite the way I expected it to be read, so maybe we can suggest a slight re-write to the introduction to avoid misleading people and thereby better introduce what follows in the document: After the reference to Stevens, we suggest to insert: "In UDP and UDP-Lite, each datagram is a self-contained message of a specified length, and options at the transport layer can be used to set properties for all subsequent datagrams sent using a socket or changed for each datagram. For datagrams, this can require the application to use the API to set IP-level information (the IP Time To Live (TTL), Differentiated Services (DiffServ) Code Point, IP fragmentation, etc) for the datagrams it sends and receives. In contrast, when using TCP and other connection-oriented transports, the IP-level information normally either remains the same for the duration of a connection or is controlled by the transport protocol rather than the application. Socket options are used in the socket API to provide additional functions Examples of socket options (in this case commonly used by UDP multicast applications) include:" ... followed by the three example sockopts. (If we add this I think it also helps explain why the network-layer primitives appear. We would of course avoide redefining TTL, etc in the following paras.) Tom & Gorry From nobody Thu Sep 14 06:06:00 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 B6B43133187; Thu, 14 Sep 2017 06:05:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: draft-ietf-taps-transports-usage@ietf.org, Zaheduzzaman Sarker , taps-chairs@ietf.org, Zaheduzzaman.Sarker@ericsson.com, taps@ietf.org, liushucheng@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150539435873.12546.8612404876059608203.idtracker@ietfa.amsl.com> Date: Thu, 14 Sep 2017 06:05:58 -0700 Archived-At: Subject: [Taps] Benoit Claise's No Objection on draft-ietf-taps-transports-usage-08: (with COMMENT) 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, 14 Sep 2017 13:05:59 -0000 Benoit Claise has entered the following ballot position for draft-ietf-taps-transports-usage-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Interesting piece of work. Thanks. I hope it will be maintained along the time Acknowledgement: "The views expressed are solely those of the author(s)." Really? Why this sentence? From nobody Thu Sep 14 06:54:49 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 536BA132355; Thu, 14 Sep 2017 06:54:41 -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 Ojg9V7-63Drb; Thu, 14 Sep 2017 06:54:40 -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 C95991321CB; Thu, 14 Sep 2017 06:54:39 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 62E5A1B000FA; Thu, 14 Sep 2017 14:54:30 +0100 (BST) Message-ID: <59BA8A14.6080405@erg.abdn.ac.uk> Date: Thu, 14 Sep 2017 14:54:28 +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: Benoit Claise CC: The IESG , draft-ietf-taps-transports-usage@ietf.org, taps-chairs@ietf.org, liushucheng@huawei.com, Zaheduzzaman.Sarker@ericsson.com, taps@ietf.org References: <150539435873.12546.8612404876059608203.idtracker@ietfa.amsl.com> In-Reply-To: <150539435873.12546.8612404876059608203.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Taps] Benoit Claise's No Objection on draft-ietf-taps-transports-usage-08: (with COMMENT) 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, 14 Sep 2017 13:54:41 -0000 On 14/09/2017, 14:05, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > draft-ietf-taps-transports-usage-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Interesting piece of work. Thanks. > I hope it will be maintained along the time I really hope so too !!! > Acknowledgement: "The views expressed are solely those of the author(s)." > Really? Why this sentence? It was because it was what the funders requested for the individual draft and was never removed when the WG adopted it. Thanks for reading to the very end, -- I shall certainly remove this sentence in the next rev.! Gorry > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Thu Sep 14 07:35:32 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 9A8B513303B; Thu, 14 Sep 2017 07:35:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Francis Dupont To: Cc: draft-ietf-taps-transports-usage-udp.all@ietf.org, ietf@ietf.org, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150539972354.12573.3384960389295469266@ietfa.amsl.com> Date: Thu, 14 Sep 2017 07:35:23 -0700 Archived-At: Subject: [Taps] Genart telechat review of draft-ietf-taps-transports-usage-udp-06 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, 14 Sep 2017 14:35:24 -0000 Reviewer: Francis Dupont Review result: On the Right Track I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-taps-transports-usage-udp-?? Reviewer: Francis Dupont Review Date: 2017-09-14 IETF LC End Date: 2017-09-14 IESG Telechat date: 2017-09-14 Summary: On the Right Track Major issues: None Minor issues: soem technical details are wrong, for instanc SO_REUSEADDR and SO_REUSEPORT descriptions. Nits/editorial comments: I'll send a full review as soon as I get the time to type it. From nobody Thu Sep 14 07:55:57 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 E58DC13235C; Thu, 14 Sep 2017 07:55:55 -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 bm5R7VOeZkPP; Thu, 14 Sep 2017 07:55: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 26C8F132335; Thu, 14 Sep 2017 07:55:54 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id v72so6729636ywa.3; Thu, 14 Sep 2017 07:55:54 -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=099xw9Ezq90oENqnrruewRiGcmoV6Cfq144NVMVuswI=; b=FDG0D03MhmANwJ3drFar7TU1FQjIeeX5leh0h4aqkQI21DRAa9iBG9NcnyF3L6lY6c OIsgS/725hgq5gnAn57kjG4ytpiO7AKKi8bW93zzSlrMPB5VND7lF95KAkZdaNWncgYV IsGBnKLk/0ri8ZpY7vM/UMwk3daRClQKMW/KUa34cIpAzz1wY5ZvcHtor3uiMEJqu54i 1EFzNu7X95X21JCECZ+D/AJ4Utaa16LXPAVnGpBaZ2nz3QupqUWreBOpn9s14g7jhraz IpN7QMdI2OhVTDaf4zEWSv5oyCqnZRpUPHxlUJxwKUew/DJPdUVnrDbykJ+fXr0374Yr LsFg== 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=099xw9Ezq90oENqnrruewRiGcmoV6Cfq144NVMVuswI=; b=CcZ382r/ZnnoIAcoiFauSf3UZ1oW94xRBXJTWIo5UstqfCCk/zGS1hGJMd4SO7xpI8 lkSzop3WiHwT+O2kguL8eTLjJThA/c9f5FwWhMXvchjFXczSH693iYHcknG68mIolk+T TD6YtlFAekRqDSaowdDkAHWeYM3MTSaTVvkUc1X90cmDzIwMAXuU6WsA1UG+3ZwQGWFd vgZu3JP5c0ZTbNUSRrIa9iHcA3O22kdwykaLDCeuOvVhRCerG/sPb5ZfXlA/Mc2bJpx2 CGpxr+p8XqFcxvsuk9oh7rmTGiB49AhLWeX1BmWCg85T0Vu0quA8yyARI08+ya6RbyjD pp/A== X-Gm-Message-State: AHPjjUi35dLzqepH0peU0JnY6pQpq+Z6sFbLM4b6AlYlCl7V4XjLIZFc EafwvCRXz2l7MIZwzudtcgG6ftq7E6IRgRlwNCA= X-Google-Smtp-Source: AOwi7QDKPAs0H4NoeNgTEqzBGaEPK3fauxahKaqRFM6VRi3NrDAz5KxHOXLRGLnHCTwCiXPeTN99uUZjUE7oR/5OhnM= X-Received: by 10.129.188.20 with SMTP id a20mr5049164ywi.361.1505400953125; Thu, 14 Sep 2017 07:55:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.15 with HTTP; Thu, 14 Sep 2017 07:55:52 -0700 (PDT) In-Reply-To: References: From: Spencer Dawkins at IETF Date: Thu, 14 Sep 2017 09:55:52 -0500 Message-ID: To: "taps@ietf.org" Cc: taps-chairs@ietf.org Content-Type: multipart/alternative; boundary="089e0825a4280e3f9c05592779c5" Archived-At: Subject: Re: [Taps] One RFC, or two, for draft-ietf-taps-transports-usage and draft-ietf-taps-transports-usage-udp 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, 14 Sep 2017 14:55:56 -0000 --089e0825a4280e3f9c05592779c5 Content-Type: text/plain; charset="UTF-8" And, following up during the actual telechat ... On Wed, Sep 13, 2017 at 11:47 PM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Dear TAPS working group, > > Multiple ADs have asked why these two drafts aren't a single draft, in > their ballots. Those are non-blocking comments, but I'd like to explore > that, before making a decision about what should happen, and when. > > It occurs to me that these ADs are reading both drafts pretty much > back-to-back in preparation for balloting during IESG Evaluation. > > If people reading the two drafts back-to-back find the split to be a > distraction, I'd like to understand the views of the working group as to > how often you expect people to read both drafts, in order to do TAPS. > > I could imagine that people working on complete TAPS APIs might need to > read both drafts. > > What about other folks you expect to read these documents? Do you expect > that some communities only need to read one of them? > > Thanks in advance for any thoughts you can share. > > Spencer, as responsible AD for TAPS > Both documents were approved on the telechat today, pending comment resolution of comments received during IESG Evaluation. So, my request to the working group to consider whether the suggestion to combine these documents makes life easier for the readers you expect will need to read one, the other, or both documents REALLY IS an honest question, and not the IESG requiring fabulously late major editorial changes without an active Discuss, because That Would Be Wrong. Either answer works. We'll Do The Right Thing. "Thanks in advance for your thoughts" :-) Spencer, as responsible AD, who the IESG said they trusted to "Do The Right Thing" --089e0825a4280e3f9c05592779c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
And, following up during the actual telechat ...

On Wed, Sep 13, 2017 at 11:= 47 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com<= /a>> wrote:
De= ar TAPS working group,

Multiple ADs have asked why these= two drafts aren't a single draft, in their ballots. Those are non-bloc= king comments, but I'd like to explore that, before making a decision a= bout what should happen, and when.

It occurs to me= that these ADs are reading both drafts pretty much back-to-back in prepara= tion for balloting during IESG Evaluation.

If peop= le reading the two drafts back-to-back find the split to be a distraction, = I'd like to understand the views of the working group as to how often y= ou expect people to read both drafts, in order to do TAPS.

I could imagine that people working on complete TAPS APIs might ne= ed to read both drafts.=C2=A0

What about other fol= ks you expect to read these documents? Do you expect that some communities = only need to read one of them?

Thanks in advance f= or any thoughts you can share.

Spencer, as respons= ible AD for TAPS

Both documents were= approved on the telechat today, pending comment resolution of comments rec= eived during IESG Evaluation.

So, my request to the working group to consider whe= ther the suggestion to combine these documents makes life easier for the re= aders you expect will need to read one, the other, or both documents REALLY= IS an honest question, and not the IESG requiring fabulously late major ed= itorial changes without an active Discuss, because That Would Be Wrong.

Either an= swer works. We'll Do The Right Thing.
<= br>
"Thanks in advance for your though= ts" :-)

Spencer, as responsible AD, who the IESG said they trusted to "= Do The Right Thing"
--089e0825a4280e3f9c05592779c5-- From nobody Thu Sep 14 09:02:57 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 CB5AD13301E; Thu, 14 Sep 2017 09:02:56 -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 tYpUsUiRHjgf; Thu, 14 Sep 2017 09:02:55 -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 D42601321C7; Thu, 14 Sep 2017 09:02:54 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id EDA371B00168; Thu, 14 Sep 2017 17:02:30 +0100 (BST) Message-ID: <59BAA815.5090209@erg.abdn.ac.uk> Date: Thu, 14 Sep 2017 17:02:29 +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=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Taps] One RFC, or two, for draft-ietf-taps-transports-usage and draft-ietf-taps-transports-usage-udp 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, 14 Sep 2017 16:02:57 -0000 On 14/09/2017, 15:55, Spencer Dawkins at IETF wrote: > And, following up during the actual telechat ... > > On Wed, Sep 13, 2017 at 11:47 PM, Spencer Dawkins at IETF > > > wrote: > > Dear TAPS working group, > > Multiple ADs have asked why these two drafts aren't a single > draft, in their ballots. Those are non-blocking comments, but I'd > like to explore that, before making a decision about what should > happen, and when. > > It occurs to me that these ADs are reading both drafts pretty much > back-to-back in preparation for balloting during IESG Evaluation. > > If people reading the two drafts back-to-back find the split to be > a distraction, I'd like to understand the views of the working > group as to how often you expect people to read both drafts, in > order to do TAPS. > > I could imagine that people working on complete TAPS APIs might > need to read both drafts. > > What about other folks you expect to read these documents? Do you > expect that some communities only need to read one of them? > > Thanks in advance for any thoughts you can share. > > Spencer, as responsible AD for TAPS > > > Both documents were approved on the telechat today, pending comment > resolution of comments received during IESG Evaluation. > > So, my request to the working group to consider whether the suggestion > to combine these documents makes life easier for the readers you > expect will need to read one, the other, or both documents REALLY IS > an honest question, and not the IESG requiring fabulously late major > editorial changes without an active Discuss, because That Would Be Wrong. > > Either answer works. We'll Do The Right Thing. > > "Thanks in advance for your thoughts" :-) > > Spencer, as responsible AD, who the IESG said they trusted to "Do The > Right Thing" > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps There was a proposal from IESG to consider whether we should merge the two usage documents. So after giving this some more thought, here is my 2c about why I think we should keep the two documents: First, I accept it may be easier for someone reviewing the history of TAPS and the rationale for design decisions to read just a single document - putting all the material in one place is always easier. However, if published in consecutive RFCs, I'm not convinced the material would be really hard for a reader to find. I suggested there were two reasons behind separating this out when we did the work. First, the old and incomplete documentation for UDP needed a slightly different approach to finding the relevent RFCs. Second, the community of interest in using UDP at the IETF is typically to be found outside the TSV area, partly because of the wide variety of uses. A second document made this easier for these people to read. That's still the case for the material that was retained in the UDP usage document. It would be my hope that the UDP document could form a long-needed part of the documentation for UDP. I expect this would continue to be a useful resource for anyone who wishes to build datagram support into a new stack, or just wants to program to this API, and avoids people needing to wade through 50-60 pages to find a section on a UDP API. I'd also hope (??!!) this document could be maintained in future as the API continues to develop. Gorry From nobody Thu Sep 14 15:37:11 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 941C0126DD9; Thu, 14 Sep 2017 15:37:09 -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 h8-7wDEZZUWF; Thu, 14 Sep 2017 15:37:07 -0700 (PDT) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (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 593D51200F3; Thu, 14 Sep 2017 15:37:07 -0700 (PDT) Received: by mail-io0-x244.google.com with SMTP id 93so1792634iol.4; Thu, 14 Sep 2017 15:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kQZQ3T1r4ESmnAJjWgryEJkd4iEv6sQsRHol3yZHM5A=; b=P7JkmI3EhrjsX979xwvGBTFKPXk4tXO6r08uiPUo5ew8H5tEH36FvpNb3ZWn2pX1a5 BvueRwR9XFcW1gSDiFJtgfKG+QfDubCAhE8ShLZrouMpSFaVS83j+Sg57YqJpEgYgfPn R4XeCcua8iAsuoNBy4UFJvMKixh16AhK1mOakbNRtigD6XnLN83EiEE9N8Pduo246yG0 zXd9vhw4E8Q5HvfvePt+AIGuiBqNGCd9LOhCJ/kv++gcTz7wgL6EJUhe9LYJJNcIgl/D pvRHde0ke9OQxgpP5TEHaJlaaM+hZiYZOBSmDxnvg1Wu2VFiVWNTH+0qvbm91dYrtM2S AITw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kQZQ3T1r4ESmnAJjWgryEJkd4iEv6sQsRHol3yZHM5A=; b=RU+az59lyg03KBaFIP4Z8o0aO2xG3B2zR69kVrwK/wre3JbgRC2TG/om+8Ehrj3ti3 BiMcJR3ATt2vggBMN/At7o8Rf2aT+E93mEH3QRCvRAYDB9OxXre0yB02TEO3HDYX5bU/ MulYdLC8ztMiN/ezn8aHCIRtEJuRSeCBRSUcLX3GghNfqALkymHOlcnl+o4YOBFmb4lB A3b0wUQysGODLnuLAzGi23n/w/cd5fmForpNLT/XC50W8UGbFAogkM9CD7VaWJ+uexpJ NoA871z/7l9PSl+rGIXRnNtR4OATq/vo+JpveBLx82gj8prLr40KigArQ0HikBlL6LkR uRIg== X-Gm-Message-State: AHPjjUhU/0wYVnJzfx55IYqnOMDfVO43h/yUUOKQhVcBfsLoq12eaSN2 QC+tP7xdZ/ZbAw== X-Google-Smtp-Source: AOwi7QBtqWtxP3olHsbf6W9lWBgiio/MlfUN06XiHwtxi3YraMvV/ferLpb7ae7qyw5FBv/dR5wuPg== X-Received: by 10.107.82.14 with SMTP id g14mr4921261iob.137.1505428626508; Thu, 14 Sep 2017 15:37:06 -0700 (PDT) Received: from [192.168.36.124] ([67.22.228.35]) by smtp.gmail.com with ESMTPSA id c13sm9280766ioj.19.2017.09.14.15.37.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Sep 2017 15:37:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Suresh Krishnan In-Reply-To: <59BA57CB.1000708@erg.abdn.ac.uk> Date: Thu, 14 Sep 2017 18:37:04 -0400 Cc: The IESG , Zaheduzzaman.Sarker@ericsson.com, taps-chairs@ietf.org, draft-ietf-taps-transports-usage-udp@ietf.org, taps@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <61445676-61B2-4178-8973-82636BBBF512@gmail.com> References: <150534437823.12565.1499220167114271596.idtracker@ietfa.amsl.com> <59BA57CB.1000708@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Taps] Suresh Krishnan's No Objection on draft-ietf-taps-transports-usage-udp-06: (with COMMENT) 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, 14 Sep 2017 22:37:10 -0000 Hi Gorry, > On Sep 14, 2017, at 6:19 AM, Gorry Fairhurst = wrote: >=20 > Thanks Suresh, please see below. >=20 > On 14/09/2017, 00:12, Suresh Krishnan wrote: >> Suresh Krishnan has entered the following ballot position for >> draft-ietf-taps-transports-usage-udp-06: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> = https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage-udp/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> * Section 1 >>=20 >> "The UDP and UDP-Lite sockets API differs from that for TCP in = several key >> ways." >>=20 >> I was expecting the document to at least briefly describe the = differences >> following this. The socket option text that follows does not really = fit the >> bill. e.g. SO_REUSEADDR applies to TCP as well as UDP. >>=20 >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > I see, that wasn't quite the way I expected it to be read, so maybe we = can suggest a slight re-write to the introduction to avoid misleading = people and thereby better introduce what follows in the document: >=20 > After the reference to Stevens, we suggest to insert: >=20 > "In UDP and UDP-Lite, each datagram is a self-contained message of a = specified length, and options at the transport layer can be used to set = properties for all subsequent datagrams sent using a socket or changed = for each datagram. For datagrams, this can require the application to = use the API to set IP-level information (the IP Time To Live (TTL), = Differentiated Services (DiffServ) Code Point, IP fragmentation, etc) = for the datagrams it sends and receives. In contrast, when using TCP and = other connection-oriented transports, the IP-level information normally = either remains the same for the duration of a connection or is = controlled by the transport protocol rather than the application. >=20 > Socket options are used in the socket API to provide additional = functions Examples of socket options (in this case commonly used by UDP = multicast applications) include:" >=20 > ... followed by the three example sockopts. >=20 > (If we add this I think it also helps explain why the network-layer = primitives appear. We would of course avoide redefining TTL, etc in the = following paras.) Excellent. This new text would completely address my concern. Thanks for = proposing that. Regards Suresh From nobody Mon Sep 18 09: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 5E0A71321DC; Mon, 18 Sep 2017 09:05:38 -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 ocux-zSrZyRa; Mon, 18 Sep 2017 09:05:31 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 00D1C1321A2; Mon, 18 Sep 2017 09:05:30 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id p10so672634ywh.8; Mon, 18 Sep 2017 09:05:30 -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=Xe7flk4btm24iIoc2zXYYmQqP5+4pwOJfiJm3qynCSg=; b=eJesW+ltZhs8FF8prkMUVhlpBeouw5rcy689dccgsfmFQf7BnWPtDl6Vku7zrex6dG oY1oNOyVoNAiQqYHO8x5dhz97gxjvXHn2L1BYkD35zfh74WmmbkdBhRwIoAasrJRrdZz U19hzI0L02niXv4yRfrajgIXZMemHC41SYp3gKEqEIWUCTBOiCv6yHiI1qwp7txjl+3j 1ar0V5ViOjB+Jyr0jYO8i3BDBg1/eIwXRxnBgn9+tUmbBVg4PbGz07CaG6iiuR784DkD NYLcTh0nZ6WRlx1nz9KwQB5VWvVA9nobRpAtT6yR0qIFedE8nJrBYF6FiHfxJFFdvgiW KJXA== 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=Xe7flk4btm24iIoc2zXYYmQqP5+4pwOJfiJm3qynCSg=; b=WzlIPs1ZEtPH3kjGOavCIXpP273nq8XhTtZMoKCEwjouw/czRsKAs/cLYBrRmN1zp4 7QlPAWRXsGNgblpOxmnWVfIvMbHuv0sceCFSiVziufm79gIUkiMCU1Oj6LQc/NfuOP8a LjopTVOIArxYoOfg5NughbdZ3dNvLymaJlirsNPKE1haSONmsCTMB7bb5q7D8IMFAW4G jCAk9818Od6G80gft0b6TfAQ3UciV9W136qNmouF3QNJux+hy3NfTwGf3cv12p8ajJ2h tMoNY41QxbjXk8mf30lzC/9KWELbDF0HR0r/K+B2OZxOPlW5Pl3w0y8VA4xxhT1zyIhL J2eg== X-Gm-Message-State: AHPjjUg6bjlUYwn+3X2OWFTiI7f4RC1MZI8ZOJvBj3b8+wuOzBVSQWFP m1pL66wFxIneamDrbVweIHnRnzhC8v176e5rf60= X-Google-Smtp-Source: ADKCNb7OBsf/+fvsOa4f/ZpquzGFzWMTPhbU9ltZLY2rGxXgGdR6SpU4iFYDKJAh2hsTktKxwNoFvNVHDoBxieXsB3U= X-Received: by 10.129.115.197 with SMTP id o188mr28177844ywc.124.1505750730000; Mon, 18 Sep 2017 09:05:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.15 with HTTP; Mon, 18 Sep 2017 09:05:29 -0700 (PDT) In-Reply-To: <59BAA815.5090209@erg.abdn.ac.uk> References: <59BAA815.5090209@erg.abdn.ac.uk> From: Spencer Dawkins at IETF Date: Mon, 18 Sep 2017 11:05:29 -0500 Message-ID: To: "gorry@erg.abdn.ac.uk" Cc: "taps@ietf.org" , taps-chairs@ietf.org Content-Type: multipart/alternative; boundary="001a114934dc61cd35055978e9b7" Archived-At: Subject: Re: [Taps] One RFC, or two, for draft-ietf-taps-transports-usage and draft-ietf-taps-transports-usage-udp 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, 18 Sep 2017 16:05:38 -0000 --001a114934dc61cd35055978e9b7 Content-Type: text/plain; charset="UTF-8" Dear TAPSters, On Thu, Sep 14, 2017 at 11:02 AM, Gorry Fairhurst wrote: > On 14/09/2017, 15:55, Spencer Dawkins at IETF wrote: > >> And, following up during the actual telechat ... >> >> On Wed, Sep 13, 2017 at 11:47 PM, Spencer Dawkins at IETF < >> spencerdawkins.ietf@gmail.com > >> wrote: >> >> Dear TAPS working group, >> >> Multiple ADs have asked why these two drafts aren't a single >> draft, in their ballots. Those are non-blocking comments, but I'd >> like to explore that, before making a decision about what should >> happen, and when. >> >> It occurs to me that these ADs are reading both drafts pretty much >> back-to-back in preparation for balloting during IESG Evaluation. >> >> If people reading the two drafts back-to-back find the split to be >> a distraction, I'd like to understand the views of the working >> group as to how often you expect people to read both drafts, in >> order to do TAPS. >> >> I could imagine that people working on complete TAPS APIs might >> need to read both drafts. >> >> What about other folks you expect to read these documents? Do you >> expect that some communities only need to read one of them? >> >> Thanks in advance for any thoughts you can share. >> >> Spencer, as responsible AD for TAPS >> >> >> Both documents were approved on the telechat today, pending comment >> resolution of comments received during IESG Evaluation. >> >> So, my request to the working group to consider whether the suggestion to >> combine these documents makes life easier for the readers you expect will >> need to read one, the other, or both documents REALLY IS an honest >> question, and not the IESG requiring fabulously late major editorial >> changes without an active Discuss, because That Would Be Wrong. >> >> Either answer works. We'll Do The Right Thing. >> >> "Thanks in advance for your thoughts" :-) >> >> Spencer, as responsible AD, who the IESG said they trusted to "Do The >> Right Thing" >> >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >> > > There was a proposal from IESG to consider whether we should merge the two > usage documents. So after giving this some more thought, here is my 2c > about why I think we should keep the two documents: > > First, I accept it may be easier for someone reviewing the history of TAPS > and the rationale for design decisions to read just a single document - > putting all the material in one place is always easier. However, if > published in consecutive RFCs, I'm not convinced the material would be > really hard for a reader to find. > > I suggested there were two reasons behind separating this out when we did > the work. First, the old and incomplete documentation for UDP needed a > slightly different approach to finding the relevent RFCs. Second, the > community of interest in using UDP at the IETF is typically to be found > outside the TSV area, partly because of the wide variety of uses. A second > document made this easier for these people to read. That's still the case > for the material that was retained in the UDP usage document. > > It would be my hope that the UDP document could form a long-needed part of > the documentation for UDP. I expect this would continue to be a useful > resource for anyone who wishes to build datagram support into a new stack, > or just wants to program to this API, and avoids people needing to wade > through 50-60 pages to find a section on a UDP API. I'd also hope (??!!) > this document could be maintained in future as the API continues to develop. > > Gorry > Gorry's e-mail captured pretty much everything I need to know. I have one more question, because I know that people have implemented TAPSish APIs and demonstrated them. If you worked on one of those APIs, did you have to read both documents? Thanks in advance, and asking for (14) friends ... Spencer, as responsible AD --001a114934dc61cd35055978e9b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear TAPSters,

On Thu, Sep 14, 2017 at 11:02 AM, Gorry Fairhurst <gorr= y@erg.abdn.ac.uk> wrote:
On 14/09/2017, 15:55, Spencer Dawkins at IETF wrote:
And, following up during the actual telechat ...

 On Wed, Sep 13, 2017 at 11:47 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@g= mail.com <mailto:spencerdawkins.ietf@gmail.com>> wrote:

=C2=A0 =C2=A0 Dear TAPS working group,

=C2=A0 =C2=A0 Multiple ADs have asked why these two drafts aren't a sin= gle
=C2=A0 =C2=A0 draft, in their ballots. Those are non-blocking comments, but= I'd
=C2=A0 =C2=A0 like to explore that, before making a decision about what sho= uld
=C2=A0 =C2=A0 happen, and when.

=C2=A0 =C2=A0 It occurs to me that these ADs are reading both drafts pretty= much
=C2=A0 =C2=A0 back-to-back in preparation for balloting during IESG Evaluat= ion.

=C2=A0 =C2=A0 If people reading the two drafts back-to-back find the split = to be
=C2=A0 =C2=A0 a distraction, I'd like to understand the views of the wo= rking
=C2=A0 =C2=A0 group as to how often you expect people to read both drafts, = in
=C2=A0 =C2=A0 order to do TAPS.

=C2=A0 =C2=A0 I could imagine that people working on complete TAPS APIs mig= ht
=C2=A0 =C2=A0 need to read both drafts.

=C2=A0 =C2=A0 What about other folks you expect to read these documents? Do= you
=C2=A0 =C2=A0 expect that some communities only need to read one of them?
=C2=A0 =C2=A0 Thanks in advance for any thoughts you can share.

=C2=A0 =C2=A0 Spencer, as responsible AD for TAPS


Both documents were approved on the telechat today, pending comment resolut= ion of comments received during IESG Evaluation.

So, my request to the working group to consider whether the suggestion to c= ombine these documents makes life easier for the readers you expect will ne= ed to read one, the other, or both documents REALLY IS an honest question, = and not the IESG requiring fabulously late major editorial changes without = an active Discuss, because That Would Be Wrong.

Either answer works. We'll Do The Right Thing.

"Thanks in advance for your thoughts" :-)

Spencer, as responsible AD, who the IESG said they trusted to "Do The = Right Thing"


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

There was a proposal from IESG to consider whether we should merge the two = usage documents. So after giving this some more thought, here is my 2c abou= t why I think we should keep the two documents:

First, I accept it may be easier for someone reviewing the history of TAPS = and the rationale for design decisions to read just a single document - put= ting all the material in one place is always easier. However, if published = in consecutive RFCs, I'm not convinced the material would be really har= d for a reader to find.

I suggested there were two reasons behind separating this out when we did t= he work. First, the old and incomplete documentation for UDP needed a sligh= tly different approach to finding the relevent RFCs. Second, the community = of interest in using UDP at the IETF is typically to be found outside the T= SV area, partly because of the wide variety of uses. A second document made= this easier for these people to read. That's still the case for the ma= terial that was retained in the UDP usage document.

It would be my hope that the UDP document could form a long-needed part of = the documentation for UDP. I expect this would continue to be a useful reso= urce for anyone who wishes to build datagram support into a new stack, or j= ust wants to program to this API, and avoids people needing to wade through= 50-60 pages to find a section on a UDP API. I'd also hope (??!!) this = document could be maintained in future as the API continues to develop.

Gorry

Gorry's e-mail = captured pretty much everything I need to know. I have one more question, b= ecause I know that people have implemented TAPSish APIs and demonstrated th= em.=C2=A0

If you worked on one of those APIs, did = you have to read both documents?=C2=A0

Thanks in a= dvance, and asking for (14) friends ...

Spencer, a= s responsible AD=C2=A0
--001a114934dc61cd35055978e9b7-- From nobody Tue Sep 19 01:46:09 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 7ED3F1330B3; Tue, 19 Sep 2017 01:46:01 -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.62.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150581076145.11813.12696050843366432367@ietfa.amsl.com> Date: Tue, 19 Sep 2017 01:46:01 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-transports-usage-udp-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: Tue, 19 Sep 2017 08:46:01 -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-07.txt Pages : 22 Date : 2017-09-19 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-07 https://datatracker.ietf.org/doc/html/draft-ietf-taps-transports-usage-udp-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-usage-udp-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 Tue Sep 19 01:57:19 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 0CEA71342CB for ; Tue, 19 Sep 2017 01:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.75 X-Spam-Level: X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, 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 27DQQQeAc3zH for ; Tue, 19 Sep 2017 01:57:13 -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 B30DE1342C7 for ; Tue, 19 Sep 2017 01:57:13 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 7C5671B0024B; Tue, 19 Sep 2017 09:56:49 +0100 (BST) Message-ID: <59C0DBD5.90608@erg.abdn.ac.uk> Date: Tue, 19 Sep 2017 09:56:53 +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 CC: Tom Jones References: <150581076175.11813.17685515386047526910.idtracker@ietfa.amsl.com> In-Reply-To: <150581076175.11813.17685515386047526910.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Taps] New Version Notification for draft-ietf-taps-transports-usage-udp-07.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: Tue, 19 Sep 2017 08:57:18 -0000 TAPs people, Here is a new revison of the ID. We think this version addresses all requested changes aftre IESG review. There was also one request to adjust the abstract, but we have not done so (if the way in which the present abstract refers to taps-transport-usage is not as desired by our AD, we'd happily accept new text). I also note that Spencer has also asked a question to the list, and this revision is published while this is being considered. Gorry & Tom On 19/09/2017, 09:46, internet-drafts@ietf.org wrote: > A new version of I-D, draft-ietf-taps-transports-usage-udp-07.txt > has been successfully submitted by Godred Fairhurst and posted to the > IETF repository. > > Name: draft-ietf-taps-transports-usage-udp > Revision: 07 > Title: Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP- Lite) Transport Protocols > Document date: 2017-09-19 > Group: taps > Pages: 22 > URL: https://www.ietf.org/internet-drafts/draft-ietf-taps-transports-usage-udp-07.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-07 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-taps-transports-usage-udp-07 > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-usage-udp-07 > > 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 Sep 20 19:31:38 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 221A6132CE7 for ; Wed, 20 Sep 2017 19:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=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 eCakdFV4660Z for ; Wed, 20 Sep 2017 19:31:35 -0700 (PDT) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (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 E9A83132C2A for ; Wed, 20 Sep 2017 19:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1505961094; 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=XBtppYn/JFFT0kYuOYYwdZpo0vo3K+7QNihR3ONhn2A=; b=m40Fb6U9M3z1tm/5kgY59+kFY1oObbTZgMKqjU9E5cduwSgf0s1XYfA0+7ROGyX9 IAdcA4KnBQOQCvr9mnX3V8E6velsRwRLHP7Y/VUyapap0FTos/E4DC5jm44Zl+7j 4k/TY7J4X3hkwLjVMFIXrXLzEo551LEkjqC+etEP2kdljoGGimI3jz2QM6c4kUGu X3QtiYaEdjOeoISugj0zyFx2O0hsI/5kKjvueUaHa7TBuwwcW90UnSSEgt+h8tOF stVj4jzS7gvj/sw8cLyKCdDg9mu5rczw8Jt0rIoxlhuBj+8NLLaZW0u59D3abMC4 bf9/KRKg6KQeOx67lgB/IQ==; 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-in6.apple.com (Apple Secure Mail Relay) with SMTP id F8.61.11091.68423C95; Wed, 20 Sep 2017 19:31:34 -0700 (PDT) X-AuditID: 11973e15-512379c000002b53-de-59c324864fb8 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 B6.C0.09069.68423C95; Wed, 20 Sep 2017 19:31:34 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_R6JWEaPDUTos2vr1PItpxQ)" Received: from [17.234.82.253] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OWL00JJBZ0LW000@nwk-mmpp-sz10.apple.com>; Wed, 20 Sep 2017 19:31:34 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <438743B0-91A3-4718-A4F2-32B465110808@apple.com> Date: Wed, 20 Sep 2017 19:31:33 -0700 In-reply-to: Cc: "gorry@erg.abdn.ac.uk" , taps-chairs@ietf.org, "taps@ietf.org" To: Spencer Dawkins at IETF References: <59BAA815.5090209@erg.abdn.ac.uk> X-Mailer: Apple Mail (2.3439) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUi2FDorNumcjjSYN5SbYvXbbMZLZZN2cNs cXvVIlaLOzEOLB49n18weeycdZfdY8mSn0wBzFFcNimpOZllqUX6dglcGbvOn2ctuNLBWHHx 9QbmBsbvJV2MnBwSAiYSHQu2sXYxcnEICaxmklhxfBtLFyMHWOJrozlE/BCjxK5Dl5hAGngF BCV+TL7HAmIzC4RJfO/oh2r+yihxdvoRNpBmYQEJic17EkFq2ARUJI5/28AM0Wsj8WPLLjYQ W1igRGL33V5WEJtFQFWi9fRqsPmcAsES184/ZoWYnyUx7+lcRhBbRMBaYktfJxvErhYmiSnP LzNDHCorsfRPCEhcQmALm0TTyQb2CYxCs5DcOgvJrRC2lsT3R61AcQ4gW17i4HlZiLCmxLN7 n9ghbG2JJ+8usC5gZFvFKJSbmJmjm5lnppdYUJCTqpecn7uJERQl0+1EdzCeWWV1iFGAg1GJ hzfA6mCkEGtiWXFl7iFGaQ4WJXHemf+AQgLpiSWp2ampBalF8UWlOanFhxiZODilGhjPbVad Nqe05sG2C7YhcaHHlzQsmDK/fRqblsPMrLtKgdc5z+mKvXty7OiioP7t7ouy+IT2rVkhO2nd X/7LV8+E5z8vjeBIuz4hUsg6p5Y1I3DVROMlMydmcqg/cnQ4v1D36ovHMpeX95mpBOn82TN9 2v9bKj/N/tcZ/lWYLP1dc4NNNR9r219HJZbijERDLeai4kQAtVangnMCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUi2FBcpdumcjjS4Gm7usXrttmMFsum7GG2 uL1qEavFnRgHFo+ezy+YPHbOusvusWTJT6YA5igum5TUnMyy1CJ9uwSujF3nz7MWXOlgrLj4 egNzA+P3ki5GDg4JAROJr43mXYxcHEIChxgldh26xNTFyMnBKyAo8WPyPRYQm1kgTOJ7Rz8r RNFXRomz04+wgTQLC0hIbN6TCFLDJqAicfzbBmaIXhuJH1t2sYHYwgIlErvv9rKC2CwCqhKt p1eDzecUCJa4dv4xK8T8LIl5T+cygtgiAtYSW/o62SB2tTBJTHl+mRniUFmJpX9CJjDyz0Jy 3iwk50HYWhLfH7UCxTmAbHmJg+dlIcKaEs/ufWKHsLUlnry7wLqAkW0Vo0BRak5ipZFeYkFB Tqpecn7uJkZwUBc672A8tszqEKMAB6MSD+8P84ORQqyJZcWVucAw4mBWEuH9K3k4Uog3JbGy KrUoP76oNCe1+BCjNAeLkjhv7gygaoH0xJLU7NTUgtQimCwTB6dUA+PUyOj0cNb7p2U2Rv57 sP1nw590i0TG9FflE5k3zvZ7Ga9T8OO51HmGx46X/4j/F1y2aHruyV69ugmZcxk/Fe/q+x3C zrLi9ExVPYm37nlWG6Ll57a9ufx7xaSV7uo7dnWesWW9suj5E8261bN2XY5dXnp8wsH9jO1H 1n5/vmDF99n/9EIap9xnUGIpzkg01GIuKk4EAL8CvLRmAgAA Archived-At: Subject: Re: [Taps] One RFC, or two, for draft-ietf-taps-transports-usage and draft-ietf-taps-transports-usage-udp 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, 21 Sep 2017 02:31:37 -0000 --Boundary_(ID_R6JWEaPDUTos2vr1PItpxQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi Spencer, As an API implementer, I would say this: - I did need to reference the content of both documents (or the equivalent information that is included in the documents, before they were complete) in our implementation - However, implementing the API details for unconnected datagram-based protocols and connected stream-based is very different, even if they reside behind a common interface. To that end, both documents are necessary, but can be looked at separately while implementing an API for the protocols. I could imagine splitting up work between implementers to each focus on one of the documents, without needing to reference the other excessively. Thanks, Tommy > On Sep 18, 2017, at 9:05 AM, Spencer Dawkins at IETF wrote: > > Dear TAPSters, > > On Thu, Sep 14, 2017 at 11:02 AM, Gorry Fairhurst > wrote: > On 14/09/2017, 15:55, Spencer Dawkins at IETF wrote: > And, following up during the actual telechat ... > > On Wed, Sep 13, 2017 at 11:47 PM, Spencer Dawkins at IETF >> wrote: > > Dear TAPS working group, > > Multiple ADs have asked why these two drafts aren't a single > draft, in their ballots. Those are non-blocking comments, but I'd > like to explore that, before making a decision about what should > happen, and when. > > It occurs to me that these ADs are reading both drafts pretty much > back-to-back in preparation for balloting during IESG Evaluation. > > If people reading the two drafts back-to-back find the split to be > a distraction, I'd like to understand the views of the working > group as to how often you expect people to read both drafts, in > order to do TAPS. > > I could imagine that people working on complete TAPS APIs might > need to read both drafts. > > What about other folks you expect to read these documents? Do you > expect that some communities only need to read one of them? > > Thanks in advance for any thoughts you can share. > > Spencer, as responsible AD for TAPS > > > Both documents were approved on the telechat today, pending comment resolution of comments received during IESG Evaluation. > > So, my request to the working group to consider whether the suggestion to combine these documents makes life easier for the readers you expect will need to read one, the other, or both documents REALLY IS an honest question, and not the IESG requiring fabulously late major editorial changes without an active Discuss, because That Would Be Wrong. > > Either answer works. We'll Do The Right Thing. > > "Thanks in advance for your thoughts" :-) > > Spencer, as responsible AD, who the IESG said they trusted to "Do The Right Thing" > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > > There was a proposal from IESG to consider whether we should merge the two usage documents. So after giving this some more thought, here is my 2c about why I think we should keep the two documents: > > First, I accept it may be easier for someone reviewing the history of TAPS and the rationale for design decisions to read just a single document - putting all the material in one place is always easier. However, if published in consecutive RFCs, I'm not convinced the material would be really hard for a reader to find. > > I suggested there were two reasons behind separating this out when we did the work. First, the old and incomplete documentation for UDP needed a slightly different approach to finding the relevent RFCs. Second, the community of interest in using UDP at the IETF is typically to be found outside the TSV area, partly because of the wide variety of uses. A second document made this easier for these people to read. That's still the case for the material that was retained in the UDP usage document. > > It would be my hope that the UDP document could form a long-needed part of the documentation for UDP. I expect this would continue to be a useful resource for anyone who wishes to build datagram support into a new stack, or just wants to program to this API, and avoids people needing to wade through 50-60 pages to find a section on a UDP API. I'd also hope (??!!) this document could be maintained in future as the API continues to develop. > > Gorry > > Gorry's e-mail captured pretty much everything I need to know. I have one more question, because I know that people have implemented TAPSish APIs and demonstrated them. > > If you worked on one of those APIs, did you have to read both documents? > > Thanks in advance, and asking for (14) friends ... > > Spencer, as responsible AD > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Boundary_(ID_R6JWEaPDUTos2vr1PItpxQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Hi = Spencer,

As an API = implementer, I would say this:

- I did need to reference the content = of both documents (or the equivalent information that is included in the = documents, before they were complete) in our implementation
- However, implementing the API details for unconnected = datagram-based protocols and connected stream-based is very different, = even if they reside behind a common interface. To that end, both = documents are necessary, but can be looked at separately while = implementing an API for the protocols. I could imagine splitting up work = between implementers to each focus on one of the documents, without = needing to reference the other excessively.

Thanks,
Tommy

On Sep 18, 2017, at 9:05 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:

Dear TAPSters,

On Thu, Sep 14, 2017 at 11:02 AM, Gorry = Fairhurst <gorry@erg.abdn.ac.uk> wrote:
On 14/09/2017, 15:55, Spencer Dawkins at IETF wrote:
And, following up during the actual telechat ...

On Wed, Sep 13, 2017 = at 11:47 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com <mailto:spencerdawkins.ietf@gmail.com>> = wrote:

    Dear TAPS working group,

    Multiple ADs have asked why = these two drafts aren't a single
    draft, in their ballots. = Those are non-blocking comments, but I'd
  =   like to explore = that, before making a decision about what should
  =   happen, and = when.

    It occurs to me that these = ADs are reading both drafts pretty much
    back-to-back in preparation = for balloting during IESG Evaluation.

  =   If people = reading the two drafts back-to-back find the split to be
    a distraction, I'd like to = understand the views of the working
    group as to how often you = expect people to read both drafts, in
    order to do TAPS.

    I could imagine that people = working on complete TAPS APIs might
    need to read both = drafts.

    What about other folks you = expect to read these documents? Do you
    expect that some = communities only need to read one of them?

    Thanks in advance for any = thoughts you can share.

    Spencer, as responsible AD = for TAPS


Both documents were = approved on the telechat today, pending comment resolution of comments = received during IESG Evaluation.

So, my = request to the working group to consider whether the suggestion to = combine these documents makes life easier for the readers you expect = will need to read one, the other, or both documents REALLY IS an honest = question, and not the IESG requiring fabulously late major editorial = changes without an active Discuss, because That Would Be Wrong.

Either answer works. We'll Do The Right = Thing.

"Thanks in advance for your = thoughts" :-)

Spencer, as responsible AD, = who the IESG said they trusted to "Do The Right Thing"


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

There was a proposal from IESG to consider whether we should = merge the two usage documents. So after giving this some more thought, = here is my 2c about why I think we should keep the two documents:

First, I accept it may be easier for someone = reviewing the history of TAPS and the rationale for design decisions to = read just a single document - putting all the material in one place is = always easier. However, if published in consecutive RFCs, I'm not = convinced the material would be really hard for a reader to find.

I suggested there were two reasons behind = separating this out when we did the work. First, the old and incomplete = documentation for UDP needed a slightly different approach to finding = the relevent RFCs. Second, the community of interest in using UDP at the = IETF is typically to be found outside the TSV area, partly because of = the wide variety of uses. A second document made this easier for these = people to read. That's still the case for the material that was retained = in the UDP usage document.

It would be my = hope that the UDP document could form a long-needed part of the = documentation for UDP. I expect this would continue to be a useful = resource for anyone who wishes to build datagram support into a new = stack, or just wants to program to this API, and avoids people needing = to wade through 50-60 pages to find a section on a UDP API. I'd also = hope (??!!) this document could be maintained in future as the API = continues to develop.

Gorry

Gorry's e-mail captured pretty much = everything I need to know. I have one more question, because I know that = people have implemented TAPSish APIs and demonstrated = them. 

If = you worked on one of those APIs, did you have to read both = documents? 

Thanks in advance, and asking for (14) friends ...

Spencer, as responsible = AD 
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

= --Boundary_(ID_R6JWEaPDUTos2vr1PItpxQ)-- From nobody Wed Sep 20 20:00: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 4080F132195; Wed, 20 Sep 2017 20:00:16 -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 I2duPLMIqR72; Wed, 20 Sep 2017 20:00: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 6F5B3124B18; Wed, 20 Sep 2017 20:00:13 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id r85so3210066ywg.1; Wed, 20 Sep 2017 20:00:13 -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=QaCwGsHylqRZj/C4D54uAsjozH9kcr7BMDvWyBUulRI=; b=tW5A0afvBvs0QKR2PXQhI7gSaG6bqmIk+6ouu+xp+7ReQwOAzYIjv+4kbpRX5kulWI P6+5T1K8eYRJ33NPLzBc5MJTX9sF94wTGU+tne+QX+6IrAbMtE9cVj8Y2ywos6cFKG1n JMVALdo72MfNM7Gj+LixWcNz2XVyooC4QS+J9vQ1DU8XUmuOnueCdLs7tPKUuQRyfur3 s/xcAgrB40wZVW8FkvpAOzpBTfUcyvv5hhxC1heTGwyJPSyhS/biT7yPUBFCVUdjirNp VUiugCcXqwPWQgBR3chdy8KfvZv4+Koo3JyoBDSs/rBvgkxlsUt/VeiHixbDbEymxVlq UT/w== 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=QaCwGsHylqRZj/C4D54uAsjozH9kcr7BMDvWyBUulRI=; b=crvFjZZ4omJq4bQTbi3dkkV+6eTz7ALiNXnx+n1Var7h67MvoZiM41vAJdjqrOQPSF UiCPXhQxqhHV4yvmFFKZ1EZS7vce4klIUiurpqdmjpltRQs3KjHMN82PSw8Ggx/I2Inw y0g2YaeHlg5Na1nwFecWr4SeNt0mQGEeUp3aiXgb07L0qynq+Nad4YirRxXiFj4zITyy K5Ln5FqXIwuXG1x9+xH9yF7/Yko9wyt8kXeTKBpZumORwaMWkthxv6YlaIUtvaXvmXHM l7eHKImc23foqdJpW4BPekhGONAPeUY87uvf+pbenM4ZFIDw576131vp3lxWtGpHlPpi Z5gA== X-Gm-Message-State: AHPjjUjo4dOgFoHmU2+MrJ1wVDjYCmux1ByZBJrR1fG3aByRW4zrdMHt 8IV9xw9lsuibbXwgmdiAyZ1vTgVkVKqfyCDO/dc= X-Google-Smtp-Source: AOwi7QCVRfyCTrA11h87sbH3Op/a1nTd5z6Rgnry24V38MstveM3T5twM/Bo/R0ixAlQCY0VDnLj8VS/HEIFG9A5QO4= X-Received: by 10.129.49.75 with SMTP id x72mr604408ywx.298.1505962812438; Wed, 20 Sep 2017 20:00:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.71 with HTTP; Wed, 20 Sep 2017 20:00:11 -0700 (PDT) In-Reply-To: <438743B0-91A3-4718-A4F2-32B465110808@apple.com> References: <59BAA815.5090209@erg.abdn.ac.uk> <438743B0-91A3-4718-A4F2-32B465110808@apple.com> From: Spencer Dawkins at IETF Date: Wed, 20 Sep 2017 22:00:11 -0500 Message-ID: To: Tommy Pauly Cc: "gorry@erg.abdn.ac.uk" , taps-chairs@ietf.org, "taps@ietf.org" Content-Type: multipart/alternative; boundary="001a11421d247afe150559aa4ac2" Archived-At: Subject: Re: [Taps] One RFC, or two, for draft-ietf-taps-transports-usage and draft-ietf-taps-transports-usage-udp 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, 21 Sep 2017 03:00:16 -0000 --001a11421d247afe150559aa4ac2 Content-Type: text/plain; charset="UTF-8" Hi, Tommy On Wed, Sep 20, 2017 at 9:31 PM, Tommy Pauly wrote: > Hi Spencer, > > As an API implementer, I would say this: > > - I did need to reference the content of both documents (or the equivalent > information that is included in the documents, before they were complete) > in our implementation > - However, implementing the API details for unconnected datagram-based > protocols and connected stream-based is very different, even if they reside > behind a common interface. To that end, both documents are necessary, but > can be looked at separately while implementing an API for the protocols. I > could imagine splitting up work between implementers to each focus on one > of the documents, without needing to reference the other excessively. > This is the other half of the input I needed. Thanks for that. My theory was that most readers would not be reading both documents back-to-back, but that's the way ADs would review the documents during IESG Evaluation (they were even on the same telechat). So it's more disorienting for us, than for pretty much anyone else :-) Spencer > > Thanks, > Tommy > > > On Sep 18, 2017, at 9:05 AM, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > Dear TAPSters, > > On Thu, Sep 14, 2017 at 11:02 AM, Gorry Fairhurst > wrote: > >> On 14/09/2017, 15:55, Spencer Dawkins at IETF wrote: >> >>> And, following up during the actual telechat ... >>> >>> On Wed, Sep 13, 2017 at 11:47 PM, Spencer Dawkins at IETF < >>> spencerdawkins.ietf@gmail.com > >>> wrote: >>> >>> Dear TAPS working group, >>> >>> Multiple ADs have asked why these two drafts aren't a single >>> draft, in their ballots. Those are non-blocking comments, but I'd >>> like to explore that, before making a decision about what should >>> happen, and when. >>> >>> It occurs to me that these ADs are reading both drafts pretty much >>> back-to-back in preparation for balloting during IESG Evaluation. >>> >>> If people reading the two drafts back-to-back find the split to be >>> a distraction, I'd like to understand the views of the working >>> group as to how often you expect people to read both drafts, in >>> order to do TAPS. >>> >>> I could imagine that people working on complete TAPS APIs might >>> need to read both drafts. >>> >>> What about other folks you expect to read these documents? Do you >>> expect that some communities only need to read one of them? >>> >>> Thanks in advance for any thoughts you can share. >>> >>> Spencer, as responsible AD for TAPS >>> >>> >>> Both documents were approved on the telechat today, pending comment >>> resolution of comments received during IESG Evaluation. >>> >>> So, my request to the working group to consider whether the suggestion >>> to combine these documents makes life easier for the readers you expect >>> will need to read one, the other, or both documents REALLY IS an honest >>> question, and not the IESG requiring fabulously late major editorial >>> changes without an active Discuss, because That Would Be Wrong. >>> >>> Either answer works. We'll Do The Right Thing. >>> >>> "Thanks in advance for your thoughts" :-) >>> >>> Spencer, as responsible AD, who the IESG said they trusted to "Do The >>> Right Thing" >>> >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>> >> >> There was a proposal from IESG to consider whether we should merge the >> two usage documents. So after giving this some more thought, here is my 2c >> about why I think we should keep the two documents: >> >> First, I accept it may be easier for someone reviewing the history of >> TAPS and the rationale for design decisions to read just a single document >> - putting all the material in one place is always easier. However, if >> published in consecutive RFCs, I'm not convinced the material would be >> really hard for a reader to find. >> >> I suggested there were two reasons behind separating this out when we did >> the work. First, the old and incomplete documentation for UDP needed a >> slightly different approach to finding the relevent RFCs. Second, the >> community of interest in using UDP at the IETF is typically to be found >> outside the TSV area, partly because of the wide variety of uses. A second >> document made this easier for these people to read. That's still the case >> for the material that was retained in the UDP usage document. >> >> It would be my hope that the UDP document could form a long-needed part >> of the documentation for UDP. I expect this would continue to be a useful >> resource for anyone who wishes to build datagram support into a new stack, >> or just wants to program to this API, and avoids people needing to wade >> through 50-60 pages to find a section on a UDP API. I'd also hope (??!!) >> this document could be maintained in future as the API continues to develop. >> >> Gorry >> > > Gorry's e-mail captured pretty much everything I need to know. I have one > more question, because I know that people have implemented TAPSish APIs and > demonstrated them. > > If you worked on one of those APIs, did you have to read both documents? > > Thanks in advance, and asking for (14) friends ... > > Spencer, as responsible AD > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > > > --001a11421d247afe150559aa4ac2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Tommy

On Wed, Sep 20, 2017 at 9:31 PM, Tommy Pauly <= ;tpauly@apple.com= > wrote:
Hi Spencer,

A= s an API implementer, I would say this:

- I did ne= ed to reference the content of both documents (or the equivalent informatio= n that is included in the documents, before they were complete) in our impl= ementation
- However, implementing the API details for unconnecte= d datagram-based protocols and connected stream-based is very different, ev= en if they reside behind a common interface. To that end, both documents ar= e necessary, but can be looked at separately while implementing an API for = the protocols. I could imagine splitting up work between implementers to ea= ch focus on one of the documents, without needing to reference the other ex= cessively.

This is the other ha= lf of the input I needed. Thanks for that.

My theo= ry was that most readers would not be reading both documents back-to-back, = but that's the way ADs would review the documents during IESG Evaluatio= n (they were even on the same telechat). So it's more disorienting for = us, than for pretty much anyone else :-)

Spencer
=C2=A0

Thanks,
=
Tommy


On Sep 18, 2017, at 9:05 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmai= l.com> wrote:

Dear TAPSters,

On Thu, Sep 14, 2017 at 11:02 AM, Gorry Fai= rhurst=C2=A0<gorry@erg.abdn.ac.uk>=C2=A0wrote:
= On 14/09/2017, 15:55, Spencer Dawkins at IETF wrote:
And, following up during the actual telechat ...

On Wed, Sep 13, 2017 at 11:47 PM, Spencer Dawkins at IETF <spencerdaw= kins.ietf@gmail.com=C2=A0<mailto:spencerdawkins.ietf@gmail.com>>= wrote:

=C2=A0 =C2=A0=C2=A0Dear TAPS working group,

=C2=A0 =C2=A0=C2=A0Multip= le ADs have asked why these two drafts aren't a single
=C2=A0 =C2=A0= =C2=A0dr= aft, in their ballots. Those are non-blocking comments, but I'd
=C2= =A0 =C2=A0=C2= =A0like to explore that, before making a decision about what should<= br>=C2=A0 =C2=A0=C2=A0happen, and when.

=C2=A0 =C2=A0=C2=A0It occurs to me that thes= e ADs are reading both drafts pretty much
=C2=A0 =C2=A0=C2=A0back-to-back in pre= paration for balloting during IESG Evaluation.

=C2=A0 =C2=A0=C2=A0If people = reading the two drafts back-to-back find the split to be
=C2=A0 =C2=A0=C2=A0a di= straction, I'd like to understand the views of the working
=C2=A0 = =C2=A0=C2=A0group as to how often you expect people to read both drafts, in
=C2= =A0 =C2=A0=C2= =A0order to do TAPS.

=C2=A0 =C2=A0=C2=A0I could imagine that people w= orking on complete TAPS APIs might
=C2=A0 =C2=A0=C2=A0need to read both drafts.<= br>
=C2=A0 =C2=A0=C2=A0What about other folks you expect to read these documents= ? Do you
=C2=A0 =C2=A0=C2=A0expect that some communities only need to read one o= f them?

=C2=A0 =C2=A0=C2=A0Thanks in advance for any thoughts you can share.=

=C2=A0 =C2=A0=C2=A0Spencer, as responsible AD for TAPS


Both docu= ments were approved on the telechat today, pending comment resolution of co= mments received during IESG Evaluation.

So, my request to the workin= g group to consider whether the suggestion to combine these documents makes= life easier for the readers you expect will need to read one, the other, o= r both documents REALLY IS an honest question, and not the IESG requiring f= abulously late major editorial changes without an active Discuss, because T= hat Would Be Wrong.

Either answer works. We'll Do The Right Thin= g.

"Thanks in advance for your thoughts" :-)

Spence= r, as responsible AD, who the IESG said they trusted to "Do The Right = Thing"


__________________________________= _____________
Taps mailing list
Taps@ietf.org
https://www.ietf= .org/mailman/listinfo/taps

There was a proposa= l from IESG to consider whether we should merge the two usage documents. So= after giving this some more thought, here is my 2c about why I think we sh= ould keep the two documents:

First, I accept it may be easier for so= meone reviewing the history of TAPS and the rationale for design decisions = to read just a single document - putting all the material in one place is a= lways easier. However, if published in consecutive RFCs, I'm not convin= ced the material would be really hard for a reader to find.

I sugges= ted there were two reasons behind separating this out when we did the work.= First, the old and incomplete documentation for UDP needed a slightly diff= erent approach to finding the relevent RFCs. Second, the community of inter= est in using UDP at the IETF is typically to be found outside the TSV area,= partly because of the wide variety of uses. A second document made this ea= sier for these people to read. That's still the case for the material t= hat was retained in the UDP usage document.

It would be my hope that= the UDP document could form a long-needed part of the documentation for UD= P. I expect this would continue to be a useful resource for anyone who wish= es to build datagram support into a new stack, or just wants to program to = this API, and avoids people needing to wade through 50-60 pages to find a s= ection on a UDP API. I'd also hope (??!!) this document could be mainta= ined in future as the API continues to develop.

Gorry

Gorry's e-mail captured pretty much every= thing I need to know. I have one more question, because I know that people = have implemented TAPSish APIs and demonstrated them.=C2=A0

If you worked on one of those APIs, did you have to read both docu= ments?=C2=A0

Thanks in advance, and asking for (14= ) friends ...

Spencer, as responsible AD=C2=A0
__________________= _____________________________
Taps= @ietf.org
https://www.ietf.org/mailman/listinfo/taps
=


--001a11421d247afe150559aa4ac2--