From nobody Fri Dec 1 16:35:59 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 8D197127078 for ; Fri, 1 Dec 2017 16:35:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151217495757.7379.14747475039043629956.idtracker@ietfa.amsl.com> Date: Fri, 01 Dec 2017 16:35:57 -0800 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, 02 Dec 2017 00:35:57 -0000 Changed milestone "Submit 'Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP' as a BCP RFC", set due date to January 2018 from October 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 January 2018 from October 2017. Changed milestone "Submit 'A Lower Effort Per-Hop Behavior (LE PHB)' as a Proposed Standard RFC", set due date to April 2018 from December 2017. Changed milestone "Submit 'SCTP NAT Support' to IESG for consideration as a PS RFC", set due date to May 2018 from December 2017. URL: https://datatracker.ietf.org/wg/tsvwg/about/ From qxie@netflix.com Fri Dec 1 10:00: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 E9DBE127B52 for ; Fri, 1 Dec 2017 10:00:20 -0800 (PST) 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 (1024-bit key) header.d=netflix.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 d9EFFaU-_WAH for ; Fri, 1 Dec 2017 10:00:18 -0800 (PST) Received: from mail-yw0-x241.google.com (mail-yw0-x241.google.com [IPv6:2607:f8b0:4002:c05::241]) (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 D24171279EB for ; Fri, 1 Dec 2017 10:00:17 -0800 (PST) Received: by mail-yw0-x241.google.com with SMTP id r205so4355059ywb.3 for ; Fri, 01 Dec 2017 10:00:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZXqW0cSOuWLOxczjyLqOjlk0zv12eAW3+2I3eRR7sDU=; b=jVbCXeAUQeZpYVMzNSpYuiv9r01TQPnBttTm6XgHqiv2frlIIKc5AW8RbVAnzjBkX5 DWTO6Xo8p5m8pxR4GBB3e9vOMEFb1qV0baoJpQpAFheTPiQEILQ0vny+AEEu+UhpCqOS A/M/OaVKEFbt7nwFScS4ypPFZbi2LjYwhrUBk= 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=ZXqW0cSOuWLOxczjyLqOjlk0zv12eAW3+2I3eRR7sDU=; b=ilBSFH1YOsjVznAHI3LEh/s6WjiFe1MgyUlUY4RJsxxy0RGMhf26JsgTWv3IndbS9+ P6nwUFzAMHbIWYYUsQ3rb3OnkN/h1vAppPK4WRoYMQrl2AkL4RvxCEb5oHzbzMSgxxEg od5jkGdCsSHezCOZl/AkOrYy8pABE5K2ij+ay2cYa4EMGGDXY8mA4LP3nnxIXiQ6T75W Hh26ztaBDrRK5WmmKevgIERZcuPiCaAAX9sJJhcjdQ9ECm/pkPq4YuGoJKvv707/031X Wdcj4izDiq8gZuoznZk64l+6bRvLflw1/3Gn276TXlw8Nb8Usf2My5KhJUjrOZkvHqFQ YuTQ== X-Gm-Message-State: AJaThX7Rj8kAP2XDzhPxYIpgYN7MeMGHHTk/u/5e7uWSKWSU3sXNpI/4 +f0zp5aNGAL6PQh0rAJhsGedvaCPxmA= X-Google-Smtp-Source: AGs4zMbv8PhCTJzAWAeCosvnxZFvb2Ul9zQdwZyYbEPmXJvYNiBssJNxjftk5/8aztrNoeMMyKkxWg== X-Received: by 10.129.91.193 with SMTP id p184mr4395440ywb.272.1512151217015; Fri, 01 Dec 2017 10:00:17 -0800 (PST) Received: from [192.168.0.152] (75-130-223-241.dhcp.stls.mo.charter.com. [75.130.223.241]) by smtp.gmail.com with ESMTPSA id o83sm339353ywb.51.2017.12.01.10.00.15 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 01 Dec 2017 10:00:16 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Qiaobing Xie In-Reply-To: <03400629-915F-469C-BA09-2A08180444C3@netflix.com> Date: Fri, 1 Dec 2017 12:00:13 -0600 Cc: =?utf-8?Q?Irene_R=C3=BCngeler?= , Kacheong Poon , peterlei@netflix.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <5A0E7F3B.9020905@erg.abdn.ac.uk> <3BCEE83B-66FE-47AF-A6AC-1DF59B9041B7@fh-muenster.de> <99901D4F-6B4C-41A6-AC7A-5A1457848BB6@fh-muenster.de> <03400629-915F-469C-BA09-2A08180444C3@netflix.com> To: Michael Tuexen , tsvwg@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: X-Mailman-Approved-At: Fri, 01 Dec 2017 16:51:42 -0800 Subject: Re: [tsvwg] WGLC comments request for draft-ietf-tsvwg-rfc4960-errata-04.txt - to end Fri 8th Dec 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: Fri, 01 Dec 2017 18:01:13 -0000 (re-send with tsvwg list) > On Nov 27, 2017, at 11:05 PM, Qiaobing Xie wrote: >=20 > In 3.2., the new text still reads quite confusing to me.. maybe just = directly says something like: >=20 > "Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST = discard/ignore subsequent ULP shutdown requests,=20 > but MUST continue to response to SHUTDOWN chunks from its peer.=E2=80=9D= >=20 > And a couple of minor fixes: >=20 > O) Receive Unacknowledged Message >=20 > Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer > size [,stream id] [,stream sequence number] [,partial > flag] [,payload protocol-id]) >=20 > -Q >=20 >> On Nov 21, 2017, at 6:47 AM, Michael Tuexen = wrote: >>=20 >>> On 21. Nov 2017, at 13:27, Irene R=C3=BCngeler = wrote: >>>=20 >>> I reviewed this draft and found some typos which I mentioned to = Michael directly. Otherwise, I have no comments concerning functional = topics and support the progression of this draft to RFC. >> Hi Irene, >>=20 >> thanks for the review. >>=20 >> The changes have been committed and the changes are available at: >> = https://github.com/sctplab/rfc4960bis/commit/77823a3d065c716c4257e65e65dae= 995ad47ee22 >>=20 >> Best regards >> Michael >>>=20 >>> Best regards >>>=20 >>> Irene >>>=20 >>>> Am 17.11.2017 um 14:52 schrieb Michael Tuexen = : >>>>=20 >>>> Dear all, >>>>=20 >>>> thank you very much for agreeing to review the ID during WG LC. >>>>=20 >>>> The WGLC has just started. I'm sending this mail since I'm not sure >>>> you are following the tsvwg mailing list. >>>>=20 >>>> Please send your comments to the mailing list. In the unlikely = event that >>>> you don't have any comments, please state that in a short mail, = too. >>>>=20 >>>> Thank you very much for your support! >>>>=20 >>>> Best regards >>>> Michael >>>>=20 >>>>> Begin forwarded message: >>>>>=20 >>>>> From: Gorry Fairhurst >>>>> Subject: [tsvwg] WGLC comments request for = draft-ietf-tsvwg-rfc4960-errata-04.txt - to end Fri 8th Dec 2017 >>>>> Date: 17. November 2017 at 07:18:35 CET >>>>> To: tsvwg@ietf.org >>>>> Cc: tsvwg-chairs@ietf.org >>>>> Reply-To: gorry@erg.abdn.ac.uk >>>>>=20 >>>>>=20 >>>>> Dear TSVWG WG, >>>>>=20 >>>>> As we discussed during the TSVWG session today, the draft "RFC = 4960 Errata and Issues", is thought ready for publication and now ready = for feedback. The latest version of the draft is available here: >>>>> https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-04 >>>>>=20 >>>>> This email starts a 3 week WGLC to allow time for folks to provide = feedback, to conclude on Fri 8th Dec 2017. Please send comments = indicating the usefulness of the draft, noting issues, or simply asking = for clariification to this list (or to the WG Dhairs). >>>>>=20 >>>>> Best Regards, >>>>>=20 >>>>> Gorry, David and Wes >>>>> (TSVWG co-Chairs) >>>>>=20 >>>>> The following people have agreed to also submit a review during = the WGLC period: >>>>> Kacheong >>>>> Peter Lei >>>>> Irene Rungeler >>>>> Qiaobing Xie >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>> ***************************************** >>>=20 >>> Dr. Irene R=C3=BCngeler >>> Fachbereich Elektrotechnik und Informatik >>> Labor f=C3=BCr Netzwerkprogrammierung, Datenbanklabor >>>=20 >>> Fachhochschule M=C3=BCnster >>> - University of Applied Sciences -=20 >>> Stegerwaldstra=C3=9Fe 39, Raum E130a >>> 48565 Steinfurt >>>=20 >>> Tel: +49 2551 962-561=20 >>> Fax: +49 2551 962-563=20 >>> EMail: I.Ruengeler@fh-muenster.de >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >=20 From nobody Sun Dec 3 18:29:00 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 D97891200C1; Sun, 3 Dec 2017 18:28:53 -0800 (PST) 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.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151235453384.6449.5212264789181369967@ietfa.amsl.com> Date: Sun, 03 Dec 2017 18:28:53 -0800 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-tunnel-congestion-feedback-06.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, 04 Dec 2017 02:28:54 -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 : Tunnel Congestion Feedback Authors : Xinpeng Wei Zhu Lei Lingli Deng Filename : draft-ietf-tsvwg-tunnel-congestion-feedback-06.txt Pages : 19 Date : 2017-12-03 Abstract: This document describes a method to measure congestion on a tunnel segment based on recommendations from RFC 6040, "Tunneling of Explicit Congestion Notification", and to use IPFIX to communicate the congestion measurements from the tunnel's egress to a controller which can respond by modifying the traffic control policies at the tunnel's ingress. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-tunnel-congestion-feedback/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-tunnel-congestion-feedback-06 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-tunnel-congestion-feedback-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-tunnel-congestion-feedback-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 4 03:00:58 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 82C4B120721 for ; Mon, 4 Dec 2017 03:00:57 -0800 (PST) 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 iGQBPWjzqQeQ for ; Mon, 4 Dec 2017 03:00:55 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 015251201F2 for ; Mon, 4 Dec 2017 03:00:55 -0800 (PST) Received: from dhcp-207-152.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:5c11:57af:b6ca:ac29]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id E1F451B00EE0 for ; Mon, 4 Dec 2017 11:00:52 +0000 (GMT) Reply-To: gorry@erg.abdn.ac.uk To: tsvwg WG From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: <5678bc42-ba95-2b0c-6606-10839557b019@erg.abdn.ac.uk> Date: Mon, 4 Dec 2017 11:00:52 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [tsvwg] IETF-100 working group notes 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, 04 Dec 2017 11:00:57 -0000 The formatted draft notes for the tsvwg meeting at ietf-100 are here: https://datatracker.ietf.org/meeting/100/materials/minutes-100-tsvwg/ Please send notes of any corrections to the Chairs. Thanks as always to all who contributed - the note takers and the meetecho team for their recordings! Best wishes, Gorry, David & Wes From nobody Tue Dec 5 02:40: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 AB6E2126B7E for ; Tue, 5 Dec 2017 02:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 MTqbtJeyyvu8 for ; Tue, 5 Dec 2017 02:40:45 -0800 (PST) Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (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 993B11241F5 for ; Tue, 5 Dec 2017 02:40:45 -0800 (PST) Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.21/8.16.0.21) with SMTP id vB5AapIB123563 for ; Tue, 5 Dec 2017 10:40:44 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=1WlHtB5ar39wn1gBLoVf+VYOgX2CpCBDiqhc43ZhanA=; b=GlWj01q0zb3RevkoWQ76sWytnv/o31ZGtdW3I3qz3+Ru6bh7/adQlL4cE2Z8vLof5y+P U5dYjldzBoig2YGlc16f/p+mMxu4Jvl33UBNU1Na3VAlFX+DxZTG3rCq3IIo5keSysyy fniHUQj1QmHy7aGAdbANbzzDxHuZK2RWGPqU05cdRLbh8DlNR47TRDtbYO3Is4wpzpce 3HY0fbRC1ZT3tEbV/hp4fOWGHar6+QN3MFuoDNdJSJ101zILV2V0ftfXI29YlfYfPCI9 i1y3yJweX9KssJkakYuXWzHqUG9jwdWGVEW1Ba0NtKRmLhu0NevQ48fg8mOIW13cFM53 vA== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2130.oracle.com with ESMTP id 2en9pgtk97-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 05 Dec 2017 10:40:44 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id vB5AehUR006077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 5 Dec 2017 10:40:44 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vB5AehFv026133 for ; Tue, 5 Dec 2017 10:40:43 GMT Received: from [10.159.211.29] (/10.159.211.29) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 05 Dec 2017 02:40:43 -0800 To: tsvwg@ietf.org References: <5A0E7F3B.9020905@erg.abdn.ac.uk> From: Ka-Cheong Poon Organization: Oracle Corporation Message-ID: Date: Tue, 5 Dec 2017 18:40:35 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <5A0E7F3B.9020905@erg.abdn.ac.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8735 signatures=668637 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=12 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1712050153 Archived-At: Subject: Re: [tsvwg] WGLC comments request for draft-ietf-tsvwg-rfc4960-errata-04.txt - to end Fri 8th Dec 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: Tue, 05 Dec 2017 10:40:47 -0000 On 11/17/2017 02:18 PM, Gorry Fairhurst wrote: > As we discussed during the TSVWG session today, the draft "RFC 4960 > Errata and Issues", is thought ready for publication and now ready for > feedback. The latest version of the draft is available here: > https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-04 Some comments: 3.6.2. It may not be clear what "path currently is used for data transfer" is. Does it mean that an SCTP impl can only use one path to send data? What does it mean if an SCTP impl sends data to more than one path simultaneously? 3.17.2. I remembered that there was a discussion on which addresses are considered to be confirmed when using sctp_connectx(). The new text means that all the addresses passed to sctp_connectx() are considered confirmed. But I remembered that the discussion argued for only the address used by the peer to send the INIT-ACK is confirmed. Is this correct? 3.26.2. o SCTP MUST NOT increment cwnd by more than 1*MTU per RTT. If MUST is used, this excludes other congestion control algorithms. Is it better to use "SHOULD"? This probably also applies to 3.27.2 (section 7.2.1). But the original already uses MUST... 3.31.2. This sentence "When calculating the number of packets to transmit and particularly using the formula above, cwnd SHOULD NOT be changed" can be confusing regarding the following if((flightsize + Max.Burst*MTU) < cwnd) cwnd = flightsize + Max.Burst*MTU cwnd is set to a NEW value yet the sentence required that cwnd cannot be changed. Maybe use another variable, eff_cwnd (effective cwnd) in the formula? 3.40. Just a question. When the I-D.ietf-tsvwg-ecn-experimentation becomes an RFC later, will this be updated in this doc too? Or will the reference stay as an I-D? 3.41. Another question. Should the Host Name Address parameter be completed removed from the doc instead of stating that it MUST not be used everywhere? I found it very strange that a type is specified in the doc and then everywhere else states that it MUST not be used... If it has to stay, I guess RFC 4960 3.3.2.1 (where Host Name Address is first mentioned) should be updated to clearly state that it is deprecated. Thanks. -- K. Poon ka-cheong.poon@oracle.com From nobody Wed Dec 6 05:49: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 B5CC71243F3; Wed, 6 Dec 2017 05:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=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 yqoZegXQMbtX; Wed, 6 Dec 2017 05:48:51 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5E2A128ACA; Wed, 6 Dec 2017 05:48:50 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 5EEC91807AD; Wed, 6 Dec 2017 14:48:49 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 34CDF2007C; Wed, 6 Dec 2017 14:48:49 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0361.001; Wed, 6 Dec 2017 14:48:48 +0100 From: To: Joe Touch CC: "tsvwg-chairs@ietf.org" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-01.txt Thread-Index: AQHS8DxD3yHTL7iCi0yopFq7TolYSqI7XLGQgABgo4CAAZmngIAGv30AgPM6QcA= Date: Wed, 6 Dec 2017 13:48:48 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A086FD6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <149859676199.31073.16978555797843649491@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933009FFCD60@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00834e85-2bc6-0df9-2afa-01056534d7c4@isi.edu> <787AE7BB302AE849A7480A190F8B933009FFDAA8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A086FD6OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-01.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, 06 Dec 2017 13:49:04 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A086FD6OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9lLA0KDQpVbmxlc3MgSeKAmW0gbWlzdGFrZW4gSSBkaWRu4oCZdCBzZWUgYW55IHVwZGF0 ZSBvZiB0aGUgZHJhZnQgdG8gYWRkcmVzcyBzb21lIG9mIHRoZSBjb21tZW50cyByYWlzZWQgaW4g bXkgcmV2aWV3Lg0KDQpGV0lXLCBhIGNvcHkgb2YgbXkgY29tbWVudHMgYXJlIGF2YWlsYWJsZSBh dDogaHR0cHM6Ly9naXRodWIuY29tL2JvdWNhZGFpci9JRVRGLURyYWZ0cy1SZXZpZXdzL2Jsb2Iv bWFzdGVyL2RyYWZ0LWlldGYtdHN2d2ctdWRwLW9wdGlvbnMtMDEtcmV2JTIwTWVkLnBkZg0KDQpD aGVlcnMsDQpNZWQNCg0KRGUgOiBKb2UgVG91Y2ggW21haWx0bzp0b3VjaEBpc2kuZWR1XQ0KRW52 b3nDqSA6IG1hcmRpIDQganVpbGxldCAyMDE3IDIzOjI3DQrDgCA6IEJPVUNBREFJUiBNb2hhbWVk IElNVC9PTE4NCkNjIDogdHN2d2ctY2hhaXJzQGlldGYub3JnDQpPYmpldCA6IFJlOiBbdHN2d2dd IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdHN2d2ctdWRwLW9wdGlvbnMtMDEudHh0DQoNCg0KV2ls bCBkbywgYnV0IG5vdGUgdGhhdCBJJ20gb24gdmFjYXRpb24gbm93IHRocm91Z2ggSnVseSAxNi4g SSdsbCBwb3N0IHRoaXMgYW5kIHBpY2sgdGhlIHRocmVhZCB1cCB3aGVuIEkgcmV0dXJuLg0KDQpK b2UNCg0KT24gNi8zMC8yMDE3IDU6MjUgQU0sIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208 bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IHdyb3RlOg0KSGkgSm9lLA0KDQpU aGUgZGlzY3Vzc2lvbiBjYW4gYmUgb24tbGlzdC4NCg0KUGxlYXNlIGZlZWwgZnJlZSB0byBmb3J3 YXJkIHRoZSBpbml0aWFsIHJldmlldyBhbmQgdGhpcyBvbmUgdG8gdGhlIGxpc3QuDQoNClRoYW5r IHlvdS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogSm9lIFRvdWNoIFttYWlsdG86dG91Y2hAaXNp LmVkdV0NCkVudm95w6kgOiBqZXVkaSAyOSBqdWluIDIwMTcgMTU6NTgNCsOAIDogQk9VQ0FEQUlS IE1vaGFtZWQgSU1UL09MTg0KQ2MgOiB0c3Z3Zy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOnRzdndn LWNoYWlyc0BpZXRmLm9yZz4NCk9iamV0IDogUmU6IFt0c3Z3Z10gSS1EIEFjdGlvbjogZHJhZnQt aWV0Zi10c3Z3Zy11ZHAtb3B0aW9ucy0wMS50eHQNCg0KDQpIaSwgTWVkLA0KDQpGaXJzdCwgaXMg dGhlcmUgYSByZWFzb24gd2UncmUgZGlzY3Vzc2luZyB0aGlzIG9mZi1saXN0PyBUaGlzIHRocmVh ZCByZWFsbHkgc2hvdWxkIGJlIG9uLWxpc3QgLSBJIGNhbiBmb3J3YXJkIHRoZXNlIG1lc3NhZ2Vz IGFuZCB3ZSBjYW4gY29udGludWUgdGhlcmUgaWYgaXQncyBPSy4NCg0KSm9lDQoNCk9uIDYvMjgv MjAxNyAxMTo1MiBQTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4gd3JvdGU6DQpIaSBKb2UsDQoNClRoYW5rIHlvdSBmb3Ig dGhlIGFuc3dlcnMuDQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUg OiBKb2UgVG91Y2ggW21haWx0bzp0b3VjaEBpc2kuZWR1XQ0KRW52b3nDqSA6IG1lcmNyZWRpIDI4 IGp1aW4gMjAxNyAyMDoyOA0Kw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xODQpDYyA6IHRz dndnLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86dHN2d2ctY2hhaXJzQGlldGYub3JnPg0KT2JqZXQg OiBSZTogW3RzdndnXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXRzdndnLXVkcC1vcHRpb25zLTAx LnR4dA0KDQoNCkhpLCBNb2hhbW1lZCwNCg0KVGhhbmtzIGZvciB0aGUgZGV0YWlsZWQgY29tbWVu dHMgLSBtb3N0IG9mIHRoZSBlZGl0b3JpYWwgc3VnZ2VzdGlvbnMgYW5kIHJlcXVlc3RzIGZvciBj bGFyaWZpY2F0aW9uIHdpbGwgYmUgYWRkcmVzc2VkIGluIHRoZSBuZXh0IHVwZGF0ZSwgZXhjZXB0 IGFzIG5vdGVkIGJlbG93LiBGb3IgZnV0dXJlIHJlZmVyZW5jZSwgSSB3b3VsZCBiZSBnbGFkIHRv IHByb3ZpZGUgdGhlIFdvcmQgc291cmNlIGlmIHRoYXQncyBlYXNpZXIgZm9yIGZlZWRiYWNrLg0K DQpbTWVkXSBPaywgdGhhbmtzLiBJIGNhbiByZXZpZXcgYW55IHVwZGF0ZWQgdmVyc2lvbiB5b3Ug d2lsbCBwcmVwYXJlLg0KDQpTb21lIGNvbW1lbnRzOg0KDQotIGFzIHRvIHdoZXRoZXIgdGhlIGxp c3Qgb2Ygb3B0aW9ucyBzaG91bGQgY29tcGxldGU7IEknbGwgbGV0IHRoZSBSRkMgRWRpdG9yIGFu ZC9vciBJQU5BIGRlY2lkZSB3aGV0aGVyIHRvIHJlbW92ZSB0aGUgUkVTRVJWRUQgZW50cmllcyBv ciB0aGUgZXhwbGljaXQgaW5kaWNhdGlvbiBvZiB0aGUgSUFOQSBhc3NpZ25hYmxlIHJlZ2lvbjsg SSdtIG5vdCBzdXJlIHdoYXQgdGhlaXIgY29udmVudGlvbiBpcy4NCg0KW01lZF0gVGhlIHBvaW50 IGlzIHRoYXQgeW91ciB0ZXh0IHNheXMg4oCcVGhlIGZvbGxvd2luZyBVRFAgb3B0aW9ucyBhcmUg Y3VycmVudGx5IOKApuKAnC4gT2J2aW91c2x5LCDigJxSRVNFUlZFROKAnSBpcyBub3QgYW4gb3B0 aW9uLg0KDQotIEFDUyBhbmQgQUUgYXJlIGRlZmluZWQgYXMgdGhlIG9ubHkgb3B0aW9ucyB0aGF0 IGRlcGVuZCBvbiB0aGUgY29udGVudHMgb2YgdGhlIG9wdGlvbiBhcmUgZm9yIGEgcmVhc29uLiBU aGF0J3MgdGhlIHNpbXBsZXN0IHdheSB0byBoYW5kbGUgdGhlIGNpcmN1bGFyaXR5IHRoYXQgd291 bGQgb3RoZXJ3aXNlIGFyaXNlLiBFLmcuLCBpZiBBQ1MgY292ZXJlZCB0aGUgY29udGVudHMgb2Yg QUUsIHRoZW4gQUNTIG11c3QgYmUgcHJvY2Vzc2VkIGxhc3QuIEJ1dCBpZiBBRSBjb3ZlcmVkIHRo ZSBjb250ZW50cyBvZiBBQ1MsIHRoZSBBRSBtdXN0IGJlIHByb2Nlc3NlZCBsYXN0LiBSaWdodCBu b3csIHdlIGRlZmluZSB0aGF0IEFFIGNvdmVycyBldmVyeXRoaW5nIEVYQ0VQVCBPTkxZIHRoZSBj b250ZW50cyBvZiBBQ1MgYW5kIHRoYXQgQUNTIGNvdmVycyBldmVyeXRoaW5nLiBCdXQgd2UgY2Fu IG5ldmVyIGtub3cgaG93IEFDUyBhbmQgQUUgd291bGQgbmVlZCB0byBoYW5kbGUgb3B0aW9ucyB0 aGF0IGFyZW4ndCB5ZXQgZGVmaW5lZCAtIGlmIHRoZXkgYWxzbyBkZXBlbmQgb24gdGhlIGNvbnRl bnRzIG9mIHRoZSBvcHRpb24gYXJlYSwgd2UgY2FuIGVuZCB1cCB3aXRoIGEgY2lyY3VsYXJpdHkg YWdhaW4uIEknbSBvcGVuIHRvIG90aGVyIHNvbHV0aW9ucyB0byB0aGlzIGlzc3VlLCBidXQgbm90 IHN1cmUgd2Ugd2FudCB0byBidXJuIGJpdHMgaW4gdGhlIG9wdGlvbiBoZWFkZXIgdG8gaW5kaWNh dGUgd2hpY2ggb3B0aW9ucyBoYXZlICJkZXBlbmRlbnQgY29udGVudHMgdGhhdCBuZWVkIHRvIGJl IHplcm9lZCBmb3IgaW5jbHVzaW9uIGluIG90aGVyIG9wdGlvbnMiIC0gYmVzaWRlcywgdGhhdCBz ZXRzIHVzIHVwIGZvciBjb3ZlcnQgY2hhbm5lbHMgdGhhdCBBRSBtaWdodCBiZSB1c2VkIHRvIHBy ZXZlbnQuIEkuZS4sIHRoZXJlJ3Mgbm8gd2F5IHRvIGxlYXZlIHRoaXMgYXMgYSBkZWNpc2lvbiBm b3IgZnV0dXJlIG9wdGlvbnMgd2l0aG91dCBjcmVhdGluZyBhIHRhbmdsZWQgbWVzcyBvZiAiSSBj b21lIGZpcnN0IiBkZWNsYXJhdGlvbnMsIHN1Y2ggYXMgd2UgaGF2ZSBhbHJlYWR5IGZvciBUQ1Ag b3B0aW9ucy4NCg0KW01lZF0gSSBoZWFyIHlvdSwgYnV0IEkgc3RpbGwgZG9u4oCZdCBnZXQgdGhp czoNCg0KRnV0dXJlIG9wdGlvbnMgTVVTVCBOT1QgYmUgZGVmaW5lZCBhcyBoYXZpbmcgYSB2YWx1 ZSBpbmRlcGVuZGVudCBvZiB0aGUNCg0KICAgY29udGVudHMgb2YgdGhlIG9wdGlvbiBhcmVhDQoN Ci0gdGhlIEZSQUcgb3B0aW9uIGlzIG9uZSBvZiB0aGUgbW9zdCBpbXBvcnRhbnQgYW5kIGEgcmVx dWlyZWQgb3B0aW9uIChpLmUuLCBpZiBVRFAgb3B0aW9ucyBhcmUgc3VwcG9ydGVkLCBGUkFHIG11 c3QgYmUgc3VwcG9ydGVkKSwgd2hpY2ggaXMgd2h5IGl0IG5lZWRzIHRvIHJlbWFpbiBpbiB0aGlz IGRvYy4gV2hldGhlciBmcmFnbWVudHMgYXJlIGRlbGl2ZXJlZCB0byB0aGUgdXNlciB3aGVuIFVE UCBvcHRpb25zIGFyZSBub3Qgc3VwcG9ydGVkIGRlcGVuZHMgb24gaG93IHRoZSBGUkFHIG9wdGlv biBpcyB1c2VkIC0gaWYgdXNlZCB3aXRob3V0IExJVEUsIHRoZSBmcmFnbWVudHMgd291bGQgYmUg ZGVsaXZlcmVkLCBidXQgaWYgdXNlZCB3aXRoIExJVEUgdGhleSB3b3VsZCBub3QgYmUuIFRoYXQn cyB3aHkgd2UgbGVmdCBib3RoIHZhcmlhbnRzIGF2YWlsYWJsZS4NCg0KW01lZF0gSU1ITywgdGhp cyBvbmUgbmVlZCBtb3JlIGV2YWx1YXRpb24vdmFsaWRhdGlvbiBiZWZvcmUgYmVpbmcgaW5jbHVk ZWQgaW4gYSBzdGFuZGFyZCB0cmFjayBkb2N1bWVudC4gSSBjYW4gbGl2ZSB3aXRoIGl0IGluIGFu IGV4cGVyaW1lbnRhbCBSRkMuIEFjdHVhbGx5LCBteSBwcm9wb3NhbCBpcyB0byBzY29wZSB0aGUg dWRwLW9wdGlvbnMgZG9jdW1lbnQgdG8gdGhlIGJhc2UgbWVjaGFuaXNtIGFuZCByZXF1aXJlZCBv cHRpb25zLiBPcHRpb25zIHRoYXQgcmVxdWlyZSBtb3JlIGV4cGVyaW1lbnRzIGFyZSBlYXN5IHRv IGJlIHByb2dyZXNzZWQgaW4gZGVkaWNhdGVkIGRvY3VtZW50cy4gVGhpcyBhcHByb2FjaCB3aWxs IGFsbG93IHVzIHRvIGZpbmFsaXplIHF1aWNrbHkgdGhlIGJhc2UgdWRwLW9wdGlvbnMuDQoNCi0g dGhlIGV4dGVuc2lvbiB0byB0aGUgVURQIEFQSSBuZWVkcyB0byBiZSBpbiB0aGUgY29yZSBvZiB0 aGUgZG9jIGJlY2F1c2UgdGhlIEFQSSBpcyBhIGtleSBwYXJ0IG9mIHRoaXMgKGFuZCBhbnkpIHBy b3RvY29sLg0KDQpbTWVkXSBKb2UsIHdlIGRvIGFsbCBhZ3JlZSB0aGF0IEFQSSBhcmUgaW1wb3J0 YW50LiBBbG1vc3QgYWxsIEFQSXMgZGVmaW5lZCBpbiBJRVRGIEnigJltIGF3YXJlIG9mIGFyZSBk ZWZpbmVkIGFzIEluZm9ybWF0aW9uYWwgUkZDcyAoSSBjYW4gcHJvdmlkZSBhbiBleGhhdXN0aXZl IGxpc3QsIGlmIG5lZWRlZCkuIFRoaXMgaXMgd2h5IEkgc3VnZ2VzdGVkIHRoYXQgeW91IG1vdmUg dGhpcyBzZWN0aW9uIGludG8gYW4gYXBwZW5kaXguDQoNCi0gYXMgdG8gdGhlIG90aGVyIHNlY3Rp b25zIHlvdSBzdWdnZXN0IG1vdmluZyB0byBhbiBhcHBlbmRpeCwgSSdsbCB3YWl0IGZvciBvdGhl ciBmZWVkYmFjayBvbiB0aGF0IHBvaW50LiBJJ20gbm90IGZvbmQgb2YgYXBwZW5kaWNlcyBleGNl cHQgZm9yIGNvZGUgZXhhbXBsZXMgb3IgdHJ1bHkgb3B0aW9uYWwgbWF0ZXJpYWw7IHRoZSBvdGhl ciBwb2ludHMgeW91J3JlIHN1Z2dlc3RpbmcgdG8gbW92ZSAob3RoZXIgdGhhbiBVRFAgQVBJLCBh ZGRyZXNzZWQgYWJvdmUpLCBlLmcuLCBzZWN0aW9ucyBkb24ndCBoYXZlIHRoYXQgcHJvcGVydHkg KHNlYyA3IG9uIHdob3NlIG9wdGlvbnMgYXJlIHRoZXNlIGFuZCBzZWMgOCBvbiBMSVRFIHZzIFVE UCBMaXRlKS4NCg0KW01lZF0gVGhvc2Ugc2VjdGlvbnMgYXJlIG5vdCBub3JtYXRpdmUgKyBzb21l IG9mIHRoZSBjb250ZW50IGlzIHJlZHVuZGFudCAoU2VjLiA3IGFuZCBTZWMgOCkgd2l0aCBvdGhl ciBzdGF0ZW1lbnRzIGVhcmxpZXIgaW4gdGhlIGRvY3VtZW50LiBUaGVzZSBzZWN0aW9ucyBkbyBu b3QgYnJpbmcgbmV3IGVsZW1lbnRzIHRvIHRoZSBkaXNjdXNzaW9uLg0KDQotIFNlYyAxMSBoYXMg YSB0eXBvOyBpdCdzIHJlYWxseSB0d28gc2VjdGlvbnMuDQoNCltNZWRdIE9LLg0KDQpUaGUgcGFy dCBhYm91dCB0aGUgY2hhbmdlcyB0byA3Njggc2hvdWxkIGJlIGl0cyBvd24gc2VjdGlvbg0KDQpb TWVkXSBXZSBkb27igJl0IG5lZWQgYSBzZWN0aW9uIGZvciB0aGlzLiBUaGlzIHRleHQgY2FuIGJl IGluc2VydGVkIGluIHRoZSBJbnRyb2R1Y3Rpb24uDQoNCi4gSSd2ZSBsZWZ0IHRoYXQgaW4gcmln aHQgbm93IGJlY2F1c2UgVURQIG9wdGlvbiAibmVnb3RpYXRpb24iIGlzIGFscmVhZHkgYSBzb2Z0 LXN0YXRlIHBlcnNpc3RlbmNlIG1lY2hhbmlzbSBzaW1pbGFyIHRvIFRDUCBjb250cm9sIGJsb2Nr IHNoYXJpbmcuDQoNCi0gSSBkb24ndCBxdWl0ZSB1bmRlcnN0YW5kIHlvdXIgY29tbWVudDoNCg0K VURQIG9wdGlvbnMgY2FuIGJlIHVzZWQgYSBjb3ZlciBjaGFubmVscy4gSW5zcGVjdGluZyB0aG9z ZSBvcHRpb25zIG1heSBiZSByZXF1aXJlZCB0byBwcm90ZWN0IHNvbWUgbmV0d29ya3MuDQoNCkkg dGhpbmsgeW91IG1lYW4gInVzZWQgYXMgYSBjb3ZlcnQgY2hhbm5lbCIsDQoNCltNZWRdIFllcy4N Cg0KIGJ1dCB0aGF0J3MgdHJ1ZSBmb3IgbmVhcmx5IGV2ZXJ5IGZpZWxkIGluIGFueSBoZWFkZXIu DQoNCltNZWRdIFllcywgYnV0IHRoaXMgaXMgZXhhY2VyYmF0ZWQgd2hlbiB0aGVyZSBpcyBubyBz cGVjaWZpY2F0aW9uIGFib3V0IHRoZSBoYW5kbGluZyBvZiB0aGUgc3VycGx1cyBhcmVhLiBJdCBp cyBsZWdpdGltYXRlIHRoYXQgbmV0d29yayBhZG1pbmlzdHJhdG9ycyB3b3VsZCBzdXNwZWN0cyB0 aG9zZSBwYWNrZXRzLg0KDQpJIGRpc2FncmVlIHRoYXQgaW5zcGVjdGlvbiBtYXkgYmUgcmVxdWly ZWQgdG8gcHJvdGVjdCBhIG5ldHdvcmsNCg0KW01lZF0gU29tZSBpbnNwZWN0aW9uIG1heSBiZSBu ZWVkZWQgdG8gZGV0ZWN0L3Byb3RlY3QgYWdhaW5zdCBhIHZhcmlldHkgb2YgYXR0YWNrcyBhbmQg dG8gcHJvdGVjdCBuZXR3b3Jrcy4gRmlyZXdhbGxzIGFyZSB0aGUgbm9ybSBpbiBlbnRlcnByaXNl IG5ldHdvcmtzLCBmb3IgZXhhbXBsZS4NCg0KLSB0aGVzZSBhcmUgdHJhbnNwb3J0IHZhbHVlcyBp biB0aGUgdHJhbnNwb3J0IHBheWxvYWQgb2YgYSBuZXR3b3JrIHBhY2tldC4NCg0KW01lZF0gVGhp cyBkb2N1bWVudCBkZWZpbmVzIHRoZW0gYXMgdHJhbnNwb3J0IHZhbHVlcywgYnV0IGxlZ2FjeSBk ZXZpY2VzIGNhbm5vdCBoYW5kbGUgdGhlbSBhcyB0cmFuc3BvcnQgdmFsdWVzLg0KDQogQnkgeW91 ciBsb2dpYywgdGhlIGVudGlyZSB0cmFuc3BvcnQgY29udGVudHMgYXJlIHBvdGVudGlhbGx5IGEg Y292ZXJ0IGNoYW5uZWwsIGFuZCB3ZSBoYXZlIG5vIHJlY29tbWVuZGF0aW9uIGVsc2V3aGVyZSB0 byByZXF1aXJlIERQSSB0byBwcm90ZWN0IGEgKm5ldHdvcmsqICh2cy4gdGhlIGVuZHBvaW50cywg d2hpY2ggb2YgY291cnNlIGNvdWxkIHJlcXVpcmUgY2hlY2tpbmcgYW55IHBhcnQgb2YgYSBtZXNz YWdlKS4NCg0KW01lZF0gSSBkb27igJl0IHVuZGVyc3RhbmQgdGhlIHJlZmVyZW5jZSB0byBEUEku IEkgdGhpbmsgeW91IHVuZGVyc3Rvb2Qg4oCcaW5zcGVjdGlvbuKAnSBhcyBpZiBJ4oCZbSBhc2tp bmcgZm9yIOKAnERQSeKAnS4gUGxlYXNlIHNlZSBhYm92ZS4NCg0KLSBhcyB0byB3aGljaCByZWZz IGFyZSBub3JtYXRpdmUsIEFGQUlDVCBvbmx5IFJGQzc2OCAgYW5kIDI0NjAgd291bGQgYmUNCg0K W01lZF0gUGxlYXNlIGZpeCB0aG9zZS4NCg0KLCBhbmQgKm1heWJlKiAxMTIyIChlLmcuLCBieSBl eHRlbmRpbmcgdGhlIGV4dGVudCBvZiB0aGUgVURQIEFQSSkuIE5vdGhpbmcgaW4gdGhpcyBkb2Mg cmVsaWVzIG9uIHRoZSBzdGFuZGFyZHMgbmF0dXJlIG9mIG90aGVyIGRvY3VtZW50cyBBRkFJQ1Qu IE15ICJhY2lkIHRlc3QiIGZvciB3aGV0aGVyIHRvIGluY2x1ZGUgc29tZXRoaW5nIGFzIG5vcm1h dGl2ZSBpcyAid291bGQgbXkgZG9jIG5lZWQgdG8gY2hhbmdlIGlmIHRoZSBvdGhlciBSRkMgY2hh bmdlZCI/IEFGQUlDVCwgdGhhdCdzIG5vdCB0cnVlIGZvciA3NjgsIGJ1dCBJJ2QgbGlrZSB0byBo ZWFyIHdoYXQgb3RoZXJzIHRoaW5rIG9mIHRoYXQgc2V0IGJlZm9yZSBtb3ZpbmcgdGhlbS4NCg0K W01lZF0gRm9yIG90aGVyIFJGQ3MgeW91IGRpZG7igJl0IGNpdGUsIG15IHJhdGlvbmFsZSBmb3Ig aW5jbHVkaW5nIHRoZW0gYXMgbm9ybWF0aXZlIGlzIGFzIGZvbGxvd3M6DQoNCsK3ICAgICAgICAg NzkzIDogTVNTIGFuZCBvdGhlciBmZWF0dXJlcyBhcmUgY2xvbmVkIGZyb20gdGhhdCBkb2N1bWVu dC4NCg0KwrcgICAgICAgICA1OTI1OiB0aGUgdWRwIG9wdGlvbiBjbG9uZXMgdGhlIFRDUCBvcHRp b24uIEFuIGltcGxlbWVudGVyIG5lZWQgdG8gcmVmZXIgdG8gdGhpcyBkb2N1bWVudCB0byBoYXZl IGFuIGlkZWEgYWJvdXQgdGhlIGZvcm1hdDog4oCcSXQgdXNlcyB0aGUgc2FtZSBmb3JtYXQgYXMg c3BlY2lmaWVkIGZvciBUQ1AtQU8sIGV4Y2VwdCB0aGF0IGl0IHVzZXMgYSBLaW5kIG9mIDgu4oCd DQoNCsK3ICAgICAgICAgNjk5NDogRXhJRHMgYXJlIGRlZmluZWQgaW4gdGhpcyBSRkMuIEFuIGlt cGxlbWVudGVyIG5lZWQgdG8gcmVhZCB0aGlzIFJGQyB0byB1bmRlcnN0YW5kL2ltcGxlbWVudCBo b3cgdGhlIHNoYXJlZCBleHBlcmltZW50IElEcyB3b3JrLg0KDQpKb2UNCg0KT24gNi8yOC8yMDE3 IDEyOjQ5IEFNLCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPiB3cm90ZToNCg0KSGkgSm9lLA0KDQoNCg0KUGxlYXNlIGZpbmQg YXR0YWNoZWQgYW4gaW5pdGlhbCByZXZpZXcgb2YgdGhpcyB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVu dCAoYm90aCBkb2MgYW5kIHBkZiBmaWxlcyBhcmUgYXR0YWNoZWQpLg0KDQoNCg0KQ2hlZXJzLA0K DQpNZWQNCg0KDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KDQpEZSA6IHRzdndnIFtt YWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBKb2UgVG91Y2gNCg0K RW52b3nDqSA6IG1hcmRpIDI3IGp1aW4gMjAxNyAyMjo1OA0KDQrDgCA6IGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPjsgaS1kLWFubm91bmNl QGlldGYub3JnPG1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQoNCkNjIDogdHN2d2dAaWV0 Zi5vcmc8bWFpbHRvOnRzdndnQGlldGYub3JnPg0KDQpPYmpldCA6IFJlOiBbdHN2d2ddIEktRCBB Y3Rpb246IGRyYWZ0LWlldGYtdHN2d2ctdWRwLW9wdGlvbnMtMDEudHh0DQoNCg0KDQpIaSwgYWxs LA0KDQoNCg0KVGhpcyB1cGRhdGUgYWRkcyBzb21lIGNsYXJpZmljYXRpb24gb24gaG93IHRvIGhh bmRsZSBvcHRpb25zIHdob3NlDQoNCnZhbHVlcyBkZXBlbmQgb24gb3RoZXIgb3B0aW9ucyAoZS5n LiwgQUNTIGFuZCBBRSkuDQoNCg0KDQpKb2UNCg0KDQoNCg0KDQpPbiA2LzI3LzIwMTcgMTo1MiBQ TSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmc+IHdyb3RlOg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUg b24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCg0KZGlyZWN0b3JpZXMuDQoNClRoaXMgZHJhZnQgaXMg YSB3b3JrIGl0ZW0gb2YgdGhlIFRyYW5zcG9ydCBBcmVhIFdvcmtpbmcgR3JvdXAgb2YgdGhlDQoN CklFVEYuDQoNCg0KDQogICAgICAgIFRpdGxlICAgICAgICAgICA6IFRyYW5zcG9ydCBPcHRpb25z IGZvciBVRFANCg0KICAgICAgICBBdXRob3IgICAgICAgICAgOiBKb2UgVG91Y2gNCg0KICAgIEZp bGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtdHN2d2ctdWRwLW9wdGlvbnMtMDEudHh0DQoNCiAg ICBQYWdlcyAgICAgICAgICAgOiAyNw0KDQogICAgRGF0ZSAgICAgICAgICAgIDogMjAxNy0wNi0y Nw0KDQoNCg0KQWJzdHJhY3Q6DQoNCiAgIFRyYW5zcG9ydCBwcm90b2NvbHMgYXJlIGV4dGVuZGVk IHRocm91Z2ggdGhlIHVzZSBvZiB0cmFuc3BvcnQgaGVhZGVyDQoNCiAgIG9wdGlvbnMuIFRoaXMg ZG9jdW1lbnQgZXhwZXJpbWVudGFsbHkgZXh0ZW5kcyBVRFAgYnkgaW5kaWNhdGluZyB0aGUNCg0K ICAgbG9jYXRpb24sIHN5bnRheCwgYW5kIHNlbWFudGljcyBmb3IgVURQIHRyYW5zcG9ydCBsYXll ciBvcHRpb25zLg0KDQoNCg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZv ciB0aGlzIGRyYWZ0IGlzOg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLXRzdndnLXVkcC1vcHRpb25zLw0KDQoNCg0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQg dmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi10c3Z3Zy11ZHAtb3B0aW9ucy0wMQ0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdHN2d2ctdWRwLW9wdGlvbnMtMDENCg0KDQoNCkEgZGlm ZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdHN2d2ctdWRwLW9wdGlvbnMtMDEN Cg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZg0KDQpzdWJtaXNzaW9uDQoNCnVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNCg0KDQpJ bnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQoN CmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCg0KDQoNCg0K --_000_787AE7BB302AE849A7480A190F8B93300A086FD6OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25z b2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyBcO2NvbG9yXDpibGFjayI7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29Q bGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJUZXh0ZSBicnV0IENhciI7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpi bGFjazt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQ csOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglj b2xvcjpibGFjazt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRl DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVs bGVzIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpi bGFjazt9DQpzcGFuLlByZm9ybWF0SFRNTENhcg0KCXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1h dMOpIEhUTUwgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IlByw6lmb3JtYXTDqSBIVE1MIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFj azt9DQpzcGFuLlRleHRlYnJ1dENhcg0KCXttc28tc3R5bGUtbmFtZToiVGV4dGUgYnJ1dCBDYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgYnJ1dCI7 DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5UZXh0ZWRlYnVs bGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyI7DQoJZm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1h aWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5 bGU6bm9ybWFsO30NCnNwYW4uRW1haWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWln aHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFs O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxp c3QgbDANCgl7bXNvLWxpc3QtaWQ6MTEyNDIyOTQ0MjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTc0MDAwOTk4MCAtOTk5MjU4NjQwIDY3ODk1Mjk5IDY3 ODk1MzAxIDY3ODk1Mjk3IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1Mjk3IDY3ODk1Mjk5IDY3ODk1 MzAxO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDsNCgltc28tZmFyZWFzdC1mb250 LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+SGkgSm9lLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPlVubGVzcyBJ4oCZbSBtaXN0YWtlbiBJIGRpZG7igJl0IHNlZSBhbnkgdXBkYXRl IG9mIHRoZSBkcmFmdCB0byBhZGRyZXNzIHNvbWUgb2YgdGhlIGNvbW1lbnRzIHJhaXNlZCBpbiBt eSByZXZpZXcuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+RldJVywgYSBjb3B5IG9mIG15IGNvbW1lbnRzIGFyZSBhdmFpbGFibGUgYXQ6DQo8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9ib3Vj YWRhaXIvSUVURi1EcmFmdHMtUmV2aWV3cy9ibG9iL21hc3Rlci9kcmFmdC1pZXRmLXRzdndnLXVk cC1vcHRpb25zLTAxLXJldiUyME1lZC5wZGYiPjxzcGFuIGxhbmc9IkVOLVVTIj5odHRwczovL2dp dGh1Yi5jb20vYm91Y2FkYWlyL0lFVEYtRHJhZnRzLVJldmlld3MvYmxvYi9tYXN0ZXIvZHJhZnQt aWV0Zi10c3Z3Zy11ZHAtb3B0aW9ucy0wMS1yZXYlMjBNZWQucGRmPC9zcGFuPjwvYT48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPg0KPHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Q2hlZXJzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+TWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IEpvZSBUb3VjaCBbbWFpbHRv OnRvdWNoQGlzaS5lZHVdDQo8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gbWFyZGkgNCBqdWls bGV0IDIwMTcgMjM6Mjc8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IEJPVUNBREFJUiBNb2hhbWVkIElN VC9PTE48YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IHRzdndnLWNoYWlyc0BpZXRmLm9yZzxicj4NCjxi Pk9iamV0Jm5ic3A7OjwvYj4gUmU6IFt0c3Z3Z10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10c3Z3 Zy11ZHAtb3B0aW9ucy0wMS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5XaWxsIGRv LCBidXQgbm90ZSB0aGF0IEknbSBvbiB2YWNhdGlvbiBub3cgdGhyb3VnaCBKdWx5IDE2LiBJJ2xs IHBvc3QgdGhpcyBhbmQgcGljayB0aGUgdGhyZWFkIHVwIHdoZW4gSSByZXR1cm4uPG86cD48L286 cD48L3A+DQo8cD5Kb2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDYvMzAvMjAx NyA1OjI1IEFNLCA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+ DQptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyBcO2NvbG9yXDpibGFjayZxdW90OyI+ SGkgSm9lLA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcg XDtjb2xvclw6YmxhY2smcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyBcO2NvbG9yXDpibGFjayZxdW90OyI+VGhl IGRpc2N1c3Npb24gY2FuIGJlIG9uLWxpc3QuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgXDtjb2xvclw6YmxhY2smcXVvdDsiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyBcO2NvbG9yXDpibGFjayZxdW90OyI+UGxlYXNlIGZlZWwgZnJlZSB0byBmb3J3YXJk IHRoZSBpbml0aWFsIHJldmlldyBhbmQgdGhpcyBvbmUgdG8gdGhlIGxpc3QuDQo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgXDtjb2xv clw6YmxhY2smcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyBcO2NvbG9yXDpibGFjayZxdW90OyI+VGhhbmsgeW91 Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyBcO2NvbG9yXDpibGFjayZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IFw7Y29sb3JcOmJsYWNrJnF1b3Q7 Ij5DaGVlcnMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3IFw7Y29sb3JcOmJsYWNrJnF1b3Q7Ij5NZWQ8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgXDtjb2xvclw6YmxhY2sm cXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RGUmbmJz cDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0 Ij4gSm9lIFRvdWNoIFs8YSBocmVmPSJtYWlsdG86dG91Y2hAaXNpLmVkdSI+bWFpbHRvOnRvdWNo QGlzaS5lZHU8L2E+XQ0KPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IGpldWRpIDI5IGp1aW4g MjAxNyAxNTo1ODxicj4NCjxiPsOAJm5ic3A7OjwvYj4gQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09M Tjxicj4NCjxiPkNjJm5ic3A7OjwvYj4gPGEgaHJlZj0ibWFpbHRvOnRzdndnLWNoYWlyc0BpZXRm Lm9yZyI+dHN2d2ctY2hhaXJzQGlldGYub3JnPC9hPjxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4g UmU6IFt0c3Z3Z10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10c3Z3Zy11ZHAtb3B0aW9ucy0wMS50 eHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5IaSwgTWVkLDxvOnA+PC9vOnA+PC9wPg0K PHA+Rmlyc3QsIGlzIHRoZXJlIGEgcmVhc29uIHdlJ3JlIGRpc2N1c3NpbmcgdGhpcyBvZmYtbGlz dD8gVGhpcyB0aHJlYWQgcmVhbGx5IHNob3VsZCBiZSBvbi1saXN0IC0gSSBjYW4gZm9yd2FyZCB0 aGVzZSBtZXNzYWdlcyBhbmQgd2UgY2FuIGNvbnRpbnVlIHRoZXJlIGlmIGl0J3MgT0suPG86cD48 L286cD48L3A+DQo8cD5Kb2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDYvMjgv MjAxNyAxMTo1MiBQTSwgPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20iPg0KbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4gd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkhpIEpvZSwNCjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPlRoYW5rIHlvdSBmb3IgdGhlIGFuc3dlcnMuDQo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+UGxlYXNlIHNlZSBpbmxpbmUuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Q2hlZXJzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+TWVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOndpbmRvd3RleHQiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IEpvZSBUb3VjaCBbPGEgaHJlZj0ibWFpbHRv OnRvdWNoQGlzaS5lZHUiPm1haWx0bzp0b3VjaEBpc2kuZWR1PC9hPl0NCjxicj4NCjxiPkVudm95 w6kmbmJzcDs6PC9iPiBtZXJjcmVkaSAyOCBqdWluIDIwMTcgMjA6Mjg8YnI+DQo8Yj7DgCZuYnNw Ozo8L2I+IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE48YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IDxh IGhyZWY9Im1haWx0bzp0c3Z3Zy1jaGFpcnNAaWV0Zi5vcmciPnRzdndnLWNoYWlyc0BpZXRmLm9y ZzwvYT48YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbdHN2d2ddIEktRCBBY3Rpb246IGRy YWZ0LWlldGYtdHN2d2ctdWRwLW9wdGlvbnMtMDEudHh0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHA+SGksIE1vaGFtbWVkLDxvOnA+PC9vOnA+PC9wPg0KPHA+VGhhbmtzIGZvciB0aGUgZGV0 YWlsZWQgY29tbWVudHMgLSBtb3N0IG9mIHRoZSBlZGl0b3JpYWwgc3VnZ2VzdGlvbnMgYW5kIHJl cXVlc3RzIGZvciBjbGFyaWZpY2F0aW9uIHdpbGwgYmUgYWRkcmVzc2VkIGluIHRoZSBuZXh0IHVw ZGF0ZSwgZXhjZXB0IGFzIG5vdGVkIGJlbG93LiBGb3IgZnV0dXJlIHJlZmVyZW5jZSwgSSB3b3Vs ZCBiZSBnbGFkIHRvIHByb3ZpZGUgdGhlIFdvcmQgc291cmNlIGlmIHRoYXQncyBlYXNpZXIgZm9y IGZlZWRiYWNrLjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5bTWVk XSBPaywgdGhhbmtzLiBJIGNhbiByZXZpZXcgYW55IHVwZGF0ZWQgdmVyc2lvbiB5b3Ugd2lsbCBw cmVwYXJlLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPlNv bWUgY29tbWVudHM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMi Pi0gYXMgdG8gd2hldGhlciB0aGUgbGlzdCBvZiBvcHRpb25zIHNob3VsZCBjb21wbGU8L3NwYW4+ dGU7IEknbGwgbGV0IHRoZSBSRkMgRWRpdG9yIGFuZC9vciBJQU5BIGRlY2lkZSB3aGV0aGVyIHRv IHJlbW92ZSB0aGUgUkVTRVJWRUQgZW50cmllcyBvciB0aGUgZXhwbGljaXQgaW5kaWNhdGlvbiBv ZiB0aGUgSUFOQSBhc3NpZ25hYmxlIHJlZ2lvbjsgSSdtIG5vdCBzdXJlIHdoYXQgdGhlaXIgY29u dmVudGlvbg0KIGlzLjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5b TWVkXSBUaGUgcG9pbnQgaXMgdGhhdCB5b3VyIHRleHQgc2F5cyDigJxUaGUgZm9sbG93aW5nIFVE UCBvcHRpb25zIGFyZSBjdXJyZW50bHkg4oCm4oCcLiBPYnZpb3VzbHksIOKAnFJFU0VSVkVE4oCd IGlzIG5vdCBhbiBvcHRpb24uDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5n PSJFTi1VUyI+LSBBQ1MgYW5kIEFFIGFyZSBkZWZpbmVkIGFzIHRoZSBvbmx5IG9wdGlvbnMgdGhh dCBkZXBlbmQgb24gdGhlIGNvbnRlbnRzIG9mIHRoZSBvcHRpb24gYXJlIGZvciBhIHJlYXNvbi4g VGhhdCdzIHRoZSBzaW1wbGVzdCB3YXkgdG8gaGFuZGxlIHRoZSBjaXJjdWxhcml0eSB0aGF0IHdv dWxkIG90aGVyd2lzZSBhcmlzZS4gRS5nLiwgaWYgQUNTIGNvdmVyZWQgdGhlIGNvbnRlbnRzIG9m IEFFLCB0aGVuIEFDPC9zcGFuPlMNCiBtdXN0IGJlIHByb2Nlc3NlZCBsYXN0LiBCdXQgaWYgQUUg Y292ZXJlZCB0aGUgY29udGVudHMgb2YgQUNTLCB0aGUgQUUgbXVzdCBiZSBwcm9jZXNzZWQgbGFz dC4gUmlnaHQgbm93LCB3ZSBkZWZpbmUgdGhhdCBBRSBjb3ZlcnMgZXZlcnl0aGluZyBFWENFUFQg T05MWSB0aGUgY29udGVudHMgb2YgQUNTIGFuZCB0aGF0IEFDUyBjb3ZlcnMgZXZlcnl0aGluZy4g QnV0IHdlIGNhbiBuZXZlciBrbm93IGhvdyBBQ1MgYW5kIEFFIHdvdWxkIG5lZWQgdG8NCiBoYW5k bGUgb3B0aW9ucyB0aGF0IGFyZW4ndCB5ZXQgZGVmaW5lZCAtIGlmIHRoZXkgYWxzbyBkZXBlbmQg b24gdGhlIGNvbnRlbnRzIG9mIHRoZSBvcHRpb24gYXJlYSwgd2UgY2FuIGVuZCB1cCB3aXRoIGEg Y2lyY3VsYXJpdHkgYWdhaW4uIEknbSBvcGVuIHRvIG90aGVyIHNvbHV0aW9ucyB0byB0aGlzIGlz c3VlLCBidXQgbm90IHN1cmUgd2Ugd2FudCB0byBidXJuIGJpdHMgaW4gdGhlIG9wdGlvbiBoZWFk ZXIgdG8gaW5kaWNhdGUgd2hpY2ggb3B0aW9ucw0KIGhhdmUgJnF1b3Q7ZGVwZW5kZW50IGNvbnRl bnRzIHRoYXQgbmVlZCB0byBiZSB6ZXJvZWQgZm9yIGluY2x1c2lvbiBpbiBvdGhlciBvcHRpb25z JnF1b3Q7IC0gYmVzaWRlcywgdGhhdCBzZXRzIHVzIHVwIGZvciBjb3ZlcnQgY2hhbm5lbHMgdGhh dCBBRSBtaWdodCBiZSB1c2VkIHRvIHByZXZlbnQuIEkuZS4sIHRoZXJlJ3Mgbm8gd2F5IHRvIGxl YXZlIHRoaXMgYXMgYSBkZWNpc2lvbiBmb3IgZnV0dXJlIG9wdGlvbnMgd2l0aG91dCBjcmVhdGlu ZyBhIHRhbmdsZWQNCiBtZXNzIG9mICZxdW90O0kgY29tZSBmaXJzdCZxdW90OyBkZWNsYXJhdGlv bnMsIHN1Y2ggYXMgd2UgaGF2ZSBhbHJlYWR5IGZvciBUQ1Agb3B0aW9ucy48bzpwPjwvbzpwPjwv cD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+W01lZF0gSSBoZWFyIHlvdSwgYnV0IEkgc3Rp bGwgZG9u4oCZdCBnZXQgdGhpczogJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbi1sZWZ0OjUuMjVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5GdXR1cmUgb3B0 aW9ucyBNVVNUIE5PVCBiZSBkZWZpbmVkIGFzIGhhdmluZyBhIHZhbHVlIGluZGVwZW5kZW50IG9m IHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7IGNvbnRlbnRzIG9mIHRoZSBvcHRpb24gYXJlYTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj4tIHRoZSBGUkFHIG9wdGlvbiBpcyBvbmUgb2YgdGhl IG1vc3QgaW1wb3J0YW50IGFuZCBhIHJlcXVpcmVkIG9wdGlvbiAoaS5lLiwgaWYgVURQIG9wdGlv bnMgYXJlIHN1cHBvcnRlZCwgRlJBRyBtdXN0IGJlIHN1cHBvcnRlZCksIHdoaWNoIGlzIHdoeSBp dCBuZWVkcyB0byByZW1haW4gaW4gdGhpcyBkb2MuDQo8L3NwYW4+V2hldGhlciBmcmFnbWVudHMg YXJlIGRlbGl2ZXJlZCB0byB0aGUgdXNlciB3aGVuIFVEUCBvcHRpb25zIGFyZSBub3Qgc3VwcG9y dGVkIGRlcGVuZHMgb24gaG93IHRoZSBGUkFHIG9wdGlvbiBpcyB1c2VkIC0gaWYgdXNlZCB3aXRo b3V0IExJVEUsIHRoZSBmcmFnbWVudHMgd291bGQgYmUgZGVsaXZlcmVkLCBidXQgaWYgdXNlZCB3 aXRoIExJVEUgdGhleSB3b3VsZCBub3QgYmUuIFRoYXQncyB3aHkgd2UgbGVmdCBib3RoIHZhcmlh bnRzDQogYXZhaWxhYmxlLjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij5bTWVkXSBJTUhPLCB0aGlzIG9uZSBuZWVkIG1vcmUgZXZhbHVhdGlvbi92YWxpZGF0aW9uIGJl Zm9yZSBiZWluZyBpbmNsdWRlZCBpbiBhIHN0YW5kYXJkIHRyYWNrIGRvY3VtZW50LiBJIGNhbiBs aXZlIHdpdGggaXQgaW4gYW4gZXhwZXJpbWVudGFsIFJGQy4gQWN0dWFsbHksIG15IHByb3Bvc2Fs IGlzIHRvIHNjb3BlIHRoZQ0KIHVkcC1vcHRpb25zIGRvY3VtZW50IHRvIHRoZSBiYXNlIG1lY2hh bmlzbSBhbmQgcmVxdWlyZWQgb3B0aW9ucy4gT3B0aW9ucyB0aGF0IHJlcXVpcmUgbW9yZSBleHBl cmltZW50cyBhcmUgZWFzeSB0byBiZSBwcm9ncmVzc2VkIGluIGRlZGljYXRlZCBkb2N1bWVudHMu IFRoaXMgYXBwcm9hY2ggd2lsbCBhbGxvdyB1cyB0byBmaW5hbGl6ZSBxdWlja2x5IHRoZSBiYXNl IHVkcC1vcHRpb25zLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVT Ij4tIHRoZSBleHRlbnNpb24gdG8gdGhlIFVEUCBBUEkgbmVlZHMgdG8gYmUgaW4gdGhlIGNvcmUg b2YgdGhlIGRvYyBiZWNhdXNlIHRoZSBBUEkgaXMgYSBrZXkgcGFydCBvZiB0aGlzIChhbmQgYW55 KSBwcm90b2NvbC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPltNZWRdIEpvZSwgd2UgZG8gYWxsIGFncmVlIHRoYXQgQVBJIGFyZSBpbXBvcnRhbnQuIEFs bW9zdCBhbGwgQVBJcyBkZWZpbmVkIGluIElFVEYgSeKAmW0gYXdhcmUgb2YgYXJlIGRlZmluZWQg YXMgSW5mb3JtYXRpb25hbCBSRkNzIChJIGNhbiBwcm92aWRlIGFuIGV4aGF1c3RpdmUgbGlzdCwg aWYgbmVlZGVkKS4gVGhpcyBpcw0KIHdoeSBJIHN1Z2dlc3RlZCB0aGF0IHlvdSBtb3ZlIHRoaXMg c2VjdGlvbiBpbnRvIGFuIGFwcGVuZGl4LiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD4tIGFz IHRvIHRoZSBvdGhlciBzZWN0aW9ucyB5b3Ugc3VnZ2VzdCBtb3ZpbmcgdG8gYW4gYXBwZW5kaXgs IEknbGwgd2FpdCBmb3Igb3RoZXIgZmVlZGJhY2sgb24gdGhhdCBwb2ludC4gSSdtIG5vdCBmb25k IG9mIGFwcGVuZGljZXMgZXhjZXB0IGZvciBjb2RlIGV4YW1wbGVzIG9yIHRydWx5IG9wdGlvbmFs IG1hdGVyaWFsOyB0aGUgb3RoZXIgcG9pbnRzIHlvdSdyZSBzdWdnZXN0aW5nIHRvIG1vdmUgKG90 aGVyIHRoYW4gVURQIEFQSSwgYWRkcmVzc2VkDQogYWJvdmUpLCBlLmcuLCBzZWN0aW9ucyBkb24n dCBoYXZlIHRoYXQgcHJvcGVydHkgKHNlYyA3IG9uIHdob3NlIG9wdGlvbnMgYXJlIHRoZXNlIGFu ZCBzZWMgOCBvbiBMSVRFIHZzIFVEUCBMaXRlKS48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+W01lZF0gVGhvc2Ugc2VjdGlvbnMgYXJlIG5vdCBub3JtYXRpdmUgJiM0 Mzsgc29tZSBvZiB0aGUgY29udGVudCBpcyByZWR1bmRhbnQgKFNlYy4gNyBhbmQgU2VjIDgpIHdp dGggb3RoZXIgc3RhdGVtZW50cyBlYXJsaWVyIGluIHRoZSBkb2N1bWVudC4gVGhlc2Ugc2VjdGlv bnMgZG8gbm90IGJyaW5nIG5ldyBlbGVtZW50cyB0bw0KIHRoZSBkaXNjdXNzaW9uLiAmbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cD4tIFNlYyAxMSBoYXMgYSB0eXBvOyBpdCdzIHJlYWxs eSB0d28gc2VjdGlvbnMuPG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PltNZWRdIE9LLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5U aGUgcGFydCBhYm91dCB0aGUgY2hhbmdlcyB0byA3Njggc2hvdWxkIGJlIGl0cyBvd24gc2VjdGlv bjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+W01lZF0g V2UgZG9u4oCZdCBuZWVkIGEgc2VjdGlvbiBmb3IgdGhpcy4gVGhpcyB0ZXh0IGNhbiBiZSBpbnNl cnRlZCBpbiB0aGUgSW50cm9kdWN0aW9uLiAmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cD48c3BhbiBsYW5nPSJFTi1VUyI+LiBJJ3ZlIGxlZnQgdGhhdCBpbiByaWdodCBub3cgYmVjYXVz ZSBVRFAgb3B0aW9uICZxdW90O25lZ290aWF0aW9uJnF1b3Q7IGlzIGFscmVhZHkgYSBzb2Z0LXN0 YXRlIHBlcnNpc3RlbmM8L3NwYW4+ZSBtZWNoYW5pc20gc2ltaWxhciB0byBUQ1AgY29udHJvbCBi bG9jayBzaGFyaW5nLjxvOnA+PC9vOnA+PC9wPg0KPHA+LSBJIGRvbid0IHF1aXRlIHVuZGVyc3Rh bmQgeW91ciBjb21tZW50OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ VURQIG9wdGlvbnMgY2FuIGJlIHVzZWQgYSBjb3ZlciBjaGFubmVscy4gSW5zcGVjdGluZyB0aG9z ZSBvcHRpb25zIG1heSBiZSByZXF1aXJlZCB0byBwcm90ZWN0IHNvbWUgbmV0d29ya3MuDQo8bzpw PjwvbzpwPjwvcD4NCjxwPkkgdGhpbmsgeW91IG1lYW4gJnF1b3Q7dXNlZCBhcyBhIGNvdmVydCBj aGFubmVsJnF1b3Q7LDxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5b TWVkXSBZZXMuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7YnV0IHRoYXQncyB0cnVlIGZvciBuZWFybHkgZXZlcnkgZmllbGQgaW4gYW55IGhlYWRl ci48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPltNZWRd IFllcywgYnV0IHRoaXMgaXMgZXhhY2VyYmF0ZWQgd2hlbiB0aGVyZSBpcyBubyBzcGVjaWZpY2F0 aW9uIGFib3V0IHRoZSBoYW5kbGluZyBvZiB0aGUgc3VycGx1cyBhcmVhLiBJdCBpcyBsZWdpdGlt YXRlIHRoYXQgbmV0d29yayBhZG1pbmlzdHJhdG9ycyB3b3VsZCBzdXNwZWN0cyB0aG9zZSBwYWNr ZXRzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGRpc2Fn cmVlIHRoYXQgaW5zcGVjdGlvbiBtYXkgYmUgcmVxdWlyZWQgdG8gcHJvdGVjdCBhIG5ldHdvcms8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPltNZWRdIFNv bWUgaW5zcGVjdGlvbiBtYXkgYmUgbmVlZGVkIHRvIGRldGVjdC9wcm90ZWN0IGFnYWluc3QgYSB2 YXJpZXR5IG9mIGF0dGFja3MgYW5kIHRvIHByb3RlY3QgbmV0d29ya3MuIEZpcmV3YWxscyBhcmUg dGhlIG5vcm0gaW4gZW50ZXJwcmlzZSBuZXR3b3JrcywgZm9yIGV4YW1wbGUuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPi0gdGhlc2UgYXJlIHRyYW5zcG9ydCB2 YWx1ZXMgaW4gdGhlIHRyYW5zcG9ydCBwYXlsb2FkIG9mIGEgbmV0d29yayBwYWNrZXQuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5bTWVkXSBUaGlzIGRv Y3VtZW50IGRlZmluZXMgdGhlbSBhcyB0cmFuc3BvcnQgdmFsdWVzLCBidXQgbGVnYWN5IGRldmlj ZXMgY2Fubm90IGhhbmRsZSB0aGVtIGFzIHRyYW5zcG9ydCB2YWx1ZXMuICZuYnNwOyZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDtCeSB5b3Vy IGxvZ2ljLCB0aGUgZW50aXJlIHRyYW5zcG9ydCBjb250ZW50cyBhcmUgcG90ZW50aWFsbHkgYSBj b3ZlcnQgY2hhbm5lbCwgYW5kIHdlIGhhdmUgbm8gcmVjb21tZW5kYXRpb24gZWxzZXdoZXJlIHRv IHJlcXVpcmUgRFBJIHRvIHByb3RlY3QgYSAqbmV0d29yayogKHZzLiB0aGUgZW5kcG9pbnRzLCB3 aGljaCBvZiBjb3Vyc2UgY291bGQgcmVxdWlyZSBjaGVja2luZyBhbnkgcGFydCBvZiBhIG1lc3Nh Z2UpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+W01l ZF0gSSBkb27igJl0IHVuZGVyc3RhbmQgdGhlIHJlZmVyZW5jZSB0byBEUEkuIEkgdGhpbmsgeW91 IHVuZGVyc3Rvb2Qg4oCcaW5zcGVjdGlvbuKAnSBhcyBpZiBJ4oCZbSBhc2tpbmcgZm9yIOKAnERQ SeKAnS4gUGxlYXNlIHNlZSBhYm92ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD4tIGFzIHRv IHdoaWNoIHJlZnMgYXJlIG5vcm1hdGl2ZSwgQUZBSUNUIG9ubHkgUkZDNzY4Jm5ic3A7IGFuZCAy NDYwIHdvdWxkIGJlPG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPltN ZWRdIFBsZWFzZSBmaXggdGhvc2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFu Zz0iRU4tVVMiPiwgYW5kICptYXliZSogMTEyMiAoZS5nLiwgYnkgZXh0ZW5kaW5nIHRoZSBleHRl bnQgb2YgdGhlIFVEUCBBUEkpLg0KPC9zcGFuPk5vdGhpbmcgaW4gdGhpcyBkb2MgcmVsaWVzIG9u IHRoZSBzdGFuZGFyZHMgbmF0dXJlIG9mIG90aGVyIGRvY3VtZW50cyBBRkFJQ1QuIE15ICZxdW90 O2FjaWQgdGVzdCZxdW90OyBmb3Igd2hldGhlciB0byBpbmNsdWRlIHNvbWV0aGluZyBhcyBub3Jt YXRpdmUgaXMgJnF1b3Q7d291bGQgbXkgZG9jIG5lZWQgdG8gY2hhbmdlIGlmIHRoZSBvdGhlciBS RkMgY2hhbmdlZCZxdW90Oz8gQUZBSUNULCB0aGF0J3Mgbm90IHRydWUgZm9yIDc2OCwgYnV0IEkn ZCBsaWtlIHRvIGhlYXINCiB3aGF0IG90aGVycyB0aGluayBvZiB0aGF0IHNldCBiZWZvcmUgbW92 aW5nIHRoZW0uIDxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5bTWVk XSBGb3Igb3RoZXIgUkZDcyB5b3UgZGlkbuKAmXQgY2l0ZSwgbXkgcmF0aW9uYWxlIGZvciBpbmNs dWRpbmcgdGhlbSBhcyBub3JtYXRpdmUgaXMgYXMgZm9sbG93czoNCjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDtt c28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+NzkzJm5ic3A7OiBNU1MgYW5k IG90aGVyIGZlYXR1cmVzIGFyZSBjbG9uZWQgZnJvbSB0aGF0IGRvY3VtZW50Ljwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7dGV4dC1pbmRlbnQ6LTE4 LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+NTkyNTogdGhlIHVk cCBvcHRpb24gY2xvbmVzIHRoZSBUQ1Agb3B0aW9uLiBBbiBpbXBsZW1lbnRlciBuZWVkIHRvIHJl ZmVyIHRvIHRoaXMgZG9jdW1lbnQgdG8gaGF2ZSBhbiBpZGVhIGFib3V0IHRoZSBmb3JtYXQ6IOKA nEl0IHVzZXMgdGhlIHNhbWUgZm9ybWF0IGFzIHNwZWNpZmllZA0KIGZvciBUQ1AtQU8sIGV4Y2Vw dCB0aGF0IGl0IHVzZXMgYSBLaW5kIG9mIDgu4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0Omww IGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij42OTk0OiBFeElEcyBhcmUgZGVmaW5lZCBpbiB0 aGlzIFJGQy4gQW4gaW1wbGVtZW50ZXIgbmVlZCB0byByZWFkIHRoaXMgUkZDIHRvIHVuZGVyc3Rh bmQvaW1wbGVtZW50IGhvdyB0aGUgc2hhcmVkIGV4cGVyaW1lbnQgSURzIHdvcmsuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHA+Sm9lPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA2 LzI4LzIwMTcgMTI6NDkgQU0sIDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tIj4NCm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+SGkgSm9lLCA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5QbGVhc2UgZmluZCBhdHRhY2hlZCBhbiBpbml0 aWFsIHJldmlldyBvZiB0aGlzIHZlcnNpb24gb2YgdGhlIGRvY3VtZW50IChib3RoIGRvYyBhbmQg cGRmIGZpbGVzIGFyZSBhdHRhY2hlZCkuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPkNoZWVycyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5NZWQ8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPi0t LS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkRlJm5ic3A7 OiB0c3Z3ZyBbPGEgaHJlZj0ibWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzp0 c3Z3Zy1ib3VuY2VzQGlldGYub3JnPC9hPl0gRGUgbGEgcGFydCBkZSBKb2UgVG91Y2g8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5FbnZvecOpJm5ic3A7OiBtYXJkaSAyNyBqdWluIDIwMTcgMjI6NTg8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT7DgCZuYnNwOzogPGEgaHJlZj0ibWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPjsgPGEgaHJlZj0i bWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZyI+aS1kLWFubm91bmNlQGlldGYub3JnPC9hPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPkNjJm5ic3A7OiA8YSBocmVmPSJtYWlsdG86dHN2d2dAaWV0 Zi5vcmciPnRzdndnQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9iamV0Jm5i c3A7OiBSZTogW3RzdndnXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXRzdndnLXVkcC1vcHRpb25z LTAxLnR4dDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPkhpLCBhbGwsPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3By ZT4NCjxwcmU+VGhpcyB1cGRhdGUgYWRkcyBzb21lIGNsYXJpZmljYXRpb24gb24gaG93IHRvIGhh bmRsZSBvcHRpb25zIHdob3NlPG86cD48L286cD48L3ByZT4NCjxwcmU+dmFsdWVzIGRlcGVuZCBv biBvdGhlciBvcHRpb25zIChlLmcuLCBBQ1MgYW5kIEFFKS48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Kb2U8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5PbiA2LzI3LzIwMTcgMTo1MiBQTSwgPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiB3cm90ZTo8bzpwPjwvbzpw PjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cHJlPkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRo ZSBvbi1saW5lIEludGVybmV0LURyYWZ0czxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+ DQo8cHJlPmRpcmVjdG9yaWVzLjxvOnA+PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+VGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgVHJhbnNwb3J0IEFyZWEgV29ya2luZyBHcm91cCBvZiB0aGU8 bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5JRVRGLjxvOnA+PC9vOnA+PC9w cmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRpdGxlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogVHJhbnNwb3J0IE9wdGlvbnMg Zm9yIFVEUDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBBdXRob3ImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBKb2UgVG91Y2g8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsmbmJzcDsgRmlsZW5hbWUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgOiBkcmFmdC1pZXRmLXRzdndnLXVkcC1vcHRpb25zLTAxLnR4dDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyBQYWdlcyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IDI3PG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7IERhdGUmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiAyMDE3LTA2 LTI3PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+ QWJzdHJhY3Q6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRyYW5zcG9ydCBw cm90b2NvbHMgYXJlIGV4dGVuZGVkIHRocm91Z2ggdGhlIHVzZSBvZiB0cmFuc3BvcnQgaGVhZGVy PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IG9wdGlvbnMuIFRoaXMgZG9jdW1l bnQgZXhwZXJpbWVudGFsbHkgZXh0ZW5kcyBVRFAgYnkgaW5kaWNhdGluZyB0aGU8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgbG9jYXRpb24sIHN5bnRheCwgYW5kIHNlbWFudGlj cyBmb3IgVURQIHRyYW5zcG9ydCBsYXllciBvcHRpb25zLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPlRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtdHN2d2ctdWRwLW9wdGlvbnMvIj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRzdndnLXVkcC1vcHRpb25zLzwvYT48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGVyZSBhcmUgYWxz byBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6PG86cD48L286cD48L3ByZT4NCjxwcmU+ PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHN2d2ctdWRw LW9wdGlvbnMtMDEiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRzdndn LXVkcC1vcHRpb25zLTAxPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi10c3Z3Zy11ZHAtb3B0 aW9ucy0wMSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRm LXRzdndnLXVkcC1vcHRpb25zLTAxPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlz IGF2YWlsYWJsZSBhdDo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi10c3Z3Zy11ZHAtb3B0aW9ucy0wMSI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdHN2d2ctdWRwLW9w dGlvbnMtMDE8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+UGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Y8bzpwPjwvbzpw PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5zdWJtaXNzaW9uPG86cD48L286cD48L3ByZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHByZT51bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0IHRvb2xzLmlldGYub3JnLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5v bnltb3VzIEZUUCBhdDo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJmdHA6Ly9mdHAu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLyI+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy88L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B93300A086FD6OPEXCLILMA3corp_-- From nobody Wed Dec 6 06:28: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 9D006126DD9; Wed, 6 Dec 2017 06:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aluXoCDWPHqo; Wed, 6 Dec 2017 06:28:45 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65ACD12714F; Wed, 6 Dec 2017 06:28:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; 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=3vxr7/JbI8lw+FqhwlCpAu8lM/ZwYYn27rQj44hoOjg=; b=Azdjtyo7fPbST006FnpbP4CH3 bJG505shXFnH/7/qIZFe0oehcXcqUt3N3U592QaBGDBQUI1/0Mcx5yxkPmlv49rmQTulS6uhBdUWg JjRoxt6EE0OIzDOZAyQx0wKrFDGnupoUyk81g71A9cv8fBYTZlP7ch+uvK4kv8+TSzky+ZyVma8qm Q5qvkU79XJ9iHQXzAT/pMZqZindm4WPI88JYEQ9qAkEDV3pAPuxj/lna8yXFmfIGbCnFCBwAh/vlZ +jzTyspg6T75yoGRGATkpmo8iIJF5/tDPVgJ82yffPR/goqgG8y+4oGKDtZpdBX6o0jwhmBwlwsUG p8g67lPMw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:59242 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eMagk-001Psq-5J; Wed, 06 Dec 2017 09:28:43 -0500 To: mohamed.boucadair@orange.com, Joe Touch Cc: "tsvwg-chairs@ietf.org" , "tsvwg@ietf.org" References: <149859676199.31073.16978555797843649491@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933009FFCD60@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00834e85-2bc6-0df9-2afa-01056534d7c4@isi.edu> <787AE7BB302AE849A7480A190F8B933009FFDAA8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A086FD6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: <964348b4-2eec-41ec-7888-27a5b3d00c4b@strayalpha.com> Date: Wed, 6 Dec 2017 06:28:39 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A086FD6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------75601050344A703F95F84842" Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-01.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, 06 Dec 2017 14:28:49 -0000 This is a multi-part message in MIME format. --------------75601050344A703F95F84842 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi, Med, I have not yet updated that draft. I also intended to post your comments to the group for discussion. Both are on my pending items list... Joe On 12/6/2017 5:48 AM, mohamed.boucadair@orange.com wrote: > > Hi Joe, > >   > > Unless I’m mistaken I didn’t see any update of the draft to address > some of the comments raised in my review. > >   > > FWIW, a copy of my comments are available at: > https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-tsvwg-udp-options-01-rev%20Med.pdf > >   > > Cheers, > > Med > >   > > *De :*Joe Touch [mailto:touch@isi.edu] > *Envoyé :* mardi 4 juillet 2017 23:27 > *À :* BOUCADAIR Mohamed IMT/OLN > *Cc :* tsvwg-chairs@ietf.org > *Objet :* Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-01.txt > >   > > Will do, but note that I'm on vacation now through July 16. I'll post > this and pick the thread up when I return. > > Joe > >   > > On 6/30/2017 5:25 AM, mohamed.boucadair@orange.com > wrote: > > Hi Joe, > >   > > The discussion can be on-list. > >   > > Please feel free to forward the initial review and this one to the > list. > >   > > Thank you. > >   > > Cheers, > > Med > >   > > *De :*Joe Touch [mailto:touch@isi.edu] > *Envoyé :* jeudi 29 juin 2017 15:58 > *À :* BOUCADAIR Mohamed IMT/OLN > *Cc :* tsvwg-chairs@ietf.org > *Objet :* Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-01.txt > >   > > Hi, Med, > > First, is there a reason we're discussing this off-list? This > thread really should be on-list - I can forward these messages and > we can continue there if it's OK. > > Joe > >   > > On 6/28/2017 11:52 PM, mohamed.boucadair@orange.com > wrote: > > Hi Joe, > >   > > Thank you for the answers. > >   > > Please see inline. > >   > > Cheers, > > Med > >   > > *De :*Joe Touch [mailto:touch@isi.edu] > *Envoyé :* mercredi 28 juin 2017 20:28 > *À :* BOUCADAIR Mohamed IMT/OLN > *Cc :* tsvwg-chairs@ietf.org > *Objet :* Re: [tsvwg] I-D Action: > draft-ietf-tsvwg-udp-options-01.txt > >   > > Hi, Mohammed, > > Thanks for the detailed comments - most of the editorial > suggestions and requests for clarification will be addressed > in the next update, except as noted below. For future > reference, I would be glad to provide the Word source if > that's easier for feedback. > > [Med] Ok, thanks. I can review any updated version you will > prepare. > > Some comments: > > - as to whether the list of options should complete; I'll let > the RFC Editor and/or IANA decide whether to remove the > RESERVED entries or the explicit indication of the IANA > assignable region; I'm not sure what their convention is. > > [Med] The point is that your text says “The following UDP > options are currently …“. Obviously, “RESERVED” is not an option. > > - ACS and AE are defined as the only options that depend on > the contents of the option are for a reason. That's the > simplest way to handle the circularity that would otherwise > arise. E.g., if ACS covered the contents of AE, then ACS must > be processed last. But if AE covered the contents of ACS, the > AE must be processed last. Right now, we define that AE covers > everything EXCEPT ONLY the contents of ACS and that ACS covers > everything. But we can never know how ACS and AE would need to > handle options that aren't yet defined - if they also depend > on the contents of the option area, we can end up with a > circularity again. I'm open to other solutions to this issue, > but not sure we want to burn bits in the option header to > indicate which options have "dependent contents that need to > be zeroed for inclusion in other options" - besides, that sets > us up for covert channels that AE might be used to prevent. > I.e., there's no way to leave this as a decision for future > options without creating a tangled mess of "I come first" > declarations, such as we have already for TCP options. > > [Med] I hear you, but I still don’t get this:   > > Future options MUST NOT be defined as having a value > independent of the > >    contents of the option area > > - the FRAG option is one of the most important and a required > option (i.e., if UDP options are supported, FRAG must be > supported), which is why it needs to remain in this doc. > Whether fragments are delivered to the user when UDP options > are not supported depends on how the FRAG option is used - if > used without LITE, the fragments would be delivered, but if > used with LITE they would not be. That's why we left both > variants available. > > [Med] IMHO, this one need more evaluation/validation before > being included in a standard track document. I can live with > it in an experimental RFC. Actually, my proposal is to scope > the udp-options document to the base mechanism and required > options. Options that require more experiments are easy to be > progressed in dedicated documents. This approach will allow us > to finalize quickly the base udp-options. > > - the extension to the UDP API needs to be in the core of the > doc because the API is a key part of this (and any) protocol. > > [Med] Joe, we do all agree that API are important. Almost all > APIs defined in IETF I’m aware of are defined as Informational > RFCs (I can provide an exhaustive list, if needed). This is > why I suggested that you move this section into an appendix. > > - as to the other sections you suggest moving to an appendix, > I'll wait for other feedback on that point. I'm not fond of > appendices except for code examples or truly optional > material; the other points you're suggesting to move (other > than UDP API, addressed above), e.g., sections don't have that > property (sec 7 on whose options are these and sec 8 on LITE > vs UDP Lite). > > [Med] Those sections are not normative + some of the content > is redundant (Sec. 7 and Sec 8) with other statements earlier > in the document. These sections do not bring new elements to > the discussion.   > > - Sec 11 has a typo; it's really two sections. > > [Med] OK. > > The part about the changes to 768 should be its own section > > [Med] We don’t need a section for this. This text can be > inserted in the Introduction.   > > . I've left that in right now because UDP option "negotiation" > is already a soft-state persistence mechanism similar to TCP > control block sharing. > > - I don't quite understand your comment: > > UDP options can be used a cover channels. Inspecting those > options may be required to protect some networks. > > I think you mean "used as a covert channel", > > [Med] Yes. > >  but that's true for nearly every field in any header. > > [Med] Yes, but this is exacerbated when there is no > specification about the handling of the surplus area. It is > legitimate that network administrators would suspects those > packets. > > I disagree that inspection may be required to protect a network > > [Med] Some inspection may be needed to detect/protect against > a variety of attacks and to protect networks. Firewalls are > the norm in enterprise networks, for example. > > - these are transport values in the transport payload of a > network packet. > > [Med] This document defines them as transport values, but > legacy devices cannot handle them as transport values.    > >  By your logic, the entire transport contents are potentially > a covert channel, and we have no recommendation elsewhere to > require DPI to protect a *network* (vs. the endpoints, which > of course could require checking any part of a message). > > [Med] I don’t understand the reference to DPI. I think you > understood “inspection” as if I’m asking for “DPI”. Please see > above. > > - as to which refs are normative, AFAICT only RFC768  and 2460 > would be > > [Med] Please fix those. > > , and *maybe* 1122 (e.g., by extending the extent of the UDP > API). Nothing in this doc relies on the standards nature of > other documents AFAICT. My "acid test" for whether to include > something as normative is "would my doc need to change if the > other RFC changed"? AFAICT, that's not true for 768, but I'd > like to hear what others think of that set before moving them. > > [Med] For other RFCs you didn’t cite, my rationale for > including them as normative is as follows: > > ·         793 : MSS and other features are cloned from that > document. > > ·         5925: the udp option clones the TCP option. An > implementer need to refer to this document to have an idea > about the format: “It uses the same format as specified for > TCP-AO, except that it uses a Kind of 8.” > > ·         6994: ExIDs are defined in this RFC. An implementer > need to read this RFC to understand/implement how the shared > experiment IDs work. > > Joe > >   > > On 6/28/2017 12:49 AM, mohamed.boucadair@orange.com > wrote: > > Hi Joe, > >   > > Please find attached an initial review of this version of the document (both doc and pdf files are attached). > >   > > Cheers, > > Med > >   > > -----Message d'origine----- > > De : tsvwg [mailto:tsvwg-bounces@ietf.org] De la part de Joe Touch > > Envoyé : mardi 27 juin 2017 22:58 > > À : internet-drafts@ietf.org ; i-d-announce@ietf.org > > Cc : tsvwg@ietf.org > > Objet : Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-01.txt > >   > > Hi, all, > >   > > This update adds some clarification on how to handle options whose > > values depend on other options (e.g., ACS and AE). > >   > > Joe > >   > >   > > On 6/27/2017 1:52 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Transport Area Working Group of the > > IETF. > >   > >         Title           : Transport Options for UDP > >         Author          : Joe Touch > >     Filename        : draft-ietf-tsvwg-udp-options-01.txt > >     Pages           : 27 > >     Date            : 2017-06-27 > >   > > Abstract: > >    Transport protocols are extended through the use of transport header > >    options. This document experimentally extends UDP by indicating the > >    location, syntax, and semantics for UDP transport layer options. > >   > >   > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ > >   > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-01 > > https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-01 > >   > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-udp-options-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/ > >   > >   > >   > >   > --------------75601050344A703F95F84842 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi, Med,

