From nobody Sun Jul 2 08:43:42 2017 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 A3397126CB6 for ; Sun, 2 Jul 2017 08:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 vGxTa68BSqpv for ; Sun, 2 Jul 2017 08:43:38 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1F71E1204DA for ; Sun, 2 Jul 2017 08:43:38 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 8AF401B0010C for ; Sun, 2 Jul 2017 18:37:34 +0100 (BST) Message-ID: <5959149B.806@erg.abdn.ac.uk> Date: Sun, 02 Jul 2017 16:43:23 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tsvwg] Request to publish draft-ietf-tsvwg-ecn-experimentation-03 as PS X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 15:43:42 -0000 The WG of this document has concluded, and the results of the reviews have been incorporated (-03). On behalf of TSVWG, I have submitted the write-up below to our AD (Spencer) with a request for publication as a PS. Thank you to all who contributed to this work, and reviewed the progress. Best wishes, Gorry (TSVWG Co-Chair) ---- Explicit Congestion Notification (ECN) Experimentation draft-ietf-tsvwg-ecn-experimentation-03 As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Standards Track, PS. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This memo updates RFC 3168, which specifies Explicit Congestion Notification (ECN) as a replacement for packet drops as indicators of network congestion. It relaxes restrictions in RFC 3168 that would otherwise hinder experimentation towards benefits beyond just removal of loss. The memo summarizes the anticipated areas of experimentation and updates RFC 3168 to enable experimentation in these areas. An Experimental RFC is required to take advantage of any of these enabling updates. In addition, this memo makes related updates to the ECN specifications for RTP in RFC 6679 and for DCCP in RFC 4341, RFC 4342 and RFC 5622. The memo also records the conclusion of the ECN Nonce experiment in RFC 3540, and provides the rationale for reclassification of RFC 3540 as Historic; this reclassification enables new experimental use of the ECT(1) codepoint. Working Group Summary: The document was adopted by the working group to enable two specific pieces of work - ABE (now in TCPM) and L4S (now a working group item in TSVWG). Both these items of work curently have experimental status, yet seek to modify the ECN specification produced by TSVWG - specifically to obsolete the ECN NONCE. This topic has been discussed in TSVWG over many years and it is finally the consensus that the experiment has concluded and that the ECN NONCE specification is no longer recommended for deployment. Document Quality: The document is ready to publish. Personnel: Who is the Document Shepherd? Gorry Fairhurst Who is the Responsible Area Director? Spencer Dawkins (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document has received significant review by several people in TSVWG - both as an individual submission and as as WG draft, including detailed feedback from M Welzl and B Briscoe. Minor updates were made in response to last call comments and this document is therefore ready to proceed. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. This draft has been reviewed many times. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. The author confirms that he knows of no IPR for this document. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures known. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document has been presented to the WG and there was consensus on the document during WGLC. Minor issues were raised, and changes have been incorporated in this revision of the ID. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. None. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not required. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. None. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This memo does not make a request to IANA. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. This memo does not include a request for a new registry to IANA. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. None. From nobody Sun Jul 2 23:36:37 2017 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 6A49E129B51 for ; Sun, 2 Jul 2017 23:36: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] 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 HarW7HsFBTmi for ; Sun, 2 Jul 2017 23:36:34 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 2BC871243FE for ; Sun, 2 Jul 2017 23:36:33 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1dRuyF-0005d4-5y; Mon, 03 Jul 2017 08:36:31 +0200 Received: from [IPv6:::1] (localhost [127.0.0.1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id F300BB0070B; Mon, 3 Jul 2017 08:36:30 +0200 (CEST) To: "Black, David" , "tsvwg@ietf.org" References: From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) Message-ID: Date: Mon, 3 Jul 2017 08:36:30 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1499063791.248984217 Archived-At: Subject: Re: [tsvwg] LE PHB -01 draft comments (from David Black) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 06:36:36 -0000 Hi David, thanks for the review. I hope I addressed most of your points in the new -02 version of the draft. More inline. On 04.03.2017 at 00:59 Black, David wrote: > First of all, thanks for working on this draft to help clean up a > long-standing set of problems around Lower Effort traffic marking and > handling. I’ve done a relatively thorough review of this draft, and > listed comments in order of occurrence. Technical issues that need > some attention are noted with ** for minor issue and **** for major > issues, and summarized here: > > > > ** Section 1.2 - I wonder whether the 2nd and 3rd bullets are overstated. Tried to be more precise in -02. > **** Section 3 - First paragraph needs some attention as it seems to > switch back and forth between networks in general and networks with full > support for LE Good point, I also tried to separate this a bit more. > > **** Section 5 - “MUST remark” requirement, is not backwards compatible > with RFC 4594, needs WG discussion I'll send a separate mail for this. > ** Section 7 - IANA Considerations need some attention Yep, but see below... > ** Section 8 - Mention of traffic “downgraded” to LE seems to conflict > with recommendations not to downgrade to LE elsewhere. Rephrased this section. [...deleted several comments...] > Also, I just notice that the header on the middle column of the IANA > registry is “Space” - it should be “Codepoint”: The registry is correct. It just lists the codpoint _pools_ first. First column is Pool, the second "Codepoint Space". There is nothing wrong with that. Then Pool1 assigned DSCPs are listed. Regards, Roland > IANA is also requested to correct the header of the middle column > > of the Pool 1 Codepoints table in that registry by changing it from > > “Space” to “Codepoint”. I didn't follow this suggestions due to the prior given reason. Regards, Roland From nobody Mon Jul 3 01:08:07 2017 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 6F26212EB4A; Mon, 3 Jul 2017 01:08:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149906928134.4897.13823109116655940075@ietfa.amsl.com> Date: Mon, 03 Jul 2017 01:08:01 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rfc4960-errata-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 08:08:01 -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 of the IETF. Title : RFC 4960 Errata and Issues Authors : Randall R. Stewart Michael Tuexen Maksim Proshin Filename : draft-ietf-tsvwg-rfc4960-errata-02.txt Pages : 59 Date : 2017-07-03 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 based 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-02 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc4960-errata-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc4960-errata-02 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 3 01:19:37 2017 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 AF6D3131480; Mon, 3 Jul 2017 01:19:32 -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.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149906997269.5014.10735968404635658068@ietfa.amsl.com> Date: Mon, 03 Jul 2017 01:19:32 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-11.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 08:19:33 -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 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-11.txt Pages : 44 Date : 2017-07-03 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-11 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-natsupp-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-natsupp-11 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 3 02:28:37 2017 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 E5778131546; Mon, 3 Jul 2017 02:28:29 -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, 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=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 c2OAVN7XnPM6; Mon, 3 Jul 2017 02:28:27 -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 7843F13153B; Mon, 3 Jul 2017 02:28:27 -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=9ihgR4Crk0JDgl+J3D1WYo6Ggt9XrRpsRy8EdaP8ZqQ=; b=xC+5DopYDlLIXOO5DLZ9tWULz5 gG4qytO8mi376mI186zBIwgrkIfXDEF5WF6NQLxmB/h2EDr8b0aTMNU+4qynmYAiO8KbRNeGY0np/ yUvDPhU0krCQn4j3XS0rt+B+mMxqftfgRx2mzqO9dxEl2E8wB4Q8bdPEoDou46dmXWRKw7fWKfzTt /vDaTLg1UxUxFNYmGQXgaaaNxeDdDL9PLUUFejffHnMgtiSeaX2QKmj+vMrrjMZ+Hv33AbWpNxTBy REkZZIUdhM9c7XpznzPKw/eBlIfGBZw1MPYOHYcyaHWe2DSQenalKP8zlSM6uIYYMQ6zijoTqdL6z Rp+sAKwA==; Received: from [31.185.128.124] (port=36640 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dRxeb-0000SI-Sy; Mon, 03 Jul 2017 10:28:26 +0100 To: "tcpm-chairs@ietf.org" , "tsvwg-chairs@ietf.org" , tcpm IETF list , tsvwg IETF list , "tsv-ads@ietf.org" From: Bob Briscoe Message-ID: <6e08e177-6096-4cd7-4388-43b52c9e597a@bobbriscoe.net> Date: Mon, 3 Jul 2017 10:28:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------07D7B434AEA72D1B6277C2A8" 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] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 09:28:30 -0000 This is a multi-part message in MIME format. --------------07D7B434AEA72D1B6277C2A8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, tcpm list, tsvwg list, There has been some offlist discussion (among different sub-groups) to narrow down the options here. It is time to see opinions from the two affected WGs (tcpm and tsvwg) on preferred process, esp. from the WG chairs and ADs. *==Background to the Process Problem==** * In tsvwg the process is in motion to make the ECN nonce [RFC 3540] historic. So, in the most recent rev of draft-ietf-tcpm-accurate-ecn-03 , we could finally include IANA assignment of the NS flag (see https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6 ) However, AccECN is EXPerimental, whereas the registry policy for assigning TCP flags is "Standards Action" https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml which means "Values are assigned only for Standards Track RFCs approved by the IESG" [RFC2434]. References: Process for designating RFCs as historic: https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html Current draft text to make RFC 3540 historic: https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3 My initial draft for the AD's status change note: https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt ecn-experimentation has just completed WGLC. It still has to go through IETF LC (after Prague). it is deliberately PS in order to be able to relax pre-existing constraints on ECN experiments in standards track RFCs. However, if poss, we want to avoid adding motivating text for a 4th experiment, which could require another cycle of WGLC and delay until Nov. RFC 3692 ("Assigning Experimental and Testing Numbers Considered Useful") could also be relevant, although it doesn't seem to help here, because it is primarily aimed at larger codepoint spaces, not single bits. *==Process Options==** * There need to be two parts to the process: 1) unassignment and 2) reassignment. The first seems clear-cut. The second is less obvious. 1) Unassigning the NS flag from RFC 3540 a) add text to IANA considerations section of ecn-experientation making the NS flag reserved 2) Assigning the NS flag to accurate-ecn (and renaming it the AE flag). Process options: a) ecn-experimentation assigns flag to itself as reserved for experiments and says initially the AccECN experiment will use it exclusively b) ecn-experimentation assigns NS flag exclusively to AccECN c) AccECN assigns NS flag to itself, with a process exception proposed to the IESG to allow an EXP doc to assign to a Standards Action registry d) the NS flag is reassigned by "AD review comment" or "IETF Last Call comment" (quoted from David's suggestions) e) other?... The difference between (a) and (b) is in the document that ends up being referenced from the IANA registry: a) ecn-experimentation b) accurate-ecn *==My own preferences==** * During discussions, I didn't prefer (c) cos I thought the IESG might question why they are being asked to make a process exception for an ECN experiment at the same time as a draft is going through that avoids raising process exceptions for ECN experiments. Nonetheless, since then, Mirja has said... On 02/07/17 23:40, Mirja Kühlewind wrote: > I actually prefer option (c). I don’t think a process exception is a bad thing. If it’s the right thing to do, then that the reason why we have such exceptions. Also I think it’d be the right thing to change the registry policy… but that probably a longer story. I agree that it is outdated that the registry requires a standards action, because it has become normal tcpm practice for any change to TCP to have to start on the experimental track. So this would justify a process exception. So, in summary, I don't mind (a), (b) or (c). I think (d) is not sufficiently open and recorded for assignment of a flag in the main TCP header. Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------07D7B434AEA72D1B6277C2A8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, tcpm list, tsvwg list,

There has been some offlist discussion (among different sub-groups) to narrow down the options here. It is time to see opinions from the two affected WGs (tcpm and tsvwg) on preferred process, esp. from the WG chairs and ADs.

==Background to the Process Problem==

In tsvwg the process is in motion to make the ECN nonce [RFC 3540] historic. So, in the most recent rev of draft-ietf-tcpm-accurate-ecn-03 , we could finally include IANA assignment of the NS flag
    (see https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6 )

However, AccECN is EXPerimental, whereas the registry policy for assigning TCP flags is "Standards Action"
    https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml
which means "Values are assigned only for Standards Track RFCs approved by the IESG" [RFC2434].

References:
    Process for designating RFCs as historic:
        https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html
    Current draft text to make RFC 3540 historic:
        https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3
    My initial draft for the AD's status change note:
        https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt

ecn-experimentation has just completed WGLC. It still has to go through IETF LC (after Prague). it is deliberately PS in order to be able to relax pre-existing constraints on ECN experiments in standards track RFCs. However, if poss, we want to avoid adding motivating text for a 4th experiment, which could require another cycle of WGLC and delay until Nov.

RFC 3692 ("Assigning Experimental and Testing Numbers Considered Useful") could also be relevant, although it doesn't seem to help here, because it is primarily aimed at larger codepoint spaces, not single bits.


==Process Options==

There need to be two parts to the process: 1) unassignment and 2) reassignment. The first seems clear-cut. The second is less obvious.

1) Unassigning the NS flag from RFC 3540
a) add text to IANA considerations section of ecn-experientation making the NS flag reserved

2) Assigning the NS flag to accurate-ecn (and renaming it the AE flag).
Process options:
a) ecn-experimentation assigns flag to itself as reserved for experiments and says initially the AccECN experiment will use it exclusively
b) ecn-experimentation assigns NS flag exclusively to AccECN
c) AccECN assigns NS flag to itself, with a process exception proposed to the IESG to allow an EXP doc to assign to a Standards Action registry
d) the NS flag is reassigned by "AD review comment" or "IETF Last Call comment" (quoted from David's suggestions)
e) other?...

The difference between (a) and (b) is in the document that ends up being referenced from the IANA registry:
a)  ecn-experimentation
b) accurate-ecn

==My own preferences==

During discussions, I didn't prefer (c) cos I thought the IESG might question why they are being asked to make a process exception for an ECN experiment at the same time as a draft is going through that avoids raising process exceptions for ECN experiments.

Nonetheless, since then, Mirja has said...

On 02/07/17 23:40, Mirja Kühlewind wrote:
I actually prefer option (c). I don’t think a process exception is a bad thing. If it’s the right thing to do, then that the reason why we have such exceptions. Also I think it’d be the right thing to change the registry policy… but that probably a longer story.
I agree that it is outdated that the registry requires a standards action, because it has become normal tcpm practice for any change to TCP to have to start on the experimental track. So this would justify a process exception.

So, in summary, I don't mind (a), (b) or (c). I think (d) is not sufficiently open and recorded for assignment of a flag in the main TCP header.


Bob


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------07D7B434AEA72D1B6277C2A8-- From nobody Mon Jul 3 10:15:07 2017 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 504751315F6; Mon, 3 Jul 2017 10:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.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_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, 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 6vYvPpoagqyb; Mon, 3 Jul 2017 10:15:01 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A8CE12EC33; Mon, 3 Jul 2017 10:15:01 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 5D0BA9827E; Mon, 3 Jul 2017 13:14:57 -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=BnE zFx1LXOh/6g3/CyZKIo2D6+s=; b=EUXJCcQeDbtEUG2VnrHUcvqdfn8vvSgaQER 8+bHMyk/zbwjRlxb33VuJ9YsSsV1lSxK2ZiVy2jApEvF81w3V3Y0ZcoVeb1Qvrwd jifrgmudHqoz92/BbG+HOUEx2dqDw9/CizlfL58GIyePf7O2TH9pEmuRuyDI0wu6 f7dfxJRI= 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= nDHdbjaM2KRK24HoUYIhBlPZgUez1dUV49th9y6DaeR7LZ64nlqWFc6lpDReZ86Y U34VwuuB6s34aK9luhUkkvfDGV0SNDhaUpxMgWa2HGTa2ykn8ZWaCQ+BKjnZ1J43 H0xFOvfNHyvAObOrny/5g0ulYtmza1V3iA2CoMS0dew= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 5551E9827D; Mon, 3 Jul 2017 13:14:57 -0400 (EDT) Received: from mail-qt0-f179.google.com (unknown [209.85.216.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id C76A998278; Mon, 3 Jul 2017 13:14:55 -0400 (EDT) Received: by mail-qt0-f179.google.com with SMTP id 32so148207602qtv.1; Mon, 03 Jul 2017 10:14:55 -0700 (PDT) X-Gm-Message-State: AKS2vOx5ZTstAZWvz8TEw4eBI3Blb3+4Z76Acx7TJxpqN1+Y3/U3mKSy HWB6XNXLEv86vmTIQhEvypY+o47GQg== X-Received: by 10.200.45.59 with SMTP id n56mr41705144qta.15.1499102095335; Mon, 03 Jul 2017 10:14:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.106.182 with HTTP; Mon, 3 Jul 2017 10:14:34 -0700 (PDT) From: "C. M. Heard" Date: Mon, 3 Jul 2017 10:14:34 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Bob Briscoe Cc: tcpm , tcpm-chairs , tsvwg , tsvwg-chairs , tsv-ads Content-Type: multipart/alternative; boundary="001a1142ae36dfe6b605536ce7b9" X-Pobox-Relay-ID: 228B968C-6013-11E7-8A80-61520C78B957-06080547!pb-smtp2.pobox.com Archived-At: Subject: Re: [tsvwg] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 17:15:04 -0000 --001a1142ae36dfe6b605536ce7b9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Bob, Couldn't the text in the IANA considerations of ecn-experimentation (which needs to be updated in any case) both change the NS flag to Reserved for ECN Experimentation and change the allocation policy for that flag from Standards Action to IETF Review, thereby updating RFC 2780? That would avoid the churn needed to add motivating text for a 4th experiment to ecn-experimentation and would allow AccECN to assign the NS bit itself without a process exception. Mike Heard On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote: > Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, tcpm list, tsvwg > list, > > There has been some offlist discussion (among different sub-groups) to > narrow down the options here. It is time to see opinions from the two > affected WGs (tcpm and tsvwg) on preferred process, esp. from the WG chai= rs > and ADs. > > *=3D=3DBackground to the Process Problem=3D=3D* > > In tsvwg the process is in motion to make the ECN nonce [RFC 3540] > historic. So, in the most recent rev of draft-ietf-tcpm-accurate-ecn-03 , > we could finally include IANA assignment of the NS flag > (see https://tools.ietf.org/html/draft-ietf-tcpm-accurate- > ecn-03#section-6 ) > > However, AccECN is EXPerimental, whereas the registry policy for assignin= g > TCP flags is "Standards Action" > https://www.iana.org/assignments/tcp-header-flags/ > tcp-header-flags.xhtml > which means "Values are assigned only for Standards Track RFCs approved b= y > the IESG" [RFC2434]. > > References: > Process for designating RFCs as historic: > https://www.ietf.org/iesg/statement/designating-rfcs-as- > historic.html > Current draft text to make RFC 3540 historic: > https://tools.ietf.org/html/draft-ietf-tsvwg-ecn- > experimentation-03#section-3 > My initial draft for the AD's status change note: > https://github.com/bbriscoe/ecn-experimentation/ > blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt > > ecn-experimentation has just completed WGLC. It still has to go through > IETF LC (after Prague). it is deliberately PS in order to be able to rela= x > pre-existing constraints on ECN experiments in standards track RFCs. > However, if poss, we want to avoid adding motivating text for a 4th > experiment, which could require another cycle of WGLC and delay until Nov= . > > RFC 3692 ("Assigning Experimental and Testing Numbers Considered Useful") > could also be relevant, although it doesn't seem to help here, because it > is primarily aimed at larger codepoint spaces, not single bits. > > > *=3D=3DProcess Options=3D=3D* > > There need to be two parts to the process: 1) unassignment and 2) > reassignment. The first seems clear-cut. The second is less obvious. > > 1) Unassigning the NS flag from RFC 3540 > a) add text to IANA considerations section of ecn-experientation making > the NS flag reserved > > 2) Assigning the NS flag to accurate-ecn (and renaming it the AE flag). > Process options: > a) ecn-experimentation assigns flag to itself as reserved for experiments > and says initially the AccECN experiment will use it exclusively > b) ecn-experimentation assigns NS flag exclusively to AccECN > c) AccECN assigns NS flag to itself, with a process exception proposed to > the IESG to allow an EXP doc to assign to a Standards Action registry > d) the NS flag is reassigned by "AD review comment" or "IETF Last Call > comment" (quoted from David's suggestions) > e) other?... > > The difference between (a) and (b) is in the document that ends up being > referenced from the IANA registry: > a) ecn-experimentation > b) accurate-ecn > > *=3D=3DMy own preferences=3D=3D* > > During discussions, I didn't prefer (c) cos I thought the IESG might > question why they are being asked to make a process exception for an ECN > experiment at the same time as a draft is going through that avoids raisi= ng > process exceptions for ECN experiments. > > Nonetheless, since then, Mirja has said... > > On 02/07/17 23:40, Mirja K=C3=BChlewind wrote: > > I actually prefer option (c). I don=E2=80=99t think a process exception i= s a bad thing. If it=E2=80=99s the right thing to do, then that the reason = why we have such exceptions. Also I think it=E2=80=99d be the right thing t= o change the registry policy=E2=80=A6 but that probably a longer story. > > I agree that it is outdated that the registry requires a standards action= , > because it has become normal tcpm practice for any change to TCP to have = to > start on the experimental track. So this would justify a process exceptio= n. > > So, in summary, I don't mind (a), (b) or (c). I think (d) is not > sufficiently open and recorded for assignment of a flag in the main TCP > header. > > > Bob > > --001a1142ae36dfe6b605536ce7b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Bob,

Couldn't the text in the IANA considerations of e= cn-experimentation (which needs to be updated in any case) both change the = NS flag to Reserved for ECN Experimentation and change the allocation polic= y for that flag from Standards Action to IETF Review, thereby updating RFC = 2780? That would avoid the churn needed to add motivating text for a 4th ex= periment to ecn-experimentation and would allow AccECN to assign the NS bit= itself without a process exception.

Mike Heard

On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe= =C2=A0wrote:

Michael*2, Yoshif= umi, Gorry, David, Wes, Mirja, Spencer, tcpm list, tsvwg list,

There has been some offlist dis= cussion (among different sub-groups) to narrow down the options here. It is= time to see opinions from the two affected WGs (tcpm and tsvwg) on preferr= ed process, esp. from the WG chairs and ADs.

=3D=3DBackground to the Process Problem=3D=3D

In tsvwg the process = is in motion to make the ECN nonce [RFC 3540] historic. So, in the most rec= ent rev of draft-ietf-tcpm-accurate-ecn-03 , we could finally include = IANA assignment of the NS flag
=C2=A0=C2=A0=C2=A0 (see=C2=A0https://tools.ie= tf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6=C2=A0)<= br style=3D"color:rgb(0,0,0);font-family:Times;font-size:medium">
However, AccECN is EXPeri= mental, whereas the registry policy for assigning TCP flags is "Standa= rds Action"
=C2=A0=C2=A0=C2=A0=C2=A0https://www.iana.org/assign= ments/tcp-header-flags/tcp-header-flags.xhtml
which means "Values are assigned= only for Standards Track RFCs approved by the IESG" [RFC2434].=

References:
=C2=A0=C2=A0=C2=A0 Proc= ess for designating RFCs as historic:=C2=A0
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2= =A0https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html
=C2=A0=C2=A0=C2=A0 Current draft text to make RFC 3540 historic:=C2=A0<= /span>
=C2=A0=C2= =A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/<= wbr>html/draft-ietf-tsvwg-ecn-experimentation-03#section-3
=C2=A0=C2=A0=C2=A0 My in= itial draft for the AD's status change note:=C2=A0
=C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0https://gi= thub.com/bbriscoe/ecn-experimentation/blob/master/status-change-e= cn-nonce-rfc3540-to-historic-00.txt

ecn-experimentation has just completed WGLC. It sti= ll has to go through IETF LC (after Prague). it is deliberately PS in order= to be able to relax pre-existing constraints on ECN experiments in standar= ds track RFCs. However, if poss, we want to avoid adding motivating text fo= r a 4th experiment, which could require another cycle of WGLC and delay unt= il Nov.=C2=A0

RFC 3= 692 ("Assigning Experimental and Testing Numbers Considered Useful&quo= t;) could also be relevant, although it doesn't seem to help here, beca= use it is primarily aimed at larger codepoint spaces, not single bits.


=3D=3DProcess Options=3D=3D

There need to be two p= arts to the process: 1) unassignment and 2) reassignment. The first seems c= lear-cut. The second is less obvious.

1) Unassigning the NS flag from RFC 3540
a) add text to IANA consi= derations section of ecn-experientation making the NS flag reserved<= br style=3D"color:rgb(0,0,0);font-family:Times;font-size:medium">
2) Assigning the NS flag = to accurate-ecn (and renaming it the AE flag).=C2=A0
Process options:
a) ecn-experimentation as= signs flag to itself as reserved for experiments and says initially the Acc= ECN experiment will use it exclusively=C2=A0
b) ecn-experimentation assigns NS flag e= xclusively to AccECN=C2=A0
c) AccECN assigns NS flag to itself, with a process except= ion proposed to the IESG to allow an EXP doc to assign to a Standards Actio= n registry=C2=A0
d) the NS flag is reassigned by "AD review comment" or &qu= ot;IETF Last Call comment" (quoted from David's suggestions)
e) other?...

The difference betwee= n (a) and (b) is in the document that ends up being referenced from the IAN= A registry:=C2=A0
a)=C2=A0 ecn-experimentation=C2=A0
b) accurate-ecn=C2=A0

=3D=3DMy own preferences=3D=3D

During discussions, I did= n't prefer (c) cos I thought the IESG might question why they are being= asked to make a process exception for an ECN experiment at the same time a= s a draft is going through that avoids raising process exceptions for ECN e= xperiments.=C2=A0

N= onetheless, since then, Mirja has said...

On 02/07/17 23:40, Mirja K=C3=BChlewind wrote:
= 
I actually prefer option (c). I don=E2=80=99t think a process exceptio=
n is a bad thing. If it=E2=80=99s the right thing to do, then that the reas=
on why we have such exceptions. Also I think it=E2=80=99d be the right thin=
g to change the registry policy=E2=80=A6 but that probably a longer story.<=
/pre>
I agree that it is outdated that the registry requires a standar= ds action, because it has become normal tcpm practice for any change to TCP= to have to start on the experimental track. So this would justify a proces= s exception.

So, in= summary, I don't mind (a), (b) or (c). I think (d) is not sufficiently= open and recorded for assignment of a flag in the main TCP header.<= br style=3D"color:rgb(0,0,0);font-family:Times;font-size:medium">

Bob

--001a1142ae36dfe6b605536ce7b9-- From nobody Mon Jul 3 11:05:24 2017 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 85E891296CF; Mon, 3 Jul 2017 11:05:22 -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, 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=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 2EomowD5gDnC; Mon, 3 Jul 2017 11:05:19 -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 516CA129503; Mon, 3 Jul 2017 11:05:18 -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:From:References:Cc: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=cY1eQNJLFtvRhmdzshQU6T1CCWLMPy5e8lYOCCR4RV8=; b=0VRAkwn6Kh1LITy+lQEHaK3JA 2nqlvbN3wUsowIjTdhsr8cfk2cPtuTI53Izrcnr9qMssoe6mhfe5s/7dLspiEYGO8lZ0MfsFNr6Vh mRmTptHzFt7SzQnjI0O1RMgDmDY2VU18GxdVmnlHG6ekoycTpadJ62d0zpE8y60fOhCKW5QhKG25d cxyQgDieKI67hN7SiNkU0XMfkVx8bYDcANyTd1rfgoUxC0CtAlnujr+vHXd4mQ7rDAh3BxEbaAAhb fN3+XjpzEeMslQ0X80dj4+rNt/zuYxGgWGr81ODQKqpnkHKsEXuETqy3G/pGz7PE49SLTUBrUSs86 WAcIGneuw==; Received: from [31.185.128.124] (port=46270 helo=[192.168.0.13]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dS5im-0002xi-76; Mon, 03 Jul 2017 19:05:16 +0100 To: "C. M. Heard" Cc: tcpm , tcpm-chairs , tsvwg , tsvwg-chairs , tsv-ads References: From: Bob Briscoe Message-ID: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> Date: Mon, 3 Jul 2017 19:05:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1B39A03FE90EB3B56B3451C8" 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] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 18:05:22 -0000 This is a multi-part message in MIME format. --------------1B39A03FE90EB3B56B3451C8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Mike, Let's call this option: (e) ecn-experimentation alters the registry policy of bit 7 of the TCP header to "IETF Review". Having a different policy for certain bits within a registry might send IANA into a spin, but I am sure they could write suitable text into the registry policy if they had to. I quite like this one. Altho unorthodox, it's neat. Thank you. Bob PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as a 2-bit field during the 3-way hand-shake. While the ECN Nonce and AccECN use the three ECN flags (bits 7-9) as a 3-bit field during the 3WHS. AccECN uses the combinations that RFC3168 and the Nonce do not use. So to cover all bases: Option (f): ecn-experimentation alters the registry policy for bits 7-9 to "IETF Review". On 03/07/17 18:14, C. M. Heard wrote: > > Bob, > > Couldn't the text in the IANA considerations of ecn-experimentation > (which needs to be updated in any case) both change the NS flag to > Reserved for ECN Experimentation and change the allocation policy for > that flag from Standards Action to IETF Review, thereby updating RFC > 2780? That would avoid the churn needed to add motivating text for a > 4th experiment to ecn-experimentation and would allow AccECN to assign > the NS bit itself without a process exception. > > Mike Heard > > On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote: > > Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, tcpm > list, tsvwg list, > > There has been some offlist discussion (among different > sub-groups) to narrow down the options here. It is time to see > opinions from the two affected WGs (tcpm and tsvwg) on preferred > process, esp. from the WG chairs and ADs. > > *==Background to the Process Problem==** > * > In tsvwg the process is in motion to make the ECN nonce [RFC 3540] > historic. So, in the most recent rev of > draft-ietf-tcpm-accurate-ecn-03 , we could finally include IANA > assignment of the NS flag > (see > https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6 > ) > > However, AccECN is EXPerimental, whereas the registry policy for > assigning TCP flags is "Standards Action" > https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml > > which means "Values are assigned only for Standards Track RFCs > approved by the IESG" [RFC2434]. > > References: > Process for designating RFCs as historic: > https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html > > Current draft text to make RFC 3540 historic: > https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3 > > My initial draft for the AD's status change note: > https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt > > > ecn-experimentation has just completed WGLC. It still has to go > through IETF LC (after Prague). it is deliberately PS in order to > be able to relax pre-existing constraints on ECN experiments in > standards track RFCs. However, if poss, we want to avoid adding > motivating text for a 4th experiment, which could require another > cycle of WGLC and delay until Nov. > > RFC 3692 ("Assigning Experimental and Testing Numbers Considered > Useful") could also be relevant, although it doesn't seem to help > here, because it is primarily aimed at larger codepoint spaces, > not single bits. > > > *==Process Options==** > * > There need to be two parts to the process: 1) unassignment and 2) > reassignment. The first seems clear-cut. The second is less obvious. > > 1) Unassigning the NS flag from RFC 3540 > a) add text to IANA considerations section of ecn-experientation > making the NS flag reserved > > 2) Assigning the NS flag to accurate-ecn (and renaming it the AE > flag). > Process options: > a) ecn-experimentation assigns flag to itself as reserved for > experiments and says initially the AccECN experiment will use it > exclusively > b) ecn-experimentation assigns NS flag exclusively to AccECN > c) AccECN assigns NS flag to itself, with a process exception > proposed to the IESG to allow an EXP doc to assign to a Standards > Action registry > d) the NS flag is reassigned by "AD review comment" or "IETF Last > Call comment" (quoted from David's suggestions) > e) other?... > > The difference between (a) and (b) is in the document that ends up > being referenced from the IANA registry: > a) ecn-experimentation > b) accurate-ecn > > *==My own preferences==** > * > During discussions, I didn't prefer (c) cos I thought the IESG > might question why they are being asked to make a process > exception for an ECN experiment at the same time as a draft is > going through that avoids raising process exceptions for ECN > experiments. > > Nonetheless, since then, Mirja has said... > > On 02/07/17 23:40, Mirja Kühlewind wrote: >> I actually prefer option (c). I don’t think a process exception is a bad thing. If it’s the right thing to do, then that the reason why we have such exceptions. Also I think it’d be the right thing to change the registry policy… but that probably a longer story. > I agree that it is outdated that the registry requires a standards > action, because it has become normal tcpm practice for any change > to TCP to have to start on the experimental track. So this would > justify a process exception. > > So, in summary, I don't mind (a), (b) or (c). I think (d) is not > sufficiently open and recorded for assignment of a flag in the > main TCP header. > > > Bob > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------1B39A03FE90EB3B56B3451C8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Mike,

Let's call this option:
(e) ecn-experimentation alters the registry policy of bit 7 of the TCP header to "IETF Review".

Having a different policy for certain bits within a registry might send IANA into a spin, but I am sure they could write suitable text into the registry policy if they had to.

I quite like this one. Altho unorthodox, it's neat.


Thank you.


Bob

PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as a 2-bit field during the 3-way hand-shake. While the ECN Nonce and AccECN use the three ECN flags (bits 7-9) as a 3-bit field during the 3WHS. AccECN uses the combinations that RFC3168 and the Nonce do not use. So to cover all bases:

Option (f): ecn-experimentation alters the registry policy for bits 7-9 to "IETF Review".


On 03/07/17 18:14, C. M. Heard wrote:

Bob,

Couldn't the text in the IANA considerations of ecn-experimentation (which needs to be updated in any case) both change the NS flag to Reserved for ECN Experimentation and change the allocation policy for that flag from Standards Action to IETF Review, thereby updating RFC 2780? That would avoid the churn needed to add motivating text for a 4th experiment to ecn-experimentation and would allow AccECN to assign the NS bit itself without a process exception.

Mike Heard

On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote:

Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, tcpm list, tsvwg list,

There has been some offlist discussion (among different sub-groups) to narrow down the options here. It is time to see opinions from the two affected WGs (tcpm and tsvwg) on preferred process, esp. from the WG chairs and ADs.

==Background to the Process Problem==

In tsvwg the process is in motion to make the ECN nonce [RFC 3540] historic. So, in the most recent rev of draft-ietf-tcpm-accurate-ecn-03 , we could finally include IANA assignment of the NS flag
    (see https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6 )

However, AccECN is EXPerimental, whereas the registry policy for assigning TCP flags is "Standards Action"
    https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml
which means "Values are assigned only for Standards Track RFCs approved by the IESG" [RFC2434].

References:
    Process for designating RFCs as historic: 
        https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html
    Current draft text to make RFC 3540 historic: 
        https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3
    My initial draft for the AD's status change note: 
        https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt

ecn-experimentation has just completed WGLC. It still has to go through IETF LC (after Prague). it is deliberately PS in order to be able to relax pre-existing constraints on ECN experiments in standards track RFCs. However, if poss, we want to avoid adding motivating text for a 4th experiment, which could require another cycle of WGLC and delay until Nov. 

RFC 3692 ("Assigning Experimental and Testing Numbers Considered Useful") could also be relevant, although it doesn't seem to help here, because it is primarily aimed at larger codepoint spaces, not single bits.


==Process Options==

There need to be two parts to the process: 1) unassignment and 2) reassignment. The first seems clear-cut. The second is less obvious.

1) Unassigning the NS flag from RFC 3540
a) add text to IANA considerations section of ecn-experientation making the NS flag reserved

2) Assigning the NS flag to accurate-ecn (and renaming it the AE flag). 
Process options:
a) ecn-experimentation assigns flag to itself as reserved for experiments and says initially the AccECN experiment will use it exclusively 
b) ecn-experimentation assigns NS flag exclusively to AccECN 
c) AccECN assigns NS flag to itself, with a process exception proposed to the IESG to allow an EXP doc to assign to a Standards Action registry 
d) the NS flag is reassigned by "AD review comment" or "IETF Last Call comment" (quoted from David's suggestions)
e) other?...

The difference between (a) and (b) is in the document that ends up being referenced from the IANA registry: 
a)  ecn-experimentation 
b) accurate-ecn 

==My own preferences==

During discussions, I didn't prefer (c) cos I thought the IESG might question why they are being asked to make a process exception for an ECN experiment at the same time as a draft is going through that avoids raising process exceptions for ECN experiments. 

Nonetheless, since then, Mirja has said...

On 02/07/17 23:40, Mirja Kühlewind wrote:
I actually prefer option (c). I don’t think a process exception is a bad thing. If it’s the right thing to do, then that the reason why we have such exceptions. Also I think it’d be the right thing to change the registry policy… but that probably a longer story.
I agree that it is outdated that the registry requires a standards action, because it has become normal tcpm practice for any change to TCP to have to start on the experimental track. So this would justify a process exception.

So, in summary, I don't mind (a), (b) or (c). I think (d) is not sufficiently open and recorded for assignment of a flag in the main TCP header.


Bob


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------1B39A03FE90EB3B56B3451C8-- From nobody Mon Jul 3 11:18:09 2017 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 B13D2128B93; Mon, 3 Jul 2017 11:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.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_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, 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 J1V4c1CN_g49; Mon, 3 Jul 2017 11:17:58 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4CE9128CDC; Mon, 3 Jul 2017 11:17:57 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 2A68B98D95; Mon, 3 Jul 2017 14:17:57 -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=CNJrsS1l2WfYOkOoaFZ4BeqjffI=; b=cbJIda 90c6AxSTODBE/qguzikq9eTZBs6W/jFpMomlGEo7xnm6D4THswzz5NffDXYfIe2l haV2lIDSk3FXv3rQYOslzu4eHZvO4zvau4FlyPgj/ms+0Q2isW/808cQa/fM3RbO GkT25fIGCqvRxobUkCAp5FP3e1r/ftj6KLXYw= 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=IXm9BTUpL4zfku/UOccdihTAUM1pYQ6G x+jAQq54raI6Y0A9lnAcWTd0sk3Z54zcC5HjouUCz01nJmxKpTGEmA+74dIgGDR2 4EFttqq19GeXnysSJ9X1YXCpDoqsEqmjPFZfr/NyHD2FlQqVbrTFLSGsZGSB9HNb rBvQaKy6edk= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 234F398D94; Mon, 3 Jul 2017 14:17:57 -0400 (EDT) Received: from mail-qk0-f178.google.com (unknown [209.85.220.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 959B398D93; Mon, 3 Jul 2017 14:17:56 -0400 (EDT) Received: by mail-qk0-f178.google.com with SMTP id d78so151641462qkb.1; Mon, 03 Jul 2017 11:17:56 -0700 (PDT) X-Gm-Message-State: AIVw113HRDqqb76D0+/iOL8OVOU248f10BtNgFO0oooTH/SM/pmXEIjh EphztJ00ArI9wQgC00bSsHlLAJYsSg== X-Received: by 10.55.96.6 with SMTP id u6mr18191651qkb.104.1499105876170; Mon, 03 Jul 2017 11:17:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.106.182 with HTTP; Mon, 3 Jul 2017 11:17:35 -0700 (PDT) In-Reply-To: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> From: "C. M. Heard" Date: Mon, 3 Jul 2017 11:17:35 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Bob Briscoe Cc: tcpm , tcpm-chairs , tsvwg , tsvwg-chairs , tsv-ads Content-Type: multipart/alternative; boundary="94eb2c0562f83addff05536dc9d9" X-Pobox-Relay-ID: F0134318-601B-11E7-A3C9-61520C78B957-06080547!pb-smtp2.pobox.com Archived-At: Subject: Re: [tsvwg] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 18:18:02 -0000 --94eb2c0562f83addff05536dc9d9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Bob, I think that your option (f) is better than option (e) (what I suggested). As an aside, either one patches up an apparent process violation committed by RFC 3540, an experimental RFC that assigned bit 7 in contradiction to the policy in RFC 2780. Mike Heard On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe wrote: > Mike, > > Let's call this option: > (e) ecn-experimentation alters the registry policy of bit 7 of the TCP > header to "IETF Review". > > Having a different policy for certain bits within a registry might send > IANA into a spin, but I am sure they could write suitable text into the > registry policy if they had to. > > I quite like this one. Altho unorthodox, it's neat. > > > Thank you. > > > Bob > > PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as a 2-bit > field during the 3-way hand-shake. While the ECN Nonce and AccECN use the > three ECN flags (bits 7-9) as a 3-bit field during the 3WHS. AccECN uses > the combinations that RFC3168 and the Nonce do not use. So to cover all > bases: > > Option (f): ecn-experimentation alters the registry policy for bits 7-9 t= o > "IETF Review". > > > On 03/07/17 18:14, C. M. Heard wrote: > > Bob, > > Couldn't the text in the IANA considerations of ecn-experimentation (whic= h > needs to be updated in any case) both change the NS flag to Reserved for > ECN Experimentation and change the allocation policy for that flag from > Standards Action to IETF Review, thereby updating RFC 2780? That would > avoid the churn needed to add motivating text for a 4th experiment to > ecn-experimentation and would allow AccECN to assign the NS bit itself > without a process exception. > > Mike Heard > > On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote: > >> Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, tcpm list, tsvw= g >> list, >> >> There has been some offlist discussion (among different sub-groups) to >> narrow down the options here. It is time to see opinions from the two >> affected WGs (tcpm and tsvwg) on preferred process, esp. from the WG cha= irs >> and ADs. >> >> *=3D=3DBackground to the Process Problem=3D=3D* >> >> In tsvwg the process is in motion to make the ECN nonce [RFC 3540] >> historic. So, in the most recent rev of draft-ietf-tcpm-accurate-ecn-03 >> , we could finally include IANA assignment of the NS flag >> (see https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ec >> n-03#section-6 ) >> >> However, AccECN is EXPerimental, whereas the registry policy for >> assigning TCP flags is "Standards Action" >> https://www.iana.org/assignments/tcp-header-flags/tcp- >> header-flags.xhtml >> which means "Values are assigned only for Standards Track RFCs approved >> by the IESG" [RFC2434]. >> >> References: >> Process for designating RFCs as historic: >> https://www.ietf.org/iesg/statement/designating-rfcs-as- >> historic.html >> Current draft text to make RFC 3540 historic: >> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experim >> entation-03#section-3 >> My initial draft for the AD's status change note: >> https://github.com/bbriscoe/ecn-experimentation/blob/ >> master/status-change-ecn-nonce-rfc3540-to-historic-00.txt >> >> ecn-experimentation has just completed WGLC. It still has to go through >> IETF LC (after Prague). it is deliberately PS in order to be able to rel= ax >> pre-existing constraints on ECN experiments in standards track RFCs. >> However, if poss, we want to avoid adding motivating text for a 4th >> experiment, which could require another cycle of WGLC and delay until No= v. >> >> RFC 3692 ("Assigning Experimental and Testing Numbers Considered Useful"= ) >> could also be relevant, although it doesn't seem to help here, because i= t >> is primarily aimed at larger codepoint spaces, not single bits. >> >> >> *=3D=3DProcess Options=3D=3D* >> >> There need to be two parts to the process: 1) unassignment and 2) >> reassignment. The first seems clear-cut. The second is less obvious. >> >> 1) Unassigning the NS flag from RFC 3540 >> a) add text to IANA considerations section of ecn-experientation making >> the NS flag reserved >> >> 2) Assigning the NS flag to accurate-ecn (and renaming it the AE flag). >> Process options: >> a) ecn-experimentation assigns flag to itself as reserved for experiment= s >> and says initially the AccECN experiment will use it exclusively >> b) ecn-experimentation assigns NS flag exclusively to AccECN >> c) AccECN assigns NS flag to itself, with a process exception proposed t= o >> the IESG to allow an EXP doc to assign to a Standards Action registry >> d) the NS flag is reassigned by "AD review comment" or "IETF Last Call >> comment" (quoted from David's suggestions) >> e) other?... >> >> The difference between (a) and (b) is in the document that ends up being >> referenced from the IANA registry: >> a) ecn-experimentation >> b) accurate-ecn >> >> *=3D=3DMy own preferences=3D=3D* >> >> During discussions, I didn't prefer (c) cos I thought the IESG might >> question why they are being asked to make a process exception for an ECN >> experiment at the same time as a draft is going through that avoids rais= ing >> process exceptions for ECN experiments. >> >> Nonetheless, since then, Mirja has said... >> >> On 02/07/17 23:40, Mirja K=C3=BChlewind wrote: >> >> I actually prefer option (c). I don=E2=80=99t think a process exception = is a bad thing. If it=E2=80=99s the right thing to do, then that the reason= why we have such exceptions. Also I think it=E2=80=99d be the right thing = to change the registry policy=E2=80=A6 but that probably a longer story. >> >> I agree that it is outdated that the registry requires a standards >> action, because it has become normal tcpm practice for any change to TCP= to >> have to start on the experimental track. So this would justify a process >> exception. >> >> So, in summary, I don't mind (a), (b) or (c). I think (d) is not >> sufficiently open and recorded for assignment of a flag in the main TCP >> header. >> >> >> Bob >> >> > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > --94eb2c0562f83addff05536dc9d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bob,

I think that your option (f) is be= tter than option (e) (what I suggested). As an aside, either one patches up= an apparent process violation committed by RFC 3540, an experimental RFC t= hat assigned bit 7 in contradiction to the policy in RFC 2780.
Mike Heard

On Mon, Jul 3, 2017 at 11:= 05 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
<= div class=3D"gmail_extra">
=20 =20 =20
Mike,

Let's call this option:
(e) ecn-experimentation alters the registry policy of bit 7 of the TCP header to "IETF Review".

Having a different policy for certain bits within a registry might send IANA into a spin, but I am sure they could write suitable text into the registry policy if they had to.

I quite like this one. Altho unorthodox, it's neat.


Thank you.


Bob

PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as a 2-bit field during the 3-way hand-shake. While the ECN Nonce and AccECN use the three ECN flags (bits 7-9) as a 3-bit field during the 3WHS. AccECN uses the combinations that RFC3168 and the Nonce do not use. So to cover all bases:

Option (f): ecn-experimentation alters the registry policy for bits 7-9 to "IETF Review".


On 03/07/17 18:14, = C. M. Heard wrote:

Bob,

Couldn't the text = in the IANA considerations of ecn-experimentation (which needs to be updated in any case) both change the NS flag to Reserved for ECN Experimentation and change the allocation policy for that flag from Standards Action to IETF Review, thereby updating RFC 2780? That would avoid the churn needed to add motivating text for a 4th experiment to ecn-experimentation and would allow AccECN to assign the NS bit itself without a process exception.

Mike Heard

On Mon, 3 Jul 2017 10:= 28:25 +0100, Bob Briscoe=C2=A0wrote:

Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, tcpm list, tsvwg list,

There has been some offlist discussion (among different sub-groups) to narrow down the options here. It is time to see opinions from the two affected WGs (tcpm and tsvwg) on preferred process, esp. from the WG chairs and ADs.

=3D=3DBackground to the Process Problem=3D=3D

In tsvwg the process is in motion to make the ECN nonce [RFC 3540] historic. So, in the most recent rev of draft-ietf-tcpm-accurate-ecn-03 , we could finally include IANA assignment of the NS flag
=C2=A0=C2=A0=C2=A0 (see=C2=A0https://tools.iet= f.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6=C2=A0)
However, AccECN is EXPerimental, whereas the registry policy for assigning TCP flags is "Standards Action"<= br style=3D"color:rgb(0,0,0);font-family:Times;font-size:medium"> =C2=A0=C2=A0=C2=A0=C2=A0https://w= ww.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml
which means "Values are assigned only for Standards Track RF= Cs approved by the IESG" [RFC2434].

References:
=C2=A0=C2=A0=C2=A0 Process for designating RFCs as historic:=C2=A0
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0https= ://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html<= /a>
=C2=A0=C2=A0=C2=A0 Current draft text to make RFC 3540 historic:=C2=A0<= br style=3D"color:rgb(0,0,0);font-family:Times;font-size:medium"> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentati= on-03#section-3
=C2=A0=C2=A0=C2=A0 My initial draft for the AD's status change note:=C2=A0=
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0https://github.com/bbriscoe/ecn-ex= perimentation/blob/master/status-change-ecn-nonce-rfc3540-to-hist= oric-00.txt

ecn-experimentation has just completed WGLC. It still has to go through IETF LC (after Prague). it is deliberately PS in order to be able to relax pre-existing constraints on ECN experiments in standards track RFCs. However, if poss, we want to avoid adding motivating text for a 4th experiment, which could require another cycle of WGLC and delay until Nov.=C2=A0

RFC 3692 ("Assigning Experimental and Testing Numbers Considered Useful") could also be relevant, although i= t doesn't seem to help here, because it is primarily aime= d at larger codepoint spaces, not single bits.


=3D=3DProcess Options=3D=3D

There need to be two parts to the process: 1) unassignment and 2) reassignment. The first seems clear-cut. The second is less obvious.

1) Unassigning the NS flag from RFC 3540
a) add text to IANA considerations section of ecn-experientation making the NS flag reserved

2) Assigning the NS flag to accurate-ecn (and renaming it the AE flag).=C2=A0
Process options:
a) ecn-experimentation assigns flag to itself as reserved for experiments and says initially the AccECN experiment will use it exclusively=C2=A0
b) ecn-experimentation assigns NS flag exclusively to AccECN=C2=A0
c) AccECN assigns NS flag to itself, with a process exception proposed to the IESG to allow an EXP doc to assign to a Standards Action registry=C2=A0
d) the NS flag is reassigned by "AD review comment" = or "IETF Last Call comment" (quoted from David's suggestions)
e) other?...

The difference between (a) and (b) is in the document that ends up being referenced from the IANA registry:=C2=A0
a)=C2=A0 ecn-experimentation=C2=A0
b) accurate-ecn=C2=A0

=3D=3DMy own preferences=3D=3D

During discussions, I didn't prefer (c) cos I thought the IESG might question why they are being asked to make a process exception for an ECN experiment at the same time as a draft is going through that avoids raising process exceptions for ECN experiments.=C2=A0

Nonetheless, since then, Mirja has said...

On 02/07/17 23:40, Mirja K=C3=BChlewind wrote:
I actually prefer option (c). I don=E2=80=99t think a =
process exception is a bad thing. If it=E2=80=99s the right thing to do, th=
en that the reason why we have such exceptions. Also I think it=E2=80=99d b=
e the right thing to change the registry policy=E2=80=A6 but that probably =
a longer story.
I agree that it is outdated that the registry requires a standards action, because it has become normal tcpm practice for any change to TCP to have to start on the experimental track. So this would justify a process exception.

So, in summary, I don't mind (a), (b) or (c). I think (d) i= s not sufficiently open and recorded for assignment of a flag in the main TCP header.


Bob


--=20
________________________________________________________________
Bob Briscoe                               ht=
tp://bobbriscoe.net/

--94eb2c0562f83addff05536dc9d9-- From nobody Mon Jul 3 14:04:43 2017 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 C63C7128B4E; Mon, 3 Jul 2017 14:04:34 -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, 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=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 0sn3Wfg-y1SX; Mon, 3 Jul 2017 14:04:31 -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 D4C35131451; Mon, 3 Jul 2017 14:04:24 -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:From:References:Cc: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=G6pPXnJ2uY0clnNZMYdqKTMVxq0QsdY35abucZgm3bE=; b=nc2tv+m5MWkznGYPKbsnGFtUm d3UQKbQuSExNCFkq5yLgrwx8a7EzCn5z1gCqQbj7cVXHaumJ5E7Uvc+TNTInesMnT/Z4QZ/JGG0R5 Dg2NOtIg54Brc2tcROSoeiGkUpMJlvJwD4oj7g0ES22aKd53ThdN6MIr+4p4Qb8qSHMDN0HoH4CFd LZfinGD4xmaBi31V5k/96V1V0QUjTkbdQFwDEkIDDOqicrxonytAK6SkQWjf+R81jwiMXPwNR+0Vi pIjq3vgwZOBPx/DjQ2tlRmJCC6O6AK9XJ0q8YvWzzlH8Wl5aqUblkxsirwymVLdey0283FJI9oqBg QW4Wyg7YA==; Received: from [31.185.128.124] (port=46542 helo=[192.168.0.13]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dS8W6-0007nR-QK; Mon, 03 Jul 2017 22:04:23 +0100 To: "C. M. Heard" Cc: tcpm , tcpm-chairs , tsvwg , tsvwg-chairs , tsv-ads References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> From: Bob Briscoe Message-ID: <4deec720-6773-fca4-6797-37bb5c845d70@bobbriscoe.net> Date: Mon, 3 Jul 2017 22:04:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E1BE2F5300F5F36BDE64B2AA" 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] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 21:04:35 -0000 This is a multi-part message in MIME format. --------------E1BE2F5300F5F36BDE64B2AA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Mike, It may not be so straightforward. * It is relatively easy to justify changing the policy for the flag that is released by making the Nonce historic, which ecn-experimentation is already giving rationale for. * Strictly it would require text to justify changing the registry policy for the other 2 flags that are still assigned to RFC3168 on the standards track. This is actually a symptom of a larger problem with the registry for these flags. The registry assigns bits to single RFCs as individual binary flags, but they are not being used like this. AccECN used combinations of the ECN flags and states of the TCP state-machine that had not yet been used together, in order to increase the available state space. RFC 3168 and RFC3540 also did this, and I'm sure people can think of many other TCP-based protocols that have done this. However, we still imagine that individual flags are assigned to individual RFCs. Option (e) reinforces this delusion, whereas option (f) challenges it. Hence option (e) 'feels' more acceptable, as long as you screw up your eyes and avoid thinking too much. I doubt anyone wants to "go there" right now. But here's text that could be used in "an RFC" (TBA) to change the whole TCP flags registry policy to reflect what is actually happening in practice: option (g) It has become typical practice for the TCP maintenance working group to expect any change to TCP to be documented as an experimental RFC and for the experiment to be deployed and proved in practice before committing technology to the standards track. RFC3168 assigned the CWR and ECE flags for its own use as single bits and RFC3540 assigned the NS flag for its own use as another single bit. However, during TCP's handshake both these RFCs use combinations of these bits as codepoints, not independent binary flags. RFC3168 and RFC3540 also give these bits different meanings when used after the handshake. So these three bits are effectively being used in combination with the SYN and ACK flags to increase the available state space in novel ways. Assigning TCP header flags as individual bits wastes all the combinations that these two RFCs and other existing RFCs do not use. The present document [ecn-experimentation] recognizes that * assigning TCP flags individually and exclusively to standards track RFCs is no longer typical practice; * the TCP flags are actually being used in novel ways that are not amenable to simple registration by IANA; * current innovation in this space is in spite of the "standards action" registry policy rather than because of it. Therefore the registry policy as a whole is changed to "IETF Review". Bob On 03/07/17 19:17, C. M. Heard wrote: > Bob, > > I think that your option (f) is better than option (e) (what I > suggested). As an aside, either one patches up an apparent process > violation committed by RFC 3540, an experimental RFC that assigned bit > 7 in contradiction to the policy in RFC 2780. > > Mike Heard > > On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe > wrote: > > Mike, > > Let's call this option: > (e) ecn-experimentation alters the registry policy of bit 7 of the > TCP header to "IETF Review". > > Having a different policy for certain bits within a registry might > send IANA into a spin, but I am sure they could write suitable > text into the registry policy if they had to. > > I quite like this one. Altho unorthodox, it's neat. > > > Thank you. > > > Bob > > PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as a > 2-bit field during the 3-way hand-shake. While the ECN Nonce and > AccECN use the three ECN flags (bits 7-9) as a 3-bit field during > the 3WHS. AccECN uses the combinations that RFC3168 and the Nonce > do not use. So to cover all bases: > > Option (f): ecn-experimentation alters the registry policy for > bits 7-9 to "IETF Review". > > > On 03/07/17 18:14, C. M. Heard wrote: >> >> Bob, >> >> Couldn't the text in the IANA considerations of >> ecn-experimentation (which needs to be updated in any case) both >> change the NS flag to Reserved for ECN Experimentation and change >> the allocation policy for that flag from Standards Action to IETF >> Review, thereby updating RFC 2780? That would avoid the churn >> needed to add motivating text for a 4th experiment to >> ecn-experimentation and would allow AccECN to assign the NS bit >> itself without a process exception. >> >> Mike Heard >> >> On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote: >> >> Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, tcpm >> list, tsvwg list, >> >> There has been some offlist discussion (among different >> sub-groups) to narrow down the options here. It is time to >> see opinions from the two affected WGs (tcpm and tsvwg) on >> preferred process, esp. from the WG chairs and ADs. >> >> *==Background to the Process Problem==** >> * >> In tsvwg the process is in motion to make the ECN nonce [RFC >> 3540] historic. So, in the most recent rev of >> draft-ietf-tcpm-accurate-ecn-03 , we could finally include >> IANA assignment of the NS flag >> (see >> https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6 >> ) >> >> However, AccECN is EXPerimental, whereas the registry policy >> for assigning TCP flags is "Standards Action" >> https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml >> >> which means "Values are assigned only for Standards Track >> RFCs approved by the IESG" [RFC2434]. >> >> References: >> Process for designating RFCs as historic: >> https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html >> >> Current draft text to make RFC 3540 historic: >> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3 >> >> My initial draft for the AD's status change note: >> https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt >> >> >> ecn-experimentation has just completed WGLC. It still has to >> go through IETF LC (after Prague). it is deliberately PS in >> order to be able to relax pre-existing constraints on ECN >> experiments in standards track RFCs. However, if poss, we >> want to avoid adding motivating text for a 4th experiment, >> which could require another cycle of WGLC and delay until Nov. >> >> RFC 3692 ("Assigning Experimental and Testing Numbers >> Considered Useful") could also be relevant, although it >> doesn't seem to help here, because it is primarily aimed at >> larger codepoint spaces, not single bits. >> >> >> *==Process Options==** >> * >> There need to be two parts to the process: 1) unassignment >> and 2) reassignment. The first seems clear-cut. The second is >> less obvious. >> >> 1) Unassigning the NS flag from RFC 3540 >> a) add text to IANA considerations section of >> ecn-experientation making the NS flag reserved >> >> 2) Assigning the NS flag to accurate-ecn (and renaming it the >> AE flag). >> Process options: >> a) ecn-experimentation assigns flag to itself as reserved for >> experiments and says initially the AccECN experiment will use >> it exclusively >> b) ecn-experimentation assigns NS flag exclusively to AccECN >> c) AccECN assigns NS flag to itself, with a process exception >> proposed to the IESG to allow an EXP doc to assign to a >> Standards Action registry >> d) the NS flag is reassigned by "AD review comment" or "IETF >> Last Call comment" (quoted from David's suggestions) >> e) other?... >> >> The difference between (a) and (b) is in the document that >> ends up being referenced from the IANA registry: >> a) ecn-experimentation >> b) accurate-ecn >> >> *==My own preferences==** >> * >> During discussions, I didn't prefer (c) cos I thought the >> IESG might question why they are being asked to make a >> process exception for an ECN experiment at the same time as a >> draft is going through that avoids raising process exceptions >> for ECN experiments. >> >> Nonetheless, since then, Mirja has said... >> >> On 02/07/17 23:40, Mirja Kühlewind wrote: >>> I actually prefer option (c). I don’t think a process exception is a bad thing. If it’s the right thing to do, then that the reason why we have such exceptions. Also I think it’d be the right thing to change the registry policy… but that probably a longer story. >> I agree that it is outdated that the registry requires a >> standards action, because it has become normal tcpm practice >> for any change to TCP to have to start on the experimental >> track. So this would justify a process exception. >> >> So, in summary, I don't mind (a), (b) or (c). I think (d) is >> not sufficiently open and recorded for assignment of a flag >> in the main TCP header. >> >> >> Bob >> > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ > > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------E1BE2F5300F5F36BDE64B2AA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Mike,

It may not be so straightforward.
* It is relatively easy to justify changing the policy for the flag that is released by making the Nonce historic, which ecn-experimentation is already giving rationale for.
* Strictly it would require text to justify changing the registry policy for the other 2 flags that are still assigned to RFC3168 on the standards track.

This is actually a symptom of a larger problem with the registry for these flags. The registry assigns bits to single RFCs as individual binary flags, but they are not being used like this. AccECN used combinations of the ECN flags and states of the TCP state-machine that had not yet been used together, in order to increase the available state space. RFC 3168 and RFC3540 also did this, and I'm sure people can think of many other TCP-based protocols that have done this.

However, we still imagine that individual flags are assigned to individual RFCs. Option (e) reinforces this delusion, whereas option (f) challenges it. Hence option (e) 'feels' more acceptable, as long as you screw up your eyes and avoid thinking too much.



I doubt anyone wants to "go there" right now. But here's text that could be used in "an RFC" (TBA) to change the whole TCP flags registry policy to reflect what is actually happening in practice:

option (g)
It has become typical practice for the TCP maintenance working group to expect any change to TCP to be documented as an experimental RFC and for the experiment to be deployed and proved in practice before committing technology to the standards track.

RFC3168 assigned the CWR and ECE flags for its own use as single bits and RFC3540 assigned the NS flag for its own use as another single bit. However, during TCP's  handshake both these RFCs use combinations of these bits as codepoints, not independent binary flags. RFC3168 and RFC3540 also give these bits different meanings when used after the handshake. So these three bits are effectively being used in combination with the SYN and ACK flags to increase the available state space in novel ways. Assigning TCP header flags as individual bits wastes all the combinations that these two RFCs and other existing RFCs do not use.

The present document [ecn-experimentation] recognizes that
* assigning TCP flags individually and exclusively to standards track RFCs is no longer typical practice;
* the TCP flags are actually being used in novel ways that are not amenable to simple registration by IANA;
* current innovation in this space is in spite of the "standards action" registry policy rather than because of it.

Therefore the registry policy as a whole is changed to "IETF Review".



Bob


On 03/07/17 19:17, C. M. Heard wrote:
Bob,

I think that your option (f) is better than option (e) (what I suggested). As an aside, either one patches up an apparent process violation committed by RFC 3540, an experimental RFC that assigned bit 7 in contradiction to the policy in RFC 2780.

Mike Heard

On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
Mike,

Let's call this option:
(e) ecn-experimentation alters the registry policy of bit 7 of the TCP header to "IETF Review".

Having a different policy for certain bits within a registry might send IANA into a spin, but I am sure they could write suitable text into the registry policy if they had to.

I quite like this one. Altho unorthodox, it's neat.


Thank you.


Bob

PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as a 2-bit field during the 3-way hand-shake. While the ECN Nonce and AccECN use the three ECN flags (bits 7-9) as a 3-bit field during the 3WHS. AccECN uses the combinations that RFC3168 and the Nonce do not use. So to cover all bases:

Option (f): ecn-experimentation alters the registry policy for bits 7-9 to "IETF Review".


On 03/07/17 18:14, C. M. Heard wrote:

Bob,

Couldn't the text in the IANA considerations of ecn-experimentation (which needs to be updated in any case) both change the NS flag to Reserved for ECN Experimentation and change the allocation policy for that flag from Standards Action to IETF Review, thereby updating RFC 2780? That would avoid the churn needed to add motivating text for a 4th experiment to ecn-experimentation and would allow AccECN to assign the NS bit itself without a process exception.

Mike Heard

On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote:

Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, tcpm list, tsvwg list,

There has been some offlist discussion (among different sub-groups) to narrow down the options here. It is time to see opinions from the two affected WGs (tcpm and tsvwg) on preferred process, esp. from the WG chairs and ADs.

==Background to the Process Problem==

In tsvwg the process is in motion to make the ECN nonce [RFC 3540] historic. So, in the most recent rev of draft-ietf-tcpm-accurate-ecn-03 , we could finally include IANA assignment of the NS flag
    (see https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6 )

However, AccECN is EXPerimental, whereas the registry policy for assigning TCP flags is "Standards Action"
    https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml
which means "Values are assigned only for Standards Track RFCs approved by the IESG" [RFC2434].

References:
    Process for designating RFCs as historic: 
        https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html
    Current draft text to make RFC 3540 historic: 
        https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3
    My initial draft for the AD's status change note: 
        https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt

ecn-experimentation has just completed WGLC. It still has to go through IETF LC (after Prague). it is deliberately PS in order to be able to relax pre-existing constraints on ECN experiments in standards track RFCs. However, if poss, we want to avoid adding motivating text for a 4th experiment, which could require another cycle of WGLC and delay until Nov. 

RFC 3692 ("Assigning Experimental and Testing Numbers Considered Useful") could also be relevant, although it doesn't seem to help here, because it is primarily aimed at larger codepoint spaces, not single bits.


==Process Options==

There need to be two parts to the process: 1) unassignment and 2) reassignment. The first seems clear-cut. The second is less obvious.

1) Unassigning the NS flag from RFC 3540
a) add text to IANA considerations section of ecn-experientation making the NS flag reserved

2) Assigning the NS flag to accurate-ecn (and renaming it the AE flag). 
Process options:
a) ecn-experimentation assigns flag to itself as reserved for experiments and says initially the AccECN experiment will use it exclusively 
b) ecn-experimentation assigns NS flag exclusively to AccECN 
c) AccECN assigns NS flag to itself, with a process exception proposed to the IESG to allow an EXP doc to assign to a Standards Action registry 
d) the NS flag is reassigned by "AD review comment" or "IETF Last Call comment" (quoted from David's suggestions)
e) other?...

The difference between (a) and (b) is in the document that ends up being referenced from the IANA registry: 
a)  ecn-experimentation 
b) accurate-ecn 

==My own preferences==

During discussions, I didn't prefer (c) cos I thought the IESG might question why they are being asked to make a process exception for an ECN experiment at the same time as a draft is going through that avoids raising process exceptions for ECN experiments. 

Nonetheless, since then, Mirja has said...

On 02/07/17 23:40, Mirja Kühlewind wrote:
I actually prefer option (c). I don’t think a process exception is a bad thing. If it’s the right thing to do, then that the reason why we have such exceptions. Also I think it’d be the right thing to change the registry policy… but that probably a longer story.
I agree that it is outdated that the registry requires a standards action, because it has become normal tcpm practice for any change to TCP to have to start on the experimental track. So this would justify a process exception.

So, in summary, I don't mind (a), (b) or (c). I think (d) is not sufficiently open and recorded for assignment of a flag in the main TCP header.


Bob


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------E1BE2F5300F5F36BDE64B2AA-- From nobody Mon Jul 3 14:53:52 2017 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 621D1131484; Mon, 3 Jul 2017 14:53: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.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149911882338.22722.251292934880358332@ietfa.amsl.com> Date: Mon, 03 Jul 2017 14:53:43 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ieee-802-11-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 21:53:43 -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 of the IETF. Title : Diffserv to IEEE 802.11 Mapping Authors : Tim Szigeti Jerome Henry Fred Baker Filename : draft-ietf-tsvwg-ieee-802-11-04.txt Pages : 34 Date : 2017-07-03 Abstract: As internet traffic is increasingly sourced-from and destined-to wireless endpoints, it is crucial that Quality of Service be aligned between wired and wireless networks; however, this is not always the case by default. This document specifies a set Differentiated Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings to reconcile the marking recommendations offered by the IETF and the IEEE so as to maintain consistent QoS treatment between wired and IEEE 802.11 wireless networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11-04 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ieee-802-11-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ieee-802-11-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 Mon Jul 3 15:13:19 2017 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 4C3D4131637; Mon, 3 Jul 2017 15:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 wZbsaPYSIzKl; Mon, 3 Jul 2017 15:13:16 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E523131474; Mon, 3 Jul 2017 15:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4156; q=dns/txt; s=iport; t=1499119996; x=1500329596; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kLSEliLbVroslCRcG78sEfqEQ+KebQ7fJ2r4pVe7Xxo=; b=BQqWSHGedh01uR4AcOSPDoV5Z8odivpoiYS5AvVTFq48iuxLCc645Pb9 KmEtaMVi00QJHdMEqqLB7mOFYGV5m3m2Sl/tdBpRazmWx1yg7qeYoRtpR azQVbcp75bzOX3703okZGpYp+ozPDDwfJ3UFqWwsywltGwNCIuo6O65YI c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAACgwFpZ/5RdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1ljgQ4HjX6Rc5V9ghEshXACGoJhPxgBAgEBAQEBAQFrKIUYAQE?= =?us-ascii?q?BAQMjEUUMBAIBCBEEAQEDAiMDAgICMBQBCAgCBAENBQiKJxCvToImi0cBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEdgQuCHIExhk9RgyaEV4JhBZ5/AodFjDGCFVaEdIp?= =?us-ascii?q?HlS8BHziBCnUVH4c/dod/gQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.40,305,1496102400"; d="scan'208";a="263690163" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jul 2017 22:13:15 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v63MDFMT020320 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 3 Jul 2017 22:13:15 GMT Received: from xch-rcd-010.cisco.com (173.37.102.20) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 3 Jul 2017 17:13:14 -0500 Received: from xch-rcd-010.cisco.com ([173.37.102.20]) by XCH-RCD-010.cisco.com ([173.37.102.20]) with mapi id 15.00.1210.000; Mon, 3 Jul 2017 17:13:14 -0500 From: "Tim Szigeti (szigeti)" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" CC: "tsvwg@ietf.org" , "Gorry (erg)" , "Black, David" , "Ruediger.Geib@telekom.de" , "Jerome Henry (jerhenry)" , Fred Baker Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-ieee-802-11-04.txt Thread-Index: AQHS9EbfYV1g+OxAAE6BJNDf19G3YqJCp2OA Date: Mon, 3 Jul 2017 22:13:14 +0000 Message-ID: <8a55dc65ef09440db2bb97da303adafc@XCH-RCD-010.cisco.com> References: <149911882338.22722.251292934880358332@ietfa.amsl.com> In-Reply-To: <149911882338.22722.251292934880358332@ietfa.amsl.com> 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: [10.19.22.202] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ieee-802-11-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 22:13:18 -0000 V2hhdCdzIG5ldy9jaGFuZ2VkOg0KDQotIGFsbCByZWNvbW1lbmRhdGlvbnMgdG8gZHJvcCBjb2Rl cG9pbnRzIGhhdmUgYmVlbiBjb21wbGV0ZWx5IHJlbW92ZWQNCi0gYWxsIHJlY29tbWVuZGF0aW9u cyB0byByZW1hcmsgY29kZXBvaW50cyBoYXZlIGJlZW4gY29tcGxldGVseSByZW1vdmVkLCB3aXRo IHRoZSBzb2xlIGV4Y2VwdGlvbiBvZiByZWNvbW1lbmRpbmcgd2lyZWxlc3MgY2xpZW50IG9wZXJh dGluZyBzeXN0ZW1zIHRvIHJlbWFyayBwYWNrZXRzIHJlcXVlc3RpbmcgQ1M2IG9yIENTNyBtYXJr aW5nIHZhbHVlcyB0byBiZSByZW1hcmtlZCB0byBEU0NQIDAgKGFzIENTNi9DUzcgbWFya2luZyB2 YWx1ZXMgYXJlIGludGVuZGVkIHNvbGVseSBmb3IgbmV0d29yayBjb250cm9sIHByb3RvY29scywg YW5kIHN1Y2gsIHRoZXNlIHNob3VsZCBub3QgYmUgc291cmNlZCBmcm9tIHdpcmVsZXNzIGNsaWVu dCBlbmRwb2ludCBkZXZpY2VzKS0tU2VjdGlvbiA1LjEgJiA4LjINCi0gYSBzaW5nbGUgbWFwcGlu ZyByZWNvbW1lbmRhdGlvbiBpcyBwcmVzZW50ZWQgZm9yIGFsbCB3aXJlbGVzcyBkZXBsb3ltZW50 cyAoU2VjdGlvbiA0LjMpOyBob3dldmVyLCBzb21lIGFkZGl0aW9uYWwgc2VjdXJpdHkgcmVjb21t ZW5kYXRpb25zIGFyZSBvZmZlcmVkIGZvciBXaWZpLWF0LXRoZS1lZGdlIGRlcGxveW1lbnQgbW9k ZWxzLCBpbmNsdWRpbmcgbWFwcGluZyBhbGwgY29kZXBvaW50cyBub3QtaW4tdXNlIHRvIFVQIDAg KGJ1dCBhZ2Fpbiwgbm8gZHJvcHBpbmcgbm9yIERTQ1AtcmVtYXJraW5nKS0tU2VjdGlvbiA4LjIN Cg0KQWRkaXRpb25hbGx5LCBhbGwgb3RoZXIgcmVjb21tZW5kYXRpb25zLCBhZGRpdGlvbnMgYW5k IG5pdHMgZnJvbSBwcmV2aW91cyByZXZpZXdzIGhhdmUgYmVlbiBpbmNvcnBvcmF0ZWQuDQoNClRo YW5rcyBmb3IgdGhlIHJldmlld3MgYW5kIGd1aWRhbmNlLiBMb29raW5nIGZvcndhcmQgdG8gbW92 aW5nIHRoaXMgZm9yd2FyZCBpbiBQcmFndWUuDQoNCi10aW0NCg0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IHRzdndnIFttYWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIGludGVybmV0LQ0KPiBkcmFmdHNAaWV0Zi5vcmcNCj4gU2VudDogTW9u ZGF5LCBKdWx5IDAzLCAyMDE3IDI6NTQgUE0NCj4gVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0K PiBDYzogdHN2d2dAaWV0Zi5vcmcNCj4gU3ViamVjdDogW3RzdndnXSBJLUQgQWN0aW9uOiBkcmFm dC1pZXRmLXRzdndnLWllZWUtODAyLTExLTA0LnR4dA0KPiANCj4gDQo+IEEgTmV3IEludGVybmV0 LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJl Y3Rvcmllcy4NCj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgVHJhbnNwb3J0IEFy ZWEgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCj4gDQo+ICAgICAgICAgVGl0bGUgICAgICAg ICAgIDogRGlmZnNlcnYgdG8gSUVFRSA4MDIuMTEgTWFwcGluZw0KPiAgICAgICAgIEF1dGhvcnMg ICAgICAgICA6IFRpbSBTemlnZXRpDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgSmVyb21l IEhlbnJ5DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgRnJlZCBCYWtlcg0KPiAJRmlsZW5h bWUgICAgICAgIDogZHJhZnQtaWV0Zi10c3Z3Zy1pZWVlLTgwMi0xMS0wNC50eHQNCj4gCVBhZ2Vz ICAgICAgICAgICA6IDM0DQo+IAlEYXRlICAgICAgICAgICAgOiAyMDE3LTA3LTAzDQo+IA0KPiBB YnN0cmFjdDoNCj4gICAgQXMgaW50ZXJuZXQgdHJhZmZpYyBpcyBpbmNyZWFzaW5nbHkgc291cmNl ZC1mcm9tIGFuZCBkZXN0aW5lZC10bw0KPiAgICB3aXJlbGVzcyBlbmRwb2ludHMsIGl0IGlzIGNy dWNpYWwgdGhhdCBRdWFsaXR5IG9mIFNlcnZpY2UgYmUgYWxpZ25lZA0KPiAgICBiZXR3ZWVuIHdp cmVkIGFuZCB3aXJlbGVzcyBuZXR3b3JrczsgaG93ZXZlciwgdGhpcyBpcyBub3QgYWx3YXlzIHRo ZQ0KPiAgICBjYXNlIGJ5IGRlZmF1bHQuICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIHNldCBE aWZmZXJlbnRpYXRlZA0KPiAgICBTZXJ2aWNlcyBDb2RlIFBvaW50IChEU0NQKSB0byBJRUVFIDgw Mi4xMSBVc2VyIFByaW9yaXR5IChVUCkgbWFwcGluZ3MNCj4gICAgdG8gcmVjb25jaWxlIHRoZSBt YXJraW5nIHJlY29tbWVuZGF0aW9ucyBvZmZlcmVkIGJ5IHRoZSBJRVRGIGFuZCB0aGUNCj4gICAg SUVFRSBzbyBhcyB0byBtYWludGFpbiBjb25zaXN0ZW50IFFvUyB0cmVhdG1lbnQgYmV0d2VlbiB3 aXJlZCBhbmQNCj4gICAgSUVFRSA4MDIuMTEgd2lyZWxlc3MgbmV0d29ya3MuDQo+IA0KPiANCj4g VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHN2d2ctaWVlZS04MDIt MTEvDQo+IA0KPiBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6 DQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRzdndnLWllZWUtODAy LTExLTA0DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0 Zi10c3Z3Zy1pZWVlLTgwMi0xMS0wNA0KPiANCj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZl cnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQtaWV0Zi10c3Z3Zy1pZWVlLTgwMi0xMS0wNA0KPiANCj4gDQo+IFBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1 Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBh dmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy8NCg0K From nobody Mon Jul 3 15:17:55 2017 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 3AEA3131620; Mon, 3 Jul 2017 15:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 TgI77cm9tdrH; Mon, 3 Jul 2017 15:17:52 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6461B129ACD; Mon, 3 Jul 2017 15:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4020; q=dns/txt; s=iport; t=1499120272; x=1500329872; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CRvDk8e27N6YMf/T9f2d8HX5OZkffE9ncXhVBQujPdA=; b=G/VhvuTf3yLOTyRQJIzKNM8Ibj09oGDGN8WwI5byU98pL2oOOnEr/Bs7 cw8NRTZ3IuAl+CY+I8mHtFiRQkEAhMIfP/p+ah1UgWANuqdEyiD2V4j8o GetIHdL01coR6VVAYQjFhV9Y2XVo7JhtuMMTiyUdvHrfgDez5gSiwvfwX 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAAD8wVpZ/4QNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1ljgQ4HjX6Rc5V9ghEshXACGoJhPxgBAgEBAQEBAQFrKIUYAQE?= =?us-ascii?q?BAQMjEUUMBAIBCBEEAQEDAiMDAgICMBQBBgEBBQMCBAENBQiKJxCvTYImi0cBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEdgQuCHIExhk9RgyaEV4JhBZ5/AodFjDGCFVa?= =?us-ascii?q?EdIpHlS8BHziBCnUVH4c/dod/gQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.40,305,1496102400"; d="scan'208";a="263699067" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Jul 2017 22:17:51 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v63MHpj5006171 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 3 Jul 2017 22:17:51 GMT Received: from xch-rcd-010.cisco.com (173.37.102.20) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 3 Jul 2017 17:17:50 -0500 Received: from xch-rcd-010.cisco.com ([173.37.102.20]) by XCH-RCD-010.cisco.com ([173.37.102.20]) with mapi id 15.00.1210.000; Mon, 3 Jul 2017 17:17:50 -0500 From: "Tim Szigeti (szigeti)" To: "tsvwg@ietf.org" , "tsvwg-chairs@ietf.org" CC: "Black, David" , "Gorry (erg)" , Fred Baker , "Jerome Henry (jerhenry)" Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-ieee-802-11-04.txt Thread-Index: AQHS9EbfYV1g+OxAAE6BJNDf19G3YqJCq7bA Date: Mon, 3 Jul 2017 22:17:50 +0000 Message-ID: <75b0160a76ef4722be7f0a562260ad41@XCH-RCD-010.cisco.com> References: <149911882338.22722.251292934880358332@ietfa.amsl.com> In-Reply-To: <149911882338.22722.251292934880358332@ietfa.amsl.com> 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: [10.19.22.202] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [tsvwg] FW: I-D Action: draft-ietf-tsvwg-ieee-802-11-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 22:17:54 -0000 V2hhdCdzIG5ldy9jaGFuZ2VkOg0KDQotIGFsbCByZWNvbW1lbmRhdGlvbnMgdG8gZHJvcCBjb2Rl cG9pbnRzIGhhdmUgYmVlbiBjb21wbGV0ZWx5IHJlbW92ZWQNCi0gYWxsIHJlY29tbWVuZGF0aW9u cyB0byByZW1hcmsgY29kZXBvaW50cyBoYXZlIGJlZW4gY29tcGxldGVseSByZW1vdmVkLCB3aXRo IHRoZSBzb2xlIGV4Y2VwdGlvbiBvZiByZWNvbW1lbmRpbmcgd2lyZWxlc3MgY2xpZW50IG9wZXJh dGluZyBzeXN0ZW1zIHRvIHJlbWFyayBwYWNrZXRzIHJlcXVlc3RpbmcgQ1M2IG9yIENTNyBtYXJr aW5nIHZhbHVlcyB0byBiZSByZW1hcmtlZCB0byBEU0NQIDAgKGFzIENTNi9DUzcgbWFya2luZyB2 YWx1ZXMgYXJlIGludGVuZGVkIHNvbGVseSBmb3IgbmV0d29yayBjb250cm9sIHByb3RvY29scywg YW5kIHN1Y2gsIHRoZXNlIHNob3VsZCBub3QgYmUgc291cmNlZCBmcm9tIHdpcmVsZXNzIGNsaWVu dCBlbmRwb2ludCBkZXZpY2VzKS0tU2VjdGlvbiA1LjEgJiA4LjINCi0gYSBzaW5nbGUgbWFwcGlu ZyByZWNvbW1lbmRhdGlvbiBpcyBwcmVzZW50ZWQgZm9yIGFsbCB3aXJlbGVzcyBkZXBsb3ltZW50 cyAoU2VjdGlvbiA0LjMpOyBob3dldmVyLCBzb21lIGFkZGl0aW9uYWwgc2VjdXJpdHkgcmVjb21t ZW5kYXRpb25zIGFyZSBvZmZlcmVkIGZvciBXaWZpLWF0LXRoZS1lZGdlIGRlcGxveW1lbnQgbW9k ZWxzLCBpbmNsdWRpbmcgbWFwcGluZyBhbGwgY29kZXBvaW50cyBub3QtaW4tdXNlIHRvIFVQIDAg KGJ1dCBhZ2Fpbiwgbm8gZHJvcHBpbmcgbm9yIERTQ1AtcmVtYXJraW5nKS0tU2VjdGlvbiA4LjIN Cg0KQWRkaXRpb25hbGx5LCBhbGwgb3RoZXIgcmVjb21tZW5kYXRpb25zLCBhZGRpdGlvbnMgYW5k IG5pdHMgZnJvbSBwcmV2aW91cyByZXZpZXdzIGhhdmUgYmVlbiBpbmNvcnBvcmF0ZWQuDQoNClRo YW5rcyBmb3IgdGhlIHJldmlld3MgYW5kIGd1aWRhbmNlLiBMb29raW5nIGZvcndhcmQgdG8gbW92 aW5nIHRoaXMgZm9yd2FyZCBpbiBQcmFndWUuDQoNCi10aW0NCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IHRzdndnIFttYWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KU2VudDogTW9uZGF5LCBKdWx5IDAz LCAyMDE3IDI6NTQgUE0NClRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCkNjOiB0c3Z3Z0BpZXRm Lm9yZw0KU3ViamVjdDogW3RzdndnXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXRzdndnLWllZWUt ODAyLTExLTA0LnR4dA0KDQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9t IHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NClRoaXMgZHJhZnQgaXMg YSB3b3JrIGl0ZW0gb2YgdGhlIFRyYW5zcG9ydCBBcmVhIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElF VEYuDQoNCiAgICAgICAgVGl0bGUgICAgICAgICAgIDogRGlmZnNlcnYgdG8gSUVFRSA4MDIuMTEg TWFwcGluZw0KICAgICAgICBBdXRob3JzICAgICAgICAgOiBUaW0gU3ppZ2V0aQ0KICAgICAgICAg ICAgICAgICAgICAgICAgICBKZXJvbWUgSGVucnkNCiAgICAgICAgICAgICAgICAgICAgICAgICAg RnJlZCBCYWtlcg0KCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtdHN2d2ctaWVlZS04MDIt MTEtMDQudHh0DQoJUGFnZXMgICAgICAgICAgIDogMzQNCglEYXRlICAgICAgICAgICAgOiAyMDE3 LTA3LTAzDQoNCkFic3RyYWN0Og0KICAgQXMgaW50ZXJuZXQgdHJhZmZpYyBpcyBpbmNyZWFzaW5n bHkgc291cmNlZC1mcm9tIGFuZCBkZXN0aW5lZC10bw0KICAgd2lyZWxlc3MgZW5kcG9pbnRzLCBp dCBpcyBjcnVjaWFsIHRoYXQgUXVhbGl0eSBvZiBTZXJ2aWNlIGJlIGFsaWduZWQNCiAgIGJldHdl ZW4gd2lyZWQgYW5kIHdpcmVsZXNzIG5ldHdvcmtzOyBob3dldmVyLCB0aGlzIGlzIG5vdCBhbHdh eXMgdGhlDQogICBjYXNlIGJ5IGRlZmF1bHQuICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIHNl dCBEaWZmZXJlbnRpYXRlZA0KICAgU2VydmljZXMgQ29kZSBQb2ludCAoRFNDUCkgdG8gSUVFRSA4 MDIuMTEgVXNlciBQcmlvcml0eSAoVVApIG1hcHBpbmdzDQogICB0byByZWNvbmNpbGUgdGhlIG1h cmtpbmcgcmVjb21tZW5kYXRpb25zIG9mZmVyZWQgYnkgdGhlIElFVEYgYW5kIHRoZQ0KICAgSUVF RSBzbyBhcyB0byBtYWludGFpbiBjb25zaXN0ZW50IFFvUyB0cmVhdG1lbnQgYmV0d2VlbiB3aXJl ZCBhbmQNCiAgIElFRUUgODAyLjExIHdpcmVsZXNzIG5ldHdvcmtzLg0KDQoNClRoZSBJRVRGIGRh dGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10c3Z3Zy1pZWVlLTgwMi0xMS8NCg0KVGhlcmUg YXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHN2d2ctaWVlZS04MDItMTEtMDQNCmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi10c3Z3Zy1pZWVlLTgwMi0xMS0w NA0KDQpBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQpo dHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi10c3Z3Zy1pZWVlLTgw Mi0xMS0wNA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KSW50ZXJuZXQt RHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRw LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0K From nobody Mon Jul 3 16:08:52 2017 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 C0E9E131716; Mon, 3 Jul 2017 16:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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 X7UkhGPydYwD; Mon, 3 Jul 2017 16:08:41 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0266F12ECED; Mon, 3 Jul 2017 16:08:41 -0700 (PDT) Received: from [10.50.4.123] (unknown [195.1.147.78]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 0489B1B0FE06; Tue, 4 Jul 2017 00:00:32 +0100 (BST) Content-Type: multipart/alternative; boundary=Apple-Mail-93148B47-17AB-4457-9024-6916EB79DE55 Mime-Version: 1.0 (1.0) From: "Gorry (erg)" X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Mon, 3 Jul 2017 23:06:09 +0200 Cc: Bob Briscoe , tsvwg-chairs , tcpm , tsvwg , tsv-ads , tcpm-chairs Content-Transfer-Encoding: 7bit Message-Id: <49200576-B166-4FE9-8B5D-36ECA5509364@erg.abdn.ac.uk> References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> To: "C. M. Heard" Archived-At: Subject: Re: [tsvwg] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 23:08:45 -0000 --Apple-Mail-93148B47-17AB-4457-9024-6916EB79DE55 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think as document shepherd I have the input I need, but I need to talk to m= y AD about how to handle the process - and liaise with the TCPM co-chairs r= egarding the TCPM WG draft. This isn't the first time we have had to look at= the implications of making another RFC historic, and I think we can do the c= orrect thing. Gorry > On 3 Jul 2017, at 20:17, C. M. Heard wrote: >=20 > Bob, >=20 > I think that your option (f) is better than option (e) (what I suggested).= As an aside, either one patches up an apparent process violation committed b= y RFC 3540, an experimental RFC that assigned bit 7 in contradiction to the p= olicy in RFC 2780. >=20 > Mike Heard >=20 >> On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe wrote:= >=20 >> Mike, >>=20 >> Let's call this option: >> (e) ecn-experimentation alters the registry policy of bit 7 of the TCP he= ader to "IETF Review". >>=20 >> Having a different policy for certain bits within a registry might send I= ANA into a spin, but I am sure they could write suitable text into the regis= try policy if they had to. >>=20 >> I quite like this one. Altho unorthodox, it's neat. >>=20 >>=20 >> Thank you. >>=20 >>=20 >> Bob >>=20 >> PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as a 2-bit f= ield during the 3-way hand-shake. While the ECN Nonce and AccECN use the thr= ee ECN flags (bits 7-9) as a 3-bit field during the 3WHS. AccECN uses the co= mbinations that RFC3168 and the Nonce do not use. So to cover all bases: >>=20 >> Option (f): ecn-experimentation alters the registry policy for bits 7-9 t= o "IETF Review".=20 >>=20 >>=20 >>> On 03/07/17 18:14, C. M. Heard wrote: >>> Bob, >>>=20 >>> Couldn't the text in the IANA considerations of ecn-experimentation (whi= ch needs to be updated in any case) both change the NS flag to Reserved for E= CN Experimentation and change the allocation policy for that flag from Stand= ards Action to IETF Review, thereby updating RFC 2780? That would avoid the c= hurn needed to add motivating text for a 4th experiment to ecn-experimentati= on and would allow AccECN to assign the NS bit itself without a process exce= ption. >>>=20 >>> Mike Heard >>> On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote: >>>> Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, tcpm list, tsv= wg list, >>>>=20 >>>> There has been some offlist discussion (among different sub-groups) to n= arrow down the options here. It is time to see opinions from the two affecte= d WGs (tcpm and tsvwg) on preferred process, esp. from the WG chairs and ADs= . >>>>=20 >>>> =3D=3DBackground to the Process Problem=3D=3D >>>>=20 >>>> In tsvwg the process is in motion to make the ECN nonce [RFC 3540] hist= oric. So, in the most recent rev of draft-ietf-tcpm-accurate-ecn-03 , we cou= ld finally include IANA assignment of the NS flag >>>> (see https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#se= ction-6 ) >>>>=20 >>>> However, AccECN is EXPerimental, whereas the registry policy for assign= ing TCP flags is "Standards Action" >>>> https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.= xhtml >>>> which means "Values are assigned only for Standards Track RFCs approved= by the IESG" [RFC2434]. >>>>=20 >>>> References: >>>> Process for designating RFCs as historic:=20 >>>> https://www.ietf.org/iesg/statement/designating-rfcs-as-histori= c.html >>>> Current draft text to make RFC 3540 historic:=20 >>>> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentatio= n-03#section-3 >>>> My initial draft for the AD's status change note:=20 >>>> https://github.com/bbriscoe/ecn-experimentation/blob/master/sta= tus-change-ecn-nonce-rfc3540-to-historic-00.txt >>>>=20 >>>> ecn-experimentation has just completed WGLC. It still has to go through= IETF LC (after Prague). it is deliberately PS in order to be able to relax p= re-existing constraints on ECN experiments in standards track RFCs. However,= if poss, we want to avoid adding motivating text for a 4th experiment, whic= h could require another cycle of WGLC and delay until Nov.=20 >>>>=20 >>>> RFC 3692 ("Assigning Experimental and Testing Numbers Considered Useful= ") could also be relevant, although it doesn't seem to help here, because it= is primarily aimed at larger codepoint spaces, not single bits. >>>>=20 >>>>=20 >>>> =3D=3DProcess Options=3D=3D >>>>=20 >>>> There need to be two parts to the process: 1) unassignment and 2) reass= ignment. The first seems clear-cut. The second is less obvious. >>>>=20 >>>> 1) Unassigning the NS flag from RFC 3540 >>>> a) add text to IANA considerations section of ecn-experientation making= the NS flag reserved >>>>=20 >>>> 2) Assigning the NS flag to accurate-ecn (and renaming it the AE flag).= =20 >>>> Process options: >>>> a) ecn-experimentation assigns flag to itself as reserved for experimen= ts and says initially the AccECN experiment will use it exclusively=20 >>>> b) ecn-experimentation assigns NS flag exclusively to AccECN=20 >>>> c) AccECN assigns NS flag to itself, with a process exception proposed t= o the IESG to allow an EXP doc to assign to a Standards Action registry=20 >>>> d) the NS flag is reassigned by "AD review comment" or "IETF Last Call c= omment" (quoted from David's suggestions) >>>> e) other?... >>>>=20 >>>> The difference between (a) and (b) is in the document that ends up bein= g referenced from the IANA registry:=20 >>>> a) ecn-experimentation=20 >>>> b) accurate-ecn=20 >>>>=20 >>>> =3D=3DMy own preferences=3D=3D >>>>=20 >>>> During discussions, I didn't prefer (c) cos I thought the IESG might qu= estion why they are being asked to make a process exception for an ECN exper= iment at the same time as a draft is going through that avoids raising proce= ss exceptions for ECN experiments.=20 >>>>=20 >>>> Nonetheless, since then, Mirja has said... >>>>=20 >>>>> On 02/07/17 23:40, Mirja K=C3=BChlewind wrote: >>>>> I actually prefer option (c). I don=E2=80=99t think a process exceptio= n is a bad thing. If it=E2=80=99s the right thing to do, then that the reaso= n why we have such exceptions. Also I think it=E2=80=99d be the right thing t= o change the registry policy=E2=80=A6 but that probably a longer story. >>>> I agree that it is outdated that the registry requires a standards acti= on, because it has become normal tcpm practice for any change to TCP to have= to start on the experimental track. So this would justify a process excepti= on. >>>>=20 >>>> So, in summary, I don't mind (a), (b) or (c). I think (d) is not suffic= iently open and recorded for assignment of a flag in the main TCP header. >>>>=20 >>>>=20 >>>> Bob >>>>=20 >>=20 >> --=20 >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ >=20 --Apple-Mail-93148B47-17AB-4457-9024-6916EB79DE55 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I think as document shepher= d I have the input I need, but I need to talk to my AD about how to handle t= he process  - and liaise with the TCPM co-chairs regarding the TCPM WG d= raft. This isn't the first time we have had to look at the implications of m= aking another RFC historic, and I think we can do the correct thing.

Gorry

On 3 Jul 2017, at 20:17, C. M. Heard &= lt;heard@pobox.com> wrote:

=
Bob,

I think that your option (f) is better than option (e) (what I suggested).= As an aside, either one patches up an apparent process violation committed b= y RFC 3540, an experimental RFC that assigned bit 7 in contradiction to the p= olicy in RFC 2780.

Mike Heard

<= div>On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe <ietf@bobbriscoe.net&= gt; wrote:
=20 =20 =20
Mike,

Let's call this option:
(e) ecn-experimentation alters the registry policy of bit 7 of the TCP header to "IETF Review".

Having a different policy for certain bits within a registry might send IANA into a spin, but I am sure they could write suitable text into the registry policy if they had to.

I quite like this one. Altho unorthodox, it's neat.


Thank you.


Bob

PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as a 2-bit field during the 3-way hand-shake. While the ECN Nonce and AccECN use the three ECN flags (bits 7-9) as a 3-bit field during the 3WHS. AccECN uses the combinations that RFC3168 and the Nonce do not use. So to cover all bases:

Option (f): ecn-experimentation alters the registry policy for bits 7-9 to "IETF Review".


On 03/07/17 18:14, C= . M. Heard wrote:

Bob,

Couldn't the text in th= e IANA considerations of ecn-experimentation (which needs to be updated in any case) both change the NS flag to Reserved for ECN Experimentation and change the allocation policy for that flag from Standards Action to IETF Review, thereby updating RFC 2780? That would avoid the churn needed to add motivating text for a 4th experiment to ecn-experimentation and would allow AccECN to assign the NS bit itself without a process exception.

Mike Heard

On Mon, 3 Jul 2017 10:2= 8:25 +0100, Bob Briscoe wrote:

Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, tcpm list, tsvwg list,

There has been some offlist discussion (among different sub-groups) to narrow down the options here. It is time to see opinions from the two affected WGs (tcpm and tsvwg) on preferred process, esp. from the WG chairs and ADs.

=3D=3DBackground to the Process Problem=3D=3D

In tsvwg the process is in motion to make the ECN nonce [RFC 3540] historic. So, in the most recent rev of draft-ietf-tcpm-accurate-ecn-03 , we could finally include IANA assignment of the NS flag
    (see https://tools.ietf.org/= html/draft-ietf-tcpm-accurate-ecn-03#section-6 )

However, AccECN is EXPerimental, whereas the registry policy for assigning TCP flags is "Standards Action"
    https://www.iana= .org/assignments/tcp-header-flags/tcp-header-flags.xhtml
which means "Values are assigned only for Standards Track RFCs approved by the IESG" [RFC2434].

References:
    Process for designating RFCs as historic: 
        https://w= ww.ietf.org/iesg/statement/designating-rfcs-as-historic.html     Current draft text to make RFC 3540 historic:          h= ttps://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03= #section-3
    My initial draft for the AD's status change note: 
        https://github.com/bbriscoe/ecn-experim= entation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-0= 0.txt

ecn-experimentation has just completed WGLC. It still has to go through IETF LC (after Prague). it is deliberately PS in order to be able to relax pre-existing constraints on ECN experiments in standards track RFCs. However, if poss, we want to avoid adding motivating text for a 4th experiment, which could require another cycle of WGLC and delay until Nov. 

RFC 3692 ("Assigning Experimental and Testing Numbers Considered Useful") could also be relevant, although it doesn't seem to help here, because it is primarily aimed at larger codepoint spaces, not single bits.


=3D=3DProcess Options=3D=3D

There need to be two parts to the process: 1) unassignment and 2) reassignment. The first seems clear-cut. The second is less obvious.

1) Unassigning the NS flag from RFC 3540
a) add text to IANA considerations section of ecn-experientation making the NS flag reserved

2) Assigning the NS flag to accurate-ecn (and renaming it the AE flag). 
Process options:
a) ecn-experimentation assigns flag to itself as reserved for experiments and says initially the AccECN experiment will use it exclusively 
b) ecn-experimentation assigns NS flag exclusively to AccECN 
c) AccECN assigns NS flag to itself, with a process exception proposed to the IESG to allow an EXP doc to assign to a Standards Action registry 
d) the NS flag is reassigned by "AD review comment" or "IETF Last Call comment" (quoted from David's suggestions)
e) other?...

The difference between (a) and (b) is in the document that ends up being referenced from the IANA registry: 
a)  ecn-experimentation 
b) accurate-ecn 

=3D=3DMy own preferences=3D=3D

During discussions, I didn't prefer (c) cos I thought the IESG might question why they are being asked to make a process exception for an ECN experiment at the same time as a draft is going through that avoids raising process exceptions for ECN experiments. 

Nonetheless, since then, Mirja has said...

On 02/07/17 23:40, Mirja K=C3=BChlewind wrote:
I actually prefer option (c). I don=E2=80=99t think a p=
rocess exception is a bad thing. If it=E2=80=99s the right thing to do, then=
 that the reason why we have such exceptions. Also I think it=E2=80=99d be t=
he right thing to change the registry policy=E2=80=A6 but that probably a lo=
nger story.
I agree that it is outdated that the registry requires a standards action, because it has become normal tcpm practice for any change to TCP to have to start on the experimental track. So this would justify a process exception.

So, in summary, I don't mind (a), (b) or (c). I think (d) is not sufficiently open and recorded for assignment of a flag in the main TCP header.


Bob


--=20
________________________________________________________________
Bob Briscoe                               http=
://bobbriscoe.net/

= --Apple-Mail-93148B47-17AB-4457-9024-6916EB79DE55-- From nobody Mon Jul 3 16:25:45 2017 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 BD8D61317B2; Mon, 3 Jul 2017 16:25:34 -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.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149912433474.15950.3578519194738407958@ietfa.amsl.com> Date: Mon, 03 Jul 2017 16:25:34 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-aqm-dualq-coupled-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 23:25: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 of the IETF. Title : DualQ Coupled AQM for Low Latency, Low Loss and Scalable Throughput Authors : Koen De Schepper Bob Briscoe Olga Bondarenko Ing-jyh Tsang Filename : draft-ietf-tsvwg-aqm-dualq-coupled-01.txt Pages : 28 Date : 2017-07-03 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-01 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-aqm-dualq-coupled-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-aqm-dualq-coupled-01 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 3 16:43:12 2017 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 5928C131778; Mon, 3 Jul 2017 16:43:11 -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.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149912539134.16172.12208741837601724106@ietfa.amsl.com> Date: Mon, 03 Jul 2017 16:43:11 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rfc6040update-shim-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 23:43:11 -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 of the IETF. Title : Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim Author : Bob Briscoe Filename : draft-ietf-tsvwg-rfc6040update-shim-04.txt Pages : 16 Date : 2017-07-03 Abstract: RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the rules for propagation of ECN consistent for all forms of IP in IP tunnel. This specification updates RFC 6040 to clarify that its scope includes tunnels where two IP headers are separated by at least one shim header that is not sufficient on its own for wide area packet forwarding. It surveys widely deployed IP tunnelling protocols separated by such shim header(s) and updates the specifications of those that do not mention ECN propagation (L2TPv2, L2TPv3, GRE and Teredo). This specification also updates RFC 6040 with configuration requirements needed to make any legacy tunnel ingress safe. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-04 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc6040update-shim-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 Tue Jul 4 01:23:48 2017 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 E4C3B1316A9; Tue, 4 Jul 2017 01:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.691 X-Spam-Level: X-Spam-Status: No, score=-4.691 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, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 EJunSIe2W7zp; Tue, 4 Jul 2017 01:23:37 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0121.outbound.protection.outlook.com [104.47.0.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 104FC127977; Tue, 4 Jul 2017 01:23:36 -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; bh=08h1Hz+4WtiGrGSg1S8vjY+CBk+68HXYdOOYLyzrC78=; b=qWv61Uuww9Ol8KPDBAReQBWqi+u+KqUvGC0PIGbJ+9g8rL3xV2fFPIrfc7tI19Y6H0imTq1JMCvDyZCyJKEBbspWRj0jn7G9mJjmNYPeqkfCYkh78+PhNyGE655OnLM8ZIeRfDL6RxPzyx5zGokWf0EJh0VXTZ1b7TAi4UbCwvI= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2770.eurprd07.prod.outlook.com (10.173.93.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.6; Tue, 4 Jul 2017 08:23:33 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::a0a5:bdaf:13ae:89c4]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::a0a5:bdaf:13ae:89c4%17]) with mapi id 15.01.1240.013; Tue, 4 Jul 2017 08:23:33 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: Bob Briscoe , "C. M. Heard" CC: tcpm , tcpm-chairs , tsvwg , tsvwg-chairs , tsv-ads Thread-Topic: Process for re-assignment of NS TCP header flag to AccECN Thread-Index: AQHS9B/XDxDuUdMXK066vpV5lCrK0aJCZZiAgAADcoCAAC6ZAIAAuRUQ Date: Tue, 4 Jul 2017 08:23:33 +0000 Message-ID: References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> <4deec720-6773-fca4-6797-37bb5c845d70@bobbriscoe.net> In-Reply-To: <4deec720-6773-fca4-6797-37bb5c845d70@bobbriscoe.net> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: bobbriscoe.net; dkim=none (message not signed) header.d=none;bobbriscoe.net; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.24] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2770; 7:tp4x3Z6Q1nRf0yoKgxMh8Dlz0yxnOOnmZTbgDETirye+rrMOlGSFMEJrtKnJkRmEuYCkco8V6Uf3Rk1QiX4aKAtm7Q7VX4BQrlFXjHvQ1xtSZgH/pU7M7o8ESmtNw0rIBAxYy4ir8iOUrR6RCiLpYIr4tk6U92F1ltd7dzfbQgYxK4nQKYKm5zLku6NK4bufJkpEYByGaPttNLGm9kdLFDxQi1EMvtbjA32bN3JJ59Y7KmUJR4ZbSyfPGQcftSFwAEhnwyWXuprqU+gEcTMGrXYtL5wK0tOUty6F4q7G2O24+FQc100nvZjVAcTR82tvEQiz4aghkOaXy97saKHCSoKYbifUaM85VVkHBqhLKxGg62VQqGkt7xJ/nS10if10h9A5UsLzw9woW8CNTdd7ElQBdi+BrW0AZH+B6/5vUOmhdQAcaP1r6XAPgZ12R7vqYOpGCdAHcM1bTsjMX0LZlQkJY7HhkurXBg9NmKVyiAB2zdm7tmjBDupLm57SGvTwG8KHQCzeblUrR0AqmgPT7DhCemDFr21zgLSv4PR/qMuQwgnfUVpBLVc0/fX5GN7e+MWrIh3KK4mWFtSwEp3B5Q8NC8G/iB2o4i5PMx6fh5Bo6iKT6CPAWb0FjM2EcrbDjLZaKua2Y+YI58EYe6tVdTwWTxZrOz2pf1H/Q896yNiRhHqXdYorvZe/YWCQ6Ko5pTM6hRCYffycmFPH3Sybs5m0hNEQ8vbIx4whWvUiXOe3GfDVDA8QYDJb02lyMSjdKqY9PdbqhPnuM9TF/2Ng6xpicRAO5dYsTu3KRMxhykc= x-ms-office365-filtering-correlation-id: e4b1af08-743e-478e-d0f4-08d4c2b5f5d7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5PR0701MB2770; x-ms-traffictypediagnostic: AM5PR0701MB2770: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(278178393323532)(166708455590820)(26388249023172)(236129657087228)(48057245064654)(100405760836317)(148574349560750)(100324003535756)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2770; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2770; x-forefront-prvs: 0358535363 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39400400002)(39410400002)(39450400003)(39850400002)(39840400002)(24454002)(51444003)(377454003)(86362001)(33656002)(5250100002)(7696004)(2900100001)(76176999)(54356999)(50986999)(966005)(478600001)(14454004)(229853002)(189998001)(5660300001)(93886004)(66066001)(4326008)(99286003)(53546010)(55016002)(53936002)(25786009)(790700001)(8656002)(53376002)(236005)(38730400002)(74316002)(2906002)(3660700001)(54906002)(6306002)(54896002)(9686003)(8676002)(8936002)(606006)(81166006)(6506006)(6436002)(3846002)(3280700002)(102836003)(6116002)(2950100002)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2770; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB254703B53B5628C6FCCD912893D70AM5PR0701MB2547_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jul 2017 08:23:33.3794 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2770 Archived-At: Subject: Re: [tsvwg] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 08:23:40 -0000 --_000_AM5PR0701MB254703B53B5628C6FCCD912893D70AM5PR0701MB2547_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QSBjb21tZW50IG9uIHRoaXMgc3RhdGVtZW50OiDigJxJdCBoYXMgYmVjb21lIHR5cGljYWwgcHJh Y3RpY2UgZm9yIHRoZSBUQ1AgbWFpbnRlbmFuY2Ugd29ya2luZyBncm91cCB0byBleHBlY3QgYW55 IGNoYW5nZSB0byBUQ1AgdG8gYmUgZG9jdW1lbnRlZCBhcyBhbiBleHBlcmltZW50YWwgUkZDIGFu ZCBmb3IgdGhlIGV4cGVyaW1lbnQgdG8gYmUgZGVwbG95ZWQgYW5kIHByb3ZlZCBpbiBwcmFjdGlj ZSBiZWZvcmUgY29tbWl0dGluZyB0ZWNobm9sb2d5IHRvIHRoZSBzdGFuZGFyZHMgdHJhY2su4oCd DQoNClRDUE0gZGVjaWRlcyBvbiB0aGUgc3RhdHVzIG9mIGRvY3VtZW50cyBjYXNlLWJ5LWNhc2Us IGJ5IHdvcmtpbmcgZ3JvdXAgY29uc2Vuc3VzLg0KDQpOb3RoaW5nIHByZXZlbnRzIFRDUE0gZnJv bSBwdWJsaXNoaW5nIGRvY3VtZW50cyBvbiBzdGFuZGFyZHMgdHJhY2suIFRoZSByZXF1aXJlbWVu dHMgaW4gUkZDIDIwMjYgU2VjdGlvbiA0LjEuMSBtYXkgYmUgYSBiaXQgaGFyZGVyIHRvIG1lZXQg Zm9yIFRDUCBleHRlbnNpb25zIGFuZCBhbGdvcml0aG1zLCBjb21wYXJlZCB0byBvdGhlciBJRVRG IHByb3RvY29scywgZ2l2ZW4gdGhlIHdpZGUgZGVwbG95bWVudCBvZiBUQ1AgaW4gdmVyeSBkaWZm ZXJlbnQgZW52aXJvbm1lbnRzLiBBbmQsIGluZGVlZCwgdGhlIFRDUE0gY29tbXVuaXR5IGNvbnNl bnN1cyBmb3Igc29tZSByZWNlbnQgZG9jdW1lbnRzIHdhcyB0byBwdWJsaXNoIHdvcmsgKGZpcnN0 KSBhcyBleHBlcmltZW50YWwuIFRoZXNlIGRlY2lzaW9ucyBoYXZlIGFsd2F5cyBiZWVuIHByZXR0 eSB1bmFuaW1vdXMsIGFzIGZhciBhcyBJIHJlY2FsbC4gQnV0IGNsZWFybHkgaWYgdGhlIGNvbW11 bml0eSBjb25zZW5zdXMgaXMgc3RhbmRhcmRzIHRyYWNrLCBUQ1BNIHdpbGwgc3VibWl0IGRvY3Vt ZW50cyBvbiBzdGFuZGFyZHMgdHJhY2vigKYNCg0KTWljaGFlbA0KDQoNCg0KRnJvbTogQm9iIEJy aXNjb2UgW21haWx0bzppZXRmQGJvYmJyaXNjb2UubmV0XQ0KU2VudDogTW9uZGF5LCBKdWx5IDAz LCAyMDE3IDExOjA0IFBNDQpUbzogQy4gTS4gSGVhcmQgPGhlYXJkQHBvYm94LmNvbT4NCkNjOiB0 Y3BtIDx0Y3BtQGlldGYub3JnPjsgdGNwbS1jaGFpcnMgPHRjcG0tY2hhaXJzQGlldGYub3JnPjsg dHN2d2cgPHRzdndnQGlldGYub3JnPjsgdHN2d2ctY2hhaXJzIDx0c3Z3Zy1jaGFpcnNAaWV0Zi5v cmc+OyB0c3YtYWRzIDx0c3YtYWRzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFByb2Nlc3MgZm9y IHJlLWFzc2lnbm1lbnQgb2YgTlMgVENQIGhlYWRlciBmbGFnIHRvIEFjY0VDTg0KDQpNaWtlLA0K DQpJdCBtYXkgbm90IGJlIHNvIHN0cmFpZ2h0Zm9yd2FyZC4NCiogSXQgaXMgcmVsYXRpdmVseSBl YXN5IHRvIGp1c3RpZnkgY2hhbmdpbmcgdGhlIHBvbGljeSBmb3IgdGhlIGZsYWcgdGhhdCBpcyBy ZWxlYXNlZCBieSBtYWtpbmcgdGhlIE5vbmNlIGhpc3RvcmljLCB3aGljaCBlY24tZXhwZXJpbWVu dGF0aW9uIGlzIGFscmVhZHkgZ2l2aW5nIHJhdGlvbmFsZSBmb3IuDQoqIFN0cmljdGx5IGl0IHdv dWxkIHJlcXVpcmUgdGV4dCB0byBqdXN0aWZ5IGNoYW5naW5nIHRoZSByZWdpc3RyeSBwb2xpY3kg Zm9yIHRoZSBvdGhlciAyIGZsYWdzIHRoYXQgYXJlIHN0aWxsIGFzc2lnbmVkIHRvIFJGQzMxNjgg b24gdGhlIHN0YW5kYXJkcyB0cmFjay4NCg0KVGhpcyBpcyBhY3R1YWxseSBhIHN5bXB0b20gb2Yg YSBsYXJnZXIgcHJvYmxlbSB3aXRoIHRoZSByZWdpc3RyeSBmb3IgdGhlc2UgZmxhZ3MuIFRoZSBy ZWdpc3RyeSBhc3NpZ25zIGJpdHMgdG8gc2luZ2xlIFJGQ3MgYXMgaW5kaXZpZHVhbCBiaW5hcnkg ZmxhZ3MsIGJ1dCB0aGV5IGFyZSBub3QgYmVpbmcgdXNlZCBsaWtlIHRoaXMuIEFjY0VDTiB1c2Vk IGNvbWJpbmF0aW9ucyBvZiB0aGUgRUNOIGZsYWdzIGFuZCBzdGF0ZXMgb2YgdGhlIFRDUCBzdGF0 ZS1tYWNoaW5lIHRoYXQgaGFkIG5vdCB5ZXQgYmVlbiB1c2VkIHRvZ2V0aGVyLCBpbiBvcmRlciB0 byBpbmNyZWFzZSB0aGUgYXZhaWxhYmxlIHN0YXRlIHNwYWNlLiBSRkMgMzE2OCBhbmQgUkZDMzU0 MCBhbHNvIGRpZCB0aGlzLCBhbmQgSSdtIHN1cmUgcGVvcGxlIGNhbiB0aGluayBvZiBtYW55IG90 aGVyIFRDUC1iYXNlZCBwcm90b2NvbHMgdGhhdCBoYXZlIGRvbmUgdGhpcy4NCg0KSG93ZXZlciwg d2Ugc3RpbGwgaW1hZ2luZSB0aGF0IGluZGl2aWR1YWwgZmxhZ3MgYXJlIGFzc2lnbmVkIHRvIGlu ZGl2aWR1YWwgUkZDcy4gT3B0aW9uIChlKSByZWluZm9yY2VzIHRoaXMgZGVsdXNpb24sIHdoZXJl YXMgb3B0aW9uIChmKSBjaGFsbGVuZ2VzIGl0LiBIZW5jZSBvcHRpb24gKGUpICdmZWVscycgbW9y ZSBhY2NlcHRhYmxlLCBhcyBsb25nIGFzIHlvdSBzY3JldyB1cCB5b3VyIGV5ZXMgYW5kIGF2b2lk IHRoaW5raW5nIHRvbyBtdWNoLg0KDQoNCg0KSSBkb3VidCBhbnlvbmUgd2FudHMgdG8gImdvIHRo ZXJlIiByaWdodCBub3cuIEJ1dCBoZXJlJ3MgdGV4dCB0aGF0IGNvdWxkIGJlIHVzZWQgaW4gImFu IFJGQyIgKFRCQSkgdG8gY2hhbmdlIHRoZSB3aG9sZSBUQ1AgZmxhZ3MgcmVnaXN0cnkgcG9saWN5 IHRvIHJlZmxlY3Qgd2hhdCBpcyBhY3R1YWxseSBoYXBwZW5pbmcgaW4gcHJhY3RpY2U6DQoNCm9w dGlvbiAoZykNCkl0IGhhcyBiZWNvbWUgdHlwaWNhbCBwcmFjdGljZSBmb3IgdGhlIFRDUCBtYWlu dGVuYW5jZSB3b3JraW5nIGdyb3VwIHRvIGV4cGVjdCBhbnkgY2hhbmdlIHRvIFRDUCB0byBiZSBk b2N1bWVudGVkIGFzIGFuIGV4cGVyaW1lbnRhbCBSRkMgYW5kIGZvciB0aGUgZXhwZXJpbWVudCB0 byBiZSBkZXBsb3llZCBhbmQgcHJvdmVkIGluIHByYWN0aWNlIGJlZm9yZSBjb21taXR0aW5nIHRl Y2hub2xvZ3kgdG8gdGhlIHN0YW5kYXJkcyB0cmFjay4NCg0KUkZDMzE2OCBhc3NpZ25lZCB0aGUg Q1dSIGFuZCBFQ0UgZmxhZ3MgZm9yIGl0cyBvd24gdXNlIGFzIHNpbmdsZSBiaXRzIGFuZCBSRkMz NTQwIGFzc2lnbmVkIHRoZSBOUyBmbGFnIGZvciBpdHMgb3duIHVzZSBhcyBhbm90aGVyIHNpbmds ZSBiaXQuIEhvd2V2ZXIsIGR1cmluZyBUQ1AncyAgaGFuZHNoYWtlIGJvdGggdGhlc2UgUkZDcyB1 c2UgY29tYmluYXRpb25zIG9mIHRoZXNlIGJpdHMgYXMgY29kZXBvaW50cywgbm90IGluZGVwZW5k ZW50IGJpbmFyeSBmbGFncy4gUkZDMzE2OCBhbmQgUkZDMzU0MCBhbHNvIGdpdmUgdGhlc2UgYml0 cyBkaWZmZXJlbnQgbWVhbmluZ3Mgd2hlbiB1c2VkIGFmdGVyIHRoZSBoYW5kc2hha2UuIFNvIHRo ZXNlIHRocmVlIGJpdHMgYXJlIGVmZmVjdGl2ZWx5IGJlaW5nIHVzZWQgaW4gY29tYmluYXRpb24g d2l0aCB0aGUgU1lOIGFuZCBBQ0sgZmxhZ3MgdG8gaW5jcmVhc2UgdGhlIGF2YWlsYWJsZSBzdGF0 ZSBzcGFjZSBpbiBub3ZlbCB3YXlzLiBBc3NpZ25pbmcgVENQIGhlYWRlciBmbGFncyBhcyBpbmRp dmlkdWFsIGJpdHMgd2FzdGVzIGFsbCB0aGUgY29tYmluYXRpb25zIHRoYXQgdGhlc2UgdHdvIFJG Q3MgYW5kIG90aGVyIGV4aXN0aW5nIFJGQ3MgZG8gbm90IHVzZS4NCg0KVGhlIHByZXNlbnQgZG9j dW1lbnQgW2Vjbi1leHBlcmltZW50YXRpb25dIHJlY29nbml6ZXMgdGhhdA0KKiBhc3NpZ25pbmcg VENQIGZsYWdzIGluZGl2aWR1YWxseSBhbmQgZXhjbHVzaXZlbHkgdG8gc3RhbmRhcmRzIHRyYWNr IFJGQ3MgaXMgbm8gbG9uZ2VyIHR5cGljYWwgcHJhY3RpY2U7DQoqIHRoZSBUQ1AgZmxhZ3MgYXJl IGFjdHVhbGx5IGJlaW5nIHVzZWQgaW4gbm92ZWwgd2F5cyB0aGF0IGFyZSBub3QgYW1lbmFibGUg dG8gc2ltcGxlIHJlZ2lzdHJhdGlvbiBieSBJQU5BOw0KKiBjdXJyZW50IGlubm92YXRpb24gaW4g dGhpcyBzcGFjZSBpcyBpbiBzcGl0ZSBvZiB0aGUgInN0YW5kYXJkcyBhY3Rpb24iIHJlZ2lzdHJ5 IHBvbGljeSByYXRoZXIgdGhhbiBiZWNhdXNlIG9mIGl0Lg0KDQpUaGVyZWZvcmUgdGhlIHJlZ2lz dHJ5IHBvbGljeSBhcyBhIHdob2xlIGlzIGNoYW5nZWQgdG8gIklFVEYgUmV2aWV3Ii4NCg0KDQoN CkJvYg0KDQpPbiAwMy8wNy8xNyAxOToxNywgQy4gTS4gSGVhcmQgd3JvdGU6DQpCb2IsDQoNCkkg dGhpbmsgdGhhdCB5b3VyIG9wdGlvbiAoZikgaXMgYmV0dGVyIHRoYW4gb3B0aW9uIChlKSAod2hh dCBJIHN1Z2dlc3RlZCkuIEFzIGFuIGFzaWRlLCBlaXRoZXIgb25lIHBhdGNoZXMgdXAgYW4gYXBw YXJlbnQgcHJvY2VzcyB2aW9sYXRpb24gY29tbWl0dGVkIGJ5IFJGQyAzNTQwLCBhbiBleHBlcmlt ZW50YWwgUkZDIHRoYXQgYXNzaWduZWQgYml0IDcgaW4gY29udHJhZGljdGlvbiB0byB0aGUgcG9s aWN5IGluIFJGQyAyNzgwLg0KDQpNaWtlIEhlYXJkDQoNCk9uIE1vbiwgSnVsIDMsIDIwMTcgYXQg MTE6MDUgQU0sIEJvYiBCcmlzY29lIDxpZXRmQGJvYmJyaXNjb2UubmV0PG1haWx0bzppZXRmQGJv YmJyaXNjb2UubmV0Pj4gd3JvdGU6DQpNaWtlLA0KDQpMZXQncyBjYWxsIHRoaXMgb3B0aW9uOg0K KGUpIGVjbi1leHBlcmltZW50YXRpb24gYWx0ZXJzIHRoZSByZWdpc3RyeSBwb2xpY3kgb2YgYml0 IDcgb2YgdGhlIFRDUCBoZWFkZXIgdG8gIklFVEYgUmV2aWV3Ii4NCg0KSGF2aW5nIGEgZGlmZmVy ZW50IHBvbGljeSBmb3IgY2VydGFpbiBiaXRzIHdpdGhpbiBhIHJlZ2lzdHJ5IG1pZ2h0IHNlbmQg SUFOQSBpbnRvIGEgc3BpbiwgYnV0IEkgYW0gc3VyZSB0aGV5IGNvdWxkIHdyaXRlIHN1aXRhYmxl IHRleHQgaW50byB0aGUgcmVnaXN0cnkgcG9saWN5IGlmIHRoZXkgaGFkIHRvLg0KDQpJIHF1aXRl IGxpa2UgdGhpcyBvbmUuIEFsdGhvIHVub3J0aG9kb3gsIGl0J3MgbmVhdC4NCg0KDQpUaGFuayB5 b3UuDQoNCg0KQm9iDQoNClBTLiBTdHJpY3RseSBSRkMzMTY4IHVzZWQgdGhlIENXUiBhbmQgRUNF IGZsYWdzIChiaXRzIDggJiA5KSBhcyBhIDItYml0IGZpZWxkIGR1cmluZyB0aGUgMy13YXkgaGFu ZC1zaGFrZS4gV2hpbGUgdGhlIEVDTiBOb25jZSBhbmQgQWNjRUNOIHVzZSB0aGUgdGhyZWUgRUNO IGZsYWdzIChiaXRzIDctOSkgYXMgYSAzLWJpdCBmaWVsZCBkdXJpbmcgdGhlIDNXSFMuIEFjY0VD TiB1c2VzIHRoZSBjb21iaW5hdGlvbnMgdGhhdCBSRkMzMTY4IGFuZCB0aGUgTm9uY2UgZG8gbm90 IHVzZS4gU28gdG8gY292ZXIgYWxsIGJhc2VzOg0KDQpPcHRpb24gKGYpOiBlY24tZXhwZXJpbWVu dGF0aW9uIGFsdGVycyB0aGUgcmVnaXN0cnkgcG9saWN5IGZvciBiaXRzIDctOSB0byAiSUVURiBS ZXZpZXciLg0KDQpPbiAwMy8wNy8xNyAxODoxNCwgQy4gTS4gSGVhcmQgd3JvdGU6DQoNCkJvYiwN Cg0KQ291bGRuJ3QgdGhlIHRleHQgaW4gdGhlIElBTkEgY29uc2lkZXJhdGlvbnMgb2YgZWNuLWV4 cGVyaW1lbnRhdGlvbiAod2hpY2ggbmVlZHMgdG8gYmUgdXBkYXRlZCBpbiBhbnkgY2FzZSkgYm90 aCBjaGFuZ2UgdGhlIE5TIGZsYWcgdG8gUmVzZXJ2ZWQgZm9yIEVDTiBFeHBlcmltZW50YXRpb24g YW5kIGNoYW5nZSB0aGUgYWxsb2NhdGlvbiBwb2xpY3kgZm9yIHRoYXQgZmxhZyBmcm9tIFN0YW5k YXJkcyBBY3Rpb24gdG8gSUVURiBSZXZpZXcsIHRoZXJlYnkgdXBkYXRpbmcgUkZDIDI3ODA/IFRo YXQgd291bGQgYXZvaWQgdGhlIGNodXJuIG5lZWRlZCB0byBhZGQgbW90aXZhdGluZyB0ZXh0IGZv ciBhIDR0aCBleHBlcmltZW50IHRvIGVjbi1leHBlcmltZW50YXRpb24gYW5kIHdvdWxkIGFsbG93 IEFjY0VDTiB0byBhc3NpZ24gdGhlIE5TIGJpdCBpdHNlbGYgd2l0aG91dCBhIHByb2Nlc3MgZXhj ZXB0aW9uLg0KDQpNaWtlIEhlYXJkDQoNCk9uIE1vbiwgMyBKdWwgMjAxNyAxMDoyODoyNSArMDEw MCwgQm9iIEJyaXNjb2Ugd3JvdGU6DQpNaWNoYWVsKjIsIFlvc2hpZnVtaSwgR29ycnksIERhdmlk LCBXZXMsIE1pcmphLCBTcGVuY2VyLCB0Y3BtIGxpc3QsIHRzdndnIGxpc3QsDQoNClRoZXJlIGhh cyBiZWVuIHNvbWUgb2ZmbGlzdCBkaXNjdXNzaW9uIChhbW9uZyBkaWZmZXJlbnQgc3ViLWdyb3Vw cykgdG8gbmFycm93IGRvd24gdGhlIG9wdGlvbnMgaGVyZS4gSXQgaXMgdGltZSB0byBzZWUgb3Bp bmlvbnMgZnJvbSB0aGUgdHdvIGFmZmVjdGVkIFdHcyAodGNwbSBhbmQgdHN2d2cpIG9uIHByZWZl cnJlZCBwcm9jZXNzLCBlc3AuIGZyb20gdGhlIFdHIGNoYWlycyBhbmQgQURzLg0KDQo9PUJhY2tn cm91bmQgdG8gdGhlIFByb2Nlc3MgUHJvYmxlbT09DQoNCkluIHRzdndnIHRoZSBwcm9jZXNzIGlz IGluIG1vdGlvbiB0byBtYWtlIHRoZSBFQ04gbm9uY2UgW1JGQyAzNTQwXSBoaXN0b3JpYy4gU28s IGluIHRoZSBtb3N0IHJlY2VudCByZXYgb2YgZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbi0w MyAsIHdlIGNvdWxkIGZpbmFsbHkgaW5jbHVkZSBJQU5BIGFzc2lnbm1lbnQgb2YgdGhlIE5TIGZs YWcNCiAgICAoc2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRjcG0t YWNjdXJhdGUtZWNuLTAzI3NlY3Rpb24tNiApDQoNCkhvd2V2ZXIsIEFjY0VDTiBpcyBFWFBlcmlt ZW50YWwsIHdoZXJlYXMgdGhlIHJlZ2lzdHJ5IHBvbGljeSBmb3IgYXNzaWduaW5nIFRDUCBmbGFn cyBpcyAiU3RhbmRhcmRzIEFjdGlvbiINCiAgICBodHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25t ZW50cy90Y3AtaGVhZGVyLWZsYWdzL3RjcC1oZWFkZXItZmxhZ3MueGh0bWwNCndoaWNoIG1lYW5z ICJWYWx1ZXMgYXJlIGFzc2lnbmVkIG9ubHkgZm9yIFN0YW5kYXJkcyBUcmFjayBSRkNzIGFwcHJv dmVkIGJ5IHRoZSBJRVNHIiBbUkZDMjQzNF0uDQoNClJlZmVyZW5jZXM6DQogICAgUHJvY2VzcyBm b3IgZGVzaWduYXRpbmcgUkZDcyBhcyBoaXN0b3JpYzoNCiAgICAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGVzaWduYXRpbmctcmZjcy1hcy1oaXN0b3JpYy5odG1sDQog ICAgQ3VycmVudCBkcmFmdCB0ZXh0IHRvIG1ha2UgUkZDIDM1NDAgaGlzdG9yaWM6DQogICAgICAg IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRzdndnLWVjbi1leHBlcmlt ZW50YXRpb24tMDMjc2VjdGlvbi0zDQogICAgTXkgaW5pdGlhbCBkcmFmdCBmb3IgdGhlIEFEJ3Mg c3RhdHVzIGNoYW5nZSBub3RlOg0KICAgICAgICBodHRwczovL2dpdGh1Yi5jb20vYmJyaXNjb2Uv ZWNuLWV4cGVyaW1lbnRhdGlvbi9ibG9iL21hc3Rlci9zdGF0dXMtY2hhbmdlLWVjbi1ub25jZS1y ZmMzNTQwLXRvLWhpc3RvcmljLTAwLnR4dA0KDQplY24tZXhwZXJpbWVudGF0aW9uIGhhcyBqdXN0 IGNvbXBsZXRlZCBXR0xDLiBJdCBzdGlsbCBoYXMgdG8gZ28gdGhyb3VnaCBJRVRGIExDIChhZnRl ciBQcmFndWUpLiBpdCBpcyBkZWxpYmVyYXRlbHkgUFMgaW4gb3JkZXIgdG8gYmUgYWJsZSB0byBy ZWxheCBwcmUtZXhpc3RpbmcgY29uc3RyYWludHMgb24gRUNOIGV4cGVyaW1lbnRzIGluIHN0YW5k YXJkcyB0cmFjayBSRkNzLiBIb3dldmVyLCBpZiBwb3NzLCB3ZSB3YW50IHRvIGF2b2lkIGFkZGlu ZyBtb3RpdmF0aW5nIHRleHQgZm9yIGEgNHRoIGV4cGVyaW1lbnQsIHdoaWNoIGNvdWxkIHJlcXVp cmUgYW5vdGhlciBjeWNsZSBvZiBXR0xDIGFuZCBkZWxheSB1bnRpbCBOb3YuDQoNClJGQyAzNjky ICgiQXNzaWduaW5nIEV4cGVyaW1lbnRhbCBhbmQgVGVzdGluZyBOdW1iZXJzIENvbnNpZGVyZWQg VXNlZnVsIikgY291bGQgYWxzbyBiZSByZWxldmFudCwgYWx0aG91Z2ggaXQgZG9lc24ndCBzZWVt IHRvIGhlbHAgaGVyZSwgYmVjYXVzZSBpdCBpcyBwcmltYXJpbHkgYWltZWQgYXQgbGFyZ2VyIGNv ZGVwb2ludCBzcGFjZXMsIG5vdCBzaW5nbGUgYml0cy4NCg0KDQo9PVByb2Nlc3MgT3B0aW9ucz09 DQoNClRoZXJlIG5lZWQgdG8gYmUgdHdvIHBhcnRzIHRvIHRoZSBwcm9jZXNzOiAxKSB1bmFzc2ln bm1lbnQgYW5kIDIpIHJlYXNzaWdubWVudC4gVGhlIGZpcnN0IHNlZW1zIGNsZWFyLWN1dC4gVGhl IHNlY29uZCBpcyBsZXNzIG9idmlvdXMuDQoNCjEpIFVuYXNzaWduaW5nIHRoZSBOUyBmbGFnIGZy b20gUkZDIDM1NDANCmEpIGFkZCB0ZXh0IHRvIElBTkEgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBv ZiBlY24tZXhwZXJpZW50YXRpb24gbWFraW5nIHRoZSBOUyBmbGFnIHJlc2VydmVkDQoNCjIpIEFz c2lnbmluZyB0aGUgTlMgZmxhZyB0byBhY2N1cmF0ZS1lY24gKGFuZCByZW5hbWluZyBpdCB0aGUg QUUgZmxhZykuDQpQcm9jZXNzIG9wdGlvbnM6DQphKSBlY24tZXhwZXJpbWVudGF0aW9uIGFzc2ln bnMgZmxhZyB0byBpdHNlbGYgYXMgcmVzZXJ2ZWQgZm9yIGV4cGVyaW1lbnRzIGFuZCBzYXlzIGlu aXRpYWxseSB0aGUgQWNjRUNOIGV4cGVyaW1lbnQgd2lsbCB1c2UgaXQgZXhjbHVzaXZlbHkNCmIp IGVjbi1leHBlcmltZW50YXRpb24gYXNzaWducyBOUyBmbGFnIGV4Y2x1c2l2ZWx5IHRvIEFjY0VD Tg0KYykgQWNjRUNOIGFzc2lnbnMgTlMgZmxhZyB0byBpdHNlbGYsIHdpdGggYSBwcm9jZXNzIGV4 Y2VwdGlvbiBwcm9wb3NlZCB0byB0aGUgSUVTRyB0byBhbGxvdyBhbiBFWFAgZG9jIHRvIGFzc2ln biB0byBhIFN0YW5kYXJkcyBBY3Rpb24gcmVnaXN0cnkNCmQpIHRoZSBOUyBmbGFnIGlzIHJlYXNz aWduZWQgYnkgIkFEIHJldmlldyBjb21tZW50IiBvciAiSUVURiBMYXN0IENhbGwgY29tbWVudCIg KHF1b3RlZCBmcm9tIERhdmlkJ3Mgc3VnZ2VzdGlvbnMpDQplKSBvdGhlcj8uLi4NCg0KVGhlIGRp ZmZlcmVuY2UgYmV0d2VlbiAoYSkgYW5kIChiKSBpcyBpbiB0aGUgZG9jdW1lbnQgdGhhdCBlbmRz IHVwIGJlaW5nIHJlZmVyZW5jZWQgZnJvbSB0aGUgSUFOQSByZWdpc3RyeToNCmEpICBlY24tZXhw ZXJpbWVudGF0aW9uDQpiKSBhY2N1cmF0ZS1lY24NCg0KPT1NeSBvd24gcHJlZmVyZW5jZXM9PQ0K DQpEdXJpbmcgZGlzY3Vzc2lvbnMsIEkgZGlkbid0IHByZWZlciAoYykgY29zIEkgdGhvdWdodCB0 aGUgSUVTRyBtaWdodCBxdWVzdGlvbiB3aHkgdGhleSBhcmUgYmVpbmcgYXNrZWQgdG8gbWFrZSBh IHByb2Nlc3MgZXhjZXB0aW9uIGZvciBhbiBFQ04gZXhwZXJpbWVudCBhdCB0aGUgc2FtZSB0aW1l IGFzIGEgZHJhZnQgaXMgZ29pbmcgdGhyb3VnaCB0aGF0IGF2b2lkcyByYWlzaW5nIHByb2Nlc3Mg ZXhjZXB0aW9ucyBmb3IgRUNOIGV4cGVyaW1lbnRzLg0KDQpOb25ldGhlbGVzcywgc2luY2UgdGhl biwgTWlyamEgaGFzIHNhaWQuLi4NCk9uIDAyLzA3LzE3IDIzOjQwLCBNaXJqYSBLw7xobGV3aW5k IHdyb3RlOg0KDQpJIGFjdHVhbGx5IHByZWZlciBvcHRpb24gKGMpLiBJIGRvbuKAmXQgdGhpbmsg YSBwcm9jZXNzIGV4Y2VwdGlvbiBpcyBhIGJhZCB0aGluZy4gSWYgaXTigJlzIHRoZSByaWdodCB0 aGluZyB0byBkbywgdGhlbiB0aGF0IHRoZSByZWFzb24gd2h5IHdlIGhhdmUgc3VjaCBleGNlcHRp b25zLiBBbHNvIEkgdGhpbmsgaXTigJlkIGJlIHRoZSByaWdodCB0aGluZyB0byBjaGFuZ2UgdGhl IHJlZ2lzdHJ5IHBvbGljeeKApiBidXQgdGhhdCBwcm9iYWJseSBhIGxvbmdlciBzdG9yeS4NCkkg YWdyZWUgdGhhdCBpdCBpcyBvdXRkYXRlZCB0aGF0IHRoZSByZWdpc3RyeSByZXF1aXJlcyBhIHN0 YW5kYXJkcyBhY3Rpb24sIGJlY2F1c2UgaXQgaGFzIGJlY29tZSBub3JtYWwgdGNwbSBwcmFjdGlj ZSBmb3IgYW55IGNoYW5nZSB0byBUQ1AgdG8gaGF2ZSB0byBzdGFydCBvbiB0aGUgZXhwZXJpbWVu dGFsIHRyYWNrLiBTbyB0aGlzIHdvdWxkIGp1c3RpZnkgYSBwcm9jZXNzIGV4Y2VwdGlvbi4NCg0K U28sIGluIHN1bW1hcnksIEkgZG9uJ3QgbWluZCAoYSksIChiKSBvciAoYykuIEkgdGhpbmsgKGQp IGlzIG5vdCBzdWZmaWNpZW50bHkgb3BlbiBhbmQgcmVjb3JkZWQgZm9yIGFzc2lnbm1lbnQgb2Yg YSBmbGFnIGluIHRoZSBtYWluIFRDUCBoZWFkZXIuDQoNCg0KQm9iDQoNCg0KDQotLQ0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoNCkJvYiBCcmlzY29lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9i b2JicmlzY29lLm5ldC8NCg0KDQoNCg0KLS0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpCb2IgQnJpc2NvZSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBodHRwOi8vYm9iYnJpc2NvZS5uZXQvDQo= --_000_AM5PR0701MB254703B53B5628C6FCCD912893D70AM5PR0701MB2547_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRpbWVzOw0KCXBh bm9zZS0xOjIgMiA2IDMgNSA0IDUgMiAzIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAu TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0KdHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWww LCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpwLm02MjQxNjM1 ODUzMTI0MTQ1MjA0Z21haWwtcDEsIGxpLm02MjQxNjM1ODUzMTI0MTQ1MjA0Z21haWwtcDEsIGRp di5tNjI0MTYzNTg1MzEyNDE0NTIwNGdtYWlsLXAxDQoJe21zby1zdHlsZS1uYW1lOm1fNjI0MTYz NTg1MzEyNDE0NTIwNGdtYWlsLXAxOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcC5tNjI0MTYzNTg1MzEyNDE0NTIwNGdtYWlsLXAyLCBs aS5tNjI0MTYzNTg1MzEyNDE0NTIwNGdtYWlsLXAyLCBkaXYubTYyNDE2MzU4NTMxMjQxNDUyMDRn bWFpbC1wMg0KCXttc28tc3R5bGUtbmFtZTptXzYyNDE2MzU4NTMxMjQxNDUyMDRnbWFpbC1wMjsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30N CnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNr O30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5 bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIu MHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5BIGNvbW1l bnQgb24gdGhpcyBzdGF0ZW1lbnQ6DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij7igJw8L3NwYW4+PC90dD48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndp bmRvd3RleHQiPkl0IGhhcyBiZWNvbWUgdHlwaWNhbCBwcmFjdGljZSBmb3IgdGhlIFRDUCBtYWlu dGVuYW5jZSB3b3JraW5nIGdyb3VwDQogdG8gZXhwZWN0IGFueSBjaGFuZ2UgdG8gVENQIHRvIGJl IGRvY3VtZW50ZWQgYXMgYW4gZXhwZXJpbWVudGFsIFJGQyBhbmQgZm9yIHRoZSBleHBlcmltZW50 IHRvIGJlIGRlcGxveWVkIGFuZCBwcm92ZWQgaW4gcHJhY3RpY2UgYmVmb3JlIGNvbW1pdHRpbmcg dGVjaG5vbG9neSB0byB0aGUgc3RhbmRhcmRzIHRyYWNrLjwvc3Bhbj48L3R0Pjx0dD48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+4oCdPC9zcGFuPjwvdHQ+PHR0PjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3R0PjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+ PGJyPg0KPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPlRDUE0g ZGVjaWRlcyBvbiB0aGUgc3RhdHVzIG9mIGRvY3VtZW50cyBjYXNlLWJ5LWNhc2UsIGJ5IHdvcmtp bmcgZ3JvdXAgY29uc2Vuc3VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 d2luZG93dGV4dCI+Tm90aGluZyBwcmV2ZW50cyBUQ1BNIGZyb20gcHVibGlzaGluZyBkb2N1bWVu dHMgb24gc3RhbmRhcmRzIHRyYWNrLiBUaGUgcmVxdWlyZW1lbnRzIGluIFJGQyAyMDI2IFNlY3Rp b24gNC4xLjEgbWF5IGJlIGEgYml0IGhhcmRlciB0byBtZWV0IGZvciBUQ1AgZXh0ZW5zaW9ucw0K IGFuZCBhbGdvcml0aG1zLCBjb21wYXJlZCB0byBvdGhlciBJRVRGIHByb3RvY29scywgZ2l2ZW4g dGhlIHdpZGUgZGVwbG95bWVudCBvZiBUQ1AgaW4gdmVyeSBkaWZmZXJlbnQgZW52aXJvbm1lbnRz LiBBbmQsIGluZGVlZCwgdGhlIFRDUE0gY29tbXVuaXR5IGNvbnNlbnN1cyBmb3Igc29tZSByZWNl bnQgZG9jdW1lbnRzIHdhcyB0byBwdWJsaXNoIHdvcmsgKGZpcnN0KSBhcyBleHBlcmltZW50YWwu IFRoZXNlIGRlY2lzaW9ucyBoYXZlIGFsd2F5cw0KIGJlZW4gcHJldHR5IHVuYW5pbW91cywgYXMg ZmFyIGFzIEkgcmVjYWxsLiBCdXQgY2xlYXJseSBpZiB0aGUgY29tbXVuaXR5IGNvbnNlbnN1cyBp cyBzdGFuZGFyZHMgdHJhY2ssIFRDUE0gd2lsbCBzdWJtaXQgZG9jdW1lbnRzIG9uIHN0YW5kYXJk cyB0cmFjazwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0 ZXh0Ij7igKY8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+TWljaGFlbDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0 ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBC b2IgQnJpc2NvZSBbbWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXRdDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gTW9uZGF5LCBKdWx5IDAzLCAyMDE3IDExOjA0IFBNPGJyPg0KPGI+VG86PC9iPiBDLiBNLiBI ZWFyZCAmbHQ7aGVhcmRAcG9ib3guY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gdGNwbSAmbHQ7dGNw bUBpZXRmLm9yZyZndDs7IHRjcG0tY2hhaXJzICZsdDt0Y3BtLWNoYWlyc0BpZXRmLm9yZyZndDs7 IHRzdndnICZsdDt0c3Z3Z0BpZXRmLm9yZyZndDs7IHRzdndnLWNoYWlycyAmbHQ7dHN2d2ctY2hh aXJzQGlldGYub3JnJmd0OzsgdHN2LWFkcyAmbHQ7dHN2LWFkc0BpZXRmLm9yZyZndDs8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFByb2Nlc3MgZm9yIHJlLWFzc2lnbm1lbnQgb2YgTlMgVENQIGhl YWRlciBmbGFnIHRvIEFjY0VDTjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk1pa2UsPGJyPg0KPGJyPg0KSXQgbWF5IG5vdCBiZSBzbyBzdHJhaWdodGZvcndh cmQuIDxicj4NCiogSXQgaXMgcmVsYXRpdmVseSBlYXN5IHRvIGp1c3RpZnkgY2hhbmdpbmcgdGhl IHBvbGljeSBmb3IgdGhlIGZsYWcgdGhhdCBpcyByZWxlYXNlZCBieSBtYWtpbmcgdGhlIE5vbmNl IGhpc3RvcmljLCB3aGljaCBlY24tZXhwZXJpbWVudGF0aW9uIGlzIGFscmVhZHkgZ2l2aW5nIHJh dGlvbmFsZSBmb3IuPGJyPg0KKiBTdHJpY3RseSBpdCB3b3VsZCByZXF1aXJlIHRleHQgdG8ganVz dGlmeSBjaGFuZ2luZyB0aGUgcmVnaXN0cnkgcG9saWN5IGZvciB0aGUgb3RoZXIgMiBmbGFncyB0 aGF0IGFyZSBzdGlsbCBhc3NpZ25lZCB0byBSRkMzMTY4IG9uIHRoZSBzdGFuZGFyZHMgdHJhY2su PGJyPg0KPGJyPg0KVGhpcyBpcyBhY3R1YWxseSBhIHN5bXB0b20gb2YgYSBsYXJnZXIgcHJvYmxl bSB3aXRoIHRoZSByZWdpc3RyeSBmb3IgdGhlc2UgZmxhZ3MuIFRoZSByZWdpc3RyeSBhc3NpZ25z IGJpdHMgdG8gc2luZ2xlIFJGQ3MgYXMgaW5kaXZpZHVhbCBiaW5hcnkgZmxhZ3MsIGJ1dCB0aGV5 IGFyZSBub3QgYmVpbmcgdXNlZCBsaWtlIHRoaXMuIEFjY0VDTiB1c2VkIGNvbWJpbmF0aW9ucyBv ZiB0aGUgRUNOIGZsYWdzIGFuZCBzdGF0ZXMgb2YgdGhlIFRDUCBzdGF0ZS1tYWNoaW5lDQogdGhh dCBoYWQgbm90IHlldCBiZWVuIHVzZWQgdG9nZXRoZXIsIGluIG9yZGVyIHRvIGluY3JlYXNlIHRo ZSBhdmFpbGFibGUgc3RhdGUgc3BhY2UuIFJGQyAzMTY4IGFuZCBSRkMzNTQwIGFsc28gZGlkIHRo aXMsIGFuZCBJJ20gc3VyZSBwZW9wbGUgY2FuIHRoaW5rIG9mIG1hbnkgb3RoZXIgVENQLWJhc2Vk IHByb3RvY29scyB0aGF0IGhhdmUgZG9uZSB0aGlzLg0KPGJyPg0KPGJyPg0KSG93ZXZlciwgd2Ug c3RpbGwgaW1hZ2luZSB0aGF0IGluZGl2aWR1YWwgZmxhZ3MgYXJlIGFzc2lnbmVkIHRvIGluZGl2 aWR1YWwgUkZDcy4gT3B0aW9uIChlKSByZWluZm9yY2VzIHRoaXMgZGVsdXNpb24sIHdoZXJlYXMg b3B0aW9uIChmKSBjaGFsbGVuZ2VzIGl0LiBIZW5jZSBvcHRpb24gKGUpICdmZWVscycgbW9yZSBh Y2NlcHRhYmxlLCBhcyBsb25nIGFzIHlvdSBzY3JldyB1cCB5b3VyIGV5ZXMgYW5kIGF2b2lkIHRo aW5raW5nIHRvbyBtdWNoLjxicj4NCjxicj4NCjxicj4NCjxicj4NCkkgZG91YnQgYW55b25lIHdh bnRzIHRvICZxdW90O2dvIHRoZXJlJnF1b3Q7IHJpZ2h0IG5vdy4gQnV0IGhlcmUncyB0ZXh0IHRo YXQgY291bGQgYmUgdXNlZCBpbiAmcXVvdDthbiBSRkMmcXVvdDsgKFRCQSkgdG8gY2hhbmdlIHRo ZSB3aG9sZSBUQ1AgZmxhZ3MgcmVnaXN0cnkgcG9saWN5IHRvIHJlZmxlY3Qgd2hhdCBpcyBhY3R1 YWxseSBoYXBwZW5pbmcgaW4gcHJhY3RpY2U6PGJyPg0KPGJyPg0Kb3B0aW9uIChnKSA8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij5JdCBoYXMgYmVjb21lIHR5cGljYWwgcHJhY3RpY2UgZm9yIHRoZSBUQ1AgbWFp bnRlbmFuY2Ugd29ya2luZyBncm91cCB0byBleHBlY3QgYW55IGNoYW5nZSB0byBUQ1AgdG8gYmUg ZG9jdW1lbnRlZCBhcyBhbiBleHBlcmltZW50YWwgUkZDIGFuZCBmb3IgdGhlIGV4cGVyaW1lbnQg dG8gYmUgZGVwbG95ZWQgYW5kIHByb3ZlZCBpbiBwcmFjdGljZSBiZWZvcmUNCiBjb21taXR0aW5n IHRlY2hub2xvZ3kgdG8gdGhlIHN0YW5kYXJkcyB0cmFjay48L3NwYW4+PC90dD48YnI+DQo8YnI+ DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlJGQzMxNjggYXNzaWduZWQgdGhl IENXUiBhbmQgRUNFIGZsYWdzIGZvciBpdHMgb3duIHVzZSBhcyBzaW5nbGUgYml0cyBhbmQgUkZD MzU0MCBhc3NpZ25lZCB0aGUgTlMgZmxhZyBmb3IgaXRzIG93biB1c2UgYXMgYW5vdGhlciBzaW5n bGUgYml0LiBIb3dldmVyLCBkdXJpbmcgVENQJ3MmbmJzcDsgaGFuZHNoYWtlIGJvdGggdGhlc2Ug UkZDcyB1c2UgY29tYmluYXRpb25zIG9mIHRoZXNlIGJpdHMNCiBhcyBjb2RlcG9pbnRzLCBub3Qg aW5kZXBlbmRlbnQgYmluYXJ5IGZsYWdzLiBSRkMzMTY4IGFuZCBSRkMzNTQwIGFsc28gZ2l2ZSB0 aGVzZSBiaXRzIGRpZmZlcmVudCBtZWFuaW5ncyB3aGVuIHVzZWQgYWZ0ZXIgdGhlIGhhbmRzaGFr ZS4gU28gdGhlc2UgdGhyZWUgYml0cyBhcmUgZWZmZWN0aXZlbHkgYmVpbmcgdXNlZCBpbiBjb21i aW5hdGlvbiB3aXRoIHRoZSBTWU4gYW5kIEFDSyBmbGFncyB0byBpbmNyZWFzZSB0aGUgYXZhaWxh YmxlIHN0YXRlDQogc3BhY2UgaW4gbm92ZWwgd2F5cy4gQXNzaWduaW5nIFRDUCBoZWFkZXIgZmxh Z3MgYXMgaW5kaXZpZHVhbCBiaXRzIHdhc3RlcyBhbGwgdGhlIGNvbWJpbmF0aW9ucyB0aGF0IHRo ZXNlIHR3byBSRkNzIGFuZCBvdGhlciBleGlzdGluZyBSRkNzIGRvIG5vdCB1c2UuDQo8L3NwYW4+ PC90dD48YnI+DQo8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlRoZSBw cmVzZW50IGRvY3VtZW50IFtlY24tZXhwZXJpbWVudGF0aW9uXSByZWNvZ25pemVzIHRoYXQNCjwv c3Bhbj48L3R0Pjxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+KiBhc3Np Z25pbmcgVENQIGZsYWdzIGluZGl2aWR1YWxseSBhbmQgZXhjbHVzaXZlbHkgdG8gc3RhbmRhcmRz IHRyYWNrIFJGQ3MgaXMgbm8gbG9uZ2VyIHR5cGljYWwgcHJhY3RpY2U7PC9zcGFuPjwvdHQ+PGJy Pg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4qIHRoZSBUQ1AgZmxhZ3MgYXJl IGFjdHVhbGx5IGJlaW5nIHVzZWQgaW4gbm92ZWwgd2F5cyB0aGF0IGFyZSBub3QgYW1lbmFibGUg dG8gc2ltcGxlIHJlZ2lzdHJhdGlvbiBieSBJQU5BOzwvc3Bhbj48L3R0Pjxicj4NCjx0dD48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+KiBjdXJyZW50IGlubm92YXRpb24gaW4gdGhpcyBz cGFjZSBpcyBpbiBzcGl0ZSBvZiB0aGUgJnF1b3Q7c3RhbmRhcmRzIGFjdGlvbiZxdW90OyByZWdp c3RyeSBwb2xpY3kgcmF0aGVyIHRoYW4gYmVjYXVzZSBvZiBpdC4NCjwvc3Bhbj48L3R0Pjxicj4N Cjxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+VGhlcmVmb3JlIHRoZSBy ZWdpc3RyeSBwb2xpY3kgYXMgYSB3aG9sZSBpcyBjaGFuZ2VkIHRvICZxdW90O0lFVEYgUmV2aWV3 JnF1b3Q7Ljwvc3Bhbj48L3R0PjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQo8 YnI+DQpCb2I8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiAwMy8wNy8xNyAxOToxNywgQy4gTS4gSGVhcmQgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJvYiwgPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoYXQgeW91ciBv cHRpb24gKGYpIGlzIGJldHRlciB0aGFuIG9wdGlvbiAoZSkgKHdoYXQgSSBzdWdnZXN0ZWQpLiBB cyBhbiBhc2lkZSwgZWl0aGVyIG9uZSBwYXRjaGVzIHVwIGFuIGFwcGFyZW50IHByb2Nlc3Mgdmlv bGF0aW9uIGNvbW1pdHRlZCBieSBSRkMgMzU0MCwgYW4gZXhwZXJpbWVudGFsIFJGQyB0aGF0IGFz c2lnbmVkIGJpdCA3IGluIGNvbnRyYWRpY3Rpb24gdG8gdGhlIHBvbGljeSBpbg0KIFJGQyAyNzgw LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5N aWtlIEhlYXJkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIE1vbiwgSnVsIDMsIDIwMTcgYXQgMTE6MDUgQU0sIEJvYiBCcmlzY29lICZsdDs8 YSBocmVmPSJtYWlsdG86aWV0ZkBib2JicmlzY29lLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmlldGZA Ym9iYnJpc2NvZS5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1pa2Us PGJyPg0KPGJyPg0KTGV0J3MgY2FsbCB0aGlzIG9wdGlvbjo8YnI+DQooZSkgZWNuLWV4cGVyaW1l bnRhdGlvbiBhbHRlcnMgdGhlIHJlZ2lzdHJ5IHBvbGljeSBvZiBiaXQgNyBvZiB0aGUgVENQIGhl YWRlciB0byAmcXVvdDtJRVRGIFJldmlldyZxdW90Oy48YnI+DQo8YnI+DQpIYXZpbmcgYSBkaWZm ZXJlbnQgcG9saWN5IGZvciBjZXJ0YWluIGJpdHMgd2l0aGluIGEgcmVnaXN0cnkgbWlnaHQgc2Vu ZCBJQU5BIGludG8gYSBzcGluLCBidXQgSSBhbSBzdXJlIHRoZXkgY291bGQgd3JpdGUgc3VpdGFi bGUgdGV4dCBpbnRvIHRoZSByZWdpc3RyeSBwb2xpY3kgaWYgdGhleSBoYWQgdG8uPGJyPg0KPGJy Pg0KSSBxdWl0ZSBsaWtlIHRoaXMgb25lLiBBbHRobyB1bm9ydGhvZG94LCBpdCdzIG5lYXQuPGJy Pg0KPGJyPg0KPGJyPg0KVGhhbmsgeW91Ljxicj4NCjxicj4NCjxicj4NCkJvYjxicj4NCjxicj4N ClBTLiBTdHJpY3RseSBSRkMzMTY4IHVzZWQgdGhlIENXUiBhbmQgRUNFIGZsYWdzIChiaXRzIDgg JmFtcDsgOSkgYXMgYSAyLWJpdCBmaWVsZCBkdXJpbmcgdGhlIDMtd2F5IGhhbmQtc2hha2UuIFdo aWxlIHRoZSBFQ04gTm9uY2UgYW5kIEFjY0VDTiB1c2UgdGhlIHRocmVlIEVDTiBmbGFncyAoYml0 cyA3LTkpIGFzIGEgMy1iaXQgZmllbGQgZHVyaW5nIHRoZSAzV0hTLiBBY2NFQ04gdXNlcyB0aGUg Y29tYmluYXRpb25zIHRoYXQgUkZDMzE2OCBhbmQgdGhlDQogTm9uY2UgZG8gbm90IHVzZS4gU28g dG8gY292ZXIgYWxsIGJhc2VzOjxicj4NCjxicj4NCk9wdGlvbiAoZik6IGVjbi1leHBlcmltZW50 YXRpb24gYWx0ZXJzIHRoZSByZWdpc3RyeSBwb2xpY3kgZm9yIGJpdHMgNy05IHRvICZxdW90O0lF VEYgUmV2aWV3JnF1b3Q7Lg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMDMvMDcvMTcgMTg6MTQsIEMu IE0uIEhlYXJkIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Im02MjQxNjM1ODUzMTI0MTQ1MjA0Z21haWwtcDEiPkJvYiw8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJtNjI0MTYzNTg1MzEyNDE0NTIwNGdtYWlsLXAyIj5Db3VsZG4ndCB0aGUg dGV4dCBpbiB0aGUgSUFOQSBjb25zaWRlcmF0aW9ucyBvZiBlY24tZXhwZXJpbWVudGF0aW9uICh3 aGljaCBuZWVkcyB0byBiZSB1cGRhdGVkIGluIGFueSBjYXNlKSBib3RoIGNoYW5nZSB0aGUgTlMg ZmxhZyB0byBSZXNlcnZlZCBmb3IgRUNOIEV4cGVyaW1lbnRhdGlvbiBhbmQgY2hhbmdlIHRoZSBh bGxvY2F0aW9uIHBvbGljeSBmb3IgdGhhdCBmbGFnIGZyb20NCiBTdGFuZGFyZHMgQWN0aW9uIHRv IElFVEYgUmV2aWV3LCB0aGVyZWJ5IHVwZGF0aW5nIFJGQyAyNzgwPyBUaGF0IHdvdWxkIGF2b2lk IHRoZSBjaHVybiBuZWVkZWQgdG8gYWRkIG1vdGl2YXRpbmcgdGV4dCBmb3IgYSA0dGggZXhwZXJp bWVudCB0byBlY24tZXhwZXJpbWVudGF0aW9uIGFuZCB3b3VsZCBhbGxvdyBBY2NFQ04gdG8gYXNz aWduIHRoZSBOUyBiaXQgaXRzZWxmIHdpdGhvdXQgYSBwcm9jZXNzIGV4Y2VwdGlvbi48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJtNjI0MTYzNTg1MzEyNDE0NTIwNGdtYWlsLXAyIj5NaWtlIEhl YXJkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTYyNDE2MzU4NTMxMjQxNDUyMDRnbWFpbC1w MiI+T24gTW9uLCAzIEp1bCAyMDE3IDEwOjI4OjI1ICYjNDM7MDEwMCwgQm9iIEJyaXNjb2UmbmJz cDt3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpUaW1lcyI+TWljaGFlbCoyLCBZ b3NoaWZ1bWksIEdvcnJ5LCBEYXZpZCwgV2VzLCBNaXJqYSwgU3BlbmNlciwgdGNwbSBsaXN0LCB0 c3Z3ZyBsaXN0LDxicj4NCjxicj4NClRoZXJlIGhhcyBiZWVuIHNvbWUgb2ZmbGlzdCBkaXNjdXNz aW9uIChhbW9uZyBkaWZmZXJlbnQgc3ViLWdyb3VwcykgdG8gbmFycm93IGRvd24gdGhlIG9wdGlv bnMgaGVyZS4gSXQgaXMgdGltZSB0byBzZWUgb3BpbmlvbnMgZnJvbSB0aGUgdHdvIGFmZmVjdGVk IFdHcyAodGNwbSBhbmQgdHN2d2cpIG9uIHByZWZlcnJlZCBwcm9jZXNzLCBlc3AuIGZyb20gdGhl IFdHIGNoYWlycyBhbmQgQURzLjxicj4NCjxicj4NCjxiPj09QmFja2dyb3VuZCB0byB0aGUgUHJv Y2VzcyBQcm9ibGVtPT08YnI+DQo8L2I+PGJyPg0KSW4gdHN2d2cgdGhlIHByb2Nlc3MgaXMgaW4g bW90aW9uIHRvIG1ha2UgdGhlIEVDTiBub25jZSBbUkZDIDM1NDBdIGhpc3RvcmljLiBTbywgaW4g dGhlIG1vc3QgcmVjZW50IHJldiBvZiBkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuLTAzICwg d2UgY291bGQgZmluYWxseSBpbmNsdWRlIElBTkEgYXNzaWdubWVudCBvZiB0aGUgTlMgZmxhZzxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAoc2VlJm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuLTAzI3NlY3Rp b24tNiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQt ZmFtaWx5OlRpbWVzIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10Y3Bt LWFjY3VyYXRlLWVjbi0wMyNzZWN0aW9uLTY8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTMuNXB0O2ZvbnQtZmFtaWx5OlRpbWVzIj4mbmJzcDspPGJyPg0KPGJyPg0KSG93ZXZlciwg QWNjRUNOIGlzIEVYUGVyaW1lbnRhbCwgd2hlcmVhcyB0aGUgcmVnaXN0cnkgcG9saWN5IGZvciBh c3NpZ25pbmcgVENQIGZsYWdzIGlzICZxdW90O1N0YW5kYXJkcyBBY3Rpb24mcXVvdDs8YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWFuYS5v cmcvYXNzaWdubWVudHMvdGNwLWhlYWRlci1mbGFncy90Y3AtaGVhZGVyLWZsYWdzLnhodG1sIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6 VGltZXMiPmh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3RjcC1oZWFkZXItZmxhZ3Mv dGNwLWhlYWRlci1mbGFncy54aHRtbDwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox My41cHQ7Zm9udC1mYW1pbHk6VGltZXMiPjxicj4NCndoaWNoIG1lYW5zICZxdW90O1ZhbHVlcyBh cmUgYXNzaWduZWQgb25seSBmb3IgU3RhbmRhcmRzIFRyYWNrIFJGQ3MgYXBwcm92ZWQgYnkgdGhl IElFU0cmcXVvdDsgW1JGQzI0MzRdLjxicj4NCjxicj4NClJlZmVyZW5jZXM6PGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7IFByb2Nlc3MgZm9yIGRlc2lnbmF0aW5nIFJGQ3MgYXMgaGlzdG9yaWM6Jm5i c3A7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bh bj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kZXNpZ25hdGlu Zy1yZmNzLWFzLWhpc3RvcmljLmh0bWwiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpUaW1lcyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVz Zy9zdGF0ZW1lbnQvZGVzaWduYXRpbmctcmZjcy1hcy1oaXN0b3JpYy5odG1sPC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpUaW1lcyI+PGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7IEN1cnJlbnQgZHJhZnQgdGV4dCB0byBtYWtlIFJGQyAzNTQwIGhpc3Rv cmljOiZuYnNwOzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt dHN2d2ctZWNuLWV4cGVyaW1lbnRhdGlvbi0wMyNzZWN0aW9uLTMiIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpUaW1lcyI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHN2d2ctZWNuLWV4cGVyaW1lbnRhdGlvbi0w MyNzZWN0aW9uLTM8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQt ZmFtaWx5OlRpbWVzIj48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgTXkgaW5pdGlhbCBkcmFmdCBm b3IgdGhlIEFEJ3Mgc3RhdHVzIGNoYW5nZSBub3RlOiZuYnNwOzxicj4NCiZuYnNwOyZuYnNwOyZu YnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9naXRo dWIuY29tL2JicmlzY29lL2Vjbi1leHBlcmltZW50YXRpb24vYmxvYi9tYXN0ZXIvc3RhdHVzLWNo YW5nZS1lY24tbm9uY2UtcmZjMzU0MC10by1oaXN0b3JpYy0wMC50eHQiIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpUaW1lcyI+aHR0cHM6 Ly9naXRodWIuY29tL2JicmlzY29lL2Vjbi1leHBlcmltZW50YXRpb24vYmxvYi9tYXN0ZXIvc3Rh dHVzLWNoYW5nZS1lY24tbm9uY2UtcmZjMzU0MC10by1oaXN0b3JpYy0wMC50eHQ8L3NwYW4+PC9h PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OlRpbWVzIj48YnI+DQo8 YnI+DQplY24tZXhwZXJpbWVudGF0aW9uIGhhcyBqdXN0IGNvbXBsZXRlZCBXR0xDLiBJdCBzdGls bCBoYXMgdG8gZ28gdGhyb3VnaCBJRVRGIExDIChhZnRlciBQcmFndWUpLiBpdCBpcyBkZWxpYmVy YXRlbHkgUFMgaW4gb3JkZXIgdG8gYmUgYWJsZSB0byByZWxheCBwcmUtZXhpc3RpbmcgY29uc3Ry YWludHMgb24gRUNOIGV4cGVyaW1lbnRzIGluIHN0YW5kYXJkcyB0cmFjayBSRkNzLiBIb3dldmVy LCBpZiBwb3NzLCB3ZSB3YW50IHRvIGF2b2lkIGFkZGluZw0KIG1vdGl2YXRpbmcgdGV4dCBmb3Ig YSA0dGggZXhwZXJpbWVudCwgd2hpY2ggY291bGQgcmVxdWlyZSBhbm90aGVyIGN5Y2xlIG9mIFdH TEMgYW5kIGRlbGF5IHVudGlsIE5vdi4mbmJzcDs8YnI+DQo8YnI+DQpSRkMgMzY5MiAoJnF1b3Q7 QXNzaWduaW5nIEV4cGVyaW1lbnRhbCBhbmQgVGVzdGluZyBOdW1iZXJzIENvbnNpZGVyZWQgVXNl ZnVsJnF1b3Q7KSBjb3VsZCBhbHNvIGJlIHJlbGV2YW50LCBhbHRob3VnaCBpdCBkb2Vzbid0IHNl ZW0gdG8gaGVscCBoZXJlLCBiZWNhdXNlIGl0IGlzIHByaW1hcmlseSBhaW1lZCBhdCBsYXJnZXIg Y29kZXBvaW50IHNwYWNlcywgbm90IHNpbmdsZSBiaXRzLjxicj4NCjxicj4NCjxicj4NCjxiPj09 UHJvY2VzcyBPcHRpb25zPT08YnI+DQo8L2I+PGJyPg0KVGhlcmUgbmVlZCB0byBiZSB0d28gcGFy dHMgdG8gdGhlIHByb2Nlc3M6IDEpIHVuYXNzaWdubWVudCBhbmQgMikgcmVhc3NpZ25tZW50LiBU aGUgZmlyc3Qgc2VlbXMgY2xlYXItY3V0LiBUaGUgc2Vjb25kIGlzIGxlc3Mgb2J2aW91cy48YnI+ DQo8YnI+DQoxKSBVbmFzc2lnbmluZyB0aGUgTlMgZmxhZyBmcm9tIFJGQyAzNTQwPGJyPg0KYSkg YWRkIHRleHQgdG8gSUFOQSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIG9mIGVjbi1leHBlcmllbnRh dGlvbiBtYWtpbmcgdGhlIE5TIGZsYWcgcmVzZXJ2ZWQ8YnI+DQo8YnI+DQoyKSBBc3NpZ25pbmcg dGhlIE5TIGZsYWcgdG8gYWNjdXJhdGUtZWNuIChhbmQgcmVuYW1pbmcgaXQgdGhlIEFFIGZsYWcp LiZuYnNwOzxicj4NClByb2Nlc3Mgb3B0aW9uczo8YnI+DQphKSBlY24tZXhwZXJpbWVudGF0aW9u IGFzc2lnbnMgZmxhZyB0byBpdHNlbGYgYXMgcmVzZXJ2ZWQgZm9yIGV4cGVyaW1lbnRzIGFuZCBz YXlzIGluaXRpYWxseSB0aGUgQWNjRUNOIGV4cGVyaW1lbnQgd2lsbCB1c2UgaXQgZXhjbHVzaXZl bHkmbmJzcDs8YnI+DQpiKSBlY24tZXhwZXJpbWVudGF0aW9uIGFzc2lnbnMgTlMgZmxhZyBleGNs dXNpdmVseSB0byBBY2NFQ04mbmJzcDs8YnI+DQpjKSBBY2NFQ04gYXNzaWducyBOUyBmbGFnIHRv IGl0c2VsZiwgd2l0aCBhIHByb2Nlc3MgZXhjZXB0aW9uIHByb3Bvc2VkIHRvIHRoZSBJRVNHIHRv IGFsbG93IGFuIEVYUCBkb2MgdG8gYXNzaWduIHRvIGEgU3RhbmRhcmRzIEFjdGlvbiByZWdpc3Ry eSZuYnNwOzxicj4NCmQpIHRoZSBOUyBmbGFnIGlzIHJlYXNzaWduZWQgYnkgJnF1b3Q7QUQgcmV2 aWV3IGNvbW1lbnQmcXVvdDsgb3IgJnF1b3Q7SUVURiBMYXN0IENhbGwgY29tbWVudCZxdW90OyAo cXVvdGVkIGZyb20gRGF2aWQncyBzdWdnZXN0aW9ucyk8YnI+DQplKSBvdGhlcj8uLi48YnI+DQo8 YnI+DQpUaGUgZGlmZmVyZW5jZSBiZXR3ZWVuIChhKSBhbmQgKGIpIGlzIGluIHRoZSBkb2N1bWVu dCB0aGF0IGVuZHMgdXAgYmVpbmcgcmVmZXJlbmNlZCBmcm9tIHRoZSBJQU5BIHJlZ2lzdHJ5OiZu YnNwOzxicj4NCmEpJm5ic3A7IGVjbi1leHBlcmltZW50YXRpb24mbmJzcDs8YnI+DQpiKSBhY2N1 cmF0ZS1lY24mbmJzcDs8YnI+DQo8YnI+DQo8Yj49PU15IG93biBwcmVmZXJlbmNlcz09PGJyPg0K PC9iPjxicj4NCkR1cmluZyBkaXNjdXNzaW9ucywgSSBkaWRuJ3QgcHJlZmVyIChjKSBjb3MgSSB0 aG91Z2h0IHRoZSBJRVNHIG1pZ2h0IHF1ZXN0aW9uIHdoeSB0aGV5IGFyZSBiZWluZyBhc2tlZCB0 byBtYWtlIGEgcHJvY2VzcyBleGNlcHRpb24gZm9yIGFuIEVDTiBleHBlcmltZW50IGF0IHRoZSBz YW1lIHRpbWUgYXMgYSBkcmFmdCBpcyBnb2luZyB0aHJvdWdoIHRoYXQgYXZvaWRzIHJhaXNpbmcg cHJvY2VzcyBleGNlcHRpb25zIGZvciBFQ04gZXhwZXJpbWVudHMuJm5ic3A7PGJyPg0KPGJyPg0K Tm9uZXRoZWxlc3MsIHNpbmNlIHRoZW4sIE1pcmphIGhhcyBzYWlkLi4uPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTMuNXB0O2ZvbnQtZmFtaWx5OlRpbWVzIj5PbiAwMi8wNy8xNyAyMzo0MCwgTWlyamEgS8O8 aGxld2luZCB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5JIGFj dHVhbGx5IHByZWZlciBvcHRpb24gKGMpLiBJIGRvbuKAmXQgdGhpbmsgYSBwcm9jZXNzIGV4Y2Vw dGlvbiBpcyBhIGJhZCB0aGluZy4gSWYgaXTigJlzIHRoZSByaWdodCB0aGluZyB0byBkbywgdGhl biB0aGF0IHRoZSByZWFzb24gd2h5IHdlIGhhdmUgc3VjaCBleGNlcHRpb25zLiBBbHNvIEkgdGhp bmsgaXTigJlkIGJlIHRoZSByaWdodCB0aGluZyB0byBjaGFuZ2UgdGhlIHJlZ2lzdHJ5IHBvbGlj eeKApiBidXQgdGhhdCBwcm9iYWJseSBhIGxvbmdlciBzdG9yeS48bzpwPjwvbzpwPjwvcHJlPg0K PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMy41cHQ7Zm9udC1mYW1pbHk6VGltZXMiPkkgYWdyZWUgdGhhdCBpdCBpcyBvdXRkYXRlZCB0 aGF0IHRoZSByZWdpc3RyeSByZXF1aXJlcyBhIHN0YW5kYXJkcyBhY3Rpb24sIGJlY2F1c2UgaXQg aGFzIGJlY29tZSBub3JtYWwgdGNwbSBwcmFjdGljZSBmb3IgYW55IGNoYW5nZSB0byBUQ1AgdG8g aGF2ZSB0byBzdGFydCBvbiB0aGUgZXhwZXJpbWVudGFsIHRyYWNrLiBTbw0KIHRoaXMgd291bGQg anVzdGlmeSBhIHByb2Nlc3MgZXhjZXB0aW9uLjxicj4NCjxicj4NClNvLCBpbiBzdW1tYXJ5LCBJ IGRvbid0IG1pbmQgKGEpLCAoYikgb3IgKGMpLiBJIHRoaW5rIChkKSBpcyBub3Qgc3VmZmljaWVu dGx5IG9wZW4gYW5kIHJlY29yZGVkIGZvciBhc3NpZ25tZW50IG9mIGEgZmxhZyBpbiB0aGUgbWFp biBUQ1AgaGVhZGVyLjxicj4NCjxicj4NCjxicj4NCkJvYjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+LS0gPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5Cb2IgQnJp c2NvZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwOi8vYm9iYnJpc2NvZS5uZXQvIiB0YXJnZXQ9Il9i bGFuayI+aHR0cDovL2JvYmJyaXNjb2UubmV0LzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+LS0gPG86cD48 L286cD48L3ByZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkJvYiBCcmlz Y29lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly9ib2JicmlzY29lLm5ldC8iPmh0dHA6Ly9ib2Ji cmlzY29lLm5ldC88L2E+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_AM5PR0701MB254703B53B5628C6FCCD912893D70AM5PR0701MB2547_-- From nobody Tue Jul 4 01:24:41 2017 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 EF4D2131B04 for ; Tue, 4 Jul 2017 01:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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 mFx4PNEeRJuS for ; Tue, 4 Jul 2017 01:24:37 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 153B6129B70 for ; Tue, 4 Jul 2017 01:24:36 -0700 (PDT) Received: from MacBook-2.local (at-zeroshell-1.erg.abdn.ac.uk [139.133.217.68]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 766201BE7C5B for ; Tue, 4 Jul 2017 10:48:07 +0100 (BST) Message-ID: <595B4997.7080002@erg.abdn.ac.uk> Date: Tue, 04 Jul 2017 09:53:59 +0200 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: tsvwg WG References: <149909666841.22758.7054606546239437372.idtracker@ietfa.amsl.com> In-Reply-To: <149909666841.22758.7054606546239437372.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <149909666841.22758.7054606546239437372.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tsvwg] Fwd: New Version Notification for draft-fairhurst-tsvwg-datagram-plpmtud-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 08:24:40 -0000 Several of us have just submitted a draft on the requirements for designing PL PMTUD for datagrams transports. Feedback would be welcome on the list or to the authors. We plan to develop this draft and include details of how to implement this for datagram transports. Gorry --- A new version of I-D, draft-fairhurst-tsvwg-datagram-plpmtud-00.txt has been successfully submitted by Godred Fairhurst and posted to the IETF repository. Name: draft-fairhurst-tsvwg-datagram-plpmtud Revision: 00 Title: Packetization Layer Path MTU Discovery for Datagram Transports Document date: 2017-07-03 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-fairhurst-tsvwg-datagram-plpmtud-00.txt Status: https://datatracker.ietf.org/doc/draft-fairhurst-tsvwg-datagram-plpmtud/ Htmlized: https://tools.ietf.org/html/draft-fairhurst-tsvwg-datagram-plpmtud-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-fairhurst-tsvwg-datagram-plpmtud-00 Abstract: This document describes a robust method for Path MTU Discovery (PMTUD) for datagram packetization layers. It allows these layers to probe an Internet path with progressively larger packets to determine a maximum packet size This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP versions 4 and 6. The document provides functionally for datagram transports that is equivalent to the packetization layer PMTUD specification for TCP, specified in RFC4821. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Jul 4 07:08:16 2017 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 2DDC21320B3; Tue, 4 Jul 2017 07:08:07 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 a1_Z-_Qyk2zw; Tue, 4 Jul 2017 07:08:03 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87DCE1320B0; Tue, 4 Jul 2017 07:08:02 -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:From:References:Cc: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=SuhJrgc+InXWSfKZ0PMNvLq3E0eygse4sbSYzKEmSYU=; b=wVHerJhy31PZcrufA83zeXO+L veQAigzkRtIUaQR2tFEPOHLhQ8rIAE7DqkWelrc43YHHcqMRynRtcUYYSqMGyoMF8sTiuS3/kk3lR QSJHGmjuJCs6nh0ZRMRvLCOYHQZKx54iFQ89lFfDMWRnUBIStA/K9Ab0boNoGQxvmOBPnvu9wxMhO VwZke89hrC2pcR2aViS7LErEccGlTEQlIBr6gjFJhTnq5SLvZoYDiDiWXHoBdnJp4GGzxTxUuWIy/ R7AZk+VOvcCwl5k5yUv8L+5lAmujjravZdPhChq57A7R79NXOX4unSxf6iJ9HscQyfUnLye1b2V0O mIQNMKxrQ==; Received: from [31.185.128.124] (port=48270 helo=[192.168.0.13]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dSOUh-0001tC-Ib; Tue, 04 Jul 2017 15:08:00 +0100 To: "Scharf, Michael (Nokia - DE/Stuttgart)" Cc: "C. M. Heard" , tcpm , tcpm-chairs , tsvwg , tsvwg-chairs , tsv-ads References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> <4deec720-6773-fca4-6797-37bb5c845d70@bobbriscoe.net> From: Bob Briscoe Message-ID: Date: Tue, 4 Jul 2017 15:07:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6C30CFA33F650B94EE9881C6" 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] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 14:08:07 -0000 This is a multi-part message in MIME format. --------------6C30CFA33F650B94EE9881C6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Michael, Actually I had first typed "accepted practice", but realized this would probably attract argument, so I changed it to "typical practice". BTW, I think this is completely understandable - one would expect a high bar for standards track changes to TCP, esp. changes to the wire protocol. My point was that, perversely, an "IETF Review" registry policy ought to be more characteristic of a protocol that is critical to the Internet, like TCP. Data points about the RFCs on https://tools.ietf.org/wg/tcpm/ 11 INF 1 BCP 10 EXP 12 PS 1 DS Of the 12 PSs, 6 obsolete previous RFCs, 2 update previous RFCs, 4 were new (not based on a previous RFC) None of the 4 new ones update the TCP wire protocol: 1 was a new TCP option, 1 was about numbering TCP options 1 was a crypto algorithm 1 (RFC5691) was essentially an update to RFC793, but did not formally update it Bob On 04/07/17 09:23, Scharf, Michael (Nokia - DE/Stuttgart) wrote: > > A comment on this statement: “It has become typical practice for the > TCP maintenance working group to expect any change to TCP to be > documented as an experimental RFC and for the experiment to be > deployed and proved in practice before committing technology to the > standards track.†> > > TCPM decides on the status of documents case-by-case, by working group > consensus. > > Nothing prevents TCPM from publishing documents on standards track. > The requirements in RFC 2026 Section 4.1.1 may be a bit harder to meet > for TCP extensions and algorithms, compared to other IETF protocols, > given the wide deployment of TCP in very different environments. And, > indeed, the TCPM community consensus for some recent documents was to > publish work (first) as experimental. These decisions have always been > pretty unanimous, as far as I recall. But clearly if the community > consensus is standards track, TCPM will submit documents on standards > track… > > Michael > > *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net] > *Sent:* Monday, July 03, 2017 11:04 PM > *To:* C. M. Heard > *Cc:* tcpm ; tcpm-chairs ; tsvwg > ; tsvwg-chairs ; tsv-ads > > *Subject:* Re: Process for re-assignment of NS TCP header flag to AccECN > > Mike, > > It may not be so straightforward. > * It is relatively easy to justify changing the policy for the flag > that is released by making the Nonce historic, which > ecn-experimentation is already giving rationale for. > * Strictly it would require text to justify changing the registry > policy for the other 2 flags that are still assigned to RFC3168 on the > standards track. > > This is actually a symptom of a larger problem with the registry for > these flags. The registry assigns bits to single RFCs as individual > binary flags, but they are not being used like this. AccECN used > combinations of the ECN flags and states of the TCP state-machine that > had not yet been used together, in order to increase the available > state space. RFC 3168 and RFC3540 also did this, and I'm sure people > can think of many other TCP-based protocols that have done this. > > However, we still imagine that individual flags are assigned to > individual RFCs. Option (e) reinforces this delusion, whereas option > (f) challenges it. Hence option (e) 'feels' more acceptable, as long > as you screw up your eyes and avoid thinking too much. > > > > I doubt anyone wants to "go there" right now. But here's text that > could be used in "an RFC" (TBA) to change the whole TCP flags registry > policy to reflect what is actually happening in practice: > > option (g) > > It has become typical practice for the TCP maintenance working > group to expect any change to TCP to be documented as an > experimental RFC and for the experiment to be deployed and proved > in practice before committing technology to the standards track. > > RFC3168 assigned the CWR and ECE flags for its own use as single > bits and RFC3540 assigned the NS flag for its own use as another > single bit. However, during TCP's handshake both these RFCs use > combinations of these bits as codepoints, not independent binary > flags. RFC3168 and RFC3540 also give these bits different meanings > when used after the handshake. So these three bits are effectively > being used in combination with the SYN and ACK flags to increase > the available state space in novel ways. Assigning TCP header > flags as individual bits wastes all the combinations that these > two RFCs and other existing RFCs do not use. > > The present document [ecn-experimentation] recognizes that > * assigning TCP flags individually and exclusively to standards > track RFCs is no longer typical practice; > * the TCP flags are actually being used in novel ways that are not > amenable to simple registration by IANA; > * current innovation in this space is in spite of the "standards > action" registry policy rather than because of it. > > Therefore the registry policy as a whole is changed to "IETF Review". > > > > > Bob > > On 03/07/17 19:17, C. M. Heard wrote: > > Bob, > > I think that your option (f) is better than option (e) (what I > suggested). As an aside, either one patches up an apparent process > violation committed by RFC 3540, an experimental RFC that assigned > bit 7 in contradiction to the policy in RFC 2780. > > Mike Heard > > On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe > wrote: > > Mike, > > Let's call this option: > (e) ecn-experimentation alters the registry policy of bit 7 of > the TCP header to "IETF Review". > > Having a different policy for certain bits within a registry > might send IANA into a spin, but I am sure they could write > suitable text into the registry policy if they had to. > > I quite like this one. Altho unorthodox, it's neat. > > > Thank you. > > > Bob > > PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) > as a 2-bit field during the 3-way hand-shake. While the ECN > Nonce and AccECN use the three ECN flags (bits 7-9) as a 3-bit > field during the 3WHS. AccECN uses the combinations that > RFC3168 and the Nonce do not use. So to cover all bases: > > Option (f): ecn-experimentation alters the registry policy for > bits 7-9 to "IETF Review". > > On 03/07/17 18:14, C. M. Heard wrote: > > Bob, > > Couldn't the text in the IANA considerations of > ecn-experimentation (which needs to be updated in any > case) both change the NS flag to Reserved for ECN > Experimentation and change the allocation policy for that > flag from Standards Action to IETF Review, thereby > updating RFC 2780? That would avoid the churn needed to > add motivating text for a 4th experiment to > ecn-experimentation and would allow AccECN to assign the > NS bit itself without a process exception. > > Mike Heard > > On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote: > > Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, > Spencer, tcpm list, tsvwg list, > > There has been some offlist discussion (among > different sub-groups) to narrow down the options here. > It is time to see opinions from the two affected WGs > (tcpm and tsvwg) on preferred process, esp. from the > WG chairs and ADs. > > *==Background to the Process Problem== > * > In tsvwg the process is in motion to make the ECN > nonce [RFC 3540] historic. So, in the most recent rev > of draft-ietf-tcpm-accurate-ecn-03 , we could finally > include IANA assignment of the NS flag > (see > https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6 ) > > However, AccECN is EXPerimental, whereas the registry > policy for assigning TCP flags is "Standards Action" > https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml > which means "Values are assigned only for Standards > Track RFCs approved by the IESG" [RFC2434]. > > References: > Process for designating RFCs as historic: > https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html > Current draft text to make RFC 3540 historic: > https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3 > My initial draft for the AD's status change note: > https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt > > ecn-experimentation has just completed WGLC. It still > has to go through IETF LC (after Prague). it is > deliberately PS in order to be able to relax > pre-existing constraints on ECN experiments in > standards track RFCs. However, if poss, we want to > avoid adding motivating text for a 4th experiment, > which could require another cycle of WGLC and delay > until Nov. > > RFC 3692 ("Assigning Experimental and Testing Numbers > Considered Useful") could also be relevant, although > it doesn't seem to help here, because it is primarily > aimed at larger codepoint spaces, not single bits. > > > *==Process Options== > * > There need to be two parts to the process: 1) > unassignment and 2) reassignment. The first seems > clear-cut. The second is less obvious. > > 1) Unassigning the NS flag from RFC 3540 > a) add text to IANA considerations section of > ecn-experientation making the NS flag reserved > > 2) Assigning the NS flag to accurate-ecn (and renaming > it the AE flag). > Process options: > a) ecn-experimentation assigns flag to itself as > reserved for experiments and says initially the AccECN > experiment will use it exclusively > b) ecn-experimentation assigns NS flag exclusively to > AccECN > c) AccECN assigns NS flag to itself, with a process > exception proposed to the IESG to allow an EXP doc to > assign to a Standards Action registry > d) the NS flag is reassigned by "AD review comment" or > "IETF Last Call comment" (quoted from David's suggestions) > e) other?... > > The difference between (a) and (b) is in the document > that ends up being referenced from the IANA registry: > a) ecn-experimentation > b) accurate-ecn > > *==My own preferences== > * > During discussions, I didn't prefer (c) cos I thought > the IESG might question why they are being asked to > make a process exception for an ECN experiment at the > same time as a draft is going through that avoids > raising process exceptions for ECN experiments. > > Nonetheless, since then, Mirja has said... > > On 02/07/17 23:40, Mirja Kühlewind wrote: > > I actually prefer option (c). I don’t think a process exception is a bad thing. If it’s the right thing to do, then that the reason why we have such exceptions. Also I think it’d be the right thing to change the registry policy… but that probably a longer story. > > I agree that it is outdated that the registry requires > a standards action, because it has become normal tcpm > practice for any change to TCP to have to start on the > experimental track. So this would justify a process > exception. > > So, in summary, I don't mind (a), (b) or (c). I think > (d) is not sufficiently open and recorded for > assignment of a flag in the main TCP header. > > > Bob > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ > > > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------6C30CFA33F650B94EE9881C6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Michael,

Actually I had first typed "accepted practice", but realized this would probably attract argument, so I changed it to "typical practice".
BTW, I think this is completely understandable - one would expect a high bar for standards track changes to TCP, esp. changes to the wire protocol.
My point was that, perversely, an "IETF Review" registry policy ought to be more characteristic of a protocol that is critical to the Internet, like TCP.

Data points about the RFCs on https://tools.ietf.org/wg/tcpm/

11 INF
1 BCP
10 EXP
12 PS
1 DS

Of the 12 PSs,
 6 obsolete previous RFCs,
 2 update previous RFCs,
 4 were new (not based on a previous RFC)

None of the 4 new ones update the TCP wire protocol:
 1 was a new TCP option,
 1 was about numbering TCP options
 1 was a crypto algorithm
 1 (RFC5691) was essentially an update to RFC793, but did not formally update it



Bob

On 04/07/17 09:23, Scharf, Michael (Nokia - DE/Stuttgart) wrote:

A comment on this statement: “It has become typical practice for the TCP maintenance working group to expect any change to TCP to be documented as an experimental RFC and for the experiment to be deployed and proved in practice before committing technology to the standards track.â€


TCPM decides on the status of documents case-by-case, by working group consensus.

 

Nothing prevents TCPM from publishing documents on standards track. The requirements in RFC 2026 Section 4.1.1 may be a bit harder to meet for TCP extensions and algorithms, compared to other IETF protocols, given the wide deployment of TCP in very different environments. And, indeed, the TCPM community consensus for some recent documents was to publish work (first) as experimental. These decisions have always been pretty unanimous, as far as I recall. But clearly if the community consensus is standards track, TCPM will submit documents on standards track…

 

Michael

 

 

 

From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: Monday, July 03, 2017 11:04 PM
To: C. M. Heard <heard@pobox.com>
Cc: tcpm <tcpm@ietf.org>; tcpm-chairs <tcpm-chairs@ietf.org>; tsvwg <tsvwg@ietf.org>; tsvwg-chairs <tsvwg-chairs@ietf.org>; tsv-ads <tsv-ads@ietf.org>
Subject: Re: Process for re-assignment of NS TCP header flag to AccECN

 

Mike,

It may not be so straightforward.
* It is relatively easy to justify changing the policy for the flag that is released by making the Nonce historic, which ecn-experimentation is already giving rationale for.
* Strictly it would require text to justify changing the registry policy for the other 2 flags that are still assigned to RFC3168 on the standards track.

This is actually a symptom of a larger problem with the registry for these flags. The registry assigns bits to single RFCs as individual binary flags, but they are not being used like this. AccECN used combinations of the ECN flags and states of the TCP state-machine that had not yet been used together, in order to increase the available state space. RFC 3168 and RFC3540 also did this, and I'm sure people can think of many other TCP-based protocols that have done this.

However, we still imagine that individual flags are assigned to individual RFCs. Option (e) reinforces this delusion, whereas option (f) challenges it. Hence option (e) 'feels' more acceptable, as long as you screw up your eyes and avoid thinking too much.



I doubt anyone wants to "go there" right now. But here's text that could be used in "an RFC" (TBA) to change the whole TCP flags registry policy to reflect what is actually happening in practice:

option (g)

It has become typical practice for the TCP maintenance working group to expect any change to TCP to be documented as an experimental RFC and for the experiment to be deployed and proved in practice before committing technology to the standards track.

RFC3168 assigned the CWR and ECE flags for its own use as single bits and RFC3540 assigned the NS flag for its own use as another single bit. However, during TCP's  handshake both these RFCs use combinations of these bits as codepoints, not independent binary flags. RFC3168 and RFC3540 also give these bits different meanings when used after the handshake. So these three bits are effectively being used in combination with the SYN and ACK flags to increase the available state space in novel ways. Assigning TCP header flags as individual bits wastes all the combinations that these two RFCs and other existing RFCs do not use.

The present document [ecn-experimentation] recognizes that
* assigning TCP flags individually and exclusively to standards track RFCs is no longer typical practice;
* the TCP flags are actually being used in novel ways that are not amenable to simple registration by IANA;
* current innovation in this space is in spite of the "standards action" registry policy rather than because of it.

Therefore the registry policy as a whole is changed to "IETF Review".




Bob

On 03/07/17 19:17, C. M. Heard wrote:

Bob,

 

I think that your option (f) is better than option (e) (what I suggested). As an aside, either one patches up an apparent process violation committed by RFC 3540, an experimental RFC that assigned bit 7 in contradiction to the policy in RFC 2780.

 

Mike Heard

 

On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:

Mike,

Let's call this option:
(e) ecn-experimentation alters the registry policy of bit 7 of the TCP header to "IETF Review".

Having a different policy for certain bits within a registry might send IANA into a spin, but I am sure they could write suitable text into the registry policy if they had to.

I quite like this one. Altho unorthodox, it's neat.


Thank you.


Bob

PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as a 2-bit field during the 3-way hand-shake. While the ECN Nonce and AccECN use the three ECN flags (bits 7-9) as a 3-bit field during the 3WHS. AccECN uses the combinations that RFC3168 and the Nonce do not use. So to cover all bases:

Option (f): ecn-experimentation alters the registry policy for bits 7-9 to "IETF Review".

 

On 03/07/17 18:14, C. M. Heard wrote:

Bob,

Couldn't the text in the IANA considerations of ecn-experimentation (which needs to be updated in any case) both change the NS flag to Reserved for ECN Experimentation and change the allocation policy for that flag from Standards Action to IETF Review, thereby updating RFC 2780? That would avoid the churn needed to add motivating text for a 4th experiment to ecn-experimentation and would allow AccECN to assign the NS bit itself without a process exception.

Mike Heard

On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote:

Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, tcpm list, tsvwg list,

There has been some offlist discussion (among different sub-groups) to narrow down the options here. It is time to see opinions from the two affected WGs (tcpm and tsvwg) on preferred process, esp. from the WG chairs and ADs.

==Background to the Process Problem==

In tsvwg the process is in motion to make the ECN nonce [RFC 3540] historic. So, in the most recent rev of draft-ietf-tcpm-accurate-ecn-03 , we could finally include IANA assignment of the NS flag
    (see https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6 )

However, AccECN is EXPerimental, whereas the registry policy for assigning TCP flags is "Standards Action"
    https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml
which means "Values are assigned only for Standards Track RFCs approved by the IESG" [RFC2434].

References:
    Process for designating RFCs as historic: 
        https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html
    Current draft text to make RFC 3540 historic: 
        https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3
    My initial draft for the AD's status change note: 
        https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt

ecn-experimentation has just completed WGLC. It still has to go through IETF LC (after Prague). it is deliberately PS in order to be able to relax pre-existing constraints on ECN experiments in standards track RFCs. However, if poss, we want to avoid adding motivating text for a 4th experiment, which could require another cycle of WGLC and delay until Nov. 

RFC 3692 ("Assigning Experimental and Testing Numbers Considered Useful") could also be relevant, although it doesn't seem to help here, because it is primarily aimed at larger codepoint spaces, not single bits.


==Process Options==

There need to be two parts to the process: 1) unassignment and 2) reassignment. The first seems clear-cut. The second is less obvious.

1) Unassigning the NS flag from RFC 3540
a) add text to IANA considerations section of ecn-experientation making the NS flag reserved

2) Assigning the NS flag to accurate-ecn (and renaming it the AE flag). 
Process options:
a) ecn-experimentation assigns flag to itself as reserved for experiments and says initially the AccECN experiment will use it exclusively 
b) ecn-experimentation assigns NS flag exclusively to AccECN 
c) AccECN assigns NS flag to itself, with a process exception proposed to the IESG to allow an EXP doc to assign to a Standards Action registry 
d) the NS flag is reassigned by "AD review comment" or "IETF Last Call comment" (quoted from David's suggestions)
e) other?...

The difference between (a) and (b) is in the document that ends up being referenced from the IANA registry: 
a)  ecn-experimentation 
b) accurate-ecn 

==My own preferences==

During discussions, I didn't prefer (c) cos I thought the IESG might question why they are being asked to make a process exception for an ECN experiment at the same time as a draft is going through that avoids raising process exceptions for ECN experiments. 

Nonetheless, since then, Mirja has said...

On 02/07/17 23:40, Mirja Kühlewind wrote:

I actually prefer option (c). I don’t think a process exception is a bad thing. If it’s the right thing to do, then that the reason why we have such exceptions. Also I think it’d be the right thing to change the registry policy… but that probably a longer story.

I agree that it is outdated that the registry requires a standards action, because it has become normal tcpm practice for any change to TCP to have to start on the experimental track. So this would justify a process exception.

So, in summary, I don't mind (a), (b) or (c). I think (d) is not sufficiently open and recorded for assignment of a flag in the main TCP header.


Bob

 

 

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

 



-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------6C30CFA33F650B94EE9881C6-- From nobody Tue Jul 4 07:20:03 2017 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 E354E13146D; Tue, 4 Jul 2017 07:19:55 -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 At8JtZ_EJoSg; Tue, 4 Jul 2017 07:19:52 -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 1EE1C1320BA; Tue, 4 Jul 2017 07:19:52 -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:From:References:Cc: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=TPVs9vjnMBcYrCaf1qK5KoZln1oXkobeHrVo71YvOWo=; b=I+/GrmBMtAxIpKEFaBh3Jopsg W7k0qaEszZmFjL5Wh5MbvB3uxPVKG2EEIeeNaiFEjH+WeqrQZhS51oEfJcN7XXam3e0yZMoGBnb8W ifZtJA7kwVLtZTQw/+Ng6fKkp8fARJpZbMQogKhFX6FIasOuiWIVimRMr78QYsrvkQT63uefF2F+2 8C9B81nhfVkGC4zM9eGn+wAmYvCL4kAOG4APay/xMbRM0xPHJVsbB5Gg2BM97coP0O3jloIqGlN7S eEprDPyJXqBi0TigRMQxvU9IbkRuWUGmPjt1C6uHcNw2HN6wqWdmC8NnNhckApkGMGO2xU1bBlwf5 X238CytQw==; Received: from [31.185.128.124] (port=48288 helo=[192.168.0.13]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dSOgA-0002s3-5p; Tue, 04 Jul 2017 15:19:50 +0100 To: "Gorry (erg)" Cc: tsvwg-chairs , tcpm , tsvwg , tsv-ads , tcpm-chairs References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> <49200576-B166-4FE9-8B5D-36ECA5509364@erg.abdn.ac.uk> From: Bob Briscoe Message-ID: <99989ba2-4dae-eb6e-90fe-cb4b19f20594@bobbriscoe.net> Date: Tue, 4 Jul 2017 15:19:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <49200576-B166-4FE9-8B5D-36ECA5509364@erg.abdn.ac.uk> Content-Type: multipart/alternative; boundary="------------E355D3219074123B7F81735D" 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] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 14:19:56 -0000 This is a multi-part message in MIME format. --------------E355D3219074123B7F81735D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Gorry, A point I didn't make, but should have done: 2 of the experiments in ecn-experimentation depend on AccECN as a pre-requisite. So it's important not to risk delay to AccECN in an attempt not to delay ecn-experimentation. Can you give any clue as to which solutions you do or don't favour? Mirja asked me to post this to the lists. I think she was hoping this would reveal all the pros and cons, so a decision could then be made quickly between the chairs/ADs/shepherds/catherds. Bob On 03/07/17 22:06, Gorry (erg) wrote: > I think as document shepherd I have the input I need, but I need to > talk to my AD about how to handle the process - and liaise with the > TCPM co-chairs regarding the TCPM WG draft. This isn't the first time > we have had to look at the implications of making another RFC > historic, and I think we can do the correct thing. > > Gorry > > On 3 Jul 2017, at 20:17, C. M. Heard > wrote: > >> Bob, >> >> I think that your option (f) is better than option (e) (what I >> suggested). As an aside, either one patches up an apparent process >> violation committed by RFC 3540, an experimental RFC that assigned >> bit 7 in contradiction to the policy in RFC 2780. >> >> Mike Heard >> >> On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe > > wrote: >> >> Mike, >> >> Let's call this option: >> (e) ecn-experimentation alters the registry policy of bit 7 of >> the TCP header to "IETF Review". >> >> Having a different policy for certain bits within a registry >> might send IANA into a spin, but I am sure they could write >> suitable text into the registry policy if they had to. >> >> I quite like this one. Altho unorthodox, it's neat. >> >> >> Thank you. >> >> >> Bob >> >> PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as a >> 2-bit field during the 3-way hand-shake. While the ECN Nonce and >> AccECN use the three ECN flags (bits 7-9) as a 3-bit field during >> the 3WHS. AccECN uses the combinations that RFC3168 and the Nonce >> do not use. So to cover all bases: >> >> Option (f): ecn-experimentation alters the registry policy for >> bits 7-9 to "IETF Review". >> >> >> On 03/07/17 18:14, C. M. Heard wrote: >>> >>> Bob, >>> >>> Couldn't the text in the IANA considerations of >>> ecn-experimentation (which needs to be updated in any case) both >>> change the NS flag to Reserved for ECN Experimentation and >>> change the allocation policy for that flag from Standards Action >>> to IETF Review, thereby updating RFC 2780? That would avoid the >>> churn needed to add motivating text for a 4th experiment to >>> ecn-experimentation and would allow AccECN to assign the NS bit >>> itself without a process exception. >>> >>> Mike Heard >>> >>> On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote: >>> >>> Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, >>> tcpm list, tsvwg list, >>> >>> There has been some offlist discussion (among different >>> sub-groups) to narrow down the options here. It is time to >>> see opinions from the two affected WGs (tcpm and tsvwg) on >>> preferred process, esp. from the WG chairs and ADs. >>> >>> *==Background to the Process Problem==** >>> * >>> In tsvwg the process is in motion to make the ECN nonce [RFC >>> 3540] historic. So, in the most recent rev of >>> draft-ietf-tcpm-accurate-ecn-03 , we could finally include >>> IANA assignment of the NS flag >>> (see >>> https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6 >>> ) >>> >>> However, AccECN is EXPerimental, whereas the registry policy >>> for assigning TCP flags is "Standards Action" >>> https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml >>> >>> which means "Values are assigned only for Standards Track >>> RFCs approved by the IESG" [RFC2434]. >>> >>> References: >>> Process for designating RFCs as historic: >>> https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html >>> >>> Current draft text to make RFC 3540 historic: >>> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3 >>> >>> My initial draft for the AD's status change note: >>> https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt >>> >>> >>> ecn-experimentation has just completed WGLC. It still has to >>> go through IETF LC (after Prague). it is deliberately PS in >>> order to be able to relax pre-existing constraints on ECN >>> experiments in standards track RFCs. However, if poss, we >>> want to avoid adding motivating text for a 4th experiment, >>> which could require another cycle of WGLC and delay until Nov. >>> >>> RFC 3692 ("Assigning Experimental and Testing Numbers >>> Considered Useful") could also be relevant, although it >>> doesn't seem to help here, because it is primarily aimed at >>> larger codepoint spaces, not single bits. >>> >>> >>> *==Process Options==** >>> * >>> There need to be two parts to the process: 1) unassignment >>> and 2) reassignment. The first seems clear-cut. The second >>> is less obvious. >>> >>> 1) Unassigning the NS flag from RFC 3540 >>> a) add text to IANA considerations section of >>> ecn-experientation making the NS flag reserved >>> >>> 2) Assigning the NS flag to accurate-ecn (and renaming it >>> the AE flag). >>> Process options: >>> a) ecn-experimentation assigns flag to itself as reserved >>> for experiments and says initially the AccECN experiment >>> will use it exclusively >>> b) ecn-experimentation assigns NS flag exclusively to AccECN >>> c) AccECN assigns NS flag to itself, with a process >>> exception proposed to the IESG to allow an EXP doc to assign >>> to a Standards Action registry >>> d) the NS flag is reassigned by "AD review comment" or "IETF >>> Last Call comment" (quoted from David's suggestions) >>> e) other?... >>> >>> The difference between (a) and (b) is in the document that >>> ends up being referenced from the IANA registry: >>> a) ecn-experimentation >>> b) accurate-ecn >>> >>> *==My own preferences==** >>> * >>> During discussions, I didn't prefer (c) cos I thought the >>> IESG might question why they are being asked to make a >>> process exception for an ECN experiment at the same time as >>> a draft is going through that avoids raising process >>> exceptions for ECN experiments. >>> >>> Nonetheless, since then, Mirja has said... >>> >>> On 02/07/17 23:40, Mirja Kühlewind wrote: >>>> I actually prefer option (c). I don’t think a process exception is a bad thing. If it’s the right thing to do, then that the reason why we have such exceptions. Also I think it’d be the right thing to change the registry policy… but that probably a longer story. >>> I agree that it is outdated that the registry requires a >>> standards action, because it has become normal tcpm practice >>> for any change to TCP to have to start on the experimental >>> track. So this would justify a process exception. >>> >>> So, in summary, I don't mind (a), (b) or (c). I think (d) is >>> not sufficiently open and recorded for assignment of a flag >>> in the main TCP header. >>> >>> >>> Bob >>> >> >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ >> >> -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------E355D3219074123B7F81735D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Gorry,

A point I didn't make, but should have done: 2 of the experiments in ecn-experimentation depend on AccECN as a pre-requisite. So it's important not to risk delay to AccECN in an attempt not to delay ecn-experimentation.

Can you give any clue as to which solutions you do or don't favour? Mirja asked me to post this to the lists. I think she was hoping this would reveal all the pros and cons, so a decision could then be made quickly between the chairs/ADs/shepherds/catherds.


Bob

On 03/07/17 22:06, Gorry (erg) wrote:
I think as document shepherd I have the input I need, but I need to talk to my AD about how to handle the process  - and liaise with the TCPM co-chairs regarding the TCPM WG draft. This isn't the first time we have had to look at the implications of making another RFC historic, and I think we can do the correct thing.

Gorry

On 3 Jul 2017, at 20:17, C. M. Heard <heard@pobox.com> wrote:

Bob,

I think that your option (f) is better than option (e) (what I suggested). As an aside, either one patches up an apparent process violation committed by RFC 3540, an experimental RFC that assigned bit 7 in contradiction to the policy in RFC 2780.

Mike Heard

On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
Mike,

Let's call this option:
(e) ecn-experimentation alters the registry policy of bit 7 of the TCP header to "IETF Review".

Having a different policy for certain bits within a registry might send IANA into a spin, but I am sure they could write suitable text into the registry policy if they had to.

I quite like this one. Altho unorthodox, it's neat.


Thank you.


Bob

PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as a 2-bit field during the 3-way hand-shake. While the ECN Nonce and AccECN use the three ECN flags (bits 7-9) as a 3-bit field during the 3WHS. AccECN uses the combinations that RFC3168 and the Nonce do not use. So to cover all bases:

Option (f): ecn-experimentation alters the registry policy for bits 7-9 to "IETF Review".


On 03/07/17 18:14, C. M. Heard wrote:

Bob,

Couldn't the text in the IANA considerations of ecn-experimentation (which needs to be updated in any case) both change the NS flag to Reserved for ECN Experimentation and change the allocation policy for that flag from Standards Action to IETF Review, thereby updating RFC 2780? That would avoid the churn needed to add motivating text for a 4th experiment to ecn-experimentation and would allow AccECN to assign the NS bit itself without a process exception.

Mike Heard

On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote:

Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, tcpm list, tsvwg list,

There has been some offlist discussion (among different sub-groups) to narrow down the options here. It is time to see opinions from the two affected WGs (tcpm and tsvwg) on preferred process, esp. from the WG chairs and ADs.

==Background to the Process Problem==

In tsvwg the process is in motion to make the ECN nonce [RFC 3540] historic. So, in the most recent rev of draft-ietf-tcpm-accurate-ecn-03 , we could finally include IANA assignment of the NS flag
    (see https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6 )

However, AccECN is EXPerimental, whereas the registry policy for assigning TCP flags is "Standards Action"
    https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml
which means "Values are assigned only for Standards Track RFCs approved by the IESG" [RFC2434].

References:
    Process for designating RFCs as historic: 
        https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html
    Current draft text to make RFC 3540 historic: 
        https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3
    My initial draft for the AD's status change note: 
        https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt

ecn-experimentation has just completed WGLC. It still has to go through IETF LC (after Prague). it is deliberately PS in order to be able to relax pre-existing constraints on ECN experiments in standards track RFCs. However, if poss, we want to avoid adding motivating text for a 4th experiment, which could require another cycle of WGLC and delay until Nov. 

RFC 3692 ("Assigning Experimental and Testing Numbers Considered Useful") could also be relevant, although it doesn't seem to help here, because it is primarily aimed at larger codepoint spaces, not single bits.


==Process Options==

There need to be two parts to the process: 1) unassignment and 2) reassignment. The first seems clear-cut. The second is less obvious.

1) Unassigning the NS flag from RFC 3540
a) add text to IANA considerations section of ecn-experientation making the NS flag reserved

2) Assigning the NS flag to accurate-ecn (and renaming it the AE flag). 
Process options:
a) ecn-experimentation assigns flag to itself as reserved for experiments and says initially the AccECN experiment will use it exclusively 
b) ecn-experimentation assigns NS flag exclusively to AccECN 
c) AccECN assigns NS flag to itself, with a process exception proposed to the IESG to allow an EXP doc to assign to a Standards Action registry 
d) the NS flag is reassigned by "AD review comment" or "IETF Last Call comment" (quoted from David's suggestions)
e) other?...

The difference between (a) and (b) is in the document that ends up being referenced from the IANA registry: 
a)  ecn-experimentation 
b) accurate-ecn 

==My own preferences==

During discussions, I didn't prefer (c) cos I thought the IESG might question why they are being asked to make a process exception for an ECN experiment at the same time as a draft is going through that avoids raising process exceptions for ECN experiments. 

Nonetheless, since then, Mirja has said...

On 02/07/17 23:40, Mirja Kühlewind wrote:
I actually prefer option (c). I don’t think a process exception is a bad thing. If it’s the right thing to do, then that the reason why we have such exceptions. Also I think it’d be the right thing to change the registry policy… but that probably a longer story.
I agree that it is outdated that the registry requires a standards action, because it has become normal tcpm practice for any change to TCP to have to start on the experimental track. So this would justify a process exception.

So, in summary, I don't mind (a), (b) or (c). I think (d) is not sufficiently open and recorded for assignment of a flag in the main TCP header.


Bob


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------E355D3219074123B7F81735D-- From nobody Tue Jul 4 07:49:31 2017 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 18F5B13193A for ; Tue, 4 Jul 2017 07:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11IwBriJiYcr for ; Tue, 4 Jul 2017 07:49: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 E913513190D for ; Tue, 4 Jul 2017 07:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc: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=6vXgi81sdl2H47oVqcpeD8XpnNAH/MOJJE7RLuCLmgU=; b=ZDApxEYSr+OAdQiQSvCalIepor RG5YPJdbGtSuHpE+iSjRB13noAS5UhESd5+RvOkPIHHh41qYbaFW0yrqKplNIkIW1djcDXtwZFF3b xxQJCNIKPTXvqmw58i50ORLE+oAPNv9BkeLNXstEApoSZazQcsLKKcmRkJvz5LEnLxLGBGhw3M66X G2vzyacjZe3O4ZE/+3RHwDD6aCZvagXamFp8KzgX6VWBNh8ltNFvc0TJ9QEtbWmJSsElcxOO/wl4E Ie2UEBYP9PdY3ouW+fSRf95FoDcqZaALgA/P4+0RGrItsEFT3LRl56udWZ5bfhRs6tD8WHgmd2XOG fnEsFxPg==; Received: from [31.185.128.124] (port=48366 helo=[192.168.0.13]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dSP8o-0005S2-E3; Tue, 04 Jul 2017 15:49:26 +0100 To: "Black, David" , "tsvwg@ietf.org" References: <149805709598.15567.6760712935864557291@ietfa.amsl.com> From: Bob Briscoe Message-ID: <0418f45d-d112-5a43-9ea2-36c1236df3f9@bobbriscoe.net> Date: Tue, 4 Jul 2017 15:49:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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] I-D Action: draft-ietf-tsvwg-ecn-experimentation-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 14:49:30 -0000 David, Thanks for getting this draft though. One potential (minor) change that you might wish to note down for the next rev: We decided to give the name ECN++ to the scheme in draft-bagnulo-tcpm-generalized-ecn-04 We are no longer using the term Generalized ECN - it is just a file-name, not a name or title. (We thought the name ECN++ was appropriate, because ECT on SYN/ACKs [RFC5562] was called ECN+). Thanks again Bob On 21/06/17 16:12, Black, David wrote: > This-03 version addresses all the WGLC comments, with particular thanks to Ingemar Johansson for finding the "SHOULD" for DCCP sender use of ECT(0) that needed to be changed to a "MUST" in accordance with prior WG discussion of this topic (mea culpa - missed that one in earlier editing). > > There are two downrefs in this draft that is intended to become a proposed status RFC: > - This draft explains the end of the ECN Nonce experiment described in RFC 3540, and hence normatively references RFC 3540. > - DCCP sender ECN behavior needs to be updated in 3 RFCs, one of which is Experimental - RFC 5622. > > Thanks, --David > >> -----Original Message----- >> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Wednesday, June 21, 2017 10:58 AM >> To: i-d-announce@ietf.org >> Cc: tsvwg@ietf.org >> Subject: I-D Action: draft-ietf-tsvwg-ecn-experimentation-03.txt >> >> >> 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 of the IETF. >> >> Title : Explicit Congestion Notification (ECN) Experimentation >> Author : David Black >> Filename : draft-ietf-tsvwg-ecn-experimentation-03.txt >> Pages : 17 >> Date : 2017-06-21 >> >> Abstract: >> This memo updates RFC 3168, which specifies Explicit Congestion >> Notification (ECN) as a replacement for packet drops as indicators of >> network congestion. It relaxes restrictions in RFC 3168 that would >> otherwise hinder experimentation towards benefits beyond just removal >> of loss. This memo summarizes the anticipated areas of >> experimentation and updates RFC 3168 to enable experimentation in >> these areas. An Experimental RFC is required to take advantage of >> any of these enabling updates. In addition, this memo makes related >> updates to the ECN specifications for RTP in RFC 6679 and for DCCP in >> RFC 4341, RFC 4342 and RFC 5622. This memo also records the >> conclusion of the ECN Nonce experiment in RFC 3540, and provides the >> rationale for reclassification of RFC 3540 as Historic; this >> reclassification enables new experimental use of the ECT(1) >> codepoint. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03 >> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn- >> experimentation-03 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ecn-experimentation-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/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Tue Jul 4 10:07:50 2017 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 6757C12EC3B; Tue, 4 Jul 2017 10:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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 A3dMWJetMVly; Tue, 4 Jul 2017 10:07:38 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id EE631132411; Tue, 4 Jul 2017 10:07:37 -0700 (PDT) Received: from MacBook-2.local (unknown [77.88.71.157]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id DDA251B0E509; Tue, 4 Jul 2017 18:35:17 +0100 (BST) Message-ID: <595BB715.70700@erg.abdn.ac.uk> Date: Tue, 04 Jul 2017 17:41:09 +0200 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: Bob Briscoe CC: tsvwg-chairs , tcpm , tsvwg , tsv-ads , tcpm-chairs References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> <49200576-B166-4FE9-8B5D-36ECA5509364@erg.abdn.ac.uk> <99989ba2-4dae-eb6e-90fe-cb4b19f20594@bobbriscoe.net> In-Reply-To: <99989ba2-4dae-eb6e-90fe-cb4b19f20594@bobbriscoe.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tsvwg] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 17:07:42 -0000 On 04/07/2017, 16:19, Bob Briscoe wrote: > Gorry, > > A point I didn't make, but should have done: 2 of the experiments in > ecn-experimentation depend on AccECN as a pre-requisite. This I realised. > So it's important not to risk delay to AccECN in an attempt not to > delay ecn-experimentation. > OK - I will take it to the next Chair's meeting. > Can you give any clue as to which solutions you do or don't favour? > Mirja asked me to post this to the lists. I think she was hoping this > would reveal all the pros and cons, so a decision could then be made > quickly between the chairs/ADs/shepherds/catherds. > I will - but need to consult others first. > > Bob > Gorry > On 03/07/17 22:06, Gorry (erg) wrote: >> I think as document shepherd I have the input I need, but I need to >> talk to my AD about how to handle the process - and liaise with the >> TCPM co-chairs regarding the TCPM WG draft. This isn't the first time >> we have had to look at the implications of making another RFC >> historic, and I think we can do the correct thing. >> >> Gorry >> >> On 3 Jul 2017, at 20:17, C. M. Heard > > wrote: >> >>> Bob, >>> >>> I think that your option (f) is better than option (e) (what I >>> suggested). As an aside, either one patches up an apparent process >>> violation committed by RFC 3540, an experimental RFC that assigned >>> bit 7 in contradiction to the policy in RFC 2780. >>> >>> Mike Heard >>> >>> On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe >> > wrote: >>> >>> Mike, >>> >>> Let's call this option: >>> (e) ecn-experimentation alters the registry policy of bit 7 of >>> the TCP header to "IETF Review". >>> >>> Having a different policy for certain bits within a registry >>> might send IANA into a spin, but I am sure they could write >>> suitable text into the registry policy if they had to. >>> >>> I quite like this one. Altho unorthodox, it's neat. >>> >>> >>> Thank you. >>> >>> >>> Bob >>> >>> PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as >>> a 2-bit field during the 3-way hand-shake. While the ECN Nonce >>> and AccECN use the three ECN flags (bits 7-9) as a 3-bit field >>> during the 3WHS. AccECN uses the combinations that RFC3168 and >>> the Nonce do not use. So to cover all bases: >>> >>> Option (f): ecn-experimentation alters the registry policy for >>> bits 7-9 to "IETF Review". >>> >>> >>> On 03/07/17 18:14, C. M. Heard wrote: >>>> >>>> Bob, >>>> >>>> Couldn't the text in the IANA considerations of >>>> ecn-experimentation (which needs to be updated in any case) >>>> both change the NS flag to Reserved for ECN Experimentation and >>>> change the allocation policy for that flag from Standards >>>> Action to IETF Review, thereby updating RFC 2780? That would >>>> avoid the churn needed to add motivating text for a 4th >>>> experiment to ecn-experimentation and would allow AccECN to >>>> assign the NS bit itself without a process exception. >>>> >>>> Mike Heard >>>> >>>> On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote: >>>> >>>> Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, >>>> tcpm list, tsvwg list, >>>> >>>> There has been some offlist discussion (among different >>>> sub-groups) to narrow down the options here. It is time to >>>> see opinions from the two affected WGs (tcpm and tsvwg) on >>>> preferred process, esp. from the WG chairs and ADs. >>>> >>>> *==Background to the Process Problem==** >>>> * >>>> In tsvwg the process is in motion to make the ECN nonce >>>> [RFC 3540] historic. So, in the most recent rev of >>>> draft-ietf-tcpm-accurate-ecn-03 , we could finally include >>>> IANA assignment of the NS flag >>>> (see >>>> https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6 >>>> ) >>>> >>>> However, AccECN is EXPerimental, whereas the registry >>>> policy for assigning TCP flags is "Standards Action" >>>> https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml >>>> >>>> which means "Values are assigned only for Standards Track >>>> RFCs approved by the IESG" [RFC2434]. >>>> >>>> References: >>>> Process for designating RFCs as historic: >>>> https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html >>>> >>>> Current draft text to make RFC 3540 historic: >>>> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3 >>>> >>>> My initial draft for the AD's status change note: >>>> https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt >>>> >>>> >>>> ecn-experimentation has just completed WGLC. It still has >>>> to go through IETF LC (after Prague). it is deliberately PS >>>> in order to be able to relax pre-existing constraints on >>>> ECN experiments in standards track RFCs. However, if poss, >>>> we want to avoid adding motivating text for a 4th >>>> experiment, which could require another cycle of WGLC and >>>> delay until Nov. >>>> >>>> RFC 3692 ("Assigning Experimental and Testing Numbers >>>> Considered Useful") could also be relevant, although it >>>> doesn't seem to help here, because it is primarily aimed at >>>> larger codepoint spaces, not single bits. >>>> >>>> >>>> *==Process Options==** >>>> * >>>> There need to be two parts to the process: 1) unassignment >>>> and 2) reassignment. The first seems clear-cut. The second >>>> is less obvious. >>>> >>>> 1) Unassigning the NS flag from RFC 3540 >>>> a) add text to IANA considerations section of >>>> ecn-experientation making the NS flag reserved >>>> >>>> 2) Assigning the NS flag to accurate-ecn (and renaming it >>>> the AE flag). >>>> Process options: >>>> a) ecn-experimentation assigns flag to itself as reserved >>>> for experiments and says initially the AccECN experiment >>>> will use it exclusively >>>> b) ecn-experimentation assigns NS flag exclusively to AccECN >>>> c) AccECN assigns NS flag to itself, with a process >>>> exception proposed to the IESG to allow an EXP doc to >>>> assign to a Standards Action registry >>>> d) the NS flag is reassigned by "AD review comment" or >>>> "IETF Last Call comment" (quoted from David's suggestions) >>>> e) other?... >>>> >>>> The difference between (a) and (b) is in the document that >>>> ends up being referenced from the IANA registry: >>>> a) ecn-experimentation >>>> b) accurate-ecn >>>> >>>> *==My own preferences==** >>>> * >>>> During discussions, I didn't prefer (c) cos I thought the >>>> IESG might question why they are being asked to make a >>>> process exception for an ECN experiment at the same time as >>>> a draft is going through that avoids raising process >>>> exceptions for ECN experiments. >>>> >>>> Nonetheless, since then, Mirja has said... >>>> >>>> On 02/07/17 23:40, Mirja Kühlewind wrote: >>>>> I actually prefer option (c). I don’t think a process exception is a bad thing. If it’s the right thing to do, then that the reason why we have such exceptions. Also I think it’d be the right thing to change the registry policy… but that probably a longer story. >>>> I agree that it is outdated that the registry requires a >>>> standards action, because it has become normal tcpm >>>> practice for any change to TCP to have to start on the >>>> experimental track. So this would justify a process exception. >>>> >>>> So, in summary, I don't mind (a), (b) or (c). I think (d) >>>> is not sufficiently open and recorded for assignment of a >>>> flag in the main TCP header. >>>> >>>> >>>> Bob >>>> >>> >>> -- >>> ________________________________________________________________ >>> Bob Briscoehttp://bobbriscoe.net/ >>> >>> > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ From nobody Thu Jul 6 01:28:56 2017 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 6FF80126DD9 for ; Thu, 6 Jul 2017 01:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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 i0CLUVEXaTxj for ; Thu, 6 Jul 2017 01:28:53 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id EF1C7126CC4 for ; Thu, 6 Jul 2017 01:28:52 -0700 (PDT) Received: from MacBook-2.local (at-zeroshell-1.erg.abdn.ac.uk [139.133.217.68]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 2BDAF1B106BB for ; Thu, 6 Jul 2017 10:04:58 +0100 (BST) Message-ID: <595DE27F.3030302@erg.abdn.ac.uk> Date: Thu, 06 Jul 2017 08:10:55 +0100 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: tsvwg WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tsvwg] TSVWG Working Group Last Call (WGLC) on draft-ietf-tsvwg-ieee-802-11-01 to conclude 10th Jul 2017 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 08:28:55 -0000 This email announces a second TSVWG Working Group Last Call (WGLC) on: DiffServ to IEEE 802.11 Mapping draft-ietf-tsvwg-ieee-802-11-01 https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11-01 This WGLC will last for about 2 weeks weeks. The purpose of this call is to provide further feedback (if required) on changes made since the first WGLC concluded. Comments should be sent to thetsvwg@ietf.org list, although purely editorial comments may be sent directly to the authors. Please cc: the WG chairs attsvwg-chairs@ietf.org if you would like the chairs to track such editorial comments as part of the WGLC process. No IPR disclosures have been submitted directly on draft-ietf-tsvwg-ieee-802-11-01 Thanks, Gorry (TSVWG Co-Chair) From nobody Fri Jul 7 03:41:48 2017 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 6E61212ECEF for ; Fri, 7 Jul 2017 03:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 ciyu9TA8KOiS for ; Fri, 7 Jul 2017 03:41:45 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 09B90131699 for ; Fri, 7 Jul 2017 03:41:44 -0700 (PDT) Received: from Gs-MacBook-Pro.local (at-zeroshell-1.erg.abdn.ac.uk [139.133.217.68]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 8CE4A1B160C4 for ; Fri, 7 Jul 2017 11:52:00 +0100 (BST) Message-ID: <595F4D19.9030502@erg.abdn.ac.uk> Date: Fri, 07 Jul 2017 09:58:01 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 10:41:47 -0000 This email is intended to start a discussion about the most appropriate DiffServ codepoint to assign to the LE PHB specified in: https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-02 The current list of available codepoints is listed by IANA here: https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml The draft currently suggests using the DSCP value 3, '000010'. Question 1: Is this codepoint a good choice for the TSVWG group to assign for the LE PHB? Things to consider: - Is the codepoint currently being used for other (non-standard applications) that may get in the way of the deployment of the LE PHB? - Is there ant evidence that this DSCP value is less likely to be forwarded than other unused codepoints? - Is this codepoint observed in the wild due to common DSCP-mangling pathologies (such as ToS-byte bleaching)? Question 2: Is there an alternate unassigned codepint that could be chosen that would give better opprotunities for deployment? Things to consider: - A codepoint less than 7 appears to have less chance of DSCP-mangling pathologies (such as ToS-byte bleaching) - IANA currently allocates from pool 1 (xxxxx0), but we could consider asking to use pool 3 ('xxxx01'), e.g., '000001'or '000101'. Measurement experience and thoughts on this topic are welcome on the mailing list ahead of the TSVWG meeting. At this meeting, I would like to see some discussion confirming the choice of DSCP codepoint or suggesting a more appropriate codepoint for the working group to request. Gorry Fairhurst (TSVWG Co-Chair) From nobody Fri Jul 7 03:59:40 2017 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 C662F126C22 for ; Fri, 7 Jul 2017 03:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 3Jc8k9At70Vg for ; Fri, 7 Jul 2017 03:59:37 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 50B6A126BF6 for ; Fri, 7 Jul 2017 03:59:34 -0700 (PDT) Received: from Gs-MacBook-Pro.local (at-zeroshell-1.erg.abdn.ac.uk [139.133.217.68]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 367701B0C5F0; Fri, 7 Jul 2017 12:30:30 +0100 (BST) Message-ID: <595F561F.4050007@erg.abdn.ac.uk> Date: Fri, 07 Jul 2017 10:36:31 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: TSVWG@IETF.ORG References: <595F4D19.9030502@erg.abdn.ac.uk> In-Reply-To: <595F4D19.9030502@erg.abdn.ac.uk> X-Forwarded-Message-Id: <595F4D19.9030502@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 10:59:39 -0000 This email is intended to start a discussion about the most appropriate DiffServ codepoint to assign to the LE PHB specified in: https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-02 The current list of available codepoints is listed by IANA here: https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml The draft currently suggests using the DSCP value 3, '000010'. Question 1: Is this codepoint a good choice for the TSVWG group to assign for the LE PHB? Things to consider: - Is the codepoint currently being used for other (non-standard applications) that may get in the way of the deployment of the LE PHB? - Is there ant evidence that this DSCP value is less likely to be forwarded than other unused codepoints? - Is this codepoint observed in the wild due to common DSCP-mangling pathologies (such as ToS-byte bleaching)? Question 2: Is there an alternate unassigned codepint that could be chosen that would give better opprotunities for deployment? Things to consider: - A codepoint less than 7 appears to have less chance of DSCP-mangling pathologies (such as ToS-byte bleaching) - IANA currently allocates from pool 1 (xxxxx0), but we could consider asking to use pool 3 ('xxxx01'), e.g., '000001'or '000101'. Measurement experience and thoughts on this topic are welcome on the mailing list ahead of the TSVWG meeting. At this meeting, I would like to see some discussion confirming the choice of DSCP codepoint or suggesting a more appropriate codepoint for the working group to request. Gorry Fairhurst (TSVWG Co-Chair) From nobody Fri Jul 7 04:03:46 2017 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 0452D1294A2 for ; Fri, 7 Jul 2017 04:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XeVLW_uj063G for ; Fri, 7 Jul 2017 04:03:42 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 9D769126BF6 for ; Fri, 7 Jul 2017 04:03:42 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1dTR2y-0002XE-U7; Fri, 07 Jul 2017 13:03:40 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id C2156B001D5; Fri, 7 Jul 2017 13:03:40 +0200 (CEST) To: gorry@erg.abdn.ac.uk, tsvwg@ietf.org References: <595F4D19.9030502@erg.abdn.ac.uk> From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: <011e5fb5-6c83-bb38-e2cb-7fced2cb774a@kit.edu> Date: Fri, 7 Jul 2017 13:03:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <595F4D19.9030502@erg.abdn.ac.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1499425420.989210247 Archived-At: Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 11:03:45 -0000 Hi Gorry, Am 07.07.2017 um 10:58 schrieb Gorry Fairhurst: > This email is intended to start a discussion about the most appropriate > DiffServ codepoint to assign to the LE PHB specified in: > https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-02 > > The current list of available codepoints is listed by IANA here: > https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml > > The draft currently suggests using the DSCP value 3, '000010'. I think it is DSCP value 2. > Question 1: Is this codepoint a good choice for the TSVWG group to > assign for the LE PHB? > > Things to consider: > - Is the codepoint currently being used for other (non-standard > applications) that may get in the way of the deployment of the LE PHB? Currently, nothing should be using a non-assigned Standard DSCP. I really don't like these discussion along the lines of: oh, probably there are some standard-ignoring boxes/apps out there, so lets try to work around their broken design. So, yes, it's probably good to know, but IMHO it's better to get this other stuff fixed rather than to always create workaround. > - Is there ant evidence that this DSCP value is less likely to be > forwarded than other unused codepoints? > - Is this codepoint observed in the wild due to common DSCP-mangling > pathologies (such as ToS-byte bleaching)? > > Question 2: Is there an alternate unassigned codepint that could be > chosen that would give better opprotunities for deployment? > Things to consider: > - A codepoint less than 7 appears to have less chance of > DSCP-mangling pathologies (such as ToS-byte bleaching) > - IANA currently allocates from pool 1 (xxxxx0), but we could > consider asking to use pool 3 ('xxxx01'), e.g., '000001'or '000101'. I don't see any compelling reason to start using another pool right now. > Measurement experience and thoughts on this topic are welcome on the > mailing list ahead of the TSVWG meeting. At this meeting, I would like > to see some discussion confirming the choice of DSCP codepoint or > suggesting a more appropriate codepoint for the working group to request. Thanks for triggering the discussion. Regards, Roland From nobody Fri Jul 7 06:07:04 2017 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 F21B21201F2 for ; Fri, 7 Jul 2017 06:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 TXHxqi3HukDY for ; Fri, 7 Jul 2017 06:07:00 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 482381287A7 for ; Fri, 7 Jul 2017 06:07:00 -0700 (PDT) Received: from Gs-MacBook-Pro.local (at-zeroshell-1.erg.abdn.ac.uk [139.133.217.68]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 7DB1E1B0A1DB; Fri, 7 Jul 2017 14:18:04 +0100 (BST) Message-ID: <595F6F4F.20005@erg.abdn.ac.uk> Date: Fri, 07 Jul 2017 12:23:59 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Bless, Roland (TM)" CC: tsvwg@ietf.org References: <595F4D19.9030502@erg.abdn.ac.uk> <011e5fb5-6c83-bb38-e2cb-7fced2cb774a@kit.edu> In-Reply-To: <011e5fb5-6c83-bb38-e2cb-7fced2cb774a@kit.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 13:07:03 -0000 On 07/07/2017, 12:03, Bless, Roland (TM) wrote: > Hi Gorry, > > Am 07.07.2017 um 10:58 schrieb Gorry Fairhurst: >> This email is intended to start a discussion about the most appropriate >> DiffServ codepoint to assign to the LE PHB specified in: >> https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-02 >> >> The current list of available codepoints is listed by IANA here: >> https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml >> >> The draft currently suggests using the DSCP value, '000010'. > I think it is DSCP value 2. That's two indeed:-). >> Question 1: Is this codepoint a good choice for the TSVWG group to >> assign for the LE PHB? >> >> Things to consider: >> - Is the codepoint currently being used for other (non-standard >> applications) that may get in the way of the deployment of the LE PHB? > Currently, nothing should be using a non-assigned Standard DSCP. > I really don't like these discussion along the lines of: oh, probably > there are some standard-ignoring boxes/apps out there, so lets try to > work around their broken design. So, yes, it's probably good to know, > but IMHO it's better to get this other stuff fixed rather than to always > create workaround. And, I think a more usedful disucssion here is around - "what happens when you use existing codepoints that are IETF-approved, and they pass through the current Internet" - do they emerge as the codepoint you propose? >> - Is there ant evidence that this DSCP value is less likely to be >> forwarded than other unused codepoints? >> - Is this codepoint observed in the wild due to common DSCP-mangling >> pathologies (such as ToS-byte bleaching)? >> >> Question 2: Is there an alternate unassigned codepint that could be >> chosen that would give better opprotunities for deployment? >> Things to consider: >> - A codepoint less than 7 appears to have less chance of >> DSCP-mangling pathologies (such as ToS-byte bleaching) >> - IANA currently allocates from pool 1 (xxxxx0), but we could >> consider asking to use pool 3 ('xxxx01'), e.g., '000001'or '000101'. > I don't see any compelling reason to start using another pool right now. Don't you? I think this depends on the outcome. >> Measurement experience and thoughts on this topic are welcome on the >> mailing list ahead of the TSVWG meeting. At this meeting, I would like >> to see some discussion confirming the choice of DSCP codepoint or >> suggesting a more appropriate codepoint for the working group to request. > Thanks for triggering the discussion. > > Regards, > Roland Roland, do you have any measurement data? Gorry From nobody Fri Jul 7 07:25:59 2017 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 B5CB61315EE for ; Fri, 7 Jul 2017 07:25:57 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 7Kx8Jkubs9zF for ; Fri, 7 Jul 2017 07:25:54 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 92C4212EC23 for ; Fri, 7 Jul 2017 07:25:54 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id m84so37441997ita.0 for ; Fri, 07 Jul 2017 07:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=xrqg7cd0KVIMe8Baw/G2xbI2fp2zWZwauY8aOgSjnFI=; b=xy6elteXv0JCkbrOk7ASQiKLOLcVdQ2TTZIW/B6LD6hNIdWG4FM2x0F8m8vJ6Y04iR T96J2RcnaEgLsWJQVrq38/rNNGZS1GYc2+ALJ95y/7Yqo982hO7GvJ9aZ/fuBuHglANz oGm7CWbwZY3Mwob3/rJcd3n5pxcalHY/QJEtJ4LFEacwyvgDp7V1gRWB/977UzNEhRoJ IeD+nKXzsug8ISXpw6SP9lOJIggvJ9naNFRxWQzYJlqj/qvDq8itTI1FzwyfFxmJ8VOG W2ZXSKDHdavGziJa1iN3LIXGmpu/9GP6k9/B1L8QuFMWwgYl09po4pS0zY9LolNTY2Yj HXpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=xrqg7cd0KVIMe8Baw/G2xbI2fp2zWZwauY8aOgSjnFI=; b=TQ9MHSl6FBLoGR3RfswmY1UIAPAbZO8YnPEgR9FvXY0tZLkCm31dDenrmFMvP7JqRj Z+K0YebNiGK2V199Sge9DyHuRjZC9SJeyObbAhpYFd+WYHFGmYCh6dakUJVsQn4V5Hau ioCpYyvbgHVLkw05JLmfMThqAiFNIyNVvKtaSqY14e4rJ/O8Nm6Mc+Hr93h6mUDWj21w Mzr65+gEkhwZbAL6Oe30z8LGD8H31Sev/vRiBrAqIWH3YOvAY8na+mZ3wzd5U+zZ4Qts ZgRES/I/FpkzOCgcBKmRW3OwWdE51m3OuSNV1jbhEioLLa9wLbTKqegh/Z+leeYyGA5X 2ZOA== X-Gm-Message-State: AIVw113QYPcPnUgw1WcA6ApFlRAm3gP/CvFzeps+95PR/1R5iNO7FwPc t7GGcsVRWwZunu5cZQl5xQ== X-Received: by 10.36.103.69 with SMTP id u66mr3233255itc.46.1499437553734; Fri, 07 Jul 2017 07:25:53 -0700 (PDT) Received: from [192.168.1.104] (cpe-76-188-215-129.neo.res.rr.com. [76.188.215.129]) by smtp.gmail.com with ESMTPSA id z62sm1783277ioz.37.2017.07.07.07.25.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jul 2017 07:25:53 -0700 (PDT) To: "tsvwg@ietf.org" From: Wesley Eddy Message-ID: Date: Fri, 7 Jul 2017 10:25:51 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tsvwg] adoption of FECFRAME drafts X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 14:25:58 -0000 As discussed in Chicago, we think there is interest and support in TSVWG to adopt the drafts that Vincent presented on extending FECFRAME: https://datatracker.ietf.org/doc/draft-roca-tsvwg-fecframev2/ https://datatracker.ietf.org/doc/draft-roca-tsvwg-rlc-fec-scheme/ We confirmed AD support for bringing this work into TSVWG, and this email is just to notify the list that these are becoming working group items. From nobody Fri Jul 7 07:39:09 2017 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 784131315E5; Fri, 7 Jul 2017 07:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3qeKb-Lj3M8; Fri, 7 Jul 2017 07:38:57 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5653213156E; Fri, 7 Jul 2017 07:38:57 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id v193so14026775ywg.2; Fri, 07 Jul 2017 07:38:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i5P5NbT7eW8ex9ptbp7p52pkyQVgwOz+2W1VpypcXmE=; b=pv1GTDEGDAFGk2B2kz92lUWy+NTLSp3hXVHj0YVa5NNb25JvEW1WiaRoxDbfg09xXk vo/HIU3wEtYOaYSfUWPQVbM0ZzundGDiFU+WigyWm61r4+Sl+UBtXSx+k+TJSlkq5r3V tO56FfttgSY7kFaMJsOKPYDF0EK02C3UxWXxF8cFYe/wVuiF82OrLrbhlcE1K/+kbE0E IC9hoQZGAc/iIs95hYP8kqmF+vMCIn3oL/9LwYzIUMz/H0jzfbs5itmDJqgoxhDiXYFx 3tYT3uUscHc7XVuf7yuVe9cDyf1sq73m5HnpzC1B20cQfEhDfcQ61EU7Fy95+vLeMH8r kc3w== 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=i5P5NbT7eW8ex9ptbp7p52pkyQVgwOz+2W1VpypcXmE=; b=LIL3Ak5W5pDdtNninI4EYJoNpJq6p2xqZBw997Uylq3IOugb8OhwCAcKlDnNprjInZ QH6PYDTb3qLy7wnggcPiz9qJ8I1P9nZ4rmK1SFBy+f2z34aVgZSirWpk/1f+H1q4H5lB OZ4q7U3ZHDNXwArNVjkQG6381MkctZl6hEo2UVpjJVsj7ND2bZjW7bw7kYz1lAu9KPqG nrUNOBha95lbSvHtWQrYAR24diIBVtR/cFyd0CVaZzUVmokOuoAHNOv0MxV+zTpmSljq xmNGP3N3OgwQzZLxBs6YEU/bZ5Mlv5IB3fvBmgVR0JgKo8/W28cS5EUk5AglicFhIKop 7TJA== X-Gm-Message-State: AIVw112VhS9f6NuA0B0y+oNVFxEzGf2fCQL70Uf8a6dNdnh4KNqrLpwc gnRfYm6XeWuQ7dJiVh+P1NWkVhsd1Q== X-Received: by 10.129.178.129 with SMTP id q123mr2226735ywh.212.1499438336441; Fri, 07 Jul 2017 07:38:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.91.137 with HTTP; Fri, 7 Jul 2017 07:38:55 -0700 (PDT) In-Reply-To: <595BB715.70700@erg.abdn.ac.uk> References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> <49200576-B166-4FE9-8B5D-36ECA5509364@erg.abdn.ac.uk> <99989ba2-4dae-eb6e-90fe-cb4b19f20594@bobbriscoe.net> <595BB715.70700@erg.abdn.ac.uk> From: Spencer Dawkins at IETF Date: Fri, 7 Jul 2017 09:38:55 -0500 Message-ID: To: G Fairhurst Cc: Bob Briscoe , tsvwg-chairs , tcpm , tsvwg , tsv-ads , tcpm-chairs Content-Type: multipart/alternative; boundary="94eb2c13d7126804310553bb312c" Archived-At: Subject: Re: [tsvwg] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 14:39:02 -0000 --94eb2c13d7126804310553bb312c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Gorry, since you asked - I don't have an objection to most of the alternatives presented in this thread. Since we're most/all in Prague Real Soon Now, I suggest that we have a whiteboard session at an appropriate break in the action, and make sure we are all on the same page, because there are several interconnected parts of the discussion. Thanks, Spencer On Tue, Jul 4, 2017 at 10:41 AM, G Fairhurst wrote: > On 04/07/2017, 16:19, Bob Briscoe wrote: > >> Gorry, >> >> A point I didn't make, but should have done: 2 of the experiments in >> ecn-experimentation depend on AccECN as a pre-requisite. >> > This I realised. > >> So it's important not to risk delay to AccECN in an attempt not to delay >> ecn-experimentation. >> >> OK - I will take it to the next Chair's meeting. > >> Can you give any clue as to which solutions you do or don't favour? Mirj= a >> asked me to post this to the lists. I think she was hoping this would >> reveal all the pros and cons, so a decision could then be made quickly >> between the chairs/ADs/shepherds/catherds. >> >> I will - but need to consult others first. > >> >> Bob >> >> Gorry > >> On 03/07/17 22:06, Gorry (erg) wrote: >> >>> I think as document shepherd I have the input I need, but I need to tal= k >>> to my AD about how to handle the process - and liaise with the TCPM >>> co-chairs regarding the TCPM WG draft. This isn't the first time we hav= e >>> had to look at the implications of making another RFC historic, and I t= hink >>> we can do the correct thing. >>> >>> Gorry >>> >>> On 3 Jul 2017, at 20:17, C. M. Heard >> heard@pobox.com>> wrote: >>> >>> Bob, >>>> >>>> I think that your option (f) is better than option (e) (what I >>>> suggested). As an aside, either one patches up an apparent process >>>> violation committed by RFC 3540, an experimental RFC that assigned bit= 7 in >>>> contradiction to the policy in RFC 2780. >>>> >>>> Mike Heard >>>> >>>> On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe >>> > wrote: >>>> >>>> Mike, >>>> >>>> Let's call this option: >>>> (e) ecn-experimentation alters the registry policy of bit 7 of >>>> the TCP header to "IETF Review". >>>> >>>> Having a different policy for certain bits within a registry >>>> might send IANA into a spin, but I am sure they could write >>>> suitable text into the registry policy if they had to. >>>> >>>> I quite like this one. Altho unorthodox, it's neat. >>>> >>>> >>>> Thank you. >>>> >>>> >>>> Bob >>>> >>>> PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as >>>> a 2-bit field during the 3-way hand-shake. While the ECN Nonce >>>> and AccECN use the three ECN flags (bits 7-9) as a 3-bit field >>>> during the 3WHS. AccECN uses the combinations that RFC3168 and >>>> the Nonce do not use. So to cover all bases: >>>> >>>> Option (f): ecn-experimentation alters the registry policy for >>>> bits 7-9 to "IETF Review". >>>> >>>> >>>> On 03/07/17 18:14, C. M. Heard wrote: >>>> >>>>> >>>>> Bob, >>>>> >>>>> Couldn't the text in the IANA considerations of >>>>> ecn-experimentation (which needs to be updated in any case) >>>>> both change the NS flag to Reserved for ECN Experimentation and >>>>> change the allocation policy for that flag from Standards >>>>> Action to IETF Review, thereby updating RFC 2780? That would >>>>> avoid the churn needed to add motivating text for a 4th >>>>> experiment to ecn-experimentation and would allow AccECN to >>>>> assign the NS bit itself without a process exception. >>>>> >>>>> Mike Heard >>>>> >>>>> On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote: >>>>> >>>>> Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, >>>>> tcpm list, tsvwg list, >>>>> >>>>> There has been some offlist discussion (among different >>>>> sub-groups) to narrow down the options here. It is time to >>>>> see opinions from the two affected WGs (tcpm and tsvwg) on >>>>> preferred process, esp. from the WG chairs and ADs. >>>>> >>>>> *=3D=3DBackground to the Process Problem=3D=3D** >>>>> * >>>>> >>>>> In tsvwg the process is in motion to make the ECN nonce >>>>> [RFC 3540] historic. So, in the most recent rev of >>>>> draft-ietf-tcpm-accurate-ecn-03 , we could finally include >>>>> IANA assignment of the NS flag >>>>> (see >>>>> https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03# >>>>> section-6 >>>>> >>>> #section-6> ) >>>>> >>>>> However, AccECN is EXPerimental, whereas the registry >>>>> policy for assigning TCP flags is "Standards Action" >>>>> https://www.iana.org/assignments/tcp-header-flags/tcp- >>>>> header-flags.xhtml >>>>> >>>> header-flags.xhtml> >>>>> which means "Values are assigned only for Standards Track >>>>> RFCs approved by the IESG" [RFC2434]. >>>>> >>>>> References: >>>>> Process for designating RFCs as historic: >>>>> https://www.ietf.org/iesg/statement/designating-rfcs-as-hist >>>>> oric.html >>>>> >>>> toric.html> >>>>> Current draft text to make RFC 3540 historic: >>>>> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimenta >>>>> tion-03#section-3 >>>>> >>>> ation-03#section-3> >>>>> My initial draft for the AD's status change note: >>>>> https://github.com/bbriscoe/ecn-experimentation/blob/master/ >>>>> status-change-ecn-nonce-rfc3540-to-historic-00.txt >>>>> >>>> /status-change-ecn-nonce-rfc3540-to-historic-00.txt> >>>>> >>>>> ecn-experimentation has just completed WGLC. It still has >>>>> to go through IETF LC (after Prague). it is deliberately PS >>>>> in order to be able to relax pre-existing constraints on >>>>> ECN experiments in standards track RFCs. However, if poss, >>>>> we want to avoid adding motivating text for a 4th >>>>> experiment, which could require another cycle of WGLC and >>>>> delay until Nov. >>>>> >>>>> RFC 3692 ("Assigning Experimental and Testing Numbers >>>>> Considered Useful") could also be relevant, although it >>>>> doesn't seem to help here, because it is primarily aimed at >>>>> larger codepoint spaces, not single bits. >>>>> >>>>> >>>>> *=3D=3DProcess Options=3D=3D** >>>>> * >>>>> There need to be two parts to the process: 1) unassignment >>>>> and 2) reassignment. The first seems clear-cut. The second >>>>> is less obvious. >>>>> >>>>> 1) Unassigning the NS flag from RFC 3540 >>>>> a) add text to IANA considerations section of >>>>> ecn-experientation making the NS flag reserved >>>>> >>>>> 2) Assigning the NS flag to accurate-ecn (and renaming it >>>>> the AE flag). >>>>> Process options: >>>>> a) ecn-experimentation assigns flag to itself as reserved >>>>> for experiments and says initially the AccECN experiment >>>>> will use it exclusively >>>>> b) ecn-experimentation assigns NS flag exclusively to AccECN >>>>> c) AccECN assigns NS flag to itself, with a process >>>>> exception proposed to the IESG to allow an EXP doc to >>>>> assign to a Standards Action registry >>>>> d) the NS flag is reassigned by "AD review comment" or >>>>> "IETF Last Call comment" (quoted from David's suggestions) >>>>> e) other?... >>>>> >>>>> The difference between (a) and (b) is in the document that >>>>> ends up being referenced from the IANA registry: >>>>> a) ecn-experimentation >>>>> b) accurate-ecn >>>>> >>>>> *=3D=3DMy own preferences=3D=3D** >>>>> * >>>>> During discussions, I didn't prefer (c) cos I thought the >>>>> IESG might question why they are being asked to make a >>>>> process exception for an ECN experiment at the same time as >>>>> a draft is going through that avoids raising process >>>>> exceptions for ECN experiments. >>>>> >>>>> Nonetheless, since then, Mirja has said... >>>>> >>>>> On 02/07/17 23:40, Mirja K=C3=BChlewind wrote: >>>>> >>>>>> I actually prefer option (c). I don=E2=80=99t think a proces= s >>>>>> exception is a bad thing. If it=E2=80=99s the right thing to do, the= n that the >>>>>> reason why we have such exceptions. Also I think it=E2=80=99d be the= right thing to >>>>>> change the registry policy=E2=80=A6 but that probably a longer story= . >>>>>> >>>>> I agree that it is outdated that the registry requires a >>>>> standards action, because it has become normal tcpm >>>>> practice for any change to TCP to have to start on the >>>>> experimental track. So this would justify a process exception= . >>>>> >>>>> So, in summary, I don't mind (a), (b) or (c). I think (d) >>>>> is not sufficiently open and recorded for assignment of a >>>>> flag in the main TCP header. >>>>> >>>>> >>>>> Bob >>>>> >>>>> >>>> -- ___________________________________________________________ >>>> _____ >>>> Bob Briscoehttp://bobbriscoe.net/ >>>> >>>> >>>> >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ >> > > --94eb2c13d7126804310553bb312c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Gorry, since you asked - I don't have an objection to = most of the alternatives presented in this thread. Since we're most/all= in Prague Real Soon Now, I suggest that we have a whiteboard session at an= appropriate break in the action, and make sure we are all on the same page= , because there are several interconnected parts of the discussion.
Thanks,

Spencer

On Tue, Jul 4, 2017 at 10:41 AM, G= Fairhurst <gorry@erg.abdn.ac.uk> wrote:
On 04/07/2017, 16:19, Bob Briscoe wrote:=
Gorry,

A point I didn't make, but should have done: 2 of the experiments in ec= n-experimentation depend on AccECN as a pre-requisite.
This I realised.
So it's important not to risk delay to AccECN in an attempt not to dela= y ecn-experimentation.

 OK - I will take it to the next Chair's meeting.
Can you give any clue as to which solutions you do or don't favour? Mir= ja asked me to post this to the lists. I think she was hoping this would re= veal all the pros and cons, so a decision could then be made quickly betwee= n the chairs/ADs/shepherds/catherds.

 I will - but need to consult others first.

Bob

Gorry
On 03/07/17 22:06, Gorry (erg) wrote:
I think as document shepherd I have the input I need, but I need to talk to= my AD about how to handle the process=C2=A0 - and liaise with the TCPM co-= chairs regarding the TCPM WG draft. This isn't the first time we have h= ad to look at the implications of making another RFC historic, and I think = we can do the correct thing.

Gorry

 On 3 Jul 2017, at 20:17, C. M. Heard <heard@pobox.com <mailto:heard@pobox.com>> wrote:

Bob,

I think that your option (f) is better than option (e) (what I suggested). = As an aside, either one patches up an apparent process violation committed = by RFC 3540, an experimental RFC that assigned bit 7 in contradiction to th= e policy in RFC 2780.

Mike Heard

On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe <ietf@bobbriscoe.net <mailto:ietf@bobbriscoe.net&g= t;> wrote:

=C2=A0 =C2=A0 Mike,

=C2=A0 =C2=A0 Let's call this option:
=C2=A0 =C2=A0 (e) ecn-experimentation alters the registry policy of bit 7 o= f
=C2=A0 =C2=A0 the TCP header to "IETF Review".

=C2=A0 =C2=A0 Having a different policy for certain bits within a registry<= br> =C2=A0 =C2=A0 might send IANA into a spin, but I am sure they could write =C2=A0 =C2=A0 suitable text into the registry policy if they had to.

=C2=A0 =C2=A0 I quite like this one. Altho unorthodox, it's neat.


=C2=A0 =C2=A0 Thank you.


=C2=A0 =C2=A0 Bob

=C2=A0 =C2=A0 PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 &= 9) as
=C2=A0 =C2=A0 a 2-bit field during the 3-way hand-shake. While the ECN Nonc= e
=C2=A0 =C2=A0 and AccECN use the three ECN flags (bits 7-9) as a 3-bit fiel= d
=C2=A0 =C2=A0 during the 3WHS. AccECN uses the combinations that RFC3168 an= d
=C2=A0 =C2=A0 the Nonce do not use. So to cover all bases:

=C2=A0 =C2=A0 Option (f): ecn-experimentation alters the registry policy fo= r
=C2=A0 =C2=A0 bits 7-9 to "IETF Review".


=C2=A0 =C2=A0 On 03/07/17 18:14, C. M. Heard wrote:

=C2=A0 =C2=A0 Bob,

=C2=A0 =C2=A0 Couldn't the text in the IANA considerations of
=C2=A0 =C2=A0 ecn-experimentation (which needs to be updated in any case) =C2=A0 =C2=A0 both change the NS flag to Reserved for ECN Experimentation a= nd
=C2=A0 =C2=A0 change the allocation policy for that flag from Standards
=C2=A0 =C2=A0 Action to IETF Review, thereby updating RFC 2780? That would<= br> =C2=A0 =C2=A0 avoid the churn needed to add motivating text for a 4th
=C2=A0 =C2=A0 experiment to ecn-experimentation and would allow AccECN to =C2=A0 =C2=A0 assign the NS bit itself without a process exception.

=C2=A0 =C2=A0 Mike Heard

=C2=A0 =C2=A0 On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Michael*2, Yoshifumi, Gorry, David, Wes, Mirja,= Spencer,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 tcpm list, tsvwg list,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 There has been some offlist discussion (among d= ifferent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sub-groups) to narrow down the options here. It= is time to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 see opinions from the two affected WGs (tcpm an= d tsvwg) on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 preferred process, esp. from the WG chairs and = ADs.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=3D=3DBackground to the Process Problem=3D=3D*= *
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *

=C2=A0 =C2=A0 =C2=A0 =C2=A0 In tsvwg the process is in motion to make the E= CN nonce
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [RFC 3540] historic. So, in the most recent rev= of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-tcpm-accurate-ecn-03 , we could= finally include
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IANA assignment of the NS flag
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (see
=C2=A0 =C2=A0 =C2=A0 =C2=A0 htt= ps://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-= 6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#sect= ion-6> )

=C2=A0 =C2=A0 =C2=A0 =C2=A0 However, AccECN is EXPerimental, whereas the re= gistry
=C2=A0 =C2=A0 =C2=A0 =C2=A0 policy for assigning TCP flags is "Standar= ds Action"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = https://www.iana.org/assignments/tcp-header-flags/tcp-header-flag= s.xhtml
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.iana.org/assignments/tcp-header-flags/tcp-header-= flags.xhtml>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 which means "Values are assigned only for = Standards Track
=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFCs approved by the IESG" [RFC2434].

=C2=A0 =C2=A0 =C2=A0 =C2=A0 References:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Process for designating RFCs as h= istoric:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 htt= ps://www.ietf.org/iesg/statement/designating-rfcs-as-historic.htm= l
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/iesg/statement/designating-rfcs-as-historic= .html>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Current draft text to make RFC 35= 40 historic:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimenta= tion-03#section-3
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 My initial draft for the AD's= status change note:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://github.com/bbriscoe/ecn-= experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-hi= storic-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-t= o-historic-00.txt>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ecn-experimentation has just completed WGLC. It= still has
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to go through IETF LC (after Prague). it is del= iberately PS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 in order to be able to relax pre-existing const= raints on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ECN experiments in standards track RFCs. Howeve= r, if poss,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 we want to avoid adding motivating text for a 4= th
=C2=A0 =C2=A0 =C2=A0 =C2=A0 experiment, which could require another cycle o= f WGLC and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 delay until Nov.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 3692 ("Assigning Experimental and Test= ing Numbers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Considered Useful") could also be relevant= , although it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 doesn't seem to help here, because it is pr= imarily aimed at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 larger codepoint spaces, not single bits.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=3D=3DProcess Options=3D=3D**
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *
=C2=A0 =C2=A0 =C2=A0 =C2=A0 There need to be two parts to the process: 1) u= nassignment
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and 2) reassignment. The first seems clear-cut.= The second
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is less obvious.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 1) Unassigning the NS flag from RFC 3540
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a) add text to IANA considerations section of =C2=A0 =C2=A0 =C2=A0 =C2=A0 ecn-experientation making the NS flag reserved<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 2) Assigning the NS flag to accurate-ecn (and r= enaming it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the AE flag).
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Process options:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a) ecn-experimentation assigns flag to itself a= s reserved
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for experiments and says initially the AccECN e= xperiment
=C2=A0 =C2=A0 =C2=A0 =C2=A0 will use it exclusively
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b) ecn-experimentation assigns NS flag exclusiv= ely to AccECN
=C2=A0 =C2=A0 =C2=A0 =C2=A0 c) AccECN assigns NS flag to itself, with a pro= cess
=C2=A0 =C2=A0 =C2=A0 =C2=A0 exception proposed to the IESG to allow an EXP = doc to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 assign to a Standards Action registry
=C2=A0 =C2=A0 =C2=A0 =C2=A0 d) the NS flag is reassigned by "AD review= comment" or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "IETF Last Call comment" (quoted from= David's suggestions)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 e) other?...

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The difference between (a) and (b) is in the do= cument that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ends up being referenced from the IANA registry= :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a)=C2=A0 ecn-experimentation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b) accurate-ecn

 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *=3D=3DMy own preferences=3D=3D**
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *
=C2=A0 =C2=A0 =C2=A0 =C2=A0 During discussions, I didn't prefer (c) cos= I thought the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IESG might question why they are being asked to= make a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 process exception for an ECN experiment at the = same time as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a draft is going through that avoids raising pr= ocess
=C2=A0 =C2=A0 =C2=A0 =C2=A0 exceptions for ECN experiments.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Nonetheless, since then, Mirja has said...

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On 02/07/17 23:40, Mirja K=C3=BChlewind wrote:<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I actually prefer option (c). I don=E2=80=99t t= hink a process exception is a bad thing. If it=E2=80=99s the right thing to= do, then that the reason why we have such exceptions. Also I think it=E2= =80=99d be the right thing to change the registry policy=E2=80=A6 but that = probably a longer story.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I agree that it is outdated that the registry r= equires a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 standards action, because it has become normal = tcpm
=C2=A0 =C2=A0 =C2=A0 =C2=A0 practice for any change to TCP to have to start= on the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 experimental track. So this would justify a pro= cess exception.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 So, in summary, I don't mind (a), (b) or (c= ). I think (d)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is not sufficiently open and recorded for assig= nment of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 flag in the main TCP header.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Bob


=C2=A0 =C2=A0 --=C2=A0 =C2=A0 =C2=A0__________________________________= ______________________________
=C2=A0 =C2=A0 Bob Briscoehttp://bobbriscoe.net/



--
________________________________________________________________<= br> Bob Briscoehttp://bobbriscoe.net/


--94eb2c13d7126804310553bb312c-- From nobody Fri Jul 7 07:52:33 2017 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 A18C512704A; Fri, 7 Jul 2017 07:52: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, 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=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 m3G8lKaTSm3m; Fri, 7 Jul 2017 07:52: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 8B54F13160A; Fri, 7 Jul 2017 07:52:27 -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:From:References:Cc: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=Z4gncIaczBJA3YVgMCXxuyvXvCmKO5iU8R+j+fcOjyc=; b=Vf+DJGdBBdMToctjYsa7WGLcz Bld5zTiiW+X5r3sZ+pjeNF4oy3b+psH75xwU2/6bOOHYAj1OO/r7gkYyhZsKI9fL+bM0cCr6Tj0Fd +eBhWP7rojeeOcO9WFv0j4k3NoLnUrvUuI5HNdXM1qnHSObRRlzLTMsiJx8dyRf9uwZrPopsQna+0 40AozHfpvFvRgXe9GDxTVPAxeEAMBVbNmS9d/Hg6QL6Zadd8d8ZZvEfDDXZN4shu/dfQWyCJgsw0V G6DJGCLCv0HdROM4dIH52zaO7XrE23MwGNU1tlbACRZ2ieIv7Dx+xifwZs5LMibhuoygNjk8emJVY m3w71hXrA==; Received: from [31.185.128.124] (port=60086 helo=[192.168.0.13]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dTUcJ-0006TK-7q; Fri, 07 Jul 2017 15:52:23 +0100 To: Spencer Dawkins at IETF , G Fairhurst Cc: tsvwg-chairs , tcpm , tsvwg , tsv-ads , tcpm-chairs References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> <49200576-B166-4FE9-8B5D-36ECA5509364@erg.abdn.ac.uk> <99989ba2-4dae-eb6e-90fe-cb4b19f20594@bobbriscoe.net> <595BB715.70700@erg.abdn.ac.uk> From: Bob Briscoe Message-ID: Date: Fri, 7 Jul 2017 15:52:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DCC20F409C3400C4BA675BC1" 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] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 14:52:32 -0000 This is a multi-part message in MIME format. --------------DCC20F409C3400C4BA675BC1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Spencer, Good idea. Except herding WG chairs and ADs to a common space-time co-ordinate during an IETF is not easy. How about at AD Office hours? > on Sunday from 1500 to 1600 in the Istanbul room at IETF 99 Bob On 07/07/17 15:38, Spencer Dawkins at IETF wrote: > Gorry, since you asked - I don't have an objection to most of the > alternatives presented in this thread. Since we're most/all in Prague > Real Soon Now, I suggest that we have a whiteboard session at an > appropriate break in the action, and make sure we are all on the same > page, because there are several interconnected parts of the discussion. > > Thanks, > > Spencer > > On Tue, Jul 4, 2017 at 10:41 AM, G Fairhurst > wrote: > > On 04/07/2017, 16:19, Bob Briscoe wrote: > > Gorry, > > A point I didn't make, but should have done: 2 of the > experiments in ecn-experimentation depend on AccECN as a > pre-requisite. > > This I realised. > > So it's important not to risk delay to AccECN in an attempt > not to delay ecn-experimentation. > > OK - I will take it to the next Chair's meeting. > > Can you give any clue as to which solutions you do or don't > favour? Mirja asked me to post this to the lists. I think she > was hoping this would reveal all the pros and cons, so a > decision could then be made quickly between the > chairs/ADs/shepherds/catherds. > > I will - but need to consult others first. > > > Bob > > Gorry > > On 03/07/17 22:06, Gorry (erg) wrote: > > I think as document shepherd I have the input I need, but > I need to talk to my AD about how to handle the process - > and liaise with the TCPM co-chairs regarding the TCPM WG > draft. This isn't the first time we have had to look at > the implications of making another RFC historic, and I > think we can do the correct thing. > > Gorry > > On 3 Jul 2017, at 20:17, C. M. Heard >> wrote: > > Bob, > > I think that your option (f) is better than option (e) > (what I suggested). As an aside, either one patches up > an apparent process violation committed by RFC 3540, > an experimental RFC that assigned bit 7 in > contradiction to the policy in RFC 2780. > > Mike Heard > > On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe > > >> wrote: > > Mike, > > Let's call this option: > (e) ecn-experimentation alters the registry policy > of bit 7 of > the TCP header to "IETF Review". > > Having a different policy for certain bits within > a registry > might send IANA into a spin, but I am sure they > could write > suitable text into the registry policy if they had to. > > I quite like this one. Altho unorthodox, it's neat. > > > Thank you. > > > Bob > > PS. Strictly RFC3168 used the CWR and ECE flags > (bits 8 & 9) as > a 2-bit field during the 3-way hand-shake. While > the ECN Nonce > and AccECN use the three ECN flags (bits 7-9) as a > 3-bit field > during the 3WHS. AccECN uses the combinations that > RFC3168 and > the Nonce do not use. So to cover all bases: > > Option (f): ecn-experimentation alters the > registry policy for > bits 7-9 to "IETF Review". > > > On 03/07/17 18:14, C. M. Heard wrote: > > > Bob, > > Couldn't the text in the IANA considerations of > ecn-experimentation (which needs to be updated > in any case) > both change the NS flag to Reserved for ECN > Experimentation and > change the allocation policy for that flag > from Standards > Action to IETF Review, thereby updating RFC > 2780? That would > avoid the churn needed to add motivating text > for a 4th > experiment to ecn-experimentation and would > allow AccECN to > assign the NS bit itself without a process > exception. > > Mike Heard > > On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe > wrote: > > Michael*2, Yoshifumi, Gorry, David, Wes, > Mirja, Spencer, > tcpm list, tsvwg list, > > There has been some offlist discussion > (among different > sub-groups) to narrow down the options > here. It is time to > see opinions from the two affected WGs > (tcpm and tsvwg) on > preferred process, esp. from the WG chairs > and ADs. > > *==Background to the Process Problem==** > * > > In tsvwg the process is in motion to make > the ECN nonce > [RFC 3540] historic. So, in the most > recent rev of > draft-ietf-tcpm-accurate-ecn-03 , we could > finally include > IANA assignment of the NS flag > (see > https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6 > > > > > ) > > However, AccECN is EXPerimental, whereas > the registry > policy for assigning TCP flags is > "Standards Action" > https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml > > > > > which means "Values are assigned only for > Standards Track > RFCs approved by the IESG" [RFC2434]. > > References: > Process for designating RFCs as historic: > https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html > > > > > Current draft text to make RFC 3540 > historic: > https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3 > > > > > My initial draft for the AD's status > change note: > https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt > > > > > > ecn-experimentation has just completed > WGLC. It still has > to go through IETF LC (after Prague). it > is deliberately PS > in order to be able to relax pre-existing > constraints on > ECN experiments in standards track RFCs. > However, if poss, > we want to avoid adding motivating text > for a 4th > experiment, which could require another > cycle of WGLC and > delay until Nov. > > RFC 3692 ("Assigning Experimental and > Testing Numbers > Considered Useful") could also be > relevant, although it > doesn't seem to help here, because it is > primarily aimed at > larger codepoint spaces, not single bits. > > > *==Process Options==** > * > There need to be two parts to the process: > 1) unassignment > and 2) reassignment. The first seems > clear-cut. The second > is less obvious. > > 1) Unassigning the NS flag from RFC 3540 > a) add text to IANA considerations section of > ecn-experientation making the NS flag reserved > > 2) Assigning the NS flag to accurate-ecn > (and renaming it > the AE flag). > Process options: > a) ecn-experimentation assigns flag to > itself as reserved > for experiments and says initially the > AccECN experiment > will use it exclusively > b) ecn-experimentation assigns NS flag > exclusively to AccECN > c) AccECN assigns NS flag to itself, with > a process > exception proposed to the IESG to allow an > EXP doc to > assign to a Standards Action registry > d) the NS flag is reassigned by "AD review > comment" or > "IETF Last Call comment" (quoted from > David's suggestions) > e) other?... > > The difference between (a) and (b) is in > the document that > ends up being referenced from the IANA > registry: > a) ecn-experimentation > b) accurate-ecn > > *==My own preferences==** > * > During discussions, I didn't prefer (c) > cos I thought the > IESG might question why they are being > asked to make a > process exception for an ECN experiment at > the same time as > a draft is going through that avoids > raising process > exceptions for ECN experiments. > > Nonetheless, since then, Mirja has said... > > On 02/07/17 23:40, Mirja Kühlewind wrote: > > I actually prefer option (c). I don’t > think a process exception is a bad thing. If > it’s the right thing to do, then that the > reason why we have such exceptions. Also I > think it’d be the right thing to change the > registry policy… but that probably a longer story. > > I agree that it is outdated that the > registry requires a > standards action, because it has become > normal tcpm > practice for any change to TCP to have to > start on the > experimental track. So this would justify > a process exception. > > So, in summary, I don't mind (a), (b) or > (c). I think (d) > is not sufficiently open and recorded for > assignment of a > flag in the main TCP header. > > > Bob > > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ > > > > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ > > > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------DCC20F409C3400C4BA675BC1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Spencer,

Good idea. Except herding WG chairs and ADs to a common space-time co-ordinate during an IETF is not easy.
How about at AD Office hours?
on Sunday from 1500 to 1600 in the Istanbul room at IETF 99



Bob

On 07/07/17 15:38, Spencer Dawkins at IETF wrote:
Gorry, since you asked - I don't have an objection to most of the alternatives presented in this thread. Since we're most/all in Prague Real Soon Now, I suggest that we have a whiteboard session at an appropriate break in the action, and make sure we are all on the same page, because there are several interconnected parts of the discussion.

Thanks,

Spencer

On Tue, Jul 4, 2017 at 10:41 AM, G Fairhurst <gorry@erg.abdn.ac.uk> wrote:
On 04/07/2017, 16:19, Bob Briscoe wrote:
Gorry,

A point I didn't make, but should have done: 2 of the experiments in ecn-experimentation depend on AccECN as a pre-requisite.
This I realised.
So it's important not to risk delay to AccECN in an attempt not to delay ecn-experimentation.

 OK - I will take it to the next Chair's meeting.
Can you give any clue as to which solutions you do or don't favour? Mirja asked me to post this to the lists. I think she was hoping this would reveal all the pros and cons, so a decision could then be made quickly between the chairs/ADs/shepherds/catherds.

 I will - but need to consult others first.

Bob

Gorry
On 03/07/17 22:06, Gorry (erg) wrote:
I think as document shepherd I have the input I need, but I need to talk to my AD about how to handle the process  - and liaise with the TCPM co-chairs regarding the TCPM WG draft. This isn't the first time we have had to look at the implications of making another RFC historic, and I think we can do the correct thing.

Gorry

 On 3 Jul 2017, at 20:17, C. M. Heard <heard@pobox.com <mailto:heard@pobox.com>> wrote:
Bob,

I think that your option (f) is better than option (e) (what I suggested). As an aside, either one patches up an apparent process violation committed by RFC 3540, an experimental RFC that assigned bit 7 in contradiction to the policy in RFC 2780.

Mike Heard
On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe <ietf@bobbriscoe.net <mailto:ietf@bobbriscoe.net>> wrote:

    Mike,

    Let's call this option:
    (e) ecn-experimentation alters the registry policy of bit 7 of
    the TCP header to "IETF Review".

    Having a different policy for certain bits within a registry
    might send IANA into a spin, but I am sure they could write
    suitable text into the registry policy if they had to.

    I quite like this one. Altho unorthodox, it's neat.


    Thank you.


    Bob

    PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as
    a 2-bit field during the 3-way hand-shake. While the ECN Nonce
    and AccECN use the three ECN flags (bits 7-9) as a 3-bit field
    during the 3WHS. AccECN uses the combinations that RFC3168 and
    the Nonce do not use. So to cover all bases:

    Option (f): ecn-experimentation alters the registry policy for
    bits 7-9 to "IETF Review".


    On 03/07/17 18:14, C. M. Heard wrote:

    Bob,

    Couldn't the text in the IANA considerations of
    ecn-experimentation (which needs to be updated in any case)
    both change the NS flag to Reserved for ECN Experimentation and
    change the allocation policy for that flag from Standards
    Action to IETF Review, thereby updating RFC 2780? That would
    avoid the churn needed to add motivating text for a 4th
    experiment to ecn-experimentation and would allow AccECN to
    assign the NS bit itself without a process exception.

    Mike Heard

    On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote:

        Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer,
        tcpm list, tsvwg list,

        There has been some offlist discussion (among different
        sub-groups) to narrow down the options here. It is time to
        see opinions from the two affected WGs (tcpm and tsvwg) on
        preferred process, esp. from the WG chairs and ADs.

        *==Background to the Process Problem==**
        *

        In tsvwg the process is in motion to make the ECN nonce
        [RFC 3540] historic. So, in the most recent rev of
        draft-ietf-tcpm-accurate-ecn-03 , we could finally include
        IANA assignment of the NS flag
            (see
        https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6
        <https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6> )

        However, AccECN is EXPerimental, whereas the registry
        policy for assigning TCP flags is "Standards Action"
        https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml
        <https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml>
        which means "Values are assigned only for Standards Track
        RFCs approved by the IESG" [RFC2434].

        References:
            Process for designating RFCs as historic:
        https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html
        <https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html>
            Current draft text to make RFC 3540 historic:
        https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3
        <https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3>
            My initial draft for the AD's status change note:
        https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt
        <https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt>

        ecn-experimentation has just completed WGLC. It still has
        to go through IETF LC (after Prague). it is deliberately PS
        in order to be able to relax pre-existing constraints on
        ECN experiments in standards track RFCs. However, if poss,
        we want to avoid adding motivating text for a 4th
        experiment, which could require another cycle of WGLC and
        delay until Nov.

        RFC 3692 ("Assigning Experimental and Testing Numbers
        Considered Useful") could also be relevant, although it
        doesn't seem to help here, because it is primarily aimed at
        larger codepoint spaces, not single bits.


        *==Process Options==**
        *
        There need to be two parts to the process: 1) unassignment
        and 2) reassignment. The first seems clear-cut. The second
        is less obvious.

        1) Unassigning the NS flag from RFC 3540
        a) add text to IANA considerations section of
        ecn-experientation making the NS flag reserved

        2) Assigning the NS flag to accurate-ecn (and renaming it
        the AE flag).
        Process options:
        a) ecn-experimentation assigns flag to itself as reserved
        for experiments and says initially the AccECN experiment
        will use it exclusively
        b) ecn-experimentation assigns NS flag exclusively to AccECN
        c) AccECN assigns NS flag to itself, with a process
        exception proposed to the IESG to allow an EXP doc to
        assign to a Standards Action registry
        d) the NS flag is reassigned by "AD review comment" or
        "IETF Last Call comment" (quoted from David's suggestions)
        e) other?...

        The difference between (a) and (b) is in the document that
        ends up being referenced from the IANA registry:
        a)  ecn-experimentation
        b) accurate-ecn

         *==My own preferences==**
        *
        During discussions, I didn't prefer (c) cos I thought the
        IESG might question why they are being asked to make a
        process exception for an ECN experiment at the same time as
        a draft is going through that avoids raising process
        exceptions for ECN experiments.

        Nonetheless, since then, Mirja has said...

        On 02/07/17 23:40, Mirja Kühlewind wrote:
        I actually prefer option (c). I don’t think a process exception is a bad thing. If it’s the right thing to do, then that the reason why we have such exceptions. Also I think it’d be the right thing to change the registry policy… but that probably a longer story.
        I agree that it is outdated that the registry requires a
        standards action, because it has become normal tcpm
        practice for any change to TCP to have to start on the
        experimental track. So this would justify a process exception.

        So, in summary, I don't mind (a), (b) or (c). I think (d)
        is not sufficiently open and recorded for assignment of a
        flag in the main TCP header.


        Bob


    --     ________________________________________________________________
    Bob Briscoehttp://bobbriscoe.net/



--
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/



-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------DCC20F409C3400C4BA675BC1-- From nobody Fri Jul 7 09:04:49 2017 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 A58B813160F for ; Fri, 7 Jul 2017 09:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 E54sx4zEa9V5 for ; Fri, 7 Jul 2017 09:04:45 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE7B13160B for ; Fri, 7 Jul 2017 09:04:44 -0700 (PDT) Received: from Gs-MacBook-Pro.local (at-zeroshell-1.erg.abdn.ac.uk [139.133.217.68]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 048681B05858 for ; Fri, 7 Jul 2017 17:56:49 +0100 (BST) Message-ID: <595FA295.20305@erg.abdn.ac.uk> Date: Fri, 07 Jul 2017 16:02:45 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tsvwg] Agenda for TSVWG at IETF-99 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 16:04:47 -0000 Please have a look at the current agenda for TSVWG: https://www.ietf.org/proceedings/99/agenda/agenda-99-tsvwg-08 Gorry From nobody Fri Jul 7 13:50:01 2017 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 C994413154F for ; Fri, 7 Jul 2017 13:49:59 -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 83Mghr62copR for ; Fri, 7 Jul 2017 13:49:57 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 D4F4A1200FC for ; Fri, 7 Jul 2017 13:49:57 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id q85so22270631pfq.1 for ; Fri, 07 Jul 2017 13:49:57 -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=pHEaTdUxnCYaZ4SMyEQGoVBlULqVElaISIqrNadk7eI=; b=lGbTPxsLYJgIA9qfq0tZYS76pYlJe8XU7QQn0VWaT83VpDCmjVvyaS8LvzzzyIrUgM zY9BDYxFFPDRR1he7Vop7Bgvcs1mDvYOw1ANnuSzBSsuR9TLET9s29EuW/WndyQko0gu xmqBsmr9pxy4M5INnkz5l/hEQTS8U0sKC4PqJy+vfFfkdqIRmwMP3IU4IZDI2nNhX/60 je7sn6lN4W8JgcE71Xz0y//RgwlTXoy9LQd0w2hdI9na/oZWlLhmJiWwonxxYD8ZQeT/ UU1T7/G0CmlzxVrrD1eoURaINJFVWLG6tWWyQaFXenT74aKO7Yqd9mvRXEXO7OWWN41/ GzLw== 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=pHEaTdUxnCYaZ4SMyEQGoVBlULqVElaISIqrNadk7eI=; b=M2+ZMnaNwqr+MH+Rrmd46F49dSdcRDs7pLPP/JsKrCABsOGKo/OWK3OufZ2/2INGSE ozUZLlEtNcRgMGsHWFTUkAPngptwHQYB3I1okm15Gd9tbyQ5kByWCxnq3xvL6Fp+vEhc N9/ewscJOw8fx5eiFfKBNl/mn+8C9rYiNDcMTxfx5HgkYpIPCDhpQP9q335geBdqKx0Z 6sCyQStfQvmDzxl2MaHyk5tPT5aYP3+ALM8+1S697oDOaXY3qIRUE6qDP1IyBr0Bj8/H SSzA/om+165kiUGuZ3Ef6xxBh+vodewqqcE3wM7GmAs4DrdjFyd1RxtiGFWJzVvnXH5u E5Bw== X-Gm-Message-State: AIVw113DIZMnczrYhmeHLG+aS/XmDop1oE37/s6Aqr0q8sWmOoBWp5IB o0/Jin8Dd1+b8mU7chM= X-Received: by 10.99.54.73 with SMTP id d70mr3312350pga.195.1499460597154; Fri, 07 Jul 2017 13:49:57 -0700 (PDT) Received: from ?IPv6:2406:e007:6d62:1:28cc:dc4c:9703:6781? ([2406:e007:6d62:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id r62sm10067595pfl.45.2017.07.07.13.49.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jul 2017 13:49:56 -0700 (PDT) To: gorry@erg.abdn.ac.uk, "Bless, Roland (TM)" Cc: tsvwg@ietf.org References: <595F4D19.9030502@erg.abdn.ac.uk> <011e5fb5-6c83-bb38-e2cb-7fced2cb774a@kit.edu> <595F6F4F.20005@erg.abdn.ac.uk> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 8 Jul 2017 08:50:03 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <595F6F4F.20005@erg.abdn.ac.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 20:50:00 -0000 On 07/07/2017 23:23, Gorry Fairhurst wrote: > On 07/07/2017, 12:03, Bless, Roland (TM) wrote: >> Hi Gorry, >> >> Am 07.07.2017 um 10:58 schrieb Gorry Fairhurst: >>> This email is intended to start a discussion about the most appropriate >>> DiffServ codepoint to assign to the LE PHB specified in: >>> https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-02 >>> >>> The current list of available codepoints is listed by IANA here: >>> https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml >>> >>> The draft currently suggests using the DSCP value, '000010'. >> I think it is DSCP value 2. > That's two indeed:-). >>> Question 1: Is this codepoint a good choice for the TSVWG group to >>> assign for the LE PHB? >>> >>> Things to consider: >>> - Is the codepoint currently being used for other (non-standard >>> applications) that may get in the way of the deployment of the LE PHB? >> Currently, nothing should be using a non-assigned Standard DSCP. >> I really don't like these discussion along the lines of: oh, probably >> there are some standard-ignoring boxes/apps out there, so lets try to >> work around their broken design. So, yes, it's probably good to know, >> but IMHO it's better to get this other stuff fixed rather than to always >> create workaround. > And, I think a more usedful disucssion here is around - "what happens > when you use existing codepoints that are IETF-approved, and they pass > through the current Internet" - do they emerge as the codepoint you propose? Since the architecture allows *any* rewriting whatever of the DSCP value at a domain boundary, I'm not clear why any of this is relevant. The Internet isn't supposed to be transparent to DSCP values, and all DSCP values are recommendations anyway. It seems to me that RFC8100 resolves the issue about what is expected to work across domain boundaries; all we are doing here is fixing the historical misuse of a codepoint. So 000010 seems like a perfectly fine bit pattern to me. Brian >>> - Is there ant evidence that this DSCP value is less likely to be >>> forwarded than other unused codepoints? >>> - Is this codepoint observed in the wild due to common DSCP-mangling >>> pathologies (such as ToS-byte bleaching)? >>> >>> Question 2: Is there an alternate unassigned codepint that could be >>> chosen that would give better opprotunities for deployment? >>> Things to consider: >>> - A codepoint less than 7 appears to have less chance of >>> DSCP-mangling pathologies (such as ToS-byte bleaching) >>> - IANA currently allocates from pool 1 (xxxxx0), but we could >>> consider asking to use pool 3 ('xxxx01'), e.g., '000001'or '000101'. >> I don't see any compelling reason to start using another pool right now. > Don't you? I think this depends on the outcome. >>> Measurement experience and thoughts on this topic are welcome on the >>> mailing list ahead of the TSVWG meeting. At this meeting, I would like >>> to see some discussion confirming the choice of DSCP codepoint or >>> suggesting a more appropriate codepoint for the working group to request. >> Thanks for triggering the discussion. >> >> Regards, >> Roland > Roland, do you have any measurement data? > > Gorry > > From nobody Sun Jul 9 04:12:41 2017 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 B009F1287A5 for ; Sun, 9 Jul 2017 04:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk 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 IBz50W722OI0 for ; Sun, 9 Jul 2017 04:12:36 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B7A31277BB for ; Sun, 9 Jul 2017 04:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1499598754; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=jKiSV8BLVacofY20w+Pas+NeoWTr7pT3IPO4QxQ4SDQ=; b=H9gmLMEwK0/rYsS3q/ZHJs2FHljzaKmipv+ZO58hqHgNAEAaUbilAcg+zodpt2Mux/abrNS9EaB5l+G1+5QFq/XjvcQgF3WzAP3asAlVOsAlooV+woz2i7jE1IAOCtqeBA2wVGjz+ai4NOyK32WTZJ/EeKQK+Bvf8BytBwjd8oQ= Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02lp0052.outbound.protection.outlook.com [213.199.154.52]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-41-AilZNk_tNFGeUan2X84j-Q-1; Sun, 09 Jul 2017 12:12:28 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB435.eurprd07.prod.outlook.com (10.242.112.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.4; Sun, 9 Jul 2017 11:12:26 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::e900:f005:6fa:29aa]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::e900:f005:6fa:29aa%14]) with mapi id 15.01.1261.007; Sun, 9 Jul 2017 11:12:26 +0000 From: Tim Chown To: Brian E Carpenter CC: "gorry@erg.abdn.ac.uk" , "Bless, Roland (TM)" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? Thread-Index: AQHS92Kl1ri+DvfXuU2Ope9bkqrAk6JLWbuA Date: Sun, 9 Jul 2017 11:12:26 +0000 Message-ID: References: <595F4D19.9030502@erg.abdn.ac.uk> <011e5fb5-6c83-bb38-e2cb-7fced2cb774a@kit.edu> <595F6F4F.20005@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:a88:d510:1101:116c:36b3:2381:7d4b] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB435; 20:D4Alx8xFR0Gql/bGERsruEdQFuVWDsdLdlgawt+4FIrNj3bzRmDdqTg67HWq1s6/Ym3hSk6XuaxJjlpy0ux0+W53arW6i6CWEEys8XxmhXq4C0N61pi/cYrj8OHVBdauSW/uGAvkynKcZXqVPhgHE0p6denGEGBIVQEkbpCo6E4= x-ms-office365-filtering-correlation-id: 8a89e994-2b68-4bf2-d5ef-08d4c6bb6165 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB435; x-ms-traffictypediagnostic: AM3PR07MB435: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(236129657087228)(1591387915157); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(201703131423075)(201702281528075)(201702281529075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123564025)(20161123558100)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB435; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB435; x-forefront-prvs: 03630A6A4A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39410400002)(39830400002)(39450400003)(24454002)(14454004)(3280700002)(3660700001)(7736002)(8676002)(2906002)(82746002)(5250100002)(81166006)(25786009)(42882006)(2950100002)(33656002)(966005)(83716003)(189998001)(93886004)(50226002)(74482002)(5660300001)(2900100001)(72206003)(8936002)(4326008)(57306001)(6916009)(53936002)(478600001)(305945005)(76176999)(50986999)(39060400002)(6246003)(36756003)(6436002)(6506006)(6306002)(6512007)(38730400002)(110136004)(6486002)(99286003)(54906002)(229853002)(53546010)(6116002)(102836003)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB435; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <9D80FC3D42B39747835E3795C40B0E9D@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2017 11:12:26.0549 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB435 X-MC-Unique: AilZNk_tNFGeUan2X84j-Q-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2017 11:12:40 -0000 PiBPbiA3IEp1bCAyMDE3LCBhdCAyMTo1MCwgQnJpYW4gRSBDYXJwZW50ZXIgPGJyaWFuLmUuY2Fy cGVudGVyQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBPbiAwNy8wNy8yMDE3IDIzOjIzLCBHb3Jy eSBGYWlyaHVyc3Qgd3JvdGU6DQo+PiBPbiAwNy8wNy8yMDE3LCAxMjowMywgQmxlc3MsIFJvbGFu ZCAoVE0pIHdyb3RlOg0KPj4+IEhpIEdvcnJ5LA0KPj4+IA0KPj4+IEFtIDA3LjA3LjIwMTcgdW0g MTA6NTggc2NocmllYiBHb3JyeSBGYWlyaHVyc3Q6DQo+Pj4+IFRoaXMgZW1haWwgaXMgaW50ZW5k ZWQgdG8gc3RhcnQgYSBkaXNjdXNzaW9uIGFib3V0IHRoZSBtb3N0IGFwcHJvcHJpYXRlDQo+Pj4+ IERpZmZTZXJ2IGNvZGVwb2ludCB0byBhc3NpZ24gdG8gdGhlIExFIFBIQiBzcGVjaWZpZWQgaW46 DQo+Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRzdndnLWxlLXBo Yi0wMg0KPj4+PiANCj4+Pj4gVGhlIGN1cnJlbnQgbGlzdCBvZiBhdmFpbGFibGUgY29kZXBvaW50 cyBpcyBsaXN0ZWQgYnkgSUFOQSBoZXJlOg0KPj4+PiBodHRwczovL3d3dy5pYW5hLm9yZy9hc3Np Z25tZW50cy9kc2NwLXJlZ2lzdHJ5L2RzY3AtcmVnaXN0cnkueGh0bWwNCj4+Pj4gDQo+Pj4+IFRo ZSBkcmFmdCBjdXJyZW50bHkgc3VnZ2VzdHMgdXNpbmcgdGhlIERTQ1AgdmFsdWUsICcwMDAwMTAn Lg0KPj4+IEkgdGhpbmsgaXQgaXMgRFNDUCB2YWx1ZSAyLg0KPiANCj4+IFRoYXQncyB0d28gaW5k ZWVkOi0pLg0KPiANCj4+Pj4gUXVlc3Rpb24gMTogSXMgdGhpcyBjb2RlcG9pbnQgYSBnb29kIGNo b2ljZSBmb3IgdGhlIFRTVldHIGdyb3VwIHRvDQo+Pj4+IGFzc2lnbiBmb3IgdGhlIExFIFBIQj8N Cj4+Pj4gDQo+Pj4+ICAgVGhpbmdzIHRvIGNvbnNpZGVyOg0KPj4+PiAgICAgLSBJcyB0aGUgY29k ZXBvaW50IGN1cnJlbnRseSBiZWluZyB1c2VkIGZvciBvdGhlciAobm9uLXN0YW5kYXJkDQo+Pj4+ IGFwcGxpY2F0aW9ucykgdGhhdCBtYXkgZ2V0IGluIHRoZSB3YXkgb2YgdGhlIGRlcGxveW1lbnQg b2YgdGhlIExFIFBIQj8NCj4+PiBDdXJyZW50bHksIG5vdGhpbmcgc2hvdWxkIGJlIHVzaW5nIGEg bm9uLWFzc2lnbmVkIFN0YW5kYXJkIERTQ1AuDQo+Pj4gSSByZWFsbHkgZG9uJ3QgbGlrZSB0aGVz ZSBkaXNjdXNzaW9uIGFsb25nIHRoZSBsaW5lcyBvZjogb2gsIHByb2JhYmx5DQo+Pj4gdGhlcmUg YXJlIHNvbWUgc3RhbmRhcmQtaWdub3JpbmcgYm94ZXMvYXBwcyBvdXQgdGhlcmUsIHNvIGxldHMg dHJ5IHRvDQo+Pj4gd29yayBhcm91bmQgdGhlaXIgYnJva2VuIGRlc2lnbi4gU28sIHllcywgaXQn cyBwcm9iYWJseSBnb29kIHRvIGtub3csDQo+Pj4gYnV0IElNSE8gaXQncyBiZXR0ZXIgdG8gZ2V0 IHRoaXMgb3RoZXIgc3R1ZmYgZml4ZWQgcmF0aGVyIHRoYW4gdG8gYWx3YXlzDQo+Pj4gY3JlYXRl IHdvcmthcm91bmQuDQo+IA0KPj4gQW5kLCBJIHRoaW5rIGEgbW9yZSB1c2VkZnVsIGRpc3Vjc3Np b24gaGVyZSBpcyBhcm91bmQgLSAid2hhdCBoYXBwZW5zIA0KPj4gd2hlbiB5b3UgdXNlIGV4aXN0 aW5nIGNvZGVwb2ludHMgdGhhdCBhcmUgSUVURi1hcHByb3ZlZCwgYW5kIHRoZXkgcGFzcyANCj4+ IHRocm91Z2ggdGhlIGN1cnJlbnQgSW50ZXJuZXQiIC0gZG8gdGhleSBlbWVyZ2UgYXMgdGhlIGNv ZGVwb2ludCB5b3UgcHJvcG9zZT8NCj4gDQo+IFNpbmNlIHRoZSBhcmNoaXRlY3R1cmUgYWxsb3dz ICphbnkqIHJld3JpdGluZyB3aGF0ZXZlciBvZiB0aGUgRFNDUCB2YWx1ZQ0KPiBhdCBhIGRvbWFp biBib3VuZGFyeSwgSSdtIG5vdCBjbGVhciB3aHkgYW55IG9mIHRoaXMgaXMgcmVsZXZhbnQuIFRo ZSBJbnRlcm5ldA0KPiBpc24ndCBzdXBwb3NlZCB0byBiZSB0cmFuc3BhcmVudCB0byBEU0NQIHZh bHVlcywgYW5kIGFsbCBEU0NQIHZhbHVlcyBhcmUNCj4gcmVjb21tZW5kYXRpb25zIGFueXdheS4g DQo+IA0KPiBJdCBzZWVtcyB0byBtZSB0aGF0IFJGQzgxMDAgcmVzb2x2ZXMgdGhlIGlzc3VlIGFi b3V0IHdoYXQgaXMgZXhwZWN0ZWQgdG8NCj4gd29yayBhY3Jvc3MgZG9tYWluIGJvdW5kYXJpZXM7 IGFsbCB3ZSBhcmUgZG9pbmcgaGVyZSBpcyBmaXhpbmcgdGhlIGhpc3RvcmljYWwNCj4gbWlzdXNl IG9mIGEgY29kZXBvaW50Lg0KDQpEbyB5b3UgbWVhbiBEU0NQIDggYmVpbmcgdXNlZCBieSBMQkUv U2NhdmVuZ2VyIGFzIGZhciBiYWNrIGFzIDIwMDIgb3Igc28/DQoNCj4gU28gMDAwMDEwIHNlZW1z IGxpa2UgYSBwZXJmZWN0bHkgZmluZSBiaXQgcGF0dGVybiB0byBtZS4NCg0KSW5kZWVkLiBJdOKA mXMgZ29vZCB0byBoYXZlIHNvbWUgZGVmYXVsdCB2YWx1ZSB0aGF0IGNhbiBiZSBhZ3JlZWQgYmV0 d2VlbiBkb21haW5zLg0KDQpUaW0NCg0KPiAgICBCcmlhbg0KPiANCj4+Pj4gICAgIC0gSXMgdGhl cmUgYW50IGV2aWRlbmNlIHRoYXQgdGhpcyBEU0NQIHZhbHVlIGlzIGxlc3MgbGlrZWx5IHRvIGJl DQo+Pj4+IGZvcndhcmRlZCB0aGFuIG90aGVyIHVudXNlZCBjb2RlcG9pbnRzPw0KPj4+PiAgICAg LSBJcyB0aGlzIGNvZGVwb2ludCBvYnNlcnZlZCBpbiB0aGUgd2lsZCBkdWUgdG8gY29tbW9uIERT Q1AtbWFuZ2xpbmcNCj4+Pj4gcGF0aG9sb2dpZXMgKHN1Y2ggYXMgVG9TLWJ5dGUgYmxlYWNoaW5n KT8NCj4+Pj4gDQo+Pj4+IFF1ZXN0aW9uIDI6IElzIHRoZXJlIGFuIGFsdGVybmF0ZSB1bmFzc2ln bmVkIGNvZGVwaW50IHRoYXQgY291bGQgYmUNCj4+Pj4gY2hvc2VuIHRoYXQgd291bGQgZ2l2ZSBi ZXR0ZXIgb3Bwcm90dW5pdGllcyBmb3IgZGVwbG95bWVudD8NCj4+Pj4gICAgIFRoaW5ncyB0byBj b25zaWRlcjoNCj4+Pj4gICAgIC0gQSBjb2RlcG9pbnQgbGVzcyB0aGFuIDcgYXBwZWFycyB0byBo YXZlIGxlc3MgY2hhbmNlIG9mDQo+Pj4+IERTQ1AtbWFuZ2xpbmcgcGF0aG9sb2dpZXMgKHN1Y2gg YXMgVG9TLWJ5dGUgYmxlYWNoaW5nKQ0KPj4+PiAgICAgLSBJQU5BIGN1cnJlbnRseSBhbGxvY2F0 ZXMgZnJvbSBwb29sIDEgKHh4eHh4MCksIGJ1dCB3ZSBjb3VsZA0KPj4+PiBjb25zaWRlciBhc2tp bmcgdG8gdXNlIHBvb2wgMyAoJ3h4eHgwMScpLCBlLmcuLCAnMDAwMDAxJ29yICcwMDAxMDEnLg0K Pj4+IEkgZG9uJ3Qgc2VlIGFueSBjb21wZWxsaW5nIHJlYXNvbiB0byBzdGFydCB1c2luZyBhbm90 aGVyIHBvb2wgcmlnaHQgbm93Lg0KPiANCj4+IERvbid0IHlvdT8gSSB0aGluayB0aGlzIGRlcGVu ZHMgb24gdGhlIG91dGNvbWUuDQo+IA0KPj4+PiBNZWFzdXJlbWVudCBleHBlcmllbmNlIGFuZCB0 aG91Z2h0cyBvbiB0aGlzIHRvcGljIGFyZSB3ZWxjb21lIG9uIHRoZQ0KPj4+PiBtYWlsaW5nIGxp c3QgYWhlYWQgb2YgdGhlIFRTVldHIG1lZXRpbmcuIEF0IHRoaXMgbWVldGluZywgSSB3b3VsZCBs aWtlDQo+Pj4+IHRvIHNlZSBzb21lIGRpc2N1c3Npb24gY29uZmlybWluZyB0aGUgY2hvaWNlIG9m IERTQ1AgY29kZXBvaW50IG9yDQo+Pj4+IHN1Z2dlc3RpbmcgYSBtb3JlIGFwcHJvcHJpYXRlIGNv ZGVwb2ludCBmb3IgdGhlIHdvcmtpbmcgZ3JvdXAgdG8gcmVxdWVzdC4NCj4+PiBUaGFua3MgZm9y IHRyaWdnZXJpbmcgdGhlIGRpc2N1c3Npb24uDQo+Pj4gDQo+Pj4gUmVnYXJkcywNCj4+PiAgUm9s YW5kDQo+PiBSb2xhbmQsIGRvIHlvdSBoYXZlIGFueSBtZWFzdXJlbWVudCBkYXRhPw0KPj4gDQo+ PiBHb3JyeQ0KPj4gDQo+PiANCj4gDQoNCg== From nobody Sun Jul 9 13:29:54 2017 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 4AE9E12EC42 for ; Sun, 9 Jul 2017 13:29:52 -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 sRtxuVX0xQ9z for ; Sun, 9 Jul 2017 13:29:50 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::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 5C06312EC15 for ; Sun, 9 Jul 2017 13:29:50 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id q86so39680262pfl.3 for ; Sun, 09 Jul 2017 13:29:50 -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=MetUOjC+pWd9BiMx6osM0sttKKIxQpLbVA4bwonidtI=; b=uxAsLzzwpymqrVkkN25VyM+VJtsuhPW0YcZn922p7/Dc1IpC9umRfBTqO4kjdRhzm+ M+FnIRZsibTLG6y94ApLJR+LcC+CdQPjAH+SbhHxslY/DuzoSiEi5dHsWm1tgfDL3YV+ 2konYafGC7kiVsWY/RA9X60g+izl1an9a6OU+3HqA/+jEpurWe5w2P+8X8LNL1GM3IN+ 7rJp+ZHwOn4OcJ/dIXl8hIhi7HvBOPIpaRXyZbb0JiSPkzKA1QBNmd/V5UcnCIdvnsSk /c++Tk7KHahs/nkt3kUqX3gaOItm7cnvkSTGKmEaV0VUcIn6KxA46dnATxpC6BoncEqX SC0A== 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=MetUOjC+pWd9BiMx6osM0sttKKIxQpLbVA4bwonidtI=; b=o8bJbzXmqHhnfOgSGr46EHEH3h0kVcemEM88DB9om11kAE9zobiaVI9n5BJqo/GStM BweZOgk7n46PDHbnSoZq9X89azdec3DSRRFddqRf8LCypi/C6vNQisC7nN6SC0fFhca1 evezuRg6jNcbSNd7Yi8LTkEYrXpQBqDj0t02zI2YsPbIs/vskx1Kd42gos6CnkXT1SF2 10GUn24Tpjs97J6dTPKygbDPobryUomgbv4BFM6Ra86DdQMbEHPITPiqz7REvJ0iAhG0 ob7LhMaujX77zvIW8bIDg2se1C+goFn4SeEp7W1bRDQ3vpqCDhUk14kB/HuJX9wzSv4E d/gA== X-Gm-Message-State: AIVw111qP0GmmNnxP2wO3zHe6UzsePOBsIoRwfbjn9cTwbuW9Gh8M6NR ckujILAo9KBIoLSt X-Received: by 10.84.224.3 with SMTP id r3mr14548638plj.38.1499632189603; Sun, 09 Jul 2017 13:29:49 -0700 (PDT) Received: from [192.168.178.21] ([118.148.76.144]) by smtp.gmail.com with ESMTPSA id d3sm4000111pfj.47.2017.07.09.13.29.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Jul 2017 13:29:49 -0700 (PDT) To: Tim Chown Cc: "gorry@erg.abdn.ac.uk" , "Bless, Roland (TM)" , "tsvwg@ietf.org" References: <595F4D19.9030502@erg.abdn.ac.uk> <011e5fb5-6c83-bb38-e2cb-7fced2cb774a@kit.edu> <595F6F4F.20005@erg.abdn.ac.uk> From: Brian E Carpenter Organization: University of Auckland Message-ID: <74717821-30ae-203b-197b-2455cbf9d4a3@gmail.com> Date: Mon, 10 Jul 2017 08:29:41 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.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] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2017 20:29:52 -0000 On 09/07/2017 23:12, Tim Chown wrote: >> On 7 Jul 2017, at 21:50, Brian E Carpenter wrote: >> >> On 07/07/2017 23:23, Gorry Fairhurst wrote: >>> On 07/07/2017, 12:03, Bless, Roland (TM) wrote: >>>> Hi Gorry, >>>> >>>> Am 07.07.2017 um 10:58 schrieb Gorry Fairhurst: >>>>> This email is intended to start a discussion about the most appropr= iate >>>>> DiffServ codepoint to assign to the LE PHB specified in: >>>>> https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-02 >>>>> >>>>> The current list of available codepoints is listed by IANA here: >>>>> https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml >>>>> >>>>> The draft currently suggests using the DSCP value, '000010'. >>>> I think it is DSCP value 2. >> >>> That's two indeed:-). >> >>>>> Question 1: Is this codepoint a good choice for the TSVWG group to >>>>> assign for the LE PHB? >>>>> >>>>> Things to consider: >>>>> - Is the codepoint currently being used for other (non-standard= >>>>> applications) that may get in the way of the deployment of the LE P= HB? >>>> Currently, nothing should be using a non-assigned Standard DSCP. >>>> I really don't like these discussion along the lines of: oh, probabl= y >>>> there are some standard-ignoring boxes/apps out there, so lets try t= o >>>> work around their broken design. So, yes, it's probably good to know= , >>>> but IMHO it's better to get this other stuff fixed rather than to al= ways >>>> create workaround. >> >>> And, I think a more usedful disucssion here is around - "what happens= =20 >>> when you use existing codepoints that are IETF-approved, and they pas= s=20 >>> through the current Internet" - do they emerge as the codepoint you p= ropose? >> >> Since the architecture allows *any* rewriting whatever of the DSCP val= ue >> at a domain boundary, I'm not clear why any of this is relevant. The I= nternet >> isn't supposed to be transparent to DSCP values, and all DSCP values a= re >> recommendations anyway.=20 >> >> It seems to me that RFC8100 resolves the issue about what is expected = to >> work across domain boundaries; all we are doing here is fixing the his= torical >> misuse of a codepoint. >=20 > Do you mean DSCP 8 being used by LBE/Scavenger as far back as 2002 or s= o? Yes. IMHO we made a mistake when the use of CS1 for LE was first document= ed (draft-bless-diffserv-pdb-le-00 in June 2002, and I was even a co-author on that version). We should have said that it was a Bad Idea; instead we said it was "justified" to violate a SHOULD in RFC2474. Brian =20 >> So 000010 seems like a perfectly fine bit pattern to me. >=20 > Indeed. It=E2=80=99s good to have some default value that can be agreed= between domains. >=20 > Tim >=20 >> Brian >> >>>>> - Is there ant evidence that this DSCP value is less likely to = be >>>>> forwarded than other unused codepoints? >>>>> - Is this codepoint observed in the wild due to common DSCP-man= gling >>>>> pathologies (such as ToS-byte bleaching)? >>>>> >>>>> Question 2: Is there an alternate unassigned codepint that could be= >>>>> chosen that would give better opprotunities for deployment? >>>>> Things to consider: >>>>> - A codepoint less than 7 appears to have less chance of >>>>> DSCP-mangling pathologies (such as ToS-byte bleaching) >>>>> - IANA currently allocates from pool 1 (xxxxx0), but we could >>>>> consider asking to use pool 3 ('xxxx01'), e.g., '000001'or '000101'= =2E >>>> I don't see any compelling reason to start using another pool right = now. >> >>> Don't you? I think this depends on the outcome. >> >>>>> Measurement experience and thoughts on this topic are welcome on th= e >>>>> mailing list ahead of the TSVWG meeting. At this meeting, I would l= ike >>>>> to see some discussion confirming the choice of DSCP codepoint or >>>>> suggesting a more appropriate codepoint for the working group to re= quest. >>>> Thanks for triggering the discussion. >>>> >>>> Regards, >>>> Roland >>> Roland, do you have any measurement data? >>> >>> Gorry >>> >>> >> >=20 From nobody Sun Jul 9 14:02:41 2017 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 213BF126CB6 for ; Sun, 9 Jul 2017 14:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk 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 Ky_ayO9IbwFC for ; Sun, 9 Jul 2017 14:02:30 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960DF12EC18 for ; Sun, 9 Jul 2017 14:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1499634148; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=GLvXV97g9i3rusE1E1GCosMRsQTh8ZpHUopHSH+aOyY=; b=GODeBoTabyhNvdvOS7Wa5rwIEWONmPsYIuxk9QBF4tgy/sRRhQFoXSxL6OS7a+Qo28mvI5M06eP5eTcj19IuCPlyXhKVQMyYg3RkNgYl6Hoi0A5SASuUjOe3SBe1GMUuQnPWYaDgim3v1pRckvm5BilmE0/47HI1abGdsR6IVkg= Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02lp0182.outbound.protection.outlook.com [213.199.180.182]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-61-cl5tgK7-PbaqZgCvfsH54w-1; Sun, 09 Jul 2017 22:02:24 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB0568.eurprd07.prod.outlook.com (10.255.133.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.4; Sun, 9 Jul 2017 21:02:22 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::e900:f005:6fa:29aa]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::e900:f005:6fa:29aa%14]) with mapi id 15.01.1261.012; Sun, 9 Jul 2017 21:02:21 +0000 From: Tim Chown To: Brian E Carpenter CC: "gorry@erg.abdn.ac.uk" , "Bless, Roland (TM)" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? Thread-Index: AQHS92Kl1ri+DvfXuU2Ope9bkqrAk6JLWbuAgACbr4CAAAkggA== Date: Sun, 9 Jul 2017 21:02:21 +0000 Message-ID: <66425AFB-A929-4A91-90F8-432F4FAE0520@jisc.ac.uk> References: <595F4D19.9030502@erg.abdn.ac.uk> <011e5fb5-6c83-bb38-e2cb-7fced2cb774a@kit.edu> <595F6F4F.20005@erg.abdn.ac.uk> <74717821-30ae-203b-197b-2455cbf9d4a3@gmail.com> In-Reply-To: <74717821-30ae-203b-197b-2455cbf9d4a3@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:a88:d510:1101:116c:36b3:2381:7d4b] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB0568; 20:WcHECQf4/Qg8sK1smtdR94F6SphsSON36kvy8gO9ApmaArj7AWpXOfcjd/v6N/5oHkIykXTBe8SLdUleiZVA9zstRdWGdiMjGmusimvnxjj2Gq23aR3U94HJSgoNJe4GjF8duuTDuZoac4dB0qTs/b3G9HImF1FcUGtifCQIvLM= x-ms-office365-filtering-correlation-id: 67a69db6-2559-4bb9-1294-08d4c70dcad1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB0568; x-ms-traffictypediagnostic: AM3PR07MB0568: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(236129657087228)(1591387915157); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123564025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201702281529075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB0568; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB0568; x-forefront-prvs: 03630A6A4A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39450400003)(39840400002)(24454002)(6486002)(3280700002)(74482002)(83716003)(53936002)(478600001)(72206003)(81166006)(86362001)(4326008)(966005)(229853002)(8936002)(2906002)(8676002)(82746002)(39060400002)(6246003)(38730400002)(110136004)(50226002)(102836003)(6116002)(2950100002)(5660300001)(36756003)(7736002)(6916009)(54906002)(93886004)(97736004)(2900100001)(57306001)(3660700001)(6436002)(76176999)(33656002)(6306002)(99286003)(6512007)(6506006)(50986999)(53546010)(42882006)(14454004)(25786009)(305945005)(5250100002)(189998001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0568; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2017 21:02:21.5721 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0568 X-MC-Unique: cl5tgK7-PbaqZgCvfsH54w-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2017 21:02:40 -0000 PiBPbiA5IEp1bCAyMDE3LCBhdCAyMToyOSwgQnJpYW4gRSBDYXJwZW50ZXIgPGJyaWFuLmUuY2Fy cGVudGVyQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBPbiAwOS8wNy8yMDE3IDIzOjEyLCBUaW0g Q2hvd24gd3JvdGU6DQo+Pj4gT24gNyBKdWwgMjAxNywgYXQgMjE6NTAsIEJyaWFuIEUgQ2FycGVu dGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOg0KPj4+IA0KPj4+IE9uIDA3 LzA3LzIwMTcgMjM6MjMsIEdvcnJ5IEZhaXJodXJzdCB3cm90ZToNCj4+Pj4gT24gMDcvMDcvMjAx NywgMTI6MDMsIEJsZXNzLCBSb2xhbmQgKFRNKSB3cm90ZToNCj4+Pj4+IEhpIEdvcnJ5LA0KPj4+ Pj4gDQo+Pj4+PiBBbSAwNy4wNy4yMDE3IHVtIDEwOjU4IHNjaHJpZWIgR29ycnkgRmFpcmh1cnN0 Og0KPj4+Pj4+IFRoaXMgZW1haWwgaXMgaW50ZW5kZWQgdG8gc3RhcnQgYSBkaXNjdXNzaW9uIGFi b3V0IHRoZSBtb3N0IGFwcHJvcHJpYXRlDQo+Pj4+Pj4gRGlmZlNlcnYgY29kZXBvaW50IHRvIGFz c2lnbiB0byB0aGUgTEUgUEhCIHNwZWNpZmllZCBpbjoNCj4+Pj4+PiBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10c3Z3Zy1sZS1waGItMDINCj4+Pj4+PiANCj4+Pj4+PiBU aGUgY3VycmVudCBsaXN0IG9mIGF2YWlsYWJsZSBjb2RlcG9pbnRzIGlzIGxpc3RlZCBieSBJQU5B IGhlcmU6DQo+Pj4+Pj4gaHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvZHNjcC1yZWdp c3RyeS9kc2NwLXJlZ2lzdHJ5LnhodG1sDQo+Pj4+Pj4gDQo+Pj4+Pj4gVGhlIGRyYWZ0IGN1cnJl bnRseSBzdWdnZXN0cyB1c2luZyB0aGUgRFNDUCB2YWx1ZSwgJzAwMDAxMCcuDQo+Pj4+PiBJIHRo aW5rIGl0IGlzIERTQ1AgdmFsdWUgMi4NCj4+PiANCj4+Pj4gVGhhdCdzIHR3byBpbmRlZWQ6LSku DQo+Pj4gDQo+Pj4+Pj4gUXVlc3Rpb24gMTogSXMgdGhpcyBjb2RlcG9pbnQgYSBnb29kIGNob2lj ZSBmb3IgdGhlIFRTVldHIGdyb3VwIHRvDQo+Pj4+Pj4gYXNzaWduIGZvciB0aGUgTEUgUEhCPw0K Pj4+Pj4+IA0KPj4+Pj4+ICBUaGluZ3MgdG8gY29uc2lkZXI6DQo+Pj4+Pj4gICAgLSBJcyB0aGUg Y29kZXBvaW50IGN1cnJlbnRseSBiZWluZyB1c2VkIGZvciBvdGhlciAobm9uLXN0YW5kYXJkDQo+ Pj4+Pj4gYXBwbGljYXRpb25zKSB0aGF0IG1heSBnZXQgaW4gdGhlIHdheSBvZiB0aGUgZGVwbG95 bWVudCBvZiB0aGUgTEUgUEhCPw0KPj4+Pj4gQ3VycmVudGx5LCBub3RoaW5nIHNob3VsZCBiZSB1 c2luZyBhIG5vbi1hc3NpZ25lZCBTdGFuZGFyZCBEU0NQLg0KPj4+Pj4gSSByZWFsbHkgZG9uJ3Qg bGlrZSB0aGVzZSBkaXNjdXNzaW9uIGFsb25nIHRoZSBsaW5lcyBvZjogb2gsIHByb2JhYmx5DQo+ Pj4+PiB0aGVyZSBhcmUgc29tZSBzdGFuZGFyZC1pZ25vcmluZyBib3hlcy9hcHBzIG91dCB0aGVy ZSwgc28gbGV0cyB0cnkgdG8NCj4+Pj4+IHdvcmsgYXJvdW5kIHRoZWlyIGJyb2tlbiBkZXNpZ24u IFNvLCB5ZXMsIGl0J3MgcHJvYmFibHkgZ29vZCB0byBrbm93LA0KPj4+Pj4gYnV0IElNSE8gaXQn cyBiZXR0ZXIgdG8gZ2V0IHRoaXMgb3RoZXIgc3R1ZmYgZml4ZWQgcmF0aGVyIHRoYW4gdG8gYWx3 YXlzDQo+Pj4+PiBjcmVhdGUgd29ya2Fyb3VuZC4NCj4+PiANCj4+Pj4gQW5kLCBJIHRoaW5rIGEg bW9yZSB1c2VkZnVsIGRpc3Vjc3Npb24gaGVyZSBpcyBhcm91bmQgLSAid2hhdCBoYXBwZW5zIA0K Pj4+PiB3aGVuIHlvdSB1c2UgZXhpc3RpbmcgY29kZXBvaW50cyB0aGF0IGFyZSBJRVRGLWFwcHJv dmVkLCBhbmQgdGhleSBwYXNzIA0KPj4+PiB0aHJvdWdoIHRoZSBjdXJyZW50IEludGVybmV0IiAt IGRvIHRoZXkgZW1lcmdlIGFzIHRoZSBjb2RlcG9pbnQgeW91IHByb3Bvc2U/DQo+Pj4gDQo+Pj4g U2luY2UgdGhlIGFyY2hpdGVjdHVyZSBhbGxvd3MgKmFueSogcmV3cml0aW5nIHdoYXRldmVyIG9m IHRoZSBEU0NQIHZhbHVlDQo+Pj4gYXQgYSBkb21haW4gYm91bmRhcnksIEknbSBub3QgY2xlYXIg d2h5IGFueSBvZiB0aGlzIGlzIHJlbGV2YW50LiBUaGUgSW50ZXJuZXQNCj4+PiBpc24ndCBzdXBw b3NlZCB0byBiZSB0cmFuc3BhcmVudCB0byBEU0NQIHZhbHVlcywgYW5kIGFsbCBEU0NQIHZhbHVl cyBhcmUNCj4+PiByZWNvbW1lbmRhdGlvbnMgYW55d2F5LiANCj4+PiANCj4+PiBJdCBzZWVtcyB0 byBtZSB0aGF0IFJGQzgxMDAgcmVzb2x2ZXMgdGhlIGlzc3VlIGFib3V0IHdoYXQgaXMgZXhwZWN0 ZWQgdG8NCj4+PiB3b3JrIGFjcm9zcyBkb21haW4gYm91bmRhcmllczsgYWxsIHdlIGFyZSBkb2lu ZyBoZXJlIGlzIGZpeGluZyB0aGUgaGlzdG9yaWNhbA0KPj4+IG1pc3VzZSBvZiBhIGNvZGVwb2lu dC4NCj4+IA0KPj4gRG8geW91IG1lYW4gRFNDUCA4IGJlaW5nIHVzZWQgYnkgTEJFL1NjYXZlbmdl ciBhcyBmYXIgYmFjayBhcyAyMDAyIG9yIHNvPw0KPiANCj4gWWVzLiBJTUhPIHdlIG1hZGUgYSBt aXN0YWtlIHdoZW4gdGhlIHVzZSBvZiBDUzEgZm9yIExFIHdhcyBmaXJzdCBkb2N1bWVudGVkDQo+ IChkcmFmdC1ibGVzcy1kaWZmc2Vydi1wZGItbGUtMDAgaW4gSnVuZSAyMDAyLCBhbmQgSSB3YXMg ZXZlbiBhIGNvLWF1dGhvcg0KPiBvbiB0aGF0IHZlcnNpb24pLiBXZSBzaG91bGQgaGF2ZSBzYWlk IHRoYXQgaXQgd2FzIGEgQmFkIElkZWE7IGluc3RlYWQgd2UNCj4gc2FpZCBpdCB3YXMgImp1c3Rp ZmllZCIgdG8gdmlvbGF0ZSBhIFNIT1VMRCBpbiBSRkMyNDc0Lg0KDQpBIGJpdCBtb290IG5vdywg YnV0IGl0IHdvdWxkIGJlIGludGVyZXN0aW5nIHRvIGtub3cgd2hlcmUgdGhlIGNob2ljZSBvZiBE U0NQIDggZm9yIExCRSBmaXJzdCBvcmlnaW5hdGVkIC0gSSBndWVzcyBmcm9tIHRoZSBRQlNTIHdv cmssIGJ1dCB3ZSBjb3BpZWQgaXQgaW4gdGhlIGludGVyZXN0cyBvZiBpbnRlcm9wZXJhYmlsaXR5 IGFjcm9zcyB0aGUgTlJFTnMgaW4gb3VyIFRGLU5HTiBleHBlcmltZW50cyBpbiBlYXJseSAyMDAy Lg0KDQpIZXJl4oCZcyBhIHNsaWRlIGRlY2sgZnJvbSBTdGFuaXNsYXYgaW4gMjAwMSAtIGh0dHBz Oi8vd3d3LmludGVybmV0Mi5lZHUvcHJlc2VudGF0aW9ucy9DYW1wdXNXb3Jrc2hvcEF0bGFudGEv U2hhbHVub3YtUW9TLUF0bGFudGEucGRmIC0gYnV0IG5vIG1lbnRpb24gb2YgdGhlIENTMSBjb25m bGljdCwgb3IgdGhlIHJlYXNvbiB0byBwaWNrIHRoZSB2YWx1ZSwganVzdCB0aGF0IDAwMTAwMCB3 YXMgYSDigJxzcGVjaWFsIGdsb2JhbCB2YWx1ZeKAnS4gIA0KDQpUaW0NCg0KPiAgICBCcmlhbg0K PiANCj4+PiBTbyAwMDAwMTAgc2VlbXMgbGlrZSBhIHBlcmZlY3RseSBmaW5lIGJpdCBwYXR0ZXJu IHRvIG1lLg0KPj4gDQo+PiBJbmRlZWQuIEl04oCZcyBnb29kIHRvIGhhdmUgc29tZSBkZWZhdWx0 IHZhbHVlIHRoYXQgY2FuIGJlIGFncmVlZCBiZXR3ZWVuIGRvbWFpbnMuDQo+PiANCj4+IFRpbQ0K Pj4gDQo+Pj4gICBCcmlhbg0KPj4+IA0KPj4+Pj4+ICAgIC0gSXMgdGhlcmUgYW50IGV2aWRlbmNl IHRoYXQgdGhpcyBEU0NQIHZhbHVlIGlzIGxlc3MgbGlrZWx5IHRvIGJlDQo+Pj4+Pj4gZm9yd2Fy ZGVkIHRoYW4gb3RoZXIgdW51c2VkIGNvZGVwb2ludHM/DQo+Pj4+Pj4gICAgLSBJcyB0aGlzIGNv ZGVwb2ludCBvYnNlcnZlZCBpbiB0aGUgd2lsZCBkdWUgdG8gY29tbW9uIERTQ1AtbWFuZ2xpbmcN Cj4+Pj4+PiBwYXRob2xvZ2llcyAoc3VjaCBhcyBUb1MtYnl0ZSBibGVhY2hpbmcpPw0KPj4+Pj4+ IA0KPj4+Pj4+IFF1ZXN0aW9uIDI6IElzIHRoZXJlIGFuIGFsdGVybmF0ZSB1bmFzc2lnbmVkIGNv ZGVwaW50IHRoYXQgY291bGQgYmUNCj4+Pj4+PiBjaG9zZW4gdGhhdCB3b3VsZCBnaXZlIGJldHRl ciBvcHByb3R1bml0aWVzIGZvciBkZXBsb3ltZW50Pw0KPj4+Pj4+ICAgIFRoaW5ncyB0byBjb25z aWRlcjoNCj4+Pj4+PiAgICAtIEEgY29kZXBvaW50IGxlc3MgdGhhbiA3IGFwcGVhcnMgdG8gaGF2 ZSBsZXNzIGNoYW5jZSBvZg0KPj4+Pj4+IERTQ1AtbWFuZ2xpbmcgcGF0aG9sb2dpZXMgKHN1Y2gg YXMgVG9TLWJ5dGUgYmxlYWNoaW5nKQ0KPj4+Pj4+ICAgIC0gSUFOQSBjdXJyZW50bHkgYWxsb2Nh dGVzIGZyb20gcG9vbCAxICh4eHh4eDApLCBidXQgd2UgY291bGQNCj4+Pj4+PiBjb25zaWRlciBh c2tpbmcgdG8gdXNlIHBvb2wgMyAoJ3h4eHgwMScpLCBlLmcuLCAnMDAwMDAxJ29yICcwMDAxMDEn Lg0KPj4+Pj4gSSBkb24ndCBzZWUgYW55IGNvbXBlbGxpbmcgcmVhc29uIHRvIHN0YXJ0IHVzaW5n IGFub3RoZXIgcG9vbCByaWdodCBub3cuDQo+Pj4gDQo+Pj4+IERvbid0IHlvdT8gSSB0aGluayB0 aGlzIGRlcGVuZHMgb24gdGhlIG91dGNvbWUuDQo+Pj4gDQo+Pj4+Pj4gTWVhc3VyZW1lbnQgZXhw ZXJpZW5jZSBhbmQgdGhvdWdodHMgb24gdGhpcyB0b3BpYyBhcmUgd2VsY29tZSBvbiB0aGUNCj4+ Pj4+PiBtYWlsaW5nIGxpc3QgYWhlYWQgb2YgdGhlIFRTVldHIG1lZXRpbmcuIEF0IHRoaXMgbWVl dGluZywgSSB3b3VsZCBsaWtlDQo+Pj4+Pj4gdG8gc2VlIHNvbWUgZGlzY3Vzc2lvbiBjb25maXJt aW5nIHRoZSBjaG9pY2Ugb2YgRFNDUCBjb2RlcG9pbnQgb3INCj4+Pj4+PiBzdWdnZXN0aW5nIGEg bW9yZSBhcHByb3ByaWF0ZSBjb2RlcG9pbnQgZm9yIHRoZSB3b3JraW5nIGdyb3VwIHRvIHJlcXVl c3QuDQo+Pj4+PiBUaGFua3MgZm9yIHRyaWdnZXJpbmcgdGhlIGRpc2N1c3Npb24uDQo+Pj4+PiAN Cj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+PiBSb2xhbmQNCj4+Pj4gUm9sYW5kLCBkbyB5b3UgaGF2ZSBh bnkgbWVhc3VyZW1lbnQgZGF0YT8NCj4+Pj4gDQo+Pj4+IEdvcnJ5DQo+Pj4+IA0KPj4+PiANCj4+ PiANCj4+IA0KPiANCg0K From nobody Sun Jul 9 14:53:02 2017 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 81059129B2C for ; Sun, 9 Jul 2017 14:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJBfpbSY9Xra for ; Sun, 9 Jul 2017 14:52:59 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 464F01242F5 for ; Sun, 9 Jul 2017 14:52:58 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1dUK8L-0003s3-Vy; Sun, 09 Jul 2017 23:52:54 +0200 Received: from [IPv6:::1] (localhost [127.0.0.1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id ACC2BB006A0; Sun, 9 Jul 2017 23:52:53 +0200 (CEST) To: Tim Chown , Brian E Carpenter Cc: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" References: <595F4D19.9030502@erg.abdn.ac.uk> <011e5fb5-6c83-bb38-e2cb-7fced2cb774a@kit.edu> <595F6F4F.20005@erg.abdn.ac.uk> <74717821-30ae-203b-197b-2455cbf9d4a3@gmail.com> <66425AFB-A929-4A91-90F8-432F4FAE0520@jisc.ac.uk> From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) Message-ID: Date: Sun, 9 Jul 2017 23:52:53 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 In-Reply-To: <66425AFB-A929-4A91-90F8-432F4FAE0520@jisc.ac.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1499637174.058880518 Archived-At: Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2017 21:53:01 -0000 Hi Tim, On 09.07.2017 at 23:02 Tim Chown wrote: > A bit moot now, but it would be interesting to know where the choice of DSCP 8 for LBE first originated - I guess from the QBSS work, but we copied it in the interests of interoperability across the NRENs in our TF-NGN experiments in early 2002. It think the CS1 proposal came in via this draft here: https://tools.ietf.org/html/draft-ietf-diffserv-pdb-bh-00 I raised my concerns here: https://www.ietf.org/mail-archive/web/diffserv/current/msg02013.html Brian's reply was here: https://www.ietf.org/mail-archive/web/diffserv/current/msg02014.html So basically the IEEE 802.1q used PCP1 as Background class and the idea was probably to do it similarly with the CS codepoints. > Here’s a slide deck from Stanislav in 2001 - https://www.internet2.edu/presentations/CampusWorkshopAtlanta/Shalunov-QoS-Atlanta.pdf - but no mention of the CS1 conflict, or the reason to pick the value, just that 001000 was a “special global valueâ€. Our first proposal (preceding QBSS) https://tools.ietf.org/html/draft-bless-diffserv-lbe-phb-00 used an experimental codepoint. Regards, Roland From nobody Sun Jul 9 16:19:53 2017 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 7919E12EC37 for ; Sun, 9 Jul 2017 16:19:52 -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 9_m5p2TWsh8g for ; Sun, 9 Jul 2017 16:19:50 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::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 BB91F12EC19 for ; Sun, 9 Jul 2017 16:19:50 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id c24so12066044pfe.1 for ; Sun, 09 Jul 2017 16:19:50 -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=HAXRY6+CGIFD1baHkeS5okn88/b//xbBbGVqhFoyG14=; b=NPeFFr9q/ip5jrlxuqhFILkD9q5PhiWUc6RYTj5X1odlFU2Uv1dOrSU/Fo6bAoGNYp mNmQKKG0Js/iCO3ZDBT/anSzWi6fyJHqjFa4TeLPu2BvyLj02axHoau8l9S4DitbN/2I rC8EvtPpc7yBjQ7SxOFlJ5bAQ95RaLPbZ3DZSw2Iy1GgEXeNq/qV+oY9z0zxGKO2DsHe 5IC0x0ba/sJrPgXVPE0f3xU8T8YnI5UGQVRdkFxVx3NupQLAuL7NoIlaEP2XJCEiYlQB bLTeP8c8RyfZaL2lgnLZO3MMWjCMZ+4HHOBKK69kCcH1DMjS7emTwXZ3lJCIjdXOhdT3 vzVQ== 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=HAXRY6+CGIFD1baHkeS5okn88/b//xbBbGVqhFoyG14=; b=LNN/oLLAt5/ea6ukWaT7/WgzVfcc8wgmlzd/NFHeP5ATXK5eIo0lRmRqM382PesfUc cBTN739Dotva6xu0hBFRBFmIe4ILChlpjSQau1zQTny44wgnen2zoOke+DcjSMl6PIUn EcLvU8X7tfCSRmwI0Wa4zBhsisZ3PuHpAlCt3Dzejs+OZeXyTbAwY++6jfBGbiKjl98y ZcFcpomNkUCuFGrOfED1OdPv6ZX0unPU3JfE7kxi8Z1qc+ThjQIF86uC7LGScIvfRFyn 60V5GILtDAMuN+rntYazhHm5q/KdoeOFVxkMTfiGcXoLob2iglq5U2raHYWXjDncKhgb bdsQ== X-Gm-Message-State: AIVw111Owy5a7QVfcTIU47OM9yGYs5lpUDIloj2cl4M3v7c5ZNFmId0S /v1SVBOorN97u4no X-Received: by 10.98.89.129 with SMTP id k1mr42600186pfj.28.1499642390098; Sun, 09 Jul 2017 16:19:50 -0700 (PDT) Received: from [192.168.178.21] ([118.148.76.144]) by smtp.gmail.com with ESMTPSA id b8sm21400514pfd.65.2017.07.09.16.19.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Jul 2017 16:19:48 -0700 (PDT) To: Roland Bless , Tim Chown Cc: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" References: <595F4D19.9030502@erg.abdn.ac.uk> <011e5fb5-6c83-bb38-e2cb-7fced2cb774a@kit.edu> <595F6F4F.20005@erg.abdn.ac.uk> <74717821-30ae-203b-197b-2455cbf9d4a3@gmail.com> <66425AFB-A929-4A91-90F8-432F4FAE0520@jisc.ac.uk> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Mon, 10 Jul 2017 11:19:42 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.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] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2017 23:19:52 -0000 On 10/07/2017 09:52, Roland Bless wrote: > Hi Tim, >=20 > On 09.07.2017 at 23:02 Tim Chown wrote: >> A bit moot now, but it would be interesting to know where the choice o= f DSCP 8 for LBE first originated - I guess from the QBSS work, but we co= pied it in the interests of interoperability across the NRENs in our TF-N= GN experiments in early 2002. >=20 > It think the CS1 proposal came in via this draft here: > https://tools.ietf.org/html/draft-ietf-diffserv-pdb-bh-00 > I raised my concerns here: > https://www.ietf.org/mail-archive/web/diffserv/current/msg02013.html > Brian's reply was here: > https://www.ietf.org/mail-archive/web/diffserv/current/msg02014.html Yes. It was a judgment call, but I now think it was wrong. Brian > So basically the IEEE 802.1q used PCP1 as Background class > and the idea was probably to do it similarly with the CS codepoints. >=20 >> Here=E2=80=99s a slide deck from Stanislav in 2001 - https://www.inter= net2.edu/presentations/CampusWorkshopAtlanta/Shalunov-QoS-Atlanta.pdf - b= ut no mention of the CS1 conflict, or the reason to pick the value, just = that 001000 was a =E2=80=9Cspecial global value=E2=80=9D. =20 >=20 > Our first proposal (preceding QBSS) > https://tools.ietf.org/html/draft-bless-diffserv-lbe-phb-00 > used an experimental codepoint. >=20 > Regards, > Roland >=20 From nobody Mon Jul 10 01:00:34 2017 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 67F8C131678 for ; Mon, 10 Jul 2017 01:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.752 X-Spam-Level: X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 iPMUerR0lA_N for ; Mon, 10 Jul 2017 01:00:27 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 90DF51275AB for ; Mon, 10 Jul 2017 01:00:27 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 2E17C1B17CE3; Mon, 10 Jul 2017 10:54:02 +0100 (BST) Message-ID: <59633402.9020907@erg.abdn.ac.uk> Date: Mon, 10 Jul 2017 09:00:02 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Brian E Carpenter CC: Roland Bless , Tim Chown , "tsvwg@ietf.org" References: <595F4D19.9030502@erg.abdn.ac.uk> <011e5fb5-6c83-bb38-e2cb-7fced2cb774a@kit.edu> <595F6F4F.20005@erg.abdn.ac.uk> <74717821-30ae-203b-197b-2455cbf9d4a3@gmail.com> <66425AFB-A929-4A91-90F8-432F4FAE0520@jisc.ac.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 08:00:32 -0000 When I asked the questions below, I didn't really have in mind a beauty contest, or to identify squating on IANA-allocated DSCP values by others. My concern was more about widely deploying a class that had lower effort, and the implications on being able to work interdomain with traffic not intended not to be "LE". At the moment, any remarking is likely to reduce the class by which traffic is identified, e.g., a network router on path bleaching the DSCP to zero would result in the packet receiving the default PHB treatment for the remainder of its path. This maybe wasn't intended, but to me it's quite OK. If two packets were marked with relative priority (AF21,AF22) etc, it seems likely that both will be remarked to zero, or that the relative priority is preseverved. When we introduce a LE PHB, then any traffic that finally results in the new LE class will receive less than default treatment (we hope!) My concern is whether there are widely deployed pathologies (especially in old equipment) that would result in some codepoints being remarked to the default PHB, while other codepoints get remarked to a LE PHB. This could easily "invert" the relative priority expected by an application, in ways we warned about in the DART work, makring interdomain diffserv support unpredictable. In practice, I have seen there are many pathologies that deployed equipment exhibits - I spoke about some of this in maprg last IETF - e.g., some nodes still implement ToS semantic processing. (This is deprecated!) However, that's not the point, if this remarking is still out there, then we can reaonably expect some packets to be remarked. This seems particularly ugly when we introduce use of a LE codepoint that will actually From what I talked about in maprg, I have a fear that this case could be rather common if we do not take care in selection of the codepoint. I think the WG can data to talk about this. Gorry ---- The draft currently suggests using the DSCP value 2, '000010'. Question 1: Is this codepoint a good choice for the TSVWG group to assign for the LE PHB? Things to consider: - Is the codepoint currently being used for other (non-standard applications) that may get in the way of the deployment of the LE PHB? - Is there ant evidence that this DSCP value is less likely to be forwarded than other unused codepoints? - Is this codepoint observed in the wild due to common DSCP-mangling pathologies (such as ToS-byte bleaching)? Question 2: Is there an alternate unassigned codepint that could be chosen that would give better opprotunities for deployment? Things to consider: - A codepoint less than 7 appears to have less chance of DSCP-mangling pathologies (such as ToS-byte bleaching) - IANA currently allocates from pool 1 (xxxxx0), but we could consider asking to use pool 3 ('xxxx01'), e.g., '000001'or '000101'. Measurement experience and thoughts on this topic are welcome on the mailing list ahead of the TSVWG meeting. At this meeting, I would like to see some discussion confirming the choice of DSCP codepoint or suggesting a more appropriate codepoint for the working group to request. Gorry Fairhurst (TSVWG Co-Chair) When From nobody Mon Jul 10 06:58:20 2017 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 931BB131785; Mon, 10 Jul 2017 06:58:12 -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 6jomJUhevh4J; Mon, 10 Jul 2017 06:58:09 -0700 (PDT) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D728613177E; Mon, 10 Jul 2017 06:58:08 -0700 (PDT) Received: by mail-yb0-x22d.google.com with SMTP id f194so28178188yba.3; Mon, 10 Jul 2017 06:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8iucfKTPUqdehBXnP+z8hZmdqE7s2KYR/QQl3SHwsVM=; b=b/dhUMxWEsUz/FrpGR5uCvh0izBJdoy12iATijwMYpzcU0z7VTTx39n3+KS89wYqa8 XQPOZ9pl/veXF/iddrSemUj2I00sODO0WXxfYkx9TSC1mg1TniVh8Ft/FI/zKXxghiTE w6Q6MJzCLLAzUfFf+H2qHmxU59Xipe/w3rlfdQdDvNV/SB2tWsbPPyKaNJyH3ulT8FDe J479M775eCpw/pEPLR4zSWTI0U15UJbcCRWHr738FowhFDv4+D5DNoxFYjPQHWTtX8gc gucx7PlYp6YlY79Vo91fJo+4amhxqDsdnNWSAPuDId1a0xV7ZmAQssDABajjNa83ur7R 8Ymg== 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=8iucfKTPUqdehBXnP+z8hZmdqE7s2KYR/QQl3SHwsVM=; b=R6LRkF87fnNXrzTSBGcZnMTuX+lSpIY90vGWyzm75Yhhz9YKHzjw4CDWGBcLr+Vk5o 21pLCMPs/p2kz39C6gluf3vSDKzMM6VYwahEiRyHCjaeDWkvcD+KTT2Vyi3WdNhcZcKK Ee7b/18Z4HH9OI6BFiguLuB3eX7qhSAzAjUV/o84fnBcblIEyoKCQm1GudWYs4zh/rQ4 ycRx1AeKL7jK8zmyYj616rDYx5vDNGdGgx2DvdEsfUXGcmpxRX+gNiNc/cc3WENNGGre 0MoQOhugkEfrOrkBIoX236pUX5h23AzmCZDIaZd2Yn6SdlF4RaLt0cBlfnEG9Y40gGtI xqbw== X-Gm-Message-State: AIVw111/AhecNE4r7Cr22uoxipSvm4+A3MkDLtJpV4QW0dIIa5e6ihl0 SZ5nGQfaORYab7CLYS2FJCZBzRHUOg== X-Received: by 10.37.246.18 with SMTP id t18mr15269170ybd.211.1499695087849; Mon, 10 Jul 2017 06:58:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.91.137 with HTTP; Mon, 10 Jul 2017 06:58:06 -0700 (PDT) In-Reply-To: References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> <49200576-B166-4FE9-8B5D-36ECA5509364@erg.abdn.ac.uk> <99989ba2-4dae-eb6e-90fe-cb4b19f20594@bobbriscoe.net> <595BB715.70700@erg.abdn.ac.uk> From: Spencer Dawkins at IETF Date: Mon, 10 Jul 2017 08:58:06 -0500 Message-ID: To: Bob Briscoe Cc: G Fairhurst , tsvwg-chairs , tcpm , tsvwg , tsv-ads , tcpm-chairs Content-Type: multipart/alternative; boundary="f403045da836fb9def0553f6f855" Archived-At: Subject: Re: [tsvwg] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 13:58:13 -0000 --f403045da836fb9def0553f6f855 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Bob, On Fri, Jul 7, 2017 at 9:52 AM, Bob Briscoe wrote: > Spencer, > > Good idea. Except herding WG chairs and ADs to a common space-time > co-ordinate during an IETF is not easy. > How about at AD Office hours? > > on Sunday from 1500 to 1600 in the Istanbul room at IETF 99 > > Two minds, with but a single thought. That works for me. Anyone with a dog in this fight, that it doesn't work for? Spencer > > > Bob > > > On 07/07/17 15:38, Spencer Dawkins at IETF wrote: > > Gorry, since you asked - I don't have an objection to most of the > alternatives presented in this thread. Since we're most/all in Prague Rea= l > Soon Now, I suggest that we have a whiteboard session at an appropriate > break in the action, and make sure we are all on the same page, because > there are several interconnected parts of the discussion. > > Thanks, > > Spencer > > On Tue, Jul 4, 2017 at 10:41 AM, G Fairhurst wrote= : > >> On 04/07/2017, 16:19, Bob Briscoe wrote: >> >>> Gorry, >>> >>> A point I didn't make, but should have done: 2 of the experiments in >>> ecn-experimentation depend on AccECN as a pre-requisite. >>> >> This I realised. >> >>> So it's important not to risk delay to AccECN in an attempt not to dela= y >>> ecn-experimentation. >>> >>> OK - I will take it to the next Chair's meeting. >> >>> Can you give any clue as to which solutions you do or don't favour? >>> Mirja asked me to post this to the lists. I think she was hoping this w= ould >>> reveal all the pros and cons, so a decision could then be made quickly >>> between the chairs/ADs/shepherds/catherds. >>> >>> I will - but need to consult others first. >> >>> >>> Bob >>> >>> Gorry >> >>> On 03/07/17 22:06, Gorry (erg) wrote: >>> >>>> I think as document shepherd I have the input I need, but I need to >>>> talk to my AD about how to handle the process - and liaise with the T= CPM >>>> co-chairs regarding the TCPM WG draft. This isn't the first time we ha= ve >>>> had to look at the implications of making another RFC historic, and I = think >>>> we can do the correct thing. >>>> >>>> Gorry >>>> >>>> On 3 Jul 2017, at 20:17, C. M. Heard >>> heard@pobox.com>> wrote: >>>> >>>> Bob, >>>>> >>>>> I think that your option (f) is better than option (e) (what I >>>>> suggested). As an aside, either one patches up an apparent process >>>>> violation committed by RFC 3540, an experimental RFC that assigned bi= t 7 in >>>>> contradiction to the policy in RFC 2780. >>>>> >>>>> Mike Heard >>>>> >>>>> On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe >>>> > wrote: >>>>> >>>>> Mike, >>>>> >>>>> Let's call this option: >>>>> (e) ecn-experimentation alters the registry policy of bit 7 of >>>>> the TCP header to "IETF Review". >>>>> >>>>> Having a different policy for certain bits within a registry >>>>> might send IANA into a spin, but I am sure they could write >>>>> suitable text into the registry policy if they had to. >>>>> >>>>> I quite like this one. Altho unorthodox, it's neat. >>>>> >>>>> >>>>> Thank you. >>>>> >>>>> >>>>> Bob >>>>> >>>>> PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as >>>>> a 2-bit field during the 3-way hand-shake. While the ECN Nonce >>>>> and AccECN use the three ECN flags (bits 7-9) as a 3-bit field >>>>> during the 3WHS. AccECN uses the combinations that RFC3168 and >>>>> the Nonce do not use. So to cover all bases: >>>>> >>>>> Option (f): ecn-experimentation alters the registry policy for >>>>> bits 7-9 to "IETF Review". >>>>> >>>>> >>>>> On 03/07/17 18:14, C. M. Heard wrote: >>>>> >>>>>> >>>>>> Bob, >>>>>> >>>>>> Couldn't the text in the IANA considerations of >>>>>> ecn-experimentation (which needs to be updated in any case) >>>>>> both change the NS flag to Reserved for ECN Experimentation and >>>>>> change the allocation policy for that flag from Standards >>>>>> Action to IETF Review, thereby updating RFC 2780? That would >>>>>> avoid the churn needed to add motivating text for a 4th >>>>>> experiment to ecn-experimentation and would allow AccECN to >>>>>> assign the NS bit itself without a process exception. >>>>>> >>>>>> Mike Heard >>>>>> >>>>>> On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote: >>>>>> >>>>>> Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, >>>>>> tcpm list, tsvwg list, >>>>>> >>>>>> There has been some offlist discussion (among different >>>>>> sub-groups) to narrow down the options here. It is time to >>>>>> see opinions from the two affected WGs (tcpm and tsvwg) on >>>>>> preferred process, esp. from the WG chairs and ADs. >>>>>> >>>>>> *=3D=3DBackground to the Process Problem=3D=3D** >>>>>> * >>>>>> >>>>>> In tsvwg the process is in motion to make the ECN nonce >>>>>> [RFC 3540] historic. So, in the most recent rev of >>>>>> draft-ietf-tcpm-accurate-ecn-03 , we could finally include >>>>>> IANA assignment of the NS flag >>>>>> (see >>>>>> https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03# >>>>>> section-6 >>>>>> >>>>> #section-6> ) >>>>>> >>>>>> However, AccECN is EXPerimental, whereas the registry >>>>>> policy for assigning TCP flags is "Standards Action" >>>>>> https://www.iana.org/assignments/tcp-header-flags/tcp-header >>>>>> -flags.xhtml >>>>>> >>>>> r-flags.xhtml> >>>>>> which means "Values are assigned only for Standards Track >>>>>> RFCs approved by the IESG" [RFC2434]. >>>>>> >>>>>> References: >>>>>> Process for designating RFCs as historic: >>>>>> https://www.ietf.org/iesg/statement/designating-rfcs-as-hist >>>>>> oric.html >>>>>> >>>>> toric.html> >>>>>> Current draft text to make RFC 3540 historic: >>>>>> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimenta >>>>>> tion-03#section-3 >>>>>> >>>>> ation-03#section-3> >>>>>> My initial draft for the AD's status change note: >>>>>> https://github.com/bbriscoe/ecn-experimentation/blob/master/ >>>>>> status-change-ecn-nonce-rfc3540-to-historic-00.txt >>>>>> >>>>> /status-change-ecn-nonce-rfc3540-to-historic-00.txt> >>>>>> >>>>>> ecn-experimentation has just completed WGLC. It still has >>>>>> to go through IETF LC (after Prague). it is deliberately PS >>>>>> in order to be able to relax pre-existing constraints on >>>>>> ECN experiments in standards track RFCs. However, if poss, >>>>>> we want to avoid adding motivating text for a 4th >>>>>> experiment, which could require another cycle of WGLC and >>>>>> delay until Nov. >>>>>> >>>>>> RFC 3692 ("Assigning Experimental and Testing Numbers >>>>>> Considered Useful") could also be relevant, although it >>>>>> doesn't seem to help here, because it is primarily aimed at >>>>>> larger codepoint spaces, not single bits. >>>>>> >>>>>> >>>>>> *=3D=3DProcess Options=3D=3D** >>>>>> * >>>>>> There need to be two parts to the process: 1) unassignment >>>>>> and 2) reassignment. The first seems clear-cut. The second >>>>>> is less obvious. >>>>>> >>>>>> 1) Unassigning the NS flag from RFC 3540 >>>>>> a) add text to IANA considerations section of >>>>>> ecn-experientation making the NS flag reserved >>>>>> >>>>>> 2) Assigning the NS flag to accurate-ecn (and renaming it >>>>>> the AE flag). >>>>>> Process options: >>>>>> a) ecn-experimentation assigns flag to itself as reserved >>>>>> for experiments and says initially the AccECN experiment >>>>>> will use it exclusively >>>>>> b) ecn-experimentation assigns NS flag exclusively to AccECN >>>>>> c) AccECN assigns NS flag to itself, with a process >>>>>> exception proposed to the IESG to allow an EXP doc to >>>>>> assign to a Standards Action registry >>>>>> d) the NS flag is reassigned by "AD review comment" or >>>>>> "IETF Last Call comment" (quoted from David's suggestions) >>>>>> e) other?... >>>>>> >>>>>> The difference between (a) and (b) is in the document that >>>>>> ends up being referenced from the IANA registry: >>>>>> a) ecn-experimentation >>>>>> b) accurate-ecn >>>>>> >>>>>> *=3D=3DMy own preferences=3D=3D** >>>>>> * >>>>>> During discussions, I didn't prefer (c) cos I thought the >>>>>> IESG might question why they are being asked to make a >>>>>> process exception for an ECN experiment at the same time as >>>>>> a draft is going through that avoids raising process >>>>>> exceptions for ECN experiments. >>>>>> >>>>>> Nonetheless, since then, Mirja has said... >>>>>> >>>>>> On 02/07/17 23:40, Mirja K=C3=BChlewind wrote: >>>>>> >>>>>>> I actually prefer option (c). I don=E2=80=99t think a proce= ss >>>>>>> exception is a bad thing. If it=E2=80=99s the right thing to do, th= en that the >>>>>>> reason why we have such exceptions. Also I think it=E2=80=99d be th= e right thing to >>>>>>> change the registry policy=E2=80=A6 but that probably a longer stor= y. >>>>>>> >>>>>> I agree that it is outdated that the registry requires a >>>>>> standards action, because it has become normal tcpm >>>>>> practice for any change to TCP to have to start on the >>>>>> experimental track. So this would justify a process exceptio= n. >>>>>> >>>>>> So, in summary, I don't mind (a), (b) or (c). I think (d) >>>>>> is not sufficiently open and recorded for assignment of a >>>>>> flag in the main TCP header. >>>>>> >>>>>> >>>>>> Bob >>>>>> >>>>>> >>>>> -- __________________________________________________________= _ >>>>> _____ >>>>> Bob Briscoehttp://bobbriscoe.net/ >>>>> >>>>> >>>>> >>> -- >>> ________________________________________________________________ >>> Bob Briscoehttp://bobbriscoe.net/ >>> >> >> > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > --f403045da836fb9def0553f6f855 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Bob,

On Fri, Jul 7, 2017 at 9:52 AM, Bob Briscoe <<= a href=3D"mailto:ietf@bobbriscoe.net" target=3D"_blank">ietf@bobbriscoe.net= > wrote:
=20 =20 =20
Spencer,

Good idea. Except herding WG chairs and ADs to a common space-time co-ordinate during an IETF is not easy.
How about at AD Office hours?
on Sunday from 1500 to 1600 in the Istanbul room at IETF 99
Two minds, with b= ut a single thought.

That works for me. Anyone wit= h a dog in this fight, that it doesn't work for?

Spencer
=C2=A0


Bob


On 07/07/17 15:38,= Spencer Dawkins at IETF wrote:
Gorry, since you asked - I don't have an objecti= on to most of the alternatives presented in this thread. Since we're most/all in Prague Real Soon Now, I suggest that we have = a whiteboard session at an appropriate break in the action, and make sure we are all on the same page, because there are several interconnected parts of the discussion.

Thanks,

Spencer

On Tue, Jul 4, 2017 at 10:41 AM, G Fairhurst <gorry@erg.abdn.ac.uk> wrote:
On 04/07/2017, 16:19, Bob = Briscoe wrote:
Gorry,

A point I didn't make, but should have done: 2 of the experiments in ecn-experimentation depend on AccECN as a pre-requisite.
This I realised.
So it's important not to risk delay to AccECN in an attempt not to delay ecn-experimentation.

 OK - I will take it to the next Chair's meeting.
Can you give any clue as to which solutions you do or don't favour? Mirja asked me to post this to the lists. I think she was hoping this would reveal all the pros and cons, so a decision could then be made quickly between the chairs/ADs/shepherds/catherds.

 I will - but need to consult others first.

Bob

Gorry
On 03/07/17 22:06, Gorry (erg) wrote:
I think as document shepherd I have the input I need, but I need to talk to my AD about how to handle the process=C2=A0 - and liaise with the TCPM co-chairs regarding the TCPM WG draft. This isn't the first time we have had to look at the implications of making another RFC historic, and I think we can do the correct thing.

Gorry

 On 3 Jul 2017, at 20:17, C. M. Heard <heard@pobox.com <mailto:heard@pobox.com>> wrote:
Bob,

I think that your option (f) is better than option (e) (what I suggested). As an aside, either one patches up an apparent process violation committed by RFC 3540, an experimental RFC that assigned bit 7 in contradiction to the policy in RFC 2780.

Mike Heard
On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe <ietf@bobbriscoe.net <mailto:ietf@bobbriscoe.net>> wrote:

=C2=A0 =C2=A0 Mike,

=C2=A0 =C2=A0 Let's call this option:
=C2=A0 =C2=A0 (e) ecn-experimentation alters the re= gistry policy of bit 7 of
=C2=A0 =C2=A0 the TCP header to "IETF Review&q= uot;.

=C2=A0 =C2=A0 Having a different policy for certain= bits within a registry
=C2=A0 =C2=A0 might send IANA into a spin, but I am= sure they could write
=C2=A0 =C2=A0 suitable text into the registry polic= y if they had to.

=C2=A0 =C2=A0 I quite like this one. Altho unorthod= ox, it's neat.


=C2=A0 =C2=A0 Thank you.


=C2=A0 =C2=A0 Bob

=C2=A0 =C2=A0 PS. Strictly RFC3168 used the CWR and= ECE flags (bits 8 & 9) as
=C2=A0 =C2=A0 a 2-bit field during the 3-way hand-s= hake. While the ECN Nonce
=C2=A0 =C2=A0 and AccECN use the three ECN flags (b= its 7-9) as a 3-bit field
=C2=A0 =C2=A0 during the 3WHS. AccECN uses the combinations that RFC3168 and
=C2=A0 =C2=A0 the Nonce do not use. So to cover all= bases:

=C2=A0 =C2=A0 Option (f): ecn-experimentation alter= s the registry policy for
=C2=A0 =C2=A0 bits 7-9 to "IETF Review".<= br>

=C2=A0 =C2=A0 On 03/07/17 18:14, C. M. Heard wrote:=

=C2=A0 =C2=A0 Bob,

=C2=A0 =C2=A0 Couldn't the text in the IANA considerations of
=C2=A0 =C2=A0 ecn-experimentation (which needs to= be updated in any case)
=C2=A0 =C2=A0 both change the NS flag to Reserved= for ECN Experimentation and
=C2=A0 =C2=A0 change the allocation policy for th= at flag from Standards
=C2=A0 =C2=A0 Action to IETF Review, thereby upda= ting RFC 2780? That would
=C2=A0 =C2=A0 avoid the churn needed to add motiv= ating text for a 4th
=C2=A0 =C2=A0 experiment to ecn-experimentation a= nd would allow AccECN to
=C2=A0 =C2=A0 assign the NS bit itself without a = process exception.

=C2=A0 =C2=A0 Mike Heard

=C2=A0 =C2=A0 On Mon, 3 Jul 2017 10:28:25 +0100, = Bob Briscoe wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Michael*2, Yoshifumi,= Gorry, David, Wes, Mirja, Spencer,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 tcpm list, tsvwg list= ,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 There has been some o= fflist discussion (among different
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sub-groups) to narrow= down the options here. It is time to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 see opinions from the= two affected WGs (tcpm and tsvwg) on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 preferred process, es= p. from the WG chairs and ADs.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=3D=3DBackground to the = Process Problem=3D=3D**
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *

=C2=A0 =C2=A0 =C2=A0 =C2=A0 In tsvwg the process = is in motion to make the ECN nonce
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [RFC 3540] historic. = So, in the most recent rev of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-tcpm-accur= ate-ecn-03 , we could finally include
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IANA assignment of th= e NS flag
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (see =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://tools.ietf.org/html/draft-ietf-tcpm-acc= urate-ecn-03#section-6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://tools.ietf.org/html/draft-ietf-tcpm= -accurate-ecn-03#section-6> )

=C2=A0 =C2=A0 =C2=A0 =C2=A0 However, AccECN is EX= Perimental, whereas the registry
=C2=A0 =C2=A0 =C2=A0 =C2=A0 policy for assigning = TCP flags is "Standards Action"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.iana.org/assignments/tcp-header-= flags/tcp-header-flags.xhtml
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.iana.org/assignments/tcp-hea= der-flags/tcp-header-flags.xhtml>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 which means "Val= ues are assigned only for Standards Track
=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFCs approved by the = IESG" [RFC2434].

=C2=A0 =C2=A0 =C2=A0 =C2=A0 References:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Process= for designating RFCs as historic:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/iesg/statement/designating= -rfcs-as-historic.html
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/iesg/statement/designa= ting-rfcs-as-historic.html>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Current= draft text to make RFC 3540 historic:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://tools.ietf.org/html/draft-ietf-= tsvwg-ecn-experimentation-03#section-3
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://tools.ietf.org/html/draft-i= etf-tsvwg-ecn-experimentation-03#section-3>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 My init= ial draft for the AD's status change note:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://git= hub.com/bbriscoe/ecn-experimentation/blob/master/status-change-ec= n-nonce-rfc3540-to-historic-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https:/= /github.com/bbriscoe/ecn-experimentation/blob/master/status-chang= e-ecn-nonce-rfc3540-to-historic-00.txt>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ecn-experimentation h= as just completed WGLC. It still has
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to go through IETF LC= (after Prague). it is deliberately PS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 in order to be able t= o relax pre-existing constraints on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ECN experiments in st= andards track RFCs. However, if poss,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 we want to avoid addi= ng motivating text for a 4th
=C2=A0 =C2=A0 =C2=A0 =C2=A0 experiment, which cou= ld require another cycle of WGLC and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 delay until Nov.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 3692 ("Assig= ning Experimental and Testing Numbers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Considered Useful&quo= t;) could also be relevant, although it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 doesn't seem to h= elp here, because it is primarily aimed at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 larger codepoint spac= es, not single bits.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=3D=3DProcess Options=3D= =3D**
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *
=C2=A0 =C2=A0 =C2=A0 =C2=A0 There need to be two pa= rts to the process: 1) unassignment
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and 2) reassignment. Th= e first seems clear-cut. The second
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is less obvious.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 1) Unassigning the NS f= lag from RFC 3540
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a) add text to IANA con= siderations section of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ecn-experientation maki= ng the NS flag reserved

=C2=A0 =C2=A0 =C2=A0 =C2=A0 2) Assigning the NS fla= g to accurate-ecn (and renaming it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the AE flag).
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Process options:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a) ecn-experimentation = assigns flag to itself as reserved
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for experiments and say= s initially the AccECN experiment
=C2=A0 =C2=A0 =C2=A0 =C2=A0 will use it exclusively=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b) ecn-experimentation = assigns NS flag exclusively to AccECN
=C2=A0 =C2=A0 =C2=A0 =C2=A0 c) AccECN assigns NS fl= ag to itself, with a process
=C2=A0 =C2=A0 =C2=A0 =C2=A0 exception proposed to t= he IESG to allow an EXP doc to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 assign to a Standards A= ction registry
=C2=A0 =C2=A0 =C2=A0 =C2=A0 d) the NS flag is reass= igned by "AD review comment" or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "IETF Last Call co= mment" (quoted from David's suggestions)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 e) other?...

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The difference between = (a) and (b) is in the document that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ends up being reference= d from the IANA registry:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a)=C2=A0 ecn-experiment= ation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b) accurate-ecn

 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *=3D=3DMy own preferences= =3D=3D**
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *
=C2=A0 =C2=A0 =C2=A0 =C2=A0 During discussions, I d= idn't prefer (c) cos I thought the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IESG might question why= they are being asked to make a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 process exception for a= n ECN experiment at the same time as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a draft is going throug= h that avoids raising process
=C2=A0 =C2=A0 =C2=A0 =C2=A0 exceptions for ECN expe= riments.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Nonetheless, since then= , Mirja has said...

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On 02/07/17 23:40, Mirj= a K=C3=BChlewind wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I actually prefer opt= ion (c). I don=E2=80=99t think a process exception is a bad thing. If it=E2=80=99s the right thing to do, then that the reason why we have such exceptions. Also I think it=E2=80=99d be the right thing to change t= he registry policy=E2=80=A6 but that probably a long= er story.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I agree that it is outd= ated that the registry requires a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 standards action, becau= se it has become normal tcpm
=C2=A0 =C2=A0 =C2=A0 =C2=A0 practice for any change= to TCP to have to start on the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 experimental track. So = this would justify a process exception.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 So, in summary, I don&#= 39;t mind (a), (b) or (c). I think (d)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is not sufficiently ope= n and recorded for assignment of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 flag in the main TCP he= ader.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Bob


=C2=A0 =C2=A0 --=C2=A0 =C2=A0 =C2=A0___________________= _____________________________________________
=C2=A0 =C2=A0 Bob Briscoehttp://bobbriscoe.net/



--
____________________________________________________= ____________
Bob Briscoehttp://bobbriscoe.net/



--=20
________________________________________________________________
Bob Briscoe                               h=
ttp://bobbriscoe.net/

--f403045da836fb9def0553f6f855-- From nobody Mon Jul 10 09:11:59 2017 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 0A27A1317D8 for ; Mon, 10 Jul 2017 09:11:55 -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] 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 F7FMj8qfXGCc for ; Mon, 10 Jul 2017 09:11:52 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 E9B521317D5 for ; Mon, 10 Jul 2017 09:11:47 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1dUbHm-0002Ac-2z; Mon, 10 Jul 2017 18:11:46 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 04F59B01439; Mon, 10 Jul 2017 18:11:46 +0200 (CEST) To: gorry@erg.abdn.ac.uk Cc: tsvwg@ietf.org References: <595F4D19.9030502@erg.abdn.ac.uk> <011e5fb5-6c83-bb38-e2cb-7fced2cb774a@kit.edu> <595F6F4F.20005@erg.abdn.ac.uk> From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: Date: Mon, 10 Jul 2017 18:11:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <595F6F4F.20005@erg.abdn.ac.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1499703106.132311686 Archived-At: Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 16:11:55 -0000 Hi Gorry, Am 07.07.2017 um 13:23 schrieb Gorry Fairhurst: > Roland, do you have any measurement data? Unfortunately not. Regards, Roland From nobody Mon Jul 10 13:36:17 2017 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 19E351318A9 for ; Mon, 10 Jul 2017 13:36:15 -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 yOh_TbUTOrRj for ; Mon, 10 Jul 2017 13:36:13 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e: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 1194512F24E for ; Mon, 10 Jul 2017 13:36:13 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id k14so55215933pgr.0 for ; Mon, 10 Jul 2017 13:36:13 -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=/xKut4kdtFP2wRW56BgnUOklJx6g7p75WoB+IYOE8go=; b=HuE5KCiCoP4sN/5kIM4H8kKFV2ii1oJPNgLteEhn/4I1Ztk3eUlKMLp9RBefYVYWka 3ulKLGCWda8+AqCmIxKDy01HQGTQBqprmKPQ5aQKbdUBGOXSko8knB8/RUjujLFDH3xZ OtiD1vDnLjhKcoeDpPjxVMXx56KMoE4pC6Nuc16aLeXKZnsPRJIELSEln/8MgiivcXNS gi6SRTVp18soOhALaDancgQVHENgcOa1NE4PWc7p8tE9cmwJ7oCh6zZufYtPEhw9LqL/ C3GEzYRB9hEKmEQWgqOx40dtbHBS4yrQV8DalViz8si569xxirle8uRjUgnooc/75hvc DLXw== 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=/xKut4kdtFP2wRW56BgnUOklJx6g7p75WoB+IYOE8go=; b=Tbr8WvyFMCZ8iylRZFroKO/vuq0MvODA/3AFEcI7JG7Begpij1zTaii+lKwaz1gEiM 0PvvfXlHb3RgAe/5Pm0Zi6rpao0haGvYZzPv+KWzOY9fksi+jH0ozzpzubwXQMT4sw7K IUNZdPBnWbqgsKDiP/IOYjvA7jjlL0QgIweaxdFi5L14vdH3LSmLedcVIo7ZISITAv8D LE0jWYErLKyHNt661EMmsPLq7CkwZR/wqHR5PPTpZ+ms4gRhbrkc6X/onfkV5ga9Pv9g NT3aX1+cgM67wKn1qmFbudpYa1jn+dmf0mz4nEQ0xYkH9+mHyIYlriBeEP3sDC8yKaIi k0mQ== X-Gm-Message-State: AIVw110bBdBCmkNQ+wF+aE5x96HwWrGsrdhXgKOPzqV/vxnYnG9+x5RE M5dmLNsexstM54a3 X-Received: by 10.101.76.140 with SMTP id m12mr16200220pgt.159.1499718972371; Mon, 10 Jul 2017 13:36:12 -0700 (PDT) Received: from [192.168.178.21] ([118.148.76.144]) by smtp.gmail.com with ESMTPSA id d70sm32280174pga.49.2017.07.10.13.36.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jul 2017 13:36:11 -0700 (PDT) To: gorry@erg.abdn.ac.uk Cc: Roland Bless , "tsvwg@ietf.org" References: <595F4D19.9030502@erg.abdn.ac.uk> <011e5fb5-6c83-bb38-e2cb-7fced2cb774a@kit.edu> <595F6F4F.20005@erg.abdn.ac.uk> <74717821-30ae-203b-197b-2455cbf9d4a3@gmail.com> <66425AFB-A929-4A91-90F8-432F4FAE0520@jisc.ac.uk> <59633402.9020907@erg.abdn.ac.uk> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 11 Jul 2017 08:36:08 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <59633402.9020907@erg.abdn.ac.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 20:36:15 -0000 > makring interdomain diffserv support unpredictable. That is the whole point, really. Interdomain diffserv support *is* unpredictable, more or less by definition, unless there is an SLA in place between the domains that defines what happens to packets with specific markings as they cross the border. "We agree to follow RFC8100" might be a minimal SLA. But absent that, there is very little we can say. I'm not aware of any measurement data that would help, unfortunately. Regards Brian On 10/07/2017 20:00, Gorry Fairhurst wrote: > When I asked the questions below, I didn't really have in mind a beauty > contest, or to identify squating on IANA-allocated DSCP values by > others. My concern was more about widely deploying a class that had > lower effort, and the implications on being able to work interdomain > with traffic not intended not to be "LE". > > At the moment, any remarking is likely to reduce the class by which > traffic is identified, e.g., a network router on path bleaching the DSCP > to zero would result in the packet receiving the default PHB treatment > for the remainder of its path. This maybe wasn't intended, but to me > it's quite OK. If two packets were marked with relative priority > (AF21,AF22) etc, it seems likely that both will be remarked to zero, or > that the relative priority is preseverved. > > When we introduce a LE PHB, then any traffic that finally results in the > new LE class will receive less than default treatment (we hope!) My > concern is whether there are widely deployed pathologies (especially in > old equipment) that would result in some codepoints being remarked to > the default PHB, while other codepoints get remarked to a LE PHB. This > could easily "invert" the relative priority expected by an application, > in ways we warned about in the DART work, makring interdomain diffserv > support unpredictable. > > In practice, I have seen there are many pathologies that deployed > equipment exhibits - I spoke about some of this in maprg last IETF - > e.g., some nodes still implement ToS semantic processing. (This is > deprecated!) However, that's not the point, if this remarking is still > out there, then we can reaonably expect some packets to be remarked. > This seems particularly ugly when we introduce use of a LE codepoint > that will actually From what I talked about in maprg, I have a fear that > this case could be rather common if we do not take care in selection of > the codepoint. I think the WG can data to talk about this. > > Gorry > > ---- > > The draft currently suggests using the DSCP value 2, '000010'. > > Question 1: Is this codepoint a good choice for the TSVWG group to > assign for the LE PHB? > > Things to consider: > - Is the codepoint currently being used for other (non-standard > applications) that may get in the way of the deployment of the LE PHB? > - Is there ant evidence that this DSCP value is less likely to be > forwarded than other unused codepoints? > - Is this codepoint observed in the wild due to common > DSCP-mangling pathologies (such as ToS-byte bleaching)? > > Question 2: Is there an alternate unassigned codepint that could be > chosen that would give better opprotunities for deployment? > > Things to consider: > - A codepoint less than 7 appears to have less chance of > DSCP-mangling pathologies (such as ToS-byte bleaching) > - IANA currently allocates from pool 1 (xxxxx0), but we could > consider asking to use pool 3 ('xxxx01'), e.g., '000001'or '000101'. > > Measurement experience and thoughts on this topic are welcome on the > mailing list ahead of the TSVWG meeting. At this meeting, I would like > to see some discussion confirming the choice of DSCP codepoint or > suggesting a more appropriate codepoint for the working group to request. > > Gorry Fairhurst > (TSVWG Co-Chair) > > When > From nobody Mon Jul 10 16:15:11 2017 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 A5496131940; Mon, 10 Jul 2017 16:15: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, MIME_QP_LONG_LINE=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 F0lW6giAkOD0; Mon, 10 Jul 2017 16:15:08 -0700 (PDT) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (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 DE30813193D; Mon, 10 Jul 2017 16:15:07 -0700 (PDT) Received: by mail-pf0-x243.google.com with SMTP id e199so16356491pfh.0; Mon, 10 Jul 2017 16:15:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ehSJJbXJwRRK7iCGkYoehVGY/l7n46s3p/Ddk44RjCE=; b=q0oFqaKNJIX7VrOhES1oGPpMpoNrfBcdzKVxU54yMIHsi6/554GN5rekkuUQaY2bCe hqG8SZHPODPAMbABUFF9QRsSC/MzqUZGSfXmBDBoWzSRjw8OWAtZ6fWsXIfwlk1iEV2l +z9bFgTkyJ9INyMmsDPOzNyn9hMmzITMcyUDp1da4S9j7B0+xxyyN6d+AJ2rgBA/U/9i gBm0hUCipaitPOpf4iTkHs5PdFMB0tLh0viESN6cHXcxVooouFtKkD0U6eJ5asdcH7bA gyoMgaQ6xGLe8uR5N3r0xlxnvv3oWgUhuO2HR3lCTHQIttG9rJz6lXx7Y3LnbFTJerPc qFog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ehSJJbXJwRRK7iCGkYoehVGY/l7n46s3p/Ddk44RjCE=; b=ELEbabnMRd0ZKHLBEOGgaVL7iTrIkhniGcyuyipmp1VeLVQ1/DPtj1f6cLwH8kRaNH FcQJh9FecjTCAXLKqnwO1Yx+F/2/tar7QgP8RXjxrKG5EXs5rtPu3I0N/EjKT5aB3i/X GJLpauRfqmpixe+Z24aGWQgxK/x9a6UuYLsvCl1t6Xig8/eocVeR7g9igdr0gUIpe/GI 5WXaQyShxkVWnsQoVChfAzf3q5wkwADl++IBTnrWNR04HE6mt7Ic5x3l57Hdt3NWwZAp vDCuZin/1vVPXcRwLUpQco9FZ2BfxgDwI7O0w7Vi9rb1PukM3t3WxQVw3n/TAEHd1+/0 HFFA== X-Gm-Message-State: AIVw111uTG6tYUSCyshFGwPmFv/kewlqVKeFcTJ+4Aa8RcJripry2WE6 zU0UGPFnEF581KQDowM= X-Received: by 10.99.100.193 with SMTP id y184mr17220595pgb.211.1499728507240; Mon, 10 Jul 2017 16:15:07 -0700 (PDT) Received: from ?IPv6:2601:646:c005:a10:783f:b5a4:a97e:82c8? ([2601:646:c005:a10:783f:b5a4:a97e:82c8]) by smtp.gmail.com with ESMTPSA id s80sm27466650pfj.33.2017.07.10.16.15.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jul 2017 16:15:06 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-A4E940A2-48EF-4272-9014-91E08FD90B3A Mime-Version: 1.0 (1.0) From: Fred Baker X-Mailer: iPhone Mail (14G5057a) In-Reply-To: Date: Mon, 10 Jul 2017 16:15:05 -0700 Cc: Bob Briscoe , G Fairhurst , tcpm , tsvwg , tsvwg-chairs , tsv-ads , tcpm-chairs Content-Transfer-Encoding: 7bit Message-Id: References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> <49200576-B166-4FE9-8B5D-36ECA5509364@erg.abdn.ac.uk> <99989ba2-4dae-eb6e-90fe-cb4b19f20594@bobbriscoe.net> <595BB715.70700@erg.abdn.ac.uk> To: Spencer Dawkins at IETF Archived-At: Subject: Re: [tsvwg] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 23:15:11 -0000 --Apple-Mail-A4E940A2-48EF-4272-9014-91E08FD90B3A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Wednesday lunch? Sent using a machine that autocorrects in interesting ways... > On Jul 10, 2017, at 6:58 AM, Spencer Dawkins at IETF wrote: >=20 > Hi, Bob, >=20 >> On Fri, Jul 7, 2017 at 9:52 AM, Bob Briscoe wrote: >> Spencer, >>=20 >> Good idea. Except herding WG chairs and ADs to a common space-time co-ord= inate during an IETF is not easy.=20 >> How about at AD Office hours? >>> on Sunday from 1500 to 1600 in the Istanbul room at IETF 99 > Two minds, with but a single thought. >=20 > That works for me. Anyone with a dog in this fight, that it doesn't work f= or? >=20 > Spencer > =20 >>=20 >>=20 >> Bob >>=20 >>=20 >>> On 07/07/17 15:38, Spencer Dawkins at IETF wrote: >>> Gorry, since you asked - I don't have an objection to most of the altern= atives presented in this thread. Since we're most/all in Prague Real Soon No= w, I suggest that we have a whiteboard session at an appropriate break in th= e action, and make sure we are all on the same page, because there are sever= al interconnected parts of the discussion. >>>=20 >>> Thanks, >>>=20 >>> Spencer >>>=20 >>>> On Tue, Jul 4, 2017 at 10:41 AM, G Fairhurst wro= te: >>>>> On 04/07/2017, 16:19, Bob Briscoe wrote: >>>>> Gorry, >>>>>=20 >>>>> A point I didn't make, but should have done: 2 of the experiments in e= cn-experimentation depend on AccECN as a pre-requisite.=20 >>>> This I realised. >>>>> So it's important not to risk delay to AccECN in an attempt not to del= ay ecn-experimentation. >>>>>=20 >>>> OK - I will take it to the next Chair's meeting. >>>>> Can you give any clue as to which solutions you do or don't favour? Mi= rja asked me to post this to the lists. I think she was hoping this would re= veal all the pros and cons, so a decision could then be made quickly between= the chairs/ADs/shepherds/catherds. >>>>>=20 >>>> I will - but need to consult others first. >>>>>=20 >>>>> Bob >>>>>=20 >>>> Gorry >>>>>> On 03/07/17 22:06, Gorry (erg) wrote: >>>>>> I think as document shepherd I have the input I need, but I need to t= alk to my AD about how to handle the process - and liaise with the TCPM co-= chairs regarding the TCPM WG draft. This isn't the first time we have had to= look at the implications of making another RFC historic, and I think we can= do the correct thing. >>>>>>=20 >>>>>> Gorry >>>>>>=20 >>>>>> On 3 Jul 2017, at 20:17, C. M. Heard > wrote: >>>>>>=20 >>>>>>> Bob, >>>>>>>=20 >>>>>>> I think that your option (f) is better than option (e) (what I sugge= sted). As an aside, either one patches up an apparent process violation comm= itted by RFC 3540, an experimental RFC that assigned bit 7 in contradiction t= o the policy in RFC 2780. >>>>>>>=20 >>>>>>> Mike Heard >>>>>>>=20 >>>>>>> On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe > wrote: >>>>>>>=20 >>>>>>> Mike, >>>>>>>=20 >>>>>>> Let's call this option: >>>>>>> (e) ecn-experimentation alters the registry policy of bit 7 of >>>>>>> the TCP header to "IETF Review". >>>>>>>=20 >>>>>>> Having a different policy for certain bits within a registry >>>>>>> might send IANA into a spin, but I am sure they could write >>>>>>> suitable text into the registry policy if they had to. >>>>>>>=20 >>>>>>> I quite like this one. Altho unorthodox, it's neat. >>>>>>>=20 >>>>>>>=20 >>>>>>> Thank you. >>>>>>>=20 >>>>>>>=20 >>>>>>> Bob >>>>>>>=20 >>>>>>> PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as >>>>>>> a 2-bit field during the 3-way hand-shake. While the ECN Nonce >>>>>>> and AccECN use the three ECN flags (bits 7-9) as a 3-bit field >>>>>>> during the 3WHS. AccECN uses the combinations that RFC3168 and >>>>>>> the Nonce do not use. So to cover all bases: >>>>>>>=20 >>>>>>> Option (f): ecn-experimentation alters the registry policy for >>>>>>> bits 7-9 to "IETF Review". >>>>>>>=20 >>>>>>>=20 >>>>>>> On 03/07/17 18:14, C. M. Heard wrote: >>>>>>>>=20 >>>>>>>> Bob, >>>>>>>>=20 >>>>>>>> Couldn't the text in the IANA considerations of >>>>>>>> ecn-experimentation (which needs to be updated in any case) >>>>>>>> both change the NS flag to Reserved for ECN Experimentation and= >>>>>>>> change the allocation policy for that flag from Standards >>>>>>>> Action to IETF Review, thereby updating RFC 2780? That would >>>>>>>> avoid the churn needed to add motivating text for a 4th >>>>>>>> experiment to ecn-experimentation and would allow AccECN to >>>>>>>> assign the NS bit itself without a process exception. >>>>>>>>=20 >>>>>>>> Mike Heard >>>>>>>>=20 >>>>>>>> On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote: >>>>>>>>=20 >>>>>>>> Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, >>>>>>>> tcpm list, tsvwg list, >>>>>>>>=20 >>>>>>>> There has been some offlist discussion (among different >>>>>>>> sub-groups) to narrow down the options here. It is time to >>>>>>>> see opinions from the two affected WGs (tcpm and tsvwg) on >>>>>>>> preferred process, esp. from the WG chairs and ADs. >>>>>>>>=20 >>>>>>>> *=3D=3DBackground to the Process Problem=3D=3D** >>>>>>>> * >>>>>>>>=20 >>>>>>>> In tsvwg the process is in motion to make the ECN nonce >>>>>>>> [RFC 3540] historic. So, in the most recent rev of >>>>>>>> draft-ietf-tcpm-accurate-ecn-03 , = we could finally include >>>>>>>> IANA assignment of the NS flag >>>>>>>> (see >>>>>>>> https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03= #section-6 >>>>>>>> ) >>>>>>>>=20 >>>>>>>> However, AccECN is EXPerimental, w= hereas the registry >>>>>>>> policy for assigning TCP flags is "Standards Action" >>>>>>>> https://www.iana.org/assignments/tcp-header-flags/tcp-heade= r-flags.xhtml >>>>>>>> >>>>>>>> which means "Values are assigned only for Standards Track >>>>>>>> RFCs approved by the IESG" [RFC2434]. >>>>>>>>=20 >>>>>>>> References: >>>>>>>> Process for designating RFCs as = historic: >>>>>>>> https://www.ietf.org/iesg/statement/designating-rfcs-as-his= toric.html >>>>>>>> >>>>>>>> Current draft text to make RFC 3540 historic: >>>>>>>> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experiment= ation-03#section-3 >>>>>>>> >>>>>>>> My initial draft for the AD's status change note: >>>>>>>> https://github.com/bbriscoe/ecn-experimentation/blob/master= /status-change-ecn-nonce-rfc3540-to-historic-00.txt >>>>>>>> >>>>>>>>=20 >>>>>>>> ecn-experimentation has just completed WGLC. It still has >>>>>>>> to go through IETF LC (after Prague). it is deliberately PS= >>>>>>>> in order to be able to relax pre-existing constraints on >>>>>>>> ECN experiments in standards track RFCs. However, if poss, >>>>>>>> we want to avoid adding motivating text for a 4th >>>>>>>> experiment, which could require another cycle of WGLC and >>>>>>>> delay until Nov. >>>>>>>>=20 >>>>>>>> RFC 3692 ("Assigning Experimental and Testing Numbers >>>>>>>> Considered Useful") could also be relevant, although it >>>>>>>> doesn't seem to help here, because it is primarily aimed at= >>>>>>>> larger codepoint spaces, not single bits. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> *=3D=3DProcess Options=3D=3D** >>>>>>>> * >>>>>>>> There need to be two parts to the process: 1) unassignment >>>>>>>> and 2) reassignment. The first seems clear-cut. The second >>>>>>>> is less obvious. >>>>>>>>=20 >>>>>>>> 1) Unassigning the NS flag from RFC 3540 >>>>>>>> a) add text to IANA considerations section of >>>>>>>> ecn-experientation making the NS flag reserved >>>>>>>>=20 >>>>>>>> 2) Assigning the NS flag to accurate-ecn (and renaming it >>>>>>>> the AE flag). >>>>>>>> Process options: >>>>>>>> a) ecn-experimentation assigns flag to itself as reserved >>>>>>>> for experiments and says initially the AccECN experiment >>>>>>>> will use it exclusively >>>>>>>> b) ecn-experimentation assigns NS flag exclusively to AccEC= N >>>>>>>> c) AccECN assigns NS flag to itself, with a process >>>>>>>> exception proposed to the IESG to allow an EXP doc to >>>>>>>> assign to a Standards Action registry >>>>>>>> d) the NS flag is reassigned by "AD = review comment" or >>>>>>>> "IETF Last Call comment" (quoted from David's suggestions) >>>>>>>> e) other?... >>>>>>>>=20 >>>>>>>> The difference between (a) and (b) is in the document that >>>>>>>> ends up being referenced from the IANA registry: >>>>>>>> a) ecn-experimentation >>>>>>>> b) accurate-ecn >>>>>>>>=20 >>>>>>>> *=3D=3DMy own preferences=3D=3D** >>>>>>>> * >>>>>>>> During discussions, I didn't prefer (c) cos I thought the >>>>>>>> IESG might question why they are being asked to make a >>>>>>>> process exception for an ECN experiment at the same time as= >>>>>>>> a draft is going through that avoids raising process >>>>>>>> exceptions for ECN experiments. >>>>>>>>=20 >>>>>>>> Nonetheless, since then, Mirja has s= aid... >>>>>>>>=20 >>>>>>>>> On 02/07/17 23:40, Mirja K=C3=BChlewind wrote: >>>>>>>>> I actually prefer option (c). I don=E2=80=99t think a proc= ess exception is a bad thing. If it=E2=80=99s the right thing to do, then th= at the reason why we have such exceptions. Also I think it=E2=80=99d be the r= ight thing to change the registry policy=E2=80=A6 but that probably a longer= story. >>>>>>>> I agree that it is outdated that the registry requires a >>>>>>>> standards action, because it has become normal tcpm >>>>>>>> practice for any change to TCP to have to start on the >>>>>>>> experimental track. So this would justify a process excepti= on. >>>>>>>>=20 >>>>>>>> So, in summary, I don't mind (a), (b) or (c). I think (d) >>>>>>>> is not sufficiently open and recorded for assignment of a >>>>>>>> flag in the main TCP header. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Bob >>>>>>>>=20 >>>>>>>=20 >>>>>>> -- _________________________________________________________= _______ >>>>>>> Bob Briscoehttp://bobbriscoe.net/ >>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>> --=20 >>>>> ________________________________________________________________ >>>>> Bob Briscoehttp://bobbriscoe.net/ >>>>=20 >>>=20 >>=20 >> --=20 >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ >=20 --Apple-Mail-A4E940A2-48EF-4272-9014-91E08FD90B3A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Wednesday lunch?

Sent using a m= achine that autocorrects in interesting ways...

On Jul 10, 201= 7, at 6:58 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:

Hi, Bob,

On Fri, Jul 7, 2017 at 9:52 AM, Bob Bris= coe <ietf@bobbriscoe.net> wrote:
=20 =20 =20
Spencer,

Good idea. Except herding WG chairs and ADs to a common space-time co-ordinate during an IETF is not easy.
How about at AD Office hours?
on Sunday from 1500 to 1600 in the Istanbul room at IETF 99
Two minds, with bu= t a single thought.

That works for me. Anyone with a= dog in this fight, that it doesn't work for?

Spenc= er
 


Bob


On 07/07/17 15:38, S= pencer Dawkins at IETF wrote:
Gorry, since you asked - I don't have an objection to most of the alternatives presented in this thread. Since we're most/all in Prague Real Soon Now, I suggest that we have a whiteboard session at an appropriate break in the action, and make sure we are all on the same page, because there are several interconnected parts of the discussion.

Thanks,

Spencer

On Tue, Jul 4, 2017 at 10:41 AM, G Fairhurst <gorry@erg.abdn.ac.uk> wrote:
On 04/07/2017, 16:19, Bob Br= iscoe wrote:
Gorry,

A point I didn't make, but should have done: 2 of the experiments in ecn-experimentation depend on AccECN as a pre-requisite.
This I realised.
So it's important not to risk delay to AccECN in an attempt not to delay ecn-experimentation.

 OK - I will take it to the next Chair's meeting.
Can you give any clue as to which solutions you do or don't favour? Mirja asked me to post this to the lists. I think she was hoping this would reveal all the pros and cons, so a decision could then be made quickly between the chairs/ADs/shepherds/catherds.

 I will - but need to consult others first.

Bob

Gorry
On 03/07/17 22:06, Gorry (erg) wrote:
I think as document shepherd I have the input I need, but I need to talk to my AD about how to handle the process  - and liaise with the TCPM co-chairs regarding the TCPM WG draft. This isn't the first time we have had to look at the implications of making another RFC historic, and I think we can do the correct thing.

Gorry

 On 3 Jul 2017, at 20:17, C. M. Heard <heard@pobox.com <mailto:heard@pobox.com>> wrote:
Bob,

I think that your option (f) is better than option (e) (what I suggested). As an aside, either one patches up an apparent process violation committed by RFC 3540, an experimental RFC that assigned bit 7 in contradiction to the policy in RFC 2780.

Mike Heard
On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe <ietf@bobbriscoe.net <mailto:ietf@bobbriscoe.net>> wrote:

    Mike,

    Let's call this option:
    (e) ecn-experimentation alters the reg= istry policy of bit 7 of
    the TCP header to "IETF Review".

    Having a different policy for certain b= its within a registry
    might send IANA into a spin, but I am s= ure they could write
    suitable text into the registry policy= if they had to.

    I quite like this one. Altho unorthodo= x, it's neat.


    Thank you.


    Bob

    PS. Strictly RFC3168 used the CWR and E= CE flags (bits 8 & 9) as
    a 2-bit field during the 3-way hand-sh= ake. While the ECN Nonce
    and AccECN use the three ECN flags (bi= ts 7-9) as a 3-bit field
    during the 3WHS. AccECN uses the combinations that RFC3168 and
    the Nonce do not use. So to cover all b= ases:

    Option (f): ecn-experimentation alters= the registry policy for
    bits 7-9 to "IETF Review".


    On 03/07/17 18:14, C. M. Heard wrote:<= br>

    Bob,

    Couldn't the text in the IANA considerations of
    ecn-experimentation (which needs to b= e updated in any case)
    both change the NS flag to Reserved f= or ECN Experimentation and
    change the allocation policy for tha= t flag from Standards
    Action to IETF Review, thereby updat= ing RFC 2780? That would
    avoid the churn needed to add motiva= ting text for a 4th
    experiment to ecn-experimentation an= d would allow AccECN to
    assign the NS bit itself without a p= rocess exception.

    Mike Heard

    On Mon, 3 Jul 2017 10:28:25 +0100, B= ob Briscoe wrote:

        Michael*2, Yoshifumi, G= orry, David, Wes, Mirja, Spencer,
        tcpm list, tsvwg list,=

        There has been some of= flist discussion (among different
        sub-groups) to narrow d= own the options here. It is time to
        see opinions from the t= wo affected WGs (tcpm and tsvwg) on
        preferred process, esp= . from the WG chairs and ADs.

        *=3D=3DBackground to the P= rocess Problem=3D=3D**
        *

        In tsvwg the process i= s in motion to make the ECN nonce
        [RFC 3540] historic. S= o, in the most recent rev of
        draft-ietf-tcpm-accura= te-ecn-03 , we could finally include
        IANA assignment of the= NS flag
            (see
=         https://tools.ietf.org/html/draft-ietf-tcpm-accura= te-ecn-03#section-6
        <https://tools.ietf.org/html/draft-ietf-tcpm-ac= curate-ecn-03#section-6> )

        However, AccECN is EXP= erimental, whereas the registry
        policy for assigning T= CP flags is "Standards Action"
        https://www.iana.org/assignments/tcp-header-fla= gs/tcp-header-flags.xhtml
        <https://www.iana.org/assignments/tcp-header= -flags/tcp-header-flags.xhtml>
        which means "Values ar= e assigned only for Standards Track
        RFCs approved by the I= ESG" [RFC2434].

        References:
            Process f= or designating RFCs as historic:
        https://www.ietf.org/iesg/statement/designating-rf= cs-as-historic.html
        <https://www.ietf.org/iesg/statement/designatin= g-rfcs-as-historic.html>
            Current d= raft text to make RFC 3540 historic:
        https://tools.ietf.org/html/draft-ietf-tsv= wg-ecn-experimentation-03#section-3
        <https://tools.ietf.org/html/draft-ietf-t= svwg-ecn-experimentation-03#section-3>
            My initi= al draft for the AD's status change note:
        https://github= .com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-no= nce-rfc3540-to-historic-00.txt
        <https://gi= thub.com/bbriscoe/ecn-experimentation/blob/master/status-change-ec= n-nonce-rfc3540-to-historic-00.txt>

        ecn-experimentation ha= s just completed WGLC. It still has
        to go through IETF LC (= after Prague). it is deliberately PS
        in order to be able to= relax pre-existing constraints on
        ECN experiments in sta= ndards track RFCs. However, if poss,
        we want to avoid addin= g motivating text for a 4th
        experiment, which coul= d require another cycle of WGLC and
        delay until Nov.

        RFC 3692 ("Assigning E= xperimental and Testing Numbers
        Considered Useful") co= uld also be relevant, although it
        doesn't seem to help h= ere, because it is primarily aimed at
        larger codepoint space= s, not single bits.


        *=3D=3DProcess Options=3D=3D= **
        *
        There need to be two par= ts to the process: 1) unassignment
        and 2) reassignment. The= first seems clear-cut. The second
        is less obvious.

        1) Unassigning the NS fl= ag from RFC 3540
        a) add text to IANA cons= iderations section of
        ecn-experientation makin= g the NS flag reserved

        2) Assigning the NS flag= to accurate-ecn (and renaming it
        the AE flag).
        Process options:
        a) ecn-experimentation a= ssigns flag to itself as reserved
        for experiments and says= initially the AccECN experiment
        will use it exclusively<= br>         b) ecn-experimentation a= ssigns NS flag exclusively to AccECN
        c) AccECN assigns NS fla= g to itself, with a process
        exception proposed to th= e IESG to allow an EXP doc to
        assign to a Standards Ac= tion registry
        d) the NS flag is reassi= gned by "AD review comment" or
        "IETF Last Call comment"= (quoted from David's suggestions)
        e) other?...

        The difference between (= a) and (b) is in the document that
        ends up being referenced= from the IANA registry:
        a)  ecn-experimenta= tion
        b) accurate-ecn

         *=3D=3DMy own preferences=3D= =3D**
        *
        During discussions, I di= dn't prefer (c) cos I thought the
        IESG might question why t= hey are being asked to make a
        process exception for an= ECN experiment at the same time as
        a draft is going through= that avoids raising process
        exceptions for ECN exper= iments.

        Nonetheless, since then,= Mirja has said...

        On 02/07/17 23:40, Mirja= K=C3=BChlewind wrote:
        I actually prefer opti= on (c). I don=E2=80=99t think a process exception is a bad thing. If it=E2=80=99s the right thing to do, then that the reason why we have such exceptions. Also I think it=E2=80=99d be the right thing to change th= e registry policy=E2=80=A6 but that probably a longe= r story.
        I agree that it is outda= ted that the registry requires a
        standards action, becaus= e it has become normal tcpm
        practice for any change t= o TCP to have to start on the
        experimental track. So t= his would justify a process exception.

        So, in summary, I don't m= ind (a), (b) or (c). I think (d)
        is not sufficiently open= and recorded for assignment of a
        flag in the main TCP hea= der.


        Bob


    --     ____________________= ____________________________________________
    Bob Briscoehttp://bobbriscoe.net/



--
_____________________________________________________= ___________
Bob Briscoehttp://bobbriscoe.net/



--=20
________________________________________________________________
Bob Briscoe                               htt=
p://bobbriscoe.net/

= --Apple-Mail-A4E940A2-48EF-4272-9014-91E08FD90B3A-- From nobody Tue Jul 11 14:01:00 2017 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 97DEA127868; Tue, 11 Jul 2017 14:00:51 -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, 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=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 wCiOIwzVL8E2; Tue, 11 Jul 2017 14:00:47 -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 CB2D4126E3A; Tue, 11 Jul 2017 14:00:46 -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:From:References:Cc: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=u4lK887vX1KvxcWNrTJlz2dGce2djafk0Bpgwuxokfo=; b=rbsWaPOedakcKYnBQVN+h7Jy9 TEvnFx5lEQH7Iu1x8Q/V4NXT6LEAzb4fRxg7kqLGIigaI1Fvic5300zLzpjI5PiX3lxXSUeiNMgxn kWjZ6iB9AMSTIe/OsL7CKx59KCwqtvyGwB/gnpPtZ6vawQsey49UEFTvZBmspId1efawqk3w19Xzc Ht1fCNBUYEm0Zs2mrWVzqEew0jQgABwpsnsHY1IdYNddKoi5HXTrVLXsL0i4HVfpqUUeJ8n8eIm6r HAqE58alOQQdfJyIqyVaj40tteUAsgqNSxb4EPbv7i9fUpZbQ0i1nkLo5ff17a4ysp2jgVZTKuq+n XD7qTVDRA==; Received: from [31.185.128.124] (port=43004 helo=[192.168.0.13]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dV2Gw-0000QT-3n; Tue, 11 Jul 2017 22:00:43 +0100 To: Fred Baker , Spencer Dawkins at IETF , Mirja Kuehlewind Cc: G Fairhurst , tcpm IETF list , tsvwg IETF list , tsvwg-chairs , tsv-ads , tcpm-chairs References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> <49200576-B166-4FE9-8B5D-36ECA5509364@erg.abdn.ac.uk> <99989ba2-4dae-eb6e-90fe-cb4b19f20594@bobbriscoe.net> <595BB715.70700@erg.abdn.ac.uk> From: Bob Briscoe Message-ID: Date: Tue, 11 Jul 2017 22:00:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------59FCB6B85B36EDB32DB6B202" 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] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 21:00:51 -0000 This is a multi-part message in MIME format. --------------59FCB6B85B36EDB32DB6B202 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit *Fred,** *For Wed, IETF agenda says "1200-1300 WG Chairs Forum" I assume some tcpm & tsvwg WG chairs plan to attend? I feel the need for a doodle here. *Spencer & Mirja* can you suggest some times you're free as you're likely to be the most calendaristically challenged. BTW, I assume there will be discussion in tcpm on Monday given this will be raised during the talk on AccECN. Also, there's no rule against anyone saying something specific by email now, in response to the choices suggested so far on the list (collected below) - then we might not need a mtg. > 2) Assigning the NS flag to accurate-ecn (and renaming it the AE flag). > Process options: > a) ecn-experimentation assigns flag to itself as reserved for > experiments and says initially the AccECN experiment will use it > exclusively > b) ecn-experimentation assigns NS flag exclusively to AccECN > c) AccECN assigns NS flag to itself, with a process exception > proposed to the IESG to allow an EXP doc to assign to a Standards > Action registry > d) the NS flag is reassigned by "AD review comment" or "IETF > Last Call comment" (quoted from David's suggestions) > e) ecn-experimentation alters the registry policy of bit 7 of > the TCP header to "IETF Review" > f) ecn-experimentation alters the registry policy for bits > 7-9 to "IETF Review". Bob On 11/07/17 00:15, Fred Baker wrote: > Wednesday lunch? > > Sent using a machine that autocorrects in interesting ways... > > On Jul 10, 2017, at 6:58 AM, Spencer Dawkins at IETF > > > wrote: > >> Hi, Bob, >> >> On Fri, Jul 7, 2017 at 9:52 AM, Bob Briscoe > > wrote: >> >> Spencer,f) >> >> Good idea. Except herding WG chairs and ADs to a common >> space-time co-ordinate during an IETF is not easy. >> How about at AD Office hours? >>> on Sunday from 1500 to 1600 in the Istanbul room at IETF 99 >> >> Two minds, with but a single thought. >> >> That works for me. Anyone with a dog in this fight, that it doesn't >> work for? >> >> Spencer >> >> >> >> Bob >> >> >> On 07/07/17 15:38, Spencer Dawkins at IETF wrote: >>> Gorry, since you asked - I don't have an objection to most of >>> the alternatives presented in this thread. Since we're most/all >>> in Prague Real Soon Now, I suggest that we have a whiteboard >>> session at an appropriate break in the action, and make sure we >>> are all on the same page, because there are several >>> interconnected parts of the discussion. >>> >>> Thanks, >>> >>> Spencer >>> >>> On Tue, Jul 4, 2017 at 10:41 AM, G Fairhurst >>> > wrote: >>> >>> On 04/07/2017, 16:19, Bob Briscoe wrote: >>> >>> Gorry, >>> >>> A point I didn't make, but should have done: 2 of the >>> experiments in ecn-experimentation depend on AccECN as a >>> pre-requisite. >>> >>> This I realised. >>> >>> So it's important not to risk delay to AccECN in an >>> attempt not to delay ecn-experimentation. >>> >>> OK - I will take it to the next Chair's meeting. >>> >>> Can you give any clue as to which solutions you do or >>> don't favour? Mirja asked me to post this to the lists. >>> I think she was hoping this would reveal all the pros >>> and cons, so a decision could then be made quickly >>> between the chairs/ADs/shepherds/catherds. >>> >>> I will - but need to consult others first. >>> >>> >>> Bob >>> >>> Gorry >>> >>> On 03/07/17 22:06, Gorry (erg) wrote: >>> >>> I think as document shepherd I have the input I >>> need, but I need to talk to my AD about how to >>> handle the process - and liaise with the TCPM >>> co-chairs regarding the TCPM WG draft. This isn't >>> the first time we have had to look at the >>> implications of making another RFC historic, and I >>> think we can do the correct thing. >>> >>> Gorry >>> >>> On 3 Jul 2017, at 20:17, C. M. Heard >>> >>> >> >>> wrote: >>> >>> Bob, >>> >>> I think that your option (f) is better than >>> option (e) (what I suggested). As an aside, >>> either one patches up an apparent process >>> violation committed by RFC 3540, an experimental >>> RFC that assigned bit 7 in contradiction to the >>> policy in RFC 2780. >>> >>> Mike Heard >>> >>> On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe >>> >> >>> >> >> wrote: >>> >>> Mike, >>> >>> Let's call this option: >>> (e) ecn-experimentation alters the registry >>> policy of bit 7 of >>> the TCP header to "IETF Review". >>> >>> Having a different policy for certain bits >>> within a registry >>> might send IANA into a spin, but I am sure >>> they could write >>> suitable text into the registry policy if >>> they had to. >>> >>> I quite like this one. Altho unorthodox, >>> it's neat. >>> >>> >>> Thank you. >>> >>> >>> Bob >>> >>> PS. Strictly RFC3168 used the CWR and ECE >>> flags (bits 8 & 9) as >>> a 2-bit field during the 3-way hand-shake. >>> While the ECN Nonce >>> and AccECN use the three ECN flags (bits >>> 7-9) as a 3-bit field >>> during the 3WHS. AccECN uses the >>> combinations that RFC3168 and >>> the Nonce do not use. So to cover all bases: >>> >>> Option (f): ecn-experimentation alters the >>> registry policy for >>> bits 7-9 to "IETF Review". >>> >>> >>> On 03/07/17 18:14, C. M. Heard wrote: >>> >>> >>> Bob, >>> >>> Couldn't the text in the IANA >>> considerations of >>> ecn-experimentation (which needs to be >>> updated in any case) >>> both change the NS flag to Reserved for >>> ECN Experimentation and >>> change the allocation policy for that >>> flag from Standards >>> Action to IETF Review, thereby updating >>> RFC 2780? That would >>> avoid the churn needed to add motivating >>> text for a 4th >>> experiment to ecn-experimentation and >>> would allow AccECN to >>> assign the NS bit itself without a >>> process exception. >>> >>> Mike Heard >>> >>> On Mon, 3 Jul 2017 10:28:25 +0100, Bob >>> Briscoe wrote: >>> >>> Michael*2, Yoshifumi, Gorry, David, >>> Wes, Mirja, Spencer, >>> tcpm list, tsvwg list, >>> >>> There has been some offlist >>> discussion (among different >>> sub-groups) to narrow down the >>> options here. It is time to >>> see opinions from the two affected >>> WGs (tcpm and tsvwg) on >>> preferred process, esp. from the WG >>> chairs and ADs. >>> >>> *==Background to the Process Problem==** >>> * >>> >>> In tsvwg the process is in motion to >>> make the ECN nonce >>> [RFC 3540] historic. So, in the most >>> recent rev of >>> draft-ietf-tcpm-accurate-ecn-03 , we could >>> finally include >>> IANA assignment of the NS flag >>> (see >>> https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6 >>> >>> >>> >> > >>> ) >>> >>> However, AccECN is EXPerimental, >>> whereas the registry >>> policy for assigning TCP flags is >>> "Standards Action" >>> https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml >>> >>> >>> >> > >>> which means "Values are assigned >>> only for Standards Track >>> RFCs approved by the IESG" [RFC2434]. >>> >>> References: >>> Process for designating RFCs as >>> historic: >>> https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html >>> >>> >>> >> > >>> Current draft text to make RFC >>> 3540 historic: >>> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3 >>> >>> >>> >> > >>> My initial draft for the AD's >>> status change note: >>> https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt >>> >>> >>> >> > >>> >>> ecn-experimentation has just completed WGLC. >>> It still has >>> to go through IETF LC (after >>> Prague). it is deliberately PS >>> in order to be able to relax >>> pre-existing constraints on >>> ECN experiments in standards track >>> RFCs. However, if poss, >>> we want to avoid adding motivating >>> text for a 4th >>> experiment, which could require >>> another cycle of WGLC and >>> delay until Nov. >>> >>> RFC 3692 ("Assigning Experimental >>> and Testing Numbers >>> Considered Useful") could also be >>> relevant, although it >>> doesn't seem to help here, because >>> it is primarily aimed at >>> larger codepoint spaces, not single >>> bits. >>> >>> >>> *==Process Options==** >>> * >>> There need to be two parts to the >>> process: 1) unassignment >>> and 2) reassignment. The first seems >>> clear-cut. The second >>> is less obvious. >>> >>> 1) Unassigning the NS flag from RFC 3540 >>> a) add text to IANA considerations >>> section of >>> ecn-experientation making the NS >>> flag reserved >>> >>> 2) Assigning the NS flag to >>> accurate-ecn (and renaming it >>> the AE flag). >>> Process options: >>> a) ecn-experimentation assigns flag >>> to itself as reserved >>> for experiments and says initially >>> the AccECN experiment >>> will use it exclusively >>> b) ecn-experimentation assigns NS >>> flag exclusively to AccECN >>> c) AccECN assigns NS flag to itself, >>> with a process >>> exception proposed to the IESG to >>> allow an EXP doc to >>> assign to a Standards Action registry >>> d) the NS flag is reassigned by "AD >>> review comment" or >>> "IETF Last Call comment" (quoted >>> from David's suggestions) >>> e) other?... >>> >>> The difference between (a) and (b) >>> is in the document that >>> ends up being referenced from the >>> IANA registry: >>> a) ecn-experimentation >>> b) accurate-ecn >>> >>> *==My own preferences==** >>> * >>> During discussions, I didn't prefer >>> (c) cos I thought the >>> IESG might question why they are >>> being asked to make a >>> process exception for an ECN >>> experiment at the same time as >>> a draft is going through that avoids >>> raising process >>> exceptions for ECN experiments. >>> >>> Nonetheless, since then, Mirja has >>> said... >>> >>> On 02/07/17 23:40, Mirja Kühlewind >>> wrote: >>> >>> I actually prefer option (c). I >>> don’t think a process exception is a bad >>> thing. If it’s the right thing to do, >>> then that the reason why we have such >>> exceptions. Also I think it’d be the >>> right thing to change the registry >>> policy… but that probably a longer story. >>> >>> I agree that it is outdated that the >>> registry requires a >>> standards action, because it has >>> become normal tcpm >>> practice for any change to TCP to >>> have to start on the >>> experimental track. So this would >>> justify a process exception. >>> >>> So, in summary, I don't mind (a), >>> (b) or (c). I think (d) >>> is not sufficiently open and >>> recorded for assignment of a >>> flag in the main TCP header. >>> >>> >>> Bob >>> >>> >>> -- >>> ________________________________________________________________ >>> Bob Briscoehttp://bobbriscoe.net/ >>> >>> >>> >>> >>> -- >>> ________________________________________________________________ >>> Bob Briscoehttp://bobbriscoe.net/ >>> >>> >>> >> >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ >> >> -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------59FCB6B85B36EDB32DB6B202 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Fred,
For Wed, IETF agenda says "1200-1300  WG Chairs Forum"
I assume some tcpm & tsvwg WG chairs plan to attend?

I feel the need for a doodle here.
Spencer & Mirja can you suggest some times you're free as you're likely to be the most calendaristically challenged.


BTW, I assume there will be discussion in tcpm on Monday given this will be raised during the talk on AccECN.
Also, there's no rule against anyone saying something specific by email now, in response to the choices suggested so far on the list (collected below) - then we might not need a mtg.

2) Assigning the NS flag to accurate-ecn (and renaming it the AE flag).
        Process options:
        a) ecn-experimentation assigns flag to itself as reserved for experiments and says initially the AccECN experiment will use it exclusively
        b) ecn-experimentation assigns NS flag exclusively to AccECN
        c) AccECN assigns NS flag to itself, with a process exception proposed to the IESG to allow an EXP doc to assign to a Standards Action registry
        d) the NS flag is reassigned by "AD review comment" or "IETF Last Call comment" (quoted from David's suggestions)
        e) ecn-experimentation alters the registry policy of bit 7 of the TCP header to "IETF Review"
        f)  ecn-experimentation alters the registry policy for bits 7-9 to "IETF Review".



Bob

On 11/07/17 00:15, Fred Baker wrote:
Wednesday lunch?

Sent using a machine that autocorrects in interesting ways...

On Jul 10, 2017, at 6:58 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:

Hi, Bob,

On Fri, Jul 7, 2017 at 9:52 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
Spencer,f)

Good idea. Except herding WG chairs and ADs to a common space-time co-ordinate during an IETF is not easy.
How about at AD Office hours?
on Sunday from 1500 to 1600 in the Istanbul room at IETF 99
Two minds, with but a single thought.

That works for me. Anyone with a dog in this fight, that it doesn't work for?

Spencer
 


Bob


On 07/07/17 15:38, Spencer Dawkins at IETF wrote:
Gorry, since you asked - I don't have an objection to most of the alternatives presented in this thread. Since we're most/all in Prague Real Soon Now, I suggest that we have a whiteboard session at an appropriate break in the action, and make sure we are all on the same page, because there are several interconnected parts of the discussion.

Thanks,

Spencer

On Tue, Jul 4, 2017 at 10:41 AM, G Fairhurst <gorry@erg.abdn.ac.uk> wrote:
On 04/07/2017, 16:19, Bob Briscoe wrote:
Gorry,

A point I didn't make, but should have done: 2 of the experiments in ecn-experimentation depend on AccECN as a pre-requisite.
This I realised.
So it's important not to risk delay to AccECN in an attempt not to delay ecn-experimentation.

 OK - I will take it to the next Chair's meeting.
Can you give any clue as to which solutions you do or don't favour? Mirja asked me to post this to the lists. I think she was hoping this would reveal all the pros and cons, so a decision could then be made quickly between the chairs/ADs/shepherds/catherds.

 I will - but need to consult others first.

Bob

Gorry
On 03/07/17 22:06, Gorry (erg) wrote:
I think as document shepherd I have the input I need, but I need to talk to my AD about how to handle the process  - and liaise with the TCPM co-chairs regarding the TCPM WG draft. This isn't the first time we have had to look at the implications of making another RFC historic, and I think we can do the correct thing.

Gorry

 On 3 Jul 2017, at 20:17, C. M. Heard <heard@pobox.com <mailto:heard@pobox.com>> wrote:
Bob,

I think that your option (f) is better than option (e) (what I suggested). As an aside, either one patches up an apparent process violation committed by RFC 3540, an experimental RFC that assigned bit 7 in contradiction to the policy in RFC 2780.

Mike Heard
On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe <ietf@bobbriscoe.net <mailto:ietf@bobbriscoe.net>> wrote:

    Mike,

    Let's call this option:
    (e) ecn-experimentation alters the registry policy of bit 7 of
    the TCP header to "IETF Review".

    Having a different policy for certain bits within a registry
    might send IANA into a spin, but I am sure they could write
    suitable text into the registry policy if they had to.

    I quite like this one. Altho unorthodox, it's neat.


    Thank you.


    Bob

    PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as
    a 2-bit field during the 3-way hand-shake. While the ECN Nonce
    and AccECN use the three ECN flags (bits 7-9) as a 3-bit field
    during the 3WHS. AccECN uses the combinations that RFC3168 and
    the Nonce do not use. So to cover all bases:

    Option (f): ecn-experimentation alters the registry policy for
    bits 7-9 to "IETF Review".


    On 03/07/17 18:14, C. M. Heard wrote:

    Bob,

    Couldn't the text in the IANA considerations of
    ecn-experimentation (which needs to be updated in any case)
    both change the NS flag to Reserved for ECN Experimentation and
    change the allocation policy for that flag from Standards
    Action to IETF Review, thereby updating RFC 2780? That would
    avoid the churn needed to add motivating text for a 4th
    experiment to ecn-experimentation and would allow AccECN to
    assign the NS bit itself without a process exception.

    Mike Heard

    On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote:

        Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer,
        tcpm list, tsvwg list,

        There has been some offlist discussion (among different
        sub-groups) to narrow down the options here. It is time to
        see opinions from the two affected WGs (tcpm and tsvwg) on
        preferred process, esp. from the WG chairs and ADs.

        *==Background to the Process Problem==**
        *

        In tsvwg the process is in motion to make the ECN nonce
        [RFC 3540] historic. So, in the most recent rev of
        draft-ietf-tcpm-accurate-ecn-03 , we could finally include
        IANA assignment of the NS flag
            (see
        https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6
        <https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6> )

        However, AccECN is EXPerimental, whereas the registry
        policy for assigning TCP flags is "Standards Action"
        https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml
        <https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml>
        which means "Values are assigned only for Standards Track
        RFCs approved by the IESG" [RFC2434].

        References:
            Process for designating RFCs as historic:
        https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html
        <https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html>
            Current draft text to make RFC 3540 historic:
        https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3
        <https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3>
            My initial draft for the AD's status change note:
        https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt
        <https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt>

        ecn-experimentation has just completed WGLC. It still has
        to go through IETF LC (after Prague). it is deliberately PS
        in order to be able to relax pre-existing constraints on
        ECN experiments in standards track RFCs. However, if poss,
        we want to avoid adding motivating text for a 4th
        experiment, which could require another cycle of WGLC and
        delay until Nov.

        RFC 3692 ("Assigning Experimental and Testing Numbers
        Considered Useful") could also be relevant, although it
        doesn't seem to help here, because it is primarily aimed at
        larger codepoint spaces, not single bits.


        *==Process Options==**
        *
        There need to be two parts to the process: 1) unassignment
        and 2) reassignment. The first seems clear-cut. The second
        is less obvious.

        1) Unassigning the NS flag from RFC 3540
        a) add text to IANA considerations section of
        ecn-experientation making the NS flag reserved

        2) Assigning the NS flag to accurate-ecn (and renaming it
        the AE flag).
        Process options:
        a) ecn-experimentation assigns flag to itself as reserved
        for experiments and says initially the AccECN experiment
        will use it exclusively
        b) ecn-experimentation assigns NS flag exclusively to AccECN
        c) AccECN assigns NS flag to itself, with a process
        exception proposed to the IESG to allow an EXP doc to
        assign to a Standards Action registry
        d) the NS flag is reassigned by "AD review comment" or
        "IETF Last Call comment" (quoted from David's suggestions)
        e) other?...

        The difference between (a) and (b) is in the document that
        ends up being referenced from the IANA registry:
        a)  ecn-experimentation
        b) accurate-ecn

         *==My own preferences==**
        *
        During discussions, I didn't prefer (c) cos I thought the
        IESG might question why they are being asked to make a
        process exception for an ECN experiment at the same time as
        a draft is going through that avoids raising process
        exceptions for ECN experiments.

        Nonetheless, since then, Mirja has said...

        On 02/07/17 23:40, Mirja Kühlewind wrote:
        I actually prefer option (c). I don’t think a process exception is a bad thing. If it’s the right thing to do, then that the reason why we have such exceptions. Also I think it’d be the right thing to change the registry policy… but that probably a longer story.
        I agree that it is outdated that the registry requires a
        standards action, because it has become normal tcpm
        practice for any change to TCP to have to start on the
        experimental track. So this would justify a process exception.

        So, in summary, I don't mind (a), (b) or (c). I think (d)
        is not sufficiently open and recorded for assignment of a
        flag in the main TCP header.


        Bob


    --     ________________________________________________________________
    Bob Briscoehttp://bobbriscoe.net/



--
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/



-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------59FCB6B85B36EDB32DB6B202-- From nobody Tue Jul 11 14:08:27 2017 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 1176212EB5F; Tue, 11 Jul 2017 14:08:26 -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 movaRLao0Dg0; Tue, 11 Jul 2017 14:08:24 -0700 (PDT) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::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 BD2AA129A97; Tue, 11 Jul 2017 14:08:24 -0700 (PDT) Received: by mail-pg0-x244.google.com with SMTP id y129so438636pgy.3; Tue, 11 Jul 2017 14:08:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vnBudu+vYavgpV6zprFp575ysppXNGoTtRS9vQvRxQs=; b=PpfmJdxpLcJUhgThZDKmFjNTuZqv8Mv7/DPURLWKOCzj35GnvdPjNGuK3VN6iSHWiA m7zNil2qP7fPyU4mtIqAd+E71aCmJZAhPBUIKYO7IF3oCrwmOamPELJal69I1SfgPDx0 bAOOui4xUheHiktXRsLRwW3hWhjVGrVvjmmuBSK7MZnz7LV1i6W6cr8YmWF0qjliH6rC VuL7V6DXuAb4TDuGqugVqb7K2NYr948+NBKyFIw/QI+Xkg7G2wBC2xPVPKMj2fGbCrha Ky9P3DOPQnrpEyl3j3H/1myTS9vVIwtSB+XFAInRca/S4oPgnjL9r8iPAEwNMjdgXnyN aLKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vnBudu+vYavgpV6zprFp575ysppXNGoTtRS9vQvRxQs=; b=LrzrKWCL6/Oyumt/tKQIP259dfEM3zg23Q8L8wQ5OOI6hNJjB5hr0opTk4GMyiVrjr jrp3Od3sYJ3d8fxone3NHT5id5GvS7yGA7WEpalNbyuzOJ537YXaUi67GBzboD8ux/IS lxbL6s8ao8Gk2FUtB6+gaMLvOZjvlry+ROBrBgwI09zOo0qmwxzxDb025Re4tO8UxmID 1ie0Y+g35Pq/R+BWNvB9xMWeAXL+amPkZoTcBla/ik82thujRGUwfbAu5dFZkyO8lfzn ryjE3NMcfjqLQS9IyXKkutcTZFoisdADNeWJrY6ZfngWqYjW9Mkralbg7znP4zV3n+Us jbrQ== X-Gm-Message-State: AIVw112mOMkk/NoeyI1QVb1wJ/cXRmmX3/1Sc1VVnQkEgdVR9EtpA7ZP RflQZlO3kwZNcfN9bp4= X-Received: by 10.98.53.134 with SMTP id c128mr52138015pfa.36.1499807304441; Tue, 11 Jul 2017 14:08:24 -0700 (PDT) Received: from ?IPv6:2601:646:c005:a10:a12e:ce02:6ef7:374a? ([2601:646:c005:a10:a12e:ce02:6ef7:374a]) by smtp.gmail.com with ESMTPSA id p28sm415067pfl.102.2017.07.11.14.08.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 14:08:23 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3436.2\)) From: Fred Baker In-Reply-To: Date: Tue, 11 Jul 2017 14:08:21 -0700 Cc: Spencer Dawkins at IETF , Mirja Kuehlewind , G Fairhurst , tcpm IETF list , tsvwg IETF list , tsvwg-chairs , tsv-ads , tcpm-chairs Content-Transfer-Encoding: quoted-printable Message-Id: References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> <49200576-B166-4FE9-8B5D-36ECA5509364@erg.abdn.ac.uk> <99989ba2-4dae-eb6e-90fe-cb4b19f20594@bobbriscoe.net> <595BB715.70700@erg.abdn.ac.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.3436.2) Archived-At: Subject: Re: [tsvwg] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 21:08:26 -0000 > On Jul 11, 2017, at 2:00 PM, Bob Briscoe wrote: >=20 > Fred, > For Wed, IETF agenda says "1200-1300 WG Chairs Forum" > I assume some tcpm & tsvwg WG chairs plan to attend? My comment was in response to yours, that herding WG Chairs and ADs into = a common space was "interesting". That is an interval in which we are = all supposed to be in one room (actuality may vary).= From nobody Tue Jul 11 14:22:09 2017 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 2E82512F287; Tue, 11 Jul 2017 14:22:08 -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, 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=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 NuNQ8X5yPTfm; Tue, 11 Jul 2017 14:22:06 -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 C5CEB12ECF0; Tue, 11 Jul 2017 14:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject: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=yOmrbCOJo7TNtZnVasLtxi8/JKNNp29maUE1up1jAvE=; b=Qi/aFE/2m+s0x4baLoeET6beb5 2rYc/bzE7wvLXAsJ8Ddf65U6Qg5C49+bsXBtEV54t6pdWUChSA4R0/SQOhmdcJEEEAC7Y4CWwApTf drrrlpbS+ON7WENqzJcKj9ZOAfZn5i47wnEXgoCoBROweck28E+GIhNIGYwUYt8ftIgoTk7Z8eoig NHOemi3IPJ7J0FSjTTgO4RWTBMlPiRBJu5QqQaLoSU2Adaf5Eq5oFMPiCaxg+qy0z2H3JmjMBuiwL d70FWSvVMe8JJQKMWV3QW0L8Nh5qkAQi8ZjWS2JJ3ze8vYsTnb/uYUyWOSVd6ZM13jT43+4zc4yB+ Tqc5XKBw==; Received: from [31.185.128.124] (port=43102 helo=[192.168.0.13]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dV2bd-0001yn-AF; Tue, 11 Jul 2017 22:22:05 +0100 To: Fred Baker Cc: Spencer Dawkins at IETF , Mirja Kuehlewind , G Fairhurst , tcpm IETF list , tsvwg IETF list , tsvwg-chairs , tsv-ads , tcpm-chairs References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> <49200576-B166-4FE9-8B5D-36ECA5509364@erg.abdn.ac.uk> <99989ba2-4dae-eb6e-90fe-cb4b19f20594@bobbriscoe.net> <595BB715.70700@erg.abdn.ac.uk> From: Bob Briscoe Message-ID: <7ebf46c6-ece8-080e-cb2f-f621b9b62def@bobbriscoe.net> Date: Tue, 11 Jul 2017 22:22:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 21:22:08 -0000 Fred, Ah! Sry. I got the wrong end of the stick. However, some authors will not be there (if that matters). Bob On 11/07/17 22:08, Fred Baker wrote: > >> On Jul 11, 2017, at 2:00 PM, Bob Briscoe wrote: >> >> Fred, >> For Wed, IETF agenda says "1200-1300 WG Chairs Forum" >> I assume some tcpm & tsvwg WG chairs plan to attend? > My comment was in response to yours, that herding WG Chairs and ADs into a common space was "interesting". That is an interval in which we are all supposed to be in one room (actuality may vary). -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Wed Jul 12 05:46:37 2017 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 1B3C512EC30 for ; Wed, 12 Jul 2017 05:46: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] 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 l2DOPMh8zSDm for ; Wed, 12 Jul 2017 05:46:32 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 0B4C612426E for ; Wed, 12 Jul 2017 05:46:32 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1dVH2E-0006CY-3E for ; Wed, 12 Jul 2017 14:46:30 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 09E8FB007C8 for ; Wed, 12 Jul 2017 14:46:30 +0200 (CEST) To: "tsvwg@ietf.org" From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: Date: Wed, 12 Jul 2017 14:46:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1499863590.160193096 Archived-At: Subject: [tsvwg] Remarking of LE (draft-ietf-tsvwg-le-phb-02) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 12:46:35 -0000 Hi, In https://mailarchive.ietf.org/arch/msg/tsvwg/d70Z9JoLOWtQCadD_uA9pJ9tBx4 David made the comment: > ****I definitely want to see broader WG discussion of that “MUST remark†requirement, as it’s not backwards compatible with RFC 4594 - at a minimum, some thought should be applied to transition and mixing networks that use CS1 and the new LE DSCP. Here are some general thoughts on remarking of the LE PHB. If correctly implemented LE (lower effort) traffic will not harm BE (best-effort) traffic, because BE traffic will preempt LE traffic. DiffServ Domains that are not implementing LE may carry LE traffic within their BE aggregate. They must be aware, however, that the "no harm" property of LE is not given. There are now two types of LE users: LE-min: this user does not care if LE packet experience better forwarding treatment, so promoting them to BE is ok. LE-strict: this user wants to be sure that LE is obeying the "no harm" property, i.e., only otherwise unused resources should be consumed by LE traffic. The question is now, how the LE-strict user can detect whether the packets were promoted to BE. Let's assume we have two different DSCPs LE-min and LE-strict. Then: LE-min: can be promoted to BE, but should stay marked as LE-min to let subsequent domains handle it correctly as LE traffic LE-strict: should not be promoted to BE. Now we have two cases: a) DS domain remarks to BE and passes it as BE to the next DS domain. The receiver could probably use some feedback channel to let the sender know that this remarking happened. An appropriate reaction should be left to the application then (continue, abort, use LE transport protocol, rate limit, etc.) => E2E principle. b) DS domain simply drops the LE packet. I think b) is not useful. Coming back to the question above: A DS domain must be able to map DSCP to PHB freely (see RFC 2474). So if a DS domain currently supports LE and uses the CS1 DSCP for that, it should support the new LE DSCP, too. The current draft says A DS domain that still uses DSCP CS1 for marking LE traffic (including Low Priority-Data as defined in [RFC4594] or the old definition in [RFC3662]) MUST remark traffic to the LE DSCP '000010' at the egress to the next DS domain. This increases the probability that the DSCP is preserved end-to-end, whereas a CS1 marked packet may be remarked by the default DSCP if the next domain is applying DiffServ-intercon [RFC8100]. So a useful strategy would be to always remark CS1 to LE, when CS1 was used for RFC3662/LE to get rid of the ambiguity of CS1. More input welcome. Regards, Roland From nobody Wed Jul 12 09:33:03 2017 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 DC1BE1300CF; Wed, 12 Jul 2017 09:33:00 -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 lrEGrG_WMdBL; Wed, 12 Jul 2017 09:32:59 -0700 (PDT) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53E78128B8F; Wed, 12 Jul 2017 09:32:59 -0700 (PDT) Received: by mail-yb0-x236.google.com with SMTP id f194so8918168yba.3; Wed, 12 Jul 2017 09:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ion3DgJDabfOkY3oHvTP2SUTCr+9TiD77CFgegDJq2A=; b=OAd28inEE8HynJxl6C0gHWlvtZE9s//0nGGo4TWNVYvHziwYp+mhOjAoey1m65dBkJ QONYn4x5IQQOHwKaf0H3BKnUapduuv9Lvor1a4JOK1F4H/ncVfn1plq0b9cStAVAS1JY exVu4JWBbD2FFT/Ryw1J66oIZ3ZKfp3ic6ko8pjqusjkFU91qDIkXRENYzQl1+jDMehT S1d5orrH3783MDgELEnqBq9GjovRYALk2dyRjZ4Yll1FH8uqtAOC+8SXJ6jpkfqJLdwE 2KKRJ79siwEw+peNvSMC5gdf+aQKf5LuCGJhVrR1XqjDVzImK5GbS4cXjba73qxQfNX+ Gj0g== 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=ion3DgJDabfOkY3oHvTP2SUTCr+9TiD77CFgegDJq2A=; b=AvrDW3NAMLFMuXRl997ogYECBbeuYsd9QGLpwzlrcU5/poCFhrLohH5HxkdKbjdU40 yPOk4Sqw4ciAkUG1Cad7vJ2zqjzAFa37mW4KzQM4JghhHw39LuHUVrVrfVuRZHDAoY6p Sjj2bOf92Q8sLf1BGFpaYF8R1ULqQhJYJbBn5Mrej6ybxI4eol5lyuAdw7AnMDWjbecW ghFSzC/MpZt9MuAdFd2ww2yJreKWmaJT8k+3QIbbRKJ8/lLEzYjC22AVxgWaqQh8sbmg J+kWK8QD+1OAFOBjozOBR0GB18SeB5TUmx+rZEZ0y2p4ZKH56rdzRYhIMXY7FC60gbP5 xsyw== X-Gm-Message-State: AIVw112iu6+8/xjHNmcPTxn+t+4WnTwrdiwKj5NneWLsVhcy9mMscetN MnjIITJXSUxBa2ypY2cv6vWIVMn0Rw== X-Received: by 10.37.0.195 with SMTP id 186mr1442020yba.46.1499877178409; Wed, 12 Jul 2017 09:32:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.91.137 with HTTP; Wed, 12 Jul 2017 09:32:57 -0700 (PDT) In-Reply-To: References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> <49200576-B166-4FE9-8B5D-36ECA5509364@erg.abdn.ac.uk> <99989ba2-4dae-eb6e-90fe-cb4b19f20594@bobbriscoe.net> <595BB715.70700@erg.abdn.ac.uk> From: Spencer Dawkins at IETF Date: Wed, 12 Jul 2017 11:32:57 -0500 Message-ID: To: Fred Baker Cc: Bob Briscoe , Mirja Kuehlewind , G Fairhurst , tcpm IETF list , tsvwg IETF list , tsvwg-chairs , tsv-ads , tcpm-chairs Content-Type: multipart/alternative; boundary="001a113cf6506d27670554215ef9" Archived-At: Subject: Re: [tsvwg] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 16:33:01 -0000 --001a113cf6506d27670554215ef9 Content-Type: text/plain; charset="UTF-8" Dear All, On Tue, Jul 11, 2017 at 4:08 PM, Fred Baker wrote: > > > > On Jul 11, 2017, at 2:00 PM, Bob Briscoe wrote: > > > > Fred, > > For Wed, IETF agenda says "1200-1300 WG Chairs Forum" > > I assume some tcpm & tsvwg WG chairs plan to attend? > > My comment was in response to yours, that herding WG Chairs and ADs into a > common space was "interesting". That is an interval in which we are all > supposed to be in one room (actuality may vary). I hadn't thought Fred's suggestion through, until I realized that I haven't seen an e-mail for the WG Chairs Forum with an agenda YET (which is disturbing, but not relevant except that it makes us huddling at the beginning, end, or even middle of that time seem very reasonable). If the answer is that the chairs are gonna eat lunch and chat in small groups, that will be very easy for me to break away from. So, yes, please continue to discuss via e-mail, but Wednesday lunch will be a time I can be cornered. Spencer --001a113cf6506d27670554215ef9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,

On Tue, Jul 11, 2017 at 4:08 PM, Fred Baker <= fredbaker.iet= f@gmail.com> wrote:


> On Jul 11, 2017, at 2:00 PM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>
> Fred,
> For Wed, IETF agenda says "1200-1300=C2=A0 WG Chairs Forum"<= br> > I assume some tcpm & tsvwg WG chairs plan to attend?

My comment was in response to yours, that herding WG Chairs and ADs = into a common space was "interesting". That is an interval in whi= ch we are all supposed to be in one room (actuality may vary).
=

I hadn't thought Fred's suggestion through, unt= il I realized that I haven't seen an e-mail for the WG Chairs Forum wit= h an agenda YET (which is disturbing, but not relevant except that it makes= us huddling at the beginning, end, or even middle of that time seem very r= easonable). If the answer is that the chairs are gonna eat lunch and chat i= n small groups, that will be very easy for me to break away from.

So,= yes, please continue to discuss via e-mail, but Wednesday lunch will be a = time I can be cornered.

Spencer
--001a113cf6506d27670554215ef9-- From nobody Wed Jul 12 14:30:39 2017 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 23EEB1317CE for ; Wed, 12 Jul 2017 14:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 tWRoY5yTBSSz for ; Wed, 12 Jul 2017 14:30:35 -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 4BAED1317DE for ; Wed, 12 Jul 2017 14:30:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=tUGnBf+6qUIlH9KFYW9GnnS5E5ME7jusNJ6kfpmEZPXgob/8x0j9dSfz21q+fzPcc3sPGGWH+w83C+WE8CWOyCn8fkUVdkmrp1VkJR0t2kYS/qqHzojnEwqxLWqllgwImhKpCGGIYcBHCAE+XR0x+cohJhI/pSNslES3JJsorhU=; 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 5971 invoked from network); 12 Jul 2017 23:30:33 +0200 Received: from p5dec20b4.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.32.180) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 12 Jul 2017 23:30:33 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Wed, 12 Jul 2017 23:30:32 +0200 Cc: Fred Baker , Bob Briscoe , G Fairhurst , tcpm IETF list , tsvwg IETF list , tsvwg-chairs , tsv-ads , tcpm-chairs Content-Transfer-Encoding: quoted-printable Message-Id: <791F99EC-0103-4BA6-B9AD-2CC1A5EF82E7@kuehlewind.net> References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> <49200576-B166-4FE9-8B5D-36ECA5509364@erg.abdn.ac.uk> <99989ba2-4dae-eb6e-90fe-cb4b19f20594@bobbriscoe.net> <595BB715.70700@erg.abdn.ac.uk> To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20170712213033.5959.66914@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [tsvwg] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 21:30:37 -0000 Hi all, let=E2=80=99s still meet in the AD office hours because it would = actually be good to chat before the tcpm and tsvwg sessions. And then we = maybe can catch up with Micheal at the receipt. Who would able able to = be there Sunday at 3pm (besides Micheal)? If we need another meeting, I can probably move my Monday lunch meeting = and we could do Monday lunch right after the tcpm session...? Mirja > Am 12.07.2017 um 18:32 schrieb Spencer Dawkins at IETF = : >=20 > Dear All, >=20 > On Tue, Jul 11, 2017 at 4:08 PM, Fred Baker = wrote: >=20 >=20 > > On Jul 11, 2017, at 2:00 PM, Bob Briscoe = wrote: > > > > Fred, > > For Wed, IETF agenda says "1200-1300 WG Chairs Forum" > > I assume some tcpm & tsvwg WG chairs plan to attend? >=20 > My comment was in response to yours, that herding WG Chairs and ADs = into a common space was "interesting". That is an interval in which we = are all supposed to be in one room (actuality may vary). >=20 > I hadn't thought Fred's suggestion through, until I realized that I = haven't seen an e-mail for the WG Chairs Forum with an agenda YET (which = is disturbing, but not relevant except that it makes us huddling at the = beginning, end, or even middle of that time seem very reasonable). If = the answer is that the chairs are gonna eat lunch and chat in small = groups, that will be very easy for me to break away from. >=20 > So, yes, please continue to discuss via e-mail, but Wednesday lunch = will be a time I can be cornered. >=20 > Spencer From nobody Wed Jul 12 14:42:49 2017 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 C6048131788 for ; Wed, 12 Jul 2017 14:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 aoSgsUP-6F96 for ; Wed, 12 Jul 2017 14:42:41 -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 7ED4F12ECC3 for ; Wed, 12 Jul 2017 14:42:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=jpmFuT1w/uEvTH/+EI8vSQXaTooSsnuoTExpyLXcG/RIJhdKiqVBGCbecYQM9ZE8pNWUeC7PS6AP3xSMgroT5ZMt3QPA4vGmBMsITuSRYAQdwhfkAG7fBq9QYsqxt/08JOas/iXnfVHcFaWay4KnGSCrO4iwDBq6hpw6qSWkxJ0=; 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 7173 invoked from network); 12 Jul 2017 23:35:57 +0200 Received: from p5dec20b4.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.32.180) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 12 Jul 2017 23:35:57 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <791F99EC-0103-4BA6-B9AD-2CC1A5EF82E7@kuehlewind.net> Date: Wed, 12 Jul 2017 23:35:56 +0200 Cc: Fred Baker , Bob Briscoe , G Fairhurst , tsvwg-chairs , tsv-ads , tcpm-chairs , Spencer Dawkins at IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> <49200576-B166-4FE9-8B5D-36ECA5509364@erg.abdn.ac.uk> <99989ba2-4dae-eb6e-90fe-cb4b19f20594@bobbriscoe.net> <595BB715.70700@erg.abdn.ac.uk> <791F99EC-0103-4BA6-B9AD-2CC1A5EF82E7@kuehlewind.net> To: tsvwg IETF list , tcpm IETF list X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20170712213557.6137.72374@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [tsvwg] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 21:42:42 -0000 Hi again, I just realized that both the tcpm and tsvwg lists are both (still) = cc=E2=80=99ed. For course everybody who want to chat about ECN (and ECN = Nonce/accECN) is invited to join but I think we mainly should have a = chat with the wg chairs and the AccECN authors. Mirja > Am 12.07.2017 um 23:30 schrieb Mirja Kuehlewind (IETF) = : >=20 > Hi all, >=20 > let=E2=80=99s still meet in the AD office hours because it would = actually be good to chat before the tcpm and tsvwg sessions. And then we = maybe can catch up with Micheal at the receipt. Who would able able to = be there Sunday at 3pm (besides Micheal)? >=20 > If we need another meeting, I can probably move my Monday lunch = meeting and we could do Monday lunch right after the tcpm session...? >=20 > Mirja >=20 >=20 >=20 >> Am 12.07.2017 um 18:32 schrieb Spencer Dawkins at IETF = : >>=20 >> Dear All, >>=20 >> On Tue, Jul 11, 2017 at 4:08 PM, Fred Baker = wrote: >>=20 >>=20 >>> On Jul 11, 2017, at 2:00 PM, Bob Briscoe = wrote: >>>=20 >>> Fred, >>> For Wed, IETF agenda says "1200-1300 WG Chairs Forum" >>> I assume some tcpm & tsvwg WG chairs plan to attend? >>=20 >> My comment was in response to yours, that herding WG Chairs and ADs = into a common space was "interesting". That is an interval in which we = are all supposed to be in one room (actuality may vary). >>=20 >> I hadn't thought Fred's suggestion through, until I realized that I = haven't seen an e-mail for the WG Chairs Forum with an agenda YET (which = is disturbing, but not relevant except that it makes us huddling at the = beginning, end, or even middle of that time seem very reasonable). If = the answer is that the chairs are gonna eat lunch and chat in small = groups, that will be very easy for me to break away from. >>=20 >> So, yes, please continue to discuss via e-mail, but Wednesday lunch = will be a time I can be cornered. >>=20 >> Spencer >=20 From nobody Wed Jul 12 18:29:37 2017 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 77028129A96 for ; Wed, 12 Jul 2017 18:29:35 -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 bioLXLyASziZ for ; Wed, 12 Jul 2017 18:29:33 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::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 97ED0120726 for ; Wed, 12 Jul 2017 18:29:33 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id c73so21216232pfk.2 for ; Wed, 12 Jul 2017 18:29:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=RhlBdGu831zzGOZw0VmBBSUhL/MwPvvLh2gDfjIr0mk=; b=Uz4x9v6UeL5Rb9bYPQWERUGQJMm24fZuaCX6iBof69QaMp4vcWDRDO9J/YaNqUqqb2 LgL+8vLg58vp6v9O9MEaGVs0LS+NW560g7PUzXNgJ5i7z9Y6rcs9oH6RSBVbnLZU4wJD vKvMPrBWlx97nuRLczecmsJguOeKMeEx02YjpHe8hjKkUTlajzNhMTDtfBOzHnzecEi6 daq1IQJaEqou5/4poRqNGDfPMW7AeneGkLR55yKxkIIK1BuaWjWoIYHRryijXKMRT7Vq 9ioCnMKYx+wl0YUb0hlzNo7mF7MPMjXlvUmn+TlrlJPpi9ZN+5Qo8SidtWQ7yHE9mZqW x3Hg== 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:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=RhlBdGu831zzGOZw0VmBBSUhL/MwPvvLh2gDfjIr0mk=; b=L97edVra7KAGdbpxBY3H8bYcD0mcklRqbD3hb00Yng156sCX+AJkIaVGz7NlcG/Axu c6Jj64IvHjLByAUMWEOFHXiYqOAGS+9Zevg/KdDrsvqa2ViJkzDcM/hUFJnRdfyQxydu iuqqdOiCq3XIrVFP+0hhE67VI4gtnS52y60jgsQ7/REF5hgnr5DRR6BbqN7lHxFevLd2 XcLy+vqxqRjCERmZMxJWqAWYmyY0flKqd00Hbv9mbMoujssJ3aksCrWYKxpoebbRqsKa LOGIfzN2AhMr6VuS4wZNIuKe2RJbIEN9ncPCFMIoihccSpD0RXIQOg3tySYnYqtZnxW3 bDqg== X-Gm-Message-State: AIVw11183kcIUjztXSd6/KACgSGmPUje5yQDXtAEdxUoF1k8yWXsUqdB 5w/BfzyeilsLO7iW X-Received: by 10.99.131.193 with SMTP id h184mr6545980pge.80.1499909372884; Wed, 12 Jul 2017 18:29:32 -0700 (PDT) Received: from [192.168.178.21] ([118.148.68.108]) by smtp.gmail.com with ESMTPSA id g12sm6378676pgr.16.2017.07.12.18.29.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jul 2017 18:29:32 -0700 (PDT) To: tsvwg@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 13 Jul 2017 13:29:35 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.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] Remarking of LE (draft-ietf-tsvwg-le-phb-02) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 01:29:35 -0000 > So a useful strategy would be to always remark CS1 to LE, when > CS1 was used for RFC3662/LE to get rid of the ambiguity of CS1. Yes, but I think it's better called a heuristic, not a strategy. Any solution that does not involve an explicit agreement between two neighbouring domains is really a "best guess". We could also say that a useful heuristic would be to always leave CS1 as it is, if CS1 was *not* previously known to be used for LE at that interface. Or alternatively, bleach it to CS0. If you don't definitively know the policy of the domain that forwards a packet to you, whatever you do is a guess. If you do know that policy, you can do the right thing. Regards Brian On 13/07/2017 00:46, Bless, Roland (TM) wrote: > Hi, >=20 > In https://mailarchive.ietf.org/arch/msg/tsvwg/d70Z9JoLOWtQCadD_uA9pJ9t= Bx4 > David made the comment: >> ****I definitely want to see broader WG discussion of that =E2=80=9CMU= ST remark=E2=80=9D requirement, as it=E2=80=99s not backwards compatible = with RFC 4594 - at a minimum, some thought should be applied to transitio= n and mixing networks that use CS1 and the new LE DSCP. >=20 > Here are some general thoughts on remarking of the LE PHB. >=20 > If correctly implemented LE (lower effort) traffic will not harm BE > (best-effort) traffic, because BE traffic will preempt LE traffic. > DiffServ Domains that are not implementing LE may carry LE traffic > within their BE aggregate. They must be aware, however, that the > "no harm" property of LE is not given. >=20 > There are now two types of LE users: > LE-min: this user does not care if LE packet experience better > forwarding treatment, so promoting them to BE is ok. >=20 > LE-strict: this user wants to be sure that LE is obeying the > "no harm" property, i.e., only otherwise unused resources > should be consumed by LE traffic. >=20 > The question is now, how the LE-strict user can detect whether > the packets were promoted to BE. Let's assume we have two > different DSCPs LE-min and LE-strict. Then: > LE-min: can be promoted to BE, but should stay marked as LE-min > to let subsequent domains handle it correctly as LE traffic > LE-strict: should not be promoted to BE. Now we have two cases: > a) DS domain remarks to BE and passes it as BE to the next D= S > domain. The receiver could probably use some feedback > channel to let the sender know that this remarking > happened. > An appropriate reaction should be left to the application= > then (continue, abort, use LE transport protocol, > rate limit, etc.) =3D> E2E principle. > b) DS domain simply drops the LE packet. >=20 > I think b) is not useful. >=20 > Coming back to the question above: > A DS domain must be able to map DSCP to PHB freely (see RFC 2474). > So if a DS domain currently supports LE and uses the CS1 DSCP for that,= > it should support the new LE DSCP, too. > The current draft says > A DS domain that still uses DSCP CS1 for marking LE traffic > (including Low Priority-Data as defined in [RFC4594] or the old > definition in [RFC3662]) MUST remark traffic to the LE DSCP '000010'= > at the egress to the next DS domain. This increases the probability= > that the DSCP is preserved end-to-end, whereas a CS1 marked packet > may be remarked by the default DSCP if the next domain is applying > DiffServ-intercon [RFC8100]. >=20 > So a useful strategy would be to always remark CS1 to LE, when > CS1 was used for RFC3662/LE to get rid of the ambiguity of CS1. > More input welcome. >=20 > Regards, > Roland >=20 >=20 From nobody Thu Jul 13 08:02:33 2017 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 29F51131907 for ; Thu, 13 Jul 2017 08:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk 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 Rq0xqOI1u42m for ; Thu, 13 Jul 2017 08:02:25 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E04DC1316B3 for ; Thu, 13 Jul 2017 08:02:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1499958143; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=Pyf7feeeyw1S5YCuQ2d76mJQ6LF4gZAnocED4hKDnN0=; b=NdD6A3wpB4yL43kPc0UZpaFNTlTm18ZjIwhI0l84dcbdLklCFLgByP89p8a0Xq+POBUEX8+qKrbRHrT1mhdUeJDeigFZf9y+kpsmnatspaGHh8KwMcBhBh4BxB4wYk7wVigOy+wJB+vujc1sllFA3l72oYR0l3rsExyO0jkKytg= Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0214.outbound.protection.outlook.com [213.199.154.214]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-17-YpFPblteMw-2fC_1lG7VWw-1; Thu, 13 Jul 2017 16:02:18 +0100 Received: from VI1PR07MB1151.eurprd07.prod.outlook.com (10.163.168.148) by VI1PR07MB1565.eurprd07.prod.outlook.com (10.165.239.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Thu, 13 Jul 2017 15:02:17 +0000 Received: from VI1PR07MB1151.eurprd07.prod.outlook.com ([fe80::847d:274a:70c3:9d85]) by VI1PR07MB1151.eurprd07.prod.outlook.com ([fe80::847d:274a:70c3:9d85%13]) with mapi id 15.01.1282.004; Thu, 13 Jul 2017 15:02:17 +0000 From: Tim Chown To: Brian E Carpenter CC: "tsvwg@ietf.org" Thread-Topic: [tsvwg] Remarking of LE (draft-ietf-tsvwg-le-phb-02) Thread-Index: AQHS+wzxRcGYyfej002cX52avJZPO6JQ+N6AgADjDoA= Date: Thu, 13 Jul 2017 15:02:17 +0000 Message-ID: <9461BD66-BCE3-450B-A60F-D681CEA3D42E@jisc.ac.uk> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [193.62.83.224] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1565; 20:9GWK0G5CTNDv7w+mZqC8JbR/pbpbVJPee1Q50ZzEmX+1VxuvVDtY6Ft6qptcmplUXp+9t1LZ2JmSF4dJ5JjtLQLxEmngOgA1ehVfX7ftbgDyrzj2Y2Mp5M67Oyg6E8U2riH21gu33oVpd19Cfx76dQtPlS5Is8JLYARJFRAhYEY= x-ms-office365-filtering-correlation-id: 33d6b3c8-234f-4483-6e80-08d4ca002728 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:VI1PR07MB1565; x-ms-traffictypediagnostic: VI1PR07MB1565: x-exchange-antispam-report-test: UriScan:(133145235818549)(236129657087228)(131327999870524)(148574349560750); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123562025)(20161123560025)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB1565; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB1565; x-forefront-prvs: 0367A50BB1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39450400003)(39410400002)(39840400002)(24454002)(83716003)(6246003)(8676002)(229853002)(2906002)(50226002)(81166006)(305945005)(478600001)(7736002)(102836003)(3846002)(230783001)(6116002)(2950100002)(6916009)(42882006)(5250100002)(3660700001)(966005)(53546010)(68736007)(8936002)(25786009)(14454004)(3280700002)(5660300001)(72206003)(74482002)(50986999)(82746002)(189998001)(76176999)(66066001)(4326008)(2900100001)(6506006)(6306002)(53936002)(6486002)(99286003)(33656002)(6436002)(39060400002)(6512007)(110136004)(57306001)(38730400002)(36756003)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB1565; H:VI1PR07MB1151.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <67CFAFD00FF65141B1D3E36775077E8C@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2017 15:02:17.0604 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1565 X-MC-Unique: YpFPblteMw-2fC_1lG7VWw-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [tsvwg] Remarking of LE (draft-ietf-tsvwg-le-phb-02) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 15:02:29 -0000 SGksDQoNCj4gT24gMTMgSnVsIDIwMTcsIGF0IDAyOjI5LCBCcmlhbiBFIENhcnBlbnRlciA8YnJp YW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+PiBTbyBhIHVzZWZ1bCBzdHJh dGVneSB3b3VsZCBiZSB0byBhbHdheXMgcmVtYXJrIENTMSB0byBMRSwgd2hlbg0KPj4gQ1MxIHdh cyB1c2VkIGZvciBSRkMzNjYyL0xFIHRvIGdldCByaWQgb2YgdGhlIGFtYmlndWl0eSBvZiBDUzEu DQo+IA0KPiBZZXMsIGJ1dCBJIHRoaW5rIGl0J3MgYmV0dGVyIGNhbGxlZCBhIGhldXJpc3RpYywg bm90IGEgc3RyYXRlZ3kuDQo+IEFueSBzb2x1dGlvbiB0aGF0IGRvZXMgbm90IGludm9sdmUgYW4g ZXhwbGljaXQgYWdyZWVtZW50IGJldHdlZW4NCj4gdHdvIG5laWdoYm91cmluZyBkb21haW5zIGlz IHJlYWxseSBhICJiZXN0IGd1ZXNzIi4NCj4gDQo+IFdlIGNvdWxkIGFsc28gc2F5IHRoYXQgYSB1 c2VmdWwgaGV1cmlzdGljIHdvdWxkIGJlIHRvIGFsd2F5cw0KPiBsZWF2ZSBDUzEgYXMgaXQgaXMs IGlmIENTMSB3YXMgKm5vdCogcHJldmlvdXNseSBrbm93biB0byBiZSB1c2VkDQo+IGZvciBMRSBh dCB0aGF0IGludGVyZmFjZS4gT3IgYWx0ZXJuYXRpdmVseSwgYmxlYWNoIGl0IHRvIENTMC4NCj4g SWYgeW91IGRvbid0IGRlZmluaXRpdmVseSBrbm93IHRoZSBwb2xpY3kgb2YgdGhlIGRvbWFpbiB0 aGF0DQo+IGZvcndhcmRzIGEgcGFja2V0IHRvIHlvdSwgd2hhdGV2ZXIgeW91IGRvIGlzIGEgZ3Vl c3MuIElmIHlvdQ0KPiBkbyBrbm93IHRoYXQgcG9saWN5LCB5b3UgY2FuIGRvIHRoZSByaWdodCB0 aGluZy4NCg0KVGhhdCBzb3VuZHMgZmFpciBlbm91Z2guDQoNCldoZW4gTEJFIHdhcyBiZWluZyB0 ZXN0ZWQgeWVhcnMgYWdvIG9uIEdFQU5UIGFuZCB2YXJpb3VzIE5SRU5zLCB3ZSBkaWQgYWxzbyBh Z3JlZSBhcyDigJxjb25zZW50aW5nIG5ldHdvcmtz4oCdIHRoYXQgQ1MxIChhcyB0aGVuKSB3b3Vs ZCBub3QgYmUgYmxlYWNoZWQsIHNvIHRoZXJlIHdhcyBEU0NQIHRyYW5zcGFyZW5jeSBmb3IgcGFy dGljaXBhdGluZyBuZXR3b3JrcywgZXZlbiBpZiBub3QgYWxsIHRoZSBlbGVtZW50cyB3ZXJlIGlt cGxlbWVudGluZyB0aGUgcXVldWluZyBwcmlvcml0aXNhdGlvbi4gDQoNClRpbQ0KDQo+IA0KPiBS ZWdhcmRzDQo+ICAgQnJpYW4NCj4gDQo+IE9uIDEzLzA3LzIwMTcgMDA6NDYsIEJsZXNzLCBSb2xh bmQgKFRNKSB3cm90ZToNCj4+IEhpLA0KPj4gDQo+PiBJbiBodHRwczovL21haWxhcmNoaXZlLmll dGYub3JnL2FyY2gvbXNnL3RzdndnL2Q3MFo5Sm9MT1d0UUNhZERfdUE5cEo5dEJ4NA0KPj4gRGF2 aWQgbWFkZSB0aGUgY29tbWVudDoNCj4+PiAqKioqSSBkZWZpbml0ZWx5IHdhbnQgdG8gc2VlIGJy b2FkZXIgV0cgZGlzY3Vzc2lvbiBvZiB0aGF0IOKAnE1VU1QgcmVtYXJr4oCdIHJlcXVpcmVtZW50 LCBhcyBpdOKAmXMgbm90IGJhY2t3YXJkcyBjb21wYXRpYmxlIHdpdGggUkZDIDQ1OTQgLSBhdCBh IG1pbmltdW0sIHNvbWUgdGhvdWdodCBzaG91bGQgYmUgYXBwbGllZCB0byB0cmFuc2l0aW9uIGFu ZCBtaXhpbmcgbmV0d29ya3MgdGhhdCB1c2UgQ1MxIGFuZCB0aGUgbmV3IExFIERTQ1AuDQo+PiAN Cj4+IEhlcmUgYXJlIHNvbWUgZ2VuZXJhbCB0aG91Z2h0cyBvbiByZW1hcmtpbmcgb2YgdGhlIExF IFBIQi4NCj4+IA0KPj4gSWYgY29ycmVjdGx5IGltcGxlbWVudGVkIExFIChsb3dlciBlZmZvcnQp IHRyYWZmaWMgd2lsbCBub3QgaGFybSBCRQ0KPj4gKGJlc3QtZWZmb3J0KSB0cmFmZmljLCBiZWNh dXNlIEJFIHRyYWZmaWMgd2lsbCBwcmVlbXB0IExFIHRyYWZmaWMuDQo+PiBEaWZmU2VydiBEb21h aW5zIHRoYXQgYXJlIG5vdCBpbXBsZW1lbnRpbmcgTEUgbWF5IGNhcnJ5IExFIHRyYWZmaWMNCj4+ IHdpdGhpbiB0aGVpciBCRSBhZ2dyZWdhdGUuIFRoZXkgbXVzdCBiZSBhd2FyZSwgaG93ZXZlciwg dGhhdCB0aGUNCj4+ICJubyBoYXJtIiBwcm9wZXJ0eSBvZiBMRSBpcyBub3QgZ2l2ZW4uDQo+PiAN Cj4+IFRoZXJlIGFyZSBub3cgdHdvIHR5cGVzIG9mIExFIHVzZXJzOg0KPj4gTEUtbWluOiB0aGlz IHVzZXIgZG9lcyBub3QgY2FyZSBpZiBMRSBwYWNrZXQgZXhwZXJpZW5jZSBiZXR0ZXINCj4+IGZv cndhcmRpbmcgdHJlYXRtZW50LCBzbyBwcm9tb3RpbmcgdGhlbSB0byBCRSBpcyBvay4NCj4+IA0K Pj4gTEUtc3RyaWN0OiB0aGlzIHVzZXIgd2FudHMgdG8gYmUgc3VyZSB0aGF0IExFIGlzIG9iZXlp bmcgdGhlDQo+PiAibm8gaGFybSIgcHJvcGVydHksIGkuZS4sIG9ubHkgb3RoZXJ3aXNlIHVudXNl ZCByZXNvdXJjZXMNCj4+IHNob3VsZCBiZSBjb25zdW1lZCBieSBMRSB0cmFmZmljLg0KPj4gDQo+ PiBUaGUgcXVlc3Rpb24gaXMgbm93LCBob3cgdGhlIExFLXN0cmljdCB1c2VyIGNhbiBkZXRlY3Qg d2hldGhlcg0KPj4gdGhlIHBhY2tldHMgd2VyZSBwcm9tb3RlZCB0byBCRS4gTGV0J3MgYXNzdW1l IHdlIGhhdmUgdHdvDQo+PiBkaWZmZXJlbnQgRFNDUHMgTEUtbWluIGFuZCBMRS1zdHJpY3QuIFRo ZW46DQo+PiBMRS1taW46IGNhbiBiZSBwcm9tb3RlZCB0byBCRSwgYnV0IHNob3VsZCBzdGF5IG1h cmtlZCBhcyBMRS1taW4NCj4+ICAgICAgICB0byBsZXQgc3Vic2VxdWVudCBkb21haW5zIGhhbmRs ZSBpdCBjb3JyZWN0bHkgYXMgTEUgdHJhZmZpYw0KPj4gTEUtc3RyaWN0OiBzaG91bGQgbm90IGJl IHByb21vdGVkIHRvIEJFLiBOb3cgd2UgaGF2ZSB0d28gY2FzZXM6DQo+PiAgICAgICAgICAgYSkg RFMgZG9tYWluIHJlbWFya3MgdG8gQkUgYW5kIHBhc3NlcyBpdCBhcyBCRSB0byB0aGUgbmV4dCBE Uw0KPj4gICAgICAgICAgICAgIGRvbWFpbi4gVGhlIHJlY2VpdmVyIGNvdWxkIHByb2JhYmx5IHVz ZSBzb21lIGZlZWRiYWNrDQo+PiAgICAgICAgICAgICAgY2hhbm5lbCB0byBsZXQgdGhlIHNlbmRl ciBrbm93IHRoYXQgdGhpcyByZW1hcmtpbmcNCj4+ICAgICAgICAgICAgICBoYXBwZW5lZC4NCj4+ ICAgICAgICAgICAgICBBbiBhcHByb3ByaWF0ZSByZWFjdGlvbiBzaG91bGQgYmUgbGVmdCB0byB0 aGUgYXBwbGljYXRpb24NCj4+ICAgICAgICAgICAgICB0aGVuIChjb250aW51ZSwgYWJvcnQsIHVz ZSBMRSB0cmFuc3BvcnQgcHJvdG9jb2wsDQo+PiAgICAgICAgICAgICAgcmF0ZSBsaW1pdCwgZXRj LikgPT4gRTJFIHByaW5jaXBsZS4NCj4+ICAgICAgICAgICBiKSBEUyBkb21haW4gc2ltcGx5IGRy b3BzIHRoZSBMRSBwYWNrZXQuDQo+PiANCj4+IEkgdGhpbmsgYikgaXMgbm90IHVzZWZ1bC4NCj4+ IA0KPj4gQ29taW5nIGJhY2sgdG8gdGhlIHF1ZXN0aW9uIGFib3ZlOg0KPj4gQSBEUyBkb21haW4g bXVzdCBiZSBhYmxlIHRvIG1hcCBEU0NQIHRvIFBIQiBmcmVlbHkgKHNlZSBSRkMgMjQ3NCkuDQo+ PiBTbyBpZiBhIERTIGRvbWFpbiBjdXJyZW50bHkgc3VwcG9ydHMgTEUgYW5kIHVzZXMgdGhlIENT MSBEU0NQIGZvciB0aGF0LA0KPj4gaXQgc2hvdWxkIHN1cHBvcnQgdGhlIG5ldyBMRSBEU0NQLCB0 b28uDQo+PiBUaGUgY3VycmVudCBkcmFmdCBzYXlzDQo+PiAgIEEgRFMgZG9tYWluIHRoYXQgc3Rp bGwgdXNlcyBEU0NQIENTMSBmb3IgbWFya2luZyBMRSB0cmFmZmljDQo+PiAgIChpbmNsdWRpbmcg TG93IFByaW9yaXR5LURhdGEgYXMgZGVmaW5lZCBpbiBbUkZDNDU5NF0gb3IgdGhlIG9sZA0KPj4g ICBkZWZpbml0aW9uIGluIFtSRkMzNjYyXSkgTVVTVCByZW1hcmsgdHJhZmZpYyB0byB0aGUgTEUg RFNDUCAnMDAwMDEwJw0KPj4gICBhdCB0aGUgZWdyZXNzIHRvIHRoZSBuZXh0IERTIGRvbWFpbi4g IFRoaXMgaW5jcmVhc2VzIHRoZSBwcm9iYWJpbGl0eQ0KPj4gICB0aGF0IHRoZSBEU0NQIGlzIHBy ZXNlcnZlZCBlbmQtdG8tZW5kLCB3aGVyZWFzIGEgQ1MxIG1hcmtlZCBwYWNrZXQNCj4+ICAgbWF5 IGJlIHJlbWFya2VkIGJ5IHRoZSBkZWZhdWx0IERTQ1AgaWYgdGhlIG5leHQgZG9tYWluIGlzIGFw cGx5aW5nDQo+PiAgIERpZmZTZXJ2LWludGVyY29uIFtSRkM4MTAwXS4NCj4+IA0KPj4gU28gYSB1 c2VmdWwgc3RyYXRlZ3kgd291bGQgYmUgdG8gYWx3YXlzIHJlbWFyayBDUzEgdG8gTEUsIHdoZW4N Cj4+IENTMSB3YXMgdXNlZCBmb3IgUkZDMzY2Mi9MRSB0byBnZXQgcmlkIG9mIHRoZSBhbWJpZ3Vp dHkgb2YgQ1MxLg0KPj4gTW9yZSBpbnB1dCB3ZWxjb21lLg0KPj4gDQo+PiBSZWdhcmRzLA0KPj4g Um9sYW5kDQo+PiANCj4+IA0KPiANCg0K From nobody Thu Jul 13 11:01:24 2017 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 1AE0D12ECB4 for ; Thu, 13 Jul 2017 11:01:23 -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, RP_MATCHES_RCVD=-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 7yfSt7YE2fkF for ; Thu, 13 Jul 2017 11:01:20 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id A250C127076 for ; Thu, 13 Jul 2017 11:01:20 -0700 (PDT) Received: from MacBook-2.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id CA4221B0E79C for ; Thu, 13 Jul 2017 20:55:16 +0100 (BST) Message-ID: <5967B58F.1090900@erg.abdn.ac.uk> Date: Thu, 13 Jul 2017 19:01:51 +0100 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: tsvwg WG Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [tsvwg] WGLC comments onn DS IEEE 802.11 (draft-ietf-tsvwg-ieee-802-11). X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 18:01:23 -0000 * I have read the ID during the second WGLC and I think this address all the things I commented upon in the previous version. I have a few LC comments on the latest text: (1) TEXT: However, by default, packets marked DSCP CS6 will be mapped to UP 6 and serviced within the Voice Access Category (AC_VO); such mapping and servicing is a contradiction… - I think it is not completely clear what “by default” means, that is whether the text is the recommended default from this spec or some other recommendation. Could you tweak the words to clarify this - so that it is clear it is the latter? (2) In section 1.6, definition of DSCP. For the avoidance of doubt, I think it probably is worth noting “The 6-bit DSCP field is carried in a byte of the IP header together with the 2-bit Explicit Congestion Notification (ECN) field.” - This may help alert people that the bit manipulation describes also has to preserve the ECN field. (3) Further NiT: - Please define /GSMA/. (4) I suspect the security section may benefit from a better definition of the case where the 802.11 network forms the edge of a DS domain. I suspect other people will suggest text on this. Gorry ———————* From nobody Sat Jul 15 09:41:06 2017 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 A4D23127078 for ; Sat, 15 Jul 2017 09:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=AFeLej/1; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=cmN8WiSi 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 0UFnPmVxFn6f for ; Sat, 15 Jul 2017 09:41:02 -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 5F086124D37 for ; Sat, 15 Jul 2017 09:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1500136560; x=1531672560; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Sp5UC/K2QNOS34ZFGeQ5j73M6TY0rZKicXJqZy8ADuk=; b=AFeLej/1W1zvSytbR3DtlWfZ4/hmro7c6qkdc0IY/kDK4DKIYbMqVOg7 3fCWWsPwxvBoTjFeVTedN2065hAxoBy2bKRvkhkl/Wm+z6liexvCHwNv0 izexOd3zVLx6MkbZTxHMHmetSjoR+zBZCqSCQB+wLyEeqJ82T1khOZJt6 Y=; 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; 15 Jul 2017 11:36:00 -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; 15 Jul 2017 22:40:58 +0600 Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v6FGepMZ030588 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 15 Jul 2017 12:41:00 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v6FGepMZ030588 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1500136860; bh=ODS+tF1AjKbtwIsWpUS5EuNmSiU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=cmN8WiSihMbKV8umMtjalIWm1FHWkc/TpCUrPpaqVgTffU6XBPsA8d/NP18x3PF7/ /1REK98L17lyc9tf6SNdaNgmDUp/ipCCCRrpPe95nfw88vFN2XUdT1173YRzjGOjmR 0IBqTSfpkf8AYKMlMRo9chichdSRjkvWmwZL3E1U= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v6FGepMZ030588 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd53.lss.emc.com (RSA Interceptor); Sat, 15 Jul 2017 12:40:20 -0400 Received: from MXHUB310.corp.emc.com (MXHUB310.corp.emc.com [10.146.3.36]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v6FGeL95016836 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Sat, 15 Jul 2017 12:40:21 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB310.corp.emc.com ([10.146.3.36]) with mapi id 14.03.0352.000; Sat, 15 Jul 2017 12:40:21 -0400 To: G Fairhurst , tsvwg WG Thread-Topic: TSVWG Working Group Last Call (WGLC) on draft-ietf-tsvwg-ieee-802-11 - David Black's comments Thread-Index: AdL9iKwSAOxDD+ndQlSPMOl+i2FRxA== Date: Sat, 15 Jul 2017 16:40:19 +0000 Message-ID: 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [tsvwg] TSVWG Working Group Last Call (WGLC) on draft-ietf-tsvwg-ieee-802-11 - David Black's comments X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 16:41:05 -0000 In general, the -04 draft is much improved from the -01 draft. All of my r= emaining major concerns involve uses of the word "trust" that=20 -- Major Section 3: This document assumes and RECOMMENDS that all wireless access points (as the bridges between wired-and-wireless networks) support the ability to: [... snip ...]=20 o trust DSCP markings set by wireless endpoint devices This instance of "trust" appears to have been overlooked. I suggest chang= ing "trust" to "process." Section 5: o DSCP-Trust at the wireless access point (effectively a 1:1 DSCP- to-DSCP mapping) Aha, the dreaded T-word again. Suggest: DSCP-Trust -> DSCP-Passthrough, a= s that not only removes the T-word, but is also more descriptive. This al= so affects Section 5.3 ... Section 5.3: Change DSCP-Trust -> DSCP-Passthrough in section title. It is generally NOT RECOMMENDED to trust DSCP markings from unauthenticated and unauthorized devices, as these are typically considered untrusted sources. to trust DSCP markings -> to pass through DSCP markings When business requirements and/or technical constraints and/or administrative policies require a trust function at the wireless edge, then it is RECOMMENDED to trust DSCP (over [IEEE.802.11-2016] UP markings) markings in the upstream direction, for the following reasons: I don't understand what a "trust function" is, so this looks like a circula= r statement. Once "trust function" is clarified, change "RECOMMENDED to tr= ust DSCP" to "RECOMMENDED to pass through DSCP" ... but the details of this= clarification are crucial as this text is a potentially serious security h= ole as currently written. A related minor issue turns up in Section 8.1 - see below. Finally, Gorry noted: (4) I suspect the security section may benefit from a better definition= =20 of the case where the 802.11 network forms the edge of a DS domain. I=20 suspect other people will suggest text on this. I suspect that some of the changes suggested in this review towards less us= e of the word "trust" will help with this concern, so I suggest that Gorry = and I both take a look at the resulting text to see whether it suffices. = That said, it would help to add a reference from the security consideration= s text on CS6 and CS7 back to section 5.4, which discusses this "edge of a = DS domain" case. -- Minor Section 2.1: Thus the QoS treatment of packets at the access point will depend on the position of the AP in the network infrastructure and on the WLAN deployment model. Needs specific examples and/or forward references to what changes with AP p= osition. Sections 5.2, 5.3 and 5.4: These sections are effectively discussing alternatives for access point Dif= fserv functionality. That structure (do one of these three) is not clear i= n the draft. Section 8.1: Additionally, Section 5.3 made it clear that it is generally NOT RECOMMENDED to trust DSCP markings from unauthorized and/or unauthenticated devices, as these are typically considered untrusted sources. This is especially relevant for IoT deployments, where tens-of-billions of devices are being connected to IP networks, many of which have little or no security. In the first sentence: "trust" -> "pass through" In the second sentence as written, "many of which" refers to "IP networks" = - I suspect that was not intended, e.g., "tens-of-billions of devices that = may have little or no security are being connected to IP networks" may be c= loser to what was intended. Setting a trust boundary reflective of business objectives and policy, such that traffic from authorized users and/or applications and/or endpoints will be accepted by the network; otherwise packet markings will be "bleached" (i.e. remarked to DSCP DF and/or UP 0). I have some idea of what a "trust boundary" is, but suspect that "traffic c= onditioning policy" may be clearer and closer to what was intended. Section 8.2: Every paragraph in this section is bidirectional in scope, applying to both= wired->wireless and wireless-> wired traffic, except for this paragraph: If such marking/mapping were not controlled, then, for example, a malicious user could cause WLAN DoS by flooding traffic marked CS7 DSCP downstream. This codepoint would map by default to UP 7 and would be assigned to the Voice Access Category (AC_VO). Such a flood could cause Denial-of-Service to not only wireless voice applications, but also to all other traffic classes. I suggest making this paragraph bidirectional by providing the example in b= oth directions and then making it clear that the following paragraph: Therefore, to mitigate such an attack, it is RECOMMENDED that all packets marked to Diffserv Codepoints not in use over the wireless network be mapped to UP 0. applies to both access points and wireless device operating systems. -- Editorial Section 1.1: Note: [RFC4594] is intended to be viewed as a set of "project plans" for building all the (diffserv) furniture that one might want. Thus, it describes different types of traffic expected in IP networks and provides guidance as to what DSCP marking(s) should be associated with each traffic type. As such, this document draws heavily on [RFC4594], [RFC5127], and [RFC8100]. The first sentence seems a bit too informal, suggest: OLD Note: [RFC4594] is intended to be viewed as a set of "project plans" for building all the (diffserv) furniture that one might want. =20 NEW Note: [RFC4594] is intended to be viewed as a framework and guidelines for supporting Diffserv in any network, including wireless networks. Section 2.1: It is important to recognize that the wired-to-wireless edge may or may not equate to the edge of the Diffserv domain. equate to the edge of the Diffserv domain -> function as an edge of a Diffs= erv domain or a domain boundary. Section 8: Initial paragraph seems overly defensive, suggest: OLD The recommendations put forward in this document do not present any additional security concerns that do not already exist in wired and wireless devices. In fact, several of the recommendations made in this document serve to mitigate and protect wired and wireless networks from potential abuse arising from existing vulnerabilities. NEW The recommendations in this document concern existing wired and wireless network functionality, and for that reason do not add significant securi= ty concerns. Some of the recommendations help protect wired and wireless networks from potential abuse, e.g., as discussed further in this sectio= n. Section 8.2: It should be strongly noted that in the wireless deployment model I suggest deleting "It should be strongly noted that"=20 Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of G Fairhurst > Sent: Thursday, July 6, 2017 3:11 AM > To: tsvwg WG > Subject: [tsvwg] TSVWG Working Group Last Call (WGLC) on draft-ietf-tsvwg= - > ieee-802-11-01 to conclude 10th Jul 2017 >=20 > This email announces a second TSVWG Working Group Last Call (WGLC) on: >=20 > DiffServ to IEEE 802.11 Mapping > draft-ietf-tsvwg-ieee-802-11-01 > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11-01 >=20 > This WGLC will last for about 2 weeks weeks. The purpose of this call is > to provide further feedback (if required) on changes made since the > first WGLC concluded. >=20 > Comments should be sent to thetsvwg@ietf.org > list, although purely > editorial comments may be sent directly to the authors. Please cc: the > WG chairs attsvwg-chairs@ietf.org if you > would like the chairs to > track such editorial comments as part of the WGLC process. >=20 > No IPR disclosures have been submitted directly on > draft-ietf-tsvwg-ieee-802-11-01 >=20 > Thanks, > Gorry > (TSVWG Co-Chair) From nobody Sat Jul 15 11:40:21 2017 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 CCAB612F4EA for ; Sat, 15 Jul 2017 11:40:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150014401983.1393.15559965853231394701.idtracker@ietfa.amsl.com> Date: Sat, 15 Jul 2017 11:40:19 -0700 From: IETF Secretariat Archived-At: Subject: [tsvwg] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 18:40:20 -0000 Changed milestone "Submit 'SCTP New Data Chunk' as a Proposed Standard RFC", resolved as "Done". Changed milestone "Submit ‘Explicit Congestion Notification (ECN) Experimentation’ as a Proposed Standard RFC", resolved as "Done". URL: https://datatracker.ietf.org/wg/tsvwg/about/ From nobody Sun Jul 16 03:18:32 2017 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 DBE30126C83 for ; Sun, 16 Jul 2017 03:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.501 X-Spam-Level: X-Spam-Status: No, score=-5.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-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=DlRA7Fgm; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=coasdsAa 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 VscqFyev2PVT for ; Sun, 16 Jul 2017 03:18:28 -0700 (PDT) Received: from esa5.dell-outbound.iphmx.com (esa5.dell-outbound.iphmx.com [68.232.153.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A306F126B6E for ; Sun, 16 Jul 2017 03:18: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=1500199693; x=1531735693; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+dkmsY6sQHO02n5vZPmvnmem/R/PxYwfp1KCEOXfh9o=; b=DlRA7FgmSii+f+UMTbLTYvqoe1RRHEFftuM8MubUAHYpV93LkeSTIRGv sEhV+KXPxNRhlIeN74aJV1MhYSVzxsBVhusr3JGSlyfs8VAQBLzvYbGUy timO1Bid/b1p+l7gDRNeLsnjuRfIcr2U5zQb7rcloYfEp39mGCoxnd2PS E=; Received: from esa5.dell-outbound2.iphmx.com ([68.232.153.203]) by esa5.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jul 2017 05:08:13 -0500 From: "Black, David" Cc: Roland Bless , "tsvwg@ietf.org" , "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa5.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jul 2017 16:16:11 +0600 Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v6GAIOwP023268 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 16 Jul 2017 06:18:26 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v6GAIOwP023268 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1500200306; bh=UOwtYOqnBN+Zy8dQ3I3lS9ivAWM=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=coasdsAap+3RCpEL3E3kAf0d0leVwj7oaGUQAyKV8P0Mmyycnc2VfsAIBhEINkCrQ J7jFKm+SO7U6Cs8+UHFHHjNQmepqGUAPBZkR5Tdt9mWxm3jj2MdE4NjoFEnAh5dILl ClUM4O+6hvgYLZzRuz6hHfliTGieFlQycHooNt/I= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v6GAIOwP023268 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd51.lss.emc.com (RSA Interceptor); Sun, 16 Jul 2017 06:18:11 -0400 Received: from MXHUB309.corp.emc.com (MXHUB309.corp.emc.com [10.146.3.35]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v6GAICmY015208 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Sun, 16 Jul 2017 06:18:12 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB309.corp.emc.com ([10.146.3.35]) with mapi id 14.03.0352.000; Sun, 16 Jul 2017 06:18:11 -0400 To: Brian E Carpenter , "gorry@erg.abdn.ac.uk" Thread-Topic: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? Thread-Index: AQHS9w2oYGABYhJJjEGTO/Xj8Xh1K6JIdlMAgAAFroCAAJ4ogIACg0cAgACbsoCAAAkggIAADh+AgAAYQQCAAJFhAIAA00EAgAh6KiA= Date: Sun, 16 Jul 2017 10:18:11 +0000 Message-ID: References: <595F4D19.9030502@erg.abdn.ac.uk> <011e5fb5-6c83-bb38-e2cb-7fced2cb774a@kit.edu> <595F6F4F.20005@erg.abdn.ac.uk> <74717821-30ae-203b-197b-2455cbf9d4a3@gmail.com> <66425AFB-A929-4A91-90F8-432F4FAE0520@jisc.ac.uk> <59633402.9020907@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.102.251] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 10:18:30 -0000 VHdvIGNvbW1lbnRzIHdpdGggV0cgY2hhaXIgaGF0IE9GRjoNCg0KWzFdIEFzIGFuIGF1dGhvciBv ZiBSRkMgODEwMCAtDQoNCj4gIldlIGFncmVlIHRvIGZvbGxvdyBSRkM4MTAwIiBtaWdodCBiZSBh IG1pbmltYWwgU0xBLiBCdXQNCj4gYWJzZW50IHRoYXQsIHRoZXJlIGlzIHZlcnkgbGl0dGxlIHdl IGNhbiBzYXkuIEknbSBub3QgYXdhcmUNCj4gb2YgYW55IG1lYXN1cmVtZW50IGRhdGEgdGhhdCB3 b3VsZCBoZWxwLCB1bmZvcnR1bmF0ZWx5Lg0KDQpBZGRpbmcgYW4gTEUgdHJhZmZpYyBjbGFzcyB0 byBSRkMgODEwMCBjYW1lIHVwIGR1cmluZyBkaXNjdXNzaW9uIG9mIFJGQyA4MTAwIChpdCB3YXMg cmVmZXJyZWQgdG8gYXMgInNjYXZlbmdlciIgaW4gdGhhdCBkaXNjdXNzaW9uKSwgYW5kIHdhcyBk ZWZlcnJlZCwgZS5nLiwgZHVlIHRvIHRoaXMgRFNDUCBjb2RlcG9pbnQgY29uY2Vybi4gICBJbiBw cmluY2lwbGUsIExFIGNvdWxkIGJlIGFkZGVkIHRvIFJGQyA4MTAwLCBidXQgSSBjYXV0aW9uIHRo YXQgdGhlIHVuZGVybHlpbmcgTVBMUyBUQyAoVHJhZmZpYyBDbGFzcyAtIHNlZSBSRkMgNTQ2Mikg Y29kZXBvaW50IHNwYWNlIGlzIGEgKnZlcnkqIGxpbWl0ZWQgcmVzb3VyY2UuICBUQyBpcyBhIDMt Yml0IGZpZWxkLCBhbmQgc28gYWRkaW5nIGFub3RoZXIgdHJhZmZpYyBjbGFzcyB0byBSRkMgODEw MCB3b3VsZCByZWNvbW1lbmQgdXNlIG9mIHRoZSA1dGggdmFsdWUgb24gYXQgbGVhc3QgaW50ZXJj b25uZWN0cyAtIGRvaW5nIHRoaXMgcmVxdWlyZXMgY2FyZWZ1bCBjb25zaWRlcmF0aW9uLCBpbmNs dWRpbmcgYnkgbmV0d29yayBvcGVyYXRvcnMuDQoNClsyXSBBcyAgYW4gaW5kaXZpZHVhbDogQWxz bywgd2hpbGUgUkZDIDM2NjIgc3VnZ2VzdGVkIHBvc3NpYmxlIHVzZSBvZiBDUzEsIGluIHByYWN0 aWNlLCB0aGF0IHVzZSBvZiBDUzEgZm9yIExFIChMb3cgUHJpb3JpdHkgRGF0YSBUcmFmZmljKSB3 YXMgY29kaWZpZWQgYnkgUkZDIDQ1OTQgKGUuZy4sIHNlZSBTZWN0aW9uIDQuMTApLCBldmVuIHRo b3VnaCBSRkMgNDU5NCBpcyBhbiBJbmZvcm1hdGlvbmFsIFJGQyAoUkZDIDQ1OTQgaXMgd2lkZWx5 IHVzZWQpLg0KDQpUaGFua3MsIC0tRGF2aWQNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiB0c3Z3ZyBbbWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBCcmlhbiBFIENhcnBlbnRlcg0KPiBTZW50OiBNb25kYXksIEp1bHkgMTAsIDIwMTcgNDoz NiBQTQ0KPiBUbzogZ29ycnlAZXJnLmFiZG4uYWMudWsNCj4gQ2M6IFJvbGFuZCBCbGVzcyA8cm9s YW5kLmJsZXNzQGtpdC5lZHU+OyB0c3Z3Z0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3Rzdndn XSBDT01NRU5UIFBMRUFTRTogV2hpY2ggRFNDUCB2YWx1ZSBzaG91bGQgd2UgdXNlIGZvcg0KPiBM RSBQSEI/DQo+IA0KPiA+IG1ha3JpbmcgaW50ZXJkb21haW4gZGlmZnNlcnYgc3VwcG9ydCB1bnBy ZWRpY3RhYmxlLg0KPiANCj4gVGhhdCBpcyB0aGUgd2hvbGUgcG9pbnQsIHJlYWxseS4gSW50ZXJk b21haW4gZGlmZnNlcnYgc3VwcG9ydA0KPiAqaXMqIHVucHJlZGljdGFibGUsIG1vcmUgb3IgbGVz cyBieSBkZWZpbml0aW9uLCB1bmxlc3MgdGhlcmUNCj4gaXMgYW4gU0xBIGluIHBsYWNlIGJldHdl ZW4gdGhlIGRvbWFpbnMgdGhhdCBkZWZpbmVzIHdoYXQgaGFwcGVucw0KPiB0byBwYWNrZXRzIHdp dGggc3BlY2lmaWMgbWFya2luZ3MgYXMgdGhleSBjcm9zcyB0aGUgYm9yZGVyLg0KPiANCj4gIldl IGFncmVlIHRvIGZvbGxvdyBSRkM4MTAwIiBtaWdodCBiZSBhIG1pbmltYWwgU0xBLiBCdXQNCj4g YWJzZW50IHRoYXQsIHRoZXJlIGlzIHZlcnkgbGl0dGxlIHdlIGNhbiBzYXkuIEknbSBub3QgYXdh cmUNCj4gb2YgYW55IG1lYXN1cmVtZW50IGRhdGEgdGhhdCB3b3VsZCBoZWxwLCB1bmZvcnR1bmF0 ZWx5Lg0KPiANCj4gUmVnYXJkcw0KPiAgICBCcmlhbg0KPiANCj4gT24gMTAvMDcvMjAxNyAyMDow MCwgR29ycnkgRmFpcmh1cnN0IHdyb3RlOg0KPiA+IFdoZW4gSSBhc2tlZCB0aGUgcXVlc3Rpb25z IGJlbG93LCBJIGRpZG4ndCByZWFsbHkgaGF2ZSBpbiBtaW5kIGEgYmVhdXR5DQo+ID4gY29udGVz dCwgb3IgdG8gaWRlbnRpZnkgc3F1YXRpbmcgb24gSUFOQS1hbGxvY2F0ZWQgRFNDUCB2YWx1ZXMg YnkNCj4gPiBvdGhlcnMuIE15IGNvbmNlcm4gd2FzIG1vcmUgYWJvdXQgd2lkZWx5IGRlcGxveWlu ZyBhIGNsYXNzIHRoYXQgaGFkDQo+ID4gbG93ZXIgZWZmb3J0LCBhbmQgdGhlIGltcGxpY2F0aW9u cyBvbiBiZWluZyBhYmxlIHRvIHdvcmsgaW50ZXJkb21haW4NCj4gPiB3aXRoIHRyYWZmaWMgbm90 IGludGVuZGVkIG5vdCB0byBiZSAiTEUiLg0KPiA+DQo+ID4gQXQgdGhlIG1vbWVudCwgYW55IHJl bWFya2luZyBpcyBsaWtlbHkgdG8gcmVkdWNlIHRoZSBjbGFzcyBieSB3aGljaA0KPiA+IHRyYWZm aWMgaXMgaWRlbnRpZmllZCwgZS5nLiwgYSBuZXR3b3JrIHJvdXRlciBvbiBwYXRoIGJsZWFjaGlu ZyB0aGUgRFNDUA0KPiA+IHRvIHplcm8gd291bGQgcmVzdWx0IGluIHRoZSBwYWNrZXQgcmVjZWl2 aW5nIHRoZSBkZWZhdWx0IFBIQiB0cmVhdG1lbnQNCj4gPiBmb3IgdGhlIHJlbWFpbmRlciBvZiBp dHMgcGF0aC4gVGhpcyBtYXliZSB3YXNuJ3QgaW50ZW5kZWQsIGJ1dCB0byBtZQ0KPiA+IGl0J3Mg cXVpdGUgT0suIElmIHR3byBwYWNrZXRzIHdlcmUgbWFya2VkIHdpdGggcmVsYXRpdmUgcHJpb3Jp dHkNCj4gPiAoQUYyMSxBRjIyKSBldGMsIGl0IHNlZW1zIGxpa2VseSB0aGF0IGJvdGggd2lsbCBi ZSByZW1hcmtlZCB0byB6ZXJvLCBvcg0KPiA+IHRoYXQgdGhlIHJlbGF0aXZlIHByaW9yaXR5IGlz IHByZXNldmVydmVkLg0KPiA+DQo+ID4gV2hlbiB3ZSBpbnRyb2R1Y2UgYSBMRSBQSEIsIHRoZW4g YW55IHRyYWZmaWMgdGhhdCBmaW5hbGx5IHJlc3VsdHMgaW4gdGhlDQo+ID4gbmV3IExFIGNsYXNz IHdpbGwgcmVjZWl2ZSBsZXNzIHRoYW4gZGVmYXVsdCB0cmVhdG1lbnQgKHdlIGhvcGUhKSBNeQ0K PiA+IGNvbmNlcm4gaXMgd2hldGhlciB0aGVyZSBhcmUgd2lkZWx5IGRlcGxveWVkIHBhdGhvbG9n aWVzIChlc3BlY2lhbGx5IGluDQo+ID4gb2xkIGVxdWlwbWVudCkgdGhhdCB3b3VsZCByZXN1bHQg aW4gc29tZSBjb2RlcG9pbnRzIGJlaW5nIHJlbWFya2VkIHRvDQo+ID4gdGhlIGRlZmF1bHQgUEhC LCB3aGlsZSBvdGhlciBjb2RlcG9pbnRzIGdldCByZW1hcmtlZCB0byBhIExFIFBIQi4gVGhpcw0K PiA+IGNvdWxkIGVhc2lseSAiaW52ZXJ0IiB0aGUgcmVsYXRpdmUgcHJpb3JpdHkgZXhwZWN0ZWQg YnkgYW4gYXBwbGljYXRpb24sDQo+ID4gaW4gd2F5cyB3ZSB3YXJuZWQgYWJvdXQgaW4gdGhlIERB UlQgd29yaywgbWFrcmluZyBpbnRlcmRvbWFpbiBkaWZmc2Vydg0KPiA+IHN1cHBvcnQgdW5wcmVk aWN0YWJsZS4NCj4gPg0KPiA+IEluIHByYWN0aWNlLCBJIGhhdmUgc2VlbiB0aGVyZSBhcmUgbWFu eSBwYXRob2xvZ2llcyB0aGF0IGRlcGxveWVkDQo+ID4gZXF1aXBtZW50IGV4aGliaXRzIC0gSSBz cG9rZSBhYm91dCBzb21lIG9mIHRoaXMgaW4gbWFwcmcgbGFzdCBJRVRGIC0NCj4gPiBlLmcuLCBz b21lIG5vZGVzIHN0aWxsIGltcGxlbWVudCBUb1Mgc2VtYW50aWMgcHJvY2Vzc2luZy4gKFRoaXMg aXMNCj4gPiBkZXByZWNhdGVkISkgSG93ZXZlciwgdGhhdCdzIG5vdCB0aGUgcG9pbnQsIGlmIHRo aXMgcmVtYXJraW5nIGlzIHN0aWxsDQo+ID4gb3V0IHRoZXJlLCB0aGVuIHdlIGNhbiByZWFvbmFi bHkgZXhwZWN0IHNvbWUgcGFja2V0cyB0byBiZSByZW1hcmtlZC4NCj4gPiBUaGlzIHNlZW1zIHBh cnRpY3VsYXJseSB1Z2x5IHdoZW4gd2UgaW50cm9kdWNlIHVzZSBvZiBhIExFIGNvZGVwb2ludA0K PiA+IHRoYXQgd2lsbCBhY3R1YWxseSBGcm9tIHdoYXQgSSB0YWxrZWQgYWJvdXQgaW4gbWFwcmcs IEkgaGF2ZSBhIGZlYXIgdGhhdA0KPiA+IHRoaXMgY2FzZSBjb3VsZCBiZSByYXRoZXIgY29tbW9u IGlmIHdlIGRvIG5vdCB0YWtlIGNhcmUgaW4gc2VsZWN0aW9uIG9mDQo+ID4gdGhlIGNvZGVwb2lu dC4gSSB0aGluayB0aGUgV0cgY2FuIGRhdGEgdG8gdGFsayBhYm91dCB0aGlzLg0KPiA+DQo+ID4g R29ycnkNCj4gPg0KPiA+IC0tLS0NCj4gPg0KPiA+IFRoZSBkcmFmdCBjdXJyZW50bHkgc3VnZ2Vz dHMgdXNpbmcgdGhlIERTQ1AgdmFsdWUgMiwgJzAwMDAxMCcuDQo+ID4NCj4gPiBRdWVzdGlvbiAx OiBJcyB0aGlzIGNvZGVwb2ludCBhIGdvb2QgY2hvaWNlIGZvciB0aGUgVFNWV0cgZ3JvdXAgdG8N Cj4gPiBhc3NpZ24gZm9yIHRoZSBMRSBQSEI/DQo+ID4NCj4gPiAgICBUaGluZ3MgdG8gY29uc2lk ZXI6DQo+ID4gICAgICAtIElzIHRoZSBjb2RlcG9pbnQgY3VycmVudGx5IGJlaW5nIHVzZWQgZm9y IG90aGVyIChub24tc3RhbmRhcmQNCj4gPiBhcHBsaWNhdGlvbnMpIHRoYXQgbWF5IGdldCBpbiB0 aGUgd2F5IG9mIHRoZSBkZXBsb3ltZW50IG9mIHRoZSBMRSBQSEI/DQo+ID4gICAgICAtIElzIHRo ZXJlIGFudCBldmlkZW5jZSB0aGF0IHRoaXMgRFNDUCB2YWx1ZSBpcyBsZXNzIGxpa2VseSB0byBi ZQ0KPiA+IGZvcndhcmRlZCB0aGFuIG90aGVyIHVudXNlZCBjb2RlcG9pbnRzPw0KPiA+ICAgICAg LSBJcyB0aGlzIGNvZGVwb2ludCBvYnNlcnZlZCBpbiB0aGUgd2lsZCBkdWUgdG8gY29tbW9uDQo+ ID4gRFNDUC1tYW5nbGluZyBwYXRob2xvZ2llcyAoc3VjaCBhcyBUb1MtYnl0ZSBibGVhY2hpbmcp Pw0KPiA+DQo+ID4gUXVlc3Rpb24gMjogSXMgdGhlcmUgYW4gYWx0ZXJuYXRlIHVuYXNzaWduZWQg Y29kZXBpbnQgdGhhdCBjb3VsZCBiZQ0KPiA+IGNob3NlbiB0aGF0IHdvdWxkIGdpdmUgYmV0dGVy IG9wcHJvdHVuaXRpZXMgZm9yIGRlcGxveW1lbnQ/DQo+ID4NCj4gPiAgICAgIFRoaW5ncyB0byBj b25zaWRlcjoNCj4gPiAgICAgIC0gQSBjb2RlcG9pbnQgbGVzcyB0aGFuIDcgYXBwZWFycyB0byBo YXZlIGxlc3MgY2hhbmNlIG9mDQo+ID4gRFNDUC1tYW5nbGluZyBwYXRob2xvZ2llcyAoc3VjaCBh cyBUb1MtYnl0ZSBibGVhY2hpbmcpDQo+ID4gICAgICAtIElBTkEgY3VycmVudGx5IGFsbG9jYXRl cyBmcm9tIHBvb2wgMSAoeHh4eHgwKSwgYnV0IHdlIGNvdWxkDQo+ID4gY29uc2lkZXIgYXNraW5n IHRvIHVzZSBwb29sIDMgKCd4eHh4MDEnKSwgZS5nLiwgJzAwMDAwMSdvciAnMDAwMTAxJy4NCj4g Pg0KPiA+IE1lYXN1cmVtZW50IGV4cGVyaWVuY2UgYW5kIHRob3VnaHRzIG9uIHRoaXMgdG9waWMg YXJlIHdlbGNvbWUgb24gdGhlDQo+ID4gbWFpbGluZyBsaXN0IGFoZWFkIG9mIHRoZSBUU1ZXRyBt ZWV0aW5nLiBBdCB0aGlzIG1lZXRpbmcsIEkgd291bGQgbGlrZQ0KPiA+IHRvIHNlZSBzb21lIGRp c2N1c3Npb24gY29uZmlybWluZyB0aGUgY2hvaWNlIG9mIERTQ1AgY29kZXBvaW50IG9yDQo+ID4g c3VnZ2VzdGluZyBhIG1vcmUgYXBwcm9wcmlhdGUgY29kZXBvaW50IGZvciB0aGUgd29ya2luZyBn cm91cCB0byByZXF1ZXN0Lg0KPiA+DQo+ID4gR29ycnkgRmFpcmh1cnN0DQo+ID4gKFRTVldHIENv LUNoYWlyKQ0KPiA+DQo+ID4gV2hlbg0KPiA+DQoNCg== From nobody Sun Jul 16 03:23:32 2017 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 840EA12EC19 for ; Sun, 16 Jul 2017 03:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.501 X-Spam-Level: X-Spam-Status: No, score=-5.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-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=uk/FIQDW; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=rsa.com header.b=VomNxuaz 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 h6W3fWLfx-ha for ; Sun, 16 Jul 2017 03:23: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 B5C4A126DC2 for ; Sun, 16 Jul 2017 03:23: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=1500200595; x=1531736595; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=6+pMrHkOEPtIDOz5McCUIAIWU6YBPTsynVperT9eUnI=; b=uk/FIQDWPEnm1J+Dd4n0qUADIhHCYGHcHVgnxJPmAN5Hav0elbioQW4l fkZx26aYkMvXzGOhdcWx9RR8s+rHT4NOr2NiM4nCKA2sbe6EjIFBNHdEz dSGFLDU8M8cG2DYMOdsas3PzLdeA7Ah9dMVtDQ8Xm6M/5EfZHT/0BZv8i s=; 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; 16 Jul 2017 05:23:14 -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; 16 Jul 2017 16:23:13 +0600 Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd05.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v6GANQFc017726 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 16 Jul 2017 06:23:26 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com v6GANQFc017726 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=rsa.com; s=jan2013; t=1500200607; bh=yMiRCt+m/gOdWXq/Ho+ANdX6w7E=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=VomNxuaz1u498AfPZK/j74dGbqoyTjInr9/DbC5Nlpkw1QT24QK4Y8/mn56j2hfGv Ms50teWwdlXmgrAXgTV5l60X+wd4cm7kz8jhDIQYro17ZY/DMl1CqjMu97La+wut1J KyAEu4RM2Nbhf+5CeLqKfQx2uVdR8MWMEaWLSPZ4= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com v6GANQFc017726 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd06.lss.emc.com (RSA Interceptor) for ; Sun, 16 Jul 2017 06:23:10 -0400 Received: from MXHUB303.corp.emc.com (MXHUB303.corp.emc.com [10.146.3.29]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v6GANDJA012744 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL) for ; Sun, 16 Jul 2017 06:23:13 -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.0352.000; Sun, 16 Jul 2017 06:23:13 -0400 To: "tsvwg@ietf.org" Thread-Topic: [tsvwg] Remarking of LE (draft-ietf-tsvwg-le-phb-02) Thread-Index: AQHS+wzq9exzBVnvuUy23dlj8wYWTaJRO+yAgADjEYCABCVz8A== Date: Sun, 16 Jul 2017 10:23:12 +0000 Message-ID: References: <9461BD66-BCE3-450B-A60F-D681CEA3D42E@jisc.ac.uk> In-Reply-To: <9461BD66-BCE3-450B-A60F-D681CEA3D42E@jisc.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.102.251] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tsvwg] Remarking of LE (draft-ietf-tsvwg-le-phb-02) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 10:23:30 -0000 U21hbGwgY29tbWVudCBhcyBhbiBpbmRpdmlkdWFsIG9uIFJvbGFuZCdzIG9yaWdpbmFsIG1lc3Nh Z2UgaW4gdGhpcyB0aHJlYWQ6DQoNCj4gPj4gTEUtc3RyaWN0OiBzaG91bGQgbm90IGJlIHByb21v dGVkIHRvIEJFLiBOb3cgd2UgaGF2ZSB0d28gY2FzZXM6DQo+ID4+ICAgICAgICAgICBhKSBEUyBk b21haW4gcmVtYXJrcyB0byBCRSBhbmQgcGFzc2VzIGl0IGFzIEJFIHRvIHRoZSBuZXh0IERTDQo+ ID4+ICAgICAgICAgICAgICBkb21haW4uIFRoZSByZWNlaXZlciBjb3VsZCBwcm9iYWJseSB1c2Ug c29tZSBmZWVkYmFjaw0KPiA+PiAgICAgICAgICAgICAgY2hhbm5lbCB0byBsZXQgdGhlIHNlbmRl ciBrbm93IHRoYXQgdGhpcyByZW1hcmtpbmcNCj4gPj4gICAgICAgICAgICAgIGhhcHBlbmVkLg0K PiA+PiAgICAgICAgICAgICAgQW4gYXBwcm9wcmlhdGUgcmVhY3Rpb24gc2hvdWxkIGJlIGxlZnQg dG8gdGhlIGFwcGxpY2F0aW9uDQo+ID4+ICAgICAgICAgICAgICB0aGVuIChjb250aW51ZSwgYWJv cnQsIHVzZSBMRSB0cmFuc3BvcnQgcHJvdG9jb2wsDQo+ID4+ICAgICAgICAgICAgICByYXRlIGxp bWl0LCBldGMuKSA9PiBFMkUgcHJpbmNpcGxlLg0KPiA+PiAgICAgICAgICAgYikgRFMgZG9tYWlu IHNpbXBseSBkcm9wcyB0aGUgTEUgcGFja2V0Lg0KPiA+Pg0KPiA+PiBJIHRoaW5rIGIpIGlzIG5v dCB1c2VmdWwuDQoNCkkgc3Ryb25nbHkgYWdyZWUgdGhhdCBiKSBpcyBhIGJhZCBpZGVhLiAgV2Ug c2hvdWxkIG5vdCBiZSBhZGRpbmcgbmV3IHdheXMgdG8gYmxhY2staG9sZSBuZXR3b3JrIHRyYWZm aWMuLi4NCg0KVGhhbmtzLCAtLURhdmlkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogdHN2d2cgW21haWx0bzp0c3Z3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgVGltIENob3duDQo+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEzLCAyMDE3IDExOjAyIEFNDQo+ IFRvOiBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPg0KPiBD YzogdHN2d2dAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt0c3Z3Z10gUmVtYXJraW5nIG9mIExF IChkcmFmdC1pZXRmLXRzdndnLWxlLXBoYi0wMikNCj4gDQo+IEhpLA0KPiANCj4gPiBPbiAxMyBK dWwgMjAxNywgYXQgMDI6MjksIEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBn bWFpbC5jb20+DQo+IHdyb3RlOg0KPiA+DQo+ID4+IFNvIGEgdXNlZnVsIHN0cmF0ZWd5IHdvdWxk IGJlIHRvIGFsd2F5cyByZW1hcmsgQ1MxIHRvIExFLCB3aGVuDQo+ID4+IENTMSB3YXMgdXNlZCBm b3IgUkZDMzY2Mi9MRSB0byBnZXQgcmlkIG9mIHRoZSBhbWJpZ3VpdHkgb2YgQ1MxLg0KPiA+DQo+ ID4gWWVzLCBidXQgSSB0aGluayBpdCdzIGJldHRlciBjYWxsZWQgYSBoZXVyaXN0aWMsIG5vdCBh IHN0cmF0ZWd5Lg0KPiA+IEFueSBzb2x1dGlvbiB0aGF0IGRvZXMgbm90IGludm9sdmUgYW4gZXhw bGljaXQgYWdyZWVtZW50IGJldHdlZW4NCj4gPiB0d28gbmVpZ2hib3VyaW5nIGRvbWFpbnMgaXMg cmVhbGx5IGEgImJlc3QgZ3Vlc3MiLg0KPiA+DQo+ID4gV2UgY291bGQgYWxzbyBzYXkgdGhhdCBh IHVzZWZ1bCBoZXVyaXN0aWMgd291bGQgYmUgdG8gYWx3YXlzDQo+ID4gbGVhdmUgQ1MxIGFzIGl0 IGlzLCBpZiBDUzEgd2FzICpub3QqIHByZXZpb3VzbHkga25vd24gdG8gYmUgdXNlZA0KPiA+IGZv ciBMRSBhdCB0aGF0IGludGVyZmFjZS4gT3IgYWx0ZXJuYXRpdmVseSwgYmxlYWNoIGl0IHRvIENT MC4NCj4gPiBJZiB5b3UgZG9uJ3QgZGVmaW5pdGl2ZWx5IGtub3cgdGhlIHBvbGljeSBvZiB0aGUg ZG9tYWluIHRoYXQNCj4gPiBmb3J3YXJkcyBhIHBhY2tldCB0byB5b3UsIHdoYXRldmVyIHlvdSBk byBpcyBhIGd1ZXNzLiBJZiB5b3UNCj4gPiBkbyBrbm93IHRoYXQgcG9saWN5LCB5b3UgY2FuIGRv IHRoZSByaWdodCB0aGluZy4NCj4gDQo+IFRoYXQgc291bmRzIGZhaXIgZW5vdWdoLg0KPiANCj4g V2hlbiBMQkUgd2FzIGJlaW5nIHRlc3RlZCB5ZWFycyBhZ28gb24gR0VBTlQgYW5kIHZhcmlvdXMg TlJFTnMsIHdlIGRpZA0KPiBhbHNvIGFncmVlIGFzIOKAnGNvbnNlbnRpbmcgbmV0d29ya3PigJ0g dGhhdCBDUzEgKGFzIHRoZW4pIHdvdWxkIG5vdCBiZQ0KPiBibGVhY2hlZCwgc28gdGhlcmUgd2Fz IERTQ1AgdHJhbnNwYXJlbmN5IGZvciBwYXJ0aWNpcGF0aW5nIG5ldHdvcmtzLCBldmVuIGlmDQo+ IG5vdCBhbGwgdGhlIGVsZW1lbnRzIHdlcmUgaW1wbGVtZW50aW5nIHRoZSBxdWV1aW5nIHByaW9y aXRpc2F0aW9uLg0KPiANCj4gVGltDQo+IA0KPiA+DQo+ID4gUmVnYXJkcw0KPiA+ICAgQnJpYW4N Cj4gPg0KPiA+IE9uIDEzLzA3LzIwMTcgMDA6NDYsIEJsZXNzLCBSb2xhbmQgKFRNKSB3cm90ZToN Cj4gPj4gSGksDQo+ID4+DQo+ID4+IEluDQo+IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcv YXJjaC9tc2cvdHN2d2cvZDcwWjlKb0xPV3RRQ2FkRF91QTlwSjl0QngNCj4gNA0KPiA+PiBEYXZp ZCBtYWRlIHRoZSBjb21tZW50Og0KPiA+Pj4gKioqKkkgZGVmaW5pdGVseSB3YW50IHRvIHNlZSBi cm9hZGVyIFdHIGRpc2N1c3Npb24gb2YgdGhhdCDigJxNVVNUDQo+IHJlbWFya+KAnSByZXF1aXJl bWVudCwgYXMgaXTigJlzIG5vdCBiYWNrd2FyZHMgY29tcGF0aWJsZSB3aXRoIFJGQyA0NTk0IC0g YXQgYQ0KPiBtaW5pbXVtLCBzb21lIHRob3VnaHQgc2hvdWxkIGJlIGFwcGxpZWQgdG8gdHJhbnNp dGlvbiBhbmQgbWl4aW5nIG5ldHdvcmtzDQo+IHRoYXQgdXNlIENTMSBhbmQgdGhlIG5ldyBMRSBE U0NQLg0KPiA+Pg0KPiA+PiBIZXJlIGFyZSBzb21lIGdlbmVyYWwgdGhvdWdodHMgb24gcmVtYXJr aW5nIG9mIHRoZSBMRSBQSEIuDQo+ID4+DQo+ID4+IElmIGNvcnJlY3RseSBpbXBsZW1lbnRlZCBM RSAobG93ZXIgZWZmb3J0KSB0cmFmZmljIHdpbGwgbm90IGhhcm0gQkUNCj4gPj4gKGJlc3QtZWZm b3J0KSB0cmFmZmljLCBiZWNhdXNlIEJFIHRyYWZmaWMgd2lsbCBwcmVlbXB0IExFIHRyYWZmaWMu DQo+ID4+IERpZmZTZXJ2IERvbWFpbnMgdGhhdCBhcmUgbm90IGltcGxlbWVudGluZyBMRSBtYXkg Y2FycnkgTEUgdHJhZmZpYw0KPiA+PiB3aXRoaW4gdGhlaXIgQkUgYWdncmVnYXRlLiBUaGV5IG11 c3QgYmUgYXdhcmUsIGhvd2V2ZXIsIHRoYXQgdGhlDQo+ID4+ICJubyBoYXJtIiBwcm9wZXJ0eSBv ZiBMRSBpcyBub3QgZ2l2ZW4uDQo+ID4+DQo+ID4+IFRoZXJlIGFyZSBub3cgdHdvIHR5cGVzIG9m IExFIHVzZXJzOg0KPiA+PiBMRS1taW46IHRoaXMgdXNlciBkb2VzIG5vdCBjYXJlIGlmIExFIHBh Y2tldCBleHBlcmllbmNlIGJldHRlcg0KPiA+PiBmb3J3YXJkaW5nIHRyZWF0bWVudCwgc28gcHJv bW90aW5nIHRoZW0gdG8gQkUgaXMgb2suDQo+ID4+DQo+ID4+IExFLXN0cmljdDogdGhpcyB1c2Vy IHdhbnRzIHRvIGJlIHN1cmUgdGhhdCBMRSBpcyBvYmV5aW5nIHRoZQ0KPiA+PiAibm8gaGFybSIg cHJvcGVydHksIGkuZS4sIG9ubHkgb3RoZXJ3aXNlIHVudXNlZCByZXNvdXJjZXMNCj4gPj4gc2hv dWxkIGJlIGNvbnN1bWVkIGJ5IExFIHRyYWZmaWMuDQo+ID4+DQo+ID4+IFRoZSBxdWVzdGlvbiBp cyBub3csIGhvdyB0aGUgTEUtc3RyaWN0IHVzZXIgY2FuIGRldGVjdCB3aGV0aGVyDQo+ID4+IHRo ZSBwYWNrZXRzIHdlcmUgcHJvbW90ZWQgdG8gQkUuIExldCdzIGFzc3VtZSB3ZSBoYXZlIHR3bw0K PiA+PiBkaWZmZXJlbnQgRFNDUHMgTEUtbWluIGFuZCBMRS1zdHJpY3QuIFRoZW46DQo+ID4+IExF LW1pbjogY2FuIGJlIHByb21vdGVkIHRvIEJFLCBidXQgc2hvdWxkIHN0YXkgbWFya2VkIGFzIExF LW1pbg0KPiA+PiAgICAgICAgdG8gbGV0IHN1YnNlcXVlbnQgZG9tYWlucyBoYW5kbGUgaXQgY29y cmVjdGx5IGFzIExFIHRyYWZmaWMNCj4gPj4gTEUtc3RyaWN0OiBzaG91bGQgbm90IGJlIHByb21v dGVkIHRvIEJFLiBOb3cgd2UgaGF2ZSB0d28gY2FzZXM6DQo+ID4+ICAgICAgICAgICBhKSBEUyBk b21haW4gcmVtYXJrcyB0byBCRSBhbmQgcGFzc2VzIGl0IGFzIEJFIHRvIHRoZSBuZXh0IERTDQo+ ID4+ICAgICAgICAgICAgICBkb21haW4uIFRoZSByZWNlaXZlciBjb3VsZCBwcm9iYWJseSB1c2Ug c29tZSBmZWVkYmFjaw0KPiA+PiAgICAgICAgICAgICAgY2hhbm5lbCB0byBsZXQgdGhlIHNlbmRl ciBrbm93IHRoYXQgdGhpcyByZW1hcmtpbmcNCj4gPj4gICAgICAgICAgICAgIGhhcHBlbmVkLg0K PiA+PiAgICAgICAgICAgICAgQW4gYXBwcm9wcmlhdGUgcmVhY3Rpb24gc2hvdWxkIGJlIGxlZnQg dG8gdGhlIGFwcGxpY2F0aW9uDQo+ID4+ICAgICAgICAgICAgICB0aGVuIChjb250aW51ZSwgYWJv cnQsIHVzZSBMRSB0cmFuc3BvcnQgcHJvdG9jb2wsDQo+ID4+ICAgICAgICAgICAgICByYXRlIGxp bWl0LCBldGMuKSA9PiBFMkUgcHJpbmNpcGxlLg0KPiA+PiAgICAgICAgICAgYikgRFMgZG9tYWlu IHNpbXBseSBkcm9wcyB0aGUgTEUgcGFja2V0Lg0KPiA+Pg0KPiA+PiBJIHRoaW5rIGIpIGlzIG5v dCB1c2VmdWwuDQo+ID4+DQo+ID4+IENvbWluZyBiYWNrIHRvIHRoZSBxdWVzdGlvbiBhYm92ZToN Cj4gPj4gQSBEUyBkb21haW4gbXVzdCBiZSBhYmxlIHRvIG1hcCBEU0NQIHRvIFBIQiBmcmVlbHkg KHNlZSBSRkMgMjQ3NCkuDQo+ID4+IFNvIGlmIGEgRFMgZG9tYWluIGN1cnJlbnRseSBzdXBwb3J0 cyBMRSBhbmQgdXNlcyB0aGUgQ1MxIERTQ1AgZm9yIHRoYXQsDQo+ID4+IGl0IHNob3VsZCBzdXBw b3J0IHRoZSBuZXcgTEUgRFNDUCwgdG9vLg0KPiA+PiBUaGUgY3VycmVudCBkcmFmdCBzYXlzDQo+ ID4+ICAgQSBEUyBkb21haW4gdGhhdCBzdGlsbCB1c2VzIERTQ1AgQ1MxIGZvciBtYXJraW5nIExF IHRyYWZmaWMNCj4gPj4gICAoaW5jbHVkaW5nIExvdyBQcmlvcml0eS1EYXRhIGFzIGRlZmluZWQg aW4gW1JGQzQ1OTRdIG9yIHRoZSBvbGQNCj4gPj4gICBkZWZpbml0aW9uIGluIFtSRkMzNjYyXSkg TVVTVCByZW1hcmsgdHJhZmZpYyB0byB0aGUgTEUgRFNDUCAnMDAwMDEwJw0KPiA+PiAgIGF0IHRo ZSBlZ3Jlc3MgdG8gdGhlIG5leHQgRFMgZG9tYWluLiAgVGhpcyBpbmNyZWFzZXMgdGhlIHByb2Jh YmlsaXR5DQo+ID4+ICAgdGhhdCB0aGUgRFNDUCBpcyBwcmVzZXJ2ZWQgZW5kLXRvLWVuZCwgd2hl cmVhcyBhIENTMSBtYXJrZWQgcGFja2V0DQo+ID4+ICAgbWF5IGJlIHJlbWFya2VkIGJ5IHRoZSBk ZWZhdWx0IERTQ1AgaWYgdGhlIG5leHQgZG9tYWluIGlzIGFwcGx5aW5nDQo+ID4+ICAgRGlmZlNl cnYtaW50ZXJjb24gW1JGQzgxMDBdLg0KPiA+Pg0KPiA+PiBTbyBhIHVzZWZ1bCBzdHJhdGVneSB3 b3VsZCBiZSB0byBhbHdheXMgcmVtYXJrIENTMSB0byBMRSwgd2hlbg0KPiA+PiBDUzEgd2FzIHVz ZWQgZm9yIFJGQzM2NjIvTEUgdG8gZ2V0IHJpZCBvZiB0aGUgYW1iaWd1aXR5IG9mIENTMS4NCj4g Pj4gTW9yZSBpbnB1dCB3ZWxjb21lLg0KPiA+Pg0KPiA+PiBSZWdhcmRzLA0KPiA+PiBSb2xhbmQN Cj4gPj4NCj4gPj4NCj4gPg0KDQo= From nobody Sun Jul 16 03:47:54 2017 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 BAC68129B62 for ; Sun, 16 Jul 2017 03:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.752 X-Spam-Level: X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 ArE3n0dsTDdQ for ; Sun, 16 Jul 2017 03:47:51 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 55197126B6E for ; Sun, 16 Jul 2017 03:47:51 -0700 (PDT) Received: from Gs-MacBook-Pro.local (unknown [88.208.89.131]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 4AAC91B000A2; Sun, 16 Jul 2017 13:41:31 +0100 (BST) Message-ID: <596B4449.1040208@erg.abdn.ac.uk> Date: Sun, 16 Jul 2017 12:47:37 +0200 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Black, David" CC: "tsvwg@ietf.org" References: <9461BD66-BCE3-450B-A60F-D681CEA3D42E@jisc.ac.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tsvwg] Remarking of LE (draft-ietf-tsvwg-le-phb-02) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 10:47:52 -0000 On 16/07/2017, 12:23, Black, David wrote: > Small comment as an individual on Roland's original message in this thread: > >>>> LE-strict: should not be promoted to BE. Now we have two cases: >>>> a) DS domain remarks to BE and passes it as BE to the next DS >>>> domain. The receiver could probably use some feedback >>>> channel to let the sender know that this remarking >>>> happened. >>>> An appropriate reaction should be left to the application >>>> then (continue, abort, use LE transport protocol, >>>> rate limit, etc.) => E2E principle. >>>> b) DS domain simply drops the LE packet. >>>> >>>> I think b) is not useful. > I strongly agree that b) is a bad idea. We should not be adding new ways to black-hole network traffic... > > Thanks, --David I also don't like black-holing network traffic... but in this case I can still see why (b) could make sense. The thing here is that an LE transport needs to accept the packets it sends in the network may not reach the endpoint during resource congestion. Therefore, it must have mechanisms to deal with such lack of reception for LE packets. The case for LE is a little different than the other classes we have defined, for LE, the congestion could persist for a time - and that's quite OK if there is other traffic more important to use the link resource. If there is a deadline, an LE App could decide to elevate the LE transport session to BE (e.g. because LE class traffic fails to make progress), otherwise it can decide to defer transmssion and finally miss the deadline. That leaves me open to hearing arguments for case (b). An argument for (a) Is that bleaching to DSCP 0 (default) is common deployed practice. For all other traffic, this results in a lower class. Indeed, the router could tell you this was happening, I'm interested to know of a good way to tell the sender the DSCP has been remarked by a router... I'm waiting to be convinced a credible method exists. An argument against (a) is that an endpoint that chooses to send traffic marked LE, and gets elevated to the BE class by the network, may later on the path encounter other traffic that was also originally marked as LE. That other traffic is now lower than this traffic - that's an argument for not "promoting" without telling the sender. Dropping effectively tells the LE transport there is a problem. Gorry >> -----Original Message----- >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Tim Chown >> Sent: Thursday, July 13, 2017 11:02 AM >> To: Brian E Carpenter >> Cc: tsvwg@ietf.org >> Subject: Re: [tsvwg] Remarking of LE (draft-ietf-tsvwg-le-phb-02) >> >> Hi, >> >>> On 13 Jul 2017, at 02:29, Brian E Carpenter >> wrote: >>>> So a useful strategy would be to always remark CS1 to LE, when >>>> CS1 was used for RFC3662/LE to get rid of the ambiguity of CS1. >>> Yes, but I think it's better called a heuristic, not a strategy. >>> Any solution that does not involve an explicit agreement between >>> two neighbouring domains is really a "best guess". >>> >>> We could also say that a useful heuristic would be to always >>> leave CS1 as it is, if CS1 was *not* previously known to be used >>> for LE at that interface. Or alternatively, bleach it to CS0. >>> If you don't definitively know the policy of the domain that >>> forwards a packet to you, whatever you do is a guess. If you >>> do know that policy, you can do the right thing. >> That sounds fair enough. >> >> When LBE was being tested years ago on GEANT and various NRENs, we did >> also agree as “consenting networks†that CS1 (as then) would not be >> bleached, so there was DSCP transparency for participating networks, even if >> not all the elements were implementing the queuing prioritisation. >> >> Tim >> >>> Regards >>> Brian >>> >>> On 13/07/2017 00:46, Bless, Roland (TM) wrote: >>>> Hi, >>>> >>>> In >> https://mailarchive.ietf.org/arch/msg/tsvwg/d70Z9JoLOWtQCadD_uA9pJ9tBx >> 4 >>>> David made the comment: >>>>> ****I definitely want to see broader WG discussion of that “MUST >> remark†requirement, as it’s not backwards compatible with RFC 4594 - at a >> minimum, some thought should be applied to transition and mixing networks >> that use CS1 and the new LE DSCP. >>>> Here are some general thoughts on remarking of the LE PHB. >>>> >>>> If correctly implemented LE (lower effort) traffic will not harm BE >>>> (best-effort) traffic, because BE traffic will preempt LE traffic. >>>> DiffServ Domains that are not implementing LE may carry LE traffic >>>> within their BE aggregate. They must be aware, however, that the >>>> "no harm" property of LE is not given. >>>> >>>> There are now two types of LE users: >>>> LE-min: this user does not care if LE packet experience better >>>> forwarding treatment, so promoting them to BE is ok. >>>> >>>> LE-strict: this user wants to be sure that LE is obeying the >>>> "no harm" property, i.e., only otherwise unused resources >>>> should be consumed by LE traffic. >>>> >>>> The question is now, how the LE-strict user can detect whether >>>> the packets were promoted to BE. Let's assume we have two >>>> different DSCPs LE-min and LE-strict. Then: >>>> LE-min: can be promoted to BE, but should stay marked as LE-min >>>> to let subsequent domains handle it correctly as LE traffic >>>> LE-strict: should not be promoted to BE. Now we have two cases: >>>> a) DS domain remarks to BE and passes it as BE to the next DS >>>> domain. The receiver could probably use some feedback >>>> channel to let the sender know that this remarking >>>> happened. >>>> An appropriate reaction should be left to the application >>>> then (continue, abort, use LE transport protocol, >>>> rate limit, etc.) => E2E principle. >>>> b) DS domain simply drops the LE packet. >>>> >>>> I think b) is not useful. >>>> >>>> Coming back to the question above: >>>> A DS domain must be able to map DSCP to PHB freely (see RFC 2474). >>>> So if a DS domain currently supports LE and uses the CS1 DSCP for that, >>>> it should support the new LE DSCP, too. >>>> The current draft says >>>> A DS domain that still uses DSCP CS1 for marking LE traffic >>>> (including Low Priority-Data as defined in [RFC4594] or the old >>>> definition in [RFC3662]) MUST remark traffic to the LE DSCP '000010' >>>> at the egress to the next DS domain. This increases the probability >>>> that the DSCP is preserved end-to-end, whereas a CS1 marked packet >>>> may be remarked by the default DSCP if the next domain is applying >>>> DiffServ-intercon [RFC8100]. >>>> >>>> So a useful strategy would be to always remark CS1 to LE, when >>>> CS1 was used for RFC3662/LE to get rid of the ambiguity of CS1. >>>> More input welcome. >>>> >>>> Regards, >>>> Roland >>>> >>>> From nobody Sun Jul 16 13:46:21 2017 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 05375131828 for ; Sun, 16 Jul 2017 13:46:20 -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 F8w_VcRvZTPW for ; Sun, 16 Jul 2017 13:46:16 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 938F7129B05 for ; Sun, 16 Jul 2017 13:46:16 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id k14so69347327pgr.0 for ; Sun, 16 Jul 2017 13:46:16 -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=DNunpO39IPERK2HsSRyxgS7fAJ3SWJWGU00aCl2IK0A=; b=CC811ClXfHij6G8dMk7qRA2IzeURJezRcaHnboT9HYYfqRrbbB5IAUUvgzlLRGIsx3 UYsyWRFflbCyVO6cPb81vnULeK/P/3TYiJ2QpjrbFwqBIFuSvQ+oB0Iph6B6P2sg0RwG O8F8ApwDUbGf8ViHzuxDJPnFpY+/NXyPrNnGVCxIYkXMngZNxAsQxJOKFVp3030GTa+L gAIdU8YAjxoM2rBF3Ljb5Pnr/72ycztYwzQJy0nnA+ZxQftOvnTwDSeXibvGSXn3xY35 ECNysuIJHq+FE46EyMZH8KGxRyVxkI3HK4nX86Vx0Vfg8/exolQlQsD7gPrAf/yIaugg IFdQ== 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=DNunpO39IPERK2HsSRyxgS7fAJ3SWJWGU00aCl2IK0A=; b=B59zuuxBuFfwlMJQ3rnDVujZL6/ZbER5zn6U5qSmv+Q43yqRJSqT99O130qnN5m2OL Q3uYXUJ+010do+B+t3O+McPpke5xxII+HDY3QzWJr2/isxlxQ74MzqONUgAoVCuPbbTn tfgUBP/mVsf8R7HRviTEb/dys45Z+NDGaPToFXrFp8XWOQd94Y4/58kr4p+0fu0HJ6KZ aqjthCLVu3W2PU6m7uQbtMmHf7yc42sLKWeS1hlUoeNt+u2PDBUdGy3fzFnD0Dnb2JFb eHPC+8cUff9AWW6jPdYQNqSMFZGfbZuWjTm5tchT+CVnY6+EVKwGRANhx2GwODGRojGx Zvtg== X-Gm-Message-State: AIVw110Sm9l/9nEPi/49R9aM4hrRWka+qI6XTxOCS0M8uxyrTKQr2FV6 ARe1fEK/Rn6mdrgc X-Received: by 10.99.177.6 with SMTP id r6mr15684523pgf.106.1500237975731; Sun, 16 Jul 2017 13:46:15 -0700 (PDT) Received: from [192.168.178.21] (69.21.255.123.dynamic.snap.net.nz. [123.255.21.69]) by smtp.gmail.com with ESMTPSA id k73sm31672145pge.13.2017.07.16.13.46.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Jul 2017 13:46:15 -0700 (PDT) To: "Black, David" , "gorry@erg.abdn.ac.uk" Cc: Roland Bless , "tsvwg@ietf.org" References: <595F4D19.9030502@erg.abdn.ac.uk> <011e5fb5-6c83-bb38-e2cb-7fced2cb774a@kit.edu> <595F6F4F.20005@erg.abdn.ac.uk> <74717821-30ae-203b-197b-2455cbf9d4a3@gmail.com> <66425AFB-A929-4A91-90F8-432F4FAE0520@jisc.ac.uk> <59633402.9020907@erg.abdn.ac.uk> From: Brian E Carpenter Organization: University of Auckland Message-ID: <50f4b157-425e-a2cc-a924-5dd02345adef@gmail.com> Date: Mon, 17 Jul 2017 08:46:09 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 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] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 20:46:20 -0000 On 16/07/2017 22:18, Black, David wrote: > Two comments with WG chair hat OFF: > > [1] As an author of RFC 8100 - > >> "We agree to follow RFC8100" might be a minimal SLA. But >> absent that, there is very little we can say. I'm not aware >> of any measurement data that would help, unfortunately. > > Adding an LE traffic class to RFC 8100 came up during discussion of RFC 8100 (it was referred to as "scavenger" in that discussion), and was deferred, e.g., due to this DSCP codepoint concern. In principle, LE could be added to RFC 8100, but I caution that the underlying MPLS TC (Traffic Class - see RFC 5462) codepoint space is a *very* limited resource. TC is a 3-bit field, and so adding another traffic class to RFC 8100 would recommend use of the 5th value on at least interconnects - doing this requires careful consideration, including by network operators. Understood. So the choice there for LE will be between remarking as BE or dropping, as discussed in the parallel thread. > [2] As an individual: Also, while RFC 3662 suggested possible use of CS1, in practice, that use of CS1 for LE (Low Priority Data Traffic) was codified by RFC 4594 (e.g., see Section 4.10), even though RFC 4594 is an Informational RFC (RFC 4594 is widely used). Indeed. Hence the "Updates: 4594 (if approved)". Brian > > Thanks, --David > >> -----Original Message----- >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Brian E Carpenter >> Sent: Monday, July 10, 2017 4:36 PM >> To: gorry@erg.abdn.ac.uk >> Cc: Roland Bless ; tsvwg@ietf.org >> Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for >> LE PHB? >> >>> makring interdomain diffserv support unpredictable. >> >> That is the whole point, really. Interdomain diffserv support >> *is* unpredictable, more or less by definition, unless there >> is an SLA in place between the domains that defines what happens >> to packets with specific markings as they cross the border. >> >> "We agree to follow RFC8100" might be a minimal SLA. But >> absent that, there is very little we can say. I'm not aware >> of any measurement data that would help, unfortunately. >> >> Regards >> Brian >> >> On 10/07/2017 20:00, Gorry Fairhurst wrote: >>> When I asked the questions below, I didn't really have in mind a beauty >>> contest, or to identify squating on IANA-allocated DSCP values by >>> others. My concern was more about widely deploying a class that had >>> lower effort, and the implications on being able to work interdomain >>> with traffic not intended not to be "LE". >>> >>> At the moment, any remarking is likely to reduce the class by which >>> traffic is identified, e.g., a network router on path bleaching the DSCP >>> to zero would result in the packet receiving the default PHB treatment >>> for the remainder of its path. This maybe wasn't intended, but to me >>> it's quite OK. If two packets were marked with relative priority >>> (AF21,AF22) etc, it seems likely that both will be remarked to zero, or >>> that the relative priority is preseverved. >>> >>> When we introduce a LE PHB, then any traffic that finally results in the >>> new LE class will receive less than default treatment (we hope!) My >>> concern is whether there are widely deployed pathologies (especially in >>> old equipment) that would result in some codepoints being remarked to >>> the default PHB, while other codepoints get remarked to a LE PHB. This >>> could easily "invert" the relative priority expected by an application, >>> in ways we warned about in the DART work, makring interdomain diffserv >>> support unpredictable. >>> >>> In practice, I have seen there are many pathologies that deployed >>> equipment exhibits - I spoke about some of this in maprg last IETF - >>> e.g., some nodes still implement ToS semantic processing. (This is >>> deprecated!) However, that's not the point, if this remarking is still >>> out there, then we can reaonably expect some packets to be remarked. >>> This seems particularly ugly when we introduce use of a LE codepoint >>> that will actually From what I talked about in maprg, I have a fear that >>> this case could be rather common if we do not take care in selection of >>> the codepoint. I think the WG can data to talk about this. >>> >>> Gorry >>> >>> ---- >>> >>> The draft currently suggests using the DSCP value 2, '000010'. >>> >>> Question 1: Is this codepoint a good choice for the TSVWG group to >>> assign for the LE PHB? >>> >>> Things to consider: >>> - Is the codepoint currently being used for other (non-standard >>> applications) that may get in the way of the deployment of the LE PHB? >>> - Is there ant evidence that this DSCP value is less likely to be >>> forwarded than other unused codepoints? >>> - Is this codepoint observed in the wild due to common >>> DSCP-mangling pathologies (such as ToS-byte bleaching)? >>> >>> Question 2: Is there an alternate unassigned codepint that could be >>> chosen that would give better opprotunities for deployment? >>> >>> Things to consider: >>> - A codepoint less than 7 appears to have less chance of >>> DSCP-mangling pathologies (such as ToS-byte bleaching) >>> - IANA currently allocates from pool 1 (xxxxx0), but we could >>> consider asking to use pool 3 ('xxxx01'), e.g., '000001'or '000101'. >>> >>> Measurement experience and thoughts on this topic are welcome on the >>> mailing list ahead of the TSVWG meeting. At this meeting, I would like >>> to see some discussion confirming the choice of DSCP codepoint or >>> suggesting a more appropriate codepoint for the working group to request. >>> >>> Gorry Fairhurst >>> (TSVWG Co-Chair) >>> >>> When >>> > From nobody Sun Jul 16 20:17:10 2017 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 B63E5127866 for ; Sun, 16 Jul 2017 20:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 EZtjQY2Y_6r7 for ; Sun, 16 Jul 2017 20:17:07 -0700 (PDT) Received: from nov-007-i584.relay.mailchannels.net (nov-007-i584.relay.mailchannels.net [46.232.183.138]) (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 270A9126B72 for ; Sun, 16 Jul 2017 20:17:05 -0700 (PDT) X-Sender-Id: wwwh2|x-authuser|randell@jesup.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id CB79F7C9DEB for ; Mon, 17 Jul 2017 03:17:01 +0000 (UTC) Received: from rcentral501.webserversystems.com (unknown [100.96.137.163]) (Authenticated sender: wwwh2) by relay.mailchannels.net (Postfix) with ESMTPA id 5D03B7C8624 for ; Mon, 17 Jul 2017 03:17:01 +0000 (UTC) X-Sender-Id: wwwh2|x-authuser|randell@jesup.org Received: from rcentral501.webserversystems.com (rcentral501.webserversystems.com [172.20.55.158]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.9.8); Mon, 17 Jul 2017 03:17:01 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh2|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh2 X-Imminent-Soft: 370762bd3fef3fd7_1500261421607_859050887 X-MC-Loop-Signature: 1500261421607:2939458639 X-MC-Ingress-Time: 1500261421606 Received: from 75.97.193.7.res-cmts.mtp.ptd.net ([75.97.193.7]:57850 helo=[192.168.1.12]) by rcentral501.webserversystems.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dWwWq-003z4g-D2 for tsvwg@ietf.org; Sun, 16 Jul 2017 23:17:00 -0400 To: tsvwg@ietf.org From: Randell Jesup Message-ID: <6dcef89b-41b9-1e26-b39e-391118236670@jesup.org> Date: Sun, 16 Jul 2017 23:15:40 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------CE2E674F19B80D8F25BD1023" Content-Language: en-US X-AuthUser: randell@jesup.org Archived-At: Subject: [tsvwg] draft-ietf-tsvwg-sctp-ndata-11 comments X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 03:17:08 -0000 This is a multi-part message in MIME format. --------------CE2E674F19B80D8F25BD1023 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I've reviewed draft-ietf-tsvwg-sctp-ndata-11. I see no issues that need addressing. I thought I did, and then realized I'd misread a section. :-) My thanks to the authors. -- Randell Jesup -- rjesup a t mozilla d o t com Please please please don't email randell-ietf@jesup.org! Way too much spam --------------CE2E674F19B80D8F25BD1023 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit I've reviewed draft-ietf-tsvwg-sctp-ndata-11.

I see no issues that need addressing. I thought I did, and then realized I'd
misread a section. :-)

My thanks to the authors.
 
-- 
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email randell-ietf@jesup.org!  Way too much spam
--------------CE2E674F19B80D8F25BD1023-- From nobody Mon Jul 17 06:00:27 2017 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 88484131B69 for ; Mon, 17 Jul 2017 06:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 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, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=0WsmMtXU; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=QNQEsrSg 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 c45apEt8_nWJ for ; Mon, 17 Jul 2017 06:00:16 -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 2ADC9131B77 for ; Mon, 17 Jul 2017 06:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1500296415; x=1531832415; h=from:to:subject:date:message-id:mime-version; bh=bRGEQBeZ4tErUtZyM3XJdbujtpaUaap2K4qrtPgbwsg=; b=0WsmMtXUWDezoWo2/FIZfKnP6YITs2ofNEpg/N9RsI/oDyd/WBcXL2zg fElPHgTnaISRZmnHiEZTPEVbyfZywwKEUyvw6RMdUUUfu+SNiKpc07Lg3 vrkJS9B9GeAjKsf1A4X8rhagM9o1N5ELjXpl+qtqpaE60GqKycN3887Au s=; 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; 17 Jul 2017 08:00:14 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa6.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jul 2017 19:00:13 +0600 Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v6HD0CdJ014618 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 17 Jul 2017 09:00:12 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com v6HD0CdJ014618 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1500296412; bh=0wN4n8o4Hiyp08dhdrHgRrRmwWY=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=QNQEsrSgpIkbwtzhQvciCVGRrWP0LayRHoSHG9c9Xx2ulUgKpdzugAMgnHpuSXjxh T0zvSH+Hq1sPdloz+kfJnVNlpsBtPQmtAu21/X5+PqyI7WGqGGyI3XgCNZ98v1ULBr BdMO9B3z3tm0H4z7shzuUMLdkzCdGobEqP1yVONQ= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com v6HD0CdJ014618 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd03.lss.emc.com (RSA Interceptor) for ; Mon, 17 Jul 2017 08:59:54 -0400 Received: from MXHUB314.corp.emc.com (MXHUB314.corp.emc.com [10.146.3.92]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v6HCxx5V018633 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Mon, 17 Jul 2017 08:59:59 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB314.corp.emc.com ([10.146.3.92]) with mapi id 14.03.0352.000; Mon, 17 Jul 2017 08:59:59 -0400 To: "tsvwg@ietf.org" Thread-Topic: Slides for Prague meetings Thread-Index: AdL+/ANRKzCmHpuGQrisv4Iyy1xM3A== Date: Mon, 17 Jul 2017 12:59:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.103.22] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362FB7A5ABMX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [tsvwg] Slides for Prague meetings X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 13:00:17 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362FB7A5ABMX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The chairs slides have now been uploaded: https://www.ietf.org/proceedings/= 99/slides/slides-99-tsvwg-sessb-tsvwg-chairs-slides-00.pdf Presenters, please send your slides to the chairs, especially for those on = the agenda (https://www.ietf.org/proceedings/99/agenda/agenda-99-tsvwg-08.t= xt) for Tuesday! 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_CE03DB3D7B45C245BCA0D243277949362FB7A5ABMX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The chairs slides have now been uploaded: https://www.ietf.org/proceedings/99/slides/slides-99-tsvwg-sessb-tsvwg-chai= rs-slides-00.pdf

 

Presenters, please send your slides to the chairs, e= specially for those on the agenda (https://www.ietf.org/proceedings/99/a= genda/agenda-99-tsvwg-08.txt) for Tuesday!

 

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_CE03DB3D7B45C245BCA0D243277949362FB7A5ABMX307CL04corpem_-- From nobody Mon Jul 17 06:14:37 2017 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 BC208131B74; Mon, 17 Jul 2017 06:14:27 -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.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150029726772.14798.1154240172828479713@ietfa.amsl.com> Date: Mon, 17 Jul 2017 06:14:27 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-fecframe-ext-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 13:14:28 -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 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-00.txt Pages : 20 Date : 2017-07-17 Abstract: RFC 6363 describes a framework for using Forward Error Correction (FEC) codes with applications in public and private IP networks 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-00 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-fecframe-ext-00 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 17 06:34:37 2017 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 39FBD131BA7; Mon, 17 Jul 2017 06:34:36 -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.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150029847620.14798.5607143949067995735@ietfa.amsl.com> Date: Mon, 17 Jul 2017 06:34:36 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rlc-fec-scheme-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 13:34:36 -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 of the IETF. Title : Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Scheme for FECFRAME Author : Vincent Roca Filename : draft-ietf-tsvwg-rlc-fec-scheme-00.txt Pages : 23 Date : 2017-07-17 Abstract: This document describes a fully-specified FEC scheme for the Sliding Window Random Linear Codes (RLC) over GF(2^^m), where m equals 1 (binary case), 4 or 8, that can be used to protect arbitrary media streams along the lines defined by FECFRAME extended to sliding window 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 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-00 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rlc-fec-scheme-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 18 07:09:16 2017 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 DE7DF131B40 for ; Tue, 18 Jul 2017 07:09:14 -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.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150038695490.11389.10760507483626771446.idtracker@ietfa.amsl.com> Date: Tue, 18 Jul 2017 07:09:14 -0700 From: IETF Secretariat Archived-At: Subject: [tsvwg] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 14:09:15 -0000 Changed milestone "Submit 'Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP' as a BCP RFC", set due date to October 2017 from September 2017. Changed milestone "Submit 'Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim' as a Proposed Standard RFC", set due date to October 2017 from September 2017. Changed milestone "Submit 'A Lower Effort Per-Hop Behavior (LE PHB)' as a Proposed Standard RFC", set due date to December 2017 from September 2017. Changed milestone "Submit 'RFC 4960 Errata and Issues' (SCTP) as an Informational RFC", set due date to December 2017 from September 2017. URL: https://datatracker.ietf.org/wg/tsvwg/about/ From nobody Tue Jul 18 07:24:35 2017 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 E1C2B131907 for ; Tue, 18 Jul 2017 07:24:33 -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.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150038787392.11324.10196875908820605377.idtracker@ietfa.amsl.com> Date: Tue, 18 Jul 2017 07:24:33 -0700 From: IETF Secretariat Archived-At: Subject: [tsvwg] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 14:24:34 -0000 Deleted milestone "Submit 'Guidelines for DiffServ to IEEE 802.11 Mapping' as an Informational RFC". URL: https://datatracker.ietf.org/wg/tsvwg/about/ From nobody Tue Jul 18 07:40:43 2017 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 B6ACB131545 for ; Tue, 18 Jul 2017 07:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=mtEuZHT6; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=NgEfRB6E 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 6l952-SURKoV for ; Tue, 18 Jul 2017 07:40:40 -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 47214127136 for ; Tue, 18 Jul 2017 07:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1500388306; x=1531924306; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=obIjw7f5xkCj43s1WenzycDCOUs4YuQuqc4RDaNxUaw=; b=mtEuZHT6uoFHzTZwcTbiAlCJ1Mkb6uL4vH0SuuO+yXDDZ5Dwy1Chpcqv vWzx/qL+N4rdFSwJ3noBz8HFt7geoTXVBVnl6+q2FkJUOtuWIgLx0Zm0+ J8M/MFKvpdakFDg0ChkfsRhqw9nIJA9EYPnwlpFGQMGz7fAT/ctsUjGKM Q=; Received: from esa1.dell-outbound2.iphmx.com ([68.232.153.201]) by esa7.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jul 2017 09:31:46 -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; 18 Jul 2017 20:37:15 +0600 Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v6IEecde005299 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 18 Jul 2017 10:40:38 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v6IEecde005299 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1500388838; bh=phZ7bzrml3u4UlN0nYSisXGOXE0=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=NgEfRB6EkHr+zbrgKE0GVe4IsOmhJ/v6gD6SYTVmBpmLHX7+Y0RmsbFkOLXSm5Tup jpqqtNR3LTjs6QVafyPX/FL2WSAq0tDO4b4rerE5OH7yHbEC3VhSNlEM7i4ZKItT0G xwRZVCxB74Osai6F8a8RYC/RgC0Hf3khpY8YhzvY= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v6IEecde005299 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd51.lss.emc.com (RSA Interceptor) for ; Tue, 18 Jul 2017 10:40:27 -0400 Received: from MXHUB302.corp.emc.com (MXHUB302.corp.emc.com [10.146.3.28]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v6IEeSrR031126 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL) for ; Tue, 18 Jul 2017 10:40:28 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB302.corp.emc.com ([10.146.3.28]) with mapi id 14.03.0352.000; Tue, 18 Jul 2017 10:40:27 -0400 To: "tsvwg@ietf.org" Thread-Topic: [tsvwg] Milestones changed for tsvwg WG Thread-Index: AQHS/9KTouu63a2spkaz5yrDQ42lbqJZp2eQ Date: Tue, 18 Jul 2017 14:40:27 +0000 Message-ID: References: <150038787392.11324.10196875908820605377.idtracker@ietfa.amsl.com> In-Reply-To: <150038787392.11324.10196875908820605377.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: mailusrhubprd51.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.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 14:40:42 -0000 VGhpcyBpcyBwYXJ0IDEgb2YgdGhlIGludGVuZGVkIFJGQyB0eXBlIGNoYW5nZSB0byBQcm9wb3Nl ZCBTdGFuZGFyZC4gICBJdCdzIG5lY2Vzc2FyeSB0byBkZWxldGUgdGhlIG9sZCBtaWxlc3RvbmUg KHBhcnQgMSkgYW5kIGFkZCBhIG5ldyBvbmUgd2l0aCB0aGUgdXBkYXRlZCBzdGF0dXMgKHBhcnQg MikgdGhhdCBpcyBub3cgYXdhaXRpbmcgQUQgYXBwcm92YWwuDQoNClRoYW5rcywgLS1EYXZpZA0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHRzdndnIFttYWlsdG86dHN2 d2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIElFVEYgU2VjcmV0YXJpYXQNCj4gU2Vu dDogVHVlc2RheSwgSnVseSAxOCwgMjAxNyAxMDoyNSBBTQ0KPiBUbzogdHN2d2dAaWV0Zi5vcmcN Cj4gU3ViamVjdDogW3RzdndnXSBNaWxlc3RvbmVzIGNoYW5nZWQgZm9yIHRzdndnIFdHDQo+IA0K PiBEZWxldGVkIG1pbGVzdG9uZSAiU3VibWl0ICdHdWlkZWxpbmVzIGZvciBEaWZmU2VydiB0byBJ RUVFIDgwMi4xMSBNYXBwaW5nJyBhcw0KPiBhbiBJbmZvcm1hdGlvbmFsIFJGQyIuDQo+IA0KPiBV Ukw6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvdHN2d2cvYWJvdXQvDQoNCg== From nobody Tue Jul 18 11:27:01 2017 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 5A1D2131BAA; Tue, 18 Jul 2017 11:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0d2AOlHo3r9r; Tue, 18 Jul 2017 11:26:57 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFB9712F28B; Tue, 18 Jul 2017 11:26:53 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id y186so9646447ywc.1; Tue, 18 Jul 2017 11:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=ykpS+uZjY395LtxagQvlqWv9S2HdLdbTK6TgQtlt0hs=; b=J3skcSzr7AaND5oQ6Oc7X2WHRDnDusiaI4QbG5A0VGTpKfcHixPGQp71PTouxQTNoU W6MOn32+IrjSFBQA5omxcrVdqSSj8BImGhlyQ0We3SuUj71YUlDLRW4DSC2PTtmNEtn5 yhE+xYzG2X5s+8O2VDQ2FFNYk3teGk3g0juDQ3B9l0ZnLXL1SDUQaalVmyiNYX4jvOh6 lFW6kBHdi56vKPVY2DT3xlBv8h0UKpzn7jySyUZwY9fD153jtJ7iU6LDlQd/+FzPIJtQ fzBwr0jxSwrL0W+wk1LVl1BeVe4LihCcmhNYKgmbw4ADxJZ428suUm938epdQ3e3GR1q UZTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=ykpS+uZjY395LtxagQvlqWv9S2HdLdbTK6TgQtlt0hs=; b=krZXU4LzoMRjjoA4FgP0xf3l1AaqPFwijhEdEfIfSRIpWOCFaXjsMeiweHXsC93WAK mdp7E5vRBBr5KvpVP16/2tapNtlccEvDeJ66uLD0Nwz90btv95PWGtSAbstrfuO6NPIq Dbm85oqEgPdYLVbxec9lMMrvQnIMqbsiTYOeE1s5QDs/1BGgV15YEwOzte5z8CjZ5p7E XQcfc5l2HRpO3eAdehkCBYLojfWoS2ZEdjSTSxCExSa1s9+j2vbOYyOwEoAEh7pDMv01 7cczWdyzNbgGnYuy1nEJE8DMay8fBp5wirMs648kruJm8WunVHV7QO1zOKdz7GVD+uJl E5iw== X-Gm-Message-State: AIVw1124VWwhKPYBkmCQC2WfrILtm/ZTwS0hwDpAHgwYp8BBfUju3CH0 wcBseUhBd4gzneIA9EJCnCy4BuvGillJ X-Received: by 10.13.227.132 with SMTP id m126mr2270378ywe.151.1500402412642; Tue, 18 Jul 2017 11:26:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.45.101 with HTTP; Tue, 18 Jul 2017 11:26:52 -0700 (PDT) From: Spencer Dawkins at IETF Date: Tue, 18 Jul 2017 20:26:52 +0200 Message-ID: To: draft-ietf-tsvwg-sctp-ndata@ietf.org Cc: "tsvwg@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c07630cd368a905549ba8f3" Archived-At: Subject: [tsvwg] AD Evaluation: draft-ietf-tsvwg-sctp-ndata-11.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 18:26:59 -0000 --94eb2c07630cd368a905549ba8f3 Content-Type: text/plain; charset="UTF-8" Sorry for not finishing this last week. I really like this mechanism and the document describing it was mostly clear to me. I did have some questions, but most are simple requests for more clarity. I suspect this will require a revised ID, so I'll mark it that way in the Datatracker, but if I'm completely wrong, don't submit one just to make me happy. Michael and I talked briefly at the beginning of TSVWG this afternoon, and as I told him, "I'm here all week", if chatting is faster than typing. I'm a bit curious about this text, This document also defines several stream schedulers for general SCTP associations. They can be used with and without user message interleaving being negotiated and possibly behave differently. because I'm wondering, "possibly behave differently than what?" Could you say a sentence or two more about what you mean here? The text in Section 3 says This section defines several stream schedulers. The stream schedulers may behave differently depending on whether user message interleaving has been negotiated for the association or not. and that's clearer to me, if I'm understanding correctly. I need a bit more help on this text, Please note that the use of such a scheduler implies late TSN assignment but it can be used with an [RFC4960] compliant implementation that does not support user message interleaving. I'm not quite sure what you mean by "can be used with/does not support user message interleaving". I'm guessing that your point was, this is a new sender-side behavior, so SCTPs that implement this specification know what I-DATA is, and when they negotiate support for I-DATA, they will reassemble fragments correctly, whether they would interleave user messages that they send or not, but I'm guessing. Also, could you provide a reference for "late TSN assignment"? This is the first usage in the document. You might consider putting this text The interleaving of user messages is required for WebRTC Datachannels as specified in [I-D.ietf-rtcweb-data-channel]. earlier in the document - perhaps in the Introduction? I wish I thought it belonged in the Abstract, too, but I'm less sure about suggesting that. You might consider adding explanatory text to If an SCTP implementation supports user message interleaving and the extension described in [RFC3758] or [RFC6525], it is REQUIRED to implement the corresponding changes specified in Section 2.3. so, If an SCTP implementation supports user message interleaving and the partial reliability extension described in [RFC3758] or the stream reconfigurtion extension described in RFC6525], it is REQUIRED to implement the corresponding changes specified in Section 2.3. for those of us who don't remember the RFC numbers of extensions off the tops of our heads. I think I know what A message is considered in flight, if at least on of its I-DATA chunks is not acknowledged in a non-renegable way. means, but is "non-renegable" a term of art in the SCTP community? I had the same question about PPID, but I'm sure you would have the same answer ... This is a nit, but The sender MUST NOT be fragmenting more than one user message in any given stream at any time. would probably be clearer if it said "must not fragment". This is a nit, but A message (either ordered or unordered) may be identified as being fragmented whose 'E' and 'B' bits are not set both. should probably be be "not both set". So, dumb question, but how close is the last sentence in If I-DATA support has been negotiated for an association, the reception of a DATA chunk is a violation of the above rules and therefore the receiver of the DATA chunk MUST abort the association by sending an ABORT chunk. The ABORT chunk MAY include the 'Protocol Violation' error cause. The same applies if I-DATA support has not be negotiated for an association and an I-DATA chunk is received. to what an SCTP that doesn't support this extension would do, if it received an I-DATA chunk? I was guessing that the last sentence isn't new behavior, but wanted to ask because it's being specified here. Whether or not it's different, it might be useful to tell the reader that. I had the same question about the last sentence in section 2.3.1, "SCTP Partial Reliability Extension", but I'm sure you would have the same answer. In this text, 3.4. Priority Based Scheduler (SCTP_SS_PRIO) Scheduling of user messages with strict priorities is used. The priority is configurable per outgoing SCTP stream. Streams having a higher priority will be scheduled first and when multiple streams have the same priority, the scheduling between them is implementation dependent. When using user message interleaving, the sending of lower priority user messages will not block the sending of higher priority user messages. I'm not sure I understand "will not block". If I'm in the process of sending a lower priority user message and a higher priority user message is being scheduled, wouldn't the higher priority user message have to wait? I'm probably not understanding this. --94eb2c07630cd368a905549ba8f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry for not finishing this last week.
I really like this mechanism and the document describing it was= mostly clear to me. I did have some questions, but most are simple request= s for more clarity.

I suspect this will require a = revised ID, so I'll mark it that way in the Datatracker, but if I'm= completely wrong, don't submit one just to make me happy.
Michael and I talked briefly at the beginning of TSVWG this af= ternoon, and as I told him, "I'm here all week", if chatting = is faster than typing.

I'm a bit curious about= this text,

=C2=A0 =C2=A0This document also define= s several stream schedulers for general SCTP
=C2=A0 =C2=A0associa= tions.=C2=A0 They can be used with and without user message
=C2= =A0 =C2=A0interleaving being negotiated and possibly behave differently.
=C2=A0 =C2=A0
because I'm wondering, "possibly b= ehave differently than what?" Could you say a sentence or two more abo= ut what you mean here? The text in Section 3 says=C2=A0

=C2=A0 =C2=A0This section defines several stream schedulers.=C2=A0 Th= e stream
=C2=A0 =C2=A0schedulers may behave differently depending= on whether user message
=C2=A0 =C2=A0interleaving has been negot= iated for the association or not.=C2=A0
=C2=A0 =C2=A0
a= nd that's clearer to me, if I'm understanding correctly.
=
I need a bit more help on this text,

=C2=A0 =C2=A0Please note that the use of such a scheduler implies late
=C2=A0 =C2=A0TSN assignment but it can be used with an [RFC4960] co= mpliant
=C2=A0 =C2=A0implementation that does not support user me= ssage interleaving.
=C2=A0 =C2=A0
I'm not quite sur= e what you mean by "can be used with/does not support user message int= erleaving". I'm guessing that your point was, this is a new sender= -side behavior, so SCTPs that implement this specification know what I-DATA= is, and when they negotiate support for I-DATA, they will reassemble fragm= ents correctly, whether they would interleave user messages that they send = or not, but I'm guessing.

Also, could you prov= ide a reference for "late TSN assignment"? This is the first usag= e in the document.

You might consider putting this= text

=C2=A0 =C2=A0The interleaving of user messag= es is required for WebRTC Datachannels
=C2=A0 =C2=A0as specified = in [I-D.ietf-rtcweb-data-channel].

earlier in the = document - perhaps in the Introduction? I wish I thought it belonged in the= Abstract, too, but I'm less sure about suggesting that.

=
You might consider adding explanatory text to=C2=A0
=C2=A0 =C2=A0If an SCTP implementation
=C2=A0 =C2=A0= supports user message interleaving and the extension described in
=C2=A0 =C2=A0[RFC3758] or [RFC6525], it is REQUIRED to implement the corre= sponding
=C2=A0 =C2=A0changes specified in Section 2.3.
=C2=A0 =C2=A0
so,=C2=A0

=C2=A0 =C2=A0If= an SCTP implementation
=C2=A0 =C2=A0supports user message interl= eaving and the partial reliability extension=C2=A0
=C2=A0 =C2=A0d= escribed in [RFC3758] or the stream reconfigurtion extension described in= =C2=A0
=C2=A0 =C2=A0RFC6525], it is REQUIRED to implement the cor= responding
=C2=A0 =C2=A0changes specified in Section 2.3.
=C2=A0 =C2=A0
for those of us who don't remember the RFC n= umbers of extensions off the tops of our heads.

I = think I know what=C2=A0

=C2=A0 =C2=A0 =C2=A0 A mes= sage is considered in flight, if at least
=C2=A0 =C2=A0 =C2=A0 on= of its I-DATA chunks is not acknowledged in a non-renegable
=C2= =A0 =C2=A0 =C2=A0 way.

means, but is "non-ren= egable" a term of art in the SCTP community? I had the same question a= bout PPID, but I'm sure you would have the same answer ...
This is a nit, but=C2=A0

=C2=A0 =C2= =A0The sender MUST NOT be fragmenting more than one user message in any
=C2=A0 =C2=A0given stream at any time. =C2=A0
=C2=A0 =C2= =A0
would probably be clearer if it said "must not fragment&= quot;.

This is a nit, but

=C2=A0 =C2=A0A message (either ordered or unordered) may be identified as<= /div>
=C2=A0 =C2=A0being fragmented whose 'E' and 'B' b= its are not set both.
=C2=A0 =C2=A0
should probably be = be "not both set".

So, dumb question, bu= t how close is the last sentence in

=C2=A0 =C2=A0I= f I-DATA support has been negotiated for an association, the
=C2= =A0 =C2=A0reception of a DATA chunk is a violation of the above rules and
=C2=A0 =C2=A0therefore the receiver of the DATA chunk MUST abort t= he association
=C2=A0 =C2=A0by sending an ABORT chunk.=C2=A0 The = ABORT chunk MAY include the 'Protocol
=C2=A0 =C2=A0Violation&= #39; error cause.=C2=A0 The same applies if I-DATA support has not
=C2=A0 =C2=A0be negotiated for an association and an I-DATA chunk is rece= ived.
=C2=A0 =C2=A0
to what an SCTP that doesn't su= pport this extension would do, if it received an I-DATA chunk? I was guessi= ng that the last sentence isn't new behavior, but wanted to ask because= it's being specified here. Whether or not it's different, it might= be useful to tell the reader that.

I had the same= question about the last sentence in section 2.3.1, "SCTP Partial Reli= ability Extension", but I'm sure you would have the same answer.

In this text,=C2=A0

3.4.= =C2=A0 Priority Based Scheduler (SCTP_SS_PRIO)

=C2= =A0 =C2=A0Scheduling of user messages with strict priorities is used.=C2=A0= The
=C2=A0 =C2=A0priority is configurable per outgoing SCTP stre= am.=C2=A0 Streams having a
=C2=A0 =C2=A0higher priority will be s= cheduled first and when multiple streams
=C2=A0 =C2=A0have the sa= me priority, the scheduling between them is implementation
=C2=A0= =C2=A0dependent.=C2=A0 When using user message interleaving, the sending o= f
=C2=A0 =C2=A0lower priority user messages will not block the se= nding of higher
=C2=A0 =C2=A0priority user messages.
= =C2=A0 =C2=A0
I'm not sure I understand "will not block&= quot;. If I'm in the process of sending a lower priority user message a= nd a higher priority user message is being scheduled, wouldn't the high= er priority user message have to wait? I'm probably not understanding t= his.
--94eb2c07630cd368a905549ba8f3-- From nobody Wed Jul 19 05:41:17 2017 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 D5E3A131CEA for ; Wed, 19 Jul 2017 05:41:14 -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 GLwfjQLLwzbj for ; Wed, 19 Jul 2017 05:41:13 -0700 (PDT) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::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 8DBD4131B43 for ; Wed, 19 Jul 2017 05:41:13 -0700 (PDT) Received: by mail-yb0-x22e.google.com with SMTP id 70so15302897ybn.2 for ; Wed, 19 Jul 2017 05:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=E5AzJQpsfNRFvqv7XXuW1A9HYie1n6FdBypsgp0Q8kQ=; b=AtSZcpRdycNDNSK9JaHHglwfNzLAl2mHLtsMI7jcbTCW9KcknDvhzE/EEJVTA3uOTV mPYkrh2afplWSCj8sf9+UK8U43YVKE/UZesJJaCd5Saom+5ALDVLYKtHLP/zevWvMxbL 8O5uCze8eqK7nsCcIsIh7oZ2WApL9+z22xznCR2StPoNc2uzol6YHw48ua3faJAIwZL6 f1rtY92ndE75Nrh+X9d/gweMFmzmzEszn+cOOmS+c+QQBZqo4Zn2ODjQmg8vPqo5vPh/ lzwnhghu339C7xv3ZaKCncdcPPdQ64b7I6jYvhjV/nhypr/Pf0jgVxM0zO0VZgCe15Iy CmzA== 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=E5AzJQpsfNRFvqv7XXuW1A9HYie1n6FdBypsgp0Q8kQ=; b=fC0vVfm4ps+KGcXu/PDMUmQ8s+IO95Qa4NgHqM4X8buuyeWQo3D41VzX1TFzh16Wfo LK9R9BMZI0nceQv3BClEFNl9uYgde7uEmeldzMo2djfzwP8FswBTsYJwZGx0/uM23yvn hHXE9egTYzEnm8Lg8IwrH0iozBJBIScxWczl71DdblfJbsr4N8J3Hz7Fej0RAJShanMW Altmey2RbEn3kzX3H6npNvjVZIIbuJYCXqCXr53e9uiFO4vDO3zAMi0bqQI5mB6zmPV0 j4IrAYwdXFs7vdEyP6iN8vjoVJQAXD6/V1/yyfP6Ajl8w5fFWm5MapiNxiwuFRzRoEeG knsg== X-Gm-Message-State: AIVw110iZ81IwblBkeBh9jacwNk223G3voTGUxU49PBMoPCcqsru92Tl SKVnZJ6U9LVxiEN1m+mx0jFbEYHfOg== X-Received: by 10.37.22.7 with SMTP id 7mr1779614ybw.75.1500468072650; Wed, 19 Jul 2017 05:41:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.45.101 with HTTP; Wed, 19 Jul 2017 05:41:12 -0700 (PDT) In-Reply-To: References: <150038787392.11324.10196875908820605377.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Wed, 19 Jul 2017 14:41:12 +0200 Message-ID: To: "Black, David" Cc: "tsvwg@ietf.org" Content-Type: multipart/alternative; boundary="001a11414c6877b9110554aaf2f4" Archived-At: Subject: Re: [tsvwg] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 12:41:15 -0000 --001a11414c6877b9110554aaf2f4 Content-Type: text/plain; charset="UTF-8" Hi, David, On Tue, Jul 18, 2017 at 4:40 PM, Black, David wrote: > This is part 1 of the intended RFC type change to Proposed Standard. > It's necessary to delete the old milestone (part 1) and add a new one with > the updated status (part 2) that is now awaiting AD approval. Not any more :D ... Thanks for making all of these changes. I reviewed them carefully and approved them all. Spencer --001a11414c6877b9110554aaf2f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, David,

On Tue, Jul 18, 2017 at 4:40 PM, Black, David &= lt;David.Black@de= ll.com> wrote:
This is part= 1 of the intended RFC type change to Proposed Standard.=C2=A0 =C2=A0It'= ;s necessary to delete the old milestone (part 1) and add a new one with th= e updated status (part 2) that is now awaiting AD approval.

Not any more :D ...

Thanks for ma= king all of these changes. I reviewed them carefully and approved them all.=

Spencer
--001a11414c6877b9110554aaf2f4-- From nobody Wed Jul 19 11:54:19 2017 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 690BA131B3E for ; Wed, 19 Jul 2017 11:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 6FfGI97DcB_z for ; Wed, 19 Jul 2017 11:54:10 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 522171318A2 for ; Wed, 19 Jul 2017 11:54:10 -0700 (PDT) X-AuditID: 1209190f-93fff700000016c9-65-596faad0d76a Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 2F.34.05833.0DAAF695; Wed, 19 Jul 2017 14:54:09 -0400 (EDT) Received: from outgoing-exchange-2.mit.edu (OUTGOING-EXCHANGE-2.MIT.EDU [18.7.34.15]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v6JIs7WT023303 for ; Wed, 19 Jul 2017 14:54:07 -0400 Received: from W92EXEDGE5.EXCHANGE.MIT.EDU (W92EXEDGE5.EXCHANGE.MIT.EDU [18.7.73.22]) by outgoing-exchange-2.mit.edu (8.13.8/8.12.4) with ESMTP id v6JIs0Od011654 for ; Wed, 19 Jul 2017 14:54:06 -0400 Received: from OC11EXCAS20.exchange.mit.edu (18.9.1.45) by W92EXEDGE5.EXCHANGE.MIT.EDU (18.7.73.22) with Microsoft SMTP Server (TLS) id 14.3.339.0; Wed, 19 Jul 2017 14:53:34 -0400 Received: from OC11EXPO31.exchange.mit.edu ([169.254.1.206]) by OC11EXCAS20.exchange.mit.edu ([18.9.1.45]) with mapi id 14.03.0352.000; Wed, 19 Jul 2017 14:54:03 -0400 From: Xiaomeng Shi To: "tsvwg@ietf.org" Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-rlc-fec-scheme-00.txt Thread-Index: AQHS/wFybhjnAphdEkyibIThkIC+u6JbxdCA Date: Wed, 19 Jul 2017 18:54:03 +0000 Message-ID: <3A1480C1-C475-46EF-B776-0E9714FD4DB2@mit.edu> References: <150029847620.14798.5607143949067995735@ietfa.amsl.com> In-Reply-To: <150029847620.14798.5607143949067995735@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.20.171.44] Content-Type: multipart/alternative; boundary="_000_3A1480C1C47546EFB7760E9714FD4DB2mitedu_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmk+LIzCtJLcpLzFFi42IR4hTV1r24Kj/SYOliXotjb+6yOTB6LFny kymAMYrLJiU1J7MstUjfLoErY+M0+4J1ERU9uy+wNTBe9+5i5OCQEDCReDvZr4uRi0NIYDGT xIfdb5ghnKuMEkcf3mWDcF4yStz79R7K2c4o8ePkJxYIZzWjxJFjq5m6GDk52AQUJW5tvcoI YosIqEpc7ljLBLJDWMBd4kBzMkTYQ+LXyQusELaRxKNrk5lBbBag8huT5oPZvAJWEo9m/mYD sYUEnCWetW4AszkFXCS2T2sC62UUEJP4fmoN2FpmAXGJW0/mg9kSAoISi2bvYYawxST+7XrI BvGmosS0bWkQ5XESqx9tZ4VYJShxcuYTlgmMYrOQTJqFpGwWkjKIuI7Egt2f2CBsbYllC18z w9hnDjyG6rWX+HdhAYqaBYwcqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3RN9HIzS/RSU0o3MYJj U5J/B+OcBu9DjAIcjEo8vB3J+ZFCrIllxZW5hxglOZiURHnn8AKF+JLyUyozEosz4otKc1KL DzFKcDArifA+WASU401JrKxKLcqHSUlzsCiJ84prNEYICaQnlqRmp6YWpBbBZGU4OJQkeM+t BGoULEpNT61Iy8wpQUgzcXCCDOcBGr4YpIa3uCAxtzgzHSJ/itGeY9OMn9+YOA79PvGdieMY mGz6/vE7kxBLXn5eqpQ478MVQG0CIG0ZpXlwk8Fpl91T7BWjONCjwrxLQYbzAFM23OxXQGuZ gNYK++aArC1JREhJNTDWcWXJTj98pc1bvdLiZ0atwSLGMwsezJ/0tGXBH5GQJOYFrT4cwpc3 6c7azDW3xHMP5697b1pj43JPKf7NDo3k9zDX+bmpY/E+29PmSXs/zRXcrbEtuOz9kqn/C88s 2drhc/y0j9riwuooq12/5m27vuByfk2BfbvOEotDE/cYWp6Ledi/l6lUiaU4I9FQi7moOBEA yPwqNZYDAAA= Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rlc-fec-scheme-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 18:54:17 -0000 --_000_3A1480C1C47546EFB7760E9714FD4DB2mitedu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Vincent and all, Thank you very much for the great effort. This is my first post to the gro= up, and I hope my message has come at an appropriate time during the pipeli= ne. I work with Code On Technologies in Cambridge, MA, where our focus is = in the application of random linear network codes in different layers of th= e network stack to achieve performance improvements when possible. We are delighted to see that the sliding window approach has become a worki= ng group item and we are in full support of the initiative. To this extent= , we thought it might be of interest to the group to see some past research= work in this area, either from us, or that we are aware of. Below is a qu= ick list, and we look forward to future discussions within tsvwg. 1) Network Coding Overview, IETF 86, 2013, Code On Technologies, https://ww= w.ietf.org/proceedings/86/slides/slides-86-nwcrg-5.pdf. 2) T. Ho, et al., "A random linear network coding approach to multicast," I= EEE Transactions on Information Theory, vol. 52, no. 10, pp. 4413-4430, 200= 6. 3) JK, Sundararajan et al., "Network coding meets TCP," INFOCOM 2009, IEEE.= IEEE, 2009. 4) M. Kim et al., "Modeling network coded TCP throughput: A simple model an= d its validation," Proceedings of the 5th International ICST Conference on = Performance Evaluation Methodologies and Tools. ICST (Institute for Compute= r Sciences, Social-Informatics and Telecommunications Engineering), 2011. 5) S. Wunderlich et al., We don't need no generation-a practical approach t= o sliding window RLNC. In Wireless Days, 2017 (pp. 218-223). IEEE. Best regards, Shirley Shi On Jul 17, 2017, at 9:34 AM, internet-drafts@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group of the IETF. Title : Sliding Window Random Linear Code (RLC) Forward Er= asure Correction (FEC) Scheme for FECFRAME Author : Vincent Roca Filename : draft-ietf-tsvwg-rlc-fec-scheme-00.txt Pages : 23 Date : 2017-07-17 Abstract: This document describes a fully-specified FEC scheme for the Sliding Window Random Linear Codes (RLC) over GF(2^^m), where m equals 1 (binary case), 4 or 8, that can be used to protect arbitrary media streams along the lines defined by FECFRAME extended to sliding window 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 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-00 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rlc-fec-scheme-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ --_000_3A1480C1C47546EFB7760E9714FD4DB2mitedu_ Content-Type: text/html; charset="us-ascii" Content-ID: <6986260FD2328143BE618BB8C66E6483@exchange.mit.edu> Content-Transfer-Encoding: quoted-printable
Dear Vincent and all,

 

Thank you very much for the great effort. &n= bsp;This is my first post to the group, and I hope my message has come at a= n appropriate time during the pipeline.  I work with Code On Technologies in Cambridge, MA, where our focus is in the appl= ication of random linear network codes in different layers of the network s= tack to achieve performance improvements when possible.  

We are delighted to see that the sliding win= dow approach has become a working group item and we are in full support of = the initiative.  To this extent, we thought it might be of interest to the group to see some past research work in thi= s area, either from us, or that we are aware of.  Below is a quick lis= t, and we look forward to future discussions within tsvwg. 

 

1) Network Coding Overview, IETF 86, 2013, C= ode On Technologies, https://www.ietf.org/proceeding= s/86/slides/slides-86-nwcrg-5.pdf.
2) T. Ho, et al., "A random linear netw= ork coding approach to multicast," IEEE Transactions on Information Th= eory, vol. 52, no. 10, pp. 4413-4430, 2006.
3) JK, Sundararajan et al., "= Network coding meets TCP," INFOCOM 2009, IEEE. IEEE, 2009.=
4) M. Kim et al., "Modeling network cod= ed TCP throughput: A simple model and its validation," Proceeding= s of the 5th International ICST Conference on Performance Evaluation Methodologies and Tools. ICST (Institute for Computer Sciences,= Social-Informatics and Telecommunications Engineering), 2011.
5) S. Wunderlich et al., We don't need = no generation-a practical approach to sliding window RLNC. In Wireless= Days, 2017 (pp. 218-223). IEEE.


Best regards,
Shirley Shi



On Jul 17, 2017, at 9:34 AM, internet-drafts@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Transport Area Working Group of the IETF.<= br class=3D"">
       Title     &nb= sp;     : Sliding Window Random Linear Code (RLC) = Forward Erasure Correction (FEC) Scheme for FECFRAME
       Author     &n= bsp;    : Vincent Roca
Filename &n= bsp;      : draft-ietf-tsvwg-rlc-fec-scheme-0= 0.txt
Pages  = ;         : 23
Date  =           : 2017-07-17
Abstract:
  This document describes a fully-specified FEC scheme for the Sl= iding
  Window Random Linear Codes (RLC) over GF(2^^m), where m equals = 1
  (binary case), 4 or 8, that can be used to protect arbitrary me= dia
  streams along the lines defined by FECFRAME extended to sliding=
  window codes.  These sliding window FEC codes rely on an e= ncoding
  window that slides over the source symbols, generating new repa= ir
  symbols whenever needed.  Compared to block FEC codes, the= se sliding
  window FEC codes offer key advantages with real-time flows in t= erms
  of reduced FEC-related latency while often providing improved e= rasure
  recovery capabilities.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-sch= eme/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tsvwg-rlc-fec-scheme-00
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rlc-fec-scheme-00

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

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


--_000_3A1480C1C47546EFB7760E9714FD4DB2mitedu_-- From nobody Thu Jul 20 02:26:54 2017 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 6067E13170E for ; Thu, 20 Jul 2017 02:26:53 -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 2rz2OA0tWIQH for ; Thu, 20 Jul 2017 02:26:52 -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 1446512ECC3 for ; Thu, 20 Jul 2017 02:26:52 -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:Cc: Subject:From:To:Sender:Reply-To: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=agkjUfD9O7ICg+WnUmJ6taxcGKHap2+nX8OaSF20lqk=; b=BI4DhqqqocKhx4zky7tORbwb7j CJ+ySPb9/b3Q+Q7gvbQncmc/oQ1IDOKuKbD7c9tSYgrORxtvhrkCPkprq4Kg4t5taOYszXDy4W4VM 0guvtUKvDtNIbJX8Kgas57yixwjZ4BKVk4B8l3c+2VS1iix2rmv93IXNqHdXg7elhELWxfuNVGgv2 SfKWC6bRhBaf4cPwGY24KsI6ZqAP9QwZSRlzMz6gCk109vyJ22E3db1rzLZGGfQRLTEp1EN6zU4hF MlXj62an2HcU+TBzpTUakQ7UmZcl0WYplIKORFu87QiSLk4723ofevgibXZR9ur+5sjKErFJe/oh/ KPl+XJXw==; Received: from dhcp-80b8.meeting.ietf.org ([31.133.128.184]:40440) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dY7jO-0008Tu-FM; Thu, 20 Jul 2017 10:26:50 +0100 To: "Black, David" From: Bob Briscoe Cc: tsvwg IETF list Message-ID: Date: Thu, 20 Jul 2017 10:26:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------3B1DF72F3408117DCA6B375D" 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] UDP/IP outer as an IP-shim-IP tunnel and AMT as an example X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 09:26:53 -0000 This is a multi-part message in MIME format. --------------3B1DF72F3408117DCA6B375D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit David (as doc shepherd), In the tsvwg mtg onTue, it was suggested that AMT ought to be included in the list of RFCs that define a new IP-shim-IP tunnelling protocol. I said that I had actually looked at this and decided not to include it. I now remember why. It was cos AMT is just using UDP-IP encapsulation, not really defining a new encapsulation. Nonetheless thanks to the guy who came to the mic (sry I can't remember the name - I think from Akamai) for making me revisit this. It identifies a gap: rfc6040update-shim doesn't mention general use of UDP-IP encapsulation. It only mentions the specific case of GUE (generic UDP encapsulation). The way I propose to handle this is to add a bullet in 5. IP-in-IP Tunnels with Tightly Coupled Shim Headers for UDP tunnels. Then add the following covering general use of UDP-IP encapsulation, giving AMT as one example of it: 5.1.x UDP Tunnels Section 3.1.11 of the UDP usage guidelines in RFC 8085 already explains that a tunnel that encapsulates an IP header within a UDP/IP datagram, e.g. Automatic Multicast Tunneling (AMT [RFC7450]), needs to follow RFC 6040 when propagating the ECN field between inner and outer IP headers. The requirements in Section 4 update RFC 6040, so they add the important, but previously unstated requirement that, if the UDP tunnel egress does not, or might not, support ECN propagation, a legacy UDP tunnel ingress has to zero the outer ECN field, e.g. by configuration. Do any RFC's need to be updated? No. Given the UDP tunnelling section of RFC 8085 (UDP usage guidelines) already refers to RFC 6040, I don't think we need to update every RFC that uses UDP Tunnelling to refer to RFC 6040. It would be ideal, but perhaps impractical. Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------3B1DF72F3408117DCA6B375D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit David (as doc shepherd),

In the tsvwg mtg onTue, it was suggested that AMT ought to be included in the list of RFCs that define a new IP-shim-IP tunnelling protocol.

I said that I had actually looked at this and decided not to include it. I now remember why. It was cos AMT is just using UDP-IP encapsulation, not really defining a new encapsulation.

Nonetheless thanks to the guy who came to the mic (sry I can't remember the name - I think from Akamai) for making me revisit this. It identifies a gap: rfc6040update-shim doesn't mention general use of UDP-IP encapsulation. It only mentions the specific case of GUE (generic UDP encapsulation).

The way I propose to handle this is to add a bullet in 5.  IP-in-IP Tunnels with Tightly Coupled Shim Headers for UDP tunnels. Then add the following covering general use of UDP-IP encapsulation, giving AMT as one example of it:

      5.1.x UDP Tunnels

      Section 3.1.11 of the UDP usage guidelines in RFC 8085 already
      explains that a tunnel that encapsulates an IP header within a
      UDP/IP datagram, e.g. Automatic Multicast Tunneling (AMT 
      [RFC7450]), needs to follow RFC 6040 when propagating the ECN
      field between inner and outer IP headers.

      The requirements in Section 4 update RFC 6040, so they add
      the important, but previously unstated requirement that, if
      the UDP tunnel egress does not, or might not, support ECN 
      propagation, a legacy UDP tunnel ingress has to zero the outer 
      ECN field, e.g. by configuration.
Do any RFC's need to be updated? No.
Given the UDP tunnelling section of RFC 8085 (UDP usage guidelines) already refers to RFC 6040, I don't think we need to update every RFC that uses UDP Tunnelling to refer to RFC 6040.

It would be ideal, but perhaps impractical.



Bob
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------3B1DF72F3408117DCA6B375D-- From nobody Thu Jul 20 05:38:01 2017 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 3C369126E3A; Thu, 20 Jul 2017 05:37:59 -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.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150055427918.16190.1444076444095506729@ietfa.amsl.com> Date: Thu, 20 Jul 2017 05:37:59 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-encap-guidelines-09.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:37:59 -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 : Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP Authors : Bob Briscoe John Kaippallimalil Pat Thaler Filename : draft-ietf-tsvwg-ecn-encap-guidelines-09.txt Pages : 35 Date : 2017-07-20 Abstract: The purpose of this document is to guide the design of congestion notification in any lower layer or tunnelling protocol that encapsulates IP. The aim is for explicit congestion signals to propagate consistently from lower layer protocols into IP. Then the IP internetwork layer can act as a portability layer to carry congestion notification from non-IP-aware congested nodes up to the transport layer (L4). Following these guidelines should assure interworking between new lower layer congestion notification mechanisms, whether specified by the IETF or other standards bodies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-encap-guidelines-09 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-encap-guidelines-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ecn-encap-guidelines-09 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 23 17:40:12 2017 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 AC6A1128B8D for ; Sun, 23 Jul 2017 17:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 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, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-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=eN5E5bGM; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=V49ktUIn 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 qKPmtozkysft for ; Sun, 23 Jul 2017 17:40:08 -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 51091126B72 for ; Sun, 23 Jul 2017 17:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1500856808; x=1532392808; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=3AB4iB6LRRRB7DNprrGfQ2nxz94I3gYrD85LBPCsX1c=; b=eN5E5bGM3b1BgFd/ZdgEIHwmbUPSn5QOU3XF+x50lh96AwkVC5ERONH3 x9uQ5GMFUJJBkwsYSVDqQk8Uw2cR3BZnAWxBnIAZfBuxbHWpGitsaNyny LsH1U4/2xo4SJYdKkg3cuwoxywsfFPxAAjmC+VwM6y/g/7jjUnKE/vQyi I=; Received: from esa6.dell-outbound2.iphmx.com ([68.232.154.99]) by esa6.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jul 2017 19:40:06 -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; 24 Jul 2017 06:40:06 +0600 Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v6O0e4I4020242 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 23 Jul 2017 20:40:05 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com v6O0e4I4020242 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1500856805; bh=hK4eZa3ZRvOfpRnpM80SUJuZKjA=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=V49ktUIn/4NAihBjrt1LftbhMnTCFRyJ0U2tJJ5b5g4ymH3d0C3ZL0NpEKINGnYej geTbvIZmyRpxoKzVxhcWkJyt0G7r3wFPQ3Vd0THKC0asn3fBpG+ypmY/n5tTU3TJh0 Ld24guoc39KuGQJSxATZ+DVJLOT4wzATrI9SK5Hw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com v6O0e4I4020242 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd54.lss.emc.com (RSA Interceptor); Sun, 23 Jul 2017 20:39:51 -0400 Received: from MXHUB309.corp.emc.com (MXHUB309.corp.emc.com [10.146.3.35]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v6O0dq7j024791 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Sun, 23 Jul 2017 20:39:53 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB309.corp.emc.com ([10.146.3.35]) with mapi id 14.03.0352.000; Sun, 23 Jul 2017 20:39:52 -0400 To: Xiaomeng Shi , "tsvwg@ietf.org" Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-rlc-fec-scheme-00.txt Thread-Index: AQHS/wJHzT21xC/eDEGbdzWCqvq1b6JbxdCAgAZiO4A= Date: Mon, 24 Jul 2017 00:39:52 +0000 Message-ID: References: <150029847620.14798.5607143949067995735@ietfa.amsl.com> <3A1480C1-C475-46EF-B776-0E9714FD4DB2@mit.edu> In-Reply-To: <3A1480C1-C475-46EF-B776-0E9714FD4DB2@mit.edu> 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_CE03DB3D7B45C245BCA0D243277949362FB8E546MX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public, GIS Solicitation Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rlc-fec-scheme-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 00:40:11 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362FB8E546MX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Shirley, Thank you for your interest, and the timing is fine. The background inform= ation is useful - beyond that, if you and/or your colleagues are interested= in reviewing this draft (and the supporting framework extension draft, draft-ietf-tsvwg-fecframe-ext-00.txt), comments would be welcome at any tim= e. In particular, there's no need to wait for Working Group Last Call to s= end comments to the list. Thanks, --David From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Xiaomeng Shi Sent: Wednesday, July 19, 2017 2:54 PM To: tsvwg@ietf.org Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rlc-fec-scheme-00.txt Dear Vincent and all, Thank you very much for the great effort. This is my first post to the gro= up, and I hope my message has come at an appropriate time during the pipeli= ne. I work with Code On Technologies in Cambridge, MA, where our focus is = in the application of random linear network codes in different layers of th= e network stack to achieve performance improvements when possible. We are delighted to see that the sliding window approach has become a worki= ng group item and we are in full support of the initiative. To this extent= , we thought it might be of interest to the group to see some past research= work in this area, either from us, or that we are aware of. Below is a qu= ick list, and we look forward to future discussions within tsvwg. 1) Network Coding Overview, IETF 86, 2013, Code On Technologies, https://ww= w.ietf.org/proceedings/86/slides/slides-86-nwcrg-5.pdf. 2) T. Ho, et al., "A random linear network coding approach to multicast," I= EEE Transactions on Information Theory, vol. 52, no. 10, pp. 4413-4430, 200= 6. 3) JK, Sundararajan et al., "Network coding meets TCP," INFOCOM 2009, IEEE.= IEEE, 2009. 4) M. Kim et al., "Modeling network coded TCP throughput: A simple model an= d its validation," Proceedings of the 5th International ICST Conference on = Performance Evaluation Methodologies and Tools. ICST (Institute for Compute= r Sciences, Social-Informatics and Telecommunications Engineering), 2011. 5) S. Wunderlich et al., We don't need no generation-a practical approach t= o sliding window RLNC. In Wireless Days, 2017 (pp. 218-223). IEEE. Best regards, Shirley Shi On Jul 17, 2017, at 9:34 AM, internet-drafts@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group of the IETF. Title : Sliding Window Random Linear Code (RLC) Forward Er= asure Correction (FEC) Scheme for FECFRAME Author : Vincent Roca Filename : draft-ietf-tsvwg-rlc-fec-scheme-00.txt Pages : 23 Date : 2017-07-17 Abstract: This document describes a fully-specified FEC scheme for the Sliding Window Random Linear Codes (RLC) over GF(2^^m), where m equals 1 (binary case), 4 or 8, that can be used to protect arbitrary media streams along the lines defined by FECFRAME extended to sliding window 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 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-00 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rlc-fec-scheme-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ --_000_CE03DB3D7B45C245BCA0D243277949362FB8E546MX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Shirley,<= o:p>

 

Thank you for your interest, and the = timing is fine.  The background information is useful – beyond t= hat, if you and/or your colleagues are interested in reviewing this draft (and the supporting framework extension draft,   

draft-ietf-tsvwg-fecframe-ext-00.txt)= , comments would be welcome at any time.  In particular, there’s= no need to wait for Working Group Last Call to send comments to the list.

 

Thanks, --David

 

From: tsvwg [mailto:tsvwg-bounces@ie= tf.org] On Behalf Of Xiaomeng Shi
Sent: Wednesday, July 19, 2017 2:54 PM
To: tsvwg@ietf.org
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rlc-fec-scheme-00.= txt

 

Dear Vincent and all,

 

Thank you very much for the great effort.  This= is my first post to the group, and I hope my message has come at an approp= riate time during the pipeline.  I work with Code On Technologies in C= ambridge, MA, where our focus is in the application of random linear network codes in different layers of the network stack to= achieve performance improvements when possible.  



We are delighted to see that the sliding window appr= oach has become a working group item and we are in full support of the init= iative.  To this extent, we thought it might be of interest to the gro= up to see some past research work in this area, either from us, or that we are aware of.  Below is a quick list= , and we look forward to future discussions within tsvwg. <= /p>

 

1) Network Coding Overview, IETF 86, 2013, Code On T= echnologies, https://www.ietf.org/proce= edings/86/slides/slides-86-nwcrg-5.pdf.

2) T. Ho, et al., "A random linear network codi= ng approach to multicast," IEEE Transactions on Information Theory, vo= l. 52, no. 10, pp. 4413-4430, 2006.

3) JK, Sundararajan et al., "Network = coding meets TCP," INFOCOM 2009, IEEE. IEEE, 2009.

4) M. Kim et al., "Modeling network coded TCP t= hroughput: A simple model and its validation," Proceedings of the= 5th International ICST Conference on Performance Evaluation Methodologies = and Tools. ICST (Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering), 2011.

5) S. Wunderlich et al., We don't need no gener= ation-a practical approach to sliding window RLNC. In Wireless Days, 2= 017 (pp. 218-223). IEEE.

 

Best regards,

Shirley Shi

 



 

On Jul 17, 2017, at 9:34 AM, internet-drafts@ietf.org wrote:

 


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Transport Area Working Group of the IETF.<= br>
       Title     &nb= sp;     : Sliding Window Random Linear Code (RLC) = Forward Erasure Correction (FEC) Scheme for FECFRAME
       Author     &n= bsp;    : Vincent Roca
Filename        : draft-ietf-tsvwg-rlc-f= ec-scheme-00.txt
Pages           : 23
Date            : 20= 17-07-17

Abstract:
  This document describes a fully-specified FEC scheme for the Sl= iding
  Window Random Linear Codes (RLC) over GF(2^^m), where m equals = 1
  (binary case), 4 or 8, that can be used to protect arbitrary me= dia
  streams along the lines defined by FECFRAME extended to sliding=
  window codes.  These sliding window FEC codes rely on an e= ncoding
  window that slides over the source symbols, generating new repa= ir
  symbols whenever needed.  Compared to block FEC codes, the= se sliding
  window FEC codes offer key advantages with real-time flows in t= erms
  of reduced FEC-related latency while often providing improved e= rasure
  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-00
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rlc-fec-sc= heme-00


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

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

 

--_000_CE03DB3D7B45C245BCA0D243277949362FB8E546MX307CL04corpem_-- From nobody Wed Jul 26 01:39:40 2017 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 3D97C131FCA for ; Wed, 26 Jul 2017 01:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.752 X-Spam-Level: X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 SwdBCwgbsdSO for ; Wed, 26 Jul 2017 01:39:36 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id A4095131FBE for ; Wed, 26 Jul 2017 01:39:36 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 2183F1B00078 for ; Wed, 26 Jul 2017 11:32:57 +0100 (BST) Message-ID: <59785536.70201@erg.abdn.ac.uk> Date: Wed, 26 Jul 2017 09:39:18 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tsvwg] Corrected TSVWG minutes available for IETF-99 (Prague) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 08:39:39 -0000 Thanks to all who contrinuted and attended the meeting in Prague. The slides and a corrected copy of the meeting minute is now uploaded to the materials pages. Please check, and please send any corrections to the list/chairs. https://datatracker.ietf.org/meeting/99/materials Best wishes, Gorry, David and Wes. Please comment on the list: - Please make measurements about the effect of selecting the DS LE codepoint. - ECN encaps and shim have been talked about a lot at this IETF, they may be ready soon to progress - please read. - L4S arch needs eyes from anyone who has interest in ECN and L4S in particular. - Please read SCTP rfc4960-errata if you have intrest in SCTP. From nobody Thu Jul 27 10:08:10 2017 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 CD0BB131891 for ; Thu, 27 Jul 2017 10:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 NI4C3q2QLsCM for ; Thu, 27 Jul 2017 10:08:06 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 3FFD4131CF4 for ; Thu, 27 Jul 2017 10:08:06 -0700 (PDT) X-AuditID: 12074424-9d3ff70000003316-a0-597a1df4538b 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-7.mit.edu (Symantec Messaging Gateway) with SMTP id 0A.C6.13078.4FD1A795; Thu, 27 Jul 2017 13:08:05 -0400 (EDT) Received: from outgoing-exchange-4.mit.edu (OUTGOING-EXCHANGE-4.MIT.EDU [18.7.34.13]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v6RH83b3008524; Thu, 27 Jul 2017 13:08:03 -0400 Received: from W92EXEDGE6.EXCHANGE.MIT.EDU (W92EXEDGE6.EXCHANGE.MIT.EDU [18.7.73.28]) by outgoing-exchange-4.mit.edu (8.13.8/8.12.4) with ESMTP id v6RH819K010665; Thu, 27 Jul 2017 13:08:02 -0400 Received: from OC11EXHUB11.exchange.mit.edu (18.9.3.25) by W92EXEDGE6.EXCHANGE.MIT.EDU (18.7.73.28) with Microsoft SMTP Server (TLS) id 14.3.339.0; Thu, 27 Jul 2017 13:07:59 -0400 Received: from OC11EXPO31.exchange.mit.edu ([169.254.1.200]) by OC11EXHUB11.exchange.mit.edu ([18.9.3.25]) with mapi id 14.03.0235.001; Thu, 27 Jul 2017 13:08:01 -0400 From: Xiaomeng Shi To: "Black, David" CC: Xiaomeng Shi , "tsvwg@ietf.org" Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-rlc-fec-scheme-00.txt Thread-Index: AQHS/wFybhjnAphdEkyibIThkIC+u6JbxdCAgAap9ACABcsSgA== Date: Thu, 27 Jul 2017 17:08:01 +0000 Message-ID: <2C00E20B-E85C-4F6F-BA28-33FA703BAB44@mit.edu> References: <150029847620.14798.5607143949067995735@ietfa.amsl.com> <3A1480C1-C475-46EF-B776-0E9714FD4DB2@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [18.101.24.185] Content-Type: multipart/alternative; boundary="_000_2C00E20BE85C4F6FBA2833FA703BAB44mitedu_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJJsWRmVeSWpSXmKPExsUixCmqrPtVtirSoGE3l8XHWYtZLI69ucvm wOQxaeYMZo8lS34yBTBFcdmkpOZklqUW6dslcGV0vdnBVnDrEGPFoas72BsYD+9l7GLk5JAQ MJH4tO0sUxcjF4eQwGImiQNzb7OAJIQEDjBKnGqNhkgcY5RoaZ8IVbWdUeLT1D8sEM5qRon1 s+8zg7SwCShK3Np6FWguB4eIgKbEw7kuIGFmASeJe9seM4OEhQXcJQ40J4OERQQ8JH6dvMAK YTtJLHs8hw2khEVAVeLs2zAQk1fASmLDjQqIRTsYJa6vfcsEUs4p4Cdx7mkH2AOMAmIS30+t YYLYJC5x68l8JojHBCUWzd7DDGGLSfzb9ZANwlaUuNy2gAWiPk5iysWTYPW8QPUnZz5hmcAo PgvJqFlIymYhKZsFdB4z0I/rd+lDlChKTOl+yA5ha0i0zpnLDlFiL/F1XTaykgWMHKsYZVNy q3RzEzNzilOTdYuTE/PyUot0zfVyM0v0UlNKNzGC4pjdRWUHY3eP9yFGAQ5GJR7eBx8rI4VY E8uKK3MPMUpyMCmJ8k4yrYgU4kvKT6nMSCzOiC8qzUktPsQowcGsJMJrIlAVKcSbklhZlVqU D5OS5mBREucV12iMEBJITyxJzU5NLUgtgsnKcHAoSfBelQFqFCxKTU+tSMvMKUFIM3Fwggzn ARr+A6SGt7ggMbc4Mx0if4rRnmPL7xPfmTgOgcljYLLp+8fvTEIsefl5qVLivOdB2gRA2jJK 8+Amg1M0u6fMK0ZxoEeFebVBqniA6R1u9iugtUxAayc2VYKsLUlESEk1MBrtfGx1MsGi2ttX zf/c8n8TnvheeShwXjDjwfos5Uj9l1uOz6ndfXPdcoO9oQw/vvzbtKaU1ynR9f2z7vRJRmqv HzV/3zDxPJPPhDvZ/94qPWR/5nc6SY4tQ7NG7+yuCw993j77w+p0/n9BfRjTkdA9hacvyawq cgy+Ie+l8Xih6bsDvef/mHkpsRRnJBpqMRcVJwIA6v5vzKwDAAA= Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rlc-fec-scheme-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 17:08:09 -0000 --_000_2C00E20BE85C4F6FBA2833FA703BAB44mitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBEYXZpZCwNCg0KVGhhbmsgeW91IGZvciB0aGUgbm90ZSEgIEkgd2lsbCByZWxheSB0aGUg bWVzc2FnZSB0byBteSBjb2xsZWFndWVzIGFzIHdlbGwuDQoNCkJlc3QsDQpTaGlybGV5DQoNCg0K T24gSnVsIDIzLCAyMDE3LCBhdCA4OjM5IFBNLCBCbGFjaywgRGF2aWQgPERhdmlkLkJsYWNrQGRl bGwuY29tPG1haWx0bzpEYXZpZC5CbGFja0BkZWxsLmNvbT4+IHdyb3RlOg0KDQpTaGlybGV5LA0K DQpUaGFuayB5b3UgZm9yIHlvdXIgaW50ZXJlc3QsIGFuZCB0aGUgdGltaW5nIGlzIGZpbmUuICBU aGUgYmFja2dyb3VuZCBpbmZvcm1hdGlvbiBpcyB1c2VmdWwg4oCTIGJleW9uZCB0aGF0LCBpZiB5 b3UgYW5kL29yIHlvdXIgY29sbGVhZ3VlcyBhcmUgaW50ZXJlc3RlZCBpbiByZXZpZXdpbmcgdGhp cyBkcmFmdCAoYW5kIHRoZSBzdXBwb3J0aW5nIGZyYW1ld29yayBleHRlbnNpb24gZHJhZnQsDQpk cmFmdC1pZXRmLXRzdndnLWZlY2ZyYW1lLWV4dC0wMC50eHQpLCBjb21tZW50cyB3b3VsZCBiZSB3 ZWxjb21lIGF0IGFueSB0aW1lLiAgSW4gcGFydGljdWxhciwgdGhlcmXigJlzIG5vIG5lZWQgdG8g d2FpdCBmb3IgV29ya2luZyBHcm91cCBMYXN0IENhbGwgdG8gc2VuZCBjb21tZW50cyB0byB0aGUg bGlzdC4NCg0KVGhhbmtzLCAtLURhdmlkDQoNCkZyb206IHRzdndnIFttYWlsdG86dHN2d2ctYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFhpYW9tZW5nIFNoaQ0KU2VudDogV2VkbmVzZGF5 LCBKdWx5IDE5LCAyMDE3IDI6NTQgUE0NClRvOiB0c3Z3Z0BpZXRmLm9yZzxtYWlsdG86dHN2d2dA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3RzdndnXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXRz dndnLXJsYy1mZWMtc2NoZW1lLTAwLnR4dA0KDQpEZWFyIFZpbmNlbnQgYW5kIGFsbCwNCg0KVGhh bmsgeW91IHZlcnkgbXVjaCBmb3IgdGhlIGdyZWF0IGVmZm9ydC4gIFRoaXMgaXMgbXkgZmlyc3Qg cG9zdCB0byB0aGUgZ3JvdXAsIGFuZCBJIGhvcGUgbXkgbWVzc2FnZSBoYXMgY29tZSBhdCBhbiBh cHByb3ByaWF0ZSB0aW1lIGR1cmluZyB0aGUgcGlwZWxpbmUuICBJIHdvcmsgd2l0aCBDb2RlIE9u IFRlY2hub2xvZ2llcyBpbiBDYW1icmlkZ2UsIE1BLCB3aGVyZSBvdXIgZm9jdXMgaXMgaW4gdGhl IGFwcGxpY2F0aW9uIG9mIHJhbmRvbSBsaW5lYXIgbmV0d29yayBjb2RlcyBpbiBkaWZmZXJlbnQg bGF5ZXJzIG9mIHRoZSBuZXR3b3JrIHN0YWNrIHRvIGFjaGlldmUgcGVyZm9ybWFuY2UgaW1wcm92 ZW1lbnRzIHdoZW4gcG9zc2libGUuDQoNCg0KV2UgYXJlIGRlbGlnaHRlZCB0byBzZWUgdGhhdCB0 aGUgc2xpZGluZyB3aW5kb3cgYXBwcm9hY2ggaGFzIGJlY29tZSBhIHdvcmtpbmcgZ3JvdXAgaXRl bSBhbmQgd2UgYXJlIGluIGZ1bGwgc3VwcG9ydCBvZiB0aGUgaW5pdGlhdGl2ZS4gIFRvIHRoaXMg ZXh0ZW50LCB3ZSB0aG91Z2h0IGl0IG1pZ2h0IGJlIG9mIGludGVyZXN0IHRvIHRoZSBncm91cCB0 byBzZWUgc29tZSBwYXN0IHJlc2VhcmNoIHdvcmsgaW4gdGhpcyBhcmVhLCBlaXRoZXIgZnJvbSB1 cywgb3IgdGhhdCB3ZSBhcmUgYXdhcmUgb2YuICBCZWxvdyBpcyBhIHF1aWNrIGxpc3QsIGFuZCB3 ZSBsb29rIGZvcndhcmQgdG8gZnV0dXJlIGRpc2N1c3Npb25zIHdpdGhpbiB0c3Z3Zy4NCg0KMSkg TmV0d29yayBDb2RpbmcgT3ZlcnZpZXcsIElFVEYgODYsIDIwMTMsIENvZGUgT24gVGVjaG5vbG9n aWVzLCBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84Ni9zbGlkZXMvc2xpZGVzLTg2 LW53Y3JnLTUucGRmLg0KMikgVC4gSG8sIGV0IGFsLiwgIkEgcmFuZG9tIGxpbmVhciBuZXR3b3Jr IGNvZGluZyBhcHByb2FjaCB0byBtdWx0aWNhc3QsIiBJRUVFIFRyYW5zYWN0aW9ucyBvbiBJbmZv cm1hdGlvbiBUaGVvcnksIHZvbC4gNTIsIG5vLiAxMCwgcHAuIDQ0MTMtNDQzMCwgMjAwNi4NCjMp IEpLLCBTdW5kYXJhcmFqYW4gZXQgYWwuLCAiTmV0d29yayBjb2RpbmcgbWVldHMgVENQLCIgSU5G T0NPTSAyMDA5LCBJRUVFLiBJRUVFLCAyMDA5Lg0KNCkgTS4gS2ltIGV0IGFsLiwgIk1vZGVsaW5n IG5ldHdvcmsgY29kZWQgVENQIHRocm91Z2hwdXQ6IEEgc2ltcGxlIG1vZGVsIGFuZCBpdHMgdmFs aWRhdGlvbiwiIFByb2NlZWRpbmdzIG9mIHRoZSA1dGggSW50ZXJuYXRpb25hbCBJQ1NUIENvbmZl cmVuY2Ugb24gUGVyZm9ybWFuY2UgRXZhbHVhdGlvbiBNZXRob2RvbG9naWVzIGFuZCBUb29scy4g SUNTVCAoSW5zdGl0dXRlIGZvciBDb21wdXRlciBTY2llbmNlcywgU29jaWFsLUluZm9ybWF0aWNz IGFuZCBUZWxlY29tbXVuaWNhdGlvbnMgRW5naW5lZXJpbmcpLCAyMDExLg0KNSkgUy4gV3VuZGVy bGljaCBldCBhbC4sIFdlIGRvbid0IG5lZWQgbm8gZ2VuZXJhdGlvbi1hIHByYWN0aWNhbCBhcHBy b2FjaCB0byBzbGlkaW5nIHdpbmRvdyBSTE5DLiBJbiBXaXJlbGVzcyBEYXlzLCAyMDE3IChwcC4g MjE4LTIyMykuIElFRUUuDQoNCkJlc3QgcmVnYXJkcywNClNoaXJsZXkgU2hpDQoNCg0KDQoNCk9u IEp1bCAxNywgMjAxNywgYXQgOTozNCBBTSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQoNCkEgTmV3IEludGVybmV0LURy YWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rv cmllcy4NClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFRyYW5zcG9ydCBBcmVhIFdv cmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQoNCiAgICAgICBUaXRsZSAgICAgICAgICAgOiBTbGlk aW5nIFdpbmRvdyBSYW5kb20gTGluZWFyIENvZGUgKFJMQykgRm9yd2FyZCBFcmFzdXJlIENvcnJl Y3Rpb24gKEZFQykgU2NoZW1lIGZvciBGRUNGUkFNRQ0KICAgICAgIEF1dGhvciAgICAgICAgICA6 IFZpbmNlbnQgUm9jYQ0KRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi10c3Z3Zy1ybGMtZmVj LXNjaGVtZS0wMC50eHQNClBhZ2VzICAgICAgICAgICA6IDIzDQpEYXRlICAgICAgICAgICAgOiAy MDE3LTA3LTE3DQoNCkFic3RyYWN0Og0KICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIGZ1bGx5 LXNwZWNpZmllZCBGRUMgc2NoZW1lIGZvciB0aGUgU2xpZGluZw0KICBXaW5kb3cgUmFuZG9tIExp bmVhciBDb2RlcyAoUkxDKSBvdmVyIEdGKDJeXm0pLCB3aGVyZSBtIGVxdWFscyAxDQogIChiaW5h cnkgY2FzZSksIDQgb3IgOCwgdGhhdCBjYW4gYmUgdXNlZCB0byBwcm90ZWN0IGFyYml0cmFyeSBt ZWRpYQ0KICBzdHJlYW1zIGFsb25nIHRoZSBsaW5lcyBkZWZpbmVkIGJ5IEZFQ0ZSQU1FIGV4dGVu ZGVkIHRvIHNsaWRpbmcNCiAgd2luZG93IGNvZGVzLiAgVGhlc2Ugc2xpZGluZyB3aW5kb3cgRkVD IGNvZGVzIHJlbHkgb24gYW4gZW5jb2RpbmcNCiAgd2luZG93IHRoYXQgc2xpZGVzIG92ZXIgdGhl IHNvdXJjZSBzeW1ib2xzLCBnZW5lcmF0aW5nIG5ldyByZXBhaXINCiAgc3ltYm9scyB3aGVuZXZl ciBuZWVkZWQuICBDb21wYXJlZCB0byBibG9jayBGRUMgY29kZXMsIHRoZXNlIHNsaWRpbmcNCiAg d2luZG93IEZFQyBjb2RlcyBvZmZlciBrZXkgYWR2YW50YWdlcyB3aXRoIHJlYWwtdGltZSBmbG93 cyBpbiB0ZXJtcw0KICBvZiByZWR1Y2VkIEZFQy1yZWxhdGVkIGxhdGVuY3kgd2hpbGUgb2Z0ZW4g cHJvdmlkaW5nIGltcHJvdmVkIGVyYXN1cmUNCiAgcmVjb3ZlcnkgY2FwYWJpbGl0aWVzLg0KDQoN ClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10c3Z3Zy1ybGMtZmVjLXNj aGVtZS8NCg0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0K aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHN2d2ctcmxjLWZlYy1zY2hl bWUtMDANCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi10 c3Z3Zy1ybGMtZmVjLXNjaGVtZS0wMA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRo ZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5v cmc8aHR0cDovL3Rvb2xzLmlldGYub3JnLz4uDQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBh dmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvDQoNCg== --_000_2C00E20BE85C4F6FBA2833FA703BAB44mitedu_ Content-Type: text/html; charset="utf-8" Content-ID: <8DF7528A9970164C96CD4CCBD0E25CEB@exchange.mit.edu> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KRGVhciBEYXZpZCwNCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rIHlvdSBmb3Ig dGhlIG5vdGUhICZuYnNwO0kgd2lsbCByZWxheSB0aGUgbWVzc2FnZSB0byBteSBjb2xsZWFndWVz IGFzIHdlbGwuDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5CZXN0LDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5TaGlybGV5PGJyIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj5PbiBKdWwgMjMsIDIwMTcsIGF0IDg6MzkgUE0sIEJsYWNrLCBEYXZpZCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOkRhdmlkLkJsYWNrQGRlbGwuY29tIiBjbGFzcz0iIj5EYXZpZC5CbGFja0BkZWxs LmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1u ZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxl PSJwYWdlOiBXb3JkU2VjdGlvbjE7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8YSBu YW1lPSJfTWFpbEVuZENvbXBvc2UiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3Mywg MTI1KTsiIGNsYXNzPSIiPlNoaXJsZXksPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9hPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIi PlRoYW5rIHlvdSBmb3IgeW91ciBpbnRlcmVzdCwgYW5kIHRoZSB0aW1pbmcgaXMgZmluZS4mbmJz cDsgVGhlIGJhY2tncm91bmQgaW5mb3JtYXRpb24gaXMgdXNlZnVsIOKAkyBiZXlvbmQgdGhhdCwg aWYgeW91IGFuZC9vciB5b3VyIGNvbGxlYWd1ZXMgYXJlIGludGVyZXN0ZWQgaW4gcmV2aWV3aW5n DQogdGhpcyBkcmFmdCAoYW5kIHRoZSBzdXBwb3J0aW5nIGZyYW1ld29yayBleHRlbnNpb24gZHJh ZnQsICZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwg NzMsIDEyNSk7IiBjbGFzcz0iIj5kcmFmdC1pZXRmLXRzdndnLWZlY2ZyYW1lLWV4dC0wMC50eHQp LCBjb21tZW50cyB3b3VsZCBiZSB3ZWxjb21lIGF0IGFueSB0aW1lLiZuYnNwOyBJbiBwYXJ0aWN1 bGFyLCB0aGVyZeKAmXMgbm8gbmVlZCB0byB3YWl0IGZvciBXb3JraW5nIEdyb3VwIExhc3QgQ2Fs bCB0byBzZW5kIGNvbW1lbnRzDQogdG8gdGhlIGxpc3QuPG86cCBjbGFzcz0iIj48L286cD48L3Nw YW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0i Ij4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMx LCA3MywgMTI1KTsiIGNsYXNzPSIiPlRoYW5rcywgLS1EYXZpZDxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+ PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXItc3R5bGU6IG5vbmUgbm9uZSBub25lIHNvbGlkOyBib3JkZXItbGVmdC13aWR0aDogMS41cHQ7 IGJvcmRlci1sZWZ0LWNvbG9yOiBibHVlOyBwYWRkaW5nOiAwaW4gMGluIDBpbiA0cHQ7IiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IHNvbGlkIG5v bmUgbm9uZTsgYm9yZGVyLXRvcC13aWR0aDogMXB0OyBib3JkZXItdG9wLWNvbG9yOiByZ2IoMjI1 LCAyMjUsIDIyNSk7IHBhZGRpbmc6IDNwdCAwaW4gMGluOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48c3BhbiBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+dHN2d2cgWzxhIGhyZWY9Im1haWx0 bzp0c3Z3Zy1ib3VuY2VzQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNv cmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5tYWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9y ZzwvYT5dPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxi IGNsYXNzPSIiPk9uDQogQmVoYWxmIE9mPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjwvYj5YaWFvbWVuZyBTaGk8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0i Ij5TZW50OjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+V2VkbmVzZGF5LCBKdWx5IDE5LCAyMDE3IDI6NTQgUE08YnIgY2xhc3M9IiI+DQo8YiBjbGFz cz0iIj5Ubzo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxhIGhyZWY9Im1haWx0bzp0c3Z3Z0BpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7 IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+dHN2d2dAaWV0Zi5vcmc8L2E+ PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbdHN2d2ddIEktRCBBY3Rpb246IGRy YWZ0LWlldGYtdHN2d2ctcmxjLWZlYy1zY2hlbWUtMDAudHh0PG86cCBjbGFzcz0iIj48L286cD48 L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyIgY2xhc3M9IiI+DQpEZWFyIFZpbmNlbnQgYW5kIGFsbCw8bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0K VGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgdGhlIGdyZWF0IGVmZm9ydC4gJm5ic3A7VGhpcyBpcyBt eSBmaXJzdCBwb3N0IHRvIHRoZSBncm91cCwgYW5kIEkgaG9wZSBteSBtZXNzYWdlIGhhcyBjb21l IGF0IGFuIGFwcHJvcHJpYXRlIHRpbWUgZHVyaW5nIHRoZSBwaXBlbGluZS4gJm5ic3A7SSB3b3Jr IHdpdGggQ29kZSBPbiBUZWNobm9sb2dpZXMgaW4gQ2FtYnJpZGdlLCBNQSwgd2hlcmUgb3VyIGZv Y3VzIGlzIGluIHRoZSBhcHBsaWNhdGlvbiBvZiByYW5kb20gbGluZWFyDQogbmV0d29yayBjb2Rl cyBpbiBkaWZmZXJlbnQgbGF5ZXJzIG9mIHRoZSBuZXR3b3JrIHN0YWNrIHRvIGFjaGlldmUgcGVy Zm9ybWFuY2UgaW1wcm92ZW1lbnRzIHdoZW4gcG9zc2libGUuICZuYnNwOzxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpXZSBhcmUgZGVs aWdodGVkIHRvIHNlZSB0aGF0IHRoZSBzbGlkaW5nIHdpbmRvdyBhcHByb2FjaCBoYXMgYmVjb21l IGEgd29ya2luZyBncm91cCBpdGVtIGFuZCB3ZSBhcmUgaW4gZnVsbCBzdXBwb3J0IG9mIHRoZSBp bml0aWF0aXZlLiAmbmJzcDtUbyB0aGlzIGV4dGVudCwgd2UgdGhvdWdodCBpdCBtaWdodCBiZSBv ZiBpbnRlcmVzdCB0byB0aGUgZ3JvdXAgdG8gc2VlIHNvbWUgcGFzdCByZXNlYXJjaCB3b3JrIGlu IHRoaXMgYXJlYSwgZWl0aGVyIGZyb20NCiB1cywgb3IgdGhhdCB3ZSBhcmUgYXdhcmUgb2YuICZu YnNwO0JlbG93IGlzIGEgcXVpY2sgbGlzdCwgYW5kIHdlIGxvb2sgZm9yd2FyZCB0byBmdXR1cmUg ZGlzY3Vzc2lvbnMgd2l0aGluIHRzdndnLiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQoxKSBOZXR3b3JrIENv ZGluZyBPdmVydmlldywgSUVURiA4NiwgMjAxMywgQ29kZSBPbiBUZWNobm9sb2dpZXMsJm5ic3A7 PHNwYW4gc3R5bGU9ImNvbG9yOiBwdXJwbGU7IiBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84Ni9zbGlkZXMvc2xpZGVzLTg2LW53Y3JnLTUucGRmIiBz dHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0i Ij5odHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84Ni9zbGlkZXMvc2xpZGVzLTg2LW53 Y3JnLTUucGRmPC9hPi48L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xh c3M9IiI+DQoyKSBULiBIbywgZXQgYWwuLCAmcXVvdDtBIHJhbmRvbSBsaW5lYXIgbmV0d29yayBj b2RpbmcgYXBwcm9hY2ggdG8gbXVsdGljYXN0LCZxdW90OyBJRUVFIFRyYW5zYWN0aW9ucyBvbiBJ bmZvcm1hdGlvbiBUaGVvcnksIHZvbC4gNTIsIG5vLiAxMCwgcHAuIDQ0MTMtNDQzMCwgMjAwNi48 bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjMpIEpLLCZuYnNwO1N1 bmRhcmFyYWphbiZuYnNwO2V0IGFsLiwgJnF1b3Q7TmV0d29yayBjb2RpbmcgbWVldHMgVENQLCZx dW90OyZuYnNwO0lORk9DT00gMjAwOSwgSUVFRS4gSUVFRSwgMjAwOS48bzpwIGNsYXNzPSIiPjwv bzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjQpIE0uIEtpbSBldCBhbC4sICZxdW90O01vZGVs aW5nIG5ldHdvcmsgY29kZWQgVENQIHRocm91Z2hwdXQ6IEEgc2ltcGxlIG1vZGVsIGFuZCBpdHMg dmFsaWRhdGlvbiwmcXVvdDsmbmJzcDtQcm9jZWVkaW5ncyBvZiB0aGUgNXRoIEludGVybmF0aW9u YWwgSUNTVCBDb25mZXJlbmNlIG9uIFBlcmZvcm1hbmNlIEV2YWx1YXRpb24gTWV0aG9kb2xvZ2ll cyBhbmQgVG9vbHMuIElDU1QgKEluc3RpdHV0ZSBmb3IgQ29tcHV0ZXIgU2NpZW5jZXMsIFNvY2lh bC1JbmZvcm1hdGljcyBhbmQNCiBUZWxlY29tbXVuaWNhdGlvbnMgRW5naW5lZXJpbmcpLCAyMDEx LjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KNSkgUy4mbmJzcDtX dW5kZXJsaWNoIGV0IGFsLiwgV2UgZG9uJ3QgbmVlZCBubyBnZW5lcmF0aW9uLWEgcHJhY3RpY2Fs IGFwcHJvYWNoIHRvIHNsaWRpbmcgd2luZG93IFJMTkMuIEluJm5ic3A7V2lyZWxlc3MgRGF5cywg MjAxNyZuYnNwOyhwcC4gMjE4LTIyMykuIElFRUUuPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4N CjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCkJlc3QgcmVnYXJkcyw8 bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NClNoaXJsZXkgU2hpPG86 cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xh c3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0 OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IiBjbGFzcz0iIj4NCk9uIEp1bCAxNywgMjAxNywgYXQgOTozNCBBTSw8c3BhbiBj bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVj b3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9h PjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj53cm90ZTo8 bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAxMnB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxiciBjbGFzcz0iIj4NCkEgTmV3IEludGVy bmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBk aXJlY3Rvcmllcy48YnIgY2xhc3M9IiI+DQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRo ZSBUcmFuc3BvcnQgQXJlYSBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O1RpdGxlICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzogU2xpZGluZyBXaW5kb3cgUmFuZG9tIExpbmVhciBDb2RlIChSTEMpIEZvcndh cmQgRXJhc3VyZSBDb3JyZWN0aW9uIChGRUMpIFNjaGVtZSBmb3IgRkVDRlJBTUU8YnIgY2xhc3M9 IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtBdXRob3IgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBWaW5j ZW50IFJvY2E8YnIgY2xhc3M9IiI+DQpGaWxlbmFtZSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDs6IGRyYWZ0LWlldGYtdHN2d2ctcmxjLWZlYy1zY2hlbWUtMDAudHh0 PGJyIGNsYXNzPSIiPg0KUGFnZXMgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiAyMzxiciBjbGFzcz0iIj4NCkRhdGUgJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 OiAyMDE3LTA3LTE3PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQWJzdHJhY3Q6PGJyIGNs YXNzPSIiPg0KJm5ic3A7Jm5ic3A7VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBmdWxseS1zcGVj aWZpZWQgRkVDIHNjaGVtZSBmb3IgdGhlIFNsaWRpbmc8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJz cDtXaW5kb3cgUmFuZG9tIExpbmVhciBDb2RlcyAoUkxDKSBvdmVyIEdGKDJeXm0pLCB3aGVyZSBt IGVxdWFscyAxPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7KGJpbmFyeSBjYXNlKSwgNCBvciA4 LCB0aGF0IGNhbiBiZSB1c2VkIHRvIHByb3RlY3QgYXJiaXRyYXJ5IG1lZGlhPGJyIGNsYXNzPSIi Pg0KJm5ic3A7Jm5ic3A7c3RyZWFtcyBhbG9uZyB0aGUgbGluZXMgZGVmaW5lZCBieSBGRUNGUkFN RSBleHRlbmRlZCB0byBzbGlkaW5nPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7d2luZG93IGNv ZGVzLiAmbmJzcDtUaGVzZSBzbGlkaW5nIHdpbmRvdyBGRUMgY29kZXMgcmVseSBvbiBhbiBlbmNv ZGluZzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO3dpbmRvdyB0aGF0IHNsaWRlcyBvdmVyIHRo ZSBzb3VyY2Ugc3ltYm9scywgZ2VuZXJhdGluZyBuZXcgcmVwYWlyPGJyIGNsYXNzPSIiPg0KJm5i c3A7Jm5ic3A7c3ltYm9scyB3aGVuZXZlciBuZWVkZWQuICZuYnNwO0NvbXBhcmVkIHRvIGJsb2Nr IEZFQyBjb2RlcywgdGhlc2Ugc2xpZGluZzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO3dpbmRv dyBGRUMgY29kZXMgb2ZmZXIga2V5IGFkdmFudGFnZXMgd2l0aCByZWFsLXRpbWUgZmxvd3MgaW4g dGVybXM8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtvZiByZWR1Y2VkIEZFQy1yZWxhdGVkIGxh dGVuY3kgd2hpbGUgb2Z0ZW4gcHJvdmlkaW5nIGltcHJvdmVkIGVyYXN1cmU8YnIgY2xhc3M9IiI+ DQombmJzcDsmbmJzcDtyZWNvdmVyeSBjYXBhYmlsaXRpZXMuPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2Ug Zm9yIHRoaXMgZHJhZnQgaXM6PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10c3Z3Zy1ybGMtZmVjLXNjaGVtZS8iIHN0eWxl PSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHN2d2ctcmxjLWZlYy1z Y2hlbWUvPC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZXJlIGFyZSBhbHNvIGh0 bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDo8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10c3Z3Zy1ybGMtZmVjLXNjaGVtZS0w MCIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xh c3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHN2d2ctcmxjLWZl Yy1zY2hlbWUtMDA8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXRzdndnLXJsYy1mZWMtc2NoZW1lLTAwIiBz dHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0i Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdHN2d2ct cmxjLWZlYy1zY2hlbWUtMDA8L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxiciBjbGFzcz0iIj4NCnVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQ8c3BhbiBjbGFzcz0iQXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYu b3JnLyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIg Y2xhc3M9IiI+dG9vbHMuaWV0Zi5vcmc8L2E+LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8 YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz LyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xh c3M9IiI+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88L2E+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2C00E20BE85C4F6FBA2833FA703BAB44mitedu_-- From nobody Thu Jul 27 15:30:20 2017 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 77832126C0F; Thu, 27 Jul 2017 15:30:19 -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.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150119461943.25303.13774993680222947702@ietfa.amsl.com> Date: Thu, 27 Jul 2017 15:30:19 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ieee-802-11-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 22:30:19 -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 : Diffserv to IEEE 802.11 Mapping Authors : Tim Szigeti Jerome Henry Fred Baker Filename : draft-ietf-tsvwg-ieee-802-11-05.txt Pages : 35 Date : 2017-07-27 Abstract: As internet traffic is increasingly sourced-from and destined-to wireless endpoints, it is crucial that Quality of Service be aligned between wired and wireless networks; however, this is not always the case by default. This document specifies a set Differentiated Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings to reconcile the marking recommendations offered by the IETF and the IEEE so as to maintain consistent QoS treatment between wired and IEEE 802.11 wireless networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11-05 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ieee-802-11-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ieee-802-11-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 Thu Jul 27 15:33:59 2017 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 F0656131E06 for ; Thu, 27 Jul 2017 15:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 wiFVbTmqEBrF for ; Thu, 27 Jul 2017 15:33:56 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4A2A131D21 for ; Thu, 27 Jul 2017 15:33:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1745; q=dns/txt; s=iport; t=1501194835; x=1502404435; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=O38E2XI2fun/mFA2m6RsvK7izYQ9Ld04a3yfeGj56UM=; b=j6TlDCaKdO+MIGhFnJCpwABernpKhZQK5WxKkCjEY86pG39zqJh4Hqb+ iVXYhGLQH2Z9/33wqx9t7eedLWg2dFUXwmFZVprT92fzKfq46gzVuGXPY ne1Oxy8zXtBeWfZUPk57qy9sV8WaC0eFPu0PUYRQib91VssW0BO4YclGu k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CaAADgaXpZ/4sNJK1dDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNagVEnB44GkWKWCoIShUcCg2U/GAECAQEBAQEBAWsohRgBAQE?= =?us-ascii?q?BAzotEgwEAgEIEQQBAR8JBzIUCQgCBAENBQiKJ7F1iz8BAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEdgyiFLQGDJIE8g12FTgEEn2YClBqCFYVSg3iGZpVxAR84gQp3FYc?= =?us-ascii?q?jP3aIcoEOAQEB?= X-IronPort-AV: E=Sophos;i="5.40,422,1496102400"; d="scan'208";a="461879876" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Jul 2017 22:33:55 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v6RMXsLw016024 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Jul 2017 22:33:55 GMT Received: from xch-rcd-010.cisco.com (173.37.102.20) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 27 Jul 2017 17:33:54 -0500 Received: from xch-rcd-010.cisco.com ([173.37.102.20]) by XCH-RCD-010.cisco.com ([173.37.102.20]) with mapi id 15.00.1210.000; Thu, 27 Jul 2017 17:33:54 -0500 From: "Tim Szigeti (szigeti)" To: G Fairhurst , tsvwg WG CC: "Jerome Henry (jerhenry)" , Fred Baker Thread-Topic: [tsvwg] WGLC comments onn DS IEEE 802.11 (draft-ietf-tsvwg-ieee-802-11). Thread-Index: AQHS/AIbIN0bqsyF/ECSDWybZpuqiqJoWJzw Date: Thu, 27 Jul 2017 22:33:54 +0000 Message-ID: References: <5967B58F.1090900@erg.abdn.ac.uk> In-Reply-To: <5967B58F.1090900@erg.abdn.ac.uk> 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: [10.132.12.98] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] WGLC comments onn DS IEEE 802.11 (draft-ietf-tsvwg-ieee-802-11). X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 22:33:58 -0000 Hi Gorry, All changes suggested below have been incorporated in the latest version (5= ) of this PS. Thank you again for your feedback and guidance. -tim > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of G Fairhurst > Sent: Thursday, July 13, 2017 11:02 AM > To: tsvwg WG > Subject: [tsvwg] WGLC comments onn DS IEEE 802.11 (draft-ietf-tsvwg-ieee- > 802-11). >=20 > * > I have read the ID during the second WGLC and I think this address all th= e > things I commented upon in the previous version. >=20 > I have a few LC comments on the latest text: >=20 > (1) TEXT: > However, by default, packets marked DSCP CS6 will be mapped to UP 6 and > serviced within the Voice Access Category (AC_VO); such mapping and > servicing is a contradiction... > - I think it is not completely clear what "by default" means, that is whe= ther > the text is the recommended default from this spec or some other > recommendation. Could you tweak the words to clarify this - so that it is= clear > it is the latter? >=20 > (2) > In section 1.6, definition of DSCP. For the avoidance of doubt, I think i= t > probably is worth noting "The 6-bit DSCP field is carried in a byte of th= e IP > header together with the 2-bit Explicit Congestion Notification (ECN) fie= ld." > - This may help alert people that the bit manipulation describes also has= to > preserve the ECN field. >=20 > (3) Further NiT: > - Please define /GSMA/. >=20 > (4) I suspect the security section may benefit from a better definition o= f the > case where the 802.11 network forms the edge of a DS domain. I suspect > other people will suggest text on this. >=20 > Gorry >=20 >=20 > -------* From nobody Thu Jul 27 15:35:14 2017 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 ECB1A131E82 for ; Thu, 27 Jul 2017 15:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 5Xc7Bo_sNG9b for ; Thu, 27 Jul 2017 15:35:09 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48A6C1321DD for ; Thu, 27 Jul 2017 15:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9386; q=dns/txt; s=iport; t=1501194909; x=1502404509; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HBcfa0Gi6jE6xbUYC3ykh2RK8FnMhDS/BvyGnBclYC0=; b=aAA/OX6Cf8xULJ7KGUdM43kuKVU4i+KlQBCwgebs/E8OK8qfBDbEtOa4 6uEr7RQS+73I0wcwHit4NrmkbGqb5eLozhL6kvY+QHue+JHGLe0iGtwaG 8LC+d2G242/nSvrvN5WzJA18k2IuPE30W3ogBFBGXron6D8connmvJi8J A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CaAADgaXpZ/5tdJa1dDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNaZG0nB44GkWKWCg6CBCyFGwKDZT8YAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQEDDhkTKxQMBAIBCBEEAQEfCQcyFAkIAQEEAQ0FCIonELErOos/AQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGAWDJASFLQGDJIQ/AQESAUWFTgWXK4g7AodNgwKJS4I?= =?us-ascii?q?VhVKKXpE0hD0BHzh/C3cVHyqFFhwZgQ8/dodPgSOBDgEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,422,1496102400"; d="scan'208";a="273654946" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jul 2017 22:35:07 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v6RMZ75u014292 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Jul 2017 22:35:07 GMT Received: from xch-rcd-010.cisco.com (173.37.102.20) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 27 Jul 2017 17:35:07 -0500 Received: from xch-rcd-010.cisco.com ([173.37.102.20]) by XCH-RCD-010.cisco.com ([173.37.102.20]) with mapi id 15.00.1210.000; Thu, 27 Jul 2017 17:35:07 -0500 From: "Tim Szigeti (szigeti)" To: "Black, David" , G Fairhurst , tsvwg WG CC: "Jerome Henry (jerhenry)" , Fred Baker Thread-Topic: TSVWG Working Group Last Call (WGLC) on draft-ietf-tsvwg-ieee-802-11 - David Black's comments Thread-Index: AdL9iKwSAOxDD+ndQlSPMOl+i2FRxAJn8Ubw Date: Thu, 27 Jul 2017 22:35:07 +0000 Message-ID: <9603e1facabb48ec865439a997392120@XCH-RCD-010.cisco.com> References: In-Reply-To: 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: [10.132.12.98] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] TSVWG Working Group Last Call (WGLC) on draft-ietf-tsvwg-ieee-802-11 - David Black's comments X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 22:35:12 -0000 Hi David, Thank you again for taking the time to do another round of review. All changes you've suggested below have been made to the latest version of = the draft. Thank you again for helping us find the right balance on security vs. funct= ionality. -tim > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Black, David > Sent: Saturday, July 15, 2017 9:40 AM > To: G Fairhurst; tsvwg WG > Subject: [tsvwg] TSVWG Working Group Last Call (WGLC) on draft-ietf-tsvwg= - > ieee-802-11 - David Black's comments >=20 > In general, the -04 draft is much improved from the -01 draft. All of my > remaining major concerns involve uses of the word "trust" that >=20 > -- Major >=20 > Section 3: >=20 > This document assumes and RECOMMENDS that all wireless access points > (as the bridges between wired-and-wireless networks) support the > ability to: >=20 > [... snip ...] >=20 > o trust DSCP markings set by wireless endpoint devices >=20 > This instance of "trust" appears to have been overlooked. I suggest > changing "trust" to "process." >=20 > Section 5: >=20 > o DSCP-Trust at the wireless access point (effectively a 1:1 DSCP- > to-DSCP mapping) >=20 > Aha, the dreaded T-word again. Suggest: DSCP-Trust -> DSCP-Passthrough, > as that not only removes the T-word, but is also more descriptive. This= also > affects Section 5.3 ... >=20 > Section 5.3: >=20 > Change DSCP-Trust -> DSCP-Passthrough in section title. >=20 > It is generally NOT RECOMMENDED to trust DSCP markings from > unauthenticated and unauthorized devices, as these are typically > considered untrusted sources. >=20 > to trust DSCP markings -> to pass through DSCP markings >=20 > When business requirements and/or technical constraints and/or > administrative policies require a trust function at the wireless > edge, then it is RECOMMENDED to trust DSCP (over [IEEE.802.11-2016] > UP markings) markings in the upstream direction, for the following > reasons: >=20 > I don't understand what a "trust function" is, so this looks like a circu= lar > statement. Once "trust function" is clarified, change "RECOMMENDED to > trust DSCP" to "RECOMMENDED to pass through DSCP" ... but the details of > this clarification are crucial as this text is a potentially serious secu= rity hole as > currently written. >=20 > A related minor issue turns up in Section 8.1 - see below. >=20 > Finally, Gorry noted: >=20 > (4) I suspect the security section may benefit from a better definitio= n > of the case where the 802.11 network forms the edge of a DS domain. I > suspect other people will suggest text on this. >=20 > I suspect that some of the changes suggested in this review towards less = use > of the word "trust" will help with this concern, so I suggest that Gorry = and I > both take a look at the resulting text to see whether it suffices. That= said, it > would help to add a reference from the security considerations text on CS= 6 > and CS7 back to section 5.4, which discusses this "edge of a DS domain" c= ase. >=20 > -- Minor >=20 > Section 2.1: >=20 > Thus the QoS treatment of packets at the access point will depend on > the position of the AP in the network infrastructure and on the WLAN > deployment model. >=20 > Needs specific examples and/or forward references to what changes with AP > position. >=20 > Sections 5.2, 5.3 and 5.4: >=20 > These sections are effectively discussing alternatives for access point D= iffserv > functionality. That structure (do one of these three) is not clear in th= e draft. >=20 > Section 8.1: >=20 > Additionally, Section 5.3 made it clear > that it is generally NOT RECOMMENDED to trust DSCP markings from > unauthorized and/or unauthenticated devices, as these are > typically considered untrusted sources. This is especially > relevant for IoT deployments, where tens-of-billions of devices > are being connected to IP networks, many of which have little or > no security. >=20 > In the first sentence: "trust" -> "pass through" >=20 > In the second sentence as written, "many of which" refers to "IP networks= " - > I suspect that was not intended, e.g., "tens-of-billions of devices that = may > have little or no security are being connected to IP networks" may be clo= ser > to what was intended. >=20 > Setting a trust boundary reflective of business objectives and > policy, such that traffic from authorized users and/or > applications and/or endpoints will be accepted by the network; > otherwise packet markings will be "bleached" (i.e. remarked to > DSCP DF and/or UP 0). >=20 > I have some idea of what a "trust boundary" is, but suspect that "traffic > conditioning policy" may be clearer and closer to what was intended. >=20 > Section 8.2: >=20 > Every paragraph in this section is bidirectional in scope, applying to bo= th > wired->wireless and wireless-> wired traffic, except for this paragraph: >=20 > If such marking/mapping were not controlled, then, for example, a > malicious user could cause WLAN DoS by flooding traffic marked CS7 > DSCP downstream. This codepoint would map by default to UP 7 and > would be assigned to the Voice Access Category (AC_VO). Such a flood > could cause Denial-of-Service to not only wireless voice > applications, but also to all other traffic classes. >=20 > I suggest making this paragraph bidirectional by providing the example in > both directions and then making it clear that the following paragraph: >=20 > Therefore, to mitigate such an attack, it is RECOMMENDED that all > packets marked to Diffserv Codepoints not in use over the wireless > network be mapped to UP 0. >=20 > applies to both access points and wireless device operating systems. >=20 >=20 > -- Editorial >=20 > Section 1.1: >=20 > Note: [RFC4594] is intended to be viewed as a set of "project plans" > for building all the (diffserv) furniture that one might want. Thus, > it describes different types of traffic expected in IP networks and > provides guidance as to what DSCP marking(s) should be associated > with each traffic type. As such, this document draws heavily on > [RFC4594], [RFC5127], and [RFC8100]. >=20 > The first sentence seems a bit too informal, suggest: >=20 > OLD > Note: [RFC4594] is intended to be viewed as a set of "project plans" > for building all the (diffserv) furniture that one might want. > NEW > Note: [RFC4594] is intended to be viewed as a framework and guidelines > for supporting Diffserv in any network, including wireless networks. >=20 > Section 2.1: >=20 > It is important to recognize that the wired-to-wireless edge may or > may not equate to the edge of the Diffserv domain. >=20 > equate to the edge of the Diffserv domain -> function as an edge of a > Diffserv domain or a domain boundary. >=20 > Section 8: >=20 > Initial paragraph seems overly defensive, suggest: >=20 > OLD > The recommendations put forward in this document do not present any > additional security concerns that do not already exist in wired and > wireless devices. In fact, several of the recommendations made in > this document serve to mitigate and protect wired and wireless > networks from potential abuse arising from existing vulnerabilities. > NEW > The recommendations in this document concern existing wired and > wireless > network functionality, and for that reason do not add significant secu= rity > concerns. Some of the recommendations help protect wired and wireles= s > networks from potential abuse, e.g., as discussed further in this sect= ion. >=20 > Section 8.2: >=20 > It should be strongly noted that in the wireless deployment model >=20 > I suggest deleting "It should be strongly noted that" >=20 > Thanks, --David >=20 >=20 > > -----Original Message----- > > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of G Fairhurst > > Sent: Thursday, July 6, 2017 3:11 AM > > To: tsvwg WG > > Subject: [tsvwg] TSVWG Working Group Last Call (WGLC) on > > draft-ietf-tsvwg- > > ieee-802-11-01 to conclude 10th Jul 2017 > > > > This email announces a second TSVWG Working Group Last Call (WGLC) on: > > > > DiffServ to IEEE 802.11 Mapping > > draft-ietf-tsvwg-ieee-802-11-01 > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11-01 > > > > This WGLC will last for about 2 weeks weeks. The purpose of this call > > is to provide further feedback (if required) on changes made since the > > first WGLC concluded. > > > > Comments should be sent to thetsvwg@ietf.org > > list, although purely editorial comments may be > > sent directly to the authors. Please cc: the WG chairs > > attsvwg-chairs@ietf.org if you would > > like the chairs to track such editorial comments as part of the WGLC > > process. > > > > No IPR disclosures have been submitted directly on > > draft-ietf-tsvwg-ieee-802-11-01 > > > > Thanks, > > Gorry > > (TSVWG Co-Chair) From nobody Fri Jul 28 00:20:25 2017 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 151B8124BE8 for ; Fri, 28 Jul 2017 00:20:23 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 ckLjUmyP-UdC for ; Fri, 28 Jul 2017 00:20:20 -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 A9F7112708C for ; Fri, 28 Jul 2017 00:20:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.40,424,1496095200"; d="scan'208,217";a="285229949" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO [192.168.1.139]) ([82.236.155.50]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jul 2017 09:20:16 +0200 From: Vincent Roca Message-Id: <6855BDC5-BEE0-47F4-A102-349A9029137C@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_C60ACAA1-1049-434E-8157-0C607E69F84B" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 28 Jul 2017 09:20:15 +0200 In-Reply-To: <2C00E20B-E85C-4F6F-BA28-33FA703BAB44@mit.edu> Cc: "Black, David" , "tsvwg@ietf.org" To: Xiaomeng Shi References: <150029847620.14798.5607143949067995735@ietfa.amsl.com> <3A1480C1-C475-46EF-B776-0E9714FD4DB2@mit.edu> <2C00E20B-E85C-4F6F-BA28-33FA703BAB44@mit.edu> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rlc-fec-scheme-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 07:20:23 -0000 --Apple-Mail=_C60ACAA1-1049-434E-8157-0C607E69F84B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Shirley, Thanks a lot for your interest and support. Yes, we=E2=80=99ll need = reviewers and you are more than welcome. This I-D on sliding window FEC codes focusses on a specific = application/use-case, but we can also regard it as the first concrete initiative for using such codes in IETF = standards.=20 The NWCRG remains the main place where discuss research topics related = to sliding window codes, and several directions / design teams have already been identified during = last week IETF=E2=80=9999 meeting. Do not hesitate to have a look at the NWCRG meeting minutes: https://www.ietf.org/proceedings/99/minutes/minutes-99-nwcrg-00.txt = Best regards, Vincent =20 > Le 27 juil. 2017 =C3=A0 19:08, Xiaomeng Shi a =C3=A9crit = : >=20 > Dear David, >=20 > Thank you for the note! I will relay the message to my colleagues as = well. >=20 > Best, > Shirley >=20 >=20 >> On Jul 23, 2017, at 8:39 PM, Black, David > wrote: >>=20 >> Shirley, <> >> =20 >> Thank you for your interest, and the timing is fine. The background = information is useful =E2=80=93 beyond that, if you and/or your = colleagues are interested in reviewing this draft (and the supporting = framework extension draft, =20 >> draft-ietf-tsvwg-fecframe-ext-00.txt), comments would be welcome at = any time. In particular, there=E2=80=99s no need to wait for Working = Group Last Call to send comments to the list. >> =20 >> Thanks, --David >> =20 >> From: tsvwg [mailto:tsvwg-bounces@ietf.org = ] On Behalf Of Xiaomeng Shi >> Sent: Wednesday, July 19, 2017 2:54 PM >> To: tsvwg@ietf.org >> Subject: Re: [tsvwg] I-D Action: = draft-ietf-tsvwg-rlc-fec-scheme-00.txt >> =20 >> Dear Vincent and all, >> =20 >> Thank you very much for the great effort. This is my first post to = the group, and I hope my message has come at an appropriate time during = the pipeline. I work with Code On Technologies in Cambridge, MA, where = our focus is in the application of random linear network codes in = different layers of the network stack to achieve performance = improvements when possible. =20 >>=20 >>=20 >> We are delighted to see that the sliding window approach has become a = working group item and we are in full support of the initiative. To = this extent, we thought it might be of interest to the group to see some = past research work in this area, either from us, or that we are aware = of. Below is a quick list, and we look forward to future discussions = within tsvwg.=20 >> =20 >> 1) Network Coding Overview, IETF 86, 2013, Code On Technologies, = https://www.ietf.org/proceedings/86/slides/slides-86-nwcrg-5.pdf = . >> 2) T. Ho, et al., "A random linear network coding approach to = multicast," IEEE Transactions on Information Theory, vol. 52, no. 10, = pp. 4413-4430, 2006. >> 3) JK, Sundararajan et al., "Network coding meets TCP," INFOCOM 2009, = IEEE. IEEE, 2009. >> 4) M. Kim et al., "Modeling network coded TCP throughput: A simple = model and its validation," Proceedings of the 5th International ICST = Conference on Performance Evaluation Methodologies and Tools. ICST = (Institute for Computer Sciences, Social-Informatics and = Telecommunications Engineering), 2011. >> 5) S. Wunderlich et al., We don't need no generation-a practical = approach to sliding window RLNC. In Wireless Days, 2017 (pp. 218-223). = IEEE. >> =20 >> Best regards, >> Shirley Shi >> =20 >>=20 >>=20 >> =20 >> On Jul 17, 2017, at 9:34 AM, 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 of the = IETF. >>=20 >> Title : Sliding Window Random Linear Code (RLC) = Forward Erasure Correction (FEC) Scheme for FECFRAME >> Author : Vincent Roca >> Filename : draft-ietf-tsvwg-rlc-fec-scheme-00.txt >> Pages : 23 >> Date : 2017-07-17 >>=20 >> Abstract: >> This document describes a fully-specified FEC scheme for the = Sliding >> Window Random Linear Codes (RLC) over GF(2^^m), where m equals 1 >> (binary case), 4 or 8, that can be used to protect arbitrary media >> streams along the lines defined by FECFRAME extended to sliding >> window 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 = erasure >> recovery capabilities. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/ = >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-tsvwg-rlc-fec-scheme-00 = >> = https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rlc-fec-scheme-00 = = >>=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/ = --Apple-Mail=_C60ACAA1-1049-434E-8157-0C607E69F84B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear Shirley,

Thanks a lot for your interest and support. Yes, = we=E2=80=99ll need reviewers and you are more than welcome.
This I-D on sliding window FEC codes focusses on a specific = application/use-case, but we can also regard
it as = the first concrete initiative for using such codes in IETF = standards. 

The = NWCRG remains the main place where discuss research topics related to = sliding window codes, and
several directions / = design teams have already been identified during last week IETF=E2=80=9999= meeting. Do not
hesitate to have a look at the = NWCRG meeting minutes:
https://www.ietf.org/proceedings/99/minutes/minutes-99-nwcrg-00= .txt

Best = regards,

  = Vincent
 

Le = 27 juil. 2017 =C3=A0 19:08, Xiaomeng Shi <xshi@mit.edu> a =C3=A9crit = :

Dear David,

Thank you for the note!  I will relay the message = to my colleagues as well.

Best,
Shirley


On Jul 23, 2017, at 8:39 PM, Black, David <David.Black@dell.com> wrote:

Shirley,
 
Thank you for your interest, and the = timing is fine.  The background information is useful =E2=80=93 = beyond that, if you and/or your colleagues are interested in reviewing this draft (and the supporting framework extension draft, =    
draft-ietf-tsvwg-fecframe-ext-00.txt), = comments would be welcome at any time.  In particular, there=E2=80=99= s no need to wait for Working Group Last Call to send comments to the list.
 
Thanks, --David
 
From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Xiaomeng = Shi
Sent: Wednesday, July 19, 2017 = 2:54 PM
To: tsvwg@ietf.org
Subject: Re: [tsvwg] I-D Action: = draft-ietf-tsvwg-rlc-fec-scheme-00.txt
 
Dear Vincent and all,
 
Thank you very much for the great effort.  This is my first post to = the group, and I hope my message has come at an appropriate time during = the pipeline.  I work with Code On Technologies in Cambridge, MA, = where our focus is in the application of random linear network codes in different layers of the network stack to achieve = performance improvements when possible.  
=


We are delighted to see that the sliding window approach has become a = working group item and we are in full support of the initiative. =  To this extent, we thought it might be of interest to the group to = see some past research work in this area, either from us, or that we are aware of.  Below is a quick list, and we look = forward to future discussions within tsvwg. 
 
1) Network Coding Overview, IETF 86, 2013, Code On = Technologies, https://www.ietf.org/proceedings/86/slides/slides-86-nwcrg-5.pd= f.
2) T. Ho, et al., "A random linear network coding approach to = multicast," IEEE Transactions on Information Theory, vol. 52, no. 10, = pp. 4413-4430, 2006.
3) JK, Sundararajan et al., "Network coding meets = TCP," INFOCOM 2009, IEEE. IEEE, 2009.
4) M. Kim et al., "Modeling network coded TCP throughput: A simple model = and its validation," Proceedings of the 5th International ICST = Conference on Performance Evaluation Methodologies and Tools. ICST = (Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering), 2011.
5) S. Wunderlich et al., We don't need no generation-a practical = approach to sliding window RLNC. In Wireless Days, 2017 (pp. = 218-223). IEEE.
 
Best regards,
Shirley Shi
 


 
On Jul 17, 2017, at 9:34 AM, internet-drafts@ietf.org wrote:
 


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

       Title =           : Sliding = Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Scheme = for FECFRAME
       Author =          : Vincent Roca
Filename        : = draft-ietf-tsvwg-rlc-fec-scheme-00.txt
Pages           : = 23
Date            : = 2017-07-17

Abstract:
  This document describes a fully-specified FEC scheme for the = Sliding
  Window Random Linear Codes (RLC) over GF(2^^m), where m = equals 1
  (binary case), 4 or 8, that can be used to protect arbitrary = media
  streams along the lines defined by FECFRAME extended to = sliding
  window 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 erasure
  recovery capabilities.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-schem= e/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tsvwg-rlc-fec-scheme-00<= /a>
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rlc-fec-= scheme-00


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=_C60ACAA1-1049-434E-8157-0C607E69F84B-- From nobody Mon Jul 31 00:45:55 2017 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 9694E131EB3 for ; Mon, 31 Jul 2017 00:45:53 -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, RP_MATCHES_RCVD=-0.001, 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 gEkQXHF9uQXR for ; Mon, 31 Jul 2017 00:45:50 -0700 (PDT) Received: from visuela.unizar.es (visuela.unizar.es [155.210.1.100]) (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 50E19131EAC for ; Mon, 31 Jul 2017 00:45:50 -0700 (PDT) Received: from gtc1pc12.cps.unizar.es ([155.210.158.17] helo=usuarioPC) by visuela.unizar.es with esmtpa (Exim 4.84_2) (envelope-from ) id 1dc5Ob-0005hI-1N for tsvwg@ietf.org; Mon, 31 Jul 2017 09:45:45 +0200 From: "Jose Saldana" To: References: <150148701942.30449.9239965900791759024.idtracker@ietfa.amsl.com> In-Reply-To: <150148701942.30449.9239965900791759024.idtracker@ietfa.amsl.com> Date: Mon, 31 Jul 2017 09:45:40 +0200 Message-ID: <004301d309d1$053dafe0$0fb90fa0$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHClVHmLYa4DuE9yzAmO+5fdX3vaaKOd0Tw Content-Language: es Archived-At: Subject: [tsvwg] RV: New Version Notification for draft-saldana-tsvwg-simplemux-07.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 07:45:54 -0000 Best regards, Jose > -----Mensaje original----- > De: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Enviado el: lunes, 31 de julio de 2017 9:44 > Para: Jose Saldana > Asunto: New Version Notification for = draft-saldana-tsvwg-simplemux-07.txt >=20 >=20 > A new version of I-D, draft-saldana-tsvwg-simplemux-07.txt > has been successfully submitted by Jose Saldana and posted to the IETF > repository. >=20 > Name: draft-saldana-tsvwg-simplemux > Revision: 07 > Title: Simplemux. A generic multiplexing protocol > Document date: 2017-07-31 > Group: Individual Submission > Pages: 14 > URL: = https://www.ietf.org/internet-drafts/draft-saldana-tsvwg-simplemux- > 07.txt > Status: = https://datatracker.ietf.org/doc/draft-saldana-tsvwg-simplemux/ > Htmlized: = https://tools.ietf.org/html/draft-saldana-tsvwg-simplemux-07 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-saldana-tsvwg-simplemux- > 07 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-saldana-tsvwg-simplemux-07 >=20 > Abstract: > The high amount of small packets present in nowaday's networks > results in a low efficiency, as the size of the headers and the > payload of these packets can be in the same order of magnitude. In > some situations, multiplexing a number of small packets into a = bigger > one is desirable in order to improve the efficiency. For example, = a > number of small packets can be sent together between a pair of > machines if they share a common network path. Thus, the traffic > profile can be shifted from small to larger packets, reducing the > network overhead and the number of packets per second to be managed > by intermediate routers. >=20 > This document describes Simplemux, a protocol able to encapsulate a > number of packets belonging to different protocols into a single > packet. Small headers (separators) are added at the beginning of > each multiplexed packet, including some flags, the packet length = and > a "Protocol" field. This allows the inclusion of a number of = packets > belonging to different protocols (the "multiplexed packets") on a > packet of another protocol (the "tunneling protocol"). >=20 > In order to reduce the overhead, the size of the multiplexing = headers > is kept very low (it may be a single byte when multiplexing small > packets). >=20 >=20 >=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 > The IETF Secretariat From nobody Mon Jul 31 06:35:26 2017 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 6ACD01322D4 for ; Mon, 31 Jul 2017 06:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=telekom.de 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 Gm-DKYqoa2vE for ; Mon, 31 Jul 2017 06:34:59 -0700 (PDT) Received: from mailout14.telekom.de (MAILOUT14.telekom.de [80.149.113.182]) (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 E8AE11322CF for ; Mon, 31 Jul 2017 06:34:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1501508099; x=1533044099; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=AHJFlW12ejYtasWj5uTemV+eUJ4M3HqpTMtU2ttjnEc=; b=IhnhR4FNABvQdushZk3AFbgteLycVkR74kRFMgV+MKd7sbwp5QQCOMh2 ELu9oZXLewRr5R1sROfEjLCj8SVRqlEFHasIip2wNh7uCnuQuI1UGKEfw axPez62mLHSuZK6dN3LD40FCd1fQ4vvrVJ/d/XeBJpYGlhrG125gWkggu S8GS6evLN8N09P38Rl+LdlwjhgUUdv5r56nOTYNhHALPMVG4mEKcCz6LV vEvNhwYPDmMsrAN6S4SryIToMl/SbkYvwJANW1H5zO4mZSbdetqqZZE2V NcdB3+//4gRstAad1wWxteG0AzAsVk8lccGqyw9V7qOFlfl6lYmJPFpY/ g==; Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT11.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jul 2017 15:34:55 +0200 X-IronPort-AV: E=Sophos;i="5.40,442,1496095200"; d="scan'208";a="51431775" Received: from he105658.emea1.cds.t-internal.com ([10.169.118.88]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 31 Jul 2017 15:34:55 +0200 Received: from HE105654.EMEA1.cds.t-internal.com (10.169.118.86) by HE105658.emea1.cds.t-internal.com (10.169.118.88) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 31 Jul 2017 15:34:54 +0200 Received: from HE105654.EMEA1.cds.t-internal.com ([fe80::44ef:d9e7:d2ca:97f6]) by HE105654.emea1.cds.t-internal.com ([fe80::44ef:d9e7:d2ca:97f6%26]) with mapi id 15.00.1263.000; Mon, 31 Jul 2017 15:34:54 +0200 From: To: , CC: , , Thread-Topic: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? Thread-Index: AQHS9w2o4prCs8a2Uk2hjK9vt7Sn6aJIEb4AgAAFrYCAAJ4pgIACg0cAgACbsYCAAAkhgIAADh6AgAAYQgCAAJFhAIAA00EAgAjBVYCAAK90gIAXOLgQ Date: Mon, 31 Jul 2017 13:34:54 +0000 Message-ID: <505f03a57bd4481b832bc22340c37316@HE105654.emea1.cds.t-internal.com> References: <595F4D19.9030502@erg.abdn.ac.uk> <011e5fb5-6c83-bb38-e2cb-7fced2cb774a@kit.edu> <595F6F4F.20005@erg.abdn.ac.uk> <74717821-30ae-203b-197b-2455cbf9d4a3@gmail.com> <66425AFB-A929-4A91-90F8-432F4FAE0520@jisc.ac.uk> <59633402.9020907@erg.abdn.ac.uk> <50f4b157-425e-a2cc-a924-5dd02345adef@gmail.com> In-Reply-To: <50f4b157-425e-a2cc-a924-5dd02345adef@gmail.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.162.83] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 13:35:25 -0000 QnJpYW4sIERhdmlkLCANCg0KdG8gY29tcGxldGUgUkZDNDU5NCBkaXNjdXNzaW9uLCBpdCBhbHNv IHNheXM6DQoNCiJJbiBuZXR3b3JrIHNlZ21lbnRzIHRoYXQgdXNlIElQIHByZWNlZGVuY2UgbWFy a2luZywgb25seSBvbmUgb2YNCnRoZSB0d28gc2VydmljZSBjbGFzc2VzIGNhbiBiZSBzdXBwb3J0 ZWQsIEhpZ2gtVGhyb3VnaHB1dCBEYXRhIG9yDQpMb3ctUHJpb3JpdHkgRGF0YS4gIFdlIFJFQ09N TUVORCB0aGF0IHRoZSBEU0NQIHZhbHVlKHMpIG9mIHRoZQ0KdW5zdXBwb3J0ZWQgc2VydmljZSBj bGFzcyBiZSBjaGFuZ2VkIHRvIDAwMHh4MSBvbiBpbmdyZXNzIGFuZA0KY2hhbmdlZCBiYWNrIHRv IG9yaWdpbmFsIHZhbHVlKHMpIG9uIGVncmVzcyBvZiB0aGUgbmV0d29yayBzZWdtZW50DQp0aGF0 IHVzZXMgcHJlY2VkZW5jZSBtYXJraW5nLiAgRm9yIGV4YW1wbGUsIGlmIExvdy1Qcmlvcml0eSBE YXRhDQppcyBtYXBwZWQgdG8gU3RhbmRhcmQgc2VydmljZSBjbGFzcywgdGhlbiAwMDAwMDEgRFND UCBtYXJraW5nIE1BWQ0KYmUgdXNlZCB0byBkaXN0aW5ndWlzaCBpdCBmcm9tIFN0YW5kYXJkIG1h cmtlZCBwYWNrZXRzIG9uIGVncmVzcy4iDQoNCkRTQ1AgMDAwMDAxIG1pZ2h0IGJlIGFuIG9wdGlv bi4gTm8gb3RoZXIgSUVURiByZWNvbW1lbmRlZCBEU0NQIGlzIHJlLW1hcmtlZCB0byB0aGlzIG9u ZS4gSXQgaXMgdG8gc29tZSBleHRlbnQgUkZDNDU5NCBjb21wYXRpYmxlIGFuZCBSRkM4MTAwIGNv dWxkIGNvcGUgd2l0aCBpdCBpZiBkZWZhdWx0IHRyYW5zcG9ydCBpcyBhcHBsaWVkLiANCg0KSSBj YW4ndCBvZmZlciB5b3UgbWVhc3VyZW1lbnQgZGF0YS4NCg0KUmVnYXJkcywNCg0KUnVlZGlnZXIN Cg0KDQotLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQpWb246IHRzdndnIFttYWls dG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10gSW0gQXVmdHJhZyB2b24gQnJpYW4gRSBDYXJwZW50 ZXINCkdlc2VuZGV0OiBTb25udGFnLCAxNi4gSnVsaSAyMDE3IDIyOjQ2DQpBbjogQmxhY2ssIERh dmlkIDxEYXZpZC5CbGFja0BkZWxsLmNvbT47IGdvcnJ5QGVyZy5hYmRuLmFjLnVrDQpDYzogUm9s YW5kIEJsZXNzIDxyb2xhbmQuYmxlc3NAa2l0LmVkdT47IHRzdndnQGlldGYub3JnDQpCZXRyZWZm OiBSZTogW3RzdndnXSBDT01NRU5UIFBMRUFTRTogV2hpY2ggRFNDUCB2YWx1ZSBzaG91bGQgd2Ug dXNlIGZvciBMRSBQSEI/DQoNCk9uIDE2LzA3LzIwMTcgMjI6MTgsIEJsYWNrLCBEYXZpZCB3cm90 ZToNCj4gVHdvIGNvbW1lbnRzIHdpdGggV0cgY2hhaXIgaGF0IE9GRjoNCj4gDQo+IFsxXSBBcyBh biBhdXRob3Igb2YgUkZDIDgxMDAgLQ0KPiANCj4+ICJXZSBhZ3JlZSB0byBmb2xsb3cgUkZDODEw MCIgbWlnaHQgYmUgYSBtaW5pbWFsIFNMQS4gQnV0IGFic2VudCB0aGF0LCANCj4+IHRoZXJlIGlz IHZlcnkgbGl0dGxlIHdlIGNhbiBzYXkuIEknbSBub3QgYXdhcmUgb2YgYW55IG1lYXN1cmVtZW50 IA0KPj4gZGF0YSB0aGF0IHdvdWxkIGhlbHAsIHVuZm9ydHVuYXRlbHkuDQo+IA0KPiBBZGRpbmcg YW4gTEUgdHJhZmZpYyBjbGFzcyB0byBSRkMgODEwMCBjYW1lIHVwIGR1cmluZyBkaXNjdXNzaW9u IG9mIFJGQyA4MTAwIChpdCB3YXMgcmVmZXJyZWQgdG8gYXMgInNjYXZlbmdlciIgaW4gdGhhdCBk aXNjdXNzaW9uKSwgYW5kIHdhcyBkZWZlcnJlZCwgZS5nLiwgZHVlIHRvIHRoaXMgRFNDUCBjb2Rl cG9pbnQgY29uY2Vybi4gICBJbiBwcmluY2lwbGUsIExFIGNvdWxkIGJlIGFkZGVkIHRvIFJGQyA4 MTAwLCBidXQgSSBjYXV0aW9uIHRoYXQgdGhlIHVuZGVybHlpbmcgTVBMUyBUQyAoVHJhZmZpYyBD bGFzcyAtIHNlZSBSRkMgNTQ2MikgY29kZXBvaW50IHNwYWNlIGlzIGEgKnZlcnkqIGxpbWl0ZWQg cmVzb3VyY2UuICBUQyBpcyBhIDMtYml0IGZpZWxkLCBhbmQgc28gYWRkaW5nIGFub3RoZXIgdHJh ZmZpYyBjbGFzcyB0byBSRkMgODEwMCB3b3VsZCByZWNvbW1lbmQgdXNlIG9mIHRoZSA1dGggdmFs dWUgb24gYXQgbGVhc3QgaW50ZXJjb25uZWN0cyAtIGRvaW5nIHRoaXMgcmVxdWlyZXMgY2FyZWZ1 bCBjb25zaWRlcmF0aW9uLCBpbmNsdWRpbmcgYnkgbmV0d29yayBvcGVyYXRvcnMuDQoNClVuZGVy c3Rvb2QuIFNvIHRoZSBjaG9pY2UgdGhlcmUgZm9yIExFIHdpbGwgYmUgYmV0d2VlbiByZW1hcmtp bmcgYXMgQkUgb3IgZHJvcHBpbmcsIGFzIGRpc2N1c3NlZCBpbiB0aGUgcGFyYWxsZWwgdGhyZWFk Lg0KDQo+IFsyXSBBcyAgYW4gaW5kaXZpZHVhbDogQWxzbywgd2hpbGUgUkZDIDM2NjIgc3VnZ2Vz dGVkIHBvc3NpYmxlIHVzZSBvZiBDUzEsIGluIHByYWN0aWNlLCB0aGF0IHVzZSBvZiBDUzEgZm9y IExFIChMb3cgUHJpb3JpdHkgRGF0YSBUcmFmZmljKSB3YXMgY29kaWZpZWQgYnkgUkZDIDQ1OTQg KGUuZy4sIHNlZSBTZWN0aW9uIDQuMTApLCBldmVuIHRob3VnaCBSRkMgNDU5NCBpcyBhbiBJbmZv cm1hdGlvbmFsIFJGQyAoUkZDIDQ1OTQgaXMgd2lkZWx5IHVzZWQpLg0KDQpJbmRlZWQuIEhlbmNl IHRoZSAiVXBkYXRlczogNDU5NCAoaWYgYXBwcm92ZWQpIi4NCg0KICAgIEJyaWFuDQoNCj4gDQo+ IFRoYW5rcywgLS1EYXZpZA0KPiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBG cm9tOiB0c3Z3ZyBbbWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBC cmlhbiBFIA0KPj4gQ2FycGVudGVyDQo+PiBTZW50OiBNb25kYXksIEp1bHkgMTAsIDIwMTcgNDoz NiBQTQ0KPj4gVG86IGdvcnJ5QGVyZy5hYmRuLmFjLnVrDQo+PiBDYzogUm9sYW5kIEJsZXNzIDxy b2xhbmQuYmxlc3NAa2l0LmVkdT47IHRzdndnQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW3Rz dndnXSBDT01NRU5UIFBMRUFTRTogV2hpY2ggRFNDUCB2YWx1ZSBzaG91bGQgd2UgdXNlIA0KPj4g Zm9yIExFIFBIQj8NCj4+DQo+Pj4gbWFrcmluZyBpbnRlcmRvbWFpbiBkaWZmc2VydiBzdXBwb3J0 IHVucHJlZGljdGFibGUuDQo+Pg0KPj4gVGhhdCBpcyB0aGUgd2hvbGUgcG9pbnQsIHJlYWxseS4g SW50ZXJkb21haW4gZGlmZnNlcnYgc3VwcG9ydA0KPj4gKmlzKiB1bnByZWRpY3RhYmxlLCBtb3Jl IG9yIGxlc3MgYnkgZGVmaW5pdGlvbiwgdW5sZXNzIHRoZXJlIGlzIGFuIA0KPj4gU0xBIGluIHBs YWNlIGJldHdlZW4gdGhlIGRvbWFpbnMgdGhhdCBkZWZpbmVzIHdoYXQgaGFwcGVucyB0byBwYWNr ZXRzIA0KPj4gd2l0aCBzcGVjaWZpYyBtYXJraW5ncyBhcyB0aGV5IGNyb3NzIHRoZSBib3JkZXIu DQo+Pg0KPj4gIldlIGFncmVlIHRvIGZvbGxvdyBSRkM4MTAwIiBtaWdodCBiZSBhIG1pbmltYWwg U0xBLiBCdXQgYWJzZW50IHRoYXQsIA0KPj4gdGhlcmUgaXMgdmVyeSBsaXR0bGUgd2UgY2FuIHNh eS4gSSdtIG5vdCBhd2FyZSBvZiBhbnkgbWVhc3VyZW1lbnQgDQo+PiBkYXRhIHRoYXQgd291bGQg aGVscCwgdW5mb3J0dW5hdGVseS4NCj4+DQo+PiBSZWdhcmRzDQo+PiAgICBCcmlhbg0KPj4NCj4+ IE9uIDEwLzA3LzIwMTcgMjA6MDAsIEdvcnJ5IEZhaXJodXJzdCB3cm90ZToNCj4+PiBXaGVuIEkg YXNrZWQgdGhlIHF1ZXN0aW9ucyBiZWxvdywgSSBkaWRuJ3QgcmVhbGx5IGhhdmUgaW4gbWluZCBh IA0KPj4+IGJlYXV0eSBjb250ZXN0LCBvciB0byBpZGVudGlmeSBzcXVhdGluZyBvbiBJQU5BLWFs bG9jYXRlZCBEU0NQIA0KPj4+IHZhbHVlcyBieSBvdGhlcnMuIE15IGNvbmNlcm4gd2FzIG1vcmUg YWJvdXQgd2lkZWx5IGRlcGxveWluZyBhIGNsYXNzIA0KPj4+IHRoYXQgaGFkIGxvd2VyIGVmZm9y dCwgYW5kIHRoZSBpbXBsaWNhdGlvbnMgb24gYmVpbmcgYWJsZSB0byB3b3JrIA0KPj4+IGludGVy ZG9tYWluIHdpdGggdHJhZmZpYyBub3QgaW50ZW5kZWQgbm90IHRvIGJlICJMRSIuDQo+Pj4NCj4+ PiBBdCB0aGUgbW9tZW50LCBhbnkgcmVtYXJraW5nIGlzIGxpa2VseSB0byByZWR1Y2UgdGhlIGNs YXNzIGJ5IHdoaWNoIA0KPj4+IHRyYWZmaWMgaXMgaWRlbnRpZmllZCwgZS5nLiwgYSBuZXR3b3Jr IHJvdXRlciBvbiBwYXRoIGJsZWFjaGluZyB0aGUgDQo+Pj4gRFNDUCB0byB6ZXJvIHdvdWxkIHJl c3VsdCBpbiB0aGUgcGFja2V0IHJlY2VpdmluZyB0aGUgZGVmYXVsdCBQSEIgDQo+Pj4gdHJlYXRt ZW50IGZvciB0aGUgcmVtYWluZGVyIG9mIGl0cyBwYXRoLiBUaGlzIG1heWJlIHdhc24ndCBpbnRl bmRlZCwgDQo+Pj4gYnV0IHRvIG1lIGl0J3MgcXVpdGUgT0suIElmIHR3byBwYWNrZXRzIHdlcmUg bWFya2VkIHdpdGggcmVsYXRpdmUgDQo+Pj4gcHJpb3JpdHkNCj4+PiAoQUYyMSxBRjIyKSBldGMs IGl0IHNlZW1zIGxpa2VseSB0aGF0IGJvdGggd2lsbCBiZSByZW1hcmtlZCB0byB6ZXJvLCANCj4+ PiBvciB0aGF0IHRoZSByZWxhdGl2ZSBwcmlvcml0eSBpcyBwcmVzZXZlcnZlZC4NCj4+Pg0KPj4+ IFdoZW4gd2UgaW50cm9kdWNlIGEgTEUgUEhCLCB0aGVuIGFueSB0cmFmZmljIHRoYXQgZmluYWxs eSByZXN1bHRzIGluIA0KPj4+IHRoZSBuZXcgTEUgY2xhc3Mgd2lsbCByZWNlaXZlIGxlc3MgdGhh biBkZWZhdWx0IHRyZWF0bWVudCAod2UgaG9wZSEpIA0KPj4+IE15IGNvbmNlcm4gaXMgd2hldGhl ciB0aGVyZSBhcmUgd2lkZWx5IGRlcGxveWVkIHBhdGhvbG9naWVzIA0KPj4+IChlc3BlY2lhbGx5 IGluIG9sZCBlcXVpcG1lbnQpIHRoYXQgd291bGQgcmVzdWx0IGluIHNvbWUgY29kZXBvaW50cyAN Cj4+PiBiZWluZyByZW1hcmtlZCB0byB0aGUgZGVmYXVsdCBQSEIsIHdoaWxlIG90aGVyIGNvZGVw b2ludHMgZ2V0IA0KPj4+IHJlbWFya2VkIHRvIGEgTEUgUEhCLiBUaGlzIGNvdWxkIGVhc2lseSAi aW52ZXJ0IiB0aGUgcmVsYXRpdmUgDQo+Pj4gcHJpb3JpdHkgZXhwZWN0ZWQgYnkgYW4gYXBwbGlj YXRpb24sIGluIHdheXMgd2Ugd2FybmVkIGFib3V0IGluIHRoZSANCj4+PiBEQVJUIHdvcmssIG1h a3JpbmcgaW50ZXJkb21haW4gZGlmZnNlcnYgc3VwcG9ydCB1bnByZWRpY3RhYmxlLg0KPj4+DQo+ Pj4gSW4gcHJhY3RpY2UsIEkgaGF2ZSBzZWVuIHRoZXJlIGFyZSBtYW55IHBhdGhvbG9naWVzIHRo YXQgZGVwbG95ZWQgDQo+Pj4gZXF1aXBtZW50IGV4aGliaXRzIC0gSSBzcG9rZSBhYm91dCBzb21l IG9mIHRoaXMgaW4gbWFwcmcgbGFzdCBJRVRGIC0gDQo+Pj4gZS5nLiwgc29tZSBub2RlcyBzdGls bCBpbXBsZW1lbnQgVG9TIHNlbWFudGljIHByb2Nlc3NpbmcuIChUaGlzIGlzDQo+Pj4gZGVwcmVj YXRlZCEpIEhvd2V2ZXIsIHRoYXQncyBub3QgdGhlIHBvaW50LCBpZiB0aGlzIHJlbWFya2luZyBp cyANCj4+PiBzdGlsbCBvdXQgdGhlcmUsIHRoZW4gd2UgY2FuIHJlYW9uYWJseSBleHBlY3Qgc29t ZSBwYWNrZXRzIHRvIGJlIHJlbWFya2VkLg0KPj4+IFRoaXMgc2VlbXMgcGFydGljdWxhcmx5IHVn bHkgd2hlbiB3ZSBpbnRyb2R1Y2UgdXNlIG9mIGEgTEUgY29kZXBvaW50IA0KPj4+IHRoYXQgd2ls bCBhY3R1YWxseSBGcm9tIHdoYXQgSSB0YWxrZWQgYWJvdXQgaW4gbWFwcmcsIEkgaGF2ZSBhIGZl YXIgDQo+Pj4gdGhhdCB0aGlzIGNhc2UgY291bGQgYmUgcmF0aGVyIGNvbW1vbiBpZiB3ZSBkbyBu b3QgdGFrZSBjYXJlIGluIA0KPj4+IHNlbGVjdGlvbiBvZiB0aGUgY29kZXBvaW50LiBJIHRoaW5r IHRoZSBXRyBjYW4gZGF0YSB0byB0YWxrIGFib3V0IHRoaXMuDQo+Pj4NCj4+PiBHb3JyeQ0KPj4+ DQo+Pj4gLS0tLQ0KPj4+DQo+Pj4gVGhlIGRyYWZ0IGN1cnJlbnRseSBzdWdnZXN0cyB1c2luZyB0 aGUgRFNDUCB2YWx1ZSAyLCAnMDAwMDEwJy4NCj4+Pg0KPj4+IFF1ZXN0aW9uIDE6IElzIHRoaXMg Y29kZXBvaW50IGEgZ29vZCBjaG9pY2UgZm9yIHRoZSBUU1ZXRyBncm91cCB0byANCj4+PiBhc3Np Z24gZm9yIHRoZSBMRSBQSEI/DQo+Pj4NCj4+PiAgICBUaGluZ3MgdG8gY29uc2lkZXI6DQo+Pj4g ICAgICAtIElzIHRoZSBjb2RlcG9pbnQgY3VycmVudGx5IGJlaW5nIHVzZWQgZm9yIG90aGVyIChu b24tc3RhbmRhcmQNCj4+PiBhcHBsaWNhdGlvbnMpIHRoYXQgbWF5IGdldCBpbiB0aGUgd2F5IG9m IHRoZSBkZXBsb3ltZW50IG9mIHRoZSBMRSBQSEI/DQo+Pj4gICAgICAtIElzIHRoZXJlIGFudCBl dmlkZW5jZSB0aGF0IHRoaXMgRFNDUCB2YWx1ZSBpcyBsZXNzIGxpa2VseSB0byANCj4+PiBiZSBm b3J3YXJkZWQgdGhhbiBvdGhlciB1bnVzZWQgY29kZXBvaW50cz8NCj4+PiAgICAgIC0gSXMgdGhp cyBjb2RlcG9pbnQgb2JzZXJ2ZWQgaW4gdGhlIHdpbGQgZHVlIHRvIGNvbW1vbiANCj4+PiBEU0NQ LW1hbmdsaW5nIHBhdGhvbG9naWVzIChzdWNoIGFzIFRvUy1ieXRlIGJsZWFjaGluZyk/DQo+Pj4N Cj4+PiBRdWVzdGlvbiAyOiBJcyB0aGVyZSBhbiBhbHRlcm5hdGUgdW5hc3NpZ25lZCBjb2RlcGlu dCB0aGF0IGNvdWxkIGJlIA0KPj4+IGNob3NlbiB0aGF0IHdvdWxkIGdpdmUgYmV0dGVyIG9wcHJv dHVuaXRpZXMgZm9yIGRlcGxveW1lbnQ/DQo+Pj4NCj4+PiAgICAgIFRoaW5ncyB0byBjb25zaWRl cjoNCj4+PiAgICAgIC0gQSBjb2RlcG9pbnQgbGVzcyB0aGFuIDcgYXBwZWFycyB0byBoYXZlIGxl c3MgY2hhbmNlIG9mIA0KPj4+IERTQ1AtbWFuZ2xpbmcgcGF0aG9sb2dpZXMgKHN1Y2ggYXMgVG9T LWJ5dGUgYmxlYWNoaW5nKQ0KPj4+ICAgICAgLSBJQU5BIGN1cnJlbnRseSBhbGxvY2F0ZXMgZnJv bSBwb29sIDEgKHh4eHh4MCksIGJ1dCB3ZSBjb3VsZCANCj4+PiBjb25zaWRlciBhc2tpbmcgdG8g dXNlIHBvb2wgMyAoJ3h4eHgwMScpLCBlLmcuLCAnMDAwMDAxJ29yICcwMDAxMDEnLg0KPj4+DQo+ Pj4gTWVhc3VyZW1lbnQgZXhwZXJpZW5jZSBhbmQgdGhvdWdodHMgb24gdGhpcyB0b3BpYyBhcmUg d2VsY29tZSBvbiB0aGUgDQo+Pj4gbWFpbGluZyBsaXN0IGFoZWFkIG9mIHRoZSBUU1ZXRyBtZWV0 aW5nLiBBdCB0aGlzIG1lZXRpbmcsIEkgd291bGQgDQo+Pj4gbGlrZSB0byBzZWUgc29tZSBkaXNj dXNzaW9uIGNvbmZpcm1pbmcgdGhlIGNob2ljZSBvZiBEU0NQIGNvZGVwb2ludCANCj4+PiBvciBz dWdnZXN0aW5nIGEgbW9yZSBhcHByb3ByaWF0ZSBjb2RlcG9pbnQgZm9yIHRoZSB3b3JraW5nIGdy b3VwIHRvIHJlcXVlc3QuDQo+Pj4NCj4+PiBHb3JyeSBGYWlyaHVyc3QNCj4+PiAoVFNWV0cgQ28t Q2hhaXIpDQo+Pj4NCj4+PiBXaGVuDQo+Pj4NCj4gDQoNCg== From nobody Mon Jul 31 10:00:53 2017 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 014321326B8 for ; Mon, 31 Jul 2017 10:00:52 -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 Kzm95CP8WfSK for ; Mon, 31 Jul 2017 10:00:50 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 626EB1326B0 for ; Mon, 31 Jul 2017 10:00:49 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id v105so151528753wrb.0 for ; Mon, 31 Jul 2017 10:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Yi1Bh1z06DpGJVXIQI+XAHL56EncQYvJzyqTJB46sxk=; b=sC+2mL1rfwrceJivqaE+urwey1Vs1+9JK1LMqHqLrGLsQCPrVPEaET8GcVmYNYjtW4 BGCqobHBeOL8w5MAjew58irvF+MJRAJ6P4mZRC0MdXvgfLHNM5iISPGo28LYr/wFVGwE F1p0yLwmNB4itLpiY/iWtPE2n9vQugu6mnEGnDY/YNUZH58yshs7HQm0y/pM8uYx1zGg spCwGDYyoKkth9cFChqJQWPXKiaG3FQHYpMAGdqb+lv59xaO8v98YKR4E/ZywPxT4kEM fmQlQ8zseh75I+GysWYGkZBe23bti57dB1pglD8ULn4F+diMJbSegUDSL5chDKd1aVl/ ykcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Yi1Bh1z06DpGJVXIQI+XAHL56EncQYvJzyqTJB46sxk=; b=Def/7I2ZDr7A9v3AutVfCU60mNoo3dZ5oi6jW3Ng2U9cHixTdlykvyA9TZAa6+4iYC nZLN8pbTxX25lWw4qyod0Z/ckwOfa/7fRAi/LrSxV/Tk+2cMVNayIA7MVhJcmCsqHzpU 8lOFmb55by9tg3jqL/vYLACnDsDLl0ew9WisG1L5rNSaTU2z5rkGrN6G1aDWBgxbHhG3 w4XOyTRu3cTbkgXdtVqm221R0RjejKq+p4K0OKtq821GOgKUxBbYZp85cK7ZQis9AK1m xmp9fZ+nKFicuBlb3lOJZVZkwWtrzJFAr+/M+OqZcdfPxFQvI2ZoJ3plQ58jD9SsLWXk Komg== X-Gm-Message-State: AIVw113swKq2FeustaObX2LfBlB2oNGSjtqu8VRWlRwHwPbVO8v+W6lM 6QXKZWEzTuAiPg== X-Received: by 10.223.155.145 with SMTP id d17mr14975760wrc.193.1501520447975; Mon, 31 Jul 2017 10:00:47 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1e::1701? ([2600:8802:5600:1e::1701]) by smtp.gmail.com with ESMTPSA id d53sm34448561wrd.81.2017.07.31.10.00.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Jul 2017 10:00:47 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3441.0.1\)) From: Fred Baker In-Reply-To: <505f03a57bd4481b832bc22340c37316@HE105654.emea1.cds.t-internal.com> Date: Mon, 31 Jul 2017 10:00:42 -0700 Cc: Brian E Carpenter , David.Black@dell.com, gorry@erg.abdn.ac.uk, roland.bless@kit.edu, tsvwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <595F4D19.9030502@erg.abdn.ac.uk> <011e5fb5-6c83-bb38-e2cb-7fced2cb774a@kit.edu> <595F6F4F.20005@erg.abdn.ac.uk> <74717821-30ae-203b-197b-2455cbf9d4a3@gmail.com> <66425AFB-A929-4A91-90F8-432F4FAE0520@jisc.ac.uk> <59633402.9020907@erg.abdn.ac.uk> <50f4b157-425e-a2cc-a924-5dd02345adef@gmail.com> <505f03a57bd4481b832bc22340c37316@HE105654.emea1.cds.t-internal.com> To: Ruediger.Geib@telekom.de X-Mailer: Apple Mail (2.3441.0.1) Archived-At: Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 17:00:52 -0000 > On Jul 31, 2017, at 6:34 AM, Ruediger.Geib@telekom.de wrote: >=20 > DSCP 000001 might be an option. No other IETF recommended DSCP is = re-marked to this one. It is to some extent RFC4594 compatible and = RFC8100 could cope with it if default transport is applied.=20 https://tools.ietf.org/html/rfc2474#section-6 indicates that 000001 is = experimental/local use, available for standards allocation only as = necessary. Pool 1 is 32 code points, of which I believe 20 are in use = (figure 3 of RFC 4594). I'd rather not dip into pool 3 unnecessarily. Is = there another option?= From nobody Mon Jul 31 13:25:46 2017 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 A069F132611 for ; Mon, 31 Jul 2017 13:25:44 -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 VzwaKXNzwcIm for ; Mon, 31 Jul 2017 13:25:43 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5639132543 for ; Mon, 31 Jul 2017 13:25:42 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id v189so13194565pgd.2 for ; Mon, 31 Jul 2017 13:25:42 -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=GVC4kTSf17cGPsk0ffpVwaaUteGSxLYuq0EylAp93eE=; b=FCPZJdh088+A1hT+wMfK9CjhnLYr/7PJnqVtf92RtaMgTZIT+NCCpFu/DYYYICWRDU rokEkr7qlfUesdeZWG1vQlLIWUwwHVpOIz04r1qhbyIY1FK23xgzuSR1zOFsHUa86KKo nxpuQG2jhxDvXLv/c0m6zQIimTh6aNtTK88avF9MgtCno0UOeKsVhJ15oUEAwrpq0QxI DyJMHQbjLfM3jU5DrYiymP6H04+lYlG1vUrjaVaCa2mirOZ55ajVzmeAOvKL4MNSbVjX N0+NfxkLPBQOtNyvuBcMiriS1Q6bKjCpJDQZAjNshSi+KeVyDdKKTSdDbDrBujgVxXIH BT7A== 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=GVC4kTSf17cGPsk0ffpVwaaUteGSxLYuq0EylAp93eE=; b=borfP4nbYsgon4Tbt43VXEiBmUImlmqUj4/eZoSRIXA0n4fukIXspt1HU/W7o1VU0e hYyzD05+yKF8tNx4eoeFBuP93WCdum05A7BkZJioE4lOMAo1fSJd6oxVpUCyWuUQZ3Q0 DeiqteF1yJ/H6nLhqqoA6EzpBbHcIH5jQlGZX6Tn2+Sdo42B5UPKYat4BthVEEAAXR/z PHd7h066TviEbiSL3jfRFjmeUfSAWSHyV1b15WOSoMMjrg1zQH9hhmZGYfSr7ipPJZ6R 6jZ11yO5sICZNxywDaaybmAma2JXIw/wnqb+SGTSniQXocWpk1DWMmupRb9iiyQGqHmT 3oww== X-Gm-Message-State: AIVw1114wu1F9dRhIaNjFDaff4rZYROzaullwt4XGClriUbanTe20jYD ZRNkGZ8heydoe5/O X-Received: by 10.99.60.83 with SMTP id i19mr16531835pgn.51.1501532742284; Mon, 31 Jul 2017 13:25:42 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id y12sm49241720pgs.91.2017.07.31.13.25.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Jul 2017 13:25:41 -0700 (PDT) To: Fred Baker , Ruediger.Geib@telekom.de Cc: David.Black@dell.com, gorry@erg.abdn.ac.uk, roland.bless@kit.edu, tsvwg@ietf.org References: <595F4D19.9030502@erg.abdn.ac.uk> <011e5fb5-6c83-bb38-e2cb-7fced2cb774a@kit.edu> <595F6F4F.20005@erg.abdn.ac.uk> <74717821-30ae-203b-197b-2455cbf9d4a3@gmail.com> <66425AFB-A929-4A91-90F8-432F4FAE0520@jisc.ac.uk> <59633402.9020907@erg.abdn.ac.uk> <50f4b157-425e-a2cc-a924-5dd02345adef@gmail.com> <505f03a57bd4481b832bc22340c37316@HE105654.emea1.cds.t-internal.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <7af582df-6c55-a835-8156-50c9f322e4e9@gmail.com> Date: Tue, 1 Aug 2017 08:25:37 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 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] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 20:25:44 -0000 On 01/08/2017 05:00, Fred Baker wrote: > > >> On Jul 31, 2017, at 6:34 AM, Ruediger.Geib@telekom.de wrote: >> >> DSCP 000001 might be an option. No other IETF recommended DSCP is re-marked to this one. It is to some extent RFC4594 compatible and RFC8100 could cope with it if default transport is applied. > > https://tools.ietf.org/html/rfc2474#section-6 indicates that 000001 is experimental/local use, available for standards allocation only as necessary. "We RECOMMEND that the DSCP value(s) of the unsupported service class be changed to 000xx1 on ingress and changed back to original value(s) on egress..." That is a local use within a domain, completely compatible with both pools 2 and 3 which are both defined as for local use. So 000001 is really not suitable for standards track recommendation, until pool 1 is full. > Pool 1 is 32 code points, of which I believe 20 are in use (figure 3 of RFC 4594). I'd rather not dip into pool 3 unnecessarily. Is there another option? 000010 is just fine. Why are we still discussing this? Brian From nobody Mon Jul 31 19:16:06 2017 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 CD9841243F6 for ; Mon, 31 Jul 2017 19:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 7VTXupTqbVVK for ; Mon, 31 Jul 2017 19:16:02 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 8CD9A12420B for ; Mon, 31 Jul 2017 19:16:02 -0700 (PDT) X-AuditID: 1209190e-00fff70000000aae-82-597fe4602993 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 23.18.02734.064EF795; Mon, 31 Jul 2017 22:16:00 -0400 (EDT) Received: from outgoing-exchange-4.mit.edu (OUTGOING-EXCHANGE-4.MIT.EDU [18.7.34.13]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v712G0pq016781; Mon, 31 Jul 2017 22:16:00 -0400 Received: from OC11EXEDGE4.EXCHANGE.MIT.EDU (OC11EXEDGE4.EXCHANGE.MIT.EDU [18.9.3.27]) by outgoing-exchange-4.mit.edu (8.13.8/8.12.4) with ESMTP id v712FxYJ025760; Mon, 31 Jul 2017 22:15:59 -0400 Received: from W92EXHUB12.exchange.mit.edu (18.7.73.21) by OC11EXEDGE4.EXCHANGE.MIT.EDU (18.9.3.27) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 31 Jul 2017 22:15:53 -0400 Received: from OC11EXPO31.exchange.mit.edu ([169.254.1.200]) by W92EXHUB12.exchange.mit.edu ([18.7.73.21]) with mapi id 14.03.0339.000; Mon, 31 Jul 2017 22:15:58 -0400 From: Xiaomeng Shi To: Vincent Roca CC: Xiaomeng Shi , "Black, David" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-rlc-fec-scheme-00.txt Thread-Index: AQHS/wFybhjnAphdEkyibIThkIC+u6JbxdCAgAap9ACABcsSgIAA7h+AgAX0ToA= Date: Tue, 1 Aug 2017 02:15:58 +0000 Message-ID: References: <150029847620.14798.5607143949067995735@ietfa.amsl.com> <3A1480C1-C475-46EF-B776-0E9714FD4DB2@mit.edu> <2C00E20B-E85C-4F6F-BA28-33FA703BAB44@mit.edu> <6855BDC5-BEE0-47F4-A102-349A9029137C@inria.fr> In-Reply-To: <6855BDC5-BEE0-47F4-A102-349A9029137C@inria.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.20.171.44] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphk+LIzCtJLcpLzFFi42IRYrdT1014Uh9pcOiTtcXHWYtZLI69uctm 0bOqn8WB2WPSzBnMHkuW/GTymPTiEEsAcxSXTUpqTmZZapG+XQJXRveS3UwFB6wrPr1ew9bA +Meyi5GTQ0LAROLA1lnMXYxcHEICi5kk3i96zALhHGCUOHnrBCuEc5xR4sO9K+wQznZGifbX m6HKVjNKHJn7kw1kGJuAosStrVcZQWwRAQ2Juw9fM4PYzAJFEmf/vAUaxcEhLOAucaA5GaLE Q+LXyQusELafRP/xKywgNouAikRD22ewVl4BK4lpd3sZIXbNZpLoPNsD1sApYCPReK8TrIhR QEzi+6k1TBC7xCVuPZnPBPGcoMSi2XuYIWwxiX+7HrKB3CABdOe0bWkgJrOApsT6XfoQnfYS Ox6+gZqiKDGl+yE7xAmCEidnPmGZwCg5C8mCWQjds5B0z0LSPQtJ9wJG1lWMsim5Vbq5iZk5 xanJusXJiXl5qUW6xnq5mSV6qSmlmxhBUcwpybeDcVKD9yFGAQ5GJR7eDtP6SCHWxLLiytxD jJIcTEqivIo9QCG+pPyUyozE4oz4otKc1OJDjBIczEoivNKPgHK8KYmVValF+TApaQ4WJXFe cY3GCCGB9MSS1OzU1ILUIpisDAeHkgTvf5BGwaLU9NSKtMycEoQ0EwcnyHAeoOHfHoIMLy5I zC3OTIfIn2I05tjy+8R3Jo6m7x+/Mwmx5OXnpUqJ82qCjBMAKc0ozYObBk7EnMzSrxjFgZ4T 5k14DFTFA0zicPNeAa1iAlolWVoLsqokESEl1cBYmqxdrbKEb+P3cM/6WuejV9J9/H2lLZL0 fDa+MhL5NtvR4YnukpD7Nj8uCzNEXHf6d4JD851U6i1dUa8UrvcrLPX3aL56fujH4hcBt69I LxBTfXZQ/ZHtvynJya4q8x0PV3Z+lL3Nyv6q6UqyvIs5v0bKpjJuh9Zsjo5u1uzDH28W78wS SVViKc5INNRiLipOBAAqGTZNnwMAAA== Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rlc-fec-scheme-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 02:16:05 -0000 RGVhciBWaW5jZW50LA0KDQpUaGFuayB5b3UgZm9yIHRoZSBwb2ludGVyISAgQWdhaW4sIEkgd2ls bCByZWxheSB0aGUgaW5mb3JtYXRpb24gdG8gbXkgY29sbGVhZ3VlcyBhcyB3ZWxsLCBhbmQgY29t ZSBiYWNrIHRvIHlvdSB3aXRoIHF1ZXN0aW9ucyBpZiBhbnkuDQoNCkJlc3QgcmVnYXJkcywNClNo aXJsZXkNCg0KDQoNCj4gT24gSnVsIDI4LCAyMDE3LCBhdCAzOjIwIEFNLCBWaW5jZW50IFJvY2Eg PHZpbmNlbnQucm9jYUBpbnJpYS5mcj4gd3JvdGU6DQo+IA0KPiBEZWFyIFNoaXJsZXksDQo+IA0K PiBUaGFua3MgYSBsb3QgZm9yIHlvdXIgaW50ZXJlc3QgYW5kIHN1cHBvcnQuIFllcywgd2XigJls bCBuZWVkIHJldmlld2VycyBhbmQgeW91IGFyZSBtb3JlIHRoYW4gd2VsY29tZS4NCj4gVGhpcyBJ LUQgb24gc2xpZGluZyB3aW5kb3cgRkVDIGNvZGVzIGZvY3Vzc2VzIG9uIGEgc3BlY2lmaWMgYXBw bGljYXRpb24vdXNlLWNhc2UsIGJ1dCB3ZSBjYW4gYWxzbyByZWdhcmQNCj4gaXQgYXMgdGhlIGZp cnN0IGNvbmNyZXRlIGluaXRpYXRpdmUgZm9yIHVzaW5nIHN1Y2ggY29kZXMgaW4gSUVURiBzdGFu ZGFyZHMuIA0KPiANCj4gVGhlIE5XQ1JHIHJlbWFpbnMgdGhlIG1haW4gcGxhY2Ugd2hlcmUgZGlz Y3VzcyByZXNlYXJjaCB0b3BpY3MgcmVsYXRlZCB0byBzbGlkaW5nIHdpbmRvdyBjb2RlcywgYW5k DQo+IHNldmVyYWwgZGlyZWN0aW9ucyAvIGRlc2lnbiB0ZWFtcyBoYXZlIGFscmVhZHkgYmVlbiBp ZGVudGlmaWVkIGR1cmluZyBsYXN0IHdlZWsgSUVURuKAmTk5IG1lZXRpbmcuIERvIG5vdA0KPiBo ZXNpdGF0ZSB0byBoYXZlIGEgbG9vayBhdCB0aGUgTldDUkcgbWVldGluZyBtaW51dGVzOg0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85OS9taW51dGVzL21pbnV0ZXMtOTktbndj cmctMDAudHh0DQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IA0KPiAgIFZpbmNlbnQNCj4gIA0KPiAN Cj4+IExlIDI3IGp1aWwuIDIwMTcgw6AgMTk6MDgsIFhpYW9tZW5nIFNoaSA8eHNoaUBtaXQuZWR1 PiBhIMOpY3JpdCA6DQo+PiANCj4+IERlYXIgRGF2aWQsDQo+PiANCj4+IFRoYW5rIHlvdSBmb3Ig dGhlIG5vdGUhICBJIHdpbGwgcmVsYXkgdGhlIG1lc3NhZ2UgdG8gbXkgY29sbGVhZ3VlcyBhcyB3 ZWxsLg0KPj4gDQo+PiBCZXN0LA0KPj4gU2hpcmxleQ0KPj4gDQo+PiANCj4+PiBPbiBKdWwgMjMs IDIwMTcsIGF0IDg6MzkgUE0sIEJsYWNrLCBEYXZpZCA8RGF2aWQuQmxhY2tAZGVsbC5jb20+IHdy b3RlOg0KPj4+IA0KPj4+IFNoaXJsZXksDQo+Pj4gIA0KPj4+IFRoYW5rIHlvdSBmb3IgeW91ciBp bnRlcmVzdCwgYW5kIHRoZSB0aW1pbmcgaXMgZmluZS4gIFRoZSBiYWNrZ3JvdW5kIGluZm9ybWF0 aW9uIGlzIHVzZWZ1bCDigJMgYmV5b25kIHRoYXQsIGlmIHlvdSBhbmQvb3IgeW91ciBjb2xsZWFn dWVzIGFyZSBpbnRlcmVzdGVkIGluIHJldmlld2luZyB0aGlzIGRyYWZ0IChhbmQgdGhlIHN1cHBv cnRpbmcgZnJhbWV3b3JrIGV4dGVuc2lvbiBkcmFmdCwgICAgDQo+Pj4gZHJhZnQtaWV0Zi10c3Z3 Zy1mZWNmcmFtZS1leHQtMDAudHh0KSwgY29tbWVudHMgd291bGQgYmUgd2VsY29tZSBhdCBhbnkg dGltZS4gIEluIHBhcnRpY3VsYXIsIHRoZXJl4oCZcyBubyBuZWVkIHRvIHdhaXQgZm9yIFdvcmtp bmcgR3JvdXAgTGFzdCBDYWxsIHRvIHNlbmQgY29tbWVudHMgdG8gdGhlIGxpc3QuDQo+Pj4gIA0K Pj4+IFRoYW5rcywgLS1EYXZpZA0KPj4+ICANCj4+PiBGcm9tOiB0c3Z3ZyBbbWFpbHRvOnRzdndn LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBYaWFvbWVuZyBTaGkNCj4+PiBTZW50OiBX ZWRuZXNkYXksIEp1bHkgMTksIDIwMTcgMjo1NCBQTQ0KPj4+IFRvOiB0c3Z3Z0BpZXRmLm9yZw0K Pj4+IFN1YmplY3Q6IFJlOiBbdHN2d2ddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdHN2d2ctcmxj LWZlYy1zY2hlbWUtMDAudHh0DQo+Pj4gIA0KPj4+IERlYXIgVmluY2VudCBhbmQgYWxsLA0KPj4+ ICANCj4+PiBUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB0aGUgZ3JlYXQgZWZmb3J0LiAgVGhpcyBp cyBteSBmaXJzdCBwb3N0IHRvIHRoZSBncm91cCwgYW5kIEkgaG9wZSBteSBtZXNzYWdlIGhhcyBj b21lIGF0IGFuIGFwcHJvcHJpYXRlIHRpbWUgZHVyaW5nIHRoZSBwaXBlbGluZS4gIEkgd29yayB3 aXRoIENvZGUgT24gVGVjaG5vbG9naWVzIGluIENhbWJyaWRnZSwgTUEsIHdoZXJlIG91ciBmb2N1 cyBpcyBpbiB0aGUgYXBwbGljYXRpb24gb2YgcmFuZG9tIGxpbmVhciBuZXR3b3JrIGNvZGVzIGlu IGRpZmZlcmVudCBsYXllcnMgb2YgdGhlIG5ldHdvcmsgc3RhY2sgdG8gYWNoaWV2ZSBwZXJmb3Jt YW5jZSBpbXByb3ZlbWVudHMgd2hlbiBwb3NzaWJsZS4gIA0KPj4+IA0KPj4+IA0KPj4+IFdlIGFy ZSBkZWxpZ2h0ZWQgdG8gc2VlIHRoYXQgdGhlIHNsaWRpbmcgd2luZG93IGFwcHJvYWNoIGhhcyBi ZWNvbWUgYSB3b3JraW5nIGdyb3VwIGl0ZW0gYW5kIHdlIGFyZSBpbiBmdWxsIHN1cHBvcnQgb2Yg dGhlIGluaXRpYXRpdmUuICBUbyB0aGlzIGV4dGVudCwgd2UgdGhvdWdodCBpdCBtaWdodCBiZSBv ZiBpbnRlcmVzdCB0byB0aGUgZ3JvdXAgdG8gc2VlIHNvbWUgcGFzdCByZXNlYXJjaCB3b3JrIGlu IHRoaXMgYXJlYSwgZWl0aGVyIGZyb20gdXMsIG9yIHRoYXQgd2UgYXJlIGF3YXJlIG9mLiAgQmVs b3cgaXMgYSBxdWljayBsaXN0LCBhbmQgd2UgbG9vayBmb3J3YXJkIHRvIGZ1dHVyZSBkaXNjdXNz aW9ucyB3aXRoaW4gdHN2d2cuIA0KPj4+ICANCj4+PiAxKSBOZXR3b3JrIENvZGluZyBPdmVydmll dywgSUVURiA4NiwgMjAxMywgQ29kZSBPbiBUZWNobm9sb2dpZXMsIGh0dHBzOi8vd3d3LmlldGYu b3JnL3Byb2NlZWRpbmdzLzg2L3NsaWRlcy9zbGlkZXMtODYtbndjcmctNS5wZGYuDQo+Pj4gMikg VC4gSG8sIGV0IGFsLiwgIkEgcmFuZG9tIGxpbmVhciBuZXR3b3JrIGNvZGluZyBhcHByb2FjaCB0 byBtdWx0aWNhc3QsIiBJRUVFIFRyYW5zYWN0aW9ucyBvbiBJbmZvcm1hdGlvbiBUaGVvcnksIHZv bC4gNTIsIG5vLiAxMCwgcHAuIDQ0MTMtNDQzMCwgMjAwNi4NCj4+PiAzKSBKSywgU3VuZGFyYXJh amFuIGV0IGFsLiwgIk5ldHdvcmsgY29kaW5nIG1lZXRzIFRDUCwiIElORk9DT00gMjAwOSwgSUVF RS4gSUVFRSwgMjAwOS4NCj4+PiA0KSBNLiBLaW0gZXQgYWwuLCAiTW9kZWxpbmcgbmV0d29yayBj b2RlZCBUQ1AgdGhyb3VnaHB1dDogQSBzaW1wbGUgbW9kZWwgYW5kIGl0cyB2YWxpZGF0aW9uLCIg UHJvY2VlZGluZ3Mgb2YgdGhlIDV0aCBJbnRlcm5hdGlvbmFsIElDU1QgQ29uZmVyZW5jZSBvbiBQ ZXJmb3JtYW5jZSBFdmFsdWF0aW9uIE1ldGhvZG9sb2dpZXMgYW5kIFRvb2xzLiBJQ1NUIChJbnN0 aXR1dGUgZm9yIENvbXB1dGVyIFNjaWVuY2VzLCBTb2NpYWwtSW5mb3JtYXRpY3MgYW5kIFRlbGVj b21tdW5pY2F0aW9ucyBFbmdpbmVlcmluZyksIDIwMTEuDQo+Pj4gNSkgUy4gV3VuZGVybGljaCBl dCBhbC4sIFdlIGRvbid0IG5lZWQgbm8gZ2VuZXJhdGlvbi1hIHByYWN0aWNhbCBhcHByb2FjaCB0 byBzbGlkaW5nIHdpbmRvdyBSTE5DLiBJbiBXaXJlbGVzcyBEYXlzLCAyMDE3IChwcC4gMjE4LTIy MykuIElFRUUuDQo+Pj4gIA0KPj4+IEJlc3QgcmVnYXJkcywNCj4+PiBTaGlybGV5IFNoaQ0KPj4+ ICANCj4+PiANCj4+PiANCj4+PiAgDQo+Pj4gT24gSnVsIDE3LCAyMDE3LCBhdCA5OjM0IEFNLCBp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgd3JvdGU6DQo+Pj4gIA0KPj4+IA0KPj4+IEEgTmV3IElu dGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0 cyBkaXJlY3Rvcmllcy4NCj4+PiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBUcmFu c3BvcnQgQXJlYSBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KPj4+IA0KPj4+ICAgICAgICBU aXRsZSAgICAgICAgICAgOiBTbGlkaW5nIFdpbmRvdyBSYW5kb20gTGluZWFyIENvZGUgKFJMQykg Rm9yd2FyZCBFcmFzdXJlIENvcnJlY3Rpb24gKEZFQykgU2NoZW1lIGZvciBGRUNGUkFNRQ0KPj4+ ICAgICAgICBBdXRob3IgICAgICAgICAgOiBWaW5jZW50IFJvY2ENCj4+PiBGaWxlbmFtZSAgICAg ICAgOiBkcmFmdC1pZXRmLXRzdndnLXJsYy1mZWMtc2NoZW1lLTAwLnR4dA0KPj4+IFBhZ2VzICAg ICAgICAgICA6IDIzDQo+Pj4gRGF0ZSAgICAgICAgICAgIDogMjAxNy0wNy0xNw0KPj4+IA0KPj4+ IEFic3RyYWN0Og0KPj4+ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBmdWxseS1zcGVjaWZp ZWQgRkVDIHNjaGVtZSBmb3IgdGhlIFNsaWRpbmcNCj4+PiAgIFdpbmRvdyBSYW5kb20gTGluZWFy IENvZGVzIChSTEMpIG92ZXIgR0YoMl5ebSksIHdoZXJlIG0gZXF1YWxzIDENCj4+PiAgIChiaW5h cnkgY2FzZSksIDQgb3IgOCwgdGhhdCBjYW4gYmUgdXNlZCB0byBwcm90ZWN0IGFyYml0cmFyeSBt ZWRpYQ0KPj4+ICAgc3RyZWFtcyBhbG9uZyB0aGUgbGluZXMgZGVmaW5lZCBieSBGRUNGUkFNRSBl eHRlbmRlZCB0byBzbGlkaW5nDQo+Pj4gICB3aW5kb3cgY29kZXMuICBUaGVzZSBzbGlkaW5nIHdp bmRvdyBGRUMgY29kZXMgcmVseSBvbiBhbiBlbmNvZGluZw0KPj4+ICAgd2luZG93IHRoYXQgc2xp ZGVzIG92ZXIgdGhlIHNvdXJjZSBzeW1ib2xzLCBnZW5lcmF0aW5nIG5ldyByZXBhaXINCj4+PiAg IHN5bWJvbHMgd2hlbmV2ZXIgbmVlZGVkLiAgQ29tcGFyZWQgdG8gYmxvY2sgRkVDIGNvZGVzLCB0 aGVzZSBzbGlkaW5nDQo+Pj4gICB3aW5kb3cgRkVDIGNvZGVzIG9mZmVyIGtleSBhZHZhbnRhZ2Vz IHdpdGggcmVhbC10aW1lIGZsb3dzIGluIHRlcm1zDQo+Pj4gICBvZiByZWR1Y2VkIEZFQy1yZWxh dGVkIGxhdGVuY3kgd2hpbGUgb2Z0ZW4gcHJvdmlkaW5nIGltcHJvdmVkIGVyYXN1cmUNCj4+PiAg IHJlY292ZXJ5IGNhcGFiaWxpdGllcy4NCj4+PiANCj4+PiANCj4+PiBUaGUgSUVURiBkYXRhdHJh Y2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4+PiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRzdndnLXJsYy1mZWMtc2NoZW1lLw0KPj4+IA0K Pj4+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj4+PiBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10c3Z3Zy1ybGMtZmVjLXNjaGVt ZS0wMA0KPj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0 Zi10c3Z3Zy1ybGMtZmVjLXNjaGVtZS0wMA0KPj4+IA0KPj4+IA0KPj4+IFBsZWFzZSBub3RlIHRo YXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1p c3Npb24NCj4+PiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxh YmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPj4+IA0KPj4+IEludGVybmV0LURyYWZ0cyBhcmUgYWxz byBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzLw0KPj4+IA0KPj4gDQo+IA0KDQo= From nobody Mon Jul 31 23:54:12 2017 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 D5A6C132820 for ; Mon, 31 Jul 2017 23:54:11 -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, RP_MATCHES_RCVD=-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 jnryqiNQ_vwt for ; Mon, 31 Jul 2017 23:54:08 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id DE87B132818 for ; Mon, 31 Jul 2017 23:54:07 -0700 (PDT) Received: from Gs-MacBook-Pro.local (at-zeroshell-1.erg.abdn.ac.uk [139.133.217.68]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id BBF611B0017A; Tue, 1 Aug 2017 07:53:38 +0100 (BST) Message-ID: <5980256F.7060100@erg.abdn.ac.uk> Date: Tue, 01 Aug 2017 07:53:35 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Brian E Carpenter CC: Fred Baker , Ruediger.Geib@telekom.de, David.Black@dell.com, roland.bless@kit.edu, tsvwg@ietf.org References: <595F4D19.9030502@erg.abdn.ac.uk> <011e5fb5-6c83-bb38-e2cb-7fced2cb774a@kit.edu> <595F6F4F.20005@erg.abdn.ac.uk> <74717821-30ae-203b-197b-2455cbf9d4a3@gmail.com> <66425AFB-A929-4A91-90F8-432F4FAE0520@jisc.ac.uk> <59633402.9020907@erg.abdn.ac.uk> <50f4b157-425e-a2cc-a924-5dd02345adef@gmail.com> <505f03a57bd4481b832bc22340c37316@HE105654.emea1.cds.t-internal.com> <7af582df-6c55-a835-8156-50c9f322e4e9@gmail.com> In-Reply-To: <7af582df-6c55-a835-8156-50c9f322e4e9@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 06:54:12 -0000 On 31/07/2017, 21:25, Brian E Carpenter wrote: > On 01/08/2017 05:00, Fred Baker wrote: >> >>> On Jul 31, 2017, at 6:34 AM, Ruediger.Geib@telekom.de wrote: >>> >>> DSCP 000001 might be an option. No other IETF recommended DSCP is re-marked to this one. It is to some extent RFC4594 compatible and RFC8100 could cope with it if default transport is applied. >> https://tools.ietf.org/html/rfc2474#section-6 indicates that 000001 is experimental/local use, available for standards allocation only as necessary. > "We RECOMMEND that the DSCP value(s) of the > unsupported service class be changed to 000xx1 on ingress and > changed back to original value(s) on egress..." > > That is a local use within a domain, completely compatible with both > pools 2 and 3 which are both defined as for local use. So 000001 > is really not suitable for standards track recommendation, until > pool 1 is full. > >> Pool 1 is 32 code points, of which I believe 20 are in use (figure 3 of RFC 4594). I'd rather not dip into pool 3 unnecessarily. Is there another option? > 000010 is just fine. Why are we still discussing this? > > Brian The reason this is being discussed is that the primary objective of the LE PHB is to protect best-effort (BE) traffic (packets forwarded with the default PHB) from LE traffic in congestion situations, I think there is reasonable doubt that a LE service can be safely deployed across the Internet using a codepoint of 000010. There seems evidence that there are still even now deployed routers that have not adjusted their remarking behaviour after the IETF deprecated ToS Precedence bleaching. I do think this change should have happened, and still think that routers still need to be updated. That does not however mean the IETF can simply ignore the consequences of this remarking still being deployed. A PS that advises LE traffic to be marked as 000010 and standardises LE treatment for 000010 needs to show that this is safe. The key point is that introducing a LE service is not the same as introducing other treatments. A packet that uses AF marking and encounters ToS Precedence bleaching would expereince AF11, AF21, AF31, AF41 emerging remarked to a codepoint of 000010, and AF12, AF22, AF32, AF42, VA would emerge as 000100, etc. Because the LE PHB is a lower effort PHB, implementing a PHB with a codepoint of 000010 would result in some traffic originally marked as AFx1 being assigned a lower effort than AFx1 or AFx2. That in itself would be less of an issue - since remarking happens - but here there is a risk that traffic trying to utilise the AF PHB groups - e.g., where AF41 can become carried using the LE PHB while traffic originally marked AF42 would be carried using the default PHB. This priority inversion seems very undesirable. If we need to seek a different codepoint, I think this could be pursued with IANA. You are correct in that the DSCPs in the IANA pool 3 "May be utilized for future Standards Action allocations as necessary". The policy is actually stated for pool 3 in the registry is "should be preferentially utilized for standardized assignments if Pool 1 is ever exhausted" and that this pool should only be used when needed. There are presently 23/32 allocations. As the TSVWG Chairs indicated, they would be willing to consider making the changes needed to allow IANA to make a pool 3 allocation for the LE service, if none of the remaining codepoints in pool 1 can be safely utilised. Gorry