From nobody Sun Jul 1 21:03:42 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00285130E1A for ; Sun, 1 Jul 2018 21:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 lvvwKAZ1BI1o for ; Sun, 1 Jul 2018 21:03:39 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 53C66130E00 for ; Sun, 1 Jul 2018 21:03:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZePyNfy+9uk77kJrrnsIAIbRtwDT3H/437xJP+3F55M=; b=CJsK0mfktiwxsgm/Q3PeI1aoa c5PmxqoQv5R2TIpJsGVJtCsgDXYDW6Ert5+p+IfGm6ANcTMUxmRotKvasO2ElMmj5V2auuDTfPtQ+ BKfcnilSAj4keQvQRDv/Htiiy2JWOlikh8MSbXHBCRvTW+/+Yzs7nEGVjoTR1T5Km52dTlkN5e7v0 Ipd2LFo8sNBFitNtJHByk/A4njKpPT5rhWBko91pgqNyjUeEPNZt0AVoyvByLTOzzotMDSacRgWg3 uTCsRvv2V1vtkrzfK57CksvbKR19GNOi/8OHxjtcwd5+N1RDKM4mqnqexiA8tKUG2V9xSg3N0hh/f t+mT7LGNA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:60505 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fZq3s-003eLo-CJ; Mon, 02 Jul 2018 00:03:37 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_D84AC257-FBAC-405C-8A1E-F56194CB2E73" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Joe Touch In-Reply-To: <272B6C51-AD9D-4AFB-9FFE-0CB40E6D1A37@strayalpha.com> Date: Sun, 1 Jul 2018 21:03:35 -0700 Cc: tsvwg Message-Id: <2714DC0A-60AA-41FA-B602-4BD40DE7FE81@strayalpha.com> References: <272B6C51-AD9D-4AFB-9FFE-0CB40E6D1A37@strayalpha.com> To: Tom Herbert X-Mailer: Apple Mail (2.3445.8.2) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Comment on draft-ietf-tsvwg-udp-options-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 04:03:41 -0000 --Apple-Mail=_D84AC257-FBAC-405C-8A1E-F56194CB2E73 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Catching up on a series of edits... > On Jan 21, 2018, at 2:47 PM, Joe Touch wrote: >=20 >> For instance, if >> an ACS checksum kind field flips from 3 to zero, the receiver would >> see EOL instead of ACS. I believe this is a general problem any time >> checksum or security is put in options. For GUE, we added a = disclaimer >> like this (draft-ietf-intarea-gue-extensions-02) >=20 > I can add some text addressing this. I have reconsidered this issue. It is impractical and not useful to address the different ways in which = an arbitrary byte change can =E2=80=9Cflip=E2=80=9D and the consequences = thereof. If a header checksum is used, these might be caught, but if not, all = bets are off. It=E2=80=99s not clear even that needs to be said. Joe --Apple-Mail=_D84AC257-FBAC-405C-8A1E-F56194CB2E73 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Catching up on a series of edits...

On Jan = 21, 2018, at 2:47 PM, Joe Touch <touch@strayalpha.com> wrote:

For = instance, if
an ACS checksum kind field flips from 3 to = zero, the receiver would
see EOL instead of ACS. I believe = this is a general problem any time
checksum or security is = put in options. For GUE, we added a disclaimer
like this = (draft-ietf-intarea-gue-extensions-02)

I can add some text addressing = this.

I have = reconsidered this issue.

It is = impractical and not useful to address the different ways in which an = arbitrary byte change can =E2=80=9Cflip=E2=80=9D and the consequences = thereof.

If a header checksum is = used, these might be caught, but if not, all bets are off. It=E2=80=99s = not clear even that needs to be said.

Joe

= --Apple-Mail=_D84AC257-FBAC-405C-8A1E-F56194CB2E73-- From nobody Sun Jul 1 22:33:49 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B53130E23; Sun, 1 Jul 2018 22:33:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153050962153.27521.12163204500355119687@ietfa.amsl.com> Date: Sun, 01 Jul 2018 22:33:41 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 05:33:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : Transport Options for UDP Author : Joe Touch Filename : draft-ietf-tsvwg-udp-options-03.txt Pages : 28 Date : 2018-07-01 Abstract: Transport protocols are extended through the use of transport header options. This document experimentally extends UDP by indicating the location, syntax, and semantics for UDP transport layer options. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-03 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-udp-options-03 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 Sun Jul 1 23:25:11 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93EF0130E0A; Sun, 1 Jul 2018 23:25:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153051270358.30578.18443141841143213674@ietfa.amsl.com> Date: Sun, 01 Jul 2018 23:25:03 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 06:25:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : Transport Options for UDP Author : Joe Touch Filename : draft-ietf-tsvwg-udp-options-04.txt Pages : 29 Date : 2018-07-01 Abstract: Transport protocols are extended through the use of transport header options. This document experimentally extends UDP by indicating the location, syntax, and semantics for UDP transport layer options. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-04 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-udp-options-04 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 Sun Jul 1 23:28:16 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE0C130E4C; Sun, 1 Jul 2018 23:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 6XY5ZZV7vh3w; Sun, 1 Jul 2018 23:28:06 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 C7DDC130E7F; Sun, 1 Jul 2018 23:28:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2sExmVJsaYnUssb46TlLh796lo8ZFwh0FdsUji3q2wk=; b=slUVI3NFgSQ0vTae7FLiBOATZ 2UkOw4z3Ei0WZLqMR2dID5bkxle8/0X7OlFc6VjrNxCNn1mmh0yGJouKF906Pd9Zhv+lZJ4MOCOEC joWgTTf9mhZM2RfVFiCse9H5Wf/XM32WnAatRxqvZ5aJ5U1FJCMSjvN6v+maueNvXQiozj+jnWKBE NPVZmAB7Tr95RsR8HBuRYTBatf7aYV7yBWKcKw4gZc9ovXlqPfYGIgh5+bN6qwobHYhpooRClyxKZ 104LsOPsnVqC0KG4u6mh+z6Djc5XJloJEfaoMgKTNX6MFQl2M7tbRykTH5spK48j5aQiGcYNz6fXS 2wqRueIbw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:61008 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fZsJd-001MWD-CJ; Mon, 02 Jul 2018 02:28:04 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Joe Touch In-Reply-To: <153051270358.30578.18443141841143213674@ietfa.amsl.com> Date: Sun, 1 Jul 2018 23:28:00 -0700 Cc: i-d-announce@ietf.org, tsvwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <153051270358.30578.18443141841143213674@ietfa.amsl.com> To: internet-drafts@ietf.org X-Mailer: Apple Mail (2.3445.8.2) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 06:28:15 -0000 Hi, all, This second version corrects the revised option numbers, provides a = little more detail on the AE and EXP options, and makes clear that the = LITE option is slid back by 0-3 bytes the same way it was slid forward = for that case.=20 For the complete set of changes, please compare versions 02 and 04. Joe > On Jul 1, 2018, at 11:25 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Area Working Group WG of = the IETF. >=20 > Title : Transport Options for UDP > Author : Joe Touch > Filename : draft-ietf-tsvwg-udp-options-04.txt > Pages : 29 > Date : 2018-07-01 >=20 > Abstract: > Transport protocols are extended through the use of transport header > options. This document experimentally extends UDP by indicating the > location, syntax, and semantics for UDP transport layer options. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-04 > https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-udp-options-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 From nobody Sun Jul 1 23:36:44 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642B3130E3C; Sun, 1 Jul 2018 23:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 r9opNK0KeGpJ; Sun, 1 Jul 2018 23:36:40 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 92C4A130E17; Sun, 1 Jul 2018 23:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=h/9/h40eKrVFMBAMX6tRWUcfESrNcA4i+TJtO5Qb4Ws=; b=2N+M9GSy0imgTiJLKzmgppgR5 dAQqQJvX5w9nAxduQCu1RwfLDgIdA1y3mW/L9KqqTI2USxXByKkq1egFKX2ZLfwhS+6hR/l5Lu68O GG1TOMTT0q1ACs2htB93tSj586jwgzKrjABPpdFnEHfHmOjZCfI97CDGOme+Lk3pjOpOVM+4tY3ku G//b+Okk+M8oxxZ0PW1a07N/QBzprSd600Zw0EpkmByYNNDCenik8dckoqAAoXmqRv7JNCSCnY8NW pCSTqsea7SLLu0OhKbpIxHtgU0rfvzGRaODBQNYKTp2/oENep2ENzqgkdMjzm5mu5BETTJK1R/aaZ n5gLJxVFQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:61064 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fZsRy-001TN9-Ar; Mon, 02 Jul 2018 02:36:40 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Joe Touch In-Reply-To: <153050962153.27521.12163204500355119687@ietfa.amsl.com> Date: Sun, 1 Jul 2018 23:36:36 -0700 Cc: i-d-announce@ietf.org, tsvwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <11FA5114-93C4-4526-9AC5-B492F984C403@strayalpha.com> References: <153050962153.27521.12163204500355119687@ietfa.amsl.com> To: internet-drafts@ietf.org X-Mailer: Apple Mail (2.3445.8.2) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 06:36:43 -0000 Hi, all, This adds all pending changes, notably: - a few typos - the LITE option for the 0-3 byte case - renumbers the options for the following reason: - ensures that all the required options come first - clarifies the computation of the CRC for ACS and OCS - sections reordered to match the sequence assigned The following has not changed: - the options remain TLV, matching the way TCP options are parsed - OCS remains optional These details will be discussed in the second TSVWG session. FYI - here=E2=80=99s a link to easily compare version 2 with the newest = version 4: = https://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-tsvwg-udp-options-02.txt?= url2=3Ddraft-ietf-tsvwg-udp-options-04.txt Joe > On Jul 1, 2018, at 10:33 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Area Working Group WG of = the IETF. >=20 > Title : Transport Options for UDP > Author : Joe Touch > Filename : draft-ietf-tsvwg-udp-options-03.txt > Pages : 28 > Date : 2018-07-01 >=20 > Abstract: > Transport protocols are extended through the use of transport header > options. This document experimentally extends UDP by indicating the > location, syntax, and semantics for UDP transport layer options. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-03 > https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-udp-options-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 From nobody Mon Jul 2 02:06:40 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1803F130E4A for ; Mon, 2 Jul 2018 02:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 UqY1XhqM4oh3 for ; Mon, 2 Jul 2018 02:06:36 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 DF2E71277BB for ; Mon, 2 Jul 2018 02:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1530522394; 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=3dK+KOTuTmK3sk9DOAt/TWn7HDW+8amBWU6LAXS8OXw=; b=GSncEhEujuzVw8zf/ItWZgRXjI+8oFUk4vDB0MVqcY9b2l26rMx2f8WCXrdGVPAs k1q/SxRQ4VdPeWC4p0ZRWz16bEXdLT5yBb1QtIaOqNLDfAc55rBoKB5lvaOJUan0 S7YgvyG4gQhQ43J37lIlO0PMyMhHNCTc7S1H/w8B/l4=; X-AuditID: c1b4fb2d-223ff700000055ff-bb-5b39eb1a4328 Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 9F.05.22015.A1BE93B5; Mon, 2 Jul 2018 11:06:34 +0200 (CEST) Received: from [147.214.20.27] (153.88.183.153) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 2 Jul 2018 11:06:33 +0200 To: tsvwg IETF list , From: Magnus Westerlund Message-ID: Date: Mon, 2 Jul 2018 11:06:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------14542A322F56651CC1E6FCA6" Content-Language: en-GB X-Originating-IP: [153.88.183.153] X-ClientProxiedBy: ESESBMB502.ericsson.se (153.88.183.169) To ESESSMB502.ericsson.se (153.88.183.163) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM2J7ha7Ua8tog1WPuCzWT7zMZnHszV02 ByaPJUt+MgUwRnHZpKTmZJalFunbJXBl9D75x1zQZ1Lx9MkxlgbG5xpdjJwcEgImEnN232fq YuTiEBI4yijR9XchM4TzjlFi5ZH7jCBVIgIhEu+un2MBsdkELCRu/mhkA7GFBbwl7l67D2bz CthLfGj9wQRiswioSNxe+RqsV1QgRmL1xsvsEDWCEidnPgGbwywQJtFwdCMbhC0u0fRlJSuI LSSgLdHQ1MEKcZ2SxPV511kg7HSJbVd+s01g5J+FZNQsJKNmIRk1i5EDyLaXeLC1DCIsL7H9 7RxmCFtf4vqd+6ww8eats5kXMLKvYhQtTi0uzk03MtZLLcpMLi7Oz9PLSy3ZxAgM6oNbfuvu YFz92vEQowAHoxIP764XltFCrIllxZW5hxglOJiVRHhFP5pHC/GmJFZWpRblxxeV5qQWH2KU 5mBREufVW7UnSkggPbEkNTs1tSC1CCbLxMEp1cC4KmPHwoou64jEokOqO7XFd+fcaJk5V1U1 4VTj/PYFba6dyg6Pbx1T1TEwyH5vnGgz++gJuymfOSf0HtVavIXd8NbqH98nbc/RfZsovyT6 idaTx0sYtyjZSDm5eu8tM7Nb02uc9rjjXv+1Vf92qlddMVhVk221rpIxvXKZiOOCX5YsG+VL Ji1UYinOSDTUYi4qTgQAuaX+s2YCAAA= Archived-At: Subject: [tsvwg] draft-ietf-tsvwg-datagram-plpmtud-02: What to do with PTB > PLPMTU X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 09:06:38 -0000 --------------14542A322F56651CC1E6FCA6 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Hi, Due to discussion started by Igor Lubashev on PLPTMUD for QUIC on the QUIC WG mailing list an issue that this draft can address is what to do when PTB messages that are verified indicate a PTB_SIZE < PLPMTU. The draft currently says: 3.3. Reducing the PLPMTU: Confirming Path Characteristics If the DPLPMTUD method detects that a packet with the PLPMTU size is no supported by the network path, then the DLPMTUD method needs to validate the PLPMTU. This can happen when a validated PTB message is received, or another event that indicates the network path no longer sustains this packet size, such as a loss report from the PL All implementations of DPLPMTUD are REQUIRED to provide support that reduces the PLPMTU when the actual PMTU supported by a network path is less than the PLPMTU. Section 4.9 says: PROBE_DONE: The PROBE_DONE state indicates a successful end to a probing phase. DPLPMTUD remains in this state until either the PMTU_RAISE_TIMER expires or a received PTB message is verified. However, I don't find any text saying what to do when the PTB message is received. Is the intention to go to PROBE_BASE and then probe up again, or the more efficient to perform PROBE_SEARCH starting at PTB_SIZE? As a more general comment, I get confused by the PTB related arrows in the state diagram in Section 4.9. A. I don't understand why PTB (>= BASE_PMTU) goes from PROBE_BASE to PROBE_DONE? For my perspective such a message can't arise from a PROBE_BASE action. It should only arise when doing PROBE_SEARCH. B. Also I don't understand PTB (< PROBED_SIZE) from PROBE_SEARCH to PROBE_BASE. 1. Shouldn't this event be PTB < PLPMTU? 2. or if PLPMTU < PTB_SIZE < PROBED_SIZE re-enter PROBE_SEARCH with PROBED_SIZE = PTB_SIZE? 3. And if PLPMTU < PTB_SIZE < PLPMTU + CLOSE_ENOUGH declare PROBE_DONE. Where CLOSE_ENOUGH is the number of bytes that you consider close enough to not probe again. Comment B.2 and B.3 are related to that there appear no indication in the diagram for how to get to PROBE_DONE base on PTB. Although the state text for PROBE_SEARCH says the not so clear: The state is exited when the PROBE_COUNT reaches MAX_PROBES; a PTB message is verified; or a probe of size PMTU_MAX is acknowledged. Cheers Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------14542A322F56651CC1E6FCA6 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit

Hi,

Due to discussion started by Igor Lubashev on PLPTMUD for QUIC on the QUIC WG mailing list an issue that this draft can address is what to do when PTB messages that are verified indicate a PTB_SIZE < PLPMTU.

The draft currently says:

3.3.  Reducing the PLPMTU: Confirming Path Characteristics

   If the DPLPMTUD method detects that a packet with the PLPMTU size is
   no supported by the network path, then the DLPMTUD method needs to
   validate the PLPMTU. This can happen when a validated PTB message is
   received, or another event that indicates the network path no longer
   sustains this packet size, such as a loss report from the PL

   All implementations of DPLPMTUD are REQUIRED to provide support that
   reduces the PLPMTU when the actual PMTU supported by a network path
   is less than the PLPMTU.

Section 4.9 says:
   PROBE_DONE: The PROBE_DONE state indicates a successful end to a
      probing phase.  DPLPMTUD remains in this state until either the
      PMTU_RAISE_TIMER expires or a received PTB message is verified.
However, I don't find any text saying what to do when the PTB message is received.

Is the intention to go to PROBE_BASE and then probe up again, or the more efficient to perform PROBE_SEARCH starting at PTB_SIZE?


As a more general comment, I get confused by the PTB related arrows in the state diagram in Section 4.9.

A. I don't understand why PTB (>= BASE_PMTU) goes from PROBE_BASE to PROBE_DONE? For my perspective such a message can't arise from a PROBE_BASE action. It should only arise when doing PROBE_SEARCH.

B. Also I don't understand PTB (< PROBED_SIZE) from PROBE_SEARCH to PROBE_BASE.
1. Shouldn't this event be PTB < PLPMTU?
2. or if PLPMTU < PTB_SIZE < PROBED_SIZE re-enter PROBE_SEARCH with PROBED_SIZE = PTB_SIZE?
3. And if PLPMTU < PTB_SIZE < PLPMTU + CLOSE_ENOUGH declare PROBE_DONE. Where CLOSE_ENOUGH is the number of bytes that you consider close enough to not probe again.

Comment B.2 and B.3 are related to that there appear no indication in the diagram for how to get to PROBE_DONE base on PTB. Although the state text for PROBE_SEARCH says the not so clear:

      The state is exited when the PROBE_COUNT
      reaches MAX_PROBES; a PTB message is verified; or a probe of size
      PMTU_MAX is acknowledged.


Cheers
Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------
--------------14542A322F56651CC1E6FCA6-- From nobody Mon Jul 2 04:50:41 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99967130F53; Mon, 2 Jul 2018 04:50:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153053222655.27909.8595812972303127418@ietfa.amsl.com> Date: Mon, 02 Jul 2018 04:50:26 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-datagram-plpmtud-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 11:50:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : Packetization Layer Path MTU Discovery for Datagram Transports Authors : Godred Fairhurst Tom Jones Michael Tuexen Irene Ruengeler Filename : draft-ietf-tsvwg-datagram-plpmtud-03.txt Pages : 38 Date : 2018-07-02 Abstract: This document describes a robust method for Path MTU Discovery (PMTUD) for datagram Packetization layers. The document describes an extension to RFC 1191 and RFC 8201, which specifies ICMP-based Path MTU Discovery for IPv4 and IPv6. The method allows a Packetization Layer (PL), or a datagram application that uses a PL, to discover whether a network path can support the current size of datagram. This can be used to detect and reduce the message size when a sender encounters a network black hole (where packets are discarded, and no ICMP message is received). The method can also probe a network path with progressively larger packets to find whether the maximum packet size can be increased. This allows a sender to determine an appropriate packet size, providing functionally for datagram transports that is equivalent to the Packetization layer PMTUD specification for TCP, specified in RFC4821. The document also provides implementation notes for incorporating Datagram PMTUD into IETF Datagram transports or applications that use transports. When published, this specification updates RFC4821. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-datagram-plpmtud-03 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-datagram-plpmtud-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-datagram-plpmtud-03 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 Mon Jul 2 06:42:18 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C144130F20; Mon, 2 Jul 2018 06:42:10 -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-tsvwg-rfc4960-errata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, gorry@erg.abdn.ac.uk, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153053893062.16074.3962132072235903491.idtracker@ietfa.amsl.com> Date: Mon, 02 Jul 2018 06:42:10 -0700 Archived-At: Subject: [tsvwg] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-tsvwg-rfc4960-errata-06=3A_=28with_COMMENT=29?= X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 13:42:12 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-tsvwg-rfc4960-errata-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-tsvwg-rfc4960-errata/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) sec 3.27.2: " o When the endpoint does not transmit data on a given transport address, the cwnd of the transport address SHOULD be adjusted to max(cwnd/2, 4*MTU) per RTO. At the first cwnd adjustment, the ssthresh of the transport address SHOULD be adjusted to the cwnd." This part is still unclear to me. What does adjust "per RTO mean"? I guess it is sufficient to adjust it once after the first RTO without data, no? Also I assume ssthresh is set after the cwnd adjustment? 2) sec 3.28.2 "An SCTP receiver MUST NOT generate more than one SACK for every incoming packet, other than to update the offered window as the receiving application consumes new data. When the window opens up, an SCTP receiver SHOULD send additional SACK chunks to update the window even if no new data is received. The receiver MUST avoid sending large bursts of window updates." This is also not super well specified now. What is a large burst? I would rather like to see something like "The receiver MUST not send more then one window update per RTT." 3) 3.31. Would it make sense to then use a different variable, e.g. cwnd_temp or max_send_limit, and not cwnd...? 4) Text changes in sec 3.35.2. are kind of unclear. I assume the new text should be added at the end of the old text sections...? From nobody Mon Jul 2 08:56:32 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5A21311DF for ; Mon, 2 Jul 2018 08:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 8hQG8LS6TU9P for ; Mon, 2 Jul 2018 08:56:22 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC1513122D for ; Mon, 2 Jul 2018 08:56:21 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id y4-v6so8901957qka.5 for ; Mon, 02 Jul 2018 08:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rH8l+gMJ2glbddPohWRKNSvVhvvCLWymonTH/achSg8=; b=QIEpV8ORxrSDHpFitTnZyHbG81IW+EZAUgqeHr/+7mJvMm6YMAt9q6ns7FgryTI3Gp AJINhfr5inwa+kK9l2ZJ8fK25K7Sip8sLsk0PLuH7RU3K5krtQm1v2P4JQmBWvT8GggB C+tVlGCHDcCsSGoHilI00PfF6qVTFqLcpvV7SMwNlowMHiczL/r82PxaFHIW29lPvDjq w66MP3XYLYiM483L5DIS7RifSx9+80rSkW+MVhGOeF84ifwLckXmSvYpvlOzPYanb1K0 Lu3lZEUSe24/YKKIkdeAc36JN9zhwy0wB0pMppUyUyGESaVGbkE/ozh2xhzKRxQLi2VX 5Ztg== 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:content-transfer-encoding; bh=rH8l+gMJ2glbddPohWRKNSvVhvvCLWymonTH/achSg8=; b=uh7elcpa5vG61mNvGbUAHFeXX5C83Q5UAw8+VsynaoF526h7MucRJD6YzyEN0KGTfY 0quEXPax4V53XDxO2KK1dRdQBmYGuXEDLV4Bi91CWMCACxMnb6hlg3G7QIJIUTvlZD7q SE+8cmfMYFp45/ab9dZ9nPf5UDksE86m/KjE7b9BT95wAJ4v5qzVQLjnseD1VqqkB0DI J0CMusOOWCtasOxMjOUbshC95uxz00zN/ZNfq6qsdP+6m1s04/SKF4ADhi1RvNwgngYu WWjWtjuCD0+n8daRixAk1PugIZqEiTJz1Kf6/jlmH7s2lUBp6hkJOOOvZ5CeKAKdYmBr ssww== X-Gm-Message-State: APt69E3waEth1072uKows+u6kHdtxVjjemrdi09ZDUmMvwOg/JVf5JP0 +L8K4QZf2sVJvDrrjw91xxt3/MP2QVw/+M+ZgrpXUd3X X-Google-Smtp-Source: AAOMgpffdO/GDAU25YixTbuIgVReRD4E9Ax81f8fOwkxF91XVkuWAh7658j3LMNWTbKRTNrVleULQi+yXsXe43bQC1U= X-Received: by 2002:a37:1fdf:: with SMTP id n92-v6mr23299660qkh.333.1530546980750; Mon, 02 Jul 2018 08:56:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:3304:0:0:0:0:0 with HTTP; Mon, 2 Jul 2018 08:56:20 -0700 (PDT) In-Reply-To: <2714DC0A-60AA-41FA-B602-4BD40DE7FE81@strayalpha.com> References: <272B6C51-AD9D-4AFB-9FFE-0CB40E6D1A37@strayalpha.com> <2714DC0A-60AA-41FA-B602-4BD40DE7FE81@strayalpha.com> From: Tom Herbert Date: Mon, 2 Jul 2018 08:56:20 -0700 Message-ID: To: Joe Touch Cc: tsvwg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] Comment on draft-ietf-tsvwg-udp-options-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 15:56:30 -0000 On Sun, Jul 1, 2018 at 9:03 PM, Joe Touch wrote: > Catching up on a series of edits... > > On Jan 21, 2018, at 2:47 PM, Joe Touch wrote: > > For instance, if > an ACS checksum kind field flips from 3 to zero, the receiver would > see EOL instead of ACS. I believe this is a general problem any time > checksum or security is put in options. For GUE, we added a disclaimer > like this (draft-ietf-intarea-gue-extensions-02) > > > I can add some text addressing this. > > > I have reconsidered this issue. > > It is impractical and not useful to address the different ways in which a= n > arbitrary byte change can =E2=80=9Cflip=E2=80=9D and the consequences the= reof. > > If a header checksum is used, these might be caught, but if not, all bets > are off. It=E2=80=99s not clear even that needs to be said. To follow your gaming analogy, when a sender inserts a checksum or integrity check it is making a bet that corrupted packets will be detected (the wager is the cost of computing the checksum). Any type of check can be assigned a probability that corrpupted packets will be detected. Suppose that a mandatory checksum (like in TCP or IP) has probability 'p_m' and and optional checksum has probability 'p_o'. Then we know that 'p_m > p_o' because the the data check can detect corruption of the checksum information, but an optional checksum misses corruption of the type field for the checksum. Manadory checksum is a better bet for the sender, question is how much better is it. For UDP options, my biggest concern is still misinterpretation of the slack space. I don't believe it has been proven that in the 40 year history of UDP no packets are being sent with an UDP length/IP lenght mismatch, although I do wonder if this has ever been used covert channel. A fixed UDP options header with a checksum would probabilistically ensure that such misinterpretion won't happen-- at a cost of just a few bytes. Tom > > Joe > From nobody Mon Jul 2 09:05:36 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09FA7130EDD for ; Mon, 2 Jul 2018 09:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 2ZFjoYgufNbG for ; Mon, 2 Jul 2018 09:05:32 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9628C130E10 for ; Mon, 2 Jul 2018 09:05:31 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id y20-v6so14195406qto.8 for ; Mon, 02 Jul 2018 09:05:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=V2zolkargeGwbmcQDU+2wZSJL8exzGs3MKi+hsRGQ3I=; b=GALqe9eqtoCvxrkDGfEj+o/LeDQK5zDT1/B7Es49s5myUZcfuwyLSHBtgAMLjNrjwR GYCjxVnPhYnPna0oZn6KonCcO3tyzu68/RoogA1lYuqQ4f91Y/Jg6GL1eUo87bhNegt7 9K6j2FFFqFmxi7HdMva2Cd1PK3XZCzBkxL5VJq1Ag1CgIepTmdNQ/g/jrXJfP/0K/far UCRAEQA8RcAZwm5u4iCs2UNuViMszQ2UZelsE+jh5X34AsvYauF4UZnk83CJeS5chKyx 8MHY/eoh4CeneHwYwPQNyMfQdIOEoacqu+nHPJOyCOJ9UH9haPjL2vfMIzFBoBJKq6pA BqkA== 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:content-transfer-encoding; bh=V2zolkargeGwbmcQDU+2wZSJL8exzGs3MKi+hsRGQ3I=; b=L515UmW1MORhDRGngsD+niA6svXLXthDI7kLUN0lkJRMV9vIzGk3TeL+zl2hJJ4CVO CR1S67dxBt/70zlyafMj9r0KzCp3NTIq0j/ZmPx62l8/wRy9I1Otc6XjOmo/awo/eRz6 ERN4y8jcTeoZJZ6/dCZUSXxvOoTjkD4uXx6X+82dUkoRRLtcq9x15AkIZHnID+eouq7J UA+Q5JcIPm+xy+HrIy6ImNIfcCLhZRjXK/pK7SDbmDxC1UWQRx0YVs4NfRsYp9nNPyh2 RYKxECQih8IAb268LrO2DQiHrXzlGCIQxK3/q+W3yKQXD85vw6yZcZCMlAOxNgB7+Kpt IF+A== X-Gm-Message-State: APt69E0++8ZK7/Sg6WEV4PXdQB7eQBPp6i3xZG7I5RWKLQ0CRkAiF9C6 egk98TvOIVXJxzMbIM4fI2KX5DHnBb/IfW+zsce4NQ== X-Google-Smtp-Source: AAOMgpeKZ5T+QGoAlRJV28U3s/Ui091fI/H/k98YT6ZSy0UUSLOiu7OKlf14JPqI9rFcuE1cjJ1teDkLl3f31N0xrwY= X-Received: by 2002:a0c:f94e:: with SMTP id i14-v6mr7667747qvo.73.1530547530524; Mon, 02 Jul 2018 09:05:30 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:3304:0:0:0:0:0 with HTTP; Mon, 2 Jul 2018 09:05:30 -0700 (PDT) In-Reply-To: <11FA5114-93C4-4526-9AC5-B492F984C403@strayalpha.com> References: <153050962153.27521.12163204500355119687@ietfa.amsl.com> <11FA5114-93C4-4526-9AC5-B492F984C403@strayalpha.com> From: Tom Herbert Date: Mon, 2 Jul 2018 09:05:30 -0700 Message-ID: To: Joe Touch Cc: tsvwg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 16:05:34 -0000 On Sun, Jul 1, 2018 at 11:36 PM, Joe Touch wrote: > Hi, all, > > This adds all pending changes, notably: > - a few typos > - the LITE option for the 0-3 byte case > - renumbers the options for the following reason: > - ensures that all the required options come first > - clarifies the computation of the CRC for ACS and OCS > - sections reordered to match the sequence assigned > > The following has not changed: > - the options remain TLV, matching the way TCP options are parsed > - OCS remains optional > Hi Joe, Can you explain why OCS uses a one byte checksum instead of the standard two byte ones' complement checksum used in IP. There is no benefit to hosts for computing a one byte checksum (it's actually slightly harder because an additional fold is needed), so the only possible benefit I see is that it saves two bytes. Note that a one byte checksum is substantially weaker than two bytes, so I'm not sure that saving a couple of bytes is worth it. Tom > These details will be discussed in the second TSVWG session. > > FYI - here=E2=80=99s a link to easily compare version 2 with the newest v= ersion 4: > https://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-tsvwg-udp-options-02.txt= ?url2=3Ddraft-ietf-tsvwg-udp-options-04.txt > > Joe > >> On Jul 1, 2018, at 10:33 PM, internet-drafts@ietf.org wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Transport Area Working Group WG of the = IETF. >> >> Title : Transport Options for UDP >> Author : Joe Touch >> Filename : draft-ietf-tsvwg-udp-options-03.txt >> Pages : 28 >> Date : 2018-07-01 >> >> Abstract: >> Transport protocols are extended through the use of transport header >> options. This document experimentally extends UDP by indicating the >> location, syntax, and semantics for UDP transport layer options. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-03 >> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-03 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-udp-options-03 >> >> >> Please note that it may take a couple of minutes from the time of submis= sion >> 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 Mon Jul 2 10:26:47 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0BC9130FBE for ; Mon, 2 Jul 2018 10:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 LeZm1PWwDx25 for ; Mon, 2 Jul 2018 10:26:31 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 0D6CA131270 for ; Mon, 2 Jul 2018 10:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=VKSE4L+tA4DeSUE584Qvo6DzlNhtaOSXXzP8BYd05l0=; b=eP7vdEiKwyBWIdwuzcnKplD0p u+GNxM/dfobpo03MpyYW3/j0T76xD+Xgt+rdJzIqn7cTWs6G29UvJljMTNzEyoAdB2jjR1ZpMw0GR GafduzHoTlVLq5NbRmwXNLOKsGMVn707tg0cKv+F//o/HsuO2rW7mjjd/N1/H4nAoJ0fbtAiJVNWe ABAA7L0cwTIQUXrnNAw2JwVr2J89BxMQRRSjdk8KKcNNuuyHtLlNhcx9HCXmHQBaHRXcZLGOIiGBu jNtutVwZSyGoFCjKi2kU/Inp4AIDghA+qTFfdyT5MNoMnHemJNzF1X8PN4/3G22qNuUSpk0o9NQ62 kapD+YBKA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:61468 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fa2am-003pxL-Tk; Mon, 02 Jul 2018 13:26:28 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Joe Touch In-Reply-To: Date: Mon, 2 Jul 2018 10:26:23 -0700 Cc: tsvwg Content-Transfer-Encoding: quoted-printable Message-Id: References: <153050962153.27521.12163204500355119687@ietfa.amsl.com> <11FA5114-93C4-4526-9AC5-B492F984C403@strayalpha.com> To: Tom Herbert X-Mailer: Apple Mail (2.3445.8.2) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 17:26:46 -0000 Hi Tom,=20 Yeah - it was to make it 16-bit. Yes, it=E2=80=99s a lot weaker, but = it=E2=80=99s also over a typically much smaller set of bytes. We can make it longer if that=E2=80=99s consensus. I=E2=80=99ll add it = to the discussion topics. Joe > On Jul 2, 2018, at 9:05 AM, Tom Herbert wrote: >=20 > On Sun, Jul 1, 2018 at 11:36 PM, Joe Touch = wrote: >> Hi, all, >>=20 >> This adds all pending changes, notably: >> - a few typos >> - the LITE option for the 0-3 byte case >> - renumbers the options for the following reason: >> - ensures that all the required options come first >> - clarifies the computation of the CRC for ACS and OCS >> - sections reordered to match the sequence assigned >>=20 >> The following has not changed: >> - the options remain TLV, matching the way TCP options are parsed >> - OCS remains optional >>=20 > Hi Joe, >=20 > Can you explain why OCS uses a one byte checksum instead of the > standard two byte ones' complement checksum used in IP. There is no > benefit to hosts for computing a one byte checksum (it's actually > slightly harder because an additional fold is needed), so the only > possible benefit I see is that it saves two bytes. Note that a one > byte checksum is substantially weaker than two bytes, so I'm not sure > that saving a couple of bytes is worth it. >=20 > Tom >=20 >> These details will be discussed in the second TSVWG session. >>=20 >> FYI - here=E2=80=99s a link to easily compare version 2 with the = newest version 4: >> = https://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-tsvwg-udp-options-02.txt?= url2=3Ddraft-ietf-tsvwg-udp-options-04.txt >>=20 >> Joe >>=20 >>> On Jul 1, 2018, at 10:33 PM, internet-drafts@ietf.org wrote: >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the Transport Area Working Group WG of = the IETF. >>>=20 >>> Title : Transport Options for UDP >>> Author : Joe Touch >>> Filename : draft-ietf-tsvwg-udp-options-03.txt >>> Pages : 28 >>> Date : 2018-07-01 >>>=20 >>> Abstract: >>> Transport protocols are extended through the use of transport = header >>> options. This document experimentally extends UDP by indicating the >>> location, syntax, and semantics for UDP transport layer options. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ >>>=20 >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-03 >>> = https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-03 >>>=20 >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-udp-options-03 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>=20 From nobody Mon Jul 2 10:42:38 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9877B130DDA for ; Mon, 2 Jul 2018 10:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 GLdj2EtU0_Dq for ; Mon, 2 Jul 2018 10:42:31 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 EE54512D7F8 for ; Mon, 2 Jul 2018 10:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IfvRaCntRsgcyl4Rbkah0yMdW6+DM/tHzbTtmlJjwxU=; b=sPMaPzPPB+J2W6W7bhO2Ze3vI CBnCG4mXOkWbhvqSrt5xBazYi1vkCTP1MsQc4toNQJuwqBZiGTLY7VM87G5507O7PogRuxU4Eohjl ND4V++6ZC69Yj+bQDDLT7fbafql3gKqrS7Iy2uJ0yT2bGhmbyUYfzi/JfXCzKRSf6I6ILLkrRWDhM 1pSBlmEK8S9LsndY4vV8TVGJJhvS6ivy+6GyoLP0+YYtw2V52h2+XBqthYU4wfuxRSEdhD1FBbomn DY6SmmFik9ZUYbgrNznF/JDIDHx0BClDe15hxvpI7fLMKlNbXtdWSFuYQMO8mGJzHQMOZfjqxMhk4 xjzxTNgxQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:61554 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fa2qL-004502-0n; Mon, 02 Jul 2018 13:42:30 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Joe Touch In-Reply-To: Date: Mon, 2 Jul 2018 10:42:28 -0700 Cc: tsvwg Content-Transfer-Encoding: quoted-printable Message-Id: References: <272B6C51-AD9D-4AFB-9FFE-0CB40E6D1A37@strayalpha.com> <2714DC0A-60AA-41FA-B602-4BD40DE7FE81@strayalpha.com> To: Tom Herbert X-Mailer: Apple Mail (2.3445.8.2) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Comment on draft-ietf-tsvwg-udp-options-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 17:42:36 -0000 > On Jul 2, 2018, at 8:56 AM, Tom Herbert wrote: >=20 > On Sun, Jul 1, 2018 at 9:03 PM, Joe Touch = wrote: >> Catching up on a series of edits... >>=20 >> On Jan 21, 2018, at 2:47 PM, Joe Touch wrote: >>=20 >> For instance, if >> an ACS checksum kind field flips from 3 to zero, the receiver would >> see EOL instead of ACS. I believe this is a general problem any time >> checksum or security is put in options. For GUE, we added a = disclaimer >> like this (draft-ietf-intarea-gue-extensions-02) >>=20 >>=20 >> I can add some text addressing this. >>=20 >>=20 >> I have reconsidered this issue. >>=20 >> It is impractical and not useful to address the different ways in = which an >> arbitrary byte change can =E2=80=9Cflip=E2=80=9D and the consequences = thereof. >>=20 >> If a header checksum is used, these might be caught, but if not, all = bets >> are off. It=E2=80=99s not clear even that needs to be said. >=20 > To follow your gaming analogy, when a sender inserts a checksum or > integrity check it is making a bet that corrupted packets will be > detected (the wager is the cost of computing the checksum). Any type > of check can be assigned a probability that corrpupted packets will be > detected. Suppose that a mandatory checksum (like in TCP or IP) has > probability 'p_m' and and optional checksum has probability 'p_o'. > Then we know that 'p_m > p_o' because the the data check can detect > corruption of the checksum information, but an optional checksum > misses corruption of the type field for the checksum. Manadory > checksum is a better bet for the sender, question is how much better > is it. >=20 > For UDP options, my biggest concern is still misinterpretation of the > slack space. Agreed - the question is whether that check needs to be very strong. > I don't believe it has been proven that in the 40 year > history of UDP no packets are being sent with an UDP length/IP lenght > mismatch, It=E2=80=99s impossible to prove a negative without complete = information; given we can=E2=80=99t see every packet on the Internet = over the past 40 years, there can never be such a proof... > although I do wonder if this has ever been used covert > channel. Sure - but there are plenty of other covert channels in Internet = protocols that are easier to use.. > A fixed UDP options header with a checksum would > probabilistically ensure that such misinterpretion won't happen-- at a > cost of just a few bytes. Probabilistically, a single byte checksum might be sufficient to catch = this happening in a sequence of such packets, though.=20 We could add text that if a large number of packets fail the test, then = we would assume the option area is not supported and disable it. Joe= From nobody Mon Jul 2 13:32:04 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE101311E5; Mon, 2 Jul 2018 13:31:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153056351359.16091.10080997250971931197@ietfa.amsl.com> Date: Mon, 02 Jul 2018 13:31:53 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-12.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 20:32:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : Stream Control Transmission Protocol (SCTP) Network Address Translation Support Authors : Randall R. Stewart Michael Tuexen Irene Ruengeler Filename : draft-ietf-tsvwg-natsupp-12.txt Pages : 44 Date : 2018-07-02 Abstract: The Stream Control Transmission Protocol (SCTP) provides a reliable communications channel between two end-hosts in many ways similar to the Transmission Control Protocol (TCP). With the widespread deployment of Network Address Translators (NAT), specialized code has been added to NAT for TCP that allows multiple hosts to reside behind a NAT and yet use only a single globally unique IPv4 address, even when two hosts (behind a NAT) choose the same port numbers for their connection. This additional code is sometimes classified as Network Address and Port Translation (NAPT). This document describes the protocol extensions required for the SCTP endpoints and the mechanisms for NATs necessary to provide similar features of NAPT in the single-point and multi-point traversal scenario. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-natsupp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-natsupp-12 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-natsupp-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-natsupp-12 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 Mon Jul 2 15:49:10 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 195C51313F7; Mon, 2 Jul 2018 15:49:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153057174005.16131.1613224464708650369@ietfa.amsl.com> Date: Mon, 02 Jul 2018 15:49:00 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-le-phb-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 22:49:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : A Lower Effort Per-Hop Behavior (LE PHB) Author : Roland Bless Filename : draft-ietf-tsvwg-le-phb-05.txt Pages : 18 Date : 2018-07-02 Abstract: This document specifies properties and characteristics of a Lower Effort (LE) per-hop behavior (PHB). The primary objective of this LE PHB is to protect best-effort (BE) traffic (packets forwarded with the default PHB) from LE traffic in congestion situations, i.e., when resources become scarce, best-effort traffic has precedence over LE traffic and may preempt it. Alternatively, packets forwarded by the LE PHB can be associated with a scavenger service class, i.e., they scavenge otherwise unused resources only. There are numerous uses for this PHB, e.g., for background traffic of low precedence, such as bulk data transfers with low priority in time, non time-critical backups, larger software updates, web search engines while gathering information from web servers and so on. This document recommends a standard DSCP value for the LE PHB. This specification obsoletes RFC 3662 and updates the DSCP recommended in RFC 4594 and RFC 8325 to use the DSCP assigned in this specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-le-phb/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-05 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-le-phb-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-le-phb-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 2 15:58:00 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1541F1313CE; Mon, 2 Jul 2018 15:57:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153057226304.16135.5125291947740616008@ietfa.amsl.com> Date: Mon, 02 Jul 2018 15:57:43 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 22:57:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : Identifying Modified Explicit Congestion Notification (ECN) Semantics for Ultra-Low Queuing Delay (L4S) Authors : Koen De Schepper Bob Briscoe Filename : draft-ietf-tsvwg-ecn-l4s-id-03.txt Pages : 34 Date : 2018-07-02 Abstract: This specification defines the identifier to be used on IP packets for a new network service called low latency, low loss and scalable throughput (L4S). It is similar to the original (or 'Classic') Explicit Congestion Notification (ECN). 'Classic' ECN marking was required to be equivalent to a drop, both when applied in the network and when responded to by a transport. Unlike 'Classic' ECN marking, for packets carrying the L4S identifier, the network applies marking more immediately and more aggressively than drop, and the transport response to each mark is reduced and smoothed relative to that for drop. The two changes counterbalance each other so that the throughput of an L4S flow will be roughly the same as a 'Classic' flow under the same conditions. However, the much more frequent control signals and the finer responses to them result in ultra-low queuing delay without compromising link utilization, even during high load. Examples of new active queue management (AQM) marking algorithms and examples of new transports (whether TCP-like or real- time) are specified separately. The new L4S identifier is the key piece that enables them to interwork and distinguishes them from 'Classic' traffic. It gives an incremental migration path so that existing 'Classic' TCP traffic will be no worse off, but it can be prevented from degrading the ultra-low delay and loss of the new scalable transports. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-l4s-id/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-03 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ecn-l4s-id-03 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 Mon Jul 2 15:58:24 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 814AD131414; Mon, 2 Jul 2018 15:58:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153057228948.16078.8082686696524143629@ietfa.amsl.com> Date: Mon, 02 Jul 2018 15:58:09 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-aqm-dualq-coupled-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 22:58:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput (L4S) Authors : Koen De Schepper Bob Briscoe Olga Bondarenko Ing-jyh Tsang Filename : draft-ietf-tsvwg-aqm-dualq-coupled-05.txt Pages : 37 Date : 2018-07-02 Abstract: Data Centre TCP (DCTCP) was designed to provide predictably low queuing latency, near-zero loss, and throughput scalability using explicit congestion notification (ECN) and an extremely simple marking behaviour on switches. However, DCTCP does not co-exist with existing TCP traffic---DCTCP is so aggressive that existing TCP algorithms approach starvation. So, until now, DCTCP could only be deployed where a clean-slate environment could be arranged, such as in private data centres. This specification defines `DualQ Coupled Active Queue Management (AQM)' to allow scalable congestion controls like DCTCP to safely co-exist with classic Internet traffic. The Coupled AQM ensures that a flow runs at about the same rate whether it uses DCTCP or TCP Reno/Cubic, but without inspecting transport layer flow identifiers. When tested in a residential broadband setting, DCTCP achieved sub-millisecond average queuing delay and zero congestion loss under a wide range of mixes of DCTCP and `Classic' broadband Internet traffic, without compromising the performance of the Classic traffic. The solution also reduces network complexity and eliminates network configuration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-aqm-dualq-coupled/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-05 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-aqm-dualq-coupled-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-aqm-dualq-coupled-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 2 18:34:00 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB0E130E9E; Mon, 2 Jul 2018 18:33:52 -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-tsvwg-rfc4960-errata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, gorry@erg.abdn.ac.uk, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153058163262.16122.9829445409588074259.idtracker@ietfa.amsl.com> Date: Mon, 02 Jul 2018 18:33:52 -0700 Archived-At: Subject: [tsvwg] Ben Campbell's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 01:33:54 -0000 Ben Campbell has entered the following ballot position for draft-ietf-tsvwg-rfc4960-errata-06: Abstain 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-tsvwg-rfc4960-errata/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Alexey that I don't see the value of publishing this, and am concerned it might even be slightly harmful. The approach seems unfriendly to implementers, who would get much more benefit from an "RFC4960bis" draft. At best it seems like an intermediate step in the creation of such a bis draft. (I note similar concerns from the Gen-ART and OPSDIR reviewers) I don't expect the decision to publish this in it's current form to change, so I am balloting "abstain" and getting out of the way. From nobody Mon Jul 2 22:51:49 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 109BD130F40; Mon, 2 Jul 2018 22:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 5DVrakiusFM8; Mon, 2 Jul 2018 22:51:38 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C11B130DF3; Mon, 2 Jul 2018 22:51:38 -0700 (PDT) Received: from [192.168.1.131] (p57BB4D2B.dip0.t-ipconnect.de [87.187.77.43]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id A6EF3721E280C; Tue, 3 Jul 2018 07:51:33 +0200 (CEST) From: Michael Tuexen Message-Id: <3744DFDF-E9DA-4227-BA3E-194882DBB884@fh-muenster.de> Content-Type: multipart/signed; boundary="Apple-Mail=_2D2B7D07-F942-4965-9FC5-4E2391149DC5"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Tue, 3 Jul 2018 07:51:31 +0200 In-Reply-To: <153053893062.16074.3962132072235903491.idtracker@ietfa.amsl.com> Cc: The IESG , draft-ietf-tsvwg-rfc4960-errata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, tsvwg@ietf.org To: =?utf-8?Q?Mirja_K=C3=BChlewind?= References: <153053893062.16074.3962132072235903491.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [tsvwg] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-tsvwg-rfc4960-errata-06=3A_=28with_COMMENT=29?= X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 05:51:43 -0000 --Apple-Mail=_2D2B7D07-F942-4965-9FC5-4E2391149DC5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 2. Jul 2018, at 15:42, Mirja K=C3=BChlewind = wrote: >=20 > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-tsvwg-rfc4960-errata-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-tsvwg-rfc4960-errata/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 Hi Mirja, thanks a lot for the comments. See my answers below: > 1) sec 3.27.2: > " o When the endpoint does not transmit data on a given transport > address, the cwnd of the transport address SHOULD be adjusted to > max(cwnd/2, 4*MTU) per RTO. At the first cwnd adjustment, the > ssthresh of the transport address SHOULD be adjusted to the = cwnd." > This part is still unclear to me. What does adjust "per RTO mean"? I = guess it > is sufficient to adjust it once after the first RTO without data, no? = Also I > assume ssthresh is set after the cwnd adjustment? The idea is that you basically half the cwnd after each RTO until you reach 4 * MTU. Then you stay at 4 * MTU. So you half it possibly = multiple times. When the idle period ends, you can use slow start to the reach the old cwnd. So ssthresh is set to cwnd before the initial adjustment. I changed the 'New text' to o When the endpoint does not transmit data on a given transport address, the cwnd of the transport address SHOULD be adjusted to max(cwnd/2, 4*MTU) per RTO. Before the first cwnd adjustment, the ssthresh of the transport address SHOULD be set to the cwnd. >=20 > 2) sec 3.28.2 > "An SCTP receiver MUST NOT generate more than one SACK for every > incoming packet, other than to update the offered window as the > receiving application consumes new data. When the window opens > up, an SCTP receiver SHOULD send additional SACK chunks to update > the window even if no new data is received. The receiver MUST avoid > sending large bursts of window updates." > This is also not super well specified now. What is a large burst? > I would rather like to see something like "The receiver MUST not send = more then > one window update per RTT." That would require a timer... You generate these SACKs when the = receiving application reads data. Assume the receive buffer is full with small messages and the application starts the read messages at high speed. There were stacks sending a window update SACK for each message = delivered. This is a large burst. Running a timer for sending these SACKs is a bit of an overkill, I think. In FreeBSD, a SACK is only sent if at least a quarter of the receive buffer is freed. This limits the burst to 4 SACKS which is in tune with the burst mitigation limit used for SCTP packets containing user data. This is also more than one per RTT. However, other implementations might do it differently and we wanted to allow this. If you think this is a critical thing, we can work out some strategy. >=20 > 3) 3.31. > Would it make sense to then use a different variable, e.g. cwnd_temp = or > max_send_limit, and not cwnd...? If you would do that, then you have to explain when to use the new variable instead of cwnd. I don't think this makes it easier... >=20 > 4) Text changes in sec 3.35.2. are kind of unclear. I assume the new = text > should be added at the end of the old text sections...? Correct. It is actually a new sub section. I have added the new = subsection header to the "New text:". It reads now 7.2.5. Change of Differentiated Services Code Points SCTP implementations MAY allow an application to configure the Differentiated Services Code Point (DSCP) used for sending packets. If a DSCP change might result in outgoing packets being queued in different queues, the congestion control parameters for all affected destination addresses MUST be reset to their initial values. Best regards Michael >=20 >=20 --Apple-Mail=_2D2B7D07-F942-4965-9FC5-4E2391149DC5 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQkDCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFojCCBIqgAwIBAgIHF6Qk oQlIMzANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTE0MDUyNzE0NTQwOVoXDTE5MDcwOTIzNTkwMFowgcYxCzAJBgNVBAYTAkRFMRwwGgYDVQQIExNO b3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFjaGhvY2hz Y2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxlMR0wGwYD VQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVlbnN0ZXIu ZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eWyu8GzsIv0iowf2v/9BT0SmCFNX /eyQe5BncOk1j6XIlY5bnNu1S5uBe3uVgekgTh3gJyVNlaoIfCgAjqCrNJIaNQq5fr/S6L8uFeaU O8IF/C4RH5P7f9Hn2GUueEjmJhg9CI3LBAhrfAmEEtNmuVfDycN2MjngwDNxUNRfuXbWxuhkgDqJ 0ztJeayHGhFDrGx88eyStx40xy+0c0OFWdWxzBFQlBRHnl+zRftj3c9qy6BY+/fGaA2vV1oKr3h5 X6eyU1T8YlpP1NDe4bylqAteX01sM2Qciu8UAPnNc7Sb93TQjhCFRVDIS3CdN6AOpwz5YWEld6ey CdmFZ7pvAgMBAAGjggH+MIIB+jASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAR BgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFArzW7zkMYDWNUKJptPDzzfe0d/XMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOBEWNhQGZoLW11ZW5zdGVyLmRlMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0 dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDov L2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYI KwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQDeRwM11kpvuRIPuzWXLapr/ZBtB76V3cuF l45x/Kx0u03yjB4GaBPcxihn4P1z5KhRYkDBMo8HXkOgbL59aF6VdOlCurEgZvghKvUkKOCyWeYx S9rTGPBkbGiNn2ATVuLXzF8rDf50ynAIu3otstOOv+3Ifqi1pzCva1nO64khQA5Gd5/BNyu+YHbW f8ERAf9leu5a7yVI7cv1gCZAHpWJpkUKmfawyY4sAJ2hbGZRBvdACOxrfbuMdSOzPneT2rlmvH+D 7M6DmzVabLYk6UtAxQhldd/T/qsHkWvaWXHt0Eb9STs2Fl03Ls7M3NyLQLhaeR3ysNURYcaEfaB+ lxN+MIIGDTCCBPWgAwIBAgIHG5mIdDexozANBgkqhkiG9w0BAQsFADCBxjELMAkGA1UEBhMCREUx HDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQK ExdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVu dHJhbGUxHTAbBgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBm aC1tdWVuc3Rlci5kZTAeFw0xNjA3MDQwNzA2MTNaFw0xOTA3MDQwNzA2MTNaMHwxCzAJBgNVBAYT AkRFMSAwHgYDVQQKDBdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEyMDAGA1UECwwpRmFjaGJlcmVp Y2ggRWxla3Ryb3RlY2huaWsgdW5kIEluZm9ybWF0aWsxFzAVBgNVBAMMDk1pY2hhZWwgVHVleGVu MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzJoaUG3Zm24XxA/zNg2sbFcL56w8xqMg +X6G7UsYec3YEncnlkw3jgE5nDefos7UVoCA7wPjFTj8AQt5xfpXElnbM45IPy5Ng7g6dS7biGSM VRACPXe1PrjgApRAwwGmCPvALnZXkmKP6Zlf+3VLfz9YWIIaeKu3jFM2Lk6Y3gr5U1l8bjHSawOo WMlfvSsXXLT38zKW7Uz9jS278j0OqHANBPgsE6/LJoCWFInwlvybxhO3nGU7OteUGaPikqzvjLsL YgpHDi0WjMZfVx/UtUSzZ4EJvmJTBeuVwyKnCbrawnfwYPTQQ6VE1OkAzmsMByBbEwJ996RtG//T XCG06QIDAQABo4ICRzCCAkMwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGB rSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTQHa9qhKgSZgCCAPThZkXaEaJ/ dTAfBgNVHSMEGDAWgBQK81u85DGA1jVCiabTw8833tHf1zAgBgNVHREEGTAXgRV0dWV4ZW5AZmgt bXVlbnN0ZXIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Zo LW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAz BggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9maC1tdWVuc3Rl ci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAEj2/6x4kzoCVIiu aaminPrOHxACyoYsmSRjYPQpgW5xRj/FlolO1nG+ZZ11sqTb3TdCGD69ko5/zs8eGKnv/i0VLCHF g1JLfpaxElN5RrR/cqRJrbzKshF9aUkBODF8vlf9BCeimMK3fifjbbWRyxHssfEECffujD7/Yvta NYMO46Roz39lIK2s37IVFq3V5RWzUeTuwpP9t8lOxirOi9eK2OYI/dh0HjR2S5Dr9nMR1dNulrhz jlFxGc+opefGScrRR9Ec0eqTXlbt1Q9UzNIYVS+OGZY8/bBbprwXVTmwSp8dygEULkIaMbLsaTaW 6TehuL8ousPJkL52SOENgSkxggQpMIIEJQIBATCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozAJBgUrDgMCGgUAoIICKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xODA3MDMwNTUxMzJaMCMGCSqGSIb3DQEJBDEWBBReYxRm3ago1mYxT0pm jUwkrqGU0jCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9y ZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2No dWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UE AxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRl AgcbmYh0N7GjMIHlBgsqhkiG9w0BCRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozANBgkqhkiG9w0BAQEFAASCAQAepSenr8mq28s/OUg0oEKoN1OFBrWscbCu KKsQdtOM8veG1S8bqfX9CSuc9VUuU+0tab/56TEmsZhzyxK9NUdf/uDreIQzkTQ3aRHBcdZIyzg1 VEwNSDqHfjjodAPX9eqBwSw3IRMN7Hcna6xc0X6zRS08Z0sLbu+3/inVprjo5lQDzN2s+0+oa0pO 2McCgBlFrK/2eRuaT/ogcd+dJ5g/8/9XogZu7fuDiIo7tQMqYiTFGbbUo/jExd+tOkE/P1OMNhBN m1nwNbzbnQ03w/wTGt4RuyKk+QsYAvEOL3MS7L6uGnLUOHnch9CxcxNhs9P4mU7QHVUUNw/VJjlO x0EPAAAAAAAA --Apple-Mail=_2D2B7D07-F942-4965-9FC5-4E2391149DC5-- From nobody Mon Jul 2 22:56:44 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7054130E44; Mon, 2 Jul 2018 22:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 GoJtvfpW8dWN; Mon, 2 Jul 2018 22:56:34 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB9C1120049; Mon, 2 Jul 2018 22:56:33 -0700 (PDT) Received: from [192.168.1.131] (p57BB4D2B.dip0.t-ipconnect.de [87.187.77.43]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 13D45721E280C; Tue, 3 Jul 2018 07:56:29 +0200 (CEST) From: Michael Tuexen Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_ED6E14C1-FD80-4B42-90C5-82F8EF56D8CA"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Tue, 3 Jul 2018 07:56:27 +0200 In-Reply-To: <153058163262.16122.9829445409588074259.idtracker@ietfa.amsl.com> Cc: The IESG , draft-ietf-tsvwg-rfc4960-errata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, tsvwg@ietf.org To: Ben Campbell References: <153058163262.16122.9829445409588074259.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [tsvwg] Ben Campbell's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 05:56:37 -0000 --Apple-Mail=_ED6E14C1-FD80-4B42-90C5-82F8EF56D8CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 3. Jul 2018, at 03:33, Ben Campbell wrote: >=20 > Ben Campbell has entered the following ballot position for > draft-ietf-tsvwg-rfc4960-errata-06: Abstain >=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-tsvwg-rfc4960-errata/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I agree with Alexey that I don't see the value of publishing this, and = am > concerned it might even be slightly harmful. The approach seems = unfriendly to > implementers, who would get much more benefit from an "RFC4960bis" = draft. At > best it seems like an intermediate step in the creation of such a bis = draft. (I > note similar concerns from the Gen-ART and OPSDIR reviewers) Yes, that is the plan. Once this document is finished, we'll start = working on the 4960bis document based on the changes described in this document. We did this in the past. RFC 4460 describes the Erratas of RFC 2960. = After RFC 4460 was done, work on RFC 4960 was started. So basically RFC 4960 =3D RFC 2960 + RFC 4460. One advantage of this was that people wondering why something has = changed between RFC 2960 and RFC 4960 can look it up, even how changes evolved = by looking at the versions on the Internet Drafts resulting in RFC 4460. This was useful to some people in the past... Best regards Michael >=20 > I don't expect the decision to publish this in it's current form to = change, so > I am balloting "abstain" and getting out of the way. >=20 >=20 --Apple-Mail=_ED6E14C1-FD80-4B42-90C5-82F8EF56D8CA Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQkDCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFojCCBIqgAwIBAgIHF6Qk oQlIMzANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTE0MDUyNzE0NTQwOVoXDTE5MDcwOTIzNTkwMFowgcYxCzAJBgNVBAYTAkRFMRwwGgYDVQQIExNO b3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFjaGhvY2hz Y2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxlMR0wGwYD VQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVlbnN0ZXIu ZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eWyu8GzsIv0iowf2v/9BT0SmCFNX /eyQe5BncOk1j6XIlY5bnNu1S5uBe3uVgekgTh3gJyVNlaoIfCgAjqCrNJIaNQq5fr/S6L8uFeaU O8IF/C4RH5P7f9Hn2GUueEjmJhg9CI3LBAhrfAmEEtNmuVfDycN2MjngwDNxUNRfuXbWxuhkgDqJ 0ztJeayHGhFDrGx88eyStx40xy+0c0OFWdWxzBFQlBRHnl+zRftj3c9qy6BY+/fGaA2vV1oKr3h5 X6eyU1T8YlpP1NDe4bylqAteX01sM2Qciu8UAPnNc7Sb93TQjhCFRVDIS3CdN6AOpwz5YWEld6ey CdmFZ7pvAgMBAAGjggH+MIIB+jASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAR BgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFArzW7zkMYDWNUKJptPDzzfe0d/XMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOBEWNhQGZoLW11ZW5zdGVyLmRlMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0 dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDov L2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYI KwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQDeRwM11kpvuRIPuzWXLapr/ZBtB76V3cuF l45x/Kx0u03yjB4GaBPcxihn4P1z5KhRYkDBMo8HXkOgbL59aF6VdOlCurEgZvghKvUkKOCyWeYx S9rTGPBkbGiNn2ATVuLXzF8rDf50ynAIu3otstOOv+3Ifqi1pzCva1nO64khQA5Gd5/BNyu+YHbW f8ERAf9leu5a7yVI7cv1gCZAHpWJpkUKmfawyY4sAJ2hbGZRBvdACOxrfbuMdSOzPneT2rlmvH+D 7M6DmzVabLYk6UtAxQhldd/T/qsHkWvaWXHt0Eb9STs2Fl03Ls7M3NyLQLhaeR3ysNURYcaEfaB+ lxN+MIIGDTCCBPWgAwIBAgIHG5mIdDexozANBgkqhkiG9w0BAQsFADCBxjELMAkGA1UEBhMCREUx HDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQK ExdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVu dHJhbGUxHTAbBgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBm aC1tdWVuc3Rlci5kZTAeFw0xNjA3MDQwNzA2MTNaFw0xOTA3MDQwNzA2MTNaMHwxCzAJBgNVBAYT AkRFMSAwHgYDVQQKDBdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEyMDAGA1UECwwpRmFjaGJlcmVp Y2ggRWxla3Ryb3RlY2huaWsgdW5kIEluZm9ybWF0aWsxFzAVBgNVBAMMDk1pY2hhZWwgVHVleGVu MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzJoaUG3Zm24XxA/zNg2sbFcL56w8xqMg +X6G7UsYec3YEncnlkw3jgE5nDefos7UVoCA7wPjFTj8AQt5xfpXElnbM45IPy5Ng7g6dS7biGSM VRACPXe1PrjgApRAwwGmCPvALnZXkmKP6Zlf+3VLfz9YWIIaeKu3jFM2Lk6Y3gr5U1l8bjHSawOo WMlfvSsXXLT38zKW7Uz9jS278j0OqHANBPgsE6/LJoCWFInwlvybxhO3nGU7OteUGaPikqzvjLsL YgpHDi0WjMZfVx/UtUSzZ4EJvmJTBeuVwyKnCbrawnfwYPTQQ6VE1OkAzmsMByBbEwJ996RtG//T XCG06QIDAQABo4ICRzCCAkMwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGB rSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTQHa9qhKgSZgCCAPThZkXaEaJ/ dTAfBgNVHSMEGDAWgBQK81u85DGA1jVCiabTw8833tHf1zAgBgNVHREEGTAXgRV0dWV4ZW5AZmgt bXVlbnN0ZXIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Zo LW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAz BggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9maC1tdWVuc3Rl ci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAEj2/6x4kzoCVIiu aaminPrOHxACyoYsmSRjYPQpgW5xRj/FlolO1nG+ZZ11sqTb3TdCGD69ko5/zs8eGKnv/i0VLCHF g1JLfpaxElN5RrR/cqRJrbzKshF9aUkBODF8vlf9BCeimMK3fifjbbWRyxHssfEECffujD7/Yvta NYMO46Roz39lIK2s37IVFq3V5RWzUeTuwpP9t8lOxirOi9eK2OYI/dh0HjR2S5Dr9nMR1dNulrhz jlFxGc+opefGScrRR9Ec0eqTXlbt1Q9UzNIYVS+OGZY8/bBbprwXVTmwSp8dygEULkIaMbLsaTaW 6TehuL8ousPJkL52SOENgSkxggQpMIIEJQIBATCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozAJBgUrDgMCGgUAoIICKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xODA3MDMwNTU2MjdaMCMGCSqGSIb3DQEJBDEWBBQugi6xQHP3lvL4Hho6 remFKJYncTCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9y ZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2No dWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UE AxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRl AgcbmYh0N7GjMIHlBgsqhkiG9w0BCRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozANBgkqhkiG9w0BAQEFAASCAQA1qfoif5bCp2rNcj/erU4T6e9YhxAXC1Ab Ufl6ue+8RXyA8bok57hsjiVkOAv0b2s69wPvgXBvKbfjC4Roz1xaHOVZ0rxRjbxgI+QxLQH8tyYy 0Ve+FkeeCMpI9s8rBUo2wlW1gdLLZ/0PhSfYArW4XwK2FkEyPLW081BWwIfFcKwJXBiNdHthQsLq 4A7gxUZRxGQL62v+IC1z4oirGdrVYfqyz7DBolZH0FCY5FamZDUGvQQmRWLEoQx8SypiaQjhMC7T po3ZmD7toZmV+T5iioypL+ZfuXWp+L/X8mfEa9Gk3JLfmu1nTCcBfPKfFwKndydVYLszrEJyQ5fS HFT/AAAAAAAA --Apple-Mail=_ED6E14C1-FD80-4B42-90C5-82F8EF56D8CA-- From nobody Tue Jul 3 02:41:32 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A75B3131208; Tue, 3 Jul 2018 02:41:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Vigoureux To: "The IESG" Cc: draft-ietf-tsvwg-rfc4960-errata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, gorry@erg.abdn.ac.uk, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153061088467.5086.7684583062561435644.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2018 02:41:24 -0700 Archived-At: Subject: [tsvwg] Martin Vigoureux's No Objection on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 09:41:25 -0000 Martin Vigoureux has entered the following ballot position for draft-ietf-tsvwg-rfc4960-errata-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-tsvwg-rfc4960-errata/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hello, Thank you for writing down this Document. I see the value of documenting fixes to known issues so I support this initiative but I somehow also share Alexey's view. I'm not sure an RFC is the best means to achieve that goal. A living wiki page would have been more suitable in my opinion. I'm not an expert in that field, but what if a new issue is uncovered in the future? That would render this Document incomplete. Will a new draft be published that Updates this Document? I am a bit more concerned by the relationship between this document and the Erratas for 4960, and by the possible "discrepancy" its publication, with all things staying as they are, would introduce. 4 Erratas for 4960 are in Reported state, yet 3 of these 4 are addressed in this Document. Also, one of these 3 has a resolution which differs from the proposed Errata text. Finally, only this errata is referenced by its ID in the Document. Spencer the first two points might be more in your hands than in the authors' but I wonder if something should be done about it as part of publishing this Document. More details below: 3.47. Clarification of Gap Ack Blocks in SACK Chunks The Errata for this is https://www.rfc-editor.org/errata/eid5202 The text change proposed by the draft is different than the one proposed by the Errata. Note that I am not arguing which one is better. 3.24. SACK.Delay Not Listed as a Protocol Parameter The Errata for this is https://www.rfc-editor.org/errata/eid4656 3.9. Miscellaneous Typos The Errata for this is https://www.rfc-editor.org/errata/eid5003 The not discussed Reported errata is https://www.rfc-editor.org/errata/eid4876 From nobody Tue Jul 3 04:01:29 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA03E130E5A; Tue, 3 Jul 2018 04:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 4JnzVYdAZNrb; Tue, 3 Jul 2018 04:01:17 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59A30130E4B; Tue, 3 Jul 2018 04:01:17 -0700 (PDT) Received: from [IPv6:2003:cd:6f1a:9700:f8d1:d329:b7e4:be68] (p200300CD6F1A9700F8D1D329B7E4BE68.dip0.t-ipconnect.de [IPv6:2003:cd:6f1a:9700:f8d1:d329:b7e4:be68]) (Authenticated sender: macmic) by drew.franken.de (Postfix) with ESMTPSA id 44F0C721E280C; Tue, 3 Jul 2018 13:01:10 +0200 (CEST) From: Michael Tuexen Message-Id: <9058127E-282C-439F-AF3C-A18FE606B6CA@fh-muenster.de> Content-Type: multipart/signed; boundary="Apple-Mail=_F7B8F740-839A-44E9-99EA-8D41B6C20E13"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Tue, 3 Jul 2018 13:01:08 +0200 In-Reply-To: <153061088467.5086.7684583062561435644.idtracker@ietfa.amsl.com> Cc: The IESG , draft-ietf-tsvwg-rfc4960-errata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, tsvwg@ietf.org To: Martin Vigoureux References: <153061088467.5086.7684583062561435644.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [tsvwg] Martin Vigoureux's No Objection on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 11:01:20 -0000 --Apple-Mail=_F7B8F740-839A-44E9-99EA-8D41B6C20E13 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 3. Jul 2018, at 11:41, Martin Vigoureux = wrote: >=20 > Martin Vigoureux has entered the following ballot position for > draft-ietf-tsvwg-rfc4960-errata-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-tsvwg-rfc4960-errata/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Hello, >=20 > Thank you for writing down this Document. I see the value of = documenting fixes > to known issues so I support this initiative but I somehow also share = Alexey's > view. I'm not sure an RFC is the best means to achieve that goal. A = living wiki > page would have been more suitable in my opinion. I'm not an expert in = that If the IETF provides this and make sure it is available in the future, it is an option. Once we have replaced RFC 4960 by the upcoming RFC = 4960bis, someone might ask why something has change and how... This is what this document can provide. > field, but what if a new issue is uncovered in the future? That would = render > this Document incomplete. Will a new draft be published that Updates = this > Document? No... Once this document is done, we plan to start working on RFC 4960 = bis and that work is pretty easy. Integrate the changes of this document. However, if in that time another issue comes up, we'll fix it, I guess. However, we try to find a good point of time to do this. We did this once in the past, when we worked on RFC 4460, which is the errata document to RFC 2960 and then published RFC 4960 =3D RFC 2960 + = RFC 4460. >=20 > I am a bit more concerned by the relationship between this document = and the > Erratas for 4960, and by the possible "discrepancy" its publication, = with all > things staying as they are, would introduce. 4 Erratas for 4960 are in = Reported > state, yet 3 of these 4 are addressed in this Document. Also, one of = these 3 > has a resolution which differs from the proposed Errata text. Finally, = only > this errata is referenced by its ID in the Document. Spencer the first = two > points might be more in your hands than in the authors' but I wonder = if > something should be done about it as part of publishing this Document. = More > details below: I double checked during the IETF LC (some brought this up) and made sure all erratas reported to the errata web site are covered. The text this document uses might not be the one in the original errata, since the WG might have improved it. But I can not change what the reporter = suggested. I do see the general point. I tried to address all reported erratas in = this document. You can see an overview in = https://github.com/sctplab/rfc4960bis/blob/master/draft-ietf-tsvwg-rfc4960= -errata.xml#L131 However, I don't control the erratas, can only discuss this on the = mailing list and provide some resolution in this document. But things are consistent in my view. >=20 > 3.47. Clarification of Gap Ack Blocks in SACK Chunks > The Errata for this is https://www.rfc-editor.org/errata/eid5202 > The text change proposed by the draft is different than the one = proposed by the > Errata. Note that I am not arguing which one is better. Errata 5202 was reported and targets two things: 1. The gap ack blocks in a SACK should not overlap 2. The gap ack blocks in a SACK should be increasing. It was actually intended the the gap block don't overlap. That was = already clarified in section 3.47 before the errata was filed. However, it was never intended that the gap ack blocks are increasing. That is why there is no text related to this. Errata 5202 was reported on December 13th, 2017. I responded stating the above and provided some explanations on the same day to tsvwg@ietf.org. I don't think we need to use the text provided in that errata. However, I have added This issue was reported as part of an Errata for with Errata ID 5202. to make things clear. See = https://github.com/sctplab/rfc4960bis/commit/62ec4089c8d6c1598482257aa97e8= 72fc5090e0e >=20 > 3.24. SACK.Delay Not Listed as a Protocol Parameter > The Errata for this is https://www.rfc-editor.org/errata/eid4656 Correct. And this is stated in = https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-06#section-3.2= 4.1 >=20 > 3.9. Miscellaneous Typos > The Errata for this is https://www.rfc-editor.org/errata/eid5003 Correct. This was already catched and fixed for the next revision: = https://github.com/sctplab/rfc4960bis/commit/b8e4e8c6c558c66dab4530cce1b0b= 5af8eea9b0f >=20 > The not discussed Reported errata is = https://www.rfc-editor.org/errata/eid4876 That is correct. It was reported on December 1st, 2016. I responded on December 9th, 2016 to tsvwg@ietf.org that is doesn't = really make sense to me and provided some explanation. On the same day the reporter answered on the mailing list closed with "Please disregard my erratum report." So I don't see any reason for changing RFC 4960 and adding a section to = this document to describe it. Best regards Michael >=20 >=20 --Apple-Mail=_F7B8F740-839A-44E9-99EA-8D41B6C20E13 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQkDCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFojCCBIqgAwIBAgIHF6Qk oQlIMzANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTE0MDUyNzE0NTQwOVoXDTE5MDcwOTIzNTkwMFowgcYxCzAJBgNVBAYTAkRFMRwwGgYDVQQIExNO b3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFjaGhvY2hz Y2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxlMR0wGwYD VQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVlbnN0ZXIu ZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eWyu8GzsIv0iowf2v/9BT0SmCFNX /eyQe5BncOk1j6XIlY5bnNu1S5uBe3uVgekgTh3gJyVNlaoIfCgAjqCrNJIaNQq5fr/S6L8uFeaU O8IF/C4RH5P7f9Hn2GUueEjmJhg9CI3LBAhrfAmEEtNmuVfDycN2MjngwDNxUNRfuXbWxuhkgDqJ 0ztJeayHGhFDrGx88eyStx40xy+0c0OFWdWxzBFQlBRHnl+zRftj3c9qy6BY+/fGaA2vV1oKr3h5 X6eyU1T8YlpP1NDe4bylqAteX01sM2Qciu8UAPnNc7Sb93TQjhCFRVDIS3CdN6AOpwz5YWEld6ey CdmFZ7pvAgMBAAGjggH+MIIB+jASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAR BgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFArzW7zkMYDWNUKJptPDzzfe0d/XMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOBEWNhQGZoLW11ZW5zdGVyLmRlMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0 dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDov L2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYI KwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQDeRwM11kpvuRIPuzWXLapr/ZBtB76V3cuF l45x/Kx0u03yjB4GaBPcxihn4P1z5KhRYkDBMo8HXkOgbL59aF6VdOlCurEgZvghKvUkKOCyWeYx S9rTGPBkbGiNn2ATVuLXzF8rDf50ynAIu3otstOOv+3Ifqi1pzCva1nO64khQA5Gd5/BNyu+YHbW f8ERAf9leu5a7yVI7cv1gCZAHpWJpkUKmfawyY4sAJ2hbGZRBvdACOxrfbuMdSOzPneT2rlmvH+D 7M6DmzVabLYk6UtAxQhldd/T/qsHkWvaWXHt0Eb9STs2Fl03Ls7M3NyLQLhaeR3ysNURYcaEfaB+ lxN+MIIGDTCCBPWgAwIBAgIHG5mIdDexozANBgkqhkiG9w0BAQsFADCBxjELMAkGA1UEBhMCREUx HDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQK ExdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVu dHJhbGUxHTAbBgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBm aC1tdWVuc3Rlci5kZTAeFw0xNjA3MDQwNzA2MTNaFw0xOTA3MDQwNzA2MTNaMHwxCzAJBgNVBAYT AkRFMSAwHgYDVQQKDBdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEyMDAGA1UECwwpRmFjaGJlcmVp Y2ggRWxla3Ryb3RlY2huaWsgdW5kIEluZm9ybWF0aWsxFzAVBgNVBAMMDk1pY2hhZWwgVHVleGVu MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzJoaUG3Zm24XxA/zNg2sbFcL56w8xqMg +X6G7UsYec3YEncnlkw3jgE5nDefos7UVoCA7wPjFTj8AQt5xfpXElnbM45IPy5Ng7g6dS7biGSM VRACPXe1PrjgApRAwwGmCPvALnZXkmKP6Zlf+3VLfz9YWIIaeKu3jFM2Lk6Y3gr5U1l8bjHSawOo WMlfvSsXXLT38zKW7Uz9jS278j0OqHANBPgsE6/LJoCWFInwlvybxhO3nGU7OteUGaPikqzvjLsL YgpHDi0WjMZfVx/UtUSzZ4EJvmJTBeuVwyKnCbrawnfwYPTQQ6VE1OkAzmsMByBbEwJ996RtG//T XCG06QIDAQABo4ICRzCCAkMwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGB rSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTQHa9qhKgSZgCCAPThZkXaEaJ/ dTAfBgNVHSMEGDAWgBQK81u85DGA1jVCiabTw8833tHf1zAgBgNVHREEGTAXgRV0dWV4ZW5AZmgt bXVlbnN0ZXIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Zo LW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAz BggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9maC1tdWVuc3Rl ci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAEj2/6x4kzoCVIiu aaminPrOHxACyoYsmSRjYPQpgW5xRj/FlolO1nG+ZZ11sqTb3TdCGD69ko5/zs8eGKnv/i0VLCHF g1JLfpaxElN5RrR/cqRJrbzKshF9aUkBODF8vlf9BCeimMK3fifjbbWRyxHssfEECffujD7/Yvta NYMO46Roz39lIK2s37IVFq3V5RWzUeTuwpP9t8lOxirOi9eK2OYI/dh0HjR2S5Dr9nMR1dNulrhz jlFxGc+opefGScrRR9Ec0eqTXlbt1Q9UzNIYVS+OGZY8/bBbprwXVTmwSp8dygEULkIaMbLsaTaW 6TehuL8ousPJkL52SOENgSkxggQpMIIEJQIBATCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozAJBgUrDgMCGgUAoIICKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xODA3MDMxMTAxMDlaMCMGCSqGSIb3DQEJBDEWBBSqY+/xMG8WGRIz/AFB +KpIhO3yFzCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9y ZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2No dWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UE AxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRl AgcbmYh0N7GjMIHlBgsqhkiG9w0BCRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozANBgkqhkiG9w0BAQEFAASCAQAzF3i4hsodY4nGYc1bOhZPWVWkIQ7VgYRe gm/lXlbDlj9OQTJ7N2NQAEWQuf2ZD+Ir+HpyrTqfFuCOiiif1jGwsRmiulE9X+8/trMc7P6Ud6i6 1GxeJx8og1qIgGWqKoUiBVqTZdbdbYzdbEbVckgWTqKSNU9uJPbkuOilfPRxYYzMlRLeOdNgmv6K bNhEIVuqxGdV44ZjmyROhEdYkyE5PrVjzgO+THh7FF0ub++gMWw2u/3/Pbx/zgSufMvFRJPqkkIn FMchh+z4aDKTZuXgSdkMos8LEu8gO69uhvAlPapa89g1hbK4DSXfQyldbEATbar6Wfpb4ly0SbVq G9jCAAAAAAAA --Apple-Mail=_F7B8F740-839A-44E9-99EA-8D41B6C20E13-- From nobody Tue Jul 3 06:16:57 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A515130DF7; Tue, 3 Jul 2018 06:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=nokia.onmicrosoft.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 VGFnAeJU-HfC; Tue, 3 Jul 2018 06:16:51 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70102.outbound.protection.outlook.com [40.107.7.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44BC4130E59; Tue, 3 Jul 2018 06:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xMyVw+K9vyX9g1iBb+oAHyIphTonVwYfO2GbHZCTFNQ=; b=UCTvg6hO1CLFiLY3sBQK5nmpO8IWtjecn095HYCjPQUOyOkB8EEszT/XmVjFjbZCBMrJTMdMAXDJK1AIXO3gCLsvNklhaq41uBXZyRa2Te+ucslmdiGh59171XGmHJwyr/AFdNOwDhe7OQ2Fpkt2NB33THj+AHg+rnPV8/EcL0E= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=martin.vigoureux@nokia.com; Received: from [IPv6:2a01:cb04:a1a:4c00:208c:d591:f5a0:b6c5] (2a01:cb04:a1a:4c00:208c:d591:f5a0:b6c5) by DB6PR0701MB2504.eurprd07.prod.outlook.com (2603:10a6:4:62::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.11; Tue, 3 Jul 2018 13:16:45 +0000 To: Michael Tuexen Cc: The IESG , draft-ietf-tsvwg-rfc4960-errata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, tsvwg@ietf.org References: <153061088467.5086.7684583062561435644.idtracker@ietfa.amsl.com> <9058127E-282C-439F-AF3C-A18FE606B6CA@fh-muenster.de> From: Martin Vigoureux Message-ID: Date: Tue, 3 Jul 2018 15:16:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <9058127E-282C-439F-AF3C-A18FE606B6CA@fh-muenster.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Originating-IP: [2a01:cb04:a1a:4c00:208c:d591:f5a0:b6c5] X-ClientProxiedBy: LNXP265CA0020.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5e::32) To DB6PR0701MB2504.eurprd07.prod.outlook.com (2603:10a6:4:62::16) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6d735574-e7b5-4083-fc82-08d5e0e73a6a X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:(109105607167333); BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7193020); SRVR:DB6PR0701MB2504; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2504; 3:kPqFPKzj89j8r7AZ/jj8TPyvut8fUJRF1RDBgVHZGU6kNPp67g41x02KDd7nmkNiOi5sXrLlVxKVmloD8QEu2HCLPjSI6OBqgE4W4eCkfodAe+ylRctLZQEYtiPyEnD+cq7UGDqbhOZcGfvYE81uUfZvbVAjDSVQtuYjp6Fc3bnhwjDeiXTDKL81Hqg/MTtpjVqoED2TMw1DHk8XVz+iNoGx549Eb/hHRD+YNr2NJ2IDxyWY1A7TlIqMcTom1A/wKzXMnkgwUgoJhafgK1uwPXu8TCXHRjD3yioBKWXmBgs=; 25:UqC6pK23Mozp8RTKsqjGG0PzV1eHcpsvDq1fHOIMYZWAZ9/NNBD7i2HeYvJA22ZrAHx9R8OSxNNQhbgqZA4LVrKFjEp30LbNbhRDG263qs7AMFjoJ0RHhdCQ1Yo+wIcZcDEtGj3wkhQ/EyOCbTXyKD/oFbznY2eczKHd4lKYUK0RAH2QqVuql9Sek/Se9R0mptK1SEksOrLDBfNeR77f0Hj8rsOoft1lkryuKwYoINqw2HvrRgVYmzMIF0afTb05aLDobDkFlSad/TUzhrWmTzty2+IUUDmhOsZgyzCl0yEuOdvzH1CKuznaGx3f00fWZIpQBP+9YheOP1EoON4EBw==; 31:TTgU73bbVnM8ffYBofEpC+EClASSyEVCDd/nV1kiwjeD8dtsvrrHLj/tL8bfT1GwC3fMzG3nkOSXLG2zahTnvFvw7ibvweJXtvFeRLZxPWGSz8vKwZYjHnwu+cGnGywT8rGlkHVeTjDQLTM+4nH1RNdEBCRZojFXPzjKU23cUHXcWfeHw9vB/YLBxxTL0Jx1ABb6zSM5LMLCxvSkGaCQciFE4/DFpxjvMiGJTbqMrQE= X-MS-TrafficTypeDiagnostic: DB6PR0701MB2504: X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2504; 20:N7ZLshztVmrOWomFV5qSheo1l3GQ3qcopjq56ccsxxQd3WFHUmKcfD7OHx1bnMUrm4XevqKmTGpZAjq0+mG7PBVVOvvCqOVIGmlb3lJCuLOSjllo64Pwe3G3UTHhx9Noe1yqgvyYLntynEcYbytkT/gsqvvEDeC7ga9Z3NznTZR9eEEnLJc82xp+I6/IC5EEzaS2sUl8Y6VIiz/vnnADfC8R75PQRI8rzGg8K69vhRsKRTNng+js0ciDXKlDbuduqcZ9qzu7Ay6yh7GSHb07GaqFTre5CUWcfm5wn4LNl4nIQ6tU4R6+mh75ogenqEz4y1EQpNtElQmnpx0FfTtukKVEcizc5f/FNttQhjyt42b9nINlQO7NqK4Bja/eV6d1Ylqs/n+lr/Hyz5YfGDUYJ1aLxthLdpgHGxQOG9brLFZXY+nQh+nqvZy2e6b5/mh5+uawz+/Q/wEisCuSP5jtRTrEV1NNVSRWsDZP5Kwd0SgX2DAQ/xXv5Tc7gV/vuUCK; 4:v5WAecKVap/Yiya3LwlWrwpMI19OMao0GhxXVZ29YyexTjBImQouuk65u8ML4M7/hUvI6UtzhzCPDXrjnIMfrFC/Uv9Ywhvf0CAp1X9VJj+nzvXuT5cAh248ujVEZ1Oytp6f/ml2na5weNiupKc3uR/IA/thGb13YpMzkbEJXk10nh4aiSXPi4pFbSX0ST+5zZJJBh0s0BIRTQ7Ja835c2M49Ts+tOwVUfBkfKYlgduedcGEHCwCkyY8GPRHBs1qiRswY1pQBFEZlXjaqxzitcSf6Az+Fwr399v2l+VpQauqXAos/4qC5Nfkt76pSPag5aFGaBD1L+qmhqBjX+EOGZ6CFDzk9J5ne0qXJUU40RvJsIkApnPlKuGAzxNC3ur2FHEoZXbbTXtvIzycTMQOpuMIeAAXzroE84jwEjsTI44= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(166708455590820)(82608151540597)(109105607167333); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231254)(11241501184)(806099)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:DB6PR0701MB2504; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2504; X-Forefront-PRVS: 0722981D2A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(396003)(366004)(136003)(376002)(346002)(39860400002)(199004)(189003)(54094003)(31014005)(345774005)(7736002)(966005)(2870700001)(8676002)(105586002)(81166006)(81156014)(106356001)(478600001)(36756003)(305945005)(316002)(67846002)(54906003)(31696002)(386003)(44832011)(52396003)(86362001)(76176011)(575784001)(50466002)(46003)(14444005)(486006)(8936002)(31686004)(2906002)(16526019)(186003)(58126008)(2616005)(65806001)(5660300001)(65826007)(6666003)(1706002)(6486002)(47776003)(52116002)(476003)(446003)(68736007)(6306002)(11346002)(65956001)(64126003)(23746002)(6246003)(53936002)(25786009)(3260700006)(4326008)(229853002)(6916009)(6116002)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2504; H:[IPv6:2a01:cb04:a1a:4c00:208c:d591:f5a0:b6c5]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; Received-SPF: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; DB6PR0701MB2504; 23:pxRnmsZ+MBLK0K2hKRXyHjVH1dosEDvOa6Q?= =?Windows-1252?Q?7tkf3GYyN707vzObCjAGRkU9oftOAJbKJqEnQkZZIyvrIuu2aPabmUrq?= =?Windows-1252?Q?hOnDgqc6lU2XLxCp1+jyzkRB8uYrUt9bwDsF0T54ApkjVF6xxhvwDoZU?= =?Windows-1252?Q?ro3BvABDoWtk2HpDHD0D3c9ltfvTtsxx3pZoneXxtivi3TYt56YJgZkk?= =?Windows-1252?Q?2zi16S0JQKHe9YJcHBH33GSqAYBRpye1Cvi/YBg0MJYgEAoqFGe8a9ol?= =?Windows-1252?Q?qnKxvjR3NSdKoxV2woUAfexR5J6RS5C0oJGNEst4qfK+EbvTAUGxG8YN?= =?Windows-1252?Q?Hsl5mI7B/DNoALfms0r8JO+ePKagvJGvPnaMfPEAo0IyPCu97wjOpcqN?= =?Windows-1252?Q?Nx0Qw/WNCCyzy/H5lwWEZ7yjSiVkcqty6RumZNpyroxHPPNod5jJSlpE?= =?Windows-1252?Q?DYDM8bgoZqCgtKo7/ysvr0g0/Hn9EW94S2E8EThIqAfJUSz+b4i4JAeo?= =?Windows-1252?Q?Sukv6Q0iItdCDBYUQt+IHN8OavAUPb/yvi+RaTW+7qWSjNzNrpHT2051?= =?Windows-1252?Q?A/T0Bf8r2NPNgQ1eKvGYRyyZc1fLSJNHRMJBVDS32HVisjzpDN5uaSpu?= =?Windows-1252?Q?YtmXWkAXJW3a0j83JHghLF3WDTvcRmQtcksTeHw9T311symnSWV8u7+B?= =?Windows-1252?Q?eGnFbwx2kyTUnnSyJGmgs7npyeUyNdzFKO+fAkitYH63S0KJl5wPqARW?= =?Windows-1252?Q?UdSZn8V+ACF5XJaNkkWTve4/EBb08KVecy4mdHKlQhW1CGXsGlwBII38?= =?Windows-1252?Q?S7tO0EFlQDgBOJaJLp+cxvW8tU0Ow4cHzBt8t/Nh80smNcd2k+ZVcgcs?= =?Windows-1252?Q?U587eILbc7q3TFRsBpanbE0w5Q8+0hkytZd7BI52cn5k5c6g72McLxKi?= =?Windows-1252?Q?yWSaHOlitWew3BkZSMvQM4PEOgQ3W05YotIrdc2Dadhfr54myVYXuZHd?= =?Windows-1252?Q?T94FcqecYXKOf4sqnkR+7c6ayVeE8RxoISYMV1t+EIyJfPJ8MbkHsRSG?= =?Windows-1252?Q?FHkGacutZLaVl56sxUH8kqv7zQNg7myvhrAMp4xzuBKPhLLjIrrJyU/Q?= =?Windows-1252?Q?cO4osZ8tlJIbMTL+G73KMpx2xIZcgUNXC5FUDCLtFNPABpKdRpsc5D74?= =?Windows-1252?Q?e0iPYCwns6K8yiMdUqui3H1H5BdtlwaJPUe3WjfAmLfJCHLhcGCE902y?= =?Windows-1252?Q?yLQ3tPa3ZMrzyVikuiKATQ1AZ7fwLH6rx6VpuQ8R8+HdKS8nuu6FdyLq?= =?Windows-1252?Q?JI60nsoD2JpoW/SHgsxO5PzXIqqVYaZN28ORU2sOb50c+jRmT/EqZUe2?= =?Windows-1252?Q?68OF07tBo107/ckq0BeCMsm5HEtB3C3+R1u1Sz4CfUPr7TeXSdSFPErc?= =?Windows-1252?Q?MFtR6uVy4XbVHYZPAs65AbpKozqqbhnnAkZGm561cQaI5ACPx6aanBEL?= =?Windows-1252?Q?yioAWCH4BB6Q7/yNW8xqoUzot9C4FUMfcK5kGoRFuZ11C4GLHc/lFoyc?= =?Windows-1252?Q?gM4yK1qzcQKoJjdk9b/JOVarcYC5dwmvBiAmdcUtf6LmXmhUMLqCOJeT?= =?Windows-1252?Q?LRAC9fEgxG4KRrSTUY6B5O+o=3D?= X-Microsoft-Antispam-Message-Info: GjLPUX17hkCuX8kcKdUj6OQhNhkNpbyruhqi0tZqnn3Ks3SIHJbNo7nQYPwhe+qaIjAtpStVihNKnPdOrjjGy6x1BHiKfClbpmBCaw2nMcuU7ymGwrTXz5EjghxJKBjc5LuXo0/TIBVpfNXdbH5qC9ydX/6PHzoeMRQ96YcR/MQC7hjcfDDVxRe44w0t5rEnfh3GSkOeyJHym+Ddtb5A+/0Upi7uCm9Pea72buL0w/Zg52uYuH6C/kSic2KC3G/q4uWpLDZUgHP3W0cJpE18kb85pYcj7IY9L99W4zNu8ImGT6gJOIPSDeTcXT8zYEeoYGq2I85cF6XvM7LTvtd61w0op+ZRP6bEXjgNahXT7sEKX8LZdJdLB84j1OrZjegS/mKHFmIs4ac9I6vqHA19kQ== X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2504; 6:UGZFrC5pk8YDTbJ2bZd/RTaqJenzqIhaFuxayaRUzOO1KYCaxn8qUypepvk1xsre7JH0a7ZiOcIdVPMCSb4k1wLwySU9nlKmZmpTjxfjcauLFdoGISnuazcW/CM4X8LrLfQQZZ/qTQpe/raS6qdeRsy8bEtWnZ0uc7OGgJZZU1N4ZtJFQhCJ3ksU5rV0Jelgj2yDFcQjFLBwOeg3YC3DxPfC20PIaVhKylmXMafh5Q06j76bAbdpfNNedT9Bi6CavCR4TT0f4CHLVs/vlBNLjy2cJnHrZnQoaodF2VSciJuVPazHHY1NTs+AGUCXI8VHa8GyncS18OIa1Pt8Zo58iK2cG0192BtkOGoVoOK3DWOo9Z4JpS2XLWT16g9VFgmCQZJl1j7S6MPOo1Mg0saARKxDYRhYmBa40PpUQkpMJ1iperwisFh+P6wL4SNDhHTEOL5M9OQ2YZlyO56n0ArkWQ==; 5:bIqxa+RbM6sd0jL9bvsbgVKFBjm4EWnMRFRhinJ+eVJiTtKgb32qk6HMFcRV3JmW+X1xgNTRwsC70T0nTasVhhrUDveMR1eQxj3NUV9En2e+NlZTh2S5dMKw6GwxHWeLxq5Vfm9ydG10RKvK4P++VqRW5r311CoxVxg85OrvBMU=; 24:xjfqh8eC6PDPhMRI5FkgmIGukrA9ZGD6V/Uei1sTWUtkiNrs7x+R3O8AJ3slYGsNg+/6eCnP99LddNhhMRxJ4UcfB8UDDpQnFhMmR17ZZWo= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2504; 7:cRFAunRbg8yRhHrRjYtn/mQFedy89gP+OvGH6wPgdyVIp7j4mH4FEYVn9edfkI3p7XGFgObxwIM6o/HI/QTKOBVcl/bSPR/f4TyCzAZIGOHlwSO3D4IKshOMPJJLRr3hAKUA+1fIf9lm+UFXjTHBMmLg3aQZcozkFAOwjAOOBaY8P2HQ0jOAhAy/ylePed/0jfRA5mi6+4DisqkjadlT7Dv9NM3S18LY316L59nEBdFl9N+mzGj8F/4uqzPR7u1v X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jul 2018 13:16:45.8885 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6d735574-e7b5-4083-fc82-08d5e0e73a6a X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2504 Archived-At: Subject: Re: [tsvwg] Martin Vigoureux's No Objection on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 13:16:55 -0000 Hello Michael, thanks for your feedback. I think we are in line. regarding the wiki, tsvwg has one here: https://trac.ietf.org/trac/tsvwg/wiki My comment on a future issue is indeed a bit moot if you plan on producing the bis rapidly. What I meant to say/ask was whether the 4 "Reported" erratas should be moved to some other state (Verified/Held For Document Update/Rejected) such that this draft and the Errata web page be in synch. I'll let Spencer decide on this. -m Le 2018-07-03 13:01, Michael Tuexen a crit: >> On 3. Jul 2018, at 11:41, Martin Vigoureux wrote: >> >> Martin Vigoureux has entered the following ballot position for >> draft-ietf-tsvwg-rfc4960-errata-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-tsvwg-rfc4960-errata/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Hello, >> >> Thank you for writing down this Document. I see the value of documenting fixes >> to known issues so I support this initiative but I somehow also share Alexey's >> view. I'm not sure an RFC is the best means to achieve that goal. A living wiki >> page would have been more suitable in my opinion. I'm not an expert in that > If the IETF provides this and make sure it is available in the future, > it is an option. Once we have replaced RFC 4960 by the upcoming RFC 4960bis, > someone might ask why something has change and how... This is what this > document can provide. >> field, but what if a new issue is uncovered in the future? That would render >> this Document incomplete. Will a new draft be published that Updates this >> Document? > No... Once this document is done, we plan to start working on RFC 4960 bis > and that work is pretty easy. Integrate the changes of this document. > However, if in that time another issue comes up, we'll fix it, I guess. > However, we try to find a good point of time to do this. > > We did this once in the past, when we worked on RFC 4460, which is the > errata document to RFC 2960 and then published RFC 4960 = RFC 2960 + RFC 4460. >> >> I am a bit more concerned by the relationship between this document and the >> Erratas for 4960, and by the possible "discrepancy" its publication, with all >> things staying as they are, would introduce. 4 Erratas for 4960 are in Reported >> state, yet 3 of these 4 are addressed in this Document. Also, one of these 3 >> has a resolution which differs from the proposed Errata text. Finally, only >> this errata is referenced by its ID in the Document. Spencer the first two >> points might be more in your hands than in the authors' but I wonder if >> something should be done about it as part of publishing this Document. More >> details below: > I double checked during the IETF LC (some brought this up) and made sure > all erratas reported to the errata web site are covered. The text this > document uses might not be the one in the original errata, since the > WG might have improved it. But I can not change what the reporter suggested. > > I do see the general point. I tried to address all reported erratas in this > document. You can see an overview in > https://github.com/sctplab/rfc4960bis/blob/master/draft-ietf-tsvwg-rfc4960-errata.xml#L131 > > However, I don't control the erratas, can only discuss this on the mailing > list and provide some resolution in this document. > > But things are consistent in my view. >> >> 3.47. Clarification of Gap Ack Blocks in SACK Chunks >> The Errata for this is https://www.rfc-editor.org/errata/eid5202 >> The text change proposed by the draft is different than the one proposed by the >> Errata. Note that I am not arguing which one is better. > Errata 5202 was reported and targets two things: > > 1. The gap ack blocks in a SACK should not overlap > 2. The gap ack blocks in a SACK should be increasing. > > It was actually intended the the gap block don't overlap. That was already > clarified in section 3.47 before the errata was filed. > However, it was never intended that the gap ack blocks are increasing. > That is why there is no text related to this. > > Errata 5202 was reported on December 13th, 2017. I responded stating the > above and provided some explanations on the same day to tsvwg@ietf.org. > > I don't think we need to use the text provided in that errata. > > However, I have added > > This issue was reported as part of an Errata for with > Errata ID 5202. > > to make things clear. See > https://github.com/sctplab/rfc4960bis/commit/62ec4089c8d6c1598482257aa97e872fc5090e0e >> >> 3.24. SACK.Delay Not Listed as a Protocol Parameter >> The Errata for this is https://www.rfc-editor.org/errata/eid4656 > Correct. And this is stated in > https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-06#section-3.24.1 >> >> 3.9. Miscellaneous Typos >> The Errata for this is https://www.rfc-editor.org/errata/eid5003 > Correct. This was already catched and fixed for the next revision: > https://github.com/sctplab/rfc4960bis/commit/b8e4e8c6c558c66dab4530cce1b0b5af8eea9b0f >> >> The not discussed Reported errata is https://www.rfc-editor.org/errata/eid4876 > That is correct. It was reported on December 1st, 2016. > I responded on December 9th, 2016 to tsvwg@ietf.org that is doesn't really > make sense to me and provided some explanation. > On the same day the reporter answered on the mailing list closed with > "Please disregard my erratum report." > > So I don't see any reason for changing RFC 4960 and adding a section to this > document to describe it. > > Best regards > Michael >> >> > From nobody Tue Jul 3 07:25:38 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21B2130E0E; Tue, 3 Jul 2018 07:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 1eMi9hs2dc0f; Tue, 3 Jul 2018 07:25:33 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 497FF130E04; Tue, 3 Jul 2018 07:25:33 -0700 (PDT) Received: from [IPv6:2a02:c6a0:3061:5015:2858:d883:8f3a:a0fd] (unknown [IPv6:2a02:c6a0:3061:5015:2858:d883:8f3a:a0fd]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id C9E33721E280C; Tue, 3 Jul 2018 16:25:29 +0200 (CEST) From: Michael Tuexen Message-Id: <36049353-5F2F-482D-AFF2-57C28D07FA02@fh-muenster.de> Content-Type: multipart/signed; boundary="Apple-Mail=_087BE627-1E12-4317-88D0-3FD0916DC8F4"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Tue, 3 Jul 2018 16:25:28 +0200 In-Reply-To: Cc: The IESG , draft-ietf-tsvwg-rfc4960-errata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, tsvwg@ietf.org To: Martin Vigoureux References: <153061088467.5086.7684583062561435644.idtracker@ietfa.amsl.com> <9058127E-282C-439F-AF3C-A18FE606B6CA@fh-muenster.de> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [tsvwg] Martin Vigoureux's No Objection on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 14:25:37 -0000 --Apple-Mail=_087BE627-1E12-4317-88D0-3FD0916DC8F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 3. Jul 2018, at 15:16, Martin Vigoureux = wrote: >=20 > Hello Michael, >=20 > thanks for your feedback. I think we are in line. Yepp, I think so. > regarding the wiki, tsvwg has one here: = https://trac.ietf.org/trac/tsvwg/wiki The problem is how long it will be available. I guess it will be = available for the time we will be working on the RFC 4960bis document, but I would = prefer to have the information available for the time RFC 4960bis is available. > My comment on a future issue is indeed a bit moot if you plan on = producing the bis rapidly. I understand and agree. >=20 > What I meant to say/ask was whether the 4 "Reported" erratas should be = moved to some other state (Verified/Held For Document Update/Rejected) = such that this draft and the Errata web page be in synch. When finalising this document I looked them up. Since I have no control about the official erratas I guess this needs some actions from = Spencer... Best regards Michael >=20 > I'll let Spencer decide on this. >=20 > -m >=20 > Le 2018-07-03 =C3=A0 13:01, Michael Tuexen a =C3=A9crit : >>> On 3. Jul 2018, at 11:41, Martin Vigoureux = wrote: >>>=20 >>> Martin Vigoureux has entered the following ballot position for >>> draft-ietf-tsvwg-rfc4960-errata-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-tsvwg-rfc4960-errata/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> Hello, >>>=20 >>> Thank you for writing down this Document. I see the value of = documenting fixes >>> to known issues so I support this initiative but I somehow also = share Alexey's >>> view. I'm not sure an RFC is the best means to achieve that goal. A = living wiki >>> page would have been more suitable in my opinion. I'm not an expert = in that >> If the IETF provides this and make sure it is available in the = future, >> it is an option. Once we have replaced RFC 4960 by the upcoming RFC = 4960bis, >> someone might ask why something has change and how... This is what = this >> document can provide. >>> field, but what if a new issue is uncovered in the future? That = would render >>> this Document incomplete. Will a new draft be published that Updates = this >>> Document? >> No... Once this document is done, we plan to start working on RFC = 4960 bis >> and that work is pretty easy. Integrate the changes of this document. >> However, if in that time another issue comes up, we'll fix it, I = guess. >> However, we try to find a good point of time to do this. >> We did this once in the past, when we worked on RFC 4460, which is = the >> errata document to RFC 2960 and then published RFC 4960 =3D RFC 2960 = + RFC 4460. >>>=20 >>> I am a bit more concerned by the relationship between this document = and the >>> Erratas for 4960, and by the possible "discrepancy" its publication, = with all >>> things staying as they are, would introduce. 4 Erratas for 4960 are = in Reported >>> state, yet 3 of these 4 are addressed in this Document. Also, one of = these 3 >>> has a resolution which differs from the proposed Errata text. = Finally, only >>> this errata is referenced by its ID in the Document. Spencer the = first two >>> points might be more in your hands than in the authors' but I wonder = if >>> something should be done about it as part of publishing this = Document. More >>> details below: >> I double checked during the IETF LC (some brought this up) and made = sure >> all erratas reported to the errata web site are covered. The text = this >> document uses might not be the one in the original errata, since the >> WG might have improved it. But I can not change what the reporter = suggested. >> I do see the general point. I tried to address all reported erratas = in this >> document. You can see an overview in >> = https://github.com/sctplab/rfc4960bis/blob/master/draft-ietf-tsvwg-rfc4960= -errata.xml#L131 >> However, I don't control the erratas, can only discuss this on the = mailing >> list and provide some resolution in this document. >> But things are consistent in my view. >>>=20 >>> 3.47. Clarification of Gap Ack Blocks in SACK Chunks >>> The Errata for this is https://www.rfc-editor.org/errata/eid5202 >>> The text change proposed by the draft is different than the one = proposed by the >>> Errata. Note that I am not arguing which one is better. >> Errata 5202 was reported and targets two things: >> 1. The gap ack blocks in a SACK should not overlap >> 2. The gap ack blocks in a SACK should be increasing. >> It was actually intended the the gap block don't overlap. That was = already >> clarified in section 3.47 before the errata was filed. >> However, it was never intended that the gap ack blocks are = increasing. >> That is why there is no text related to this. >> Errata 5202 was reported on December 13th, 2017. I responded stating = the >> above and provided some explanations on the same day to = tsvwg@ietf.org. >> I don't think we need to use the text provided in that errata. >> However, I have added >> This issue was reported as part of an Errata for with >> Errata ID 5202. >> to make things clear. See >> = https://github.com/sctplab/rfc4960bis/commit/62ec4089c8d6c1598482257aa97e8= 72fc5090e0e >>>=20 >>> 3.24. SACK.Delay Not Listed as a Protocol Parameter >>> The Errata for this is https://www.rfc-editor.org/errata/eid4656 >> Correct. And this is stated in >> = https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-06#section-3.2= 4.1 >>>=20 >>> 3.9. Miscellaneous Typos >>> The Errata for this is https://www.rfc-editor.org/errata/eid5003 >> Correct. This was already catched and fixed for the next revision: >> = https://github.com/sctplab/rfc4960bis/commit/b8e4e8c6c558c66dab4530cce1b0b= 5af8eea9b0f >>>=20 >>> The not discussed Reported errata is = https://www.rfc-editor.org/errata/eid4876 >> That is correct. It was reported on December 1st, 2016. >> I responded on December 9th, 2016 to tsvwg@ietf.org that is doesn't = really >> make sense to me and provided some explanation. >> On the same day the reporter answered on the mailing list closed with >> "Please disregard my erratum report." >> So I don't see any reason for changing RFC 4960 and adding a section = to this >> document to describe it. >> Best regards >> Michael >>>=20 >>>=20 --Apple-Mail=_087BE627-1E12-4317-88D0-3FD0916DC8F4 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQkDCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFojCCBIqgAwIBAgIHF6Qk oQlIMzANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTE0MDUyNzE0NTQwOVoXDTE5MDcwOTIzNTkwMFowgcYxCzAJBgNVBAYTAkRFMRwwGgYDVQQIExNO b3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFjaGhvY2hz Y2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxlMR0wGwYD VQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVlbnN0ZXIu ZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eWyu8GzsIv0iowf2v/9BT0SmCFNX /eyQe5BncOk1j6XIlY5bnNu1S5uBe3uVgekgTh3gJyVNlaoIfCgAjqCrNJIaNQq5fr/S6L8uFeaU O8IF/C4RH5P7f9Hn2GUueEjmJhg9CI3LBAhrfAmEEtNmuVfDycN2MjngwDNxUNRfuXbWxuhkgDqJ 0ztJeayHGhFDrGx88eyStx40xy+0c0OFWdWxzBFQlBRHnl+zRftj3c9qy6BY+/fGaA2vV1oKr3h5 X6eyU1T8YlpP1NDe4bylqAteX01sM2Qciu8UAPnNc7Sb93TQjhCFRVDIS3CdN6AOpwz5YWEld6ey CdmFZ7pvAgMBAAGjggH+MIIB+jASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAR BgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFArzW7zkMYDWNUKJptPDzzfe0d/XMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOBEWNhQGZoLW11ZW5zdGVyLmRlMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0 dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDov L2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYI KwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQDeRwM11kpvuRIPuzWXLapr/ZBtB76V3cuF l45x/Kx0u03yjB4GaBPcxihn4P1z5KhRYkDBMo8HXkOgbL59aF6VdOlCurEgZvghKvUkKOCyWeYx S9rTGPBkbGiNn2ATVuLXzF8rDf50ynAIu3otstOOv+3Ifqi1pzCva1nO64khQA5Gd5/BNyu+YHbW f8ERAf9leu5a7yVI7cv1gCZAHpWJpkUKmfawyY4sAJ2hbGZRBvdACOxrfbuMdSOzPneT2rlmvH+D 7M6DmzVabLYk6UtAxQhldd/T/qsHkWvaWXHt0Eb9STs2Fl03Ls7M3NyLQLhaeR3ysNURYcaEfaB+ lxN+MIIGDTCCBPWgAwIBAgIHG5mIdDexozANBgkqhkiG9w0BAQsFADCBxjELMAkGA1UEBhMCREUx HDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQK ExdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVu dHJhbGUxHTAbBgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBm aC1tdWVuc3Rlci5kZTAeFw0xNjA3MDQwNzA2MTNaFw0xOTA3MDQwNzA2MTNaMHwxCzAJBgNVBAYT AkRFMSAwHgYDVQQKDBdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEyMDAGA1UECwwpRmFjaGJlcmVp Y2ggRWxla3Ryb3RlY2huaWsgdW5kIEluZm9ybWF0aWsxFzAVBgNVBAMMDk1pY2hhZWwgVHVleGVu MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzJoaUG3Zm24XxA/zNg2sbFcL56w8xqMg +X6G7UsYec3YEncnlkw3jgE5nDefos7UVoCA7wPjFTj8AQt5xfpXElnbM45IPy5Ng7g6dS7biGSM VRACPXe1PrjgApRAwwGmCPvALnZXkmKP6Zlf+3VLfz9YWIIaeKu3jFM2Lk6Y3gr5U1l8bjHSawOo WMlfvSsXXLT38zKW7Uz9jS278j0OqHANBPgsE6/LJoCWFInwlvybxhO3nGU7OteUGaPikqzvjLsL YgpHDi0WjMZfVx/UtUSzZ4EJvmJTBeuVwyKnCbrawnfwYPTQQ6VE1OkAzmsMByBbEwJ996RtG//T XCG06QIDAQABo4ICRzCCAkMwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGB rSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTQHa9qhKgSZgCCAPThZkXaEaJ/ dTAfBgNVHSMEGDAWgBQK81u85DGA1jVCiabTw8833tHf1zAgBgNVHREEGTAXgRV0dWV4ZW5AZmgt bXVlbnN0ZXIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Zo LW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAz BggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9maC1tdWVuc3Rl ci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAEj2/6x4kzoCVIiu aaminPrOHxACyoYsmSRjYPQpgW5xRj/FlolO1nG+ZZ11sqTb3TdCGD69ko5/zs8eGKnv/i0VLCHF g1JLfpaxElN5RrR/cqRJrbzKshF9aUkBODF8vlf9BCeimMK3fifjbbWRyxHssfEECffujD7/Yvta NYMO46Roz39lIK2s37IVFq3V5RWzUeTuwpP9t8lOxirOi9eK2OYI/dh0HjR2S5Dr9nMR1dNulrhz jlFxGc+opefGScrRR9Ec0eqTXlbt1Q9UzNIYVS+OGZY8/bBbprwXVTmwSp8dygEULkIaMbLsaTaW 6TehuL8ousPJkL52SOENgSkxggQpMIIEJQIBATCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozAJBgUrDgMCGgUAoIICKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xODA3MDMxNDI1MjlaMCMGCSqGSIb3DQEJBDEWBBSaUQpprX1lnGJxQMwT bHL9v3cCkjCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9y ZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2No dWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UE AxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRl AgcbmYh0N7GjMIHlBgsqhkiG9w0BCRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozANBgkqhkiG9w0BAQEFAASCAQBfwgenp/nFUVGFqeMv6dTvtnyx25zV2nT1 ye9Nf56fmUAMN+XFRbAV22160Cgxe7AgxjMiWk2g+EiQ6iCRmtvCB6qN/qAdnEA68qSXktq9xDP9 siSeZfud7mLP/YPUmW6Ub3vv6RHYnmfPaCLG497IKOgxubWd3UNyzWsGUDskUdbUH++CUulDLbrx 4XwOhorZBODMf/bwtXxXBvFxyx6xdgfsMjoMVpzYfe7PcELDgOwC2J3RzufuGwUGyqFMFomz5M3S BSOdOQQChGsWfpBnnS+eh/mLehJ7KBLGqPuDb1ZynkGmvRGk7xoPbIlycvl7UDTSjdAP9509GMpu pbi3AAAAAAAA --Apple-Mail=_087BE627-1E12-4317-88D0-3FD0916DC8F4-- From nobody Tue Jul 3 09:08:29 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 467D11310EA; Tue, 3 Jul 2018 09:00:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: tsvwg@ietf.org, spencerdawkins.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153063363126.4893.7788797875457829086.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2018 09:00:31 -0700 Archived-At: Subject: [tsvwg] tsvwg - Requested sessions have been scheduled for IETF 102 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 16:00:41 -0000 Dear Gorry Fairhurst, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tsvwg Session 1 (2:00 requested) Thursday, 19 July 2018, Afternoon Session II 1550-1750 Room Name: Centre Ville size: 200 --------------------------------------------- tsvwg Session 2 (1:00 requested) Thursday, 19 July 2018, Afternoon Session III 1810-1910 Room Name: Centre Ville size: 200 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/102/sessions/tsvwg.ics Request Information: --------------------------------------------------------- Working Group Name: Transport Area Working Group Area Name: Transport Area Session Requester: Gorry Fairhurst Number of Sessions: 2 Length of Session(s): 1 Hour, 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: opsarea rtgwg tcpinc quic ippm taps mptcp tcpm rmcat iccrg tsvarea intarea saag detnet Second Priority: dtn rtcweb v6ops tram dispatch Third Priority: artarea ccamp People who must be present: David L. Black Gorry Fairhurst Spencer Dawkins Wesley Eddy Mirja Kuehlewind Resources Requested: Special Requests: Must not conflict with Transport Area BoFs. One of the two sessions must not conflict with saag. Either the 1 hour or 2 hour session may be timetabled first. --------------------------------------------------------- From nobody Tue Jul 3 13:37:15 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D66130DE2; Tue, 3 Jul 2018 13:37:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-tsvwg-rfc4960-errata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, gorry@erg.abdn.ac.uk, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153065022701.5099.10852319899819966685.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2018 13:37:07 -0700 Archived-At: Subject: [tsvwg] Adam Roach's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 20:37:07 -0000 Adam Roach has entered the following ballot position for draft-ietf-tsvwg-rfc4960-errata-06: Abstain 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-tsvwg-rfc4960-errata/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Ben (and, transitively, the OPSDIR an GENART reviewers). From my reading, this document -- while immensely valuable to the working group for creation of an RFC 4960 bis document -- has little archival value. The following standing guidance from the IESG would seem to be applicable: https://www.ietf.org/blog/support-documents-ietf-working-groups/ Like Ben, I'm abstaining on this document. I would ask the working group to consider not publishing it in this form, and waiting until a complete bis version of the document can be produced. From nobody Tue Jul 3 16:31:41 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD68E130DD4; Tue, 3 Jul 2018 16:31:33 -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-tsvwg-rfc4960-errata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, gorry@erg.abdn.ac.uk, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153066069383.5123.15949635433835942791.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2018 16:31:33 -0700 Archived-At: Subject: [tsvwg] Eric Rescorla's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 23:31:35 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-tsvwg-rfc4960-errata-06: Abstain 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-tsvwg-rfc4960-errata/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Adam and Spencer. This is just an incredibly user-hostile presentation of this information, in particular: Note that when reading this document one must use care to assure that a field or item is not updated further on within the document. Since this document is a historical record of the sequential changes that have been found necessary at various inter-op events and through discussion on the list, the last delta in the text is the one which should be applied. This seems like good input to a -bis but should not be published as-is. From nobody Tue Jul 3 22:19:47 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72CD130DEC; Tue, 3 Jul 2018 22:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 gb7a-Epa53XQ; Tue, 3 Jul 2018 22:19:37 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20A79130DEF; Tue, 3 Jul 2018 22:19:36 -0700 (PDT) Received: from [IPv6:2003:cd:6f1a:9700:f075:1c12:65bd:31d7] (p200300CD6F1A9700F0751C1265BD31D7.dip0.t-ipconnect.de [IPv6:2003:cd:6f1a:9700:f075:1c12:65bd:31d7]) (Authenticated sender: macmic) by drew.franken.de (Postfix) with ESMTPSA id 3620672106C26; Wed, 4 Jul 2018 07:19:32 +0200 (CEST) From: Michael Tuexen Message-Id: <6030538E-9108-4DBA-A8BE-0CE604BFE9D9@fh-muenster.de> Content-Type: multipart/signed; boundary="Apple-Mail=_B5AAAF06-2596-4ED1-A5D2-A979550BE449"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Wed, 4 Jul 2018 07:19:29 +0200 In-Reply-To: <153065022701.5099.10852319899819966685.idtracker@ietfa.amsl.com> Cc: The IESG , draft-ietf-tsvwg-rfc4960-errata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, tsvwg@ietf.org To: Adam Roach References: <153065022701.5099.10852319899819966685.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [tsvwg] Adam Roach's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 05:19:41 -0000 --Apple-Mail=_B5AAAF06-2596-4ED1-A5D2-A979550BE449 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 3. Jul 2018, at 22:37, Adam Roach wrote: >=20 > Adam Roach has entered the following ballot position for > draft-ietf-tsvwg-rfc4960-errata-06: Abstain >=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-tsvwg-rfc4960-errata/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I agree with Ben (and, transitively, the OPSDIR an GENART reviewers). = =46rom my > reading, this document -- while immensely valuable to the working = group for > creation of an RFC 4960 bis document -- has little archival value. The = following > standing guidance from the IESG would seem to be applicable: >=20 > https://www.ietf.org/blog/support-documents-ietf-working-groups/ >=20 > Like Ben, I'm abstaining on this document. I would ask the working = group to > consider not publishing it in this form, and waiting until a complete = bis > version of the document can be produced. Just to get a better understanding of your position: Are you suggesting either (1) To work on RFC4960-bis and once that gets published, publish an = RFC4960-errata which is consistent with RFC4960-bis at a later time. or (2) To work on RFC4960-bis and just drop this document since there is no = archival value for the reasons why something has changed. Having the changed = version is the important point. Best regards Michael >=20 >=20 --Apple-Mail=_B5AAAF06-2596-4ED1-A5D2-A979550BE449 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQkDCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFojCCBIqgAwIBAgIHF6Qk oQlIMzANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTE0MDUyNzE0NTQwOVoXDTE5MDcwOTIzNTkwMFowgcYxCzAJBgNVBAYTAkRFMRwwGgYDVQQIExNO b3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFjaGhvY2hz Y2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxlMR0wGwYD VQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVlbnN0ZXIu ZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eWyu8GzsIv0iowf2v/9BT0SmCFNX /eyQe5BncOk1j6XIlY5bnNu1S5uBe3uVgekgTh3gJyVNlaoIfCgAjqCrNJIaNQq5fr/S6L8uFeaU O8IF/C4RH5P7f9Hn2GUueEjmJhg9CI3LBAhrfAmEEtNmuVfDycN2MjngwDNxUNRfuXbWxuhkgDqJ 0ztJeayHGhFDrGx88eyStx40xy+0c0OFWdWxzBFQlBRHnl+zRftj3c9qy6BY+/fGaA2vV1oKr3h5 X6eyU1T8YlpP1NDe4bylqAteX01sM2Qciu8UAPnNc7Sb93TQjhCFRVDIS3CdN6AOpwz5YWEld6ey CdmFZ7pvAgMBAAGjggH+MIIB+jASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAR BgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFArzW7zkMYDWNUKJptPDzzfe0d/XMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOBEWNhQGZoLW11ZW5zdGVyLmRlMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0 dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDov L2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYI KwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQDeRwM11kpvuRIPuzWXLapr/ZBtB76V3cuF l45x/Kx0u03yjB4GaBPcxihn4P1z5KhRYkDBMo8HXkOgbL59aF6VdOlCurEgZvghKvUkKOCyWeYx S9rTGPBkbGiNn2ATVuLXzF8rDf50ynAIu3otstOOv+3Ifqi1pzCva1nO64khQA5Gd5/BNyu+YHbW f8ERAf9leu5a7yVI7cv1gCZAHpWJpkUKmfawyY4sAJ2hbGZRBvdACOxrfbuMdSOzPneT2rlmvH+D 7M6DmzVabLYk6UtAxQhldd/T/qsHkWvaWXHt0Eb9STs2Fl03Ls7M3NyLQLhaeR3ysNURYcaEfaB+ lxN+MIIGDTCCBPWgAwIBAgIHG5mIdDexozANBgkqhkiG9w0BAQsFADCBxjELMAkGA1UEBhMCREUx HDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQK ExdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVu dHJhbGUxHTAbBgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBm aC1tdWVuc3Rlci5kZTAeFw0xNjA3MDQwNzA2MTNaFw0xOTA3MDQwNzA2MTNaMHwxCzAJBgNVBAYT AkRFMSAwHgYDVQQKDBdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEyMDAGA1UECwwpRmFjaGJlcmVp Y2ggRWxla3Ryb3RlY2huaWsgdW5kIEluZm9ybWF0aWsxFzAVBgNVBAMMDk1pY2hhZWwgVHVleGVu MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzJoaUG3Zm24XxA/zNg2sbFcL56w8xqMg +X6G7UsYec3YEncnlkw3jgE5nDefos7UVoCA7wPjFTj8AQt5xfpXElnbM45IPy5Ng7g6dS7biGSM VRACPXe1PrjgApRAwwGmCPvALnZXkmKP6Zlf+3VLfz9YWIIaeKu3jFM2Lk6Y3gr5U1l8bjHSawOo WMlfvSsXXLT38zKW7Uz9jS278j0OqHANBPgsE6/LJoCWFInwlvybxhO3nGU7OteUGaPikqzvjLsL YgpHDi0WjMZfVx/UtUSzZ4EJvmJTBeuVwyKnCbrawnfwYPTQQ6VE1OkAzmsMByBbEwJ996RtG//T XCG06QIDAQABo4ICRzCCAkMwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGB rSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTQHa9qhKgSZgCCAPThZkXaEaJ/ dTAfBgNVHSMEGDAWgBQK81u85DGA1jVCiabTw8833tHf1zAgBgNVHREEGTAXgRV0dWV4ZW5AZmgt bXVlbnN0ZXIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Zo LW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAz BggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9maC1tdWVuc3Rl ci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAEj2/6x4kzoCVIiu aaminPrOHxACyoYsmSRjYPQpgW5xRj/FlolO1nG+ZZ11sqTb3TdCGD69ko5/zs8eGKnv/i0VLCHF g1JLfpaxElN5RrR/cqRJrbzKshF9aUkBODF8vlf9BCeimMK3fifjbbWRyxHssfEECffujD7/Yvta NYMO46Roz39lIK2s37IVFq3V5RWzUeTuwpP9t8lOxirOi9eK2OYI/dh0HjR2S5Dr9nMR1dNulrhz jlFxGc+opefGScrRR9Ec0eqTXlbt1Q9UzNIYVS+OGZY8/bBbprwXVTmwSp8dygEULkIaMbLsaTaW 6TehuL8ousPJkL52SOENgSkxggQpMIIEJQIBATCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozAJBgUrDgMCGgUAoIICKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xODA3MDQwNTE5MzBaMCMGCSqGSIb3DQEJBDEWBBQsMLt6T/lddLRJNY6Y 1Fp/BExeTzCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9y ZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2No dWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UE AxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRl AgcbmYh0N7GjMIHlBgsqhkiG9w0BCRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozANBgkqhkiG9w0BAQEFAASCAQAOQ98zOghaNmUZz5vhXi5E/3WNXWHFSH2J Hx43A9gWSTBIkSYWRI9//NSuBKi1HYw5CV2hSvoEt8Z0ZTvyIP3R48CsXAx/PElWpT4NY5hq9p4g wXgC9WU9/b7sCosO6SBRSYK5Es+jgLsfhEMyKZL0t20kYU5L/OBIW0C+q/b3i+wQ7DhHiDrl5Dz9 o1xn+aBGxV8dJi5cUl2QXDsyt3Wq927Nvz/r4LJiatWNShib4wsNiMIcqmhjFlIDLnMINBY2wKoh SXORrB9dIXp6p/zcP0U2ZoBh5l60BM4MZZB/JgW4rRl+ZSvV6RTPJHNK/P3D2KJiJqGsM52N6i8M LvaBAAAAAAAA --Apple-Mail=_B5AAAF06-2596-4ED1-A5D2-A979550BE449-- From nobody Tue Jul 3 22:25:09 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDE2130E1A; Tue, 3 Jul 2018 22:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 M25NUD9t-wMR; Tue, 3 Jul 2018 22:25:01 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6017D130DEF; Tue, 3 Jul 2018 22:25:01 -0700 (PDT) Received: from [IPv6:2003:cd:6f1a:9700:f075:1c12:65bd:31d7] (p200300CD6F1A9700F0751C1265BD31D7.dip0.t-ipconnect.de [IPv6:2003:cd:6f1a:9700:f075:1c12:65bd:31d7]) (Authenticated sender: macmic) by drew.franken.de (Postfix) with ESMTPSA id 8D3EB72106C27; Wed, 4 Jul 2018 07:24:58 +0200 (CEST) From: Michael Tuexen Message-Id: <059E8CF3-A927-4433-AC24-8D5A20A9734D@fh-muenster.de> Content-Type: multipart/signed; boundary="Apple-Mail=_46AF683C-8FDA-4F4C-B2D8-DDD52C16BF30"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Wed, 4 Jul 2018 07:24:57 +0200 In-Reply-To: <153066069383.5123.15949635433835942791.idtracker@ietfa.amsl.com> Cc: The IESG , draft-ietf-tsvwg-rfc4960-errata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, tsvwg@ietf.org To: Eric Rescorla References: <153066069383.5123.15949635433835942791.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [tsvwg] Eric Rescorla's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 05:25:03 -0000 --Apple-Mail=_46AF683C-8FDA-4F4C-B2D8-DDD52C16BF30 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > > On 4. Jul 2018, at 01:31, Eric Rescorla wrote: > > Eric Rescorla has entered the following ballot position for > draft-ietf-tsvwg-rfc4960-errata-06: Abstain > > 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-tsvwg-rfc4960-errata/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with Adam and Spencer. This is just an incredibly user-hostile Not sure if Adam and Spencer are in agreement here... > presentation of this information, in particular: > > Note that when reading this document one must use care to assure that > a field or item is not updated further on within the document. Since > this document is a historical record of the sequential changes that > have been found necessary at various inter-op events and through > discussion on the list, the last delta in the text is the one which > should be applied. > > This seems like good input to a -bis but should not be published as-is. So I guess you are suggesting to drop this document and work on an RFC4960bis instead, because there is no need to document the reasons for the changes? Best regards Michael > > --Apple-Mail=_46AF683C-8FDA-4F4C-B2D8-DDD52C16BF30 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQkDCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFojCCBIqgAwIBAgIHF6Qk oQlIMzANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTE0MDUyNzE0NTQwOVoXDTE5MDcwOTIzNTkwMFowgcYxCzAJBgNVBAYTAkRFMRwwGgYDVQQIExNO b3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFjaGhvY2hz Y2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxlMR0wGwYD VQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVlbnN0ZXIu ZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eWyu8GzsIv0iowf2v/9BT0SmCFNX /eyQe5BncOk1j6XIlY5bnNu1S5uBe3uVgekgTh3gJyVNlaoIfCgAjqCrNJIaNQq5fr/S6L8uFeaU O8IF/C4RH5P7f9Hn2GUueEjmJhg9CI3LBAhrfAmEEtNmuVfDycN2MjngwDNxUNRfuXbWxuhkgDqJ 0ztJeayHGhFDrGx88eyStx40xy+0c0OFWdWxzBFQlBRHnl+zRftj3c9qy6BY+/fGaA2vV1oKr3h5 X6eyU1T8YlpP1NDe4bylqAteX01sM2Qciu8UAPnNc7Sb93TQjhCFRVDIS3CdN6AOpwz5YWEld6ey CdmFZ7pvAgMBAAGjggH+MIIB+jASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAR BgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFArzW7zkMYDWNUKJptPDzzfe0d/XMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOBEWNhQGZoLW11ZW5zdGVyLmRlMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0 dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDov L2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYI KwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQDeRwM11kpvuRIPuzWXLapr/ZBtB76V3cuF l45x/Kx0u03yjB4GaBPcxihn4P1z5KhRYkDBMo8HXkOgbL59aF6VdOlCurEgZvghKvUkKOCyWeYx S9rTGPBkbGiNn2ATVuLXzF8rDf50ynAIu3otstOOv+3Ifqi1pzCva1nO64khQA5Gd5/BNyu+YHbW f8ERAf9leu5a7yVI7cv1gCZAHpWJpkUKmfawyY4sAJ2hbGZRBvdACOxrfbuMdSOzPneT2rlmvH+D 7M6DmzVabLYk6UtAxQhldd/T/qsHkWvaWXHt0Eb9STs2Fl03Ls7M3NyLQLhaeR3ysNURYcaEfaB+ lxN+MIIGDTCCBPWgAwIBAgIHG5mIdDexozANBgkqhkiG9w0BAQsFADCBxjELMAkGA1UEBhMCREUx HDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQK ExdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVu dHJhbGUxHTAbBgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBm aC1tdWVuc3Rlci5kZTAeFw0xNjA3MDQwNzA2MTNaFw0xOTA3MDQwNzA2MTNaMHwxCzAJBgNVBAYT AkRFMSAwHgYDVQQKDBdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEyMDAGA1UECwwpRmFjaGJlcmVp Y2ggRWxla3Ryb3RlY2huaWsgdW5kIEluZm9ybWF0aWsxFzAVBgNVBAMMDk1pY2hhZWwgVHVleGVu MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzJoaUG3Zm24XxA/zNg2sbFcL56w8xqMg +X6G7UsYec3YEncnlkw3jgE5nDefos7UVoCA7wPjFTj8AQt5xfpXElnbM45IPy5Ng7g6dS7biGSM VRACPXe1PrjgApRAwwGmCPvALnZXkmKP6Zlf+3VLfz9YWIIaeKu3jFM2Lk6Y3gr5U1l8bjHSawOo WMlfvSsXXLT38zKW7Uz9jS278j0OqHANBPgsE6/LJoCWFInwlvybxhO3nGU7OteUGaPikqzvjLsL YgpHDi0WjMZfVx/UtUSzZ4EJvmJTBeuVwyKnCbrawnfwYPTQQ6VE1OkAzmsMByBbEwJ996RtG//T XCG06QIDAQABo4ICRzCCAkMwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGB rSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTQHa9qhKgSZgCCAPThZkXaEaJ/ dTAfBgNVHSMEGDAWgBQK81u85DGA1jVCiabTw8833tHf1zAgBgNVHREEGTAXgRV0dWV4ZW5AZmgt bXVlbnN0ZXIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Zo LW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAz BggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9maC1tdWVuc3Rl ci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAEj2/6x4kzoCVIiu aaminPrOHxACyoYsmSRjYPQpgW5xRj/FlolO1nG+ZZ11sqTb3TdCGD69ko5/zs8eGKnv/i0VLCHF g1JLfpaxElN5RrR/cqRJrbzKshF9aUkBODF8vlf9BCeimMK3fifjbbWRyxHssfEECffujD7/Yvta NYMO46Roz39lIK2s37IVFq3V5RWzUeTuwpP9t8lOxirOi9eK2OYI/dh0HjR2S5Dr9nMR1dNulrhz jlFxGc+opefGScrRR9Ec0eqTXlbt1Q9UzNIYVS+OGZY8/bBbprwXVTmwSp8dygEULkIaMbLsaTaW 6TehuL8ousPJkL52SOENgSkxggQpMIIEJQIBATCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozAJBgUrDgMCGgUAoIICKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xODA3MDQwNTI0NTdaMCMGCSqGSIb3DQEJBDEWBBTo5Z9vjkuJGcMUagbc KV1CjX0JPzCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9y ZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2No dWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UE AxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRl AgcbmYh0N7GjMIHlBgsqhkiG9w0BCRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozANBgkqhkiG9w0BAQEFAASCAQAXmh40VUqzXt6+Zlnp65cExnNJUPKG7fyo +h8PRFtIp8nmGhi8eDeK54zTQdt5ievjIcyLZhz+1xEnnOJ/9kdUnlaq4YyRzauydCqnHl+qgIzS +eY+Wxc0PchOKs+5vQPNubTN1fWAW1CUi41odrfcSeO4R6+YfZoBl0NULGvGr6pGr2ABtTvQF1Vx xVMoNvIaeaAjnXf+KGzy8Jl+1yi+sm2kFLIWt1qnpVaQZo1i7h9wHXNh4LgYgKE1DFA8RT1lGdQs Mw9L7Tptsc+oy46Qi+x9rRihW4ZVsKMoYqGHAe2gDb2l/FIOzL6njMIy3peE6cLxnBzdHA/OE7KX cqC9AAAAAAAA --Apple-Mail=_46AF683C-8FDA-4F4C-B2D8-DDD52C16BF30-- From nobody Tue Jul 3 22:27:23 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF5D130E39 for ; Tue, 3 Jul 2018 22:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 eyTjTTMJZENp for ; Tue, 3 Jul 2018 22:27:18 -0700 (PDT) Received: from pb-smtp1.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF714130DEF for ; Tue, 3 Jul 2018 22:27:18 -0700 (PDT) Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id B64481004F2 for ; Wed, 4 Jul 2018 01:27:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; s=sasl; bh=P/X 9c2iF1cdbDb4btpS/PFMwSpw=; b=gSyeRnYs59eQBRuiE79N7AcB04LPivsp2ZR AwHocSgTZKL1PtB0SPIB1M+OOz4qTWgCnbMeohQCuqncnl/vIOEqQWDRtG6FyDpj hmNsimcGuxDu+OjH9xRdYAwhK4oY+wygToWEsZ7wmoDsMF/6bPeJoO6nlsK4sPyu 56dRkHfw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; q=dns; s=sasl; b= NJJZ2eJq7V0G1wwt7hId5I97WbdHQxpKVArYh03gbhPEes+0CeEQi17D903R5Iu1 wOdnTYaeRmjsc99xYxN8T/v9aey1zWdYfEcBvtUyRMdzFqjWFxyCTnIU7YEoIV+w qK+Hs4+HADXjyF0PltZSYQQoUgPDpwtKHJGNGCEB50I= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id AC5881004F1 for ; Wed, 4 Jul 2018 01:27:15 -0400 (EDT) Received: from mail-oi0-f50.google.com (unknown [209.85.218.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 2EF3E1004ED for ; Wed, 4 Jul 2018 01:27:15 -0400 (EDT) Received: by mail-oi0-f50.google.com with SMTP id m2-v6so8378076oim.12 for ; Tue, 03 Jul 2018 22:27:15 -0700 (PDT) X-Gm-Message-State: APt69E1LR0oTXGvq5cZIoAh8AJWlIj+YJSKf3UF1kLD9E/haIhmlgMvS UWhdBBaCc3CPNWGbo9fxkYQ2f8eF6cFhyDP5Cro= X-Google-Smtp-Source: AAOMgpfUcH/Vz8q5dyxrLo79NMSogAXWe/GB2tu1q/CH88A/BzSgbuYQW69S/j+K/GIZVB032XvkrB22+zFP0HLNffw= X-Received: by 2002:aca:1719:: with SMTP id j25-v6mr591908oii.138.1530682034522; Tue, 03 Jul 2018 22:27:14 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:cb94:0:0:0:0:0 with HTTP; Tue, 3 Jul 2018 22:26:54 -0700 (PDT) From: "C. M. Heard" Date: Tue, 3 Jul 2018 22:26:54 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Joe Touch Cc: tsvwg Content-Type: multipart/alternative; boundary="000000000000ee92da057025ae9a" X-Pobox-Relay-ID: E93B2FCA-7F4A-11E8-A392-0DFB1A68708C-06080547!pb-smtp1.pobox.com Archived-At: Subject: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 05:27:22 -0000 --000000000000ee92da057025ae9a Content-Type: text/plain; charset="UTF-8" Hi Joe, This version looks really good to me, with only a couple of minor issues. First, in Section 5.4, Alternate Checksum (ACS), there are two technical comments that I made on the -02 version that I don't believe have been properly addressed: On Sun, May 6, 2018 at 10:23 AM, C. M. Heard wrote: > > Also, it is necessary to specify whether the data polynomial is > constructed as if the bytes are transmitted most significant bit first or > least significant bit first. Finally, the polynomial is x^16 + x^12 + x^5 > + 1 (which would be 0x11021, but that fact is not needed, and I recommend > omitting it). > In what is probably a typo, the -04 draft has the generator polynomial as "x^16 + x^12 + x^5 + x" instead of "x^16 + x^12 + x^5 + 1." It also does not specify how to construct the polynomial represent the data to be checksummed. That latter point may not be entirely obvious. In order to re-used existing software used to compute CRC-CCITT, that polynomial needs to be constructed as if the least significant bit of each byte is the the coefficient associated with the highest power of x. So, for example, *0x8b* would correspond to x^7 + x^6 + x^4 + 1 and not to x^7 + x^3 + x + 1 as one might expect. Here is how one might fully specify the algorithm. Suppose that there are n bytes of checksummed data, indexed from 0 through n-1 in order of appearance in the (possibly reassembled) datagram, and P(k,x) is the polynomial representing the kth byte. Then the polynomial M(x) representing the data to be checksummed would be the sum, taken from k=0 to n-1, of x^(8*(n-1-k)) * P(k,x). The ACS option then contains the remainder upon division (modulo 2) of x^16 * M(x) by the generator polynomial x^16 + x^12 + x^5 + 1. I would not belabor such a seemingly trivial point were it not so vexatious in practice. Maybe you can think of some nice, short, words to make this point clear. Or maybe there is a suitable stable reference that has the details, though at this time I am not aware of one. Or maybe I am in the rough and it really is something that "everyone knows" (but I doubt that). Also, may I suggest that instead of saying that the "Alternate Checksum (ACS) provides a stronger alternative to the UDP header checksum" consider saying instead "Alternate Checksum (ACS) provides a stronger alternative to the checksum in the UDP header." To me, the words "UDP header checksum" suggest a checksum that covers only the UDP header (similar to an analogous one in IPv4). There are two additional occurrences in Section 5.7, where I have some other editorial suggestions as well: OLD: >> During fragmentation, the UDP header checksum of each fragment needs to be recomputed based on each datagram's pseudoheader. >> After reassembly is complete and validated using the checksum of the terminal FRAG option, the UDP header checksum of the resulting datagram needs to be recomputed based on the datagram's pseudoheader. NEW: >> During fragmentation, the checksum in the UDP header of each fragment needs to be recomputed based on that datagram's pseudoheader. >> After reassembly is complete and validated using the checksum of the terminal FRAG option, the checksum in the UDP header of the resulting datagram needs to be recomputed based on the reassembled datagram's pseudoheader. Thanks and regards, Mike Heard --000000000000ee92da057025ae9a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Joe,

This version looks r= eally good to me, with only a couple of minor issues.

<= div>First, in Section 5.4, Alternate Checksum (ACS), there are two technica= l comments that I made on the -02 version that I don't believe have bee= n properly addressed:

O= n Sun, May 6, 2018 at 10:23 AM, C. M. Heard wrote:
Also, it is necessary to specify whether the data polynomial is co= nstructed as if the bytes are transmitted most significant bit first or lea= st significant bit first. Finally, the polynomial is=C2=A0x^16 + x^12 + x^5 + 1 (which would be 0= x11021, but that fact is not needed, and I recommend omitting it).

In what is probably a = typo, the -04 draft has the generator polynomial as "x^16 + x^12 + x^5 + x" instead of = "x^16 + x^= 12 + x^5 + 1."

It also does not specify how to construct the polynomial rep= resent the data to be checksummed. That latter point may not be entirely ob= vious.

In order to re-used existing software used to compute CRC-CCIT= T, that polynomial needs to be constructed as if the least significant bit = of each byte is the the coefficient associated with the highest power of x.= So, for example, 0x8b would correspond to

x^7 += x^6 =C2=A0+ x^4 + 1

and not to
=

x^7=C2=A0+ x^3=C2=A0+ x =C2=A0+ 1
as one might expect. Here is how one might fully specify the al= gorithm.=C2=A0Suppose = that there are n bytes of checksummed data, indexed from 0 through n-1 in o= rder of appearance in the (possibly reassembled) datagram, and P(k,x) is th= e polynomial representing the kth byte. Then the polynomial M(x) representi= ng the data to be checksummed would be the sum, taken from k=3D0 to n-1, of= =C2=A0x^(8*(n-1= -k)) * P(k,x). The ACS option then contains = the remainder upon division (modulo 2) = of=C2=A0= x^16 * M(x) =C2=A0by the generator polynomial=C2=A0x^16 + x^12 + x^5 + 1.

I would not belabor s= uch a seemingly trivial point were it not so vexatious in practice.=C2=A0Maybe you can thi= nk of some nice, short, words to make this point clear. Or maybe there is a= suitable=C2=A0= stable reference that has the details, though at this time I am not aware o= f one. Or maybe I am in the rough and it really is something that "eve= ryone knows" (but I doubt that).

Also, may I suggest that instead of saying= that the "Alternate Checksum (ACS) provides a stronger alternative to the UDP= header checksum" consider saying instead "Alternate Checksum (AC= S) provides a stronger alternative to the checksum in the UDP header."= To me, the words "UDP header checksum" =C2=A0sugge= st a checksum that covers only the UDP header (similar to an analogous one = in IPv4). There are two additional occurrences in Section 5.7, where I have= some other editorial suggestions as well:

OLD:
   >> Du=
ring fragmentation, the UDP=
 header checksum of each fragment
   needs to be recomputed based on each datagram's pseudoheader.

   >> After reassembly is complete and validated using the checksum o=
f
   the terminal FRAG option, the UDP header checksum of the resulting
   datagra=
m needs to be recomputed based on the datagram's
   pseudoheader.

NEW:
   >> During fragmentation, the checksum in the UDP header o=
f each fragment
   needs to be recomputed based on that datagram's pseudoheader.

   >> After reassembly is complete and validated using the checksum o=
f
   the terminal FRAG option, the checksum in the UDP header of the resulting
   datagra=
m needs to be recomputed based on the reassembled datagram's
   pseudoheader.

Thanks and regards,

Mike Heard --000000000000ee92da057025ae9a-- From nobody Wed Jul 4 02:35:31 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948D0130E64; Wed, 4 Jul 2018 02:35:23 -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, 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=fastmail.fm header.b=IsqAN0GW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XSurO9/e 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 TpL7zMuy8X09; Wed, 4 Jul 2018 02:35:21 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD678130E82; Wed, 4 Jul 2018 02:35:19 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 390F620F02; Wed, 4 Jul 2018 05:35:19 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 04 Jul 2018 05:35:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=230pbxxXwiyOUxcWXOluJnQBG8KLv C4ex1BZoazbpGA=; b=IsqAN0GWciwlF5KOmQ8zJd7+FT00bDjA37SufpGxeqOfs WvYlZuFRIHFNZkbz7D8ZlmOnttYhZD+jklvhIgxYFWDetq+bd0qsnVlWHSRBRhUI FcZo3uQua6T5nuXqhD4DvDep0OGnL+2F2PBYqBvfWjwmDoW7mvHMtZOQJxyQrjky XzBW8TyjSDu5KV8e0fKtUpatxRxympYQ17W5pRj7kEj96hL8kvTU43VXPWH2xS6E R7QGIShUE00f23SZOjMEE81XLIjnBcRRjowURdvyf+LRmoooz5cpLbbHPaKXtnFZ JiOuKCIxF47smNpZr/dNaM2vLxL98GABQEkQEpY9A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=230pbx xXwiyOUxcWXOluJnQBG8KLvC4ex1BZoazbpGA=; b=XSurO9/eeKDuHg7oyTpjCe o6y7SW8ukO6H8ALurPbmJRCBroqssSPIKEVoJUuZcBygbhX91qRyvQ2EzbiHwMdL NB+tCRd2Ywda/EJVbu2VeNxlRAaEVnMhfbHN7MH64yCiYl4JGogaQJnVTQsNsKFX uvQQuxmyJd3YV3AyihhbNZy4BVvF6+Faw+z41nasTkG/PGvkackFlutwReoWjvRk fNuSy/HZJF3jsmj2ItZNnN6mx4kBJnjB51s0xQ6/8XBS6HmL4ZTrtwQ1qaWGgzzK mAsf/awPlVfD+3nggK8l/bt6oBmON6HTx4N3pQXMT6wFkRCEPJkUEQXIZiUzEVvw == X-ME-Proxy: X-ME-Sender: Received: from [192.168.0.6] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by mail.messagingengine.com (Postfix) with ESMTPA id 4BAAAE4439; Wed, 4 Jul 2018 05:35:18 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPad Mail (14F89) In-Reply-To: <059E8CF3-A927-4433-AC24-8D5A20A9734D@fh-muenster.de> Date: Wed, 4 Jul 2018 10:49:18 +0100 Cc: Eric Rescorla , Gorry Fairhurst , tsvwg-chairs@ietf.org, tsvwg@ietf.org, The IESG , draft-ietf-tsvwg-rfc4960-errata@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <28888985-EC4F-4CB7-B7CC-C4E6B78839DB@fastmail.fm> References: <153066069383.5123.15949635433835942791.idtracker@ietfa.amsl.com> <059E8CF3-A927-4433-AC24-8D5A20A9734D@fh-muenster.de> To: Michael Tuexen Archived-At: Subject: Re: [tsvwg] Eric Rescorla's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 09:35:24 -0000 Hi Michael, On 4 Jul 2018, at 06:24, Michael Tuexen wrote: >> On 4. Jul 2018, at 01:31, Eric Rescorla wrote: >>=20 >> I agree with Adam and Spencer. This is just an incredibly user-hostile > Not sure if Adam and Spencer are in agreement here... >> presentation of this information, in particular: >>=20 >> Note that when reading this document one must use care to assure that >> a field or item is not updated further on within the document. Since >> this document is a historical record of the sequential changes that >> have been found necessary at various inter-op events and through >> discussion on the list, the last delta in the text is the one which >> should be applied. >>=20 >> This seems like good input to a -bis but should not be published as-is. > So I guess you are suggesting to drop this document and work on an > RFC4960bis instead, because there is no need to document the reasons > for the changes? Just speaking for myself: I prefer the WG just works on the bis without publ= ishing this one. Preserving history of decisions somewhere would be useful, b= ut I think an RFC is going to be a wrong choice here. You can add comments t= o datatracker for the bis, pointing to this draft. This would provide enough= background without requiring extra work from RFC Editor. Best Regards, Alexey= From nobody Wed Jul 4 03:51:05 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FE5130E34; Wed, 4 Jul 2018 03:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 tWKWHp7J_fn9; Wed, 4 Jul 2018 03:50:59 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 801DB126F72; Wed, 4 Jul 2018 03:50:59 -0700 (PDT) Received: from [10.225.63.149] (unknown [194.95.9.240]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 7DBD572106C26; Wed, 4 Jul 2018 12:50:56 +0200 (CEST) From: Michael Tuexen Message-Id: <414CDF0D-8ABC-45AB-8264-D04366F9D5F2@fh-muenster.de> Content-Type: multipart/signed; boundary="Apple-Mail=_E4B35C66-D9DC-40A5-A772-08C07B089C97"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Wed, 4 Jul 2018 12:51:24 +0200 In-Reply-To: <28888985-EC4F-4CB7-B7CC-C4E6B78839DB@fastmail.fm> Cc: Eric Rescorla , Gorry Fairhurst , tsvwg-chairs@ietf.org, tsvwg@ietf.org, The IESG , draft-ietf-tsvwg-rfc4960-errata@ietf.org To: Alexey Melnikov References: <153066069383.5123.15949635433835942791.idtracker@ietfa.amsl.com> <059E8CF3-A927-4433-AC24-8D5A20A9734D@fh-muenster.de> <28888985-EC4F-4CB7-B7CC-C4E6B78839DB@fastmail.fm> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [tsvwg] Eric Rescorla's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 10:51:03 -0000 --Apple-Mail=_E4B35C66-D9DC-40A5-A772-08C07B089C97 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 4. Jul 2018, at 11:49, Alexey Melnikov = wrote: >=20 > Hi Michael, >=20 > On 4 Jul 2018, at 06:24, Michael Tuexen wrote: >=20 >>> On 4. Jul 2018, at 01:31, Eric Rescorla wrote: >>>=20 >>> I agree with Adam and Spencer. This is just an incredibly = user-hostile >> Not sure if Adam and Spencer are in agreement here... >>> presentation of this information, in particular: >>>=20 >>> Note that when reading this document one must use care to assure = that >>> a field or item is not updated further on within the document. = Since >>> this document is a historical record of the sequential changes that >>> have been found necessary at various inter-op events and through >>> discussion on the list, the last delta in the text is the one which >>> should be applied. >>>=20 >>> This seems like good input to a -bis but should not be published = as-is. >> So I guess you are suggesting to drop this document and work on an >> RFC4960bis instead, because there is no need to document the reasons >> for the changes? >=20 > Just speaking for myself: I prefer the WG just works on the bis = without publishing this one. Preserving history of decisions somewhere = would be useful, but I think an RFC is going to be a wrong choice here. = You can add comments to datatracker for the bis, pointing to this draft. = This would provide enough background without requiring extra work from = RFC Editor. OK. In the past people were interested what has changed and why, but = that can change over time. It is not a problem to just work on a RFC 4960bis document and not tie = it to an errata document. The review then has to be based on the new RFC = 4960bis. Thanks for your opinion and guidance. Unfortunately it comes at the = lasted point of time possible. Best regards Michael >=20 > Best Regards, > Alexey --Apple-Mail=_E4B35C66-D9DC-40A5-A772-08C07B089C97 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQkDCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFojCCBIqgAwIBAgIHF6Qk oQlIMzANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTE0MDUyNzE0NTQwOVoXDTE5MDcwOTIzNTkwMFowgcYxCzAJBgNVBAYTAkRFMRwwGgYDVQQIExNO b3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFjaGhvY2hz Y2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxlMR0wGwYD VQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVlbnN0ZXIu ZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eWyu8GzsIv0iowf2v/9BT0SmCFNX /eyQe5BncOk1j6XIlY5bnNu1S5uBe3uVgekgTh3gJyVNlaoIfCgAjqCrNJIaNQq5fr/S6L8uFeaU O8IF/C4RH5P7f9Hn2GUueEjmJhg9CI3LBAhrfAmEEtNmuVfDycN2MjngwDNxUNRfuXbWxuhkgDqJ 0ztJeayHGhFDrGx88eyStx40xy+0c0OFWdWxzBFQlBRHnl+zRftj3c9qy6BY+/fGaA2vV1oKr3h5 X6eyU1T8YlpP1NDe4bylqAteX01sM2Qciu8UAPnNc7Sb93TQjhCFRVDIS3CdN6AOpwz5YWEld6ey CdmFZ7pvAgMBAAGjggH+MIIB+jASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAR BgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFArzW7zkMYDWNUKJptPDzzfe0d/XMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOBEWNhQGZoLW11ZW5zdGVyLmRlMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0 dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDov L2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYI KwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQDeRwM11kpvuRIPuzWXLapr/ZBtB76V3cuF l45x/Kx0u03yjB4GaBPcxihn4P1z5KhRYkDBMo8HXkOgbL59aF6VdOlCurEgZvghKvUkKOCyWeYx S9rTGPBkbGiNn2ATVuLXzF8rDf50ynAIu3otstOOv+3Ifqi1pzCva1nO64khQA5Gd5/BNyu+YHbW f8ERAf9leu5a7yVI7cv1gCZAHpWJpkUKmfawyY4sAJ2hbGZRBvdACOxrfbuMdSOzPneT2rlmvH+D 7M6DmzVabLYk6UtAxQhldd/T/qsHkWvaWXHt0Eb9STs2Fl03Ls7M3NyLQLhaeR3ysNURYcaEfaB+ lxN+MIIGDTCCBPWgAwIBAgIHG5mIdDexozANBgkqhkiG9w0BAQsFADCBxjELMAkGA1UEBhMCREUx HDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQK ExdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVu dHJhbGUxHTAbBgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBm aC1tdWVuc3Rlci5kZTAeFw0xNjA3MDQwNzA2MTNaFw0xOTA3MDQwNzA2MTNaMHwxCzAJBgNVBAYT AkRFMSAwHgYDVQQKDBdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEyMDAGA1UECwwpRmFjaGJlcmVp Y2ggRWxla3Ryb3RlY2huaWsgdW5kIEluZm9ybWF0aWsxFzAVBgNVBAMMDk1pY2hhZWwgVHVleGVu MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzJoaUG3Zm24XxA/zNg2sbFcL56w8xqMg +X6G7UsYec3YEncnlkw3jgE5nDefos7UVoCA7wPjFTj8AQt5xfpXElnbM45IPy5Ng7g6dS7biGSM VRACPXe1PrjgApRAwwGmCPvALnZXkmKP6Zlf+3VLfz9YWIIaeKu3jFM2Lk6Y3gr5U1l8bjHSawOo WMlfvSsXXLT38zKW7Uz9jS278j0OqHANBPgsE6/LJoCWFInwlvybxhO3nGU7OteUGaPikqzvjLsL YgpHDi0WjMZfVx/UtUSzZ4EJvmJTBeuVwyKnCbrawnfwYPTQQ6VE1OkAzmsMByBbEwJ996RtG//T XCG06QIDAQABo4ICRzCCAkMwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGB rSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTQHa9qhKgSZgCCAPThZkXaEaJ/ dTAfBgNVHSMEGDAWgBQK81u85DGA1jVCiabTw8833tHf1zAgBgNVHREEGTAXgRV0dWV4ZW5AZmgt bXVlbnN0ZXIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Zo LW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAz BggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9maC1tdWVuc3Rl ci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAEj2/6x4kzoCVIiu aaminPrOHxACyoYsmSRjYPQpgW5xRj/FlolO1nG+ZZ11sqTb3TdCGD69ko5/zs8eGKnv/i0VLCHF g1JLfpaxElN5RrR/cqRJrbzKshF9aUkBODF8vlf9BCeimMK3fifjbbWRyxHssfEECffujD7/Yvta NYMO46Roz39lIK2s37IVFq3V5RWzUeTuwpP9t8lOxirOi9eK2OYI/dh0HjR2S5Dr9nMR1dNulrhz jlFxGc+opefGScrRR9Ec0eqTXlbt1Q9UzNIYVS+OGZY8/bBbprwXVTmwSp8dygEULkIaMbLsaTaW 6TehuL8ousPJkL52SOENgSkxggQpMIIEJQIBATCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozAJBgUrDgMCGgUAoIICKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xODA3MDQxMDUxMjVaMCMGCSqGSIb3DQEJBDEWBBSGGNSIn0hg3Cc/rOyQ +Nsh5AnInTCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9y ZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2No dWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UE AxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRl AgcbmYh0N7GjMIHlBgsqhkiG9w0BCRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozANBgkqhkiG9w0BAQEFAASCAQAXOJEgcWvER5HBTUdecPWAeGe4M1yCNYPg sjvqBNXqDM0u8VeXM106mEeHS72QAJ7ZZYBqnBAfnbEme56E1KHD43lijtlp+ZuKQiSTkcatAQwl mst9ki5OADrm9jRQAdavD16SpLHKpV9bBxSs8pSzeAcSIbsd2qbJ9OVMpsCeEbLDFp4GAP3y2FoX PNC9bUV+YQD5f792V7dui1AQ2GsyVimZ4DZUZaKEYk+BvpSw4t0N64U4xQrxfNgRi+Z4hovNvV6n gLoLE6HOtprKrLfFkb+csEgbtvOOQA7d7axBr8GFXH3iorE2LZF5ycC1pO+4xwxYhRL240h4Yhgy VIyfAAAAAAAA --Apple-Mail=_E4B35C66-D9DC-40A5-A772-08C07B089C97-- From nobody Wed Jul 4 06:04:31 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F93B130F03 for ; Wed, 4 Jul 2018 06:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 5_TF-ebZr4kM for ; Wed, 4 Jul 2018 06:04:27 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D1D3130F90 for ; Wed, 4 Jul 2018 06:04:10 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id j68-v6so1908533ywg.1 for ; Wed, 04 Jul 2018 06:04:10 -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=BhhylHhqBaliBm+v7MmleHn7yhbsGJgO8r0aOqmrj+w=; b=OKVuJKuCypzC3LKWh0fOXOahRqkjr9Y+jKleoZbytQyewpUDXqouDzxtLzpx3AUMXs 0jgCTa3kDWjqs5ZhZxfzE3oOvv1dbUryMsGcDdy8qgJRlqVH0i1aICOtHAKhXo3BNqso bMcFDeHTGgGTFKHeiBDf0Wn7wvcp3S0u/ZlXDKaPY1UOsIy6Z8in/a2JWLsN1OfBcNR+ osXKzeiG+jId8Ri+YUU7etSxZV0/xNGL8tlSuL21oyEDULOBT8ErvI37Yj7/k2FKpCB+ vWNtXRSLbsCzj8z/pPc+lbjLiPrlvAMTgVsIDzEJQk1wh11djfz3E4ZtcCgJS+ATkyRV zyEg== 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=BhhylHhqBaliBm+v7MmleHn7yhbsGJgO8r0aOqmrj+w=; b=RxSnWKdnt847YXDdCohC8A6E0LqbMTQ2DW6V1OzMZW6uUqndUjjeNQcFR2pmRQx5DA 2IVOl/DIp1w1725D/8RoVQKYCKWAUUfQrkUjTLK4ygGZImiKwAHCjX2/hkBtQEVNIyuE 7OOR1cuj4D478qnA0/Wib7BeI5/4KpYALL43ghGFT7fZeNAQrWOh7HoM28YAob6jUvbv uEcv5lmDgk+eonb0DrKviXMFHB5yIQsI1mobaDVYdytfTFOeYARDAsngspmilpjb46ZE wSqwIkYIMEC0XZ/cuWiehVUndKb0CMASrlY7e6s3I5IiKqx1KaZeWmTAa3w+dgUvaeqY xO0g== X-Gm-Message-State: APt69E2WLcyS1G8rV5Quv9WFmB4z530eBe2y8TXhuNQFUo9yjtHYyPC1 N3bmsQebojWUBVjf4JscY4DfUGqDOi4ZFNcG3rv16PfC X-Google-Smtp-Source: AAOMgpe1VU5GCxGTbOw/fq677DVWILD3HEAAi23FdA0jqmAMlZmAh8NJ5qgCZb9L9xu0qvndf7QWCDcSTTDWZMCqYZk= X-Received: by 2002:a81:3e02:: with SMTP id l2-v6mr884767ywa.381.1530709449656; Wed, 04 Jul 2018 06:04:09 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 06:03:29 -0700 (PDT) In-Reply-To: <059E8CF3-A927-4433-AC24-8D5A20A9734D@fh-muenster.de> References: <153066069383.5123.15949635433835942791.idtracker@ietfa.amsl.com> <059E8CF3-A927-4433-AC24-8D5A20A9734D@fh-muenster.de> From: Eric Rescorla Date: Wed, 4 Jul 2018 06:03:29 -0700 Message-ID: To: Michael Tuexen Cc: The IESG , draft-ietf-tsvwg-rfc4960-errata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, tsvwg@ietf.org Content-Type: multipart/alternative; boundary="00000000000000527605702c11b6" Archived-At: Subject: Re: [tsvwg] Eric Rescorla's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 13:04:29 -0000 --00000000000000527605702c11b6 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 3, 2018 at 10:24 PM, Michael Tuexen wrote: > > > > On 4. Jul 2018, at 01:31, Eric Rescorla wrote: > > > > Eric Rescorla has entered the following ballot position for > > draft-ietf-tsvwg-rfc4960-errata-06: Abstain > > > > 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-tsvwg-rfc4960-errata/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I agree with Adam and Spencer. This is just an incredibly user-hostile > Not sure if Adam and Spencer are in agreement here... > > presentation of this information, in particular: > > > > Note that when reading this document one must use care to assure that > > a field or item is not updated further on within the document. Since > > this document is a historical record of the sequential changes that > > have been found necessary at various inter-op events and through > > discussion on the list, the last delta in the text is the one which > > should be applied. > > > > This seems like good input to a -bis but should not be published as-is. > So I guess you are suggesting to drop this document and work on an > RFC4960bis instead, Yes. because there is no need to document the reasons > for the changes? > I think generally not, though in some specific cases, it might be useful, where it's substantive. -Ekr > Best regards > Michael > > > > > > --00000000000000527605702c11b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jul 3, 2018 at 10:24 PM, Michael Tuexen <<= a href=3D"mailto:tuexen@fh-muenster.de" target=3D"_blank">tuexen@fh-muenste= r.de> wrote:
>
> On 4. Jul 2018, at 01:31, Eric Rescorla <ekr@rtfm.com> wrote:
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-tsvwg-rfc4960-errata-06: Abstain
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/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/<= wbr>doc/draft-ietf-tsvwg-rfc4960-errata/
>
>
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> I agree with Adam and Spencer. This is just an incredibly user-hostile=
Not sure if Adam and Spencer are in agreement here...
> presentation of this information, in particular:
>
>=C2=A0 Note that when reading this document one must use care to assure= that
>=C2=A0 a field or item is not updated further on within the document.= =C2=A0 Since
>=C2=A0 this document is a historical record of the sequential changes t= hat
>=C2=A0 have been found necessary at various inter-op events and through=
>=C2=A0 discussion on the list, the last delta in the text is the one wh= ich
>=C2=A0 should be applied.
>
> This seems like good input to a -bis but should not be published as-is= .
So I guess you are suggesting to drop this document and work on an RFC4960bis instead,

Yes.


because there is no need = to document the reasons
for the changes?

I think generally not,= though in some specific cases, it might be useful, where
it'= s substantive.

-Ekr


Best regards
Michael
>
>


--00000000000000527605702c11b6-- From nobody Wed Jul 4 07:10:36 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0CD130F6C for ; Wed, 4 Jul 2018 07:10:34 -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, 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 (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 b_3_rgPzRCVI for ; Wed, 4 Jul 2018 07:10:32 -0700 (PDT) Received: from pb-smtp1.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E401F130F4C for ; Wed, 4 Jul 2018 07:10:31 -0700 (PDT) Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id A3E74DEFA1 for ; Wed, 4 Jul 2018 10:10:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=QFev5lJS4j0pGPprVLy6a9BrsxQ=; b=fZVLnC O2VexBnM5/8EI+0sGCGWV2OEeqBgJv6la1xuyvZZmRbF9/xiIb1b74OBk0goqOui Pc/HKgxI5A3flcew3v4qXjd9hTm3UlSy6DihHV5fjIhGKZNHHpQOw8vU/oLgx28R +l+9Emrpu9n5BiSUGDOnQ3wHunLUTj4TziT08= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=jVycwGp/KhNBqJMwDJS852JbqcSXabOb uQkrc4k4Lv0PEp0UamYJyHtfMjPj/fiXnVqbVHGLIc7f7sQ6HhdVb3uqssOC9Fgo RPsyIqRB259Dkce+W11YUmTTrNxneqC2GZVHXF9q3+ED27V3MV5VkKSkc/Nr5VdI zSoTnyHxY24= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 9B5FFDEF9E for ; Wed, 4 Jul 2018 10:10:30 -0400 (EDT) Received: from mail-oi0-f48.google.com (unknown [209.85.218.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 17333DEF99 for ; Wed, 4 Jul 2018 10:10:30 -0400 (EDT) Received: by mail-oi0-f48.google.com with SMTP id r16-v6so10986296oie.3 for ; Wed, 04 Jul 2018 07:10:30 -0700 (PDT) X-Gm-Message-State: APt69E1dYTchl0X9Y9A8naPO99IeeP35qa9kYwXitB3rn0ZnApJo4+OJ s2TDiXO6YQ7C+ZGtAMvPCPuMzDZ3hCSogvSObuQ= X-Google-Smtp-Source: AAOMgpdH4bJ2cIC9ahJnVGQXx+Xp0k8gO1RXySRmxbfuVFugx9U+9th28Nxp+VPcRD32K+Jpzj8+zRX0eFP1nQyVPZQ= X-Received: by 2002:aca:61c5:: with SMTP id v188-v6mr2634789oib.28.1530713429501; Wed, 04 Jul 2018 07:10:29 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:cb94:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 07:10:09 -0700 (PDT) In-Reply-To: References: From: "C. M. Heard" Date: Wed, 4 Jul 2018 07:10:09 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Joe Touch Cc: tsvwg Content-Type: multipart/alternative; boundary="00000000000037ed3f05702cfece" X-Pobox-Relay-ID: 020CFD78-7F94-11E8-9C12-0DFB1A68708C-06080547!pb-smtp1.pobox.com Archived-At: Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 14:10:35 -0000 --00000000000037ed3f05702cfece Content-Type: text/plain; charset="UTF-8" On Tue, Jul 3, 2018 at 10:26 PM, C. M. Heard wrote: ... > [Section 5.4, Alternate Checksum (ACS)] does not specify how to construct > the polynomial represent the data to be checksummed. That latter point may > not be entirely obvious. > > In order to re-used existing software used to compute CRC-CCITT, that > polynomial needs to be constructed as if the least significant bit of each > byte is the the coefficient associated with the highest power of x. So, for > example, *0x8b* would correspond to > > x^7 + x^6 + x^4 + 1 > > > and not to > > x^7 + x^3 + x + 1 > > > as one might expect. Here is how one might fully specify the algorithm. Suppose > that there are n bytes of checksummed data, indexed from 0 through n-1 in > order of appearance in the (possibly reassembled) datagram, and P(k,x) is > the polynomial representing the kth byte. Then the polynomial M(x) > representing the data to be checksummed would be the sum, taken from k=0 to > n-1, of x^(8*(n-1-k)) * P(k,x). The ACS option then contains the > remainder upon division (modulo 2) of x^16 * M(x) by the generator > polynomial x^16 + x^12 + x^5 + 1. > That would be the CRC-CCITT calculated using the above bit-ordering convention but without inverting the first 16 bits of checksummed data and without inverting the final final remainder. > I would not belabor such a seemingly trivial point were it not so > vexatious in practice. Maybe you can think of some nice, short, words to > make this point clear. Or maybe there is a suitable stable reference that > has the details, though at this time I am not aware of one. Or maybe I am > in the rough and it really is something that "everyone knows" (but I doubt > that). > There is actually a stable reference, namely Appendix C of RFC 1662. It provides a reference implementation for exact algorithm used by X.25 and HDLC, in which the first 16 bits of checksummed data are inverted prior to the calculation and the final remainder is inverted prior to transmission. It uses the above bit-ordering convention and calculates a 16-bit remainder in which the most significant bit is the coefficient of x^0 and the lest significant bit is the coefficient of x^15. That gets transmitted least significant byte first -- i.e., the opposite way from standard network byte order -- which is necessary for an implementation that processes the message + CRC serially. RFC 5570 relied upon this reference to specify a 16-bit checksum for the CALIPSO IPv6 option: This 16-bit field contains the a CRC-16 checksum as defined in Appendix C of RFC 1662 [RFC1662 ]. The checksum is calculated over the entire CALIPSO option in this packet, including option header, zeroed-out checksum field, option contents, and any required padding zero bits. Unfortunately, this is underspecified with respect to the byte ordering of the checksum field. Erratum 4545 (https://www.rfc-editor.org/errata/eid4545) was filed against RFC 5570 for that reason. We do not want to fall into the same trap of underspecification with the UDP ACS option. I would like to propose the following specific changes to the text: OLD: The Alternate Checksum (ACS) provides a stronger alternative to the UDP header checksum, using a 16-bit CRC of the conventional UDP payload only (excluding the IP pseudoheader, UDP header, and UDP options, and not include the LITE area). It does not include the IP pseudoheader or UDP header, and so need not be updated by NATs when IP addresses or UDP ports are rewritten. Its purpose is to detect errors that the UDP checksum might not detect. CRC-CCITT (polynomial x^16 + x^12 + x^5 + x) has been chosen because of its ubiquity and use in other packet protocols, such as X.25, HDLC, and Bluetooth. The option contains the remainder of the calculation of the polynomial over the UDP payload data (i.e., not inverted). NEW: The Alternate Checksum (ACS) provides a stronger alternative to the checksum in the UDP header, using a 16-bit CRC of the conventional UDP payload only (excluding the IP pseudoheader, UDP header, and UDP options, and not include the LITE area). Since it does not include the IP pseudoheader or the UDP header, it need not be updated by NATs when IP addresses or UDP ports are rewritten. Its purpose is to detect errors that the UDP checksum might not detect. CRC-CCITT (polynomial x^16 + x^12 + x^5 + 1) has been chosen because of its ubiquity and use in other packet protocols, such as X.25, HDLC, and Bluetooth. The option contains the CRC-16 calculated in the manner defined in Appendix C of RFC 1662 [RFC1662 ], except that it is not inverted and is stored in network byte order. If you want to exclude the inversion of the first two bytes of checksummed data, that could be done also. There is no particular technical reason for one choice versus another; I picked the option that takes fewer words to specify. Sorry that it took so many words for me to get to this point. Mike Heard --00000000000037ed3f05702cfece Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 3, 2018 at 10:26 PM= , C. M. Heard wrote:
...
[Section 5.4, Alternate Checksum (ACS)]=C2=A0does not specify ho= w to construct the polynomial represent the data to be checksummed. That la= tter point may not be entirely obvious.

In order to re-used existing = software used to compute CRC-CCITT, that polynomial needs to be constructed= as if the least significant bit of each byte is the the coefficient associ= ated with the highest power of x. So, for example,=C2=A00x8b=C2=A0wo= uld correspond to

x^7 + x^6 =C2=A0+ x^4 + 1

and not to

x^7=C2=A0+ x^3=C2=A0+ x =C2=A0+ 1=

as one might expect. Here is how one might= fully specify the algorithm.=C2=A0Suppose that there are n bytes of checksummed data, indexed fr= om 0 through n-1 in order of appearance in the (possibly reassembled) datag= ram, and P(k,x) is the polynomial representing the kth byte. Then the polyn= omial M(x) representing the data to be checksummed would be the sum, taken = from k=3D0 to n-1, of=C2=A0x^(8*(n-1-k)) * P(k,x). The ACS option then contains=C2=A0the remainder= upon division (modulo 2) of=C2=A0x^16 * M(x) =C2=A0by the generator polynomial=C2= =A0x^16 + x^12 = + x^5 + 1.
<= br>
That would be the CRC-CCITT calculated using the above bit-or= dering convention but=C2=A0without=C2=A0inverting the first 16 bits of chec= ksummed data and without inverting the final final remainder.
=C2= =A0
I would not belabor such a seemingly trivial point wer= e it not so vexatious in practice.=C2=A0Maybe you can think of some nice, short, words to = make this point clear. Or maybe there is a suitable=C2=A0stable reference that has the det= ails, though at this time I am not aware of one. Or maybe I am in the rough= and it really is something that "everyone knows" (but I doubt th= at).

There is actually a stabl= e reference, namely Appendix C of RFC 1662. It provides a reference impleme= ntation for exact algorithm used by X.25 and HDLC, in which the first 16 bi= ts of checksummed data are inverted prior to the calculation and the final = remainder is inverted prior to transmission. It uses the above bit-ordering= convention and calculates a 16-bit remainder in which the most significant= bit is the coefficient of x^0 and the lest significant bit is the coeffici= ent of x^15. That gets transmitted least significant byte first -- i.e., th= e opposite way from standard network byte order -- which is necessary for a= n implementation that processes the message + CRC serially.

<= /div>
RFC 5570 relied upon this reference to specify a 16-bit checksum = for the CALIPSO IPv6 option:

   This 16-bit field contains the a C=
RC-16 checksum as defined in
   Appendix=C2=
=A0C of RFC 1662 [RFC1662].  The checksum is ca=
lculated over
   the entire CALIPSO option in this packet, including option header,
   zeroed-out checksum field, option contents, and any required padding
   zero bits.

Unfortunately, this is undersp= ecified with respect to the byte ordering of the checksum field. Erratum 45= 45 (https://www.rfc-e= ditor.org/errata/eid4545)=C2=A0was filed against RFC 5570 for that reas= on. We do not want to fall into the same trap of underspecification with th= e UDP ACS option.

I would like to propose the foll= owing specific changes to the text:

OLD:
   The Alternat=
e Checksum (ACS) provides a stronger alternative to the
   UDP header checksum, using a 16-bit CRC of the conventional UDP
   payload only (excluding the IP pseudoheader, UDP header, and UDP
   options, and not include the LITE area). It does not include the IP
   pseudoheader or UDP header, and so need not be updated by NATs when
   IP addresses or UDP ports are rewritten. Its purpose is to detect
   errors that the UDP checksum might not detect. CRC-CCITT (polynomial
   x^16 + x^12 + x^5 + x) has been chosen because of its ubiquity and
   use in other packet protocols, such as X.25, HDLC, and Bluetooth.
   The option contains the =
remainder of the calculation of the
   polynomial over the UDP payload data (i.e., not inverted).


NEW:
   The Alternate Checksu=
m (ACS) provides a stronger alternative to the
   checksum in the UDP header=
, using a 16-bit CRC of the conventional
   UDP payload only (excluding the IP pseudoheader, UDP header, and UDP
   options, and not include the LITE area). Since it does not include
   the IP pseudoheader or the=
 UDP header, it=
 need not be updated by NATs
   when IP addresses or UDP ports are rewritten. Its purpose is to detect
   errors that the UDP checksum might not detect. CRC-CCITT (polynomial
   x^16 + x^12 + x^5 + 1) has been chosen because of its ubiquity and
   use in other packet protocols, such as X.25, HDLC, and Bluetooth.
   The option contains the CRC-16 calculated in the manner def=
ined in
   Appendix=C2=
=A0C of RFC 1662 [RFC1662], except that it is n=
ot inverted
   and is stored in network byte order.

If you want to exclude the inversion of the first two bytes = of checksummed data, that could be done also. There is no particular techni= cal reason for one choice versus another; I picked the option that takes fe= wer words to specify. Sorry that it took so many words for me to get to thi= s point.

Mike Heard
--00000000000037ed3f05702cfece-- From nobody Wed Jul 4 12:50:27 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F0C131095; Wed, 4 Jul 2018 12:50:20 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 8610B4k0nz4M; Wed, 4 Jul 2018 12:50:17 -0700 (PDT) Received: from mail.mera.ru (mail.mera.ru [188.130.168.162]) (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 0DB7D130DD3; Wed, 4 Jul 2018 12:50:17 -0700 (PDT) Received: from cmail.merann.ru ([192.168.50.72]) by mail.mera.ru with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (envelope-from ) id 1fanly-000Gse-II; Wed, 04 Jul 2018 22:49:06 +0300 Received: from e16srv02.merann.ru (192.168.50.32) by cmail.merann.ru (192.168.50.72) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 4 Jul 2018 22:50:05 +0300 Received: from e16srv03.merann.ru (2001:67c:2344:50::33) by e16srv02.merann.ru (2001:67c:2344:50::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.845.34; Wed, 4 Jul 2018 22:50:04 +0300 Received: from e16srv03.merann.ru ([fe80::55f8:ff7c:1a00:7a7d]) by e16srv03.merann.ru ([fe80::55f8:ff7c:1a00:7a7d%12]) with mapi id 15.01.0845.039; Wed, 4 Jul 2018 22:50:05 +0300 From: "Proshin, Maksim" To: Eric Rescorla , Michael Tuexen CC: Gorry Fairhurst , "tsvwg-chairs@ietf.org" , "tsvwg@ietf.org" , The IESG , "draft-ietf-tsvwg-rfc4960-errata@ietf.org" Thread-Topic: [tsvwg] Eric Rescorla's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) Thread-Index: AQHUEyYPylUgMba5oUC0U8bPKFJlmKR+VhqAgACAHYCAAJ2rJg== Date: Wed, 4 Jul 2018 19:50:05 +0000 Message-ID: <115bf219e0fc4c3993e983914de37185@mera.ru> References: <153066069383.5123.15949635433835942791.idtracker@ietfa.amsl.com> <059E8CF3-A927-4433-AC24-8D5A20A9734D@fh-muenster.de>, In-Reply-To: Accept-Language: en-US, ru-RU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [95.79.9.158] x-inside-org: True Content-Type: multipart/alternative; boundary="_000_115bf219e0fc4c3993e983914de37185meraru_" MIME-Version: 1.0 X-Src-IF-Name: mail.mera.ru Archived-At: Subject: Re: [tsvwg] Eric Rescorla's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 19:50:21 -0000 --_000_115bf219e0fc4c3993e983914de37185meraru_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, As one of SCTP developers I can confirm that such document is really useful= . When we were applying RFC4960 to our implementation of RFC2960, we active= ly used RFC4460. The most important benefit of the documents such as RFC446= 0 and the current drat is that they explain why a change is needed and why = a particular solution was chosen which makes developers decisions easier. Also I know that some developers are already using this draft to improve th= eir implementations. Of course, they might need minor corrections when the = RFCbis is published but they already now can benefit from this work. An alternative approach could be to incorporate this draft in RFCbis docume= nt as an abstract section but that will seriously enlarge the size of the d= ocument. BR, Maxim ________________________________ From: tsvwg on behalf of Eric Rescorla Sent: Wednesday, July 4, 2018 4:03 PM To: Michael Tuexen Cc: Gorry Fairhurst; tsvwg-chairs@ietf.org; tsvwg@ietf.org; The IESG; draft= -ietf-tsvwg-rfc4960-errata@ietf.org Subject: Re: [tsvwg] Eric Rescorla's Abstain on draft-ietf-tsvwg-rfc4960-er= rata-06: (with COMMENT) On Tue, Jul 3, 2018 at 10:24 PM, Michael Tuexen > wrote: > > On 4. Jul 2018, at 01:31, Eric Rescorla > wrote: > > Eric Rescorla has entered the following ballot position for > draft-ietf-tsvwg-rfc4960-errata-06: Abstain > > 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-tsvwg-rfc4960-errata/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with Adam and Spencer. This is just an incredibly user-hostile Not sure if Adam and Spencer are in agreement here... > presentation of this information, in particular: > > Note that when reading this document one must use care to assure that > a field or item is not updated further on within the document. Since > this document is a historical record of the sequential changes that > have been found necessary at various inter-op events and through > discussion on the list, the last delta in the text is the one which > should be applied. > > This seems like good input to a -bis but should not be published as-is.. So I guess you are suggesting to drop this document and work on an RFC4960bis instead, Yes. because there is no need to document the reasons for the changes? I think generally not, though in some specific cases, it might be useful, w= here it's substantive. -Ekr Best regards Michael > > --_000_115bf219e0fc4c3993e983914de37185meraru_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,


As one of SCTP developers I can confirm that such document is really use= ful. When we were applying RFC4960 to our implementation of RFC2960, w= e actively used RFC4460. The most important benefit of the docume= nts such as RFC4460 and the current drat is that they explain why a change is needed and why a particular solution was= chosen which makes developers decisions easier. 


Also I know that some developers are already using this draft to im= prove their implementations. Of course, they might need minor corrections w= hen the RFCbis is published but they already now can benefit from this work= . 


An alternative approach could be to incorporate this draft in RFCbis docume= nt as an abstract section but that will seriously enlarge the size of the d= ocument.

BR, Maxim


From: tsvwg <tsvwg-bounc= es@ietf.org> on behalf of Eric Rescorla <ekr@rtfm.com>
Sent: Wednesday, July 4, 2018 4:03 PM
To: Michael Tuexen
Cc: Gorry Fairhurst; tsvwg-chairs@ietf.org; tsvwg@ietf.org; The IESG= ; draft-ietf-tsvwg-rfc4960-errata@ietf.org
Subject: Re: [tsvwg] Eric Rescorla's Abstain on draft-ietf-tsvwg-rfc= 4960-errata-06: (with COMMENT)
 


On Tue, Jul 3, 2018 at 10:24 PM, Michael Tuexen = <tuexen@fh-mu= enster.de> wrote:
>
> On 4. Jul 2018, at 01:31, Eric Rescorla <ekr@rtfm.com> wrote:
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-tsvwg-rfc4960-errata-06: Abstain
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> 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-tsvwg-rfc4960-errata/=
>
>
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> I agree with Adam and Spencer. This is just an incredibly user-hostile=
Not sure if Adam and Spencer are in agreement here...
> presentation of this information, in particular:
>
>  Note that when reading this document one must use care to assure= that
>  a field or item is not updated further on within the document.&n= bsp; Since
>  this document is a historical record of the sequential changes t= hat
>  have been found necessary at various inter-op events and through=
>  discussion on the list, the last delta in the text is the one wh= ich
>  should be applied.
>
> This seems like good input to a -bis but should not be published as-is= ..
So I guess you are suggesting to drop this document and work on an RFC4960bis instead,

Yes.


because there is no need to document the reasons
for the changes?

I think generally not, though in some specific cases, it might be usef= ul, where
it's substantive.

-Ekr


Best regards
Michael
>
>


--_000_115bf219e0fc4c3993e983914de37185meraru_-- From nobody Wed Jul 4 13:00:32 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA8FF131095; Wed, 4 Jul 2018 13:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwTvFhyD8IkF; Wed, 4 Jul 2018 13:00:20 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 3E6FD130DD6; Wed, 4 Jul 2018 13:00:20 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w64JxGkc062743 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 4 Jul 2018 14:59:17 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Michael Tuexen Cc: Gorry Fairhurst , tsvwg-chairs@ietf.org, tsvwg@ietf.org, The IESG , draft-ietf-tsvwg-rfc4960-errata@ietf.org References: <153065022701.5099.10852319899819966685.idtracker@ietfa.amsl.com> <6030538E-9108-4DBA-A8BE-0CE604BFE9D9@fh-muenster.de> From: Adam Roach Message-ID: <1ebab249-4e1e-72a2-9226-5d561837b19e@nostrum.com> Date: Wed, 4 Jul 2018 14:59:16 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <6030538E-9108-4DBA-A8BE-0CE604BFE9D9@fh-muenster.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [tsvwg] Adam Roach's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 20:00:24 -0000 On 7/4/18 12:19 AM, Michael Tuexen wrote: > >> On 3. Jul 2018, at 22:37, Adam Roach wrote: >> >> Adam Roach has entered the following ballot position for >> draft-ietf-tsvwg-rfc4960-errata-06: Abstain >> >> 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-tsvwg-rfc4960-errata/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I agree with Ben (and, transitively, the OPSDIR an GENART reviewers). From my >> reading, this document -- while immensely valuable to the working group for >> creation of an RFC 4960 bis document -- has little archival value. The following >> standing guidance from the IESG would seem to be applicable: >> >> https://www.ietf.org/blog/support-documents-ietf-working-groups/ >> >> Like Ben, I'm abstaining on this document. I would ask the working group to >> consider not publishing it in this form, and waiting until a complete bis >> version of the document can be produced. > Just to get a better understanding of your position: > > Are you suggesting either > > (1) To work on RFC4960-bis and once that gets published, publish an RFC4960-errata > which is consistent with RFC4960-bis at a later time. > > or > > (2) To work on RFC4960-bis and just drop this document since there is no archival > value for the reasons why something has changed. Having the changed version > is the important point. I'm suggesting something close to (2), which I hoped the link to https://www.ietf.org/blog/support-documents-ietf-working-groups/ would make clear. /a From nobody Wed Jul 4 19:34:26 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A2093130D7A; Wed, 4 Jul 2018 19:34:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Terry Manderson To: "The IESG" Cc: draft-ietf-tsvwg-rfc4960-errata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, gorry@erg.abdn.ac.uk, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153075805965.27340.4527070242181524910.idtracker@ietfa.amsl.com> Date: Wed, 04 Jul 2018 19:34:19 -0700 Archived-At: Subject: [tsvwg] Terry Manderson's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 02:34:20 -0000 Terry Manderson has entered the following ballot position for draft-ietf-tsvwg-rfc4960-errata-06: Abstain 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-tsvwg-rfc4960-errata/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I appreciate and recognise the WG's desire to highlight the number of issues that need to be correctioned in RFC 4960. I urge the WG to select an alternative way to keep track of these concerns in leading toward a -bis. Archiving the enumerated list doesn't to me seem like an ideal way forward. Adam has provided a URL of previous advice that the WG should consider. I am, therefore, abstaining. From nobody Wed Jul 4 21:00:09 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7BC131053; Wed, 4 Jul 2018 20:59:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-tsvwg-rfc4960-errata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, gorry@erg.abdn.ac.uk, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153076319986.27384.9856169936302827044.idtracker@ietfa.amsl.com> Date: Wed, 04 Jul 2018 20:59:59 -0700 Archived-At: Subject: [tsvwg] Benjamin Kaduk's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 04:00:06 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-tsvwg-rfc4960-errata-06: Abstain 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-tsvwg-rfc4960-errata/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The reasons for my Abstain vs. No Objection are covered in the other Abstain positions' descriptions. In particular, the "user-unfriendliness" aspect; e.g., in my notes, I was going to suggest switching the example CRC code to using fixed-width types, and had to wait until basically the end of the document to see that this was already done. I did take some notes while reviewing the document, though: Section 3.14.2 (new text) When its peer is multi-homed, an endpoint SHOULD send fast retransmissions to the same destination transport address where the original data was sent to. If the primary path has been changed and the original data was sent there before the fast retransmit, the implementation MAY send it to the new primary path. What is "there"? Section 3.35.2 There seem to be two instances of "Old Text" for the same outline of text; presumably the second one is supposed to be "New Text". Section 3.36.2 The ICMP3 change goes both from "MAY ignore" to "SHOULD ignore" and from "code does not indicate" to "code indicates", which is qualitatively a large change. There are 13 code values that are not mentioned in either old or new text, and the supporting problem/solution descriptions don't do very much to explain the change for these 13 codes. Section 3.40.2 Is ECN really still a "proposed extension to IP", or a realized extension? From nobody Thu Jul 5 05:41:06 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF26130E31 for ; Thu, 5 Jul 2018 05:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 93ybcTm8DpfG for ; Thu, 5 Jul 2018 05:41:01 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 943C31277BB for ; Thu, 5 Jul 2018 05:41:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1530794458; 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=cLyaUei0AaMEzxenbrfNwKGRfk3fdELyV7Y93Tsel2c=; b=Ty+8oneaNEjPLWt2JJzZZhlpTRaOdl4YdWMN0ihSOjHbfiVnULzwKDM5zR+nGMfC QajtFo21jGEOxdOKTC/4nzZglNSZbYYGTtOCmpLiuPJ3ErANvwG0PNJSMjoHp0bt 0NjP3LsbvdcKaMub9vCN6UOzGJtlXQZSYoaVeqz98h0=; X-AuditID: c1b4fb3a-9e9ff700000079c1-ad-5b3e11dac655 Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 64.B3.31169.AD11E3B5; Thu, 5 Jul 2018 14:40:58 +0200 (CEST) Received: from [147.214.163.236] (153.88.183.153) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 5 Jul 2018 14:40:58 +0200 To: tsvwg IETF list From: Magnus Westerlund Message-ID: <6f8ee7ac-9318-b4ab-626c-a3a36acba042@ericsson.com> Date: Thu, 5 Jul 2018 14:40:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------230E040F632298E1AB6D2E84" Content-Language: en-GB X-Originating-IP: [153.88.183.153] X-ClientProxiedBy: ESESBMB503.ericsson.se (153.88.183.170) To ESESSMB502.ericsson.se (153.88.183.163) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM2J7he4tQbtog9O7LCyOvbnL5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJuzVzEVzG5mrPj7N6qBcWpGFyMnh4SAicS/uYfZuxi5OIQE jjJKHJi2kQXC+cAo8erCFUaQKhEBFYkvK7vYQWw2AQuJmz8a2UBsYQEjiRk3D4PV8ArYS9z8 /gWohoODBai+8aErSFhUIEZi9cbL7BAlghInZz5hAbGZBcIkem/dYYawxSWavqxkBbGFBLQl Gpo6WCGOU5K4Pu86C4SdLrHs/SHGCYz8s5CMmoVk1Cwko2YBXcEMdNGDrWUQYXmJ7W/nQJXo S1y/c58VJt68dTbzAkb2VYyixanFxbnpRkZ6qUWZycXF+Xl6eaklmxiBgXxwy2+rHYwHnzse YhTgYFTi4ZVgtIsWYk0sK67MPcQowcGsJMIrzAwU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuuU ZhElJJCeWJKanZpakFoEk2Xi4JRqYPR9YqY6r44vOfjX2+CGpFjr6e8t8jPbD719ED73SZVH g9yU6wW71VP+TrmnV+T3Z1OG3Knvtnz3Jtieai5YfOWxQlBq1Kn6PdNeXDf0Ej023bFcNOjG KfnMveLJEQnb2CMX5tafLTO0514ivktk0oLmw1dL3JdFGbzatm7DiyyL79KXyy5ErFViKc5I NNRiLipOBAAfqhj1YAIAAA== Archived-At: Subject: [tsvwg] Experience and Status of ECN in QUIC work X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 12:41:04 -0000 --------------230E040F632298E1AB6D2E84 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit TSVWG, ECN support was added to QUIC in the latest draft versions (-13). The relevant documents that include ECN related text are: https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/ The inclusion of ECN in QUIC can be summarized as. Each sender performs initial verification when the connection is established or migrated by setting ECT on the packets it send. The receiver will report if it sees ECN marks, i.e. any value other than not-ECT, using a new acknowledgement frame type (ACK_ECN) that includes counters of how many packets with the various markings the receiver have seen since connection establishment. If the receiver gets not-ECT or can't read ECN marks then it uses the ACK frame to report these packets so that the sender can learn of the lack of ECT capability and turn its marking off. Marking consistency are continuously verified. ECN black hole mitigation is discussed and a possible mechanism is that any RTO will result in retransmission without ECT marks. The inclusion of ECN in QUIC has so far been fairly well discussed. Initially by the design team. Then at the QUIC interim meeting in June, followed by a lot of discussion of the actual text proposal on github. Thanks to everyone that engaged. Based on these discussions there are some questions and experience that I have noticed that is worth spreading and discussing. This is also the topics coming in the TSVWG session for my agenda item. Also I don't believe the last word is said about details of how ECN in QUIC is realized. There are currently three different github issues related to ECN: - Improve ACK_ECN frame encoding (e.g., use bit-vector) (https://github.com/quicwg/base-drafts/issues/1439) - Fragility in ECN counters with lost acks (https://github.com/quicwg/base-drafts/issues/1481) - Detect adversarial ECN reporting (https://github.com/quicwg/base-drafts/issues/1426) So the things I want to bring to attention are: A. Suppression of ECN values in packet duplicates In QUIC the drafts currently says that a receiver should suppress the ECN values received in any packet duplicates. The main reason for that is to mitigate a potential active attack by a off-path attacker that has some capability to receive a copy of the packets of the target flow. We call it an on-the-side attack. By taking a copy of a legit packet, and changing the ECN field to ECN-CE and then forward the modified copy to the intended receiver one can perform a denial of service attack by driving down the congestion window. To mitigate this, the recommendation is to care about only the first arrived packet. This forces an on-the-side attacker to be able to race their attack packets with the original packet. The downside of this is of course that an actual network duplication where none-first packets gets marked as ECN-CE after the duplication we ignore the congestion signal. My personal standpoint is that this is okay. If not the first packet was marked then congestion may not be so bad that it is a problem if the duplication don't happens. Secondly, if it is any persistent congestion then this flow will be marked in a later packet. There was some disagreement on this so I think it is worth more discussion. B. Will ECT(0) and ECT(1) be mixed in one packet flow? In the discussions around optimizing how the ECN information reported from receiver to sender this question arose. If one can make assumption that within a connection one will use only one of the ECT codepoints then we can optimize the reporting based on that assumption. So how safe is this assumption? And in this case, what is the importance of being able to detect ECT codepoint remarking, i.e. changing between 0 and 1 in either direction? C. Detecting Cheating Receivers As there are some risks in certain deployment situations that the receiver would have an incentive to lie about if an ECN-CE mark was received or not to gain throughput. A sender could detect this case by sending packets marked as ECN-CE to verify that receiver reports these packets are being marked. As the sender will ignore the ECN-CE marks it self generated there is a risk that these marks hide real CE marks. Thus, the general question is how often, at most, should a sender mark with ECN-CE? D. Delayed Acknowledgement and ECN We also have an interesting discussion around ECN, Delayed Acknowledgement and the interaction with recovery period. QUIC supports delayed acknowledgement. So far there are quite a lot of implementer freedom of how to use this. What is currently specified is that when receiving an ECN-CE mark the receiver sends an immediate ACK, so get rapid response to the congestion signal. When the ACK_ECN reaches the sender it will go into Recovery until a packet sent after entering recovery has been acknowledged. During recovery as the congestion window already is reduced and frozen the reception of additional ECN-CE marks (at least for the current congestion control mechanism) is not that important. What is important is if any packets are ECN-CE marked when exiting recovery. Marks on packets sent after recovery should result in a new congestion event and new recovery period. To resolve this the current requirement is to immediately acknowledge each ECN-CE marks. This will result in some additional acknowledgements. There has been some discussion if one want to optimize this case or if it is not worth it. One direction was to ensure that even with delayed ACKs one get frequent enough acknowledgements. This resulted in discussion in the direction of ensuring that the longest delay before acknowledging is caped at a quarter of the RTT. That way one achieve no worse than quarter RTT resolution on the ECN-CE marks. Another potential direction is explicit indication of which packet numbers that would resolve this uncertainty. Then also exists the question if the receiver needs any indication of recovery periods to optimize the acknowledgements. E. Utility of detailed CE information As there has been discussion about explicitly indicate which packet numbers was marked as CE, it is also good to understand if there are any significant utility of having this information for the sender compared to what the counters provide. I assume this goes into the potential for congestion control mechanism evolution. But, does it matter for example for L4S? Cheers Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------230E040F632298E1AB6D2E84 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit

TSVWG,

ECN support was added to QUIC in the latest draft versions (-13). The relevant documents that include ECN related text are:

https://datatracker.ietf.org/doc/draft-ietf-quic-transport/
https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/

The inclusion of ECN in QUIC can be summarized as. Each sender performs initial verification when the connection is established or migrated by setting ECT on the packets it send. The receiver will report if it sees ECN marks, i.e. any value other than not-ECT, using a new acknowledgement frame type (ACK_ECN) that includes counters of how many packets with the various markings the receiver have seen since connection establishment. If the receiver gets not-ECT or can't read ECN marks then it uses the ACK frame to report these packets so that the sender can learn of the lack of ECT capability and turn its marking off. Marking consistency are continuously verified. ECN black hole mitigation is discussed and a possible mechanism is that any RTO will result in retransmission without ECT marks.

The inclusion of ECN in QUIC has so far been fairly well discussed. Initially by the design team. Then at the QUIC interim meeting in June, followed by a lot of discussion of the actual text proposal on github. Thanks to everyone that engaged. Based on these discussions there are some questions and experience that I have noticed that is worth spreading and discussing. This is also the topics coming in the TSVWG session for my agenda item.

Also I don't believe the last word is said about details of how ECN in QUIC is realized. There are currently three different github issues related to ECN:

- Improve ACK_ECN frame encoding (e.g., use bit-vector) (https://github.com/quicwg/base-drafts/issues/1439)
- Fragility in ECN counters with lost acks (https://github.com/quicwg/base-drafts/issues/1481)
- Detect adversarial ECN reporting (https://github.com/quicwg/base-drafts/issues/1426)

So the things I want to bring to attention are:


A. Suppression of ECN values in packet duplicates

In QUIC the drafts currently says that a receiver should suppress the ECN values received in any packet duplicates. The main reason for that is to mitigate a potential active attack by a off-path attacker that has some capability to receive a copy of the packets of the target flow. We call it an on-the-side attack. By taking a copy of a legit packet, and changing the ECN field to ECN-CE and then forward the modified copy to the intended receiver one can perform a denial of service attack by driving down the congestion window. To mitigate this, the recommendation is to care about only the first arrived packet. This forces an on-the-side attacker to be able to race their attack packets with the original packet.

The downside of this is of course that an actual network duplication where none-first packets gets marked as ECN-CE after the duplication we ignore the congestion signal. My personal standpoint is that this is okay. If not the first packet was marked then congestion may not be so bad that it is a problem if the duplication don't happens. Secondly, if it is any persistent congestion then this flow will be marked in a later packet. There was some disagreement on this so I think it is worth more discussion.


B. Will ECT(0) and ECT(1) be mixed in one packet flow?

In the discussions around optimizing how the ECN information reported from receiver to sender this question arose. If one can make assumption that within a connection one will use only one of the ECT codepoints then we can optimize the reporting based on that assumption. So how safe is this assumption? And in this case, what is the importance of being able to detect ECT codepoint remarking, i.e. changing between 0 and 1 in either direction?


C. Detecting Cheating Receivers

As there are some risks in certain deployment situations that the receiver would have an incentive to lie about if an ECN-CE mark was received or not to gain throughput. A sender could detect this case by sending packets marked as ECN-CE to verify that receiver reports these packets are being marked. As the sender will ignore the ECN-CE marks it self generated there is a risk that these marks hide real CE marks. Thus, the general question is how often, at most, should a sender mark with ECN-CE?


D. Delayed Acknowledgement and ECN

We also have an interesting discussion around ECN, Delayed Acknowledgement and the interaction with recovery period. QUIC supports delayed acknowledgement. So far there are quite a lot of implementer freedom of how to use this. What is currently specified is that when receiving an ECN-CE mark the receiver sends an immediate ACK, so get rapid response to the congestion signal. When the ACK_ECN reaches the sender it will go into Recovery until a packet sent after entering recovery has been acknowledged. During recovery as the congestion window already is reduced and frozen the reception of additional ECN-CE marks (at least for the current congestion control mechanism) is not that important. What is important is if any packets are ECN-CE marked when exiting recovery. Marks on packets sent after recovery should result in a new congestion event and new recovery period. To resolve this the current requirement is to immediately acknowledge each ECN-CE marks. This will result in some additional acknowledgements.

There has been some discussion if one want to optimize this case or if it is not worth it. One direction was to ensure that even with delayed ACKs one get frequent enough acknowledgements. This resulted in discussion in the direction of ensuring that the longest delay before acknowledging is caped at a quarter of the RTT. That way one achieve no worse than quarter RTT resolution on the ECN-CE marks. Another potential direction is explicit indication of which packet numbers that would resolve this uncertainty. Then also exists the question if the receiver needs any indication of recovery periods to optimize the acknowledgements.

E. Utility of detailed CE information

As there has been discussion about explicitly indicate which packet numbers was marked as CE, it is also good to understand if there are any significant utility of having this information for the sender compared to what the counters provide. I assume this goes into the potential for congestion control mechanism evolution. But, does it matter for example for L4S?


Cheers 

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------
--------------230E040F632298E1AB6D2E84-- From nobody Thu Jul 5 05:44:48 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B85130ED4; Thu, 5 Jul 2018 05:44:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-tsvwg-rfc4960-errata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, gorry@erg.abdn.ac.uk, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153079467561.11318.9631100600931048176.idtracker@ietfa.amsl.com> Date: Thu, 05 Jul 2018 05:44:35 -0700 Archived-At: Subject: [tsvwg] Alissa Cooper's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 12:44:47 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-tsvwg-rfc4960-errata-06: Abstain 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-tsvwg-rfc4960-errata/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with the Gen-ART reviewer and the other ADs who have abstained on this document. I see why the WG wants this documented, but it doesn't appear to need to be documented in an RFC. From nobody Thu Jul 5 06:43:33 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7AF130E2A; Thu, 5 Jul 2018 06:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1KMXXID24yJ; Thu, 5 Jul 2018 06:43:21 -0700 (PDT) Received: from mail.mera.ru (mail.mera.ru [188.130.168.162]) (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 E3BA0130E3B; Thu, 5 Jul 2018 06:43:20 -0700 (PDT) Received: from mbx03.merann.ru ([192.168.50.73]) by mail.mera.ru with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) (envelope-from ) id 1fb4WL-000CEx-DQ; Thu, 05 Jul 2018 16:42:05 +0300 Received: from e16srv01.merann.ru (192.168.50.31) by mbx03.merann.ru (192.168.50.73) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 5 Jul 2018 16:43:05 +0300 Received: from e16srv03.merann.ru (2001:67c:2344:50::33) by e16srv01.merann.ru (2001:67c:2344:50::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.845.34; Thu, 5 Jul 2018 16:43:05 +0300 Received: from e16srv03.merann.ru ([fe80::55f8:ff7c:1a00:7a7d]) by e16srv03.merann.ru ([fe80::55f8:ff7c:1a00:7a7d%12]) with mapi id 15.01.0845.039; Thu, 5 Jul 2018 16:43:05 +0300 From: "Proshin, Maksim" To: Adam Roach , Michael Tuexen CC: Gorry Fairhurst , The IESG , "draft-ietf-tsvwg-rfc4960-errata@ietf.org" , "tsvwg-chairs@ietf.org" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] Adam Roach's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) Thread-Index: AQHUEw2yJGNY++XcC0+g6+w6kiFHFaR+VMSAgAD1zwCAAVmf+Q== Date: Thu, 5 Jul 2018 13:43:05 +0000 Message-ID: References: <153065022701.5099.10852319899819966685.idtracker@ietfa.amsl.com> <6030538E-9108-4DBA-A8BE-0CE604BFE9D9@fh-muenster.de>, <1ebab249-4e1e-72a2-9226-5d561837b19e@nostrum.com> In-Reply-To: <1ebab249-4e1e-72a2-9226-5d561837b19e@nostrum.com> Accept-Language: en-US, ru-RU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [5.164.245.232] x-inside-org: True Content-Type: multipart/alternative; boundary="_000_c1029fed68bc49e0b03d0d9e0c35fd57meraru_" MIME-Version: 1.0 X-Src-IF-Name: mail.mera.ru Archived-At: Subject: Re: [tsvwg] Adam Roach's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 13:43:25 -0000 --_000_c1029fed68bc49e0b03d0d9e0c35fd57meraru_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Adam, I guess support documents are never published. How they could be found and = used by developers who are not closely involved in WG work? BR, Maxim ________________________________ From: tsvwg on behalf of Adam Roach Sent: Wednesday, July 4, 2018 10:59:16 PM To: Michael Tuexen Cc: Gorry Fairhurst; The IESG; draft-ietf-tsvwg-rfc4960-errata@ietf.org; ts= vwg-chairs@ietf.org; tsvwg@ietf.org Subject: Re: [tsvwg] Adam Roach's Abstain on draft-ietf-tsvwg-rfc4960-errat= a-06: (with COMMENT) On 7/4/18 12:19 AM, Michael Tuexen wrote: > >> On 3. Jul 2018, at 22:37, Adam Roach wrote: >> >> Adam Roach has entered the following ballot position for >> draft-ietf-tsvwg-rfc4960-errata-06: Abstain >> >> 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.htm= l >> 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-tsvwg-rfc4960-errata/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I agree with Ben (and, transitively, the OPSDIR an GENART reviewers). Fr= om my >> reading, this document -- while immensely valuable to the working group = for >> creation of an RFC 4960 bis document -- has little archival value. The f= ollowing >> standing guidance from the IESG would seem to be applicable: >> >> https://www.ietf.org/blog/support-documents-ietf-working-groups/ >> >> Like Ben, I'm abstaining on this document. I would ask the working group= to >> consider not publishing it in this form, and waiting until a complete bi= s >> version of the document can be produced. > Just to get a better understanding of your position: > > Are you suggesting either > > (1) To work on RFC4960-bis and once that gets published, publish an RFC49= 60-errata > which is consistent with RFC4960-bis at a later time. > > or > > (2) To work on RFC4960-bis and just drop this document since there is no = archival > value for the reasons why something has changed. Having the changed = version > is the important point. I'm suggesting something close to (2), which I hoped the link to https://www.ietf.org/blog/support-documents-ietf-working-groups/ would make clear. /a --_000_c1029fed68bc49e0b03d0d9e0c35fd57meraru_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Adam,


I guess support documents are never published. How they could = be found and used by developers who are not closely involved in WG work?


BR, Maxim 


From: tsvwg <tsvwg-bou= nces@ietf.org> on behalf of Adam Roach <adam@nostrum.com>
Sent: Wednesday, July 4, 2018 10:59:16 PM
To: Michael Tuexen
Cc: Gorry Fairhurst; The IESG; draft-ietf-tsvwg-rfc4960-errata@ietf.= org; tsvwg-chairs@ietf.org; tsvwg@ietf.org
Subject: Re: [tsvwg] Adam Roach's Abstain on draft-ietf-tsvwg-rfc496= 0-errata-06: (with COMMENT)
 
On 7/4/18 12:19 AM, Michael Tuexen wrote:
>
>> On 3. Jul 2018, at 22:37, Adam Roach <adam@nostrum.com> wrot= e:
>>
>> Adam Roach has entered the following ballot position for
>> draft-ietf-tsvwg-rfc4960-errata-06: Abstain
>>
>> 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-tsvwg-rfc4960-errat= a/
>>
>>
>>
>> ------------------------------------------------------------------= ----
>> COMMENT:
>> ------------------------------------------------------------------= ----
>>
>> I agree with Ben (and, transitively, the OPSDIR an GENART reviewer= s). From my
>> reading, this document -- while immensely valuable to the working = group for
>> creation of an RFC 4960 bis document -- has little archival value.= The following
>> standing guidance from the IESG would seem to be applicable:
>>
>> https://www.ietf.org/blog/support-documents-ietf-working-groups/=
>>
>> Like Ben, I'm abstaining on this document. I would ask the working= group to
>> consider not publishing it in this form, and waiting until a compl= ete bis
>> version of the document can be produced.
> Just to get a better understanding of your position:
>
> Are you suggesting either
>
> (1) To work on RFC4960-bis and once that gets published, publish an RF= C4960-errata
>      which is consistent with RFC4960-bis at = a later time.
>
> or
>
> (2) To work on RFC4960-bis and just drop this document since there is = no archival
>      value for the reasons why something has = changed. Having the changed version
>      is the important point.

I'm suggesting something close to (2), which I hoped the link to
https://www.ietf.org/blog/support-documents-ietf-working-groups/ woul= d
make clear.

/a

--_000_c1029fed68bc49e0b03d0d9e0c35fd57meraru_-- From nobody Thu Jul 5 07:54:41 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 286F5130E84; Thu, 5 Jul 2018 07:54:32 -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-tsvwg-rfc4960-errata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, gorry@erg.abdn.ac.uk, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153080247215.11318.5611327442992806232.idtracker@ietfa.amsl.com> Date: Thu, 05 Jul 2018 07:54:32 -0700 Archived-At: Subject: [tsvwg] Eric Rescorla's Discuss on draft-ietf-tsvwg-rfc4960-errata-06: (with DISCUSS and COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 14:54:33 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-tsvwg-rfc4960-errata-06: Discuss 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-tsvwg-rfc4960-errata/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Given that the majority of the IESG has now ballotted abstain, I think we should at least discuss this. I'm marking my ballot DISCUSS until we have a chance to discuss this on a telechat. After we've done that, if Spencer still believes we should advance the document, I will withdraw my DISCUSS. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Adam and Spencer. This is just an incredibly user-hostile presentation of this information, in particular: Note that when reading this document one must use care to assure that a field or item is not updated further on within the document. Since this document is a historical record of the sequential changes that have been found necessary at various inter-op events and through discussion on the list, the last delta in the text is the one which should be applied. This seems like good input to a -bis but should not be published as-is. From nobody Thu Jul 5 08:13:54 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB2312F1AC for ; Thu, 5 Jul 2018 08:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable 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 C-_c0NlEYwWa for ; Thu, 5 Jul 2018 08:13:50 -0700 (PDT) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (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 F1313130DED for ; Thu, 5 Jul 2018 08:13:47 -0700 (PDT) Received: by mail-yb0-x231.google.com with SMTP id r3-v6so3345659ybo.4 for ; Thu, 05 Jul 2018 08:13:47 -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=Eq+fzOJOjN1vXaNkPulCQ8UZ18RiayGcTTVQKyG2+Y4=; b=mFJ8gUv+Fy9/5pb7OxFuo+X6YHYRB4E9laBnHbbhaPoTJSvZpveJV/h+E2CLkYKRxp JM9a1VrTApzFDbxxtGo3ZR2Z2Lj0yewyNU0Uv1MHbq0YtVxlRrPgrp317o+MlZp5lIvp YzvHVQa39F5vqZdmo7eCn07Eaz5oKx1ZD/lbMD3dq7VYlyFR0fjL5uWNdc3RSW50nXTI qPDvhHRogd9k2KAdUrA22YooBCnohfZJ9Fb1fLOf5uo8+QpIfVo/H61k2uiNJ/djTNhW yEAirMsRvCljay+AHTOFdf5cl+WOBkYXkY0INDyTrvN7mM/6Wu/ZRdfN2XtOIKwcUIz1 ozmw== 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=Eq+fzOJOjN1vXaNkPulCQ8UZ18RiayGcTTVQKyG2+Y4=; b=k7yhtF4Y9BocLVlUKTUCauEKkWHasfF1VOc/RV2aJdXe+NWH6ra/bADVxJE+rDBRUL VODeSfsc+TYpM2FnvkXCIqdH8UTmTSeDO1fRhSZK9aoyuJfDekywthyeB5aJCpDY42dA m058z8A4qwbnNARYrrXv4wyMooT4W1Gk3+nj3llN96iKh2O1KZXNPltFkVIiNI9fe2Om +J8j0VTZBIUhvp/by66mMX1LuLA0GMe1Kw0xiCBCG2XmiJZza7W8LZyLetgq52HA6Z7x Ds2yRYVmz2OSithvN4Ocduskk3z2HM35kZNdfQEhx7W0vpzvQ1miOZ8XSdBe7/yzj7cK CrEQ== X-Gm-Message-State: APt69E0JZvVWt7kAi3TurkrYUiBIlJvDtFcDEMTjGdzpqDvcYcCECQmz SzaTr7vwiDUbvA3R54h4J2uTOiObeJ0TVoFUb3OWog== X-Google-Smtp-Source: AAOMgpehIhHDihjEcpeYgm/jYht1nBFWsU4+ZHikzl/7g4lEN3e8wt3aSgmlg6yZq95N47ztWX0t/SvMjgSVzynHB70= X-Received: by 2002:a25:b1a0:: with SMTP id h32-v6mr3411239ybj.413.1530803627103; Thu, 05 Jul 2018 08:13:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Thu, 5 Jul 2018 08:13:06 -0700 (PDT) In-Reply-To: <153080247215.11318.5611327442992806232.idtracker@ietfa.amsl.com> References: <153080247215.11318.5611327442992806232.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Thu, 5 Jul 2018 08:13:06 -0700 Message-ID: To: The IESG Cc: Gorry Fairhurst , tsvwg@ietf.org, draft-ietf-tsvwg-rfc4960-errata@ietf.org, tsvwg-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000006a32d9057041fedf" Archived-At: Subject: Re: [tsvwg] Eric Rescorla's Discuss on draft-ietf-tsvwg-rfc4960-errata-06: (with DISCUSS and COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 15:13:52 -0000 --0000000000006a32d9057041fedf Content-Type: text/plain; charset="UTF-8" There was some discussion of this on the call, so to clarify my position. Both because of the internal structure and the IESG statement cited by Adam in his DISCUSS, I think this document should not advance, and I think it's important to air those issues prior to making a decision. My DISCUSS is in the sense seen here (https://ietf.org/standards/process/iesg-ballots/) of: "I think we need to talk about this.". Once we have done so, if Spencer thinks that this document is worth publishing, I will remove my DISCUSS. -Ekr On Thu, Jul 5, 2018 at 7:54 AM, Eric Rescorla wrote: > Eric Rescorla has entered the following ballot position for > draft-ietf-tsvwg-rfc4960-errata-06: Discuss > > 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-tsvwg-rfc4960-errata/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Given that the majority of the IESG has now ballotted abstain, I think we > should at least discuss this. I'm marking my ballot DISCUSS until we have a > chance to discuss this on a telechat. After we've done that, if Spencer > still > believes we should advance the document, I will withdraw my DISCUSS. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with Adam and Spencer. This is just an incredibly user-hostile > presentation of this information, in particular: > > Note that when reading this document one must use care to assure that > a field or item is not updated further on within the document. Since > this document is a historical record of the sequential changes that > have been found necessary at various inter-op events and through > discussion on the list, the last delta in the text is the one which > should be applied. > > This seems like good input to a -bis but should not be published as-is. > > > --0000000000006a32d9057041fedf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There was some discussion of this on the call, so to = clarify my position.

Both because of the internal = structure and the IESG statement cited by Adam in his DISCUSS, I think this= document should not advance, and I think it's important to air those i= ssues prior to making a decision. My DISCUSS is in the sense seen here (https://ietf.org/= standards/process/iesg-ballots/) of: "I think we need to talk abou= t this.". Once we have done so, if Spencer thinks that this document i= s worth publishing, I will remove my DISCUSS.

-Ekr=



On Thu, Jul 5, 2018 at 7:54 AM, Eric Rescorla <ekr@rtfm.com&g= t; wrote:
Eric Rescorla has entere= d the following ballot position for
draft-ietf-tsvwg-rfc4960-errata-06: Discuss

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/<= wbr>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/d= oc/draft-ietf-tsvwg-rfc4960-errata/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

Given that the majority of the IESG has now ballotted abstain, I think we should at least discuss this. I'm marking my ballot DISCUSS until we ha= ve a
chance to discuss this on a telechat. After we've done that, if Spencer= still
believes we should advance the document, I will withdraw my DISCUSS.


-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

I agree with Adam and Spencer. This is just an incredibly user-hostile
presentation of this information, in particular:

=C2=A0 Note that when reading this document one must use care to assure tha= t
=C2=A0 a field or item is not updated further on within the document.=C2=A0= Since
=C2=A0 this document is a historical record of the sequential changes that<= br> =C2=A0 have been found necessary at various inter-op events and through
=C2=A0 discussion on the list, the last delta in the text is the one which<= br> =C2=A0 should be applied.

This seems like good input to a -bis but should not be published as-is.



--0000000000006a32d9057041fedf-- From nobody Thu Jul 5 17:40:52 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FCA130FA2 for ; Thu, 5 Jul 2018 17:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 WDAImj3YkcDS for ; Thu, 5 Jul 2018 17:40:48 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 95C4F130E27 for ; Thu, 5 Jul 2018 17:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IIHLaRkdK12h2KVmWVOi1WEm0lAQn8ceMihXZ61MBOI=; b=nckPJjSsqxjLn5XH9VEkbFo3g RCFYrV8TW2nJ5xr7SFbHAssk9y/mXDt6ryaSzl5AMNSLp/ME7MiDv9csKQuSfmGZNc8MzgWF8H3M/ qTiP2nlB1UjPFgM6gLgAsIh4h/zUSRv/aHufDF8eVnGhbUHYpzrqrRz0aBwKDCLEoxbLCCj1uVaXy XiGArhcz5fUNN5d9CWwK2yy4hfImaJFwWcMquZ+h63Y9n+18PlRZxddZONdZF/cClE6A/+gmxVLI5 JpvgrCCgVG9lDAyYj6SQ3ulGkXgiv6gRAxRzZaS0Fsckkh512XOe+yubtMaQwMGzI4xumpwAFp5rb jWL2hw6yw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:50490 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fbEnn-003tjb-9U; Thu, 05 Jul 2018 20:40:48 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_737A8A2F-EB78-48FB-891D-4E57B316A6A8" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Joe Touch In-Reply-To: Date: Thu, 5 Jul 2018 17:40:46 -0700 Cc: tsvwg Message-Id: References: To: "C. M. Heard" X-Mailer: Apple Mail (2.3445.8.2) X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 00:40:51 -0000 --Apple-Mail=_737A8A2F-EB78-48FB-891D-4E57B316A6A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks - this will be fixed in the next revision. Joe > On Jul 3, 2018, at 10:26 PM, C. M. Heard wrote: >=20 > Hi Joe, >=20 > This version looks really good to me, with only a couple of minor = issues. >=20 > First, in Section 5.4, Alternate Checksum (ACS), there are two = technical comments that I made on the -02 version that I don't believe = have been properly addressed: >=20 > On Sun, May 6, 2018 at 10:23 AM, C. M. Heard wrote: > Also, it is necessary to specify whether the data polynomial is = constructed as if the bytes are transmitted most significant bit first = or least significant bit first. Finally, the polynomial is x^16 + x^12 + = x^5 + 1 (which would be 0x11021, but that fact is not needed, and I = recommend omitting it). >=20 > In what is probably a typo, the -04 draft has the generator polynomial = as "x^16 + x^12 + x^5 + x" instead of "x^16 + x^12 + x^5 + 1." >=20 > It also does not specify how to construct the polynomial represent the = data to be checksummed. That latter point may not be entirely obvious. >=20 > In order to re-used existing software used to compute CRC-CCITT, that = polynomial needs to be constructed as if the least significant bit of = each byte is the the coefficient associated with the highest power of x. = So, for example, 0x8b would correspond to >=20 > x^7 + x^6 + x^4 + 1 >=20 > and not to >=20 > x^7 + x^3 + x + 1 >=20 > as one might expect. Here is how one might fully specify the = algorithm. Suppose that there are n bytes of checksummed data, indexed = from 0 through n-1 in order of appearance in the (possibly reassembled) = datagram, and P(k,x) is the polynomial representing the kth byte. Then = the polynomial M(x) representing the data to be checksummed would be the = sum, taken from k=3D0 to n-1, of x^(8*(n-1-k)) * P(k,x). The ACS option = then contains the remainder upon division (modulo 2) of x^16 * M(x) by = the generator polynomial x^16 + x^12 + x^5 + 1. >=20 > I would not belabor such a seemingly trivial point were it not so = vexatious in practice. Maybe you can think of some nice, short, words to = make this point clear. Or maybe there is a suitable stable reference = that has the details, though at this time I am not aware of one. Or = maybe I am in the rough and it really is something that "everyone knows" = (but I doubt that). >=20 > Also, may I suggest that instead of saying that the "Alternate = Checksum (ACS) provides a stronger alternative to the UDP header = checksum" consider saying instead "Alternate Checksum (ACS) provides a = stronger alternative to the checksum in the UDP header." To me, the = words "UDP header checksum" suggest a checksum that covers only the UDP = header (similar to an analogous one in IPv4). There are two additional = occurrences in Section 5.7, where I have some other editorial = suggestions as well: >=20 > OLD: > >> During fragmentation, the UDP header checksum of each fragment > needs to be recomputed based on each datagram's pseudoheader. >=20 > >> After reassembly is complete and validated using the checksum of > the terminal FRAG option, the UDP header checksum of the resulting > datagram needs to be recomputed based on the datagram's > pseudoheader. >=20 > NEW: > >> During fragmentation, the checksum in the UDP header of each = fragment > needs to be recomputed based on that datagram's pseudoheader. >=20 > >> After reassembly is complete and validated using the checksum of > the terminal FRAG option, the checksum in the UDP header of the = resulting > datagram needs to be recomputed based on the reassembled datagram's > pseudoheader. >=20 > Thanks and regards, >=20 > Mike Heard --Apple-Mail=_737A8A2F-EB78-48FB-891D-4E57B316A6A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Thanks - this will be fixed in the next revision.

Joe
On Jul = 3, 2018, at 10:26 PM, C. M. Heard <heard@pobox.com> wrote:

Hi Joe,

This version looks really good to me, = with only a couple of minor issues.

First, in Section 5.4, Alternate = Checksum (ACS), there are two technical comments that I made on the -02 = version that I don't believe have been properly addressed:

On Sun, May 6, 2018 at 10:23 AM, C. M. Heard = wrote:
Also, it is = necessary to specify whether the data polynomial is constructed as if = the bytes are transmitted most significant bit first or least = significant bit first. Finally, the polynomial is x^16 + x^12 + x^5 + 1 (which = would be 0x11021, but that fact is not needed, and I recommend omitting = it).

In what is probably a = typo, the -04 draft has the generator polynomial as "x^16 + x^12 + x^5 + x" = instead of "x^16 = + x^12 + x^5 + 1."

It also does not specify how = to construct the polynomial represent the data to be checksummed. That = latter point may not be entirely obvious.

In order to re-used existing software used = to compute CRC-CCITT, that polynomial needs to be constructed as if the = least significant bit of each byte is the the coefficient associated = with the highest power of x. So, for example, 0x8b = would correspond to

x^7 + x^6  + x^4 + 1
and not to

x^7 + = x^3 + x  + 1

as one might expect. Here is how one = might fully specify the algorithm. Suppose that there are n bytes of checksummed = data, indexed from 0 through n-1 in order of appearance in the (possibly = reassembled) datagram, and P(k,x) is the polynomial representing the kth = byte. Then the polynomial M(x) representing the data to be checksummed = would be the sum, taken from k=3D0 to n-1, of x^(8*(n-1-k)) * P(k,x). The = ACS option then contains the remainder upon division = (modulo 2) of x^16 * M(x)  by the generator = polynomial x^16 + x^12 + x^5 + 1.

I would not belabor such a seemingly trivial = point were it not so vexatious in practice. Maybe you can think of some = nice, short, words to make this point clear. Or maybe there is a = suitable stable reference that has the details, though at this = time I am not aware of one. Or maybe I am in the rough and it really is = something that "everyone knows" (but I doubt that).

Also, may I suggest that instead of saying that = the "Alternate Checksum (ACS) provides a stronger alternative to = the UDP header checksum" consider saying instead "Alternate Checksum = (ACS) provides a stronger alternative to the checksum in the UDP = header." To me, the words "UDP header checksum" =  suggest a checksum that covers only the UDP header (similar to an = analogous one in IPv4). There are two additional occurrences in Section = 5.7, where I have some other editorial suggestions as well:

OLD:
   >> =
During fragmentation, the UDP header checksum of each fragment
   needs to be recomputed based on each =
datagram's pseudoheader.

   >> After reassembly is complete and validated using the =
checksum of
   the terminal FRAG option, the UDP header =
checksum of the resulting
   datagram =
needs to be recomputed based on the datagram's
   pseudoheader.

NEW:
   >> During fragmentation, the checksum in the UDP =
header of each fragment
   needs to be recomputed based on that =
datagram's pseudoheader.

   >> After reassembly is complete and validated using the =
checksum of
   the terminal FRAG option, the checksum in the UDP =
header of the resulting
   datagram =
needs to be recomputed based on the reassembled =
datagram's
   pseudoheader.

Thanks = and regards,

Mike Heard

= --Apple-Mail=_737A8A2F-EB78-48FB-891D-4E57B316A6A8-- From nobody Thu Jul 5 18:21:10 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D69E130DCB; Thu, 5 Jul 2018 18:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 TIhGu3y0GETd; Thu, 5 Jul 2018 18:21:01 -0700 (PDT) Received: from mail-pl0-x242.google.com (mail-pl0-x242.google.com [IPv6:2607:f8b0:400e:c01::242]) (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 EA611130DC6; Thu, 5 Jul 2018 18:21:00 -0700 (PDT) Received: by mail-pl0-x242.google.com with SMTP id k1-v6so2051580plt.2; Thu, 05 Jul 2018 18:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=+3V9j2ByDpo1iMjxVAscRDdM7pM+/DfpZTB7QX7ou0I=; b=S+LwZ0s01ubab4DMTxVmNyV54kXHmCcE8zrWuX3zuL/QpmMZ1DK9vLYVfPlhld/+J/ 1N1ADOVdWlUp3cez3NY6Qy27cUalzY3CRP2JpjjCBrYHS5mlVvPpmDJd8GCaBu/vXwrU LgkvdoTyLO/YdgUz3ZwxoW4Huj/lxFpUBmr2oVPfZ+7uzyj4WR4ByaNa+ISsfDxs6gYQ LHHWtVc7prADIU5S5waHEtSMuz9mCqjqP2AfzV9xA3ab7AEbOFOjtYw9fg5koJFls+eZ co48Qu7g8JRlWQPHlzMsEuX691E4p1cFdZmNlKwpvyGLyMPjt4wqfAacuJfbM+GjjMij BQbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+3V9j2ByDpo1iMjxVAscRDdM7pM+/DfpZTB7QX7ou0I=; b=dD82UE60y5dF6tlY7kEMUOOVzr8c4vDsG2MHtSZx7/Wi9Cg3QGWi2F4FLlnnlnceVu 2T3S3hyF7tvd1VD8bVQK5WAzR/4a6T65Nihk+hrrYtO8DrByw7VEIoPiop76dWe816Yf 4/X7Leicq/yQMir8JoCXSDAYPBMILN3d72ib5cJR/ClmJRmwR5duVYiygI46D5eyerfG qrsSFb1DkJWQtKLsM/4y/OivrUyW/Z5E/Xj97INmwkd8Grq5PmvhW0pJGFI23FE0i4XF ebXVlzuobHPHMhuI9DIWQzFCyptxkaXcwJDbjBaL/DR/MEY+F15xHqa16Vti6drbXLml jCNQ== X-Gm-Message-State: APt69E1N1ESL/05VzaXnyvYacB6dpXJJlrvB/1k2SGyiLnyL+Bn/5IgN 7NOIkw0AAmdZDE76UcKS7W/2hw== X-Google-Smtp-Source: AAOMgpd6Cx1Ju+XOJbJHPMCq5G4a2eoQkcW9QmP4D/AWzeb+3/s6SMP1/s1miK4+wHyeExohnis2gQ== X-Received: by 2002:a17:902:8645:: with SMTP id y5-v6mr8260918plt.334.1530840059989; Thu, 05 Jul 2018 18:20:59 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id g2-v6sm17865496pfd.165.2018.07.05.18.20.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Jul 2018 18:20:59 -0700 (PDT) To: tsvwg@ietf.org References: <153065022701.5099.10852319899819966685.idtracker@ietfa.amsl.com> <6030538E-9108-4DBA-A8BE-0CE604BFE9D9@fh-muenster.de> <1ebab249-4e1e-72a2-9226-5d561837b19e@nostrum.com> Cc: IESG From: Brian E Carpenter Message-ID: <3beedff4-0c5b-8e39-12f8-cf1abc0ee977@gmail.com> Date: Fri, 6 Jul 2018 13:20:58 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] Adam Roach's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 01:21:04 -0000 On 06/07/2018 01:43, Proshin, Maksim wrote: > Hi Adam, > > > I guess support documents are never published. How they could be found and used by developers who are not closely involved in WG work? No, they are often published. I can give you several examples that I've been somewhat involved in: http://tools.ietf.org/html/rfc3248 (actually an alternative to a standards track RFC) http://tools.ietf.org/html/rfc6294 https://tools.ietf.org/html/rfc6436 I'm not sure why the present one is different, except for being rather long. Brian > > > BR, Maxim > > ________________________________ > From: tsvwg on behalf of Adam Roach > Sent: Wednesday, July 4, 2018 10:59:16 PM > To: Michael Tuexen > Cc: Gorry Fairhurst; The IESG; draft-ietf-tsvwg-rfc4960-errata@ietf.org; tsvwg-chairs@ietf.org; tsvwg@ietf.org > Subject: Re: [tsvwg] Adam Roach's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) > > On 7/4/18 12:19 AM, Michael Tuexen wrote: >> >>> On 3. Jul 2018, at 22:37, Adam Roach wrote: >>> >>> Adam Roach has entered the following ballot position for >>> draft-ietf-tsvwg-rfc4960-errata-06: Abstain >>> >>> 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-tsvwg-rfc4960-errata/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> I agree with Ben (and, transitively, the OPSDIR an GENART reviewers). From my >>> reading, this document -- while immensely valuable to the working group for >>> creation of an RFC 4960 bis document -- has little archival value. The following >>> standing guidance from the IESG would seem to be applicable: >>> >>> https://www.ietf.org/blog/support-documents-ietf-working-groups/ >>> >>> Like Ben, I'm abstaining on this document. I would ask the working group to >>> consider not publishing it in this form, and waiting until a complete bis >>> version of the document can be produced. >> Just to get a better understanding of your position: >> >> Are you suggesting either >> >> (1) To work on RFC4960-bis and once that gets published, publish an RFC4960-errata >> which is consistent with RFC4960-bis at a later time. >> >> or >> >> (2) To work on RFC4960-bis and just drop this document since there is no archival >> value for the reasons why something has changed. Having the changed version >> is the important point. > > I'm suggesting something close to (2), which I hoped the link to > https://www.ietf.org/blog/support-documents-ietf-working-groups/ would > make clear. > > /a > > From nobody Fri Jul 6 08:16:18 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D18130E82 for ; Fri, 6 Jul 2018 08:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dsxwNfRN_6Q for ; Fri, 6 Jul 2018 08:16:15 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07100130E5D for ; Fri, 6 Jul 2018 08:16:14 -0700 (PDT) Received: by accordion.employees.org (Postfix, from userid 1736) id 5D9B82D5262; Fri, 6 Jul 2018 15:16:11 +0000 (UTC) Date: Fri, 6 Jul 2018 16:16:11 +0100 From: Derek Fawcus To: tsvwg Message-ID: <20180706151611.GA67496@accordion.employees.org> References: <153050962153.27521.12163204500355119687@ietfa.amsl.com> <11FA5114-93C4-4526-9AC5-B492F984C403@strayalpha.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 15:16:17 -0000 On Mon, Jul 02, 2018 at 10:26:23AM -0700, Joe Touch wrote: > Hi Tom, > > Yeah - it was to make it 16-bit. Yes, it’s a lot weaker, but it’s also over a typically much smaller set of bytes. > > We can make it longer if that’s consensus. I’ll add it to the discussion topics. Well I've mentioned in the past the my view that it should just use the common 16 bit 1s complement algorithm as used in the IP header, TCP header, UDP header. DF From nobody Fri Jul 6 14:09:48 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D619130E70; Fri, 6 Jul 2018 14:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 8FPISa3DlTBp; Fri, 6 Jul 2018 14:09:38 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DB2A130F28; Fri, 6 Jul 2018 14:09:36 -0700 (PDT) Received: from [IPv6:2003:cd:6f1a:9700:b5c6:bf04:2e47:716d] (p200300CD6F1A9700B5C6BF042E47716D.dip0.t-ipconnect.de [IPv6:2003:cd:6f1a:9700:b5c6:bf04:2e47:716d]) (Authenticated sender: macmic) by drew.franken.de (Postfix) with ESMTPSA id 59695721E2823; Fri, 6 Jul 2018 23:09:32 +0200 (CEST) From: Michael Tuexen Message-Id: <6C927C38-AD7D-460B-B8D3-B8B3F6248564@fh-muenster.de> Content-Type: multipart/signed; boundary="Apple-Mail=_404DEB4D-8267-40E4-A92B-06AB8C4FC462"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Fri, 6 Jul 2018 23:09:30 +0200 In-Reply-To: <153076319986.27384.9856169936302827044.idtracker@ietfa.amsl.com> Cc: The IESG , draft-ietf-tsvwg-rfc4960-errata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, tsvwg@ietf.org To: Benjamin Kaduk References: <153076319986.27384.9856169936302827044.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [tsvwg] Benjamin Kaduk's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 21:09:42 -0000 --Apple-Mail=_404DEB4D-8267-40E4-A92B-06AB8C4FC462 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 5. Jul 2018, at 05:59, Benjamin Kaduk wrote: >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-tsvwg-rfc4960-errata-06: Abstain >=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-tsvwg-rfc4960-errata/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > The reasons for my Abstain vs. No Objection are covered in the other = Abstain > positions' descriptions. In particular, the "user-unfriendliness" = aspect; e.g., > in my notes, I was going to suggest switching the example CRC code to = using > fixed-width types, and had to wait until basically the end of the = document to > see that this was already done. >=20 > I did take some notes while reviewing the document, though: Hi Benjamin, thanks for providing the notes. See my comments in-line. >=20 > Section 3.14.2 (new text) >=20 > When its peer is multi-homed, an endpoint SHOULD send fast > retransmissions to the same destination transport address where the > original data was sent to. If the primary path has been changed and = the > original data was sent there before the fast retransmit, the > implementation MAY send it to the new primary path. >=20 > What is "there"? the old primary path... I changed the text to When its peer is multi-homed, an endpoint SHOULD send fast retransmissions to the same destination transport address where the original data was sent to. If the primary path has been changed and the original data was sent to the old primary path before the fast = retransmit, the implementation MAY send it to the new primary path. > Section 3.35.2 >=20 > There seem to be two instances of "Old Text" for the same outline of = text; > presumably the second one is supposed to be "New Text". Yepp, that was a typo, which has already been fixed in the git repo: = https://github.com/sctplab/rfc4960bis/commit/650416a74049578aeea6c0e609881= 5f746ecc778 >=20 > Section 3.36.2 >=20 > The ICMP3 change goes both from "MAY ignore" to "SHOULD ignore" and = from > "code does not indicate" to "code indicates", which is qualitatively a > large change. There are 13 code values that are not mentioned in = either > old or new text, and the supporting problem/solution descriptions = don't do > very much to explain the change for these 13 codes. The codes not mentioned may be ignored... But you are right: The change for ICMP3) is missing IPv6 and is not = covered by the explanation in 3.36.1. This was a mistake in RFC 4960, the text below the enumeration in RFC 4960 describes the intention: Note that these procedures differ from [RFC1122] and from its requirements for processing of port-unreachable messages and the requirements that an implementation MUST abort associations in response to a "protocol unreachable" message. Port-unreachable messages are not processed, since an implementation will send an ABORT, not a port unreachable. The stricter handling of the "protocol unreachable" message is due to security concerns for hosts that do NOT support SCTP. The updated ICMP3 reflects this now. I change the text of 3.36.1 to: Appendix C of describes the handling of = ICMPv4 and ICMPv6 messages. The handling of ICMP messages indicating that the port number is unreachable described in the enumeration is not consistent = with the description given in after the = enumeration. Furthermore, the text explicitly describes the handling of ICMPv6 = packets indicating reachability problems, but does not do the same for the corresponding ICMPv4 packets. and the text of 3.36.3 to: The text has been changed to describe the intended handling of ICMP messages indicating that the port number is unreachable by replacing the = third rule. Furthermore, remove the limitation to ICMPv6 in the ninth rule. >=20 > Section 3.40.2 >=20 > Is ECN really still a "proposed extension to IP", or a realized = extension? The issue was that the references needed an updated. But I removed the = word "proposed"... >=20 >=20 --Apple-Mail=_404DEB4D-8267-40E4-A92B-06AB8C4FC462 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQkDCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFojCCBIqgAwIBAgIHF6Qk oQlIMzANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTE0MDUyNzE0NTQwOVoXDTE5MDcwOTIzNTkwMFowgcYxCzAJBgNVBAYTAkRFMRwwGgYDVQQIExNO b3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFjaGhvY2hz Y2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxlMR0wGwYD VQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVlbnN0ZXIu ZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eWyu8GzsIv0iowf2v/9BT0SmCFNX /eyQe5BncOk1j6XIlY5bnNu1S5uBe3uVgekgTh3gJyVNlaoIfCgAjqCrNJIaNQq5fr/S6L8uFeaU O8IF/C4RH5P7f9Hn2GUueEjmJhg9CI3LBAhrfAmEEtNmuVfDycN2MjngwDNxUNRfuXbWxuhkgDqJ 0ztJeayHGhFDrGx88eyStx40xy+0c0OFWdWxzBFQlBRHnl+zRftj3c9qy6BY+/fGaA2vV1oKr3h5 X6eyU1T8YlpP1NDe4bylqAteX01sM2Qciu8UAPnNc7Sb93TQjhCFRVDIS3CdN6AOpwz5YWEld6ey CdmFZ7pvAgMBAAGjggH+MIIB+jASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAR BgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFArzW7zkMYDWNUKJptPDzzfe0d/XMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOBEWNhQGZoLW11ZW5zdGVyLmRlMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0 dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDov L2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYI KwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQDeRwM11kpvuRIPuzWXLapr/ZBtB76V3cuF l45x/Kx0u03yjB4GaBPcxihn4P1z5KhRYkDBMo8HXkOgbL59aF6VdOlCurEgZvghKvUkKOCyWeYx S9rTGPBkbGiNn2ATVuLXzF8rDf50ynAIu3otstOOv+3Ifqi1pzCva1nO64khQA5Gd5/BNyu+YHbW f8ERAf9leu5a7yVI7cv1gCZAHpWJpkUKmfawyY4sAJ2hbGZRBvdACOxrfbuMdSOzPneT2rlmvH+D 7M6DmzVabLYk6UtAxQhldd/T/qsHkWvaWXHt0Eb9STs2Fl03Ls7M3NyLQLhaeR3ysNURYcaEfaB+ lxN+MIIGDTCCBPWgAwIBAgIHG5mIdDexozANBgkqhkiG9w0BAQsFADCBxjELMAkGA1UEBhMCREUx HDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQK ExdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVu dHJhbGUxHTAbBgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBm aC1tdWVuc3Rlci5kZTAeFw0xNjA3MDQwNzA2MTNaFw0xOTA3MDQwNzA2MTNaMHwxCzAJBgNVBAYT AkRFMSAwHgYDVQQKDBdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEyMDAGA1UECwwpRmFjaGJlcmVp Y2ggRWxla3Ryb3RlY2huaWsgdW5kIEluZm9ybWF0aWsxFzAVBgNVBAMMDk1pY2hhZWwgVHVleGVu MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzJoaUG3Zm24XxA/zNg2sbFcL56w8xqMg +X6G7UsYec3YEncnlkw3jgE5nDefos7UVoCA7wPjFTj8AQt5xfpXElnbM45IPy5Ng7g6dS7biGSM VRACPXe1PrjgApRAwwGmCPvALnZXkmKP6Zlf+3VLfz9YWIIaeKu3jFM2Lk6Y3gr5U1l8bjHSawOo WMlfvSsXXLT38zKW7Uz9jS278j0OqHANBPgsE6/LJoCWFInwlvybxhO3nGU7OteUGaPikqzvjLsL YgpHDi0WjMZfVx/UtUSzZ4EJvmJTBeuVwyKnCbrawnfwYPTQQ6VE1OkAzmsMByBbEwJ996RtG//T XCG06QIDAQABo4ICRzCCAkMwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGB rSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTQHa9qhKgSZgCCAPThZkXaEaJ/ dTAfBgNVHSMEGDAWgBQK81u85DGA1jVCiabTw8833tHf1zAgBgNVHREEGTAXgRV0dWV4ZW5AZmgt bXVlbnN0ZXIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Zo LW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAz BggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9maC1tdWVuc3Rl ci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAEj2/6x4kzoCVIiu aaminPrOHxACyoYsmSRjYPQpgW5xRj/FlolO1nG+ZZ11sqTb3TdCGD69ko5/zs8eGKnv/i0VLCHF g1JLfpaxElN5RrR/cqRJrbzKshF9aUkBODF8vlf9BCeimMK3fifjbbWRyxHssfEECffujD7/Yvta NYMO46Roz39lIK2s37IVFq3V5RWzUeTuwpP9t8lOxirOi9eK2OYI/dh0HjR2S5Dr9nMR1dNulrhz jlFxGc+opefGScrRR9Ec0eqTXlbt1Q9UzNIYVS+OGZY8/bBbprwXVTmwSp8dygEULkIaMbLsaTaW 6TehuL8ousPJkL52SOENgSkxggQpMIIEJQIBATCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozAJBgUrDgMCGgUAoIICKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xODA3MDYyMTA5MzFaMCMGCSqGSIb3DQEJBDEWBBQIcw+HQTYlAi14oivp Y+Y/vqngcDCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9y ZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2No dWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UE AxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRl AgcbmYh0N7GjMIHlBgsqhkiG9w0BCRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozANBgkqhkiG9w0BAQEFAASCAQCos2P7TZk1WLrwb0JDMtMiYnezT00sE89l i0XLeg/cRiNTlh4v/8xYCtBx8QSUxCzNknQDGLv4hc6MIeE2jFso9nrXs2FtjQKdqCqtCOuor85N Ho600cehhCiPdSwhWEUB0TpSK43jnUqURczxN5kDAiHBa048W38SiRwoGAopMcd/JwhmzhGDHGwl TMcN9VsgM8YmrMfxji60BsV18UuDAXsStAn2LW/KyZj4QXioCDIAxJftsOxQD3XYUIHdmSj9sfPu lM1rqT+7Lz7PH0RN3yTCo3Wp14zWp+pFD7YkTd0fQQym9FJdOmyco/8ZcCMykro01nPlLc3Xoyl9 AbpPAAAAAAAA --Apple-Mail=_404DEB4D-8267-40E4-A92B-06AB8C4FC462-- From nobody Fri Jul 6 14:35:34 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 907E2130FBA; Fri, 6 Jul 2018 14:35:31 -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 ovWep105zT_W; Fri, 6 Jul 2018 14:35:29 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 46542130F6C; Fri, 6 Jul 2018 14:35:29 -0700 (PDT) X-AuditID: 12074423-8fbff700000041bb-8c-5b3fe09f4416 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id A6.13.16827.0A0EF3B5; Fri, 6 Jul 2018 17:35:28 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w66LZQIf023010; Fri, 6 Jul 2018 17:35:26 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w66LZIWK017651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Jul 2018 17:35:21 -0400 Date: Fri, 6 Jul 2018 16:35:18 -0500 From: Benjamin Kaduk To: Michael Tuexen Cc: The IESG , draft-ietf-tsvwg-rfc4960-errata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, tsvwg@ietf.org Message-ID: <20180706213516.GD60996@kduck.kaduk.org> References: <153076319986.27384.9856169936302827044.idtracker@ietfa.amsl.com> <6C927C38-AD7D-460B-B8D3-B8B3F6248564@fh-muenster.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6C927C38-AD7D-460B-B8D3-B8B3F6248564@fh-muenster.de> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsUixCmqrLvggX20wdPZnBbf9kxhsXjdNpvR YsaficwWDX13WS2OvbnLZjFh6SNWBzaPns8vmDx6ppxm9Viy5CdTAHMUl01Kak5mWWqRvl0C V8byj/eZC5oVK+avPMfcwDhRqouRk0NCwESiZeUKpi5GLg4hgcVMEq1zJ7JCOBsYJY7OfM0O 4Vxhkvh5by4rSAuLgIrEp3+tLCA2G5Dd0H2ZGcQWEdCS+Pf+DjNIA7PAckaJY1u62UASwgKx Ept2n2HsYuTg4AXa9/FUBsTQVkaJ2+duMILU8AoISpyc+QRsKDPQoBv/XjKB1DMLSEss/8cB EuYUcJLY8v8YE4gtKqAssbfvEPsERoFZSLpnIemehdC9gJF5FaNsSm6Vbm5iZk5xarJucXJi Xl5qka6ZXm5miV5qSukmRlBos7so72B82ed9iFGAg1GJh/dCun20EGtiWXFl7iFGSQ4mJVFe q9NAIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8WvVAOd6UxMqq1KJ8mJQ0B4uSOG/OIsZoIYH0 xJLU7NTUgtQimKwMB4eSBG/cfaBGwaLU9NSKtMycEoQ0EwcnyHAeoOHOIDW8xQWJucWZ6RD5 U4y6HH/eT53ELMSSl5+XKiXOOx2kSACkKKM0D24OKCVJZO+vecUoDvSWMO9GkCoeYDqDm/QK aAkT0JKJAnYgS0oSEVJSDYxuqoEV83at6H2ecGLPZYmlP+48r03SNc1RuCdpfW2PC3PltF7F ZgOzSa+adu6ZvPVy919LS5ejZ6KObtJfqDVz86aSitsWmyfH7s6o//DnW8Xuq1OnZ12IZNZv TI3ZZum3+UzjOa0pT9/wCa09s3Pmln+1Riw1Wy7u28j5xv58fYhKMNuSq7u7lFiKMxINtZiL ihMB7peOYSQDAAA= Archived-At: Subject: Re: [tsvwg] Benjamin Kaduk's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 21:35:32 -0000 Hi Michael, On Fri, Jul 06, 2018 at 11:09:30PM +0200, Michael Tuexen wrote: > > On 5. Jul 2018, at 05:59, Benjamin Kaduk wrote: > > > > I did take some notes while reviewing the document, though: > Hi Benjamin, > > thanks for providing the notes. See my comments in-line. > > > > Section 3.14.2 (new text) > > > > When its peer is multi-homed, an endpoint SHOULD send fast > > retransmissions to the same destination transport address where the > > original data was sent to. If the primary path has been changed and the > > original data was sent there before the fast retransmit, the > > implementation MAY send it to the new primary path. > > > > What is "there"? > the old primary path... I changed the text to > > When its peer is multi-homed, an endpoint SHOULD send fast > retransmissions to the same destination transport address where the > original data was sent to. If the primary path has been changed and the > original data was sent to the old primary path before the fast retransmit, > the implementation MAY send it to the new primary path. Thanks! If forced to guess, I would have guessed the old primary path, but this is much clearer to me. > > Section 3.35.2 > > > > There seem to be two instances of "Old Text" for the same outline of text; > > presumably the second one is supposed to be "New Text". > Yepp, that was a typo, which has already been fixed in the git repo: > https://github.com/sctplab/rfc4960bis/commit/650416a74049578aeea6c0e6098815f746ecc778 > > > > Section 3.36.2 > > > > The ICMP3 change goes both from "MAY ignore" to "SHOULD ignore" and from > > "code does not indicate" to "code indicates", which is qualitatively a > > large change. There are 13 code values that are not mentioned in either > > old or new text, and the supporting problem/solution descriptions don't do > > very much to explain the change for these 13 codes. > The codes not mentioned may be ignored... > > But you are right: The change for ICMP3) is missing IPv6 and is not covered > by the explanation in 3.36.1. This was a mistake in RFC 4960, > the text below the enumeration in RFC 4960 describes the intention: > > Note that these procedures differ from [RFC1122] and from its > requirements for processing of port-unreachable messages and the > requirements that an implementation MUST abort associations in > response to a "protocol unreachable" message. Port-unreachable > messages are not processed, since an implementation will send an > ABORT, not a port unreachable. The stricter handling of the > "protocol unreachable" message is due to security concerns for hosts > that do NOT support SCTP. > > The updated ICMP3 reflects this now. > > I change the text of 3.36.1 to: > > Appendix C of describes the handling of ICMPv4 and > ICMPv6 messages. > The handling of ICMP messages indicating that the port > number is unreachable described in the enumeration is not consistent with > the description given in after the enumeration. > Furthermore, the text explicitly describes the handling of ICMPv6 packets > indicating reachability problems, but does not do the same for the > corresponding ICMPv4 packets. > > and the text of 3.36.3 to: > > The text has been changed to describe the intended handling of ICMP > messages indicating that the port number is unreachable by replacing the third rule. > Furthermore, remove the limitation to ICMPv6 in the ninth rule. Ah, this makes more sense -- as you can imagine, I was just looking at the diff of the OLD/NEW chunks in this document, so I missed the broader context in 4960 itself. > > Section 3.40.2 > > > > Is ECN really still a "proposed extension to IP", or a realized extension? > The issue was that the references needed an updated. But I removed the word > "proposed"... Thanks. And, more generally, thanks to all the authors for assembling the information like this -- it's clear that a lot of energy and attention to detail went into it, and I'm sure that will be reflected when we are looking at 4960bis. -Benjamin From nobody Fri Jul 6 15:55:11 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3FF131062 for ; Fri, 6 Jul 2018 15:55:09 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=Mae42zh7; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=w+ajOdJu 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 nR60HwZKTfaP for ; Fri, 6 Jul 2018 15:55:06 -0700 (PDT) Received: from esa2.dell-outbound.iphmx.com (esa2.dell-outbound.iphmx.com [68.232.149.220]) (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 D0459124D68 for ; Fri, 6 Jul 2018 15:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1530917705; x=1562453705; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=JomS9/mjmFlXIIg1G1u5bJ8SbsL08vOkmXYZG/NAt2A=; b=Mae42zh7NKPdS4WFcX0ZOzLFSVvW16y4YVmqX0LXkgsduZK7iY7ziD1o WESli7wUhqxMT9lgreY3fjl+BUE2MmZ1y2tIQTw9QZrc89Nop936/l/ua XM9wcRp6w1gEcFiFonWbeqF5sO5aydA2I795uSxx6icMIVoQRGJZJWw7i M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GRAQDn8T9bmGOa6ERbHAEBAQQBAQoBA?= =?us-ascii?q?YJTIiYEfg5/KAqYKYIHdZQ9gT8XJAsjC4Q+AoIuITUXAQIBAQIBAQIBAQIQAQE?= =?us-ascii?q?BAQEGDQsGKSMMgjUkAQoESy8IAzABAQEBAQEBAQEBAQEBAQEBAQEXAg02ARIBA?= =?us-ascii?q?RgBAQEBAgEtEx8NCgQECQICAQgRAQMBAQsdBxsXFAMGCAIEARIIgk1LAYEbXAg?= =?us-ascii?q?BDqtwH4JZhVOBMgMFBYYzgjWBVz6BD4JaBy6DGAIDAYFeDB8JAoJ6giSFWIIMJ?= =?us-ascii?q?UeRAQMEAgKGBoVbhQKGd4UhijWHLwIEAgQFAhSBQwKCB3BQgmkJghsOCXoBAQG?= =?us-ascii?q?CSIUUhT5vjXuBGgEB?= X-IPAS-Result: =?us-ascii?q?A2GRAQDn8T9bmGOa6ERbHAEBAQQBAQoBAYJTIiYEfg5/KAq?= =?us-ascii?q?YKYIHdZQ9gT8XJAsjC4Q+AoIuITUXAQIBAQIBAQIBAQIQAQEBAQEGDQsGKSMMg?= =?us-ascii?q?jUkAQoESy8IAzABAQEBAQEBAQEBAQEBAQEBAQEXAg02ARIBARgBAQEBAgEtEx8?= =?us-ascii?q?NCgQECQICAQgRAQMBAQsdBxsXFAMGCAIEARIIgk1LAYEbXAgBDqtwH4JZhVOBM?= =?us-ascii?q?gMFBYYzgjWBVz6BD4JaBy6DGAIDAYFeDB8JAoJ6giSFWIIMJUeRAQMEAgKGBoV?= =?us-ascii?q?bhQKGd4UhijWHLwIEAgQFAhSBQwKCB3BQgmkJghsOCXoBAQGCSIUUhT5vjXuBG?= =?us-ascii?q?gEB?= Received: from esa6.dell-outbound2.iphmx.com ([68.232.154.99]) by esa2.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2018 17:55:04 -0500 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa6.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jul 2018 04:55:03 +0600 Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w66Mt2TB014359 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 6 Jul 2018 18:55:03 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com w66Mt2TB014359 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1530917703; bh=lgdYRQWDENgdkKm7oLQxpZh2qOI=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=w+ajOdJuOIAltCE2Hqq2MVKJdadT0/GeLgQZf/Gx4jNzxSMf5844f7KohZly7O+2D wAQ20tu8IsFq8pxvCnYPmo2dvLue/hRdjWlIee32rllv9Z1fk4Hd02Oi9tZyo9oAcD J02deDFC9IRkkxwQ8itWUKGWBQ6VWLWeYFZE6/cU= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com w66Mt2TB014359 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd56.lss.emc.com (RSA Interceptor); Fri, 6 Jul 2018 18:54:37 -0400 Received: from MXHUB308.corp.emc.com (MXHUB308.corp.emc.com [10.146.3.34]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w66MsfC7017206 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 6 Jul 2018 18:54:42 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB308.corp.emc.com ([10.146.3.34]) with mapi id 14.03.0382.000; Fri, 6 Jul 2018 18:54:41 -0400 To: Magnus Westerlund , tsvwg IETF list Thread-Topic: [tsvwg] Experience and Status of ECN in QUIC work Thread-Index: AQHUFF2BykvnESWqZki4EZ+C86Hr2qSCy6Ng Date: Fri, 6 Jul 2018 22:54:41 +0000 Message-ID: References: <6f8ee7ac-9318-b4ab-626c-a3a36acba042@ericsson.com> In-Reply-To: <6f8ee7ac-9318-b4ab-626c-a3a36acba042@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.21.34] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D24327794936301A7BF7MX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tsvwg] Experience and Status of ECN in QUIC work X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 22:55:10 -0000 --_000_CE03DB3D7B45C245BCA0D24327794936301A7BF7MX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Magnus, Topic B may well be resolved (at least for now) by RFC 8311: > B. Will ECT(0) and ECT(1) be mixed in one packet flow? > In the discussions around optimizing how the ECN information reported fro= m receiver to sender this question arose. > If one can make assumption that within a connection one will use only one= of the ECT codepoints then we can optimize > the reporting based on that assumption. So how safe is this assumption? A= nd in this case, what is the importance of > being able to detect ECT codepoint remarking, i.e. changing between 0 and= 1 in either direction? RFC 8311 currently prohibits use of ECT(1) outside of experiments. The L4S= experiment is the current known use of ECT(1), and it only uses one ECT co= depoint per flow. If that QUIC optimization is valuable, it may be reasonable to go ahead wit= h it, leaving its consequences for possible future experiments to be dealt = with by the possible future experimenters. In addition ... > C. Detecting Cheating Receivers This is not a new concern - RFC 8311's discussion of the ECN Nonce (RFC 354= 0) and the rationale for obsoleting it is relevant to this topic. Thanks, --David From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Magnus Westerlund Sent: Thursday, July 5, 2018 8:41 AM To: tsvwg IETF list Subject: [tsvwg] Experience and Status of ECN in QUIC work TSVWG, ECN support was added to QUIC in the latest draft versions (-13). The relev= ant documents that include ECN related text are: https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/ The inclusion of ECN in QUIC can be summarized as. Each sender performs ini= tial verification when the connection is established or migrated by setting= ECT on the packets it send. The receiver will report if it sees ECN marks,= i.e. any value other than not-ECT, using a new acknowledgement frame type = (ACK_ECN) that includes counters of how many packets with the various marki= ngs the receiver have seen since connection establishment. If the receiver = gets not-ECT or can't read ECN marks then it uses the ACK frame to report t= hese packets so that the sender can learn of the lack of ECT capability and= turn its marking off. Marking consistency are continuously verified. ECN b= lack hole mitigation is discussed and a possible mechanism is that any RTO = will result in retransmission without ECT marks. The inclusion of ECN in QUIC has so far been fairly well discussed. Initial= ly by the design team. Then at the QUIC interim meeting in June, followed b= y a lot of discussion of the actual text proposal on github. Thanks to ever= yone that engaged. Based on these discussions there are some questions and = experience that I have noticed that is worth spreading and discussing. This= is also the topics coming in the TSVWG session for my agenda item. Also I don't believe the last word is said about details of how ECN in QUIC= is realized. There are currently three different github issues related to = ECN: - Improve ACK_ECN frame encoding (e.g., use bit-vector) (https://github.com/quicwg/base-drafts/issu= es/1439) - Fragility in ECN counters with lost acks (https://github.com/quicwg/base-drafts/issues/1481) - Detect adversarial ECN reporting (https://github.com/quicwg/base-drafts/issues/1426) So the things I want to bring to attention are: A. Suppression of ECN values in packet duplicates In QUIC the drafts currently says that a receiver should suppress the ECN v= alues received in any packet duplicates. The main reason for that is to mit= igate a potential active attack by a off-path attacker that has some capabi= lity to receive a copy of the packets of the target flow. We call it an on-= the-side attack. By taking a copy of a legit packet, and changing the ECN f= ield to ECN-CE and then forward the modified copy to the intended receiver = one can perform a denial of service attack by driving down the congestion w= indow. To mitigate this, the recommendation is to care about only the first= arrived packet. This forces an on-the-side attacker to be able to race the= ir attack packets with the original packet. The downside of this is of course that an actual network duplication where = none-first packets gets marked as ECN-CE after the duplication we ignore th= e congestion signal. My personal standpoint is that this is okay. If not th= e first packet was marked then congestion may not be so bad that it is a pr= oblem if the duplication don't happens. Secondly, if it is any persistent c= ongestion then this flow will be marked in a later packet. There was some d= isagreement on this so I think it is worth more discussion. B. Will ECT(0) and ECT(1) be mixed in one packet flow? In the discussions around optimizing how the ECN information reported from = receiver to sender this question arose. If one can make assumption that wit= hin a connection one will use only one of the ECT codepoints then we can op= timize the reporting based on that assumption. So how safe is this assumpti= on? And in this case, what is the importance of being able to detect ECT co= depoint remarking, i.e. changing between 0 and 1 in either direction? C. Detecting Cheating Receivers As there are some risks in certain deployment situations that the receiver = would have an incentive to lie about if an ECN-CE mark was received or not = to gain throughput. A sender could detect this case by sending packets mark= ed as ECN-CE to verify that receiver reports these packets are being marked= . As the sender will ignore the ECN-CE marks it self generated there is a r= isk that these marks hide real CE marks. Thus, the general question is how = often, at most, should a sender mark with ECN-CE? D. Delayed Acknowledgement and ECN We also have an interesting discussion around ECN, Delayed Acknowledgement = and the interaction with recovery period. QUIC supports delayed acknowledge= ment. So far there are quite a lot of implementer freedom of how to use thi= s. What is currently specified is that when receiving an ECN-CE mark the re= ceiver sends an immediate ACK, so get rapid response to the congestion sign= al. When the ACK_ECN reaches the sender it will go into Recovery until a pa= cket sent after entering recovery has been acknowledged. During recovery as= the congestion window already is reduced and frozen the reception of addit= ional ECN-CE marks (at least for the current congestion control mechanism) = is not that important. What is important is if any packets are ECN-CE marke= d when exiting recovery. Marks on packets sent after recovery should result= in a new congestion event and new recovery period. To resolve this the cur= rent requirement is to immediately acknowledge each ECN-CE marks. This will= result in some additional acknowledgements. There has been some discussion if one want to optimize this case or if it i= s not worth it. One direction was to ensure that even with delayed ACKs one= get frequent enough acknowledgements. This resulted in discussion in the d= irection of ensuring that the longest delay before acknowledging is caped a= t a quarter of the RTT. That way one achieve no worse than quarter RTT reso= lution on the ECN-CE marks. Another potential direction is explicit indicat= ion of which packet numbers that would resolve this uncertainty. Then also = exists the question if the receiver needs any indication of recovery period= s to optimize the acknowledgements. E. Utility of detailed CE information As there has been discussion about explicitly indicate which packet numbers= was marked as CE, it is also good to understand if there are any significa= nt utility of having this information for the sender compared to what the c= ounters provide. I assume this goes into the potential for congestion contr= ol mechanism evolution. But, does it matter for example for L4S? Cheers Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --_000_CE03DB3D7B45C245BCA0D24327794936301A7BF7MX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Magnus= ,

<WG Chair Hat =3D OFF>

 

Topic B may well be resolved (at leas= t for now) by RFC 8311:

> B. Will ECT(0) and ECT(1) be mixed in one packet flow?

> In the discussions around optimizing how the ECN information report= ed from receiver to sender this question arose.
> If one can make assumption that within a connection one will use only = one of the ECT codepoints then we can optimize
> the reporting based on that assumption. So how safe is this assumption= ? And in this case, what is the importance of
> being able to detect ECT codepoint remarking, i.e. changing between 0 = and 1 in either direction?

RFC 8311 currently prohibits use of E= CT(1) outside of experiments.  The L4S experiment is the current known= use of ECT(1), and it only uses one ECT codepoint per flow.

 

If that QUIC optimization is valuable= , it may be reasonable to go ahead with it, leaving its consequences for po= ssible future experiments to be dealt with by the possible future experimenters.

 

In addition …=

> C. Detecting Cheating Receivers

This is not a new concern – RFC= 8311’s discussion of the ECN Nonce (RFC 3540) and the rationale for = obsoleting it is relevant to this topic.

 

</WG Chair Hat =3D OFF>

 

Thanks, --David

 

From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Magnus Westerlund
Sent: Thursday, July 5, 2018 8:41 AM
To: tsvwg IETF list
Subject: [tsvwg] Experience and Status of ECN in QUIC work

 

TSVWG,

ECN support was added to QUIC in the latest draft versions (-13). The re= levant documents that include ECN related text are:

= https://datatracker.ietf.org/doc/draft-ietf-quic-transport/
http= s://datatracker.ietf.org/doc/draft-ietf-quic-recovery/

The inclusion of ECN in QUIC can be summarized as. Each sender performs = initial verification when the connection is established or migrated by sett= ing ECT on the packets it send. The receiver will report if it sees ECN mar= ks, i.e. any value other than not-ECT, using a new acknowledgement frame type (ACK_ECN) that includes counters of= how many packets with the various markings the receiver have seen since co= nnection establishment. If the receiver gets not-ECT or can't read ECN mark= s then it uses the ACK frame to report these packets so that the sender can learn of the lack of ECT capab= ility and turn its marking off. Marking consistency are continuously verifi= ed. ECN black hole mitigation is discussed and a possible mechanism is that= any RTO will result in retransmission without ECT marks. 

The inclusion of ECN in QUIC has so far been fairly well discussed. Init= ially by the design team. Then at the QUIC interim meeting in June, followe= d by a lot of discussion of the actual text proposal on github. Thanks to e= veryone that engaged. Based on these discussions there are some questions and experience that I have noticed th= at is worth spreading and discussing. This is also the topics coming in the= TSVWG session for my agenda item.

Also I don't believe the last word is said about details of how ECN in Q= UIC is realized. There are currently three different github issues related = to ECN:

- Improve = ACK_ECN frame encoding (e.g., use bit-vector) (https://github.com/quicwg/base-drafts= /issues/1439)
- Fragility i= n ECN counters with lost acks (https://github.com/quicwg/base-drafts/issues/1481= )
- Detect adve= rsarial ECN reporting (https://github.com/quicwg/base-drafts/issues/1426)

So the things I want to bring to attention are:

 

A. Suppression of ECN values in packet duplicates

In QUIC the drafts currently says that a receiver should suppress the EC= N values received in any packet duplicates. The main reason for that is to = mitigate a potential active attack by a off-path attacker that has some cap= ability to receive a copy of the packets of the target flow. We call it an on-the-side attack. By taking a = copy of a legit packet, and changing the ECN field to ECN-CE and then forwa= rd the modified copy to the intended receiver one can perform a denial of s= ervice attack by driving down the congestion window. To mitigate this, the recommendation is to care about o= nly the first arrived packet. This forces an on-the-side attacker to be abl= e to race their attack packets with the original packet.

The downside of this is of course that an actual network duplication whe= re none-first packets gets marked as ECN-CE after the duplication we ignore= the congestion signal. My personal standpoint is that this is okay. If not= the first packet was marked then congestion may not be so bad that it is a problem if the duplication don't= happens. Secondly, if it is any persistent congestion then this flow will = be marked in a later packet. There was some disagreement on this so I think= it is worth more discussion.

 

B. Will ECT(0) and ECT(1) be mixed in one packet flow?

In the discussions around optimizing how the ECN information reported fr= om receiver to sender this question arose. If one can make assumption that = within a connection one will use only one of the ECT codepoints then we can= optimize the reporting based on that assumption. So how safe is this assumption? And in this case, what is= the importance of being able to detect ECT codepoint remarking, i.e. chang= ing between 0 and 1 in either direction?

 

C. Detecting Cheating Receivers

As there are some risks in certain deployment situations that the receiv= er would have an incentive to lie about if an ECN-CE mark was received or n= ot to gain throughput. A sender could detect this case by sending packets m= arked as ECN-CE to verify that receiver reports these packets are being marked. As the sender will ignore the ECN-= CE marks it self generated there is a risk that these marks hide real CE ma= rks. Thus, the general question is how often, at most, should a sender mark= with ECN-CE?

 

D. Delayed Acknowledgement and ECN

We also have an interesting discussion around ECN, Delayed Acknowledgeme= nt and the interaction with recovery period. QUIC supports delayed acknowle= dgement. So far there are quite a lot of implementer freedom of how to use = this. What is currently specified is that when receiving an ECN-CE mark the receiver sends an immediate ACK,= so get rapid response to the congestion signal. When the ACK_ECN reaches t= he sender it will go into Recovery until a packet sent after entering recov= ery has been acknowledged. During recovery as the congestion window already is reduced and frozen the recept= ion of additional ECN-CE marks (at least for the current congestion control= mechanism) is not that important. What is important is if any packets are = ECN-CE marked when exiting recovery. Marks on packets sent after recovery should result in a new congestion eve= nt and new recovery period. To resolve this the current requirement is to i= mmediately acknowledge each ECN-CE marks. This will result in some addition= al acknowledgements.

There has been some discussion if one want to optimize this case or if i= t is not worth it. One direction was to ensure that even with delayed ACKs = one get frequent enough acknowledgements. This resulted in discussion in th= e direction of ensuring that the longest delay before acknowledging is caped at a quarter of the RTT. That = way one achieve no worse than quarter RTT resolution on the ECN-CE marks. A= nother potential direction is explicit indication of which packet numbers t= hat would resolve this uncertainty. Then also exists the question if the receiver needs any indication of reco= very periods to optimize the acknowledgements.

E. Utility of detailed CE information

As there has been discussion about explicitly indicate which packet numb= ers was marked as CE, it is also good to understand if there are any signif= icant utility of having this information for the sender compared to what th= e counters provide. I assume this goes into the potential for congestion control mechanism evolution. But, d= oes it matter for example for L4S?

 

Cheers 
 
Magnus Westerlund 
 
----------------------------------------------------------------------=
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------=
Ericsson AB          =
;       | Phone  +46 10 7148287=
Torshamnsgatan 23         =
;  | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------=
--_000_CE03DB3D7B45C245BCA0D24327794936301A7BF7MX307CL04corpem_-- From nobody Sun Jul 8 04:31:24 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5980A130FCF; Sun, 8 Jul 2018 04:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=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 ZAmO2lvOTxH6; Sun, 8 Jul 2018 04:31:13 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 30A6A130FD4; Sun, 8 Jul 2018 04:31:13 -0700 (PDT) Received: from [10.210.175.179] (unknown [148.252.128.59]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id D1FD11B0093E; Wed, 4 Jul 2018 22:22:23 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: "Gorry (erg)" X-Mailer: iPhone Mail (15E216) In-Reply-To: <1ebab249-4e1e-72a2-9226-5d561837b19e@nostrum.com> Date: Wed, 4 Jul 2018 17:22:13 -0400 Cc: Michael Tuexen , The IESG , draft-ietf-tsvwg-rfc4960-errata@ietf.org, tsvwg-chairs@ietf.org, tsvwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <11361597-3F3C-4361-B880-ED836CB326B3@erg.abdn.ac.uk> References: <153065022701.5099.10852319899819966685.idtracker@ietfa.amsl.com> <6030538E-9108-4DBA-A8BE-0CE604BFE9D9@fh-muenster.de> <1ebab249-4e1e-72a2-9226-5d561837b19e@nostrum.com> To: Adam Roach Archived-At: Subject: Re: [tsvwg] Adam Roach's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2018 11:31:17 -0000 I think you are discussing a change of process wrt to what we have done befo= re in TSVWG ... I am concerned that so much energy has been spent during IET= F last call and now again. Please can you decide if you need the WG to chang= e the process for this doc? GorrY > On 4 Jul 2018, at 15:59, Adam Roach wrote: >=20 >> On 7/4/18 12:19 AM, Michael Tuexen wrote: >>=20 >>> On 3. Jul 2018, at 22:37, Adam Roach wrote: >>>=20 >>> Adam Roach has entered the following ballot position for >>> draft-ietf-tsvwg-rfc4960-errata-06: Abstain >>>=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.htm= l >>> 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-tsvwg-rfc4960-errata/ >>>=20 >>>=20 >>>=20 >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>>=20 >>> I agree with Ben (and, transitively, the OPSDIR an GENART reviewers). =46rom= my >>> reading, this document -- while immensely valuable to the working group f= or >>> creation of an RFC 4960 bis document -- has little archival value. The f= ollowing >>> standing guidance from the IESG would seem to be applicable: >>>=20 >>> https://www.ietf.org/blog/support-documents-ietf-working-groups/ >>>=20 >>> Like Ben, I'm abstaining on this document. I would ask the working group= to >>> consider not publishing it in this form, and waiting until a complete bi= s >>> version of the document can be produced. >> Just to get a better understanding of your position: >>=20 >> Are you suggesting either >>=20 >> (1) To work on RFC4960-bis and once that gets published, publish an RFC49= 60-errata >> which is consistent with RFC4960-bis at a later time. >>=20 >> or >>=20 >> (2) To work on RFC4960-bis and just drop this document since there is no a= rchival >> value for the reasons why something has changed. Having the changed v= ersion >> is the important point. >=20 > I'm suggesting something close to (2), which I hoped the link to https://w= ww.ietf.org/blog/support-documents-ietf-working-groups/ would make clear. >=20 > /a From nobody Sun Jul 8 20:06:24 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8576130DDE; Sun, 8 Jul 2018 20:06:16 -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 BiZHuzW4t6Dv; Sun, 8 Jul 2018 20:06:14 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::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 AED50130EF5; Sun, 8 Jul 2018 20:06:14 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id q7-v6so11462540pff.2; Sun, 08 Jul 2018 20:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UIO2HtPtnaxOTqdNBCPQBp/zoGR1Isk54iWiBQtbC9E=; b=ZGUj5F4x7aQ2Mg7YDlk+w3gWHH/WO5Yr+cvN5Vjos8HZ1ncLoSDBNiNt2rT+oZRzwe 1Hrl8CY2VEuAxuOir0pkepz3xFR1cloXG3/wakkptdWhCu2P/jVe/6kwIwPV+eeAhZ3K aZo2DYeIXV2I10t+D4/ThkM2ted/lSE9Tw10iR5eVg3oeJzaTlGyNyIjHsh/4C/TQAEG 2NiK0sPkt8H7jaRl6GAL0xEe6OpIgq2ne9wYp9I/mZHB+pL6Bgqw7hnfOR75ggvkwgD8 8Hx5/ErefiY8Tje/9loEvBMg/0z1rg9Q4m5oxeOsyTIXHdSV8TWse4LGKYveU3h4ZHwE jCpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=UIO2HtPtnaxOTqdNBCPQBp/zoGR1Isk54iWiBQtbC9E=; b=gMSwdScgfC/8zhU+aCl8qDgCOytSD2aXRfd7OV9762UTAj6fIlq1Rg8gEhCW+9RUNr BmPOcJXV/bFDOJ+XJJhxHAbHum8x+CaDPuSiopqvFtkCJKB67hPPw5NDVdsnp6REl0Gz Y2OmTj0Dcu6D9ZYuSIDxi6OZYz40VzS85IRfw53Elv2p+FGBPMAA6XSlqQZgGCJ5n8E8 px7zxOee2isrsmpRM7K5DoscV7dOurl8JZWK+EZ/BQLldDjFrNSJILRQU2yUEHpkLGr3 K1/jCPVogxtjJ3yXRjfGpuXw6J/UML8M0yIGYSjqVR/xX8SgUxb/PXyY/3rgI7taFxQU rUBQ== X-Gm-Message-State: APt69E0WQrJPmnssUx8c0vKPQYY9YdBxe6xMm5t7FroHZVjyahVEoTje G+hFxCnqKV7rK8MWrFYg2ZqIRg== X-Google-Smtp-Source: AAOMgpc1jiMF+q12GxxF1fn4RSC2HnvIWNWKkjTzwVJetgqNDXdDfCSamXMeDKifjDEuLiEimyQWcg== X-Received: by 2002:a62:4a41:: with SMTP id x62-v6mr17812554pfa.45.1531105573899; Sun, 08 Jul 2018 20:06:13 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id g86-v6sm30662pfd.23.2018.07.08.20.06.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Jul 2018 20:06:13 -0700 (PDT) To: tsvwg@ietf.org Cc: IESG References: <153065022701.5099.10852319899819966685.idtracker@ietfa.amsl.com> <6030538E-9108-4DBA-A8BE-0CE604BFE9D9@fh-muenster.de> <1ebab249-4e1e-72a2-9226-5d561837b19e@nostrum.com> <3beedff4-0c5b-8e39-12f8-cf1abc0ee977@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <24170514-9e25-2826-5396-f4409cc729d7@gmail.com> Date: Mon, 9 Jul 2018 15:06:09 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <3beedff4-0c5b-8e39-12f8-cf1abc0ee977@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] Adam Roach's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 03:06:17 -0000 On 06/07/2018 13:20, Brian E Carpenter wrote: > On 06/07/2018 01:43, Proshin, Maksim wrote: >> Hi Adam, >> >> >> I guess support documents are never published. How they could be found and used by developers who are not closely involved in WG work? > > No, they are often published. I can give you several examples that I've been > somewhat involved in: > > http://tools.ietf.org/html/rfc3248 (actually an alternative to a standards track RFC) > http://tools.ietf.org/html/rfc6294 > https://tools.ietf.org/html/rfc6436 > > I'm not sure why the present one is different, except for being rather long. BTW, the IESG statement suggests that "support documents" are "such things as requirements and use cases", and as I understood it at the time, those were what the IESG was concerned about. Such documents were more or less excluded by the ANIMA WG charter, for example. We were explicitly told by the AD that the idea was to prevent wasting WG time. The present document is definitely not requirements and use cases, and is not time-wasting. In any case, this is very late in the process to mention this guidance: the work has been done, with the full knowledge of the AD. Brian > > Brian > >> >> >> BR, Maxim >> >> ________________________________ >> From: tsvwg on behalf of Adam Roach >> Sent: Wednesday, July 4, 2018 10:59:16 PM >> To: Michael Tuexen >> Cc: Gorry Fairhurst; The IESG; draft-ietf-tsvwg-rfc4960-errata@ietf.org; tsvwg-chairs@ietf.org; tsvwg@ietf.org >> Subject: Re: [tsvwg] Adam Roach's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) >> >> On 7/4/18 12:19 AM, Michael Tuexen wrote: >>> >>>> On 3. Jul 2018, at 22:37, Adam Roach wrote: >>>> >>>> Adam Roach has entered the following ballot position for >>>> draft-ietf-tsvwg-rfc4960-errata-06: Abstain >>>> >>>> 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-tsvwg-rfc4960-errata/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> I agree with Ben (and, transitively, the OPSDIR an GENART reviewers). From my >>>> reading, this document -- while immensely valuable to the working group for >>>> creation of an RFC 4960 bis document -- has little archival value. The following >>>> standing guidance from the IESG would seem to be applicable: >>>> >>>> https://www.ietf.org/blog/support-documents-ietf-working-groups/ >>>> >>>> Like Ben, I'm abstaining on this document. I would ask the working group to >>>> consider not publishing it in this form, and waiting until a complete bis >>>> version of the document can be produced. >>> Just to get a better understanding of your position: >>> >>> Are you suggesting either >>> >>> (1) To work on RFC4960-bis and once that gets published, publish an RFC4960-errata >>> which is consistent with RFC4960-bis at a later time. >>> >>> or >>> >>> (2) To work on RFC4960-bis and just drop this document since there is no archival >>> value for the reasons why something has changed. Having the changed version >>> is the important point. >> >> I'm suggesting something close to (2), which I hoped the link to >> https://www.ietf.org/blog/support-documents-ietf-working-groups/ would >> make clear. >> >> /a >> >> From nobody Sun Jul 8 20:33:28 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E718130EF6 for ; Sun, 8 Jul 2018 20:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 bEONaBifbWLZ for ; Sun, 8 Jul 2018 20:33:24 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 DFA50130DC6 for ; Sun, 8 Jul 2018 20:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=J+NOpzEO4A0WVkD+fLltJzK+9zIB0npQsI6Tr6yqthM=; b=k9DwWTCQ2mJfgMnjWqdBaIT0C dYsgG9P4eHZLO5+8PQjHtmZZvR4LhMmmK+9gKLDnhSL+PkPUgGyIl+c7vpIFubH9RelEWGaTCODcN Af40ZiSleUJfC70SlW9XQ4DLisFKoSoIU0MeHRfW90BRGfL/TUFGsSXM1c51ernefLN9jzXynwZ4k qCRGmcSk/fvwUoKS3g2tquzFtwziXVkBON71Nhc4VOTPhsQSqu1egR0DH1UMNBDi91DFXM9vzZKqW mvaQ1PVwJ0p+dNJS2LK2QOWhaDpNPk9gzd7Le8hNDL7TnPCGV+uHW+hNHqKqtAU2Ascraxb1MTq4O qCST6C93w==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:55936 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fcMvR-002L4F-5w; Sun, 08 Jul 2018 23:33:21 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Joe Touch In-Reply-To: <20180706151611.GA67496@accordion.employees.org> Date: Sun, 8 Jul 2018 20:33:20 -0700 Cc: tsvwg Content-Transfer-Encoding: quoted-printable Message-Id: <2E639AE9-1F0F-4A48-80FE-7DD974D11BB8@strayalpha.com> References: <153050962153.27521.12163204500355119687@ietfa.amsl.com> <11FA5114-93C4-4526-9AC5-B492F984C403@strayalpha.com> <20180706151611.GA67496@accordion.employees.org> To: Derek Fawcus X-Mailer: Apple Mail (2.3445.8.2) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 03:33:27 -0000 Hi, Derek, The 8-bit variant uses the exact same algorithm as the 16-bit, except = that it =E2=80=9Cfolds=E2=80=9D the result at the end. So the real = question is whether we need 16 bits of protection or can tolerate 8 to = save space. The only other comparable variant would be IPv4 (which isn=E2=80=99t = used in IPv6); the TCP and UDP header checksums cover the payload as = well as header, so they don=E2=80=99t quite correlate to the use we = need. Joe > On Jul 6, 2018, at 8:16 AM, Derek Fawcus = wrote: >=20 > On Mon, Jul 02, 2018 at 10:26:23AM -0700, Joe Touch wrote: >> Hi Tom,=20 >>=20 >> Yeah - it was to make it 16-bit. Yes, it=E2=80=99s a lot weaker, but = it=E2=80=99s also over a typically much smaller set of bytes. >>=20 >> We can make it longer if that=E2=80=99s consensus. I=E2=80=99ll add = it to the discussion topics. >=20 > Well I've mentioned in the past the my view that it should just use = the common > 16 bit 1s complement algorithm as used in the IP header, TCP header, = UDP header. >=20 > DF >=20 From nobody Mon Jul 9 04:58:13 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91D0130E7D for ; Mon, 9 Jul 2018 04:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7R4kvgt9Rcom for ; Mon, 9 Jul 2018 04:58:04 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37CB3130FB8 for ; Mon, 9 Jul 2018 04:58:02 -0700 (PDT) Received: by accordion.employees.org (Postfix, from userid 1736) id 44BD22D5282; Mon, 9 Jul 2018 11:58:00 +0000 (UTC) Date: Mon, 9 Jul 2018 12:58:00 +0100 From: Derek Fawcus To: tsvwg Message-ID: <20180709115800.GA5413@accordion.employees.org> References: <153050962153.27521.12163204500355119687@ietfa.amsl.com> <11FA5114-93C4-4526-9AC5-B492F984C403@strayalpha.com> <20180706151611.GA67496@accordion.employees.org> <2E639AE9-1F0F-4A48-80FE-7DD974D11BB8@strayalpha.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2E639AE9-1F0F-4A48-80FE-7DD974D11BB8@strayalpha.com> User-Agent: Mutt/1.10.0 (2018-05-17) Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 11:58:07 -0000 On Sun, Jul 08, 2018 at 08:33:20PM -0700, Joe Touch wrote: > > The 8-bit variant uses the exact same algorithm as the 16-bit, except that it “folds” the result at the end. So the real question is whether we need 16 bits of protection or can tolerate 8 to save space. With the proviso that one has to first parse the TLVs to determine the length, or do it on the fly while parsing the TLVs, so one can't use the existing implementation unless one goes for a two pass approach. The other 'variable' in this is additional implentation complexity. As to space, I view the existance of the FRAG option as significantly mitigating that. > The only other comparable variant would be IPv4 (which isn’t used in IPv6); the TCP and UDP header checksums cover the payload as well as header, so they don’t quite correlate to the use we need. What is covered differs, but the algorithm for TCP/UDP/UDP-Lite/DCCP/IPv4 is identical. DF From nobody Mon Jul 9 05:57:56 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181A0130E0C; Mon, 9 Jul 2018 05:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 w4yqnULmQLOT; Mon, 9 Jul 2018 05:57:53 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 11B4C130EFF; Mon, 9 Jul 2018 05:57:53 -0700 (PDT) Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com [66.111.4.228]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 499E71B000DD; Mon, 9 Jul 2018 13:57:46 +0100 (BST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailauth.nyi.internal (Postfix) with ESMTP id 36FC320A41; Mon, 9 Jul 2018 08:57:45 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Mon, 09 Jul 2018 08:57:45 -0400 X-ME-Proxy: X-ME-Sender: Received: from tom-desk.erg.abdn.ac.uk (tom-desk.erg.abdn.ac.uk [137.50.17.12]) by mail.messagingengine.com (Postfix) with ESMTPA id 80EB41029E; Mon, 9 Jul 2018 08:57:44 -0400 (EDT) Date: Mon, 9 Jul 2018 13:58:02 +0100 From: Tom Jones To: Ron Bonica Cc: "draft-leddy-6man-truncate@ietf.org" , "tsvwg@ietf.org" Message-ID: <20180709125801.GA20652@tom-desk.erg.abdn.ac.uk> References: <20180615091758.GA17192@tom-desk.erg.abdn.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [tsvwg] FW: New Version Notification for draft-leddy-6man-truncate-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 12:57:56 -0000 ...snip... > > 3. > > > > 0 1 2 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Option Type | Opt Data Len |T|D|R| Reserved| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Figure 2 > > > > TCP does not carry a length field in its header, instead it uses the total length > > field in IPv4 and the payload length in IPv6, modifying this value may make it > > difficult or impossible for the receiving TCP to find the intended end of > > segment. This option needs to carry enough information to reproduce the > > original payload length field. > > > > I suggest adding the original payload length to the option, like so: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 0 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > +-+-+-+-+ > > | Option Type | Opt Data Len |T|D|R| Reserved| Original Payload Length > > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > +-+-+-+-+ > > > > Figure 2 > > > > This will require increasing the option length from 1 to 3. > > > > Does TCP need to know the Original Payload Length? What would it do with this information if it had it? > > I suspect that there is a good use for this data, but I am curious to know what it is. > TCP needs to be able to reconstruct the segment length from the ip payload length, it does not carry a segment length field itself. If we are going to allow delivery of truncated packets, TCP needs to be able to find the original segment size. In addition, if we use truncate to add padding for pmtud probes we need to know how much padding was added for the probe so we can strip it off and get the original packet back. - [tj] From nobody Mon Jul 9 06:54:31 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A40130FF3 for ; Mon, 9 Jul 2018 06:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 v3FZAXw03Gfh for ; Mon, 9 Jul 2018 06:54:27 -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 0E211130FEB for ; Mon, 9 Jul 2018 06:54:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=MsTrf6/a5bZUoaT553QNhU3GL06rSewhMSW67iNIeuuBV6eiVK/IHs9d78WvCQlYPcoxPSS5lE28+9ujfxiqZzv6vHNRnR4uPoqKUOqCby/3tjlHFMRfkV4VBjFlNo7zJ8GgDSokovPWRby7zixSN2VxV0PfRM/GJn1O+KWOKEA=; 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 10448 invoked from network); 9 Jul 2018 15:47:45 +0200 Received: from i577bcefb.versanet.de (HELO ?192.168.178.24?) (87.123.206.251) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 9 Jul 2018 15:47:44 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <3744DFDF-E9DA-4227-BA3E-194882DBB884@fh-muenster.de> Date: Mon, 9 Jul 2018 15:47:43 +0200 Cc: Gorry Fairhurst , tsvwg-chairs@ietf.org, tsvwg@ietf.org, The IESG , draft-ietf-tsvwg-rfc4960-errata@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <13A3C3D7-4E58-4B98-B6CB-04B8CA01AE59@kuehlewind.net> References: <153053893062.16074.3962132072235903491.idtracker@ietfa.amsl.com> <3744DFDF-E9DA-4227-BA3E-194882DBB884@fh-muenster.de> To: Michael Tuexen X-Mailer: Apple Mail (2.3445.8.2) X-PPP-Message-ID: <20180709134745.10439.81870@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [tsvwg] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-tsvwg-rfc4960-errata-06=3A_=28with_COMMENT=29?= X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 13:54:29 -0000 Hi Michael, see below. > Am 03.07.2018 um 07:51 schrieb Michael Tuexen : >=20 >> On 2. Jul 2018, at 15:42, Mirja K=C3=BChlewind = wrote: >>=20 >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-tsvwg-rfc4960-errata-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-tsvwg-rfc4960-errata/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 > Hi Mirja, >=20 > thanks a lot for the comments. See my answers below: >> 1) sec 3.27.2: >> " o When the endpoint does not transmit data on a given transport >> address, the cwnd of the transport address SHOULD be adjusted to >> max(cwnd/2, 4*MTU) per RTO. At the first cwnd adjustment, the >> ssthresh of the transport address SHOULD be adjusted to the = cwnd." >> This part is still unclear to me. What does adjust "per RTO mean"? I = guess it >> is sufficient to adjust it once after the first RTO without data, no? = Also I >> assume ssthresh is set after the cwnd adjustment? > The idea is that you basically half the cwnd after each RTO until you > reach 4 * MTU. Then you stay at 4 * MTU. So you half it possibly = multiple > times. >=20 > When the idle period ends, you can use slow start to the reach the old > cwnd. So ssthresh is set to cwnd before the initial adjustment. >=20 > I changed the 'New text' to >=20 > o When the endpoint does not transmit data on a given transport > address, the cwnd of the transport address SHOULD be adjusted to > max(cwnd/2, 4*MTU) per RTO. Before the first cwnd adjustment, the > ssthresh of the transport address SHOULD be set to the cwnd. Thanks that resolved most of my confusion=E2=80=A6 The =E2=80=9Eper = RTO=E2=80=9C could also be more clear. Was thinking about proposing = something like =E2=80=9Eafter each RTO if time that is idle=E2=80=9C. = However, not sure that is better and might just be me who was = confused/didn=E2=80=99t read carefully. >>=20 >> 2) sec 3.28.2 >> "An SCTP receiver MUST NOT generate more than one SACK for every >> incoming packet, other than to update the offered window as the >> receiving application consumes new data. When the window opens >> up, an SCTP receiver SHOULD send additional SACK chunks to update >> the window even if no new data is received. The receiver MUST avoid >> sending large bursts of window updates." >> This is also not super well specified now. What is a large burst? >> I would rather like to see something like "The receiver MUST not send = more then >> one window update per RTT." > That would require a timer... You generate these SACKs when the = receiving > application reads data. Assume the receive buffer is full with small > messages and the application starts the read messages at high speed. >=20 > There were stacks sending a window update SACK for each message = delivered. > This is a large burst. Running a timer for sending these SACKs is a = bit > of an overkill, I think. In FreeBSD, a SACK is only sent if at least > a quarter of the receive buffer is freed. This limits the burst to > 4 SACKS which is in tune with the burst mitigation limit used for > SCTP packets containing user data. This is also more than one per RTT. > However, other implementations might do it differently and we wanted > to allow this. >=20 > If you think this is a critical thing, we can work out some strategy. Yes, to me it seems to make sense to at least implement some limit. Why = don=E2=80=99t use just go for =E2=80=9EMUST not send more than 4 window = updates per RTT=E2=80=9C if that is what you do already anyway?=20 >>=20 >> 3) 3.31. >> Would it make sense to then use a different variable, e.g. cwnd_temp = or >> max_send_limit, and not cwnd...? > If you would do that, then you have to explain when to use the new > variable instead of cwnd. I don't think this makes it easier=E2=80=A6 I still find the use of cwnd here confusing. >>=20 >> 4) Text changes in sec 3.35.2. are kind of unclear. I assume the new = text >> should be added at the end of the old text sections...? > Correct. It is actually a new sub section. I have added the new = subsection > header to the "New text:". It reads now >=20 > 7.2.5. Change of Differentiated Services Code Points >=20 > SCTP implementations MAY allow an application to configure the > Differentiated Services Code Point (DSCP) used for sending packets. > If a DSCP change might result in outgoing packets being queued in > different queues, the congestion control parameters for all affected > destination addresses MUST be reset to their initial values. >=20 > Best regards > Michael Thanks! Mirja >>=20 >>=20 >=20 From nobody Mon Jul 9 07:00:47 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023E6130FF5; Mon, 9 Jul 2018 07:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 MlOrniUdM_9m; Mon, 9 Jul 2018 07:00:43 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 60F79130FD7; Mon, 9 Jul 2018 07:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vEG5pPuiumZoDqaiVpjVzYiJd0sN9COUNvqclA4/EEM=; b=ymgquzmQDbjJrQaXHrl5/ASTf Pi0o/fZTdDE3tnF2xESohFkEnodQUD8ZGI941+fWcZqyNoeeaeLVamcGctrU8RUG1q9xyuaRHVTpW eIbVEWHse3pSZTYDP3Ar/tt3fRc2iKTmaWypvxx1OLnbAJTWumqqQQshSsQd0u/csFo5FZWh/V61K YqEcaPxG0/oTGq/oEQTQGKaP0eWGvt5dNP2xa9xzxs9ZvOuOi1TRTSfOSlDWzCIVC7ZosSYP/Hdnn 4g267m7RJj6jarmZ10+PeqBJa8GnuQa334HsV/8o8Igv5LpIkgCe3knyB2hxUSkFiT0jWVky505ih mpqsFbPgw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:50269 helo=[192.168.1.16]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fcWiS-002vsm-Nd; Mon, 09 Jul 2018 10:00:40 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (15F79) In-Reply-To: <20180709125801.GA20652@tom-desk.erg.abdn.ac.uk> Date: Mon, 9 Jul 2018 07:00:36 -0700 Cc: Ron Bonica , "draft-leddy-6man-truncate@ietf.org" , "tsvwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8CB2327F-7CF5-4B6E-B24C-504030753DBF@strayalpha.com> References: <20180615091758.GA17192@tom-desk.erg.abdn.ac.uk> <20180709125801.GA20652@tom-desk.erg.abdn.ac.uk> To: Tom Jones X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] FW: New Version Notification for draft-leddy-6man-truncate-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 14:00:46 -0000 On Jul 9, 2018, at 5:58 AM, Tom Jones wrote: >> Does TCP need to know the Original Payload Length? What would it do with t= his information if it had it? >>=20 >> I suspect that there is a good use for this data, but I am curious to kno= w what it is. >>=20 >=20 > TCP needs to be able to reconstruct the segment length from the ip > payload length, it does not carry a segment length field itself. If we > are going to allow delivery of truncated packets, TCP needs to be able > to find the original segment size. This restores the need but still doesn=E2=80=99t explain why TCP has that ne= ed. Remember that the data in these packets should be discarded anyway, so what w= ould TCP do with this info? Joe= From nobody Mon Jul 9 07:01:36 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B5C130FF4; Mon, 9 Jul 2018 07:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 JA72FDGZ3lbB; Mon, 9 Jul 2018 07:01:27 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 2E12A130FD7; Mon, 9 Jul 2018 07:01:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=mCq2JI/BM/mFkM2l5cCdFNIUoynOXXz4tlHZOsREpps=; b=4sd3KZpFZjvx2BYqXz3xRP/yL xiSKpa88jyvEQN6WHJxmSbz1ZhUHotNW7NKhhQGe/IH3oKADpTDEG10lvUaBsRb1xjINlmDNSDeAc e1Bj3ps62nW3nu+9Q3MWqwqSzXpMoX36dafS0HmHvIlWh07BejuYGLg0uNTuPsKovKvHUogaFzp5Q H2vaunG0AIT2sstbtEvfZ/KjrTXB46u5a4FOXrfoDdSV/Ui5sJRF5cMizWvR9PYzwSTxVSUyYO0/f Ax5ooH9j/EYNnmm4LHlVoTfjQqgyoyTxifJ2jkXNbPhIhCkEE8C7Y1ePsJA3EyOX/z7wJPNHPihZ8 4zjJRcz0w==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:50269 helo=[192.168.1.16]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fcWjA-002vsm-CU; Mon, 09 Jul 2018 10:01:25 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (15F79) In-Reply-To: <8CB2327F-7CF5-4B6E-B24C-504030753DBF@strayalpha.com> Date: Mon, 9 Jul 2018 07:01:20 -0700 Cc: Ron Bonica , "draft-leddy-6man-truncate@ietf.org" , "tsvwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <7A1DEBCC-C311-47D9-B18F-37445E0391DD@strayalpha.com> References: <20180615091758.GA17192@tom-desk.erg.abdn.ac.uk> <20180709125801.GA20652@tom-desk.erg.abdn.ac.uk> <8CB2327F-7CF5-4B6E-B24C-504030753DBF@strayalpha.com> To: Tom Jones X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] FW: New Version Notification for draft-leddy-6man-truncate-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 14:01:30 -0000 > On Jul 9, 2018, at 7:00 AM, Joe Touch wrote: >=20 >=20 >=20 > On Jul 9, 2018, at 5:58 AM, Tom Jones wrote: >=20 >>> Does TCP need to know the Original Payload Length? What would it do with= this information if it had it? >>>=20 >>> I suspect that there is a good use for this data, but I am curious to kn= ow what it is. >>>=20 >>=20 >> TCP needs to be able to reconstruct the segment length from the ip >> payload length, it does not carry a segment length field itself. If we >> are going to allow delivery of truncated packets, TCP needs to be able >> to find the original segment size. >=20 > This restores Restates. =20 > the need but still doesn=E2=80=99t explain why TCP has that need. >=20 > Remember that the data in these packets should be discarded anyway, so wha= t would TCP do with this info? >=20 > Joe From nobody Mon Jul 9 07:14:09 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E13130DC4; Mon, 9 Jul 2018 07:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 7jwg2WDJWQs9; Mon, 9 Jul 2018 07:14:05 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA9A128CF3; Mon, 9 Jul 2018 07:14:04 -0700 (PDT) Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com [66.111.4.228]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 6A0071B002D1; Mon, 9 Jul 2018 15:13:57 +0100 (BST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailauth.nyi.internal (Postfix) with ESMTP id 40DD721CA5; Mon, 9 Jul 2018 10:13:56 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Mon, 09 Jul 2018 10:13:56 -0400 X-ME-Proxy: X-ME-Sender: Received: from tom-desk.erg.abdn.ac.uk (tom-desk.erg.abdn.ac.uk [137.50.17.12]) by mail.messagingengine.com (Postfix) with ESMTPA id 4450E102C8; Mon, 9 Jul 2018 10:13:55 -0400 (EDT) Date: Mon, 9 Jul 2018 15:14:12 +0100 From: Tom Jones To: Joe Touch Cc: Ron Bonica , "draft-leddy-6man-truncate@ietf.org" , "tsvwg@ietf.org" Message-ID: <20180709141412.GA20732@tom-desk.erg.abdn.ac.uk> References: <20180615091758.GA17192@tom-desk.erg.abdn.ac.uk> <20180709125801.GA20652@tom-desk.erg.abdn.ac.uk> <8CB2327F-7CF5-4B6E-B24C-504030753DBF@strayalpha.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8CB2327F-7CF5-4B6E-B24C-504030753DBF@strayalpha.com> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [tsvwg] FW: New Version Notification for draft-leddy-6man-truncate-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 14:14:08 -0000 On Mon, Jul 09, 2018 at 07:00:36AM -0700, Joe Touch wrote: > > > On Jul 9, 2018, at 5:58 AM, Tom Jones wrote: > > >> Does TCP need to know the Original Payload Length? What would it do with this information if it had it? > >> > >> I suspect that there is a good use for this data, but I am curious to know what it is. > >> > > > > TCP needs to be able to reconstruct the segment length from the ip > > payload length, it does not carry a segment length field itself. If we > > are going to allow delivery of truncated packets, TCP needs to be able > > to find the original segment size. > > This restores the need but still doesn’t explain why TCP has that need. > > Remember that the data in these packets should be discarded anyway, so > what would TCP do with this info? Okay I think I understand. I agree, if truncated packets are always discarded at the end host then this information is not worth carrying. I think there is a powerful mechanism here to do path mtu probing for TCP: - Create an IP datagram of known good pmtu size - set the truncate option - add padding. If the path cannot pass this datagram it will truncate removing the padding, but leaving the original datagram. This original datagram could be passed up the stack, really it is as if we only sent the good small datagram. On supported paths, ptmu probing could be done without risking a loss in the tcp congestion controller. For this to be possible the truncate option needs to indicate how large the original (before padding) ip datagram was. - [tj] From nobody Mon Jul 9 07:41:50 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4FCC130E34 for ; Mon, 9 Jul 2018 07:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 UcsShyDkF_ME for ; Mon, 9 Jul 2018 07:41:47 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02E9F130E2F for ; Mon, 9 Jul 2018 07:41:47 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id a132-v6so9801826qkg.3 for ; Mon, 09 Jul 2018 07:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=IEaMUe6NyRrU1jAgvAoxcUVziKIxY2v/ktaqHQa0HGM=; b=xUtIEpW+vGrrx8aYaZyiEXoIeJUa1ZL0vBlAOC2Ok0IBW3hjcNBmIEKwJwrSP8JU6s PhJBmfMer2PBgk/JtMjTDXW+YZXIWAuDhKbvmjwGISZD1oPgScW+SdLkF958sLeg0UO6 WUBXs1epfZe8Lct1ug94QQGZ25dS5ppnHL3iBwy5b0BTg1xueHwjIbVavfsNqHf8HsD9 k1szgEuQhGS6z2IK1ud9CbMXlUrcI4nWrAcgbiUFJru3GJLOqtGm+YANuPYiBhe9hA/T am0ymPtEf8hu6SpeU93CzcSA6yOZqGW0Y006bsEk2Bs8AijLHpafFVsBRma13Mb5QCmp 43/g== 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:content-transfer-encoding; bh=IEaMUe6NyRrU1jAgvAoxcUVziKIxY2v/ktaqHQa0HGM=; b=MUXs9hosNPmsYbd6Tte6TPCwSJYrczLLqT7PNlOMMFDE2Y9kdaJvXb3EXBfrwgwvHx dOla1QXO/X45kHDHug8qe4IzienocYQChnV4oM4u/gaSBCLngAwfSrGK7lH7BNsy/1+B KAxwetyaNW/6jbHMGB6gvRaZxwi7gRfqWfm946YrcQlxMtouUIyIY5IYD3s8gYnJYi5i mqMEqsY76JqNldGgzAtopjfPCmBuZyijOTR1N2xRnyAMwGwP3cG/T2/4oVXXz0CyOjLD QX58AAIYnPjEhgRO/WC6OPanoGOqDrxGifxd7813TH4MvRRJkXuf0jayufXMUb921+St 0/Eg== X-Gm-Message-State: APt69E2DSeuLBVJRPz6B2mBW96B1gUzFikxXt8i4/x+1ZwQkaqMTO/VG JKbNSRt8ATbsj01A2g/0yti3eT9wZwV/MaH0AywZ+g== X-Google-Smtp-Source: AAOMgpd0+mqVwkie6bvruG1CguohP5AFZ2OiIV7/xlk3g7nR+jSXMYK0Wre01CP7vrxdmsPeYtlfeSMHdPHvhpSx+Xw= X-Received: by 2002:ae9:c002:: with SMTP id u2-v6mr17638751qkk.391.1531147305825; Mon, 09 Jul 2018 07:41:45 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:3304:0:0:0:0:0 with HTTP; Mon, 9 Jul 2018 07:41:45 -0700 (PDT) In-Reply-To: <20180709115800.GA5413@accordion.employees.org> References: <153050962153.27521.12163204500355119687@ietfa.amsl.com> <11FA5114-93C4-4526-9AC5-B492F984C403@strayalpha.com> <20180706151611.GA67496@accordion.employees.org> <2E639AE9-1F0F-4A48-80FE-7DD974D11BB8@strayalpha.com> <20180709115800.GA5413@accordion.employees.org> From: Tom Herbert Date: Mon, 9 Jul 2018 07:41:45 -0700 Message-ID: To: Derek Fawcus Cc: tsvwg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 14:41:49 -0000 On Mon, Jul 9, 2018 at 4:58 AM, Derek Fawcus wrote: > On Sun, Jul 08, 2018 at 08:33:20PM -0700, Joe Touch wrote: >> >> The 8-bit variant uses the exact same algorithm as the 16-bit, except th= at it =E2=80=9Cfolds=E2=80=9D the result at the end. So the real question i= s whether we need 16 bits of protection or can tolerate 8 to save space. I don't see that saving a single byte is justified. > > With the proviso that one has to first parse the TLVs to determine the le= ngth, > or do it on the fly while parsing the TLVs, so one can't use the existing > implementation unless one goes for a two pass approach. > Also, it's usually good to process integrity checks and security before other TLVs especially if they have side effects. As I mentioned previously, a four byte fixed header for UDP options that includes type (to differentiate different uses of UDP slack space), length, and 2 byte checksum addresses a lot of issues like this. Overhead of this is about zero since the EOL option byte would be eliminated, and OCS (type byte + one or two checksum bytes) is eliminated as well. > The other 'variable' in this is additional implentation complexity. > As to space, I view the existance of the FRAG option as significantly mit= igating that. > >> The only other comparable variant would be IPv4 (which isn=E2=80=99t use= d in IPv6); the TCP and UDP header checksums cover the payload as well as h= eader, so they don=E2=80=99t quite correlate to the use we need. > > What is covered differs, but the algorithm for TCP/UDP/UDP-Lite/DCCP/IPv4= is identical. > And the implementation for this particular algorithm has been heavily optimized and it's been implemented in hardware many times over. Tom > DF > From nobody Mon Jul 9 08:15:29 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E138D130E06 for ; Mon, 9 Jul 2018 08:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.779 X-Spam-Level: X-Spam-Status: No, score=-1.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_DKIM_INVALID=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=strayalpha.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 vmzobSZWvHGL for ; Mon, 9 Jul 2018 08:15:25 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 85E8E12F295 for ; Mon, 9 Jul 2018 08:15:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0iOaUCE1VvUG7l8jv7IUY0oIH+KaIgV0S0SDMpU8eAQ=; b=PKXONlMPRIzgN+I9mXjAKrped cKL/0mTwqI46jZD4jmEXV50eTeHKb3or2SOJTDOQ09CnTjgaRzlQTpF6S6qVxddyYBBvyLtqV/lVR 7lWzm9zJBFP/xOrbDY7Yv0awRqLzPLq1/BYEkmOcd5PHqJsYwjBkM6pAweddmiRRnLow6m6naQ/QJ jp8WDImnsYWcBY4d8wa3U4lTDF+hMxdfdl5flmKvdTu++HWrXQOM3xmCS2VIU2UacvI6jWj35x4dG 0II2tde+fLS5bYLrcw6Ec0UFaZacH89aB7O3rj1H4GL1uHkPI4hXSCbC0uote15eVEqrc7tjMvves 9zhODQrbQ==; Received: from [::1] (port=39908 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.91) (envelope-from ) id 1fcXsp-0041in-Un; Mon, 09 Jul 2018 11:15:24 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_a6f97156cd517545dcec900635d09965" Date: Mon, 09 Jul 2018 08:15:23 -0700 From: Joe Touch To: Tom Herbert Cc: Derek Fawcus , tsvwg In-Reply-To: References: <153050962153.27521.12163204500355119687@ietfa.amsl.com> <11FA5114-93C4-4526-9AC5-B492F984C403@strayalpha.com> <20180706151611.GA67496@accordion.employees.org> <2E639AE9-1F0F-4A48-80FE-7DD974D11BB8@strayalpha.com> <20180709115800.GA5413@accordion.employees.org> Message-ID: <6792f6a41de4a711c6a07ff37f38a1a3@strayalpha.com> X-Sender: touch@strayalpha.com User-Agent: Roundcube Webmail/1.3.3 X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 15:15:27 -0000 --=_a6f97156cd517545dcec900635d09965 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII On 2018-07-09 07:41, Tom Herbert wrote: > On Mon, Jul 9, 2018 at 4:58 AM, Derek Fawcus > wrote: On Sun, Jul 08, 2018 at 08:33:20PM -0700, Joe Touch wrote: > The 8-bit variant uses the exact same algorithm as the 16-bit, except that it "folds" the result at the end. So the real question is whether we need 16 bits of protection or can tolerate 8 to save space. I don't see that saving a single byte is justified. > With the proviso that one has to first parse the TLVs to determine the length, > or do it on the fly while parsing the TLVs, so one can't use the existing > implementation unless one goes for a two pass approach. Also, it's usually good to process integrity checks and security before other TLVs especially if they have side effects. As I mentioned previously, a four byte fixed header for UDP options That is a completely separate issue that doesn't affect the difference between a 1 and 2 byte OCS checksum. ... > The other 'variable' in this is additional implentation complexity. > As to space, I view the existance of the FRAG option as significantly mitigating that. > > The only other comparable variant would be IPv4 (which isn't used in IPv6); the TCP and UDP header checksums cover the payload as well as header, so they don't quite correlate to the use we need. > What is covered differs, but the algorithm for TCP/UDP/UDP-Lite/DCCP/IPv4 is identical. And the implementation for this particular algorithm has been heavily optimized and it's been implemented in hardware many times over. I am aware (RFC1936). Again, this doesn't change the algorithm. Joe --=_a6f97156cd517545dcec900635d09965 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8


 


On 2018-07-09 07:41, Tom Herbert wrote:

= On Mon, Jul 9, 2018 at 4:58 AM, Derek Fawcus
<dfawcus+lists-tsvwg@employees.org> = wrote:
On Sun, Jul 08, 2018 at 08:33:20PM -0700, Joe Touch wr= ote:

The 8-bit variant uses the exact same algorithm= as the 16-bit, except that it "folds" the result at the end. So the real q= uestion is whether we need 16 bits of protection or can tolerate 8 to save = space.

I don't see that saving a single byte is justified.


With the proviso that one has to first parse th= e TLVs to determine the length,
or do it on the fly while parsing the= TLVs, so one can't use the existing
implementation unless one goes f= or a two pass approach.

Also, it's usually good to process integrity checks and security
befo= re other TLVs especially if they have side effects. As I mentioned
pr= eviously, a four byte fixed header for UDP options
=  
= That is a completely separate issue that doesn't affect the difference betw= een a 1 and 2 byte OCS checksum.
= =2E..
=
The other 'variable' in this is additional implentatio= n complexity.
As to space, I view the existance of the FRAG option as= significantly mitigating that.

The only other comparable variant would be IPv4 (which= isn't used in IPv6); the TCP and UDP header checksums cover the payload as= well as header, so they don't quite correlate to the use we need.
What is covered differs, but the algorithm for TCP/UDP/UDP-Lite/DCCP= /IPv4 is identical.

And the implementation for this particular algorithm has been heavily
= optimized and it's been implemented in hardware many times over.
=  
= I am aware (RFC1936). Again, this doesn't change the algorithm.
=  
= Joe
--=_a6f97156cd517545dcec900635d09965-- From nobody Mon Jul 9 08:17:13 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A7A130E23; Mon, 9 Jul 2018 08:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 AimolClDUQ-R; Mon, 9 Jul 2018 08:17:10 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 239FE12F295; Mon, 9 Jul 2018 08:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/MhKzx+MlD768X0RlMluWT+EuS1FYw2ffOE3m30g4Mk=; b=nmWCTHsIM+VDxG+ygcdnUn/ZP ZS8zAHSrtTVmmk+6Xc4EOiaJfM0s9z1ag8Eno/MsWh8I+GmaETTWPBsyA/CLm2Llv69eSXzGZJqpC PLzCdVO7+cWmCDIXZHVYGOXMCKgGdufjJ2PD0wz6ejUtRNb04iBm1pCTULpZjUl2DdIyH1HED9SCs 0Zkcr5uEh4W7N3elGNjgV3etnrvdU2iEWk+s2amp1GsRg9j9imHK0DUbDMGG7V6jfLH3lJkXfvU0z DUdq/78Ei3mVr7y41N43LNHB3UTft4Wo5rYrZUhiv7vpiFbvJxulL7xI97ZxKxvldGf5pSIAh55yg /jBlBOyhQ==; Received: from [::1] (port=55876 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.91) (envelope-from ) id 1fcXuW-00433b-At; Mon, 09 Jul 2018 11:17:09 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_3735385a386644adbec41a688da7782b" Date: Mon, 09 Jul 2018 08:17:08 -0700 From: Joe Touch To: Tom Jones Cc: Ron Bonica , draft-leddy-6man-truncate@ietf.org, tsvwg@ietf.org In-Reply-To: <20180709141412.GA20732@tom-desk.erg.abdn.ac.uk> References: <20180615091758.GA17192@tom-desk.erg.abdn.ac.uk> <20180709125801.GA20652@tom-desk.erg.abdn.ac.uk> <8CB2327F-7CF5-4B6E-B24C-504030753DBF@strayalpha.com> <20180709141412.GA20732@tom-desk.erg.abdn.ac.uk> Message-ID: <0b1b2318fbd025799e78f955e52eb5e4@strayalpha.com> X-Sender: touch@strayalpha.com User-Agent: Roundcube Webmail/1.3.3 X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] FW: New Version Notification for draft-leddy-6man-truncate-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 15:17:12 -0000 --=_3735385a386644adbec41a688da7782b Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII On 2018-07-09 07:14, Tom Jones wrote: > On Mon, Jul 09, 2018 at 07:00:36AM -0700, Joe Touch wrote: > > On Jul 9, 2018, at 5:58 AM, Tom Jones wrote: > > Does TCP need to know the Original Payload Length? What would it do with this information if it had it? > > I suspect that there is a good use for this data, but I am curious to know what it is. > > TCP needs to be able to reconstruct the segment length from the ip > payload length, it does not carry a segment length field itself. If we > are going to allow delivery of truncated packets, TCP needs to be able > to find the original segment size. This restores the need but still doesn't explain why TCP has that need. Remember that the data in these packets should be discarded anyway, so what would TCP do with this info? Okay I think I understand. I agree, if truncated packets are always discarded at the end host then this information is not worth carrying. I think there is a powerful mechanism here to do path mtu probing for TCP: - Create an IP datagram of known good pmtu size - set the truncate option - add padding. There is no current TCP option for padding, so you'd need to add a new TCP option for that (that might confuse implementations, including middle boxes). Joe --=_3735385a386644adbec41a688da7782b Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8


 


On 2018-07-09 07:14, Tom Jones wrote:

= On Mon, Jul 09, 2018 at 07:00:36AM -0700, Joe Touch wrote:


On Jul 9, 2018, at 5:58 AM, Tom Jones <= ;tom@erg.abdn.ac.uk> wrote:
Does TCP need to know the Original Payload Length? Wha= t would it do with this information if it had it?

I suspect tha= t there is a good use for this data, but I am curious to know what it is.

TCP needs to be able to reconstruct the segment length from the ip payload length, it does not carry a segment length field itself. If we=
are going to allow delivery of truncated packets, TCP needs to be ab= le
to find the original segment size.

This restores the need but still doesn't explain why TCP has that ne= ed.

Remember that the data in these packets should be discarded= anyway, so
what would TCP do with this info?

Okay I think I understand.

I agree, if truncated packets= are always discarded at the end host then
this information is not wo= rth carrying.

I think there is a powerful mechanism here to do= path mtu probing for
TCP:
      =   - Create an IP datagram of known good pmtu size
 &nb= sp;      - set the truncate option
&nbs= p;       - add padding.
=  
= There is no current TCP option for padding, so you'd need to add a new= TCP option for that (that might confuse implementations, including middle = boxes).
=  
= Joe
--=_3735385a386644adbec41a688da7782b-- From nobody Mon Jul 9 08:25:32 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9DD130E42 for ; Mon, 9 Jul 2018 08:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 m2u0CCY7PxdI for ; Mon, 9 Jul 2018 08:25:28 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 D3D04130E3F for ; Mon, 9 Jul 2018 08:25:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=sGYj9slKSBcqkFBYG6cUgWm5m/LIe9+fD8ukEwkXdxk=; b=tnbWFOsuiW3adxeyNQfLicBL9 KaRIsxgpdq97ZOI6lcxHEi46/WPdkGSRZ0lrQ6pHhgw11aQG8puKTl+dgUj3HNyBP0sSuyDh+k3Ox KRynm0E3IeR3MOczGrRzHB687IwGxqKZv8cmK4wDqBkmdtQMTlFv4PFEDmmO/ZaUEQ+ZoZ/L3UOOE o3SzLAW7+Ie8MsY8YWkOITOn9y0Qzbp4bSwQAWT67/lKfm2jl3+YHW1Nrq0Fy58PbeHME0E9+wXg9 aErhoEGJzBwAZixBcE2X++hlY4kaMcQgEZLxfy5fmNj6kebT2f937ghvtjDjPvDrUHiUbj64gE3ke 3Q0nAUuyQ==; Received: from [::1] (port=53716 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.91) (envelope-from ) id 1fcY2Z-004FY6-V5; Mon, 09 Jul 2018 11:25:28 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_a0cdd7017ebec37673a85a9b548c08c9" Date: Mon, 09 Jul 2018 08:25:27 -0700 From: Joe Touch To: Tom Herbert Cc: Derek Fawcus , tsvwg In-Reply-To: References: <153050962153.27521.12163204500355119687@ietfa.amsl.com> <11FA5114-93C4-4526-9AC5-B492F984C403@strayalpha.com> <20180706151611.GA67496@accordion.employees.org> <2E639AE9-1F0F-4A48-80FE-7DD974D11BB8@strayalpha.com> <20180709115800.GA5413@accordion.employees.org> Message-ID: <5dad894866658b310181c0d90d652c0b@strayalpha.com> X-Sender: touch@strayalpha.com User-Agent: Roundcube Webmail/1.3.3 X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 15:25:31 -0000 --=_a0cdd7017ebec37673a85a9b548c08c9 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII FWIW, regarding the size of the fixed header... On 2018-07-09 07:41, Tom Herbert wrote: > On Mon, Jul 9, 2018 at 4:58 AM, Derek Fawcus > ...a four byte fixed header for UDP options that includes > type (to differentiate different uses of UDP slack space), length, and > 2 byte checksum addresses a lot of issues like this. Overhead of this > is about zero since the EOL option byte would be eliminated, and OCS > (type byte + one or two checksum bytes) is eliminated as well. TLV OCS would be either 2 bytes (ID and 1-byte sum) or 3 (ID and 2-byte sum). It wouldn't necessarily need a length, though we could include it anyway and make it 3 or 4 bytes, correspondingly. A fixed header as you propose would need to be at least the same length - OCS (1 or 2 bytes) and 2 bytes for length (I don't think it's appropriate to add option space and then needlessly constrain it). However, there's no "savings" per se of EOL; EOL is used *only* when the sender extends the IP data area beyond where the current UDP header, UDP payload, and UDP options extend. In currently expected cases, this would not need to be present. Note that there's no "quick use" of OCS using length; we *have* to try to parse the options anyway, otherwise we won't restore the option space for LITE. Joe --=_a0cdd7017ebec37673a85a9b548c08c9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

FWIW, regarding the size of the fixed header...

On 2018-07-09 07:41, Tom Herbert wrote:

= On Mon, Jul 9, 2018 at 4:58 AM, Derek Fawcus
...a four byte fixed head= er for UDP options that includes
type (to differentiate different use= s of UDP slack space), length, and
2 byte checksum addresses a lot of= issues like this. Overhead of this
is about zero since the EOL optio= n byte would be eliminated, and OCS
(type byte + one or two checksum = bytes) is eliminated as well.
=  
= TLV OCS would be either 2 bytes (ID and 1-byte sum) or 3 (ID and 2-byte sum= ). It wouldn't necessarily need a length, though we could include it anyway= and make it 3 or 4 bytes, correspondingly.
=  
= A fixed header as you propose would need to be at least the same length - O= CS (1 or 2 bytes) and 2 bytes for length (I don't think it's appropriate to= add option space and then needlessly constrain it).
=  
= However, there's no "savings" per se of EOL; EOL is used *only* when the se= nder extends the IP data area beyond where the current UDP header, UDP payl= oad, and UDP options extend. In currently expected cases, this would n= ot need to be present.
=  
= Note that there's no "quick use" of OCS using length; we *have* to try to p= arse the options anyway, otherwise we won't restore the option space for LI= TE.
=  
= Joe
--=_a0cdd7017ebec37673a85a9b548c08c9-- From nobody Mon Jul 9 09:47:48 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23BD130EAA for ; Mon, 9 Jul 2018 09:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 z-LMo14YplDO for ; Mon, 9 Jul 2018 09:47:45 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 31725130E88 for ; Mon, 9 Jul 2018 09:47:45 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id u62-v6so10032139qkf.9 for ; Mon, 09 Jul 2018 09:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Chj1voiBjFkj5wjnezT9dmvucDyiwghzl1MoS0iMEVE=; b=LAGJ3yj4JzCgAkqT3rhn27EpNuBRXEzTOXagmMd+zolkkqPSmFqgYdczeWMczLlv7Y TrSubI0Zx+2tmZLiOdNg7Y12L/b5L4H3NSE6Kyyr9Wn9hnCso0MDsXagA8N5s0ct56nT 60avmXZfZelg9H6FW2iHCUniSieqpOjdenhPN+zYccjD8HmHufTpbotEEaO/V7LQDg/v GaksPbwr/U8Jka9DLmV+YPfc9WjJX0DkdksCMEGzw7InWv/ZmFaLYF0rO6r0Qazp96xl gAGyfVqR7GZtOmsNQQApFoPWzoEtF9GXN5w9nwM3IpbK0SPWpgPR43NrqB1fe0XYcBy6 Q+9Q== 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=Chj1voiBjFkj5wjnezT9dmvucDyiwghzl1MoS0iMEVE=; b=FOTHZeAqujmA0yhccm9OdNkrplJKVL+AvGcuYDNz7edF0LHqDZeUgxVwKync73abUw B/uc5Au4+nn8WdbeTPGwMalsWAAXo/jKOfaVjZw7bTIorX9wWqDWK1mJsTTiuOoIbR54 gHAg1rmF+qx1fTcTMYtwmtkgbfeq+BbyCu47qDSI8CblcMqT5+iikwY7pypVrvitHIPx M3GNg5uhUHCFVfz4BKx1D7ZU7I7hUQw0tgZIl/O7GY+M+oBCuYx835JSWhaTchwmHj59 da9Nht2Rh1xrpDki2ye8F6yF+bgCPbxzLoROqU7Z51Oe8Pu2D3Tx9+PDsHoQH9+j88c6 SYfA== X-Gm-Message-State: APt69E3j1yvrJyTSjDoOOm/2ZDi0qp5ccPBj2MA3gXyxZzr3S+/yqQ8G 1mnBtjbjY1ng3hy93HglG+gGK3H5PvCKSQKPpEy6nQ== X-Google-Smtp-Source: AAOMgpdVf+Xd+5O8BcEoQRg9oKKBgVXLO9nDy6tdnuuh6A4fqbfACpudNtOCl9ms7Dekjb5THDedUiKugz4sNDPreh8= X-Received: by 2002:ae9:c002:: with SMTP id u2-v6mr18085848qkk.391.1531154864148; Mon, 09 Jul 2018 09:47:44 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:3304:0:0:0:0:0 with HTTP; Mon, 9 Jul 2018 09:47:43 -0700 (PDT) In-Reply-To: <5dad894866658b310181c0d90d652c0b@strayalpha.com> References: <153050962153.27521.12163204500355119687@ietfa.amsl.com> <11FA5114-93C4-4526-9AC5-B492F984C403@strayalpha.com> <20180706151611.GA67496@accordion.employees.org> <2E639AE9-1F0F-4A48-80FE-7DD974D11BB8@strayalpha.com> <20180709115800.GA5413@accordion.employees.org> <5dad894866658b310181c0d90d652c0b@strayalpha.com> From: Tom Herbert Date: Mon, 9 Jul 2018 09:47:43 -0700 Message-ID: To: Joe Touch Cc: Derek Fawcus , tsvwg Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 16:47:47 -0000 On Mon, Jul 9, 2018 at 8:25 AM, Joe Touch wrote: > FWIW, regarding the size of the fixed header... > > On 2018-07-09 07:41, Tom Herbert wrote: > > On Mon, Jul 9, 2018 at 4:58 AM, Derek Fawcus > ...a four byte fixed header for UDP options that includes > type (to differentiate different uses of UDP slack space), length, and > 2 byte checksum addresses a lot of issues like this. Overhead of this > is about zero since the EOL option byte would be eliminated, and OCS > (type byte + one or two checksum bytes) is eliminated as well. > > > TLV OCS would be either 2 bytes (ID and 1-byte sum) or 3 (ID and 2-byte > sum). It wouldn't necessarily need a length, though we could include it > anyway and make it 3 or 4 bytes, correspondingly. > > A fixed header as you propose would need to be at least the same length - > OCS (1 or 2 bytes) and 2 bytes for length (I don't think it's appropriate to > add option space and then needlessly constrain it). > > However, there's no "savings" per se of EOL; EOL is used *only* when the > sender extends the IP data area beyond where the current UDP header, UDP > payload, and UDP options extend. In currently expected cases, this would not > need to be present. > > Note that there's no "quick use" of OCS using length; we *have* to try to > parse the options anyway, otherwise we won't restore the option space for > LITE. Personally, I see no practical value in UDP LITE or including a variant of it in UDP options. Every NIC being deployed today has hardware capabilities to offload full UDP checksum, and there is zero cost to the host stack to use that. Using LITE is actually a complication that will be less efficient. Tom > > Joe From nobody Mon Jul 9 10:55:47 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B10130E65 for ; Mon, 9 Jul 2018 10:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 dk5ZCej0OAAr for ; Mon, 9 Jul 2018 10:55:44 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 C291812F1AC for ; Mon, 9 Jul 2018 10:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=GmD8+2vs2zh+yzGwYRRlivDAso418xpLV1S8e2mtb8g=; b=aryMTeGNjj/cZ2hO1zVNCPVTJ TlJsBBF8SRWH8Ks6AB1UZga09AvjJUuY76lzv9/ag4RceCNpfswSiq+86iUaYS9mX7IefyVkEDV+X q+LwXHZ6rG6GIWhXLP1qLh7/oyEYorUxcuXNxPxOIeLYuGIO5lYU0s/vPQ3Wvb84b5g47dF4vEmao xh66u68zEudUAynY1q42Db0LYfz+6R+RrfC9Ifdwa+icFQFMlTE4ETnvwQOUqCvmP8QsxJEmHEKyC /G6cqnUQZxgA3W3jMrv2qRUg8Dcx9Fb3QOPif/PwXePFGGr2C5ApB+9Y0khMOlJ7Y9qOWht/dfoV4 kqizbJ8dg==; Received: from [::1] (port=51044 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.91) (envelope-from ) id 1fcaNz-00278v-58; Mon, 09 Jul 2018 13:55:43 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_f1f78100970c5b86fd135bf44c934fd6" Date: Mon, 09 Jul 2018 10:55:43 -0700 From: Joe Touch To: Tom Herbert Cc: tsvwg In-Reply-To: References: <153050962153.27521.12163204500355119687@ietfa.amsl.com> <11FA5114-93C4-4526-9AC5-B492F984C403@strayalpha.com> <20180706151611.GA67496@accordion.employees.org> <2E639AE9-1F0F-4A48-80FE-7DD974D11BB8@strayalpha.com> <20180709115800.GA5413@accordion.employees.org> <5dad894866658b310181c0d90d652c0b@strayalpha.com> Message-ID: <4c525ab5f8bf398d47b741bd6e7aed0a@strayalpha.com> X-Sender: touch@strayalpha.com User-Agent: Roundcube Webmail/1.3.3 X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 17:55:47 -0000 --=_f1f78100970c5b86fd135bf44c934fd6 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Keep in mind that LITE is key to making transparent frag/reassembly as well, because LITE data is never interpreted as valid by hosts that don't already support it (in this option's version of that capability). Joe On 2018-07-09 09:47, Tom Herbert wrote: > On Mon, Jul 9, 2018 at 8:25 AM, Joe Touch wrote: > >> FWIW, regarding the size of the fixed header... >> >> On 2018-07-09 07:41, Tom Herbert wrote: >> >> On Mon, Jul 9, 2018 at 4:58 AM, Derek Fawcus >> ...a four byte fixed header for UDP options that includes >> type (to differentiate different uses of UDP slack space), length, and >> 2 byte checksum addresses a lot of issues like this. Overhead of this >> is about zero since the EOL option byte would be eliminated, and OCS >> (type byte + one or two checksum bytes) is eliminated as well. >> >> TLV OCS would be either 2 bytes (ID and 1-byte sum) or 3 (ID and 2-byte >> sum). It wouldn't necessarily need a length, though we could include it >> anyway and make it 3 or 4 bytes, correspondingly. >> >> A fixed header as you propose would need to be at least the same length - >> OCS (1 or 2 bytes) and 2 bytes for length (I don't think it's appropriate to >> add option space and then needlessly constrain it). >> >> However, there's no "savings" per se of EOL; EOL is used *only* when the >> sender extends the IP data area beyond where the current UDP header, UDP >> payload, and UDP options extend. In currently expected cases, this would not >> need to be present. >> >> Note that there's no "quick use" of OCS using length; we *have* to try to >> parse the options anyway, otherwise we won't restore the option space for >> LITE. > > Personally, I see no practical value in UDP LITE or including a > variant of it in UDP options. Every NIC being deployed today has > hardware capabilities to offload full UDP checksum, and there is zero > cost to the host stack to use that. Using LITE is actually a > complication that will be less efficient. > > Tom > >> Joe --=_f1f78100970c5b86fd135bf44c934fd6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Keep in mind that LITE is key to making transparent frag/reassembly as w= ell, because LITE data is never interpreted as valid by hosts that don't al= ready support it (in this option's version of that capability).

Joe

On 2018-07-09 09:47, Tom Herbert wrote:

= On Mon, Jul 9, 2018 at 8:25 AM, Joe Touch <touch@strayalpha.com> wrote:
FWIW, regarding the size of the fixed header...
<= br /> On 2018-07-09 07:41, Tom Herbert wrote:

On Mon, Jul 9, 20= 18 at 4:58 AM, Derek Fawcus
...a four byte fixed header for UDP optio= ns that includes
type (to differentiate different uses of UDP slack s= pace), length, and
2 byte checksum addresses a lot of issues like thi= s. Overhead of this
is about zero since the EOL option byte would be = eliminated, and OCS
(type byte + one or two checksum bytes) is elimin= ated as well.


TLV OCS would be either 2 bytes (ID and 1-b= yte sum) or 3 (ID and 2-byte
sum). It wouldn't necessarily need a len= gth, though we could include it
anyway and make it 3 or 4 bytes, corr= espondingly.

A fixed header as you propose would need to be at = least the same length -
OCS (1 or 2 bytes) and 2 bytes for length (I = don't think it's appropriate to
add option space and then needlessly = constrain it).

However, there's no "savings" per se of EOL; EOL= is used *only* when the
sender extends the IP data area beyond where= the current UDP header, UDP
payload, and UDP options extend. In curr= ently expected cases, this would not
need to be present.

= Note that there's no "quick use" of OCS using length; we *have* to try to parse the options anyway, otherwise we won't restore the option space = for
LITE.

Personally, I see no practical value in UDP LITE or including a
variant of it in UDP options. Every NIC being deployed today has
ha= rdware capabilities to offload full UDP checksum, and there is zero
c= ost to the host stack to use that. Using LITE is actually a
complicat= ion that will be less efficient.

Tom


Joe
--=_f1f78100970c5b86fd135bf44c934fd6-- From nobody Mon Jul 9 13:33:16 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272C3130DE1; Mon, 9 Jul 2018 13:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.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 4Cl8kqfA9_qd; Mon, 9 Jul 2018 13:33:12 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 EDE5A129C6A; Mon, 9 Jul 2018 13:33:11 -0700 (PDT) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w69KTBNQ004133; Mon, 9 Jul 2018 13:33:05 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=CeQB0YfhQz8JHTHDOnamv4VPRGyeag+Gb90PtiKQFfo=; b=F5M0X/u5eYsHgSTMaDu2lIRF89G96SdTYfBFBOUhYFyAnSZ5+x3mRQS3PR30v+1+KkU+ XLqlViE7DGUzKOgQrci9/fCpEMGi8wBabafHzFmmccnbWysvnq4VEeacOmPko7XRg/X9 g6obxvlIOSh5cD3vcetWR2jJnKYAQz8hm4phc+M4JaEbsYJSLLHqX59gxN2M62FKdBti SAVaLM/XxuX3/+28tgoTg1HeyBDPtJISZeBIB/a8Vc8w2TS7ik2CE2B5VjqslrBqKFKh C1h/b46nVauLo1PH4aP+YuwJkYDgMXLRQ/4qAwBCE7YaP2eOEJd7jjtqgojv2+Kb5FDi Kw== Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0015.outbound.protection.outlook.com [207.46.163.15]) by mx0b-00273201.pphosted.com with ESMTP id 2k4d99g6yt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 09 Jul 2018 13:33:05 -0700 Received: from CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) by CO1PR05MB476.namprd05.prod.outlook.com (10.141.72.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.952.14; Mon, 9 Jul 2018 20:33:03 +0000 Received: from CO1PR05MB443.namprd05.prod.outlook.com ([fe80::312a:3c1:f69:c7fb]) by CO1PR05MB443.namprd05.prod.outlook.com ([fe80::312a:3c1:f69:c7fb%13]) with mapi id 15.20.0952.013; Mon, 9 Jul 2018 20:33:03 +0000 From: Ron Bonica To: Tom Jones CC: "draft-leddy-6man-truncate@ietf.org" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] FW: New Version Notification for draft-leddy-6man-truncate-03.txt Thread-Index: AQHUAaHD5P4MUTF86U++/9A7XgU/kqRbS6/wgAFifcCABGIeAIAGuQUQgB88XQCAAH0rwA== Date: Mon, 9 Jul 2018 20:33:03 +0000 Message-ID: References: <20180615091758.GA17192@tom-desk.erg.abdn.ac.uk> <20180709125801.GA20652@tom-desk.erg.abdn.ac.uk> In-Reply-To: <20180709125801.GA20652@tom-desk.erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.300.84 dlp-reaction: no-action x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO1PR05MB476; 7:CXyOqYd0o15201qyTshYpg7+JksUkiIypGPUJhONtR7GYLVLIp4K9fQ2MHG8pWRWp4027jLI4P+qPJ3cPu7GXnGimUXDn/DghZIBQY7QP0hcVqh0wxNntpoH7x8WgV6uEeKkfG1ThjyrgnUvlU/qxDUnWbaNhmlZcmjlvDV9vCVnGv8A2+93szEEVdZRsoLMvTdc+KpEZrU50NRsR6wG2XkCfp3sTHFXalCmymY5fUNm1qjxKZVxg9B34KDNZOo1 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: a9a352e2-6a29-4bf5-0709-08d5e5db2b77 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(130329453890623); BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7153060)(7193020); SRVR:CO1PR05MB476; x-ms-traffictypediagnostic: CO1PR05MB476: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(130329453890623); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231311)(944501410)(52105095)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201703031522075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:CO1PR05MB476; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB476; x-forefront-prvs: 07283408BE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(366004)(376002)(136003)(346002)(13464003)(199004)(189003)(476003)(5660300001)(446003)(7736002)(93886005)(3846002)(6116002)(478600001)(76176011)(296002)(316002)(4326008)(11346002)(7696005)(186003)(25786009)(486006)(54906003)(229853002)(305945005)(86362001)(97736004)(2900100001)(256004)(6916009)(74316002)(14444005)(68736007)(6506007)(81156014)(81166006)(55016002)(8936002)(102836004)(66066001)(99286004)(53546011)(2906002)(8676002)(53936002)(6436002)(26005)(9686003)(15650500001)(105586002)(106356001)(14454004)(5250100002)(6246003)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB476; H:CO1PR05MB443.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: 9vbeO8jKnUOaeXY+XBxFzSGqcMiKbOH5nBXbmn2dAYQ9iAyLKTntOWVNLdOaIeb0UG4QPpW3CW0YTeRduZSIRjVPScKNIU5bZEet2ZSMWjamLZllgtSEBhFmrYbGPjSxfAHoMWg6mU6NjI8IWnTrCCAAV3nApQxFqMN8h39kdCNGHUMQcKl6P7e8pgYUH8ZP99LRWm4ksdBQ05awlYA4purZkHMKWyRqfTBmjT47OcnLt2abolRAZl7cHiTnkqSkD0RHadRvDapfNy5enMR/OcUAjyKwu8k33TS3CKzNfhfDeeuftvvYpYV983m9zr7fOWw40v8yyGJx9/LKm6dSqmx5+yLjWnKhcfh6EN6mEo4= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: a9a352e2-6a29-4bf5-0709-08d5e5db2b77 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2018 20:33:03.0737 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB476 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-09_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807090232 Archived-At: Subject: Re: [tsvwg] FW: New Version Notification for draft-leddy-6man-truncate-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 20:33:14 -0000 Hi Tom, I will wait for you and Joe to converge before changing the draft. However,= if you decide that you need to know the pre-truncation payload length, I c= an do the following: - Add a 16-bit field to both the Truncation Eligible and Truncated Packed o= ptions - On the Truncation Eligible, the value of this field is always zero - When an intermediate node cannot forward a packet that is eligible for tr= uncation due to an MTU issue - Overwrite the Truncation Eligible option with a Truncated Packet option - Copy the Payload Length from the IPv6 header to the new field in the Tru= ncated Packet option - Truncate the packet - Update the Payload Length field in the IPv6 header - Forward the packet towards the destination. Ron > -----Original Message----- > From: Tom Jones > Sent: Monday, July 9, 2018 8:58 AM > To: Ron Bonica > Cc: draft-leddy-6man-truncate@ietf.org; tsvwg@ietf.org > Subject: Re: [tsvwg] FW: New Version Notification for draft-leddy-6man- > truncate-03.txt >=20 >=20 > ...snip... > > > 3. > > > > > > 0 1 2 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Option Type | Opt Data Len |T|D|R| Reserved| > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > Figure 2 > > > > > > TCP does not carry a length field in its header, instead it uses the > > > total length field in IPv4 and the payload length in IPv6, modifying > > > this value may make it difficult or impossible for the receiving TCP > > > to find the intended end of segment. This option needs to carry > > > enough information to reproduce the original payload length field. > > > > > > I suggest adding the original payload length to the option, like so: > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 > > > 4 5 6 7 8 0 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+- > > > +-+-+-+-+ > > > | Option Type | Opt Data Len |T|D|R| Reserved| Original Payload > Length > > > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+- > > > +-+-+-+-+ > > > > > > Figure 2 > > > > > > This will require increasing the option length from 1 to 3. > > > > > > > Does TCP need to know the Original Payload Length? What would it do wit= h > this information if it had it? > > > > I suspect that there is a good use for this data, but I am curious to k= now > what it is. > > >=20 > TCP needs to be able to reconstruct the segment length from the ip payloa= d > length, it does not carry a segment length field itself. If we are going = to allow > delivery of truncated packets, TCP needs to be able to find the original > segment size. >=20 > In addition, if we use truncate to add padding for pmtud probes we need t= o > know how much padding was added for the probe so we can strip it off and > get the original packet back. >=20 > - [tj] From nobody Mon Jul 9 16:44:14 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5AB127332; Mon, 9 Jul 2018 16:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 svyACbJpKZBP; Mon, 9 Jul 2018 16:44:07 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 8B04F130DE9; Mon, 9 Jul 2018 16:44:07 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w69NhqBM029023 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 9 Jul 2018 18:43:52 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Brian E Carpenter , tsvwg@ietf.org Cc: IESG References: <153065022701.5099.10852319899819966685.idtracker@ietfa.amsl.com> <6030538E-9108-4DBA-A8BE-0CE604BFE9D9@fh-muenster.de> <1ebab249-4e1e-72a2-9226-5d561837b19e@nostrum.com> <3beedff4-0c5b-8e39-12f8-cf1abc0ee977@gmail.com> <24170514-9e25-2826-5396-f4409cc729d7@gmail.com> From: Adam Roach Message-ID: Date: Mon, 9 Jul 2018 18:43:47 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: <24170514-9e25-2826-5396-f4409cc729d7@gmail.com> Content-Type: multipart/alternative; boundary="------------06CE988B59D15FF8E866B58C" Content-Language: en-US Archived-At: Subject: Re: [tsvwg] Adam Roach's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 23:44:12 -0000 This is a multi-part message in MIME format. --------------06CE988B59D15FF8E866B58C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I'm not intending to ignore this thread; I'm waiting for Spencer, the sponsoring AD, to have time to catch up on the discussion so far and weigh in. I believe he was offline last week, and I'm sure he's busy catching up at the moment. Speaking to two of the points below: * The three RFCs cited predate the 2016 statement by five to 14 years, which sharply limits its applicability to their respective publications. * There is possibly some subjectivity in what may be construed as a "support document;" however, it's worth noting that eleven of the current fifteen IESG members plus two of the three area review teams reviewers have indicated that they believe the document does not have sufficient archival value to be published as an RFC. I'll also point out that my ballot position (Abstain) is non-blocking, and Spencer is free to move forward with the document (if he so chooses) once he is able to discuss it with the IESG. He and the working group have received my advice, and concurring advice from a large majority of the IESG. How he and you choose to act on it is your own decision. /a On 7/8/18 10:06 PM, Brian E Carpenter wrote: > On 06/07/2018 13:20, Brian E Carpenter wrote: >> On 06/07/2018 01:43, Proshin, Maksim wrote: >>> Hi Adam, >>> >>> >>> I guess support documents are never published. How they could be found and used by developers who are not closely involved in WG work? >> No, they are often published. I can give you several examples that I've been >> somewhat involved in: >> >> http://tools.ietf.org/html/rfc3248 (actually an alternative to a standards track RFC) >> http://tools.ietf.org/html/rfc6294 >> https://tools.ietf.org/html/rfc6436 >> >> I'm not sure why the present one is different, except for being rather long. > BTW, the IESG statement suggests that "support documents" are "such things as > requirements and use cases", and as I understood it at the time, those were > what the IESG was concerned about. Such documents were more or less excluded > by the ANIMA WG charter, for example. We were explicitly told by the AD that > the idea was to prevent wasting WG time. The present document is definitely > not requirements and use cases, and is not time-wasting. In any case, this > is very late in the process to mention this guidance: the work has been done, > with the full knowledge of the AD. > > Brian > >> Brian >> >>> >>> BR, Maxim >>> >>> ________________________________ >>> From: tsvwg on behalf of Adam Roach >>> Sent: Wednesday, July 4, 2018 10:59:16 PM >>> To: Michael Tuexen >>> Cc: Gorry Fairhurst; The IESG; draft-ietf-tsvwg-rfc4960-errata@ietf.org; tsvwg-chairs@ietf.org; tsvwg@ietf.org >>> Subject: Re: [tsvwg] Adam Roach's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) >>> >>> On 7/4/18 12:19 AM, Michael Tuexen wrote: >>>>> On 3. Jul 2018, at 22:37, Adam Roach wrote: >>>>> >>>>> Adam Roach has entered the following ballot position for >>>>> draft-ietf-tsvwg-rfc4960-errata-06: Abstain >>>>> >>>>> 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-tsvwg-rfc4960-errata/ >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> I agree with Ben (and, transitively, the OPSDIR an GENART reviewers). From my >>>>> reading, this document -- while immensely valuable to the working group for >>>>> creation of an RFC 4960 bis document -- has little archival value. The following >>>>> standing guidance from the IESG would seem to be applicable: >>>>> >>>>> https://www.ietf.org/blog/support-documents-ietf-working-groups/ >>>>> >>>>> Like Ben, I'm abstaining on this document. I would ask the working group to >>>>> consider not publishing it in this form, and waiting until a complete bis >>>>> version of the document can be produced. >>>> Just to get a better understanding of your position: >>>> >>>> Are you suggesting either >>>> >>>> (1) To work on RFC4960-bis and once that gets published, publish an RFC4960-errata >>>> which is consistent with RFC4960-bis at a later time. >>>> >>>> or >>>> >>>> (2) To work on RFC4960-bis and just drop this document since there is no archival >>>> value for the reasons why something has changed. Having the changed version >>>> is the important point. >>> I'm suggesting something close to (2), which I hoped the link to >>> https://www.ietf.org/blog/support-documents-ietf-working-groups/ would >>> make clear. >>> >>> /a >>> >>> --------------06CE988B59D15FF8E866B58C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I'm not intending to ignore this thread; I'm waiting for Spencer, the sponsoring AD, to have time to catch up on the discussion so far and weigh in. I believe he was offline last week, and I'm sure he's busy catching up at the moment.

Speaking to two of the points below:
  • The three RFCs cited predate the 2016 statement by five to 14 years, which sharply limits its applicability to their respective publications.

  • There is possibly some subjectivity in what may be construed as a "support document;" however, it's worth noting that eleven of the current fifteen IESG members plus two of the three area review teams reviewers have indicated that they believe the document does not have sufficient archival value to be published as an RFC.

I'll also point out that my ballot position (Abstain) is non-blocking, and Spencer is free to move forward with the document (if he so chooses) once he is able to discuss it with the IESG. He and the working group have received my advice, and concurring advice from a large majority of the IESG. How he and you choose to act on it is your own decision.

/a



On 7/8/18 10:06 PM, Brian E Carpenter wrote:
On 06/07/2018 13:20, Brian E Carpenter wrote:
On 06/07/2018 01:43, Proshin, Maksim wrote:
Hi Adam,


I guess support documents are never published. How they could be found and used by developers who are not closely involved in WG work?
No, they are often published. I can give you several examples that I've been
somewhat involved in:

http://tools.ietf.org/html/rfc3248 (actually an alternative to a standards track RFC)
http://tools.ietf.org/html/rfc6294
https://tools.ietf.org/html/rfc6436

I'm not sure why the present one is different, except for being rather long.
BTW, the IESG statement suggests that "support documents" are "such things as
requirements and use cases", and as I understood it at the time, those were
what the IESG was concerned about. Such documents were more or less excluded
by the ANIMA WG charter, for example. We were explicitly told by the AD that
the idea was to prevent wasting WG time. The present document is definitely
not requirements and use cases, and is not time-wasting. In any case, this
is very late in the process to mention this guidance: the work has been done,
with the full knowledge of the AD.

  Brian

   Brian


BR, Maxim

________________________________
From: tsvwg <tsvwg-bounces@ietf.org> on behalf of Adam Roach <adam@nostrum.com>
Sent: Wednesday, July 4, 2018 10:59:16 PM
To: Michael Tuexen
Cc: Gorry Fairhurst; The IESG; draft-ietf-tsvwg-rfc4960-errata@ietf.org; tsvwg-chairs@ietf.org; tsvwg@ietf.org
Subject: Re: [tsvwg] Adam Roach's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT)

On 7/4/18 12:19 AM, Michael Tuexen wrote:

            
On 3. Jul 2018, at 22:37, Adam Roach <adam@nostrum.com> wrote:

Adam Roach has entered the following ballot position for
draft-ietf-tsvwg-rfc4960-errata-06: Abstain

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-tsvwg-rfc4960-errata/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with Ben (and, transitively, the OPSDIR an GENART reviewers). From my
reading, this document -- while immensely valuable to the working group for
creation of an RFC 4960 bis document -- has little archival value. The following
standing guidance from the IESG would seem to be applicable:

https://www.ietf.org/blog/support-documents-ietf-working-groups/

Like Ben, I'm abstaining on this document. I would ask the working group to
consider not publishing it in this form, and waiting until a complete bis
version of the document can be produced.
Just to get a better understanding of your position:

Are you suggesting either

(1) To work on RFC4960-bis and once that gets published, publish an RFC4960-errata
     which is consistent with RFC4960-bis at a later time.

or

(2) To work on RFC4960-bis and just drop this document since there is no archival
     value for the reasons why something has changed. Having the changed version
     is the important point.
I'm suggesting something close to (2), which I hoped the link to
https://www.ietf.org/blog/support-documents-ietf-working-groups/ would
make clear.

/a



    


--------------06CE988B59D15FF8E866B58C-- From nobody Mon Jul 9 17:11:23 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D04D130EAC; Mon, 9 Jul 2018 17:11:14 -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 36px6DlY-nyu; Mon, 9 Jul 2018 17:11:11 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03E9B130DC7; Mon, 9 Jul 2018 17:11:10 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id j3-v6so14769756pfh.11; Mon, 09 Jul 2018 17:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=sLAjGTXuDd0Hq9PBbNlgBs2aRm0G3wtFSgAXDsKl/tc=; b=bUuq2gbAJkISAm8XDM8OziT2G3FZwfwKdaCOxk0rckwbkAp9Tk8NvL44cvxzHxzZBZ 0IQro1x0kZRNVU3uj0dUlfAxmonX1AbxScZpAD/L5oatfkgWtqzsNAmu0KHzZBv6s3tX oiQBpYHaq68rp8RQwyO5UKCZxJ6+QcnuMinCUSVOZLs72ZOfz75PpKUFFfAYqxqq2Ks/ +rUZNJNK9gBLiUM0hEpubAVGbJfgFTIu7Dy+Qo+Szus+CRnASu60iWThEKABWstnyGc3 xPBEquKbYGUbzVnKh/8mYe0YrRpR5vEIAGgUQVh/1QPO7BVc8GG9ZwzkZ8SX1NzVT1XK 0V1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sLAjGTXuDd0Hq9PBbNlgBs2aRm0G3wtFSgAXDsKl/tc=; b=H8i9v7QqTpSmlW3frFOXtRFPhzlrr7UnTeECmNAZOtWMfX+MU3MOfZSREHGtw/dAWi syAZ5b8vnrUMWoPuPY4VJLnL9rw5zvRptCaPOypz6k6mu3rmGJkD0uoOEtwGzpqqG5bq drKp0vRpRnCyMR6977oikKJcWfIGFoUbcMVLTSy5b3aPEDs5CFeskcF22G2RYktfcyjy dsd0kP9MUQ8F3aeExpzko8AuOK0sCbp4+gsHEMJ7MGFtWF0QNzXrhw8FxqWJUlY2ztjP wxsccpnXfnlrJIF9Gmt/tCF/+OIPIzn/u5kLjvY71k8dsurJSIQCNegK7a/R0fa1zNAx 3ZlQ== X-Gm-Message-State: APt69E28Kj/LwGgtcXWw363dOEh2N3m0iieRbhWpTdR3Ab/TM5s30WLA 24nSz4h6ehZvOyxasLeO8tmBbw== X-Google-Smtp-Source: AAOMgpfhT8vJOlKm5TugtTumc99luZfXmNVGVsvCYtnfotLMvR9fmPd/0L54lMeNtoS5R6CQMjPcug== X-Received: by 2002:a62:998:: with SMTP id 24-v6mr21433023pfj.99.1531181470174; Mon, 09 Jul 2018 17:11:10 -0700 (PDT) Received: from [130.216.38.4] (sc-cs-316971.cs.auckland.ac.nz. [130.216.38.4]) by smtp.gmail.com with ESMTPSA id z4-v6sm9639285pfl.11.2018.07.09.17.11.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jul 2018 17:11:08 -0700 (PDT) To: Adam Roach , tsvwg@ietf.org Cc: IESG References: <153065022701.5099.10852319899819966685.idtracker@ietfa.amsl.com> <6030538E-9108-4DBA-A8BE-0CE604BFE9D9@fh-muenster.de> <1ebab249-4e1e-72a2-9226-5d561837b19e@nostrum.com> <3beedff4-0c5b-8e39-12f8-cf1abc0ee977@gmail.com> <24170514-9e25-2826-5396-f4409cc729d7@gmail.com> From: Brian E Carpenter Message-ID: <107094f9-3f91-e823-5801-e30f63779282@gmail.com> Date: Tue, 10 Jul 2018 12:11:06 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] Adam Roach's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 00:11:15 -0000 On 10/07/2018 11:43, Adam Roach wrote: > I'm not intending to ignore this thread; I'm waiting for Spencer, the > sponsoring AD, to have time to catch up on the discussion so far and > weigh in. I believe he was offline last week, and I'm sure he's busy > catching up at the moment. > > Speaking to two of the points below: > > * The three RFCs cited predate the 2016 statement by five to 14 years, > which sharply limits its applicability to their respective publications. True, but the underlying question is whether they have in fact demonstrated archival value (which I don't presume to answer). FWIW I support the IESG guidance on this topic, but it is only guidance. > * There is possibly some subjectivity in what may be construed as a > "support document;" however, it's worth noting that eleven of the > current fifteen IESG members plus two of the three area review teams > reviewers have indicated that they believe the document does not > have sufficient archival value to be published as an RFC. Yes, I see that, and in some sense I might agree, but the deeper issue is not a new one: is it OK for the IESG to second-guess this sort of choice, which we must presume is a WG consensus decision? (The TSVWG chairs have always been pretty careful about the consensus process, IMHO). Regards Brian > I'll also point out that my ballot position (Abstain) is non-blocking, > and Spencer is free to move forward with the document (if he so chooses) > once he is able to discuss it with the IESG. He and the working group > have received my advice, and concurring advice from a large majority of > the IESG. How he and you choose to act on it is your own decision. > > /a > > > > On 7/8/18 10:06 PM, Brian E Carpenter wrote: >> On 06/07/2018 13:20, Brian E Carpenter wrote: >>> On 06/07/2018 01:43, Proshin, Maksim wrote: >>>> Hi Adam, >>>> >>>> >>>> I guess support documents are never published. How they could be found and used by developers who are not closely involved in WG work? >>> No, they are often published. I can give you several examples that I've been >>> somewhat involved in: >>> >>> http://tools.ietf.org/html/rfc3248 (actually an alternative to a standards track RFC) >>> http://tools.ietf.org/html/rfc6294 >>> https://tools.ietf.org/html/rfc6436 >>> >>> I'm not sure why the present one is different, except for being rather long. >> BTW, the IESG statement suggests that "support documents" are "such things as >> requirements and use cases", and as I understood it at the time, those were >> what the IESG was concerned about. Such documents were more or less excluded >> by the ANIMA WG charter, for example. We were explicitly told by the AD that >> the idea was to prevent wasting WG time. The present document is definitely >> not requirements and use cases, and is not time-wasting. In any case, this >> is very late in the process to mention this guidance: the work has been done, >> with the full knowledge of the AD. >> >> Brian >> >>> Brian >>> >>>> >>>> BR, Maxim >>>> >>>> ________________________________ >>>> From: tsvwg on behalf of Adam Roach >>>> Sent: Wednesday, July 4, 2018 10:59:16 PM >>>> To: Michael Tuexen >>>> Cc: Gorry Fairhurst; The IESG; draft-ietf-tsvwg-rfc4960-errata@ietf.org; tsvwg-chairs@ietf.org; tsvwg@ietf.org >>>> Subject: Re: [tsvwg] Adam Roach's Abstain on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) >>>> >>>> On 7/4/18 12:19 AM, Michael Tuexen wrote: >>>>>> On 3. Jul 2018, at 22:37, Adam Roach wrote: >>>>>> >>>>>> Adam Roach has entered the following ballot position for >>>>>> draft-ietf-tsvwg-rfc4960-errata-06: Abstain >>>>>> >>>>>> 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-tsvwg-rfc4960-errata/ >>>>>> >>>>>> >>>>>> >>>>>> ---------------------------------------------------------------------- >>>>>> COMMENT: >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> I agree with Ben (and, transitively, the OPSDIR an GENART reviewers). From my >>>>>> reading, this document -- while immensely valuable to the working group for >>>>>> creation of an RFC 4960 bis document -- has little archival value. The following >>>>>> standing guidance from the IESG would seem to be applicable: >>>>>> >>>>>> https://www.ietf.org/blog/support-documents-ietf-working-groups/ >>>>>> >>>>>> Like Ben, I'm abstaining on this document. I would ask the working group to >>>>>> consider not publishing it in this form, and waiting until a complete bis >>>>>> version of the document can be produced. >>>>> Just to get a better understanding of your position: >>>>> >>>>> Are you suggesting either >>>>> >>>>> (1) To work on RFC4960-bis and once that gets published, publish an RFC4960-errata >>>>> which is consistent with RFC4960-bis at a later time. >>>>> >>>>> or >>>>> >>>>> (2) To work on RFC4960-bis and just drop this document since there is no archival >>>>> value for the reasons why something has changed. Having the changed version >>>>> is the important point. >>>> I'm suggesting something close to (2), which I hoped the link to >>>> https://www.ietf.org/blog/support-documents-ietf-working-groups/ would >>>> make clear. >>>> >>>> /a >>>> >>>> > > From nobody Mon Jul 9 18:26:38 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5AE6130ECE; Mon, 9 Jul 2018 18:26:36 -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 hljwXxE6OftJ; Mon, 9 Jul 2018 18:26:35 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 797DE130EB7; Mon, 9 Jul 2018 18:26:35 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E0858B80CF0; Mon, 9 Jul 2018 18:26:34 -0700 (PDT) To: j.pourtet@gmail.com, randall@lakerest.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: spencerdawkins.ietf@gmail.com, iesg@ietf.org, tsvwg@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180710012634.E0858B80CF0@rfc-editor.org> Date: Mon, 9 Jul 2018 18:26:34 -0700 (PDT) Archived-At: Subject: [tsvwg] [Errata Rejected] RFC4960 (4876) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 01:26:37 -0000 The following errata report has been rejected for RFC4960, "Stream Control Transmission Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid4876 -------------------------------------- Status: Rejected Type: Technical Reported by: Julien Pourtet Date Reported: 2016-12-01 Rejected by: Spencer Dawkins (IESG) Section: 5.1.5. Original Text ------------- 3) Compare the port numbers and the Verification Tag contained within the COOKIE ECHO chunk to the actual port numbers and the Verification Tag within the SCTP common header of the received packet. If these values do not match, the packet MUST be silently discarded. Corrected Text -------------- 3) Compare the port numbers and the Verification Tag contained within the TCB data carried in the State Cookie to the actual port numbers and the Verification Tag within the SCTP common header of the received packet. If these values do not match, the packet MUST be silently discarded. Notes ----- The comparison has to be performed between the values found in the SCTP common header and what is inside the TCB carried in the State Cookie. The current phrasing can lead to think that there are Verifcation Tag and port number fields within the COOKIE ECHO chunk yet outside the State Cookie. --VERIFIER NOTES-- This errata was withdrawn by the submitter, and was not included in draft-ietf-tsvwg-rfc4960-errata. -------------------------------------- RFC4960 (draft-ietf-tsvwg-2960bis-05) -------------------------------------- Title : Stream Control Transmission Protocol Publication Date : September 2007 Author(s) : R. Stewart, Ed. Category : PROPOSED STANDARD Source : Transport Area Working Group Area : Transport Stream : IETF Verifying Party : IESG From nobody Mon Jul 9 18:29:41 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97AEF130ED0; Mon, 9 Jul 2018 18:29:35 -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 DxqLuql6I4GU; Mon, 9 Jul 2018 18:29:33 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2946D130ECE; Mon, 9 Jul 2018 18:29:33 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A5708B80EC8; Mon, 9 Jul 2018 18:29:32 -0700 (PDT) To: lionel.morand@orange.com, randall@lakerest.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: spencerdawkins.ietf@gmail.com, iesg@ietf.org, tsvwg@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180710012932.A5708B80EC8@rfc-editor.org> Date: Mon, 9 Jul 2018 18:29:32 -0700 (PDT) Archived-At: Subject: [tsvwg] [Errata Verified] RFC4960 (4656) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 01:29:36 -0000 The following errata report has been verified for RFC4960, "Stream Control Transmission Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid4656 -------------------------------------- Status: Verified Type: Technical Reported by: Lionel Morand Date Reported: 2016-04-06 Verified by: Spencer Dawkins (IESG) Section: GLOBAL Original Text ------------- 6.2. Acknowledgement on Reception of DATA Chunks The SCTP endpoint MUST always acknowledge the reception of each valid DATA chunk when the DATA chunk received is inside its receive window. When the receiver's advertised window is 0, the receiver MUST drop any new incoming DATA chunk with a TSN larger than the largest TSN received so far. If the new incoming DATA chunk holds a TSN value less than the largest TSN received so far, then the receiver SHOULD drop the largest TSN held for reordering and accept the new incoming DATA chunk. In either case, if such a DATA chunk is dropped, the receiver MUST immediately send back a SACK with the current receive window showing only DATA chunks received and accepted so far. The dropped DATA chunk(s) MUST NOT be included in the SACK, as they were not accepted. The receiver MUST also have an algorithm for advertising its receive window to avoid receiver silly window syndrome (SWS), as described in [RFC0813]. The algorithm can be similar to the one described in Section 4.2.3.3 of [RFC1122]. The guidelines on delayed acknowledgement algorithm specified in Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an acknowledgement SHOULD be generated for at least every second packet (not every second DATA chunk) received, and SHOULD be generated within 200 ms of the arrival of any unacknowledged DATA chunk. In some situations, it may be beneficial for an SCTP transmitter to be more conservative than the algorithms detailed in this document allow. However, an SCTP transmitter MUST NOT be more aggressive than the following algorithms allow. An SCTP receiver MUST NOT generate more than one SACK for every incoming packet, other than to update the offered window as the receiving application consumes new data. IMPLEMENTATION NOTE: The maximum delay for generating an acknowledgement may be configured by the SCTP administrator, either statically or dynamically, in order to meet the specific timing requirement of the protocol being carried. An implementation MUST NOT allow the maximum delay to be configured to be more than 500 ms. In other words, an implementation MAY lower this value below 500 ms but MUST NOT raise it above 500 ms. [ remaining of the section unchanged ] *********************************************************************** 15. Suggested SCTP Protocol Parameter Values The following protocol parameters are RECOMMENDED: RTO.Initial - 3 seconds RTO.Min - 1 second RTO.Max - 60 seconds Max.Burst - 4 RTO.Alpha - 1/8 RTO.Beta - 1/4 Valid.Cookie.Life - 60 seconds Association.Max.Retrans - 10 attempts Path.Max.Retrans - 5 attempts (per destination address) Max.Init.Retransmits - 8 attempts HB.interval - 30 seconds HB.Max.Burst - 1 IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to customize some of these protocol parameters (see Section 10). Note: RTO.Min SHOULD be set as recommended above. Corrected Text -------------- 6.2. Acknowledgement on Reception of DATA Chunks The SCTP endpoint MUST always acknowledge the reception of each valid DATA chunk when the DATA chunk received is inside its receive window. When the receiver's advertised window is 0, the receiver MUST drop any new incoming DATA chunk with a TSN larger than the largest TSN received so far. If the new incoming DATA chunk holds a TSN value less than the largest TSN received so far, then the receiver SHOULD drop the largest TSN held for reordering and accept the new incoming DATA chunk. In either case, if such a DATA chunk is dropped, the receiver MUST immediately send back a SACK with the current receive window showing only DATA chunks received and accepted so far. The dropped DATA chunk(s) MUST NOT be included in the SACK, as they were not accepted. The receiver MUST also have an algorithm for advertising its receive window to avoid receiver silly window syndrome (SWS), as described in [RFC0813]. The algorithm can be similar to the one described in Section 4.2.3.3 of [RFC1122]. The guidelines on delayed acknowledgement algorithm specified in Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an acknowledgement SHOULD be generated for at least every second packet (not every second DATA chunk) received, and SHOULD be generated within 200 ms of the arrival of any unacknowledged DATA chunk. In some situations, it may be beneficial for an SCTP transmitter to be more conservative than the algorithms detailed in this document allow. However, an SCTP transmitter MUST NOT be more aggressive than the following algorithms allow. An SCTP receiver MUST NOT generate more than one SACK for every incoming packet, other than to update the offered window as the receiving application consumes new data. IMPLEMENTATION NOTE: The maximum delay for generating an acknowledgement may be configured by the SCTP administrator, either statically or dynamically, in order to meet the specific timing requirement of the protocol being carried. An implementation MUST NOT allow the maximum delay (protocol parameter 'SACK.Delay') to be configured to be more than 500 ms. In other words, an implementation MAY lower the value of 'SACK.Delay' below 500 ms but MUST NOT raise it above 500 ms. [ remaining of the section unchanged ] *********************************************************************** 15. Suggested SCTP Protocol Parameter Values The following protocol parameters are RECOMMENDED: RTO.Initial - 3 seconds RTO.Min - 1 second RTO.Max - 60 seconds Max.Burst - 4 RTO.Alpha - 1/8 RTO.Beta - 1/4 Valid.Cookie.Life - 60 seconds Association.Max.Retrans - 10 attempts Path.Max.Retrans - 5 attempts (per destination address) Max.Init.Retransmits - 8 attempts HB.interval - 30 seconds HB.Max.Burst - 1 SACK.Delay - 200 milliseconds IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to customize some of these protocol parameters (see Section 10). Note: RTO.Min SHOULD be set as recommended above. Notes ----- In section 6.2, the name 'SACK.Delay' is given to the protocol parameter that indicate themaximum delay for generating a SACK. In section 15, the list of SCTP protocol parameters and associated recommended value is not complete. The maximum delay for generating an acknowledgement ('SACK.Delay') is missing from this list. -------------------------------------- RFC4960 (draft-ietf-tsvwg-2960bis-05) -------------------------------------- Title : Stream Control Transmission Protocol Publication Date : September 2007 Author(s) : R. Stewart, Ed. Category : PROPOSED STANDARD Source : Transport Area Working Group Area : Transport Stream : IETF Verifying Party : IESG From nobody Mon Jul 9 18:31:54 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC3C130ECE; Mon, 9 Jul 2018 18:31:45 -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 166jeFUwF43u; Mon, 9 Jul 2018 18:31:44 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14D51130EB7; Mon, 9 Jul 2018 18:31:44 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 95823B815B4; Mon, 9 Jul 2018 18:31:43 -0700 (PDT) To: ncw@realvnc.com, randall@lakerest.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: spencerdawkins.ietf@gmail.com, iesg@ietf.org, tsvwg@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180710013143.95823B815B4@rfc-editor.org> Date: Mon, 9 Jul 2018 18:31:43 -0700 (PDT) Archived-At: Subject: [tsvwg] [Errata Verified] RFC4960 (5202) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 01:31:46 -0000 The following errata report has been verified for RFC4960, "Stream Control Transmission Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5202 -------------------------------------- Status: Verified Type: Technical Reported by: Nicholas Wilson Date Reported: 2017-12-13 Verified by: Spencer Dawkins (IESG) Section: 3.3.4. Original Text ------------- The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack Block acknowledges a subsequence of TSNs received following a break in the sequence of received TSNs. By definition, all TSNs acknowledged by Gap Ack Blocks are greater than the value of the Cumulative TSN Ack. Corrected Text -------------- The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack Block acknowledges a subsequence of TSNs received following a break in the sequence of received TSNs. By definition, all TSNs acknowledged by Gap Ack Blocks are greater than the value of the Cumulative TSN Ack. The sequence of Gap Ack Blocks MUST be an increasing sequence of ranges, non-intersecting, and with at least one TSN as a gap between each Block and between the Cumulative TSN Ack and the first Block. Notes ----- It seems clear that the Gap Ack sequence must be sent in its "canonical" form (monotonic non-overlapping ranges) but I can't find anywhere where this is actually stated. It is implied (but not stated) by the following sentence on the next page, which implies that there is no freedom of choice in how the Gap Ack sequence is encoded: "For example, assume that ... then the parameter part of the SACK MUST be constructed as follows" -------------------------------------- RFC4960 (draft-ietf-tsvwg-2960bis-05) -------------------------------------- Title : Stream Control Transmission Protocol Publication Date : September 2007 Author(s) : R. Stewart, Ed. Category : PROPOSED STANDARD Source : Transport Area Working Group Area : Transport Stream : IETF Verifying Party : IESG From nobody Mon Jul 9 18:32:59 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0303130ECE; Mon, 9 Jul 2018 18:32:57 -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 wN3PrKSMJin4; Mon, 9 Jul 2018 18:32:56 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CEC8130EB7; Mon, 9 Jul 2018 18:32:56 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BFA4DB816B9; Mon, 9 Jul 2018 18:32:55 -0700 (PDT) To: maxbot1539@gmail.com, randall@lakerest.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: spencerdawkins.ietf@gmail.com, iesg@ietf.org, tsvwg@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180710013255.BFA4DB816B9@rfc-editor.org> Date: Mon, 9 Jul 2018 18:32:55 -0700 (PDT) Archived-At: Subject: [tsvwg] [Errata Verified] RFC4960 (5003) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 01:32:58 -0000 The following errata report has been verified for RFC4960, "Stream Control Transmission Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5003 -------------------------------------- Status: Verified Type: Editorial Reported by: Max Mattes Date Reported: 2017-04-24 Verified by: Spencer Dawkins (IESG) Section: 10.1 Original Text ------------- o Receive Unacknowledged Message Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer size, [,stream id] [, stream sequence number] [,partial flag] [,payload protocol-id]) Corrected Text -------------- O) Receive Unacknowledged Message Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer size, [,stream id] [, stream sequence number] [,partial flag] [,payload protocol-id]) Notes ----- This is part of a lettered list of items, and surrounding sublists use lowercase "o" as a bullet. This item appears to have been mis-corrected to an "o" sublist item when it should be item "O)" of the primary list, as evidenced by the preceding item "N)" and following "P)" -------------------------------------- RFC4960 (draft-ietf-tsvwg-2960bis-05) -------------------------------------- Title : Stream Control Transmission Protocol Publication Date : September 2007 Author(s) : R. Stewart, Ed. Category : PROPOSED STANDARD Source : Transport Area Working Group Area : Transport Stream : IETF Verifying Party : IESG From nobody Mon Jul 9 18:36:19 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17ABF130ECE; Mon, 9 Jul 2018 18:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, 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 5HhHNHQtF1cI; Mon, 9 Jul 2018 18:36:05 -0700 (PDT) Received: from mail-yb0-x244.google.com (mail-yb0-x244.google.com [IPv6:2607:f8b0:4002:c09::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 4D78E130EB7; Mon, 9 Jul 2018 18:36:05 -0700 (PDT) Received: by mail-yb0-x244.google.com with SMTP id y11-v6so7979709ybm.7; Mon, 09 Jul 2018 18:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3ubPrA8Y715x90yD/KaaMUXIKFnAresIwSb13t8EWYA=; b=RiCbb4hr1Dm9azbDAbHJMz6WrTXLOn8THOwPeQs2AJLhNdvkH9L8An7GwNm4c/fjtm Fnzrap8jo/6PKw3Oo5oBz/c5755Q7anRsXCxWk46BLQrx8dz8aEL8t4R0GiOVKykrkfk kd9bJrEkRjLR6RALfh8ZsJfyXQw1SU5ufJgyeti0s2Lbpz1kSAF9bfeKX9uVX1D7EP46 1QPXwfx/i4Yf60F341nzy2+0dzF5RESN+ZRga44GTDNKM5vLAZXMy5ZWIE9XcWkNLeW3 W6swdxB+lJ5PtYeCB8pcPF9mYIIcG8yhps7GSNhGDp7LUqzNI4ZBWj2Fw539BRqhA3QR 6KcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3ubPrA8Y715x90yD/KaaMUXIKFnAresIwSb13t8EWYA=; b=nqM9p1ALZtw3JbC/r5IZCwQvHCmdRHp5p7JCwGmBobMSB+xcyKxNq5nfdWdop1X4CS sp/JpSp0vx+c27djLZSJVNS7ObL0iTRVDFlIzCJqlsaxegHOoUpWZlnq7rH9Jf4x4vje c8O4Xl7kNuhWgqF/e4zdivwstZo9hb7s7CFgnR1fJGO/+bUZ8ZkAApOHsIik0mSA2G03 XQ9/kimESeneYa5KTn6nUwKqM3GnQSR1gHGpcj/asZrxdkiitQZZE7ydVuqWQtax6XCq K/3JTwaXukimj5gtUjPAWCESD8oKdxr6gafunc4lY1Y+ycGF1W1zVdQZxP98WgXXLRfo icmA== X-Gm-Message-State: APt69E0NWmdnUbyJuSeSf9hG4XpMe5ecXGFac63Ksh++DpW+nDRsaThz MYzE3rhnUw/cPOq4nQwPwmZChg6AoZJQLjFoaKg= X-Google-Smtp-Source: AAOMgpeI7xeog0oNGnlapvxLc4Vg2kuysp26CfvKdwQAtd0QAzCyzm6sLupBpNToX9GxeunG9vbEe0dm9/VlRZK9oI4= X-Received: by 2002:a25:770e:: with SMTP id s14-v6mr12089161ybc.235.1531186564118; Mon, 09 Jul 2018 18:36:04 -0700 (PDT) MIME-Version: 1.0 References: <153061088467.5086.7684583062561435644.idtracker@ietfa.amsl.com> <9058127E-282C-439F-AF3C-A18FE606B6CA@fh-muenster.de> <36049353-5F2F-482D-AFF2-57C28D07FA02@fh-muenster.de> In-Reply-To: <36049353-5F2F-482D-AFF2-57C28D07FA02@fh-muenster.de> From: Spencer Dawkins at IETF Date: Mon, 9 Jul 2018 20:35:53 -0500 Message-ID: To: Michael Tuexen Cc: Martin Vigoureux , G Fairhurst , tsvwg-chairs , tsvwg@ietf.org, IESG , draft-ietf-tsvwg-rfc4960-errata@ietf.org Content-Type: multipart/alternative; boundary="0000000000003d3c6605709b27d5" Archived-At: Subject: Re: [tsvwg] Martin Vigoureux's No Objection on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 01:36:11 -0000 --0000000000003d3c6605709b27d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Martin, On Tue, Jul 3, 2018 at 9:25 AM Michael Tuexen wrote= : > > On 3. Jul 2018, at 15:16, Martin Vigoureux > wrote: > > > > Hello Michael, > > > > thanks for your feedback. I think we are in line. > Yepp, I think so. > > regarding the wiki, tsvwg has one here: > https://trac.ietf.org/trac/tsvwg/wiki > The problem is how long it will be available. I guess it will be availabl= e > for > the time we will be working on the RFC 4960bis document, but I would pref= er > to have the information available for the time RFC 4960bis is available. > > My comment on a future issue is indeed a bit moot if you plan on > producing the bis rapidly. > I understand and agree. > > > > What I meant to say/ask was whether the 4 "Reported" erratas should be > moved to some other state (Verified/Held For Document Update/Rejected) su= ch > that this draft and the Errata web page be in synch. > When finalising this document I looked them up. Since I have no control > about the official erratas I guess this needs some actions from Spencer..= . > Thank you for raising this issue especially. I've been involved in so few -bis documents that it's never occurred to me to wonder about the errata. I believe the correct new status should be "Verified", because the working group has agreed to the new text (in three of the four cases), and I rejected the fourth as having been withdrawn by the submitter. So now, we should be in sync. Spencer > Best regards > Michael > > > > I'll let Spencer decide on this. > > > > -m > > > > Le 2018-07-03 =C3=A0 13:01, Michael Tuexen a =C3=A9crit : > >>> On 3. Jul 2018, at 11:41, Martin Vigoureux > wrote: > >>> > >>> Martin Vigoureux has entered the following ballot position for > >>> draft-ietf-tsvwg-rfc4960-errata-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 th= is > >>> 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-tsvwg-rfc4960-errata/ > >>> > >>> > >>> > >>> ---------------------------------------------------------------------= - > >>> COMMENT: > >>> ---------------------------------------------------------------------= - > >>> > >>> Hello, > >>> > >>> Thank you for writing down this Document. I see the value of > documenting fixes > >>> to known issues so I support this initiative but I somehow also share > Alexey's > >>> view. I'm not sure an RFC is the best means to achieve that goal. A > living wiki > >>> page would have been more suitable in my opinion. I'm not an expert i= n > that > >> If the IETF provides this and make sure it is available in the future, > >> it is an option. Once we have replaced RFC 4960 by the upcoming RFC > 4960bis, > >> someone might ask why something has change and how... This is what thi= s > >> document can provide. > >>> field, but what if a new issue is uncovered in the future? That would > render > >>> this Document incomplete. Will a new draft be published that Updates > this > >>> Document? > >> No... Once this document is done, we plan to start working on RFC 4960 > bis > >> and that work is pretty easy. Integrate the changes of this document. > >> However, if in that time another issue comes up, we'll fix it, I guess= . > >> However, we try to find a good point of time to do this. > >> We did this once in the past, when we worked on RFC 4460, which is the > >> errata document to RFC 2960 and then published RFC 4960 =3D RFC 2960 + > RFC 4460. > >>> > >>> I am a bit more concerned by the relationship between this document > and the > >>> Erratas for 4960, and by the possible "discrepancy" its publication, > with all > >>> things staying as they are, would introduce. 4 Erratas for 4960 are i= n > Reported > >>> state, yet 3 of these 4 are addressed in this Document. Also, one of > these 3 > >>> has a resolution which differs from the proposed Errata text. Finally= , > only > >>> this errata is referenced by its ID in the Document. Spencer the firs= t > two > >>> points might be more in your hands than in the authors' but I wonder = if > >>> something should be done about it as part of publishing this Document= . > More > >>> details below: > >> I double checked during the IETF LC (some brought this up) and made su= re > >> all erratas reported to the errata web site are covered. The text this > >> document uses might not be the one in the original errata, since the > >> WG might have improved it. But I can not change what the reporter > suggested. > >> I do see the general point. I tried to address all reported erratas in > this > >> document. You can see an overview in > >> > https://github.com/sctplab/rfc4960bis/blob/master/draft-ietf-tsvwg-rfc496= 0-errata.xml#L131 > >> However, I don't control the erratas, can only discuss this on the > mailing > >> list and provide some resolution in this document. > >> But things are consistent in my view. > >>> > >>> 3.47. Clarification of Gap Ack Blocks in SACK Chunks > >>> The Errata for this is https://www.rfc-editor.org/errata/eid5202 > >>> The text change proposed by the draft is different than the one > proposed by the > >>> Errata. Note that I am not arguing which one is better. > >> Errata 5202 was reported and targets two things: > >> 1. The gap ack blocks in a SACK should not overlap > >> 2. The gap ack blocks in a SACK should be increasing. > >> It was actually intended the the gap block don't overlap. That was > already > >> clarified in section 3.47 before the errata was filed. > >> However, it was never intended that the gap ack blocks are increasing. > >> That is why there is no text related to this. > >> Errata 5202 was reported on December 13th, 2017. I responded stating t= he > >> above and provided some explanations on the same day to tsvwg@ietf.org= . > >> I don't think we need to use the text provided in that errata. > >> However, I have added > >> This issue was reported as part of an Errata for target=3D"RFC4960"/> with > >> Errata ID 5202. > >> to make things clear. See > >> > https://github.com/sctplab/rfc4960bis/commit/62ec4089c8d6c1598482257aa97e= 872fc5090e0e > >>> > >>> 3.24. SACK.Delay Not Listed as a Protocol Parameter > >>> The Errata for this is https://www.rfc-editor.org/errata/eid4656 > >> Correct. And this is stated in > >> > https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-06#section-3.= 24.1 > >>> > >>> 3.9. Miscellaneous Typos > >>> The Errata for this is https://www.rfc-editor.org/errata/eid5003 > >> Correct. This was already catched and fixed for the next revision: > >> > https://github.com/sctplab/rfc4960bis/commit/b8e4e8c6c558c66dab4530cce1b0= b5af8eea9b0f > >>> > >>> The not discussed Reported errata is > https://www.rfc-editor.org/errata/eid4876 > >> That is correct. It was reported on December 1st, 2016. > >> I responded on December 9th, 2016 to tsvwg@ietf.org that is doesn't > really > >> make sense to me and provided some explanation. > >> On the same day the reporter answered on the mailing list closed with > >> "Please disregard my erratum report." > >> So I don't see any reason for changing RFC 4960 and adding a section t= o > this > >> document to describe it. > >> Best regards > >> Michael > >>> > >>> > > --0000000000003d3c6605709b27d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Martin,=C2=A0

On Tue, Jul 3, 2018 at 9:25 AM Michael Tuexen <tuexen@fh-muenster.de> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">> On 3. Jul 2018, at 15:16, Martin Vigoure= ux <mart= in.vigoureux@nokia.com> wrote:
>
> Hello Michael,
>
> thanks for your feedback. I think we are in line.
Yepp, I think so.
> regarding the wiki, tsvwg has one here: https://trac.ietf.= org/trac/tsvwg/wiki
The problem is how long it will be available. I guess it will be available = for
the time we will be working on the RFC 4960bis document, but I would prefer=
to have the information available for the time RFC 4960bis is available. > My comment on a future issue is indeed a bit moot if you plan on produ= cing the bis rapidly.
I understand and agree.
>
> What I meant to say/ask was whether the 4 "Reported" erratas= should be moved to some other state (Verified/Held For Document Update/Rej= ected) such that this draft and the Errata web page be in synch.
When finalising this document I looked them up. Since I have no control
about the official erratas I guess this needs some actions from Spencer...<= br>

Thank you for raising this issue especi= ally. I've been involved in so few -bis documents that it's never o= ccurred to me to wonder about the errata.=C2=A0

I = believe the correct new status should be "Verified", because the = working group has agreed to the new text (in three of the four cases), and = I rejected the fourth as having been withdrawn by the submitter.=C2=A0

So now, we should be in sync.=C2=A0

Spencer
=C2=A0
Bes= t regards
Michael
>
> I'll let Spencer decide on this.
>
> -m
>
> Le 2018-07-03 =C3=A0 13:01, Michael Tuexen a =C3=A9crit :
>>> On 3. Jul 2018, at 11:41, Martin Vigoureux <martin.vigoureux@nokia.com= > wrote:
>>>
>>> Martin Vigoureux has entered the following ballot position for=
>>> draft-ietf-tsvwg-rfc4960-errata-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.ie= tf.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.ie= tf.org/doc/draft-ietf-tsvwg-rfc4960-errata/
>>>
>>>
>>>
>>> --------------------------------------------------------------= --------
>>> COMMENT:
>>> --------------------------------------------------------------= --------
>>>
>>> Hello,
>>>
>>> Thank you for writing down this Document. I see the value of d= ocumenting fixes
>>> to known issues so I support this initiative but I somehow als= o share Alexey's
>>> view. I'm not sure an RFC is the best means to achieve tha= t goal. A living wiki
>>> page would have been more suitable in my opinion. I'm not = an expert in that
>> If the IETF provides this and make sure it is available in the fut= ure,
>> it is an option. Once we have replaced RFC 4960 by the upcoming RF= C 4960bis,
>> someone might ask why something has change and how... This is what= this
>> document can provide.
>>> field, but what if a new issue is uncovered in the future? Tha= t would render
>>> this Document incomplete. Will a new draft be published that U= pdates this
>>> Document?
>> No... Once this document is done, we plan to start working on RFC = 4960 bis
>> and that work is pretty easy. Integrate the changes of this docume= nt.
>> However, if in that time another issue comes up, we'll fix it,= I guess.
>> However, we try to find a good point of time to do this.
>> We did this once in the past, when we worked on RFC 4460, which is= the
>> errata document to RFC 2960 and then published RFC 4960 =3D RFC 29= 60 + RFC 4460.
>>>
>>> I am a bit more concerned by the relationship between this doc= ument and the
>>> Erratas for 4960, and by the possible "discrepancy" = its publication, with all
>>> things staying as they are, would introduce. 4 Erratas for 496= 0 are in Reported
>>> state, yet 3 of these 4 are addressed in this Document. Also, = one of these 3
>>> has a resolution which differs from the proposed Errata text. = Finally, only
>>> this errata is referenced by its ID in the Document. Spencer t= he first two
>>> points might be more in your hands than in the authors' bu= t I wonder if
>>> something should be done about it as part of publishing this D= ocument. More
>>> details below:
>> I double checked during the IETF LC (some brought this up) and mad= e sure
>> all erratas reported to the errata web site are covered. The text = this
>> document uses might not be the one in the original errata, since t= he
>> WG might have improved it. But I can not change what the reporter = suggested.
>> I do see the general point. I tried to address all reported errata= s in this
>> document. You can see an overview in
>> h= ttps://github.com/sctplab/rfc4960bis/blob/master/draft-ietf-tsvwg-rfc4960-e= rrata.xml#L131
>> However, I don't control the erratas, can only discuss this on= the mailing
>> list and provide some resolution in this document.
>> But things are consistent in my view.
>>>
>>> 3.47.=C2=A0 Clarification of Gap Ack Blocks in SACK Chunks
>>> The Errata for this is https://www.rfc-editor.= org/errata/eid5202
>>> The text change proposed by the draft is different than the on= e proposed by the
>>> Errata. Note that I am not arguing which one is better.
>> Errata 5202 was reported and targets two things:
>> 1. The gap ack blocks in a SACK should not overlap
>> 2. The gap ack blocks in a SACK should be increasing.
>> It was actually intended the the gap block don't overlap. That= was already
>> clarified in section 3.47 before the errata was filed.
>> However, it was never intended that the gap ack blocks are increas= ing.
>> That is why there is no text related to this.
>> Errata 5202 was reported on December 13th, 2017. I responded stati= ng the
>> above and provided some explanations on the same day to tsvwg@ietf.org.
>> I don't think we need to use the text provided in that errata.=
>> However, I have added
>> <t>This issue was reported as part of an Errata for <xref= target=3D"RFC4960"/> with
>> Errata ID 5202.</t>
>> to make things clear. See
>> https:= //github.com/sctplab/rfc4960bis/commit/62ec4089c8d6c1598482257aa97e872fc509= 0e0e
>>>
>>> 3.24.=C2=A0 SACK.Delay Not Listed as a Protocol Parameter
>>> The Errata for this is https://www.rfc-editor.= org/errata/eid4656
>> Correct. And this is stated in
>> https://tools.= ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-06#section-3.24.1
>>>
>>> 3.9.=C2=A0 Miscellaneous Typos
>>> The Errata for this is https://www.rfc-editor.= org/errata/eid5003
>> Correct. This was already catched and fixed for the next revision:=
>> https:= //github.com/sctplab/rfc4960bis/commit/b8e4e8c6c558c66dab4530cce1b0b5af8eea= 9b0f
>>>
>>> The not discussed Reported errata is https://w= ww.rfc-editor.org/errata/eid4876
>> That is correct. It was reported on December 1st, 2016.
>> I responded on December 9th, 2016 to tsvwg@ietf.org that is doesn't really
>> make sense to me and provided some explanation.
>> On the same day the reporter answered on the mailing list closed w= ith
>> "Please disregard my erratum report."
>> So I don't see any reason for changing RFC 4960 and adding a s= ection to this
>> document to describe it.
>> Best regards
>> Michael
>>>
>>>

--0000000000003d3c6605709b27d5-- From nobody Tue Jul 10 03:11:54 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C461130E33; Tue, 10 Jul 2018 03:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 fCr404OOsIpd; Tue, 10 Jul 2018 03:11:49 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBE55130DD0; Tue, 10 Jul 2018 03:11:48 -0700 (PDT) Received: from [192.168.1.133] (p57BB4637.dip0.t-ipconnect.de [87.187.70.55]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id B4E03721E2826; Tue, 10 Jul 2018 12:11:39 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Michael Tuexen In-Reply-To: <20180710013143.95823B815B4@rfc-editor.org> Date: Tue, 10 Jul 2018 12:11:37 +0200 Cc: ncw@realvnc.com, randall@lakerest.net, tsvwg , The IESG , RFC Errata System Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180710013143.95823B815B4@rfc-editor.org> To: spencerdawkins.ietf@gmail.com X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [tsvwg] [Errata Verified] RFC4960 (5202) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 10:11:53 -0000 > On 10. Jul 2018, at 03:31, RFC Errata System = wrote: >=20 > The following errata report has been verified for RFC4960, > "Stream Control Transmission Protocol".=20 >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5202 >=20 > -------------------------------------- > Status: Verified Hi Spencer, just to be clear: This errata suggests two corrections: (1) Ensure that the gap ack blocks are not overlapping. (2) Ensure that the gap ack blocks are monotonic. The result of the discussion (and therefore what has been included in = https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-06#section-3.4= 7) is the following: * The intention actually was to have the gap blocks isolated. So = accepting (1) is OK. * In some cases you blocks might not be monotonic. This is the same as = with the handling of gap reports in TCP SACK. Therefore (2) is NOT OK. Not sure if this covered by "Verified". Best regards Michael > Type: Technical >=20 > Reported by: Nicholas Wilson > Date Reported: 2017-12-13 > Verified by: Spencer Dawkins (IESG) >=20 > Section: 3.3.4. >=20 > Original Text > ------------- > The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack > Block acknowledges a subsequence of TSNs received following a break > in the sequence of received TSNs. By definition, all TSNs > acknowledged by Gap Ack Blocks are greater than the value of the > Cumulative TSN Ack. >=20 > Corrected Text > -------------- > The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack > Block acknowledges a subsequence of TSNs received following a break > in the sequence of received TSNs. By definition, all TSNs > acknowledged by Gap Ack Blocks are greater than the value of the > Cumulative TSN Ack. >=20 > The sequence of Gap Ack Blocks MUST be an increasing sequence of > ranges, non-intersecting, and with at least one TSN as a gap between > each Block and between the Cumulative TSN Ack and the first Block. >=20 > Notes > ----- > It seems clear that the Gap Ack sequence must be sent in its = "canonical" form (monotonic non-overlapping ranges) but I can't find = anywhere where this is actually stated. >=20 > It is implied (but not stated) by the following sentence on the next = page, which implies that there is no freedom of choice in how the Gap = Ack sequence is encoded: >=20 > "For example, assume that ... > then the parameter part of the SACK MUST be constructed as follows" >=20 > -------------------------------------- > RFC4960 (draft-ietf-tsvwg-2960bis-05) > -------------------------------------- > Title : Stream Control Transmission Protocol > Publication Date : September 2007 > Author(s) : R. Stewart, Ed. > Category : PROPOSED STANDARD > Source : Transport Area Working Group > Area : Transport > Stream : IETF > Verifying Party : IESG >=20 From nobody Tue Jul 10 09:31:16 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77985131010; Tue, 10 Jul 2018 09:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 Tc5ihCbUaBee; Tue, 10 Jul 2018 09:31:06 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83B92130E58; Tue, 10 Jul 2018 09:31:06 -0700 (PDT) Received: from [192.168.1.131] (p57BB4A9F.dip0.t-ipconnect.de [87.187.74.159]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id EFEA6721E280C; Tue, 10 Jul 2018 18:31:00 +0200 (CEST) From: Michael Tuexen Message-Id: <95A2B040-CA97-4712-8C6E-A03551094DED@fh-muenster.de> Content-Type: multipart/signed; boundary="Apple-Mail=_A37318E5-9F84-432C-854C-8E54CAE928EF"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 10 Jul 2018 18:30:58 +0200 In-Reply-To: <13A3C3D7-4E58-4B98-B6CB-04B8CA01AE59@kuehlewind.net> Cc: Gorry Fairhurst , tsvwg-chairs@ietf.org, tsvwg@ietf.org, The IESG , draft-ietf-tsvwg-rfc4960-errata@ietf.org To: "Mirja Kuehlewind (IETF)" References: <153053893062.16074.3962132072235903491.idtracker@ietfa.amsl.com> <3744DFDF-E9DA-4227-BA3E-194882DBB884@fh-muenster.de> <13A3C3D7-4E58-4B98-B6CB-04B8CA01AE59@kuehlewind.net> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [tsvwg] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-tsvwg-rfc4960-errata-06=3A_=28with_COMMENT=29?= X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 16:31:10 -0000 --Apple-Mail=_A37318E5-9F84-432C-854C-8E54CAE928EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mirja, see comments in-line. Best regards Michael > On 9. Jul 2018, at 15:47, Mirja Kuehlewind (IETF) = wrote: >=20 > Hi Michael, >=20 > see below. >=20 >> Am 03.07.2018 um 07:51 schrieb Michael Tuexen = : >>=20 >>> On 2. Jul 2018, at 15:42, Mirja K=C3=BChlewind = wrote: >>>=20 >>> Mirja K=C3=BChlewind has entered the following ballot position for >>> draft-ietf-tsvwg-rfc4960-errata-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-tsvwg-rfc4960-errata/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >> Hi Mirja, >>=20 >> thanks a lot for the comments. See my answers below: >>> 1) sec 3.27.2: >>> " o When the endpoint does not transmit data on a given transport >>> address, the cwnd of the transport address SHOULD be adjusted to >>> max(cwnd/2, 4*MTU) per RTO. At the first cwnd adjustment, the >>> ssthresh of the transport address SHOULD be adjusted to the = cwnd." >>> This part is still unclear to me. What does adjust "per RTO mean"? I = guess it >>> is sufficient to adjust it once after the first RTO without data, = no? Also I >>> assume ssthresh is set after the cwnd adjustment? >> The idea is that you basically half the cwnd after each RTO until you >> reach 4 * MTU. Then you stay at 4 * MTU. So you half it possibly = multiple >> times. >>=20 >> When the idle period ends, you can use slow start to the reach the = old >> cwnd. So ssthresh is set to cwnd before the initial adjustment. >>=20 >> I changed the 'New text' to >>=20 >> o When the endpoint does not transmit data on a given transport >> address, the cwnd of the transport address SHOULD be adjusted to >> max(cwnd/2, 4*MTU) per RTO. Before the first cwnd adjustment, the >> ssthresh of the transport address SHOULD be set to the cwnd. >=20 > Thanks that resolved most of my confusion=E2=80=A6 The =E2=80=9Eper = RTO=E2=80=9C could also be more clear. Was thinking about proposing = something like =E2=80=9Eafter each RTO if time that is idle=E2=80=9C. = However, not sure that is better and might just be me who was = confused/didn=E2=80=99t read carefully. what about using o While the endpoint does not transmit data on a given transport address, the cwnd of the transport address SHOULD be adjusted to max(cwnd/2, 4*MTU) once per RTO. Before the first cwnd adjustment, the ssthresh of the transport address SHOULD be set to the cwnd. The term "idle" is used differently in the document. So I would like to avoid it here. >=20 >>>=20 >>> 2) sec 3.28.2 >>> "An SCTP receiver MUST NOT generate more than one SACK for every >>> incoming packet, other than to update the offered window as the >>> receiving application consumes new data. When the window opens >>> up, an SCTP receiver SHOULD send additional SACK chunks to update >>> the window even if no new data is received. The receiver MUST avoid >>> sending large bursts of window updates." >>> This is also not super well specified now. What is a large burst? >>> I would rather like to see something like "The receiver MUST not = send more then >>> one window update per RTT." >> That would require a timer... You generate these SACKs when the = receiving >> application reads data. Assume the receive buffer is full with small >> messages and the application starts the read messages at high speed. >>=20 >> There were stacks sending a window update SACK for each message = delivered. >> This is a large burst. Running a timer for sending these SACKs is a = bit >> of an overkill, I think. In FreeBSD, a SACK is only sent if at least >> a quarter of the receive buffer is freed. This limits the burst to >> 4 SACKS which is in tune with the burst mitigation limit used for >> SCTP packets containing user data. This is also more than one per = RTT. >> However, other implementations might do it differently and we wanted >> to allow this. >>=20 >> If you think this is a critical thing, we can work out some strategy. >=20 > Yes, to me it seems to make sense to at least implement some limit. = Why don=E2=80=99t use just go for =E2=80=9EMUST not send more than 4 = window updates per RTT=E2=80=9C if that is what you do already anyway?=20= Since FreeBSD does not send more than 4 window updates per T. And T can = be any positive number. It is not tied to RTT. What about=20 The receiver MUST avoid sending a large number of window updates, in = particular large bursts of them. I think this is a better description of the intention. >=20 >>>=20 >>> 3) 3.31. >>> Would it make sense to then use a different variable, e.g. cwnd_temp = or >>> max_send_limit, and not cwnd...? >> If you would do that, then you have to explain when to use the new >> variable instead of cwnd. I don't think this makes it easier=E2=80=A6 >=20 > I still find the use of cwnd here confusing. We debated this a lot. The point is that you want to reduce cwnd = temporarily, not and other variable. So you would do something old_cwnd =3D cwnd if ((flightsize + Max.Burst*MTU) < cwnd) cwnd =3D flightsize + Max.Burst*MTU /* do what ever you want to do with cwnd */ cwnd =3D old_cwnd I guess this pattern is pretty well described with the current text. But not with introducing a new variabel with the reduced value. >=20 >>>=20 >>> 4) Text changes in sec 3.35.2. are kind of unclear. I assume the new = text >>> should be added at the end of the old text sections...? >> Correct. It is actually a new sub section. I have added the new = subsection >> header to the "New text:". It reads now >>=20 >> 7.2.5. Change of Differentiated Services Code Points >>=20 >> SCTP implementations MAY allow an application to configure the >> Differentiated Services Code Point (DSCP) used for sending packets. >> If a DSCP change might result in outgoing packets being queued in >> different queues, the congestion control parameters for all affected >> destination addresses MUST be reset to their initial values. >>=20 >> Best regards >> Michael >=20 >=20 > Thanks! > Mirja >=20 >=20 >>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_A37318E5-9F84-432C-854C-8E54CAE928EF Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQkDCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFojCCBIqgAwIBAgIHF6Qk oQlIMzANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTE0MDUyNzE0NTQwOVoXDTE5MDcwOTIzNTkwMFowgcYxCzAJBgNVBAYTAkRFMRwwGgYDVQQIExNO b3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFjaGhvY2hz Y2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxlMR0wGwYD VQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVlbnN0ZXIu ZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eWyu8GzsIv0iowf2v/9BT0SmCFNX /eyQe5BncOk1j6XIlY5bnNu1S5uBe3uVgekgTh3gJyVNlaoIfCgAjqCrNJIaNQq5fr/S6L8uFeaU O8IF/C4RH5P7f9Hn2GUueEjmJhg9CI3LBAhrfAmEEtNmuVfDycN2MjngwDNxUNRfuXbWxuhkgDqJ 0ztJeayHGhFDrGx88eyStx40xy+0c0OFWdWxzBFQlBRHnl+zRftj3c9qy6BY+/fGaA2vV1oKr3h5 X6eyU1T8YlpP1NDe4bylqAteX01sM2Qciu8UAPnNc7Sb93TQjhCFRVDIS3CdN6AOpwz5YWEld6ey CdmFZ7pvAgMBAAGjggH+MIIB+jASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAR BgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFArzW7zkMYDWNUKJptPDzzfe0d/XMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOBEWNhQGZoLW11ZW5zdGVyLmRlMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0 dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDov L2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYI KwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQDeRwM11kpvuRIPuzWXLapr/ZBtB76V3cuF l45x/Kx0u03yjB4GaBPcxihn4P1z5KhRYkDBMo8HXkOgbL59aF6VdOlCurEgZvghKvUkKOCyWeYx S9rTGPBkbGiNn2ATVuLXzF8rDf50ynAIu3otstOOv+3Ifqi1pzCva1nO64khQA5Gd5/BNyu+YHbW f8ERAf9leu5a7yVI7cv1gCZAHpWJpkUKmfawyY4sAJ2hbGZRBvdACOxrfbuMdSOzPneT2rlmvH+D 7M6DmzVabLYk6UtAxQhldd/T/qsHkWvaWXHt0Eb9STs2Fl03Ls7M3NyLQLhaeR3ysNURYcaEfaB+ lxN+MIIGDTCCBPWgAwIBAgIHG5mIdDexozANBgkqhkiG9w0BAQsFADCBxjELMAkGA1UEBhMCREUx HDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQK ExdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVu dHJhbGUxHTAbBgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBm aC1tdWVuc3Rlci5kZTAeFw0xNjA3MDQwNzA2MTNaFw0xOTA3MDQwNzA2MTNaMHwxCzAJBgNVBAYT AkRFMSAwHgYDVQQKDBdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEyMDAGA1UECwwpRmFjaGJlcmVp Y2ggRWxla3Ryb3RlY2huaWsgdW5kIEluZm9ybWF0aWsxFzAVBgNVBAMMDk1pY2hhZWwgVHVleGVu MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzJoaUG3Zm24XxA/zNg2sbFcL56w8xqMg +X6G7UsYec3YEncnlkw3jgE5nDefos7UVoCA7wPjFTj8AQt5xfpXElnbM45IPy5Ng7g6dS7biGSM VRACPXe1PrjgApRAwwGmCPvALnZXkmKP6Zlf+3VLfz9YWIIaeKu3jFM2Lk6Y3gr5U1l8bjHSawOo WMlfvSsXXLT38zKW7Uz9jS278j0OqHANBPgsE6/LJoCWFInwlvybxhO3nGU7OteUGaPikqzvjLsL YgpHDi0WjMZfVx/UtUSzZ4EJvmJTBeuVwyKnCbrawnfwYPTQQ6VE1OkAzmsMByBbEwJ996RtG//T XCG06QIDAQABo4ICRzCCAkMwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGB rSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTQHa9qhKgSZgCCAPThZkXaEaJ/ dTAfBgNVHSMEGDAWgBQK81u85DGA1jVCiabTw8833tHf1zAgBgNVHREEGTAXgRV0dWV4ZW5AZmgt bXVlbnN0ZXIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Zo LW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAz BggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9maC1tdWVuc3Rl ci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAEj2/6x4kzoCVIiu aaminPrOHxACyoYsmSRjYPQpgW5xRj/FlolO1nG+ZZ11sqTb3TdCGD69ko5/zs8eGKnv/i0VLCHF g1JLfpaxElN5RrR/cqRJrbzKshF9aUkBODF8vlf9BCeimMK3fifjbbWRyxHssfEECffujD7/Yvta NYMO46Roz39lIK2s37IVFq3V5RWzUeTuwpP9t8lOxirOi9eK2OYI/dh0HjR2S5Dr9nMR1dNulrhz jlFxGc+opefGScrRR9Ec0eqTXlbt1Q9UzNIYVS+OGZY8/bBbprwXVTmwSp8dygEULkIaMbLsaTaW 6TehuL8ousPJkL52SOENgSkxggQpMIIEJQIBATCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozAJBgUrDgMCGgUAoIICKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xODA3MTAxNjMwNTlaMCMGCSqGSIb3DQEJBDEWBBSoWN3uT6PArJNAndfQ /9ANtaA/nDCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9y ZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2No dWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UE AxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRl AgcbmYh0N7GjMIHlBgsqhkiG9w0BCRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozANBgkqhkiG9w0BAQEFAASCAQBD32A7iTkibVQ/YVP66GccxFo4yiGOFPk8 r9Y3lajFM9Z35dW7nSZdsnOJi/Et8cx8GPB0snj1jDhqoTYFNvrHwDTWWGmAs7tNAHmsI14wrF3E NXxOiqELsM3UAcE7DhyNJ/Cy4/vq1KmSczRB60rYhFmhqKdWC8GhZoTAnVQ6b655KYSP/0Lpr2RC 532+4s7SFEhghhxqvnydydkvJ2swJgc1VxoqmL5ZBkoRCffvD9MmLSWaaH+0jQbPZaDE7ggpBzuE NVWx3vdV4UHGIfH6/xcBCjisNZgOs3GeqysdQqupzsN5pIzpjALFoFqR0m7HnMfaIQPgr6IF5a4J UpuVAAAAAAAA --Apple-Mail=_A37318E5-9F84-432C-854C-8E54CAE928EF-- From nobody Tue Jul 10 20:37:48 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1423C130EC5 for ; Tue, 10 Jul 2018 20:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 43QJJHz5n6gi for ; Tue, 10 Jul 2018 20:37:44 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 2F632130ECB for ; Tue, 10 Jul 2018 20:37:44 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w6B3WTaG005029; Wed, 11 Jul 2018 04:37:08 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=n0X2iCPaZr6zxC0KoQkYFTkkqG+0fso3tyFZGeL4nmM=; b=ggdHOCB1nycik4l0Dz5K2P2Jyn7C/qz2gKZFKYjKHS2iGkJ+FxUbXnGcVL1JI3pjq9O/ 7eqo/0Hkov2lacH9KmDhLhjkmbKAKqnNRIFWbY/WXymKzrgn2jS/eEhwkUqKsSZQZk8V wJ1Bz8/7AaUNrgm5CvnhPBfP0VtHKhobaUeuve6uY5jUxMex9bVsy8daIp7qfm/5FN74 2EcLzEYj+GFqQG9fv8XSc9MdR+MG3K+zlojWfi2pk5cz8dtfjjpEdoIpRpjs5KbW0SDG v00u2bIIxIGE94+x0TYkPngPKO7xzuVOEOLDFVCd5BQ2bug2G2SNHN9yxtJvApnVAzhS ew== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050095.ppops.net-00190b01. with ESMTP id 2k2par2x8y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Jul 2018 04:37:07 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w6B3ZIgt026079; Tue, 10 Jul 2018 23:37:06 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2k2ruv3th2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 10 Jul 2018 23:37:06 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 10 Jul 2018 23:37:05 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1365.000; Tue, 10 Jul 2018 23:37:05 -0400 From: "Lubashev, Igor" To: Gorry Fairhurst , "tom@erg.abdn.ac.uk" , "tuexen@fh-muenster.de" , "tsvwg@ietf.org" Thread-Topic: Effect of TPB on PLPMTU in draft-ietf-tsvwg-datagram-plpmtud-03 Thread-Index: AdQYuJHqZou2yOBNSVyJkVd+t1SSJg== Date: Wed, 11 Jul 2018 03:37:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.102] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-10_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=998 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807110034 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-10_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=914 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807110033 Archived-At: Subject: [tsvwg] Effect of TPB on PLPMTU in draft-ietf-tsvwg-datagram-plpmtud-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 03:37:47 -0000 This came up in a discussion in QUIC WG. The draft is very useful for its recommendations on the probing aspects of = PLPMTUD. Yet, it seems too "timid" in its recommendations regarding valida= ted (and "not-validated") TPB messages. The draft explicitly forbids TPB setting PLPMTU (even provisionally): "A va= lidated PTB message MAY be used as input to the DPLPMTUD algorithm, but MUS= T NOT be used directly to set the PLPMTU" (section 5.1.5). This seems to b= e in contradiction with section 5.4.3 that implies that a provisional reduc= tion on PMTU is ok for QUIC: "Any reduction in PMTU due to a report contain= ed in an ICMP packet is provisional until QUIC's loss detection algorithm d= etermines that the packet is actually lost" (a quotation from quic-transpor= t). It also recommends discarding PTB messages "where there is insufficien= t ICMP payload" (section 4.3). PTB is a common signal that is acknowledged by the draft and RFC4821 as use= ful for optimal performance. The biggest problem with PTB signals on the I= nternet is not that they are lying but that they do not make it to the send= er. When they do make it to the sender (still a common occurrence), ignori= ng PTBs (or merely using them as a signal to start probing, per section 3.3= ) is likely to drive at least one RTT of data into an MTU blackhole. Malicious PTB messages should be a concern, but if a PLPMTU > PTB_SIZE >=3D= BASE_PMTU (or another value between BASE_PMTU and MAX_PMTU), I think it ma= kes sense to set PLPMTU and PROBED_SIZE to PTB_SIZE (and begin PLPMTUD). T= he upside, the common case, is avoidance of a blackhole for an RTT or more.= The downside, in case of a malicious PTB, is a minor and temporary decrea= se in throughput. As an attack, it seems not worth the attacker's efforts = (especially, if the attacker is powerful enough to fake validated PTBs). I'd go further and claim that there should be such OK_PMTU between BASE_PMT= U and MAX_PMTU to recommend setting PLPMTU =3D PROBED_SIZE =3D PTB_SIZE usi= ng "not-validated" PTB messages, if PLPMTU > PTB_SIZE >=3D OK_PMTU. All o= f the reasons above apply, especially since such PTB messages are common on= the Internet today. ("Not-validated" means that the message cannot be val= idated due to the lack of validating data or an API deficiency; it does not= mean that a message has been proven Invalid.) I am looking forward to feedback on this. - Igor From nobody Wed Jul 11 15:09:40 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F325130EAA for ; Wed, 11 Jul 2018 15:09:38 -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, HTML_MESSAGE=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=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rPxTHIzgnEh for ; Wed, 11 Jul 2018 15:09:35 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6764130E73 for ; Wed, 11 Jul 2018 15:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:MIME-Version:Date:Message-ID: Subject:From:To:Sender:Reply-To:Cc: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=fJcMqEuXo3zaNfnc7qgdhjmm4K2hFBxUr0gx9Zpl7XE=; b=t3MLxg9OCXBtP7Agd/8nv9jC6o /+YZW5hA6bwq48k1WdoKMGDrhToDTZpwuhaIAocLkTktsKTl7fHcCyvEvcJVdgVAVQt9uEfCle/pW 6e4JLYKmOjaCu1vYAVjLI3umCHOKVMInRsq496gXuHvnHsRqsk9oRP0CLaZLCrSbjSyHn8ryiN7s3 wCLapeQ8QUIdPogvZJo12+e777yPyNJYBegNOBlB7E3rffUL5jsBVwKy/FwyS8VR279oJe37oDjCm KrfrO6FyjBQpC0KMRJgwg0fQGdBSERdXovbv6ckLEIJ/8VnY6xYfzsHkgsDpyxAvINfmnrxrELZ+R zpTGwSjw==; Received: from 70.245.199.146.dyn.plus.net ([146.199.245.70]:51054 helo=[192.168.0.4]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1fdNIh-0005Si-UH for tsvwg@ietf.org; Wed, 11 Jul 2018 23:09:33 +0100 To: tsvwg IETF list From: Bob Briscoe Message-ID: <4a939f11-0990-b680-2613-4415822541d8@bobbriscoe.net> Date: Wed, 11 Jul 2018 23:09:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------49CB734C5F95AA3B0932E529" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: [tsvwg] Low Latency Low Loss and Scalable Throughput (L4S) updates X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 22:09:39 -0000 This is a multi-part message in MIME format. --------------49CB734C5F95AA3B0932E529 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Folks, In this IETF cycle we've updated 2 of the 3 tsvwg L4S drafts. And we updated the informational one about interaction with Diffserv (which is still an individual draft). Each has 1 or 2 main changes described below, as well as numerous small updates. Pls use the diff facility for details. Identifying Modified ECN Semantics for Ultra-Low Queuing Delay (L4S); draft-ietf-tsvwg-ecn-l4s-id-03 * Additional requirement for scalable (L4S) congestion controls: MUST NOT detect loss in units of packets (e.g. 3DupACK), instead MUST count in units of time (c.f. RACK). o Rationale is given in a new appendix section A.1.7. Measuring Reordering Tolerance in Time Units . Essentially, it gives certainty to an L4S queue in the network, so it can relax ordering, which removes head-of-line blocking. o I expect to spend a good deal of the allotted presentation slot in Montreal explaining this, 'cos it's powerful but subtle. Or you can read the appendix. * The other main change is a better explanation of the "A.2.3. Faster Convergence at Flow Start" problem. We will be presenting a solution to this called Paced Chirping in ICCRG, which has led to deeper understanding of the problem too. DualQ Coupled AQMs for L4S; draft-ietf-tsvwg-aqm-dualq-coupled-05 * Closed off open issue on defining flexibility for operators to add classifiers. o Essentially, the classifier MUST NOT alter ECN or Diffserv codepoints to reflect its reclassification. Also the draft now contains rules on how an AQM does ECN-marking of reclassified packets given their ECN codepoint will often be unexpected in a particular queue. Interactions between L4S and Diffserv; draft-briscoe-tsvwg-l4s-diffserv-01 * Removed CS5 (application signalling) from list of Diffserv codepoints compatible with the L4S service, 'cos it's used for broadcast video by at least one major vendor. Cheers Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------49CB734C5F95AA3B0932E529 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Folks,

In this IETF cycle we've updated 2 of the 3 tsvwg L4S drafts. And we updated the informational one about interaction with Diffserv (which is still an individual draft). Each has 1 or 2 main changes described below, as well as numerous small updates. Pls use the diff facility for details.

Identifying Modified ECN Semantics for Ultra-Low Queuing Delay (L4S); draft-ietf-tsvwg-ecn-l4s-id-03

  • Additional requirement for scalable (L4S) congestion controls: MUST NOT detect loss in units of packets (e.g. 3DupACK), instead MUST count in units of time (c.f. RACK).
    • Rationale is given in a new appendix section A.1.7.  Measuring Reordering Tolerance in Time Units. Essentially, it gives certainty to an L4S queue in the network, so it can relax ordering, which removes head-of-line blocking.
    • I expect to spend a good deal of the allotted presentation slot in Montreal explaining this, 'cos it's powerful but subtle. Or you can read the appendix.
  • The other main change is a better explanation of the "A.2.3.  Faster Convergence at Flow Start" problem. We will be presenting a solution to this called Paced Chirping in ICCRG, which has led to deeper understanding of the problem too.

DualQ Coupled AQMs for L4S; draft-ietf-tsvwg-aqm-dualq-coupled-05

  • Closed off open issue on defining flexibility for operators to add classifiers.
    • Essentially, the classifier MUST NOT alter ECN or Diffserv codepoints to reflect its reclassification. Also the draft now contains rules on how an AQM does ECN-marking of reclassified packets given their ECN codepoint will often be unexpected in a particular queue.

Interactions between L4S and Diffserv; draft-briscoe-tsvwg-l4s-diffserv-01

  • Removed CS5 (application signalling) from list of Diffserv codepoints compatible with the L4S service, 'cos it's used for broadcast video by at least one major vendor.
Cheers


Bob


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------49CB734C5F95AA3B0932E529-- From nobody Thu Jul 12 00:28:09 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6FC3131084; Thu, 12 Jul 2018 00:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=netapp.onmicrosoft.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 xouEJWh91Xfi; Thu, 12 Jul 2018 00:28:06 -0700 (PDT) Received: from mx62.netapp.com (mx62.netapp.com [IPv6:2620:10a:4003:8000:2306::b]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 418FA13107B; Thu, 12 Jul 2018 00:28:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.51,341,1526367600"; d="asc'?scan'208";a="31781921" Received: from vmwexchts03-prd.hq.netapp.com ([10.122.105.31]) by mx62-out.netapp.com with ESMTP; 12 Jul 2018 00:27:54 -0700 Received: from VMWEXCCAS06-PRD.hq.netapp.com (10.122.105.22) by VMWEXCHTS03-PRD.hq.netapp.com (10.122.105.31) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 12 Jul 2018 00:27:53 -0700 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS06-PRD.hq.netapp.com (10.122.105.22) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Thu, 12 Jul 2018 00:27:53 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VmYFOZ3Z7IPORlHeA3a0DFaq4F65/Qjp/jxFMWBTmoc=; b=d5HsDoS0mK+hqIz+E0Kb9fT9BesPdJGscYQxC0iEmpS7APAR2tLdy2jp+OuQBZ2Unh8X/rlICGT2kQWVNrNpGmGsj526sAdxrz6uuqQFxsPZkC632HVHO5RNgdm9f3OHMSht+h/Q+JaN2KSnrUt70UVrUMbMxXjnzbJ7zM7N7Lk= Received: from MWHPR06MB2830.namprd06.prod.outlook.com (10.175.138.7) by MWHPR06MB3261.namprd06.prod.outlook.com (10.174.248.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.22; Thu, 12 Jul 2018 07:27:51 +0000 Received: from MWHPR06MB2830.namprd06.prod.outlook.com ([fe80::cc2d:b840:31a2:53d0]) by MWHPR06MB2830.namprd06.prod.outlook.com ([fe80::cc2d:b840:31a2:53d0%8]) with mapi id 15.20.0952.017; Thu, 12 Jul 2018 07:27:51 +0000 From: "Eggert, Lars" To: "lpwan@ietf.org" , "tsvwg@ietf.org" CC: "draft-ietf-lpwan-ipv6-static-context-hc@ietf.org" Thread-Topic: draft-ietf-lpwan-ipv6-static-context-hc & ECN Thread-Index: AQHUGbHX10vH2IoOjkyX0iquSzq0rA== Date: Thu, 12 Jul 2018 07:27:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.9.1) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR06MB3261; 7:9l0EsGDDDHdygJka5OijqwuTscGDDGJOMZZorBgUT7tgZweQbjEy3/js8rB9tulOE8n2U9+wpDBL2iNrLbsYZz51KoRgE1uB+6TL/OIuxrjzCgcLerZduoXmaElEScP7x7BeBQegcYXch3NB8puqPuXbQs30+ByxMlgy3Chm67mzvx5bfdrZfVnolEdHV4SCoyWENIQNrwCWlmrzTWuYBDzzK4BWEg2QTPlNC8emPRrntNdhzRclJIcY+x6LhmDV x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 4a61c833-7b83-4766-1d18-08d5e7c8fa0c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(49563074)(7193020); SRVR:MWHPR06MB3261; x-ms-traffictypediagnostic: MWHPR06MB3261: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(8121501046)(5005006)(3231311)(944501410)(52105095)(10201501046)(3002001)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:MWHPR06MB3261; BCL:0; PCL:0; RULEID:; SRVR:MWHPR06MB3261; x-forefront-prvs: 0731AA2DE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(376002)(346002)(39860400002)(396003)(189003)(199004)(82746002)(2900100001)(450100002)(6512007)(57306001)(6436002)(66066001)(4326008)(3846002)(2906002)(305945005)(6116002)(97736004)(6486002)(256004)(7736002)(99936001)(83716003)(68736007)(106356001)(25786009)(81166006)(186003)(105586002)(6506007)(36756003)(2501003)(5250100002)(478600001)(81156014)(2616005)(86362001)(486006)(50226002)(316002)(476003)(110136005)(8676002)(8936002)(26005)(33656002)(53936002)(5660300001)(99286004)(102836004)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR06MB3261; H:MWHPR06MB2830.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: byxjpphZKAJlrK+aPv86VXtSxRrPfc9SnDB5/fEdjy1UigSb84hcQaIV1BhAKN+88qjIeUymyjou+Rru/p4+69D8Aj/DCiurLBd9ZGyX2/8HebL7Q1Z9Fq9B2Y0VqcKInr/MhGA7wqbhlgDMgt8Eo6mZT/mWxvbNabRyKYauZAjSVSNWb6A+tVfY0X8Q4I+0u21Djsw6O0YAw+BCrd5t0dKn7WKljKkAkp0udk8oHAwds35vuazpqe3sJjwmZ5blTnsjg3eFl75HyOkSsWjvEXu+EQMB1J0Jpmxq3/46fvxD8H5KAWrwKdBgt9ftxkYHkIru39ShMW6o4w+ZPqMsFVuJdPcJIg71cgBvvKBadNw= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_E4CCEB59-7E85-49CA-836E-6836EE3B52DE"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4a61c833-7b83-4766-1d18-08d5e7c8fa0c X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2018 07:27:51.6495 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR06MB3261 X-OriginatorOrg: netapp.com Archived-At: Subject: [tsvwg] draft-ietf-lpwan-ipv6-static-context-hc & ECN X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 07:28:08 -0000 --Apple-Mail=_E4CCEB59-7E85-49CA-836E-6836EE3B52DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Section 10.2. (IPv6 Traffic class field) says: > If the DiffServ field does not vary and is known by both sides, the > Field Descriptor in the Rule SHOULD contain a TV with this = well-known > value, an "equal" MO and a "not-sent" CDA. given that the TC field includes the ECN bits, I think this = recommendation is dangerous, since it will cause ECN bleaching. IMO the main recommendation *must* be one of the options below: > Otherwise, two possibilities can be considered depending on the > variability of the value: >=20 > o One possibility is to not compress the field and send the = original > value. In the Rule, TV is not set to any particular value, MO = is > set to "ignore" and CDA is set to "value-sent". >=20 > o If some upper bits in the field are constant and known, a better > option is to only send the LSBs. In the Rule, TV is set to a > value with the stable known upper part, MO is set to MSB(x) and > CDA to LSB(y). Lars PS: I haven't checked whether other related drafts have similar issues. --Apple-Mail=_E4CCEB59-7E85-49CA-836E-6836EE3B52DE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAltHAvYACgkQVLXDCb9w wVcIKA//a0c2movM7tcZSRGq/X/kI9YcBdt6iZbIoJugM0+D1fvnAYJILB7OGqhy awUSWqnDOBH/fd2uZuyWAdsGJmVY4DVEYOO5DvZ6FxcqvkUmY3r1aeWbNZaqJoha 8HpASlAijH+hXdLRkwnDWDTcfbe9etnJ5CRdI5qC0GQH7JkCmcKs6nFqfYl2I00A RbhKebHv/KtdZ+QadvNMVkRd4zNRkM0Tvxg7aqeygKE/MqQGj3jRWuH48D79qXno Kt3sT+fbpN2NSRiZbiHNHRhPVVfk16zPwP06XTorf1GcD1m648etb/Xrm1zDdrwC 5nlVE61B1aydwh5r/MRG+mk4u9d70IXpQjhkYStQdsQINRItR++Fv9duy+gp/Ob1 owgXklKYMrLwlJKm843sFq2DVkw4nX4v3+xCE15e0NZs6yqMPziqWZjZeQD2dID8 bdSX6u8/dpulF24k/9gvoDCVmK0TjQ0m55fAbbh6r90EpzpUVoWL9H9/cM4BD3ak +2+TAb2l51DZyTcbn2nHsDClpnnz9xT8UNPKYXL87mUum40XCyt8VCnKqG8YPy3j Gzf1rRKyi+EzeO8y8gS8nkXtgRHYlQa1r5SN6wAJ2khUWu2wlNgfxIFtrqbSVPKv BCabLBwCSSh0XASg36buqxrWYys9zHOlriRXn4e2OHBWzubVmkg= =VAzu -----END PGP SIGNATURE----- --Apple-Mail=_E4CCEB59-7E85-49CA-836E-6836EE3B52DE-- From nobody Thu Jul 12 00:30:36 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F74C131089; Thu, 12 Jul 2018 00:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=netapp.onmicrosoft.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 ktE6sJ5GMyxH; Thu, 12 Jul 2018 00:30:26 -0700 (PDT) Received: from mx65.netapp.com (mx65.netapp.com [IPv6:2620:10a:4003:8000:2306::e]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39652130E0E; Thu, 12 Jul 2018 00:30:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.51,341,1526367600"; d="asc'?scan'208";a="28323710" Received: from vmwexchts03-prd.hq.netapp.com ([10.122.105.31]) by mx65-out.netapp.com with ESMTP; 12 Jul 2018 00:30:24 -0700 Received: from HIOEXCMBX08-PRD.hq.netapp.com (10.122.105.41) by VMWEXCHTS03-PRD.hq.netapp.com (10.122.105.31) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 12 Jul 2018 00:30:24 -0700 Received: from VMWEXCCAS04-PRD.hq.netapp.com (10.122.105.20) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 12 Jul 2018 00:30:03 -0700 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS04-PRD.hq.netapp.com (10.122.105.20) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Thu, 12 Jul 2018 00:29:42 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LIc7n2RwJOhERYrKcq6TCGZFvmX/tC1QAduZwxZVtGg=; b=qF7MfLgEoaluuQSUHUAUvFJ8D10ZG5SQsJhue3it5i2Ol2oP0HeOkrwOi610mJ3qY2yWk/iLSGr3WWdQXjYSVW5bwN3pdgf9x3PIXQtnjcai74Smsue7uDO/qjm9sKYks1i7wiuHn2ued9F3iEiHfChhIL/z7LNTwhR0V932Gc4= Received: from MWHPR06MB2830.namprd06.prod.outlook.com (10.175.138.7) by MWHPR06MB3261.namprd06.prod.outlook.com (10.174.248.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.22; Thu, 12 Jul 2018 07:29:40 +0000 Received: from MWHPR06MB2830.namprd06.prod.outlook.com ([fe80::cc2d:b840:31a2:53d0]) by MWHPR06MB2830.namprd06.prod.outlook.com ([fe80::cc2d:b840:31a2:53d0%8]) with mapi id 15.20.0952.017; Thu, 12 Jul 2018 07:29:40 +0000 From: "Eggert, Lars" To: "lp-wan@ietf.org" , "tsvwg@ietf.org" CC: "draft-ietf-lpwan-ipv6-static-context-hc@ietf.org" Thread-Topic: draft-ietf-lpwan-ipv6-static-context-hc & ECN Thread-Index: AQHUGbIYZfbBODsDfEaFSCV757twtw== Date: Thu, 12 Jul 2018 07:29:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.9.1) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR06MB3261; 7:GbFagtNpnOAONZwkX0YN3UplXGsF1hZ/1A+URSmJs4kbsdNpt6U6VzCSLIIbdvRq+q/VJNXUrU0iJoLhvGady+Pdp2GTvvjpJ423QAckBfiMvDAm6euEkrZfNV3UCce1VtJgAtZEL6Z7Ylm/56l8kLAe6lLoM9czQfvkFEGYx6ZbmYZP87nbHtxhdxmg2PfoyzdNMHP2JjYaD7O+kp0d2Bg2yCThDGQYcbQ1wPFKYNMRn37PNRrWl3X6WGg+9Cfl x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ec426483-60ac-448c-0ae0-08d5e7c93ab1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(49563074)(7193020); SRVR:MWHPR06MB3261; x-ms-traffictypediagnostic: MWHPR06MB3261: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(8121501046)(5005006)(3231311)(944501410)(52105095)(10201501046)(3002001)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:MWHPR06MB3261; BCL:0; PCL:0; RULEID:; SRVR:MWHPR06MB3261; x-forefront-prvs: 0731AA2DE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(376002)(346002)(39860400002)(396003)(189003)(199004)(82746002)(2900100001)(450100002)(6512007)(57306001)(6436002)(66066001)(4326008)(3846002)(2906002)(305945005)(6116002)(97736004)(6486002)(256004)(7736002)(99936001)(83716003)(68736007)(106356001)(25786009)(81166006)(186003)(105586002)(6506007)(36756003)(2501003)(5250100002)(478600001)(81156014)(2616005)(86362001)(486006)(50226002)(316002)(476003)(110136005)(8676002)(8936002)(26005)(33656002)(53936002)(5660300001)(99286004)(102836004)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR06MB3261; H:MWHPR06MB2830.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: pvYm+3XdwAV0Atj0TKKnc3SW7Qnev1NmD72mb3F4RcmLsJeVyvPCormggg9qpls3lk+sDiEHHotWd0B6O69s1deLtYsQA8Fy3ypMNIGKfAW7U2oJ9gtBYfCRvcqFPKIuwdRTBPNwWBb9rRS75AHr1XiSARbIyp8l1zpnCZWZUMvvVGF382f7fsGmhnGKNsqoSDIXrMGuZOfCx7AHuGjXmzy47/BxseUivG6o4NcDLp+LeUZ0XhzR6DXUomVDT+0vcQN4tn1rvcBLNjn2DJsVPqG8nsFzGLrroUSbRv+8aBjcIIo+mGkb6xz/XCgLZFBqiM5verIxhwVSwP5Hr8BdRwwWbuEzITiAgWTElbRqFVQ= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_ACE9B206-43D9-4BA7-9E94-7B492B82D99A"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ec426483-60ac-448c-0ae0-08d5e7c93ab1 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2018 07:29:40.1146 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR06MB3261 X-OriginatorOrg: netapp.com Archived-At: Subject: [tsvwg] draft-ietf-lpwan-ipv6-static-context-hc & ECN X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 07:30:28 -0000 --Apple-Mail=_ACE9B206-43D9-4BA7-9E94-7B492B82D99A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [Resending with correct address for lp-wan] Hi, Section 10.2. (IPv6 Traffic class field) says: > If the DiffServ field does not vary and is known by both sides, the > Field Descriptor in the Rule SHOULD contain a TV with this = well-known > value, an "equal" MO and a "not-sent" CDA. given that the TC field includes the ECN bits, I think this = recommendation is dangerous, since it will cause ECN bleaching. IMO the main recommendation *must* be one of the options below: > Otherwise, two possibilities can be considered depending on the > variability of the value: >=20 > o One possibility is to not compress the field and send the = original > value. In the Rule, TV is not set to any particular value, MO is > set to "ignore" and CDA is set to "value-sent". >=20 > o If some upper bits in the field are constant and known, a better > option is to only send the LSBs. In the Rule, TV is set to a > value with the stable known upper part, MO is set to MSB(x) and > CDA to LSB(y). Lars PS: I haven't checked whether other related drafts have similar issues. --Apple-Mail=_ACE9B206-43D9-4BA7-9E94-7B492B82D99A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAltHA2MACgkQVLXDCb9w wVfXxhAAmr87fPnRd5o1IP9SFyY2IlMQcrAbU5wOz0PK9zJazDg9E3YMcBMtKk2F t3oYmBAO2FR8KaLGrn3CvnlEBeiZLQwz3bm2kUrgQstEBbYo4JmDbChvglFek/kS j42H1B3uFmgxh4ZTEEUtElqfIcpBXiFyU6UPA2ynw4adqIJKzSyiB7DvJ7bj+9lB EqgR+kJaq67jk5oBd+TcBrRpLwy/UbOKPeCI+J9oWNmdAEUIW6h8mCC9Dm7W2WZU Sio5lShAc0Q4GtVf09+r59QTyxuvvgR6cBiUbE6Fj0eVFVmUqacre/ewVh5fKQoV KpqFvrQTA0XkUnuvutsOEVBQ4QhyVIyMbOheW4TVofxOE6kuBLEp2yq+Als5ySu1 P1kRVx5jesVSEH3NTeG1j5Lu5Ex6Me2x8V+l8KQFf2qm3t9Fl1HvzNVtt3QAhCyj 5YXxx44FcvHylR5wPZKnMba+L+wxbRc2nXrh1bshJ7K2k7vLOn5HdtK//+bQd5fk cbdUYMLYKBpUr0pjOKYPPiYuViiFcrCUR/I54759i31DpJzVeciLBGor2R2vz9eO vWYkPHYwNeb4KUcNaj91DtjuiuZK5IaYn/WNLynxOcEq963fQ9AVsM+ohY/X7qab om8nJGz5P2akdL46iwxhZL3Yzjw/dqRMQFmSc18WCvXOejmUoI0= =6KVw -----END PGP SIGNATURE----- --Apple-Mail=_ACE9B206-43D9-4BA7-9E94-7B492B82D99A-- From nobody Thu Jul 12 06:25:16 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F564130F08 for ; Thu, 12 Jul 2018 06:25:14 -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, 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 5922vvbwWyCg for ; Thu, 12 Jul 2018 06:25:10 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 F0978130EF7 for ; Thu, 12 Jul 2018 06:25:09 -0700 (PDT) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id D40376ED54ED9; Thu, 12 Jul 2018 14:25:05 +0100 (IST) Received: from BLREML405-HUB.china.huawei.com (10.20.4.41) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 12 Jul 2018 14:25:06 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.180]) by BLREML405-HUB.china.huawei.com ([10.20.4.41]) with mapi id 14.03.0382.000; Thu, 12 Jul 2018 18:54:55 +0530 From: Sidhartha pant To: Michael Tuexen , Shweta r CC: "tsvwg@ietf.org" , Sharath Chandra B , Ashutosh prakash Thread-Topic: [tsvwg] Query regarding random parameter in SCTP-AUTH RFC 4895 Thread-Index: AdP8l1xvzHW+uN9dTO+47C2gCum3/ABAlOqAAJlmqwAABsAWgAGeeFGAAIKkw4AAKhrngAFbFruAAsvO8mA= Date: Thu, 12 Jul 2018 13:24:55 +0000 Message-ID: <67CF347253A4874C8F2A2A8CD1D9460B72BF4A56@BLREML503-MBX.china.huawei.com> References: <421CE35A2FDF994790546C7F50F875455E9601DB@dggemi506-mbs.china.huawei.com> <421CE35A2FDF994790546C7F50F875455E9616AC@dggemi506-mbs.china.huawei.com> <421CE35A2FDF994790546C7F50F875455E96521A@dggemi526-mbs.china.huawei.com> <61C0B574-D6F8-4FC9-B0CC-1C6F4F39F768@lurchi.franken.de> <421CE35A2FDF994790546C7F50F875455E967537@dggemi526-mbs.china.huawei.com> <1BF25B06-D8D3-484E-B69A-E60709153A52@lurchi.franken.de> In-Reply-To: <1BF25B06-D8D3-484E-B69A-E60709153A52@lurchi.franken.de> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.205.190] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [tsvwg] Query regarding random parameter in SCTP-AUTH RFC 4895 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 13:25:15 -0000 SGkgTWljaGFlbCwNCg0KQXMgcGVyIHRoZSByZWNlbnQgZGlzY3Vzc2lvbnMgb24gUkZDIDQ4OTUg YW5kIFJGQyA2MDgzLCB3ZSBhcmUgYWJsZSB0byBjb25jbHVkZSBvbiBwb2ludCAxIGFuZCBoYXZl IHNvbWUgZG91YnRzIG9uIHBvaW50IDIgYW5kIDMuDQpIb3dldmVyIHdlIGFyZSBub3QgYWJsZSB0 byBmaW5kIHNwZWNpZmljIHJlZmVyZW5jZXMgaW4gdGhlIGFib3ZlIFJGQ3MgZm9yIHRoZXNlIHBv aW50cy4gOi0NCg0KMS4JV2hlbiB0aGUga2V5IGlzIGluc3RhbGxlZCBidXQgbm90IHlldCBhY3Rp dmUsIFNDVFAgc2hvdWxkIHByb2Nlc3MgaXQgLCBpZiBzdWNoIGFuIEFVVEggY29udGFpbmluZyB0 aGlzIGtleSBpcyByZWNlaXZlZC4NCjIuCU9ubHkgdGhlIGFjdGl2ZSBrZXkgc2hvdWxkIGJlIHVz ZSB0byBzZW5kIHBhY2tldCwgZG9lcyB0aGlzIG1lYW4gd2Ugc2hvdWxkIGJ1bmRsZSBjaHVua3Mg d2l0aCBkaWZmZXJlbnQga2V5cz8gVGhpcyBpcyBpbiBjb250cmFzdCB3aXRoIHRoZSBzdGF0ZW1l bnQgdGhhdCBubyB0d28gdXNlciBtZXNzYWdlcyB3aXRoIGRpZmZlcmVudCBrZXkgc2hvdWxkIGJl IGJ1bmRsZWQgYW5kIHNlbnQuIA0KYSkJUkZDIDY0NTggU2VjdGlvbiAzLjUuODotIOKAnFBsZWFz ZSBub3RlIHRoYXQgdGhlIFNDVFAgaW1wbGVtZW50YXRpb24gbXVzdCBub3QgYnVuZGxlIHVzZXIg bWVzc2FnZXMgdGhhdCBuZWVkIHRvIGJlIGF1dGhlbnRpY2F0ZWQgdXNpbmcgZGlmZmVyZW50IHNo YXJlZCBrZXkgaWRlbnRpZmllcnMu4oCdDQozLglCZWZvcmUgc2VuZGluZyB0aGUgRklOSVNIRUQg bWVzc2FnZSwgYWN0aXZlIGtleSBzaG91bGQgYmUgc3dpdGNoZWQgdG8gbmV3IGtleSwgaG93ZXZl ciBpbiBzb21lIG9wZW4gU1NMIGltcGxlbWVudGF0aW9uIHdlIG9ic2VydmUgdGhhdCBrZXkgaXMg YWN0aXZhdGVkIG9ubHkgb25jZSB0aGUgRklOSVNIRUQgaGFuZHNoYWtlIGlzIGNvbXBsZXRlZC4N CmEpCVJGQyA2MDgzOiDigJxCZWZvcmUgc2VuZGluZyB0aGUgRmluaXNoZWQgbWVzc2FnZSwgdGhl IGFjdGl2ZSBTQ1RQLUFVVEgga2V5IE1VU1QgYmUgc3dpdGNoZWQgdG8gdGhlIG5ldyBvbmUu4oCd DQoNCkkgZmVlbCBjdXJyZW50bHkgdGhlIFJGQyBleHBsaWNpdGx5IGRvZXMgbm90IHNwZWNpZnkg dGhlIGFib3ZlIHBvaW50cywgSSBhbSB3b25kZXJpbmcgaWYgYW4gZXJyYXRhIGV4aXN0cyBvciB3 ZSBjYW4gdXBkYXRlIHRoZXNlIGluIHRoZSBSRkNzICg2MDgzIGFuZCA0ODk1KS4NCg0KVGhhbmsg eW91Lg0KDQpCZXN0IFJlZ2FyZHMsDQpTaWRoYXJ0aGEgUGFudA0KRG9tYWluIFNFfFZQUCBUZWFt IDIwMTIgTGFiDQoNCkh1YXdlaSBUZWNobm9sb2dpZXMgSW5kaWEgUHZ0LiBMdGQuDQpTdXJ2ZXkg Tm8uIDM3LCBOZXh0IHRvIEVQSVAgQXJlYSwgS3VuZGFsYWhhbGxpLCBXaGl0ZWZpZWxkDQpCZW5n YWx1cnUtNTYwMDY2LCBLYXJuYXRha2EgDQpUZWw6ICsgOTEtODAtNDkxNjA3MDAgRXh0IDcxNTk0 IElJIE1vYjogKzkxOTg4NjE3NDg3NCBFbWFpbDogc3BhbnRAaHVhd2VpLmNvbQ0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWljaGFlbCBUdWV4ZW4gW21haWx0bzptaWNoYWVs LnR1ZXhlbkBsdXJjaGkuZnJhbmtlbi5kZV0gDQpTZW50OiAyOCBKdW5lIDIwMTggMTg6NDINClRv OiBTaHdldGEgciA8c2h3ZXRhLmsuckBodWF3ZWkuY29tPg0KQ2M6IHRzdndnQGlldGYub3JnOyBT aGFyYXRoIENoYW5kcmEgQiA8c2hhcmF0aGNiQGh1YXdlaS5jb20+OyBTaWRoYXJ0aGEgcGFudCA8 c2lkaGFydGhhLnBhbnRAaHVhd2VpLmNvbT47IEFzaHV0b3NoIHByYWthc2ggPGFzaHV0b3NoLnBy YWthc2hAaHVhd2VpLmNvbT4NClN1YmplY3Q6IFJlOiBbdHN2d2ddIFF1ZXJ5IHJlZ2FyZGluZyBy YW5kb20gcGFyYW1ldGVyIGluIFNDVFAtQVVUSCBSRkMgNDg5NQ0KDQoNCg0KPiBPbiAyMS4gSnVu IDIwMTgsIGF0IDE3OjMzLCBTaHdldGEgciA8c2h3ZXRhLmsuckBodWF3ZWkuY29tPiB3cm90ZToN Cj4gDQo+IEhpIE1pY2hhZWwsDQo+ICANCj4gPGltYWdlMDAxLnBuZz4NCj4gIA0KPiAgDQo+IFJG QyA2MDgzOg0KPiA0LjguICBIYW5kbGluZyBvZiBFbmRwb2ludC1QYWlyIFNoYXJlZCBTZWNyZXRz DQo+ICANCj4gICAgVGhlIGVuZHBvaW50LXBhaXIgc2hhcmVkIHNlY3JldCBmb3IgU2hhcmVkIEtl eSBJZGVudGlmaWVyIDAgaXMgZW1wdHkNCj4gICAgYW5kIE1VU1QgYmUgdXNlZCB3aGVuIGVzdGFi bGlzaGluZyBhIERUTFMgY29ubmVjdGlvbi4gIFdoZW5ldmVyIHRoZQ0KPiAgICBtYXN0ZXIga2V5 IGNoYW5nZXMsIGEgNjQtYnl0ZSBzaGFyZWQgc2VjcmV0IGlzIGRlcml2ZWQgZnJvbSBldmVyeQ0K PiAgICBtYXN0ZXIgc2VjcmV0IGFuZCBwcm92aWRlZCBhcyBhIG5ldyBlbmRwb2ludC1wYWlyIHNo YXJlZCBzZWNyZXQgYnkNCj4gICAgdXNpbmcgdGhlIGV4cG9ydGVyIGRlc2NyaWJlZCBpbiBbUkZD NTcwNV0uICBUaGUgZXhwb3J0ZXIgTVVTVCB1c2UgdGhlDQo+ICAgIGxhYmVsIGdpdmVuIGluIFNl Y3Rpb24gNSBhbmQgbm8gY29udGV4dC4gIFRoZSBuZXcgU2hhcmVkIEtleQ0KPiAgICBJZGVudGlm aWVyIE1VU1QgYmUgdGhlIG9sZCBTaGFyZWQgS2V5IElkZW50aWZpZXIgaW5jcmVtZW50ZWQgYnkg MS4NCj4gICAgSWYgdGhlIG9sZCBvbmUgaXMgNjU1MzUsIHRoZSBuZXcgb25lIE1VU1QgYmUgMS4N Cj4gIA0KPiAgICBCZWZvcmUgc2VuZGluZyB0aGUgRmluaXNoZWQgbWVzc2FnZSwgdGhlIGFjdGl2 ZSBTQ1RQLUFVVEgga2V5IE1VU1QgYmUNCj4gICAgc3dpdGNoZWQgdG8gdGhlIG5ldyBvbmUuDQo+ ICANCj4gICAgT25jZSB0aGUgY29ycmVzcG9uZGluZyBGaW5pc2hlZCBtZXNzYWdlIGZyb20gdGhl IHBlZXIgaGFzIGJlZW4NCj4gICAgcmVjZWl2ZWQsIHRoZSBvbGQgU0NUUC1BVVRIIGtleSBTSE9V TEQgYmUgcmVtb3ZlZC4NCj4gIA0KPiAtLS0+IE15IGRvdWJ0ICwgaG93IHVzZXIgd2lsbCBjb21l IHRvIGtub3cgd2hlbiB0byBjb25maWd1cmUgbmV3IGtleSwgSXMgSXQgbGlrZSBiZWZvcmUgY2xp ZW50IHNlbmRzIENoYW5nZUNpcGhlclNwZWMsIHVzZXIgd2lsbCBnZXQgZHJ5X2V2ZW50IGNhbGxi YWNrLCB0aGF0IHRpbWUgdXNlciBjb25maWd1cmVzIG5ldyBrZXkgYW5kIHNlbmRzIEZpbmlzaGVk IG1lc3NhZ2Ugd2l0aCBuZXcga2V5Pw0KVGV4dCBzYXlzIHdoZW4gdG8gdXNlIGEgbmV3IGtleSBm b3Igc2VuZGluZzogQmVmb3JlIHNlbmRpbmcgdGhlIEZpbmlzaGVkIG1lc3NhZ2UgeW91IG5lZWQg dG8gc3dpdGNoLg0KU28gdGhlIEZpbmlzaGVkIG1lc3NhZ2UgaXMgdGhlIGZpcnN0IG9uZSB1c2lu ZyB0aGUgbmV3IEFVVEgga2V5Lg0KPiAgICAgIE9uIHNlcnZlciBzaWRlLCBpdCBzaG91bGQgYWxy ZWFkeSBoYXZlIHVwZGF0ZWQgbmV3IGtleSBvdGhlcndpc2UgaXQgY2Fubm90IHByb2Nlc3MgRmlu aXNoZWQgbWVzc2FnZS4gQnV0IHdoZW4gc2VydmVyIChhZnRlciB3aGljaCBwYWNrZXQgb2YgRFRM UyBoYW5kc2hha2UpIHdpbGwgdXBkYXRlIGl0cyBrZXkgPw0KWW91IHNob3VsZCBoYXZlIGluc3Rh bGxlZCBpdCwgYnV0IG5vdCBtYWRlIGl0IHRoZSBhY3RpdmUgb25lLiBUaGVyZWZvcmUgeW91IGNh biByZWNlaXZlIG1lc3NhZ2VzIHVzaW5nIGl0LCBidXQgeW91IGRvbid0IHVzZSBpdCBhbHJlYWR5 IGZvciBzZW5kaW5nIG1lc3NhZ2VzLg0KDQpQbGVhc2Ugbm90ZSB0aGUgdGhlIGRhbmNlIHJlbGF0 ZWQgdG8gdGhlIHNlbmRlciBkcnkgZXZlbnQgaXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gNC43Lg0K DQpCZXN0IHJlZ2FyZHMNCk1pY2hhZWwNCj4gICAgICANCj4gICAgICANCj4gIA0KPiAgDQo+IFJl Z2FyZHMsDQo+IFNod2V0YSBLIFINCj4gVGVzdGVyIOKAkyBWUFAsIDIwMTIgTEFCDQo+ICANCj4g SHVhd2VpIFRlY2hub2xvZ2llcyBJbmRpYSBQdnQuIEx0ZC4NCj4gU3VydmV5IE5vLiAzNywgTmV4 dCB0byBFUElQIEFyZWEsIEt1bmRhbGFoYWxsaSwgV2hpdGVmaWVsZCBCZW5nYWx1cnUsIA0KPiBL YXJuYXRha2EgLSA1NjAwNjYNCj4gVGVsOiArIDkxLTgwLTQ5MTYwNzAwIEV4dCA3MTU1MyBJSSBN b2I6IDk5ODY2MDEyNTV8fCBFbWFpbDogDQo+IHNod2V0YWtyQGh1YXdlaS5jb20NCj4gIA0KPiAg DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1pY2hhZWwgVHVleGVuIFtt YWlsdG86TWljaGFlbC5UdWV4ZW5AbHVyY2hpLmZyYW5rZW4uZGVdDQo+IFNlbnQ6IDIxIEp1bmUg MjAxOCAwMDo1OA0KPiBUbzogU2h3ZXRhIHINCj4gQ2M6IHRzdndnQGlldGYub3JnOyBTaGFyYXRo IENoYW5kcmEgQjsgU2lkaGFydGhhIHBhbnQ7IEFzaHV0b3NoIA0KPiBwcmFrYXNoDQo+IFN1Ympl Y3Q6IFJlOiBbdHN2d2ddIFF1ZXJ5IHJlZ2FyZGluZyByYW5kb20gcGFyYW1ldGVyIGluIFNDVFAt QVVUSCBSRkMgDQo+IDQ4OTUNCj4gIA0KPiAgDQo+ICANCj4gPiBPbiAxOC4gSnVuIDIwMTgsIGF0 IDA3OjA3LCBTaHdldGEgciA8c2h3ZXRhLmsuckBodWF3ZWkuY29tPiB3cm90ZToNCj4gPiANCj4g PiANCj4gPiANCj4gPiBIaSBNaWNoYWVsLA0KPiA+IA0KPiA+IFNvbWUgbW9yZSBkb3VidHMuDQo+ ID4gDQo+ID4gMSkgQXMgcGVyIG15IHVuZGVyc3RhbmRpbmcgb3RoZXIgdGhhbiBEQVRBICYgU0FD SyBjaHVua3MsIHJlbWFpbmluZyBhcmUgY29udHJvbCBjaHVua3MuIEFtIEkgY29ycmVjdCA/DQo+ IE9ubHkgREFUQSBjaHVua3MgKHNwZWNpZmllZCBpbiBSRkMgNDk2MCkgYW5kIEktREFUQSAoc3Bl Y2lmaWVkIGluIFJGQyA4MjYwKSBhcmUgZGF0YSBjaHVua3MuIEFsbCBvdGhlciBjaHVua3MsIGlu Y2x1ZGluZyB0aGUgU0FDSyBjaHVuaywgYXJlIGNvbnRyb2wgY2h1bmtzLg0KPiA+IA0KPiA+IDIp IEFzIHBlciAsDQo+ID4gDQo+ID4gICA1LjEuICBBdXRoZW50aWNhdGlvbiBDaHVuayAoQVVUSCkN Cj4gPiAgIFRoZSBjb250cm9sIGNodW5rIEFVVEggTVVTVCBOT1QgYXBwZWFyIG1vcmUgdGhhbiBv bmNlIGluIGFuIFNDVFANCj4gPiAgIHBhY2tldC4gIEFsbCBjb250cm9sIGFuZCBkYXRhIGNodW5r cyB0aGF0IGFyZSBwbGFjZWQgYWZ0ZXIgdGhlIEFVVEgNCj4gPiAgIGNodW5rIGluIHRoZSBwYWNr ZXQgYXJlIHNlbnQgaW4gYW4gYXV0aGVudGljYXRlZCB3YXkuICBUaG9zZSBjaHVua3MNCj4gPiAg IHBsYWNlZCBpbiBhIHBhY2tldCBiZWZvcmUgdGhlIEFVVEggY2h1bmsgYXJlIG5vdCBhdXRoZW50 aWNhdGVkLg0KPiA+ICAgUGxlYXNlIG5vdGUgdGhhdCBEQVRBIGNodW5rcyBjYW4gbm90IGFwcGVh ciBiZWZvcmUgY29udHJvbCBjaHVua3MgaW4NCj4gPiAgIGFuIFNDVFAgcGFja2V0Lg0KPiA+IA0K PiA+ICAgLS0+IEFzIHBlciB0aGlzLCBBVVRIIG5lZWQgbm90IGJlIHRoZSBmaXJzdCBjaHVuayBp biB0aGUgcGFja2V0Lg0KPiA+ICAgICAgIEVSUk9SK0FVVEgrREFUQSBpcyB2YWxpZCBjb21iaW5h dGlvbiB3aGVyZSBwZWVyIGhhcyBhc2tlZCBmb3Igb25seSBEQVRBIGF1dGhlbnRpY2F0aW9uID8N Cj4gWWVzLCB0aGF0IGlzIGEgdmFsaWQgcGFja2V0Lg0KPiA+IA0KPiA+IDMpIEVuZHBvaW50IGhh cyBhc2tlZCBmb3Igb25seSBIQiBhdXRoZW50aWNhdGlvbi4gDQo+ID4gICBJZiBpdCByZWNlaXZl cyBEQVRBK0FVVEgrSEIgd2hpY2ggaXMgbm90IGNvcnJlY3QgYmVjYXVzZSBEQVRBIGNhbm5vdCBh cHBlYXIgYmVmb3JlIGNvbnRyb2wgY2h1bmtzLCB3aG9sZSBwYWNrZXQgc2hvdWxkIGJlIGRpc2Nh cmRlZC4NCj4gPiAgICBXaGF0IGlzIHlvdXIgb3Bpbmlvbj8NCj4gV2UgZG9uJ3QgcmVxdWlyZSBh biBpbXBsZW1lbnRhdGlvbiB0byBwcmUtc2NhbiB0aGUgcGFja2V0IGJlZm9yZSBwcm9jZXNzaW5n IGl0LiBTbyB5b3UgY2FuIHN0YXJ0IHdpdGggdGhlIGZpcnN0IGNodW5rLCB3aGljaCBpcyBhIERB VEEgY2h1bmssIGFuZCBwcm9jZXNzIGl0LCBzaW5jZSBub3RoaW5nIGlzIHdyb25nIHdpdGggYSBE QVRBIGNodW5rIGJlaW5nIHRoZSBmaXJzdCBjaHVuay4NCj4gV2hlbiBzdGFydGluZyB0aGUgcHJv Y2VzcyB0aGUgQVVUSCBjaHVuayAob3IgYW55IG90aGVyIGNvbnRyb2wgY2h1bmspLCB5b3UgZGV0 ZWN0IHRoYXQgdGhpcyBwYWNrZXQgaXMgbm90IHZhbGlkLiBZb3UgY2FuIHNlbmQgYW4gQUJPUlQg KHBvc3NpYmx5IGluZGljYXRpbmcgYSBwcm90b2NvbCB2aW9sYXRpb24pIGFuZCBkZXN0cm95IHRo ZSBhc3NvY2lhdGlvbi4gVGhpcyBpcyB3aGF0IHRoZSBGcmVlQlNEIGltcGxlbWVudGF0aW9uIGRv ZXMuLi4NCj4gPiANCj4gPiA0KQ0KPiA+IDYuICBQcm9jZWR1cmVzDQo+ID4gNi4xLiAgRXN0YWJs aXNobWVudCBvZiBhbiBBc3NvY2lhdGlvbiBTaGFyZWQgS2V5DQo+ID4gDQo+ID4gICBBbiBTQ1RQ IGVuZHBvaW50IGhhcyBhIGxpc3Qgb2YgY2h1bmtzIGl0IG9ubHkgYWNjZXB0cyBpZiB0aGV5IGFy ZQ0KPiA+ICAgcmVjZWl2ZWQgaW4gYW4gYXV0aGVudGljYXRlZCB3YXkuICBUaGlzIGxpc3QgaXMg aW5jbHVkZWQgaW4gdGhlIElOSVQNCj4gPiAgIGFuZCBJTklULUFDSywgYW5kIE1BWSBiZSBvbWl0 dGVkIGlmIGl0IGlzIGVtcHR5LiAgU2luY2UgdGhpcyBsaXN0DQo+ID4gICBkb2VzIG5vdCBjaGFu Z2UgZHVyaW5nIHRoZSBsaWZldGltZSBvZiB0aGUgU0NUUCBlbmRwb2ludCB0aGVyZSBpcyBubw0K PiA+ICAgcHJvYmxlbSBpbiBjYXNlIG9mIElOSVQgY29sbGlzaW9uLg0KPiA+IA0KPiA+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgU0NUUCBDbGllbnQgICAgICAgICAgICBTQ1RQIFNl cnZlcg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIElOSVQgICAgICAgICAg LS0tLT4gICAgDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8LS0tLSAgIElOSVQgQWNrDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgQ29va2llICAgICAgICAtLS0+DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8LS0tICBjb29raWUgYWNrDQo+ID4gDQo+ID4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFJlc3RhcnQsIHNlbmQgSU5JVC0tLT4NCj4gPiANCj4gPiAtLT4gRHVy aW5nIHJlc3RhcnQgYWxsIHRoZSAocmFuZG9tLCBjaHVua2xpc3QsIEhNQUMgYWxnbykgc2hvdWxk IGJlIHNhbWUgaW4gSU5JVCBjaHVuayA/IHdoYXQgc2hvdWxkIGJlIHRoZSBiZWhhdmlvciBpZiBJ TklUIGlzIHJlY2VpdmVkIHdpdGggZGlmZmVyZW50IEFVVEggcGFyYW1zID8NCj4gQSByZXN0YXJ0 IG5vcm1hbGx5IG1lYW5zIHRoYXQgdGhlIGNsaWVudCBsb3N0IGl0cyBzdGF0ZSBjb21wbGV0ZWx5 IChsaWtlIGEgc3lzdGVtIHJlYm9vdGVkKSBzbyB0aGUgcGFyYW1ldGVycyBtaWdodCBub3QgYmUg dGhlIHNhbWUuIFRoaXMgaXMgbm90IGEgY29sbGlzaW9uIGNhc2UuLi4NCj4gIA0KPiBCZXN0IHJl Z2FyZHMNCj4gTWljaGFlbA0KPiA+IA0KPiA+IA0KPiA+IFJlZ2FyZHMsDQo+ID4gU2h3ZXRhIEsg Ug0KPiA+IFRlc3RlciDigJMgVlBQLCAyMDEyIExBQg0KPiA+IA0KPiA+IA0KPiA+IEh1YXdlaSBU ZWNobm9sb2dpZXMgSW5kaWEgUHZ0LiBMdGQuDQo+ID4gU3VydmV5IE5vLiAzNywgTmV4dCB0byBF UElQIEFyZWEsIEt1bmRhbGFoYWxsaSwgV2hpdGVmaWVsZCANCj4gPiBCZW5nYWx1cnUsIEthcm5h dGFrYSAtIDU2MDA2Ng0KPiA+IFRlbDogKyA5MS04MC00OTE2MDcwMCBFeHQgNzE1NTMgSUkgTW9i OiA5OTg2NjAxMjU1fHwgRW1haWw6DQo+ID4gc2h3ZXRha3JAaHVhd2VpLmNvbQ0KPiA+IA0KPiA+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogTWljaGFlbCBUdWV4ZW4gW21h aWx0bzpNaWNoYWVsLlR1ZXhlbkBsdXJjaGkuZnJhbmtlbi5kZV0NCj4gPiBTZW50OiAxMCBKdW5l IDIwMTggMDQ6NTANCj4gPiBUbzogU2h3ZXRhIHINCj4gPiBDYzogdHN2d2dAaWV0Zi5vcmc7IFNo YXJhdGggQ2hhbmRyYSBCOyBTaWRoYXJ0aGEgcGFudDsgQXNodXRvc2ggDQo+ID4gcHJha2FzaA0K PiA+IFN1YmplY3Q6IFJlOiBbdHN2d2ddIFF1ZXJ5IHJlZ2FyZGluZyByYW5kb20gcGFyYW1ldGVy IGluIFNDVFAtQVVUSCANCj4gPiBSRkMNCj4gPiA0ODk1DQo+ID4gDQo+ID4+IE9uIDkuIEp1biAy MDE4LCBhdCAxNjowNiwgU2h3ZXRhIHIgPHNod2V0YS5rLnJAaHVhd2VpLmNvbT4gd3JvdGU6DQo+ ID4+IA0KPiA+PiBIaSBNaWNoYWVsLA0KPiA+PiANCj4gPj4gSSBoYXZlIGFub3RoZXIgZG91YnQg cmVnYXJkaW5nIEhNQUMgYWxnb3JpdGhtIHNlbGVjdGlvbi4NCj4gPj4gDQo+ID4+IFJGQyA0ODk1 OiANCj4gPj4gc2VjdGlvbiA2LjEuICBFc3RhYmxpc2htZW50IG9mIGFuIEFzc29jaWF0aW9uIFNo YXJlZCBLZXkNCj4gPj4gDQo+ID4+ICBFYWNoIFNDVFAgZW5kcG9pbnQgTVVTVCBpbmNsdWRlIGlu IHRoZSBJTklUIGFuZCBJTklULUFDSyBhIA0KPiA+PiBITUFDLUFMR08gcGFyYW1ldGVyIGNvbnRh aW5pbmcgYSBsaXN0IG9mIEhNQUMgSWRlbnRpZmllcnMgaXQgDQo+ID4+IHJlcXVlc3RzIHRoZSBw ZWVyIHRvIHVzZS4gIFRoZSByZWNlaXZlciBvZiBhbiBITUFDLUFMR08gcGFyYW1ldGVyIA0KPiA+ PiBTSE9VTEQgdXNlIHRoZSBmaXJzdCBsaXN0ZWQgYWxnb3JpdGhtIGl0IHN1cHBvcnRzLiAgVGhl IEhNQUMgDQo+ID4+IGFsZ29yaXRobSBiYXNlZCBvbiBTSEEtMSBNVVNUIGJlIHN1cHBvcnRlZCBh bmQgaW5jbHVkZWQgaW4gdGhlIEhNQUMtQUxHTyBwYXJhbWV0ZXIuDQo+ID4+IA0KPiA+PiBTZWN0 aW9uIDYuMy4gIFJlY2VpdmluZyBBdXRoZW50aWNhdGVkIENodW5rcw0KPiA+PiANCj4gPj4gIFRo ZSByZWNlaXZlciBNVVNUIHVzZSB0aGUgSE1BQyBhbGdvcml0aG0gaW5kaWNhdGVkIGluIHRoZSBI TUFDIA0KPiA+PiBJZGVudGlmaWVyIGZpZWxkLiAgSWYgdGhpcyBhbGdvcml0aG0gd2FzIG5vdCBz cGVjaWZpZWQgYnkgdGhlIA0KPiA+PiByZWNlaXZlciBpbiB0aGUgSE1BQy1BTEdPIHBhcmFtZXRl ciBpbiB0aGUgSU5JVCBvciBJTklULUFDSyBjaHVuayANCj4gPj4gZHVyaW5nIGFzc29jaWF0aW9u IHNldHVwLCB0aGUgQVVUSCBjaHVuayBhbmQgYWxsIHRoZSBjaHVua3MgYWZ0ZXIgDQo+ID4+IGl0 IE1VU1QgYmUgZGlzY2FyZGVkIGFuZCBhbiBFUlJPUiBjaHVuayBTSE9VTEQgYmUgc2VudCB3aXRo IHRoZSANCj4gPj4gZXJyb3IgY2F1c2UgZGVmaW5lZCBpbiBTZWN0aW9uIDQuMS4NCj4gPj4gDQo+ ID4+IC0tLS0tLT4gICAgICAgICAgIFNDVFAgQ2xpZW50ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgU0NUUCBTZXJ2ZXINCj4gPj4gICAgICAgICAgICAgIElOSVQg c2VuZCB3aXRoIChTSEEtMjU2LCBTSEEtMSkgIC0tLS0+ICAgIA0KPiA+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC0tLS0gICBJTklUIEFjayAo IFNIQS0yNTYsIFNIQS0xKQ0KPiA+PiAgICAgICAgICAgICAgICAgQ29va2llICAgICAgICAgICAg ICAgICAgICAgICAgIC0tLT4NCj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPC0tLSAgY29va2llIGFjaw0KPiA+PiANCj4gPj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8LS0tIHNlbmRzIERBVEEgIA0KPiA+ PiB3aXRoIEFVVEggY2h1bmsgSE1BQyBJZGVudGlmaWVyPSBTSEEtMjU2DQo+ID4+IA0KPiA+PiAg ICAgICAgICBTZW5kIFNBQ0sgd2l0aCBBVVRIIGNodW5rIGhtYWMgaWQgPSBTSEEtMSAtLS0tPg0K PiA+PiANCj4gPj4gICAgICAgICBEQVRBICYgU0FDSyBwcm9jZXNzaW5nIHNob3VsZCBiZSBzdWNj ZXNzICwgdGhpcyBpcyBteSB1bmRlcnN0YW5kaW5nLiBXaGF0IGlzIHlvdXIgb3Bpbmlvbj8NCj4g PiBDb3JyZWN0Lg0KPiA+PiANCj4gPj4gDQo+ID4+IA0KPiA+PiAtLS0tLS0+ICAgICAgICAgICBT Q1RQIENsaWVudCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFND VFAgU2VydmVyDQo+ID4+ICAgICAgICAgICAgICBJTklUIHNlbmQgd2l0aCAoU0hBLTEsIFNIQS0y NTYpICAtLS0tPiAgICANCj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDwtLS0tICAgSU5JVCBBY2sgKFNIQS0xLCBTSEEtMjU2KQ0KPiA+PiAg ICAgICAgICAgICAgICAgQ29va2llICAgICAgICAgICAgICAgICAgICAgICAgIC0tLT4NCj4gPj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC0tLSAgY29v a2llIGFjaw0KPiA+PiANCj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8LS0tIHNlbmRzIERBVEEgIA0KPiA+PiB3aXRoIEFVVEggY2h1bmsgSE1BQyBJ ZGVudGlmaWVyPSBTSEEtMjU2DQo+ID4+IA0KPiA+PiAgICAgICAgICBTZW5kIFNBQ0sgd2l0aCBB VVRIIGNodW5rIGhtYWMgaWQgPSBTSEEtMjU2IC0tLS0+DQo+ID4+IA0KPiA+PiAgICAgICAgIERB VEEgJiBTQUNLIHByb2Nlc3Npbmcgc2hvdWxkIGJlIHN1Y2Nlc3MgLCB0aGlzIGlzIG15IHVuZGVy c3RhbmRpbmcuIFdoYXQgaXMgeW91ciBvcGluaW9uPw0KPiA+IENvcnJlY3QuDQo+ID4+IA0KPiA+ PiANCj4gPj4gSSBnb3QgdGhpcyBkb3VidCBiZWNhdXNlIGluIFJGQyBpdHMgZ2l2ZW4gIiBUaGUg cmVjZWl2ZXIgTVVTVCB1c2UgdGhlIEhNQUMgYWxnb3JpdGhtIGluZGljYXRlZCBpbiB0aGUgSE1B QyBJZGVudGlmaWVyIGZpZWxkLiINCj4gPiBXaGF0IGlzIG1lYW50IGlzIHRoYXQgaWYgdGhlIHJl Y2VpdmVyIG9mIGFuIGF1dGggY2h1bmsgbXVzdCB1c2UgdGhlIEhNQUMgYWxnb3JpdGhtIGdpdmVu IGluIHRoZSBITUFDIElkZW50aWZpZXIgZmllbGQgb2YgdGhlIEFVVEggY2h1bmsgYXMgbG9uZyBh cyBpdCBpcyBhY2NlcHRhYmxlIGJ5IHRoZSByZWNlaXZlci4NCj4gPiANCj4gPiBCZXN0IHJlZ2Fy ZHMNCj4gPiBNaWNoYWVsDQo+ID4+IA0KPiA+PiANCj4gPj4gUmVnYXJkcywNCj4gPj4gU2h3ZXRh IEsgUg0KPiA+PiBUZXN0ZXIg4oCTIFZQUCwgMjAxMiBMQUINCj4gPj4gDQo+ID4+IEh1YXdlaSBU ZWNobm9sb2dpZXMgSW5kaWEgUHZ0LiBMdGQuDQo+ID4+IFN1cnZleSBOby4gMzcsIE5leHQgdG8g RVBJUCBBcmVhLCBLdW5kYWxhaGFsbGksIFdoaXRlZmllbGQgDQo+ID4+IEJlbmdhbHVydSwgS2Fy bmF0YWthIC0gNTYwMDY2DQo+ID4+IFRlbDogKyA5MS04MC00OTE2MDcwMCBFeHQgNzE1NTMgSUkg TW9iOiA5OTg2NjAxMjU1fHwgRW1haWw6DQo+ID4+IHNod2V0YWtyQGh1YXdlaS5jb20NCj4gPj4g DQo+ID4+IA0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBNaWNo YWVsIFR1ZXhlbiBbbWFpbHRvOk1pY2hhZWwuVHVleGVuQGx1cmNoaS5mcmFua2VuLmRlXQ0KPiA+ PiBTZW50OiAwNyBKdW5lIDIwMTggMDA6MjQNCj4gPj4gVG86IFNod2V0YSByDQo+ID4+IENjOiB0 c3Z3Z0BpZXRmLm9yZzsgU2hhcmF0aCBDaGFuZHJhIEI7IFNpZGhhcnRoYSBwYW50OyBBc2h1dG9z aCANCj4gPj4gcHJha2FzaA0KPiA+PiBTdWJqZWN0OiBSZTogW3RzdndnXSBRdWVyeSByZWdhcmRp bmcgcmFuZG9tIHBhcmFtZXRlciBpbiBTQ1RQLUFVVEggDQo+ID4+IFJGQw0KPiA+PiA0ODk1DQo+ ID4+IA0KPiA+Pj4gT24gNS4gSnVuIDIwMTgsIGF0IDAyOjM1LCBTaHdldGEgciA8c2h3ZXRhLmsu ckBodWF3ZWkuY29tPiB3cm90ZToNCj4gPj4+IA0KPiA+Pj4gSGkgR3JvdXAsDQo+ID4+PiANCj4g Pj4+IEdyZWV0aW5ncy4gSSBoYXZlIGEgZG91YnQgcmVnYXJkaW5nIFNDVFAgUkZDIDQ4OTUuDQo+ ID4+PiANCj4gPj4+IDEpICAgICAgc2VjdGlvbiDigJwzLjEuICBSYW5kb20gUGFyYW1ldGVyIChS QU5ET00p4oCdLg0KPiA+Pj4gDQo+ID4+PiAgICAgUmFuZG9tIE51bWJlcjogbiBieXRlcyAodW5z aWduZWQgaW50ZWdlcikNCj4gPj4+ICAgICBUaGlzIHZhbHVlIHJlcHJlc2VudHMgYW4gYXJiaXRy YXJ5IFJhbmRvbSBOdW1iZXIgaW4gbmV0d29yayBieXRlIG9yZGVyLg0KPiA+Pj4gDQo+ID4+PiAg ICBTZWN0aW9uIDYuMS4gIEVzdGFibGlzaG1lbnQgb2YgYW4gQXNzb2NpYXRpb24gU2hhcmVkIEtl eQ0KPiA+Pj4gDQo+ID4+PiAgIEFuIFNDVFAgZW5kcG9pbnQgd2lsbGluZyB0byByZWNlaXZlIG9y IHNlbmQgYXV0aGVudGljYXRlZCBjaHVua3MgTVVTVA0KPiA+Pj4gICBzZW5kIG9uZSBSQU5ET00g cGFyYW1ldGVyIGluIGl0cyBJTklUIG9yIElOSVQtQUNLIGNodW5rLiAgVGhlIFJBTkRPTQ0KPiA+ Pj4gICBwYXJhbWV0ZXIgTVVTVCBjb250YWluIGEgMzItYnl0ZSBSYW5kb20gTnVtYmVyLg0KPiA+ Pj4gDQo+ID4+PiAtLS0tPiBUaGUgcmFuZG9tIG9mIHNpemUgMzIgYnl0ZXMgc2hvdWxkIGJlIGlu IG5ldHdvcmsgYnl0ZSBvcmRlciBtZWFucyAzMmJ5dGVzIGlzIGRpdmlkZWQgaW50byA0IGJ5dGVz IHBhcnRpdGlvbiAodG90YWxseSA4IHBhcnRpdGlvbnMpIGFuZCB0aGVuIG50b2hsIGlzIGRvbmUg Zm9yIGVhY2ggcGFydGl0aW9uID8NCj4gPj4gTm8uIEl0IGlzIGp1c3QgYSBudW1iZXIgb2YgMzIg Ynl0ZXMgYW5kIGlzIHN0b3JlZCBpbiBiaWcgZW5hZGlhbi4NCj4gPj4+IA0KPiA+Pj4gMikgICAg ICBQZWVyIGhhcyBhc2tlZCBmb3IgSEIgYXV0aGVudGljYXRpb24uDQo+ID4+PiBJbiB0aGUgc2Nl bmFyaW8gb2Ygc2VuZGluZyBIQiB0byB1bmNvbmZpcm1lZCBhZGRyZXNzLCBpcyBpdCBjb3JyZWN0 IHRvIGJ1bmRsZSBBVVRIK0hCIGFuZCBzZW5kIHRvIHVuY29uZmlybWVkIGFkZHJlc3MgPw0KPiA+ Pj4gTXkgZG91YnQgaGVyZSBpcyBjYW4gQVVUSCBiZSBzZW50IHRvIHVuY29uZmlybWVkIGFkZHJl c3MgPw0KPiA+PiBZZXMuIElmIHRoZSBwZWVyIHJlcXVpcmVzIEhFQVJUQkVBVCBjaHVua3MgdG8g YmUgYXV0aGVudGljYXRlZCwgdGhlIGVuZC1wb2ludCBoYXMgdG8gc2VudCB0aGVtIGF1dGhlbnRp Y2F0ZWQuIEl0IGRvZXMgbm90IG1hdHRlciB3aGV0aGVyIHRoZSBIRVJUQkVBVHMgYXJlIHVzZWQg Zm9yIHBhdGggY29uZmlybWF0aW9uIG9yIG5vdC4NCj4gPj4+IA0KPiA+Pj4gMykgICAgICBJbiA0 OTg1LCBpdCBpcyBnaXZlbiwNCj4gPj4+IA0KPiA+Pj4gPGltYWdlMDAxLnBuZz4NCj4gPj4+IA0K PiA+Pj4gTG9jYWwgKGF1dGggc3VwcG9ydCkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBQZWVyIChBdXRoIG5vdCBzdXBwb3J0KQ0KPiA+Pj4gDQo+ ID4+PiBTZW5kIElOSVQgd2l0aCBhdXRoIHBhcmEgYW5kIGNodW5rbGlzdChEQVRBKSAtLT4gIA0K PiA+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDwtLS0tLSAgc2VuZHMgSU5JVC1BQ0sgd2l0aG91dCBhdXRoIHBh cmFtZXRlcnMgIChhcyBwZXIgYWJvdmUgc2VjdGlvbiwgIFBlZXIgaWdub3JlIGF1dGggcGFyYW1l dGVyIHJlY2VpdmVkIGluIElOSVQgYW5kIHNlbmRzIElOSVQtQUNLKQ0KPiA+Pj4gQ29va2llIGVj aG8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLS0+ DQo+ID4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDwtLS0tICAgICBjb29raWUgYWNrDQo+ID4+PiANCj4gPj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFzc29jaWF0aW9uIGVz dGFibGlzaGVkLg0KPiA+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwtLS0tICAgc2VuZHMgREFUQSB3aXRob3V0IEFV VEggY2h1bmsNCj4gPj4+IA0KPiA+Pj4gTG9jYWwgc2hvdWxkIHNlbmQgU0FDSyBvciBkaXNjYXJk IHRoZSBEQVRBIGFzIGl0IGRvZXMgbm90IGhhdmUgQVVUSCA/DQo+ID4+IEFmdGVyIHRoaW5raW5n IGFib3V0IGl0IGFuZCBkaXNjdXNzaW5nIGl0IHdpdGggUGV0ZXIgTGVpLCB0aGUgbG9jYWwgbm9k ZSBtdXN0IGRyb3AgdGhlIERBVEEgY2h1bmsuDQo+ID4+PiANCj4gPj4+IDQpICAgICAgNi4xLiAg RXN0YWJsaXNobWVudCBvZiBhbiBBc3NvY2lhdGlvbiBTaGFyZWQgS2V5DQo+ID4+PiANCj4gPj4+ ICAgVGhlIGNvbmNhdGVuYXRpb24gaXMgcGVyZm9ybWVkIG9uIGJ5dGUgdmVjdG9ycywgYW5kIGFs bCANCj4gPj4+IG51bWVyaWNhbCBjb21wYXJpc29ucyB1c2UgbmV0d29yayBieXRlIG9yZGVyIHRv IGNvbnZlcnQgdGhlIGtleSB2ZWN0b3JzIHRvIGEgbnVtYmVyLg0KPiA+Pj4gDQo+ID4+PiAtLS0t PkNhbiB5b3UgcGxlYXNlIGV4cGxhaW4gYWJvdXQgaG93IHRvIGNvbnZlcnQga2V5IHZlY3RvciB0 byBhIG51bWJlciBhbmQgd2hhdCBzaG91bGQgYmUgdGhlIHNpemUgb2YgdGhpcyBudW1iZXIuDQo+ ID4+IFRoZSBwb2ludCBpcyB0byBjb21wYXJlIHRoZSBieXRlIHZlY3RvciBmcm9tIHRoZSBtb3N0 IHNpZ25pZmljYW50IGJ5dGUgdG8gdGhlIGxvd2VzdC4NCj4gPj4gVGhhdCBpcyB3aHkgeW91IG5l ZWQgdG8ga25vdyB0aGUgYnl0ZSBvcmRlcmluZy4NCj4gPj4+IA0KPiA+Pj4gNSkgICAgICBXaGF0 IHNob3VsZCBiZSB0aGUgbGVuZ3RoIG9mICBBc3NvY2lhdGlvbiBTaGFyZWQgS2V5ID8gIChBcyBw ZXIgUkZDIDIxMDQgLCB0aGUga2V5IGNhbiBiZSBvZiBhbnkgbGVuZ3RoIHVwdG8gNjQgYnl0ZXMp DQo+ID4+IEl0IGNhbiBiZSBhcmJpdHJhcmlseSBsb25nLiBTZWUNCj4gPj4gaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzY0NTgjc2VjdGlvbi04LjMuMw0KPiA+PiBmb3IgYW4gQVBJLiBQ bGVhc2Ugbm90ZSB0aGUgaW4gdGhlIGNhc2Ugb2YgRFRMUy9TQ1RQIGl0IGlzIDY0IGJ5dGVzIA0K PiA+PiBhcyBzcGVjaWZpZWQgaW4NCj4gPj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzYwODMjc2VjdGlvbi00LjgNCj4gPj4+IA0KPiA+Pj4gNikgICAgICBGb3IgY2xpZW50IFNIQS0x IG1vc3QgcHJlZmVyYWJsZSANCj4gPj4+IEZvciBzZXJ2ZXIgU0hBLTI1NiBtb3N0IHByZWZlcmFi bGUNCj4gPj4+IA0KPiA+Pj4gDQo+ID4+PiAgICAgIFNDVFAgQ2xpZW50ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU0NUUCBTZXJ2ZXINCj4gPj4+IElOSVQgc2Vu ZCB3aXRoIChTSEEtMSwgU0hBLTI1NikgIC0tLS0+DQo+ID4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8LS0tLSAgIElOSVQgQWNrICggU0hBLTI1 NiwgU0hBLTEpDQo+ID4+PiBDb29raWUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIC0tLT4NCj4gPj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPC0tLSAgY29va2llIGFjaw0KPiA+Pj4gDQo+ID4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwtLS0gc2VuZHMgREFUQSANCj4g Pj4+IHdpdGggIEFVVEggY2h1bmsgSE1BQyBJZGVudGlmaWVyPSBTSEEtMQ0KPiA+Pj4gDQo+ID4+ PiAgICAgU2VuZCBTQUNLIHdpdGggQVVUSCBjaHVuayBobWFjIGlkID0gU0hBLTI1NiAtLS0tPg0K PiA+Pj4gDQo+ID4+PiAgICAgICAgREFUQSAmIFNBQ0sgcHJvY2Vzc2luZyBzaG91bGQgYmUgc3Vj Y2VzcyAsIHRoaXMgaXMgbXkgdW5kZXJzdGFuZGluZy4NCj4gPj4+IA0KPiA+Pj4gICAgICAgV2hh dCBpcyB5b3VyIG9waW5pb24/ICANCj4gPj4gSSBhZ3JlZS4NCj4gPj4gDQo+ID4+IFBsZWFzZSBs ZXQgdXMga25vdyBpZiB5b3UgaGF2ZSBmdXJ0aGVyIHF1ZXN0aW9ucy4NCj4gPj4gDQo+ID4+IEJl c3QgcmVnYXJkcw0KPiA+PiBNaWNoYWVsDQo+ID4+PiANCj4gPj4+IA0KPiA+Pj4gDQo+ID4+PiAN Cj4gPj4+IFJlZ2FyZHMsDQo+ID4+PiBTaHdldGEgSyBSDQo+ID4+PiBUZXN0ZXIg4oCTIFZQUCwg MjAxMiBMQUINCj4gPj4+IA0KPiA+Pj4gSHVhd2VpIFRlY2hub2xvZ2llcyBJbmRpYSBQdnQuIEx0 ZC4NCj4gPj4+IFN1cnZleSBOby4gMzcsIE5leHQgdG8gRVBJUCBBcmVhLCBLdW5kYWxhaGFsbGks IFdoaXRlZmllbGQgDQo+ID4+PiBCZW5nYWx1cnUsIEthcm5hdGFrYSAtIDU2MDA2Ng0KPiA+Pj4g VGVsOiArIDkxLTgwLTQ5MTYwNzAwIEV4dCA3MTU1MyBJSSBNb2I6IDk5ODY2MDEyNTV8fCBFbWFp bDoNCj4gPj4+IHNod2V0YWtyQGh1YXdlaS5jb20NCj4gPj4gDQo+ID4gDQoNCg== From nobody Fri Jul 13 09:28:32 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E45127598 for ; Fri, 13 Jul 2018 09:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=O/hqiqEE; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=DLH6nZ4f 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 72GmI_mIJOhZ for ; Fri, 13 Jul 2018 09:28:28 -0700 (PDT) Received: from esa1.dell-outbound.iphmx.com (esa1.dell-outbound.iphmx.com [68.232.153.90]) (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 A5139130E01 for ; Fri, 13 Jul 2018 09:28:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1531498791; x=1563034791; h=from:to:subject:date:message-id:mime-version; bh=r0KwYfnWj/3Wu3c/y8Fuom/u1BdB3Pgod5gqJ1D9fJs=; b=O/hqiqEEY2+kDoHGqfI5hYzio0ajxDr6ZJLCY+SfWe1jIEfT53NU4GrD 91TBsfzjttj8BKJyhfhrq2s6BVqPHnUpmYf6Uwm/j9ojTJEKM2plk0mRu ATSayulSPTjNNNYS8/AsGXAyLLWZP19crBiFwJTR69+Li5w7cgAXqqsdb U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2HhAgD20Uhbh8mZ6ERcHgEGDIJTIoEoD?= =?us-ascii?q?38oCoVQkl2ZBDsLIwuDB4E3AoJQITgUAQIBAQIBAQIBAQIQAQEBCgsJCCkjAQu?= =?us-ascii?q?CNSIRSy8IMwEBAQEBAQEBAQEBAQEBAQEBARcCQwESThMfGxEBDB4dORQSAQQTC?= =?us-ascii?q?IMYAYEbZAEOqmCCeIc9AwWJAoFYPoN0g0cCA4FfK4MFgiSZXgMEAgKBPoRKimC?= =?us-ascii?q?EEYgRijmHNAIEAgQFAhSBWIF0cIM5giUOCYNFhRSFPm+LKoEaAQE?= X-IPAS-Result: =?us-ascii?q?A2HhAgD20Uhbh8mZ6ERcHgEGDIJTIoEoD38oCoVQkl2ZBDs?= =?us-ascii?q?LIwuDB4E3AoJQITgUAQIBAQIBAQIBAQIQAQEBCgsJCCkjAQuCNSIRSy8IMwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARcCQwESThMfGxEBDB4dORQSAQQTCIMYAYEbZAEOqmC?= =?us-ascii?q?CeIc9AwWJAoFYPoN0g0cCA4FfK4MFgiSZXgMEAgKBPoRKimCEEYgRijmHNAIEA?= =?us-ascii?q?gQFAhSBWIF0cIM5giUOCYNFhRSFPm+LKoEaAQE?= Received: from esa1.dell-outbound2.iphmx.com ([68.232.153.201]) by esa1.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jul 2018 11:19:50 -0500 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa1.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jul 2018 22:19:45 +0600 Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w6DGSPal014396 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 13 Jul 2018 12:28:26 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com w6DGSPal014396 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1531499306; bh=UnpPcUzz7ASJ9Il8ZhSVyci09wM=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=DLH6nZ4f/Z/vl+oCXd9Te+RvhLhngNfZrZm8Jtax5/r8W0kIrsNJjJW4WjmKFQG4a 3LYGR443ipbMIF1fehBvdksFpbR25PMfLnjL1kpAPN4FItDQKsSgj52Hhd80NXBkwl H9PmNnKBchBHRUNK3CSDVAe2YI4UWeXEf8WYU8kk= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com w6DGSPal014396 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd51.lss.emc.com (RSA Interceptor) for ; Fri, 13 Jul 2018 12:28:07 -0400 Received: from MXHUB315.corp.emc.com (MXHUB315.corp.emc.com [10.146.3.93]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w6DGQmwX002610 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Fri, 13 Jul 2018 12:28:07 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB315.corp.emc.com ([10.146.3.93]) with mapi id 14.03.0399.000; Fri, 13 Jul 2018 12:27:57 -0400 To: "tsvwg@ietf.org" Thread-Topic: Montreal agenda posted, send slides please! Thread-Index: AdQaxiYwE+ohpNpqRBGeWHQvCn/sqw== Date: Fri, 13 Jul 2018 16:27:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.21.34] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D24327794936301D2A8EMX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [tsvwg] Montreal agenda posted, send slides please! X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 16:28:31 -0000 --_000_CE03DB3D7B45C245BCA0D24327794936301D2A8EMX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable TSVWG meets on Thursday afternoon in Montreal, 15:50-19:10 - room Centre Vi= lle on the ground floor. The agenda is posted: https://datatracker.ietf.org/meeting/102/materials/ag= enda-102-tsvwg Please send slides to the chairs (tsvwg-chairs@ietf.org) by mid-day Tuesday. Thanks, --David --_000_CE03DB3D7B45C245BCA0D24327794936301D2A8EMX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

TSVWG meets on Thursday afternoon in Montreal, 15:50= -19:10 - room Centre Ville on the ground floor.

 

The agenda is posted: https://datatracker.ietf.org/meeting/102/materials/agenda-102-tsvwg

 

Please send slides to the chairs (tsvwg-chairs@ietf.org) by mid-day Tuesday.<= /o:p>

 

Thanks, --David

 

--_000_CE03DB3D7B45C245BCA0D24327794936301D2A8EMX307CL04corpem_-- From nobody Fri Jul 13 09:49:16 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2939130DED for ; Fri, 13 Jul 2018 09:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=KKjpSsPi; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=rsa.com header.b=MP7Yikvg 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 zk7jDoR9zKcd for ; Fri, 13 Jul 2018 09:49:12 -0700 (PDT) Received: from esa4.dell-outbound.iphmx.com (esa4.dell-outbound.iphmx.com [68.232.149.214]) (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 3EA9F129C6B for ; Fri, 13 Jul 2018 09:49:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1531500552; x=1563036552; h=from:to:subject:date:message-id:mime-version; bh=yKDsG9wSEPA9Fo29fcx8fMlbJyiJ8Tlf/y+Ejh/5/Co=; b=KKjpSsPi/EhKByCtqInQVrm1VTjihjtXVDQy3UmVYFRb/njCVsDyxXvg jknLHO7xfaLRO3PGMBmkXbxC20TrcvT8MdnOzibtQgLUfGOvfu7kgI3ZH NfHKElH8y1+DpTpLsJmPN9UJsWCTqR/0Bdiu/qk+SOvtWGUXZzcRw7Zr2 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2HfAgBo10hbh2Ka6ERZAx4BBgyCUyKBK?= =?us-ascii?q?A9/KAqYLZk/Cy6EPgKCUCE4FAECAQECAQECAQECEAEBAQoLCQgpIwELgjUiEVY?= =?us-ascii?q?kDgEBAVMCD0dOEx8bEQEqHTkUEgEEEwiDGAGBG2QBqmyCeIc8CIkCgVg+iR8ME?= =?us-ascii?q?yaCa4Ikh2eRdwMEAgKIbJQekW0CBAIEBQIUgViBdHCDOYIzgkeBB4pSbzCKeoE?= =?us-ascii?q?aAQE?= X-IPAS-Result: =?us-ascii?q?A2HfAgBo10hbh2Ka6ERZAx4BBgyCUyKBKA9/KAqYLZk/Cy6?= =?us-ascii?q?EPgKCUCE4FAECAQECAQECAQECEAEBAQoLCQgpIwELgjUiEVYkDgEBAVMCD0dOE?= =?us-ascii?q?x8bEQEqHTkUEgEEEwiDGAGBG2QBqmyCeIc8CIkCgVg+iR8MEyaCa4Ikh2eRdwM?= =?us-ascii?q?EAgKIbJQekW0CBAIEBQIUgViBdHCDOYIzgkeBB4pSbzCKeoEaAQE?= Received: from esa4.dell-outbound2.iphmx.com ([68.232.154.98]) by esa4.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jul 2018 11:49:11 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa4.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jul 2018 22:49:10 +0600 Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd05.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w6DGn9GU003700 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 13 Jul 2018 12:49:10 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com w6DGn9GU003700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=rsa.com; s=jan2013; t=1531500550; bh=p8OUxIfS4KZ2js5MXRrGHdHqfpk=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=MP7YikvgJww+fFgwGsFsGtf0DaeJ5Flpp4h+uWcNzUPcJ5QvykPQYhW7+hZiVKPIt EXVFCI3aL8Bv3661LNm8kiXdnO3KPQW3WXgH/UUKGQya6Q5t54+xcxJwiBHUysxYAq glcwZwZlz2pI7I/f0SWm/4GrUN0e9kUJmNbsNggI= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com w6DGn9GU003700 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd01.lss.emc.com (RSA Interceptor) for ; Fri, 13 Jul 2018 12:48:55 -0400 Received: from MXHUB303.corp.emc.com (MXHUB303.corp.emc.com [10.146.3.29]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w6DGmt3w031953 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL) for ; Fri, 13 Jul 2018 12:48:56 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB303.corp.emc.com ([10.146.3.29]) with mapi id 14.03.0399.000; Fri, 13 Jul 2018 12:48:55 -0400 To: "tsvwg@ietf.org" Thread-Topic: L4S & Diffserv - incremental deployment Thread-Index: AdQayWD5mHxkCBVIQLaRR7tvOOYenw== Date: Fri, 13 Jul 2018 16:48:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.21.34] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D24327794936301D2B1DMX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [tsvwg] L4S & Diffserv - incremental deployment X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 16:49:15 -0000 --_000_CE03DB3D7B45C245BCA0D24327794936301D2B1DMX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bob, Regarding draft-briscoe-tsvwg-l4s-diffserv, writing as an individual, not a= s a WG chair. The draft currently seems to focus on the end-state of full deployment of L= 4S with Diffserv. I'm also interested in enabling incremental deployment o= f L4S - being able to enable/disable L4S based on DSCP value looks like a p= romising mechanism for that. Towards that end, the examples in Section 4 d= on't seem to cover all of the possibilities in a partial deployment of L4S,= where its use/non-use is controlled by DSCP. Section 6 could benefit from some related thought and editing: - Section 6.1: The guidance on not remarking DSCPs is scoped to L4S functio= nality. Obviously, Diffserv can and does remark DSCPs, so the advice shoul= d be that only Diffserv functionality remarks DSCPs, not L4S. - Section 6.2: This seems to be entirely about implementation, including wh= at to do on current hardware. I'd like to see a statement that at the pro= tocol specification level, Diffserv classification SHOULD precede ECN class= ification in order to enable L4S enable/disable on a per-DSCP basis, with t= he full 8-bit (DSCP + ECN) classifier being a possible implementation and c= onstraints of existing hardware (can't do that) being a possible reason to = not follow the SHOULD. Thanks, --David ---------------------------------------------------------------- David L. Black, Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 Mobile: +1 (978) 394-7754 David.Black@dell.com ---------------------------------------------------------------- --_000_CE03DB3D7B45C245BCA0D24327794936301D2B1DMX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<WG_Chair_Hat=3DOFF>

 

Bob,

 

Regarding draft-briscoe-tsvwg-l4s-diffserv, writing = as an individual, not as a WG chair.

 

The draft currently seems to focus on the end-state = of full deployment of L4S with Diffserv.  I’m also interested in= enabling incremental deployment of L4S - being able to enable/disable L4S = based on DSCP value looks like a promising mechanism for that.  Towards that end, the examples in Section 4 don’t se= em to cover all of the possibilities in a partial deployment of L4S, where = its use/non-use is controlled by DSCP.

 

Section 6 could benefit from some related thought an= d editing:

 

- Section 6.1: The guidance on not remarking DSCPs i= s scoped to L4S functionality.  Obviously, Diffserv can and does remar= k DSCPs, so the advice should be that only Diffserv functionality remarks D= SCPs, not L4S.

 

- Section 6.2: This seems to be entirely about imple= mentation, including what to do on current hardware.   I’d = like to see a statement that at the protocol specification level, Diffserv = classification SHOULD precede ECN classification in order to enable L4S enable/disable on a per-DSCP basis, with the full 8-bi= t (DSCP + ECN) classifier being a possible implementation and constrain= ts of existing hardware (can’t do that) being a possible reason to no= t follow the SHOULD.

 

</WG_Chair_Hat=3DOFF>

 

Thanks, --David

----------------------------------------------------= ------------

David L. Black, Distinguished Engineer

Dell EMC, 176 South St., Hopkinton, MA  01748

+1 (508) 293-7953    Mobile: += ;1 (978) 394-7754

David.Black@dell.com

----------------------------------------------------= ------------

 

--_000_CE03DB3D7B45C245BCA0D24327794936301D2B1DMX307CL04corpem_-- From nobody Fri Jul 13 10:26:11 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2A9130EDF for ; Fri, 13 Jul 2018 10:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 jaY7ntpE47Dt for ; Fri, 13 Jul 2018 10:26:04 -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 7C7BF130ED1 for ; Fri, 13 Jul 2018 10:26:04 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id r184-v6so6629664ywg.6 for ; Fri, 13 Jul 2018 10:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tCQCEA0rfqTD5pLxo/epMixR0NUY/eX9GhdMD+tPMRA=; b=m5QRespHoJ4xDK2nVWH5hGSiiRXWlyF56fCCBGPWSp0Orx5XCUf1MgqhcGsWOwNF5P FBKNG6Ci4XV6dnBjq+OYcAJF/PPGrqdNQVkIjiCg001ifB87G8g2B225Bwtm0GMCjjmn ulrjY21GgAAk5RtX8a4I/Kzy+2Lr7po9pmnqrMgSI4/Z0Di8GB1OUKpESJtqscwB5Jq9 ITuJW5pvGOIGZoELN3hzFxJxRUV08Fbfj5VfZChslw9yQfynpf2SMkKSGU3I+0vZsNYA E3zrh1Hh3KL7fL9Uy0ZGt7CQNSdXycpx0KeNQWT1lQjTt8WeKm/ZaScs5S33/f4bJomA ZmGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tCQCEA0rfqTD5pLxo/epMixR0NUY/eX9GhdMD+tPMRA=; b=QPNrkFyYWWB1jm5FBowm1kwIciZTgqptOrbFibbULO+Dj+1wa5H63NzT66wPfTfZsa oiNNI7kNwZ7U2nDhUQKs3XuEJLgbsfYZWbgjXV255UaZKVFOemTIOHPq8d/VE2rzWSxn aftuOghPu/INi2xA8wOUBq1h9JKcqZt7ifGXhTRMz8EnPvyosCkPQaQGGkjU+X3TBP4x 25Di5ACFd9seOqDoZPKHy/RxvW2X6LX2gDKHkME8T/ky0D0Tq0nAq/DAq/nZKgIiBbPI Z9LiDMbMFe2f65nMFFzopM5JRaej4iFYVcx/cD3+osIiE2SXcJQYUvzDsnzG8fH/6NiC z60A== X-Gm-Message-State: AOUpUlGzpU4JY5UJfybnA9FUDnPvznvchi0JqdQpNHv8Qtw/EBcMzgC2 DIn0siH9D29g+CnkW29VT6kbt5VCRqPIPtQAOeE= X-Google-Smtp-Source: AAOMgpe54SOyNvcgT5zMORpwLronFiVicH0sk7mSDF9BtfQFNVkOQiGih6ybGarA4JS1W+LL7bifnoSGaEfjQ07SFTQ= X-Received: by 2002:a0d:e081:: with SMTP id j123-v6mr3769319ywe.279.1531502763522; Fri, 13 Jul 2018 10:26:03 -0700 (PDT) MIME-Version: 1.0 References: <6f8ee7ac-9318-b4ab-626c-a3a36acba042@ericsson.com> In-Reply-To: <6f8ee7ac-9318-b4ab-626c-a3a36acba042@ericsson.com> From: Spencer Dawkins at IETF Date: Fri, 13 Jul 2018 12:25:50 -0500 Message-ID: To: Magnus Westerlund Cc: tsvwg@ietf.org Content-Type: multipart/alternative; boundary="00000000000031410d0570e4c69a" Archived-At: Subject: Re: [tsvwg] Experience and Status of ECN in QUIC work X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 17:26:10 -0000 --00000000000031410d0570e4c69a Content-Type: text/plain; charset="UTF-8" Responsible AD hat is even more off than David's WG chair hat in his response ... On Thu, Jul 5, 2018 at 7:41 AM Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > TSVWG, > > ECN support was added to QUIC in the latest draft versions (-13). The > relevant documents that include ECN related text are: > > https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ > https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/ > > The inclusion of ECN in QUIC can be summarized as. Each sender performs > initial verification when the connection is established or migrated by > setting ECT on the packets it send. The receiver will report if it sees ECN > marks, i.e. any value other than not-ECT, using a new acknowledgement frame > type (ACK_ECN) that includes counters of how many packets with the various > markings the receiver have seen since connection establishment. If the > receiver gets not-ECT or can't read ECN marks then it uses the ACK frame to > report these packets so that the sender can learn of the lack of ECT > capability and turn its marking off. Marking consistency are continuously > verified. ECN black hole mitigation is discussed and a possible mechanism > is that any RTO will result in retransmission without ECT marks. > > The inclusion of ECN in QUIC has so far been fairly well discussed. > Initially by the design team. Then at the QUIC interim meeting in June, > followed by a lot of discussion of the actual text proposal on github. > Thanks to everyone that engaged. Based on these discussions there are some > questions and experience that I have noticed that is worth spreading and > discussing. This is also the topics coming in the TSVWG session for my > agenda item. > I'd like to thank the QUIC-ECN design team for surfacing this in TSVWG at this time. > Also I don't believe the last word is said about details of how ECN in > QUIC is realized. There are currently three different github issues related > to ECN: > > - Improve ACK_ECN frame encoding (e.g., use bit-vector) > ( > https://github.com/quicwg/base-drafts/issues/1439) > - Fragility in ECN counters with lost acks > ( > https://github.com/quicwg/base-drafts/issues/1481) > - Detect adversarial ECN reporting > ( > https://github.com/quicwg/base-drafts/issues/1426) > > So the things I want to bring to attention are: > > > A. Suppression of ECN values in packet duplicates > > In QUIC the drafts currently says that a receiver should suppress the ECN > values received in any packet duplicates. The main reason for that is to > mitigate a potential active attack by a off-path attacker that has some > capability to receive a copy of the packets of the target flow. We call it > an on-the-side attack. By taking a copy of a legit packet, and changing the > ECN field to ECN-CE and then forward the modified copy to the intended > receiver one can perform a denial of service attack by driving down the > congestion window. To mitigate this, the recommendation is to care about > only the first arrived packet. This forces an on-the-side attacker to be > able to race their attack packets with the original packet. > > The downside of this is of course that an actual network duplication where > none-first packets gets marked as ECN-CE after the duplication we ignore > the congestion signal. My personal standpoint is that this is okay. If not > the first packet was marked then congestion may not be so bad that it is a > problem if the duplication don't happens. Secondly, if it is any persistent > congestion then this flow will be marked in a later packet. There was some > disagreement on this so I think it is worth more discussion. > > > B. Will ECT(0) and ECT(1) be mixed in one packet flow? > > In the discussions around optimizing how the ECN information reported from > receiver to sender this question arose. If one can make assumption that > within a connection one will use only one of the ECT codepoints then we can > optimize the reporting based on that assumption. So how safe is this > assumption? And in this case, what is the importance of being able to > detect ECT codepoint remarking, i.e. changing between 0 and 1 in either > direction? > > > C. Detecting Cheating Receivers > > As there are some risks in certain deployment situations that the receiver > would have an incentive to lie about if an ECN-CE mark was received or not > to gain throughput. A sender could detect this case by sending packets > marked as ECN-CE to verify that receiver reports these packets are being > marked. As the sender will ignore the ECN-CE marks it self generated there > is a risk that these marks hide real CE marks. Thus, the general question > is how often, at most, should a sender mark with ECN-CE? > In my mind, A and C are related - how perfectly does a sender need to react perfectly to ECN-CE markings? In A, I think that may be where Magnus is coming from - the sender is already reacting to ECN-CE, and if the sender hasn't responded sufficiently, the flow will continue to be marked in later packets, and the sender will have an opportunity to react again, until it has reacted sufficiently. Is that the question? In C, I'm trying to understand how much a receiver can benefit by cheating. ISTM that if a receiver sees ECN-CE markings and doesn't reflect that back to the sender, one of two things will happen. - Either the sender really doesn't need to slow down (so no further ECN-CE marks arrive at the receiver), or - The sender really does need to slow down (so the receiver keeps cheating until actual packets get lost, which the receiver really can't disguise), and is finally slowing down based on packet losses I understand that CoDel and PIE are Experimental, and I understand that L4S is still in TSV, but does a receiver cheating now, and going forward, make as much sense as it did when https://tools.ietf.org/html/rfc3168#section-18(*) was published in 2001, with congestion control mechanisms available at that time? It seems like that's just begging for bufferbloat, followed by losses, followed by poor performance during recovery. Curiously, Spencer, with no hats (*) I understand that https://tools.ietf.org/html/rfc3168#section-18 is discussing misbehaving routers, not misbehaving receivers, but that was a handy reference for "what happens if the sender can't trust ECN signals" ... > D. Delayed Acknowledgement and ECN > > We also have an interesting discussion around ECN, Delayed Acknowledgement > and the interaction with recovery period. QUIC supports delayed > acknowledgement. So far there are quite a lot of implementer freedom of how > to use this. What is currently specified is that when receiving an ECN-CE > mark the receiver sends an immediate ACK, so get rapid response to the > congestion signal. When the ACK_ECN reaches the sender it will go into > Recovery until a packet sent after entering recovery has been acknowledged. > During recovery as the congestion window already is reduced and frozen the > reception of additional ECN-CE marks (at least for the current congestion > control mechanism) is not that important. What is important is if any > packets are ECN-CE marked when exiting recovery. Marks on packets sent > after recovery should result in a new congestion event and new recovery > period. To resolve this the current requirement is to immediately > acknowledge each ECN-CE marks. This will result in some additional > acknowledgements. > > There has been some discussion if one want to optimize this case or if it > is not worth it. One direction was to ensure that even with delayed ACKs > one get frequent enough acknowledgements. This resulted in discussion in > the direction of ensuring that the longest delay before acknowledging is > caped at a quarter of the RTT. That way one achieve no worse than quarter > RTT resolution on the ECN-CE marks. Another potential direction is explicit > indication of which packet numbers that would resolve this uncertainty. > Then also exists the question if the receiver needs any indication of > recovery periods to optimize the acknowledgements. > > E. Utility of detailed CE information > > As there has been discussion about explicitly indicate which packet > numbers was marked as CE, it is also good to understand if there are any > significant utility of having this information for the sender compared to > what the counters provide. I assume this goes into the potential for > congestion control mechanism evolution. But, does it matter for example for > L4S? > > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Network Architecture & Protocols, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --00000000000031410d0570e4c69a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Responsible AD hat is even more off than David's WG ch= air hat in his response ...=C2=A0

On Thu, Jul 5, 2018 at 7:41 AM Magnus Westerlund <magnus.westerlund@ericsson.com&g= t; wrote:
=20 =20 =20

TSVWG,

ECN support was added to QUIC in the latest draft versions (-13). The relevant documents that include ECN related text are:

https://datatracker.ietf.org/doc/draft-ietf-quic-transport/
https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/

The inclusion of ECN in QUIC can be summarized as. Each sender performs initial verification when the connection is established or migrated by setting ECT on the packets it send. The receiver will report if it sees ECN marks, i.e. any value other than not-ECT, using a new acknowledgement frame type (ACK_ECN) that includes counters of how many packets with the various markings the receiver have seen since connection establishment. If the receiver gets not-ECT or can't read ECN marks then it uses the AC= K frame to report these packets so that the sender can learn of the lack of ECT capability and turn its marking off. Marking consistency are continuously verified. ECN black hole mitigation is discussed and a possible mechanism is that any RTO will result in retransmission without ECT marks.=C2=A0

The inclusion of ECN in QUIC has so far been fairly well discussed. Initially by the design team. Then at the QUIC interim meeting in June, followed by a lot of discussion of the actual text proposal on github. Thanks to everyone that engaged. Based on these discussions there are some questions and experience that I have noticed that is worth spreading and discussing. This is also the topics coming in the TSVWG session for my agenda item.

I'd like to thank the QUIC-ECN design team for sur= facing this in TSVWG at this time.=C2=A0=C2=A0

Also I don't believe the last word is said about details of how ECN in QUIC is realized. There are currently three different github issues related to ECN:

- I= mprove ACK_ECN frame encoding (e.g., use bit-vector) (ht= tps://github.com/quicwg/base-drafts/issues/1439)
- Fr= agility in ECN counters with lost acks (ht= tps://github.com/quicwg/base-drafts/issues/1481)
- De= tect adversarial ECN reporting (ht= tps://github.com/quicwg/base-drafts/issues/1426)

So the things I want to bring to attention are:


A. Suppression of ECN values in packet duplicates

In QUIC the drafts currently says that a receiver should suppress the ECN values received in any packet duplicates. The main reason for that is to mitigate a potential active attack by a off-path attacker that has some capability to receive a copy of the packets of the target flow. We call it an on-the-side attack. By taking a copy of a legit packet, and changing the ECN field to ECN-CE and then forward the modified copy to the intended receiver one can perform a denial of service attack by driving down the congestion window. To mitigate this, the recommendation is to care about only the first arrived packet. This forces an on-the-side attacker to be able to race their attack packets with the original packet.

The downside of this is of course that an actual network duplication where none-first packets gets marked as ECN-CE after the duplication we ignore the congestion signal. My personal standpoint is that this is okay. If not the first packet was marked then congestion may not be so bad that it is a problem if the duplication don't happens. Secondly, if it is any persistent congestion then this flow will be marked in a later packet. There was some disagreement on this so I think it is worth more discussion.


B. Will ECT(0) and ECT(1) be mixed in one packet flow?

In the discussions around optimizing how the ECN information reported from receiver to sender this question arose. If one can make assumption that within a connection one will use only one of the ECT codepoints then we can optimize the reporting based on that assumption. So how safe is this assumption? And in this case, what is the importance of being able to detect ECT codepoint remarking, i.e. changing between 0 and 1 in either direction?


C. Detecting Cheating Receivers

As there are some risks in certain deployment situations that the receiver would have an incentive to lie about if an ECN-CE mark was received or not to gain throughput. A sender could detect this case by sending packets marked as ECN-CE to verify that receiver reports these packets are being marked. As the sender will ignore the ECN-CE marks it self generated there is a risk that these marks hide real CE marks. Thus, the general question is how often, at most, should a sender mark with ECN-CE?

In my mind, A and C are related - how perfectly does a sender need to= react perfectly to ECN-CE markings?

In A, I think= that may be where Magnus is coming from - the sender is already reacting t= o ECN-CE, and if the sender hasn't responded sufficiently, the flow wil= l continue to be marked in later packets, and the sender will have an oppor= tunity to react again, until it has reacted sufficiently. Is that the quest= ion?=C2=A0

In C, I'm trying to understand how = much a receiver can benefit by cheating. ISTM that if a receiver sees ECN-C= E markings and doesn't reflect that back to the sender, one of two thin= gs will happen.
  • Either the sender really doesn't need= to slow down (so no further ECN-CE marks arrive at the receiver), or=C2=A0=
  • The sender really does need to slow down (so the receiver keeps ch= eating until actual packets get lost, which the receiver really can't d= isguise), and is finally slowing down based on packet losses
= I understand that CoDel and PIE are Experimental, and I understand that L4S= is still in TSV, but does a receiver cheating now, and going forward, make= as much sense as it did when=C2=A0https://tools.ietf.org/html/rfc3168#section-18(*)= was published in 2001, with congestion control mechanisms available at tha= t time? It seems like that's just begging for bufferbloat, followed by = losses, followed by poor performance during recovery.

<= /div>
Curiously,

Spencer, with no hats

(*) I understand that=C2=A0https://tools.ietf.org/html/rfc3168#section-18= is discussing misbehaving routers, not misbehaving receivers, but that= was a handy reference for "what happens if the sender can't trust= ECN signals" ...

D. Delayed Acknowledgement and ECN

We also have an interesting discussion around ECN, Delayed Acknowledgement and the interaction with recovery period. QUIC supports delayed acknowledgement. So far there are quite a lot of implementer freedom of how to use this. What is currently specified is that when receiving an ECN-CE mark the receiver sends an immediate ACK, so get rapid response to the congestion signal. When the ACK_ECN reaches the sender it will go into Recovery until a packet sent after entering recovery has been acknowledged. During recovery as the congestion window already is reduced and frozen the reception of additional ECN-CE marks (at least for the current congestion control mechanism) is not that important. What is important is if any packets are ECN-CE marked when exiting recovery. Marks on packets sent after recovery should result in a new congestion event and new recovery period. To resolve this the current requirement is to immediately acknowledge each ECN-CE marks. This will result in some additional acknowledgements.

There has been some discussion if one want to optimize this case or if it is not worth it. One direction was to ensure that even with delayed ACKs one get frequent enough acknowledgements. This resulted in discussion in the direction of ensuring that the longest delay before acknowledging is caped at a quarter of the RTT. That way one achieve no worse than quarter RTT resolution on the ECN-CE marks. Another potential direction is explicit indication of which packet numbers that would resolve this uncertainty. Then also exists the question if the receiver needs any indication of recovery periods to optimize the acknowledgements.

E. Utility of detailed CE information

As there has been discussion about explicitly indicate which packet numbers was marked as CE, it is also good to understand if there are any significant utility of having this information for the sender compared to what the counters provide. I assume this goes into the potential for congestion control mechanism evolution. But, does it matter for example for L4S?


Che=
ers=20

Magnus Westerlund=20

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------
  
--00000000000031410d0570e4c69a-- From nobody Fri Jul 13 10:39:31 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6EB130EE9; Fri, 13 Jul 2018 10:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 tO5us-uFxF1l; Fri, 13 Jul 2018 10:39:18 -0700 (PDT) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E559F130E79; Fri, 13 Jul 2018 10:39:17 -0700 (PDT) Received: by mail-yb0-x234.google.com with SMTP id c3-v6so3514498ybi.13; Fri, 13 Jul 2018 10:39:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iceaKbLKA6xCXhcr53tyoSJMo/GGQ/GtlbVoCFkLXVM=; b=OKuY54FTzbAMufb8b9ZfJ7nbBAuPRSokNjfYkq4u0No9/3Llwl24jyidL1erGGIngz rPprm6aygc+LIIocMOuNl1vF/gf3X1LQKt9xJjseZZec7Hz+F//d2nMKwMTNveoRPHw7 xa70PF8nAXA9WDW9GduiRs/yYGXM0smaobW632000aZv0urxYLhuBho8qyGcWsVtIpSn fWGmgQ3LcmhyYN90Whu8VMuaxKucvmUoAxOwlWOGfs5aJ+kXQhxW7T7ZrdmyzafTSpRl 0DlEHr6N+n/rtgRWsFEmwFYcd1jaWViYvXvIqjeTQwR7NkmTjHEGL7VOsINQ5ufChvL+ tLTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iceaKbLKA6xCXhcr53tyoSJMo/GGQ/GtlbVoCFkLXVM=; b=nNiwmdSjLdxHUJ9SWb8JR71i4gXyaSanU3FRhJuq3q6Q+5+y7Yp8GMfgBBzzBHKzk5 p46HWEnTtBkP1kYnAXGty2/Ou1L29eXF/fPKvquotwFYhPiuhC4e217mqTAIz8nIBcXn YRZHfPdhzRDs8fo0LmcbxsU1ke8xEvGIIm9osR+p9K6PCexB2VKFmvOq1A+5YgdFdZqk 74UdYDymOsxNB2L+RwSDME4lAUZAferj05I7wvvk0Zgn/sv9+kSXbbCNqq3TtPTA/C3L /Qay8jpbvBJlC5NWRgaD9HTdNU20IKdC6JSLPR3htI8CH4mTjNNTq0iDdyfMW7znwYvh f/4g== X-Gm-Message-State: AOUpUlFnOabT4mnmGrpCAhdmqBVnzP798Siv3hFcMp4ycpcd+WOulkdM CRTlWGPMj/No5IFKEv5A7knkAvdk3hlc0CiBX1I= X-Google-Smtp-Source: AAOMgpfX7uOM/ArcxtwNhrAGOEErkU0IrCgRlGsOdQySsots0AmjVUGuvabfm5e/W9q68VCiDAqXLcz+X0qTL478GmI= X-Received: by 2002:a25:504a:: with SMTP id e71-v6mr3987159ybb.44.1531503557005; Fri, 13 Jul 2018 10:39:17 -0700 (PDT) MIME-Version: 1.0 References: <20180710013143.95823B815B4@rfc-editor.org> In-Reply-To: From: Spencer Dawkins at IETF Date: Fri, 13 Jul 2018 12:39:04 -0500 Message-ID: To: Michael Tuexen Cc: ncw@realvnc.com, randall , tsvwg@ietf.org, IESG , RFC Editor Content-Type: multipart/alternative; boundary="0000000000007cd7f40570e4f532" Archived-At: Subject: Re: [tsvwg] [Errata Verified] RFC4960 (5202) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 17:39:22 -0000 --0000000000007cd7f40570e4f532 Content-Type: text/plain; charset="UTF-8" Hi, Michael, On Tue, Jul 10, 2018 at 5:11 AM Michael Tuexen < michael.tuexen@lurchi.franken.de> wrote: > > On 10. Jul 2018, at 03:31, RFC Errata System > wrote: > > > > The following errata report has been verified for RFC4960, > > "Stream Control Transmission Protocol". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata/eid5202 > > > > -------------------------------------- > > Status: Verified > Hi Spencer, > > just to be clear: > > This errata suggests two corrections: > (1) Ensure that the gap ack blocks are not overlapping. > (2) Ensure that the gap ack blocks are monotonic. > > The result of the discussion (and therefore what has been included in > https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-06#section-3.47 > ) > is the following: > * The intention actually was to have the gap blocks isolated. So accepting > (1) > is OK. > * In some cases you blocks might not be monotonic. This is the same as with > the handling of gap reports in TCP SACK. Therefore (2) is NOT OK. > Right. > Not sure if this covered by "Verified". > So, you're thinking "Held for document update"? This case is slightly odd, because one correction is correct, so that's why I marked the errata as "Verified", even though the other correction is not. I'm happy to hear other opinions (I'm not an errata system wizard, and haven't had an errata that fit this corner case previously). If it seems more appropriate to people that I mark the errata as "Held for document update", I'm happy to do that. Just let me know. Spencer > Best regards > Michael > > Type: Technical > > > > Reported by: Nicholas Wilson > > Date Reported: 2017-12-13 > > Verified by: Spencer Dawkins (IESG) > > > > Section: 3.3.4. > > > > Original Text > > ------------- > > The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack > > Block acknowledges a subsequence of TSNs received following a break > > in the sequence of received TSNs. By definition, all TSNs > > acknowledged by Gap Ack Blocks are greater than the value of the > > Cumulative TSN Ack. > > > > Corrected Text > > -------------- > > The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack > > Block acknowledges a subsequence of TSNs received following a break > > in the sequence of received TSNs. By definition, all TSNs > > acknowledged by Gap Ack Blocks are greater than the value of the > > Cumulative TSN Ack. > > > > The sequence of Gap Ack Blocks MUST be an increasing sequence of > > ranges, non-intersecting, and with at least one TSN as a gap between > > each Block and between the Cumulative TSN Ack and the first Block. > > > > Notes > > ----- > > It seems clear that the Gap Ack sequence must be sent in its "canonical" > form (monotonic non-overlapping ranges) but I can't find anywhere where > this is actually stated. > > > > It is implied (but not stated) by the following sentence on the next > page, which implies that there is no freedom of choice in how the Gap Ack > sequence is encoded: > > > > "For example, assume that ... > > then the parameter part of the SACK MUST be constructed as follows" > > > > -------------------------------------- > > RFC4960 (draft-ietf-tsvwg-2960bis-05) > > -------------------------------------- > > Title : Stream Control Transmission Protocol > > Publication Date : September 2007 > > Author(s) : R. Stewart, Ed. > > Category : PROPOSED STANDARD > > Source : Transport Area Working Group > > Area : Transport > > Stream : IETF > > Verifying Party : IESG > > > > --0000000000007cd7f40570e4f532 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Michael,=C2=A0

On Tue, Jul 10, 2018 at 5:11 AM Michael Tuexen <michael.tuexen@lurchi.franken.de> wrote:
> On 10. Jul 2018,= at 03:31, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
>
> The following errata report has been verified for RFC4960,
> "Stream Control Transmission Protocol".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5202
>
> --------------------------------------
> Status: Verified
Hi Spencer,

just to be clear:

This errata suggests two corrections:
(1) Ensure that the gap ack blocks are not overlapping.
(2) Ensure that the gap ack blocks are monotonic.

The result of the discussion (and therefore what has been included in
https://tools.ietf.org/ht= ml/draft-ietf-tsvwg-rfc4960-errata-06#section-3.47)
is the following:
* The intention actually was to have the gap blocks isolated. So accepting = (1)
=C2=A0 is OK.
* In some cases you blocks might not be monotonic. This is the same as with=
=C2=A0 the handling of gap reports in TCP SACK. Therefore (2) is NOT OK.

Right.=C2=A0
=C2=A0
Not sure if this covered by "Verified".<= br>

So, you're thinking "Held for = document update"?=C2=A0

This case is slightly= odd, because one correction is correct, so that's why I marked the err= ata as "Verified", even though the other correction is not. I'= ;m happy to hear other opinions (I'm not an errata system wizard, and h= aven't had an errata that fit this corner case previously).=C2=A0
=

If it seems more appropriate to people that I mark the = errata as "Held for document update", I'm happy to do that.

Just let me know.=C2=A0

Sp= encer


Best regards
Michael
> Type: Technical
>
> Reported by: Nicholas Wilson <ncw@realvnc.com>
> Date Reported: 2017-12-13
> Verified by: Spencer Dawkins (IESG)
>
> Section: 3.3.4.
>
> Original Text
> -------------
>=C2=A0 =C2=A0The SACK also contains zero or more Gap Ack Blocks.=C2=A0 = Each Gap Ack
>=C2=A0 =C2=A0Block acknowledges a subsequence of TSNs received followin= g a break
>=C2=A0 =C2=A0in the sequence of received TSNs.=C2=A0 By definition, all= TSNs
>=C2=A0 =C2=A0acknowledged by Gap Ack Blocks are greater than the value = of the
>=C2=A0 =C2=A0Cumulative TSN Ack.
>
> Corrected Text
> --------------
>=C2=A0 =C2=A0The SACK also contains zero or more Gap Ack Blocks.=C2=A0 = Each Gap Ack
>=C2=A0 =C2=A0Block acknowledges a subsequence of TSNs received followin= g a break
>=C2=A0 =C2=A0in the sequence of received TSNs.=C2=A0 By definition, all= TSNs
>=C2=A0 =C2=A0acknowledged by Gap Ack Blocks are greater than the value = of the
>=C2=A0 =C2=A0Cumulative TSN Ack.
>
>=C2=A0 =C2=A0The sequence of Gap Ack Blocks MUST be an increasing seque= nce of
>=C2=A0 =C2=A0ranges, non-intersecting, and with at least one TSN as a g= ap between
>=C2=A0 =C2=A0each Block and between the Cumulative TSN Ack and the firs= t Block.
>
> Notes
> -----
> It seems clear that the Gap Ack sequence must be sent in its "can= onical" form (monotonic non-overlapping ranges) but I can't find a= nywhere where this is actually stated.
>
> It is implied (but not stated) by the following sentence on the next p= age, which implies that there is no freedom of choice in how the Gap Ack se= quence is encoded:
>
>=C2=A0 =C2=A0 "For example, assume that ...
>=C2=A0 =C2=A0 then the parameter part of the SACK MUST be constructed a= s follows"
>
> --------------------------------------
> RFC4960 (draft-ietf-tsvwg-2960bis-05)
> --------------------------------------
> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Stream C= ontrol Transmission Protocol
> Publication Date=C2=A0 =C2=A0 : September 2007
> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: R. Stewart, Ed. > Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD<= br> > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Transport Are= a Working Group
> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Transpor= t
> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
>

--0000000000007cd7f40570e4f532-- From nobody Fri Jul 13 10:48:15 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195FC130ED1; Fri, 13 Jul 2018 10:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 Y5yx8_3vxWNQ; Fri, 13 Jul 2018 10:48:10 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01720130DC2; Fri, 13 Jul 2018 10:48:09 -0700 (PDT) Received: from [IPv6:2003:cd:6f11:e500:106:a1bb:4b5:fcab] (p200300CD6F11E5000106A1BB04B5FCAB.dip0.t-ipconnect.de [IPv6:2003:cd:6f11:e500:106:a1bb:4b5:fcab]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id A951B721E2825; Fri, 13 Jul 2018 19:48:06 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Michael Tuexen In-Reply-To: Date: Fri, 13 Jul 2018 19:48:05 +0200 Cc: ncw@realvnc.com, randall , tsvwg@ietf.org, IESG , RFC Editor Content-Transfer-Encoding: quoted-printable Message-Id: <9EED3DC1-1788-4C69-86A5-A0524676F054@lurchi.franken.de> References: <20180710013143.95823B815B4@rfc-editor.org> To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [tsvwg] [Errata Verified] RFC4960 (5202) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 17:48:13 -0000 > On 13. Jul 2018, at 19:39, Spencer Dawkins at IETF = wrote: >=20 > Hi, Michael,=20 >=20 > On Tue, Jul 10, 2018 at 5:11 AM Michael Tuexen = wrote: > > On 10. Jul 2018, at 03:31, RFC Errata System = wrote: > >=20 > > The following errata report has been verified for RFC4960, > > "Stream Control Transmission Protocol".=20 > >=20 > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata/eid5202 > >=20 > > -------------------------------------- > > Status: Verified > Hi Spencer, >=20 > just to be clear: >=20 > This errata suggests two corrections: > (1) Ensure that the gap ack blocks are not overlapping. > (2) Ensure that the gap ack blocks are monotonic. >=20 > The result of the discussion (and therefore what has been included in > = https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-06#section-3.4= 7) > is the following: > * The intention actually was to have the gap blocks isolated. So = accepting (1) > is OK. > * In some cases you blocks might not be monotonic. This is the same as = with > the handling of gap reports in TCP SACK. Therefore (2) is NOT OK. >=20 > Right.=20 > =20 > Not sure if this covered by "Verified". >=20 > So, you're thinking "Held for document update"?=20 >=20 > This case is slightly odd, because one correction is correct, so = that's why I marked the errata as "Verified", even though the other = correction is not. I'm happy to hear other opinions (I'm not an errata = system wizard, and haven't had an errata that fit this corner case = previously).=20 >=20 > If it seems more appropriate to people that I mark the errata as "Held = for document update", I'm happy to do that. >=20 > Just let me know.=20 Maybe "Held for document update" is more appropriate... I just want to avoid that by stating "Verified" reader make the assumption that both suggestions/comments are correct. Best regards Michael >=20 > Spencer >=20 >=20 > Best regards > Michael > > Type: Technical > >=20 > > Reported by: Nicholas Wilson > > Date Reported: 2017-12-13 > > Verified by: Spencer Dawkins (IESG) > >=20 > > Section: 3.3.4. > >=20 > > Original Text > > ------------- > > The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack > > Block acknowledges a subsequence of TSNs received following a = break > > in the sequence of received TSNs. By definition, all TSNs > > acknowledged by Gap Ack Blocks are greater than the value of the > > Cumulative TSN Ack. > >=20 > > Corrected Text > > -------------- > > The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack > > Block acknowledges a subsequence of TSNs received following a = break > > in the sequence of received TSNs. By definition, all TSNs > > acknowledged by Gap Ack Blocks are greater than the value of the > > Cumulative TSN Ack. > >=20 > > The sequence of Gap Ack Blocks MUST be an increasing sequence of > > ranges, non-intersecting, and with at least one TSN as a gap = between > > each Block and between the Cumulative TSN Ack and the first Block. > >=20 > > Notes > > ----- > > It seems clear that the Gap Ack sequence must be sent in its = "canonical" form (monotonic non-overlapping ranges) but I can't find = anywhere where this is actually stated. > >=20 > > It is implied (but not stated) by the following sentence on the next = page, which implies that there is no freedom of choice in how the Gap = Ack sequence is encoded: > >=20 > > "For example, assume that ... > > then the parameter part of the SACK MUST be constructed as = follows" > >=20 > > -------------------------------------- > > RFC4960 (draft-ietf-tsvwg-2960bis-05) > > -------------------------------------- > > Title : Stream Control Transmission Protocol > > Publication Date : September 2007 > > Author(s) : R. Stewart, Ed. > > Category : PROPOSED STANDARD > > Source : Transport Area Working Group > > Area : Transport > > Stream : IETF > > Verifying Party : IESG > >=20 >=20 From nobody Fri Jul 13 11:02:48 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707E4126DBF for ; Fri, 13 Jul 2018 11:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); 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 LT63k0sTM-0j for ; Fri, 13 Jul 2018 11:02:43 -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 A1721130ED8 for ; Fri, 13 Jul 2018 11:02:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=hNV4O8Y1Y54WCHFQbWLNWWrmdstuSgRmgB1n5yz9fker9Sf1oAQyjsrjsMRiYauiVRWCl2+qZ38hp/us8n1++/pIe6txKQ8u1ciE0vf2xO+NKEUFtpKyyMIXJPgK3+poSAL3FUFVG/102u9MNWnkxsViw5fcchJ8JXpBdRaKP18=; 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 5800 invoked from network); 13 Jul 2018 20:01:40 +0200 Received: from unknown (HELO ?172.20.4.114?) (207.96.227.254) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 13 Jul 2018 20:01:40 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <9EED3DC1-1788-4C69-86A5-A0524676F054@lurchi.franken.de> Date: Fri, 13 Jul 2018 14:01:36 -0400 Cc: Michael Tuexen , ncw@realvnc.com, RFC Editor , tsvwg@ietf.org, randall , IESG Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180710013143.95823B815B4@rfc-editor.org> <9EED3DC1-1788-4C69-86A5-A0524676F054@lurchi.franken.de> To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.3445.8.2) X-PPP-Message-ID: <20180713180140.5790.25413@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [tsvwg] [Errata Verified] RFC4960 (5202) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 18:02:47 -0000 Spencer, I guess, you can also edit the errata and remove the second = part (or at minimum at a comment). Maybe double-check with the = secretary! Or alternatively, you reject this errata which a comment that one part = is incorrect, and submit a new errata with only the correct part=E2=80=A6 Mirja > Am 13.07.2018 um 13:48 schrieb Michael Tuexen = : >=20 >> On 13. Jul 2018, at 19:39, Spencer Dawkins at IETF = wrote: >>=20 >> Hi, Michael,=20 >>=20 >> On Tue, Jul 10, 2018 at 5:11 AM Michael Tuexen = wrote: >>> On 10. Jul 2018, at 03:31, RFC Errata System = wrote: >>>=20 >>> The following errata report has been verified for RFC4960, >>> "Stream Control Transmission Protocol".=20 >>>=20 >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata/eid5202 >>>=20 >>> -------------------------------------- >>> Status: Verified >> Hi Spencer, >>=20 >> just to be clear: >>=20 >> This errata suggests two corrections: >> (1) Ensure that the gap ack blocks are not overlapping. >> (2) Ensure that the gap ack blocks are monotonic. >>=20 >> The result of the discussion (and therefore what has been included in >> = https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-06#section-3.4= 7) >> is the following: >> * The intention actually was to have the gap blocks isolated. So = accepting (1) >> is OK. >> * In some cases you blocks might not be monotonic. This is the same = as with >> the handling of gap reports in TCP SACK. Therefore (2) is NOT OK. >>=20 >> Right.=20 >>=20 >> Not sure if this covered by "Verified". >>=20 >> So, you're thinking "Held for document update"?=20 >>=20 >> This case is slightly odd, because one correction is correct, so = that's why I marked the errata as "Verified", even though the other = correction is not. I'm happy to hear other opinions (I'm not an errata = system wizard, and haven't had an errata that fit this corner case = previously).=20 >>=20 >> If it seems more appropriate to people that I mark the errata as = "Held for document update", I'm happy to do that. >>=20 >> Just let me know.=20 > Maybe "Held for document update" is more appropriate... I just want to > avoid that by stating "Verified" reader make the assumption that both > suggestions/comments are correct. >=20 > Best regards > Michael >>=20 >> Spencer >>=20 >>=20 >> Best regards >> Michael >>> Type: Technical >>>=20 >>> Reported by: Nicholas Wilson >>> Date Reported: 2017-12-13 >>> Verified by: Spencer Dawkins (IESG) >>>=20 >>> Section: 3.3.4. >>>=20 >>> Original Text >>> ------------- >>> The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack >>> Block acknowledges a subsequence of TSNs received following a break >>> in the sequence of received TSNs. By definition, all TSNs >>> acknowledged by Gap Ack Blocks are greater than the value of the >>> Cumulative TSN Ack. >>>=20 >>> Corrected Text >>> -------------- >>> The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack >>> Block acknowledges a subsequence of TSNs received following a break >>> in the sequence of received TSNs. By definition, all TSNs >>> acknowledged by Gap Ack Blocks are greater than the value of the >>> Cumulative TSN Ack. >>>=20 >>> The sequence of Gap Ack Blocks MUST be an increasing sequence of >>> ranges, non-intersecting, and with at least one TSN as a gap = between >>> each Block and between the Cumulative TSN Ack and the first Block. >>>=20 >>> Notes >>> ----- >>> It seems clear that the Gap Ack sequence must be sent in its = "canonical" form (monotonic non-overlapping ranges) but I can't find = anywhere where this is actually stated. >>>=20 >>> It is implied (but not stated) by the following sentence on the next = page, which implies that there is no freedom of choice in how the Gap = Ack sequence is encoded: >>>=20 >>> "For example, assume that ... >>> then the parameter part of the SACK MUST be constructed as = follows" >>>=20 >>> -------------------------------------- >>> RFC4960 (draft-ietf-tsvwg-2960bis-05) >>> -------------------------------------- >>> Title : Stream Control Transmission Protocol >>> Publication Date : September 2007 >>> Author(s) : R. Stewart, Ed. >>> Category : PROPOSED STANDARD >>> Source : Transport Area Working Group >>> Area : Transport >>> Stream : IETF >>> Verifying Party : IESG >>>=20 >>=20 >=20 From nobody Fri Jul 13 11:22:55 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D635130E03; Fri, 13 Jul 2018 11:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 bcM6OS_Z15it; Fri, 13 Jul 2018 11:22:45 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA7EA130E46; Fri, 13 Jul 2018 11:22:44 -0700 (PDT) Received: from [IPv6:2003:cd:6f11:e500:106:a1bb:4b5:fcab] (p200300CD6F11E5000106A1BB04B5FCAB.dip0.t-ipconnect.de [IPv6:2003:cd:6f11:e500:106:a1bb:4b5:fcab]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id CE5F8721E2825; Fri, 13 Jul 2018 20:22:41 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Michael Tuexen In-Reply-To: Date: Fri, 13 Jul 2018 20:22:40 +0200 Cc: Spencer Dawkins at IETF , ncw@realvnc.com, RFC Editor , tsvwg@ietf.org, randall , IESG Content-Transfer-Encoding: quoted-printable Message-Id: <9470E471-8FDE-40A6-8D9A-567B426917BB@lurchi.franken.de> References: <20180710013143.95823B815B4@rfc-editor.org> <9EED3DC1-1788-4C69-86A5-A0524676F054@lurchi.franken.de> To: "Mirja Kuehlewind (IETF)" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [tsvwg] [Errata Verified] RFC4960 (5202) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 18:22:47 -0000 > On 13. Jul 2018, at 20:01, Mirja Kuehlewind (IETF) = wrote: >=20 > Spencer, I guess, you can also edit the errata and remove the second = part (or at minimum at a comment). Maybe double-check with the = secretary! >=20 > Or alternatively, you reject this errata which a comment that one part = is incorrect, and submit a new errata with only the correct part=E2=80=A6 Both would work for me... Best regards Michael >=20 > Mirja >=20 >=20 >=20 >> Am 13.07.2018 um 13:48 schrieb Michael Tuexen = : >>=20 >>> On 13. Jul 2018, at 19:39, Spencer Dawkins at IETF = wrote: >>>=20 >>> Hi, Michael,=20 >>>=20 >>> On Tue, Jul 10, 2018 at 5:11 AM Michael Tuexen = wrote: >>>> On 10. Jul 2018, at 03:31, RFC Errata System = wrote: >>>>=20 >>>> The following errata report has been verified for RFC4960, >>>> "Stream Control Transmission Protocol".=20 >>>>=20 >>>> -------------------------------------- >>>> You may review the report below and at: >>>> http://www.rfc-editor.org/errata/eid5202 >>>>=20 >>>> -------------------------------------- >>>> Status: Verified >>> Hi Spencer, >>>=20 >>> just to be clear: >>>=20 >>> This errata suggests two corrections: >>> (1) Ensure that the gap ack blocks are not overlapping. >>> (2) Ensure that the gap ack blocks are monotonic. >>>=20 >>> The result of the discussion (and therefore what has been included = in >>> = https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-06#section-3.4= 7) >>> is the following: >>> * The intention actually was to have the gap blocks isolated. So = accepting (1) >>> is OK. >>> * In some cases you blocks might not be monotonic. This is the same = as with >>> the handling of gap reports in TCP SACK. Therefore (2) is NOT OK. >>>=20 >>> Right.=20 >>>=20 >>> Not sure if this covered by "Verified". >>>=20 >>> So, you're thinking "Held for document update"?=20 >>>=20 >>> This case is slightly odd, because one correction is correct, so = that's why I marked the errata as "Verified", even though the other = correction is not. I'm happy to hear other opinions (I'm not an errata = system wizard, and haven't had an errata that fit this corner case = previously).=20 >>>=20 >>> If it seems more appropriate to people that I mark the errata as = "Held for document update", I'm happy to do that. >>>=20 >>> Just let me know.=20 >> Maybe "Held for document update" is more appropriate... I just want = to >> avoid that by stating "Verified" reader make the assumption that both >> suggestions/comments are correct. >>=20 >> Best regards >> Michael >>>=20 >>> Spencer >>>=20 >>>=20 >>> Best regards >>> Michael >>>> Type: Technical >>>>=20 >>>> Reported by: Nicholas Wilson >>>> Date Reported: 2017-12-13 >>>> Verified by: Spencer Dawkins (IESG) >>>>=20 >>>> Section: 3.3.4. >>>>=20 >>>> Original Text >>>> ------------- >>>> The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack >>>> Block acknowledges a subsequence of TSNs received following a break >>>> in the sequence of received TSNs. By definition, all TSNs >>>> acknowledged by Gap Ack Blocks are greater than the value of the >>>> Cumulative TSN Ack. >>>>=20 >>>> Corrected Text >>>> -------------- >>>> The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack >>>> Block acknowledges a subsequence of TSNs received following a break >>>> in the sequence of received TSNs. By definition, all TSNs >>>> acknowledged by Gap Ack Blocks are greater than the value of the >>>> Cumulative TSN Ack. >>>>=20 >>>> The sequence of Gap Ack Blocks MUST be an increasing sequence of >>>> ranges, non-intersecting, and with at least one TSN as a gap = between >>>> each Block and between the Cumulative TSN Ack and the first Block. >>>>=20 >>>> Notes >>>> ----- >>>> It seems clear that the Gap Ack sequence must be sent in its = "canonical" form (monotonic non-overlapping ranges) but I can't find = anywhere where this is actually stated. >>>>=20 >>>> It is implied (but not stated) by the following sentence on the = next page, which implies that there is no freedom of choice in how the = Gap Ack sequence is encoded: >>>>=20 >>>> "For example, assume that ... >>>> then the parameter part of the SACK MUST be constructed as = follows" >>>>=20 >>>> -------------------------------------- >>>> RFC4960 (draft-ietf-tsvwg-2960bis-05) >>>> -------------------------------------- >>>> Title : Stream Control Transmission Protocol >>>> Publication Date : September 2007 >>>> Author(s) : R. Stewart, Ed. >>>> Category : PROPOSED STANDARD >>>> Source : Transport Area Working Group >>>> Area : Transport >>>> Stream : IETF >>>> Verifying Party : IESG >>>>=20 >>>=20 >>=20 >=20 From nobody Fri Jul 13 13:05:48 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D69130E25 for ; Fri, 13 Jul 2018 13:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=Cz7CcYJe; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=FarjdETW 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 y8XcYvg1SpbD for ; Fri, 13 Jul 2018 13:05:42 -0700 (PDT) Received: from esa1.dell-outbound.iphmx.com (esa1.dell-outbound.iphmx.com [68.232.153.90]) (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 CEF5F128BAC for ; Fri, 13 Jul 2018 13:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1531511780; x=1563047780; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=w25Ae+c5TwyLEBqZpUYEr9sF8ysbFhQvb/6fwKno8So=; b=Cz7CcYJedtvzLV3hHQpUmO9fNHQuSOpXXfKo2I02sFr4wLpi4BTjhIsX caBPJvC832Pr1/ooTdZj7cW8Ya5TihZ+cjVIRq1eddZgqTpVWJXSeKsrA y6+Ed8YEiGFz0ta0iuAvVdM+gtyFtkxyFJy+dn8SJqj7/ny8VGN8ciPhk Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FEAQC1BElbmMqZ6ERcHAEBAQQBAQoBA?= =?us-ascii?q?YJTIiYEfg9/KAqDcZQ9ggx1lgMXJAsjC4Q+AheCOSE4FAECAQECAQECAQECEAE?= =?us-ascii?q?BAQEBCAsLBikjDII1JAEKBEsvCAMwAQEBAQEBAQEBAQEBAQEBAQEBFwINNgESA?= =?us-ascii?q?QEYAQEBAQIBIwoTHw0KAwEECQICAQgRAQMBAQsWBwMCAgIZFxQDBggCBAENBQi?= =?us-ascii?q?CTUsBgRtcCAEOqR2BLoJ4hz8DBQWGOYEtgReBWD6BEYJcBy6DGQEBAgEBgV4VF?= =?us-ascii?q?gmCSzGCJIVbggwlR5ELAwQCAoYIhVuFBYZ+hSSKOYc0AgQCBAUCFIFYgV4OCHC?= =?us-ascii?q?DOQmCHA4JegEBAYJIhRSFPm+LKoEaAQE?= X-IPAS-Result: =?us-ascii?q?A2FEAQC1BElbmMqZ6ERcHAEBAQQBAQoBAYJTIiYEfg9/KAq?= =?us-ascii?q?DcZQ9ggx1lgMXJAsjC4Q+AheCOSE4FAECAQECAQECAQECEAEBAQEBCAsLBikjD?= =?us-ascii?q?II1JAEKBEsvCAMwAQEBAQEBAQEBAQEBAQEBAQEBFwINNgESAQEYAQEBAQIBIwo?= =?us-ascii?q?THw0KAwEECQICAQgRAQMBAQsWBwMCAgIZFxQDBggCBAENBQiCTUsBgRtcCAEOq?= =?us-ascii?q?R2BLoJ4hz8DBQWGOYEtgReBWD6BEYJcBy6DGQEBAgEBgV4VFgmCSzGCJIVbggw?= =?us-ascii?q?lR5ELAwQCAoYIhVuFBYZ+hSSKOYc0AgQCBAUCFIFYgV4OCHCDOQmCHA4JegEBA?= =?us-ascii?q?YJIhRSFPm+LKoEaAQE?= Received: from esa2.dell-outbound2.iphmx.com ([68.232.153.202]) by esa1.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jul 2018 14:56:18 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa2.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jul 2018 01:59:42 +0600 Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w6DK5aZv019934 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 13 Jul 2018 16:05:38 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com w6DK5aZv019934 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1531512339; bh=1fT+kMBUQzvEyPMHcpP4CDWZZNU=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=FarjdETWNT3/L+NPe5XaCPe7YIORc05AYUUCqDdan+reHR7vx3cW9qjrmBZGjaxXm ZBDmhjcv0uRVaiUfRzGme1uR8yftDHOjg/J797gmjqj9MBz8YDDWnYyK39mYahzXy3 jMr1gX45wVnfsvXZ6yVhcx0Gx6u3EYiDQDQ8nHBI= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com w6DK5aZv019934 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd04.lss.emc.com (RSA Interceptor); Fri, 13 Jul 2018 16:05:23 -0400 Received: from MXHUB305.corp.emc.com (MXHUB305.corp.emc.com [10.146.3.31]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w6DK5Li6011067 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Fri, 13 Jul 2018 16:05:22 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB305.corp.emc.com ([10.146.3.31]) with mapi id 14.03.0399.000; Fri, 13 Jul 2018 16:05:21 -0400 To: Spencer Dawkins at IETF , Magnus Westerlund CC: "tsvwg@ietf.org" Thread-Topic: [tsvwg] Experience and Status of ECN in QUIC work Thread-Index: AQHUFF2BykvnESWqZki4EZ+C86Hr2qSNt2kA///ngOA= Date: Fri, 13 Jul 2018 20:05:21 +0000 Message-ID: References: <6f8ee7ac-9318-b4ab-626c-a3a36acba042@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.21.34] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D24327794936301D3594MX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tsvwg] Experience and Status of ECN in QUIC work X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 20:05:46 -0000 --_000_CE03DB3D7B45C245BCA0D24327794936301D3594MX307CL04corpem_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V0cgY2hhaXIgaGF0IHN0aWxsIG9mZiDigKYNCg0KPiBJJ20gdHJ5aW5nIHRvIHVuZGVyc3RhbmQg aG93IG11Y2ggYSByZWNlaXZlciBjYW4gYmVuZWZpdCBieSBjaGVhdGluZy4gSVNUTSB0aGF0IGlm IGEgcmVjZWl2ZXIgc2VlcyBFQ04tQ0UgbWFya2luZ3MgYW5kIGRvZXNuJ3QgcmVmbGVjdCB0aGF0 IGJhY2sgdG8gdGhlIHNlbmRlciwgb25lIG9mIHR3byB0aGluZ3Mgd2lsbCBoYXBwZW4uDQoNCiAg KiAgIEVpdGhlciB0aGUgc2VuZGVyIHJlYWxseSBkb2Vzbid0IG5lZWQgdG8gc2xvdyBkb3duIChz byBubyBmdXJ0aGVyIEVDTi1DRSBtYXJrcyBhcnJpdmUgYXQgdGhlIHJlY2VpdmVyKSwgb3INCiAg KiAgIFRoZSBzZW5kZXIgcmVhbGx5IGRvZXMgbmVlZCB0byBzbG93IGRvd24gKHNvIHRoZSByZWNl aXZlciBrZWVwcyBjaGVhdGluZyB1bnRpbCBhY3R1YWwgcGFja2V0cyBnZXQgbG9zdCwgd2hpY2gg dGhlIHJlY2VpdmVyIHJlYWxseSBjYW4ndCBkaXNndWlzZSksIGFuZCBpcyBmaW5hbGx5IHNsb3dp bmcgZG93biBiYXNlZCBvbiBwYWNrZXQgbG9zc2VzDQpJdCBoZWxwcyB0byB0aGluayBhYm91dCBi ZWhhdmlvciBhdCB0aGUgYm90dGxlbmVjayBxdWV1ZSB0aGF0IGlzIGdlbmVyYXRpbmcgdGhlIEVD Ti1DRSBtYXJrcy4gICBJZiBhbGwgcmVjZWl2ZXJzIGNoZWF0IGFuZCBpZ25vcmUgdGhlIG1hcmtz LCBub2JvZHkgd2lucyBiZWNhdXNlIHRoZSBib3R0bGVuZWNrIGNvbmRpdGlvbiBwZXJzaXN0cy4g ICBUaGUgY2hlYXRpbmcgcmVjZWl2ZXIgd2lucyBpZiBvdGhlciByZWNlaXZlcnMgZG9u4oCZdCBj aGVhdCwgYW5kIHRoZSByZXN1bHRpbmcgYmFja29mZiBvZiBvdGhlciBmbG93cyBjYXVzZXMgdGhl IGJvdHRsZW5lY2sgcXVldWUgdG8gbm8gbG9uZ2VyIGJlIGEgYm90dGxlbmVjaywgaS5lLiwgaXQg c3RvcHMgZ2VuZXJhdGluZyBFQ04tQ0UgbWFya3MuICAgQXQgdGhhdCBwb2ludCB0aGUgY2hlYXRp bmcgcmVjZWl2ZXLigJlzIGZsb3cgaGFzIG1vcmUgc2hhcmUgb2YgdGhlIGZvcm1lcmx5IGJvdHRs ZW5lY2tlZCBxdWV1ZeKAmXMgdGhyb3VnaHB1dCB0aGFuIHRoYXQgZmxvdyBzaG91bGQuDQoNClRo YW5rcywgLS1EYXZpZA0KDQpGcm9tOiB0c3Z3ZyBbbWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBTcGVuY2VyIERhd2tpbnMgYXQgSUVURg0KU2VudDogRnJpZGF5LCBK dWx5IDEzLCAyMDE4IDE6MjYgUE0NClRvOiBNYWdudXMgV2VzdGVybHVuZA0KQ2M6IHRzdndnQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW3RzdndnXSBFeHBlcmllbmNlIGFuZCBTdGF0dXMgb2YgRUNO IGluIFFVSUMgd29yaw0KDQpSZXNwb25zaWJsZSBBRCBoYXQgaXMgZXZlbiBtb3JlIG9mZiB0aGFu IERhdmlkJ3MgV0cgY2hhaXIgaGF0IGluIGhpcyByZXNwb25zZSAuLi4NCg0KT24gVGh1LCBKdWwg NSwgMjAxOCBhdCA3OjQxIEFNIE1hZ251cyBXZXN0ZXJsdW5kIDxtYWdudXMud2VzdGVybHVuZEBl cmljc3Nvbi5jb208bWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4+IHdyb3Rl Og0KDQpUU1ZXRywNCg0KRUNOIHN1cHBvcnQgd2FzIGFkZGVkIHRvIFFVSUMgaW4gdGhlIGxhdGVz dCBkcmFmdCB2ZXJzaW9ucyAoLTEzKS4gVGhlIHJlbGV2YW50IGRvY3VtZW50cyB0aGF0IGluY2x1 ZGUgRUNOIHJlbGF0ZWQgdGV4dCBhcmU6DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtcXVpYy10cmFuc3BvcnQvDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLXF1aWMtcmVjb3ZlcnkvDQoNClRoZSBpbmNsdXNpb24gb2YgRUNO IGluIFFVSUMgY2FuIGJlIHN1bW1hcml6ZWQgYXMuIEVhY2ggc2VuZGVyIHBlcmZvcm1zIGluaXRp YWwgdmVyaWZpY2F0aW9uIHdoZW4gdGhlIGNvbm5lY3Rpb24gaXMgZXN0YWJsaXNoZWQgb3IgbWln cmF0ZWQgYnkgc2V0dGluZyBFQ1Qgb24gdGhlIHBhY2tldHMgaXQgc2VuZC4gVGhlIHJlY2VpdmVy IHdpbGwgcmVwb3J0IGlmIGl0IHNlZXMgRUNOIG1hcmtzLCBpLmUuIGFueSB2YWx1ZSBvdGhlciB0 aGFuIG5vdC1FQ1QsIHVzaW5nIGEgbmV3IGFja25vd2xlZGdlbWVudCBmcmFtZSB0eXBlIChBQ0tf RUNOKSB0aGF0IGluY2x1ZGVzIGNvdW50ZXJzIG9mIGhvdyBtYW55IHBhY2tldHMgd2l0aCB0aGUg dmFyaW91cyBtYXJraW5ncyB0aGUgcmVjZWl2ZXIgaGF2ZSBzZWVuIHNpbmNlIGNvbm5lY3Rpb24g ZXN0YWJsaXNobWVudC4gSWYgdGhlIHJlY2VpdmVyIGdldHMgbm90LUVDVCBvciBjYW4ndCByZWFk IEVDTiBtYXJrcyB0aGVuIGl0IHVzZXMgdGhlIEFDSyBmcmFtZSB0byByZXBvcnQgdGhlc2UgcGFj a2V0cyBzbyB0aGF0IHRoZSBzZW5kZXIgY2FuIGxlYXJuIG9mIHRoZSBsYWNrIG9mIEVDVCBjYXBh YmlsaXR5IGFuZCB0dXJuIGl0cyBtYXJraW5nIG9mZi4gTWFya2luZyBjb25zaXN0ZW5jeSBhcmUg Y29udGludW91c2x5IHZlcmlmaWVkLiBFQ04gYmxhY2sgaG9sZSBtaXRpZ2F0aW9uIGlzIGRpc2N1 c3NlZCBhbmQgYSBwb3NzaWJsZSBtZWNoYW5pc20gaXMgdGhhdCBhbnkgUlRPIHdpbGwgcmVzdWx0 IGluIHJldHJhbnNtaXNzaW9uIHdpdGhvdXQgRUNUIG1hcmtzLg0KDQpUaGUgaW5jbHVzaW9uIG9m IEVDTiBpbiBRVUlDIGhhcyBzbyBmYXIgYmVlbiBmYWlybHkgd2VsbCBkaXNjdXNzZWQuIEluaXRp YWxseSBieSB0aGUgZGVzaWduIHRlYW0uIFRoZW4gYXQgdGhlIFFVSUMgaW50ZXJpbSBtZWV0aW5n IGluIEp1bmUsIGZvbGxvd2VkIGJ5IGEgbG90IG9mIGRpc2N1c3Npb24gb2YgdGhlIGFjdHVhbCB0 ZXh0IHByb3Bvc2FsIG9uIGdpdGh1Yi4gVGhhbmtzIHRvIGV2ZXJ5b25lIHRoYXQgZW5nYWdlZC4g QmFzZWQgb24gdGhlc2UgZGlzY3Vzc2lvbnMgdGhlcmUgYXJlIHNvbWUgcXVlc3Rpb25zIGFuZCBl eHBlcmllbmNlIHRoYXQgSSBoYXZlIG5vdGljZWQgdGhhdCBpcyB3b3J0aCBzcHJlYWRpbmcgYW5k IGRpc2N1c3NpbmcuIFRoaXMgaXMgYWxzbyB0aGUgdG9waWNzIGNvbWluZyBpbiB0aGUgVFNWV0cg c2Vzc2lvbiBmb3IgbXkgYWdlbmRhIGl0ZW0uDQpJJ2QgbGlrZSB0byB0aGFuayB0aGUgUVVJQy1F Q04gZGVzaWduIHRlYW0gZm9yIHN1cmZhY2luZyB0aGlzIGluIFRTVldHIGF0IHRoaXMgdGltZS4N Cg0KQWxzbyBJIGRvbid0IGJlbGlldmUgdGhlIGxhc3Qgd29yZCBpcyBzYWlkIGFib3V0IGRldGFp bHMgb2YgaG93IEVDTiBpbiBRVUlDIGlzIHJlYWxpemVkLiBUaGVyZSBhcmUgY3VycmVudGx5IHRo cmVlIGRpZmZlcmVudCBnaXRodWIgaXNzdWVzIHJlbGF0ZWQgdG8gRUNOOg0KDQotIEltcHJvdmUg QUNLX0VDTiBmcmFtZSBlbmNvZGluZyAoZS5nLiwgdXNlIGJpdC12ZWN0b3IpPGh0dHBzOi8vZ2l0 aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvaXNzdWVzLzE0Mzk+IChodHRwczovL2dpdGh1Yi5j b20vcXVpY3dnL2Jhc2UtZHJhZnRzL2lzc3Vlcy8xNDM5KQ0KLSBGcmFnaWxpdHkgaW4gRUNOIGNv dW50ZXJzIHdpdGggbG9zdCBhY2tzPGh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFm dHMvaXNzdWVzLzE0ODE+IChodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL2lz c3Vlcy8xNDgxKQ0KLSBEZXRlY3QgYWR2ZXJzYXJpYWwgRUNOIHJlcG9ydGluZzxodHRwczovL2dp dGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL2lzc3Vlcy8xNDI2PiAoaHR0cHM6Ly9naXRodWIu Y29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9pc3N1ZXMvMTQyNikNCg0KU28gdGhlIHRoaW5ncyBJIHdh bnQgdG8gYnJpbmcgdG8gYXR0ZW50aW9uIGFyZToNCg0KDQoNCkEuIFN1cHByZXNzaW9uIG9mIEVD TiB2YWx1ZXMgaW4gcGFja2V0IGR1cGxpY2F0ZXMNCg0KSW4gUVVJQyB0aGUgZHJhZnRzIGN1cnJl bnRseSBzYXlzIHRoYXQgYSByZWNlaXZlciBzaG91bGQgc3VwcHJlc3MgdGhlIEVDTiB2YWx1ZXMg cmVjZWl2ZWQgaW4gYW55IHBhY2tldCBkdXBsaWNhdGVzLiBUaGUgbWFpbiByZWFzb24gZm9yIHRo YXQgaXMgdG8gbWl0aWdhdGUgYSBwb3RlbnRpYWwgYWN0aXZlIGF0dGFjayBieSBhIG9mZi1wYXRo IGF0dGFja2VyIHRoYXQgaGFzIHNvbWUgY2FwYWJpbGl0eSB0byByZWNlaXZlIGEgY29weSBvZiB0 aGUgcGFja2V0cyBvZiB0aGUgdGFyZ2V0IGZsb3cuIFdlIGNhbGwgaXQgYW4gb24tdGhlLXNpZGUg YXR0YWNrLiBCeSB0YWtpbmcgYSBjb3B5IG9mIGEgbGVnaXQgcGFja2V0LCBhbmQgY2hhbmdpbmcg dGhlIEVDTiBmaWVsZCB0byBFQ04tQ0UgYW5kIHRoZW4gZm9yd2FyZCB0aGUgbW9kaWZpZWQgY29w eSB0byB0aGUgaW50ZW5kZWQgcmVjZWl2ZXIgb25lIGNhbiBwZXJmb3JtIGEgZGVuaWFsIG9mIHNl cnZpY2UgYXR0YWNrIGJ5IGRyaXZpbmcgZG93biB0aGUgY29uZ2VzdGlvbiB3aW5kb3cuIFRvIG1p dGlnYXRlIHRoaXMsIHRoZSByZWNvbW1lbmRhdGlvbiBpcyB0byBjYXJlIGFib3V0IG9ubHkgdGhl IGZpcnN0IGFycml2ZWQgcGFja2V0LiBUaGlzIGZvcmNlcyBhbiBvbi10aGUtc2lkZSBhdHRhY2tl ciB0byBiZSBhYmxlIHRvIHJhY2UgdGhlaXIgYXR0YWNrIHBhY2tldHMgd2l0aCB0aGUgb3JpZ2lu YWwgcGFja2V0Lg0KDQpUaGUgZG93bnNpZGUgb2YgdGhpcyBpcyBvZiBjb3Vyc2UgdGhhdCBhbiBh Y3R1YWwgbmV0d29yayBkdXBsaWNhdGlvbiB3aGVyZSBub25lLWZpcnN0IHBhY2tldHMgZ2V0cyBt YXJrZWQgYXMgRUNOLUNFIGFmdGVyIHRoZSBkdXBsaWNhdGlvbiB3ZSBpZ25vcmUgdGhlIGNvbmdl c3Rpb24gc2lnbmFsLiBNeSBwZXJzb25hbCBzdGFuZHBvaW50IGlzIHRoYXQgdGhpcyBpcyBva2F5 LiBJZiBub3QgdGhlIGZpcnN0IHBhY2tldCB3YXMgbWFya2VkIHRoZW4gY29uZ2VzdGlvbiBtYXkg bm90IGJlIHNvIGJhZCB0aGF0IGl0IGlzIGEgcHJvYmxlbSBpZiB0aGUgZHVwbGljYXRpb24gZG9u J3QgaGFwcGVucy4gU2Vjb25kbHksIGlmIGl0IGlzIGFueSBwZXJzaXN0ZW50IGNvbmdlc3Rpb24g dGhlbiB0aGlzIGZsb3cgd2lsbCBiZSBtYXJrZWQgaW4gYSBsYXRlciBwYWNrZXQuIFRoZXJlIHdh cyBzb21lIGRpc2FncmVlbWVudCBvbiB0aGlzIHNvIEkgdGhpbmsgaXQgaXMgd29ydGggbW9yZSBk aXNjdXNzaW9uLg0KDQoNCg0KQi4gV2lsbCBFQ1QoMCkgYW5kIEVDVCgxKSBiZSBtaXhlZCBpbiBv bmUgcGFja2V0IGZsb3c/DQoNCkluIHRoZSBkaXNjdXNzaW9ucyBhcm91bmQgb3B0aW1pemluZyBo b3cgdGhlIEVDTiBpbmZvcm1hdGlvbiByZXBvcnRlZCBmcm9tIHJlY2VpdmVyIHRvIHNlbmRlciB0 aGlzIHF1ZXN0aW9uIGFyb3NlLiBJZiBvbmUgY2FuIG1ha2UgYXNzdW1wdGlvbiB0aGF0IHdpdGhp biBhIGNvbm5lY3Rpb24gb25lIHdpbGwgdXNlIG9ubHkgb25lIG9mIHRoZSBFQ1QgY29kZXBvaW50 cyB0aGVuIHdlIGNhbiBvcHRpbWl6ZSB0aGUgcmVwb3J0aW5nIGJhc2VkIG9uIHRoYXQgYXNzdW1w dGlvbi4gU28gaG93IHNhZmUgaXMgdGhpcyBhc3N1bXB0aW9uPyBBbmQgaW4gdGhpcyBjYXNlLCB3 aGF0IGlzIHRoZSBpbXBvcnRhbmNlIG9mIGJlaW5nIGFibGUgdG8gZGV0ZWN0IEVDVCBjb2RlcG9p bnQgcmVtYXJraW5nLCBpLmUuIGNoYW5naW5nIGJldHdlZW4gMCBhbmQgMSBpbiBlaXRoZXIgZGly ZWN0aW9uPw0KDQoNCg0KQy4gRGV0ZWN0aW5nIENoZWF0aW5nIFJlY2VpdmVycw0KDQpBcyB0aGVy ZSBhcmUgc29tZSByaXNrcyBpbiBjZXJ0YWluIGRlcGxveW1lbnQgc2l0dWF0aW9ucyB0aGF0IHRo ZSByZWNlaXZlciB3b3VsZCBoYXZlIGFuIGluY2VudGl2ZSB0byBsaWUgYWJvdXQgaWYgYW4gRUNO LUNFIG1hcmsgd2FzIHJlY2VpdmVkIG9yIG5vdCB0byBnYWluIHRocm91Z2hwdXQuIEEgc2VuZGVy IGNvdWxkIGRldGVjdCB0aGlzIGNhc2UgYnkgc2VuZGluZyBwYWNrZXRzIG1hcmtlZCBhcyBFQ04t Q0UgdG8gdmVyaWZ5IHRoYXQgcmVjZWl2ZXIgcmVwb3J0cyB0aGVzZSBwYWNrZXRzIGFyZSBiZWlu ZyBtYXJrZWQuIEFzIHRoZSBzZW5kZXIgd2lsbCBpZ25vcmUgdGhlIEVDTi1DRSBtYXJrcyBpdCBz ZWxmIGdlbmVyYXRlZCB0aGVyZSBpcyBhIHJpc2sgdGhhdCB0aGVzZSBtYXJrcyBoaWRlIHJlYWwg Q0UgbWFya3MuIFRodXMsIHRoZSBnZW5lcmFsIHF1ZXN0aW9uIGlzIGhvdyBvZnRlbiwgYXQgbW9z dCwgc2hvdWxkIGEgc2VuZGVyIG1hcmsgd2l0aCBFQ04tQ0U/DQpJbiBteSBtaW5kLCBBIGFuZCBD IGFyZSByZWxhdGVkIC0gaG93IHBlcmZlY3RseSBkb2VzIGEgc2VuZGVyIG5lZWQgdG8gcmVhY3Qg cGVyZmVjdGx5IHRvIEVDTi1DRSBtYXJraW5ncz8NCg0KSW4gQSwgSSB0aGluayB0aGF0IG1heSBi ZSB3aGVyZSBNYWdudXMgaXMgY29taW5nIGZyb20gLSB0aGUgc2VuZGVyIGlzIGFscmVhZHkgcmVh Y3RpbmcgdG8gRUNOLUNFLCBhbmQgaWYgdGhlIHNlbmRlciBoYXNuJ3QgcmVzcG9uZGVkIHN1ZmZp Y2llbnRseSwgdGhlIGZsb3cgd2lsbCBjb250aW51ZSB0byBiZSBtYXJrZWQgaW4gbGF0ZXIgcGFj a2V0cywgYW5kIHRoZSBzZW5kZXIgd2lsbCBoYXZlIGFuIG9wcG9ydHVuaXR5IHRvIHJlYWN0IGFn YWluLCB1bnRpbCBpdCBoYXMgcmVhY3RlZCBzdWZmaWNpZW50bHkuIElzIHRoYXQgdGhlIHF1ZXN0 aW9uPw0KDQpJbiBDLCBJJ20gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgaG93IG11Y2ggYSByZWNlaXZl ciBjYW4gYmVuZWZpdCBieSBjaGVhdGluZy4gSVNUTSB0aGF0IGlmIGEgcmVjZWl2ZXIgc2VlcyBF Q04tQ0UgbWFya2luZ3MgYW5kIGRvZXNuJ3QgcmVmbGVjdCB0aGF0IGJhY2sgdG8gdGhlIHNlbmRl ciwgb25lIG9mIHR3byB0aGluZ3Mgd2lsbCBoYXBwZW4uDQoNCiAgKiAgIEVpdGhlciB0aGUgc2Vu ZGVyIHJlYWxseSBkb2Vzbid0IG5lZWQgdG8gc2xvdyBkb3duIChzbyBubyBmdXJ0aGVyIEVDTi1D RSBtYXJrcyBhcnJpdmUgYXQgdGhlIHJlY2VpdmVyKSwgb3INCiAgKiAgIFRoZSBzZW5kZXIgcmVh bGx5IGRvZXMgbmVlZCB0byBzbG93IGRvd24gKHNvIHRoZSByZWNlaXZlciBrZWVwcyBjaGVhdGlu ZyB1bnRpbCBhY3R1YWwgcGFja2V0cyBnZXQgbG9zdCwgd2hpY2ggdGhlIHJlY2VpdmVyIHJlYWxs eSBjYW4ndCBkaXNndWlzZSksIGFuZCBpcyBmaW5hbGx5IHNsb3dpbmcgZG93biBiYXNlZCBvbiBw YWNrZXQgbG9zc2VzDQpJIHVuZGVyc3RhbmQgdGhhdCBDb0RlbCBhbmQgUElFIGFyZSBFeHBlcmlt ZW50YWwsIGFuZCBJIHVuZGVyc3RhbmQgdGhhdCBMNFMgaXMgc3RpbGwgaW4gVFNWLCBidXQgZG9l cyBhIHJlY2VpdmVyIGNoZWF0aW5nIG5vdywgYW5kIGdvaW5nIGZvcndhcmQsIG1ha2UgYXMgbXVj aCBzZW5zZSBhcyBpdCBkaWQgd2hlbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzE2 OCNzZWN0aW9uLTE4KCopIHdhcyBwdWJsaXNoZWQgaW4gMjAwMSwgd2l0aCBjb25nZXN0aW9uIGNv bnRyb2wgbWVjaGFuaXNtcyBhdmFpbGFibGUgYXQgdGhhdCB0aW1lPyBJdCBzZWVtcyBsaWtlIHRo YXQncyBqdXN0IGJlZ2dpbmcgZm9yIGJ1ZmZlcmJsb2F0LCBmb2xsb3dlZCBieSBsb3NzZXMsIGZv bGxvd2VkIGJ5IHBvb3IgcGVyZm9ybWFuY2UgZHVyaW5nIHJlY292ZXJ5Lg0KDQpDdXJpb3VzbHks DQoNClNwZW5jZXIsIHdpdGggbm8gaGF0cw0KDQooKikgSSB1bmRlcnN0YW5kIHRoYXQgaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzMxNjgjc2VjdGlvbi0xOCBpcyBkaXNjdXNzaW5nIG1p c2JlaGF2aW5nIHJvdXRlcnMsIG5vdCBtaXNiZWhhdmluZyByZWNlaXZlcnMsIGJ1dCB0aGF0IHdh cyBhIGhhbmR5IHJlZmVyZW5jZSBmb3IgIndoYXQgaGFwcGVucyBpZiB0aGUgc2VuZGVyIGNhbid0 IHRydXN0IEVDTiBzaWduYWxzIiAuLi4NCg0KRC4gRGVsYXllZCBBY2tub3dsZWRnZW1lbnQgYW5k IEVDTg0KDQpXZSBhbHNvIGhhdmUgYW4gaW50ZXJlc3RpbmcgZGlzY3Vzc2lvbiBhcm91bmQgRUNO LCBEZWxheWVkIEFja25vd2xlZGdlbWVudCBhbmQgdGhlIGludGVyYWN0aW9uIHdpdGggcmVjb3Zl cnkgcGVyaW9kLiBRVUlDIHN1cHBvcnRzIGRlbGF5ZWQgYWNrbm93bGVkZ2VtZW50LiBTbyBmYXIg dGhlcmUgYXJlIHF1aXRlIGEgbG90IG9mIGltcGxlbWVudGVyIGZyZWVkb20gb2YgaG93IHRvIHVz ZSB0aGlzLiBXaGF0IGlzIGN1cnJlbnRseSBzcGVjaWZpZWQgaXMgdGhhdCB3aGVuIHJlY2Vpdmlu ZyBhbiBFQ04tQ0UgbWFyayB0aGUgcmVjZWl2ZXIgc2VuZHMgYW4gaW1tZWRpYXRlIEFDSywgc28g Z2V0IHJhcGlkIHJlc3BvbnNlIHRvIHRoZSBjb25nZXN0aW9uIHNpZ25hbC4gV2hlbiB0aGUgQUNL X0VDTiByZWFjaGVzIHRoZSBzZW5kZXIgaXQgd2lsbCBnbyBpbnRvIFJlY292ZXJ5IHVudGlsIGEg cGFja2V0IHNlbnQgYWZ0ZXIgZW50ZXJpbmcgcmVjb3ZlcnkgaGFzIGJlZW4gYWNrbm93bGVkZ2Vk LiBEdXJpbmcgcmVjb3ZlcnkgYXMgdGhlIGNvbmdlc3Rpb24gd2luZG93IGFscmVhZHkgaXMgcmVk dWNlZCBhbmQgZnJvemVuIHRoZSByZWNlcHRpb24gb2YgYWRkaXRpb25hbCBFQ04tQ0UgbWFya3Mg KGF0IGxlYXN0IGZvciB0aGUgY3VycmVudCBjb25nZXN0aW9uIGNvbnRyb2wgbWVjaGFuaXNtKSBp cyBub3QgdGhhdCBpbXBvcnRhbnQuIFdoYXQgaXMgaW1wb3J0YW50IGlzIGlmIGFueSBwYWNrZXRz IGFyZSBFQ04tQ0UgbWFya2VkIHdoZW4gZXhpdGluZyByZWNvdmVyeS4gTWFya3Mgb24gcGFja2V0 cyBzZW50IGFmdGVyIHJlY292ZXJ5IHNob3VsZCByZXN1bHQgaW4gYSBuZXcgY29uZ2VzdGlvbiBl dmVudCBhbmQgbmV3IHJlY292ZXJ5IHBlcmlvZC4gVG8gcmVzb2x2ZSB0aGlzIHRoZSBjdXJyZW50 IHJlcXVpcmVtZW50IGlzIHRvIGltbWVkaWF0ZWx5IGFja25vd2xlZGdlIGVhY2ggRUNOLUNFIG1h cmtzLiBUaGlzIHdpbGwgcmVzdWx0IGluIHNvbWUgYWRkaXRpb25hbCBhY2tub3dsZWRnZW1lbnRz Lg0KDQpUaGVyZSBoYXMgYmVlbiBzb21lIGRpc2N1c3Npb24gaWYgb25lIHdhbnQgdG8gb3B0aW1p emUgdGhpcyBjYXNlIG9yIGlmIGl0IGlzIG5vdCB3b3J0aCBpdC4gT25lIGRpcmVjdGlvbiB3YXMg dG8gZW5zdXJlIHRoYXQgZXZlbiB3aXRoIGRlbGF5ZWQgQUNLcyBvbmUgZ2V0IGZyZXF1ZW50IGVu b3VnaCBhY2tub3dsZWRnZW1lbnRzLiBUaGlzIHJlc3VsdGVkIGluIGRpc2N1c3Npb24gaW4gdGhl IGRpcmVjdGlvbiBvZiBlbnN1cmluZyB0aGF0IHRoZSBsb25nZXN0IGRlbGF5IGJlZm9yZSBhY2tu b3dsZWRnaW5nIGlzIGNhcGVkIGF0IGEgcXVhcnRlciBvZiB0aGUgUlRULiBUaGF0IHdheSBvbmUg YWNoaWV2ZSBubyB3b3JzZSB0aGFuIHF1YXJ0ZXIgUlRUIHJlc29sdXRpb24gb24gdGhlIEVDTi1D RSBtYXJrcy4gQW5vdGhlciBwb3RlbnRpYWwgZGlyZWN0aW9uIGlzIGV4cGxpY2l0IGluZGljYXRp b24gb2Ygd2hpY2ggcGFja2V0IG51bWJlcnMgdGhhdCB3b3VsZCByZXNvbHZlIHRoaXMgdW5jZXJ0 YWludHkuIFRoZW4gYWxzbyBleGlzdHMgdGhlIHF1ZXN0aW9uIGlmIHRoZSByZWNlaXZlciBuZWVk cyBhbnkgaW5kaWNhdGlvbiBvZiByZWNvdmVyeSBwZXJpb2RzIHRvIG9wdGltaXplIHRoZSBhY2tu b3dsZWRnZW1lbnRzLg0KDQpFLiBVdGlsaXR5IG9mIGRldGFpbGVkIENFIGluZm9ybWF0aW9uDQoN CkFzIHRoZXJlIGhhcyBiZWVuIGRpc2N1c3Npb24gYWJvdXQgZXhwbGljaXRseSBpbmRpY2F0ZSB3 aGljaCBwYWNrZXQgbnVtYmVycyB3YXMgbWFya2VkIGFzIENFLCBpdCBpcyBhbHNvIGdvb2QgdG8g dW5kZXJzdGFuZCBpZiB0aGVyZSBhcmUgYW55IHNpZ25pZmljYW50IHV0aWxpdHkgb2YgaGF2aW5n IHRoaXMgaW5mb3JtYXRpb24gZm9yIHRoZSBzZW5kZXIgY29tcGFyZWQgdG8gd2hhdCB0aGUgY291 bnRlcnMgcHJvdmlkZS4gSSBhc3N1bWUgdGhpcyBnb2VzIGludG8gdGhlIHBvdGVudGlhbCBmb3Ig Y29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbSBldm9sdXRpb24uIEJ1dCwgZG9lcyBpdCBtYXR0 ZXIgZm9yIGV4YW1wbGUgZm9yIEw0Uz8NCg0KDQoNCkNoZWVycw0KDQoNCg0KTWFnbnVzIFdlc3Rl cmx1bmQNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KTmV0d29yayBBcmNoaXRlY3R1cmUgJiBQcm90 b2NvbHMsIEVyaWNzc29uIFJlc2VhcmNoDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KRXJpY3Nzb24gQUIg ICAgICAgICAgICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQoNClRvcnNoYW1uc2dhdGFu IDIzICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0KDQpTRS0xNjQgODAgU3RvY2to b2xtLCBTd2VkZW4gfCBtYWlsdG86IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbTxtYWls dG86bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo= --_000_CE03DB3D7B45C245BCA0D24327794936301D3594MX307CL04corpem_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFt ZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3Qg bDANCgl7bXNvLWxpc3QtaWQ6MTE4NjI4NDgyNDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEx NTM0MzIwMzY7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoz LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30N CnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XRyBjaGFpciBoYXQgc3RpbGwgb2ZmIOKApjwvc3Bhbj48 bzpwPjwvbzpwPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgSSdtIHRyeWluZyB0byB1bmRlcnN0YW5k IGhvdyBtdWNoIGEgcmVjZWl2ZXIgY2FuIGJlbmVmaXQgYnkgY2hlYXRpbmcuIElTVE0gdGhhdCBp ZiBhIHJlY2VpdmVyIHNlZXMgRUNOLUNFIG1hcmtpbmdzIGFuZCBkb2Vzbid0IHJlZmxlY3QgdGhh dCBiYWNrIHRvIHRoZSBzZW5kZXIsIG9uZSBvZiB0d28gdGhpbmdzIHdpbGwgaGFwcGVuLjxvOnA+ PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28t bGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpFaXRoZXIgdGhlIHNlbmRlciByZWFsbHkgZG9lc24ndCBu ZWVkIHRvIHNsb3cgZG93biAoc28gbm8gZnVydGhlciBFQ04tQ0UgbWFya3MgYXJyaXZlIGF0IHRo ZSByZWNlaXZlciksIG9yJm5ic3A7PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KVGhlIHNlbmRlciByZWFsbHkgZG9lcyBuZWVk IHRvIHNsb3cgZG93biAoc28gdGhlIHJlY2VpdmVyIGtlZXBzIGNoZWF0aW5nIHVudGlsIGFjdHVh bCBwYWNrZXRzIGdldCBsb3N0LCB3aGljaCB0aGUgcmVjZWl2ZXIgcmVhbGx5IGNhbid0IGRpc2d1 aXNlKSwgYW5kIGlzIGZpbmFsbHkgc2xvd2luZyBkb3duIGJhc2VkIG9uIHBhY2tldCBsb3NzZXM8 bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5JdCBoZWxwcyB0byB0aGluayBhYm91dCBiZWhhdmlvciBhdCB0aGUg Ym90dGxlbmVjayBxdWV1ZSB0aGF0IGlzIGdlbmVyYXRpbmcgdGhlIEVDTi1DRSBtYXJrcy4mbmJz cDsmbmJzcDsgSWYgYWxsIHJlY2VpdmVycyBjaGVhdCBhbmQgaWdub3JlIHRoZSBtYXJrcywgbm9i b2R5IHdpbnMgYmVjYXVzZQ0KIHRoZSBib3R0bGVuZWNrIGNvbmRpdGlvbiBwZXJzaXN0cy4mbmJz cDsmbmJzcDsgVGhlIGNoZWF0aW5nIHJlY2VpdmVyIHdpbnMgaWYgb3RoZXIgcmVjZWl2ZXJzIGRv buKAmXQgY2hlYXQsIGFuZCB0aGUgcmVzdWx0aW5nIGJhY2tvZmYgb2Ygb3RoZXIgZmxvd3MgY2F1 c2VzIHRoZSBib3R0bGVuZWNrIHF1ZXVlIHRvIG5vIGxvbmdlciBiZSBhIGJvdHRsZW5lY2ssIGku ZS4sIGl0IHN0b3BzIGdlbmVyYXRpbmcgRUNOLUNFIG1hcmtzLiZuYnNwOyZuYnNwOyBBdCB0aGF0 IHBvaW50IHRoZSBjaGVhdGluZw0KIHJlY2VpdmVy4oCZcyBmbG93IGhhcyBtb3JlIHNoYXJlIG9m IHRoZSBmb3JtZXJseSBib3R0bGVuZWNrZWQgcXVldWXigJlzIHRocm91Z2hwdXQgdGhhbiB0aGF0 IGZsb3cgc2hvdWxkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ VGhhbmtzLCAtLURhdmlkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gdHN2d2cgW21haWx0bzp0c3Z3Zy1ib3VuY2VzQGll dGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5TcGVuY2VyIERhd2tpbnMgYXQgSUVURjxicj4N CjxiPlNlbnQ6PC9iPiBGcmlkYXksIEp1bHkgMTMsIDIwMTggMToyNiBQTTxicj4NCjxiPlRvOjwv Yj4gTWFnbnVzIFdlc3Rlcmx1bmQ8YnI+DQo8Yj5DYzo8L2I+IHRzdndnQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbdHN2d2ddIEV4cGVyaWVuY2UgYW5kIFN0YXR1cyBvZiBFQ04g aW4gUVVJQyB3b3JrPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlJlc3BvbnNpYmxlIEFEIGhhdCBpcyBldmVuIG1vcmUgb2ZmIHRoYW4gRGF2aWQn cyBXRyBjaGFpciBoYXQgaW4gaGlzIHJlc3BvbnNlIC4uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEp1bCA1LCAyMDE4IGF0IDc6NDEg QU0gTWFnbnVzIFdlc3Rlcmx1bmQgJmx0OzxhIGhyZWY9Im1haWx0bzptYWdudXMud2VzdGVybHVu ZEBlcmljc3Nvbi5jb20iPm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwPlRTVldH LDxvOnA+PC9vOnA+PC9wPg0KPHA+RUNOIHN1cHBvcnQgd2FzIGFkZGVkIHRvIFFVSUMgaW4gdGhl IGxhdGVzdCBkcmFmdCB2ZXJzaW9ucyAoLTEzKS4gVGhlIHJlbGV2YW50IGRvY3VtZW50cyB0aGF0 IGluY2x1ZGUgRUNOIHJlbGF0ZWQgdGV4dCBhcmU6PG86cD48L286cD48L3A+DQo8cD48YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXF1aWMtdHJhbnNw b3J0LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtcXVpYy10cmFuc3BvcnQvPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcXVpYy1yZWNvdmVyeS8iIHRhcmdldD0iX2Js YW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXF1aWMtcmVj b3ZlcnkvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHA+VGhlIGluY2x1c2lvbiBvZiBFQ04gaW4gUVVJ QyBjYW4gYmUgc3VtbWFyaXplZCBhcy4gRWFjaCBzZW5kZXIgcGVyZm9ybXMgaW5pdGlhbCB2ZXJp ZmljYXRpb24gd2hlbiB0aGUgY29ubmVjdGlvbiBpcyBlc3RhYmxpc2hlZCBvciBtaWdyYXRlZCBi eSBzZXR0aW5nIEVDVCBvbiB0aGUgcGFja2V0cyBpdCBzZW5kLiBUaGUgcmVjZWl2ZXIgd2lsbCBy ZXBvcnQgaWYgaXQgc2VlcyBFQ04gbWFya3MsIGkuZS4gYW55IHZhbHVlIG90aGVyIHRoYW4gbm90 LUVDVCwNCiB1c2luZyBhIG5ldyBhY2tub3dsZWRnZW1lbnQgZnJhbWUgdHlwZSAoQUNLX0VDTikg dGhhdCBpbmNsdWRlcyBjb3VudGVycyBvZiBob3cgbWFueSBwYWNrZXRzIHdpdGggdGhlIHZhcmlv dXMgbWFya2luZ3MgdGhlIHJlY2VpdmVyIGhhdmUgc2VlbiBzaW5jZSBjb25uZWN0aW9uIGVzdGFi bGlzaG1lbnQuIElmIHRoZSByZWNlaXZlciBnZXRzIG5vdC1FQ1Qgb3IgY2FuJ3QgcmVhZCBFQ04g bWFya3MgdGhlbiBpdCB1c2VzIHRoZSBBQ0sgZnJhbWUgdG8NCiByZXBvcnQgdGhlc2UgcGFja2V0 cyBzbyB0aGF0IHRoZSBzZW5kZXIgY2FuIGxlYXJuIG9mIHRoZSBsYWNrIG9mIEVDVCBjYXBhYmls aXR5IGFuZCB0dXJuIGl0cyBtYXJraW5nIG9mZi4gTWFya2luZyBjb25zaXN0ZW5jeSBhcmUgY29u dGludW91c2x5IHZlcmlmaWVkLiBFQ04gYmxhY2sgaG9sZSBtaXRpZ2F0aW9uIGlzIGRpc2N1c3Nl ZCBhbmQgYSBwb3NzaWJsZSBtZWNoYW5pc20gaXMgdGhhdCBhbnkgUlRPIHdpbGwgcmVzdWx0IGlu IHJldHJhbnNtaXNzaW9uDQogd2l0aG91dCBFQ1QgbWFya3MuJm5ic3A7PG86cD48L286cD48L3A+ DQo8cD5UaGUgaW5jbHVzaW9uIG9mIEVDTiBpbiBRVUlDIGhhcyBzbyBmYXIgYmVlbiBmYWlybHkg d2VsbCBkaXNjdXNzZWQuIEluaXRpYWxseSBieSB0aGUgZGVzaWduIHRlYW0uIFRoZW4gYXQgdGhl IFFVSUMgaW50ZXJpbSBtZWV0aW5nIGluIEp1bmUsIGZvbGxvd2VkIGJ5IGEgbG90IG9mIGRpc2N1 c3Npb24gb2YgdGhlIGFjdHVhbCB0ZXh0IHByb3Bvc2FsIG9uIGdpdGh1Yi4gVGhhbmtzIHRvIGV2 ZXJ5b25lIHRoYXQgZW5nYWdlZC4gQmFzZWQgb24gdGhlc2UNCiBkaXNjdXNzaW9ucyB0aGVyZSBh cmUgc29tZSBxdWVzdGlvbnMgYW5kIGV4cGVyaWVuY2UgdGhhdCBJIGhhdmUgbm90aWNlZCB0aGF0 IGlzIHdvcnRoIHNwcmVhZGluZyBhbmQgZGlzY3Vzc2luZy4gVGhpcyBpcyBhbHNvIHRoZSB0b3Bp Y3MgY29taW5nIGluIHRoZSBUU1ZXRyBzZXNzaW9uIGZvciBteSBhZ2VuZGEgaXRlbS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkknZCBsaWtlIHRvIHRoYW5rIHRoZSBRVUlDLUVDTiBkZXNpZ24gdGVhbSBmb3Igc3VyZmFj aW5nIHRoaXMgaW4gVFNWV0cgYXQgdGhpcyB0aW1lLiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwPkFsc28gSSBkb24ndCBiZWxpZXZlIHRo ZSBsYXN0IHdvcmQgaXMgc2FpZCBhYm91dCBkZXRhaWxzIG9mIGhvdyBFQ04gaW4gUVVJQyBpcyBy ZWFsaXplZC4gVGhlcmUgYXJlIGN1cnJlbnRseSB0aHJlZSBkaWZmZXJlbnQgZ2l0aHViIGlzc3Vl cyByZWxhdGVkIHRvIEVDTjo8bzpwPjwvbzpwPjwvcD4NCjxwPi0gPGEgaHJlZj0iaHR0cHM6Ly9n aXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9pc3N1ZXMvMTQzOSIgdGFyZ2V0PSJfYmxhbmsi Pg0KSW1wcm92ZSBBQ0tfRUNOIGZyYW1lIGVuY29kaW5nIChlLmcuLCB1c2UgYml0LXZlY3Rvcik8 L2E+ICg8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL2lzc3Vl cy8xNDM5IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRy YWZ0cy9pc3N1ZXMvMTQzOTwvYT4pPGJyPg0KLSA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20v cXVpY3dnL2Jhc2UtZHJhZnRzL2lzc3Vlcy8xNDgxIiB0YXJnZXQ9Il9ibGFuayI+RnJhZ2lsaXR5 IGluIEVDTiBjb3VudGVycyB3aXRoIGxvc3QgYWNrczwvYT4gKDxhIGhyZWY9Imh0dHBzOi8vZ2l0 aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvaXNzdWVzLzE0ODEiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL2lzc3Vlcy8xNDgxPC9hPik8YnI+ DQotIDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvaXNzdWVz LzE0MjYiIHRhcmdldD0iX2JsYW5rIj5EZXRlY3QgYWR2ZXJzYXJpYWwgRUNOIHJlcG9ydGluZzwv YT4gKDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvaXNzdWVz LzE0MjYiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJh ZnRzL2lzc3Vlcy8xNDI2PC9hPik8bzpwPjwvbzpwPjwvcD4NCjxwPlNvIHRoZSB0aGluZ3MgSSB3 YW50IHRvIGJyaW5nIHRvIGF0dGVudGlvbiBhcmU6PG86cD48L286cD48L3A+DQo8cD48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwPkEuIFN1cHByZXNzaW9uIG9mIEVDTiB2YWx1ZXMgaW4gcGFja2V0 IGR1cGxpY2F0ZXM8bzpwPjwvbzpwPjwvcD4NCjxwPkluIFFVSUMgdGhlIGRyYWZ0cyBjdXJyZW50 bHkgc2F5cyB0aGF0IGEgcmVjZWl2ZXIgc2hvdWxkIHN1cHByZXNzIHRoZSBFQ04gdmFsdWVzIHJl Y2VpdmVkIGluIGFueSBwYWNrZXQgZHVwbGljYXRlcy4gVGhlIG1haW4gcmVhc29uIGZvciB0aGF0 IGlzIHRvIG1pdGlnYXRlIGEgcG90ZW50aWFsIGFjdGl2ZSBhdHRhY2sgYnkgYSBvZmYtcGF0aCBh dHRhY2tlciB0aGF0IGhhcyBzb21lIGNhcGFiaWxpdHkgdG8gcmVjZWl2ZSBhIGNvcHkgb2YgdGhl DQogcGFja2V0cyBvZiB0aGUgdGFyZ2V0IGZsb3cuIFdlIGNhbGwgaXQgYW4gb24tdGhlLXNpZGUg YXR0YWNrLiBCeSB0YWtpbmcgYSBjb3B5IG9mIGEgbGVnaXQgcGFja2V0LCBhbmQgY2hhbmdpbmcg dGhlIEVDTiBmaWVsZCB0byBFQ04tQ0UgYW5kIHRoZW4gZm9yd2FyZCB0aGUgbW9kaWZpZWQgY29w eSB0byB0aGUgaW50ZW5kZWQgcmVjZWl2ZXIgb25lIGNhbiBwZXJmb3JtIGEgZGVuaWFsIG9mIHNl cnZpY2UgYXR0YWNrIGJ5IGRyaXZpbmcgZG93biB0aGUNCiBjb25nZXN0aW9uIHdpbmRvdy4gVG8g bWl0aWdhdGUgdGhpcywgdGhlIHJlY29tbWVuZGF0aW9uIGlzIHRvIGNhcmUgYWJvdXQgb25seSB0 aGUgZmlyc3QgYXJyaXZlZCBwYWNrZXQuIFRoaXMgZm9yY2VzIGFuIG9uLXRoZS1zaWRlIGF0dGFj a2VyIHRvIGJlIGFibGUgdG8gcmFjZSB0aGVpciBhdHRhY2sgcGFja2V0cyB3aXRoIHRoZSBvcmln aW5hbCBwYWNrZXQuDQo8bzpwPjwvbzpwPjwvcD4NCjxwPlRoZSBkb3duc2lkZSBvZiB0aGlzIGlz IG9mIGNvdXJzZSB0aGF0IGFuIGFjdHVhbCBuZXR3b3JrIGR1cGxpY2F0aW9uIHdoZXJlIG5vbmUt Zmlyc3QgcGFja2V0cyBnZXRzIG1hcmtlZCBhcyBFQ04tQ0UgYWZ0ZXIgdGhlIGR1cGxpY2F0aW9u IHdlIGlnbm9yZSB0aGUgY29uZ2VzdGlvbiBzaWduYWwuIE15IHBlcnNvbmFsIHN0YW5kcG9pbnQg aXMgdGhhdCB0aGlzIGlzIG9rYXkuIElmIG5vdCB0aGUgZmlyc3QgcGFja2V0IHdhcyBtYXJrZWQg dGhlbg0KIGNvbmdlc3Rpb24gbWF5IG5vdCBiZSBzbyBiYWQgdGhhdCBpdCBpcyBhIHByb2JsZW0g aWYgdGhlIGR1cGxpY2F0aW9uIGRvbid0IGhhcHBlbnMuIFNlY29uZGx5LCBpZiBpdCBpcyBhbnkg cGVyc2lzdGVudCBjb25nZXN0aW9uIHRoZW4gdGhpcyBmbG93IHdpbGwgYmUgbWFya2VkIGluIGEg bGF0ZXIgcGFja2V0LiBUaGVyZSB3YXMgc29tZSBkaXNhZ3JlZW1lbnQgb24gdGhpcyBzbyBJIHRo aW5rIGl0IGlzIHdvcnRoIG1vcmUgZGlzY3Vzc2lvbi4NCjxvOnA+PC9vOnA+PC9wPg0KPHA+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cD5CLiBXaWxsIEVDVCgwKSBhbmQgRUNUKDEpIGJlIG1peGVk IGluIG9uZSBwYWNrZXQgZmxvdz88bzpwPjwvbzpwPjwvcD4NCjxwPkluIHRoZSBkaXNjdXNzaW9u cyBhcm91bmQgb3B0aW1pemluZyBob3cgdGhlIEVDTiBpbmZvcm1hdGlvbiByZXBvcnRlZCBmcm9t IHJlY2VpdmVyIHRvIHNlbmRlciB0aGlzIHF1ZXN0aW9uIGFyb3NlLiBJZiBvbmUgY2FuIG1ha2Ug YXNzdW1wdGlvbiB0aGF0IHdpdGhpbiBhIGNvbm5lY3Rpb24gb25lIHdpbGwgdXNlIG9ubHkgb25l IG9mIHRoZSBFQ1QgY29kZXBvaW50cyB0aGVuIHdlIGNhbiBvcHRpbWl6ZSB0aGUgcmVwb3J0aW5n IGJhc2VkIG9uDQogdGhhdCBhc3N1bXB0aW9uLiBTbyBob3cgc2FmZSBpcyB0aGlzIGFzc3VtcHRp b24/IEFuZCBpbiB0aGlzIGNhc2UsIHdoYXQgaXMgdGhlIGltcG9ydGFuY2Ugb2YgYmVpbmcgYWJs ZSB0byBkZXRlY3QgRUNUIGNvZGVwb2ludCByZW1hcmtpbmcsIGkuZS4gY2hhbmdpbmcgYmV0d2Vl biAwIGFuZCAxIGluIGVpdGhlciBkaXJlY3Rpb24/PG86cD48L286cD48L3A+DQo8cD48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwPkMuIERldGVjdGluZyBDaGVhdGluZyBSZWNlaXZlcnM8bzpwPjwv bzpwPjwvcD4NCjxwPkFzIHRoZXJlIGFyZSBzb21lIHJpc2tzIGluIGNlcnRhaW4gZGVwbG95bWVu dCBzaXR1YXRpb25zIHRoYXQgdGhlIHJlY2VpdmVyIHdvdWxkIGhhdmUgYW4gaW5jZW50aXZlIHRv IGxpZSBhYm91dCBpZiBhbiBFQ04tQ0UgbWFyayB3YXMgcmVjZWl2ZWQgb3Igbm90IHRvIGdhaW4g dGhyb3VnaHB1dC4gQSBzZW5kZXIgY291bGQgZGV0ZWN0IHRoaXMgY2FzZSBieSBzZW5kaW5nIHBh Y2tldHMgbWFya2VkIGFzIEVDTi1DRSB0byB2ZXJpZnkgdGhhdCByZWNlaXZlcg0KIHJlcG9ydHMg dGhlc2UgcGFja2V0cyBhcmUgYmVpbmcgbWFya2VkLiBBcyB0aGUgc2VuZGVyIHdpbGwgaWdub3Jl IHRoZSBFQ04tQ0UgbWFya3MgaXQgc2VsZiBnZW5lcmF0ZWQgdGhlcmUgaXMgYSByaXNrIHRoYXQg dGhlc2UgbWFya3MgaGlkZSByZWFsIENFIG1hcmtzLiBUaHVzLCB0aGUgZ2VuZXJhbCBxdWVzdGlv biBpcyBob3cgb2Z0ZW4sIGF0IG1vc3QsIHNob3VsZCBhIHNlbmRlciBtYXJrIHdpdGggRUNOLUNF Pw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JbiBteSBtaW5kLCBBIGFuZCBDIGFyZSByZWxhdGVkIC0gaG93IHBlcmZl Y3RseSBkb2VzIGEgc2VuZGVyIG5lZWQgdG8gcmVhY3QgcGVyZmVjdGx5IHRvIEVDTi1DRSBtYXJr aW5ncz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SW4gQSwgSSB0aGluayB0aGF0IG1heSBiZSB3aGVyZSBNYWdudXMgaXMgY29taW5nIGZyb20g LSB0aGUgc2VuZGVyIGlzIGFscmVhZHkgcmVhY3RpbmcgdG8gRUNOLUNFLCBhbmQgaWYgdGhlIHNl bmRlciBoYXNuJ3QgcmVzcG9uZGVkIHN1ZmZpY2llbnRseSwgdGhlIGZsb3cgd2lsbCBjb250aW51 ZSB0byBiZSBtYXJrZWQgaW4gbGF0ZXIgcGFja2V0cywgYW5kIHRoZSBzZW5kZXIgd2lsbCBoYXZl IGFuIG9wcG9ydHVuaXR5DQogdG8gcmVhY3QgYWdhaW4sIHVudGlsIGl0IGhhcyByZWFjdGVkIHN1 ZmZpY2llbnRseS4gSXMgdGhhdCB0aGUgcXVlc3Rpb24/Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIEMsIEknbSB0cnlpbmcgdG8g dW5kZXJzdGFuZCBob3cgbXVjaCBhIHJlY2VpdmVyIGNhbiBiZW5lZml0IGJ5IGNoZWF0aW5nLiBJ U1RNIHRoYXQgaWYgYSByZWNlaXZlciBzZWVzIEVDTi1DRSBtYXJraW5ncyBhbmQgZG9lc24ndCBy ZWZsZWN0IHRoYXQgYmFjayB0byB0aGUgc2VuZGVyLCBvbmUgb2YgdHdvIHRoaW5ncyB3aWxsIGhh cHBlbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KRWl0aGVyIHRo ZSBzZW5kZXIgcmVhbGx5IGRvZXNuJ3QgbmVlZCB0byBzbG93IGRvd24gKHNvIG5vIGZ1cnRoZXIg RUNOLUNFIG1hcmtzIGFycml2ZSBhdCB0aGUgcmVjZWl2ZXIpLCBvciZuYnNwOzxvOnA+PC9vOnA+ PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NClRo ZSBzZW5kZXIgcmVhbGx5IGRvZXMgbmVlZCB0byBzbG93IGRvd24gKHNvIHRoZSByZWNlaXZlciBr ZWVwcyBjaGVhdGluZyB1bnRpbCBhY3R1YWwgcGFja2V0cyBnZXQgbG9zdCwgd2hpY2ggdGhlIHJl Y2VpdmVyIHJlYWxseSBjYW4ndCBkaXNndWlzZSksIGFuZCBpcyBmaW5hbGx5IHNsb3dpbmcgZG93 biBiYXNlZCBvbiBwYWNrZXQgbG9zc2VzPG86cD48L286cD48L2xpPjwvdWw+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSB1bmRlcnN0YW5kIHRoYXQgQ29EZWwgYW5kIFBJRSBhcmUgRXhw ZXJpbWVudGFsLCBhbmQgSSB1bmRlcnN0YW5kIHRoYXQgTDRTIGlzIHN0aWxsIGluIFRTViwgYnV0 IGRvZXMgYSByZWNlaXZlciBjaGVhdGluZyBub3csIGFuZCBnb2luZyBmb3J3YXJkLCBtYWtlIGFz IG11Y2ggc2Vuc2UgYXMgaXQgZGlkIHdoZW4mbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjMzE2OCNzZWN0aW9uLTE4KCopIj5odHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjMzE2OCNzZWN0aW9uLTE4KCopPC9hPg0KIHdhcyBwdWJsaXNoZWQgaW4gMjAwMSwg d2l0aCBjb25nZXN0aW9uIGNvbnRyb2wgbWVjaGFuaXNtcyBhdmFpbGFibGUgYXQgdGhhdCB0aW1l PyBJdCBzZWVtcyBsaWtlIHRoYXQncyBqdXN0IGJlZ2dpbmcgZm9yIGJ1ZmZlcmJsb2F0LCBmb2xs b3dlZCBieSBsb3NzZXMsIGZvbGxvd2VkIGJ5IHBvb3IgcGVyZm9ybWFuY2UgZHVyaW5nIHJlY292 ZXJ5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkN1cmlvdXNseSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+U3BlbmNlciwgd2l0aCBubyBoYXRzPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPigqKSBJIHVuZGVyc3RhbmQgdGhh dCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzMTY4I3NlY3Rp b24tMTgiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzMTY4I3NlY3Rpb24tMTg8L2E+ IGlzIGRpc2N1c3NpbmcgbWlzYmVoYXZpbmcgcm91dGVycywgbm90IG1pc2JlaGF2aW5nIHJlY2Vp dmVycywgYnV0IHRoYXQgd2FzIGEgaGFuZHkgcmVmZXJlbmNlIGZvciAmcXVvdDt3aGF0IGhhcHBl bnMNCiBpZiB0aGUgc2VuZGVyIGNhbid0IHRydXN0IEVDTiBzaWduYWxzJnF1b3Q7IC4uLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwPkQuIERlbGF5ZWQgQWNr bm93bGVkZ2VtZW50IGFuZCBFQ04gPG86cD48L286cD48L3A+DQo8cD5XZSBhbHNvIGhhdmUgYW4g aW50ZXJlc3RpbmcgZGlzY3Vzc2lvbiBhcm91bmQgRUNOLCBEZWxheWVkIEFja25vd2xlZGdlbWVu dCBhbmQgdGhlIGludGVyYWN0aW9uIHdpdGggcmVjb3ZlcnkgcGVyaW9kLiBRVUlDIHN1cHBvcnRz IGRlbGF5ZWQgYWNrbm93bGVkZ2VtZW50LiBTbyBmYXIgdGhlcmUgYXJlIHF1aXRlIGEgbG90IG9m IGltcGxlbWVudGVyIGZyZWVkb20gb2YgaG93IHRvIHVzZSB0aGlzLiBXaGF0IGlzIGN1cnJlbnRs eSBzcGVjaWZpZWQNCiBpcyB0aGF0IHdoZW4gcmVjZWl2aW5nIGFuIEVDTi1DRSBtYXJrIHRoZSBy ZWNlaXZlciBzZW5kcyBhbiBpbW1lZGlhdGUgQUNLLCBzbyBnZXQgcmFwaWQgcmVzcG9uc2UgdG8g dGhlIGNvbmdlc3Rpb24gc2lnbmFsLiBXaGVuIHRoZSBBQ0tfRUNOIHJlYWNoZXMgdGhlIHNlbmRl ciBpdCB3aWxsIGdvIGludG8gUmVjb3ZlcnkgdW50aWwgYSBwYWNrZXQgc2VudCBhZnRlciBlbnRl cmluZyByZWNvdmVyeSBoYXMgYmVlbiBhY2tub3dsZWRnZWQuIER1cmluZw0KIHJlY292ZXJ5IGFz IHRoZSBjb25nZXN0aW9uIHdpbmRvdyBhbHJlYWR5IGlzIHJlZHVjZWQgYW5kIGZyb3plbiB0aGUg cmVjZXB0aW9uIG9mIGFkZGl0aW9uYWwgRUNOLUNFIG1hcmtzIChhdCBsZWFzdCBmb3IgdGhlIGN1 cnJlbnQgY29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbSkgaXMgbm90IHRoYXQgaW1wb3J0YW50 LiBXaGF0IGlzIGltcG9ydGFudCBpcyBpZiBhbnkgcGFja2V0cyBhcmUgRUNOLUNFIG1hcmtlZCB3 aGVuIGV4aXRpbmcgcmVjb3ZlcnkuDQogTWFya3Mgb24gcGFja2V0cyBzZW50IGFmdGVyIHJlY292 ZXJ5IHNob3VsZCByZXN1bHQgaW4gYSBuZXcgY29uZ2VzdGlvbiBldmVudCBhbmQgbmV3IHJlY292 ZXJ5IHBlcmlvZC4gVG8gcmVzb2x2ZSB0aGlzIHRoZSBjdXJyZW50IHJlcXVpcmVtZW50IGlzIHRv IGltbWVkaWF0ZWx5IGFja25vd2xlZGdlIGVhY2ggRUNOLUNFIG1hcmtzLiBUaGlzIHdpbGwgcmVz dWx0IGluIHNvbWUgYWRkaXRpb25hbCBhY2tub3dsZWRnZW1lbnRzLg0KPG86cD48L286cD48L3A+ DQo8cD5UaGVyZSBoYXMgYmVlbiBzb21lIGRpc2N1c3Npb24gaWYgb25lIHdhbnQgdG8gb3B0aW1p emUgdGhpcyBjYXNlIG9yIGlmIGl0IGlzIG5vdCB3b3J0aCBpdC4gT25lIGRpcmVjdGlvbiB3YXMg dG8gZW5zdXJlIHRoYXQgZXZlbiB3aXRoIGRlbGF5ZWQgQUNLcyBvbmUgZ2V0IGZyZXF1ZW50IGVu b3VnaCBhY2tub3dsZWRnZW1lbnRzLiBUaGlzIHJlc3VsdGVkIGluIGRpc2N1c3Npb24gaW4gdGhl IGRpcmVjdGlvbiBvZiBlbnN1cmluZyB0aGF0IHRoZQ0KIGxvbmdlc3QgZGVsYXkgYmVmb3JlIGFj a25vd2xlZGdpbmcgaXMgY2FwZWQgYXQgYSBxdWFydGVyIG9mIHRoZSBSVFQuIFRoYXQgd2F5IG9u ZSBhY2hpZXZlIG5vIHdvcnNlIHRoYW4gcXVhcnRlciBSVFQgcmVzb2x1dGlvbiBvbiB0aGUgRUNO LUNFIG1hcmtzLiBBbm90aGVyIHBvdGVudGlhbCBkaXJlY3Rpb24gaXMgZXhwbGljaXQgaW5kaWNh dGlvbiBvZiB3aGljaCBwYWNrZXQgbnVtYmVycyB0aGF0IHdvdWxkIHJlc29sdmUgdGhpcyB1bmNl cnRhaW50eS4NCiBUaGVuIGFsc28gZXhpc3RzIHRoZSBxdWVzdGlvbiBpZiB0aGUgcmVjZWl2ZXIg bmVlZHMgYW55IGluZGljYXRpb24gb2YgcmVjb3ZlcnkgcGVyaW9kcyB0byBvcHRpbWl6ZSB0aGUg YWNrbm93bGVkZ2VtZW50cy4NCjxvOnA+PC9vOnA+PC9wPg0KPHA+RS4gVXRpbGl0eSBvZiBkZXRh aWxlZCBDRSBpbmZvcm1hdGlvbjxvOnA+PC9vOnA+PC9wPg0KPHA+QXMgdGhlcmUgaGFzIGJlZW4g ZGlzY3Vzc2lvbiBhYm91dCBleHBsaWNpdGx5IGluZGljYXRlIHdoaWNoIHBhY2tldCBudW1iZXJz IHdhcyBtYXJrZWQgYXMgQ0UsIGl0IGlzIGFsc28gZ29vZCB0byB1bmRlcnN0YW5kIGlmIHRoZXJl IGFyZSBhbnkgc2lnbmlmaWNhbnQgdXRpbGl0eSBvZiBoYXZpbmcgdGhpcyBpbmZvcm1hdGlvbiBm b3IgdGhlIHNlbmRlciBjb21wYXJlZCB0byB3aGF0IHRoZSBjb3VudGVycyBwcm92aWRlLiBJIGFz c3VtZSB0aGlzDQogZ29lcyBpbnRvIHRoZSBwb3RlbnRpYWwgZm9yIGNvbmdlc3Rpb24gY29udHJv bCBtZWNoYW5pc20gZXZvbHV0aW9uLiBCdXQsIGRvZXMgaXQgbWF0dGVyIGZvciBleGFtcGxlIGZv ciBMNFM/DQo8bzpwPjwvbzpwPjwvcD4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHByZT5D aGVlcnMgPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmU+TWFnbnVzIFdlc3Rlcmx1bmQgPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8 L286cD48L3ByZT4NCjxwcmU+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk5l dHdvcmsgQXJjaGl0ZWN0dXJlICZhbXA7IFByb3RvY29scywgRXJpY3Nzb24gUmVzZWFyY2g8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3ByZT4NCjxwcmU+ RXJpY3Nzb24gQUImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBQaG9u ZSZuYnNwOyAmIzQzOzQ2IDEwIDcxNDgyODc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Ub3JzaGFt bnNnYXRhbiAyMyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8IE1vYmlsZSAmIzQzOzQ2IDczIDA5NDkwNzk8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5TRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW4gfCBtYWlsdG86IDxhIGhyZWY9Im1h aWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb208L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+LS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CE03DB3D7B45C245BCA0D24327794936301D3594MX307CL04corpem_-- From nobody Fri Jul 13 14:09:32 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF1C130E37 for ; Fri, 13 Jul 2018 14:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 POZvVdy3kP_1 for ; Fri, 13 Jul 2018 14:09:27 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B2DC130E17 for ; Fri, 13 Jul 2018 14:09:27 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id h127-v6so13284202ybg.12 for ; Fri, 13 Jul 2018 14:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lJMwf3J9OAOmXKXS2mTeEDPIC86jYJ51/lg3oZRJpqM=; b=A1nvwHCufLAhAFlXSr/WjXe2PrNWW4HHmZ905rxv6bxShJZIBxBm7qt9HKe1XI4ent g8qGIkKAzePddQp+qjCUFVhHJTizd+fwa2rDUJ6VbOgVVs43Azt9qE2SxdmAoEbDf77J CWRJwo8wWdsYbDlvkEakJfuIqhQe3wbxn+cDnOl3jaKURQmBqgV2dUCPzGywxK9cPLEp EnqaAxeU9niPpfniGLpdnLgVGq6gRPnRwX9ujHocqBWOiV1v/1cjVr+UlLvrM+OAbng0 8r50BEOgBw3MS5B4cD/76BrAmtWOiNRiFQJTsLySqugnMPSC3vKN0nuZRosjkQ4yFU69 14FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lJMwf3J9OAOmXKXS2mTeEDPIC86jYJ51/lg3oZRJpqM=; b=FBcwVY5DSIZTFTJghn0/2OsU169UYo79RN/jVU4LyByrR0enZCcMQ/3t3fD2EdYiuL zyNsWXTUBYNHudPzGg2yvx2mj3HmDkdxCPMwOC3TXCzfaFGrqiQj49svm501qU8cKbcQ VfyyZ/lPprDOt8x3DOLVuuzJXR2+Ha5WUoS889u9CQ0pnS76yoiVVBz5bXI9m6lAvtaT ZPtoRdKFyGPfALQNAroIAtM+mgsvx3qfUfPO+1sswuIXaz9Y282+OGvGt2rIhjna8bkw pjddbiEKTWrxDJIiRJTRSP/lHO+qpMYdLD9fz3uNPklIFtb906MJl/eZobeT0nlUuYpx Jzrw== X-Gm-Message-State: AOUpUlE5NKaRyBqCDWA6pgBz/Ed70gZwNQS/yIR4P18r/0HfkUC/utQO yzIY6+OXxesMzTuaYsxHIuLMcaendiVcC1RNQ5c= X-Google-Smtp-Source: AAOMgpesr+Pss72BqPQ7xQl8Z5Tl9UwGJF0JnmZYfg+MA9J1LF16bfdCvW3URYik2j0peJScNY2xodHGGVdtrpZTynw= X-Received: by 2002:a25:6f8b:: with SMTP id k133-v6mr4396446ybc.286.1531516166480; Fri, 13 Jul 2018 14:09:26 -0700 (PDT) MIME-Version: 1.0 References: <6f8ee7ac-9318-b4ab-626c-a3a36acba042@ericsson.com> In-Reply-To: From: Spencer Dawkins at IETF Date: Fri, 13 Jul 2018 16:09:14 -0500 Message-ID: To: "Black, David" Cc: Magnus Westerlund , tsvwg@ietf.org Content-Type: multipart/alternative; boundary="000000000000122b1e0570e7e5fa" Archived-At: Subject: Re: [tsvwg] Experience and Status of ECN in QUIC work X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 21:09:31 -0000 --000000000000122b1e0570e7e5fa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, David, AD hat still off as well ... On Fri, Jul 13, 2018 at 3:05 PM Black, David wrote: > WG chair hat still off =E2=80=A6 > > > > > I'm trying to understand how much a receiver can benefit by cheating. > ISTM that if a receiver sees ECN-CE markings and doesn't reflect that bac= k > to the sender, one of two things will happen. > > - Either the sender really doesn't need to slow down (so no further > ECN-CE marks arrive at the receiver), or > - The sender really does need to slow down (so the receiver keeps > cheating until actual packets get lost, which the receiver really can'= t > disguise), and is finally slowing down based on packet losses > > It helps to think about behavior at the bottleneck queue that is > generating the ECN-CE marks. If all receivers cheat and ignore the mark= s, > nobody wins because the bottleneck condition persists. The cheating > receiver wins if other receivers don=E2=80=99t cheat, and the resulting b= ackoff of > other flows causes the bottleneck queue to no longer be a bottleneck, i.e= ., > it stops generating ECN-CE marks. At that point the cheating receiver= =E2=80=99s > flow has more share of the formerly bottlenecked queue=E2=80=99s throughp= ut than > that flow should. > That is helpful. Thank you. I'm still curious about how long this advantage lasts, but I can easily imagine that's not an answerable question in the general case. I'll keep watching discussion on the mailing list, and during TSVWG next week. Spencer > > > Thanks, --David > > > > *From:* tsvwg [mailto:tsvwg-bounces@ietf.org] *On Behalf Of *Spencer > Dawkins at IETF > *Sent:* Friday, July 13, 2018 1:26 PM > *To:* Magnus Westerlund > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tsvwg] Experience and Status of ECN in QUIC work > > > > Responsible AD hat is even more off than David's WG chair hat in his > response ... > > > > On Thu, Jul 5, 2018 at 7:41 AM Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: > > TSVWG, > > ECN support was added to QUIC in the latest draft versions (-13). The > relevant documents that include ECN related text are: > > https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ > https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/ > > The inclusion of ECN in QUIC can be summarized as. Each sender performs > initial verification when the connection is established or migrated by > setting ECT on the packets it send. The receiver will report if it sees E= CN > marks, i.e. any value other than not-ECT, using a new acknowledgement fra= me > type (ACK_ECN) that includes counters of how many packets with the variou= s > markings the receiver have seen since connection establishment. If the > receiver gets not-ECT or can't read ECN marks then it uses the ACK frame = to > report these packets so that the sender can learn of the lack of ECT > capability and turn its marking off. Marking consistency are continuously > verified. ECN black hole mitigation is discussed and a possible mechanism > is that any RTO will result in retransmission without ECT marks. > > The inclusion of ECN in QUIC has so far been fairly well discussed. > Initially by the design team. Then at the QUIC interim meeting in June, > followed by a lot of discussion of the actual text proposal on github. > Thanks to everyone that engaged. Based on these discussions there are som= e > questions and experience that I have noticed that is worth spreading and > discussing. This is also the topics coming in the TSVWG session for my > agenda item. > > I'd like to thank the QUIC-ECN design team for surfacing this in TSVWG at > this time. > > Also I don't believe the last word is said about details of how ECN in > QUIC is realized. There are currently three different github issues relat= ed > to ECN: > > - Improve ACK_ECN frame encoding (e.g., use bit-vector) > ( > https://github.com/quicwg/base-drafts/issues/1439) > - Fragility in ECN counters with lost acks > ( > https://github.com/quicwg/base-drafts/issues/1481) > - Detect adversarial ECN reporting > ( > https://github.com/quicwg/base-drafts/issues/1426) > > So the things I want to bring to attention are: > > > > A. Suppression of ECN values in packet duplicates > > In QUIC the drafts currently says that a receiver should suppress the ECN > values received in any packet duplicates. The main reason for that is to > mitigate a potential active attack by a off-path attacker that has some > capability to receive a copy of the packets of the target flow. We call i= t > an on-the-side attack. By taking a copy of a legit packet, and changing t= he > ECN field to ECN-CE and then forward the modified copy to the intended > receiver one can perform a denial of service attack by driving down the > congestion window. To mitigate this, the recommendation is to care about > only the first arrived packet. This forces an on-the-side attacker to be > able to race their attack packets with the original packet. > > The downside of this is of course that an actual network duplication wher= e > none-first packets gets marked as ECN-CE after the duplication we ignore > the congestion signal. My personal standpoint is that this is okay. If no= t > the first packet was marked then congestion may not be so bad that it is = a > problem if the duplication don't happens. Secondly, if it is any persiste= nt > congestion then this flow will be marked in a later packet. There was som= e > disagreement on this so I think it is worth more discussion. > > > > B. Will ECT(0) and ECT(1) be mixed in one packet flow? > > In the discussions around optimizing how the ECN information reported fro= m > receiver to sender this question arose. If one can make assumption that > within a connection one will use only one of the ECT codepoints then we c= an > optimize the reporting based on that assumption. So how safe is this > assumption? And in this case, what is the importance of being able to > detect ECT codepoint remarking, i.e. changing between 0 and 1 in either > direction? > > > > C. Detecting Cheating Receivers > > As there are some risks in certain deployment situations that the receive= r > would have an incentive to lie about if an ECN-CE mark was received or no= t > to gain throughput. A sender could detect this case by sending packets > marked as ECN-CE to verify that receiver reports these packets are being > marked. As the sender will ignore the ECN-CE marks it self generated ther= e > is a risk that these marks hide real CE marks. Thus, the general question > is how often, at most, should a sender mark with ECN-CE? > > In my mind, A and C are related - how perfectly does a sender need to > react perfectly to ECN-CE markings? > > > > In A, I think that may be where Magnus is coming from - the sender is > already reacting to ECN-CE, and if the sender hasn't responded > sufficiently, the flow will continue to be marked in later packets, and t= he > sender will have an opportunity to react again, until it has reacted > sufficiently. Is that the question? > > > > In C, I'm trying to understand how much a receiver can benefit by > cheating. ISTM that if a receiver sees ECN-CE markings and doesn't reflec= t > that back to the sender, one of two things will happen. > > - Either the sender really doesn't need to slow down (so no further > ECN-CE marks arrive at the receiver), or > - The sender really does need to slow down (so the receiver keeps > cheating until actual packets get lost, which the receiver really can'= t > disguise), and is finally slowing down based on packet losses > > I understand that CoDel and PIE are Experimental, and I understand that > L4S is still in TSV, but does a receiver cheating now, and going forward, > make as much sense as it did when > https://tools.ietf.org/html/rfc3168#section-18(*) was published in 2001, > with congestion control mechanisms available at that time? It seems like > that's just begging for bufferbloat, followed by losses, followed by poor > performance during recovery. > > > > Curiously, > > > > Spencer, with no hats > > > > (*) I understand that https://tools.ietf.org/html/rfc3168#section-18 is > discussing misbehaving routers, not misbehaving receivers, but that was a > handy reference for "what happens if the sender can't trust ECN signals" = ... > > D. Delayed Acknowledgement and ECN > > We also have an interesting discussion around ECN, Delayed Acknowledgemen= t > and the interaction with recovery period. QUIC supports delayed > acknowledgement. So far there are quite a lot of implementer freedom of h= ow > to use this. What is currently specified is that when receiving an ECN-CE > mark the receiver sends an immediate ACK, so get rapid response to the > congestion signal. When the ACK_ECN reaches the sender it will go into > Recovery until a packet sent after entering recovery has been acknowledge= d. > During recovery as the congestion window already is reduced and frozen th= e > reception of additional ECN-CE marks (at least for the current congestion > control mechanism) is not that important. What is important is if any > packets are ECN-CE marked when exiting recovery. Marks on packets sent > after recovery should result in a new congestion event and new recovery > period. To resolve this the current requirement is to immediately > acknowledge each ECN-CE marks. This will result in some additional > acknowledgements. > > There has been some discussion if one want to optimize this case or if it > is not worth it. One direction was to ensure that even with delayed ACKs > one get frequent enough acknowledgements. This resulted in discussion in > the direction of ensuring that the longest delay before acknowledging is > caped at a quarter of the RTT. That way one achieve no worse than quarter > RTT resolution on the ECN-CE marks. Another potential direction is explic= it > indication of which packet numbers that would resolve this uncertainty. > Then also exists the question if the receiver needs any indication of > recovery periods to optimize the acknowledgements. > > E. Utility of detailed CE information > > As there has been discussion about explicitly indicate which packet > numbers was marked as CE, it is also good to understand if there are any > significant utility of having this information for the sender compared to > what the counters provide. I assume this goes into the potential for > congestion control mechanism evolution. But, does it matter for example f= or > L4S? > > > > Cheers > > > > Magnus Westerlund > > > > ---------------------------------------------------------------------- > > Network Architecture & Protocols, Ericsson Research > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > Torshamnsgatan 23 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > --000000000000122b1e0570e7e5fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, David,=C2=A0

AD hat still off as we= ll ...=C2=A0

On F= ri, Jul 13, 2018 at 3:05 PM Black, David <David.Black@dell.com> wrote:

WG chair hat still off =E2=80=A6

=C2=A0

> I'm trying to understand how much a receive= r can benefit by cheating. ISTM that if a receiver sees ECN-CE markings and= doesn't reflect that back to the sender, one of two things will happen= .

  • Either the sender really doesn't need to slow down (so no further ECN-C= E marks arrive at the receiver), or=C2=A0
  • The sender really does need to slow down (so the receiver keeps cheating un= til actual packets get lost, which the receiver really can't disguise),= and is finally slowing down based on packet losses

It helps to think about behavior at t= he bottleneck queue that is generating the ECN-CE marks.=C2=A0=C2=A0 If all= receivers cheat and ignore the marks, nobody wins because the bottleneck condition persists.=C2=A0=C2=A0 The cheating receiver wins = if other receivers don=E2=80=99t cheat, and the resulting backoff of other = flows causes the bottleneck queue to no longer be a bottleneck, i.e., it st= ops generating ECN-CE marks.=C2=A0=C2=A0 At that point the cheating receiver=E2=80=99s flow has more share of the formerly bottlenecked queue= =E2=80=99s throughput than that flow should.


That is helpful. Thank you.=C2=A0

I'm still curious about how long this advantage lasts, but I c= an easily imagine that's not an answerable question in the general case= .

I'll keep watching discussion on the mailing= list, and during TSVWG next week.

Spencer=C2=A0

=C2=A0

Thanks, --David<= /p>

=C2=A0

From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Spencer Dawkins at IETF
Sent: Friday, July 13, 2018 1:26 PM
To: Magnus Westerlund
Cc: tsvwg@ietf.o= rg
Subject: Re: [tsvwg] Experience and Status of ECN in QUIC work

=C2=A0

Responsible AD hat is even more off than David's= WG chair hat in his response ...=C2=A0

=C2=A0

On Thu, Jul 5, 2018 at 7:41 AM Magnus Westerlund <= ;magnus= .westerlund@ericsson.com> wrote:

TSVWG,

ECN support was added to QUIC in the latest draft versions (-13). The re= levant documents that include ECN related text are:

https://datatracker.ietf.org/doc/draft-ietf-quic-transpor= t/
https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/

The inclusion of ECN in QUIC can be summarized as. Each sender performs = initial verification when the connection is established or migrated by sett= ing ECT on the packets it send. The receiver will report if it sees ECN mar= ks, i.e. any value other than not-ECT, using a new acknowledgement frame type (ACK_ECN) that includes counters of= how many packets with the various markings the receiver have seen since co= nnection establishment. If the receiver gets not-ECT or can't read ECN = marks then it uses the ACK frame to report these packets so that the sender can learn of the lack of ECT capab= ility and turn its marking off. Marking consistency are continuously verifi= ed. ECN black hole mitigation is discussed and a possible mechanism is that= any RTO will result in retransmission without ECT marks.=C2=A0

The inclusion of ECN in QUIC has so far been fairly well discussed. Init= ially by the design team. Then at the QUIC interim meeting in June, followe= d by a lot of discussion of the actual text proposal on github. Thanks to e= veryone that engaged. Based on these discussions there are some questions and experience that I have noticed th= at is worth spreading and discussing. This is also the topics coming in the= TSVWG session for my agenda item.

I'd like to thank the QUIC-ECN design team for s= urfacing this in TSVWG at this time.=C2=A0=C2=A0

Also I don't believe the last word is said about details of how ECN = in QUIC is realized. There are currently three different github issues rela= ted to ECN:

- Improve ACK_ECN frame encoding (e.g., use bit-vector) (https://git= hub.com/quicwg/base-drafts/issues/1439)
- Fragility in ECN counters with lost acks (https://github.co= m/quicwg/base-drafts/issues/1481)
- Detect adversarial ECN reporting (https://github.com/quicwg= /base-drafts/issues/1426)

So the things I want to bring to attention are:

=C2=A0

A. Suppression of ECN values in packet duplicates

In QUIC the drafts currently says that a receiver should suppress the EC= N values received in any packet duplicates. The main reason for that is to = mitigate a potential active attack by a off-path attacker that has some cap= ability to receive a copy of the packets of the target flow. We call it an on-the-side attack. By taking a = copy of a legit packet, and changing the ECN field to ECN-CE and then forwa= rd the modified copy to the intended receiver one can perform a denial of s= ervice attack by driving down the congestion window. To mitigate this, the recommendation is to care about o= nly the first arrived packet. This forces an on-the-side attacker to be abl= e to race their attack packets with the original packet.

The downside of this is of course that an actual network duplication whe= re none-first packets gets marked as ECN-CE after the duplication we ignore= the congestion signal. My personal standpoint is that this is okay. If not= the first packet was marked then congestion may not be so bad that it is a problem if the duplication don&#= 39;t happens. Secondly, if it is any persistent congestion then this flow w= ill be marked in a later packet. There was some disagreement on this so I t= hink it is worth more discussion.

=C2=A0

B. Will ECT(0) and ECT(1) be mixed in one packet flow?

In the discussions around optimizing how the ECN information reported fr= om receiver to sender this question arose. If one can make assumption that = within a connection one will use only one of the ECT codepoints then we can= optimize the reporting based on that assumption. So how safe is this assumption? And in this case, what is= the importance of being able to detect ECT codepoint remarking, i.e. chang= ing between 0 and 1 in either direction?

=C2=A0

C. Detecting Cheating Receivers

As there are some risks in certain deployment situations that the receiv= er would have an incentive to lie about if an ECN-CE mark was received or n= ot to gain throughput. A sender could detect this case by sending packets m= arked as ECN-CE to verify that receiver reports these packets are being marked. As the sender will ignore the ECN-= CE marks it self generated there is a risk that these marks hide real CE ma= rks. Thus, the general question is how often, at most, should a sender mark= with ECN-CE?

In my mind, A and C are related - how perfectly does= a sender need to react perfectly to ECN-CE markings?

=C2=A0

In A, I think that may be where Magnus is coming fro= m - the sender is already reacting to ECN-CE, and if the sender hasn't = responded sufficiently, the flow will continue to be marked in later packet= s, and the sender will have an opportunity to react again, until it has reacted sufficiently. Is that the question?= =C2=A0

=C2=A0

In C, I'm trying to understand how much a receiv= er can benefit by cheating. ISTM that if a receiver sees ECN-CE markings an= d doesn't reflect that back to the sender, one of two things will happe= n.

  • Either the sender really doesn't need to slow down (so no further ECN-C= E marks arrive at the receiver), or=C2=A0
  • The sender really does need to slow down (so the receiver keeps cheating un= til actual packets get lost, which the receiver really can't disguise),= and is finally slowing down based on packet losses

I understand that CoDel and PIE are Experimental, an= d I understand that L4S is still in TSV, but does a receiver cheating now, = and going forward, make as much sense as it did when=C2=A0https://tool= s.ietf.org/html/rfc3168#section-18(*) was published in 2001, with congestion control mechanisms available at tha= t time? It seems like that's just begging for bufferbloat, followed by = losses, followed by poor performance during recovery.

=C2=A0

Curiously,

=C2=A0

Spencer, with no hats

=C2=A0

(*) I understand that=C2=A0https://tools.ietf.org/= html/rfc3168#section-18 is discussing misbehaving routers, not misbehav= ing receivers, but that was a handy reference for "what happens if the sender can't trust ECN signals" ...

D. Delayed Acknowledgement and ECN

We also have an interesting discussion around ECN, Delayed Acknowledgeme= nt and the interaction with recovery period. QUIC supports delayed acknowle= dgement. So far there are quite a lot of implementer freedom of how to use = this. What is currently specified is that when receiving an ECN-CE mark the receiver sends an immediate ACK,= so get rapid response to the congestion signal. When the ACK_ECN reaches t= he sender it will go into Recovery until a packet sent after entering recov= ery has been acknowledged. During recovery as the congestion window already is reduced and frozen the recept= ion of additional ECN-CE marks (at least for the current congestion control= mechanism) is not that important. What is important is if any packets are = ECN-CE marked when exiting recovery. Marks on packets sent after recovery should result in a new congestion eve= nt and new recovery period. To resolve this the current requirement is to i= mmediately acknowledge each ECN-CE marks. This will result in some addition= al acknowledgements.

There has been some discussion if one want to optimize this case or if i= t is not worth it. One direction was to ensure that even with delayed ACKs = one get frequent enough acknowledgements. This resulted in discussion in th= e direction of ensuring that the longest delay before acknowledging is caped at a quarter of the RTT. That = way one achieve no worse than quarter RTT resolution on the ECN-CE marks. A= nother potential direction is explicit indication of which packet numbers t= hat would resolve this uncertainty. Then also exists the question if the receiver needs any indication of reco= very periods to optimize the acknowledgements.

E. Utility of detailed CE information

As there has been discussion about explicitly indicate which packet numb= ers was marked as CE, it is also good to understand if there are any signif= icant utility of having this information for the sender compared to what th= e counters provide. I assume this goes into the potential for congestion control mechanism evolution. But, d= oes it matter for example for L4S?

=C2=A0

Cheers 
=C2=A0
Magnus Westerlund 
=C2=A0
----------------------------------------------------------------------=
Network Architecture & Protocols, Ericsson Research<=
/pre>
----------------------------------------------------------------------=
Ericsson AB=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Phone=C2=A0 +46 10 7148287=
Torshamnsgatan 23=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------=
--000000000000122b1e0570e7e5fa-- From nobody Sat Jul 14 03:33:37 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AECCD131083 for ; Sat, 14 Jul 2018 03:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 bQlfzOQieRTR for ; Sat, 14 Jul 2018 03:33:32 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78607130E58 for ; Sat, 14 Jul 2018 03:33:31 -0700 (PDT) Received: from [10.53.229.2] (unknown [88.128.80.168]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 6C58A721E2822; Sat, 14 Jul 2018 12:33:26 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Michael Tuexen In-Reply-To: <67CF347253A4874C8F2A2A8CD1D9460B72BF4A56@BLREML503-MBX.china.huawei.com> Date: Sat, 14 Jul 2018 12:33:22 +0200 Cc: Shweta r , "tsvwg@ietf.org" , Sharath Chandra B , Ashutosh prakash Content-Transfer-Encoding: quoted-printable Message-Id: <7FF68D15-EA4C-4076-B884-1531F150C7E8@lurchi.franken.de> References: <421CE35A2FDF994790546C7F50F875455E9601DB@dggemi506-mbs.china.huawei.com> <421CE35A2FDF994790546C7F50F875455E9616AC@dggemi506-mbs.china.huawei.com> <421CE35A2FDF994790546C7F50F875455E96521A@dggemi526-mbs.china.huawei.com> <61C0B574-D6F8-4FC9-B0CC-1C6F4F39F768@lurchi.franken.de> <421CE35A2FDF994790546C7F50F875455E967537@dggemi526-mbs.china.huawei.com> <1BF25B06-D8D3-484E-B69A-E60709153A52@lurchi.franken.de> <67CF347253A4874C8F2A2A8CD1D9460B72BF4A56@BLREML503-MBX.china.huawei.com> To: Sidhartha pant X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [tsvwg] Query regarding random parameter in SCTP-AUTH RFC 4895 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2018 10:33:37 -0000 > On 12. Jul 2018, at 15:24, Sidhartha pant = wrote: >=20 > Hi Michael, >=20 > As per the recent discussions on RFC 4895 and RFC 6083, we are able to = conclude on point 1 and have some doubts on point 2 and 3. > However we are not able to find specific references in the above RFCs = for these points. :- >=20 > 1. When the key is installed but not yet active, SCTP should = process it , if such an AUTH containing this key is received. > 2. Only the active key should be use to send packet, does this mean = we should bundle chunks with different keys? This is in contrast with = the statement that no two user messages with different key should be = bundled and sent.=20 https://tools.ietf.org/html/rfc6458#section-8.1.18 states When used with setsockopt(), the SCTP implementation must use the indicated shared key identifier for all messages being given to an SCTP implementation via a send call after the setsockopt() call, until changed again. For each user message which needs to be sent authenticated, the stack = must know which key to use. It is the key, which was the active key at the point = of time the (beginning of the) message was given to the SCTP stack unless it is = overwritten by using a CMSG as described in https://tools.ietf.org/html/rfc6458#section-5.3.8 So the stack knows for each user message which key to use. When the = stack bundled user messages, it MUST NOT bundle message requiring different = keys. In that case, the stack needs to send separate messages... > a) RFC 6458 Section 3.5.8:- =E2=80=9CPlease note that the SCTP = implementation must not bundle user messages that need to be = authenticated using different shared key identifiers.=E2=80=9D > 3. Before sending the FINISHED message, active key should be = switched to new key, however in some open SSL implementation we observe = that key is activated only once the FINISHED handshake is completed. > a) RFC 6083: =E2=80=9CBefore sending the Finished message, the = active SCTP-AUTH key MUST be switched to the new one.=E2=80=9D Then it is a bug... At least it is not as specified. I'm not sure, but = it might be an optimization to avoid a timeout. I remember something like this vaguely. You send the CHANGE-CIPHERSPEC message and the FINISHED message back to = back. Assume you send the FINISHED message with the new keyid then it might be = dropped by the peer, if at the time it is received, the new key is not configured = yet. So you might wait some time between sending the messages. Or, and I = think this is what OpenSSL does, send it using the old key. Then both messages will = be accepted. But this is not as specified... This might be something for an errata... >=20 > I feel currently the RFC explicitly does not specify the above points, = I am wondering if an errata exists or we can update these in the RFCs = (6083 and 4895). Feel free to submit erratas... >=20 > Thank you. >=20 > Best Regards, > Sidhartha Pant > Domain SE|VPP Team 2012 Lab >=20 > Huawei Technologies India Pvt. Ltd. > Survey No. 37, Next to EPIP Area, Kundalahalli, Whitefield > Bengaluru-560066, Karnataka=20 > Tel: + 91-80-49160700 Ext 71594 II Mob: +919886174874 Email: = spant@huawei.com >=20 > -----Original Message----- > From: Michael Tuexen [mailto:michael.tuexen@lurchi.franken.de]=20 > Sent: 28 June 2018 18:42 > To: Shweta r > Cc: tsvwg@ietf.org; Sharath Chandra B ; = Sidhartha pant ; Ashutosh prakash = > Subject: Re: [tsvwg] Query regarding random parameter in SCTP-AUTH RFC = 4895 >=20 >=20 >=20 >> On 21. Jun 2018, at 17:33, Shweta r wrote: >>=20 >> Hi Michael, >>=20 >> >>=20 >>=20 >> RFC 6083: >> 4.8. Handling of Endpoint-Pair Shared Secrets >>=20 >> The endpoint-pair shared secret for Shared Key Identifier 0 is = empty >> and MUST be used when establishing a DTLS connection. Whenever the >> master key changes, a 64-byte shared secret is derived from every >> master secret and provided as a new endpoint-pair shared secret by >> using the exporter described in [RFC5705]. The exporter MUST use = the >> label given in Section 5 and no context. The new Shared Key >> Identifier MUST be the old Shared Key Identifier incremented by 1. >> If the old one is 65535, the new one MUST be 1. >>=20 >> Before sending the Finished message, the active SCTP-AUTH key MUST = be >> switched to the new one. >>=20 >> Once the corresponding Finished message from the peer has been >> received, the old SCTP-AUTH key SHOULD be removed. >>=20 >> ---> My doubt , how user will come to know when to configure new key, = Is It like before client sends ChangeCipherSpec, user will get dry_event = callback, that time user configures new key and sends Finished message = with new key? > Text says when to use a new key for sending: Before sending the = Finished message you need to switch. > So the Finished message is the first one using the new AUTH key. >> On server side, it should already have updated new key otherwise = it cannot process Finished message. But when server (after which packet = of DTLS handshake) will update its key ? > You should have installed it, but not made it the active one. = Therefore you can receive messages using it, but you don't use it = already for sending messages. >=20 > Please note the the dance related to the sender dry event is described = in section 4.7. >=20 > Best regards > Michael >>=20 >>=20 >>=20 >>=20 >> Regards, >> Shweta K R >> Tester =E2=80=93 VPP, 2012 LAB >>=20 >> Huawei Technologies India Pvt. Ltd. >> Survey No. 37, Next to EPIP Area, Kundalahalli, Whitefield Bengaluru,=20= >> Karnataka - 560066 >> Tel: + 91-80-49160700 Ext 71553 II Mob: 9986601255|| Email:=20 >> shwetakr@huawei.com >>=20 >>=20 >> -----Original Message----- >> From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] >> Sent: 21 June 2018 00:58 >> To: Shweta r >> Cc: tsvwg@ietf.org; Sharath Chandra B; Sidhartha pant; Ashutosh=20 >> prakash >> Subject: Re: [tsvwg] Query regarding random parameter in SCTP-AUTH = RFC=20 >> 4895 >>=20 >>=20 >>=20 >>> On 18. Jun 2018, at 07:07, Shweta r wrote: >>>=20 >>>=20 >>>=20 >>> Hi Michael, >>>=20 >>> Some more doubts. >>>=20 >>> 1) As per my understanding other than DATA & SACK chunks, remaining = are control chunks. Am I correct ? >> Only DATA chunks (specified in RFC 4960) and I-DATA (specified in RFC = 8260) are data chunks. All other chunks, including the SACK chunk, are = control chunks. >>>=20 >>> 2) As per , >>>=20 >>> 5.1. Authentication Chunk (AUTH) >>> The control chunk AUTH MUST NOT appear more than once in an SCTP >>> packet. All control and data chunks that are placed after the AUTH >>> chunk in the packet are sent in an authenticated way. Those chunks >>> placed in a packet before the AUTH chunk are not authenticated. >>> Please note that DATA chunks can not appear before control chunks = in >>> an SCTP packet. >>>=20 >>> --> As per this, AUTH need not be the first chunk in the packet. >>> ERROR+AUTH+DATA is valid combination where peer has asked for = only DATA authentication ? >> Yes, that is a valid packet. >>>=20 >>> 3) Endpoint has asked for only HB authentication.=20 >>> If it receives DATA+AUTH+HB which is not correct because DATA = cannot appear before control chunks, whole packet should be discarded. >>> What is your opinion? >> We don't require an implementation to pre-scan the packet before = processing it. So you can start with the first chunk, which is a DATA = chunk, and process it, since nothing is wrong with a DATA chunk being = the first chunk. >> When starting the process the AUTH chunk (or any other control = chunk), you detect that this packet is not valid. You can send an ABORT = (possibly indicating a protocol violation) and destroy the association. = This is what the FreeBSD implementation does... >>>=20 >>> 4) >>> 6. Procedures >>> 6.1. Establishment of an Association Shared Key >>>=20 >>> An SCTP endpoint has a list of chunks it only accepts if they are >>> received in an authenticated way. This list is included in the = INIT >>> and INIT-ACK, and MAY be omitted if it is empty. Since this list >>> does not change during the lifetime of the SCTP endpoint there is = no >>> problem in case of INIT collision. >>>=20 >>> SCTP Client SCTP Server >>> INIT ----> =20 >>> <---- INIT Ack >>> Cookie ---> >>> <--- cookie ack >>>=20 >>> Restart, send INIT---> >>>=20 >>> --> During restart all the (random, chunklist, HMAC algo) should be = same in INIT chunk ? what should be the behavior if INIT is received = with different AUTH params ? >> A restart normally means that the client lost its state completely = (like a system rebooted) so the parameters might not be the same. This = is not a collision case... >>=20 >> Best regards >> Michael >>>=20 >>>=20 >>> Regards, >>> Shweta K R >>> Tester =E2=80=93 VPP, 2012 LAB >>>=20 >>>=20 >>> Huawei Technologies India Pvt. Ltd. >>> Survey No. 37, Next to EPIP Area, Kundalahalli, Whitefield=20 >>> Bengaluru, Karnataka - 560066 >>> Tel: + 91-80-49160700 Ext 71553 II Mob: 9986601255|| Email: >>> shwetakr@huawei.com >>>=20 >>> -----Original Message----- >>> From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] >>> Sent: 10 June 2018 04:50 >>> To: Shweta r >>> Cc: tsvwg@ietf.org; Sharath Chandra B; Sidhartha pant; Ashutosh=20 >>> prakash >>> Subject: Re: [tsvwg] Query regarding random parameter in SCTP-AUTH=20= >>> RFC >>> 4895 >>>=20 >>>> On 9. Jun 2018, at 16:06, Shweta r wrote: >>>>=20 >>>> Hi Michael, >>>>=20 >>>> I have another doubt regarding HMAC algorithm selection. >>>>=20 >>>> RFC 4895:=20 >>>> section 6.1. Establishment of an Association Shared Key >>>>=20 >>>> Each SCTP endpoint MUST include in the INIT and INIT-ACK a=20 >>>> HMAC-ALGO parameter containing a list of HMAC Identifiers it=20 >>>> requests the peer to use. The receiver of an HMAC-ALGO parameter=20= >>>> SHOULD use the first listed algorithm it supports. The HMAC=20 >>>> algorithm based on SHA-1 MUST be supported and included in the = HMAC-ALGO parameter. >>>>=20 >>>> Section 6.3. Receiving Authenticated Chunks >>>>=20 >>>> The receiver MUST use the HMAC algorithm indicated in the HMAC=20 >>>> Identifier field. If this algorithm was not specified by the=20 >>>> receiver in the HMAC-ALGO parameter in the INIT or INIT-ACK chunk=20= >>>> during association setup, the AUTH chunk and all the chunks after=20= >>>> it MUST be discarded and an ERROR chunk SHOULD be sent with the=20 >>>> error cause defined in Section 4.1. >>>>=20 >>>> ------> SCTP Client = SCTP Server >>>> INIT send with (SHA-256, SHA-1) ----> =20 >>>> <---- INIT Ack = ( SHA-256, SHA-1) >>>> Cookie ---> >>>> <--- cookie ack >>>>=20 >>>> <--- sends DATA =20 >>>> with AUTH chunk HMAC Identifier=3D SHA-256 >>>>=20 >>>> Send SACK with AUTH chunk hmac id =3D SHA-1 ----> >>>>=20 >>>> DATA & SACK processing should be success , this is my = understanding. What is your opinion? >>> Correct. >>>>=20 >>>>=20 >>>>=20 >>>> ------> SCTP Client = SCTP Server >>>> INIT send with (SHA-1, SHA-256) ----> =20 >>>> <---- INIT Ack = (SHA-1, SHA-256) >>>> Cookie ---> >>>> <--- cookie ack >>>>=20 >>>> <--- sends DATA =20 >>>> with AUTH chunk HMAC Identifier=3D SHA-256 >>>>=20 >>>> Send SACK with AUTH chunk hmac id =3D SHA-256 ----> >>>>=20 >>>> DATA & SACK processing should be success , this is my = understanding. What is your opinion? >>> Correct. >>>>=20 >>>>=20 >>>> I got this doubt because in RFC its given " The receiver MUST use = the HMAC algorithm indicated in the HMAC Identifier field." >>> What is meant is that if the receiver of an auth chunk must use the = HMAC algorithm given in the HMAC Identifier field of the AUTH chunk as = long as it is acceptable by the receiver. >>>=20 >>> Best regards >>> Michael >>>>=20 >>>>=20 >>>> Regards, >>>> Shweta K R >>>> Tester =E2=80=93 VPP, 2012 LAB >>>>=20 >>>> Huawei Technologies India Pvt. Ltd. >>>> Survey No. 37, Next to EPIP Area, Kundalahalli, Whitefield=20 >>>> Bengaluru, Karnataka - 560066 >>>> Tel: + 91-80-49160700 Ext 71553 II Mob: 9986601255|| Email: >>>> shwetakr@huawei.com >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] >>>> Sent: 07 June 2018 00:24 >>>> To: Shweta r >>>> Cc: tsvwg@ietf.org; Sharath Chandra B; Sidhartha pant; Ashutosh=20 >>>> prakash >>>> Subject: Re: [tsvwg] Query regarding random parameter in SCTP-AUTH=20= >>>> RFC >>>> 4895 >>>>=20 >>>>> On 5. Jun 2018, at 02:35, Shweta r wrote: >>>>>=20 >>>>> Hi Group, >>>>>=20 >>>>> Greetings. I have a doubt regarding SCTP RFC 4895. >>>>>=20 >>>>> 1) section =E2=80=9C3.1. Random Parameter (RANDOM)=E2=80=9D. >>>>>=20 >>>>> Random Number: n bytes (unsigned integer) >>>>> This value represents an arbitrary Random Number in network = byte order. >>>>>=20 >>>>> Section 6.1. Establishment of an Association Shared Key >>>>>=20 >>>>> An SCTP endpoint willing to receive or send authenticated chunks = MUST >>>>> send one RANDOM parameter in its INIT or INIT-ACK chunk. The = RANDOM >>>>> parameter MUST contain a 32-byte Random Number. >>>>>=20 >>>>> ----> The random of size 32 bytes should be in network byte order = means 32bytes is divided into 4 bytes partition (totally 8 partitions) = and then ntohl is done for each partition ? >>>> No. It is just a number of 32 bytes and is stored in big enadian. >>>>>=20 >>>>> 2) Peer has asked for HB authentication. >>>>> In the scenario of sending HB to unconfirmed address, is it = correct to bundle AUTH+HB and send to unconfirmed address ? >>>>> My doubt here is can AUTH be sent to unconfirmed address ? >>>> Yes. If the peer requires HEARTBEAT chunks to be authenticated, the = end-point has to sent them authenticated. It does not matter whether the = HERTBEATs are used for path confirmation or not. >>>>>=20 >>>>> 3) In 4985, it is given, >>>>>=20 >>>>> >>>>>=20 >>>>> Local (auth support) = Peer (Auth not support) >>>>>=20 >>>>> Send INIT with auth para and chunklist(DATA) --> =20 >>>>> = <----- sends INIT-ACK without auth parameters (as per above section, = Peer ignore auth parameter received in INIT and sends INIT-ACK) >>>>> Cookie echo ---> >>>>> = <---- cookie ack >>>>>=20 >>>>> Association = established. >>>>> = <---- sends DATA without AUTH chunk >>>>>=20 >>>>> Local should send SACK or discard the DATA as it does not have = AUTH ? >>>> After thinking about it and discussing it with Peter Lei, the local = node must drop the DATA chunk. >>>>>=20 >>>>> 4) 6.1. Establishment of an Association Shared Key >>>>>=20 >>>>> The concatenation is performed on byte vectors, and all=20 >>>>> numerical comparisons use network byte order to convert the key = vectors to a number. >>>>>=20 >>>>> ---->Can you please explain about how to convert key vector to a = number and what should be the size of this number. >>>> The point is to compare the byte vector from the most significant = byte to the lowest. >>>> That is why you need to know the byte ordering. >>>>>=20 >>>>> 5) What should be the length of Association Shared Key ? = (As per RFC 2104 , the key can be of any length upto 64 bytes) >>>> It can be arbitrarily long. See >>>> https://tools.ietf.org/html/rfc6458#section-8.3.3 >>>> for an API. Please note the in the case of DTLS/SCTP it is 64 bytes=20= >>>> as specified in >>>> https://tools.ietf.org/html/rfc6083#section-4.8 >>>>>=20 >>>>> 6) For client SHA-1 most preferable=20 >>>>> For server SHA-256 most preferable >>>>>=20 >>>>>=20 >>>>> SCTP Client SCTP = Server >>>>> INIT send with (SHA-1, SHA-256) ----> >>>>> <---- INIT Ack = ( SHA-256, SHA-1) >>>>> Cookie ---> >>>>> <--- cookie ack >>>>>=20 >>>>> <--- sends DATA=20= >>>>> with AUTH chunk HMAC Identifier=3D SHA-1 >>>>>=20 >>>>> Send SACK with AUTH chunk hmac id =3D SHA-256 ----> >>>>>=20 >>>>> DATA & SACK processing should be success , this is my = understanding. >>>>>=20 >>>>> What is your opinion? =20 >>>> I agree. >>>>=20 >>>> Please let us know if you have further questions. >>>>=20 >>>> Best regards >>>> Michael >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Regards, >>>>> Shweta K R >>>>> Tester =E2=80=93 VPP, 2012 LAB >>>>>=20 >>>>> Huawei Technologies India Pvt. Ltd. >>>>> Survey No. 37, Next to EPIP Area, Kundalahalli, Whitefield=20 >>>>> Bengaluru, Karnataka - 560066 >>>>> Tel: + 91-80-49160700 Ext 71553 II Mob: 9986601255|| Email: >>>>> shwetakr@huawei.com >>>>=20 >>>=20 >=20 From nobody Mon Jul 16 11:47:43 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE877130E62; Mon, 16 Jul 2018 11:47:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tsvwg@ietf.org Message-ID: <153176685386.21857.1374404301055798835@ietfa.amsl.com> Date: Mon, 16 Jul 2018 11:47:33 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rfc4960-errata-07.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 18:47:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : RFC 4960 Errata and Issues Authors : Randall R. Stewart Michael Tuexen Maksim Proshin Filename : draft-ietf-tsvwg-rfc4960-errata-07.txt Pages : 89 Date : 2018-07-16 Abstract: This document is a compilation of issues found since the publication of RFC4960 in September 2007 based on experience with implementing, testing, and using SCTP along with the suggested fixes. This document provides deltas to RFC4960 and is organized in a time ordered way. The issues are listed in the order they were brought up. Because some text is changed several times the last delta in the text is the one which should be applied. In addition to the delta a description of the problem and the details of the solution are also provided. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-errata/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-07 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc4960-errata-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc4960-errata-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 Wed Jul 18 07:46:13 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 180D6130EC0 for ; Wed, 18 Jul 2018 07:46:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153192516009.2939.7651701005484843375.idtracker@ietfa.amsl.com> Date: Wed, 18 Jul 2018 07:46:00 -0700 From: IETF Secretariat Archived-At: Subject: [tsvwg] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 14:46:05 -0000 Changed milestone "Submit 'Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim' as a Proposed Standard RFC", set due date to June 2018 from January 2018. Changed milestone "Submit 'Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP' as a BCP RFC", set due date to June 2018 from October 2018. Changed milestone "Submit 'SCTP NAT Support' to IESG for consideration as a PS RFC", set due date to October 2018 from May 2018. URL: https://datatracker.ietf.org/wg/tsvwg/about/ From nobody Wed Jul 18 08:49:01 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4316E13118F for ; Wed, 18 Jul 2018 08:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=UGR+W2az; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=bn+m+AL8 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 cLIHJlTFV3DC for ; Wed, 18 Jul 2018 08:48:57 -0700 (PDT) Received: from esa6.dell-outbound.iphmx.com (esa6.dell-outbound.iphmx.com [68.232.149.229]) (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 9EBEE130E14 for ; Wed, 18 Jul 2018 08:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1531928937; x=1563464937; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Fk6QAKhiaUtE463wbgFqa3PJ7+q+2ElGLg25InWsRtc=; b=UGR+W2azOWS7Pav+CposEOI+Wgm/4Nbwbq/YZc9AYyQAXskH+MxTXLDx IaAFXDtN9+iAZ0vjU4PO9nC6zzwjQ83ViyR2FHKjma7sHTvR05oDfDWtq MwVcjsbZ3KP2WY1krArbUi+BAlnYbPFOpcGc6mTthxVi0yt4LIUfxduY9 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2HqAgDoXU9bmGKa6ERcHgEGDIJ1gTd/K?= =?us-ascii?q?AqDdJQwggyDOJIBgT87CyMLhD4CF4JjITQYAQIBAQIBAQIBAQIQAQEBAQEICws?= =?us-ascii?q?GKSMBC4I1IhFLLwgzAQEBAQEBAQEBAQEBAQEBAQEBFwJDARIaAQEBBCMRDB8bC?= =?us-ascii?q?wQCAQgRBAEBAwIGHQMCAgIwFAEICAIEEwiDGAGBfwEOqVeBLoJ4h0kDBYELh3e?= =?us-ascii?q?BWD6BEYMRgxkBAQOBOiUVgmoxgiSZYgMEAgKGCJcDijuHNQIEAgQFAhSBQYILc?= =?us-ascii?q?IMFATOCM4NOhRSFPm+LeoEaAQE?= X-IPAS-Result: =?us-ascii?q?A2HqAgDoXU9bmGKa6ERcHgEGDIJ1gTd/KAqDdJQwggyDOJI?= =?us-ascii?q?BgT87CyMLhD4CF4JjITQYAQIBAQIBAQIBAQIQAQEBAQEICwsGKSMBC4I1IhFLL?= =?us-ascii?q?wgzAQEBAQEBAQEBAQEBAQEBAQEBFwJDARIaAQEBBCMRDB8bCwQCAQgRBAEBAwI?= =?us-ascii?q?GHQMCAgIwFAEICAIEEwiDGAGBfwEOqVeBLoJ4h0kDBYELh3eBWD6BEYMRgxkBA?= =?us-ascii?q?QOBOiUVgmoxgiSZYgMEAgKGCJcDijuHNQIEAgQFAhSBQYILcIMFATOCM4NOhRS?= =?us-ascii?q?FPm+LeoEaAQE?= Received: from esa4.dell-outbound2.iphmx.com ([68.232.154.98]) by esa6.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jul 2018 10:48:55 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa4.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jul 2018 21:48:50 +0600 Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w6IFmnQZ030634 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 18 Jul 2018 11:48:50 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com w6IFmnQZ030634 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1531928930; bh=5OkWCaS8tdvbYxNI3iiVfnQz7xs=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=bn+m+AL8QCF1esFmy9nq2bM6w2BAv+GmEneKYIDf1YhrF2APNkAtqlsKkxKklAzt5 ezrDI6+9ljZhA8getIabM6SKk0XBs/G8BHLmXTai4BSWKSswTI/F3MmzWCbsyDTn48 RkyjL5gm6J2S+QNL8AWY0lTu7F43E578t2+sIugI= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com w6IFmnQZ030634 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd02.lss.emc.com (RSA Interceptor) for ; Wed, 18 Jul 2018 11:48:28 -0400 Received: from MXHUB303.corp.emc.com (MXHUB303.corp.emc.com [10.146.3.29]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w6IFmRdH026998 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL) for ; Wed, 18 Jul 2018 11:48:28 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB303.corp.emc.com ([10.146.3.29]) with mapi id 14.03.0399.000; Wed, 18 Jul 2018 11:48:26 -0400 To: "tsvwg@ietf.org" Thread-Topic: [tsvwg] Milestones changed for tsvwg WG Thread-Index: AQHUHqqYmiWTznU4f0aPDP6CMlAnm6SVIBFQ Date: Wed, 18 Jul 2018 15:48:26 +0000 Message-ID: References: <153192516009.2939.7651701005484843375.idtracker@ietfa.amsl.com> In-Reply-To: <153192516009.2939.7651701005484843375.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.105.8.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tsvwg] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 15:49:00 -0000 VGhpcyBpcyBjYXRjaGluZyB1cCB3aXRoIGFuZCBjb3JyZWN0aW5nIG1pbGVzdG9uZSBjaGFuZ2Vz IHRoYXQgd2VyZSBkaXNjdXNzZWQgaW4gTG9uZG9uIC4uLg0KDQpUaGFua3MsIC0tRGF2aWQNCg0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHRzdndnIFttYWlsdG86dHN2 d2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIElFVEYgU2VjcmV0YXJpYXQNCj4gU2Vu dDogV2VkbmVzZGF5LCBKdWx5IDE4LCAyMDE4IDEwOjQ2IEFNDQo+IFRvOiB0c3Z3Z0BpZXRmLm9y Zw0KPiBTdWJqZWN0OiBbdHN2d2ddIE1pbGVzdG9uZXMgY2hhbmdlZCBmb3IgdHN2d2cgV0cNCj4g DQo+IENoYW5nZWQgbWlsZXN0b25lICJTdWJtaXQgJ1Byb3BhZ2F0aW5nIEV4cGxpY2l0IENvbmdl c3Rpb24gTm90aWZpY2F0aW9uDQo+IEFjcm9zcyBJUCBUdW5uZWwgSGVhZGVycyBTZXBhcmF0ZWQg YnkgYSBTaGltJyBhcyBhIFByb3Bvc2VkIFN0YW5kYXJkIFJGQyIsDQo+IHNldCBkdWUgZGF0ZSB0 byBKdW5lIDIwMTggZnJvbSBKYW51YXJ5IDIwMTguDQo+IA0KPiBDaGFuZ2VkIG1pbGVzdG9uZSAi U3VibWl0ICdHdWlkZWxpbmVzIGZvciBBZGRpbmcgQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24gdG8N Cj4gUHJvdG9jb2xzIHRoYXQgRW5jYXBzdWxhdGUgSVAnIGFzIGEgQkNQIFJGQyIsIHNldCBkdWUg ZGF0ZSB0byBKdW5lIDIwMTggZnJvbQ0KPiBPY3RvYmVyIDIwMTguDQo+IA0KPiBDaGFuZ2VkIG1p bGVzdG9uZSAiU3VibWl0ICdTQ1RQIE5BVCBTdXBwb3J0JyB0byBJRVNHIGZvciBjb25zaWRlcmF0 aW9uIGFzIGENCj4gUFMgUkZDIiwgc2V0IGR1ZSBkYXRlIHRvIE9jdG9iZXIgMjAxOCBmcm9tIE1h eSAyMDE4Lg0KPiANCj4gVVJMOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL3Rzdndn L2Fib3V0Lw0KDQo= From nobody Wed Jul 18 09:03:41 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 259C3130EEE; Wed, 18 Jul 2018 09:03:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tsvwg@ietf.org Message-ID: <153192981506.2849.3859390728675290034@ietfa.amsl.com> Date: Wed, 18 Jul 2018 09:03:35 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-aqm-dualq-coupled-06.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 16:03:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput (L4S) Authors : Koen De Schepper Bob Briscoe Olga Bondarenko Ing-jyh Tsang Filename : draft-ietf-tsvwg-aqm-dualq-coupled-06.txt Pages : 38 Date : 2018-07-18 Abstract: Data Centre TCP (DCTCP) was designed to provide predictably low queuing latency, near-zero loss, and throughput scalability using explicit congestion notification (ECN) and an extremely simple marking behaviour on switches. However, DCTCP does not co-exist with existing TCP traffic---DCTCP is so aggressive that existing TCP algorithms approach starvation. So, until now, DCTCP could only be deployed where a clean-slate environment could be arranged, such as in private data centres. This specification defines `DualQ Coupled Active Queue Management (AQM)' to allow scalable congestion controls like DCTCP to safely co-exist with classic Internet traffic. The Coupled AQM ensures that a flow runs at about the same rate whether it uses DCTCP or TCP Reno/Cubic, but without inspecting transport layer flow identifiers. When tested in a residential broadband setting, DCTCP achieved sub-millisecond average queuing delay and zero congestion loss under a wide range of mixes of DCTCP and `Classic' broadband Internet traffic, without compromising the performance of the Classic traffic. The solution also reduces network complexity and eliminates network configuration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-aqm-dualq-coupled/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-06 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-aqm-dualq-coupled-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-aqm-dualq-coupled-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 Wed Jul 18 09:20:15 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910701311B7 for ; Wed, 18 Jul 2018 09:20:13 -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 BJR9IRa7b4GY for ; Wed, 18 Jul 2018 09:20:09 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9AB1311AC for ; Wed, 18 Jul 2018 09:20:08 -0700 (PDT) Received: from dhcp-8ea7.meeting.ietf.org (dhcp-8ea7.meeting.ietf.org [31.133.142.167]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id D99B91B000E5; Wed, 18 Jul 2018 17:20:02 +0100 (BST) Message-ID: <5B4F68A9.7050206@erg.abdn.ac.uk> Date: Wed, 18 Jul 2018 12:19:53 -0400 From: G Fairhurst 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: Michael Tuexen CC: Randall Stewart , mproshin@tieto.mera.ru, tsvwg WG References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tsvwg] draft-ietf-tsvwg-natsupp-12 -- comments on the draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 16:20:13 -0000 Thanks for this revision, but I still do have a number of concerns that I think need to be acted upon before a WGLC. The editors may like to address some/all of these before the IETF TSVWG meeting... If people have opinions please. Gorry --- I think the use of "NAPT" seems odd to me. I think in most cases the document is talking about adding NAPT functions (that I know of as an ALG) to support SCTP NAT traversal. --- I think this text is not quite correct: "This document describes an SCTP specific variant NAT and specific packets and procedures to help NATs provide similar features of NAPT in the single-point and multi-point traversal scenario. An SCTP implementation supporting this extension will follow these procedures to assure that in both single-homed and multi-homed cases a NAT will maintain the proper state without needing to change port numbers." I think this text may be a better start: " This document specifies procedures allow a NAT to support SCTP by providing similar features to those provided by a NAPT for TCP and other supported protocols " The document also specifies a set of data formats for SCTP packets and a set of SCTP endpoint procedures to support NAT traversal. An SCTP implementation supporting these procedures can assure that in both single-homed and multi-homed cases a NAT will maintain the proper state without needing to change port numbers." --- There are several text note that say something like: ' [NOTE: ASSIGNMENT OF M-BIT TO BE CONFIRMED BY IANA. ]" (I do not understand from that *what* you wish the RFC-ED to insert here. I think we want the RFC-ED to remove this commnent, and if we keep thois, we should say so.) Actually, I really do we need to actually retain the comment now, as we move to WGLC - could we just remove? --- Nits: "NAT box" to "NAT device" "NAT which has" to ""NAT that has" "can't" to "is unable to" (or similar) "i. e." to "i.e." - is "end point" one word? --- To me, NAPT includes port translation of the IP payload, and NAT only changes IP addresses. Is this your interpretation, and has this been used consistently? --- I am unclear what is intended by the para with this statement: "When considering this feature it is possible to have multiple levels of support. " - This para needs to be rewritten, does the table refer to support of the new mechanisms in this document? or do I misunderstand? are the features just what is described in one of the sections, or something else. I was pretty confused. What does this mean: "This is because for the most part of the current situation". - what situation? --- "This document uses the following terms" - I think this should also use the terms defined by the IETF BEHAVE work. Please be consistent with these and say so in the terminology. --- I am not a huge fan of a construct that uses MUST followed by a bullet list, as in: "The endpoint MUST do the following:" - I would strongly advise you to use "MUST" instead in each individual bullet, so that the requirement is clear. --- The meaning of this requirement appears ambiguous: "if it does not discard the incoming ERROR chunk." If I understamd this, you could write: "if the NAT device does not discard the incoming ERROR chunk, then the server MUST validate that the peer of the SCTP association supports the dynamic address extension". --- Section 4.1 and 4.2 - I think (maybe I am wrong) this is all background? and therefore could be subsections of section 1? --- The english in section 4 reads like a paper, there are many loose terms here, that need to be tightened. e.g. (but please check the entire text): "Furthermore we are focusing in this section on the single point traversal scenario." - who is we, and what does this mean? "The modification of SCTP packets sent to the public Internet is easy." - what does that mean? "It may also be necessary to establish some state in the NAT box to handle incoming packets, which is discussed later."? --- Section 4.3 needs to be renamed to align with BEHAVE terms. --- There are several examples of requirements that do not say how to realise them, this is a problem. I suspect we could simply be missing cross-references to the SCTP base spec to tell the NAT implementer where the appropriate method is defined. "A NAT box MUST support IP reassembly of received fragmented SCTP packets." --- Section 6.6 is inherently IPv4, and I think thoought is needed to help avoid silly review comments: "Handling of Fragmented SCTP Packets" to "Handling ofFragmented SCTP Packets" >> Is there an RFC that decsribes in-network reassembly of IPv4 fragments? >> If you allow this, then you place requirements on all IP fragments passing through this NAT, that you should state. >> You also need to discuss timer actions, MSL, etc. >> How do you deal with fragments that set "DF"? >> Do you propose or not to re-assemble IPv6 fragments? >> There are also security issues in performing reassembly! After all this, I really wonder if this is a GOOD thing to include in the NAT function. Can you justify why this is an important function? ------------ Please rephrase this: "The suggested value for the T bit is 0x01 and for the M bit is 0x02." as something like: "IANA is requested to assign the value of 0x01 for theT bit and the value of 0x02 for theM bit." --- Please rephrase this (multiple): "It is suggested to use the values given below." as "IANA is requested to assign the following values:" --- "More than one host behind a NAT may pick". - could this be. "Multiple endpoints behind a NAT device could use" --- Why is there a section 6.1 subsection, this text seems to belong in section 6 as an overview of everything in section 6? --- Section 6.2 - I retain my comment that I think this section should differentiate NAT and endpoint actions. In this case it should somehow be labeled as an endpoint mechanism. e.g., "Considerations when an endpoint sets up an SCTP association" --- In section 6.2, there are a set of requirements: e.g, "Every association MUST initially be set up single-homed." , etc, etc. I am unclear. Are these changes to the base spec, or clarifications of what the base spec says, either way I would not feel comfortable without some sort of reference back to the base spec. --- I think the first part of section 6.3 refers to what NATs provide, I think you need to make a subsection title including "NAT" and place the first part in this. e.g. "6.3.1 NAT Handling of Internal Port Number and VTAG Collisions" I think the last 3 para of section 6.3 refers to what NATs provide, I think you need to make a subsection title including "NAT" and place the first part in this. "6.3.2 SCTP Endpoint Handling of Internal Port Number and VTAG Collisions" --- I really think that section 6.4 can and should also be sub-divided in the same way. --- I really think that section 6.5 can and should also be sub-divided in the same way. --- In section 6.5, this also states: "Upon reception of this ERROR chunk by an SCTP endpoint the receiver SHOULD take the following actions" - what happens if it does not? (please say). --- Section 6.6 is clearly just "NAT" ? - if I understand, can this be added to the title? --- Section 6.7 is clearly just "SCTP Endpoint" ? - if I understand, can this be added to the title? --- From nobody Wed Jul 18 13:01:33 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67E5130FDF for ; Wed, 18 Jul 2018 13:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lETpdxtLh8st for ; Wed, 18 Jul 2018 13:01:28 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8217B130FF8 for ; Wed, 18 Jul 2018 13:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:Cc:From:References:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=t+cu80WS3IHxmOtutSZvAxzuHYzY7umQWqx0AsIB4rU=; b=RPx5cRoQIKFXXTrEfWX+bJXNk bxCk5J9lgbNXQnnJFYpcYjlR+pSf25+CUkaPqo29hLajB/H2rchc1fwycHhDyJ/ucwc7YXnpTPl/M I2ZEeN5pwPSl0CmPPXHUs/d5ywxISx8Uk6qo6BV22iLkkzko17zaqkSHqQE0EySaWd9oM+4XWjoAD 4GqHbbrCi8CZCumCk95Z5VRcH837BM4YMJWP2zbgI3yquEDl0l366i9/yalodsNWrT/IqN6/TtAuV BF5TFTsAWS1FhiwSB86pnBSq2j33PFNUK3Rn+zClwReA1sK8KaOLyoGxP/EFX8jdre856GbglYtqJ Ldxi2M6ew==; Received: from dhcp-80b8.meeting.ietf.org ([31.133.128.184]:59312) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1ffsda-00049O-L1; Wed, 18 Jul 2018 21:01:26 +0100 To: "Black, David" References: From: Bob Briscoe Cc: "tsvwg@ietf.org" Message-ID: <91009949-5c63-e7f5-49b1-54d029f2b1e6@bobbriscoe.net> Date: Wed, 18 Jul 2018 16:01:24 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1B6CEA902614C1FE509AB0FC" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tsvwg] L4S & Diffserv - incremental deployment X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 20:01:31 -0000 This is a multi-part message in MIME format. --------------1B6CEA902614C1FE509AB0FC Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit David, Thanks for taking the time to read and comment... On 13/07/18 12:48, Black, David wrote: > > > > Bob, > > Regarding draft-briscoe-tsvwg-l4s-diffserv, writing as an individual, > not as a WG chair. > > The draft currently seems to focus on the end-state of full deployment > of L4S with Diffserv. Im also interested in enabling incremental > deployment of L4S - being able to enable/disable L4S based on DSCP > value looks like a promising mechanism for that. Towards that end, > the examples in Section 4 dont seem to cover all of the possibilities > in a partial deployment of L4S, where its use/non-use is controlled by > DSCP. > I'm also primarily interested in enabling early use of L4S with Diffserv, while hosts are starting to deploy scalable congestion controls that can use ECT(1). That's what Table 1 is about, and the text around it in section 3. Low Latency Diffserv Classes within a DualQ Bandwidth Pool . As you can see, EF is identified as the most likely DSCP that existing 'non-queue-building' apps could use to get into the low latency queue (e.g. a low-rate stream of sync datagrams for an online game). Is there something I've done wrong that didn't allow you to see why this section was what you wanted to read. I didn't want to explicitly talk about an incremental deployment roadmap for L4S, cos the RFC series is meant to be timeless. > Section 6 could benefit from some related thought and editing: > > - Section 6.1: The guidance on not remarking DSCPs is scoped to L4S > functionality. Obviously, Diffserv can and does remark DSCPs, so the > advice should be that only Diffserv functionality remarks DSCPs, not L4S. > We'll certainly make that clear. > - Section 6.2: This seems to be entirely about implementation, > including what to do on current hardware. Id like to see a > statement that at the protocol specification level, Diffserv > classification SHOULD precede ECN classification in order to enable > L4S enable/disable on a per-DSCP basis, with the full 8-bit (DSCP + > ECN) classifier being a possible implementation and constraints of > existing hardware (cant do that) being a possible reason to not > follow the SHOULD. > We've had long email discussion on this before. I'm going to find you in a corridor to understand why we're talking past each other on this. Bob > > > Thanks, --David > > ---------------------------------------------------------------- > > David L. Black, Distinguished Engineer > > Dell EMC, 176 South St., Hopkinton, MA 01748 > > +1 (508) 293-7953 Mobile: +1 (978) 394-7754 > > David.Black@dell.com > > ---------------------------------------------------------------- > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------1B6CEA902614C1FE509AB0FC Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit David,

Thanks for taking the time to read and comment...

On 13/07/18 12:48, Black, David wrote:

<WG_Chair_Hat=OFF>

Bob,

Regarding draft-briscoe-tsvwg-l4s-diffserv, writing as an individual, not as a WG chair.

The draft currently seems to focus on the end-state of full deployment of L4S with Diffserv. Im also interested in enabling incremental deployment of L4S - being able to enable/disable L4S based on DSCP value looks like a promising mechanism for that. Towards that end, the examples in Section 4 dont seem to cover all of the possibilities in a partial deployment of L4S, where its use/non-use is controlled by DSCP.

I'm also primarily interested in enabling early use of L4S with Diffserv, while hosts are starting to deploy scalable congestion controls that can use ECT(1). That's what Table 1 is about, and the text around it in section 3. Low Latency Diffserv Classes within a DualQ Bandwidth Pool.

As you can see, EF is identified as the most likely DSCP that existing 'non-queue-building' apps could use to get into the low latency queue (e.g. a low-rate stream of sync datagrams for an online game).

Is there something I've done wrong that didn't allow you to see why this section was what you wanted to read.
I didn't want to explicitly talk about an incremental deployment roadmap for L4S, cos the RFC series is meant to be timeless.

Section 6 could benefit from some related thought and editing:

- Section 6.1: The guidance on not remarking DSCPs is scoped to L4S functionality. Obviously, Diffserv can and does remark DSCPs, so the advice should be that only Diffserv functionality remarks DSCPs, not L4S.

We'll certainly make that clear.

- Section 6.2: This seems to be entirely about implementation, including what to do on current hardware. Id like to see a statement that at the protocol specification level, Diffserv classification SHOULD precede ECN classification in order to enable L4S enable/disable on a per-DSCP basis, with the full 8-bit (DSCP + ECN) classifier being a possible implementation and constraints of existing hardware (cant do that) being a possible reason to not follow the SHOULD.

We've had long email discussion on this before. I'm going to find you in a corridor to understand why we're talking past each other on this.


Bob

</WG_Chair_Hat=OFF>

Thanks, --David

----------------------------------------------------------------

David L. Black, Distinguished Engineer

Dell EMC, 176 South St., Hopkinton, MA 01748

+1 (508) 293-7953 Mobile: +1 (978) 394-7754

David.Black@dell.com

----------------------------------------------------------------


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------1B6CEA902614C1FE509AB0FC-- From nobody Wed Jul 18 17:14:11 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D985E131209 for ; Wed, 18 Jul 2018 17:14:08 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=0zSFy9Mk; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=J4f/6UJn 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 sl0_NK3d1-on for ; Wed, 18 Jul 2018 17:14:05 -0700 (PDT) Received: from esa7.dell-outbound.iphmx.com (esa7.dell-outbound.iphmx.com [68.232.153.96]) (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 9B9E51310D1 for ; Wed, 18 Jul 2018 17:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1531958842; x=1563494842; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UU+Ap4QlE2A9LJXggooVCC5AasgW9flRC3gIyVNy2do=; b=0zSFy9MkBj8rcO0Ct29Z3gA+/gufNL/zAzK7ZtfkU7e7C8VDYwihX4wi uFAnNo4Hzt+QcZr5UVtHIjbr447YoGXwNeOotIzsml1xiSSlKiE+tj64s PYPgZlF2Jv3ZHWqgQKOtKQy5Zd5U0ytiWvWsEeb+oHQO/LVD0ZqsHcIB2 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2F+AABp109bh8qZ6ERZAxwBAQEEAQEKA?= =?us-ascii?q?QGCUyKBN38oCoRWfYYljCyCDIJ7kj4UgSsXJAslCYMHgTcCgnohNBgBAgEBAgE?= =?us-ascii?q?BAgEBAhABAQEKCwkIKSMMgjUiEUsvCDIBAQEBAQEBAQEBAQEBAQEBAQEBFwI5C?= =?us-ascii?q?gESAQEYAQEBAQMtEx8aAQ8CAQgOAwQBAQsdBzIUCQgBAQQOBQiDGAGBG2QBDqs?= =?us-ascii?q?eH4JZh0kIh2uBF4FYPoQigxkBAQIBgSoBEgEhDBMMCQgJgmuCJIdqbJEMAwQCA?= =?us-ascii?q?oYIgmSHfUOGO4UkijuEToJnAgQCBAUCFIFBgRpxcFCCaQmCKoJHgQeEWTuFPm8?= =?us-ascii?q?wiHKBH4EaAQE?= X-IPAS-Result: =?us-ascii?q?A2F+AABp109bh8qZ6ERZAxwBAQEEAQEKAQGCUyKBN38oCoR?= =?us-ascii?q?WfYYljCyCDIJ7kj4UgSsXJAslCYMHgTcCgnohNBgBAgEBAgEBAgEBAhABAQEKC?= =?us-ascii?q?wkIKSMMgjUiEUsvCDIBAQEBAQEBAQEBAQEBAQEBAQEBFwI5CgESAQEYAQEBAQM?= =?us-ascii?q?tEx8aAQ8CAQgOAwQBAQsdBzIUCQgBAQQOBQiDGAGBG2QBDqseH4JZh0kIh2uBF?= =?us-ascii?q?4FYPoQigxkBAQIBgSoBEgEhDBMMCQgJgmuCJIdqbJEMAwQCAoYIgmSHfUOGO4U?= =?us-ascii?q?kijuEToJnAgQCBAUCFIFBgRpxcFCCaQmCKoJHgQeEWTuFPm8wiHKBH4EaAQE?= Received: from esa2.dell-outbound2.iphmx.com ([68.232.153.202]) by esa7.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jul 2018 19:07:04 -0500 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa2.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jul 2018 06:04:46 +0600 Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w6J0DfZW016792 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 18 Jul 2018 20:13:41 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com w6J0DfZW016792 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1531959222; bh=F5lkUuHGYqeE29E5WXJpvBFE3AQ=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=J4f/6UJnbnfCxBmNbdZWhou/MI6PYCjxmygu2mrsVvpPu7yFMf53c0UYyBuy4iVU2 aba/leNL7gP3pPjlE2pLnfBi9djOiJR2MnndAjFUgQaPgwHDyNWTcYtfmMaHQpjmp8 bbaN7a8MJx4+4lyO+oUZDPLay3+R8q0sUiWkh2XQ= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com w6J0DfZW016792 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd54.lss.emc.com (RSA Interceptor); Wed, 18 Jul 2018 20:13:21 -0400 Received: from MXHUB318.corp.emc.com (MXHUB318.corp.emc.com [10.146.3.96]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w6J0DLdd026760 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 18 Jul 2018 20:13:22 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB318.corp.emc.com ([10.146.3.96]) with mapi id 14.03.0399.000; Wed, 18 Jul 2018 20:13:21 -0400 To: Bob Briscoe CC: "tsvwg@ietf.org" Thread-Topic: [tsvwg] L4S & Diffserv - incremental deployment Thread-Index: AdQayWD5mHxkCBVIQLaRR7tvOOYenwEKkDEAAAASprA= Date: Thu, 19 Jul 2018 00:13:20 +0000 Message-ID: References: <91009949-5c63-e7f5-49b1-54d029f2b1e6@bobbriscoe.net> In-Reply-To: <91009949-5c63-e7f5-49b1-54d029f2b1e6@bobbriscoe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.105.8.135] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D24327794936301E1D1BMX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tsvwg] L4S & Diffserv - incremental deployment X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 00:14:09 -0000 --_000_CE03DB3D7B45C245BCA0D24327794936301E1D1BMX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bob, It sounds like we don't have a fundamental disagreement. That's good - I = should reread the draft and propose some small text changes that would addr= ess my concern, which is reflected in both the overall comment on Section 4= and the specific comment on Section 6.2. What I'm looking for is roughly: * By itself, use of ECT(1) is not sufficient to cause traffic to use= the L4S Queue in a Dual Queue AQM. * The network operator can enable or disable L4S Queue usage for ECT= (1)-marked traffic on a DSCP-by-DSCP basis. The above bullets are oversimplified in that they're easy to mis-read as im= plying that there is one L4S Queue - there may be more than one, e.g., as i= ndicated by Figure 2 in the draft. I can't promise that I'll be able to reread the draft and propose text befo= re the TSVWG meeting tomorrow, but I will put it on my "To Do" list ... Thanks, --David From: Bob Briscoe [mailto:ietf@bobbriscoe.net] Sent: Wednesday, July 18, 2018 4:01 PM To: Black, David Cc: tsvwg@ietf.org Subject: Re: [tsvwg] L4S & Diffserv - incremental deployment David, Thanks for taking the time to read and comment... On 13/07/18 12:48, Black, David wrote: Bob, Regarding draft-briscoe-tsvwg-l4s-diffserv, writing as an individual, not a= s a WG chair. The draft currently seems to focus on the end-state of full deployment of L= 4S with Diffserv. I'm also interested in enabling incremental deployment o= f L4S - being able to enable/disable L4S based on DSCP value looks like a p= romising mechanism for that. Towards that end, the examples in Section 4 d= on't seem to cover all of the possibilities in a partial deployment of L4S,= where its use/non-use is controlled by DSCP. I'm also primarily interested in enabling early use of L4S with Diffserv, w= hile hosts are starting to deploy scalable congestion controls that can use= ECT(1). That's what Table 1 is about, and the text around it in section 3.= Low Latency Diffserv Classes within a DualQ Bandwidth Pool. As you can see, EF is identified as the most likely DSCP that existing 'non= -queue-building' apps could use to get into the low latency queue (e.g. a l= ow-rate stream of sync datagrams for an online game). Is there something I've done wrong that didn't allow you to see why this se= ction was what you wanted to read. I didn't want to explicitly talk about an incremental deployment roadmap fo= r L4S, cos the RFC series is meant to be timeless. Section 6 could benefit from some related thought and editing: - Section 6.1: The guidance on not remarking DSCPs is scoped to L4S functio= nality. Obviously, Diffserv can and does remark DSCPs, so the advice shoul= d be that only Diffserv functionality remarks DSCPs, not L4S. We'll certainly make that clear. - Section 6.2: This seems to be entirely about implementation, including wh= at to do on current hardware. I'd like to see a statement that at the pro= tocol specification level, Diffserv classification SHOULD precede ECN class= ification in order to enable L4S enable/disable on a per-DSCP basis, with t= he full 8-bit (DSCP + ECN) classifier being a possible implementation and c= onstraints of existing hardware (can't do that) being a possible reason to = not follow the SHOULD. We've had long email discussion on this before. I'm going to find you in a = corridor to understand why we're talking past each other on this. Bob Thanks, --David ---------------------------------------------------------------- David L. Black, Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 Mobile: +1 (978) 394-7754 David.Black@dell.com ---------------------------------------------------------------- -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --_000_CE03DB3D7B45C245BCA0D24327794936301E1D1BMX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bob,

 

It sounds like we don&= #8217;t have a fundamental disagreement.   That’s good - I = should reread the draft and propose some small text changes that would addr= ess my concern, which is reflected in both the overall comment on Section 4 and the specific comment on Section 6.2.

 

What I’m looking= for is roughly:

·        By itself, use= of ECT(1) is not sufficient to cause traffic to use the L4S Queue in a Dua= l Queue AQM.

·        The network op= erator can enable or disable L4S Queue usage for ECT(1)-marked traffic on a= DSCP-by-DSCP basis.

The above bullets are = oversimplified in that they’re easy to mis-read as implying that ther= e is one L4S Queue – there may be more than one, e.g., as indicated b= y Figure 2 in the draft.

 

I can’t promise = that I’ll be able to reread the draft and propose text before the TSV= WG meeting tomorrow, but I will put it on my “To Do” list ̷= 0;

 

Thanks, --David

 

From:= Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: Wednesday, July 18, 2018 4:01 PM
To: Black, David
Cc: tsvwg@ietf.org
Subject: Re: [tsvwg] L4S & Diffserv - incremental deployment

 

David,

Thanks for taking the time to read and comment...

On 13/07/18 12:48, Black, David wrote:

<WG_Chair_Hat=3DOFF>

 

Bob,

 

Regarding draft-briscoe-tsvwg-l4s-diffserv, writing = as an individual, not as a WG chair.

 

The draft currently seems to focus on the end-state = of full deployment of L4S with Diffserv.  I’m also interested in= enabling incremental deployment of L4S - being able to enable/disable L4S = based on DSCP value looks like a promising mechanism for that.  Towards that end, the examples in Section 4 don’t se= em to cover all of the possibilities in a partial deployment of L4S, where = its use/non-use is controlled by DSCP.

I'm also primarily interested in enabling early = use of L4S with Diffserv, while hosts are starting to deploy scalable conge= stion controls that can use ECT(1). That's what Table 1 is about, and the text around it in section 3.  Low Latency Diffserv Classes within a DualQ Bandwidth Pool.
As you can see, EF is identified as the most likely DSCP that existing 'non= -queue-building' apps could use to get into the low latency queue (e.g. a l= ow-rate stream of sync datagrams for an online game).

Is there something I've done wrong that didn't allow you to see why this se= ction was what you wanted to read.
I didn't want to explicitly talk about an incremental deployment roadmap fo= r L4S, cos the RFC series is meant to be timeless.


 

Section 6 could benefit from some related thought an= d editing:

 

- Section 6.1: The guidance on not remarking DSCPs i= s scoped to L4S functionality.  Obviously, Diffserv can and does remar= k DSCPs, so the advice should be that only Diffserv functionality remarks D= SCPs, not L4S.

We'll certainly make that clear.


 

- Section 6.2: This seems to be entirely about imple= mentation, including what to do on current hardware.   I’d = like to see a statement that at the protocol specification level, Diffserv = classification SHOULD precede ECN classification in order to enable L4S enable/disable on a per-DSCP basis, with the full 8-bi= t (DSCP + ECN) classifier being a possible implementation and constrain= ts of existing hardware (can’t do that) being a possible reason to no= t follow the SHOULD.

We've had long email discussion on this before. = I'm going to find you in a corridor to understand why we're talking past ea= ch other on this.


Bob


 

</WG_Chair_Hat=3DOFF>

 

Thanks, --David

----------------------------------------------------= ------------

David L. Black, Distinguished Engineer

Dell EMC, 176 South St., Hopkinton, MA  01748

+1 (508) 293-7953    Mobile: += ;1 (978) 394-7754

David.Black@= dell.com

----------------------------------------------------= ------------

 



-- 
________________________________________________________________<=
/o:p>
Bob Briscoe          =
;            &n=
bsp;        http://bobbriscoe.net/
--_000_CE03DB3D7B45C245BCA0D24327794936301E1D1BMX307CL04corpem_-- From nobody Thu Jul 19 17:28:53 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F17DA124C04; Thu, 19 Jul 2018 17:28:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tsvwg@ietf.org Message-ID: <153204653191.10649.14068730462120039669@ietfa.amsl.com> Date: Thu, 19 Jul 2018 17:28:51 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 00:28:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : Transport Options for UDP Author : Joe Touch Filename : draft-ietf-tsvwg-udp-options-05.txt Pages : 29 Date : 2018-07-19 Abstract: Transport protocols are extended through the use of transport header options. This document experimentally extends UDP by indicating the location, syntax, and semantics for UDP transport layer options. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-05 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-udp-options-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 20 04:05:17 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C82130E31 for ; Fri, 20 Jul 2018 04:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, 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 jlLi3MVplhXl for ; Fri, 20 Jul 2018 04:05:12 -0700 (PDT) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::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 2020F128BAC for ; Fri, 20 Jul 2018 04:05:12 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id e84-v6so4475580ybb.0 for ; Fri, 20 Jul 2018 04:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=UfKGuyGPcyP3XAaetAz8D/gl17B3ihDjlYFzq0pPbdM=; b=VUa0S68NOJKuJIXWyWz9foOzJqopy4evbNdUdH7JeYTSlTHD02ZRC+Mk9gjEJi1GJE yQJ+ucQy27vxme9G2bG/2H+kRxYOp5E27CGE6UfPh6i0zdRfQmoUCj4NfB9tCLvBsNB0 Ag6gOUQPDe4HUNo7LcBN+VhtS60ltr+bBxgmB2r1Z/UMN8LDwMwThdxmIDLhQlIonqFP BzG/dXwMwV4bDgz/TjpL4Z2UT6X/6J8R2cp8UEJbOD0Cgc0Vqn11Dl0B4Pl+h9nPYrTX 02il4oEs5IMQWs3KCz7zCwMpIbqIuEoJhqSEnkZv8zHGIGbShmWW75NbS8HKfmKXQBwy Y+Mg== 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; bh=UfKGuyGPcyP3XAaetAz8D/gl17B3ihDjlYFzq0pPbdM=; b=TBr4qwnUA+LpyxihMcwH9c16T/4e3SUUd263A0qttirHglz8BabLVUI+2dHNQko8GH V/b9N14/uOOmK+UAHGO1afc+7zsSLgzSr5x7MsRiwGxMWmi4TpCV4oKfBH0LyfDYqbp8 h5yjppqTJ7+2RqO2tKUg/VZikhqVCZJzYQHgVOMt379rMsWKkBVT1f/eQse53KXyC+Je vQLYQdo5uYpeOxVCfcK7jOCDoQxf7biBoVqJOK9B4cy7fHxFXM5k13XkDwSkr9cTcxn9 5FWjHrQ/QxvRrFsGVIRgWAZY5K4MLV1dtMKS3aAABKIlqfhkTNe8sRkCTHvRMrIpqDFl U40Q== X-Gm-Message-State: AOUpUlHAZYeHlh9HEak4NDXieTF7N9HF+pbAiZeA6BjocdBImc0KhQ8q yIyT7upH7g9yILnZp5o5IgZwR3twCUEgI1xSo1VuCZTw X-Google-Smtp-Source: AAOMgpcn5G9OaRiepCVk2gH8gzXYfq+cL+gfyj3pIp8Q/z2ZIg9NFoCAPErp4l5FdK0LEKqt/BT5e6ypw7xY1w9j35A= X-Received: by 2002:a25:8384:: with SMTP id t4-v6mr710775ybk.71.1532084710842; Fri, 20 Jul 2018 04:05:10 -0700 (PDT) MIME-Version: 1.0 From: Spencer Dawkins at IETF Date: Fri, 20 Jul 2018 06:04:57 -0500 Message-ID: To: tsvwg@ietf.org Content-Type: multipart/alternative; boundary="000000000000f4a7da05716c444d" Archived-At: Subject: [tsvwg] Request for TSVWG clue to PANRG draft author X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 11:05:15 -0000 --000000000000f4a7da05716c444d Content-Type: text/plain; charset="UTF-8" Dear TSVWG, Some of you are likely aware of the Path Aware Networking Research Group (PANRG, https://irtf.org/panrg), and some of you are likely aware that PANRG has me editing a draft on why Path-Aware Networking ideas that the IETF has considered have not been adopted, implemented, and deployed ("draft-dawkins-panrg-what-not-to-do"). There is a section on IntServ in https://tools.ietf.org/html/draft-dawkins-panrg-what-not-to-do-01#section-4.1, but it seemed to me that the current contents of that section may not capture all of the reasons why IntServ was not deployed, based on TSVWG discussions at the end of yesterday's meeting session. If you have thoughts about that, I'd love to hear them. If you'd like to contribute on the PANRG mailing list, that mailing list is at https://irtf.org/mailman/listinfo/panrg. If not, unicast to me, as the draft editor, will be fine. And thanks for that. Spencer, as (in this case) individual contributor in PANRG --000000000000f4a7da05716c444d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear TSVWG,

Some of you are likely awar= e of the Path Aware Networking Research Group (PANRG,=C2=A0https://irtf.org/panrg), and some of you are likely = aware that PANRG has me editing a draft on why Path-Aware Networking ideas = that the IETF has considered have not been adopted, implemented, and deploy= ed ("draft-dawkins-panrg-what-not-to-do").

There is a section on IntServ in https://tools.ietf.org/h= tml/draft-dawkins-panrg-what-not-to-do-01#section-4.1, but it seemed to= me that the current contents of that section may not capture all of the re= asons why IntServ was not deployed, based on TSVWG discussions at the end o= f yesterday's meeting session.=C2=A0

If you ha= ve thoughts about that, I'd love to hear them. If you'd like to con= tribute on the PANRG mailing list, that mailing list is at=C2=A0https://irtf.org/mailman/listinfo/= panrg. If not, unicast to me, as the draft editor, will be fine.=C2=A0<= /div>

And thanks for that.=C2=A0

Spencer, as (in this case) individual contributor in PANRG
--000000000000f4a7da05716c444d-- From nobody Fri Jul 20 08:00:29 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCFC1310D2 for ; Fri, 20 Jul 2018 08:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 n36_DwQM0Kmd for ; Fri, 20 Jul 2018 08:00:24 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 CC8DD131027 for ; Fri, 20 Jul 2018 08:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=aT5BqiZWwLWzaOltpjpinJIPxmLx+KZzafgB8M563lc=; b=e48y+bvpDaU+AzT/laQSolqiP iKCt7ktG8/38ssY4Cd5q5R4Dm6G5eZAPaXXurBn/eI24NPGd9Gch1OX0AYsih0kr8pgtYJti+w7gU fuB3jcY94ks0tosfpXmdZ2zkHi5ae5RuW1EdkrqH0S+asSAT5qdrJgoRoP7h0n+ddwmA93B4Sm/qz /T47XnTnepvbaOFcMBPhuewpMR8OfeCsihRWDNDBcNvDJn2bWE5ra1N59cbwZkM8osgK62MX0/Hxe DdaDIfctN5MFpDraxeKLB6JpbcRibFLZ2iETb1Hvn5uf4jk/eXYL5oloYz5OiaM2lJcVbEsRgWwuI lsAIxXqgQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:49495 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fgWtJ-001YLA-H6; Fri, 20 Jul 2018 11:00:24 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_CEFAE3FB-9AD7-49A6-9D7F-616B56302D96" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Joe Touch In-Reply-To: Date: Fri, 20 Jul 2018 08:00:20 -0700 Cc: tsvwg@ietf.org Message-Id: References: To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.3445.8.2) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Request for TSVWG clue to PANRG draft author X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 15:00:28 -0000 --Apple-Mail=_CEFAE3FB-9AD7-49A6-9D7F-616B56302D96 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Spencer (et al.), AFAICT, there are a few key lessons from both IntServ and DIffServ, IMO. = This isn=E2=80=99t a complete list, just some of the ones I=E2=80=99ve = seen most often: - don=E2=80=99t ask a question if you don=E2=80=99t need to know the = answer As per Bob Briscoe, if the answer to a reservation is always = =E2=80=9Cyes=E2=80=9D, then the reservation system isn=E2=80=99t needed. The US phone system learned that it was cheaper to have enough = capacity for flat-rate unlimited long distance=20 and not track than it was to operate the mechanism to track each = call - the same lesson applies=20 a corollary is that it=E2=80=99s better to be fast than perfect, = i.e., using HBH options means you should NOT expect=20 line-rate processing. frankly, it=E2=80=99s hard enough for = vendors to keep up with line rate for all packet sizes (some don=E2=80=99t= ) when there are no HBH options, at least partly because consumers = don=E2=80=99t want to pay for a feature that isn=E2=80=99t always needed (i.e., many cars have engines that work fine except for = steep hills, because it=E2=80=99s cheaper to sell a small engine and most people don=E2=80=99t need it most of the time). - don=E2=80=99t make idle threats Enforcement is critical; if you=E2=80=99re going to say no to = some requests, then your system really needs to throttle those who either don=E2=80=99t bother to ask or who disregard a = negative response. - follow the money A mechanism that doesn=E2=80=99t or can=E2=80=99t track to = billing won=E2=80=99t be useful. AFAICT, multicast (except for free in = the local area) suffered from this issue - i.e., if you can=E2=80=99t figure out = how to charge for something, how useful can it be? - don=E2=80=99t read minds Variations in network handling of traffic should be tied to = explicit markings of such, not application classes. I.e., behaviors should be requested explicitly, not inferred from port = numbers, etc. Joe > On Jul 20, 2018, at 4:04 AM, Spencer Dawkins at IETF = wrote: >=20 > Dear TSVWG, >=20 > Some of you are likely aware of the Path Aware Networking Research = Group (PANRG, https://irtf.org/panrg ), and some = of you are likely aware that PANRG has me editing a draft on why = Path-Aware Networking ideas that the IETF has considered have not been = adopted, implemented, and deployed = ("draft-dawkins-panrg-what-not-to-do"). >=20 > There is a section on IntServ in = https://tools.ietf.org/html/draft-dawkins-panrg-what-not-to-do-01#section-= 4.1 = , but it seemed to me that the current contents of that section may = not capture all of the reasons why IntServ was not deployed, based on = TSVWG discussions at the end of yesterday's meeting session.=20 >=20 > If you have thoughts about that, I'd love to hear them. If you'd like = to contribute on the PANRG mailing list, that mailing list is at = https://irtf.org/mailman/listinfo/panrg = . If not, unicast to me, as the = draft editor, will be fine.=20 >=20 > And thanks for that.=20 >=20 > Spencer, as (in this case) individual contributor in PANRG --Apple-Mail=_CEFAE3FB-9AD7-49A6-9D7F-616B56302D96 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = Spencer (et al.),

AFAICT, there are a few key lessons from both IntServ and = DIffServ, IMO. This isn=E2=80=99t a complete list, just some of the ones = I=E2=80=99ve seen most often:

- don=E2=80=99t ask a question if you = don=E2=80=99t need to know the answer
As per = Bob Briscoe, if the answer to a reservation is always =E2=80=9Cyes=E2=80=9D= , then the reservation system isn=E2=80=99t needed.
= The US phone system learned that it was cheaper to have enough = capacity for flat-rate unlimited long distance 
= and not track than it was to operate the mechanism to track each = call - the same lesson applies 

a corollary is that it=E2=80=99s = better to be fast than perfect, i.e., using HBH options means you should = NOT expect 
line-rate processing. frankly, = it=E2=80=99s hard enough for vendors to keep up with line rate for all = packet sizes (some don=E2=80=99t)
when = there are no HBH options, at least partly because consumers don=E2=80=99t = want to pay for a feature that isn=E2=80=99t always
= needed (i.e., many cars have engines that work fine except for = steep hills, because it=E2=80=99s cheaper to sell a small = engine
and most people don=E2=80=99t = need it most of the time).

- don=E2=80=99t make idle threats
= Enforcement is critical; if you=E2=80=99re going to say no to = some requests, then your system really needs to throttle those
= who either don=E2=80=99t bother to ask or who disregard a = negative response.

- follow the money
A = mechanism that doesn=E2=80=99t or can=E2=80=99t track to billing won=E2=80= =99t be useful. AFAICT, multicast (except for free in the local = area)
suffered from this issue - i.e., = if you can=E2=80=99t figure out how to charge for something, how useful = can it be?

- = don=E2=80=99t read minds
= Variations in network handling of traffic should be tied to = explicit markings of such, not application classes. I.e.,
= behaviors should be requested explicitly, not inferred from port = numbers, etc.

Joe

On Jul 20, 2018, at 4:04 AM, Spencer Dawkins = at IETF <spencerdawkins.ietf@gmail.com> wrote:

Dear TSVWG,

Some of you are likely aware of the Path Aware Networking = Research Group (PANRG, https://irtf.org/panrg), and some of you are likely aware = that PANRG has me editing a draft on why Path-Aware Networking ideas = that the IETF has considered have not been adopted, implemented, and = deployed ("draft-dawkins-panrg-what-not-to-do").

There is a section on IntServ in https://tools.ietf.org/html/draft-dawkins-panrg-what-not-to-do-= 01#section-4.1, but it seemed to me that the current contents of = that section may not capture all of the reasons why IntServ was not = deployed, based on TSVWG discussions at the end of yesterday's meeting = session. 

If you have thoughts about that, I'd love to hear them. If = you'd like to contribute on the PANRG mailing list, that mailing list is = at https://irtf.org/mailman/listinfo/panrg. If not, unicast = to me, as the draft editor, will be fine. 

And thanks for that. 

Spencer, as (in this = case) individual contributor in PANRG

= --Apple-Mail=_CEFAE3FB-9AD7-49A6-9D7F-616B56302D96-- From nobody Fri Jul 20 08:17:12 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98251310AC for ; Fri, 20 Jul 2018 08:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, 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 38AAXVpsiyEV for ; Fri, 20 Jul 2018 08:17:05 -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 0E27F1310C3 for ; Fri, 20 Jul 2018 08:17:04 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id r3-v6so4473821ywc.5 for ; Fri, 20 Jul 2018 08:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=saykvD1R7IOew2FYIku/Wg6UBO3xxHGol0IuwbpMbYE=; b=GxWfTsVMq2l58qVvtAbqVENqdLdZVYkYKc/wabjFFjYqDWWyirNwxX5w860akotxZh Zv/hYwHWD6HpTnIUHwlnazvM1BCpC365wxhrd/ykua6K6lxdTKNqn7wj1srfJyPna+31 MpehsJXAUVCULtE3IrIKJqqI2GmZ3OFclcjVR6jBJ60R06W7pwm16zprhfeWWxjxweU1 14HC51osMtTtMjIZJ7rOBGP2ro8MxPrgBzdtSOUwphJiWk+gs7Z9tQsP9Mm3nAxrCfSD q9N/Hb9fDFIiSVKvdWhqXCuingzKyFhvIt6g8aaSveHQg4q97hUJFTI9qrF+XiAR2ZB4 cMdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=saykvD1R7IOew2FYIku/Wg6UBO3xxHGol0IuwbpMbYE=; b=e8Xo0bAe12ygrar0BGKpPh9995QqVwktBjmGxL/wfaDfv4UKuFYp+VEK2E1YtYsDN2 YudP3yFyyDHeh0n0ssbLB8bqKhnTfMJhV/2c7WjmjaiIIoQp6hzt01mu2+g0ZisXAL2O 4DvRjIMCv7EdP+Y1TdQxKTv+PqlsQRT3tuPt4H49gwZtjDPpGYE7tO2oaVjd7TOjryMr hEGUBmJ+U5Hex5cXoCFWxflwjBveO1mbK1iEXYbBfk8y721TW7FVUB0jAM/OBRofzblg T7E12+UJcOUu0SG5YDnMfgXIqTwUDzVG87D6EsM6BJeHgCdUWYbibGlNRytm+CmLCK+N yuPA== X-Gm-Message-State: AOUpUlEOD759pF9J+xcImskL2ABMdh4s6w5eLyhvZsjThg8zvzlVX+Gm qGpa0YQbUGvGiwEiiinRO68IXxBLtrDIAbELt1nLtg== X-Google-Smtp-Source: AAOMgpei14aZEfdygdHvdd0V/t21kxyZPgbpWt/KeriHDD2F+Qy0tpYMP0o8qc9YpmPAarrYinzaKyaGOCLSTnMU35Y= X-Received: by 2002:a81:c10e:: with SMTP id f14-v6mr1234935ywi.52.1532099823182; Fri, 20 Jul 2018 08:17:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Dawkins at IETF Date: Fri, 20 Jul 2018 10:16:49 -0500 Message-ID: To: Joe Touch Cc: tsvwg@ietf.org Content-Type: multipart/alternative; boundary="000000000000b8a8d205716fc98c" Archived-At: Subject: Re: [tsvwg] Request for TSVWG clue to PANRG draft author X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 15:17:07 -0000 --000000000000b8a8d205716fc98c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Joe, On Fri, Jul 20, 2018 at 10:00 AM Joe Touch wrote: > Hi, Spencer (et al.), > > AFAICT, there are a few key lessons from both IntServ and DIffServ, IMO. > This isn=E2=80=99t a complete list, just some of the ones I=E2=80=99ve se= en most often: > > - don=E2=80=99t ask a question if you don=E2=80=99t need to know the answ= er > As per Bob Briscoe, if the answer to a reservation is always =E2=80=9Cyes= =E2=80=9D, then > the reservation system isn=E2=80=99t needed. > The US phone system learned that it was cheaper to have enough capacity > for flat-rate unlimited long distance > and not track than it was to operate the mechanism to track each call - > the same lesson applies > > a corollary is that it=E2=80=99s better to be fast than perfect, i.e., us= ing HBH > options means you should NOT expect > line-rate processing. frankly, it=E2=80=99s hard enough for vendors to ke= ep up > with line rate for all packet sizes (some don=E2=80=99t) > when there are no HBH options, at least partly because consumers don=E2= =80=99t > want to pay for a feature that isn=E2=80=99t always > needed (i.e., many cars have engines that work fine except for steep > hills, because it=E2=80=99s cheaper to sell a small engine > and most people don=E2=80=99t need it most of the time). > > - don=E2=80=99t make idle threats > Enforcement is critical; if you=E2=80=99re going to say no to some reques= ts, then > your system really needs to throttle those > who either don=E2=80=99t bother to ask or who disregard a negative respon= se. > > - follow the money > A mechanism that doesn=E2=80=99t or can=E2=80=99t track to billing won=E2= =80=99t be useful. > AFAICT, multicast (except for free in the local area) > suffered from this issue - i.e., if you can=E2=80=99t figure out how to c= harge for > something, how useful can it be? > > - don=E2=80=99t read minds > Variations in network handling of traffic should be tied to explicit > markings of such, not application classes. I.e., > behaviors should be requested explicitly, not inferred from port numbers, > etc. > > Joe > Thanks, this is very helpful! Spencer --000000000000b8a8d205716fc98c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Joe,

On Fri, Jul 20, 2018 at 10:00 AM Joe Touch <touch@strayalpha.com> wrote:
Hi, Spencer (et al.),

AFAICT, there are a few key = lessons from both IntServ and DIffServ, IMO. This isn=E2=80=99t a complete = list, just some of the ones I=E2=80=99ve seen most often:

- don=E2=80=99t ask a question if you don=E2=80=99t need to know th= e answer
As per Bob Briscoe, if the answer to a = reservation is always =E2=80=9Cyes=E2=80=9D, then the reservation system is= n=E2=80=99t needed.
The US phone system learned = that it was cheaper to have enough capacity for flat-rate unlimited long di= stance=C2=A0
and not track than it was to operat= e the mechanism to track each call - the same lesson applies=C2=A0

a corollary is that it=E2=80=99s better t= o be fast than perfect, i.e., using HBH options means you should NOT expect= =C2=A0
line-rate processing. frankly, it=E2=80= =99s hard enough for vendors to keep up with line rate for all packet sizes= (some don=E2=80=99t)
when there are no HBH opti= ons, at least partly because consumers don=E2=80=99t want to pay for a feat= ure that isn=E2=80=99t always
needed (i.e., many= cars have engines that work fine except for steep hills, because it=E2=80= =99s cheaper to sell a small engine
and most peo= ple don=E2=80=99t need it most of the time).

- don= =E2=80=99t make idle threats
Enforcement is crit= ical; if you=E2=80=99re going to say no to some requests, then your system = really needs to throttle those
who either don=E2= =80=99t bother to ask or who disregard a negative response.

<= /div>
- follow the money
A mechanism that do= esn=E2=80=99t or can=E2=80=99t track to billing won=E2=80=99t be useful. AF= AICT, multicast (except for free in the local area)
<= /span>suffered from this issue - i.e., if you can=E2=80=99t figure out how = to charge for something, how useful can it be?

- d= on=E2=80=99t read minds
Variations in network ha= ndling of traffic should be tied to explicit markings of such, not applicat= ion classes. I.e.,
behaviors should be requested= explicitly, not inferred from port numbers, etc.

= Joe

Thanks, this is very he= lpful!

Spencer
--000000000000b8a8d205716fc98c-- From nobody Fri Jul 20 10:41:26 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E48130F90 for ; Fri, 20 Jul 2018 10:41:26 -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 BIvcYVh7wMTt for ; Fri, 20 Jul 2018 10:41:24 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDB30130DEE for ; Fri, 20 Jul 2018 10:41:23 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id y10-v6so10557449ioa.10 for ; Fri, 20 Jul 2018 10:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=85cENY5w2LPcgnmnQU3ZJOw16ksXcLiAiM3Ul9crsFg=; b=DUTMm03/QBguyqk/293+j4Q0g3WSxKYGtrpgJeDnlq989u3mz6fKTwaVJ2p4dHeDir PM8APNHk4NP94k3hP7pBpb2Nz7n2nB40dp2wJgtjI/O5k/iuUkfX2zYeM5rmw3na8f2q L4uYsIPZeRZtoCi46QT63aHF5F7ZXZJXl4B9vqAI3IpHgHKbWoJP0NeBCFS3tvNHI6uM 3zzS6qUs47lbZqBlyX1t2HDtkdDCE2/1gwCB+LbYs1tu+7bf30AogR3GnhK8QSX/KlDo f/vR5uOzlMH2dzUZVRIA3HlSz5xCtEN5mR5ECoOFgNs4fNJ2O/VvNHdkirlCtf+1DNHj J0Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=85cENY5w2LPcgnmnQU3ZJOw16ksXcLiAiM3Ul9crsFg=; b=K5uvnFKKGSCTmYSH4lado24lhOUM+z9Q3lO5pXLCZBxM9Dpb6VkR3e3iGT+VxeoG3i uvgQ5jDxtDPOz5xh3eGT8ou7eGOhDSclBpdWE7IxYi6uj7xp54l7rrfjp55RvVmoLkoR yY2I7RUo2fifjMplARtOxxX6BxIOYSYcKo/CC+IQscl/O6xxPQljDbr6aeDHsgZ1Lwyd 1nbPYYv/o5u4KLdmGEak6QT+qsqgCxMccploAbFRdBAmhpGpo7RltyEix0peKhHfHAxS hdFYA5tSjH3J8cLj0wvWpir9kHYMIIK57ovFYz/+OwgY7CduNaGOTwyAU3g8RKnPLouN DvEg== X-Gm-Message-State: AOUpUlEx/P2mr2bhwMwmpp+d4eu6td8aCcHR3kmk3CvGyC2DciCQcDy7 xzA7dd1E6RW1V+E7/IEt/zR+IPJK6kI= X-Google-Smtp-Source: AAOMgpcSnuQNSPNKd7o3OwfRMHkEToZu85Z1es4dy7olpVv1ZPdEAdzs7vv3pe8yNt6d6PfW7qdOQw== X-Received: by 2002:a6b:b955:: with SMTP id j82-v6mr2330174iof.158.1532108482968; Fri, 20 Jul 2018 10:41:22 -0700 (PDT) Received: from [10.255.242.174] ([207.164.22.20]) by smtp.gmail.com with ESMTPSA id f18-v6sm1561953itc.44.2018.07.20.10.41.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Jul 2018 10:41:22 -0700 (PDT) To: Joe Touch Cc: Spencer Dawkins at IETF , tsvwg@ietf.org References: From: Brian E Carpenter Message-ID: <7c73e9f1-3963-9eb4-81bf-c69755e8763d@gmail.com> Date: Sat, 21 Jul 2018 05:41:29 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] Request for TSVWG clue to PANRG draft author X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 17:41:26 -0000 Joe, I agree with all that, but I'd like to explore one point a bit further: > it=E2=80=99s better to be fast than perfect, i.e., using HBH options> m= eans you should NOT expect line-rate processing. > frankly, it=E2=80=99s hard enough for vendors to keep up with line rate= > for all packet sizes (some don=E2=80=99t) when there are no HBH options= , I heard the opposite assertion yesterday: that we can now build hardware that's fast enough to handle state lookup and header processing per packet at line speed. Now Moore's law etc. has indeed meant that lookup and processing have been getting faster over many years, but so has line speed. My question is: has anybody systematically studied whether the increase in state lookup and processing speed has kept up with or exceeded the increase of line speed, all at constant real cost per customer? If lookup and processing speed has *not* increased significantly faster than line speed, at constant cost per customer, I don't see how solutions requiring per-flow state can succeed any better than RSVP. We know that with powerful enough rockets, pigs can fly, and carrier-grade NATs can handle per-flow state, but I very much doubt that this meets the standard of constant cost per customer compared to stateless forwarding. Does anybody have numbers or can point to a published study? Regards Brian=20 From nobody Fri Jul 20 10:51:39 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B554213120C for ; Fri, 20 Jul 2018 10:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 n9dy1uWVdo5A for ; Fri, 20 Jul 2018 10:51:23 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 D4A631311A2 for ; Fri, 20 Jul 2018 10:51:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9uHQ4gVtIfg/nLzSpEn1vomjlw4twCz7i71VCaH6Bxg=; b=fCul8P9nrptnfXF/uhxNIHz5B cpO6DfnP2d4fSvd17wRqFlJ8odyBsi2bf6ssEzqzRgBq4P/a19Fno7QB1Fxr4QLIbDcAn8EexuaGW 5V3xy41a7YWyvn/2e3Ndyz58oW90ojixN9fYFyjfVQEWWP/oPp+iOG83JHuLgmvjc9qTZKR23cWvi zijONGU2RG86VWl29Ig8Qegsh0rOei4puTCTmeUnxS0JApueaX11QaZI4uHU9+Z0G8MUrES3E+IVO nsioF09qwjXZdplssaF9tI7XRxhfygUYnK8v1Ql7hDmEjG3SHDHnmSSAVXCilXTyReC8HkdmuvNKx WpaDxW/2g==; Received: from [::1] (port=60230 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.91) (envelope-from ) id 1fgZYp-003lpZ-2U; Fri, 20 Jul 2018 13:51:23 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_5c23f87cf109182189ebbb561884872c" Date: Fri, 20 Jul 2018 10:51:23 -0700 From: Joe Touch To: Brian E Carpenter Cc: tsvwg@ietf.org In-Reply-To: <7c73e9f1-3963-9eb4-81bf-c69755e8763d@gmail.com> References: <7c73e9f1-3963-9eb4-81bf-c69755e8763d@gmail.com> Message-ID: X-Sender: touch@strayalpha.com User-Agent: Roundcube Webmail/1.3.3 X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Request for TSVWG clue to PANRG draft author X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 17:51:34 -0000 --=_5c23f87cf109182189ebbb561884872c Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi, Brian, I take your point that hardware has gotten faster, but AFAICT it will always be cheaper to not process HBH options in hardware. The real question will be whether anyone will want to pay what HBH hardware costs for the benefit/revenue possible, e.g., for QoS -- again, vs. just over provisioning capacity. Though I too would be glad to hear what's possible (esp. if it can include some hint at the relative cost). Joe On 2018-07-20 10:41, Brian E Carpenter wrote: > Joe, > > I agree with all that, but I'd like to explore one point a bit further: > >> it's better to be fast than perfect, i.e., using HBH options> means you should NOT expect line-rate processing. >> frankly, it's hard enough for vendors to keep up with line rate >> for all packet sizes (some don't) when there are no HBH options, > > I heard the opposite assertion yesterday: that we can now build > hardware that's fast enough to handle state lookup and header > processing per packet at line speed. > > Now Moore's law etc. has indeed meant that lookup and processing > have been getting faster over many years, but so has line speed. > > My question is: has anybody systematically studied whether the > increase in state lookup and processing speed has kept up with > or exceeded the increase of line speed, all at constant real > cost per customer? > > If lookup and processing speed has *not* increased significantly > faster than line speed, at constant cost per customer, I don't see > how solutions requiring per-flow state can succeed any better than > RSVP. > > We know that with powerful enough rockets, pigs can fly, and > carrier-grade NATs can handle per-flow state, but I very much > doubt that this meets the standard of constant cost per customer > compared to stateless forwarding. > > Does anybody have numbers or can point to a published study? > > Regards > Brian --=_5c23f87cf109182189ebbb561884872c Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi, Brian,

I take your point that hardware has gotten faster, but AFAICT it will al= ways be cheaper to not process HBH options in hardware.

The real question will be whether anyone will want to pay what HBH hardw= are costs for the benefit/revenue possible, e.g., for QoS -- again, vs. jus= t over provisioning capacity.

Though I too would be glad to hear what's possible (esp. if it can inclu= de some hint at the relative cost).

Joe

 


On 2018-07-20 10:41, Brian E Carpenter wrote:

= Joe,

I agree with all that, but I'd like to explore one point a= bit further:

it's better to be fast than perfect, i.e., using HBH o= ptions> means you should NOT expect line-rate processing.
frankly,= it's hard enough for vendors to keep up with line rate
for all packe= t sizes (some don't) when there are no HBH options,

I heard the opposite assertion yesterday: that we can now build
hardware that's fast enough to handle state lookup and header
proce= ssing per packet at line speed.

Now Moore's law etc. has indeed= meant that lookup and processing
have been getting faster over many = years, but so has line speed.

My question is: has anybody syste= matically studied whether the
increase in state lookup and processing= speed has kept up with
or exceeded the increase of line speed, all a= t constant real
cost per customer?

If lookup and processi= ng speed has *not* increased significantly
faster than line speed, at= constant cost per customer, I don't see
how solutions requiring per-= flow state can succeed any better than
RSVP.

We know that= with powerful enough rockets, pigs can fly, and
carrier-grade NATs c= an handle per-flow state, but I very much
doubt that this meets the s= tandard of constant cost per customer
compared to stateless forwardin= g.

Does anybody have numbers or can point to a published study?=

Regards
   Brian

--=_5c23f87cf109182189ebbb561884872c-- From nobody Sat Jul 21 10:33:59 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652E9130DCF for ; Sat, 21 Jul 2018 10:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 UBvZZuf9U1Il for ; Sat, 21 Jul 2018 10:33:55 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D1F127333 for ; Sat, 21 Jul 2018 10:33:55 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id m13-v6so13044876qth.1 for ; Sat, 21 Jul 2018 10:33:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jAP5T5gqTkKBKS9SFE94PIF/2lPIn2vlNH2ZbJtmvJE=; b=ZNTIK4QZecnr3w2SLLlhQGJ/av8jlzMggtrSR2ab2Le//mq+QWHNFzTqXwY+l2v2rh O9o7Gxb4uakGccMSYeD9i7iBCZgYM+yUwU74lU0wkIbbebHUhaDZQIix7GWV6qVPchtg lEsZI2UAW0M2Gbid4OtPLctZs2Rg/VtxucNBF/oO2Jgp6TY16i6AXiwNIDeBUp5F3FH9 ETuYbpYjuZ4oetATLxcd8InC3cQS53cxIrTfNNEXlPeRTOYEcfTF4F6/mRU9cSHa2nPJ uL455+C97JNcMCKDPVAJjuwxkPV+vVcOaT7mvdxgHVnL1LLeNDyImO9f4n7tIuzf9kfD n6Fw== 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=jAP5T5gqTkKBKS9SFE94PIF/2lPIn2vlNH2ZbJtmvJE=; b=Y6lUJURNQWljphbOQW8yjk6flqZonDZmUPCZUqVga3FMbLp0VoDZbG/UMPrkjIPvxM p7zFLBvm69N1yKCpGYdHogz1nF+rKakjky0DP26imyQ5lThhPLmp33jgxSgLZa3ckTsX UjbiBgYqC7VeoCQFUgk3VAMGnPRm0ozkU2i+bxdz3iIcQsqNw5qO6jvoF4PD1TYvOCD2 zvt1orkQm2s6SppJB44AWe2bMQwA1SSpvr1wVU6VWVaKgxm6AJROKls7zWTFqHDNm2pQ TY6pAHZ7w1M7rCK6y0zPg/hXyhEN4VtK0c5jHZ3LuMqJv4a6lE+TDJr+2PMJDCxLhj1O /F/Q== X-Gm-Message-State: AOUpUlENAsZHZDHjZ0QmSu4mW/zC/PaSKMjUL2Vw4xgFez8BGoQzczSA WfyLpDyzZ86Ki7pmty3cWXfToKHCOk4kUudss7CItQ== X-Google-Smtp-Source: AAOMgpfHpCxPc8tDLZlpMrd3bItboCyUU6VdPCpl6bcMM7rNbtGAtlP3SGnX8hXhnDNfowWFeQNK727eC0uYM13EWRo= X-Received: by 2002:ac8:6648:: with SMTP id j8-v6mr5420888qtp.254.1532194434219; Sat, 21 Jul 2018 10:33:54 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:3304:0:0:0:0:0 with HTTP; Sat, 21 Jul 2018 10:33:53 -0700 (PDT) In-Reply-To: References: <7c73e9f1-3963-9eb4-81bf-c69755e8763d@gmail.com> From: Tom Herbert Date: Sat, 21 Jul 2018 10:33:53 -0700 Message-ID: To: Joe Touch Cc: Brian E Carpenter , tsvwg Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tsvwg] Request for TSVWG clue to PANRG draft author X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2018 17:33:58 -0000 On Fri, Jul 20, 2018 at 10:51 AM, Joe Touch wrote: > Hi, Brian, > > I take your point that hardware has gotten faster, but AFAICT it will always > be csheaper to not process HBH options in hardware. > Joe, The answer to this depends on the exact question being asked. If the question is whether hardware can process any arbitrary number and combination of TLVs in HBH options as allowed by standard, then the answer will be no. For instance, it's unreasonable to a expect anyone to efficiently parse a long list of tiny TLVs with random unknown types whose number in the packet is only limited by MTU (could be hundreds of them in a single packet) However, if the question is whether hardware could parse HBH options that are somehow constrained, like maybe only needing to parse a couple of TLVs that are known to the implementation, fixed length, and the total length keeps all headers within the parsing buffer of HW (typically 128 bytes currently); then procesing HBH options in HW could be feasible. > The real question will be whether anyone will want to pay what HBH hardware > costs for the benefit/revenue possible, e.g., for QoS -- again, vs. just > over provisioning capacity. > Programmable hardware devices, like those that support BPF or P4, should address the cost component of the problem. Tom > Though I too would be glad to hear what's possible (esp. if it can include > some hint at the relative cost). > > Joe > > > > > On 2018-07-20 10:41, Brian E Carpenter wrote: > > Joe, > > I agree with all that, but I'd like to explore one point a bit further: > > it's better to be fast than perfect, i.e., using HBH options> means you > should NOT expect line-rate processing. > frankly, it's hard enough for vendors to keep up with line rate > for all packet sizes (some don't) when there are no HBH options, > > > I heard the opposite assertion yesterday: that we can now build > hardware that's fast enough to handle state lookup and header > processing per packet at line speed. > > Now Moore's law etc. has indeed meant that lookup and processing > have been getting faster over many years, but so has line speed. > > My question is: has anybody systematically studied whether the > increase in state lookup and processing speed has kept up with > or exceeded the increase of line speed, all at constant real > cost per customer? > > If lookup and processing speed has *not* increased significantly > faster than line speed, at constant cost per customer, I don't see > how solutions requiring per-flow state can succeed any better than > RSVP. > > We know that with powerful enough rockets, pigs can fly, and > carrier-grade NATs can handle per-flow state, but I very much > doubt that this meets the standard of constant cost per customer > compared to stateless forwarding. > > Does anybody have numbers or can point to a published study? > > Regards > Brian > From nobody Wed Jul 25 02:50:09 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 852FE126DBF; Wed, 25 Jul 2018 02:50:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tsvwg@ietf.org Message-ID: <153251220347.15477.4964875960468719912@ietfa.amsl.com> Date: Wed, 25 Jul 2018 02:50:03 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-fecframe-ext-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 09:50:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : Forward Error Correction (FEC) Framework Extension to Sliding Window Codes Authors : Vincent Roca Ali Begen Filename : draft-ietf-tsvwg-fecframe-ext-03.txt Pages : 20 Date : 2018-07-25 Abstract: RFC 6363 describes a framework for using Forward Error Correction (FEC) codes to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. However FECFRAME as per RFC 6363 is restricted to block FEC codes. The present document extends FECFRAME to support FEC Codes based on a sliding encoding window, in addition to Block FEC Codes, in a backward compatible way. During multicast/broadcast real-time content delivery, the use of sliding window codes significantly improves robustness in harsh environments, with less repair traffic and lower FEC-related added latency. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-fecframe-ext-03 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-fecframe-ext-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-fecframe-ext-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 25 02:52:20 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF13A130FCD; Wed, 25 Jul 2018 02:52:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tsvwg@ietf.org Message-ID: <153251233095.15451.13291266750385417075@ietfa.amsl.com> Date: Wed, 25 Jul 2018 02:52:10 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rlc-fec-scheme-06.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 09:52:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME Authors : Vincent Roca Belkacem Teibi Filename : draft-ietf-tsvwg-rlc-fec-scheme-06.txt Pages : 34 Date : 2018-07-25 Abstract: This document describes two fully-specified Forward Erasure Correction (FEC) Schemes for Sliding Window Random Linear Codes (RLC), one for RLC over GF(2) (binary case), a second one for RLC over GF(2^^8), with the possibility of controlling the code density. They can protect arbitrary media streams along the lines defined by FECFRAME extended to sliding window FEC codes. These sliding window FEC codes rely on an encoding window that slides over the source symbols, generating new repair symbols whenever needed. Compared to block FEC codes, these sliding window FEC codes offer key advantages with real-time flows in terms of reduced FEC-related latency while often providing improved packet erasure recovery capabilities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-rlc-fec-scheme-06 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rlc-fec-scheme-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rlc-fec-scheme-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 Wed Jul 25 03:10:56 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51FA112DD85 for ; Wed, 25 Jul 2018 03:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] 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 2_6eAbz1PhgF for ; Wed, 25 Jul 2018 03:10:52 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 5E4CC130E5A for ; Wed, 25 Jul 2018 03:10:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.51,401,1526335200"; d="scan'208,217";a="340229711" Received: from demeter.inrialpes.fr ([194.199.28.3]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jul 2018 12:10:27 +0200 From: Vincent Roca Message-Id: <02E6BC9D-2A8C-4489-BA31-7DB0F0195F0E@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_5E15D783-1C0B-409C-89CD-8CFC653D5AA9" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 25 Jul 2018 12:10:27 +0200 In-Reply-To: <153251220347.15477.4964875960468719912@ietfa.amsl.com> Cc: Vincent Roca , tsvwg@ietf.org, nwcrg@irtf.org To: Wesley Eddy References: <153251220347.15477.4964875960468719912@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-fecframe-ext-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 10:10:55 -0000 --Apple-Mail=_5E15D783-1C0B-409C-89CD-8CFC653D5AA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Wes, all, We have just updated the FECFRAME extension and RLC FEC Scheme for = FECFRAME I-Ds as discussed during IETF 102 meeting. Those updates fix a few typos, = slightly improve text, add an acknowledgment section. We authors do not think it requires a new = WGLC. Cheers, Vincent NB: if one looks at the RLC FEC Scheme diff: = https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-rlc-fec-scheme-06.t= xt = one may think that Appendix A providing the TinyMT32 C-code has = been significantly changed. This is not the case, we merely updated a few comments (in = particular added references for the initial PRNG state parameters=E2=80=99 choice). The = rfcdiff tool seems to have lost tracks. > Le 25 juil. 2018 =C3=A0 11:50, internet-drafts@ietf.org a =C3=A9crit : >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Area Working Group WG of = the IETF. >=20 > Title : Forward Error Correction (FEC) Framework = Extension to Sliding Window Codes > Authors : Vincent Roca > Ali Begen > Filename : draft-ietf-tsvwg-fecframe-ext-03.txt > Pages : 20 > Date : 2018-07-25 >=20 > Abstract: > RFC 6363 describes a framework for using Forward Error Correction > (FEC) codes to provide protection against packet loss. The = framework > supports applying FEC to arbitrary packet flows over unreliable > transport and is primarily intended for real-time, or streaming, > media. However FECFRAME as per RFC 6363 is restricted to block FEC > codes. The present document extends FECFRAME to support FEC Codes > based on a sliding encoding window, in addition to Block FEC Codes, > in a backward compatible way. During multicast/broadcast real-time > content delivery, the use of sliding window codes significantly > improves robustness in harsh environments, with less repair traffic > and lower FEC-related added latency. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tsvwg-fecframe-ext-03 > https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-fecframe-ext-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-fecframe-ext-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 --Apple-Mail=_5E15D783-1C0B-409C-89CD-8CFC653D5AA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello= Wes, all,

We have = just updated the FECFRAME extension and RLC FEC Scheme for FECFRAME I-Ds = as
discussed during IETF 102 meeting. Those updates = fix a few typos, slightly improve text, add
an = acknowledgment section. We authors do not think it requires a new = WGLC.

Cheers,

   Vincent


NB: = if one looks at the RLC FEC Scheme diff:
one may think that Appendix = A providing the TinyMT32 C-code has been significantly = changed.
This is not the case, we merely = updated a few comments (in particular added references
= for the initial PRNG state parameters=E2=80=99 choice). The = rfcdiff tool seems to have lost tracks.


Le 25 juil. 2018 =C3=A0 11:50, internet-drafts@ietf.org a =C3=A9crit :


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

       Title =           : Forward = Error Correction (FEC) Framework Extension to Sliding Window Codes
       Authors =         : Vincent Roca
=             &n= bsp;           &nbs= p;Ali Begen
Filename =        : = draft-ietf-tsvwg-fecframe-ext-03.txt
Pages =           : 20
= Date =            : = 2018-07-25

Abstract:
=   RFC 6363 describes a framework for using Forward Error = Correction
  (FEC) codes to provide protection = against packet loss.  The framework
=   supports applying FEC to arbitrary packet flows over = unreliable
  transport and is primarily = intended for real-time, or streaming,
  media. =  However FECFRAME as per RFC 6363 is restricted to block FEC
  codes.  The present document extends = FECFRAME to support FEC Codes
  based on a = sliding encoding window, in addition to Block FEC Codes,
=   in a backward compatible way.  During = multicast/broadcast real-time
  content = delivery, the use of sliding window codes significantly
=   improves robustness in harsh environments, with less repair = traffic
  and lower FEC-related added = latency.


The IETF = datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/=

There are also htmlized versions = available at:
https://tools.ietf.org/html/draft-ietf-tsvwg-fecframe-ext-03https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-fecframe= -ext-03

A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-fecframe-e= xt-03


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/


= --Apple-Mail=_5E15D783-1C0B-409C-89CD-8CFC653D5AA9-- From nobody Wed Jul 25 07:06:38 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E4E130E09 for ; Wed, 25 Jul 2018 07:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-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 CARxtmDYh2VK for ; Wed, 25 Jul 2018 07:06:35 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6200C1292AD for ; Wed, 25 Jul 2018 07:06:35 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id g11-v6so6423110ioq.9 for ; Wed, 25 Jul 2018 07:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=8JTb8GasLdV8fjDbhej/K4X+5o+qD+kL9/tgyfWsk14=; b=GsGF/Bc/2gjbS6SSC9CDstRX0beRD5hxf8vj5OLKnzLv4ti4iujCT7HyfVIgnkbhfs /c61VZe3uniNfQSkCoOLVsQgFMV8Xq+rRoYITjBVCxJ6jILLSWWpBdQpfnrU3x9Qk7Jz 67RxWmuyrwBABvxzdXOzDY2jDl4w80xMo6wYevYkYG20V/cJDrsUnXok3xbQRWvnkivj mOlvMFj6p3uzE1wTvUXqtW95NZHqqaAUD2ulBJduVKcWUORCxhvqsimoAgg9btA0AvIp e/eGQXEP9/rrFtNv8zf0zcbGvAmKOeWi8rvSFqS9BeuMKctAhX2byJKZPicITWrhMgd+ yloA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=8JTb8GasLdV8fjDbhej/K4X+5o+qD+kL9/tgyfWsk14=; b=WEFnfbj7wEhqejZxQwGdQGqkQUuaT8mXbOmB/tHTMLg+3bA7YqNb8AaYiWbV2JPqmf PQ9SI9jmDB4YAr+gt8LnerL8om5bOgFjs3SOpOJrmxmWZRmVtIc9Thgd3y2RBhhGoFbl 0gaxBYPnj+bg7RBJq0U/VbgET6R+kt7CtL2ZPnRJraipzZQtaRcQxp3MRV236o3r5pCi 1SK4RCAUX5Xy5O527uGCHNmFtpByvsVY+pjhIOp3+jfrQ1c4T/hGhN3rox5he0lCCx01 Yx3sc8zcI51ktBEt2AJPFemTd99EsOYSbblSocN+Y5UzykuqQvGyMaV0wdu59yYrAYs3 39Lg== X-Gm-Message-State: AOUpUlGkfKYKXyrgCVo1E92p5Lm3B1KRBbnPywaShNhgqQ6/5+tonSo2 53vhncxJd9TdUkOzJ6A8cI6qqA== X-Google-Smtp-Source: AAOMgpc6xdgIKiDUcVzDnuM+Fuok043L+PfZxYLD2izwpA1LtgiUFX3ji7AC3BEv1ekg19lHkOyabg== X-Received: by 2002:a5e:8916:: with SMTP id k22-v6mr18075018ioj.9.1532527594551; Wed, 25 Jul 2018 07:06:34 -0700 (PDT) Received: from [192.168.1.105] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id b85-v6sm2598442itd.37.2018.07.25.07.06.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jul 2018 07:06:33 -0700 (PDT) To: Vincent Roca Cc: tsvwg@ietf.org, nwcrg@irtf.org References: <153251220347.15477.4964875960468719912@ietfa.amsl.com> <02E6BC9D-2A8C-4489-BA31-7DB0F0195F0E@inria.fr> From: Wesley Eddy Message-ID: <12740637-b43a-cfbf-5b25-f3315fa80ae8@mti-systems.com> Date: Wed, 25 Jul 2018 10:06:31 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <02E6BC9D-2A8C-4489-BA31-7DB0F0195F0E@inria.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-fecframe-ext-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 14:06:38 -0000 On 7/25/2018 6:10 AM, Vincent Roca wrote: > Hello Wes, all, > > We have just updated the FECFRAME extension and RLC FEC Scheme for > FECFRAME I-Ds as > discussed during IETF 102 meeting. Those updates fix a few typos, > slightly improve text, add > an acknowledgment section. We authors do not think it requires a new WGLC. > Thanks.  I think everyone who commented during the WGLC has now confirmed that they're happy with the changes, so I'll start the shepherd write-up. From nobody Wed Jul 25 07:35:01 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC48F130E7F for ; Wed, 25 Jul 2018 07:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-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 8JW784VP5iMU for ; Wed, 25 Jul 2018 07:34:45 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 9BAF1126F72 for ; Wed, 25 Jul 2018 07:34:45 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id q19-v6so6492100ioh.11 for ; Wed, 25 Jul 2018 07:34:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=4zELWJeFHZDeAPVMsWIbpRTzen4+HIH8RuVkcDxf/iA=; b=crZ76hc40UzU3DTyYkCLNi7uBzRsEvKVjXwvB3hmPOp1LArhmRgekZ5f95ndHnjM+8 JycUM+6E1yrSCH+vDBILQ7Q8FybUq9xJxzTPuJAlamM6d4RpupbwJEbVioa7C/MFbpwy 0nd5z5VJVpvnUgVE1lMHQJYOostD9BJvfpG58K7NjJo0gqJ2XFB7hvOkCRiRM2LGJPw7 yW4su4DY/5Rol7xNFGJv4K1uGY7DXCl97Gxgy3KsPPKyoZZqFuEO3RR+8NfWZ7Iw4vTa vpV+r7pLXIXOOSNHiJbYgNwUYLc8E/eRxU+fSioQ2UTOYBmr9erqYKiFPfK2+/xkBS0f kA9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=4zELWJeFHZDeAPVMsWIbpRTzen4+HIH8RuVkcDxf/iA=; b=bHBkBaSbIJSCSu8xKF7Fe8A/7a/PiilnyfV9aQm7EltkmYb7xP4rxegb4qMNUKQTg9 I1wc6XIhKXaLBqxapPeuQDhoArCHwUaxofDlCbNicURz8YpNyu6Fyq9Vu5V38zdwCcMX rYCxJfsFJglXwDihgKNz81C3l4mevK+aLQsBj0oVITDtCE0dA8GvFHfIIdsGvZtjOfTB GZjk3wh2XIOp70aEXAuWB2vCO5G7foCvcB89++ZgKZVbMJCSrrWCTr5P6IBcLGbWx2zA uWioh3efEl39VtkzY3Akoy5dlzUaoBW6AUHcvDNk0OYvaNSEPUJwaTcQSdrbTAtilV/A oGzg== X-Gm-Message-State: AOUpUlGzzCx3GMxTiMhVhmhL6JuZ3+ZDNaG0RoOIthfrEy2/bsdBgX4a /PXKNgptw5y3Xs3VjShZ7BLjdSWNuAc= X-Google-Smtp-Source: AAOMgpcRthwew9Vn+IuPAv3NL3IpTC6Yr4XqhvpeUbRXxVUOsOYxGRvHnWzJhgR5v5oVDA6NVVD7tA== X-Received: by 2002:a6b:a082:: with SMTP id j124-v6mr16855620ioe.35.1532529284529; Wed, 25 Jul 2018 07:34:44 -0700 (PDT) Received: from [192.168.1.105] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id h21-v6sm849379itf.33.2018.07.25.07.34.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jul 2018 07:34:44 -0700 (PDT) To: Vincent Roca Cc: tsvwg@ietf.org References: <153251220347.15477.4964875960468719912@ietfa.amsl.com> <02E6BC9D-2A8C-4489-BA31-7DB0F0195F0E@inria.fr> From: Wesley Eddy Message-ID: Date: Wed, 25 Jul 2018 10:34:40 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <02E6BC9D-2A8C-4489-BA31-7DB0F0195F0E@inria.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-fecframe-ext-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 14:34:58 -0000 On 7/25/2018 6:10 AM, Vincent Roca wrote: > Hello Wes, all, > > We have just updated the FECFRAME extension and RLC FEC Scheme for > FECFRAME I-Ds as > discussed during IETF 102 meeting. Those updates fix a few typos, > slightly improve text, add > an acknowledgment section. We authors do not think it requires a new WGLC. > > Hi Vincent, one part of the shepherd write-up asks us to make sure that if any other RFCs are updated, obsoleted, etc., that it's indicated properly. As this document explains, it extends but doesn't replace RFC 6363. One could see this as a definite case for having it say "Updates: 6363" in the header.  Do you agree, or was there a reason I've forgotten why we decided not to indicate that? From nobody Wed Jul 25 08:00:11 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B53A130E72 for ; Wed, 25 Jul 2018 08:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 306Ncp4gMAmC for ; Wed, 25 Jul 2018 08:00:07 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 A1260130E0C for ; Wed, 25 Jul 2018 08:00:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.51,401,1526335200"; d="scan'208";a="340268543" Received: from demeter.inrialpes.fr ([194.199.28.3]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jul 2018 17:00:05 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Vincent Roca In-Reply-To: Date: Wed, 25 Jul 2018 17:00:04 +0200 Cc: Vincent Roca , tsvwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <153251220347.15477.4964875960468719912@ietfa.amsl.com> <02E6BC9D-2A8C-4489-BA31-7DB0F0195F0E@inria.fr> To: Wesley Eddy X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-fecframe-ext-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 15:00:10 -0000 > Le 25 juil. 2018 =C3=A0 16:34, Wesley Eddy a = =C3=A9crit : >=20 > On 7/25/2018 6:10 AM, Vincent Roca wrote: >> Hello Wes, all, >>=20 >> We have just updated the FECFRAME extension and RLC FEC Scheme for = FECFRAME I-Ds as >> discussed during IETF 102 meeting. Those updates fix a few typos, = slightly improve text, add >> an acknowledgment section. We authors do not think it requires a new = WGLC. >=20 > Hi Vincent, one part of the shepherd write-up asks us to make sure = that if any other RFCs are updated, obsoleted, etc., that it's indicated = properly. >=20 > As this document explains, it extends but doesn't replace RFC 6363. >=20 > One could see this as a definite case for having it say "Updates: = 6363" in the header. Do you agree, or was there a reason I've forgotten = why we decided not to indicate that? I think the question has never been asked like that. My first idea, back in 2016, was to replace RFC 6363 altogether. Then David had this key remark that in fact we just want to extend RFC = 6363 and the title reflects this. I don=E2=80=99t know what =C2=AB updates RFC 6363 =C2=BB implies = exactly. If =C2=AB updates =C2=BB implies =C2=AB replaces =C2=BB then = the answer is no. RFC 6363 will remain as is, without any change, we just = add a new capability to it. The new FECFRAME standard should now be understood as the combination: RFC 6363 + RFC XXX (this doc). Does it answer? Cheers, Vincent From nobody Wed Jul 25 08:11:07 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A0412DD85 for ; Wed, 25 Jul 2018 08:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-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 062qkheSczR9 for ; Wed, 25 Jul 2018 08:11:01 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D588F126CC7 for ; Wed, 25 Jul 2018 08:11:01 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id p81-v6so9144599itp.1 for ; Wed, 25 Jul 2018 08:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=/huvpWiCEd23sQoXekhwmZE/DDa2QwqTihBqIJpRA/E=; b=ZelIayitUyFIJmTjltVlqaa/agBh9gGubeGDHD2piULDjiJbL+ROO436nMwCKIFbZg 6G2EF4V0uubp4Q6bROIGqP0dtpYc3iIQAE9dpEUKgtfmaUKHFGgrlfOlDj3nrtL2koiG b2MS4+cqMIUZJSHl3s12sCXiiAJ9n0P5Z7OPjtckdIWXHhcmOPtjwjSoRCZlmOuQLp5L PU4Diwz/GgtrRwdlFs5rM3GjsgTawsMIZ+q8Nm2Xa5i7B0p1dIK80mgU0tEROEcy+J4z 7F7NV61sTYkGgZgOLE0TyfeENxuCpSLrKteImJKyHj5XjG5tCLM0sbwNzMijobtcEx1S J7nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=/huvpWiCEd23sQoXekhwmZE/DDa2QwqTihBqIJpRA/E=; b=gRuP/JpeS3X+VayAIBVPv/T2sTQnXWeOTXgFbg7MkxEB12RjlhVjFVvvH2acPXeaiQ oZM/+XtkTv5V9jpBxUAoOSC9V/NEgHgpclWHZO8x/8Drp9dolKMFg2oJMUkKXN7tsDsr jyDpz4L4CR6jdlGKQrHKCuPFZHDOPgwxXeq+7gUUwv57PI5iZ5KfLjYVKVbIfbS3PPoD +JKnxnzAGWpurfFik5/PE05jHCmXKAoEQNJBu3svci9iqru8T7VH5EfnRvVtGQBlES59 nzZ0PHABjhy5jFUnG7BclUyg3bQXLIWOVRH9qRNkbtlFcMc1PJRdOm+2i7IIYCxEAzNv MsNQ== X-Gm-Message-State: AOUpUlFmreKwGDUrq+u/WRnx7kI7hXAnwKaGZCmfqyGJwIRP9zdYFO75 zUzvk0dtqZo33a32IKWjS5x23isWFGg= X-Google-Smtp-Source: AAOMgpegmozXzk+6KcUfFZKkCMAPuENm2OgWlw16l7LoxZFHz7uZUKASD635geeHttj3auKAqzAn+w== X-Received: by 2002:a24:b101:: with SMTP id o1-v6mr6340640itf.121.1532531460525; Wed, 25 Jul 2018 08:11:00 -0700 (PDT) Received: from [192.168.1.105] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id h123-v6sm2682902itb.32.2018.07.25.08.10.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jul 2018 08:10:59 -0700 (PDT) To: Vincent Roca Cc: tsvwg@ietf.org References: <153251220347.15477.4964875960468719912@ietfa.amsl.com> <02E6BC9D-2A8C-4489-BA31-7DB0F0195F0E@inria.fr> From: Wesley Eddy Message-ID: <51a3a5d9-0bbd-ecbd-6701-daf129cc7947@mti-systems.com> Date: Wed, 25 Jul 2018 11:10:57 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B8E9AFE88A5346E7B05CDD88" Content-Language: en-US Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-fecframe-ext-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 15:11:06 -0000 This is a multi-part message in MIME format. --------------B8E9AFE88A5346E7B05CDD88 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/25/2018 11:00 AM, Vincent Roca wrote: >> Le 25 juil. 2018 à 16:34, Wesley Eddy a écrit : >> Hi Vincent, one part of the shepherd write-up asks us to make sure that if any other RFCs are updated, obsoleted, etc., that it's indicated properly. >> >> As this document explains, it extends but doesn't replace RFC 6363. >> >> One could see this as a definite case for having it say "Updates: 6363" in the header. Do you agree, or was there a reason I've forgotten why we decided not to indicate that? > I think the question has never been asked like that. > > My first idea, back in 2016, was to replace RFC 6363 altogether. > Then David had this key remark that in fact we just want to extend RFC 6363 and the title reflects this. > > I don’t know what « updates RFC 6363 » implies exactly. If « updates » implies « replaces » then the > answer is no. RFC 6363 will remain as is, without any change, we just add a new capability to it. > > The new FECFRAME standard should now be understood as the combination: > RFC 6363 + RFC XXX (this doc). > It sounds like "Updates" has the right semantics then.  What we don't want is "Obsoletes". FYI, it's defined in 2223: Updates To be used as a reference from a new item that cannot be used alone (i.e., one that supplements a previous document), to refer to the previous document. The newer publication is a part that will supplement or be added on to the existing document; e.g., an addendum, or separate, extra information that is to be added to the original document. --------------B8E9AFE88A5346E7B05CDD88 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 7/25/2018 11:00 AM, Vincent Roca wrote:
Le 25 juil. 2018 à 16:34, Wesley Eddy <wes@mti-systems.com> a écrit :
Hi Vincent, one part of the shepherd write-up asks us to make sure that if any other RFCs are updated, obsoleted, etc., that it's indicated properly.

As this document explains, it extends but doesn't replace RFC 6363.

One could see this as a definite case for having it say "Updates: 6363" in the header.  Do you agree, or was there a reason I've forgotten why we decided not to indicate that?
I think the question has never been asked like that.

My first idea, back in 2016, was to replace RFC 6363 altogether.
Then David had this key remark that in fact we just want to extend RFC 6363 and the title reflects this.

I don’t know what « updates RFC 6363 » implies exactly. If « updates » implies « replaces » then the
answer is no. RFC 6363 will remain as is, without any change, we just add a new capability to it.

The new FECFRAME standard should now be understood as the combination:
	RFC 6363 + RFC XXX (this doc).


It sounds like "Updates" has the right semantics then.  What we don't want is "Obsoletes".

FYI, it's defined in 2223:
   Updates

      To be used as a reference from a new item that cannot be used
      alone (i.e., one that supplements a previous document), to refer
      to the previous document.  The newer publication is a part that
      will supplement or be added on to the existing document; e.g., an
      addendum, or separate, extra information that is to be added to
      the original document.

--------------B8E9AFE88A5346E7B05CDD88-- From nobody Wed Jul 25 08:21:20 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7829F12F1AC for ; Wed, 25 Jul 2018 08:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=DbaQUwOY; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=Ac+MM3zP 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 lE0wEekv2mXc for ; Wed, 25 Jul 2018 08:21:16 -0700 (PDT) Received: from esa4.dell-outbound.iphmx.com (esa4.dell-outbound.iphmx.com [68.232.149.214]) (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 153C51271FF for ; Wed, 25 Jul 2018 08:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1532532076; x=1564068076; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=p7cAc13P0OaDJ5EeNu2vlYgLP3mmCZLJlcl1vV8F4os=; b=DbaQUwOY4yzTS44kLCbwRZ+n5pW4Ey8Yy2cs6keWrkTMYdQqhPMIOzqY Mvsfmo1kqQi3v7tu9op8ymDMJk3z+X3MkTqcmGvL1oPA4DRpODW9Adtgk KdRABU2swGKdyR2vaGxog7YPKcTFOlJ+seY+slysiYY0NRPEPCzF1BCqI Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2HDAACQlFhbhz+a6ERcGgEBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYJ5gjYoCoN0iAaMO4IMgzuSDoE/OwsuhD4CF4JQITQYAQIBAQIBAQI?= =?us-ascii?q?BAQIQAQEBCgsJCCkjDII1JAEOSy8IMwEBAQEBAQEBAQEBAQEBAQEBARcCQxMCG?= =?us-ascii?q?AEBAQMBIxEMHxoBBAcEAgEIEQQBAQECAgYdAwICAjAUAQgIAgQBDQUIgxiBeAg?= =?us-ascii?q?BsBSBLoJ6h1cIgQuGYIEXgVk+gRFGgkyEfxWCajGCJJl3AwQCAp0yj2CCJgIEA?= =?us-ascii?q?gQFAhSBQYILcC+DCoIzg06KUm+NVoEbAQE?= X-IPAS-Result: =?us-ascii?q?A2HDAACQlFhbhz+a6ERcGgEBAQEBAgEBAQEIAQEBAYJ5gjY?= =?us-ascii?q?oCoN0iAaMO4IMgzuSDoE/OwsuhD4CF4JQITQYAQIBAQIBAQIBAQIQAQEBCgsJC?= =?us-ascii?q?CkjDII1JAEOSy8IMwEBAQEBAQEBAQEBAQEBAQEBARcCQxMCGAEBAQMBIxEMHxo?= =?us-ascii?q?BBAcEAgEIEQQBAQECAgYdAwICAjAUAQgIAgQBDQUIgxiBeAgBsBSBLoJ6h1cIg?= =?us-ascii?q?QuGYIEXgVk+gRFGgkyEfxWCajGCJJl3AwQCAp0yj2CCJgIEAgQFAhSBQYILcC+?= =?us-ascii?q?DCoIzg06KUm+NVoEbAQE?= Received: from esa3.dell-outbound2.iphmx.com ([68.232.154.63]) by esa4.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jul 2018 10:21:14 -0500 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jul 2018 21:19:49 +0600 Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w6PFLBIC013573 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 25 Jul 2018 11:21:13 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com w6PFLBIC013573 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1532532074; bh=6IzSwhTQYFxwXcZ5imA1Yl/akLM=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Ac+MM3zPsKw7KYt+nTyUXUtuLiBu7ef0ozeY6oWNyni8HrCWrGXjxsOXj53ne3YIZ F+voybjByKnaKnf/0YpZHUdWh5DvgxTdoNNZMbJ0Xy2TDWExKfJ3eLcVQIpjBWjJM6 XFZ+71e7xdqQu4tPs7ujaNkoDsQmtgZWC7/ketDk= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com w6PFLBIC013573 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd52.lss.emc.com (RSA Interceptor); Wed, 25 Jul 2018 11:20:52 -0400 Received: from MXHUB313.corp.emc.com (MXHUB313.corp.emc.com [10.146.3.91]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w6PFKpnf030950 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 25 Jul 2018 11:20:51 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB313.corp.emc.com ([10.146.3.91]) with mapi id 14.03.0399.000; Wed, 25 Jul 2018 11:20:51 -0400 To: Vincent Roca , Wesley Eddy CC: "tsvwg@ietf.org" Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-fecframe-ext-03.txt Thread-Index: AQHUI/zpOGNwdIC8uEKz3EODtSA7yqSf+n+AgABJ0gCAAAcZAP//vo5A Date: Wed, 25 Jul 2018 15:20:50 +0000 Message-ID: References: <153251220347.15477.4964875960468719912@ietfa.amsl.com> <02E6BC9D-2A8C-4489-BA31-7DB0F0195F0E@inria.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.21.34] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-fecframe-ext-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 15:21:19 -0000 PiBJIGRvbuKAmXQga25vdyB3aGF0IMKrIHVwZGF0ZXMgUkZDIDYzNjMgwrsgaW1wbGllcyBleGFj dGx5LiBJZiDCqyB1cGRhdGVzIMK7DQo+IGltcGxpZXMgwqsgcmVwbGFjZXMgwrsgdGhlbiB0aGUN Cj4gYW5zd2VyIGlzIG5vLiBSRkMgNjM2MyB3aWxsIHJlbWFpbiBhcyBpcywgd2l0aG91dCBhbnkg Y2hhbmdlLCB3ZSBqdXN0IGFkZCBhDQo+IG5ldyBjYXBhYmlsaXR5IHRvIGl0Lg0KDQpIZXJlLCAi dXBkYXRlcyIgbWVhbnMgImV4dGVuZHMgb3IgbW9kaWZpZXMuIiAgICBMb29raW5nIGF0IHRoZSB0 d28gZHJhZnRzLCB0aGVyZSBhcHBlYXIgdG8gYmUgdHdvIGRpZmZlcmVudCBvdXRjb21lcy4NCg0K MSkgVGhlIGZlY2ZyYW1lLWV4dCBkcmFmdCBjbGVhcmx5IGV4dGVuZHMgdGhlIFJGQyA2MzYzIGZy YW1ld29yay4gICBJbiBhZGRpdGlvbiwgU2VjdGlvbiA1LjMgZGVmaW5pdGVseSBtb2RpZmllcyBS RkMgNjM2MywgYXMgaW5kaWNhdGVkIGJ5IHRoZSBmaXJzdCBwYXJhZ3JhcGggaW4gdGhhdCBzZWN0 aW9uOg0KDQogICBUaGUgRkVDIFNjaGVtZSByZXF1aXJlbWVudHMgb2YgW1JGQzYzNjNdLCBTZWN0 aW9uIDUuNiwgbW9zdGx5IGFwcGx5DQogICB0byB0aGlzIEZFQ0ZSQU1FIGV4dGVuc2lvbiBhbmQg YXJlIG5vdCByZXBlYXRlZCBoZXJlLiAgQW4gZXhjZXB0aW9uDQogICB0aG91Z2ggaXMgdGhlICJm dWxsIHNwZWNpZmljYXRpb24gb2YgdGhlIEZFQyBjb2RlIiwgaXRlbSAoNCksIHRoYXQgaXMNCiAg IHNwZWNpZmljIHRvIGJsb2NrIEZFQyBjb2Rlcy4gIFRoZSBmb2xsb3dpbmcgaXRlbSAoNCkgYXBw bGllcyBpbiBjYXNlDQogICBvZiBTbGlkaW5nIFdpbmRvdyBGRUMgc2NoZW1lczoNCg0KU28sIGl0 IGxvb2tzIGxpa2UgdGhlIGZlY2ZyYW1lLWV4dCBkcmFmdCBuZWVkIGFuICJVcGRhdGVzOiA2MzYz IiBoZWFkZXIsIGFuZCB0aGUgZHJhZnQgd2lsbCBuZWVkIGEgc2VjdGlvbiBzdW1tYXJpemluZyBj aGFuZ2VzIHRvIFJGQyA2MzYzIC0gYXQgbGVhc3QgdGhlIHNlY3Rpb24gNS4zIGNoYW5nZSwgYW5k IGFsc28gaWRlbnRpZnlpbmcgYW55IG5vcm1hdGl2ZSB0ZXh0IGluIFJGQyA2MzYzIHRoYXQgZG9l c24ndCBhcHBseSB0byBTbGlkaW5nIFdpbmRvdyBDb2Rlcy4NCg0KMikgSW4gY29udHJhc3QsIHRo ZSBybGMtZmVjLXNjaGVtZSBkcmFmdCBhcHBlYXJzIHRvIHVzZSB0aGUgUkZDIDYzNjMgZnJhbWV3 b3JrIGFzIGV4dGVuZGVkIGJ5IHRoZSBmZWNmcmFtZS1leHQgZHJhZnQgd2l0aG91dCBtb2RpZnlp bmcgdGhhdCBmcmFtZXdvcmsuICBJZiB0aGF0IGlzIGNvcnJlY3QsIGl0IGRvZXMgbm90IG5lZWQg YW4gIlVwZGF0ZXM6IDYzNjMiIGhlYWRlciwgYXMgYWxsIHRoZSBjaGFuZ2VzICYgZXh0ZW5zaW9u cyB0byBSRkMgNjM2MyBvdWdodCB0byBiZSBpbiB0aGUgZmVjZnJhbWUtZXh0IGRyYWZ0Lg0KDQpU aGFua3MsIC0tRGF2aWQNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0 c3Z3ZyBbbWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBWaW5jZW50 IFJvY2ENCj4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDI1LCAyMDE4IDExOjAwIEFNDQo+IFRvOiBX ZXNsZXkgRWRkeQ0KPiBDYzogdHN2d2dAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt0c3Z3Z10g SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10c3Z3Zy1mZWNmcmFtZS1leHQtMDMudHh0DQo+IA0KPiA+ IExlIDI1IGp1aWwuIDIwMTggw6AgMTY6MzQsIFdlc2xleSBFZGR5IDx3ZXNAbXRpLXN5c3RlbXMu Y29tPiBhIMOpY3JpdCA6DQo+ID4NCj4gPiBPbiA3LzI1LzIwMTggNjoxMCBBTSwgVmluY2VudCBS b2NhIHdyb3RlOg0KPiA+PiBIZWxsbyBXZXMsIGFsbCwNCj4gPj4NCj4gPj4gV2UgaGF2ZSBqdXN0 IHVwZGF0ZWQgdGhlIEZFQ0ZSQU1FIGV4dGVuc2lvbiBhbmQgUkxDIEZFQyBTY2hlbWUgZm9yDQo+ IEZFQ0ZSQU1FIEktRHMgYXMNCj4gPj4gZGlzY3Vzc2VkIGR1cmluZyBJRVRGIDEwMiBtZWV0aW5n LiBUaG9zZSB1cGRhdGVzIGZpeCBhIGZldyB0eXBvcywgc2xpZ2h0bHkNCj4gaW1wcm92ZSB0ZXh0 LCBhZGQNCj4gPj4gYW4gYWNrbm93bGVkZ21lbnQgc2VjdGlvbi4gV2UgYXV0aG9ycyBkbyBub3Qg dGhpbmsgaXQgcmVxdWlyZXMgYSBuZXcNCj4gV0dMQy4NCj4gPg0KPiA+IEhpIFZpbmNlbnQsIG9u ZSBwYXJ0IG9mIHRoZSBzaGVwaGVyZCB3cml0ZS11cCBhc2tzIHVzIHRvIG1ha2Ugc3VyZSB0aGF0 IGlmDQo+IGFueSBvdGhlciBSRkNzIGFyZSB1cGRhdGVkLCBvYnNvbGV0ZWQsIGV0Yy4sIHRoYXQg aXQncyBpbmRpY2F0ZWQgcHJvcGVybHkuDQo+ID4NCj4gPiBBcyB0aGlzIGRvY3VtZW50IGV4cGxh aW5zLCBpdCBleHRlbmRzIGJ1dCBkb2Vzbid0IHJlcGxhY2UgUkZDIDYzNjMuDQo+ID4NCj4gPiBP bmUgY291bGQgc2VlIHRoaXMgYXMgYSBkZWZpbml0ZSBjYXNlIGZvciBoYXZpbmcgaXQgc2F5ICJV cGRhdGVzOiA2MzYzIiBpbiB0aGUNCj4gaGVhZGVyLiAgRG8geW91IGFncmVlLCBvciB3YXMgdGhl cmUgYSByZWFzb24gSSd2ZSBmb3Jnb3R0ZW4gd2h5IHdlIGRlY2lkZWQNCj4gbm90IHRvIGluZGlj YXRlIHRoYXQ/DQo+IA0KPiBJIHRoaW5rIHRoZSBxdWVzdGlvbiBoYXMgbmV2ZXIgYmVlbiBhc2tl ZCBsaWtlIHRoYXQuDQo+IA0KPiBNeSBmaXJzdCBpZGVhLCBiYWNrIGluIDIwMTYsIHdhcyB0byBy ZXBsYWNlIFJGQyA2MzYzIGFsdG9nZXRoZXIuDQo+IFRoZW4gRGF2aWQgaGFkIHRoaXMga2V5IHJl bWFyayB0aGF0IGluIGZhY3Qgd2UganVzdCB3YW50IHRvIGV4dGVuZCBSRkMgNjM2Mw0KPiBhbmQg dGhlIHRpdGxlIHJlZmxlY3RzIHRoaXMuDQo+IA0KPiBJIGRvbuKAmXQga25vdyB3aGF0IMKrIHVw ZGF0ZXMgUkZDIDYzNjMgwrsgaW1wbGllcyBleGFjdGx5LiBJZiDCqyB1cGRhdGVzIMK7DQo+IGlt cGxpZXMgwqsgcmVwbGFjZXMgwrsgdGhlbiB0aGUNCj4gYW5zd2VyIGlzIG5vLiBSRkMgNjM2MyB3 aWxsIHJlbWFpbiBhcyBpcywgd2l0aG91dCBhbnkgY2hhbmdlLCB3ZSBqdXN0IGFkZCBhDQo+IG5l dyBjYXBhYmlsaXR5IHRvIGl0Lg0KPiANCj4gVGhlIG5ldyBGRUNGUkFNRSBzdGFuZGFyZCBzaG91 bGQgbm93IGJlIHVuZGVyc3Rvb2QgYXMgdGhlIGNvbWJpbmF0aW9uOg0KPiAJUkZDIDYzNjMgKyBS RkMgWFhYICh0aGlzIGRvYykuDQo+IA0KPiBEb2VzIGl0IGFuc3dlcj8NCj4gQ2hlZXJzLA0KPiAN Cj4gICBWaW5jZW50DQoNCg== From nobody Wed Jul 25 12:59:12 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383B2130E36 for ; Wed, 25 Jul 2018 12:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 r