I have not yet updated that draft. I also intended to post your comments to the group for discussion. Both are on my pending items list...

Joe


On 12/6/2017 5:48 AM, mohamed.boucadair@orange.com wrote:

Hi Joe,

 

Unless I’m mistaken I didn’t see any update of the draft to address some of the comments raised in my review.

 

FWIW, a copy of my comments are available at: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-tsvwg-udp-options-01-rev%20Med.pdf

 

Cheers,

Med

 

De : Joe Touch [mailto:touch@isi.edu]
Envoyé : mardi 4 juillet 2017 23:27
À : BOUCADAIR Mohamed IMT/OLN
Cc : tsvwg-chairs@ietf.org
Objet : Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-01.txt

 

Will do, but note that I'm on vacation now through July 16. I'll post this and pick the thread up when I return.

Joe

 

On 6/30/2017 5:25 AM, mohamed.boucadair@orange.com wrote:

Hi Joe,

 

The discussion can be on-list.

 

Please feel free to forward the initial review and this one to the list.

 

Thank you.

 

Cheers,

Med

 

De : Joe Touch [mailto:touch@isi.edu]
Envoyé : jeudi 29 juin 2017 15:58
À : BOUCADAIR Mohamed IMT/OLN
Cc : tsvwg-chairs@ietf.org
Objet : Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-01.txt

 

Hi, Med,

First, is there a reason we're discussing this off-list? This thread really should be on-list - I can forward these messages and we can continue there if it's OK.

Joe

 

On 6/28/2017 11:52 PM, mohamed.boucadair@orange.com wrote:

Hi Joe,

 

Thank you for the answers.

 

Please see inline.

 

Cheers,

Med

 

De : Joe Touch [mailto:touch@isi.edu]
Envoyé : mercredi 28 juin 2017 20:28
À : BOUCADAIR Mohamed IMT/OLN
Cc : tsvwg-chairs@ietf.org
Objet : Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-01.txt

 

Hi, Mohammed,

Thanks for the detailed comments - most of the editorial suggestions and requests for clarification will be addressed in the next update, except as noted below. For future reference, I would be glad to provide the Word source if that's easier for feedback.

[Med] Ok, thanks. I can review any updated version you will prepare.

Some comments:

- as to whether the list of options should complete; I'll let the RFC Editor and/or IANA decide whether to remove the RESERVED entries or the explicit indication of the IANA assignable region; I'm not sure what their convention is.

[Med] The point is that your text says “The following UDP options are currently …“. Obviously, “RESERVED” is not an option.

- ACS and AE are defined as the only options that depend on the contents of the option are for a reason. That's the simplest way to handle the circularity that would otherwise arise. E.g., if ACS covered the contents of AE, then ACS must be processed last. But if AE covered the contents of ACS, the AE must be processed last. Right now, we define that AE covers everything EXCEPT ONLY the contents of ACS and that ACS covers everything. But we can never know how ACS and AE would need to handle options that aren't yet defined - if they also depend on the contents of the option area, we can end up with a circularity again. I'm open to other solutions to this issue, but not sure we want to burn bits in the option header to indicate which options have "dependent contents that need to be zeroed for inclusion in other options" - besides, that sets us up for covert channels that AE might be used to prevent. I.e., there's no way to leave this as a decision for future options without creating a tangled mess of "I come first" declarations, such as we have already for TCP options.

[Med] I hear you, but I still don’t get this:  

Future options MUST NOT be defined as having a value independent of the

   contents of the option area

- the FRAG option is one of the most important and a required option (i.e., if UDP options are supported, FRAG must be supported), which is why it needs to remain in this doc. Whether fragments are delivered to the user when UDP options are not supported depends on how the FRAG option is used - if used without LITE, the fragments would be delivered, but if used with LITE they would not be. That's why we left both variants available.

[Med] IMHO, this one need more evaluation/validation before being included in a standard track document. I can live with it in an experimental RFC. Actually, my proposal is to scope the udp-options document to the base mechanism and required options. Options that require more experiments are easy to be progressed in dedicated documents. This approach will allow us to finalize quickly the base udp-options.

- the extension to the UDP API needs to be in the core of the doc because the API is a key part of this (and any) protocol.

[Med] Joe, we do all agree that API are important. Almost all APIs defined in IETF I’m aware of are defined as Informational RFCs (I can provide an exhaustive list, if needed). This is why I suggested that you move this section into an appendix.

- as to the other sections you suggest moving to an appendix, I'll wait for other feedback on that point. I'm not fond of appendices except for code examples or truly optional material; the other points you're suggesting to move (other than UDP API, addressed above), e.g., sections don't have that property (sec 7 on whose options are these and sec 8 on LITE vs UDP Lite).

[Med] Those sections are not normative + some of the content is redundant (Sec. 7 and Sec 8) with other statements earlier in the document. These sections do not bring new elements to the discussion.  

- Sec 11 has a typo; it's really two sections.

[Med] OK.

The part about the changes to 768 should be its own section

[Med] We don’t need a section for this. This text can be inserted in the Introduction.  

. I've left that in right now because UDP option "negotiation" is already a soft-state persistence mechanism similar to TCP control block sharing.

- I don't quite understand your comment:

UDP options can be used a cover channels. Inspecting those options may be required to protect some networks.

I think you mean "used as a covert channel",

[Med] Yes.

 but that's true for nearly every field in any header.

[Med] Yes, but this is exacerbated when there is no specification about the handling of the surplus area. It is legitimate that network administrators would suspects those packets.

I disagree that inspection may be required to protect a network

[Med] Some inspection may be needed to detect/protect against a variety of attacks and to protect networks. Firewalls are the norm in enterprise networks, for example.

- these are transport values in the transport payload of a network packet.

[Med] This document defines them as transport values, but legacy devices cannot handle them as transport values.   

 By your logic, the entire transport contents are potentially a covert channel, and we have no recommendation elsewhere to require DPI to protect a *network* (vs. the endpoints, which of course could require checking any part of a message).

[Med] I don’t understand the reference to DPI. I think you understood “inspection” as if I’m asking for “DPI”. Please see above.

- as to which refs are normative, AFAICT only RFC768  and 2460 would be

[Med] Please fix those.

, and *maybe* 1122 (e.g., by extending the extent of the UDP API). Nothing in this doc relies on the standards nature of other documents AFAICT. My "acid test" for whether to include something as normative is "would my doc need to change if the other RFC changed"? AFAICT, that's not true for 768, but I'd like to hear what others think of that set before moving them.

[Med] For other RFCs you didn’t cite, my rationale for including them as normative is as follows:

·         793 : MSS and other features are cloned from that document.

·         5925: the udp option clones the TCP option. An implementer need to refer to this document to have an idea about the format: “It uses the same format as specified for TCP-AO, except that it uses a Kind of 8.”

·         6994: ExIDs are defined in this RFC. An implementer need to read this RFC to understand/implement how the shared experiment IDs work.

Joe

 

On 6/28/2017 12:49 AM, mohamed.boucadair@orange.com wrote:

Hi Joe, 
 
Please find attached an initial review of this version of the document (both doc and pdf files are attached). 
 
Cheers,
Med
 
-----Message d'origine-----
De : tsvwg [mailto:tsvwg-bounces@ietf.org] De la part de Joe Touch
Envoyé : mardi 27 juin 2017 22:58
À : internet-drafts@ietf.org; i-d-announce@ietf.org
Cc : tsvwg@ietf.org
Objet : Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-01.txt
 
Hi, all,
 
This update adds some clarification on how to handle options whose
values depend on other options (e.g., ACS and AE).
 
Joe
 
 
On 6/27/2017 1:52 PM, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Transport Area Working Group of the
IETF.
 
        Title           : Transport Options for UDP
        Author          : Joe Touch
    Filename        : draft-ietf-tsvwg-udp-options-01.txt
    Pages           : 27
    Date            : 2017-06-27
 
Abstract:
   Transport protocols are extended through the use of transport header
   options. This document experimentally extends UDP by indicating the
   location, syntax, and semantics for UDP transport layer options.
 
 
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/
 
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-01
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-01
 
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-udp-options-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/
 

 

 

 


--------------75601050344A703F95F84842-- From nobody Wed Dec 13 06:11:36 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 1A7B5126C2F for ; Wed, 13 Dec 2017 06:11:34 -0800 (PST) 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, 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 JSq-W4fJJCoQ for ; Wed, 13 Dec 2017 06:11:32 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A332124B0A for ; Wed, 13 Dec 2017 06:11:32 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id BE980B81BCE; Wed, 13 Dec 2017 06:11:06 -0800 (PST) To: randall@lakerest.net, spencerdawkins.ietf@gmail.com, ietf@kuehlewind.net, david.black@emc.com, gorry@erg.abdn.ac.uk, wes@mti-systems.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: ncw@realvnc.com, tsvwg@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171213141106.BE980B81BCE@rfc-editor.org> Date: Wed, 13 Dec 2017 06:11:06 -0800 (PST) Archived-At: Subject: [tsvwg] [Technical Errata Reported] RFC4960 (5202) 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, 13 Dec 2017 14:11:34 -0000 The following errata report has been submitted for RFC4960, "Stream Control Transmission Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5202 -------------------------------------- Type: Technical Reported by: Nicholas Wilson Section: 3.3.4. Original Text ------------- The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack Block acknowledges a subsequence of TSNs received following a break in the sequence of received TSNs. By definition, all TSNs acknowledged by Gap Ack Blocks are greater than the value of the Cumulative TSN Ack. Corrected Text -------------- The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack Block acknowledges a subsequence of TSNs received following a break in the sequence of received TSNs. By definition, all TSNs acknowledged by Gap Ack Blocks are greater than the value of the Cumulative TSN Ack. The sequence of Gap Ack Blocks MUST be an increasing sequence of ranges, non-intersecting, and with at least one TSN as a gap between each Block and between the Cumulative TSN Ack and the first Block. Notes ----- It seems clear that the Gap Ack sequence must be sent in its "canonical" form (monotonic non-overlapping ranges) but I can't find anywhere where this is actually stated. It is implied (but not stated) by the following sentence on the next page, which implies that there is no freedom of choice in how the Gap Ack sequence is encoded: "For example, assume that ... then the parameter part of the SACK MUST be constructed as follows" Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4960 (draft-ietf-tsvwg-2960bis-05) -------------------------------------- Title : Stream Control Transmission Protocol Publication Date : September 2007 Author(s) : R. Stewart, Ed. Category : PROPOSED STANDARD Source : Transport Area Working Group Area : Transport Stream : IETF Verifying Party : IESG From nobody Wed Dec 13 07:09: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 C7E7E12704A for ; Wed, 13 Dec 2017 07:09:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kf0myPfHH25d for ; Wed, 13 Dec 2017 07:09:48 -0800 (PST) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FA44126CD8 for ; Wed, 13 Dec 2017 07:09:48 -0800 (PST) Received: from [IPv6:2003:cd:6be2:1e00:cc44:63a9:5971:28b9] (p200300CD6BE21E00CC4463A9597128B9.dip0.t-ipconnect.de [IPv6:2003:cd:6be2:1e00:cc44:63a9:5971:28b9]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 8EDCA72106C11; Wed, 13 Dec 2017 16:09:44 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Michael Tuexen In-Reply-To: <20171213141106.BE980B81BCE@rfc-editor.org> Date: Wed, 13 Dec 2017 16:09:42 +0100 Cc: Randall Stewart , Spencer Dawkins at IETF , =?utf-8?Q?Mirja_K=C3=BChlewind?= , "Black, David" , Gorry Fairhurst , Wesley Eddy , ncw@realvnc.com, tsvwg IETF list Content-Transfer-Encoding: quoted-printable Message-Id: <73B36B79-323F-4ADC-BD8C-2ACE488ACA62@lurchi.franken.de> References: <20171213141106.BE980B81BCE@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [tsvwg] [Technical Errata Reported] RFC4960 (5202) 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, 13 Dec 2017 15:09:52 -0000 > On 13. Dec 2017, at 15:11, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC4960, > "Stream Control Transmission Protocol". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5202 >=20 > -------------------------------------- > Type: Technical > Reported by: Nicholas Wilson >=20 > Section: 3.3.4. >=20 > Original Text > ------------- > The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack > Block acknowledges a subsequence of TSNs received following a break > in the sequence of received TSNs. By definition, all TSNs > acknowledged by Gap Ack Blocks are greater than the value of the > Cumulative TSN Ack. >=20 > Corrected Text > -------------- > The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack > Block acknowledges a subsequence of TSNs received following a break > in the sequence of received TSNs. By definition, all TSNs > acknowledged by Gap Ack Blocks are greater than the value of the > Cumulative TSN Ack. >=20 > The sequence of Gap Ack Blocks MUST be an increasing sequence of > ranges, non-intersecting, and with at least one TSN as a gap between > each Block and between the Cumulative TSN Ack and the first Block. Part of this is already clarified in = https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-04#section-3.4= 7 The missing piece is that the Gap Ack Blocks should be increasing. I know that the FreeBSD implementation always send them in increasing = order, but can handle them in any order when a SACK is received. Please note that TCP allows them in any order, see the last sentence = from https://tools.ietf.org/html/rfc2018#section-4 * The SACK option SHOULD be filled out by repeating the most recently reported SACK blocks (based on first SACK blocks in previous SACK options) that are not subsets of a SACK block already included in the SACK option being constructed. This assures that in normal operation, any segment remaining part of a non-contiguous block of data held by the data receiver is reported in at least three successive SACK options, even for large-window TCP implementations [RFC1323]). After the first SACK block, the following SACK blocks in the SACK option may be listed in arbitrary order. So I'm not sure if we need to require this. If we do, doesn't the same ordering requirement apply to the Duplicate TSNs? >=20 > Notes > ----- > It seems clear that the Gap Ack sequence must be sent in its = "canonical" form (monotonic non-overlapping ranges) but I can't find = anywhere where this is actually stated. >=20 > It is implied (but not stated) by the following sentence on the next = page, which implies that there is no freedom of choice in how the Gap = Ack sequence is encoded: >=20 > "For example, assume that ... > then the parameter part of the SACK MUST be constructed as follows" I agree, this "MUST" is not correct. Please note in particular that the = new text in = https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-04#section-3.4= 7 uses a SHOULD for the isolation property... Best regards Michael >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC4960 (draft-ietf-tsvwg-2960bis-05) > -------------------------------------- > Title : Stream Control Transmission Protocol > Publication Date : September 2007 > Author(s) : R. Stewart, Ed. > Category : PROPOSED STANDARD > Source : Transport Area Working Group > Area : Transport > Stream : IETF > Verifying Party : IESG >=20 From nobody Wed Dec 13 13:02: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 0B7F012708C for ; Wed, 13 Dec 2017 13:01:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jqvll-ju-q7b for ; Wed, 13 Dec 2017 13:01:56 -0800 (PST) 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 06DF81242EA for ; Wed, 13 Dec 2017 13:01:56 -0800 (PST) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 2708F1B00D2E for ; Wed, 13 Dec 2017 21:01:22 +0000 (GMT) Message-ID: <5A319522.5020708@erg.abdn.ac.uk> Date: Wed, 13 Dec 2017 21:01:22 +0000 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] Review of draft-ietf-tsvwg-rfc4960-errata-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: Wed, 13 Dec 2017 21:01:59 -0000 This email contains a shepherd review for the above draft. There are several issues, that seem straight forward to correct and where alternate wording may be needed. I have a comment about the use of lower case RFC2119 wording: While I know that documents continue to be published with a mix of upper case normative keywords and lower case words, I'd like the authors to explicitly check each of the lower case uses. In some places, the correct thing appears to be to use a normative version. I suggest we should be extremely careful in this usage when considering progressing a document to full standard. I'd advise replacing all other non-normative uses of /should/ and /may/ with /ought to/ and /could/ to remove this ambiguity. This would make it really clear what the normative requirements are. Gorry (TSVWG Co-Chair). ---- Abstract - English? /time based/ - seems wrong, this could be hypenated, although maybe it would be better as /time ordered/? --- Introduction /the publishing of this/ - may be better as /the publication of this/. --- 3.1.2 /the endpoint should mark the corresponding/ - This seems like a protocol action, why is this not /the endpoint SHOULD mark the corresponding/ --- /and may also/ - similarly /and MAY also/ - although I would understand why the latter was /and could also/ ... but I'd prefer to avoid the lower case MAY. --- /After this, the endpoint should continue HEARTBEAT on this destination address but should stop increasing the counter./ - are these /SHOULD/ if not, why not? and if a reason, I suggest you replace by /ought/. --- 3.2.2 /and should discard subsequent ULP shutdown requests./ - are these /SHOULD/ if not, why not? and if a reason, I suggest you replace by /ought/. --- 3.2.3 /If it did the endpoints/ - please insert comma aftre /did/. --- 3.3.2 - RFC2434 needs to be replaced by RFC5226. --- 3.6.2 /An endpoint shall keep a counter on the total number of consecutive retransmissions to its peer/ - is this /SHOULD/ if not, I suggest you replace by /ought/. --- /the path currently used for data transfer shall not increment the association error counter, / - Could this lead to failure, is this /SHOULD NOT/ or actually /MUST NOT/? --- 3.9.2 /to the current Path MTU/ - Elsewhere this is called PMTU. --- /for path MTU discovery./ - seems wrong, should this be: /for Path MTU Discovery./ or /for PMTU Discovery./ ? --- /constraint of the path MTU/ - Capital P, or PMTU? --- 3.11.2 /SCTP should perform slow/ - If SCTP is to follow TCP CC, then I think this needs to be: /SCTP SHOULD perform slow/ --- 3.13.2 /When a HEARTBEAT ACK is received from the peer endpoint, the counter should also be reset./ - I think that is SHOULD be reset. --- /The receiver of the HEARTBEAT ACK may choose not to clear the counter if there is outstanding data on the association. - I think that is MAY or /could/ --- / Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT should clear the error counter/ - I think that is SHOULD be clear, since it sets what comes on the wire. --- /The endpoint may optionally report/ - /could optionally report/ or /is permitted to optionally report/? --- /The receiver of the HEARTBEAT ACK should also clear/ - I'd have thought that was SHOULD. --- 3.15.2 - PMTU or Path MTU. --- 3.16.2 - The following text seems odd, but perhaps you could refer to RFC5681 where this exact phrase is used?: /The initial value of ssthresh SHOULD be arbitrarily high (e.g., to the size of the largest possible advertised window)./ --- 3.20.1 /But receiving new packets from the peer does not guarantee peer's accessibility/ - Maybe better as: /However, reception of new packets from the peer does not guarantee the peer's accessibility/ - Is reachability better than accessibility? --- 3.20.2 /should not increment the error counter/ - /ought not/ or /should not/. --- /This is because the receiver MAY keep its window closed for an indefinite time./ - is this really /MAY/ - are we permitting something or saying it can be so? If the latter, please use /could/ in place of MAY. --- - This text seems odd: /Refer to Section 6.2 on the receiver behavior when it advertises a zero window./ - would this be better as: /Section 6.2 deescribes the receiver behavior when it advertises a zero window./ --- 3.21.2 (multiple) /When this flag is set, the stream id and Stream Sequence Number must accompany this receive./ - This seems like protocol action is it /MUST/? --- /the endpoint shall clear the error counter of the destination transport address to which the DATA chunk was last sent (or HEARTBEAT was sent), and SHOULD/ - why is the first /shall/ lower case, and not an /ought to/ or a SHALL? --- /should clear the error counter/ - why is the /should/ lower case, and not an /ought to/ or a SHALL? --- (multiple) / An endpoint should limit the number of retransmissions of the SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'./ - why is the /should/ lower case, and not an /ought to/ or a SHALL? --- - A MUST states a requirement: /Furthermore, we require that the receiver of an INIT chunk MUST enforce these rules by silently discarding the INIT chunk and all further chunks if the INIT chunk is bundled with other chunks or the packet has a non-zero verification tag. / - needs to be rewritten as: /The receiver of an INIT chunk MUST silently discard the INIT chunk and all further chunks if the INIT chunk is bundled with other chunks or the packet has a non-zero verification tag./ --- 3.26.2 / When cwnd is greater than ssthresh, cwnd should be incremented by 1*MTU per RTT if the sender has cwnd or more bytes of data outstanding for the corresponding transport address./ - /SHOULD/. --- 3.27.2 / When the endpoint does not transmit data on a given transport address, the cwnd of the transport address should be adjusted to max(cwnd/2, 4*MTU) per RTO. At the first cwnd adjustment, the ssthresh of the transport address should be adjusted to the cwnd./ - /SHOULD be adjusted/ (twice)? --- 3.32.1 - This update is based on RFC6298. I think the updated text should in some way refer to this update as the basis of the method. --- 3.33.2. / The endpoint may bundle the ERROR chunk/ - /MAY/. --- 3.35.2 - This text doesn't seem very clear to me: / SCTP implementations MAY allow an application to configure the Differentiated Services Code Point (DSCP) used for sending packets. If a DSCP change might result in outgoing packets being queued in different queues, the congestion control parameters for all affected destination addresses MUST be reset to their initial values. / - (1) Does this mean for each packet? or for the entire asscociation or what? (I think it reads like an association?) - What does /being queued in different queues/ mean? ... any change to the DSCP could result in different results, but this is more likely if the change modifies an AF class. It is probably safer to point to RFC7657 for specifics. - Please update this. --- 3.40.2 - The update you note in the following two specific cases is not in the ID you cite, but in AccECN I think... where the change from RTT-based reduction is mentioned. Please check and update. / [RFC3168] updated by [I-D.ietf-tsvwg-ecn-experimentation] details a specific bit for a receiver to send back in its TCP acknowledgements to notify the sender of the Congestion Experienced (CE) bit having arrived from the network./ - / RFC3168] updated by [I-D.ietf-tsvwg-ecn-experimentation] details a specific bit for a sender to send in the header of its next outbound TCP segment to indicate to its peer that it has reduced its congestion window./ - Although maybe you could choose not to cite this? --- 3.44 - Section 3.44 clearly DOES have IANA implications. This represents changes that were made to port assignment, and although these are captured in a published RFC they are re-stated here and I think this NEEDS to be called out in the IANA considerations. IANA would be expected to review these changes (again), and this needs to be explained in section 4. --- / If the name resolution is not successful, the endpoint MUST immediately send an ABORT with "Unresolvable Address" error cause to its peer. The ABORT shall be sent to the source IP address from which the last peer packet was received./ - please replace/update the /shall/. --- /Should be set to all '0's and ignored by the receiver./ - SHOULD. --- 3.4.62 - Can one of the authors give me assurance that the code quoted is still correct at this time? --- From nobody Wed Dec 13 15:05: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 54DB012420B for ; Wed, 13 Dec 2017 15:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8ZVBqn2e6Kg for ; Wed, 13 Dec 2017 15:05:56 -0800 (PST) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D77981201F8 for ; Wed, 13 Dec 2017 15:05:55 -0800 (PST) Received: from [IPv6:2003:cd:6be2:1e00:71ad:e6c0:b111:bdb7] (p200300CD6BE21E0071ADE6C0B111BDB7.dip0.t-ipconnect.de [IPv6:2003:cd:6be2:1e00:71ad:e6c0:b111:bdb7]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id AEAA1721E280C; Thu, 14 Dec 2017 00:05:53 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Michael Tuexen In-Reply-To: <5A319522.5020708@erg.abdn.ac.uk> Date: Thu, 14 Dec 2017 00:05:51 +0100 Cc: tsvwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <51CC55FA-A7B3-4B09-85CD-662874B0F30D@lurchi.franken.de> References: <5A319522.5020708@erg.abdn.ac.uk> To: Gorry Fairhurst X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [tsvwg] Review of draft-ietf-tsvwg-rfc4960-errata-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: Wed, 13 Dec 2017 23:05:58 -0000 > On 13. Dec 2017, at 22:01, Gorry Fairhurst = wrote: >=20 >=20 > This email contains a shepherd review for the above draft. There are = several issues, that seem straight forward to correct and where = alternate wording may be needed. Thanks for the review. I'll go through you comments in detail in a = couple of days. >=20 > I have a comment about the use of lower case RFC2119 wording: While I = know that documents continue to be published with a mix of upper case = normative keywords and lower case words, I'd like the authors to = explicitly check each of the lower case uses. In some places, the = correct thing appears to be to use a normative version. >=20 > I suggest we should be extremely careful in this usage when = considering progressing a document to full standard. I'd advise = replacing all other non-normative uses of /should/ and /may/ with /ought = to/ and /could/ to remove this ambiguity. This would make it really = clear what the normative requirements are. Clarification question: Are you asking to check each of the lowercase = uses in RFC 4960 or in draft-ietf-tsvwg-rfc4960-errata-04.txt? Best regards Michael >=20 > Gorry > (TSVWG Co-Chair). >=20 > ---- >=20 > Abstract > - English? > /time based/ > - seems wrong, this could be hypenated, although maybe it would be = better as /time ordered/? > --- > Introduction > /the publishing of this/ > - may be better as /the publication of this/. > --- > 3.1.2 > /the endpoint should mark the corresponding/ > - This seems like a protocol action, why is this not > /the endpoint SHOULD mark the corresponding/ > --- > /and may also/ > - similarly /and MAY also/ > - although I would understand why the latter was /and could also/ ... = but I'd prefer to avoid the lower case MAY. > --- >=20 > /After this, the endpoint should continue > HEARTBEAT on this destination address but should stop increasing the > counter./ > - are these /SHOULD/ if not, why not? and if a reason, I suggest you = replace by /ought/. > --- > 3.2.2 > /and should discard subsequent ULP shutdown requests./ >=20 > - are these /SHOULD/ if not, why not? and if a reason, I suggest you = replace by /ought/. > --- > 3.2.3 > /If it did the endpoints/ > - please insert comma aftre /did/. > --- > 3.3.2 > - RFC2434 needs to be replaced by RFC5226. > --- > 3.6.2 > /An endpoint shall keep a counter on the total number of consecutive > retransmissions to its peer/ > - is this /SHOULD/ if not, I suggest you replace by /ought/. > --- > /the path currently used for data transfer shall > not increment the association error counter, / > - Could this lead to failure, is this /SHOULD NOT/ or actually /MUST = NOT/? > --- > 3.9.2 > /to the current Path MTU/ > - Elsewhere this is called PMTU. > --- > /for path MTU discovery./ > - seems wrong, should this be: > /for Path MTU Discovery./ or /for PMTU Discovery./ ? > --- > /constraint of the path MTU/ > - Capital P, or PMTU? > --- > 3.11.2 > /SCTP should perform slow/ > - If SCTP is to follow TCP CC, then I think this needs to be: > /SCTP SHOULD perform slow/ > --- > 3.13.2 > /When a > HEARTBEAT ACK is received from the peer endpoint, the counter should > also be reset./ > - I think that is SHOULD be reset. > --- > /The receiver of the HEARTBEAT ACK may choose not to > clear the counter if there is outstanding data on the association. > - I think that is MAY or /could/ > --- > / > Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT > should clear the error counter/ > - I think that is SHOULD be clear, since it sets what comes on the = wire. > --- > /The endpoint may optionally report/ > - /could optionally report/ or /is permitted to optionally report/? > --- > /The receiver of the HEARTBEAT ACK should also clear/ > - I'd have thought that was SHOULD. > --- > 3.15.2 > - PMTU or Path MTU. > --- > 3.16.2 > - The following text seems odd, but perhaps you could refer to RFC5681 = where this exact phrase is used?: > /The initial value of ssthresh SHOULD be arbitrarily high (e.g., > to the size of the largest possible advertised window)./ > --- > 3.20.1 > /But receiving new packets from the peer does not guarantee peer's = accessibility/ > - Maybe better as: > /However, reception of new packets from the peer does not guarantee = the peer's accessibility/ > - Is reachability better than accessibility? > --- > 3.20.2 > /should not increment the error counter/ > - /ought not/ or /should not/. > --- > /This is because the receiver MAY > keep its window closed for an indefinite time./ > - is this really /MAY/ - are we permitting something or saying it can = be so? > If the latter, please use /could/ in place of MAY. > --- > - This text seems odd: > /Refer to Section 6.2 on the receiver behavior when it advertises a = zero window./ > - would this be better as: >=20 > /Section 6.2 deescribes the receiver behavior when it advertises a = zero window./ >=20 > --- > 3.21.2 (multiple) > /When > this flag is set, the stream id and Stream Sequence Number must > accompany this receive./ > - This seems like protocol action is it /MUST/? > --- > /the endpoint shall > clear the error counter of the destination transport address to = which > the DATA chunk was last sent (or HEARTBEAT was sent), and SHOULD/ > - why is the first /shall/ lower case, and not an /ought to/ or a = SHALL? > --- > /should clear the error counter/ > - why is the /should/ lower case, and not an /ought to/ or a SHALL? >=20 > --- (multiple) > / An endpoint should limit the number of retransmissions of the > SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'./ > - why is the /should/ lower case, and not an /ought to/ or a SHALL? > --- > - A MUST states a requirement: > /Furthermore, we require > that the receiver of an INIT chunk MUST enforce these rules by > silently discarding the INIT chunk and all further chunks if the = INIT > chunk is bundled with other chunks or the packet has a non-zero > verification tag. / > - needs to be rewritten as: > /The receiver of an INIT chunk MUST silently discard the INIT chunk > and all further chunks if the INIT > chunk is bundled with other chunks or the packet has a non-zero > verification tag./ > --- > 3.26.2 > / > When cwnd is greater than ssthresh, cwnd should be incremented by > 1*MTU per RTT if the sender has cwnd or more bytes of data > outstanding for the corresponding transport address./ > - /SHOULD/. > --- > 3.27.2 > / > When the endpoint does not transmit data on a given transport > address, the cwnd of the transport address should be adjusted to > max(cwnd/2, 4*MTU) per RTO. At the first cwnd adjustment, the > ssthresh of the transport address should be adjusted to the = cwnd./ > - /SHOULD be adjusted/ (twice)? > --- > 3.32.1 > - This update is based on RFC6298. > I think the updated text should in some way refer > to this update as the basis of the method. > --- > 3.33.2. > / > The endpoint may bundle the ERROR chunk/ > - /MAY/. > --- > 3.35.2 > - This text doesn't seem very clear to me: > / > SCTP implementations MAY allow an application to configure the > Differentiated Services Code Point (DSCP) used for sending packets. > If a DSCP change might result in outgoing packets being queued in > different queues, the congestion control parameters for all affected > destination addresses MUST be reset to their initial values. >=20 > / > - (1) Does this mean for each packet? or for the entire asscociation = or what? > (I think it reads like an association?) > - What does /being queued in different queues/ mean? ... any change to = the > DSCP could result in different results, but this is more likely if the = change > modifies an AF class. It is probably safer to point to RFC7657 for = specifics. > - Please update this. > --- > 3.40.2 > - The update you note in the following two specific cases is not in = the ID you cite, but in AccECN I think... where the change > from RTT-based reduction is mentioned. Please check and update. > / > [RFC3168] updated by [I-D.ietf-tsvwg-ecn-experimentation] > details a specific bit for a receiver to send back in its > TCP acknowledgements to notify the sender of the Congestion > Experienced (CE) bit having arrived from the network./ > - > / > RFC3168] updated by [I-D.ietf-tsvwg-ecn-experimentation] > details a specific bit for a sender to send in the header > of its next outbound TCP segment to indicate to its peer that it has > reduced its congestion window./ > - Although maybe you could choose not to cite this? > --- > 3.44 > - Section 3.44 clearly DOES have IANA implications. This represents = changes > that were made to port assignment, and although these are captured in > a published RFC they are re-stated here and I think this NEEDS to be > called out in the IANA considerations. IANA would be expected to = review > these changes (again), and this needs to be explained in section 4. > --- > / > If the name resolution is not successful, the endpoint MUST > immediately send an ABORT with "Unresolvable Address" error cause > to its peer. The ABORT shall be sent to the source IP address > from which the last peer packet was received./ > - please replace/update the /shall/. > --- > /Should be set to all '0's and ignored by the receiver./ > - SHOULD. > --- > 3.4.62 > - Can one of the authors give me assurance that the code quoted is = still correct at this time? > --- >=20 From nobody Thu Dec 14 00:41: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 18A561271FD for ; Thu, 14 Dec 2017 00:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RI115umn72G4 for ; Thu, 14 Dec 2017 00:41:20 -0800 (PST) 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 8AA9A126CC4 for ; Thu, 14 Dec 2017 00:41:20 -0800 (PST) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 7AA6E1B00E87 for ; Thu, 14 Dec 2017 08:40:48 +0000 (GMT) Message-ID: <5A323910.1040700@erg.abdn.ac.uk> Date: Thu, 14 Dec 2017 08:40:48 +0000 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: <151324070716.6166.7663135987842986637.idtracker@ietfa.amsl.com> In-Reply-To: <151324070716.6166.7663135987842986637.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <151324070716.6166.7663135987842986637.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-iana-dscp-registry-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, 14 Dec 2017 08:41:23 -0000 I submitted the short ID below as a first-cut at a process ID for updating the DSCP registry. Comments/corrections are welcome. Please send to me or via the tsvwg list. Gorry (as an individual author). ---- A new version of I-D, draft-fairhurst-tsvwg-iana-dscp-registry-00.txt has been successfully submitted by Godred Fairhurst and posted to the IETF repository. Name: draft-fairhurst-tsvwg-iana-dscp-registry Revision: 00 Title: Re-assignment of Pool 3 of the DSCP Registry to assignment by IETF Standards Action Document date: 2017-12-14 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-fairhurst-tsvwg-iana-dscp-registry-00.txt Status: https://datatracker.ietf.org/doc/draft-fairhurst-tsvwg-iana-dscp-registry/ Htmlized: https://tools.ietf.org/html/draft-fairhurst-tsvwg-iana-dscp-registry-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-fairhurst-tsvwg-iana-dscp-registry-00 Abstract: The Differentiated Services (Diffserv) architecture specifies use of the DSField in the IPv4 and IPv6 packet header to carry the Diffserv Codepoint (DSCP). The Internet Assigned Numbers Authority (IANA) maintains a registry of assigned DSCP values. This update to RFC2474 requests a change to the IANA assignment method for Pool 3 of the registry to change this to Standards Action assignment. The update also removes permission for Local Use of the codepoints that form Pool 3 of the DSCP registry. 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 Thu Dec 14 12:28: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 D2AEE127735 for ; Thu, 14 Dec 2017 12:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=RXr4wtFL; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=IAAptwvE 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 4FEv7y7GQnza for ; Thu, 14 Dec 2017 12:28:16 -0800 (PST) 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 C6DED127599 for ; Thu, 14 Dec 2017 12:28:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1513282665; x=1544818665; h=from:cc:to:subject:date:message-id:mime-version; bh=Gbywmm1fQptl+L85DcSvMG3EHCucfdKfjqJs5znxv/o=; b=RXr4wtFLD4VyfSkkL2vddHZ78y4gttfBPwgRfC8/U3yf7pjmltn68k5U oIMhlurqUjk0kIADfCuFXw9YNROi5HlT5q0qied0/SlFybEqOE5SVUU7j Rdo0Azt4ZGqBwzHg9UQ6al7p7BWpTUYJg+MPYz+0+iQAmaGpn27DzEBd1 c=; IronPort-PHdr: =?us-ascii?q?9a23=3AIzlW6xIEp4SHvAO6itmcpTZWNBhigK39O0sv0rFi?= =?us-ascii?q?tYgeK/vxwZ3uMQTl6Ol3ixeRBMOHs6sC07KempujcFRI2YyGvnEGfc4EfD4+ou?= =?us-ascii?q?JSoTYdBtWYA1bwNv/gYn9yNs1DUFh44yPzahANS47xaFLIv3K98yMZFAnhOgpp?= =?us-ascii?q?POT1HZPZg9iq2+yo9JDffxhEiCChbb9uMR67sRjfus4KjIV4N60/0AHJonxGe+?= =?us-ascii?q?RXwWNnO1eelAvi68mz4ZBu7T1et+ou+MBcX6r6eb84TaFDAzQ9L281/szrugLd?= =?us-ascii?q?QgaJ+3ART38ZkhtMAwjC8RH6QpL8uTb0u+ZhxCWXO9D9QLYpUjqg8qhrUgflhi?= =?us-ascii?q?cZOTAk7GHZhM9+jKNHrx2uvBFw2ZLYbYWPOfZiYq/RY9UXTndBUMZLUCxBB5ux?= =?us-ascii?q?Y4USAuoFJ+lXs4r9q0MTphWwHwasGuLvxSJGinTr2qA03f4uER/H3AM9Bd4DrX?= =?us-ascii?q?DUo8/pO6cRSu260bfHzTHHb/9MxTj9743IfwknrPqRXrxwadLcxEgsGg/fkFmd?= =?us-ascii?q?p5LpMymI2ukNvWWX9fRsWf6xh2I/tg19viKjytkih4TKnI4YxV/J+T9kzIs7Jt?= =?us-ascii?q?C0UEB7bsCnHZdMsiyXMoh7T8wmTmFmvSs3yqAJtoSlcCUP1Zgr2gXQZvmIfoWG?= =?us-ascii?q?4R/uVOCcKipiin1/YrKwnROy/FClyu37S8a7zk5HrjFAktnQrnAN0AHT6tSfRv?= =?us-ascii?q?t94Eih3TGP2hjN5eFfO084i7DXJIM/zb40kpofqEPDHjLqmErti6+Wa0Mk9fW2?= =?us-ascii?q?5+j9Y7Xmvp+cN4p7iw3kLqsuncm/Dfw5MggIQWeb5fyx2bzg8EHjXrlHgOM6nr?= =?us-ascii?q?PEvJ3aK8kXvLC1DxNL3oo77hawFTam0NAWnXkdK1JFfQqKgYbzNFHQIfD3EO2z?= =?us-ascii?q?jkmokDhx2//GPabsDYjTIXjHlLftZ6py60lZyAYr19BQ+4pUCq0dIPL0QkLxqM?= =?us-ascii?q?fYDgE3Mgy72OvnCcty1p8QWW6VBa+ZKqzS4he04bdlP/KSe4A9uTvhJb4i/fGk?= =?us-ascii?q?xSslgkECcoGo0IcZLneiEaI1DV+eZC+mqNMIGmRO9iY3Uu3mwhXWfTdNZnr0da?= =?us-ascii?q?Y17TITBI+iCcHIQYX70+/J5zuyApADPjMOMVuLC3q9L4g=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GRAgDn3TJah8qZ6ERdHQEBBQELAYJKI?= =?us-ascii?q?oEoEHQnB50jmRMUgT5DCoU7AoR3QBcBAQEBAQEBAQEBAhABAQEKCwkIKCQLgjg?= =?us-ascii?q?iEUshBjIBAQEBAQEBAQEBAQEBAQEBAQEXAj0TAQEcMBMfGgERASpWJgEEG4k+Z?= =?us-ascii?q?AGrZ4MRh04BAQEBBgIBHQiDZYE2WIFXhlyDIQESASGCVgxigjKZWIlMBgKBd4c?= =?us-ascii?q?fjiiGEotElkACBAIEBQIagTshAoEWbm9PgimCYyWBTniIHYEkgRUBAQE?= X-IPAS-Result: =?us-ascii?q?A2GRAgDn3TJah8qZ6ERdHQEBBQELAYJKIoEoEHQnB50jmRM?= =?us-ascii?q?UgT5DCoU7AoR3QBcBAQEBAQEBAQEBAhABAQEKCwkIKCQLgjgiEUshBjIBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEXAj0TAQEcMBMfGgERASpWJgEEG4k+ZAGrZ4MRh04BAQE?= =?us-ascii?q?BBgIBHQiDZYE2WIFXhlyDIQESASGCVgxigjKZWIlMBgKBd4cfjiiGEotElkACB?= =?us-ascii?q?AIEBQIagTshAoEWbm9PgimCYyWBTniIHYEkgRUBAQE?= 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; 14 Dec 2017 14:17:44 -0600 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 Dec 2017 02:27:15 +0600 Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id vBEKSDdQ024689 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 14 Dec 2017 15:28:14 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com vBEKSDdQ024689 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1513283294; bh=gjSlyoF8sCb4OUVTxd9C5HW3WtU=; h=From:To:CC:Subject:Date:Message-ID:Content-Type:MIME-Version; b=IAAptwvEGTGogCmL6DiZyJAzD1milL+Dgna8lMN5bjdC+hWvXKxXbXoKJmQmqMrvv r7vobyV1Kr7s9oNXmpGWKoPl7djNlEEEH/Jw+av0BJkaOkT3TudrbopaJswZIpdV6f JNzvingHj1rURY8YJ1L51FqtCCE/fcfZvTT8lRVg= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com vBEKSDdQ024689 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd56.lss.emc.com (RSA Interceptor) for ; Thu, 14 Dec 2017 15:27:51 -0500 Received: from MXHUB321.corp.emc.com (MXHUB321.corp.emc.com [10.146.3.99]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id vBEKRvP2000615 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Thu, 14 Dec 2017 15:27:57 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB321.corp.emc.com ([10.146.3.99]) with mapi id 14.03.0352.000; Thu, 14 Dec 2017 15:27:57 -0500 To: "tsvwg@ietf.org" Thread-Topic: Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 Thread-Index: AdN1GcwEk8+6wIkTQ1++dedJ90kdDw== Date: Thu, 14 Dec 2017 20:27:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.138] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362FE164EBMX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 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, 14 Dec 2017 20:28:19 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362FE164EBMX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm tardy in getting to this action item from the TSVWG meeting in Singapor= e ... The TSVWG chairs are considering adoption of the draft "Packetization Layer Path MTU Discovery for Datagram Transports". This draft has been discussed at the previous IETF meeting and on the list,= and the chairs are now looking for input from the group to help inform whe= ther TSVWG should adopt this draft. * Please send an email to this list if you would like to see this work adop= ted in TSVWG, or you have comments on the suitability for adoption. * Please indicate if you are willing to REVIEW such a document during its d= evelopment. Please send all notes of support/comments to the TSVWG list or the WG chair= s by the date above. Best wishes, David and Wes. (TSVWG Co-Chairs) [Gorry is recused from this adoption decision, as he is a= n author of this draft.] [The time period for this adoption call is longer than usual to allow for t= he winter holidays - may yours be joyous!] Abstract This document describes a robust method for Path MTU Discovery (PMTUD) for datagram Packetization layers. The method allows a Packetization layer (or a datagram application that uses it) to probe an network path with progressively larger packets to determine a maximum packet size. The document describes as an extension to RFC 1191 and RFC 8201, which specify ICMP-based Path MTU Discovery for IPv4 and IPv6. This provides functionally for datagram transports that is equivalent to the Packetization layer PMTUD specification for TCP, specified in RFC4821. --_000_CE03DB3D7B45C245BCA0D243277949362FE164EBMX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m tardy in getting to this action item fr= om the TSVWG meeting in Singapore …

 

The TSVWG chairs are considering adoption of the = draft

"Packetization Layer Path MTU Discovery for = Datagram Transports".

 

This draft has been discussed at the previous IET= F meeting and on the list, and the chairs are now looking for input from th= e group to help inform whether TSVWG should adopt this draft.

 

* Please send an email to this list if you would = like to see this work adopted in TSVWG, or you have comments on the suitabi= lity for adoption.

 

* Please indicate if you are willing to REVIEW su= ch a document during its development.

 

Please send all notes of support/comments to the = TSVWG list or the WG chairs by the date above.

 

Best wishes,

 

David and Wes.

(TSVWG Co-Chairs) [Gorry is recused from this ado= ption decision, as he is an author of this draft.]

[The time period for this adoption call is longer= than usual to allow for the winter holidays – may yours be joyous!]<= o:p>

 

Abstract

 

   This document describes a robust met= hod for Path MTU Discovery

   (PMTUD) for datagram Packetization l= ayers.  The method allows a

   Packetization layer (or a datagram a= pplication that uses it) to probe

   an network path with progressively l= arger packets to determine a

   maximum packet size.  The docum= ent describes as an extension to RFC

   1191 and RFC 8201, which specify ICM= P-based Path MTU Discovery for

   IPv4 and IPv6.  This provides f= unctionally for datagram transports

   that is equivalent to the Packetizat= ion layer PMTUD specification for

   TCP, specified in RFC4821.

 

--_000_CE03DB3D7B45C245BCA0D243277949362FE164EBMX307CL04corpem_-- From nobody Thu Dec 14 12:32:03 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 BBFD0127ABE; Thu, 14 Dec 2017 12:32:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151328352176.13847.465795518140690932.idtracker@ietfa.amsl.com> Date: Thu, 14 Dec 2017 12:32:01 -0800 Archived-At: Subject: [tsvwg] The TSVWG WG has placed draft-fairhurst-tsvwg-datagram-plpmtud in state "Call For Adoption By WG Issued" 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, 14 Dec 2017 20:32:02 -0000 The TSVWG WG has placed draft-fairhurst-tsvwg-datagram-plpmtud in state Call For Adoption By WG Issued (entered by David Black) The document is available at https://datatracker.ietf.org/doc/draft-fairhurst-tsvwg-datagram-plpmtud/ From nobody Thu Dec 14 15:36:13 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 72720126DFF for ; Thu, 14 Dec 2017 15:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtK87Z6-ibaE for ; Thu, 14 Dec 2017 15:36:10 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3E35120725 for ; Thu, 14 Dec 2017 15:36:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=JNUQ3Qa3LjWC08lLs+Lqxxbor9zspN8+z1YLBRevqFU=; b=2T+Rta5NRlxyof9r/wy/zzSuh 6g7c67seyZcUVjsxgHnIWWVQ26IdIIEe+AMZyC3UDbMR9wwytDb5fx46E130S898erItqay8kIiZl ZoEZrdPAmdm85TqdVhjmHsMkW+dd7tuw3JB4b6eXgZ7X0HDIHnDWiPxZL5+losGVQHjIKYHO9upBR S1Sr574rd0MktU7gwq+N1jYRRR9MVfGSATNwf1l7cVHp1voURhAvBv1TtrpXKT+MuOWHMdDd6ZNDu g9QMoTKk3uAiyuI4q3YrC6SzgbhEDM8dzABJsJfH9xxxc14GZLGEaaFzMEdOYiCAOMXRi/nyOrD9N /60DPUuLg==; Received: from [204.140.240.55] (port=54289 helo=[172.26.23.140]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1ePd2u-002pRl-Is; Thu, 14 Dec 2017 18:36:09 -0500 Content-Type: multipart/alternative; boundary=Apple-Mail-418AB866-786A-4769-ABF3-69DF83AF87ED Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (15C114) In-Reply-To: Date: Thu, 14 Dec 2017 15:36:07 -0800 Cc: "tsvwg@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <79AA639A-EBB0-4D54-8490-C16371007E4B@strayalpha.com> References: To: "Black, David" X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 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, 14 Dec 2017 23:36:12 -0000 --Apple-Mail-418AB866-786A-4769-ABF3-69DF83AF87ED Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Agree with adoption.=20 Joe > On Dec 14, 2017, at 12:27 PM, Black, David wrote: >=20 > The TSVWG chairs are considering adoption of the draft >=20 > "Packetization Layer Path MTU Discovery for Datagram Transports". >=20 > =20 >=20 > This draft has been discussed at the previous IETF meeting and on the list= , and the chairs are now looking for input from the group to help inform whe= ther TSVWG should adopt this draft. >=20 > =20 >=20 > * Please send an email to this list if you would like to see this work ado= pted in TSVWG, or you have comments on the suitability for adoption. --Apple-Mail-418AB866-786A-4769-ABF3-69DF83AF87ED Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Agree with adoption. 

Joe

On Dec 14, 2017, at 12:27 PM, Black, David <David.Black@dell.com> wrote:

The TSVWG chairs are considering adoption of the draft

"Packetization Layer Path MTU Discovery for Datagram Transports".

 

This draft has been discussed at the previous IETF meeting and on the list, and the chairs are now looking for input from the group to help inform whether TSVWG should adopt this draft.

 

* Please send an email to this list if you would like to see this work adopted in TSVWG, or you have comments on the suitability for adoption.

--Apple-Mail-418AB866-786A-4769-ABF3-69DF83AF87ED-- From nobody Fri Dec 15 00:28: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 A2498126E01 for ; Fri, 15 Dec 2017 00:28:58 -0800 (PST) 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 g7UK3lyeK7Nb for ; Fri, 15 Dec 2017 00:28:55 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5B4124D85 for ; Fri, 15 Dec 2017 00:28:55 -0800 (PST) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 6B1581B00E74 for ; Fri, 15 Dec 2017 08:28:22 +0000 (GMT) Message-ID: <5A3387A7.5000008@erg.abdn.ac.uk> Date: Fri, 15 Dec 2017 08:28:23 +0000 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: <151332592165.30474.8109230096499713270.idtracker@ietfa.amsl.com> In-Reply-To: <151332592165.30474.8109230096499713270.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <151332592165.30474.8109230096499713270.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tsvwg] IETF WG state changed for draft-ietf-tsvwg-rfc4960-errata 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, 15 Dec 2017 08:28:58 -0000 The above document WGLC has now completed. Review comments are still welcome, as the document progresses through IETF review. A revised ID needs to be published by the document editors in response to the issues raised. The IETF WG state of draft-ietf-tsvwg-rfc4960-errata has been changed to "Waiting for WG Chair Go-Ahead" from "In WG Last Call" by Gorry Fairhurst: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-errata/ Gorry Fairhurst (TSVWG Shepherd for draft-ietf-tsvwg-rfc4960-errata) From nobody Fri Dec 15 07:09: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 166C31200CF for ; Fri, 15 Dec 2017 07:09:12 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 BXP_2xKbSxuX for ; Fri, 15 Dec 2017 07:09:10 -0800 (PST) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2ACD120721 for ; Fri, 15 Dec 2017 07:09:09 -0800 (PST) Received: by mail-it0-x232.google.com with SMTP id t1so20143483ite.5 for ; Fri, 15 Dec 2017 07:09:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=V9ArtycYdU5jdlqY2krjGrGBq4Tzy/v96ljlijXFwak=; b=Ds5zrnDqs8tqwXPYarzKOczZ1IgJzbK2cIJsYGFsn1eute16qVWZOxNSUlsWRWtuJl I9ofTUexYquVOivOqeGOMOom+WDTmP5iuQg0lPhyCyOr6X6FZkfbacwHn8j5RIo8c/rn mvcz1yyYo9B22ta0e1L9qblCv+HfvHOvtveAb6X8PzPmi4Ah4DblAkAWnMQSk3Itl4U0 aFdLW/vglQYbDimPgf6R1XKGDJd7fdj98tsT2H3iBYffQrYilq8D7tItLmBvObG45le+ Uv/zRMNrx9J/eyLOxoOKQF8vS00vbD+hwc/actLczRml3ONKzBOD97fP3x4bApT8mjH1 vzwQ== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=V9ArtycYdU5jdlqY2krjGrGBq4Tzy/v96ljlijXFwak=; b=PSVgIP0j1+GBWnk9NNqVDA+k4hRSxZFigW/JN58rQHit18Qf2eCSjRvVxOTd5anq5Q TWaziCLYk7DIKdg0ICCFF3hz5SBCVDt6EwlHX0D3yqPVFjvK7pUWQvdtSVqtXhFbdLvi FB5eaPmm9SiKAcH3hET/1/+CQW8kBp2YdZfdTrX8XJMg6h/jLkLfryv2Cy03bwDsnylQ /EX5VsmyBTtqhs1RcWQUmS2qUMByhkeixpR7DOqrbEDxCZe7VddJMTWCFC5ebxJtfOaL QCtFJ6S2tEYPhY3g8toWsxS02IBfD4l84lAqKAuKm13mnp242s9bdq5rU4+8ryx6xzaI zcFQ== X-Gm-Message-State: AKGB3mIbq54dTa245v42gR+u5LS6vD1a6ybFS8bcfrewTsgYKpFuihZA kNmBexyO0HVglwD6vb6kz1iT1MfDu7I= X-Google-Smtp-Source: ACJfBosPuBESovYW38Q2MAEPUf1l03VHr77UQ6u43DbIh9fKEJWdm2y8F6ZeN9MTZehZJI2YKO1Q6w== X-Received: by 10.107.200.195 with SMTP id y186mr13575850iof.90.1513350549121; Fri, 15 Dec 2017 07:09:09 -0800 (PST) Received: from [192.168.1.105] (cpe-76-188-215-129.neo.res.rr.com. [76.188.215.129]) by smtp.gmail.com with ESMTPSA id o2sm3606237ioe.71.2017.12.15.07.09.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Dec 2017 07:09:08 -0800 (PST) To: tsvwg@ietf.org References: From: Wesley Eddy Message-ID: <08b1ff20-f059-89ab-6905-e99665e94941@mti-systems.com> Date: Fri, 15 Dec 2017 10:09:05 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------46D0C1F260CF50C5330C972B" Content-Language: en-US Archived-At: Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 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, 15 Dec 2017 15:09:12 -0000 This is a multi-part message in MIME format. --------------46D0C1F260CF50C5330C972B Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 12/14/2017 3:27 PM, Black, David wrote: > > * Please send an email to this list if you would like to see this work > adopted in TSVWG, or you have comments on the suitability for adoption. > > * Please indicate if you are willing to REVIEW such a document during > its development. > > I agree with adopting, and will contribute to review as it progresses. --------------46D0C1F260CF50C5330C972B Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 12/14/2017 3:27 PM, Black, David wrote:

* Please send an email to this list if you would like to see this work adopted in TSVWG, or you have comments on the suitability for adoption.

* Please indicate if you are willing to REVIEW such a document during its development.



I agree with adopting, and will contribute to review as it progresses.


--------------46D0C1F260CF50C5330C972B-- From nobody Fri Dec 15 20:43:02 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 0197C1241F3; Fri, 15 Dec 2017 20:42:56 -0800 (PST) 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.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151339937595.8414.4499195154489588213@ietfa.amsl.com> Date: Fri, 15 Dec 2017 20:42:56 -0800 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ieee-802-11-10.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: Sat, 16 Dec 2017 04:42:56 -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-10.txt Pages : 36 Date : 2017-12-15 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 of 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-10 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ieee-802-11-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ieee-802-11-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Dec 16 00:48: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 2B6C2127201 for ; Sat, 16 Dec 2017 00:48:49 -0800 (PST) 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 ZotL1HqWhnXy for ; Sat, 16 Dec 2017 00:48:44 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 89A3A126DFB for ; Sat, 16 Dec 2017 00:48:44 -0800 (PST) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 72E681B01152 for ; Sat, 16 Dec 2017 08:48:11 +0000 (GMT) Message-ID: <5A34DDCA.1040108@erg.abdn.ac.uk> Date: Sat, 16 Dec 2017 08:48:10 +0000 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] TSVWG Status Summary 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, 16 Dec 2017 08:48:49 -0000 The list below shows the status of the working group documents as the Chairs see it. Please check below and comment on drafts using the list. Please do also send any corrections/omissions to the chairs. Gorry, David and Wes (TSVWG Chairs) December 2017 ------------------------------------------------------------------- Documents recently published: RFC 7496 Document Shepherd: Gorry RFC 7605 Document Shepherd: Gorry RFC 7857 Document Shepherd: David RFC 7829 Document Shepherd: Gorry RFC 8084 Document Shepherd: David RFC 8085 Document Shepherd: David RFC 8086 Document Shepherd: David RFC 8100 Document Shepherd: Gorry (DS interconn) RFC 8260 Document Shepherd: Gorry RFC 8261 Document Shepherd: Gorry --- IDs in RFC Editor Queue (http://www.rfc-editor.org/queue.html) : draft-ietf-tsvwg-rtcweb-qos - PS - Document Shepherd: David Approved, announcement 8th August 2016 RFC Editor: MISSREF - part of large rtcweb drafts hairball/tarball (C238) --- draft-ietf-tsvwg-ecn-experimentation - PS - Document Shepherd: Gorry Approved, announcement 27th November 2017 RFC Editor --- RFC-Ed ACTIONS: - None ---------------------------------------------------------- IDs in IESG Evaluation ---- draft-ietf-tsvwg-ieee-802-11 - PS - Document Shepherd: David Replaces: draft-szigeti-tsvwg-ieee-802-11 - Initial presentation at Prague IETF (Summer 2014) - Presentation at IETF Nov 2015. Thought to fall within TSVWG charter - No call issued for adoption at this time. Chair Note: Does this need to reference RC4594 or an update to that spec.? There's some background work that's likely to surface as proposed 4594bis and 5127bis drafts. Working Group call for adoption to end 25th June 2016. Adopted 28-June-2016 WG proposed status was updated to PS - notified WG on 8th August 2016, concluded. Name changed to remove "Guidelines" in the title, and target made PS IETF-97 (Seoul) presented. WGLC feedback, returned to WG for more discussion IPR: status : T. Szigeti = OK; F. Baker =OK - Comments by DB - incorporated in rev -02. - Comments by GF, FB on conditioning statements May 2017 IESG approved, 30 November 2017, status modified, will now be a BCP. DUE: Authors need to revise based on IESG comments. ------------------------------------------------------------------------------ WG Drafts with Chairs: --- draft-ietf-tsvwg-tunnel-congestion-feedback - Document Shepherd: David Replaces: draft-wei-tsvwg-tunnel-congestion-feedback - Thought to fall within TSVWG charter, comments welcome on tsvwg list. - IETF 91: Authors will work w/Bob Briscoe, who has a related individual draft for conex, on feedback mechanisms. Goal is concrete action taken based on detected problems that can be used from other drafts by reference. Also have to deal with possibility of dropped packets within tunnel. Draft returned to Working Group, will need a second WGLC after it is revised. *** NOTE: 2 IPR declarations relate to the work of this draft *** November 2016: WGLC, but not enough reviews. Two reviewers were found in Seoul (Bob Briscoe, Jake Holland) - need reviews before considering progress. Document with WG Chairs. --- draft-ietf-tsvwg-rfc4960-errata - Info - Document Shepherd: Gorry Replaces: draft-tuexen-tsvwg-rfc4960-errata Topic thought to fall within TSVWG charter Support for this work noted in Prague (Aug 2015). Expected to be used as the basis for an update to SCTP base specification. Authors have requested adoption IETF-95 - sense of the meeting room to proceed. IETF-96 - sense of the meeting room to proceed Adopted (22nd August 2016) WGLC: Please send WGLC comments to the TSVWG list to end Fri 8th Dec 2017. Reviewers: Irene R. - Editorial corrections ka-cheong.poon - Review received Qiaobing Xie - Review received Marcelo Ricardo - reviewed an earlier version, no further comments marcelo.leitner - no further comments Nicholas Wilson: http://www.rfc-editor.org/errata/eid5202 13th Dec: Chairs will talk to Authors to conclude the WGLC. DUE: Shepherd writeup of the document. DUE: Revised ID needed to address issues raised.. ------------------------------------------------------------------------------ In WGLC: --- None. ------------------------------------------------------------------------------ WG Drafts: draft-ietf-tsvwg-ecn-encap-guidelines - BCP - Document Shepherd: David Replaces: draft-briscoe-tsvwg-ecn-encap-guidelines -00 Presented in Prague, IETF-80. - comments at IETF-80 (see minutes) New ID presented in Atlanta, IETF-85. ID presented in IETF-88,89 - forward an appropriate message (perhaps your note to the mailing list for approval to adopt) to ieee-ietf-coord@ietf.org) ++ Reviewers: Andrew McGregor, Dirk Kutscher, (Richard Sheffnegger), Brian Trammell, Gorry. Mar 2014, WG Call for adoption started, to end 4th March 2014 19 for, 1 against. 8 echoed on the list Adoption call concluded and document adopted. - ecn-encap-guidelines and AQM are the main new things they need to know about. on IEEE802.1Q) Liaison sent to IEEE 802 (Nov 24, 2014). Liaison sent to 3GPP (August 2015) Oct 2015 - Draft updated for Yokohama meetings. Not sure about INT Area presentation. Need some more soak time for 3GPP Liaison. 3GPP liaison statement People who volunteered to review: * Andrew McGregor, Google * Dirk Kutscher, NEC * (I've also just asked Ingemar Johansson to volunteer) Support on list * Matt Mathis, Google * Richard Scheffenegger, NetApp * Michael Welzl, Uni Oslo * Wei Xin Peng, Huawei * Rong Pan, Cisco * Michael Menth, Tubingen Uni * Zhu Lei, Huawei * Piers O'Hanlon, UCL * Philip Eardley, BT * Suresh Krishnan * An Nguyen, DHS/OEC * Vinay Bannai, Paypal * Mirja Kuehlewind, Stuttgart Uni * Ruediger Geib, DT * Ingemar Johansson, Ericsson (? unclear whether support, or just a comment) Non-supportive of a doc solely about ECN. * Joe Touch, ISI IETF-98 (Chicago) Chairs will talk to TRILL chairs and try to get both into WGLC. DUE: Next version to be presented to IETF INT Area. DUE: Please comment on TSVWG list. --- draft-ietf-tsvwg-rfc6040update-shim-00 - PS - Document Shepherd: David Replaces: draft-briscoe-tsvwg-rfc6040bis Replaces: draft-ietf-tsvwg-rfc6040-update Topic thought to fall within TSVWG charter Support for this work noted (Berlin IETF, 2016) - to be published as a pair with ecn encaps. An adoption call was started on list by the Chairs until 22nd August 2016, concluded and adopted. Adopted, intended for publication as a PS RFC) WG work item - new-revision submitted ++ Randal Stewart will review ++ Randal Jessup will review IETF-97 (Seoul) presented Renamed as draft-ietf-tsvwg-rfc6040update-shim - 15th Nov 2016. DUE: Next version to be presented to IETF INT Area. DUE: Please discuss on the TSVWG list. --- draft-ietf-tsvwg-natsupp - Document Shepherd: Gorry Replaces: draft-stewart-natsupp-tsvwg Dependency from BEHAVE WG (no longer applicable). Adopted as a work item 21 Sept 2010 (Gorry). WG -00, 29/11/2010 Uploaded as: draft-ietf-natsupp-tsvwg Authors restructured draft (-03) Added support for single and multi-homed support. IETF-86: 3 people in meeting had read -04 or -05. Feb 2014, Authors please update following comments and align to related draft on SCTP NAT (conflicts found in language) Authors expected to produce a single document to replace both. ++ Dan Wing has committed to review this. ++ Fred Baker has committed to review this. Separated the simpler case for single-homed use - this separation should be clear. March 2015 document restructured and merged with draft-ietf-tsvwg-sctpnat March 2015, initial review by Gorry - need to consider helping NAT vendors access the recommendations. Gorry, Karen: Minor NiTs, Scope of IPv4 NAT discussed in Prague IETF and still thought within Charter. Authors expect to complete by May 2018. DUE: Revised ID-needed. --- draft-ietf-tsvwg-le-phb - Document Shepherd: David Replaces: draft-bless-tsvwg-le-phb A Lower Effort Per-Hop Behavior (LE PHB) Topic thought to fall within TSVWG charter Support for this work noted (Berlin IETF, 2016). An adoption call was started on list by the Chairs until 22nd August 2016, concluded and adopted. Adopted Nov 2016. New rev as a WG item. (Targeting publication as an EXP RFC) IETF-97 (Seoul), presented. IETF-98 (Chicago) discussed choice of code point - awaiting more data, expected decision by Sept 2017 IETF-100 (Singapore) Waiting for process draft to update IANA Registry pool 3 DUE: Please comment on the TSVWG list. --- draft-ietf-tsvwg-l4s-arch - Document Shepherd: Wes Replaces draft-briscoe-tsvwg-l4s-arch IETF-96, Previous version discussed at L4S BoF IETF-97 (Seoul), presented. IETF-98 (Chicago) 10 people had red the draft, clear support for adoption. Adopted. IETF-100 (Singapore) update presented - draft is in "holding pattern" while implementations are being worked and tested in conjunction with new scalable congestion control algorithms (e.g. SCReaM and TCP Prague). Linux and simulator code is becoming available, along with at least one chip implementation. DUE: Please discuss and share results on the TSVWG list. --- draft-ietf-tsvwg-ecn-l4s-id - Document Shepherd: Wes Replaces draft-briscoe-tsvwg-ecn-l4s-id New draft Nov-2914: Identifying Modified Explicit Congestion Notification (ECN) Semantics for Ultra-Low Queuing Delay IETF-96, Previous version discussed at L4S BoF IETF-97 (Seoul), presented. IETF-98 (Chicago) 10 people had red the draft, clear support for adoption. Adopted by tsvwg IETF-100 (Singapore) - See update on draft-ietf-tsvwg-l4s-arch above DUE: Please discuss and share results on the TSVWG list. --- draft-ietf-tsvwg-dualq-coupled - Document Shepherd: Wes Replaces: draft-briscoe-aqm-dualq-coupled Currently individual draft, TSVWG will consider this. - requires update to base ECN RFC - see separate draft. *** IPR related to this draft was submitted: September 16, 2015 (Reasonable and Non-Discriminatory License to All Implementers with Possible Royalty/Fee) *** Updated -01 March 2016, discussed on the AQM WG list. IETF-97 (Seoul), presented, new research results (Nov 2016) IETF-98 (Chicago) 10 people had read the draft, clear support for adoption. Adopted by tsvwg IETF-100 (Singapore) - See update on draft-ietf-tsvwg-l4s-arch above DUE: Please discuss on the TSVWG list. --- draft-ietf-tsvwg-udp-options - Document Shepherd: Gorry Replaces: draft-touch-tsvwg-udp-options Transport Options for UDP - Presentation at IETF Nov 2015. Topic thought to fall within TSVWG charter Discussed IETF-96 (Berlin) IETF-97 (Seoul) presented - no comments. IETF-98 (Chicago) 5 + 1 from jabber interested in this topic, 1 thought we shouldn't Comments on security model and discussed on list Adoption call until 31st May 2017 - Closed Tom Jones - supports adoption (will try an implementation) Tom Herbert - supports adoption (will review) Mike Heard - supports adoption (will review) D Fawcus - supports adoption (will review) DUE: Chairs to discuss publications status and intended date for milestone DUE: Please discuss on the TSVWG list. --- draft-ietf-tsvwg-fecframe-ext - Document Shepherd: Wes replaces - draft-roca-tsvwg-fecframev2 IETF-97 (Seoul), presented - could this be an update rather than bis? Adoption call requested by authors IETF-98 10 people had interest in work on this topic. DUE: Please discuss on the TSVWG list. --- draft-ietf-tsvwg-rlc-fec-scheme - Document Shepherd: Wes replaces - draft-roca-tsvwg-rlc-fec-scheme IETF-98 10 people had interest in work on this topic. DUE: Please discuss on the TSVWG list. ------------------------------------------------------------------- Adoption Call in Progress: draft-fairhurst-tsvwg-datagram-plpmtud-01 Support noted in INTAREA presentation (IETF-100) Presented in TSVWG, IETF-100 Thought to be within charter of TSVWG. DUE: Dec 2018: Adoption call to started on TSVWG list -------------------------------------------------------------------- Drafts under consideration by WG for adoption: - None. -------------------------------------------------------------------- Other drafts and work items linked to TSVWG: --- draft-fairhurst-tsvwg-transport-encrypt - Document Shepherd: TBD Support noted in INTAREA presentation (IETF-100) Presented in TSVWG, IETF-100 Adoption requested by authors DUE: Please discuss on the TSVWG list. --- draft-finzi-priority-switching-scheduler - Document Shepherd: TBD Presented in TSVWG, IETF-100 DUE: Please discuss on the TSVWG list. --- draft-tuexen-tsvwg-sctp-udp-encaps-cons - Document Shepherd: N/A. Thought to fall within TSVWG charter Presented to TSVWG in Buenos Aires (April 2016) Update at Soul IETF (Nov 2016) This list or errata will not be published as a RFC, it will be supeceded by a .bis document. DUE: Please discuss on the TSVWG list. -------------------------------------------------------------------- Liaisons: ITU-T Study Group 12 Liaison on QoS Classes & markings for interconnection IEEE liaison to support L2/L3 work on ECN marking 3GPP liaison to support L2/L3 work on ECN marking ================================================================== From nobody Mon Dec 18 06:49:57 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 A163E124D85 for ; Mon, 18 Dec 2017 06:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.089 X-Spam-Level: X-Spam-Status: No, score=-0.089 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaecqsLO9z_N for ; Mon, 18 Dec 2017 06:49:54 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 598EA124B17 for ; Mon, 18 Dec 2017 06:49:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: 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=SiofaNKppJ/jMt3xuLVlJKnYJqCRt8apvAIROokToJQ=; b=CGEwf1H24UR3ASU1tzJvPrdTs 8zJMAivazQL/WSuX+iy6q81vdBRZnCJJms/4IdSdEnrgOPRkm0MkdZHJg5HOLaN5f7UwzmomhYNBF ylA4D6y7O7iZqdi0zgFSs/aLQqv4MjdF/NTaJ142CYJjYNRqEwRsiyGYUsoctaKTwBfW6KJerDJUd tiCEl6AfX9IfKkwF4n4ejW83uRfBgiPvtD5n6GoYeQEuCFQjtMbzDt7bGflRUgPCXxhEiZ+gfrEud R0hm19GyZ954c7CMI1nF223SdELZsAmaRBecCJ89Grgkjo7xbbmiTb+nDIw02OZ5gnqKYjzlDX6fQ 0cFUchYGg==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:52290 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eQwjo-000KJ0-Iy; Mon, 18 Dec 2017 09:49:53 -0500 To: Wesley Eddy , tsvwg@ietf.org References: <08b1ff20-f059-89ab-6905-e99665e94941@mti-systems.com> From: Joe Touch Message-ID: <6b60574b-4545-4531-d5f6-87ccaae3f8b5@strayalpha.com> Date: Mon, 18 Dec 2017 06:49:49 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <08b1ff20-f059-89ab-6905-e99665e94941@mti-systems.com> Content-Type: multipart/alternative; boundary="------------0ADF21E3943DBDABBB93B231" Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 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, 18 Dec 2017 14:49:56 -0000 This is a multi-part message in MIME format. --------------0ADF21E3943DBDABBB93B231 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sorry I didn't mention, but I would also agree to review it. On 12/15/2017 7:09 AM, Wesley Eddy wrote: > On 12/14/2017 3:27 PM, Black, David wrote: >> >> >> >> * Please send an email to this list if you would like to see this >> work adopted in TSVWG, or you have comments on the suitability for >> adoption. >> >> >> >> * Please indicate if you are willing to REVIEW such a document during >> its development. >> >> >> > > I agree with adopting, and will contribute to review as it progresses. > > --------------0ADF21E3943DBDABBB93B231 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Sorry I didn't mention, but I would also agree to review it.


On 12/15/2017 7:09 AM, Wesley Eddy wrote:
On 12/14/2017 3:27 PM, Black, David wrote:

* Please send an email to this list if you would like to see this work adopted in TSVWG, or you have comments on the suitability for adoption.

* Please indicate if you are willing to REVIEW such a document during its development.



I agree with adopting, and will contribute to review as it progresses.



--------------0ADF21E3943DBDABBB93B231-- From nobody Mon Dec 18 09:47:05 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 64C3A1200F1; Mon, 18 Dec 2017 09:46:59 -0800 (PST) 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.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151361921937.3433.12178860525972093884@ietfa.amsl.com> Date: Mon, 18 Dec 2017 09:46:59 -0800 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ieee-802-11-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, 18 Dec 2017 17:46: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 : Diffserv to IEEE 802.11 Mapping Authors : Tim Szigeti Jerome Henry Fred Baker Filename : draft-ietf-tsvwg-ieee-802-11-11.txt Pages : 36 Date : 2017-12-18 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 of 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-11 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ieee-802-11-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ieee-802-11-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 Tue Dec 19 00:12:51 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 E596612DA15 for ; Tue, 19 Dec 2017 00:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 iQvGkLadwJMs for ; Tue, 19 Dec 2017 00:12:48 -0800 (PST) Received: from mailout34.telekom.de (MAILOUT34.telekom.de [194.25.225.146]) (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 33F29124205 for ; Tue, 19 Dec 2017 00:12:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1513671168; x=1545207168; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=9sktySKAWLsis/TMWInE5X/AKbFXkiIEDs9qdBxcO6M=; b=AuFf0Nl6EeZjqR8ADB+a3kroiXZPG8XB6ZwLnI+LojPIBWbp78eDwHBv w0EX6lSdHjaKFCY9c43n2EtEbjiYcQiyDrMAMVvEnu3NcEibDUkOQKsso m469YOXltSOmeabertyd1EQfB5csj0TXQN1c2DrzEpXfAowOFdo+yw7Li E+m8rd0AU7R38DJrxobDCbC4y8FtvFNbxgv930eUEiVka6afv5B8HCLVV G0DQPVMK6qlmOxe6744C5zmXHUTuIMtEdX5BITV3kJ/zBQZhllszyoa03 eaq89c311zoYZr1vuDa4CSXHf0IKu1A9427lqF3eLbheTcCQBPJtyvJWg g==; Received: from qdezc2.de.t-internal.com ([10.171.255.37]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Dec 2017 09:12:46 +0100 X-IronPort-AV: E=Sophos;i="5.45,425,1508796000"; d="scan'208";a="714587005" Received: from he104993.emea1.cds.t-internal.com ([10.169.119.36]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES256-SHA; 19 Dec 2017 09:12:45 +0100 Received: from HE106138.EMEA1.cds.t-internal.com (10.169.119.71) by HE104993.emea1.cds.t-internal.com (10.169.119.36) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 19 Dec 2017 09:12:45 +0100 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE106138.EMEA1.cds.t-internal.com (10.169.119.71) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 19 Dec 2017 09:12:45 +0100 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.15) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 19 Dec 2017 09:12:07 +0100 Received: from LEXPR01MB0094.DEUPRD01.PROD.OUTLOOK.DE (10.158.163.139) by LEXPR01MB0094.DEUPRD01.PROD.OUTLOOK.DE (10.158.163.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Tue, 19 Dec 2017 08:12:44 +0000 Received: from LEXPR01MB0094.DEUPRD01.PROD.OUTLOOK.DE ([fe80::bd79:9e12:5cb0:ec5a]) by LEXPR01MB0094.DEUPRD01.PROD.OUTLOOK.DE ([fe80::bd79:9e12:5cb0:ec5a%14]) with mapi id 15.20.0302.017; Tue, 19 Dec 2017 08:12:44 +0000 From: To: , Thread-Topic: [tsvwg] Fwd: New Version Notification for draft-fairhurst-tsvwg-iana-dscp-registry-00.txt Thread-Index: AQHTdLdvrYbg5+MRs0SevX0zBhEVUaNKWJVQ Date: Tue, 19 Dec 2017 08:12:44 +0000 Message-ID: References: <151324070716.6166.7663135987842986637.idtracker@ietfa.amsl.com> <5A323910.1040700@erg.abdn.ac.uk> In-Reply-To: <5A323910.1040700@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de; x-originating-ip: [164.19.3.188] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; LEXPR01MB0094; 6:jHhvBXJeHSNv/qOaqLU/VRyfiuMY/vF89wM/hRHa68i5AytA33YooJ8RUmGeU5/FJAHTsP4QBss4Qeu6KEHWcVJSDcKCgrG+/vq3+efSMSN2rrD5+eYhcKrdSW50N6K9KuvnKwdC6lfUnrK7bBA+BaWJumDKlbVWVGRs1/iONZLsy25f0cmuTUjYcLEohO5nPUcs5cJvy9MOqC+u4SEx6CS8d1V6Hy50CrnuG3amy15anWr1WiZersZIMqVQQZw9HeJk0riKT92qkdvq63OeuhrtPp94aQ2AKbTxqDJj1Xuq5Q5R76YQCGIBujQAXfVpGLyCpwWSXFWoYLvW672BT+eBKI1r/5PPwolcasVeU4k=; 5:G0H73OJ//aRWiuxxAP0SRazpbbLbVDh+OWB2Tjw49gILdxb8ar4tBe+3nB6IJDHsp/FmVFmyotYjP6IT3mcvfSFkKp3164eCO9PweNd1kv+xDWQq2224EUAkC7/+BZRWODPEYpxBGv0pJEAc4oEznTVv7NMsUIzOcvY1OR6eEaE=; 24:eGovf5PqqNqXKElTq6b34FsB1XHus7x4cYHvbJwXQOydis/SklmV/lBDcvu9MtMvqlFAfhPku33hMGzh0Uo89gTv4VymaZyhDGh+B7G1Jjs=; 7:sQBmZLKfqfSbhSvHPeVbDu58nvi9lMQ/pO2jNBztviSm7rIa5DWN23VXlkXRX2ddIV8OQC3bwFoF3y0tfP7Ds1hhRWbvPqfWDbGj4unqdnDLZURR4gHblQ+0nIHtQVeP0WXMk7sHvHSjO1X+nfiJO+SLWEZfmZdmbEJ7bxOmUFq11bX4API6/u6c2W8Z9EbJ20CkMG/mQFCecNYdX6dxViPD/IxVEXdYFfZzBEaOiRRdrfpoZ1WNecWLHZNSMZrN x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d9a5e7c2-8160-42b4-4f6b-08d546b848a9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307); SRVR:LEXPR01MB0094; x-ms-traffictypediagnostic: LEXPR01MB0094: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231023)(6041248)(20161123555025)(20161123558100)(20161123562025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:LEXPR01MB0094; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:LEXPR01MB0094; x-forefront-prvs: 052670E5A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(39860400002)(376002)(346002)(189003)(199004)(377424004)(5250100002)(6116002)(3660700001)(8936002)(2950100002)(86362001)(68736007)(3280700002)(75402003)(110136005)(52396003)(7736002)(66066001)(2906002)(316002)(5660300001)(33656002)(15650500001)(97736004)(74482002)(230783001)(4001150100001)(7696005)(6306002)(2900100001)(102836003)(76176011)(2501003)(59450400001)(478600001)(3846002)(9686003)(72206003)(105586002)(85182001)(85202003)(55016002)(305945005)(14454004)(53936002)(8676002)(966005)(81156014)(81166006)(106356001)(777600001); DIR:OUT; SFP:1101; SCL:1; SRVR:LEXPR01MB0094; H:LEXPR01MB0094.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d9a5e7c2-8160-42b4-4f6b-08d546b848a9 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2017 08:12:44.8837 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEXPR01MB0094 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [tsvwg] Fwd: New Version Notification for draft-fairhurst-tsvwg-iana-dscp-registry-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, 19 Dec 2017 08:12:50 -0000 SGkgR29ycnksDQoNCnRoYW5rcy4gSSBicmllZmx5IHJlYWQgeW91ciBkcmFmdCBhbmQgSSBzdXBw b3J0IGl0Lg0KDQpSZWdhcmRzLA0KDQpSdWVkaWdlcg0KDQotLS0tLVVyc3Byw7xuZ2xpY2hlIE5h Y2hyaWNodC0tLS0tDQpWb246IHRzdndnIFttYWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10g SW0gQXVmdHJhZyB2b24gR29ycnkgRmFpcmh1cnN0DQpHZXNlbmRldDogRG9ubmVyc3RhZywgMTQu IERlemVtYmVyIDIwMTcgMDk6NDENCkFuOiB0c3Z3Z0BpZXRmLm9yZw0KQmV0cmVmZjogW3Rzdndn XSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZmFpcmh1cnN0LXRzdndn LWlhbmEtZHNjcC1yZWdpc3RyeS0wMC50eHQNCg0KSSBzdWJtaXR0ZWQgdGhlIHNob3J0IElEIGJl bG93IGFzIGEgZmlyc3QtY3V0IGF0IGEgcHJvY2VzcyBJRCBmb3IgdXBkYXRpbmcgdGhlIERTQ1Ag cmVnaXN0cnkuIENvbW1lbnRzL2NvcnJlY3Rpb25zIGFyZSB3ZWxjb21lLiBQbGVhc2Ugc2VuZCB0 byBtZSBvciB2aWEgdGhlIHRzdndnIGxpc3QuDQoNCkdvcnJ5DQooYXMgYW4gaW5kaXZpZHVhbCBh dXRob3IpLg0KDQotLS0tDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1mYWlyaHVyc3Qt dHN2d2ctaWFuYS1kc2NwLXJlZ2lzdHJ5LTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBHb2RyZWQgRmFpcmh1cnN0IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3Np dG9yeS4NCg0KTmFtZToJCWRyYWZ0LWZhaXJodXJzdC10c3Z3Zy1pYW5hLWRzY3AtcmVnaXN0cnkN ClJldmlzaW9uOgkwMA0KVGl0bGU6CQlSZS1hc3NpZ25tZW50IG9mIFBvb2wgMyBvZiB0aGUgRFND UCBSZWdpc3RyeSB0byBhc3NpZ25tZW50IGJ5IElFVEYgU3RhbmRhcmRzIEFjdGlvbg0KRG9jdW1l bnQgZGF0ZToJMjAxNy0xMi0xNA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2Vz OgkJNg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1mYWlyaHVyc3QtdHN2d2ctaWFuYS1kc2NwLXJlZ2lzdHJ5LTAwLnR4dA0KU3RhdHVz OiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZhaXJodXJz dC10c3Z3Zy1pYW5hLWRzY3AtcmVnaXN0cnkvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZhaXJodXJzdC10c3Z3Zy1pYW5hLWRzY3AtcmVnaXN0cnkt MDANCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1s L2RyYWZ0LWZhaXJodXJzdC10c3Z3Zy1pYW5hLWRzY3AtcmVnaXN0cnktMDANCg0KDQpBYnN0cmFj dDoNCiAgICBUaGUgRGlmZmVyZW50aWF0ZWQgU2VydmljZXMgKERpZmZzZXJ2KSBhcmNoaXRlY3R1 cmUgc3BlY2lmaWVzIHVzZSBvZg0KICAgIHRoZSBEU0ZpZWxkIGluIHRoZSBJUHY0IGFuZCBJUHY2 IHBhY2tldCBoZWFkZXIgdG8gY2FycnkgdGhlIERpZmZzZXJ2DQogICAgQ29kZXBvaW50IChEU0NQ KS4gVGhlIEludGVybmV0IEFzc2lnbmVkIE51bWJlcnMgQXV0aG9yaXR5IChJQU5BKQ0KICAgIG1h aW50YWlucyBhIHJlZ2lzdHJ5IG9mIGFzc2lnbmVkIERTQ1AgdmFsdWVzLg0KDQogICAgVGhpcyB1 cGRhdGUgdG8gUkZDMjQ3NCByZXF1ZXN0cyBhIGNoYW5nZSB0byB0aGUgSUFOQSBhc3NpZ25tZW50 DQogICAgbWV0aG9kIGZvciBQb29sIDMgb2YgdGhlIHJlZ2lzdHJ5IHRvIGNoYW5nZSB0aGlzIHRv IFN0YW5kYXJkcyBBY3Rpb24NCiAgICBhc3NpZ25tZW50LiAgVGhlIHVwZGF0ZSBhbHNvIHJlbW92 ZXMgcGVybWlzc2lvbiBmb3IgTG9jYWwgVXNlIG9mIHRoZQ0KICAgIGNvZGVwb2ludHMgdGhhdCBm b3JtIFBvb2wgMyBvZiB0aGUgRFNDUCByZWdpc3RyeS4NCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Tue Dec 19 09:21: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 8157112D7F3 for ; Tue, 19 Dec 2017 09:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDhhi7LXUCQW for ; Tue, 19 Dec 2017 09:21:39 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0A43D124C27 for ; Tue, 19 Dec 2017 09:21:39 -0800 (PST) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 08A011B00B19 for ; Tue, 19 Dec 2017 17:21:06 +0000 (GMT) Message-ID: <5A394A82.7010501@erg.abdn.ac.uk> Date: Tue, 19 Dec 2017 17:21:06 +0000 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: <151370387232.7383.17926337492059791035.idtracker@ietfa.amsl.com> In-Reply-To: <151370387232.7383.17926337492059791035.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <151370387232.7383.17926337492059791035.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-transport-encrypt-05.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, 19 Dec 2017 17:21:41 -0000 A new version of our draft has been prepared based on feedabck from the presenation in the OpSec WG and detailed review comments by Mohamed Boucadair - many thanks! Both authors would be interested in any further comments and questions about this draft. Best wishes, Colin and Gorry -------- Original Message -------- Subject: New Version Notification for draft-fairhurst-tsvwg-transport-encrypt-05.txt Date: Tue, 19 Dec 2017 09:17:52 -0800 From: internet-drafts@ietf.org To: Colin Perkins , Godred Fairhurst , Gorry Fairhurst A new version of I-D, draft-fairhurst-tsvwg-transport-encrypt-05.txt has been successfully submitted by Godred Fairhurst and posted to the IETF repository. Name: draft-fairhurst-tsvwg-transport-encrypt Revision: 05 Title: The Impact of Transport Header Encryption on Network Operation and Evolution of the Internet Document date: 2017-12-19 Group: Individual Submission Pages: 29 URL: https://www.ietf.org/internet-drafts/draft-fairhurst-tsvwg-transport-encrypt-05.txt Status: https://datatracker.ietf.org/doc/draft-fairhurst-tsvwg-transport-encrypt/ Htmlized: https://tools.ietf.org/html/draft-fairhurst-tsvwg-transport-encrypt-05 Htmlized: https://datatracker.ietf.org/doc/html/draft-fairhurst-tsvwg-transport-encrypt-05 Diff: https://www.ietf.org/rfcdiff?url2=draft-fairhurst-tsvwg-transport-encrypt-05 Abstract: This document describes implications of applying end-to-end encryption at the transport layer. It identifies in-network uses of transport layer header information. It then reviews the implications of developing encrypted end-to-end transport protocols on transport protocol design and the implications on network operation. Since transport measurement and analysis of the impact of network characteristics have been important to the design of current transport protocols, it also considers some anticipated implications on transport and application evolution. 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 Thu Dec 21 12:38:26 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 D3763126B6E; Thu, 21 Dec 2017 12:38:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: gorry@erg.abdn.ac.uk, spencerdawkins.ietf@gmail.com, tsvwg-chairs@ietf.org, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151388870484.12916.12208196574703231142.idtracker@ietfa.amsl.com> Date: Thu, 21 Dec 2017 12:38:24 -0800 Archived-At: Subject: [tsvwg] tsvwg - New Meeting Session Request for IETF 101 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, 21 Dec 2017 20:38:25 -0000 A new meeting session request has just been submitted by Gorry Fairhurst, a Chair of the tsvwg working group. --------------------------------------------------------- Working Group Name: Transport Area Working Group Area Name: Transport Area Session Requester: Gorry Fairhurst Number of Sessions: 2 Length of Session(s): 1 Hour, 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: intarea tsvarea iccrg rmcat tcpm mptcp taps ippm quic tcpinc rtgwg opsarea Second Priority: dtn rtcweb v6ops tram dispatch Third Priority: artarea ccamp People who must be present: David L. Black Gorry Fairhurst Spencer Dawkins Wesley Eddy Mirja Kuehlewind Resources Requested: Special Requests: [If rtcweb has 2 sessions, 1 should not conflict] [Must not conflict with Transport Area BoFs] It's quite OK to do Friday am sometimes (as last), but good to not always have that slot. --------------------------------------------------------- From nobody Fri Dec 22 11:58:39 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 0A6341200B9; Fri, 22 Dec 2017 11:58:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Cc: "David L. Black" , The IESG , tsvwg@ietf.org, david.black@emc.com, draft-ietf-tsvwg-ieee-802-11@ietf.org, spencerdawkins.ietf@gmail.com, rfc-editor@rfc-editor.org, tsvwg-chairs@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <151397270603.28012.1820897448193462753.idtracker@ietfa.amsl.com> Date: Fri, 22 Dec 2017 11:58:26 -0800 Archived-At: Subject: [tsvwg] Protocol Action: 'Diffserv to IEEE 802.11 Mapping' to Proposed Standard (draft-ietf-tsvwg-ieee-802-11-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: Fri, 22 Dec 2017 19:58:26 -0000 The IESG has approved the following document: - 'Diffserv to IEEE 802.11 Mapping' (draft-ietf-tsvwg-ieee-802-11-11.txt) as Proposed Standard This document is the product of the Transport Area Working Group. The IESG contact persons are Mirja Kühlewind and Spencer Dawkins. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11/ Technical Summary 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. Working Group Summary This draft is supported by the portion of the tsvwg working group that is familiar with and interested in Diffserv. The mappings in this draft have been stable for about the past year and are being implemented. Recent activity on this draft stemming from WG Last Call has focused on other aspects, primarily security-related (e.g., network cannot "trust" DSCP markings set by the originator of traffic) and related concerns around dealing with possible use and misuse of the high priority CS6 and CS7 DSCP markings for network control traffic such as routing protocols. All of these concerns have been resolved, and the shepherd is confident that the draft reflects WG rough consensus. The TSVWG WG is working on revising and replacing the RFC 3662 specification of Lower Effort (less than best effort) Diffserv traffic; that revision will change the recommended DSCP. The WG has decided that this DSCP to UP mapping draft should reflect current "running code" that uses the CS1 codepoint for Lower Effort traffic and not wait for completion of work on replacement of RFC 3662 and selection of a new recommended default DSCP for Lower Effort traffic. Document Quality The draft has received significant review and critique from a number of Diffserv experts, including the draft shepherd. the draft has been significantly modified as a result, including revising the mappings to resolve concerns about potential priority inversion between wired and wireless networks. The WiFi material has also been reviewed by a WiFi expert. Personnel The Document Shepherd is David Black. The responsible Area Director is Spencer Dawkins. RFC Editor Note OLD o Setting a traffic conditioning policy 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). Additionally, Section 5.3 made it clear that it is generally NOT RECOMMENDED to pass through 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 with little or no security capabilities (making such vulernable to be utilized as agents for DDoS attacks, the effects of which can be amplified with preferential QoS treatments, should the packet markings of such devices be trusted). NEW o Setting a traffic conditioning policy 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). Additionally, Section 5.3 made it clear that it is generally NOT RECOMMENDED to pass through 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 with little or no security capabilities, leaving them vulnerable to be utilized as agents for DDoS attacks. These attacks can be amplified with preferential QoS treatments, should the packet markings of such devices be trusted.