From nobody Fri Jan 3 01:17:37 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51BAB1200D8 for ; Fri, 3 Jan 2020 01:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bC_wmWX9PSvg for ; Fri, 3 Jan 2020 01:17:34 -0800 (PST) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (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 05EC2120044 for ; Fri, 3 Jan 2020 01:17:33 -0800 (PST) Received: by mail-ua1-x92d.google.com with SMTP id 59so14446810uap.12 for ; Fri, 03 Jan 2020 01:17:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=rxy6m6GIQyWLrIXn7/xdSsYjlc66OU4sebffxEgemOY=; b=p8McNOxE2yHY1dmLVpXJZ/rLM5rTmYplCtDcgeib0HK5yuiAHLDYgC8RdrMBTAZeQq RXgHvpQe+t/SxT1QG5AoMC2luXWIbqGry+YF0fd7KSs++6bBdBz2AqJteU1xPd0OdCwy ThKI6YR3ZJGfWhqS8AY4M18AWJibNz//9jOoCgRkToxHa7yMBMSh0NG1ZtVLj9c6yzHs Oge9F5wz4KOkS+0vtD6ynewqstciJ/qJVA2rFBDgq5kJK8dgMGQfDQzsdk/SOjciTFLv ODyKSOMG68swJ3rTj0iMoNu5jZKU5e5xBeZCgiMY3rqqJWAmgI3gqx9k106FzWaoUwUS 4J/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=rxy6m6GIQyWLrIXn7/xdSsYjlc66OU4sebffxEgemOY=; b=qYqeqpPKkXbJCIaodT1Zh8+b98h5IV/lugflFEt69HjVPbi6VrWGQu0SJzk9SxWsZt 7GkGOZRSO+AiPbrFi421w7ONS00ZpqAmkXxWBVFKpAYxvYZSskRQxGaTMAin57CZu9gZ o1bTK+/rQ4N5iY6wL9qj3ahJ1hRgt93JYYN5BExCUuZQmqpDX2PXgm5yPs1Eoq3689nr dVZhHRRu2YL49plrjCMHOIYBsdpcXc2PWO8DRD7t6BDp7yPkLhOdxWc/MXYywMJKc4bj yKwH1FakhjA5gcEOby7+Wpj+j4oK3omV8N4rtjvCfZ3fXhXOq65iQF2/1oaja5/CfuMW jL7A== X-Gm-Message-State: APjAAAXH47iE9IwGZI+KLUrS85HBlrAKHK+vSbYmQvhF4PPHb5bWRu8p 1EmxfQ21QnDfsMkCIy69ubBSP/ReP2kaLOQSrilTkvo3 X-Google-Smtp-Source: APXvYqxJYT85Gu5AN9HhSZU+HlbOHtVjrNBXCGbFiA/+XV2nd3HUf6zkdNJ3uqNxwNBFEQjNR5skOJWjlkKnGKXJP1o= X-Received: by 2002:ab0:485:: with SMTP id 5mr34429459uaw.140.1578043052908; Fri, 03 Jan 2020 01:17:32 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Yoshifumi Nishida Date: Fri, 3 Jan 2020 01:17:21 -0800 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="0000000000009be2b7059b38c794" Archived-At: Subject: Re: [tcpm] intended status of draft-ietf-tcpm-accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 09:17:35 -0000 --0000000000009be2b7059b38c794 Content-Type: text/plain; charset="UTF-8" Hello, This might be because some folks are on winter break, but it seems that we don't have much feedback on this. I am thinking about this a bit and start wondering if this may mean our general feelings are "either status is fine" or there are some other reasons. If this is the case, I am thinking exp status might be suitable as PS generally requires explicit supports (such as the case for TCP RACK) If you could provide any opinions or comments, we will appreciate very much! Thanks, -- Yoshi On Fri, Dec 13, 2019 at 1:17 AM Yoshifumi Nishida wrote: > Hi folks, > > We would like to get feedback for the intended status > of draft-ietf-tcpm-accurate-ecn. > The current intended status of this draft is experimental, but we've seen > some voices that PS is more preferable for the draft during Singapore > meeting and on the ML. So, we would like to check the consensus on it. > > There are some on-going related discussions such as flag registration > policy, SCE, ECN++, etc, however, we believe the intended status > discussions is independent from them and can proceed it separately. (If you > have concerns on it, please share your opinion here) > > We appreciate your feedback. > > Thanks, > -- > Yoshi on behalf of tcpm co-chairs. > > > --0000000000009be2b7059b38c794 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

This might be because some folks are on winter break, b= ut it seems that we don't have much feedback on this.
I am thinking about this a bit and start wondering if this may mean= our general feelings are "either status is fine" or there are so= me other reasons.
If this is the case, I am thinking exp status m= ight be suitable as PS generally requires explicit supports (such as the ca= se for TCP RACK)
If you could provide any opinions or comments, w= e will appreciate very much!

Thanks,
--<= /div>
Yoshi

On Fri, Dec 13, 2019 at 1:17 AM Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:
Hi folks,

We would like = to get feedback for the intended status of=C2=A0draft-ietf-tcpm-accurate-ec= n.=C2=A0
The current intended status of this draft is= experimental, but we've seen some voices that PS is more preferable fo= r the draft during Singapore meeting and on the ML. So, we would like to ch= eck the consensus on it.

There are some on-going r= elated discussions such as flag registration policy, SCE, ECN++, etc, howev= er, we believe the intended status discussions is independent from them and= can proceed it separately. (If you have concerns on it, please share your = opinion here)

We appreciate your feedback.

Thanks,
--
Yoshi on behalf of tcpm co= -chairs.


--0000000000009be2b7059b38c794-- From nobody Fri Jan 3 05:49:07 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63456120086 for ; Fri, 3 Jan 2020 05:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jue3j21DwZoT for ; Fri, 3 Jan 2020 05:49:01 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 333C2120077 for ; Fri, 3 Jan 2020 05:49:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References: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=fi5r+5lD1h8FsAESCXEDQ0hEeQoq0li9dvrdCZnp/6w=; b=gyNhzsa3Dw2w+MLkQKyrFQqZW dhCxa06irD+tHxVNmU+fn6pzssyInF5gwMqh7JvLEfKFMkjJkh85/YrxmE4bCc7vQlYX/VoypLyN4 kC+YT8jOOblCIz+4ENyLxW9GVfuNf+4fq+ftuMbeKS8LlWO4wtuShCVZ93ktCrEu8ehnY8N4s/gZB FXn7TSwJgO04AL8cjqqsXKnJdXvFBDIDD9O09hOnxhEHxvXJ++8xQMve8EihrTjji9SJJ2ZX68bdX vJrDY/Dsax1QDmFIeLlZ2dzv9pOFTBqJJvqg1h4V3BJnTYlcg1bSXlwaQhXpRTdrxIyLt6/St+jAj vH5jmMYnw==; Received: from [31.185.135.151] (port=46940 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1inNJy-0007Ex-Nb; Fri, 03 Jan 2020 13:48:58 +0000 To: Yoshifumi Nishida , "tcpm@ietf.org Extensions" References: From: Bob Briscoe Message-ID: <34288421-58db-78ba-2083-f2418f3bff70@bobbriscoe.net> Date: Fri, 3 Jan 2020 13:48:58 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B96646D480E38BA27E7109CA" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] intended status of draft-ietf-tcpm-accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 13:49:05 -0000 This is a multi-part message in MIME format. --------------B96646D480E38BA27E7109CA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Yoshi, Are you expecting everyone who stuck their hand up at IETF-106 in Singapore to repeat their opinion? Or is the ML call primarily meant to look for people with opinions who were not present? So far, the only opinions on the ML have repeated those in the f2f mtg, for which the minutes said: Yoshi: PS: 8, EXP: 2, don't care: 8 In context, "don't care" meant "either" (not "don't care about the draft"). To repeat my opinion given verbally: * I'm happy  with either PS or EXP. * On balance, PS, 'cos when making a change to the TCP wire protocol putting EXP or PS in an RFC header doesn't make any difference to whether the change can be reversed. So, it's better to be clear how serious we have to be about getting it right. * Making it PS would make the header flags process faster, and add weight to the internal corporate cases need to allocate time for implementing this (and implementing supporting stuff like offload) * but both those are less important than getting it right. Bob On 03/01/2020 09:17, Yoshifumi Nishida wrote: > Hello, > > This might be because some folks are on winter break, but it seems > that we don't have much feedback on this. > I am thinking about this a bit and start wondering if this may mean > our general feelings are "either status is fine" or there are some > other reasons. > If this is the case, I am thinking exp status might be suitable as PS > generally requires explicit supports (such as the case for TCP RACK) > If you could provide any opinions or comments, we will appreciate very > much! > > Thanks, > -- > Yoshi > > On Fri, Dec 13, 2019 at 1:17 AM Yoshifumi Nishida > wrote: > > Hi folks, > > We would like to get feedback for the intended status > of draft-ietf-tcpm-accurate-ecn. > The current intended status of this draft is experimental, but > we've seen some voices that PS is more preferable for the draft > during Singapore meeting and on the ML. So, we would like to check > the consensus on it. > > There are some on-going related discussions such as flag > registration policy, SCE, ECN++, etc, however, we believe the > intended status discussions is independent from them and can > proceed it separately. (If you have concerns on it, please share > your opinion here) > > We appreciate your feedback. > > Thanks, > -- > Yoshi on behalf of tcpm co-chairs. > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------B96646D480E38BA27E7109CA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Yoshi,

Are you expecting everyone who stuck their hand up at IETF-106 in Singapore to repeat their opinion? Or is the ML call primarily meant to look for people with opinions who were not present? So far, the only opinions on the ML have repeated those in the f2f mtg, for which the minutes said:
Yoshi: PS: 8, EXP: 2, don't care: 8
In context, "don't care" meant "either" (not "don't care about the draft").

To repeat my opinion given verbally:
  • I'm happy  with either PS or EXP.
  • On balance, PS, 'cos when making a change to the TCP wire protocol putting EXP or PS in an RFC header doesn't make any difference to whether the change can be reversed. So, it's better to be clear how serious we have to be about getting it right.
  • Making it PS would make the header flags process faster, and add weight to the internal corporate cases need to allocate time for implementing this (and implementing supporting stuff like offload)
  • but both those are less important than getting it right.


Bob

On 03/01/2020 09:17, Yoshifumi Nishida wrote:
Hello,

This might be because some folks are on winter break, but it seems that we don't have much feedback on this.
I am thinking about this a bit and start wondering if this may mean our general feelings are "either status is fine" or there are some other reasons.
If this is the case, I am thinking exp status might be suitable as PS generally requires explicit supports (such as the case for TCP RACK)
If you could provide any opinions or comments, we will appreciate very much!

Thanks,
--
Yoshi

On Fri, Dec 13, 2019 at 1:17 AM Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:
Hi folks,

We would like to get feedback for the intended status of draft-ietf-tcpm-accurate-ecn. 
The current intended status of this draft is experimental, but we've seen some voices that PS is more preferable for the draft during Singapore meeting and on the ML. So, we would like to check the consensus on it.

There are some on-going related discussions such as flag registration policy, SCE, ECN++, etc, however, we believe the intended status discussions is independent from them and can proceed it separately. (If you have concerns on it, please share your opinion here)

We appreciate your feedback.

Thanks,
--
Yoshi on behalf of tcpm co-chairs.



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


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------B96646D480E38BA27E7109CA-- From nobody Fri Jan 3 13:31:24 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0D6120045 for ; Fri, 3 Jan 2020 13:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 DfieEGwTwTr5 for ; Fri, 3 Jan 2020 13:31:20 -0800 (PST) Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (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 95ECD120026 for ; Fri, 3 Jan 2020 13:31:20 -0800 (PST) Received: by mail-vk1-xa33.google.com with SMTP id c129so11081938vkh.7 for ; Fri, 03 Jan 2020 13:31:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1MNxG0MBuxXoRP0yzMBQwe/gUkrdIgmzXLiQx7dmlMM=; b=DglmCH7MfwYXbkhym7/7atdkKN7WyZN/krRpQcOzCV9CiKPE2LbllsAxgLp+lWnuDP TWEEmzonP3CycaLn3bRp1f2jBaUkxwI510lrMBAeJjxkCgcszIH5+YNUM3EsazfOvizQ qk73FSNUTnWuPIGarLEREX1oYODS6DIcEN1ywPWVvxp268r7qYVKcz28o83239z2S+FW 0uxKsqQHKodqd0ne8/MLMOinQNMjIEownzhIQPnLP6QSAGNKfYyXv9sP0L968z4FOFVJ MMMbipZmGTPu+qEEMmXfIwYiQ0dpqX3gfe1njnltsajs9pe7StsbfvZEZgsCu2Lx6mFP Jz0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1MNxG0MBuxXoRP0yzMBQwe/gUkrdIgmzXLiQx7dmlMM=; b=VR50c726a/yarpkqhiigdLGhmAC5ZZKoqsdMRk8M7lo+REzSz0Qyf/ZHmQSFyF00T4 X1DpOaEKsy0Xjo5871wgflqgrF7CU09mz055A5NfTkqWmLs+LUYM9k1iz75mP8GUunrQ MijiQekVSq2A3rRXk04zwTAYGiyJCDAVEIFE5CuyVUwqM7pZGkB/OCniqzRnv+rxmDik gdbftjgyuxagaUOX8ZQTxpZzVWia2/xI3iamHv54m/pF5ombJwlGWDddgVJMw6Cxslab lCqZOrdj89dV/l7SyAt4FKZfyLHTyqfGd194q9eO//oLSzkC4XzRuWVDQr3Wo9UJXfPw DPDA== X-Gm-Message-State: APjAAAXrdwAyRHVK78f147uLNRtD11GzGaMIlWTrir5vUauKIppMwtIH Y4VdPmbGowHWWc8qnhr83UnXrWrjUJwZidK5b2iBJw== X-Google-Smtp-Source: APXvYqx2ZKzzH4I7zswVJWRCjaI1AKxn8l7UkGiBMS69I62WLQhs0h5e03ktwzxKwUHX/eL4sS+9z5eiY14VfAKdRLE= X-Received: by 2002:a1f:6005:: with SMTP id u5mr47966147vkb.35.1578087079370; Fri, 03 Jan 2020 13:31:19 -0800 (PST) MIME-Version: 1.0 References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk> <41223eeb-4b18-1abb-1d52-26489d8090e3@mti-systems.com> In-Reply-To: <41223eeb-4b18-1abb-1d52-26489d8090e3@mti-systems.com> From: Yuchung Cheng Date: Fri, 3 Jan 2020 13:30:43 -0800 Message-ID: To: Wesley Eddy Cc: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] 793bis: delayed ACKs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 21:31:23 -0000 On Thu, Dec 19, 2019 at 2:06 PM Wesley Eddy wrote: > > Regarding Gorry's comment below, I have an alternative suggestion. I > think the details are discussed well in 5681 > https://tools.ietf.org/html/rfc5681#section-4.2 and that we can simply > point to that for expansion. Beside that, perhaps it is worth some additional text on real practices. With GRO, ACK decimation/compression in the network and in the host, ACKs are greatly stretched (tens of full-size segments) for performance reasons. It would only be more common w/ ever faster networks. > > > On 8/28/2019 11:39 AM, Gorry Fairhurst wrote: > > Section 3.8.6.3 Delayed ACK. > > OLD: > > and in a stream of full-sized segments there > > SHOULD be an ACK for at least every second segment (SHLD-19). > > - Delayed ACK is specified in RFC1122 as: "...and in a stream of > > full-sized segments there SHOULD be an ACK for at least every second > > segment." Although correct, this does not specify a behaviour when > > segments are not "full-sized". When asked by people, I have think this > > should be something like: > > NEW: > > "the receiver SHOULD send an ACK when the data > > needing acknowledgment corresponds to no more than two full-sized > > (MSS) segments." > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Sat Jan 4 02:03:13 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5618712081B for ; Sat, 4 Jan 2020 02:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtKFhwgwSU1r for ; Sat, 4 Jan 2020 02:03:06 -0800 (PST) Received: from mail-vk1-xa29.google.com (mail-vk1-xa29.google.com [IPv6:2607:f8b0:4864:20::a29]) (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 9D180120860 for ; Sat, 4 Jan 2020 02:03:06 -0800 (PST) Received: by mail-vk1-xa29.google.com with SMTP id y184so11330559vkc.11 for ; Sat, 04 Jan 2020 02:03:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Nr6l3xpsKiMZZrsDNbtR7Iuf6to4kmxg34AAhMlD+A8=; b=DDhwfSNrl2fgHQe6v+d6VGsn1B8RVaz9Z0HqGbIaKTX7h3mBZGkbV8yz6oc5vHmK1s U/O4i5ZhNTVq2IBSy3jVklHBnO8b3ebH9YKjbL4IYYw8P3IaivYsBYe86+DfmY2Qdu1I PKJ6kmhGFI94439g7pDMy75dkyZozY6gOq8YGTBgRX3J4phI4yWvVNRiEuUJk97RIjAC cYPywDZIIcnrcw5ayymG94Ut9kuhUv7zA4mt0wMNh2Acjf+TVCN01N+JdN37s8KWTIK8 fgbb/4XM9ASf5ZT/asB8MrdFBsY4SNfljLi02v3+2wADzqN2FWudH1oeVPvKEwoo+YJ+ NcQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Nr6l3xpsKiMZZrsDNbtR7Iuf6to4kmxg34AAhMlD+A8=; b=rW/Cy1LOC/IkR6VlSRqIrbFtkQLaaL5zCqwOIXAQVGTyJqouP8gN4mro5BTdI8tH2w 8oVX+RcWQ3Pd/z0MLHpo8w6IB0dYyaL1D/o2d/vMIcmTRX56mcmsCc7tE6FsPIL5b2HJ +NjwgzUPgQYC0na76vd5H/YRYkN4w+PinA+M9yKtUY2ViYv1GeOhmJNtQw339VLIMUUv qIGLz6FC+bE3uO7HPxsUmsifyM67MdIjBQ6J4Sam6z37VAvA/SRRVB7kTR1cLfCSaWvT 76aJSB711Ob5qLM6Fy6TChoaoa9gpZ7RihY5LiD/HuNOAjs6ZUtdY88w/Yk9g4R6MlU+ OIcw== X-Gm-Message-State: APjAAAUCOmTEJBvGKz5TULdPFmw4EtLgrBCoQ5ItqShSubnuKjgUY21p HJaUfKXB0BqlHHbT4SiMAPtLCas5B4r1zGh1u+2m2w== X-Google-Smtp-Source: APXvYqw6TnD43BgBqUCRDX1vIyYrI75vwNFkiKR+kcPtjbxQmvdcS/twxLvkeh35SC4XDqBnR9+WH9MjKSFcBJBWs6Y= X-Received: by 2002:a1f:ea04:: with SMTP id i4mr48418784vkh.94.1578132185737; Sat, 04 Jan 2020 02:03:05 -0800 (PST) MIME-Version: 1.0 References: <34288421-58db-78ba-2083-f2418f3bff70@bobbriscoe.net> In-Reply-To: <34288421-58db-78ba-2083-f2418f3bff70@bobbriscoe.net> From: Yoshifumi Nishida Date: Sat, 4 Jan 2020 02:02:54 -0800 Message-ID: To: Bob Briscoe Cc: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="00000000000056ecc3059b4d8812" Archived-At: Subject: Re: [tcpm] intended status of draft-ietf-tcpm-accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2020 10:03:12 -0000 --00000000000056ecc3059b4d8812 Content-Type: text/plain; charset="UTF-8" Hi Bob, My intention was the later. For the folks who were not in the room at Singapore meeting. But, of course, people who were there can also express their opinions if they want as it can stimulate other folks to speak up. Thanks, -- Yoshi On Fri, Jan 3, 2020 at 5:48 AM Bob Briscoe wrote: > Yoshi, > > Are you expecting everyone who stuck their hand up at IETF-106 in > Singapore to repeat their opinion? Or is the ML call primarily meant to > look for people with opinions who were not present? So far, the only > opinions on the ML have repeated those in the f2f mtg, for which the > minutes said: > > Yoshi: PS: 8, EXP: 2, don't care: 8 > > In context, "don't care" meant "either" (not "don't care about the draft"). > > To repeat my opinion given verbally: > > - I'm happy with either PS or EXP. > - On balance, PS, 'cos when making a change to the TCP wire protocol > putting EXP or PS in an RFC header doesn't make any difference to whether > the change can be reversed. So, it's better to be clear how serious we have > to be about getting it right. > - Making it PS would make the header flags process faster, and add > weight to the internal corporate cases need to allocate time for > implementing this (and implementing supporting stuff like offload) > - but both those are less important than getting it right. > > > > Bob > > On 03/01/2020 09:17, Yoshifumi Nishida wrote: > > Hello, > > This might be because some folks are on winter break, but it seems that we > don't have much feedback on this. > I am thinking about this a bit and start wondering if this may mean our > general feelings are "either status is fine" or there are some other > reasons. > If this is the case, I am thinking exp status might be suitable as PS > generally requires explicit supports (such as the case for TCP RACK) > If you could provide any opinions or comments, we will appreciate very > much! > > Thanks, > -- > Yoshi > > On Fri, Dec 13, 2019 at 1:17 AM Yoshifumi Nishida > wrote: > >> Hi folks, >> >> We would like to get feedback for the intended status >> of draft-ietf-tcpm-accurate-ecn. >> The current intended status of this draft is experimental, but we've seen >> some voices that PS is more preferable for the draft during Singapore >> meeting and on the ML. So, we would like to check the consensus on it. >> >> There are some on-going related discussions such as flag registration >> policy, SCE, ECN++, etc, however, we believe the intended status >> discussions is independent from them and can proceed it separately. (If you >> have concerns on it, please share your opinion here) >> >> We appreciate your feedback. >> >> Thanks, >> -- >> Yoshi on behalf of tcpm co-chairs. >> >> >> > _______________________________________________ > tcpm mailing listtcpm@ietf.orghttps://www.ietf.org/mailman/listinfo/tcpm > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > --00000000000056ecc3059b4d8812 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bob,

My intention was the= later. For the folks who were not in the room at Singapore meeting.
<= div>But, of course, people who were there can also express their opinions i= f they want as it can stimulate other folks to speak up.

Thanks,
--
Yoshi

On Fri, Jan 3, 2020 at 5:48 AM B= ob Briscoe <in@bobbriscoe.net&g= t; wrote:
=20 =20 =20
Yoshi,

Are you expecting everyone who stuck their hand up at IETF-106 in Singapore to repeat their opinion? Or is the ML call primarily meant to look for people with opinions who were not present? So far, the only opinions on the ML have repeated those in the f2f mtg, for which the minutes said:
Yoshi: PS: 8, EXP: 2, don't care: 8
In context, "don't care" meant "either" (not &q= uot;don't care about the draft").

To repeat my opinion given verbally:
  • I'm happy=C2=A0 with either PS or EXP.
  • On balance, PS, 'cos when making a change to the TCP wire protocol putting EXP or PS in an RFC header doesn't make any difference to whether the change can be reversed. So, it's better to be clear how serious we have to be about getting it right.
  • Making it PS would make the header flags process faster, and add weight to the internal corporate cases need to allocate time for implementing this (and implementing supporting stuff like offload)
  • but both those are less important than getting it right.


Bob

On 03/01/2020 09:17, Yoshifumi Nishida wrote:
=20
Hello,

This might be because some folks are on winter break, but it seems that we don't have much feedback on this.
I am thinking about this a bit and start wondering if this may mean our general feelings are "either status is fine" or there are some other reasons.
If this is the case, I am thinking exp status might be suitable as PS generally requires explicit supports (such as the case for TCP RACK)
If you could provide any opinions or comments, we will appreciate very much!

Thanks,
--
Yoshi

On Fri, Dec 13, 2019 at 1:17 AM Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:
Hi folks,

We would like to get feedback for the intended status of=C2=A0draft-ietf-tcpm-accurate-ecn.=C2=A0
The current intended status of this draft is experimental, but we've seen some voices that PS is more preferable for the draft during Singapore meeting and on the ML. So, we would like to check the consensus on it.

There are some on-going related discussions such as flag registration policy, SCE, ECN++, etc, however, we believe the intended status discussions is independent from them and can proceed it separately. (If you have concerns on it, please share your opinion here)

We appreciate your feedback.

Thanks,
--
Yoshi on behalf of tcpm co-chairs.



_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/tcpm


--=20
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--00000000000056ecc3059b4d8812-- From nobody Wed Jan 8 12:58:15 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F2A12021C for ; Wed, 8 Jan 2020 12:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6DLxeb1UTx9 for ; Wed, 8 Jan 2020 12:58:12 -0800 (PST) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 F0BD812012A for ; Wed, 8 Jan 2020 12:58:11 -0800 (PST) Received: by mail-wm1-x329.google.com with SMTP id b19so417273wmj.4 for ; Wed, 08 Jan 2020 12:58:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=njDPFFOtMgWz2/R01MFqLqlfupMPEP1MQ73Ux2X6Opc=; b=HncYI3Vv4wFcT13h5QeorqchLBEI4s9nr1T73R6uJGKQOeAUzpSf8T1EJ2Jd24e5km 8JBO0pt0WiDQRvz5aob/1XquOcdfCR0Pwj47e/OVQlTHCKdXyLAI2COHiQgxKdV7Qmiq WQpNQPapEvirdFsDlG5m1J1FC3kRPzFS229/pMFJKo+bBhxFIiI+V/NQNBfWhvInpvlD Jdomlt89GahtK1LJFVYCx5hFpSIU6iBY+1t+qOguEspVRsMJyxMQjdMPoz8H/3rLVJ39 gqkKcXdpD0+cuFR9aud0mhXKhqULwSQgVIJzlMmOydCMCf+xRva+N+Io9ShtaxN2293D bfQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=njDPFFOtMgWz2/R01MFqLqlfupMPEP1MQ73Ux2X6Opc=; b=nMtl/eaCW+Qhv4XNilvVhNzf6Af0n3NVJoU0gxgR7vJed+lJMNw48F02A96UGT5FYE /ThO0OxMHTovodNyTj1/86yqM/fTf0gGHgZ//GSc262MViXVA9n9Ph4lzFZZazOc8l+C DMQsydeiQlcMwrQh0FKmu5C5wEuW/C0D5ql+06/qLMtaHJlPZbmdh8nwBuo+a3R3EfC4 iJ0gdT4x+IgR0JdT+iSYSJjVSeB/NHMzXGA7/+BdrvRyWQBzazeDAPZInQh5hNOi915W 1XCHIeltCH54OZ+ZAZtTpuun8XmIywhbB5lrK93OB3AhXCqFTGBUifs/+uBHLWRxVCg3 VjCQ== X-Gm-Message-State: APjAAAVo/1tno3wS0fjfQSpNMnA5BUdcoClKuEC6Mw9zMCSIoE371xAQ /tph7ceWWlEcxQ+/ZF1PLve+8Zopa6ACI24ldDCcHBRe9b8= X-Google-Smtp-Source: APXvYqyCVkHS7bfGW9OCpgMfuZJFHsja75YMP/vy58p3OO5fokn34KPefF6XpZ4rswLL1iO9qOKjuDwXFG3mTGK72z8= X-Received: by 2002:a05:600c:2c13:: with SMTP id q19mr578801wmg.144.1578517090290; Wed, 08 Jan 2020 12:58:10 -0800 (PST) MIME-Version: 1.0 From: Martin Duke Date: Wed, 8 Jan 2020 12:57:58 -0800 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="000000000000705223059ba726ab" Archived-At: Subject: [tcpm] Review: draft-balasubramanian-tcpm-hystartplusplus-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 20:58:14 -0000 --000000000000705223059ba726ab Content-Type: text/plain; charset="UTF-8" Hi Praveen, Thanks for writing this up. It's great to hear what's actually happening out there with major implementations. 1. I think this draft has a somewhat uncomfortable relationship with ABC (RFC 3465), which for some reason is still Experimental. In each description of Slow Start (Sec 1 and 3.2) you say one MSS per ack, which is the non-ABC Reno behavior. But then the actual LSS algorithm uses bytes counted. Note that for a non-ABC implementation that also uses HyStart++, this means an LSS_DIVISOR as low as 0.5 can cause LSS to be *more* aggressive than regular slow start if the receiver acks every other packet. In the non-RFC but common case where ACKs are aggregated even more aggressively, LSS can be more aggressive than slow start for arbitrarily low divisor values. I'm not sure the design has to change, but there ought to be some discussion of these considerations. 2. in section 3.2, you set the ssthresh to cwnd upon entering LSS. But then later you say "HyStart++ ends when cwnd exceeds ssthresh..." which by definition is immediately. I think you mean the normal Reno/Cubic ssthresh; perhaps it would be better to invent a new name for the value that is used in computing K. Similarly, I don't believe MIN_SSTHRESH has any relationship to the conventional ssthresh (i.e. it is not a minimum) and therefore should also be renamed. 3. Section 3.3 could use some further considerations for setting these parameters. In particular, values of LSS_DIVISOR > 1 will be more aggressive than slow start, at least for low values of cwnd/ssthresh. Depending on the result of #1 above, the warning may need to be for a lower value. 4. Though not necessary to make this draft worthwhile, some data from Microsoft's deployment showing the value of this would be helpful. If I were to try to sell this feature to our customers, they would probably want to see that it was providing benefits to large traffic generators rather than backing off for the good of the internet. In particular, I wonder whether Reno/Cubic is fair to Hystart++ as regular slow start would seem to cause LSS to cut the throttle. Nits: - Please spell out SMSS before using it. - Title of 3.3: s/Constant/Constants - 3.3. You are little sloppy with units. MIN_SSTHRESH is clearly measured in bytes in Sec 3.2 but is reported in segments in this section. Martin --000000000000705223059ba726ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Praveen,

Thanks for writi= ng this up. It's great to hear what's actually happening out there = with major implementations.

1. I think this draft = has a somewhat uncomfortable relationship with ABC (RFC 3465), which for so= me reason is still Experimental. In each description of Slow Start (Sec 1 a= nd 3.2) you say one MSS per ack, which is the non-ABC Reno behavior. But th= en the actual LSS algorithm uses bytes counted.

No= te that for a non-ABC implementation that also uses HyStart++, this means a= n LSS_DIVISOR as low as 0.5 can cause LSS to be *more* aggressive than regu= lar slow start if the receiver acks every other packet. In the non-RFC but = common case where ACKs are aggregated even more aggressively, LSS can be mo= re aggressive than slow start for arbitrarily low divisor values. I'm n= ot sure the design has to change, but there ought to be some discussion of = these considerations.

2. in section 3.2, you set the ssthresh to cwnd upon entering LSS. But= then later you say "HyStart++ ends when cwnd exceeds ssthresh..."= ; which by definition is immediately. I think you mean the normal Reno/Cubi= c ssthresh; perhaps it would be better to invent a new name for the value t= hat is used in computing K.

Similarly, I don'= t believe MIN_SSTHRESH has any relationship to the conventional ssthresh (i= .e. it is not a minimum) and therefore should also be renamed.

3. Section 3.3 could use some further considerati= ons for setting these parameters. In particular, values of LSS_DIVISOR >= 1 will be more aggressive than slow start, at least for low values of cwnd= /ssthresh. Depending on the result of #1 above, the warning may need to be = for a lower value.

4. Though not necess= ary to make this draft worthwhile, some data from Microsoft's deploymen= t showing the value of this would be helpful. If I were to try to sell this= feature to our customers, they would probably want to see that it was prov= iding benefits to large traffic generators rather than backing off for the = good of the internet. In particular, I wonder whether Reno/Cubic is fair to= Hystart++ as regular slow start would seem to cause LSS to cut the throttl= e.

Nits:
- Please spell out SMSS bef= ore using it.
- Title of 3.3: s/Constant/Constants
- 3.3. You are little sloppy with units. MIN_SSTHRESH is clearly mea= sured in bytes in Sec 3.2 but is reported in segments in this section.

Martin
--000000000000705223059ba726ab-- From nobody Thu Jan 9 13:28:03 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1337712081C; Thu, 9 Jan 2020 13:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 uhPVNWso4XFC; Thu, 9 Jan 2020 13:27:58 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 B648512080F; Thu, 9 Jan 2020 13:27:54 -0800 (PST) Received: from 200116b82ca13800f0693c898e4dd303.dip.versatel-1u1.de ([2001:16b8:2ca1:3800:f069:3c89:8e4d:d303]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ipfLK-0004rG-7T; Thu, 09 Jan 2020 22:27:50 +0100 From: Mirja Kuehlewind Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <4DF47B41-2A8F-4FC1-8734-4D133F3EBBE5@kuehlewind.net> Date: Thu, 9 Jan 2020 22:27:49 +0100 Cc: tcpm IETF list To: draft-ietf-tcpm-converters.all@ietf.org X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1578605277;455956c6; X-HE-SMSGID: 1ipfLK-0004rG-7T Archived-At: Subject: [tcpm] AD review of draft-ietf-tcpm-converters-14 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 21:28:01 -0000 Hi authors, I finally did my AD review for draft-ietf-tcpm-converters-14 (actually = I'm still not fully finished with the review of the appendix but would = like to send out this first batch of questions now). As you can see below, I have a whole bunch of questions/comments. Some = of these may only be editorial in the end but I would like to make sure = that I understand all the technical parts correctly before we move on = with the processing.=20 I think there are basically two main technical points I would like to = get some clarification on, both probably related to things that have = been introduced later in the life time of the doc but maybe not = consequently been changed throughout the whole doc.=20 One is besiaclly point 8 below but there are some related other points = below: It is not fully clear which packets can carry Convert messages. I = think initially Convert messages were only supposed to be in the SYN and = SYN/ACK. But then later you enabled it also for other packets, however, = it seem the only real case that needs this is when an error message is = send by the client. But sending Convert messages in other packet than = the SYN and the SYN/ACK seems more complicated because all TCP payload = data is transmitted reliable and must be ack'ed and evil. retransmitted. = Maybe it=E2=80=99s okay if only an error message is send and a reset = right after (so no retransmission), however, this is not specified, and = I wonder if the complexity is really needed worth the benefit of being = able to log more concrete errors in the converter. The other point is basically point 12 below about the TCP option field = in the Connect TLV (also related to point 17 below). This is not well = enough specified and seem also quite complex as a generic mechanism. I = would think the converter should usually try to use the same option as = the client did send in his SYN to the converter, if supported by the = converter TCP implementation. The TFO cookie might be a special case. = I=E2=80=99m not sure if that needs to be generalised or if having a = separate TLV for that one case might be simpler. Please also reconsider = this but in any case it needs more explanation in the spec. Please see all my questions/comments below. I may send another message, = when I have reviewed the appendix tomorrow (hopefully with none or only = few additional comments). Thanks! Mirja ---------------------- 1) I was initially a bit confused about the setup in Figure 6 and = respectively the paragraph just before that figure in sec 3.2: It wasn't = clear to me how the server might know the converter address (or if the = proxy maybe has to be on path). I assume the =E2=80=9Cuse case=E2=80=9D = is that there was a previous connection using the converter and now the = server tries to reconnect but of course only knows the converter = address, or something? Maybe you could add slightly more text here. I = also I would recommend to explicitly mention that this setup still has = to be explicitly configured by the client but using an out of band = protocol (which is out or scope for this spec). Further I think it would = be good to mention here already that the converter also inserts the = respective TCP option in the SYN to the client (if possible due to space = limits) and refer to section 4.2 for a concrete example. Btw. shouldn't there be some discussion about MTU issue if options are = added by the converter? 2) The following paragraph in section 3.2. seems to specify protocol = requirements but don=E2=80=99t use normative language: "If the downstream (or upstream) connection fails for some reason (excessive retransmissions, reception of an RST segment, etc.), then the Converter should force the tear-down of the upstream (or downstream) connection. The same reasoning applies when the upstream connection ends. In this case, the Converter should also terminate the downstream connection by using FIN segments. If the downstream connection terminates with the exchange of FIN segments, the Converter should initiate a graceful termination of the upstream connection.=E2=80=9D I recommend to use normativen language here (SHOULD instead of should; = or maybe even MUST?). However, as this text is part of a kind of = overview section, it doesn=E2=80=99t seem to be a really good fit to use = normative language in that section. So maybe the whole discussion about = use of TFO (or not) should be moved to an own section? 3) Just to double-check, I'm wondering a bit about this phrasing in sec = 3.3.1: "If no entry is found, the Transport Converter MUST silently ignore the packet.=E2=80=9D That means the converter will drop the packet (with no other action), = right? Why do you use term ignore here (instead of drop or discard)? Or = does this have any other implication? Note that this term is used several times in the doc. 4) Also a quick question about this in sec 3.3.1: "A Transport Converter may operate in address preservation mode (that is, the Converter does not rewrite the source IP address (i.e., C=3D=3DT)) or address sharing mode (that is, an address pool is = shared among all Clients serviced by the Converter (i.e., C!=3DT)); refer to Appendix D for more details. Which behavior to use by a Transport Converter is deployment-specific.=E2=80=9D I guess preservation mode can only be used if the converter is on path. = I think that should be explicitly noted here.=20 5) Sec 3.3.2: To be honest I=E2=80=99m not sure I fully understand this = section, especially this sentence: "Upon receipt of a secondary subflow by the Transport Converter from a Client, the Converter follows the same behavior specified in Section 3.3.1 for processing Non-SYNs.=E2=80=9D Do you mean by "receipt of a secondary subflow=E2=80=9D the SYN on that = subflow or other data? For the SYN I would expect that there is no = payload data and therefore nothing to proxy. For other subflow packets, = I guess you need to reorder first, so probably it would be good to = mention that=E2=80=A6? Maybe it=E2=80=99s just me misunderstanding = something but I believe more explanation is needed here. 6) Can you maybe add some more text (in section 5 maybe) why a separate = port number is used/needed? As the client has to be explicitly = configured it could easily be configured with an address and port = number. Is this to avoid collisions with other protocols? What would be = the scenario here? 7) Sec 5.1: "The Unassigned field MUST be set to zero in this version of the protocol. These bits are available for future use [RFC8126].=E2=80=9D Why is there a reference to RFC8126 here? 8) Also sec 5.1 but probably editorial: "Data added by the Convert Protocol to the TCP bytestream is unambiguously distinguished from payload data by the Total Length field in the Convert messages.=E2=80=9D I believe what you want to say here is that the total length is used to = figure out where potential other payload data might start. However, what = I would understand from this sentence is that the total length field can = be used to distinguish SYNs that carry the Convert protocol from SYNs = that may carry other payload only, which I don=E2=80=99t think is the = case. 8) I first have a more general question about the function of the = protocol. Sec 5 says: "Convert messages may appear only in a SYN, SYN+ACK, or ACK.=E2=80=9D I=E2=80=99m not sure I understand the ACK case here because if you add a = CONVERT message to a TCP packet that means you add payload data. I was = reading this as pure ACK but that can't be the case. So do you mean by = this you can only send new data if your previous data was ACK or = something else=E2=80=A6? However, I believe there is usually just one message from the client in = the SYN and the one message from the converter in the SYN/ACK, and then = the connection is either closed or switched to the actual payload = transmission. So I was assuming that's the only communication pattern = you can have. Or is the idea that multiple client-converter exchanges = can be done on the same TCP connection also after the TCP handshake and = then any time in the connection you would be able to switch over to = sending other payload data? I think this need further clarification in = the draft. Note that section 7 also say: "In this section, we only discuss the middleboxes that modify SYN and SYN+ACK packets since the Convert Protocol places its messages in such packets.=E2=80=9D 9) This point is probably related to the previous point. In section 5.1 = you say that the connection MUST be reset (if length is zero) but in all = other sections you say the connection must be closed if there is a = problem. Assuming the Convert protocol will only be used in SYN and = SYN/ACK, reset is probably more appropriate. If it can be used also in = later packets you probably have to say something like =E2=80=9Cclose or = reset if the handshake is not completed=E2=80=9D=E2=80=A6?=20 E.g. see sec 5.2.1: "If two or more instances of the same TLV are exchanged over a Convert connection, the associated TCP connections MUST be closed.=E2=80=9D Is that close or reset?=20 Also related: The next section (5.2.2) says: "Type 0x0 is a reserved valued. Implementations MUST discard messages with such TLV.=E2=80=9D (Nit s/valued/value/) And in sec 5.2.5: "Connect TLVs witch such messages MUST be discarded by the Transport Converter." I guess every time you say in the document that a message is discarded = that would also lead somehow to closing the connection most likely by = to sending a reset, no? Or should the SYN just be drop and no reply send = for any reason? Please clarify. 10) Probably editorial in sec 5.2.4: "A Transport Converter SHOULD include in this list the TCP options that it accepts from Clients; these options are included by the Transport Converter in the SYN packets that it sends to initiate connections.=E2=80=9D I had to read the second half twice because it suddenly talks about a = completely different =E2=80=9Cscenario=E2=80=9D than replying to an Info = TLV. Maybe some rewording could help a bit like "A Transport Converter SHOULD include in this list the TCP options that it accepts from Clients; these options are also included by the Transport Converter in the SYN packets if it initiates connections to the client.=E2=80=9D Or maybe even use normative language here:=20 =E2=80=9Cthe Transport Convert SHOULD also include the same option in = the SYN if=20 it initiates a connection to the client.=E2=80=9D 11) sec 5.2.5: Maybe also be slightly more clear here: "For incoming connections destined to a Client serviced via a Transport Converter, these fields convey the source port number and IP address.=E2=80=9D Proposed "For incoming connections destined to a Client serviced via a Transport Converter, these fields convey the source port number and IP address of the SYN packet received by the=20 Transport Converter from the server.=E2=80=9D 12) I have a couple of question about the TCP options field in the = Connect TLV, basically this text in section 5.2.5: " Upon reception of a Connect TLV, and absent any policy (e.g., rate- limit) or resource exhaustion conditions, a Transport Converter attempts to establish a connection to the address and port that it contains. The Transport Converter MUST use by default the TCP options that correspond to its local policy to establish this connection. These are the options that it advertises in the Supported TCP Extensions TLV. Bonaventure, et al. Expires May 7, 2020 [Page 22] Internet-Draft Convert Protocol November 2019 Upon reception of an extended Connect TLV, and absent any rate limit policy or resource exhaustion conditions, a Transport Converter MUST attempt to establish a connection to the address and port that it contains. It MUST include the options of the 'TCP Options' sub-field in the SYN sent to the Server in addition to the TCP options that it would have used according to its local policies. For the TCP options that are listed without an optional value, the Transport Converter MUST generate its own value. For the TCP options that are included in the 'TCP Options' field with an optional value, it MUST copy the entire option for use in the connection with the destination peer. This feature is required to support TCP Fast Open.=E2=80=9D First of all the upper paragraph is probably old and should have been = removed, right? Then I=E2=80=99m not certain about the new approach with the TCP option = field. If the converter actually ends up in a split connection (with = e.g. MPTCP on client side but without it on server side), I thought it = can only announce those options in the SYN to the server that are = actually implemented in the converter and it will be able to support = later in the connection. So blindly copying the options provided by the = client doesn=E2=80=99t seem right. Or what do I miss? I understand the case where you want to use TFO between the client and = the convert but can=E2=80=99t use it anymore between the the client and = the server then. However you can only use TFO with the second connection = you make to a server. So in the first connection either TFO was used = between the convert and the server and the convert could now use it = again with the cookie it received or TFO was used end-to-end in the = first connection and it now clear to me why the converter is used now. = Maybe I=E2=80=99m missing something but I think the drafts would at = least need more explanation about the motivation to have this. If it=E2=80=99s really only about TFO cookies and we are sure we want to = have that feature, maybe an own TLV would be simpler? 13) In sec 5.2.6 do you mean by "extended TCP header=E2=80=9D the TCP = option space? I=E2=80=99m not sure that "extended TCP header=E2=80=9D is = a clearly defined term; as least I=E2=80=99m not 100% sure what you = mean=E2=80=A6 14) nit in sec 5.2.7: s/The Cookie TLV (Figure 20 is an optional/The Cookie TLV (Figure 20) is = an optional/ -> missing closing bracket 15) Sec 5.2.7: Question about normative language: "If the received SYN did not contain a Cookie TLV, and cookie validation is required, the Transport Converter should compute a Cookie bound to this Client address and return a Convert message containing the fixed header, an Error TLV set to "Missing Cookie" and the computed Cookie and close the connection.=E2=80=9D Is this maybe a MAY condition? All of it? Or something like this "If the received SYN did not contain a Cookie TLV, and cookie validation is required, the Transport Converter MAY compute a Cookie bound to this Client address. It MUST return a Convert message containing the fixed header and Error TLV set to "Missing Cookie=E2=80=9D= and MAY add the computed Cookie. After sending the Error TLV is MUST/SHOULD = close/reset =20 the connection.=E2=80=9D Not fully sure what is the intention here=E2=80=A6 15) sec 5.2.8: What's the purpose of the client sending an Unsupported Version error? = If the converter replies with a different version than requested used by = the client, that's simply a fatal error/implementation error and the = client can only reset the connection I think. More generally if I read this correctly there are only 3 errors that = could be sent by the client. I guess those errors would be send in the = first packet after the SYN/ACK is received=E2=80=A6? Related to my = question above, I think it would be much easier to only have Convert = message in the SYN and SYN/ACK and no explicit error message from the = client. Otherwise more explanation in the draft would be need how this = actually is supposed to work. 16) sec 5.2.8: "A Client which receives this error code MUST cache the received Cookie and include it in subsequent Convert messages sent to that Transport Converter.=E2=80=9D This seems to be a slightly weird normative MUST. Sure you have to cache = the cookie in oder to be able to use the converter, however, there may = be cases where you loose the cache and then sending a Connect without = the cookie to get a new Cookie is a valid option. So you may use SHOULD = here or even better reword it completely... 17) There is an Unsupported TCP Option in section 5.2.8. However, this = error is not mentioned in 5.2.5. In contrast sec 5.2.5 says that the = converter MUST open a connection and MUST use these options. This is = related to my point 12 above but it was not clear to me that options can = be rejected, however, this whole part seems to make the protocol really = complicated and as I said if the only use case is TFO I would prefer to = rather have a separate specific TLV for that case only. 18) I think section 6.7 should still say something about if this option = is supported or not=E2=80=A6 19) section 7: "Consider a middlebox that removes the SYN payload. The Client can detect this problem by looking at the acknowledgment number field of the SYN+ACK returned by the Transport Converter. The Client MUST stop to use this Transport Converter given the middlebox interference.=E2=80=9D If the converter received a SYN without a Convert message in the payload = on the respective port, it is supposed to anyway send a SYN/ACK? I would = assume it would rather send a RESET, no? I think that needs to be = further specified. 20) Sec 7 also says: =E2=80=9CIf an Error was returned by the Transport Converter, a message = to close the connection would normally follow from the Converter.=E2=80=9D However sec 5.2.8 says: "Upon reception of an Error TLV, a Client MUST close the associated connection.=E2=80=9D I assume one of these is not correct=E2=80=A6 please clarify which end = is suppose to do what in case of an error. 21) The text in sec 7 then further says: "If no such message is received, the Client may continue to use this = Converter.=E2=80=9D Isn=E2=80=99t that a bit dangerous? =20 22) section 8.5: Why are the authentication mechanism discussed in this = section MPTCP specific? I think the same mechanisms could also be = applied to Converters supporting other options, no? 23) sec 8.3: "Means to protect against SYN flooding attacks MUST also be enabled = [RFC4987].=E2=80=9D Not sure if the use of MUST is clear here. Which part of RFC4987 does = this MUST relate to? All of it? Maybe a SHOULD or no normative language = is more appropriate? 24) sec 9.2: Maybe call the new registry the "The TCP Convert Protocol = (Convert) Parameters=E2=80=9D (TCP added)=E2=80=A6? 25) sec 9.2.2: "The values in the range 192-255 can be assigned for Private Use.=E2=80=9D= IANA does not assigned any value for Private use, they can just be used, = so this should be "The values in the range 192-255 are reserved for Private Use.=E2=80=9D if that is what you want? 26) also on section 9.2.X: "Specification Required" includes having an = expert review and RFC8126 says: "As with Expert Review (Section 4.5), clear guidance to the designated expert should be provided when defining the registry, and thorough understanding of Section 5 is important.=E2=80=9D So please provide further guidance about what the expert is supported to = evaluate.=20 27) Not sure if the following references need to be normative as there = no normative requirement connect to them but only an optional case is = discussed: RFC4279, RFC7250 =E2=80=A6? However, RFC7323, RFC2018, RFC6978, RFC6978, RFC2827, RFC6181 should = probably be normative references=E2=80=A6? 28) The term =E2=80=9Cexperimental option=E2=80=9D is used with two = different meaning in the intro of section 6 (options that are defined in = an exp RFC) and in section 6.9 (options with kind 254 and 255). Please = clarify this at both places. From nobody Thu Jan 9 16:08:17 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C9E120131; Thu, 9 Jan 2020 16:08:14 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qPI5yr0T0Zs; Thu, 9 Jan 2020 16:08:12 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 C180312003E; Thu, 9 Jan 2020 16:08:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1578614885; bh=/RbmiNMaH9Bz5g2JviXI+FLLZ69+rFvYJuavL4g6/hE=; h=X-UI-Sender-Class:To:From:Subject:Date; b=ZoqseahJmMUmiOB+BLJuybtA2+OZ/s8BolyxD3/cHVR5s7e1Oy2Chqw/GvuFOJy1q vfLyVrw9uBCj4sSHMR10Ts36tkXyYCZhXENrm92MPYmSPGB/RGjPBqywrvPsxYA/VD qmX3Uk9Sn9vn7DOg5vNmNhakWYQVm0oAeZfJtXYE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.233.110] ([185.236.167.136]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MmULr-1jXKJo0F1d-00iVbW; Fri, 10 Jan 2020 01:08:05 +0100 To: "tcpm@ietf.org" , draft-ietf-tcpm-generalized-ecn@ietf.org From: "Scheffenegger, Richard" Message-ID: <6f6f4c2f-b72f-b7fb-55aa-c6985862d061@gmx.at> Date: Fri, 10 Jan 2020 01:08:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:UA/nNMEced2UMdc1Uaf44NPNGHuQGE5KyFiMSLG7rLMk6HDjk31 buxzh1RY1milbK/N/L5fT6FBbVdrfIAYvytIMeq7Icb9PS11Rf9rYxKBSaqIF4sQYBlPAMu CpJ5uUDU5566p5ZPOHi+H6fRKqc/lv/gZzDir3ESek8DlfSeAleY9Bo8i2Xho683Y7XvEM7 R/zvSP4rCw8XNQgoQBF5w== X-UI-Out-Filterresults: notjunk:1;V03:K0:+izLSlPaBW8=:38su22c8jKpyJ7s2JeXqys kgpIxlbhuk6N+0uXbnLbABXPn88kDWxYV0Vvbm2zFQSv/RFGNUZ8PsqrL5wQ8+cPOLqP9VLDM oT2VfYvWuwIT0ouGrsJAV5V7XpYxRCexZhmZLsV49dPimM904bYV2vMM5enjVAUxVVglS3RNS wQg3r4bCZZHhR8Y/U9+9TDdEzqg+0NfjlqNWD0FC79GnC5BNojcwL1HQUnI4wMNlSCTdAy2F5 rdCeDwfEZIQD0syFun1vKFyCnfpw9W2baeDARBvurV7WyaRkyHoqe5RTunwXqcDI9FtFcWbs9 rOF0W0RoCSeDIY1OMuU4RiXncST17CgXaGrltj9CZi9SPGXkMwnMirQwTcXM4v0Pyv252AX8G lnEWxVlL+Ckz6w2tXIiVazfB2atgwthDqJQ0PSW5SfaRYG5xgeJghzn8RyzBsfJRr5vXgpA6a QDZEbkjmFhxh3XtFoKTiKYJE9P+w5gfy5JrJYbZYgEWAcljaQXWwDzOzmx6GrDugBmvJHG80z 7b4B/5408lLdLjdBQ+bbYkR3Yt+qQLyMGysUOJKlatoEU6Ty7XmP7dJseOo6aUyFa3zRYcIJN s/ND+A+P44yn6sAQ6e3KHxaNfUcUUKqx872QuR4KTe+JJh359+PpF1CtqonFfz5cJwbP13o15 gUKcKemH/i7xnWQA4MR8s8txchNwqzJprRefJSyLxplIKBftLFW2H7aSuke3+ri63r/Pwyg5W PejCSBl9IEpFyV5ZMl1e9+Fw6lzIPxYdKOMZDkjOlxywlZISUNlfFri6v0J8jKonQOqk9oiYb 6dijtoesYmykErVFmZdM0W2uC5NZTY1AQKszWH3pRdDxRTLSsGd58lk0PVLFsqYiDKMZYKqsp /GLXqlWqbSG3hZsj4pojZevP11Vs+oTUQgeNtasO805ZEHX72mFT0syDkFv766ZOVrSQr21oH rwcJgKUG2dzCztxD+F+JUqeD7t7u+ztmwf7GC+MbGnBDGMRePNMZ5U3nP7xVpMoHDyKIvhJIy h5uo95x6sCpyq60CAIOktvgTDYHsWRw8y+8cvt1K0ytL+w9d/Y4o1jcqGRrmYxKzXowW+gTAq fKVf1GjEj9W1jn6KffjuTAPQEgcqMTlWe4HwS3EZBRuF1pwFIOb4tiqYBF6AgvPCTj0p+Sgnh I7a1TRDyzYhk2IM5FKetF1f811G5846NaIZ79hAlLtwV7W5I7kyaQoSP2Gr7sTaGf2/kmxH92 3e6eOmTz3CMETfaaDhLrNUi95hwnZstNNWEzbNA== Archived-At: Subject: [tcpm] ECN++ X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 00:08:14 -0000 Marcelo, Bob, I just noted that there is a slight oversight in FreeBSD currently, which results in all session that are simultaneously ECN-enabled and SACK-permitted to effectively send out retransmissions with the ECT0 codepoint. Strictly speaking, this is in violation of RFC3168, but might also be a good (nearly a decade long) validation of the performance of ECN++ for all types of data segments (new and retransmitted ones), although at a low and implicit exposure... On that note, since I think ECN++ is quite valuable (with a number of published research finding this change to be crucial), perhaps you can summarize the outstanding issues (other than more reviewers required; I admit I still haven't gone through all the delta between -04 and -05). Best regards, Richard From nobody Fri Jan 10 06:48:05 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5501C1208F1; Fri, 10 Jan 2020 06:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwT3tqVLcF0y; Fri, 10 Jan 2020 06:47:51 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 77BC01200FF; Fri, 10 Jan 2020 06:47:51 -0800 (PST) Received: from 200116b82cafa900d8adddaba4a4c379.dip.versatel-1u1.de ([2001:16b8:2caf:a900:d8ad:ddab:a4a4:c379]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ipvZl-0007pb-OR; Fri, 10 Jan 2020 15:47:49 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <4DF47B41-2A8F-4FC1-8734-4D133F3EBBE5@kuehlewind.net> Date: Fri, 10 Jan 2020 15:47:49 +0100 Cc: tcpm IETF list Content-Transfer-Encoding: quoted-printable Message-Id: <52F7B691-AB5F-4C63-BC8D-CFB5E569D085@kuehlewind.net> References: <4DF47B41-2A8F-4FC1-8734-4D133F3EBBE5@kuehlewind.net> To: draft-ietf-tcpm-converters.all@ietf.org X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1578667671;41ecfb7b; X-HE-SMSGID: 1ipvZl-0007pb-OR Archived-At: Subject: Re: [tcpm] AD review of draft-ietf-tcpm-converters-14 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 14:48:03 -0000 Hi again, Of course if have more question/comments. However these are easy ones: = one nit, and two question about why the text is in the appendix :-) One more thought: Looking at the SOCKS6 document again, I think what you = have defined here, can actually be seen as a light-weight SOCKS. I think = that=E2=80=99s fine but maybe it would be better to acknowledge it this = way=E2=80=A6? There will also be reviews by the INT ADs in IESG = Evaluation and I don=E2=80=99t think this has been otherwise reviewed by = any INT area working group yet, right? After all thanks for a well-written document and also for the good = shepherd write-up! Mirja -------------------- 1) Appendix B.1: " o 0x4: (client) send data in the opening SYN regardless of cookie availability and without a cookie option. By setting this configuration variable to 0x5, a Linux client using the above code would send data inside the SYN without using a TFO option.=E2=80=9D 0x4 or 0x5 ? 2) This is fully editorial, but given appendix C is really short, I = think this could have also be just be place somewhere in the body of the = document like e.g. in section 5.2.7 or the intro text in section 5. 3) Further I also don=E2=80=99t fully see why appendix D is in the = appendix. I think most of this is mentioned in the body of the document = already but in less detail which makes it actually harder to understand = (in think I had at least one question to this below). I think having = this text as subsections in 3.3. would actually be helpful to understand = the usage better. > On 9. Jan 2020, at 22:27, Mirja Kuehlewind = wrote: >=20 > Hi authors, >=20 > I finally did my AD review for draft-ietf-tcpm-converters-14 (actually = I'm still not fully finished with the review of the appendix but would = like to send out this first batch of questions now). >=20 > As you can see below, I have a whole bunch of questions/comments. Some = of these may only be editorial in the end but I would like to make sure = that I understand all the technical parts correctly before we move on = with the processing.=20 >=20 > I think there are basically two main technical points I would like to = get some clarification on, both probably related to things that have = been introduced later in the life time of the doc but maybe not = consequently been changed throughout the whole doc.=20 >=20 > One is besiaclly point 8 below but there are some related other points = below: It is not fully clear which packets can carry Convert messages. I = think initially Convert messages were only supposed to be in the SYN and = SYN/ACK. But then later you enabled it also for other packets, however, = it seem the only real case that needs this is when an error message is = send by the client. But sending Convert messages in other packet than = the SYN and the SYN/ACK seems more complicated because all TCP payload = data is transmitted reliable and must be ack'ed and evil. retransmitted. = Maybe it=E2=80=99s okay if only an error message is send and a reset = right after (so no retransmission), however, this is not specified, and = I wonder if the complexity is really needed worth the benefit of being = able to log more concrete errors in the converter. >=20 > The other point is basically point 12 below about the TCP option field = in the Connect TLV (also related to point 17 below). This is not well = enough specified and seem also quite complex as a generic mechanism. I = would think the converter should usually try to use the same option as = the client did send in his SYN to the converter, if supported by the = converter TCP implementation. The TFO cookie might be a special case. = I=E2=80=99m not sure if that needs to be generalised or if having a = separate TLV for that one case might be simpler. Please also reconsider = this but in any case it needs more explanation in the spec. >=20 > Please see all my questions/comments below. I may send another = message, when I have reviewed the appendix tomorrow (hopefully with none = or only few additional comments). >=20 > Thanks! > Mirja >=20 > ---------------------- >=20 > 1) I was initially a bit confused about the setup in Figure 6 and = respectively the paragraph just before that figure in sec 3.2: It wasn't = clear to me how the server might know the converter address (or if the = proxy maybe has to be on path). I assume the =E2=80=9Cuse case=E2=80=9D = is that there was a previous connection using the converter and now the = server tries to reconnect but of course only knows the converter = address, or something? Maybe you could add slightly more text here. I = also I would recommend to explicitly mention that this setup still has = to be explicitly configured by the client but using an out of band = protocol (which is out or scope for this spec). Further I think it would = be good to mention here already that the converter also inserts the = respective TCP option in the SYN to the client (if possible due to space = limits) and refer to section 4.2 for a concrete example. >=20 > Btw. shouldn't there be some discussion about MTU issue if options are = added by the converter? >=20 > 2) The following paragraph in section 3.2. seems to specify protocol = requirements but don=E2=80=99t use normative language: >=20 > "If the downstream (or upstream) connection fails for some reason > (excessive retransmissions, reception of an RST segment, etc.), then > the Converter should force the tear-down of the upstream (or > downstream) connection. >=20 > The same reasoning applies when the upstream connection ends. In > this case, the Converter should also terminate the downstream > connection by using FIN segments. If the downstream connection > terminates with the exchange of FIN segments, the Converter should > initiate a graceful termination of the upstream connection.=E2=80=9D >=20 > I recommend to use normativen language here (SHOULD instead of should; = or maybe even MUST?). However, as this text is part of a kind of = overview section, it doesn=E2=80=99t seem to be a really good fit to use = normative language in that section. So maybe the whole discussion about = use of TFO (or not) should be moved to an own section? >=20 >=20 > 3) Just to double-check, I'm wondering a bit about this phrasing in = sec 3.3.1: > "If no entry is found, the Transport Converter MUST silently > ignore the packet.=E2=80=9D > That means the converter will drop the packet (with no other action), = right? Why do you use term ignore here (instead of drop or discard)? Or = does this have any other implication? > Note that this term is used several times in the doc. >=20 > 4) Also a quick question about this in sec 3.3.1: > "A Transport Converter may operate in address preservation mode (that > is, the Converter does not rewrite the source IP address (i.e., > C=3D=3DT)) or address sharing mode (that is, an address pool is = shared > among all Clients serviced by the Converter (i.e., C!=3DT)); refer = to > Appendix D for more details. Which behavior to use by a Transport > Converter is deployment-specific.=E2=80=9D > I guess preservation mode can only be used if the converter is on = path. I think that should be explicitly noted here.=20 >=20 > 5) Sec 3.3.2: To be honest I=E2=80=99m not sure I fully understand = this section, especially this sentence: > "Upon receipt of a secondary subflow by the Transport Converter from a > Client, the Converter follows the same behavior specified in > Section 3.3.1 for processing Non-SYNs.=E2=80=9D > Do you mean by "receipt of a secondary subflow=E2=80=9D the SYN on = that subflow or other data? For the SYN I would expect that there is no = payload data and therefore nothing to proxy. For other subflow packets, = I guess you need to reorder first, so probably it would be good to = mention that=E2=80=A6? Maybe it=E2=80=99s just me misunderstanding = something but I believe more explanation is needed here. >=20 > 6) Can you maybe add some more text (in section 5 maybe) why a = separate port number is used/needed? As the client has to be explicitly = configured it could easily be configured with an address and port = number. Is this to avoid collisions with other protocols? What would be = the scenario here? >=20 > 7) Sec 5.1: > "The Unassigned field MUST be set to zero in this version of the > protocol. These bits are available for future use [RFC8126].=E2=80=9D= > Why is there a reference to RFC8126 here? >=20 > 8) Also sec 5.1 but probably editorial: > "Data added by the Convert Protocol to the TCP bytestream is > unambiguously distinguished from payload data by the Total Length > field in the Convert messages.=E2=80=9D > I believe what you want to say here is that the total length is used = to figure out where potential other payload data might start. However, = what I would understand from this sentence is that the total length = field can be used to distinguish SYNs that carry the Convert protocol = from SYNs that may carry other payload only, which I don=E2=80=99t think = is the case. >=20 > 8) I first have a more general question about the function of the = protocol. Sec 5 says: > "Convert messages may appear only in a SYN, SYN+ACK, or ACK.=E2=80=9D > I=E2=80=99m not sure I understand the ACK case here because if you add = a CONVERT message to a TCP packet that means you add payload data. I was = reading this as pure ACK but that can't be the case. So do you mean by = this you can only send new data if your previous data was ACK or = something else=E2=80=A6? > However, I believe there is usually just one message from the client = in the SYN and the one message from the converter in the SYN/ACK, and = then the connection is either closed or switched to the actual payload = transmission. So I was assuming that's the only communication pattern = you can have. Or is the idea that multiple client-converter exchanges = can be done on the same TCP connection also after the TCP handshake and = then any time in the connection you would be able to switch over to = sending other payload data? I think this need further clarification in = the draft. >=20 > Note that section 7 also say: > "In this section, we only discuss > the middleboxes that modify SYN and SYN+ACK packets since the = Convert > Protocol places its messages in such packets.=E2=80=9D >=20 > 9) This point is probably related to the previous point. In section = 5.1 you say that the connection MUST be reset (if length is zero) but in = all other sections you say the connection must be closed if there is a = problem. Assuming the Convert protocol will only be used in SYN and = SYN/ACK, reset is probably more appropriate. If it can be used also in = later packets you probably have to say something like =E2=80=9Cclose or = reset if the handshake is not completed=E2=80=9D=E2=80=A6?=20 >=20 > E.g. see sec 5.2.1: > "If two or more > instances of the same TLV are exchanged over a Convert connection, > the associated TCP connections MUST be closed.=E2=80=9D > Is that close or reset?=20 >=20 > Also related: > The next section (5.2.2) says: > "Type 0x0 is a reserved valued. Implementations MUST discard messages > with such TLV.=E2=80=9D > (Nit s/valued/value/) > And in sec 5.2.5: > "Connect TLVs witch such messages MUST be discarded by the Transport > Converter." > I guess every time you say in the document that a message is discarded = that would also lead somehow to closing the connection most likely by = to sending a reset, no? Or should the SYN just be drop and no reply send = for any reason? Please clarify. >=20 > 10) Probably editorial in sec 5.2.4: > "A Transport Converter SHOULD include in this > list the TCP options that it accepts from Clients; these options are > included by the Transport Converter in the SYN packets that it sends > to initiate connections.=E2=80=9D > I had to read the second half twice because it suddenly talks about a = completely different =E2=80=9Cscenario=E2=80=9D than replying to an Info = TLV. Maybe some rewording could help a bit like > "A Transport Converter SHOULD include in this > list the TCP options that it accepts from Clients; these options are > also included by the Transport Converter in the SYN packets if it > initiates connections to the client.=E2=80=9D > Or maybe even use normative language here:=20 > =E2=80=9Cthe Transport Convert SHOULD also include the same option in = the SYN if=20 > it initiates a connection to the client.=E2=80=9D >=20 > 11) sec 5.2.5: Maybe also be slightly more clear here: > "For incoming connections destined to a Client > serviced via a Transport Converter, these fields convey the source > port number and IP address.=E2=80=9D > Proposed > "For incoming connections destined to a Client > serviced via a Transport Converter, these fields convey the source > port number and IP address of the SYN packet received by the=20 > Transport Converter from the server.=E2=80=9D >=20 > 12) I have a couple of question about the TCP options field in the = Connect TLV, basically this text in section 5.2.5: > " Upon reception of a Connect TLV, and absent any policy (e.g., = rate- > limit) or resource exhaustion conditions, a Transport Converter > attempts to establish a connection to the address and port that it > contains. The Transport Converter MUST use by default the TCP > options that correspond to its local policy to establish this > connection. These are the options that it advertises in the > Supported TCP Extensions TLV. >=20 >=20 > Bonaventure, et al. Expires May 7, 2020 [Page = 22] > Internet-Draft Convert Protocol November = 2019 >=20 >=20 > Upon reception of an extended Connect TLV, and absent any rate limit > policy or resource exhaustion conditions, a Transport Converter MUST > attempt to establish a connection to the address and port that it > contains. It MUST include the options of the 'TCP Options' = sub-field > in the SYN sent to the Server in addition to the TCP options that it > would have used according to its local policies. For the TCP = options > that are listed without an optional value, the Transport Converter > MUST generate its own value. For the TCP options that are included > in the 'TCP Options' field with an optional value, it MUST copy the > entire option for use in the connection with the destination peer. > This feature is required to support TCP Fast Open.=E2=80=9D >=20 > First of all the upper paragraph is probably old and should have been = removed, right? >=20 > Then I=E2=80=99m not certain about the new approach with the TCP = option field. If the converter actually ends up in a split connection = (with e.g. MPTCP on client side but without it on server side), I = thought it can only announce those options in the SYN to the server that = are actually implemented in the converter and it will be able to support = later in the connection. So blindly copying the options provided by the = client doesn=E2=80=99t seem right. Or what do I miss? >=20 > I understand the case where you want to use TFO between the client and = the convert but can=E2=80=99t use it anymore between the the client and = the server then. However you can only use TFO with the second connection = you make to a server. So in the first connection either TFO was used = between the convert and the server and the convert could now use it = again with the cookie it received or TFO was used end-to-end in the = first connection and it now clear to me why the converter is used now. = Maybe I=E2=80=99m missing something but I think the drafts would at = least need more explanation about the motivation to have this. >=20 > If it=E2=80=99s really only about TFO cookies and we are sure we want = to have that feature, maybe an own TLV would be simpler? >=20 > 13) In sec 5.2.6 do you mean by "extended TCP header=E2=80=9D the TCP = option space? I=E2=80=99m not sure that "extended TCP header=E2=80=9D is = a clearly defined term; as least I=E2=80=99m not 100% sure what you = mean=E2=80=A6 >=20 > 14) nit in sec 5.2.7: > s/The Cookie TLV (Figure 20 is an optional/The Cookie TLV (Figure 20) = is an optional/ -> missing closing bracket >=20 > 15) Sec 5.2.7: > Question about normative language: > "If the received SYN did not contain a Cookie TLV, and cookie > validation is required, the Transport Converter should compute a > Cookie bound to this Client address and return a Convert message > containing the fixed header, an Error TLV set to "Missing Cookie" = and > the computed Cookie and close the connection.=E2=80=9D > Is this maybe a MAY condition? All of it? Or something like this > "If the received SYN did not contain a Cookie TLV, and cookie > validation is required, the Transport Converter MAY compute a > Cookie bound to this Client address. It MUST return a Convert = message > containing the fixed header and Error TLV set to "Missing Cookie=E2=80= =9D and MAY add > the computed Cookie. After sending the Error TLV is MUST/SHOULD = close/reset =20 > the connection.=E2=80=9D > Not fully sure what is the intention here=E2=80=A6 >=20 > 15) sec 5.2.8: > What's the purpose of the client sending an Unsupported Version error? = If the converter replies with a different version than requested used by = the client, that's simply a fatal error/implementation error and the = client can only reset the connection I think. >=20 > More generally if I read this correctly there are only 3 errors that = could be sent by the client. I guess those errors would be send in the = first packet after the SYN/ACK is received=E2=80=A6? Related to my = question above, I think it would be much easier to only have Convert = message in the SYN and SYN/ACK and no explicit error message from the = client. Otherwise more explanation in the draft would be need how this = actually is supposed to work. >=20 > 16) sec 5.2.8: > "A Client which receives this error code MUST cache the received > Cookie and include it in subsequent Convert messages sent to that > Transport Converter.=E2=80=9D > This seems to be a slightly weird normative MUST. Sure you have to = cache the cookie in oder to be able to use the converter, however, there = may be cases where you loose the cache and then sending a Connect = without the cookie to get a new Cookie is a valid option. So you may use = SHOULD here or even better reword it completely... >=20 > 17) There is an Unsupported TCP Option in section 5.2.8. However, this = error is not mentioned in 5.2.5. In contrast sec 5.2.5 says that the = converter MUST open a connection and MUST use these options. This is = related to my point 12 above but it was not clear to me that options can = be rejected, however, this whole part seems to make the protocol really = complicated and as I said if the only use case is TFO I would prefer to = rather have a separate specific TLV for that case only. >=20 > 18) I think section 6.7 should still say something about if this = option is supported or not=E2=80=A6 >=20 > 19) section 7: > "Consider a middlebox that removes the SYN payload. The Client can > detect this problem by looking at the acknowledgment number field of > the SYN+ACK returned by the Transport Converter. The Client MUST > stop to use this Transport Converter given the middlebox > interference.=E2=80=9D > If the converter received a SYN without a Convert message in the = payload on the respective port, it is supposed to anyway send a SYN/ACK? = I would assume it would rather send a RESET, no? I think that needs to = be further specified. >=20 > 20) Sec 7 also says: > =E2=80=9CIf an Error was returned by the Transport Converter, a = message to close > the connection would normally follow from the Converter.=E2=80=9D > However sec 5.2.8 says: > "Upon reception of an Error TLV, a > Client MUST close the associated connection.=E2=80=9D > I assume one of these is not correct=E2=80=A6 please clarify which end = is suppose to do what in case of an error. >=20 > 21) The text in sec 7 then further says: > "If no such > message is received, the Client may continue to use this = Converter.=E2=80=9D > Isn=E2=80=99t that a bit dangerous? =20 >=20 > 22) section 8.5: Why are the authentication mechanism discussed in = this section MPTCP specific? I think the same mechanisms could also be = applied to Converters supporting other options, no? >=20 > 23) sec 8.3: > "Means to protect against SYN flooding attacks MUST also be enabled = [RFC4987].=E2=80=9D > Not sure if the use of MUST is clear here. Which part of RFC4987 does = this MUST relate to? All of it? Maybe a SHOULD or no normative language = is more appropriate? >=20 > 24) sec 9.2: Maybe call the new registry the "The TCP Convert Protocol = (Convert) > Parameters=E2=80=9D (TCP added)=E2=80=A6? >=20 > 25) sec 9.2.2: > "The values in the range 192-255 can be assigned for Private Use.=E2=80=9D= > IANA does not assigned any value for Private use, they can just be = used, so this should be > "The values in the range 192-255 are reserved for Private Use.=E2=80=9D > if that is what you want? >=20 > 26) also on section 9.2.X: "Specification Required" includes having an = expert review and RFC8126 says: > "As with Expert Review (Section 4.5), clear guidance to the designated > expert should be provided when defining the registry, and thorough > understanding of Section 5 is important.=E2=80=9D > So please provide further guidance about what the expert is supported = to evaluate.=20 >=20 > 27) Not sure if the following references need to be normative as there = no normative requirement connect to them but only an optional case is = discussed: RFC4279, RFC7250 =E2=80=A6? >=20 > However, RFC7323, RFC2018, RFC6978, RFC6978, RFC2827, RFC6181 should = probably be normative references=E2=80=A6? >=20 > 28) The term =E2=80=9Cexperimental option=E2=80=9D is used with two = different meaning in the intro of section 6 (options that are defined in = an exp RFC) and in section 6.9 (options with kind 254 and 255). Please = clarify this at both places. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 From nobody Fri Jan 10 07:38:09 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE03512006B; Fri, 10 Jan 2020 07:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxDD-MneLhji; Fri, 10 Jan 2020 07:38:05 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3405F120048; Fri, 10 Jan 2020 07:38:05 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 47vRvb5J4kz1y9C; Fri, 10 Jan 2020 16:38:03 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.35]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 47vRvb4cbzzFpWV; Fri, 10 Jan 2020 16:38:03 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM6C.corporate.adroot.infra.ftgroup ([fe80::f58e:8e9d:ae18:b9e3%21]) with mapi id 14.03.0468.000; Fri, 10 Jan 2020 16:38:03 +0100 From: To: Mirja Kuehlewind , "draft-ietf-tcpm-converters.all@ietf.org" CC: tcpm IETF list Thread-Topic: AD review of draft-ietf-tcpm-converters-14 Thread-Index: AQHVx8T3k0Q2q/9dJU+VDQF+wEx0IKfkBc6g Date: Fri, 10 Jan 2020 15:38:03 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933031407777@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <4DF47B41-2A8F-4FC1-8734-4D133F3EBBE5@kuehlewind.net> <52F7B691-AB5F-4C63-BC8D-CFB5E569D085@kuehlewind.net> In-Reply-To: <52F7B691-AB5F-4C63-BC8D-CFB5E569D085@kuehlewind.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] AD review of draft-ietf-tcpm-converters-14 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 15:38:07 -0000 SGkgTWlyamEsIA0KDQpUaGFuayB5b3UgZm9yIGRldGFpbGVkIHJldmlldyAoYXMgdXN1YWwhKS4N Cg0KV2Ugd2lsbCBnZXQgYmFjayB0byB5b3UgQVNBUC4gDQoNClBsZWFzZSBzZWUgaW5saW5lLiAN Cg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6 IE1pcmphIEt1ZWhsZXdpbmQgW21haWx0bzppZXRmQGt1ZWhsZXdpbmQubmV0XQ0KPiBFbnZvecOp wqA6IHZlbmRyZWRpIDEwIGphbnZpZXIgMjAyMCAxNTo0OA0KPiDDgMKgOiBkcmFmdC1pZXRmLXRj cG0tY29udmVydGVycy5hbGxAaWV0Zi5vcmcNCj4gQ2PCoDogdGNwbSBJRVRGIGxpc3QNCj4gT2Jq ZXTCoDogUmU6IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLXRjcG0tY29udmVydGVycy0xNA0KPiAN Cj4gSGkgYWdhaW4sDQo+IA0KPiBPZiBjb3Vyc2UgaWYgaGF2ZSBtb3JlIHF1ZXN0aW9uL2NvbW1l bnRzLiBIb3dldmVyIHRoZXNlIGFyZSBlYXN5IG9uZXM6DQo+IG9uZSBuaXQsIGFuZCB0d28gcXVl c3Rpb24gYWJvdXQgd2h5IHRoZSB0ZXh0IGlzIGluIHRoZSBhcHBlbmRpeCA6LSkNCj4gDQo+IE9u ZSBtb3JlIHRob3VnaHQ6IExvb2tpbmcgYXQgdGhlIFNPQ0tTNiBkb2N1bWVudCBhZ2FpbiwgSSB0 aGluayB3aGF0IHlvdQ0KPiBoYXZlIGRlZmluZWQgaGVyZSwgY2FuIGFjdHVhbGx5IGJlIHNlZW4g YXMgYSBsaWdodC13ZWlnaHQgU09DS1MuIEkgdGhpbmsNCj4gdGhhdOKAmXMgZmluZSBidXQgbWF5 YmUgaXQgd291bGQgYmUgYmV0dGVyIHRvIGFja25vd2xlZGdlIGl0IHRoaXMgd2F54oCmPw0KPiBU aGVyZSB3aWxsIGFsc28gYmUgcmV2aWV3cyBieSB0aGUgSU5UIEFEcyBpbiBJRVNHIEV2YWx1YXRp b24gYW5kIEkgZG9u4oCZdA0KPiB0aGluayB0aGlzIGhhcyBiZWVuIG90aGVyd2lzZSByZXZpZXdl ZCBieSBhbnkgSU5UIGFyZWEgd29ya2luZyBncm91cA0KPiB5ZXQsIHJpZ2h0Pw0KPiANCj4gQWZ0 ZXIgYWxsIHRoYW5rcyBmb3IgYSB3ZWxsLXdyaXR0ZW4gZG9jdW1lbnQgYW5kIGFsc28gZm9yIHRo ZSBnb29kDQo+IHNoZXBoZXJkIHdyaXRlLXVwIQ0KPiANCj4gTWlyamENCj4gDQo+IA0KPiANCj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gMSkgQXBwZW5kaXggQi4xOg0KPiAiICAgbyAgMHg0OiAo Y2xpZW50KSBzZW5kIGRhdGEgaW4gdGhlIG9wZW5pbmcgU1lOIHJlZ2FyZGxlc3Mgb2YgY29va2ll DQo+ICAgICAgIGF2YWlsYWJpbGl0eSBhbmQgd2l0aG91dCBhIGNvb2tpZSBvcHRpb24uDQo+IA0K PiAgICBCeSBzZXR0aW5nIHRoaXMgY29uZmlndXJhdGlvbiB2YXJpYWJsZSB0byAweDUsIGEgTGlu dXggY2xpZW50IHVzaW5nDQo+ICAgIHRoZSBhYm92ZSBjb2RlIHdvdWxkIHNlbmQgZGF0YSBpbnNp ZGUgdGhlIFNZTiB3aXRob3V0IHVzaW5nIGEgVEZPDQo+ICAgIG9wdGlvbi7igJ0NCj4gMHg0IG9y IDB4NSA/DQo+IA0KDQpbTWVkXSAweDUgaXMgY29ycmVjdCBiZWNhdXNlIHRoZXNlIGFyZSBiaXRt YXAgdmFsdWVzLiANCg0KPiAyKSBUaGlzIGlzIGZ1bGx5IGVkaXRvcmlhbCwgYnV0IGdpdmVuIGFw cGVuZGl4IEMgaXMgcmVhbGx5IHNob3J0LCBJDQo+IHRoaW5rIHRoaXMgY291bGQgaGF2ZSBhbHNv IGJlIGp1c3QgYmUgcGxhY2Ugc29tZXdoZXJlIGluIHRoZSBib2R5IG9mIHRoZQ0KPiBkb2N1bWVu dCBsaWtlIGUuZy4gaW4gc2VjdGlvbiA1LjIuNyBvciB0aGUgaW50cm8gdGV4dCBpbiBzZWN0aW9u IDUuDQoNCltNZWRdIFdvcmtzIGZvciBtZS4gDQoNCj4gDQo+IDMpIEZ1cnRoZXIgSSBhbHNvIGRv buKAmXQgZnVsbHkgc2VlIHdoeSBhcHBlbmRpeCBEIGlzIGluIHRoZSBhcHBlbmRpeC4gSQ0KPiB0 aGluayBtb3N0IG9mIHRoaXMgaXMgbWVudGlvbmVkIGluIHRoZSBib2R5IG9mIHRoZSBkb2N1bWVu dCBhbHJlYWR5IGJ1dA0KPiBpbiBsZXNzIGRldGFpbCB3aGljaCBtYWtlcyBpdCBhY3R1YWxseSBo YXJkZXIgdG8gdW5kZXJzdGFuZCAoaW4gdGhpbmsgSQ0KPiBoYWQgYXQgbGVhc3Qgb25lIHF1ZXN0 aW9uIHRvIHRoaXMgYmVsb3cpLiBJIHRoaW5rIGhhdmluZyB0aGlzIHRleHQgYXMNCj4gc3Vic2Vj dGlvbnMgaW4gMy4zLiB3b3VsZCBhY3R1YWxseSBiZSBoZWxwZnVsIHRvIHVuZGVyc3RhbmQgdGhl IHVzYWdlDQo+IGJldHRlci4NCj4gDQoNCltNZWRdIFdlIHB1dCBpdCB0aGVyZSBiZWNhdXNlIHdl IHRob3VnaHQgdGhpcyBpcyBnZXR0aW5nIGRvd24gaW50byBkZXBsb3ltZW50IG9wdGlvbnMvY29u c2lkZXJhdGlvbnMuIFdlIGNhbiBtb3ZlIGl0IHRvIHRoZSBtYWluIHRleHQgaWYgd2UgbWFpbnRh aW4gdGhlIHNhbWUgbGV2ZWwgb2YgZGV0YWlscy4gSG9wZSB0aGlzIGlzIE9LIHdpdGggeW91Lg0K DQo= From nobody Mon Jan 13 06:44:10 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 913D31200D6; Mon, 13 Jan 2020 06:44:08 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6sEYuJKYyFm; Mon, 13 Jan 2020 06:44:06 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 F0E9D120127; Mon, 13 Jan 2020 06:44:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1578926642; bh=T20/Ul3HMaceeKeWiEZ6aOzFXkTksK+5QEOgPpLMqms=; h=X-UI-Sender-Class:To:From:Subject:Date; b=GS002NhLWpzwEdM0oiroQCKET3FJldUbeLC376PxrQ8Wx4+lY84rRxFyRikM68vsW c2A+GT0ZC9ybg52W98EARMl6DC6Adejj9BNHwIqWmB9Puc9BK2yVvczwl0oazH4fSp +scOVbiQ30MVwnnJLKON6Ik+VSM+kTimxIfhAtSE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.67.133.231] ([217.70.210.46]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N79yQ-1jiuJ41CaS-017WnE; Mon, 13 Jan 2020 15:44:02 +0100 To: "tcpm@ietf.org" , iccrg IRTF list , "tsvwg@ietf.org" From: "Scheffenegger, Richard" Message-ID: <9743ac1c-9909-9ec9-9df4-53cd108f9baa@gmx.at> Date: Mon, 13 Jan 2020 15:44:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:5NQIAb2/YumjEnde4QZh3gWCDjrROjEXguuBYvskfT6I/YHp81O 5oXDXQRR6nCZeuWfky7NS/BKkUCAkj64tWi/5qX3DhCnpcGo5Mh+e9x9uRVsDtWQwlBskpw pMFBnaSdEzoPnmbCpPKHSyoDggkbSBeDZOp72c4fMrtXFUNGkcQlND2OanAZbteqAc94wNL eWehQgWZmk7Ey+PFOskAg== X-UI-Out-Filterresults: notjunk:1;V03:K0:BheClyc03Zk=:bceN9sZwdsoSFtvfMe5uxg N3lgeWZXVXIIpvMJTXulbBhFaIdhWdmj4SX7LyVr9EjFFScdNQC5dD5eJMM4d0Gq550oosP5A J71RV0bhlhO2q7K3JeBw6dnaduaMz6p4moEi5kTbWtCqDGpKCAvozml+A9qXXCWIQ9HnVCrHA DSG8is3h3r2PvwcOaghTnEYQZsreuUUqWSMHE/7yhJBc5j5kAnOZDTnVsZOFTKHCAPbErx6iI gqLetly4BmiTVCVfywSWLKSP0OukiSTqzUsEhmJ6cl6YjE6LPMjTG4O26FNc7e7yetaoyKyza EwN74Pa5Zqit0TFPUUj+ArAvDQ9v0CmKxFk/3BC34r+xbwg31tLX+JepqHfqhA+dKEFKZgd5F ymTbRU+Aum+4l9fvaTKUIGc0dfCitUaI2OctajAo3V6AJ7t52mYIkd8YyszqWKWYrA9NBair9 EM751cBo/AI+Up4ZuJl1abV76skYwBev2w1n0yZWqJb/1PZAQj5QcxExlQAWUnIZLZ1wsrLjS CZDbGSoSdORuzT5PxFAkwpUXxcH7Xui2ytvTlOjNCntVCI73rEZHe4OGp1XvlyW3u4Q/0q5BZ 9ks2Nn3/bFVLJDY/lMMQwMeyA8Qxob7Nhz5ZAoUsAH+oSQT6l6fp3M4IJlC7xWO6ogRS3Befc XE82BbtkCZPxAaQGWEA2dUrs4pnvYkSxIlf51XlOXfonWxuFBtwcTBQJBZwcQKUeez+ZqEm2j XRMDNOGuCw7NCp4aI6z8WDL++KElP5MxYDMImnOOGMw5+M1Ey27IanNxlezBB1JHgpqILhL+T 5sjBZzFUH97PGQ0h95ARJfuytUM7eRU8g3s25OwjVxFwmJ1V8cJMz0I9+dkd81lvaeKd+hIrs YMpAsSNg063SJB9KIz9t+Tj08Kl3CGX+bLW49a4CpCvbplEk872AGIHUZ2Ej8paWocbMpNya+ EFLmGb+zeeSyDYjTp98Jy8fLqzW2nV7Zkv3l0ag0unS2DnpS2pEePb9GNJmh7lDEcOfVvRDAF 0/Ds8Xopn7El+jkl1Z3aXbfc2WyF91BJQA4VIOD88DW8W2ojAVoJelE+jj1ByOgbXiMHTv9v0 ky5QDFJuaIIuNUU06dcGc4m47QU2x39wVcV2BNhLrNvAYQ5iDjruMSDCWA8Wvf3ZRON9dI+LK eerxFYAmfkPaoNFAWXd2rCpnXcK3UFIiXiEIAS8thj80kipYVjr04XOe0rqAAr2nko1lLFSES tmHLhgM4hu8eJuqv62UPAcB+47Cm/MiwbVRE+oQ== Archived-At: Subject: [tcpm] On RFC3168 ECN signaling in TCP implememtations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2020 14:44:09 -0000 Hi group, I just wanted to report a few findings that Neil and I found while looking into corner cases of the TCP header RFC3168 ECN flags signaling. tl;dnr: Please confirm, that the TCP RFC3168 header flags are independent from the IP ECT codepoint. And that CWR shall be sent immediately whenever cwnd is reduced, including during RTO events (for ECN-enabled sessions across a loss-only congestion point). First, there is an implementation oversight in FBSD, for ECN+SACK enabled sessions. While RFC3168 is quite strict in stipulating, that all retransmissions (and control packets) are not to be sent with the ECN-capable-transport Codepoint in the IP header, this is only true for non-SACK loss recovery at the moment in that stack. I have mentioned this on the tcpm list already with the subject ECN++. Second, I found that FreeBSD (not checked OpenBSD or NetBSD) is not setting the CWR (congestion window reduced) flag for Retransmission-Timeout retransmissions. This is also problematic in a larger context (which is how we found this initially) - if the RTO happens due to lost retransmissions, and CE is set during the same window - while loss recovery is happening - the lack of the CWR bit will keep the latched ECE flag on the receiver to remain se= t. Thus, the ACK for the RTO retransmission is returned with ECE still set - preventing the growth of cwnd in this first RTT after RTO. On top, the RTO has a 0.5 probability to run into the delayed ACK timeout. The 1st packet thereafter, sent with the ECE-marked ACK, will have a probabiliy of 1.0 to wait for an delayed ACK timeout. In that cornercase (two different congestion points, one with loss-only and one with ECN), the above reults in very sluggish recovery from an RTO, since the cwnd is also set to 1 MSS when the RTO happens. While discussing this with Neal, he found that there exists another oversight on the Linux side. Apparently, TCP ECN header flags are only set when the IP packet of the segment is also ECT-marked. With other words, during RTO the Linux stack does want to send out the CWR bit (as we believe is the correct behavior), but doesn't because that RTO retransmission is sent without the ECN-capable-transport codepoint in the IP header. Effectively, a similar scenario as in the FreeBSD plays out - the RTO is sent, doesn't clear the latched ECE flag on the receiver; the ACK to the RTO retransmission still carries an ECE flag, to which the stack then responds by reducing cwnd once more (to 1 segment), setting CWR only then (or when the first new data segment is transmitted). We wanted to confirm if our understaning of RFC3168 signaling is correct, and what the expected interaction between RFC3168 signaling with loss / RTO should be. Best regards, Richard From nobody Wed Jan 15 00:20:56 2020 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C80D12010D; Wed, 15 Jan 2020 00:20:55 -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: nsd.ietf@gmail.com, tcpm@ietf.org, ietf@kuehlewind.net, tcpm-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157907645501.8971.10298138905377811896.idtracker@ietfa.amsl.com> Date: Wed, 15 Jan 2020 00:20:55 -0800 Archived-At: Subject: [tcpm] tcpm - New Meeting Session Request for IETF 107 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 08:20:55 -0000 A new meeting session request has just been submitted by Yoshifumi Nishida, a Chair of the tcpm working group. --------------------------------------------------------- Working Group Name: TCP Maintenance and Minor Extensions Area Name: Transport Area Session Requester: Yoshifumi Nishida Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: Chair Conflict: mptcp Technology Overlap: tsvwg quic taps tsvarea iccrg panrg maprg People who must be present: Yoshifumi Nishida Michael Tuexen Michael Scharf Mirja Kuehlewind Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Jan 15 12:47:56 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0FD12089C; Wed, 15 Jan 2020 12:47:53 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6E4uTBjAoTY; Wed, 15 Jan 2020 12:47:51 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 D041F120935; Wed, 15 Jan 2020 12:47:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1579121268; bh=7lxXFIez7ra+c1BZORab57HwZeneholx/WZ0bilEDfo=; h=X-UI-Sender-Class:Subject:From:To:References:Date:In-Reply-To; b=D+C9brQruhLoQ/chf9johf+3qvWG8q5/0DrAoUdVaHBQuqtyj0QBS6VsIuLqaSaCD +NsJAtB1LehrrH2RNuDE1RyARL4E9kXxh4d7tP5SczYgkieM0sg2MUCCGHw5CTsnkr MMmyJGOAHLYJps+bdzlE36jJEkA5XVGEdK/qLXuY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.233.107] ([185.236.167.136]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MgNcz-1jIcWn1yqV-00huy2; Wed, 15 Jan 2020 21:42:30 +0100 From: "Scheffenegger, Richard" To: "tcpm@ietf.org" , draft-ietf-tcpm-generalized-ecn@ietf.org, FreeBSD Transport , Neal Cardwell , Christoph Paasch , Vidhi Goel , Rodney Grimes , Michael Tuexen References: <6f6f4c2f-b72f-b7fb-55aa-c6985862d061@gmx.at> Message-ID: <3cd59a2f-d926-769c-175e-91938b962463@gmx.at> Date: Wed, 15 Jan 2020 21:42:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <6f6f4c2f-b72f-b7fb-55aa-c6985862d061@gmx.at> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:lzfaD4KngQq7OG+TVhoLLX67a8ThhCGLwl836E5aVg64oXiKx9l n3X2IrH31ogzrTNOLArnlBAdM9j8FVQvT1ymXhTPXuKninsRuFd8TZ8NL1uFUl8LmPuJJeF 1YGolINqZ9j+tZB1oC7jbqVYLiDovFE7uLW/19+u+yhMRX0mZTpmtZfZIXXqd2cTCVjKB40 dbOSVmPeE+M9E+MHvnk6A== X-UI-Out-Filterresults: notjunk:1;V03:K0:U3XkMah0DBU=:wSHnnz++huLJOKRXRRY9mf 4jX3A0OW8Fq7OJ+fV2cgu8P6hVFtwqlX2IraiRk3je3LWUWhwxWCbWG0leCNhv1xa1DU437KH SZX5RqvqstbX8zO5DocQgjI8Hko83FuVCldHspfu8wbJNtzVUvEjDxXLJkhI7TbWcZ0PlwKN3 I0FWp+Gi3dcIjzKRQmy2nt8nn4qVzqvquE/GqgL7JFW5bF/jvOLTNktvkaGlm62RzFJiy5gZF 4NyZz60Vx7hNtimJtIuOamGQlAQmPW2qqF7K7CREzg0+dx76bkVdDEuSMnxJfg0f48xksuJsn 2Cgvu3r3mHKq5d2MCAgsbMPYUK/bmmUl4SeuuIlaQGj84Wt2LQWQK5MIEr1tYFxi4SCBWNhPW YQNrBqjGYq5PGIVJYjdFGd0HFhJJRLuA6nMitxdz5YsOpXG6GMF2ykGKdTE3AMm08E+Qlbo7p 9qoZ9y31zg3PBHD432uAq8YBZ0L3Z+XlYyMEp7zsOp/vA7TtoRQIalWWDBeHvoRqbs026y3Fd 0cyXuzutparytq2a/PkbBfKFHkmytJLSkvxU5SNjfyvHkppg9kM7b6AMElGlXBBnfsHVAAQGo rWIL2npPmJ1AZfUf8kysPgdWChFpasSfc1dLNzmJT1F26pYO8lHhCRHxDOXGHTPnAdRRkJwn4 BR4q1YKXlp7BxnjNiR9gTD+jiczPXsvUODIwhkYD9CXxkET5wkELa7d3ZwVQfG9Uqzuvqzh02 d4TRFJC/lXFBPLoGrhP0wvsB5dpd1iddCi2WnMVSnrP0aL774yFCerJA7JcBgauZGiehmCq1g sZ5syevSillU3f4AMGDgJPg+W6tvjqwvD3LD6tzvvkVEvvapHLIdtAzvARDtTlBOMVxzfZZiv r5svCG7WL0Le6gh9mWW1i8htnEewrGXTrtp+pa7eN/hx9+DgZ3eRch11NqlumF70Q8W1f8wjy gz5lS9CTIwjW76X4+fvcnGKcEMt5imn8onI6rx0TdXiZGoczpKG8yBXd9wF5ivzLCSNt12WOq dI5lxo4Xh9Q52nR8WOKX0DoSjJca6cLS62N+q3tya2XGxlnz34Y9pP6ne6CBeX4vfPQKfROf2 kPJ0GEskonzwo6PzgUcnFKZZc3ntUW04xOIuCwKNOVOFIPJwaalVuz09hvlHnwHdo0LqTwJux 1DO1HQEYCsBwgqzPLJLwmDorrEZlGphIwAijSgSblph+XksosXNPgpwbPcNNdv/rZnLQSv4Tm 3nhcKIRKb08kEyYvDKg0AB44UOfXkCd99QVjOhQ== Archived-At: Subject: Re: [tcpm] ECN++ X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 20:47:54 -0000 Hi, Yet another interesting observation =E2=80=93 as fbsd currently doesn=E2= =80=99t refrain from marking SACK-retransmission to be not-ECT, you can actually end up getting a CE mark on a retransmission across a ECN-enabled congestion poin= t. Obviously this is better than loss=E2=80=A6 What happens next is, that fbsd "honors" that ECE mark, since it is in loss-recovery, not congestion-recovery. It adjusts the recovery_point to the current snd_max (rightmost sent segment), and adjusts ssthresh and cwnd by multiplicative decrease factor... Furthermore, it appears that it also resets the traversal of the SACK scoreboard (incidential a "good" thing, as a few earlier retransmissions also got dropped, not marked, and are being resent without an RTO). But in the context of ECN++, what would be the expected response here? I assume, that with the exception of the fresh traversal of the SACK scoreboard, the above steps seem sensible. Any thoughts on this interesting interaction between ECE (during SACK loss recovery)? Best regards, Richard Am 10.01.2020 um 01:08 schrieb Scheffenegger, Richard: > Marcelo, Bob, > > I just noted that there is a slight oversight in FreeBSD currently, > which results in all session that are simultaneously ECN-enabled and > SACK-permitted to effectively send out retransmissions with the ECT0 > codepoint. > > Strictly speaking, this is in violation of RFC3168, but might also be a > good (nearly a decade long) validation of the performance of ECN++ for > all types of data segments (new and retransmitted ones), although at a > low and implicit exposure... > > > On that note, since I think ECN++ is quite valuable (with a number of > published research finding this change to be crucial), perhaps you can > summarize the outstanding issues (other than more reviewers required; I > admit I still haven't gone through all the delta between -04 and -05). > > Best regards, > =C2=A0 Richard > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Jan 17 04:27:13 2020 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7593E12003F for ; Fri, 17 Jan 2020 04:27:11 -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.116.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157926403147.20303.1219645214216579433.idtracker@ietfa.amsl.com> Date: Fri, 17 Jan 2020 04:27:11 -0800 From: IETF Secretariat Archived-At: Subject: [tcpm] Milestones changed for tcpm WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 12:27:11 -0000 Changed milestone "Submit document on a time-based fast loss detection algorithm for TCP to the IESG for publication as an Experimental RFC", set description to "Submit document on a time-based fast loss detection algorithm for TCP to the IESG for publication as a Proposed Standard RFC". URL: https://datatracker.ietf.org/wg/tcpm/about/ From nobody Fri Jan 17 14:09:46 2020 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D20C9120026; Fri, 17 Jan 2020 14:09:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <157929898074.20335.1195446513473590378@ietfa.amsl.com> Date: Fri, 17 Jan 2020 14:09:40 -0800 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-rack-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 22:09:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF. Title : RACK: a time-based fast loss detection algorithm for TCP Authors : Yuchung Cheng Neal Cardwell Nandita Dukkipati Priyaranjan Jha Filename : draft-ietf-tcpm-rack-07.txt Pages : 30 Date : 2020-01-17 Abstract: This document presents a new TCP loss detection algorithm called RACK ("Recent ACKnowledgment"). RACK uses the notion of time, instead of packet or sequence counts, to detect losses, for modern TCP implementations that can support per-packet timestamps and the selective acknowledgment (SACK) option. It is intended to replace the conventional DUPACK threshold approach and its variants, as well as other nonstandard approaches. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-rack-07 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rack-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rack-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jan 19 13:51:20 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF07120033; Sun, 19 Jan 2020 13:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.891 X-Spam-Level: X-Spam-Status: No, score=-0.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.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 g48C-uiw3-s8; Sun, 19 Jan 2020 13:51:17 -0800 (PST) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D7E112001E; Sun, 19 Jan 2020 13:51:17 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 7D03125A13; Sun, 19 Jan 2020 22:51:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1579470675; bh=6w6GNP1ppvfQYwLD4HjRP6U3EhFkFIVC+mPunOBcYGI=; h=From:To:CC:Subject:Date:From; b=OL9lwYsPzNx9Ln5nd+Yuvb9bVN4wJ5kwGacHP16OV1ircOeCOiDRDZzgWaB+QrWlh zWyPAqwDtZFZDvjRpzhED76RACb+8AgT5SkazPJbp2fTS8E5ir3/Y593yWZR8cH2BE phG6xnPU1Mn2i34U0ir6d9TiRaYjgWSq2TwEC7jw= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBFt3QmviYvc; Sun, 19 Jan 2020 22:51:14 +0100 (CET) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Sun, 19 Jan 2020 22:51:14 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.158]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Sun, 19 Jan 2020 22:51:13 +0100 From: "Scharf, Michael" To: "draft-ietf-tcpm-rack@ietf.org" CC: tcpm IETF list Thread-Topic: draft-ietf-tcpm-rack - editorial impact of target PS Thread-Index: AdXPEfaA08MAFRCISZS3xRB6hDYy6g== Date: Sun, 19 Jan 2020 21:51:13 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D8DBCE1@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.48.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] draft-ietf-tcpm-rack - editorial impact of target PS X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2020 21:51:19 -0000 Hi all, I briefly scanned through draft-ietf-tcpm-rack-07 regarding the impact of t= he new target as PS. This e-mail is only about editorial and formal issues. Note that I am not t= he responsible chair for this document. Questions: * Metadata: Does the document update other RFCs (such as RFC 5681)? My curr= ent thinking is that the answer is "no", but I want to cross-check. As the = document now targets PS, it theoretically could update other RFCs. If the d= ocument does not update other RFCs, maybe it needs to explain this and the = reason for not doing it somewhere? * Abstract: "It is intended to replace the conventional DUPACK threshold ap= proach and its variants, as well as other nonstandard approaches." I am not sure if the word "replace" could be a formal issue, in particula= r if other RFCs are not updated by this document (see previous comment). An= other wording that may work around this question could e.g. be "it is inten= ded to be an alternative to the conventional DUPACK threshold". Do others i= n the working group have any opinion on that wording (in particular native = speakers)? The same question applies to later use of the word "replace".=20 * Section 4:=20 "This document provides a concrete and detailed reordering window adaptation algorithm for implementers. We note that the specifics of the algorithm are likely to evolve over time. But that is a separate engineering optimization that's out of scope for this document." This could be understood as an experiment... Thus, I am not sure if this = wording will pass an IETF last call on standards track. I wonder if this co= uld be reworded to something along the lines of ... "This document provides a concrete and detailed reordering window adaptation algorithm as a standard solution that is safe to use.=20 Implementers have to aware that engineering optimization of the algorithm are possible." Section 8.4 "Nevertheless RACK is still an experimental algorithm. Since the oldest loss detection algorithm, the 3 duplicate ACK threshold [RFC5681], has been standardized and widely deployed. RACK can easily and optionally support the conventional approach for compatibility." The first sentence probably should be removed. I don't really understand = the second sentence. And wouldn't it make sense to better emphasize the "co= mpatibility" earlier in the document, say, in the intro? Thanks Michael (with no hat)=20 From nobody Tue Jan 21 10:04:33 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13487120178 for ; Tue, 21 Jan 2020 10:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 icEwKdNHD2cN for ; Tue, 21 Jan 2020 10:04:28 -0800 (PST) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 8FD3312007A for ; Tue, 21 Jan 2020 10:04:28 -0800 (PST) Received: by mail-vs1-xe31.google.com with SMTP id g15so2462709vsf.1 for ; Tue, 21 Jan 2020 10:04:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1ByD7/NcFj5SpoWIB2BZXJQzUHQc3FYE5Nix/9wkkCY=; b=TZf0CftN4EOOeHj33yYH9WDEX2nOWOmbYTWxrAHK8oe3rBFaQ2U8buSeSOu3NxcHXN dER9vUCYjRR3+TgpLNTptJ8yx3fFJYUdRQ3FbOjOcAEq3CYHuM9Utbiy/Fi20G++aexe byORv0nBc0Da3O0kd+AZILHmFQ0C5BUnqW81A/Z9r2PdqnNBa+q7JXOQcO0dYqdghpuP S+PTE/uKCpgaP1R5Chv34NGsi7m2SWnhLwj/MsXhoXpkbpCObcBmpdb5D36iwRwRJMFL Xch/ULOmq7Ic2gAEc9xiIq/tyCSsY6jABohuzEJ/r4O+VkYuSqOIfoifH/p88D+Xu/rZ Kiog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1ByD7/NcFj5SpoWIB2BZXJQzUHQc3FYE5Nix/9wkkCY=; b=Xhdisbu7V/7x+Fi+blbsGReHmIVnqp8J8dCHggILldOLCTub4LlZA33y+Ey8JjLKzt T5Y8wN+7IO4jEbu9TD7sTio85GLLwDzCvy0l+5inIv47355iSnZXzM5V1agNb8cJBxnn Vvt9IKjoaOrfdTt7JuAsLjWGc/uautM1KeQytkOtb4pqbx1nxqGcSRRs2rX18IYYkW74 UsKGwoifduxr5GsoKr220WeHnJ9oaSJUCmnkeu9Lv0wjXMKbLEYVmqSnCVbNFHWfp08d Yv8V3Ii1m4yZqKPAbgKoOvar/HSK+o4rqVQeWKWmuvGJz3nn4iMgwU+Iy3QMh+aivMvf EIFQ== X-Gm-Message-State: APjAAAXfW8Yxqnqv9hY/YyO2QJa+D6okxQHjqQX4M+PLwpqkKav0+ZNm SKKEZ/sW8ajwNOo6odOCTN/12kp2TosqOeYs0Jd6GQ== X-Google-Smtp-Source: APXvYqz/G63+JL/MRUyljpOu0dV7lyOj2GK6I+MHsTHOo//k/YVFJgHQ8w5KDQGysFqymCLB5gwjfgtUsiGOVZyewu8= X-Received: by 2002:a67:d816:: with SMTP id e22mr3929730vsj.134.1579629867169; Tue, 21 Jan 2020 10:04:27 -0800 (PST) MIME-Version: 1.0 References: <6EC6417807D9754DA64F3087E2E2E03E2D8DBCE1@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D8DBCE1@rznt8114.rznt.rzdir.fht-esslingen.de> From: Yuchung Cheng Date: Tue, 21 Jan 2020 10:03:51 -0800 Message-ID: To: "Scharf, Michael" Cc: "draft-ietf-tcpm-rack@ietf.org" , tcpm IETF list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] draft-ietf-tcpm-rack - editorial impact of target PS X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 18:04:31 -0000 On Sun, Jan 19, 2020 at 1:51 PM Scharf, Michael wrote: > > Hi all, > > I briefly scanned through draft-ietf-tcpm-rack-07 regarding the impact of= the new target as PS. > > This e-mail is only about editorial and formal issues. Note that I am not= the responsible chair for this document. > > Questions: > > * Metadata: Does the document update other RFCs (such as RFC 5681)? My cu= rrent thinking is that the answer is "no", but I want to cross-check. As th= e document now targets PS, it theoretically could update other RFCs. If the= document does not update other RFCs, maybe it needs to explain this and th= e reason for not doing it somewhere? > > * Abstract: "It is intended to replace the conventional DUPACK threshold = approach and its variants, as well as other nonstandard approaches." > > I am not sure if the word "replace" could be a formal issue, in particu= lar if other RFCs are not updated by this document (see previous comment). = Another wording that may work around this question could e.g. be "it is int= ended to be an alternative to the conventional DUPACK threshold". Do others= in the working group have any opinion on that wording (in particular nativ= e speakers)? > > The same question applies to later use of the word "replace". I am fine with other wordings except I don't have a better one. > > * Section 4: > > "This document provides a concrete and detailed reordering window > adaptation algorithm for implementers. We note that the specifics of > the algorithm are likely to evolve over time. But that is a separate > engineering optimization that's out of scope for this document." > > This could be understood as an experiment... Thus, I am not sure if thi= s wording will pass an IETF last call on standards track. I wonder if this = could be reworded to something along the lines of ... > > "This document provides a concrete and detailed reordering window > adaptation algorithm as a standard solution that is safe to use. > Implementers have to aware that engineering optimization of > the algorithm are possible." how about we just get rid of the paragraph completely since TCP will evolve no matter what. > > Section 8.4 > > "Nevertheless RACK is still an experimental algorithm. Since the > oldest loss detection algorithm, the 3 duplicate ACK threshold > [RFC5681], has been standardized and widely deployed. RACK can > easily and optionally support the conventional approach for > compatibility." > > The first sentence probably should be removed. I don't really understan= d the second sentence. And wouldn't it make sense to better emphasize the "= compatibility" earlier in the document, say, in the intro? s.g. +1 on removing first sentence > > Thanks > > Michael (with no hat) From nobody Tue Jan 21 23:23:43 2020 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4B6120013; Tue, 21 Jan 2020 23:23:41 -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: nsd.ietf@gmail.com, tcpm@ietf.org, ietf@kuehlewind.net, tcpm-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157967782115.28823.5185677614368770165.idtracker@ietfa.amsl.com> Date: Tue, 21 Jan 2020 23:23:41 -0800 Archived-At: Subject: [tcpm] tcpm - Update to a Meeting Session Request for IETF 107 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 07:23:41 -0000 An update to a meeting session request has just been submitted by Yoshifumi Nishida, a Chair of the tcpm working group. --------------------------------------------------------- Working Group Name: TCP Maintenance and Minor Extensions Area Name: Transport Area Session Requester: Yoshifumi Nishida Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: Chair Conflict: mptcp Technology Overlap: tsvwg quic taps tsvarea iccrg panrg maprg People who must be present: Yoshifumi Nishida Michael Tuexen Michael Scharf Mirja Kuehlewind Resources Requested: Special Requests: If possible, please allocate the meeting during Monday-Wednesday. (Monday or Tuesday would be more preferable) --------------------------------------------------------- From nobody Wed Jan 22 04:24:29 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93396120089 for ; Wed, 22 Jan 2020 04:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi 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 e8HXbVGxCpOj for ; Wed, 22 Jan 2020 04:24:24 -0800 (PST) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFA3D120077 for ; Wed, 22 Jan 2020 04:24:24 -0800 (PST) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Wed, 22 Jan 2020 14:24:18 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:subject:message-id:mime-version:content-type; s= dkim20130528; bh=aO/tytD3HXEwb9grga+Ktogl8lscaCUy1XFrnFfGBpo=; b= HLnwcark6VzVTLDOKpzvyqVJbVypj81FLX3IVswEeEnxpphTeqyMwieRBoPMoSUZ aeTD1S0oIITyGi6CQo8keIeeiZr/Hfo4hNWwM5TrX9ojq5q4zu8HwCnNxYwuT4cH BK2d1ows/a1wLpUWOaelvL7OWMFR44c2kWMhmH7NqSI= Received: from whs-18.cs.helsinki.fi (whs-18.cs.helsinki.fi [128.214.166.46]) (TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPS; Wed, 22 Jan 2020 14:24:18 +0200 id 00000000005A0170.000000005E283EF2.00001BF7 Date: Wed, 22 Jan 2020 14:24:18 +0200 (EET) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@whs-18.cs.helsinki.fi To: tcpm@ietf.org, pravb@microsoft.com, huanyi@microsoft.com, maolson@microsoft.com Message-ID: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Archived-At: Subject: [tcpm] Review of hystartplusplus-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 12:24:27 -0000 Hi all, I've just read through the HyStart++ draft v01. Two comments: I find using variable named "Eta" and related constants (MIN/MAX_ETA) somewhat strange as to me ETA reads "estimated time of arrival" which in the context didn't seem to make much of a sense. Then there is a major contradiction within the draft: if (currentRoundMinRTT >= (lastRoundMinRTT + Eta)) ssthresh = cwnd exit slow start and enter LSS "HyStart++ ends when cwnd exceeds ssthresh or when congestion is observed." ...ssthresh is set to cwnd when exiting slow start and LSS is entered as per the algorithm but the quoted sentence tells that LSS will be terminated as soon as cwnd grows any? -- i. From nobody Wed Jan 22 07:24:41 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE32E120128; Wed, 22 Jan 2020 07:24:32 -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 ss4VsgpWyafH; Wed, 22 Jan 2020 07:24:29 -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 B609C120111; Wed, 22 Jan 2020 07:24:29 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 7E999F40710; Wed, 22 Jan 2020 07:24:20 -0800 (PST) To: rbonica@juniper.net, touch@isi.edu, mankin@psg.com, rbonica@juniper.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: ietf@kuehlewind.net, iesg@ietf.org, tcpm@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200122152420.7E999F40710@rfc-editor.org> Date: Wed, 22 Jan 2020 07:24:20 -0800 (PST) Archived-At: Subject: [tcpm] [Errata Verified] RFC5925 (5961) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 15:24:33 -0000 The following errata report has been verified for RFC5925, "The TCP Authentication Option". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5961 -------------------------------------- Status: Verified Type: Technical Reported by: Ron Bonica Date Reported: 2020-01-22 Verified by: Mirja Kühlewind (IESG) Section: 7.4 Original Text ------------- d. Determine the RNextKeyID as indicated by the rnext_key pointer, and insert it in the TCP-AO RNextKeyID field (using the rnext_key MKT’s RecvID as the TCP-AO KeyID) Corrected Text -------------- d. Determine the RNextKeyID as indicated by the rnext_key pointer, and insert it in the TCP-AO RNextKeyID field (using the rnext_key MKT’s RecvID as the TCP-AO RNextKeyID) Notes ----- This was a cut-and-paste error -------------------------------------- RFC5925 (draft-ietf-tcpm-tcp-auth-opt-11) -------------------------------------- Title : The TCP Authentication Option Publication Date : June 2010 Author(s) : J. Touch, A. Mankin, R. Bonica Category : PROPOSED STANDARD Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG From nobody Wed Jan 22 09:25:38 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA50512010E for ; Wed, 22 Jan 2020 07:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 466EkmQyVqg0 for ; Wed, 22 Jan 2020 07:19:26 -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 D444312010C for ; Wed, 22 Jan 2020 07:19:26 -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=eIFZsKNChQQkXRP2rr5fetZ7/NKibv2T3vDuUilUs+Q=; b=I+95fS128ZtZKGzeTY/qqVclM yj5j00cZW0NTWqFe5RMmirEa2PXVWsksXQDxGRneAkeGYHxXgb+8LdrvyBR+26aD7K8C/IIbNKQPm z3AgL+nveG7ThfN3srolElNdcNqaHVlPIqFvSdnXJV1ZmwmoxKZQ6JLX4etGIFpo0moz+5bwYi//h MfWZLe6bqACwhciRC/rs+CIYXrALxFSHqI0sCkURJqjGh3opBVIsN59zDojDPC49D2lhsYj3MR0+I NrdqyubnN6Ep4CHfNsqag5NtSUZLmqatDh/RV/ynEVlDfgdhqwvkqwWB/GmwvHLqhG7mBJp+dlNiS stQhu1x5g==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:64041 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iuHmn-002wQf-5z; Wed, 22 Jan 2020 10:19:21 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Joe Touch In-Reply-To: <20200122141007.AC3E5F40710@rfc-editor.org> Date: Wed, 22 Jan 2020 07:19:16 -0800 Cc: "Dr. Joe Touch" , Allison Mankin , Ron Bonica , ietf@kuehlewind.net, magnus.westerlund@ericsson.com, michael.scharf@hs-esslingen.de, tuexen@fh-muenster.de, nsd.ietf@gmail.com, tcpm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3DE0239D-EB27-40E6-A4A3-DE5093D0FE73@strayalpha.com> References: <20200122141007.AC3E5F40710@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.3608.40.2.2.4) X-OutGoing-Spam-Status: No, score=-0.2 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: X-Mailman-Approved-At: Wed, 22 Jan 2020 09:25:37 -0800 Subject: Re: [tcpm] [Technical Errata Reported] RFC5925 (5961) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 15:19:29 -0000 FYI - Ron and I both checked this. > On Jan 22, 2020, at 6:10 AM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC5925, > "The TCP Authentication Option". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid5961 >=20 > -------------------------------------- > Type: Technical > Reported by: Ron Bonica >=20 > Section: 7.4 >=20 > Original Text > ------------- > d. Determine the RNextKeyID as indicated by the rnext_key > pointer, and insert it in the TCP-AO RNextKeyID field (using > the rnext_key MKT=E2=80=99s RecvID as the TCP-AO KeyID) >=20 >=20 > Corrected Text > -------------- > d. Determine the RNextKeyID as indicated by the rnext_key > pointer, and insert it in the TCP-AO RNextKeyID field (using > the rnext_key MKT=E2=80=99s RecvID as the TCP-AO RNextKeyID) >=20 >=20 > Notes > ----- > This was a cut-and-paste error >=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 > -------------------------------------- > RFC5925 (draft-ietf-tcpm-tcp-auth-opt-11) > -------------------------------------- > Title : The TCP Authentication Option > Publication Date : June 2010 > Author(s) : J. Touch, A. Mankin, R. Bonica > Category : PROPOSED STANDARD > Source : TCP Maintenance and Minor Extensions > Area : Transport > Stream : IETF > Verifying Party : IESG From nobody Wed Jan 22 09:25:42 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA0712010E for ; Wed, 22 Jan 2020 07:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=dQTgor3b; dkim=pass (1024-bit key) header.d=juniper.net header.b=IsQcWg4x 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 dAvzuFbTdfBC for ; Wed, 22 Jan 2020 07:28:27 -0800 (PST) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 619BD12010C for ; Wed, 22 Jan 2020 07:28:27 -0800 (PST) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00MFMwxc017264; Wed, 22 Jan 2020 07:28:16 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=iiibKzdFuLjZ1LEpysglO2Og5plv2hIEXQU9byoOVcc=; b=dQTgor3bWc7DD/tLOwOBfK5nGWo3uF/du2JR4ChtxBmNtg9MuA9JMkBoF7ZuEYTqY9FC 7x5bBdyVl0+4d4kPzMBUQv0vKT8LIyZqqT3Evorb8RBkpnH931oEf+KrcNg5CUg4Wx5o cbPzQ14mdPUZUDhjYEnV2/PxQVoAyu8BePHOkijTccA3EW72HX90L5PmOtv4IDF1udMj RwIzfR+MK83xRUPDvDr8dzJCLsRnP1KItLv0Gv45ipuTy1B0iIdYMQzLRTCiQhnsAPiP Zbx3mqJ20Ei5e9QnFTW+amDXaaKj+LdUrSaP7hgGrUZ2diRB5eg5EB1s3qgbVoecy+5M +g== Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp2055.outbound.protection.outlook.com [104.47.37.55]) by mx0a-00273201.pphosted.com with ESMTP id 2xnyw4aw3j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Jan 2020 07:28:15 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XWN4MiU+JXYRCiPbUJRr6iXb63EfgSIDgEjl16ULtIDA976izLi5mIEV7KuluYQlX8c+bXsVi3UwejCRO38GY4kD/AKodifvkVa0MoXdPEjUGqfN6UtEkZXE6yc2A1ZtWQrMy05D/VCn6aH5pZl0JhAjKB5ijXSdo9KTrmG0TY2RHbCQcairw3bdIFOuwr6ATQUXzVrgkg1zQVHsFEXc+Idx91e0o0q0P8kmz7GMVuwgfLxbah/Mn71eyySs9QMVaHr9InIzfU6ITH1EoGHMq8POU5/isDYsX8qlgJHc1rfyBddQd/FycIwlYm1/vSdcxIwPlmSIkImB3L7fvT8Hng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iiibKzdFuLjZ1LEpysglO2Og5plv2hIEXQU9byoOVcc=; b=LJKezFS0WOQH5x6roFchdfRdAGBHINWdMwwBaGWqcPrSlRgJHX1/LarEVN7npm6D1BhHikqpr3BNO+k5QgRqKpmbH2aPKjVYP9vzyYi6d0UBcAdp75yFwSF+dqGiS9+KHP4fT+OPweWrlXsGs62GyYXI4KcqEUXxXV5DBaI4a5w0Mweztnd3/AGRRid626s5XxMyFgKfXnd3975VNTxp1mOObQHu9FI0Sk3g3Rj/Ycoj4Z342E8mpTG3laRnkE/PlxGmR4LFNDITAwsMTGYbXwPniIqWrYEc+j5aw7hXjf0R6Qzipa3+7DTBMiS6HSyaaNTFV7FWb51ph5B+p/BoVw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iiibKzdFuLjZ1LEpysglO2Og5plv2hIEXQU9byoOVcc=; b=IsQcWg4xbB/inyUYr007RayXs/+yjNFvnatlPqQrT7WVt4LagtwuDTTy0LW4ABRjGwGi154UcWX1adU6P1whdF3lupvLgyVwPFjCxKP+WUjpV1EvKJXb9/CjDkxfKr8GNO2hIY7Pa1B9LR4xeGIRvUdsk6M9jd6tLlZ44p5SjEY= Received: from BN7PR05MB3938.namprd05.prod.outlook.com (52.132.216.30) by BN7PR05MB4563.namprd05.prod.outlook.com (52.132.222.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.10; Wed, 22 Jan 2020 15:28:12 +0000 Received: from BN7PR05MB3938.namprd05.prod.outlook.com ([fe80::f826:68df:3aa7:4864]) by BN7PR05MB3938.namprd05.prod.outlook.com ([fe80::f826:68df:3aa7:4864%5]) with mapi id 15.20.2665.017; Wed, 22 Jan 2020 15:28:11 +0000 From: Ron Bonica To: Joe Touch , RFC Errata System CC: "Dr. Joe Touch" , Allison Mankin , "ietf@kuehlewind.net" , "magnus.westerlund@ericsson.com" , "michael.scharf@hs-esslingen.de" , "tuexen@fh-muenster.de" , "nsd.ietf@gmail.com" , "tcpm@ietf.org" Thread-Topic: [Technical Errata Reported] RFC5925 (5961) Thread-Index: AQHV0S2vIkLW29vOgkaxBxJ7Tax/f6f2zEMAgAACbMA= Date: Wed, 22 Jan 2020 15:28:11 +0000 Message-ID: References: <20200122141007.AC3E5F40710@rfc-editor.org> <3DE0239D-EB27-40E6-A4A3-DE5093D0FE73@strayalpha.com> In-Reply-To: <3DE0239D-EB27-40E6-A4A3-DE5093D0FE73@strayalpha.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=rbonica@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-01-22T15:28:10.8859042Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=c1e906a0-b3ae-4c80-ac7e-44e00f6de1af; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic dlp-product: dlpe-windows dlp-version: 11.3.2.8 dlp-reaction: no-action x-originating-ip: [108.28.233.91] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 258d9531-e844-4d5d-eb1d-08d79f4fb124 x-ms-traffictypediagnostic: BN7PR05MB4563: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 029097202E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(396003)(136003)(376002)(366004)(346002)(189003)(199004)(52536014)(8936002)(316002)(4326008)(5660300002)(81166006)(81156014)(55016002)(9686003)(53546011)(6506007)(26005)(54906003)(33656002)(110136005)(186003)(86362001)(66476007)(76116006)(66946007)(966005)(478600001)(2906002)(71200400001)(7696005)(8676002)(7416002)(66446008)(66556008)(64756008); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR05MB4563; H:BN7PR05MB3938.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +oNY9shv60dlxgEZ2yE/SjQ4vGRozzD6v7eFJnEBoCf5iL6a33oXBc76jn3XAgs73NzENolOiEdw4csy4vkXXuGAp7N+F5HHapFoXnf/XiKDP4aSRTHP5WhsKC2Wgr5SdKFdxEoVuXeHkL4y1xSJ9cUNAbiPEVwVgbqHbDkmsMjFx7MbAbHTYWunv93kPAwJYoMMz6UFao5OdMOl67ttYXhdSACUhCfa/XNFCy5RDoj1CdbDJuQsy4Dzt40xSloXSPVi8CxQw2q9cEEBF1ymIdBO/CSbSgjq07DzO2keFyEQV7NbGiMWW8rWXBx+3l9073iLvP03gg508Lh6Pc1P4zK6jp+s3tnwYjia2ve4j3Dj99s8N/THKKxt503hqiMYFsWPSGh1DOolJlMO+OdAUKfQMSt3WXRMUsIVPSwUT/b4wK5xaWMds4qNsRk0lSw6bPEjzBM+zELsNz+l5LNeJZ3y9prnjea6e0KkLLdwEHc= x-ms-exchange-antispam-messagedata: F/qUW2uCfXCGs7c5gO+09UIaKyvVhvazxW240OyKy8Sq9e657MHEmQkDhHXquqR2kyxWKf2tldFBNoY8zZbqfR8Yd4RiXglsI0gn+6JHYcDDFO98+G0HUHyixnhUqy1YPShdvaeZboIqd24EsVNZfA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 258d9531-e844-4d5d-eb1d-08d79f4fb124 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2020 15:28:11.7934 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: SWdbZYp0iQ3n+KoL5AFTcGUUsLFLckmvPXrVK0bCyln5me61lQmxzIZhXag4T/lU+ywYRa8567wjmnuFy/CEFQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR05MB4563 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-17_05:2020-01-16, 2020-01-17 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 spamscore=0 suspectscore=0 lowpriorityscore=0 phishscore=0 adultscore=0 bulkscore=0 mlxlogscore=999 priorityscore=1501 clxscore=1011 mlxscore=0 malwarescore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001220137 Archived-At: X-Mailman-Approved-At: Wed, 22 Jan 2020 09:25:37 -0800 Subject: Re: [tcpm] [Technical Errata Reported] RFC5925 (5961) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 15:28:29 -0000 KzENCg0KDQpKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBKb2UgVG91Y2ggPHRvdWNoQHN0cmF5YWxwaGEuY29tPiANClNlbnQ6IFdl ZG5lc2RheSwgSmFudWFyeSAyMiwgMjAyMCAxMDoxOSBBTQ0KVG86IFJGQyBFcnJhdGEgU3lzdGVt IDxyZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPg0KQ2M6IERyLiBKb2UgVG91Y2ggPHRvdWNoQGlz aS5lZHU+OyBBbGxpc29uIE1hbmtpbiA8bWFua2luQHBzZy5jb20+OyBSb24gQm9uaWNhIDxyYm9u aWNhQGp1bmlwZXIubmV0PjsgaWV0ZkBrdWVobGV3aW5kLm5ldDsgbWFnbnVzLndlc3Rlcmx1bmRA ZXJpY3Nzb24uY29tOyBtaWNoYWVsLnNjaGFyZkBocy1lc3NsaW5nZW4uZGU7IHR1ZXhlbkBmaC1t dWVuc3Rlci5kZTsgbnNkLmlldGZAZ21haWwuY29tOyB0Y3BtQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzU5MjUgKDU5NjEpDQoNCkZZSSAtIFJv biBhbmQgSSBib3RoIGNoZWNrZWQgdGhpcy4NCg0KPiBPbiBKYW4gMjIsIDIwMjAsIGF0IDY6MTAg QU0sIFJGQyBFcnJhdGEgU3lzdGVtIDxyZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPiB3cm90ZToN Cj4gDQo+IFRoZSBmb2xsb3dpbmcgZXJyYXRhIHJlcG9ydCBoYXMgYmVlbiBzdWJtaXR0ZWQgZm9y IFJGQzU5MjUsICJUaGUgVENQIA0KPiBBdXRoZW50aWNhdGlvbiBPcHRpb24iLg0KPiANCj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gWW91IG1heSByZXZpZXcgdGhl IHJlcG9ydCBiZWxvdyBhbmQgYXQ6DQo+IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRw czovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGEvZWlkNTk2MV8NCj4gXzshIU5FdDZ5TWFPLWdr IVNxa3VUMUxPOGxxaW5ub256c2Q5VGJEMnpIUjRBR2VhbUZiSFNfcnhMSTRsbXh2TmR0SkN4Yg0K PiBNcGhSVG1kbmxUJA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gVHlwZTogVGVjaG5pY2FsDQo+IFJlcG9ydGVkIGJ5OiBSb24gQm9uaWNhIDxyYm9uaWNh QGp1bmlwZXIubmV0Pg0KPiANCj4gU2VjdGlvbjogNy40DQo+IA0KPiBPcmlnaW5hbCBUZXh0DQo+ IC0tLS0tLS0tLS0tLS0NCj4gZC4gRGV0ZXJtaW5lIHRoZSBSTmV4dEtleUlEIGFzIGluZGljYXRl ZCBieSB0aGUgcm5leHRfa2V5IHBvaW50ZXIsIGFuZCANCj4gaW5zZXJ0IGl0IGluIHRoZSBUQ1At QU8gUk5leHRLZXlJRCBmaWVsZCAodXNpbmcgdGhlIHJuZXh0X2tleSBNS1TigJlzIA0KPiBSZWN2 SUQgYXMgdGhlIFRDUC1BTyBLZXlJRCkNCj4gDQo+IA0KPiBDb3JyZWN0ZWQgVGV4dA0KPiAtLS0t LS0tLS0tLS0tLQ0KPiBkLiBEZXRlcm1pbmUgdGhlIFJOZXh0S2V5SUQgYXMgaW5kaWNhdGVkIGJ5 IHRoZSBybmV4dF9rZXkgcG9pbnRlciwgYW5kIA0KPiBpbnNlcnQgaXQgaW4gdGhlIFRDUC1BTyBS TmV4dEtleUlEIGZpZWxkICh1c2luZyB0aGUgcm5leHRfa2V5IE1LVOKAmXMgDQo+IFJlY3ZJRCBh cyB0aGUgVENQLUFPIFJOZXh0S2V5SUQpDQo+IA0KPiANCj4gTm90ZXMNCj4gLS0tLS0NCj4gVGhp cyB3YXMgYSBjdXQtYW5kLXBhc3RlIGVycm9yDQo+IA0KPiBJbnN0cnVjdGlvbnM6DQo+IC0tLS0t LS0tLS0tLS0NCj4gVGhpcyBlcnJhdHVtIGlzIGN1cnJlbnRseSBwb3N0ZWQgYXMgIlJlcG9ydGVk Ii4gSWYgbmVjZXNzYXJ5LCBwbGVhc2UgDQo+IHVzZSAiUmVwbHkgQWxsIiB0byBkaXNjdXNzIHdo ZXRoZXIgaXQgc2hvdWxkIGJlIHZlcmlmaWVkIG9yIHJlamVjdGVkLiANCj4gV2hlbiBhIGRlY2lz aW9uIGlzIHJlYWNoZWQsIHRoZSB2ZXJpZnlpbmcgcGFydHkgY2FuIGxvZyBpbiB0byBjaGFuZ2Ug DQo+IHRoZSBzdGF0dXMgYW5kIGVkaXQgdGhlIHJlcG9ydCwgaWYgbmVjZXNzYXJ5Lg0KPiANCj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gUkZDNTkyNSAoZHJhZnQt aWV0Zi10Y3BtLXRjcC1hdXRoLW9wdC0xMSkNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gVGl0bGUgICAgICAgICAgICAgICA6IFRoZSBUQ1AgQXV0aGVudGljYXRp b24gT3B0aW9uDQo+IFB1YmxpY2F0aW9uIERhdGUgICAgOiBKdW5lIDIwMTANCj4gQXV0aG9yKHMp ICAgICAgICAgICA6IEouIFRvdWNoLCBBLiBNYW5raW4sIFIuIEJvbmljYQ0KPiBDYXRlZ29yeSAg ICAgICAgICAgIDogUFJPUE9TRUQgU1RBTkRBUkQNCj4gU291cmNlICAgICAgICAgICAgICA6IFRD UCBNYWludGVuYW5jZSBhbmQgTWlub3IgRXh0ZW5zaW9ucw0KPiBBcmVhICAgICAgICAgICAgICAg IDogVHJhbnNwb3J0DQo+IFN0cmVhbSAgICAgICAgICAgICAgOiBJRVRGDQo+IFZlcmlmeWluZyBQ YXJ0eSAgICAgOiBJRVNHDQo= From nobody Wed Jan 22 09:25:48 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386AE1200F4 for ; Wed, 22 Jan 2020 06:10:18 -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 GyRDCllBlmue for ; Wed, 22 Jan 2020 06:10:16 -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 D2B7B1200D8 for ; Wed, 22 Jan 2020 06:10:16 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id AC3E5F40710; Wed, 22 Jan 2020 06:10:07 -0800 (PST) To: touch@isi.edu, mankin@psg.com, rbonica@juniper.net, ietf@kuehlewind.net, magnus.westerlund@ericsson.com, michael.scharf@hs-esslingen.de, tuexen@fh-muenster.de, nsd.ietf@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: rbonica@juniper.net, tcpm@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200122141007.AC3E5F40710@rfc-editor.org> Date: Wed, 22 Jan 2020 06:10:07 -0800 (PST) Archived-At: X-Mailman-Approved-At: Wed, 22 Jan 2020 09:25:47 -0800 Subject: [tcpm] [Technical Errata Reported] RFC5925 (5961) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 14:10:18 -0000 The following errata report has been submitted for RFC5925, "The TCP Authentication Option". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5961 -------------------------------------- Type: Technical Reported by: Ron Bonica Section: 7.4 Original Text ------------- d. Determine the RNextKeyID as indicated by the rnext_key pointer, and insert it in the TCP-AO RNextKeyID field (using the rnext_key MKT’s RecvID as the TCP-AO KeyID) Corrected Text -------------- d. Determine the RNextKeyID as indicated by the rnext_key pointer, and insert it in the TCP-AO RNextKeyID field (using the rnext_key MKT’s RecvID as the TCP-AO RNextKeyID) Notes ----- This was a cut-and-paste error 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. -------------------------------------- RFC5925 (draft-ietf-tcpm-tcp-auth-opt-11) -------------------------------------- Title : The TCP Authentication Option Publication Date : June 2010 Author(s) : J. Touch, A. Mankin, R. Bonica Category : PROPOSED STANDARD Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG From nobody Wed Jan 22 10:57:05 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A82120805 for ; Wed, 22 Jan 2020 10:57:04 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXj1VncbZ4tk for ; Wed, 22 Jan 2020 10:57:01 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 922E2120804 for ; Wed, 22 Jan 2020 10:57:00 -0800 (PST) Received: from [192.168.100.103] (unknown [186.183.3.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id C7DCD82A3B; Wed, 22 Jan 2020 19:56:56 +0100 (CET) To: Wesley Eddy , gorry@erg.abdn.ac.uk, "tcpm@ietf.org" References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk> <5d11289c-0174-8a5e-7f47-b0110564a601@mti-systems.com> From: Fernando Gont Message-ID: Date: Wed, 22 Jan 2020 15:54:37 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <5d11289c-0174-8a5e-7f47-b0110564a601@mti-systems.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tcpm] 793bis: TCP Quiet Time X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 18:57:04 -0000 Hello, Wes, On 18/12/19 18:33, Wesley Eddy wrote: > I don't think I noticed anyone responding to Gorry's comment below, and > I haven't made any alterations in the 793bis draft with regard to this > (other than fixing some spelling mistakes).  I wanted to pull this into > its own thread in case other people have thoughts or would like to > discuss further what the quiet time concept's relevance is in 2020. My response to Gorry in-line: > > On 8/28/2019 11:39 AM, Gorry Fairhurst wrote: >> OLD, Section: "   The TCP Quiet Time Concept" >> - Found this section quite amusing. Is this concept widely implemented >> in stacks? No. >> - The examples given need updated, for instance one example starts "At >> 2 megabits/sec. it takes 4.5 hours to", clearly at 10 Gbps this line >> of thinking becomes problematic. >> - There is an odd sentence that states: >> "In the absence of knowledge >>    about the sequence numbers used on a particular connection, the TCP >>    specification recommends that the source delay for MSL seconds before >>    emitting segments on the connection, to allow time for segments from >>    the earlier connection incarnation to drain from the system." >> - how would the "source" know the MSL rather than use the Internet >> default? Unless I'm missing something, MSL implies the value specified in this spec. -- so there's no need to guess or "know" more than that. (the real MSL is kind of tricky since, in theory, it is derived from the IPv4 Time to Live. You might know the TTL *you* use, but you probably won't know the TTL that other remote TCPs had employed. So, strictly speaking, in order to be safe you'd have to wait 255 seconds). >> - To me, this section raises many questions about whether this is best >> current practice. AFAIK, it has never been a "best current practice". That said, you need the "quiet time concept" from a "correctness" point of view. -- otherwise the TCP SEQ takes care of old segments of the same incarnation of the connection, but not of old segments from a *previous* incarnation of the connection. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 22 11:06:01 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDAE9120804 for ; Wed, 22 Jan 2020 11:05: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yx47wFc1uBTg for ; Wed, 22 Jan 2020 11:05:58 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29C64120802 for ; Wed, 22 Jan 2020 11:05:58 -0800 (PST) Received: from [192.168.100.103] (unknown [186.183.3.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 040A3860E3; Wed, 22 Jan 2020 20:05:53 +0100 (CET) To: tcpm@ietf.org References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk> <4D99C7DD-F57E-4708-8F02-824EB4BF8E24@weston.borman.com> <333A2AF9-7DDD-4FAA-B0BD-E6871564850F@strayalpha.com> From: Fernando Gont Message-ID: Date: Wed, 22 Jan 2020 16:05:31 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tcpm] 793bis: IP ID X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 19:06:00 -0000 Hi, Dave, On 20/12/19 17:37, David Borman wrote: > Yes, the IPID is only used for doing IP fragment reassembly, so the IPID really doesn’t matter on retransmission when IP fragmentation is not possible. Some boxes are know to clear DF and fragment packets. That's why some implementations have resorted to ensure IP ID uniqueness (or try to), even when they send packets with DF=1. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 22 17:08:26 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11CD12004E for ; Wed, 22 Jan 2020 17:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 l-hb38M19pu9 for ; Wed, 22 Jan 2020 17:08:23 -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 D490312002E for ; Wed, 22 Jan 2020 17:08:23 -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:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xdhEhtg9jLxPQ7R34ctz5NI0Albw77Le59XsNg52GlA=; b=QT2dp5tXy0VUwse9VI0kcVk4A LtY+43uTjWpjPwRtrlmL7utf7qH7m5sUC2rcg4QL93FVGmqJ2rMrneNoZCvbnRFmfoE4hOU9uX+J9 O9NUu6vQ3jvNEf4Bl2Cy/F3qyscOXC+AGNc1gjsQfzx0mQu/5lGQ23f27GLEOTzZVVHvO++hRHvBm H7OpzPWa5tGp9Urm5A+jn7DoLEIv2HF6xdCjPKTPwL1fSP5w/F88Hfem/RthYn9vZchoFQCgJfOst 80h0Ex9K2aA19tDItW4yKO2O0WoW+orIHEJEQb9pUDSSHu2pSoqmBJxTOsHt4i9MsOQ9va+Jei8tB bk5MwjL8Q==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:52613 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iuQyk-000f9T-Ic; Wed, 22 Jan 2020 20:08:19 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_233EDEDF-5CFC-4829-81DE-6FDDD8102E13" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Joe Touch In-Reply-To: Date: Wed, 22 Jan 2020 17:08:12 -0800 Cc: tcpm@ietf.org Message-Id: <3B11B295-3C70-436E-B8E7-C4B394E5C0C3@strayalpha.com> References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk> <4D99C7DD-F57E-4708-8F02-824EB4BF8E24@weston.borman.com> <333A2AF9-7DDD-4FAA-B0BD-E6871564850F@strayalpha.com> To: Fernando Gont X-Mailer: Apple Mail (2.3608.40.2.2.4) 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: [tcpm] 793bis: IP ID X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 01:08:25 -0000 --Apple-Mail=_233EDEDF-5CFC-4829-81DE-6FDDD8102E13 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 22, 2020, at 11:05 AM, Fernando Gont = wrote: >=20 > On 20/12/19 17:37, David Borman wrote: >> Yes, the IPID is only used for doing IP fragment reassembly, so the = IPID really doesn=E2=80=99t matter on retransmission when IP = fragmentation is not possible. >=20 > Some boxes are know to clear DF and fragment packets. That's why some = implementations have resorted to ensure IP ID uniqueness (or try to), = even when they send packets with DF=3D1. True, but equally true that devices reuse the ID when the packet is = atomic (not already fragmented and DF=3D1), as noted in RFC 6864. That = RFC deprecated use of the IPv4 ID except for reassembly. There is no similar deprecation of the need for intermediate devices to = honor DF. Joe= --Apple-Mail=_233EDEDF-5CFC-4829-81DE-6FDDD8102E13 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jan 22, 2020, at 11:05 AM, Fernando Gont <fgont@si6networks.com> wrote:

On 20/12/19 17:37, David Borman = wrote:
Yes, = the IPID is only used for doing IP fragment reassembly, so the IPID = really doesn=E2=80=99t matter on retransmission when IP fragmentation is = not possible.

Some boxes are know to clear DF and fragment packets. That's = why some implementations have resorted to ensure IP ID uniqueness (or = try to), even when they send packets with = DF=3D1.

True, but equally true that devices reuse the ID when the = packet is atomic (not already fragmented and DF=3D1), as noted in RFC = 6864. That RFC deprecated use of the IPv4 ID except for = reassembly.

There is no similar deprecation of the need for intermediate = devices to honor DF.

Joe
= --Apple-Mail=_233EDEDF-5CFC-4829-81DE-6FDDD8102E13-- From nobody Wed Jan 22 22:00:23 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E1112003F for ; Wed, 22 Jan 2020 22:00:21 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 LfMKtIdKgfAm for ; Wed, 22 Jan 2020 22:00:17 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640106.outbound.protection.outlook.com [40.107.64.106]) (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 B2FED12002F for ; Wed, 22 Jan 2020 22:00:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EOf+hPebrKi92GA2eGHlus707Tb4Fug3iR6iV1u6YZg+qUAwrhfI/oEaI7gLjHgkSpbIhUAeBfdtHbQgbUe0sf0ETB0QMCybPu7+OkhlERdW9j4bj8va6JdNXv2Jf8IxSVbCn8fZ0OtDgRUvuB0bjrBZSvkfXRh001qvjuOPD7k4F+H2RICkZVKVs65+SX5jdyvr0bKf9QpJgTrXc0B21W9eoeKEvqE64P6FcWNIm2YbUcsz5EAZt4j/zrYsoWokAun5vgQg0NhtH1UaxNjiA3ckHyLpYr7hX4pD5SusGvM3zrcjDOXUA/ZSTUzeALvELlf4JIQIjeovA2fmHd7kRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oHV0Zk6pW0hL2Cq5DeeT7bMHjdzrSQ7ErtvSlpWapQo=; b=gdi8c4F8d1CyepDCmJwqFgg0+LfykEu35OGsZA6jbYVHhqv+knOysWSH8Yju53hq5uxDx5MU3IjcVz6iI+k68bmDOyVqwvTNRRr+NeZg+115GIMM7oK0sI5i0wB1HEcPKH/tgmzQyokO9LJViO9FesctxP3ZA6+DXUGuCGbN0Ws19OeGLnhPTZPrtuWtkSZxUevQgvOIXWZMZh4zW8yWylZvbZhzGLEbRHoP6KSElZkji37qS755oPE6u3A8Tn8kF+kbhR6YIgLJQPJWN5Bc6P+CjVJOb/udQOWIeZTWq7Gu2orUD2mTk8WOfjvVytDqgz0y2ka6sJZ/14I47Hw5yw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oHV0Zk6pW0hL2Cq5DeeT7bMHjdzrSQ7ErtvSlpWapQo=; b=Mg1lOlfroQvcklieS1fgtz6tjqf0WdDi8WW6KCG7/Kair5G8EFF91JD3jA+idH3Le6CX6R3lm6QqFhHPQP7nNNS4T3WgEfwbaS3bS7R8p+iEf9vJmKLaTIGU6ajDr+O+erYqCd7rAsLm9vl+qYpjXDi6RIV4ADjvGsvd7GJ6npw= Received: from BYAPR00MB0454.namprd00.prod.outlook.com (20.178.53.202) by BYAPR00MB0568.namprd00.prod.outlook.com (20.179.56.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2698.0; Thu, 23 Jan 2020 06:00:14 +0000 Received: from BYAPR00MB0454.namprd00.prod.outlook.com ([fe80::ed84:dd1d:d241:ced1]) by BYAPR00MB0454.namprd00.prod.outlook.com ([fe80::ed84:dd1d:d241:ced1%4]) with mapi id 15.20.2705.000; Thu, 23 Jan 2020 06:00:14 +0000 From: Praveen Balasubramanian To: =?utf-8?B?SWxwbyBKw6RydmluZW4=?= , "tcpm@ietf.org" , Yi Huang , Matt Olson Thread-Topic: [EXTERNAL] Review of hystartplusplus-01 Thread-Index: AQHV0R7kfRB3qKw5302hW7apN/7iv6f3lbAA Date: Thu, 23 Jan 2020 06:00:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=pravb@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-01-23T06:00:10.4608689Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=1a0111a6-1cfd-44d3-a662-f5e62820e20c; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-originating-ip: [2001:4898:80e8:8:6c76:cda3:12a0:f9f8] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6ab66465-3a0a-4878-78be-08d79fc98404 x-ms-traffictypediagnostic: BYAPR00MB0568:|BYAPR00MB0568: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 029174C036 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(39860400002)(346002)(366004)(376002)(396003)(199004)(189003)(76116006)(2906002)(66556008)(66476007)(10290500003)(64756008)(66946007)(478600001)(66446008)(52536014)(5660300002)(9686003)(8936002)(55016002)(316002)(296002)(8676002)(110136005)(81156014)(71200400001)(81166006)(53546011)(6636002)(6666004)(33656002)(6506007)(8990500004)(86362001)(7696005)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR00MB0568; H:BYAPR00MB0454.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +lOv8vgQISyi209sIv93N8a9YilHrrJJol0yyJl9WL0D6dJMA/dBUic2LdffxiT+WumgRnLPHsDca09m2BrZJji1aKrC18Rj56/HfmnMwcPONtNS36T2bfe3SgswBLLKvYix16iIP9DJ6EiBq1BJ7tLMyNamUDFobaNQaJlPfUerrTHyhIDoKvb+EF4C3NcMO5RwjIOzzZZnpqQFIC3RZnmyA3HW8hDni3kzfKD22Y89+x29zpLWssx9wKK95XY/vbe1UyHIYr/xSAWEB/kNZXsOCUtrJsXFNchTA2dfDoq5R5/7Dt17ibBd9BW2ppnQoSj1xdgt+IdjsxpHtAt0IHFQo8WRfZhTmjy4LR2OdiQ6GcsjJGgtvKyx/8PLUPtbMaFYur/FW874jW9a+h28NZ4Zw1pQokce5qKaskub2akUJx9S98dRcjujKVcbgyW4 x-ms-exchange-antispam-messagedata: C00jYCMZz3X/gR8bRnkOwGK7/4N5d5cDHLxfs3uZa0eVOEE+h1GM1SvPxuDNqXIHQNMjV6zCfyR2cJ4ymhbP7Ovni7hqddtr8qMBgjxDjGezuLLNFEHszY7gvdFEGjaCQzK2pg1rKGGV/JG9ZKBteA7qaXaQXZ/oF3nXDBYVByp/DniLbPi7ILuSL11KAmTyvlG1OTfmfrIWRIO6jQl+3Q== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6ab66465-3a0a-4878-78be-08d79fc98404 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2020 06:00:11.7310 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: LEO7CVYK0vNDwNxKFfDmGX0EW6+EHKz9A7daFvtQ/ruD3PW4+F/JOnWqpCqN2+q1Vp1E/HS6j/G9CvzBiHQNfe9MpE6asP/p1GA80BnKBcY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR00MB0568 Archived-At: Subject: Re: [tcpm] [EXTERNAL] Review of hystartplusplus-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 06:00:22 -0000 VGhhbmtzIGZvciB0aGUgcmV2aWV3IQ0KDQpUaGUgdmFyaWFibGUgbmFtZSBFdGEgY29tZXMgZnJv bSBlcXVhdGlvbnMgaW4gdGhlIEh5U3RhcnQgcGFwZXIgIiBIeWJyaWQgU2xvdyBTdGFydCBmb3Ig SGlnaC1CYW5kd2lkdGggYW5kIExvbmctRGlzdGFuY2UgTmV0d29ya3MiIHdoaWNoIHVzZSB0aGUg R3JlZWsgYWxwaGFiZXQgzrcuIFdlIHdpbGwgY2hhbmdlIHRvIGNhbGwgaXQgUlRUIHRocmVzaG9s ZCB0byBhdm9pZCBjb25mdXNpb24gd2l0aCAiZXN0aW1hdGVkIHRpbWUgb2YgYXJyaXZhbCIuDQoN CkluZGVlZCB0aGF0IGlzIGEgY29udHJhZGljdGlvbiBhbmQgaXMgYSBtaXN0YWtlLiBIeVN0YXJ0 KysgZW5kcyBhZnRlciB0aGUgZmlyc3QgY29uZ2VzdGlvbiBzaWduYWwgaXMgb2JzZXJ2ZWQuIA0K DQpUaGFua3MNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IElscG8gSsOkcnZp bmVuIDxpbHBvLmphcnZpbmVuQGNzLmhlbHNpbmtpLmZpPiANClNlbnQ6IFdlZG5lc2RheSwgSmFu dWFyeSAyMiwgMjAyMCA0OjI0IEFNDQpUbzogdGNwbUBpZXRmLm9yZzsgUHJhdmVlbiBCYWxhc3Vi cmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb20+OyBZaSBIdWFuZyA8aHVhbnlpQG1pY3Jvc29m dC5jb20+OyBNYXR0IE9sc29uIDxtYW9sc29uQG1pY3Jvc29mdC5jb20+DQpTdWJqZWN0OiBbRVhU RVJOQUxdIFJldmlldyBvZiBoeXN0YXJ0cGx1c3BsdXMtMDENCg0KSGkgYWxsLA0KDQpJJ3ZlIGp1 c3QgcmVhZCB0aHJvdWdoIHRoZSBIeVN0YXJ0KysgZHJhZnQgdjAxLiBUd28gY29tbWVudHM6DQoN CkkgZmluZCB1c2luZyB2YXJpYWJsZSBuYW1lZCAiRXRhIiBhbmQgcmVsYXRlZCBjb25zdGFudHMg KE1JTi9NQVhfRVRBKSBzb21ld2hhdCBzdHJhbmdlIGFzIHRvIG1lIEVUQSByZWFkcyAiZXN0aW1h dGVkIHRpbWUgb2YgYXJyaXZhbCIgd2hpY2ggaW4gdGhlIGNvbnRleHQgZGlkbid0IHNlZW0gdG8g bWFrZSBtdWNoIG9mIGEgc2Vuc2UuDQoNClRoZW4gdGhlcmUgaXMgYSBtYWpvciBjb250cmFkaWN0 aW9uIHdpdGhpbiB0aGUgZHJhZnQ6DQoNCmlmIChjdXJyZW50Um91bmRNaW5SVFQgPj0gKGxhc3RS b3VuZE1pblJUVCArIEV0YSkpDQogICAgICAgICAgICAgICBzc3RocmVzaCA9IGN3bmQNCiAgICAg ICAgICAgICAgIGV4aXQgc2xvdyBzdGFydCBhbmQgZW50ZXIgTFNTDQoNCiAgIkh5U3RhcnQrKyBl bmRzIHdoZW4gY3duZCBleGNlZWRzIHNzdGhyZXNoIG9yIHdoZW4gY29uZ2VzdGlvbiBpcw0KICAg b2JzZXJ2ZWQuIg0KDQouLi5zc3RocmVzaCBpcyBzZXQgdG8gY3duZCB3aGVuIGV4aXRpbmcgc2xv dyBzdGFydCBhbmQgTFNTIGlzIGVudGVyZWQgYXMgcGVyIHRoZSBhbGdvcml0aG0gYnV0IHRoZSBx dW90ZWQgc2VudGVuY2UgdGVsbHMgdGhhdCBMU1Mgd2lsbCBiZSB0ZXJtaW5hdGVkIGFzIHNvb24g YXMgY3duZCBncm93cyBhbnk/DQoNCi0tDQogaS4NCg== From nobody Wed Jan 22 22:27:14 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA2312003F for ; Wed, 22 Jan 2020 22:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 IyfBF8tP2jO2 for ; Wed, 22 Jan 2020 22:27:11 -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 678E312002F for ; Wed, 22 Jan 2020 22:27:11 -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:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=XjQQx9MZk7/sIkoBKNCHZvZrcXqn9h9gOHacO2jbe18=; b=esVnPh9r2cc7YFy0Ca37DIwhe YI03/UQ6P2t6u6eT4J8Ary/vGjam8C7DcqTkToWSF2GFIru/R+ZFBkwhxms2F5QTPmFT7rXHnNJJV plTN9sxX2FV38i+v2AMRVsbNP9fmgNJ+SIOlZ4I8NRJKB7TGH9gfqdfTWktCPeDQHx2yoEWr4bqkL pRyShfSv0zZ4Gpqhvv8R0Ch4l825N7e22aD6Ikyo754UZL6sDtNF/TNFlagkA1p4AC5X7ny5wtRLe Ao11ZjtBWn0O190v9TWqdTQswfXOakIrre4haAe5ruEhjGFK9L70Rbq4CVKUZCfYy/nuGSv1kqHh6 c/Qg79lXg==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:63390 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iuVxJ-001oHb-9M; Thu, 23 Jan 2020 01:27:09 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_667B72DD-3B65-4A2F-9D58-C778E640804D" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Joe Touch In-Reply-To: Date: Wed, 22 Jan 2020 22:27:04 -0800 Cc: Wes Eddy , gorry@erg.abdn.ac.uk, "tcpm@ietf.org" Message-Id: <4B73D1AE-7901-4F2C-A56F-D4BF6D914050@strayalpha.com> References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk> <5d11289c-0174-8a5e-7f47-b0110564a601@mti-systems.com> To: Fernando Gont X-Mailer: Apple Mail (2.3608.40.2.2.4) 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: [tcpm] 793bis: TCP Quiet Time X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 06:27:13 -0000 --Apple-Mail=_667B72DD-3B65-4A2F-9D58-C778E640804D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 22, 2020, at 10:54 AM, Fernando Gont = wrote: >=20 >> On 8/28/2019 11:39 AM, Gorry Fairhurst wrote: >>> OLD, Section: " The TCP Quiet Time Concept" >>> - Found this section quite amusing. Is this concept widely = implemented in stacks? >=20 > No. It might be useful to consider this is relevant only for systems that = reboot in under 2 MSL anyway. That=E2=80=99s a good reason most systems = don=E2=80=99t need to care - but a good reason to worry about ignoring = this issue as we move forward. I.e., of this concept and its utility, as financial investors advise: Past performance is not be a predictor of future results. Joe= --Apple-Mail=_667B72DD-3B65-4A2F-9D58-C778E640804D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jan 22, 2020, at 10:54 AM, Fernando Gont <fgont@si6networks.com> wrote:

On = 8/28/2019 11:39 AM, Gorry Fairhurst wrote:
OLD, Section: "   The TCP Quiet Time = Concept"
- Found this section quite amusing. Is this = concept widely implemented in stacks?

No.

It might be useful to consider this is relevant only for = systems that reboot in under 2 MSL anyway. That=E2=80=99s a good reason = most systems don=E2=80=99t need to care - but a good reason to worry = about ignoring this issue as we move forward.

I.e., of this concept and its utility, = as financial investors advise:

Past performance is not be a = predictor of future results.

Joe
= --Apple-Mail=_667B72DD-3B65-4A2F-9D58-C778E640804D-- From nobody Wed Jan 22 22:59:25 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05599120115 for ; Wed, 22 Jan 2020 22:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 MUBvcfnOC2lf for ; Wed, 22 Jan 2020 22:59:19 -0800 (PST) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 9F24712003F for ; Wed, 22 Jan 2020 22:59:19 -0800 (PST) Received: by mail-io1-xd36.google.com with SMTP id m25so1909492ioo.8 for ; Wed, 22 Jan 2020 22:59:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hhT9oBClRapNsVEyIpYObSC+1bskF9Ui1t6GYZW6KK4=; b=ZShd0DzVoRXC2ghh/YkiYJprmpO+MNhCo8t1lkrsEseF7lCFAUPON9S6jLzOceoHaP nT9PjqkcHYfn4f5CDFYNq+acv5ie3rtpDQY+1bqSTiBGySKRZaeTwnCinMpPHyTq7coV 8uial4dDkDHBx3AXXh14werfQzxDi5wWsIWB1/+vpYEvn4wOcMfln7Ny+EfQdbm+PkHJ duIHI3fK80zkQK9sYKXZOQVprDa6sIMmhYdiVkJzhUPWxXmDNFVZ9NjfyKYNMlXfTdo8 PoXmYjDhPvcQGY3kP1kjoUelHC8YCRxJLeMN5Cl01IuwALkjF8WysEx5QQonFq7kdKXj ULyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hhT9oBClRapNsVEyIpYObSC+1bskF9Ui1t6GYZW6KK4=; b=ugJ6ajzjnB817caLJBl4YuFvNbAGbexGnlHLcD55fNM/OIENI+s9rLdSKsuQ4NYfRH m+8gDky7bKTpxSIH/adK5qubue0Du4QyOrUlT83cqtDLHZjNM5x0t+xj5mXMuWPKaH53 1QTnKdUkWsmyR6Nvs3QNtpxIyU/w0E5StpbLT3xFtzL5B/dRVbAgPvOi2HgScB9MW2tQ vCxvk29T9E0orFe5atyi1j12kL0ZtmXETu53M93Y9jCFYSMWy4e3QL0mVaev+GCIUQCx 7yLYBxM8ycO7uOJ1aU+0w/fLm4HIQGxu+D2Xv5ql3J0iSXao0W32BgGaKp1pT0WbR5ot 9R/A== X-Gm-Message-State: APjAAAWTM4Uhk8lP67KOWBbt0wRGfDdZwqbwLT6a4huVJJJ4Ctqf2z1t c97+IsXJ3gFF26sqhh5II/zHGNQyc2MrcFHu3YDyO/lh8Ng= X-Google-Smtp-Source: APXvYqyeDgLBrnc1btNu8eRvkdhZ676N/aY2AZE6rpJ9dA8K9EIHWsHWSC3J57PgeiW7sYShbDWiFAbCnGqy1S4Axho= X-Received: by 2002:a5d:8c89:: with SMTP id g9mr5756033ion.178.1579762758558; Wed, 22 Jan 2020 22:59:18 -0800 (PST) MIME-Version: 1.0 References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk> <5d11289c-0174-8a5e-7f47-b0110564a601@mti-systems.com> <4B73D1AE-7901-4F2C-A56F-D4BF6D914050@strayalpha.com> In-Reply-To: <4B73D1AE-7901-4F2C-A56F-D4BF6D914050@strayalpha.com> From: Matt Mathis Date: Wed, 22 Jan 2020 22:59:06 -0800 Message-ID: To: Joe Touch Cc: Fernando Gont , "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000e228e059cc92eee" Archived-At: Subject: Re: [tcpm] 793bis: TCP Quiet Time X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 06:59:22 -0000 --0000000000000e228e059cc92eee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There are two other changes that have largely made this problem moot: a) ISS and ephemeral port randomization make it extremely unlikely that segments delayed across a reboot will be in sequence for any connections (at the time this was written, both ISS and ephemeral ports were generated by counters starting from fixed integers). b) Although not reflected in policy, the effective MSL of the internet has been declining as it gets faster. There are paths and devices that can delay packets by more than 10 seconds but they don't normally cause packets to be reordered by that much, so a new SYN can't pass an old data segment, which is a requirement for triggering the hazard. I would suggest changing the text to say "a theoretical problem.... that could be fixed by... but for the following reasons it is viewed as being sufficiently unlikely to ignore. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay We must not tolerate intolerance; however our response must be carefully measured: too strong would be hypocritical and risks spiraling out of control; too weak risks being mistaken for tacit approval. On Wed, Jan 22, 2020 at 10:27 PM Joe Touch wrote: > > > On Jan 22, 2020, at 10:54 AM, Fernando Gont wrote= : > > On 8/28/2019 11:39 AM, Gorry Fairhurst wrote: > > OLD, Section: " The TCP Quiet Time Concept" > - Found this section quite amusing. Is this concept widely implemented in > stacks? > > > No. > > > It might be useful to consider this is relevant only for systems that > reboot in under 2 MSL anyway. That=E2=80=99s a good reason most systems d= on=E2=80=99t need > to care - but a good reason to worry about ignoring this issue as we move > forward. > > I.e., of this concept and its utility, as financial investors advise: > > Past performance is not be a predictor of future results. > > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --0000000000000e228e059cc92eee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There are two other changes that have largely made this pr= oblem moot:
a) ISS and ephemeral=C2=A0port randomization make it extrem= ely unlikely that segments delayed across a reboot will be in sequence for = any connections (at the time this was written, both ISS and ephemeral ports= were generated by counters starting from fixed integers).
b) Alt= hough not reflected in policy, the effective MSL of the internet has been d= eclining as it gets faster.=C2=A0 =C2=A0There are paths and devices that ca= n delay packets by more than 10 seconds but they don't normally=C2=A0ca= use packets to be=C2=A0reordered=C2=A0by that much, so a new SYN can't = pass an old data segment, which is a requirement for triggering the hazard.=

I would suggest changing the text to say "a = theoretical=C2=A0problem....=C2=A0 that could be fixed by...=C2=A0 but for = the following reasons it is viewed as being sufficiently=C2=A0unlikely=C2= =A0to ignore.

Thanks,
--MM--
The best way t= o predict the future is to create it. =C2=A0- Alan Kay

We must not t= olerate intolerance;
=C2=A0 =C2=A0 =C2=A0 =C2=A0howev= er our response must be carefully measured:=C2=A0
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 too strong would be hypocritical and risks spir= aling out of control;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 t= oo weak risks being mistaken for tacit approval.


On Wed, Jan 22, 2020 at 10:27 PM Joe Touch <touch@strayalpha.com> wrote:


On Jan = 22, 2020, at 10:54 AM, Fernando Gont <fgont@si6networks.com> wrote:

On 8/28/2019 11:39 AM, Gorr= y Fairhurst wrote:
OLD, Section: "=C2=A0= =C2=A0 The TCP Quiet Time Concept"
- Found this section quite amusi= ng. Is this concept widely implemented in stacks?

No.=

It might be useful to consid= er this is relevant only for systems that reboot in under 2 MSL anyway. Tha= t=E2=80=99s a good reason most systems don=E2=80=99t need to care - but a g= ood reason to worry about ignoring this issue as we move forward.

I.e., of this concept and its utility, as financial investo= rs advise:

<= /span>Past performance is not be a predictor of future results.
<= br>
Joe
______________________________________________= _
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--0000000000000e228e059cc92eee-- From nobody Wed Jan 22 23:00:33 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02371201C6 for ; Wed, 22 Jan 2020 22:59:33 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88XPR6ocnnOZ for ; Wed, 22 Jan 2020 22:59:31 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A79CE120820 for ; Wed, 22 Jan 2020 22:59:31 -0800 (PST) Received: from [192.168.100.103] (unknown [186.183.3.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 6635F8629E; Thu, 23 Jan 2020 07:59:27 +0100 (CET) To: Joe Touch Cc: Wes Eddy , gorry@erg.abdn.ac.uk, "tcpm@ietf.org" References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk> <5d11289c-0174-8a5e-7f47-b0110564a601@mti-systems.com> <4B73D1AE-7901-4F2C-A56F-D4BF6D914050@strayalpha.com> From: Fernando Gont Message-ID: Date: Thu, 23 Jan 2020 03:52:27 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <4B73D1AE-7901-4F2C-A56F-D4BF6D914050@strayalpha.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tcpm] 793bis: TCP Quiet Time X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 06:59:36 -0000 On 23/1/20 03:27, Joe Touch wrote: > > >> On Jan 22, 2020, at 10:54 AM, Fernando Gont > > wrote: >> >>> On 8/28/2019 11:39 AM, Gorry Fairhurst wrote: >>>> OLD, Section: "   The TCP Quiet Time Concept" >>>> - Found this section quite amusing. Is this concept widely >>>> implemented in stacks? >> >> No. > > It might be useful to consider this is relevant only for systems that > reboot in under 2 MSL anyway. That’s a good reason most systems don’t > need to care - but a good reason to worry about ignoring this issue as > we move forward. > > I.e., of this concept and its utility, as financial investors advise: > > Past performance is not be a predictor of future results. I agree. That said, in virtualized environments, and also in many (most?) modern envirnonments, you normally get to bootstrap in less than MSL. As noted, I wouldn't remove the "quiet time concept", since it has to do with correctness of the spec (it is the only way to answer the question "how do you take care of stale segments from previous incarnations of a connection?"). That said, I find it quite unlikely that OSes try to implement the Quite Time Concept -- even for the cases where it would be required. Particularly if they can get away with it, for practical purposes, by means of TCP timestamps. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 22 23:22:48 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B8A120072 for ; Wed, 22 Jan 2020 23:22:47 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKSJPxY-Oa6t for ; Wed, 22 Jan 2020 23:22:46 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28104120026 for ; Wed, 22 Jan 2020 23:22:46 -0800 (PST) Received: from [192.168.100.103] (unknown [186.183.3.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id B7B8082DC0; Thu, 23 Jan 2020 08:22:42 +0100 (CET) To: Matt Mathis , Joe Touch Cc: "tcpm@ietf.org" References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk> <5d11289c-0174-8a5e-7f47-b0110564a601@mti-systems.com> <4B73D1AE-7901-4F2C-A56F-D4BF6D914050@strayalpha.com> From: Fernando Gont Message-ID: <42ac39b4-34e0-7b51-cbb1-b158723ab089@si6networks.com> Date: Thu, 23 Jan 2020 04:20:08 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tcpm] 793bis: TCP Quiet Time X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 07:22:48 -0000 On 23/1/20 03:59, Matt Mathis wrote: > There are two other changes that have largely made this problem moot: > a) ISS and ephemeral port randomization make it extremely unlikely that > segments delayed across a reboot will be in sequence for any connections > (at the time this was written, both ISS and ephemeral ports were > generated by counters starting from fixed integers). FWIW, note in many of the randomization schemes (e.g. RFC6528) the resulting sequence still looks like a counter for each (src, dst). Still, I would expect the problem to be unlikely. > b) Although not reflected in policy, the effective MSL of the internet > has been declining as it gets faster.   There are paths and devices that > can delay packets by more than 10 seconds but they don't normally cause > packets to be reordered by that much, so a new SYN can't pass an old > data segment, which is a requirement for triggering the hazard. Agreed. > I would suggest changing the text to say "a theoretical problem.... > that could be fixed by...  but for the following reasons it is viewed as > being sufficiently unlikely to ignore. I would agree with this. That aside, one might also consider than as encryption becomes more pervasive, even in the case the problem took place, the connection would be reset, and the application would recover. -- so I guess it would be a hard case to make OSes implement this "quiet time". Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 23 05:25:00 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41EF21200CE for ; Thu, 23 Jan 2020 05:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 OO6GG__iH6NQ for ; Thu, 23 Jan 2020 05:24:56 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5A436120096 for ; Thu, 23 Jan 2020 05:24:56 -0800 (PST) Received: from gorry-mac.erg.abdn.ac.uk (unknown [IPv6:2001:630:42:110:b938:ce19:7b9a:f008]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 741191B0007F; Thu, 23 Jan 2020 13:24:48 +0000 (GMT) To: Fernando Gont , tcpm@ietf.org References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk> <4D99C7DD-F57E-4708-8F02-824EB4BF8E24@weston.borman.com> <333A2AF9-7DDD-4FAA-B0BD-E6871564850F@strayalpha.com> From: Gorry Fairhurst Message-ID: <495c6e94-d5a4-effe-3c4d-d5275deb8cc8@erg.abdn.ac.uk> Date: Thu, 23 Jan 2020 13:24:47 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [tcpm] 793bis: IP ID X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 13:24:58 -0000 I think this is the wrong ID to discuss anything related to IPv4 ID. I suspect some deployed boxes do exist that do shortest-packet first link scheduling; re-use various codepoints; and boxes that in this case clear DF. That's sad, but real. In days gone by, people may have built implementations that relied on any of these. It doesn't mean a modern TCP Spec needs to discuss the IPv4 ID field. I'd encourage the TCP Spec to say nothing about how IPv4 uses the ID field. Gorry On 22/01/2020 19:05, Fernando Gont wrote: > Hi, Dave, > > On 20/12/19 17:37, David Borman wrote: >> Yes, the IPID is only used for doing IP fragment reassembly, so the >> IPID really doesn’t matter on retransmission when IP fragmentation is >> not possible. > > Some boxes are know to clear DF and fragment packets. That's why some > implementations have resorted to ensure IP ID uniqueness (or try to), > even when they send packets with DF=1. > > Thanks, From nobody Thu Jan 23 06:32:40 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3571207FC for ; Thu, 23 Jan 2020 06:32:39 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sW_J6NvQdMa2 for ; Thu, 23 Jan 2020 06:32:38 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBA84120133 for ; Thu, 23 Jan 2020 06:32:37 -0800 (PST) Received: from [192.168.100.103] (unknown [186.183.3.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 1820186325; Thu, 23 Jan 2020 15:32:26 +0100 (CET) To: Gorry Fairhurst , tcpm@ietf.org References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk> <4D99C7DD-F57E-4708-8F02-824EB4BF8E24@weston.borman.com> <333A2AF9-7DDD-4FAA-B0BD-E6871564850F@strayalpha.com> <495c6e94-d5a4-effe-3c4d-d5275deb8cc8@erg.abdn.ac.uk> From: Fernando Gont Message-ID: <6bcf519e-d641-ea81-f391-10962e13afc5@si6networks.com> Date: Thu, 23 Jan 2020 11:13:16 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <495c6e94-d5a4-effe-3c4d-d5275deb8cc8@erg.abdn.ac.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] 793bis: IP ID X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 14:32:39 -0000 On 23/1/20 10:24, Gorry Fairhurst wrote: > I think this is the wrong ID to discuss anything related to IPv4 ID. > > I suspect some deployed boxes do exist that do shortest-packet first > link scheduling; re-use various codepoints; and boxes that in this case > clear DF. That's sad, but real. In days gone by, people may have built > implementations that relied on any of these. It doesn't mean a modern > TCP Spec needs to discuss the IPv4 ID field. > > I'd encourage the TCP Spec to say nothing about how IPv4 uses the ID field. +1 THanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 23 06:54:58 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B4612013B for ; Thu, 23 Jan 2020 06:54:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 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_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 hTpl1ntQK6Fk for ; Thu, 23 Jan 2020 06:54:55 -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 8AF4A1200E6 for ; Thu, 23 Jan 2020 06:54:55 -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=/2ujeHNxleA22VJbpk2QRFHClQYS5SxiA8K5r5Xyr2E=; b=IT/SvMRgzA+dwzl7+/VVsonEv qrZG9lgOhIiVFMBvVRW+vpZBIkz0Xw0qcn1c0OtNd9NhBS1RiTHGsdNr3N4NkWxBhj7wdG2dHz09k sWs2wL+gR8Z6HWTfaurfP76cKTglTrlHteOSbdVdPBfPMeswrDSh/PVztiIB76ohZTI2T3rmIlnt8 E/CNnOG03QKZJ1mLFWjpmz5Py3qKXG1X1xiyzC7JSkdCWFCQN4gBOlRBdgdxFAReCS4Pe467HtHFn /YDF/xquyNMarbw/2VNWnhyQqVFh5OwRKRSqKk4GuIy0ZAWvVpa54N13MqnEijrfwxeZxM/MoQ9XX 5w7PRuzBw==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:63750 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iudse-002wPX-Dv; Thu, 23 Jan 2020 09:54:53 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Joe Touch In-Reply-To: <495c6e94-d5a4-effe-3c4d-d5275deb8cc8@erg.abdn.ac.uk> Date: Thu, 23 Jan 2020 06:54:47 -0800 Cc: Fernando Gont , tcpm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk> <4D99C7DD-F57E-4708-8F02-824EB4BF8E24@weston.borman.com> <333A2AF9-7DDD-4FAA-B0BD-E6871564850F@strayalpha.com> <495c6e94-d5a4-effe-3c4d-d5275deb8cc8@erg.abdn.ac.uk> To: Gorry Fairhurst X-Mailer: Apple Mail (2.3608.40.2.2.4) 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: [tcpm] 793bis: IP ID X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 14:54:57 -0000 > On Jan 23, 2020, at 5:24 AM, Gorry Fairhurst = wrote: >=20 > I think this is the wrong ID to discuss anything related to IPv4 ID. I disagree.=20 It=E2=80=99s important to support the *requirement* in 6864 by = explicitly indicating that the ID *MUST NOT* be used for duplicate = segment detection in TCP. It=E2=80=99s not enough to simply ignore the issue. We can=E2=80=99t fix = incorrect implementations unless we have something to back it up. joe= From nobody Thu Jan 23 08:31:57 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F181208DB for ; Thu, 23 Jan 2020 08:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.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 tvoWj8eH5E9k for ; Thu, 23 Jan 2020 08:31:53 -0800 (PST) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 299DB1208DC for ; Thu, 23 Jan 2020 08:31:53 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id A094525A16 for ; Thu, 23 Jan 2020 17:31:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1579797111; bh=uA59VLW9WHqAOf594PzXYlmbKVIN7WSB5VoUTy9cT4Y=; h=From:To:Subject:Date:From; b=MNbFzdv7lk/OGEyMXQrq+PQoaRZZm32bTh4WwNQTnG9L/TZOGR2dTJ4OlJaF5yWeg FPR13mp0cCBh+XGJn51VN9duH314HRVQN0pWdiI8dlvH8HNtoomNB4DQk8sIcsdzhe 3dsCHyexQsxspleS1eOs9Kyns7D4DsRlVd5tfDos= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6J_XXBZ1NbV for ; Thu, 23 Jan 2020 17:31:51 +0100 (CET) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS for ; Thu, 23 Jan 2020 17:31:51 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.158]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Thu, 23 Jan 2020 17:31:50 +0100 From: "Scharf, Michael" To: tcpm IETF list Thread-Topic: Reminder: Several documents close to WGLC Thread-Index: AdXSBxSv2alz1IuKQw63aqjP/EnMYw== Date: Thu, 23 Jan 2020 16:31:50 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D8EC7F0@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.48.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] Reminder: Several documents close to WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 16:31:56 -0000 Hi all, I'd like to remind everybody that we have quite a number of documents that = seem relatively stable, i.e., the chairs are discussing starting correspond= ing WGLCs.=20 As an example for a document that hasn't received a lot of comments recentl= y, I'd like to mention draft-ietf-tcpm-2140bis. Reminder regarding this as well as other TCPM documents: It is always possi= ble to read and comment on documents on the list *between* meetings. No fur= ther comments implicitly imply agreement with the content... Thanks Michael From nobody Thu Jan 23 21:24:37 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE243120044 for ; Thu, 23 Jan 2020 21:24:35 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RI6L-SwrJJhu for ; Thu, 23 Jan 2020 21:24:34 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D514B120020 for ; Thu, 23 Jan 2020 21:24:33 -0800 (PST) Received: from [192.168.100.103] (unknown [186.183.3.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 955BE85FEF; Fri, 24 Jan 2020 06:24:26 +0100 (CET) To: Joe Touch , Gorry Fairhurst Cc: tcpm@ietf.org References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk> <4D99C7DD-F57E-4708-8F02-824EB4BF8E24@weston.borman.com> <333A2AF9-7DDD-4FAA-B0BD-E6871564850F@strayalpha.com> <495c6e94-d5a4-effe-3c4d-d5275deb8cc8@erg.abdn.ac.uk> From: Fernando Gont Message-ID: Date: Fri, 24 Jan 2020 01:58:56 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tcpm] 793bis: IP ID X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 05:24:36 -0000 On 23/1/20 11:54, Joe Touch wrote: > > >> On Jan 23, 2020, at 5:24 AM, Gorry Fairhurst wrote: >> >> I think this is the wrong ID to discuss anything related to IPv4 ID. > > I disagree. > > It’s important to support the *requirement* in 6864 by explicitly indicating that the ID *MUST NOT* be used for duplicate segment detection in TCP. With layering in mind, why would one want to do that? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 23 21:49:06 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65487120041 for ; Thu, 23 Jan 2020 21:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 pogQTF247gb4 for ; Thu, 23 Jan 2020 21:49:02 -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 BE6DD120020 for ; Thu, 23 Jan 2020 21:49:02 -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:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=jEa77ZBsLoIpdpAvsUG8GfTFHaKPvD5I/qZRSTisNWQ=; b=j8m9ooF4UYVtDvU0uqplN1Wlk vPwd8J8lB+7u+cxJJTTxUtLs8D11+dwH7PxWMXoeCfcyv7e7Yz+yiDFRmDAWItqWrPFyw00QflzUx /xsKYGrv+1GGsMNL85e/MVXCWkuMCv9dBmjQxNWORIp74A3lRO8Efobqmcf1hABuniwuKupQskUz7 dvg8owohSmDR2+KdOApWZIVgYHbP20vWiZKxrf3Qoky/RirqpDbEZQGzp61TL+VMgw2jt5rLD9W9F rghfRS8Xd6zSA/zEWGitnw+7EFaZFvux1LYA4gFt3IKtnbYAakIsYo45Z0iRJk5ji6CwOo2FE6e4D 2wJWKcqQQ==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:49918 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iurpw-001OgZ-9l; Fri, 24 Jan 2020 00:49:00 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_950ED203-14B9-4D6E-ABED-1D05C5810C22" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Joe Touch In-Reply-To: Date: Thu, 23 Jan 2020 21:48:55 -0800 Cc: Gorry Fairhurst , tcpm@ietf.org Message-Id: <5C1F0A09-F6B8-4EDB-BB9D-431DD6C04D06@strayalpha.com> References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk> <4D99C7DD-F57E-4708-8F02-824EB4BF8E24@weston.borman.com> <333A2AF9-7DDD-4FAA-B0BD-E6871564850F@strayalpha.com> <495c6e94-d5a4-effe-3c4d-d5275deb8cc8@erg.abdn.ac.uk> To: Fernando Gont X-Mailer: Apple Mail (2.3608.40.2.2.4) 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: [tcpm] 793bis: IP ID X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 05:49:04 -0000 --Apple-Mail=_950ED203-14B9-4D6E-ABED-1D05C5810C22 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 23, 2020, at 8:58 PM, Fernando Gont = wrote: >=20 > On 23/1/20 11:54, Joe Touch wrote: >>> On Jan 23, 2020, at 5:24 AM, Gorry Fairhurst = wrote: >>>=20 >>> I think this is the wrong ID to discuss anything related to IPv4 ID. >> I disagree. >> It=E2=80=99s important to support the *requirement* in 6864 by = explicitly indicating that the ID *MUST NOT* be used for duplicate = segment detection in TCP. >=20 > With layering in mind, why would one want to do that? Because the information in RFC1122 in section 4.2.2.15 needs to be = integrated and corrected to bring it up to date with RFC6864, even if in = the negative. I.e., this doc should be very clear on two points: - TCP MUST NOT attempt to control the IP ID to try to indicate = duplicate sent segments - TCP MUST NOT use the IP ID in trying to identify duplicate = received segments I.e., in summary, exactly to encode that layering. Joe --Apple-Mail=_950ED203-14B9-4D6E-ABED-1D05C5810C22 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jan 23, 2020, at 8:58 PM, Fernando Gont <fgont@si6networks.com> wrote:

On = 23/1/20 11:54, Joe Touch wrote:
On Jan 23, 2020, at 5:24 = AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:

I think this is the wrong ID to discuss anything related to = IPv4 ID.
I disagree.
It=E2=80=99s= important to support the *requirement* in 6864 by explicitly indicating = that the ID *MUST NOT* be used for duplicate segment detection in = TCP.

With layering in mind, = why would one want to do that?

Because the information in RFC1122 in = section 4.2.2.15 needs to be integrated and corrected to = bring it up to date with RFC6864, even if in the negative.

I.e., this doc should be very clear on two = points:

- TCP MUST NOT attempt to control = the IP ID to try to indicate duplicate sent segments
- TCP = MUST NOT use the IP ID in trying to identify duplicate received = segments

I.e., in summary, exactly = to encode that layering.

Joe


= --Apple-Mail=_950ED203-14B9-4D6E-ABED-1D05C5810C22-- From nobody Fri Jan 24 00:06:42 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57BA4120019; Fri, 24 Jan 2020 00:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Knac_7BHUuy7; Fri, 24 Jan 2020 00:06:37 -0800 (PST) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (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 0A6B5120041; Fri, 24 Jan 2020 00:06:14 -0800 (PST) Received: by mail-vs1-xe35.google.com with SMTP id p6so668662vsj.11; Fri, 24 Jan 2020 00:06:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uwDZS95ncEZ+sE9cBW51jdd1EYIX49fKtWXn1o56ahI=; b=TVq5DTzUggeDzB1F/cqRKP+mf9ISfBURBwpq/uJ3Wt/DqUZ1Q1b2rphyIopRT5t+/8 O6EtQsx4gzJl2g67XYkG7wuFW1+Eer2OKNdKSKtUOx4mbz9Ox8H9DbglTlbATTnJmqPp Wvsloq4OfltdDit91ZWKadhNCvJVevVmUHoHP85hnTUugmLC0zDwsXZKJKqsZIY2lvcy heuboIR7Et1u6o47HdmDEjt9/UM6l3NuFufWtaRamg9Ki6KSpNZedg8bTgLikY1Xgayj 5nw8aT3HFro98BFOiIcnMBu0Fv2h59YEp2fWZHx1j4uR8nZJCLeJ8BRN7mA52R9nQ5W3 5ZTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uwDZS95ncEZ+sE9cBW51jdd1EYIX49fKtWXn1o56ahI=; b=ZtA+wz89Vt6gn6Ssedq4NZjBOQ4ySmA/IkpSQJ5cAFdK0QDD4oNj/Q90MyKg8uJMBU i/ZZ0hWQk/h1Ul+WPdlERkpxuoz2Dsx9S49foUGp37USyB9CqTyRItsIgUelcOX1gANY 8nblm1TXfVzS1B7g3i+9r1xU/c31+YElr6WhluCqrXy0PwfFKb/VmA0oOYbeuvWPXkQT MyTTS5mCkfVp6EgZC0Jd9Bj07cE0/sSiQPC9xEupetyS9uGcO+io8kXpmeQEcIr4l38o oStAshHnNW1v8D00EGhlxgi19uxXPRuo98Uvmt2Ll73xDWRnYUEItAtbVQmnAeqDuoaL 1rew== X-Gm-Message-State: APjAAAVr1pGXH6aRgdZkyxyPgYJkftr8VI/ffxVyX4YIEH7EN8JnkziJ 3Zaa8vhyntXweIvxlKwvHDPfp5rjLS8v865syAFuIMyD X-Google-Smtp-Source: APXvYqxqsXHrTR/wviS1a0z/TT3LTOzpv5JyaLfyt5fytEe2kmiP6vXxIjSVIccZ+THGcXku89Hgd1OlX3x400CX2Tw= X-Received: by 2002:a67:ec12:: with SMTP id d18mr1373401vso.129.1579853173380; Fri, 24 Jan 2020 00:06:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Yoshifumi Nishida Date: Fri, 24 Jan 2020 00:06:02 -0800 Message-ID: To: "tcpm@ietf.org Extensions" Cc: tcpm-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000325d71059cde3b7b" Archived-At: Subject: Re: [tcpm] intended status of draft-ietf-tcpm-accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 08:06:40 -0000 --000000000000325d71059cde3b7b Content-Type: text/plain; charset="UTF-8" Hi everyone, Sorry for taking long time. After several discussions among the chairs, we've concluded the rough consensus of the WG is that this document should target PS. As tcpm is a relatively small community, it's sometimes not easy to assess the consensus in the group. However, as far as we've checked, most of people don't have issues on publishing it as a PS doc. This will mean the updated version of this draft will require further detailed reviews since the current version was written for an experimental doc. This might take extra time compared to publishing an EXP draft. In addition, there are possibilities that other ECN proposals will be published in the future (and they can be PS as well). This draft should be carefully reviewed not to prevent such activities. Thanks, -- Yoshi on behalf of tcpm co-chairs On Fri, Dec 13, 2019 at 1:17 AM Yoshifumi Nishida wrote: > Hi folks, > > We would like to get feedback for the intended status > of draft-ietf-tcpm-accurate-ecn. > The current intended status of this draft is experimental, but we've seen > some voices that PS is more preferable for the draft during Singapore > meeting and on the ML. So, we would like to check the consensus on it. > > There are some on-going related discussions such as flag registration > policy, SCE, ECN++, etc, however, we believe the intended status > discussions is independent from them and can proceed it separately. (If you > have concerns on it, please share your opinion here) > > We appreciate your feedback. > > Thanks, > -- > Yoshi on behalf of tcpm co-chairs. > > > --000000000000325d71059cde3b7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

Sorry for = taking long time. After several discussions among the chairs, we've con= cluded the rough consensus of the WG is that this document should target PS= .

As tcpm is a relatively small community, it= 's sometimes not easy to assess the consensus in the group.
H= owever, as far as we've checked, most of people don't have issues o= n publishing it as a PS doc.

This will mean = the updated version of this draft will require further detailed reviews sin= ce the current version was written for an experimental doc. This might take= extra time compared to publishing an EXP draft.
In addition, the= re are possibilities that other ECN proposals will be published in the futu= re (and they can be PS as well). This draft should be carefully reviewed no= t to prevent such activities.

Thanks,
--=
Yoshi on behalf of tcpm co-chairs


=
On Fri, De= c 13, 2019 at 1:17 AM Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:
Hi folks,
<= div dir=3D"ltr">
We would like to get feedback for the in= tended status of=C2=A0draft-ietf-tcpm-accurate-ecn.=C2=A0
=
The current intended status of this draft is experimental, but we'= ve seen some voices that PS is more preferable for the draft during Singapo= re meeting and on the ML. So, we would like to check the consensus on it.

There are some on-going related discussions such as= flag registration policy, SCE, ECN++, etc, however, we believe the intende= d status discussions is independent from them and can proceed it separately= . (If you have concerns on it, please share your opinion here)
We appreciate your feedback.

Thanks,<= /div>
--
Yoshi on behalf of tcpm co-chairs.


--000000000000325d71059cde3b7b-- From nobody Fri Jan 24 03:55:55 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3EAD120044 for ; Fri, 24 Jan 2020 03:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 DXS0xIIoQVxH for ; Fri, 24 Jan 2020 03:55:51 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1DCE120024 for ; Fri, 24 Jan 2020 03:55:50 -0800 (PST) Received: from [192.168.100.103] (unknown [186.183.3.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id AC99886107; Fri, 24 Jan 2020 12:55:01 +0100 (CET) To: Joe Touch Cc: Gorry Fairhurst , tcpm@ietf.org References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk> <4D99C7DD-F57E-4708-8F02-824EB4BF8E24@weston.borman.com> <333A2AF9-7DDD-4FAA-B0BD-E6871564850F@strayalpha.com> <495c6e94-d5a4-effe-3c4d-d5275deb8cc8@erg.abdn.ac.uk> <5C1F0A09-F6B8-4EDB-BB9D-431DD6C04D06@strayalpha.com> From: Fernando Gont Message-ID: <58445bde-d5a1-d853-cb50-80d1ab1fc8e6@si6networks.com> Date: Fri, 24 Jan 2020 03:08:36 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <5C1F0A09-F6B8-4EDB-BB9D-431DD6C04D06@strayalpha.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tcpm] 793bis: IP ID X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 11:55:53 -0000 On 24/1/20 02:48, Joe Touch wrote: > > >> On Jan 23, 2020, at 8:58 PM, Fernando Gont > > wrote: >> >> On 23/1/20 11:54, Joe Touch wrote: >>>> On Jan 23, 2020, at 5:24 AM, Gorry Fairhurst >>> > wrote: >>>> >>>> I think this is the wrong ID to discuss anything related to IPv4 ID. >>> I disagree. >>> It’s important to support the *requirement* in 6864 by explicitly >>> indicating that the ID *MUST NOT* be used for duplicate segment >>> detection in TCP. >> >> With layering in mind, why would one want to do that? > > Because the information in RFC1122 in section 4.2.2.15 needs to be > integrated Does it? It would seem to me that these IP ID tricks are an implementation-specific trick that would never be implemented in general-purpose implementations. Even more, it would make even less sense in the light of the Internet moving towards IPv6 (albeit at a horrible pace), wheere the "IP ID" is not available in all packets. > and corrected to bring it up to date with RFC6864, even if in > the negative. > > I.e., this doc should be very clear on two points: > > - TCP MUST NOT attempt to control the IP ID to try to indicate duplicate > sent segments > - TCP MUST NOT use the IP ID in trying to identify duplicate received > segments > > I.e., in summary, exactly to encode that layering. My question here is whether we want to drag such (mostly obsolete) details into this more modern spec, or not. It would seem yo me that a fresh reader of *this* 793bis would probably be quite puzzled when reading this sort of requirement that mostly have to do with what some implementations did ages ago... -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jan 24 04:42:39 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88EF112001E; Fri, 24 Jan 2020 04:42:37 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 k6WkghCgCPTJ; Fri, 24 Jan 2020 04:42:34 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06DEA12003E; Fri, 24 Jan 2020 04:42:34 -0800 (PST) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 483zLb3tW3z5vyR; Fri, 24 Jan 2020 13:42:31 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 483zLb2yGczCqkh; Fri, 24 Jan 2020 13:42:31 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM42.corporate.adroot.infra.ftgroup ([fe80::1c8e:403e:fbea:5835%21]) with mapi id 14.03.0468.000; Fri, 24 Jan 2020 13:42:31 +0100 From: To: Mirja Kuehlewind , "draft-ietf-tcpm-converters.all@ietf.org" CC: tcpm IETF list Thread-Topic: AD review of draft-ietf-tcpm-converters-14 Thread-Index: AQHVxzOtzufBQBxQTEiSsj2yNS+tRqf51j0A Date: Fri, 24 Jan 2020 12:42:31 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933031410A7D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <4DF47B41-2A8F-4FC1-8734-4D133F3EBBE5@kuehlewind.net> In-Reply-To: <4DF47B41-2A8F-4FC1-8734-4D133F3EBBE5@kuehlewind.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] AD review of draft-ietf-tcpm-converters-14 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 12:42:38 -0000 SGkgTWlyamEsIA0KDQpXZSBhcmUgY3VycmVudGx5IHByZXBhcmluZyBjaGFuZ2VzIHRvIHRha2Ug aW50byBhY2NvdW50IHlvdXIgcmV2aWV3LiBPdXIgcGxhbiBpcyB0byBoYXZlIGEgcmV2aXNlZCB2 ZXJzaW9uIGJ5IHRoZSBuZXh0IHdlZWsgYnV0IEkgd291bGQgbGlrZSB0byByZXBvcnQgb24gdGhp cyBjb21tZW50OiANCg0KPiA2KSBDYW4geW91IG1heWJlIGFkZCBzb21lIG1vcmUgdGV4dCAoaW4g c2VjdGlvbiA1IG1heWJlKSB3aHkgYQ0KPiBzZXBhcmF0ZSBwb3J0IG51bWJlciBpcyB1c2VkL25l ZWRlZD8gQXMgdGhlIGNsaWVudCBoYXMgdG8gYmUNCj4gZXhwbGljaXRseSBjb25maWd1cmVkIGl0 IGNvdWxkIGVhc2lseSBiZSBjb25maWd1cmVkIHdpdGggYW4gYWRkcmVzcw0KPiBhbmQgcG9ydCBu dW1iZXIuIElzIHRoaXMgdG8gYXZvaWQgY29sbGlzaW9ucyB3aXRoIG90aGVyIHByb3RvY29scz8N Cj4gV2hhdCB3b3VsZCBiZSB0aGUgc2NlbmFyaW8gaGVyZT8NCg0KQWZ0ZXIgY2FyZWZ1bGx5IHJl LXJlYWRpbmcgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc2MDUjc2VjdGlvbi03LjEg YW5kIHRha2luZyBpbnRvIGFjY291bnQgdGhlIGRlcGxveW1lbnQgbW9kZWxzLCBhbiBJUCBhZGRy ZXNzIHdpbGwgYmUgbmVlZGVkIHRvIGJlIHN1cHBsaWVkL2Rpc2NvdmVyZWQgYW55d2F5Li4uIHNv IHRoZSBwb3J0IG51bWJlciBjYW4gYmUgc3VwcGxpZWQvZGlzY292ZXJlZCBhcyB3ZWxsLiANCg0K VW5sZXNzIHRoZXJlIGlzIGFuIG9iamVjdGlvbiwgd2Ugd2lsbCB1cGRhdGUgdGhlIGRyYWZ0IHRv IG9ubHkgcmVnaXN0ZXIgYSBzZXJ2aWNlIG5hbWUgd2l0aG91dCBhc2tpbmcgZm9yIGFueSBzcGVj aWZpYyBwb3J0LiBUaGUgbmFtZSB3aWxsIGJlIHR5cGljYWxseSB1c2VkIHRvIGJ1aWxkIHNlcnZp Y2UgbGFiZWxzIHRoYXQgY2FuIGJlIHRoZW4gdXNlZCB0byByZXRyaWV2ZSBhIHNlcnZpY2UgcG9y dCBudW1iZXIgdXNpbmcsIGUuZy4sIEROUyBTUlYuIA0KDQpUaGFuayB5b3UuDQoNCkNoZWVycywN Ck9saXZpZXIgJiBNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDog TWlyamEgS3VlaGxld2luZCBbbWFpbHRvOmlldGZAa3VlaGxld2luZC5uZXRdDQo+IEVudm95w6nC oDogamV1ZGkgOSBqYW52aWVyIDIwMjAgMjI6MjgNCj4gw4DCoDogZHJhZnQtaWV0Zi10Y3BtLWNv bnZlcnRlcnMuYWxsQGlldGYub3JnDQo+IENjwqA6IHRjcG0gSUVURiBsaXN0DQo+IE9iamV0wqA6 IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLXRjcG0tY29udmVydGVycy0xNA0KPiANCj4gSGkgYXV0 aG9ycywNCj4gDQo+IEkgZmluYWxseSBkaWQgbXkgQUQgcmV2aWV3IGZvciBkcmFmdC1pZXRmLXRj cG0tY29udmVydGVycy0xNCAoYWN0dWFsbHkNCj4gSSdtIHN0aWxsIG5vdCBmdWxseSBmaW5pc2hl ZCB3aXRoIHRoZSByZXZpZXcgb2YgdGhlIGFwcGVuZGl4IGJ1dCB3b3VsZA0KPiBsaWtlIHRvIHNl bmQgb3V0IHRoaXMgZmlyc3QgYmF0Y2ggb2YgcXVlc3Rpb25zIG5vdykuDQo+IA0KPiBBcyB5b3Ug Y2FuIHNlZSBiZWxvdywgSSBoYXZlIGEgd2hvbGUgYnVuY2ggb2YgcXVlc3Rpb25zL2NvbW1lbnRz LiBTb21lDQo+IG9mIHRoZXNlIG1heSBvbmx5IGJlIGVkaXRvcmlhbCBpbiB0aGUgZW5kIGJ1dCBJ IHdvdWxkIGxpa2UgdG8gbWFrZQ0KPiBzdXJlIHRoYXQgSSB1bmRlcnN0YW5kIGFsbCB0aGUgdGVj aG5pY2FsIHBhcnRzIGNvcnJlY3RseSBiZWZvcmUgd2UNCj4gbW92ZSBvbiB3aXRoIHRoZSBwcm9j ZXNzaW5nLg0KPiANCj4gSSB0aGluayB0aGVyZSBhcmUgYmFzaWNhbGx5IHR3byBtYWluIHRlY2hu aWNhbCBwb2ludHMgSSB3b3VsZCBsaWtlIHRvDQo+IGdldCBzb21lIGNsYXJpZmljYXRpb24gb24s IGJvdGggcHJvYmFibHkgcmVsYXRlZCB0byB0aGluZ3MgdGhhdCBoYXZlDQo+IGJlZW4gaW50cm9k dWNlZCBsYXRlciBpbiB0aGUgbGlmZSB0aW1lIG9mIHRoZSBkb2MgYnV0IG1heWJlIG5vdA0KPiBj b25zZXF1ZW50bHkgYmVlbiBjaGFuZ2VkIHRocm91Z2hvdXQgdGhlIHdob2xlIGRvYy4NCj4gDQo+ IE9uZSBpcyBiZXNpYWNsbHkgcG9pbnQgOCBiZWxvdyBidXQgdGhlcmUgYXJlIHNvbWUgcmVsYXRl ZCBvdGhlciBwb2ludHMNCj4gYmVsb3c6IEl0IGlzIG5vdCBmdWxseSBjbGVhciB3aGljaCBwYWNr ZXRzIGNhbiBjYXJyeSBDb252ZXJ0IG1lc3NhZ2VzLg0KPiBJIHRoaW5rIGluaXRpYWxseSBDb252 ZXJ0IG1lc3NhZ2VzIHdlcmUgb25seSBzdXBwb3NlZCB0byBiZSBpbiB0aGUgU1lODQo+IGFuZCBT WU4vQUNLLiBCdXQgdGhlbiBsYXRlciB5b3UgZW5hYmxlZCBpdCBhbHNvIGZvciBvdGhlciBwYWNr ZXRzLA0KPiBob3dldmVyLCBpdCBzZWVtIHRoZSBvbmx5IHJlYWwgY2FzZSB0aGF0IG5lZWRzIHRo aXMgaXMgd2hlbiBhbiBlcnJvcg0KPiBtZXNzYWdlIGlzIHNlbmQgYnkgdGhlIGNsaWVudC4gQnV0 IHNlbmRpbmcgQ29udmVydCBtZXNzYWdlcyBpbiBvdGhlcg0KPiBwYWNrZXQgdGhhbiB0aGUgU1lO IGFuZCB0aGUgU1lOL0FDSyBzZWVtcyBtb3JlIGNvbXBsaWNhdGVkIGJlY2F1c2UgYWxsDQo+IFRD UCBwYXlsb2FkIGRhdGEgaXMgdHJhbnNtaXR0ZWQgcmVsaWFibGUgYW5kIG11c3QgYmUgYWNrJ2Vk IGFuZCBldmlsLg0KPiByZXRyYW5zbWl0dGVkLiBNYXliZSBpdOKAmXMgb2theSBpZiBvbmx5IGFu IGVycm9yIG1lc3NhZ2UgaXMgc2VuZCBhbmQgYQ0KPiByZXNldCByaWdodCBhZnRlciAoc28gbm8g cmV0cmFuc21pc3Npb24pLCBob3dldmVyLCB0aGlzIGlzIG5vdA0KPiBzcGVjaWZpZWQsIGFuZCBJ IHdvbmRlciBpZiB0aGUgY29tcGxleGl0eSBpcyByZWFsbHkgbmVlZGVkIHdvcnRoIHRoZQ0KPiBi ZW5lZml0IG9mIGJlaW5nIGFibGUgdG8gbG9nIG1vcmUgY29uY3JldGUgZXJyb3JzIGluIHRoZSBj b252ZXJ0ZXIuDQo+IA0KPiBUaGUgb3RoZXIgcG9pbnQgaXMgYmFzaWNhbGx5IHBvaW50IDEyIGJl bG93IGFib3V0IHRoZSBUQ1Agb3B0aW9uIGZpZWxkDQo+IGluIHRoZSBDb25uZWN0IFRMViAoYWxz byByZWxhdGVkIHRvIHBvaW50IDE3IGJlbG93KS4gVGhpcyBpcyBub3Qgd2VsbA0KPiBlbm91Z2gg c3BlY2lmaWVkIGFuZCBzZWVtIGFsc28gcXVpdGUgY29tcGxleCBhcyBhIGdlbmVyaWMgbWVjaGFu aXNtLiBJDQo+IHdvdWxkIHRoaW5rIHRoZSBjb252ZXJ0ZXIgc2hvdWxkIHVzdWFsbHkgdHJ5IHRv IHVzZSB0aGUgc2FtZSBvcHRpb24gYXMNCj4gdGhlIGNsaWVudCBkaWQgc2VuZCBpbiBoaXMgU1lO IHRvIHRoZSBjb252ZXJ0ZXIsIGlmIHN1cHBvcnRlZCBieSB0aGUNCj4gY29udmVydGVyIFRDUCBp bXBsZW1lbnRhdGlvbi4gVGhlIFRGTyBjb29raWUgbWlnaHQgYmUgYSBzcGVjaWFsIGNhc2UuDQo+ IEnigJltIG5vdCBzdXJlIGlmIHRoYXQgbmVlZHMgdG8gYmUgZ2VuZXJhbGlzZWQgb3IgaWYgaGF2 aW5nIGEgc2VwYXJhdGUNCj4gVExWIGZvciB0aGF0IG9uZSBjYXNlIG1pZ2h0IGJlIHNpbXBsZXIu IFBsZWFzZSBhbHNvIHJlY29uc2lkZXIgdGhpcw0KPiBidXQgaW4gYW55IGNhc2UgaXQgbmVlZHMg bW9yZSBleHBsYW5hdGlvbiBpbiB0aGUgc3BlYy4NCj4gDQo+IFBsZWFzZSBzZWUgYWxsIG15IHF1 ZXN0aW9ucy9jb21tZW50cyBiZWxvdy4gSSBtYXkgc2VuZCBhbm90aGVyDQo+IG1lc3NhZ2UsIHdo ZW4gSSBoYXZlIHJldmlld2VkIHRoZSBhcHBlbmRpeCB0b21vcnJvdyAoaG9wZWZ1bGx5IHdpdGgN Cj4gbm9uZSBvciBvbmx5IGZldyBhZGRpdGlvbmFsIGNvbW1lbnRzKS4NCj4gDQo+IFRoYW5rcyEN Cj4gTWlyamENCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IDEpIEkgd2FzIGlu aXRpYWxseSBhIGJpdCBjb25mdXNlZCBhYm91dCB0aGUgc2V0dXAgaW4gRmlndXJlIDYgYW5kDQo+ IHJlc3BlY3RpdmVseSB0aGUgcGFyYWdyYXBoIGp1c3QgYmVmb3JlIHRoYXQgZmlndXJlIGluIHNl YyAzLjI6IEl0DQo+IHdhc24ndCBjbGVhciB0byBtZSBob3cgdGhlIHNlcnZlciBtaWdodCBrbm93 IHRoZSBjb252ZXJ0ZXIgYWRkcmVzcyAob3INCj4gaWYgdGhlIHByb3h5IG1heWJlIGhhcyB0byBi ZSBvbiBwYXRoKS4gSSBhc3N1bWUgdGhlIOKAnHVzZSBjYXNl4oCdIGlzIHRoYXQNCj4gdGhlcmUg d2FzIGEgcHJldmlvdXMgY29ubmVjdGlvbiB1c2luZyB0aGUgY29udmVydGVyIGFuZCBub3cgdGhl IHNlcnZlcg0KPiB0cmllcyB0byByZWNvbm5lY3QgYnV0IG9mIGNvdXJzZSBvbmx5IGtub3dzIHRo ZSBjb252ZXJ0ZXIgYWRkcmVzcywgb3INCj4gc29tZXRoaW5nPyBNYXliZSB5b3UgY291bGQgYWRk IHNsaWdodGx5IG1vcmUgdGV4dCBoZXJlLiBJIGFsc28gSSB3b3VsZA0KPiByZWNvbW1lbmQgdG8g ZXhwbGljaXRseSBtZW50aW9uIHRoYXQgdGhpcyBzZXR1cCBzdGlsbCBoYXMgdG8gYmUNCj4gZXhw bGljaXRseSBjb25maWd1cmVkIGJ5IHRoZSBjbGllbnQgYnV0IHVzaW5nIGFuIG91dCBvZiBiYW5k IHByb3RvY29sDQo+ICh3aGljaCBpcyBvdXQgb3Igc2NvcGUgZm9yIHRoaXMgc3BlYykuIEZ1cnRo ZXIgSSB0aGluayBpdCB3b3VsZCBiZQ0KPiBnb29kIHRvIG1lbnRpb24gaGVyZSBhbHJlYWR5IHRo YXQgdGhlIGNvbnZlcnRlciBhbHNvIGluc2VydHMgdGhlDQo+IHJlc3BlY3RpdmUgVENQIG9wdGlv biBpbiB0aGUgU1lOIHRvIHRoZSBjbGllbnQgKGlmIHBvc3NpYmxlIGR1ZSB0bw0KPiBzcGFjZSBs aW1pdHMpIGFuZCByZWZlciB0byBzZWN0aW9uIDQuMiBmb3IgYSBjb25jcmV0ZSBleGFtcGxlLg0K PiANCj4gQnR3LiBzaG91bGRuJ3QgdGhlcmUgYmUgc29tZSBkaXNjdXNzaW9uIGFib3V0IE1UVSBp c3N1ZSBpZiBvcHRpb25zIGFyZQ0KPiBhZGRlZCBieSB0aGUgY29udmVydGVyPw0KPiANCj4gMikg VGhlIGZvbGxvd2luZyBwYXJhZ3JhcGggaW4gc2VjdGlvbiAzLjIuIHNlZW1zIHRvIHNwZWNpZnkg cHJvdG9jb2wNCj4gcmVxdWlyZW1lbnRzIGJ1dCBkb27igJl0IHVzZSBub3JtYXRpdmUgbGFuZ3Vh Z2U6DQo+IA0KPiAiSWYgdGhlIGRvd25zdHJlYW0gKG9yIHVwc3RyZWFtKSBjb25uZWN0aW9uIGZh aWxzIGZvciBzb21lIHJlYXNvbg0KPiAgICAoZXhjZXNzaXZlIHJldHJhbnNtaXNzaW9ucywgcmVj ZXB0aW9uIG9mIGFuIFJTVCBzZWdtZW50LCBldGMuKSwNCj4gdGhlbg0KPiAgICB0aGUgQ29udmVy dGVyIHNob3VsZCBmb3JjZSB0aGUgdGVhci1kb3duIG9mIHRoZSB1cHN0cmVhbSAob3INCj4gICAg ZG93bnN0cmVhbSkgY29ubmVjdGlvbi4NCj4gDQo+ICAgIFRoZSBzYW1lIHJlYXNvbmluZyBhcHBs aWVzIHdoZW4gdGhlIHVwc3RyZWFtIGNvbm5lY3Rpb24gZW5kcy4gIEluDQo+ICAgIHRoaXMgY2Fz ZSwgdGhlIENvbnZlcnRlciBzaG91bGQgYWxzbyB0ZXJtaW5hdGUgdGhlIGRvd25zdHJlYW0NCj4g ICAgY29ubmVjdGlvbiBieSB1c2luZyBGSU4gc2VnbWVudHMuICBJZiB0aGUgZG93bnN0cmVhbSBj b25uZWN0aW9uDQo+ICAgIHRlcm1pbmF0ZXMgd2l0aCB0aGUgZXhjaGFuZ2Ugb2YgRklOIHNlZ21l bnRzLCB0aGUgQ29udmVydGVyIHNob3VsZA0KPiAgICBpbml0aWF0ZSBhIGdyYWNlZnVsIHRlcm1p bmF0aW9uIG9mIHRoZSB1cHN0cmVhbSBjb25uZWN0aW9uLuKAnQ0KPiANCj4gSSByZWNvbW1lbmQg dG8gdXNlIG5vcm1hdGl2ZW4gbGFuZ3VhZ2UgaGVyZSAoU0hPVUxEIGluc3RlYWQgb2Ygc2hvdWxk Ow0KPiBvciBtYXliZSBldmVuIE1VU1Q/KS4gSG93ZXZlciwgYXMgdGhpcyB0ZXh0IGlzIHBhcnQg b2YgYSBraW5kIG9mDQo+IG92ZXJ2aWV3IHNlY3Rpb24sIGl0IGRvZXNu4oCZdCBzZWVtIHRvIGJl IGEgcmVhbGx5IGdvb2QgZml0IHRvIHVzZQ0KPiBub3JtYXRpdmUgbGFuZ3VhZ2UgaW4gdGhhdCBz ZWN0aW9uLiBTbyBtYXliZSB0aGUgd2hvbGUgZGlzY3Vzc2lvbg0KPiBhYm91dCB1c2Ugb2YgVEZP IChvciBub3QpIHNob3VsZCBiZSBtb3ZlZCB0byBhbiBvd24gc2VjdGlvbj8NCj4gDQo+IA0KPiAz KSBKdXN0IHRvIGRvdWJsZS1jaGVjaywgSSdtIHdvbmRlcmluZyBhIGJpdCBhYm91dCB0aGlzIHBo cmFzaW5nIGluDQo+IHNlYyAzLjMuMToNCj4gIklmIG5vIGVudHJ5IGlzIGZvdW5kLCB0aGUgVHJh bnNwb3J0IENvbnZlcnRlciBNVVNUIHNpbGVudGx5DQo+ICAgIGlnbm9yZSB0aGUgcGFja2V0LuKA nQ0KPiBUaGF0IG1lYW5zIHRoZSBjb252ZXJ0ZXIgd2lsbCBkcm9wIHRoZSBwYWNrZXQgKHdpdGgg bm8gb3RoZXIgYWN0aW9uKSwNCj4gcmlnaHQ/IFdoeSBkbyB5b3UgdXNlIHRlcm0gaWdub3JlIGhl cmUgKGluc3RlYWQgb2YgZHJvcCBvciBkaXNjYXJkKT8NCj4gT3IgZG9lcyB0aGlzIGhhdmUgYW55 IG90aGVyIGltcGxpY2F0aW9uPw0KPiBOb3RlIHRoYXQgdGhpcyB0ZXJtIGlzIHVzZWQgc2V2ZXJh bCB0aW1lcyBpbiB0aGUgZG9jLg0KPiANCj4gNCkgQWxzbyBhIHF1aWNrIHF1ZXN0aW9uIGFib3V0 IHRoaXMgaW4gc2VjIDMuMy4xOg0KPiAiQSBUcmFuc3BvcnQgQ29udmVydGVyIG1heSBvcGVyYXRl IGluIGFkZHJlc3MgcHJlc2VydmF0aW9uIG1vZGUgKHRoYXQNCj4gICAgaXMsIHRoZSBDb252ZXJ0 ZXIgZG9lcyBub3QgcmV3cml0ZSB0aGUgc291cmNlIElQIGFkZHJlc3MgKGkuZS4sDQo+ICAgIEM9 PVQpKSBvciBhZGRyZXNzIHNoYXJpbmcgbW9kZSAodGhhdCBpcywgYW4gYWRkcmVzcyBwb29sIGlz IHNoYXJlZA0KPiAgICBhbW9uZyBhbGwgQ2xpZW50cyBzZXJ2aWNlZCBieSB0aGUgQ29udmVydGVy IChpLmUuLCBDIT1UKSk7IHJlZmVyIHRvDQo+ICAgIEFwcGVuZGl4IEQgZm9yIG1vcmUgZGV0YWls cy4gIFdoaWNoIGJlaGF2aW9yIHRvIHVzZSBieSBhIFRyYW5zcG9ydA0KPiAgICBDb252ZXJ0ZXIg aXMgZGVwbG95bWVudC1zcGVjaWZpYy7igJ0NCj4gSSBndWVzcyBwcmVzZXJ2YXRpb24gbW9kZSBj YW4gb25seSBiZSB1c2VkIGlmIHRoZSBjb252ZXJ0ZXIgaXMgb24NCj4gcGF0aC4gSSB0aGluayB0 aGF0IHNob3VsZCBiZSBleHBsaWNpdGx5IG5vdGVkIGhlcmUuDQo+IA0KPiA1KSBTZWMgMy4zLjI6 IFRvIGJlIGhvbmVzdCBJ4oCZbSBub3Qgc3VyZSBJIGZ1bGx5IHVuZGVyc3RhbmQgdGhpcw0KPiBz ZWN0aW9uLCBlc3BlY2lhbGx5IHRoaXMgc2VudGVuY2U6DQo+ICJVcG9uIHJlY2VpcHQgb2YgYSBz ZWNvbmRhcnkgc3ViZmxvdyBieSB0aGUgVHJhbnNwb3J0IENvbnZlcnRlciBmcm9tIGENCj4gICAg Q2xpZW50LCB0aGUgQ29udmVydGVyIGZvbGxvd3MgdGhlIHNhbWUgYmVoYXZpb3Igc3BlY2lmaWVk IGluDQo+ICAgIFNlY3Rpb24gMy4zLjEgZm9yIHByb2Nlc3NpbmcgTm9uLVNZTnMu4oCdDQo+IERv IHlvdSBtZWFuIGJ5ICJyZWNlaXB0IG9mIGEgc2Vjb25kYXJ5IHN1YmZsb3figJ0gdGhlIFNZTiBv biB0aGF0DQo+IHN1YmZsb3cgb3Igb3RoZXIgZGF0YT8gRm9yIHRoZSBTWU4gSSB3b3VsZCBleHBl Y3QgdGhhdCB0aGVyZSBpcyBubw0KPiBwYXlsb2FkIGRhdGEgYW5kIHRoZXJlZm9yZSBub3RoaW5n IHRvIHByb3h5LiBGb3Igb3RoZXIgc3ViZmxvdw0KPiBwYWNrZXRzLCBJIGd1ZXNzIHlvdSBuZWVk IHRvIHJlb3JkZXIgZmlyc3QsIHNvIHByb2JhYmx5IGl0IHdvdWxkIGJlDQo+IGdvb2QgdG8gbWVu dGlvbiB0aGF04oCmPyBNYXliZSBpdOKAmXMganVzdCBtZSBtaXN1bmRlcnN0YW5kaW5nIHNvbWV0 aGluZw0KPiBidXQgSSBiZWxpZXZlIG1vcmUgZXhwbGFuYXRpb24gaXMgbmVlZGVkIGhlcmUuDQo+ IA0KPiA2KSBDYW4geW91IG1heWJlIGFkZCBzb21lIG1vcmUgdGV4dCAoaW4gc2VjdGlvbiA1IG1h eWJlKSB3aHkgYQ0KPiBzZXBhcmF0ZSBwb3J0IG51bWJlciBpcyB1c2VkL25lZWRlZD8gQXMgdGhl IGNsaWVudCBoYXMgdG8gYmUNCj4gZXhwbGljaXRseSBjb25maWd1cmVkIGl0IGNvdWxkIGVhc2ls eSBiZSBjb25maWd1cmVkIHdpdGggYW4gYWRkcmVzcw0KPiBhbmQgcG9ydCBudW1iZXIuIElzIHRo aXMgdG8gYXZvaWQgY29sbGlzaW9ucyB3aXRoIG90aGVyIHByb3RvY29scz8NCj4gV2hhdCB3b3Vs ZCBiZSB0aGUgc2NlbmFyaW8gaGVyZT8NCj4gDQo+IDcpIFNlYyA1LjE6DQo+ICJUaGUgVW5hc3Np Z25lZCBmaWVsZCBNVVNUIGJlIHNldCB0byB6ZXJvIGluIHRoaXMgdmVyc2lvbiBvZiB0aGUNCj4g ICAgcHJvdG9jb2wuICBUaGVzZSBiaXRzIGFyZSBhdmFpbGFibGUgZm9yIGZ1dHVyZSB1c2UgW1JG QzgxMjZdLuKAnQ0KPiBXaHkgaXMgdGhlcmUgYSByZWZlcmVuY2UgdG8gUkZDODEyNiBoZXJlPw0K PiANCj4gOCkgQWxzbyBzZWMgNS4xIGJ1dCBwcm9iYWJseSBlZGl0b3JpYWw6DQo+ICJEYXRhIGFk ZGVkIGJ5IHRoZSBDb252ZXJ0IFByb3RvY29sIHRvIHRoZSBUQ1AgYnl0ZXN0cmVhbSBpcw0KPiAg ICB1bmFtYmlndW91c2x5IGRpc3Rpbmd1aXNoZWQgZnJvbSBwYXlsb2FkIGRhdGEgYnkgdGhlIFRv dGFsIExlbmd0aA0KPiAgICBmaWVsZCBpbiB0aGUgQ29udmVydCBtZXNzYWdlcy7igJ0NCj4gSSBi ZWxpZXZlIHdoYXQgeW91IHdhbnQgdG8gc2F5IGhlcmUgaXMgdGhhdCB0aGUgdG90YWwgbGVuZ3Ro IGlzIHVzZWQNCj4gdG8gZmlndXJlIG91dCB3aGVyZSBwb3RlbnRpYWwgb3RoZXIgcGF5bG9hZCBk YXRhIG1pZ2h0IHN0YXJ0LiBIb3dldmVyLA0KPiB3aGF0IEkgd291bGQgdW5kZXJzdGFuZCBmcm9t IHRoaXMgc2VudGVuY2UgaXMgdGhhdCB0aGUgdG90YWwgbGVuZ3RoDQo+IGZpZWxkIGNhbiBiZSB1 c2VkIHRvIGRpc3Rpbmd1aXNoIFNZTnMgdGhhdCBjYXJyeSB0aGUgQ29udmVydCBwcm90b2NvbA0K PiBmcm9tIFNZTnMgdGhhdCBtYXkgY2Fycnkgb3RoZXIgcGF5bG9hZCBvbmx5LCB3aGljaCBJIGRv buKAmXQgdGhpbmsgaXMNCj4gdGhlIGNhc2UuDQo+IA0KPiA4KSBJIGZpcnN0IGhhdmUgYSBtb3Jl IGdlbmVyYWwgcXVlc3Rpb24gYWJvdXQgdGhlIGZ1bmN0aW9uIG9mIHRoZQ0KPiBwcm90b2NvbC4g U2VjIDUgc2F5czoNCj4gIkNvbnZlcnQgbWVzc2FnZXMgbWF5IGFwcGVhciBvbmx5IGluIGEgU1lO LCBTWU4rQUNLLCBvciBBQ0su4oCdDQo+IEnigJltIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB0aGUg QUNLIGNhc2UgaGVyZSBiZWNhdXNlIGlmIHlvdSBhZGQgYQ0KPiBDT05WRVJUIG1lc3NhZ2UgdG8g YSBUQ1AgcGFja2V0IHRoYXQgbWVhbnMgeW91IGFkZCBwYXlsb2FkIGRhdGEuIEkgd2FzDQo+IHJl YWRpbmcgdGhpcyBhcyBwdXJlIEFDSyBidXQgdGhhdCBjYW4ndCBiZSB0aGUgY2FzZS4gU28gZG8g eW91IG1lYW4gYnkNCj4gdGhpcyB5b3UgY2FuIG9ubHkgc2VuZCBuZXcgZGF0YSBpZiB5b3VyIHBy ZXZpb3VzIGRhdGEgd2FzIEFDSyBvcg0KPiBzb21ldGhpbmcgZWxzZeKApj8NCj4gSG93ZXZlciwg SSBiZWxpZXZlIHRoZXJlIGlzIHVzdWFsbHkganVzdCBvbmUgbWVzc2FnZSBmcm9tIHRoZSBjbGll bnQNCj4gaW4gdGhlIFNZTiBhbmQgdGhlIG9uZSBtZXNzYWdlIGZyb20gdGhlIGNvbnZlcnRlciBp biB0aGUgU1lOL0FDSywgYW5kDQo+IHRoZW4gdGhlIGNvbm5lY3Rpb24gaXMgZWl0aGVyIGNsb3Nl ZCBvciBzd2l0Y2hlZCB0byB0aGUgYWN0dWFsIHBheWxvYWQNCj4gdHJhbnNtaXNzaW9uLiBTbyBJ IHdhcyBhc3N1bWluZyB0aGF0J3MgdGhlIG9ubHkgY29tbXVuaWNhdGlvbiBwYXR0ZXJuDQo+IHlv dSBjYW4gaGF2ZS4gT3IgaXMgdGhlIGlkZWEgdGhhdCBtdWx0aXBsZSBjbGllbnQtY29udmVydGVy IGV4Y2hhbmdlcw0KPiBjYW4gYmUgZG9uZSBvbiB0aGUgc2FtZSBUQ1AgY29ubmVjdGlvbiBhbHNv IGFmdGVyIHRoZSBUQ1AgaGFuZHNoYWtlDQo+IGFuZCB0aGVuIGFueSB0aW1lIGluIHRoZSBjb25u ZWN0aW9uIHlvdSB3b3VsZCBiZSBhYmxlIHRvIHN3aXRjaCBvdmVyDQo+IHRvIHNlbmRpbmcgb3Ro ZXIgcGF5bG9hZCBkYXRhPyBJIHRoaW5rIHRoaXMgbmVlZCBmdXJ0aGVyIGNsYXJpZmljYXRpb24N Cj4gaW4gdGhlIGRyYWZ0Lg0KPiANCj4gTm90ZSB0aGF0IHNlY3Rpb24gNyBhbHNvIHNheToNCj4g IkluIHRoaXMgc2VjdGlvbiwgd2Ugb25seSBkaXNjdXNzDQo+ICAgIHRoZSBtaWRkbGVib3hlcyB0 aGF0IG1vZGlmeSBTWU4gYW5kIFNZTitBQ0sgcGFja2V0cyBzaW5jZSB0aGUNCj4gQ29udmVydA0K PiAgICBQcm90b2NvbCBwbGFjZXMgaXRzIG1lc3NhZ2VzIGluIHN1Y2ggcGFja2V0cy7igJ0NCj4g DQo+IDkpIFRoaXMgcG9pbnQgaXMgcHJvYmFibHkgcmVsYXRlZCB0byB0aGUgcHJldmlvdXMgcG9p bnQuIEluIHNlY3Rpb24NCj4gNS4xIHlvdSBzYXkgdGhhdCB0aGUgY29ubmVjdGlvbiBNVVNUIGJl IHJlc2V0IChpZiBsZW5ndGggaXMgemVybykgYnV0DQo+IGluIGFsbCBvdGhlciBzZWN0aW9ucyB5 b3Ugc2F5IHRoZSBjb25uZWN0aW9uIG11c3QgYmUgY2xvc2VkIGlmIHRoZXJlDQo+IGlzIGEgcHJv YmxlbS4gQXNzdW1pbmcgdGhlIENvbnZlcnQgcHJvdG9jb2wgd2lsbCBvbmx5IGJlIHVzZWQgaW4g U1lODQo+IGFuZCBTWU4vQUNLLCByZXNldCBpcyBwcm9iYWJseSBtb3JlIGFwcHJvcHJpYXRlLiBJ ZiBpdCBjYW4gYmUgdXNlZA0KPiBhbHNvIGluIGxhdGVyIHBhY2tldHMgeW91IHByb2JhYmx5IGhh dmUgdG8gc2F5IHNvbWV0aGluZyBsaWtlIOKAnGNsb3NlDQo+IG9yIHJlc2V0IGlmIHRoZSBoYW5k c2hha2UgaXMgbm90IGNvbXBsZXRlZOKAneKApj8NCj4gDQo+IEUuZy4gc2VlIHNlYyA1LjIuMToN Cj4gIklmIHR3byBvciBtb3JlDQo+ICAgIGluc3RhbmNlcyBvZiB0aGUgc2FtZSBUTFYgYXJlIGV4 Y2hhbmdlZCBvdmVyIGEgQ29udmVydCBjb25uZWN0aW9uLA0KPiAgICB0aGUgYXNzb2NpYXRlZCBU Q1AgY29ubmVjdGlvbnMgTVVTVCBiZSBjbG9zZWQu4oCdDQo+IElzIHRoYXQgY2xvc2Ugb3IgcmVz ZXQ/DQo+IA0KPiBBbHNvIHJlbGF0ZWQ6DQo+IFRoZSBuZXh0IHNlY3Rpb24gKDUuMi4yKSBzYXlz Og0KPiAiVHlwZSAweDAgaXMgYSByZXNlcnZlZCB2YWx1ZWQuICBJbXBsZW1lbnRhdGlvbnMgTVVT VCBkaXNjYXJkIG1lc3NhZ2VzDQo+ICAgIHdpdGggc3VjaCBUTFYu4oCdDQo+IChOaXQgcy92YWx1 ZWQvdmFsdWUvKQ0KPiBBbmQgaW4gc2VjIDUuMi41Og0KPiAiQ29ubmVjdCBUTFZzIHdpdGNoIHN1 Y2ggbWVzc2FnZXMgTVVTVCBiZSBkaXNjYXJkZWQgYnkgdGhlIFRyYW5zcG9ydA0KPiAgICBDb252 ZXJ0ZXIuIg0KPiBJIGd1ZXNzIGV2ZXJ5IHRpbWUgeW91IHNheSBpbiB0aGUgZG9jdW1lbnQgdGhh dCBhIG1lc3NhZ2UgaXMgZGlzY2FyZGVkDQo+IHRoYXQgd291bGQgIGFsc28gbGVhZCBzb21laG93 IHRvIGNsb3NpbmcgdGhlIGNvbm5lY3Rpb24gbW9zdCBsaWtlbHkgYnkNCj4gdG8gc2VuZGluZyBh IHJlc2V0LCBubz8gT3Igc2hvdWxkIHRoZSBTWU4ganVzdCBiZSBkcm9wIGFuZCBubyByZXBseQ0K PiBzZW5kIGZvciBhbnkgcmVhc29uPyBQbGVhc2UgY2xhcmlmeS4NCj4gDQo+IDEwKSBQcm9iYWJs eSBlZGl0b3JpYWwgaW4gc2VjIDUuMi40Og0KPiAiQSBUcmFuc3BvcnQgQ29udmVydGVyIFNIT1VM RCBpbmNsdWRlIGluIHRoaXMNCj4gICAgbGlzdCB0aGUgVENQIG9wdGlvbnMgdGhhdCBpdCBhY2Nl cHRzIGZyb20gQ2xpZW50czsgdGhlc2Ugb3B0aW9ucw0KPiBhcmUNCj4gICAgaW5jbHVkZWQgYnkg dGhlIFRyYW5zcG9ydCBDb252ZXJ0ZXIgaW4gdGhlIFNZTiBwYWNrZXRzIHRoYXQgaXQNCj4gc2Vu ZHMNCj4gICAgdG8gaW5pdGlhdGUgY29ubmVjdGlvbnMu4oCdDQo+IEkgaGFkIHRvIHJlYWQgdGhl IHNlY29uZCBoYWxmIHR3aWNlIGJlY2F1c2UgaXQgc3VkZGVubHkgdGFsa3MgYWJvdXQgYQ0KPiBj b21wbGV0ZWx5IGRpZmZlcmVudCDigJxzY2VuYXJpb+KAnSB0aGFuIHJlcGx5aW5nIHRvIGFuIElu Zm8gVExWLiBNYXliZQ0KPiBzb21lIHJld29yZGluZyBjb3VsZCBoZWxwIGEgYml0IGxpa2UNCj4g IkEgVHJhbnNwb3J0IENvbnZlcnRlciBTSE9VTEQgaW5jbHVkZSBpbiB0aGlzDQo+ICAgIGxpc3Qg dGhlIFRDUCBvcHRpb25zIHRoYXQgaXQgYWNjZXB0cyBmcm9tIENsaWVudHM7IHRoZXNlIG9wdGlv bnMNCj4gYXJlDQo+ICAgIGFsc28gaW5jbHVkZWQgYnkgdGhlIFRyYW5zcG9ydCBDb252ZXJ0ZXIg aW4gdGhlIFNZTiBwYWNrZXRzIGlmIGl0DQo+ICAgIGluaXRpYXRlcyBjb25uZWN0aW9ucyB0byB0 aGUgY2xpZW50LuKAnQ0KPiBPciBtYXliZSBldmVuIHVzZSBub3JtYXRpdmUgbGFuZ3VhZ2UgaGVy ZToNCj4g4oCcdGhlIFRyYW5zcG9ydCBDb252ZXJ0IFNIT1VMRCBhbHNvIGluY2x1ZGUgdGhlIHNh bWUgb3B0aW9uIGluIHRoZSBTWU4NCj4gaWYNCj4gICAgaXQgaW5pdGlhdGVzIGEgY29ubmVjdGlv biB0byB0aGUgY2xpZW50LuKAnQ0KPiANCj4gMTEpIHNlYyA1LjIuNTogTWF5YmUgYWxzbyBiZSBz bGlnaHRseSBtb3JlIGNsZWFyIGhlcmU6DQo+ICJGb3IgaW5jb21pbmcgY29ubmVjdGlvbnMgZGVz dGluZWQgdG8gYSBDbGllbnQNCj4gICAgc2VydmljZWQgdmlhIGEgVHJhbnNwb3J0IENvbnZlcnRl ciwgdGhlc2UgZmllbGRzIGNvbnZleSB0aGUgc291cmNlDQo+ICAgIHBvcnQgbnVtYmVyIGFuZCBJ UCBhZGRyZXNzLuKAnQ0KPiBQcm9wb3NlZA0KPiAiRm9yIGluY29taW5nIGNvbm5lY3Rpb25zIGRl c3RpbmVkIHRvIGEgQ2xpZW50DQo+ICAgIHNlcnZpY2VkIHZpYSBhIFRyYW5zcG9ydCBDb252ZXJ0 ZXIsIHRoZXNlIGZpZWxkcyBjb252ZXkgdGhlIHNvdXJjZQ0KPiAgICBwb3J0IG51bWJlciBhbmQg SVAgYWRkcmVzcyBvZiB0aGUgU1lOIHBhY2tldCByZWNlaXZlZCBieSB0aGUNCj4gICAgVHJhbnNw b3J0IENvbnZlcnRlciBmcm9tIHRoZSBzZXJ2ZXIu4oCdDQo+IA0KPiAxMikgSSBoYXZlIGEgY291 cGxlIG9mIHF1ZXN0aW9uIGFib3V0IHRoZSBUQ1Agb3B0aW9ucyBmaWVsZCBpbiB0aGUNCj4gQ29u bmVjdCBUTFYsIGJhc2ljYWxseSB0aGlzIHRleHQgaW4gc2VjdGlvbiA1LjIuNToNCj4gIiAgIFVw b24gcmVjZXB0aW9uIG9mIGEgQ29ubmVjdCBUTFYsIGFuZCBhYnNlbnQgYW55IHBvbGljeSAoZS5n LiwNCj4gcmF0ZS0NCj4gICAgbGltaXQpIG9yIHJlc291cmNlIGV4aGF1c3Rpb24gY29uZGl0aW9u cywgYSBUcmFuc3BvcnQgQ29udmVydGVyDQo+ICAgIGF0dGVtcHRzIHRvIGVzdGFibGlzaCBhIGNv bm5lY3Rpb24gdG8gdGhlIGFkZHJlc3MgYW5kIHBvcnQgdGhhdCBpdA0KPiAgICBjb250YWlucy4g IFRoZSBUcmFuc3BvcnQgQ29udmVydGVyIE1VU1QgdXNlIGJ5IGRlZmF1bHQgdGhlIFRDUA0KPiAg ICBvcHRpb25zIHRoYXQgY29ycmVzcG9uZCB0byBpdHMgbG9jYWwgcG9saWN5IHRvIGVzdGFibGlz aCB0aGlzDQo+ICAgIGNvbm5lY3Rpb24uICBUaGVzZSBhcmUgdGhlIG9wdGlvbnMgdGhhdCBpdCBh ZHZlcnRpc2VzIGluIHRoZQ0KPiAgICBTdXBwb3J0ZWQgVENQIEV4dGVuc2lvbnMgVExWLg0KPiAN Cj4gDQo+IEJvbmF2ZW50dXJlLCBldCBhbC4gICAgICAgIEV4cGlyZXMgTWF5IDcsIDIwMjAgICAg ICAgICAgICAgICAgIFtQYWdlDQo+IDIyXQ0KPiBJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg Q29udmVydCBQcm90b2NvbCAgICAgICAgICAgICAgIE5vdmVtYmVyDQo+IDIwMTkNCj4gDQo+IA0K PiAgICBVcG9uIHJlY2VwdGlvbiBvZiBhbiBleHRlbmRlZCBDb25uZWN0IFRMViwgYW5kIGFic2Vu dCBhbnkgcmF0ZQ0KPiBsaW1pdA0KPiAgICBwb2xpY3kgb3IgcmVzb3VyY2UgZXhoYXVzdGlvbiBj b25kaXRpb25zLCBhIFRyYW5zcG9ydCBDb252ZXJ0ZXINCj4gTVVTVA0KPiAgICBhdHRlbXB0IHRv IGVzdGFibGlzaCBhIGNvbm5lY3Rpb24gdG8gdGhlIGFkZHJlc3MgYW5kIHBvcnQgdGhhdCBpdA0K PiAgICBjb250YWlucy4gIEl0IE1VU1QgaW5jbHVkZSB0aGUgb3B0aW9ucyBvZiB0aGUgJ1RDUCBP cHRpb25zJyBzdWItDQo+IGZpZWxkDQo+ICAgIGluIHRoZSBTWU4gc2VudCB0byB0aGUgU2VydmVy IGluIGFkZGl0aW9uIHRvIHRoZSBUQ1Agb3B0aW9ucyB0aGF0DQo+IGl0DQo+ICAgIHdvdWxkIGhh dmUgdXNlZCBhY2NvcmRpbmcgdG8gaXRzIGxvY2FsIHBvbGljaWVzLiAgRm9yIHRoZSBUQ1ANCj4g b3B0aW9ucw0KPiAgICB0aGF0IGFyZSBsaXN0ZWQgd2l0aG91dCBhbiBvcHRpb25hbCB2YWx1ZSwg dGhlIFRyYW5zcG9ydCBDb252ZXJ0ZXINCj4gICAgTVVTVCBnZW5lcmF0ZSBpdHMgb3duIHZhbHVl LiAgRm9yIHRoZSBUQ1Agb3B0aW9ucyB0aGF0IGFyZSBpbmNsdWRlZA0KPiAgICBpbiB0aGUgJ1RD UCBPcHRpb25zJyBmaWVsZCB3aXRoIGFuIG9wdGlvbmFsIHZhbHVlLCBpdCBNVVNUIGNvcHkgdGhl DQo+ICAgIGVudGlyZSBvcHRpb24gZm9yIHVzZSBpbiB0aGUgY29ubmVjdGlvbiB3aXRoIHRoZSBk ZXN0aW5hdGlvbiBwZWVyLg0KPiAgICBUaGlzIGZlYXR1cmUgaXMgcmVxdWlyZWQgdG8gc3VwcG9y dCBUQ1AgRmFzdCBPcGVuLuKAnQ0KPiANCj4gRmlyc3Qgb2YgYWxsIHRoZSB1cHBlciBwYXJhZ3Jh cGggaXMgcHJvYmFibHkgb2xkIGFuZCBzaG91bGQgaGF2ZSBiZWVuDQo+IHJlbW92ZWQsIHJpZ2h0 Pw0KPiANCj4gVGhlbiBJ4oCZbSBub3QgY2VydGFpbiBhYm91dCB0aGUgbmV3IGFwcHJvYWNoIHdp dGggdGhlIFRDUCBvcHRpb24gZmllbGQuDQo+IElmIHRoZSBjb252ZXJ0ZXIgYWN0dWFsbHkgZW5k cyB1cCBpbiBhIHNwbGl0IGNvbm5lY3Rpb24gKHdpdGggZS5nLg0KPiBNUFRDUCBvbiBjbGllbnQg c2lkZSBidXQgd2l0aG91dCBpdCBvbiBzZXJ2ZXIgc2lkZSksIEkgdGhvdWdodCBpdCBjYW4NCj4g b25seSBhbm5vdW5jZSB0aG9zZSBvcHRpb25zIGluIHRoZSBTWU4gdG8gdGhlIHNlcnZlciB0aGF0 IGFyZSBhY3R1YWxseQ0KPiBpbXBsZW1lbnRlZCBpbiB0aGUgY29udmVydGVyIGFuZCBpdCB3aWxs IGJlIGFibGUgdG8gc3VwcG9ydCBsYXRlciBpbg0KPiB0aGUgY29ubmVjdGlvbi4gU28gYmxpbmRs eSBjb3B5aW5nIHRoZSBvcHRpb25zIHByb3ZpZGVkIGJ5IHRoZSBjbGllbnQNCj4gZG9lc27igJl0 IHNlZW0gcmlnaHQuIE9yIHdoYXQgZG8gSSBtaXNzPw0KPiANCj4gSSB1bmRlcnN0YW5kIHRoZSBj YXNlIHdoZXJlIHlvdSB3YW50IHRvIHVzZSBURk8gYmV0d2VlbiB0aGUgY2xpZW50IGFuZA0KPiB0 aGUgY29udmVydCBidXQgY2Fu4oCZdCB1c2UgaXQgYW55bW9yZSBiZXR3ZWVuIHRoZSB0aGUgY2xp ZW50IGFuZCB0aGUNCj4gc2VydmVyIHRoZW4uIEhvd2V2ZXIgeW91IGNhbiBvbmx5IHVzZSBURk8g d2l0aCB0aGUgc2Vjb25kIGNvbm5lY3Rpb24NCj4geW91IG1ha2UgdG8gYSBzZXJ2ZXIuIFNvIGlu IHRoZSBmaXJzdCBjb25uZWN0aW9uIGVpdGhlciBURk8gd2FzIHVzZWQNCj4gYmV0d2VlbiB0aGUg Y29udmVydCBhbmQgdGhlIHNlcnZlciBhbmQgdGhlIGNvbnZlcnQgY291bGQgbm93IHVzZSBpdA0K PiBhZ2FpbiB3aXRoIHRoZSBjb29raWUgaXQgcmVjZWl2ZWQgb3IgVEZPIHdhcyB1c2VkIGVuZC10 by1lbmQgaW4gdGhlDQo+IGZpcnN0IGNvbm5lY3Rpb24gYW5kIGl0IG5vdyBjbGVhciB0byBtZSB3 aHkgdGhlIGNvbnZlcnRlciBpcyB1c2VkIG5vdy4NCj4gTWF5YmUgSeKAmW0gbWlzc2luZyBzb21l dGhpbmcgYnV0IEkgdGhpbmsgdGhlIGRyYWZ0cyB3b3VsZCBhdCBsZWFzdCBuZWVkDQo+IG1vcmUg ZXhwbGFuYXRpb24gYWJvdXQgdGhlIG1vdGl2YXRpb24gdG8gaGF2ZSB0aGlzLg0KPiANCj4gSWYg aXTigJlzIHJlYWxseSBvbmx5IGFib3V0IFRGTyBjb29raWVzIGFuZCB3ZSBhcmUgc3VyZSB3ZSB3 YW50IHRvIGhhdmUNCj4gdGhhdCBmZWF0dXJlLCBtYXliZSBhbiBvd24gVExWIHdvdWxkIGJlIHNp bXBsZXI/DQo+IA0KPiAxMykgSW4gc2VjIDUuMi42IGRvIHlvdSBtZWFuIGJ5ICJleHRlbmRlZCBU Q1AgaGVhZGVy4oCdIHRoZSBUQ1Agb3B0aW9uDQo+IHNwYWNlPyBJ4oCZbSBub3Qgc3VyZSB0aGF0 ICJleHRlbmRlZCBUQ1AgaGVhZGVy4oCdIGlzIGEgY2xlYXJseSBkZWZpbmVkDQo+IHRlcm07IGFz IGxlYXN0IEnigJltIG5vdCAxMDAlIHN1cmUgd2hhdCB5b3UgbWVhbuKApg0KPiANCj4gMTQpIG5p dCBpbiBzZWMgNS4yLjc6DQo+IHMvVGhlIENvb2tpZSBUTFYgKEZpZ3VyZSAyMCBpcyBhbiBvcHRp b25hbC9UaGUgQ29va2llIFRMViAoRmlndXJlIDIwKQ0KPiBpcyBhbiBvcHRpb25hbC8gLT4gbWlz c2luZyBjbG9zaW5nIGJyYWNrZXQNCj4gDQo+IDE1KSBTZWMgNS4yLjc6DQo+IFF1ZXN0aW9uIGFi b3V0IG5vcm1hdGl2ZSBsYW5ndWFnZToNCj4gIklmIHRoZSByZWNlaXZlZCBTWU4gZGlkIG5vdCBj b250YWluIGEgQ29va2llIFRMViwgYW5kIGNvb2tpZQ0KPiAgICB2YWxpZGF0aW9uIGlzIHJlcXVp cmVkLCB0aGUgVHJhbnNwb3J0IENvbnZlcnRlciBzaG91bGQgY29tcHV0ZSBhDQo+ICAgIENvb2tp ZSBib3VuZCB0byB0aGlzIENsaWVudCBhZGRyZXNzIGFuZCByZXR1cm4gYSBDb252ZXJ0IG1lc3Nh Z2UNCj4gICAgY29udGFpbmluZyB0aGUgZml4ZWQgaGVhZGVyLCBhbiBFcnJvciBUTFYgc2V0IHRv ICJNaXNzaW5nIENvb2tpZSINCj4gYW5kDQo+ICAgIHRoZSBjb21wdXRlZCBDb29raWUgYW5kIGNs b3NlIHRoZSBjb25uZWN0aW9uLuKAnQ0KPiBJcyB0aGlzIG1heWJlIGEgTUFZIGNvbmRpdGlvbj8g QWxsIG9mIGl0PyBPciBzb21ldGhpbmcgbGlrZSB0aGlzDQo+ICJJZiB0aGUgcmVjZWl2ZWQgU1lO IGRpZCBub3QgY29udGFpbiBhIENvb2tpZSBUTFYsIGFuZCBjb29raWUNCj4gICAgdmFsaWRhdGlv biBpcyByZXF1aXJlZCwgdGhlIFRyYW5zcG9ydCBDb252ZXJ0ZXIgTUFZIGNvbXB1dGUgYQ0KPiAg ICBDb29raWUgYm91bmQgdG8gdGhpcyBDbGllbnQgYWRkcmVzcy4gSXQgTVVTVCByZXR1cm4gYSBD b252ZXJ0DQo+IG1lc3NhZ2UNCj4gICAgY29udGFpbmluZyB0aGUgZml4ZWQgaGVhZGVyIGFuZCBF cnJvciBUTFYgc2V0IHRvICJNaXNzaW5nIENvb2tpZeKAnQ0KPiBhbmQgTUFZIGFkZA0KPiAgICB0 aGUgY29tcHV0ZWQgQ29va2llLiBBZnRlciBzZW5kaW5nIHRoZSBFcnJvciBUTFYgaXMgTVVTVC9T SE9VTEQNCj4gY2xvc2UvcmVzZXQNCj4gICAgdGhlIGNvbm5lY3Rpb24u4oCdDQo+IE5vdCBmdWxs eSBzdXJlIHdoYXQgaXMgdGhlIGludGVudGlvbiBoZXJl4oCmDQo+IA0KPiAxNSkgc2VjIDUuMi44 Og0KPiBXaGF0J3MgdGhlIHB1cnBvc2Ugb2YgdGhlIGNsaWVudCBzZW5kaW5nIGFuIFVuc3VwcG9y dGVkIFZlcnNpb24gZXJyb3I/DQo+IElmIHRoZSBjb252ZXJ0ZXIgcmVwbGllcyB3aXRoIGEgZGlm ZmVyZW50IHZlcnNpb24gdGhhbiByZXF1ZXN0ZWQgdXNlZA0KPiBieSB0aGUgY2xpZW50LCB0aGF0 J3Mgc2ltcGx5IGEgZmF0YWwgZXJyb3IvaW1wbGVtZW50YXRpb24gZXJyb3IgYW5kDQo+IHRoZSBj bGllbnQgY2FuIG9ubHkgcmVzZXQgdGhlIGNvbm5lY3Rpb24gSSB0aGluay4NCj4gDQo+IE1vcmUg Z2VuZXJhbGx5IGlmIEkgcmVhZCB0aGlzIGNvcnJlY3RseSB0aGVyZSBhcmUgb25seSAzIGVycm9y cyB0aGF0DQo+IGNvdWxkIGJlIHNlbnQgYnkgdGhlIGNsaWVudC4gSSBndWVzcyB0aG9zZSBlcnJv cnMgd291bGQgYmUgc2VuZCBpbiB0aGUNCj4gZmlyc3QgcGFja2V0IGFmdGVyIHRoZSBTWU4vQUNL IGlzIHJlY2VpdmVk4oCmPyBSZWxhdGVkIHRvIG15IHF1ZXN0aW9uDQo+IGFib3ZlLCBJIHRoaW5r IGl0IHdvdWxkIGJlIG11Y2ggZWFzaWVyIHRvIG9ubHkgaGF2ZSBDb252ZXJ0IG1lc3NhZ2UgaW4N Cj4gdGhlIFNZTiBhbmQgU1lOL0FDSyBhbmQgbm8gZXhwbGljaXQgZXJyb3IgbWVzc2FnZSBmcm9t IHRoZSBjbGllbnQuDQo+IE90aGVyd2lzZSBtb3JlIGV4cGxhbmF0aW9uIGluIHRoZSBkcmFmdCB3 b3VsZCBiZSBuZWVkIGhvdyB0aGlzDQo+IGFjdHVhbGx5IGlzIHN1cHBvc2VkIHRvIHdvcmsuDQo+ IA0KPiAxNikgc2VjIDUuMi44Og0KPiAiQSBDbGllbnQgd2hpY2ggcmVjZWl2ZXMgdGhpcyBlcnJv ciBjb2RlIE1VU1QgY2FjaGUgdGhlIHJlY2VpdmVkDQo+ICAgICAgIENvb2tpZSBhbmQgaW5jbHVk ZSBpdCBpbiBzdWJzZXF1ZW50IENvbnZlcnQgbWVzc2FnZXMgc2VudCB0bw0KPiB0aGF0DQo+ICAg ICAgIFRyYW5zcG9ydCBDb252ZXJ0ZXIu4oCdDQo+IFRoaXMgc2VlbXMgdG8gYmUgYSBzbGlnaHRs eSB3ZWlyZCBub3JtYXRpdmUgTVVTVC4gU3VyZSB5b3UgaGF2ZSB0bw0KPiBjYWNoZSB0aGUgY29v a2llIGluIG9kZXIgdG8gYmUgYWJsZSB0byB1c2UgdGhlIGNvbnZlcnRlciwgaG93ZXZlciwNCj4g dGhlcmUgbWF5IGJlIGNhc2VzIHdoZXJlIHlvdSBsb29zZSB0aGUgY2FjaGUgYW5kIHRoZW4gc2Vu ZGluZyBhDQo+IENvbm5lY3Qgd2l0aG91dCB0aGUgY29va2llIHRvIGdldCBhIG5ldyBDb29raWUg aXMgYSB2YWxpZCBvcHRpb24uIFNvDQo+IHlvdSBtYXkgdXNlIFNIT1VMRCBoZXJlIG9yIGV2ZW4g YmV0dGVyIHJld29yZCBpdCBjb21wbGV0ZWx5Li4uDQo+IA0KPiAxNykgVGhlcmUgaXMgYW4gVW5z dXBwb3J0ZWQgVENQIE9wdGlvbiBpbiBzZWN0aW9uIDUuMi44LiBIb3dldmVyLCB0aGlzDQo+IGVy cm9yIGlzIG5vdCBtZW50aW9uZWQgaW4gNS4yLjUuIEluIGNvbnRyYXN0IHNlYyA1LjIuNSBzYXlz IHRoYXQgdGhlDQo+IGNvbnZlcnRlciBNVVNUIG9wZW4gYSBjb25uZWN0aW9uIGFuZCBNVVNUIHVz ZSB0aGVzZSBvcHRpb25zLiBUaGlzIGlzDQo+IHJlbGF0ZWQgdG8gbXkgcG9pbnQgMTIgYWJvdmUg YnV0IGl0IHdhcyBub3QgY2xlYXIgdG8gbWUgdGhhdCBvcHRpb25zDQo+IGNhbiBiZSByZWplY3Rl ZCwgaG93ZXZlciwgdGhpcyB3aG9sZSBwYXJ0IHNlZW1zIHRvIG1ha2UgdGhlIHByb3RvY29sDQo+ IHJlYWxseSBjb21wbGljYXRlZCBhbmQgYXMgSSBzYWlkIGlmIHRoZSBvbmx5IHVzZSBjYXNlIGlz IFRGTyBJIHdvdWxkDQo+IHByZWZlciB0byByYXRoZXIgaGF2ZSBhIHNlcGFyYXRlIHNwZWNpZmlj IFRMViBmb3IgdGhhdCBjYXNlIG9ubHkuDQo+IA0KPiAxOCkgSSB0aGluayBzZWN0aW9uIDYuNyBz aG91bGQgc3RpbGwgc2F5IHNvbWV0aGluZyBhYm91dCBpZiB0aGlzDQo+IG9wdGlvbiBpcyBzdXBw b3J0ZWQgb3Igbm904oCmDQo+IA0KPiAxOSkgc2VjdGlvbiA3Og0KPiAiQ29uc2lkZXIgYSBtaWRk bGVib3ggdGhhdCByZW1vdmVzIHRoZSBTWU4gcGF5bG9hZC4gIFRoZSBDbGllbnQgY2FuDQo+ICAg IGRldGVjdCB0aGlzIHByb2JsZW0gYnkgbG9va2luZyBhdCB0aGUgYWNrbm93bGVkZ21lbnQgbnVt YmVyIGZpZWxkDQo+IG9mDQo+ICAgIHRoZSBTWU4rQUNLIHJldHVybmVkIGJ5IHRoZSBUcmFuc3Bv cnQgQ29udmVydGVyLiAgVGhlIENsaWVudCBNVVNUDQo+ICAgIHN0b3AgdG8gdXNlIHRoaXMgVHJh bnNwb3J0IENvbnZlcnRlciBnaXZlbiB0aGUgbWlkZGxlYm94DQo+ICAgIGludGVyZmVyZW5jZS7i gJ0NCj4gSWYgdGhlIGNvbnZlcnRlciByZWNlaXZlZCBhIFNZTiB3aXRob3V0IGEgQ29udmVydCBt ZXNzYWdlIGluIHRoZQ0KPiBwYXlsb2FkIG9uIHRoZSByZXNwZWN0aXZlIHBvcnQsIGl0IGlzIHN1 cHBvc2VkIHRvIGFueXdheSBzZW5kIGENCj4gU1lOL0FDSz8gSSB3b3VsZCBhc3N1bWUgaXQgd291 bGQgcmF0aGVyIHNlbmQgYSBSRVNFVCwgbm8/IEkgdGhpbmsgdGhhdA0KPiBuZWVkcyB0byBiZSBm dXJ0aGVyIHNwZWNpZmllZC4NCj4gDQo+IDIwKSBTZWMgNyBhbHNvIHNheXM6DQo+IOKAnElmIGFu IEVycm9yIHdhcyByZXR1cm5lZCBieSB0aGUgVHJhbnNwb3J0IENvbnZlcnRlciwgYSBtZXNzYWdl IHRvDQo+IGNsb3NlDQo+ICAgIHRoZSBjb25uZWN0aW9uIHdvdWxkIG5vcm1hbGx5IGZvbGxvdyBm cm9tIHRoZSBDb252ZXJ0ZXIu4oCdDQo+IEhvd2V2ZXIgc2VjIDUuMi44IHNheXM6DQo+ICJVcG9u IHJlY2VwdGlvbiBvZiBhbiBFcnJvciBUTFYsIGENCj4gICAgQ2xpZW50IE1VU1QgY2xvc2UgdGhl IGFzc29jaWF0ZWQgY29ubmVjdGlvbi7igJ0NCj4gSSBhc3N1bWUgb25lIG9mIHRoZXNlIGlzIG5v dCBjb3JyZWN04oCmIHBsZWFzZSBjbGFyaWZ5IHdoaWNoIGVuZCBpcw0KPiBzdXBwb3NlIHRvIGRv IHdoYXQgaW4gY2FzZSBvZiBhbiBlcnJvci4NCj4gDQo+IDIxKSBUaGUgdGV4dCBpbiBzZWMgNyB0 aGVuIGZ1cnRoZXIgc2F5czoNCj4gIklmIG5vIHN1Y2gNCj4gICAgbWVzc2FnZSBpcyByZWNlaXZl ZCwgdGhlIENsaWVudCBtYXkgY29udGludWUgdG8gdXNlIHRoaXMNCj4gQ29udmVydGVyLuKAnQ0K PiBJc27igJl0IHRoYXQgYSBiaXQgZGFuZ2Vyb3VzPw0KPiANCj4gMjIpIHNlY3Rpb24gOC41OiBX aHkgYXJlIHRoZSBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gZGlzY3Vzc2VkIGluDQo+IHRoaXMg c2VjdGlvbiBNUFRDUCBzcGVjaWZpYz8gSSB0aGluayB0aGUgc2FtZSBtZWNoYW5pc21zIGNvdWxk IGFsc28gYmUNCj4gYXBwbGllZCB0byBDb252ZXJ0ZXJzIHN1cHBvcnRpbmcgb3RoZXIgb3B0aW9u cywgbm8/DQo+IA0KPiAyMykgc2VjIDguMzoNCj4gIk1lYW5zIHRvIHByb3RlY3QgYWdhaW5zdCBT WU4gZmxvb2RpbmcgYXR0YWNrcyBNVVNUIGFsc28gYmUgZW5hYmxlZA0KPiBbUkZDNDk4N10u4oCd DQo+IE5vdCBzdXJlIGlmIHRoZSB1c2Ugb2YgTVVTVCBpcyBjbGVhciBoZXJlLiBXaGljaCBwYXJ0 IG9mIFJGQzQ5ODcgZG9lcw0KPiB0aGlzIE1VU1QgcmVsYXRlIHRvPyBBbGwgb2YgaXQ/IE1heWJl IGEgU0hPVUxEIG9yIG5vIG5vcm1hdGl2ZQ0KPiBsYW5ndWFnZSBpcyBtb3JlIGFwcHJvcHJpYXRl Pw0KPiANCj4gMjQpIHNlYyA5LjI6IE1heWJlIGNhbGwgdGhlIG5ldyByZWdpc3RyeSB0aGUgIlRo ZSBUQ1AgQ29udmVydCBQcm90b2NvbA0KPiAoQ29udmVydCkNCj4gICAgUGFyYW1ldGVyc+KAnSAo VENQIGFkZGVkKeKApj8NCj4gDQo+IDI1KSBzZWMgOS4yLjI6DQo+ICJUaGUgdmFsdWVzIGluIHRo ZSByYW5nZSAxOTItMjU1IGNhbiBiZSBhc3NpZ25lZCBmb3IgUHJpdmF0ZSBVc2Uu4oCdDQo+IElB TkEgZG9lcyBub3QgYXNzaWduZWQgYW55IHZhbHVlIGZvciBQcml2YXRlIHVzZSwgdGhleSBjYW4g anVzdCBiZQ0KPiB1c2VkLCBzbyB0aGlzIHNob3VsZCBiZQ0KPiAiVGhlIHZhbHVlcyBpbiB0aGUg cmFuZ2UgMTkyLTI1NSBhcmUgcmVzZXJ2ZWQgZm9yIFByaXZhdGUgVXNlLuKAnQ0KPiBpZiB0aGF0 IGlzIHdoYXQgeW91IHdhbnQ/DQo+IA0KPiAyNikgYWxzbyBvbiBzZWN0aW9uIDkuMi5YOiAiU3Bl Y2lmaWNhdGlvbiBSZXF1aXJlZCIgaW5jbHVkZXMgaGF2aW5nIGFuDQo+IGV4cGVydCByZXZpZXcg YW5kIFJGQzgxMjYgc2F5czoNCj4gIkFzIHdpdGggRXhwZXJ0IFJldmlldyAoU2VjdGlvbiA0LjUp LCBjbGVhciBndWlkYW5jZSB0byB0aGUgZGVzaWduYXRlZA0KPiAgICBleHBlcnQgc2hvdWxkIGJl IHByb3ZpZGVkIHdoZW4gZGVmaW5pbmcgdGhlIHJlZ2lzdHJ5LCBhbmQgdGhvcm91Z2gNCj4gICAg dW5kZXJzdGFuZGluZyBvZiBTZWN0aW9uIDUgaXMgaW1wb3J0YW50LuKAnQ0KPiBTbyBwbGVhc2Ug cHJvdmlkZSBmdXJ0aGVyIGd1aWRhbmNlIGFib3V0IHdoYXQgdGhlIGV4cGVydCBpcyBzdXBwb3J0 ZWQNCj4gdG8gZXZhbHVhdGUuDQo+IA0KPiAyNykgTm90IHN1cmUgaWYgdGhlIGZvbGxvd2luZyBy ZWZlcmVuY2VzIG5lZWQgdG8gYmUgbm9ybWF0aXZlIGFzIHRoZXJlDQo+IG5vIG5vcm1hdGl2ZSBy ZXF1aXJlbWVudCBjb25uZWN0IHRvIHRoZW0gYnV0IG9ubHkgYW4gb3B0aW9uYWwgY2FzZSBpcw0K PiBkaXNjdXNzZWQ6IFJGQzQyNzksIFJGQzcyNTAg4oCmPw0KPiANCj4gSG93ZXZlciwgUkZDNzMy MywgUkZDMjAxOCwgUkZDNjk3OCwgUkZDNjk3OCwgUkZDMjgyNywgUkZDNjE4MSBzaG91bGQNCj4g cHJvYmFibHkgYmUgbm9ybWF0aXZlIHJlZmVyZW5jZXPigKY/DQo+IA0KPiAyOCkgVGhlIHRlcm0g 4oCcZXhwZXJpbWVudGFsIG9wdGlvbuKAnSBpcyB1c2VkIHdpdGggdHdvIGRpZmZlcmVudCBtZWFu aW5nDQo+IGluIHRoZSBpbnRybyBvZiBzZWN0aW9uIDYgKG9wdGlvbnMgdGhhdCBhcmUgZGVmaW5l ZCBpbiBhbiBleHAgUkZDKSBhbmQNCj4gaW4gc2VjdGlvbiA2LjkgKG9wdGlvbnMgd2l0aCBraW5k IDI1NCBhbmQgMjU1KS4gUGxlYXNlIGNsYXJpZnkgdGhpcyBhdA0KPiBib3RoIHBsYWNlcy4NCj4g DQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCg0K From nobody Fri Jan 24 05:49:43 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60741200D7; Fri, 24 Jan 2020 05:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 tDQJkE9YSFQx; Fri, 24 Jan 2020 05:49:38 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 F3DA312006B; Fri, 24 Jan 2020 05:49:37 -0800 (PST) Received: from 200116b824ebc200bd8262b58bd1130c.dip.versatel-1u1.de ([2001:16b8:24eb:c200:bd82:62b5:8bd1:130c]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1iuzL3-00013X-NN; Fri, 24 Jan 2020 14:49:33 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <787AE7BB302AE849A7480A190F8B933031410A7D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Fri, 24 Jan 2020 14:49:33 +0100 Cc: "draft-ietf-tcpm-converters.all@ietf.org" , tcpm IETF list Content-Transfer-Encoding: quoted-printable Message-Id: <2A965C09-D40D-49CA-B5D6-F4E7063EF0C7@kuehlewind.net> References: <4DF47B41-2A8F-4FC1-8734-4D133F3EBBE5@kuehlewind.net> <787AE7BB302AE849A7480A190F8B933031410A7D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1579873778;68a7e9ce; X-HE-SMSGID: 1iuzL3-00013X-NN Archived-At: Subject: Re: [tcpm] AD review of draft-ietf-tcpm-converters-14 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 13:49:42 -0000 Hi Med, Regarding the port, I think that#s a good approach. As the whole working = group is cc=E2=80=99ing, let=E2=80=99s wait a week or so to see if there = are only objection as you propose. Mirja > On 24. Jan 2020, at 13:42, = wrote: >=20 > Hi Mirja,=20 >=20 > We are currently preparing changes to take into account your review. = Our plan is to have a revised version by the next week but I would like = to report on this comment:=20 >=20 >> 6) Can you maybe add some more text (in section 5 maybe) why a >> separate port number is used/needed? As the client has to be >> explicitly configured it could easily be configured with an address >> and port number. Is this to avoid collisions with other protocols? >> What would be the scenario here? >=20 > After carefully re-reading = https://tools.ietf.org/html/rfc7605#section-7.1 and taking into account = the deployment models, an IP address will be needed to be = supplied/discovered anyway... so the port number can be = supplied/discovered as well.=20 >=20 > Unless there is an objection, we will update the draft to only = register a service name without asking for any specific port. The name = will be typically used to build service labels that can be then used to = retrieve a service port number using, e.g., DNS SRV.=20 >=20 > Thank you. >=20 > Cheers, > Olivier & Med >=20 >> -----Message d'origine----- >> De : Mirja Kuehlewind [mailto:ietf@kuehlewind.net] >> Envoy=C3=A9 : jeudi 9 janvier 2020 22:28 >> =C3=80 : draft-ietf-tcpm-converters.all@ietf.org >> Cc : tcpm IETF list >> Objet : AD review of draft-ietf-tcpm-converters-14 >>=20 >> Hi authors, >>=20 >> I finally did my AD review for draft-ietf-tcpm-converters-14 = (actually >> I'm still not fully finished with the review of the appendix but = would >> like to send out this first batch of questions now). >>=20 >> As you can see below, I have a whole bunch of questions/comments. = Some >> of these may only be editorial in the end but I would like to make >> sure that I understand all the technical parts correctly before we >> move on with the processing. >>=20 >> I think there are basically two main technical points I would like to >> get some clarification on, both probably related to things that have >> been introduced later in the life time of the doc but maybe not >> consequently been changed throughout the whole doc. >>=20 >> One is besiaclly point 8 below but there are some related other = points >> below: It is not fully clear which packets can carry Convert = messages. >> I think initially Convert messages were only supposed to be in the = SYN >> and SYN/ACK. But then later you enabled it also for other packets, >> however, it seem the only real case that needs this is when an error >> message is send by the client. But sending Convert messages in other >> packet than the SYN and the SYN/ACK seems more complicated because = all >> TCP payload data is transmitted reliable and must be ack'ed and evil. >> retransmitted. Maybe it=E2=80=99s okay if only an error message is = send and a >> reset right after (so no retransmission), however, this is not >> specified, and I wonder if the complexity is really needed worth the >> benefit of being able to log more concrete errors in the converter. >>=20 >> The other point is basically point 12 below about the TCP option = field >> in the Connect TLV (also related to point 17 below). This is not well >> enough specified and seem also quite complex as a generic mechanism. = I >> would think the converter should usually try to use the same option = as >> the client did send in his SYN to the converter, if supported by the >> converter TCP implementation. The TFO cookie might be a special case. >> I=E2=80=99m not sure if that needs to be generalised or if having a = separate >> TLV for that one case might be simpler. Please also reconsider this >> but in any case it needs more explanation in the spec. >>=20 >> Please see all my questions/comments below. I may send another >> message, when I have reviewed the appendix tomorrow (hopefully with >> none or only few additional comments). >>=20 >> Thanks! >> Mirja >>=20 >> ---------------------- >>=20 >> 1) I was initially a bit confused about the setup in Figure 6 and >> respectively the paragraph just before that figure in sec 3.2: It >> wasn't clear to me how the server might know the converter address = (or >> if the proxy maybe has to be on path). I assume the =E2=80=9Cuse = case=E2=80=9D is that >> there was a previous connection using the converter and now the = server >> tries to reconnect but of course only knows the converter address, or >> something? Maybe you could add slightly more text here. I also I = would >> recommend to explicitly mention that this setup still has to be >> explicitly configured by the client but using an out of band protocol >> (which is out or scope for this spec). Further I think it would be >> good to mention here already that the converter also inserts the >> respective TCP option in the SYN to the client (if possible due to >> space limits) and refer to section 4.2 for a concrete example. >>=20 >> Btw. shouldn't there be some discussion about MTU issue if options = are >> added by the converter? >>=20 >> 2) The following paragraph in section 3.2. seems to specify protocol >> requirements but don=E2=80=99t use normative language: >>=20 >> "If the downstream (or upstream) connection fails for some reason >> (excessive retransmissions, reception of an RST segment, etc.), >> then >> the Converter should force the tear-down of the upstream (or >> downstream) connection. >>=20 >> The same reasoning applies when the upstream connection ends. In >> this case, the Converter should also terminate the downstream >> connection by using FIN segments. If the downstream connection >> terminates with the exchange of FIN segments, the Converter should >> initiate a graceful termination of the upstream connection.=E2=80=9D >>=20 >> I recommend to use normativen language here (SHOULD instead of = should; >> or maybe even MUST?). However, as this text is part of a kind of >> overview section, it doesn=E2=80=99t seem to be a really good fit to = use >> normative language in that section. So maybe the whole discussion >> about use of TFO (or not) should be moved to an own section? >>=20 >>=20 >> 3) Just to double-check, I'm wondering a bit about this phrasing in >> sec 3.3.1: >> "If no entry is found, the Transport Converter MUST silently >> ignore the packet.=E2=80=9D >> That means the converter will drop the packet (with no other action), >> right? Why do you use term ignore here (instead of drop or discard)? >> Or does this have any other implication? >> Note that this term is used several times in the doc. >>=20 >> 4) Also a quick question about this in sec 3.3.1: >> "A Transport Converter may operate in address preservation mode (that >> is, the Converter does not rewrite the source IP address (i.e., >> C=3D=3DT)) or address sharing mode (that is, an address pool is = shared >> among all Clients serviced by the Converter (i.e., C!=3DT)); refer = to >> Appendix D for more details. Which behavior to use by a Transport >> Converter is deployment-specific.=E2=80=9D >> I guess preservation mode can only be used if the converter is on >> path. I think that should be explicitly noted here. >>=20 >> 5) Sec 3.3.2: To be honest I=E2=80=99m not sure I fully understand = this >> section, especially this sentence: >> "Upon receipt of a secondary subflow by the Transport Converter from = a >> Client, the Converter follows the same behavior specified in >> Section 3.3.1 for processing Non-SYNs.=E2=80=9D >> Do you mean by "receipt of a secondary subflow=E2=80=9D the SYN on = that >> subflow or other data? For the SYN I would expect that there is no >> payload data and therefore nothing to proxy. For other subflow >> packets, I guess you need to reorder first, so probably it would be >> good to mention that=E2=80=A6? Maybe it=E2=80=99s just me = misunderstanding something >> but I believe more explanation is needed here. >>=20 >> 6) Can you maybe add some more text (in section 5 maybe) why a >> separate port number is used/needed? As the client has to be >> explicitly configured it could easily be configured with an address >> and port number. Is this to avoid collisions with other protocols? >> What would be the scenario here? >>=20 >> 7) Sec 5.1: >> "The Unassigned field MUST be set to zero in this version of the >> protocol. These bits are available for future use [RFC8126].=E2=80=9D= >> Why is there a reference to RFC8126 here? >>=20 >> 8) Also sec 5.1 but probably editorial: >> "Data added by the Convert Protocol to the TCP bytestream is >> unambiguously distinguished from payload data by the Total Length >> field in the Convert messages.=E2=80=9D >> I believe what you want to say here is that the total length is used >> to figure out where potential other payload data might start. = However, >> what I would understand from this sentence is that the total length >> field can be used to distinguish SYNs that carry the Convert protocol >> from SYNs that may carry other payload only, which I don=E2=80=99t = think is >> the case. >>=20 >> 8) I first have a more general question about the function of the >> protocol. Sec 5 says: >> "Convert messages may appear only in a SYN, SYN+ACK, or ACK.=E2=80=9D >> I=E2=80=99m not sure I understand the ACK case here because if you = add a >> CONVERT message to a TCP packet that means you add payload data. I = was >> reading this as pure ACK but that can't be the case. So do you mean = by >> this you can only send new data if your previous data was ACK or >> something else=E2=80=A6? >> However, I believe there is usually just one message from the client >> in the SYN and the one message from the converter in the SYN/ACK, and >> then the connection is either closed or switched to the actual = payload >> transmission. So I was assuming that's the only communication pattern >> you can have. Or is the idea that multiple client-converter exchanges >> can be done on the same TCP connection also after the TCP handshake >> and then any time in the connection you would be able to switch over >> to sending other payload data? I think this need further = clarification >> in the draft. >>=20 >> Note that section 7 also say: >> "In this section, we only discuss >> the middleboxes that modify SYN and SYN+ACK packets since the >> Convert >> Protocol places its messages in such packets.=E2=80=9D >>=20 >> 9) This point is probably related to the previous point. In section >> 5.1 you say that the connection MUST be reset (if length is zero) but >> in all other sections you say the connection must be closed if there >> is a problem. Assuming the Convert protocol will only be used in SYN >> and SYN/ACK, reset is probably more appropriate. If it can be used >> also in later packets you probably have to say something like = =E2=80=9Cclose >> or reset if the handshake is not completed=E2=80=9D=E2=80=A6? >>=20 >> E.g. see sec 5.2.1: >> "If two or more >> instances of the same TLV are exchanged over a Convert connection, >> the associated TCP connections MUST be closed.=E2=80=9D >> Is that close or reset? >>=20 >> Also related: >> The next section (5.2.2) says: >> "Type 0x0 is a reserved valued. Implementations MUST discard = messages >> with such TLV.=E2=80=9D >> (Nit s/valued/value/) >> And in sec 5.2.5: >> "Connect TLVs witch such messages MUST be discarded by the Transport >> Converter." >> I guess every time you say in the document that a message is = discarded >> that would also lead somehow to closing the connection most likely = by >> to sending a reset, no? Or should the SYN just be drop and no reply >> send for any reason? Please clarify. >>=20 >> 10) Probably editorial in sec 5.2.4: >> "A Transport Converter SHOULD include in this >> list the TCP options that it accepts from Clients; these options >> are >> included by the Transport Converter in the SYN packets that it >> sends >> to initiate connections.=E2=80=9D >> I had to read the second half twice because it suddenly talks about a >> completely different =E2=80=9Cscenario=E2=80=9D than replying to an = Info TLV. Maybe >> some rewording could help a bit like >> "A Transport Converter SHOULD include in this >> list the TCP options that it accepts from Clients; these options >> are >> also included by the Transport Converter in the SYN packets if it >> initiates connections to the client.=E2=80=9D >> Or maybe even use normative language here: >> =E2=80=9Cthe Transport Convert SHOULD also include the same option in = the SYN >> if >> it initiates a connection to the client.=E2=80=9D >>=20 >> 11) sec 5.2.5: Maybe also be slightly more clear here: >> "For incoming connections destined to a Client >> serviced via a Transport Converter, these fields convey the source >> port number and IP address.=E2=80=9D >> Proposed >> "For incoming connections destined to a Client >> serviced via a Transport Converter, these fields convey the source >> port number and IP address of the SYN packet received by the >> Transport Converter from the server.=E2=80=9D >>=20 >> 12) I have a couple of question about the TCP options field in the >> Connect TLV, basically this text in section 5.2.5: >> " Upon reception of a Connect TLV, and absent any policy (e.g., >> rate- >> limit) or resource exhaustion conditions, a Transport Converter >> attempts to establish a connection to the address and port that it >> contains. The Transport Converter MUST use by default the TCP >> options that correspond to its local policy to establish this >> connection. These are the options that it advertises in the >> Supported TCP Extensions TLV. >>=20 >>=20 >> Bonaventure, et al. Expires May 7, 2020 [Page >> 22] >> Internet-Draft Convert Protocol November >> 2019 >>=20 >>=20 >> Upon reception of an extended Connect TLV, and absent any rate >> limit >> policy or resource exhaustion conditions, a Transport Converter >> MUST >> attempt to establish a connection to the address and port that it >> contains. It MUST include the options of the 'TCP Options' sub- >> field >> in the SYN sent to the Server in addition to the TCP options that >> it >> would have used according to its local policies. For the TCP >> options >> that are listed without an optional value, the Transport Converter >> MUST generate its own value. For the TCP options that are included >> in the 'TCP Options' field with an optional value, it MUST copy the >> entire option for use in the connection with the destination peer. >> This feature is required to support TCP Fast Open.=E2=80=9D >>=20 >> First of all the upper paragraph is probably old and should have been >> removed, right? >>=20 >> Then I=E2=80=99m not certain about the new approach with the TCP = option field. >> If the converter actually ends up in a split connection (with e.g. >> MPTCP on client side but without it on server side), I thought it can >> only announce those options in the SYN to the server that are = actually >> implemented in the converter and it will be able to support later in >> the connection. So blindly copying the options provided by the client >> doesn=E2=80=99t seem right. Or what do I miss? >>=20 >> I understand the case where you want to use TFO between the client = and >> the convert but can=E2=80=99t use it anymore between the the client = and the >> server then. However you can only use TFO with the second connection >> you make to a server. So in the first connection either TFO was used >> between the convert and the server and the convert could now use it >> again with the cookie it received or TFO was used end-to-end in the >> first connection and it now clear to me why the converter is used = now. >> Maybe I=E2=80=99m missing something but I think the drafts would at = least need >> more explanation about the motivation to have this. >>=20 >> If it=E2=80=99s really only about TFO cookies and we are sure we want = to have >> that feature, maybe an own TLV would be simpler? >>=20 >> 13) In sec 5.2.6 do you mean by "extended TCP header=E2=80=9D the TCP = option >> space? I=E2=80=99m not sure that "extended TCP header=E2=80=9D is a = clearly defined >> term; as least I=E2=80=99m not 100% sure what you mean=E2=80=A6 >>=20 >> 14) nit in sec 5.2.7: >> s/The Cookie TLV (Figure 20 is an optional/The Cookie TLV (Figure 20) >> is an optional/ -> missing closing bracket >>=20 >> 15) Sec 5.2.7: >> Question about normative language: >> "If the received SYN did not contain a Cookie TLV, and cookie >> validation is required, the Transport Converter should compute a >> Cookie bound to this Client address and return a Convert message >> containing the fixed header, an Error TLV set to "Missing Cookie" >> and >> the computed Cookie and close the connection.=E2=80=9D >> Is this maybe a MAY condition? All of it? Or something like this >> "If the received SYN did not contain a Cookie TLV, and cookie >> validation is required, the Transport Converter MAY compute a >> Cookie bound to this Client address. It MUST return a Convert >> message >> containing the fixed header and Error TLV set to "Missing Cookie=E2=80= =9D >> and MAY add >> the computed Cookie. After sending the Error TLV is MUST/SHOULD >> close/reset >> the connection.=E2=80=9D >> Not fully sure what is the intention here=E2=80=A6 >>=20 >> 15) sec 5.2.8: >> What's the purpose of the client sending an Unsupported Version = error? >> If the converter replies with a different version than requested used >> by the client, that's simply a fatal error/implementation error and >> the client can only reset the connection I think. >>=20 >> More generally if I read this correctly there are only 3 errors that >> could be sent by the client. I guess those errors would be send in = the >> first packet after the SYN/ACK is received=E2=80=A6? Related to my = question >> above, I think it would be much easier to only have Convert message = in >> the SYN and SYN/ACK and no explicit error message from the client. >> Otherwise more explanation in the draft would be need how this >> actually is supposed to work. >>=20 >> 16) sec 5.2.8: >> "A Client which receives this error code MUST cache the received >> Cookie and include it in subsequent Convert messages sent to >> that >> Transport Converter.=E2=80=9D >> This seems to be a slightly weird normative MUST. Sure you have to >> cache the cookie in oder to be able to use the converter, however, >> there may be cases where you loose the cache and then sending a >> Connect without the cookie to get a new Cookie is a valid option. So >> you may use SHOULD here or even better reword it completely... >>=20 >> 17) There is an Unsupported TCP Option in section 5.2.8. However, = this >> error is not mentioned in 5.2.5. In contrast sec 5.2.5 says that the >> converter MUST open a connection and MUST use these options. This is >> related to my point 12 above but it was not clear to me that options >> can be rejected, however, this whole part seems to make the protocol >> really complicated and as I said if the only use case is TFO I would >> prefer to rather have a separate specific TLV for that case only. >>=20 >> 18) I think section 6.7 should still say something about if this >> option is supported or not=E2=80=A6 >>=20 >> 19) section 7: >> "Consider a middlebox that removes the SYN payload. The Client can >> detect this problem by looking at the acknowledgment number field >> of >> the SYN+ACK returned by the Transport Converter. The Client MUST >> stop to use this Transport Converter given the middlebox >> interference.=E2=80=9D >> If the converter received a SYN without a Convert message in the >> payload on the respective port, it is supposed to anyway send a >> SYN/ACK? I would assume it would rather send a RESET, no? I think = that >> needs to be further specified. >>=20 >> 20) Sec 7 also says: >> =E2=80=9CIf an Error was returned by the Transport Converter, a = message to >> close >> the connection would normally follow from the Converter.=E2=80=9D >> However sec 5.2.8 says: >> "Upon reception of an Error TLV, a >> Client MUST close the associated connection.=E2=80=9D >> I assume one of these is not correct=E2=80=A6 please clarify which = end is >> suppose to do what in case of an error. >>=20 >> 21) The text in sec 7 then further says: >> "If no such >> message is received, the Client may continue to use this >> Converter.=E2=80=9D >> Isn=E2=80=99t that a bit dangerous? >>=20 >> 22) section 8.5: Why are the authentication mechanism discussed in >> this section MPTCP specific? I think the same mechanisms could also = be >> applied to Converters supporting other options, no? >>=20 >> 23) sec 8.3: >> "Means to protect against SYN flooding attacks MUST also be enabled >> [RFC4987].=E2=80=9D >> Not sure if the use of MUST is clear here. Which part of RFC4987 does >> this MUST relate to? All of it? Maybe a SHOULD or no normative >> language is more appropriate? >>=20 >> 24) sec 9.2: Maybe call the new registry the "The TCP Convert = Protocol >> (Convert) >> Parameters=E2=80=9D (TCP added)=E2=80=A6? >>=20 >> 25) sec 9.2.2: >> "The values in the range 192-255 can be assigned for Private Use.=E2=80= =9D >> IANA does not assigned any value for Private use, they can just be >> used, so this should be >> "The values in the range 192-255 are reserved for Private Use.=E2=80=9D= >> if that is what you want? >>=20 >> 26) also on section 9.2.X: "Specification Required" includes having = an >> expert review and RFC8126 says: >> "As with Expert Review (Section 4.5), clear guidance to the = designated >> expert should be provided when defining the registry, and thorough >> understanding of Section 5 is important.=E2=80=9D >> So please provide further guidance about what the expert is supported >> to evaluate. >>=20 >> 27) Not sure if the following references need to be normative as = there >> no normative requirement connect to them but only an optional case is >> discussed: RFC4279, RFC7250 =E2=80=A6? >>=20 >> However, RFC7323, RFC2018, RFC6978, RFC6978, RFC2827, RFC6181 should >> probably be normative references=E2=80=A6? >>=20 >> 28) The term =E2=80=9Cexperimental option=E2=80=9D is used with two = different meaning >> in the intro of section 6 (options that are defined in an exp RFC) = and >> in section 6.9 (options with kind 254 and 255). Please clarify this = at >> both places. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 From nobody Fri Jan 24 06:50:26 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D3F12008D for ; Fri, 24 Jan 2020 06:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 dtewI_uCZ0p6 for ; Fri, 24 Jan 2020 06:50:22 -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 17EE512006E for ; Fri, 24 Jan 2020 06:50:22 -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=rqkbKKawauRr7XSEPgnHgHcLidXIo42Ofos35uHp6BA=; b=Zya5AEGcWCUg8GLTihTJiBFyn ekfnsCXp/gPJtVUTT+Sx+rhWEmd2LTSr3UTIy6lNTnsEmofVc7oLzlVLeMPNEdMjHGac0omShkjf/ cYXS99pSTTGW0PKK/iL1BHrlzdibztHKBprds9DhZrQnousC2bP16fkj78vtJVsuBA9t4s8HGtY+c p+h9SAlQDufQBzRt2nbmzwWyoz2zukLRzNvIZcp+svPcywhqsGUN4+CJwpQs3IGaRw6ndcidpHpZl 9ys5cAwWgtJVC2VghWBBY0XLo9BZCKQkNgYRkXUDOH6cVQKOX3YE23/ALkwarl/bY/eh4WYlCBswy ngfX/jm4A==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:50608 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iv0Hk-002Kmb-Sg; Fri, 24 Jan 2020 09:50:17 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Joe Touch In-Reply-To: <58445bde-d5a1-d853-cb50-80d1ab1fc8e6@si6networks.com> Date: Fri, 24 Jan 2020 06:50:12 -0800 Cc: tcpm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9424F89C-82E1-4669-9C0D-8B9C92D20025@strayalpha.com> References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk> <4D99C7DD-F57E-4708-8F02-824EB4BF8E24@weston.borman.com> <333A2AF9-7DDD-4FAA-B0BD-E6871564850F@strayalpha.com> <495c6e94-d5a4-effe-3c4d-d5275deb8cc8@erg.abdn.ac.uk> <5C1F0A09-F6B8-4EDB-BB9D-431DD6C04D06@strayalpha.com> <58445bde-d5a1-d853-cb50-80d1ab1fc8e6@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3608.40.2.2.4) 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: [tcpm] 793bis: IP ID X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 14:50:25 -0000 Text is needed here to deal with the current text in 1122. 793bis = doesn=E2=80=99t exist in a vacuum. Joe > On Jan 23, 2020, at 10:08 PM, Fernando Gont = wrote: >=20 > On 24/1/20 02:48, Joe Touch wrote: >>> On Jan 23, 2020, at 8:58 PM, Fernando Gont > wrote: >>>=20 >>> On 23/1/20 11:54, Joe Touch wrote: >>>>> On Jan 23, 2020, at 5:24 AM, Gorry Fairhurst > wrote: >>>>>=20 >>>>> I think this is the wrong ID to discuss anything related to IPv4 = ID. >>>> I disagree. >>>> It=E2=80=99s important to support the *requirement* in 6864 by = explicitly indicating that the ID *MUST NOT* be used for duplicate = segment detection in TCP. >>>=20 >>> With layering in mind, why would one want to do that? >> Because the information in RFC1122 in section 4.2.2.15 needs to be = integrated >=20 > Does it? It would seem to me that these IP ID tricks are an = implementation-specific trick that would never be implemented in = general-purpose implementations. >=20 > Even more, it would make even less sense in the light of the Internet = moving towards IPv6 (albeit at a horrible pace), wheere the "IP ID" is = not available in all packets. >=20 >=20 >> and corrected to bring it up to date with RFC6864, even if in the = negative. >> I.e., this doc should be very clear on two points: >> - TCP MUST NOT attempt to control the IP ID to try to indicate = duplicate sent segments >> - TCP MUST NOT use the IP ID in trying to identify duplicate received = segments >> I.e., in summary, exactly to encode that layering. >=20 >=20 > My question here is whether we want to drag such (mostly obsolete) = details into this more modern spec, or not. >=20 > It would seem yo me that a fresh reader of *this* 793bis would = probably be quite puzzled when reading this sort of requirement that = mostly have to do with what some implementations did ages ago... >=20 >=20 > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Sat Jan 25 02:41:37 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0B8120089; Sat, 25 Jan 2020 02:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gA4CO6A1NRvS; Sat, 25 Jan 2020 02:41:32 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 CC64E120072; Sat, 25 Jan 2020 02:41:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1579948878; bh=I5SztyzGmiwJb2U2aQx5dTwK+xQEXprJN8a3841DXWM=; h=X-UI-Sender-Class:Subject:From:To:References:Date:In-Reply-To; b=Fd6bd8Ch+sUz4xty4KfOjPbcfo2gecSocJWxjm+twwc9hUypvRS/rCZqwedqobdGC YiZhjBpF/c23pQzZ09FTqC/PiPXAhJ3UbieeVJhwTnMlM8Wwe3ZsSCn3ylaS+vlqEO dLUsnIkc/7aKFsH5COidsOvWiWH1iJlzXHOR6vNo= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.249.64.52] ([217.70.211.10]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MPokD-1jIAv701Hn-00MvIq; Sat, 25 Jan 2020 11:41:18 +0100 From: "Scheffenegger, Richard" To: "tcpm@ietf.org" , draft-ietf-tcpm-generalized-ecn@ietf.org, FreeBSD Transport , Neal Cardwell , Christoph Paasch , Vidhi Goel , Rodney Grimes , Michael Tuexen References: <6f6f4c2f-b72f-b7fb-55aa-c6985862d061@gmx.at> <3cd59a2f-d926-769c-175e-91938b962463@gmx.at> Message-ID: Date: Sat, 25 Jan 2020 11:41:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <3cd59a2f-d926-769c-175e-91938b962463@gmx.at> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:v4ptnx/ebscp41id6r+EjVbn4v4AQtSwm8WkATgtOJn7+lY1SCM OFY7aYDn6KFPtFgotqi7DVKnDkJuaui5QrOTFBgDhAis1odgHFgM8aX38NmrX/hIAkfJCRR 2T1AQ/Q7brt/MfrycHZGdQ6PSn6bvoGj/us4Sd9mVSMpJwkko7xaVy4xzq2AvDAW27sLnys onYAGdTIFbYI+nyitEIog== X-UI-Out-Filterresults: notjunk:1;V03:K0:nOUA/135oJw=:woihVO0nYhQYldf5R41LzS rzbrUObSegyJR2kk+u4OclrPombyJkNhfyDnm9+67EVZu94hXR2By51zdNaqMop2mC2IzAC4D 3fNdP2svbx5y/yzLZMwbZYbjnhAS4xM10UcQo6lzPjjFoj/e1qN0/f6tFP+s44b6XTs/JVJ4n VW9KUZYqqaZluov/1M0acBHOZ5d/MS/b9owyXIhRauoIYJaESAwMkmDUx+lIcb2Q6fF0HvNqw 9dNUBDbhSgT1EkdzaIR76fEk1USHtkqOnVS7WoED9ZSO1kyy+bpsbv2+YfoHupcam4Mm4HhlX 8Io51FcqSxzgz92AbSHjZ8e/y6gUYFg9GsnkTGJL8LANpBsJ+E4fqz8DlgPaREQyY29sYe4kP QyG9gAiOvXfx/COzXYbV4/4AQZweA8wT1mEeqXRmjThsg9Nvp7v8TKuVeHCWn4gzriqOKuDnr GB4+TW4zAt5lIVMrf1oJuT5OfQVGRDH9TNxeHMNM90vpCRvfRtCyLCu4jvQxs63qAi0/1iMOc 9NtZDzNoD7HvP77j4Q29D8PiqSJpp3J2jllQ2+xigzepKAfWIu9tZiTRCIgxiuafZQCFpZ3GU AzZeosRk0TsXb0ag2vsxPb0COV3qWf5BB7Rs9XEYSkiNkkLKagh9MVYmaENfkq1KFGN1bwqpx 3gX0sSHwgzC4ue6Z8GMW6eO7JGx7BEJV2KHYPwUXvu9ZScYJ1mpeRE+RMdHDrBIfaxOXtAZaK yJ6mFcDoumI7D1In1BprsFbKeyyADB026pRqUE7vz9KDgmU6sfNbCeVXMLmVSs/YuvQI5hINh nFnZIBhUFIiV9OMm4rLdgZ1bIH07wtEDg9IXkHbLXm1ysuwb93dQ5488chnGRm3cYbDX0NsR6 MOpi6KWxWpiCgL+K0jmttZwSj3PfXs+FSaQxUGgvscCm7JjkjzI4TcE3sWKsRfHVyePJpZ+QC MQawY4K84DTfKuyI9yVG1yMNO5xeO02Tun+Jn5BpEtqJrv8uehsFfXi+RcOsAG04pjGV8rS4M vOh2nEoIuZ9Imfl3sCsCV85NLXdGcwf7PVh1Bb02wWgxzucszJ+uwm9YT8FbniDShybT5Xru9 TauZu/Xrf3OrvYWuB9ZCq34BY/N77gq3KYoiaspf+mZ+uRVYLkpxNiC1KrkNhbfv14pH3Zp7I Z+Tu7MGzlnBojLuaNOHlLG7wsH7a5XeMD9Gx7010bbGKKMQA75hkfoS6qnW4E+xFU9MW556sl n7gyr9CSBphKTvBqf Archived-At: Subject: Re: [tcpm] ECN++ X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2020 10:41:35 -0000 Hi Group, Marcelo, Bob, Another update in this context, which IMHO may be discussed as an actual change of mechanism with ECN++. I was looking into the very poor interaction of ECN between a Linux client and a BSD server, with request-response workload. That is, where each side sends out less than MSS data, before the application waits for the other side to respond to this. Neal pointed out this statement in RFC3168: ...the TCP sender sets the CWR flag in the TCP header of the first new data packet sent after the window reduction. ... When the TCP data sender is ready to set the CWR bit after reducing the congestion window, it SHOULD set the CWR bit only on the first new data packet that it transmits. However, BSD is sending out the CWR as soon as possible - while Linux interprets the SHOULD overly strictly (IMHO) and ignores CWR unless it is received with (new) data. But binding the CWR flag to a new data segment delays the ECN signaling loop artificially (for long runs of unidirectional transmitted data), and it is not clear what the benefit there would be, as the CWR flag is not retransmitted anyway (thus not bound to a point in the sequence number space). I therefore propose a change in the Generalized ECN draft, to lift the above restriction (while it is "only" a SHOULD, this is one more example of an overly strict receiving-side implementation), and no longer artificially delay the CWR signal - to become also more useful for passive measurements. Richard For those interested: The effect of ignoring the CWR on non-new-data segments by Linux is, that the ECE flag is left latched. Thus BSD continues window-after-window with cwnd reductions, and due to another bug where the ECN-induced reduction has no lower bound, eventually cwnd ends up at 0 Byte and is only increased to 1 Byte by a Timer - until by pure chance, the CWR is sent together with 1 new byte of data. But in the preceeding minutes, the session only saw progress by less than 1 byte / RTT... Am 15.01.2020 um 21:42 schrieb Scheffenegger, Richard: > > Hi, > > Yet another interesting observation =E2=80=93 as fbsd currently doesn=E2= =80=99t refrain > from marking SACK-retransmission to be not-ECT, you can actually end up > getting a CE mark on a retransmission across a ECN-enabled congestion > point. > > Obviously this is better than loss=E2=80=A6 > > What happens next is, that fbsd "honors" that ECE mark, since it is in > loss-recovery, not congestion-recovery. It adjusts the recovery_point to > the current snd_max (rightmost sent segment), and adjusts ssthresh and > cwnd by multiplicative decrease factor... > > Furthermore, it appears that it also resets the traversal of the SACK > scoreboard (incidential a "good" thing, as a few earlier retransmissions > also got dropped, not marked, and are being resent without an RTO). > > But in the context of ECN++, what would be the expected response here? > > I assume, that with the exception of the fresh traversal of the SACK > scoreboard, the above steps seem sensible. > > Any thoughts on this interesting interaction between ECE (during SACK > loss recovery)? > > Best regards, > =C2=A0=C2=A0 Richard > > > > Am 10.01.2020 um 01:08 schrieb Scheffenegger, Richard: >> Marcelo, Bob, >> >> I just noted that there is a slight oversight in FreeBSD currently, >> which results in all session that are simultaneously ECN-enabled and >> SACK-permitted to effectively send out retransmissions with the ECT0 >> codepoint. >> >> Strictly speaking, this is in violation of RFC3168, but might also be a >> good (nearly a decade long) validation of the performance of ECN++ for >> all types of data segments (new and retransmitted ones), although at a >> low and implicit exposure... >> >> >> On that note, since I think ECN++ is quite valuable (with a number of >> published research finding this change to be crucial), perhaps you can >> summarize the outstanding issues (other than more reviewers required; I >> admit I still haven't gone through all the delta between -04 and -05). >> >> Best regards, >> =C2=A0=C2=A0 Richard >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Sat Jan 25 02:47:32 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 439D2120099 for ; Sat, 25 Jan 2020 02:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.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 9ICIYf5Wvlb6 for ; Sat, 25 Jan 2020 02:47:26 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8CAB120072 for ; Sat, 25 Jan 2020 02:47:25 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id y4so5429242ljj.9 for ; Sat, 25 Jan 2020 02:47:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kwSLDWwXNlPBmUqxceqjyKpAutqmLXArtu2RXVHcaws=; b=AJ/0w4CrYJU74Z0425jHtVYg9wco0Rnjsx4L8D/VAAlqZPDBLwaac7BO6kMt/NUnD2 OYqNgPsiODl2qwDGivcP2wh6BUVpQav29pAS46mU2rubcMTOUJafyrgHoM3p/oae/uDl F1lJz9drg6YtIeJ9OHclrtIyswz8zJ1+c8Xn32Ni5Z2XCQR8IhD7Qs4dHrYTf9hVcy4b tdfOoInHpfXgdtDiDGzI+Fq05BcHkGePMbRDkgG14XeDoDJgFQshFl5gZhzk0sZIVham py48IlmqwkPoN1XidDJDWViG+idn5HT6G/2e+wcg9/ypHCGbFOjD8rQ8LyIgko+8UyYN uxBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kwSLDWwXNlPBmUqxceqjyKpAutqmLXArtu2RXVHcaws=; b=Mqhq7G0tke9ElmTP7/iqLubUFb6HIxmVq283TX7m51reaoX5t8UCLIWmck326mX89Q lFNG1j3qIeKfLoGUsNBj1ynoEf7QSSNwSivhFimk7sl9iDLaDiALZVNLzwGohwM4Uv2s 8L7X41sJVH+8zsKJ9Js6Rp3VjEzkVLkIrEiSBoJ5X44rMu7J15VrKtPbadk8lgCjecH0 74iDt9BAAplFLt3P3t2Djtv3zgiz24gWeeYiCSNSgMe78JRxF2CbOCPQEBxDpghA2WhE KF6f+lugUrgAy8OsE+K+Tg6cBzFPd7GhfYKS1XPA4WA9gM6mWwDEQlT0C5P1GYukR2MD j1oA== X-Gm-Message-State: APjAAAXc0uf3sik/Ef8vhXr1fINhCRIIs/Q2skwKJmRGN1cmRTyZbnMT hcqlmMYgdb4uBrwp+DrH/PYgSQlqdOs5g5IBbAtWVeIN3xhMm1657iQujui2gaZWbMUWNs0Ljkp GAtpwV2sTeWwxDutfqQ== X-Google-Smtp-Source: APXvYqwnSu/vbBQORHySKRkAii3d+8xubLQ4NUdW7EtWPlh0T4+uhI3anx9ennNwSDqZFDTz27ZWVW19K+FiD1i7e3w= X-Received: by 2002:a2e:9d11:: with SMTP id t17mr5084938lji.169.1579949243755; Sat, 25 Jan 2020 02:47:23 -0800 (PST) MIME-Version: 1.0 References: <4DF47B41-2A8F-4FC1-8734-4D133F3EBBE5@kuehlewind.net> In-Reply-To: <4DF47B41-2A8F-4FC1-8734-4D133F3EBBE5@kuehlewind.net> From: Olivier Bonaventure Date: Sat, 25 Jan 2020 11:46:57 +0100 Message-ID: To: Mirja Kuehlewind Cc: draft-ietf-tcpm-converters.all@ietf.org, tcpm IETF list Content-Type: multipart/alternative; boundary="00000000000070068f059cf499f7" Archived-At: Subject: Re: [tcpm] AD review of draft-ietf-tcpm-converters-14 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2020 10:47:30 -0000 --00000000000070068f059cf499f7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Mirja, Thanks again for the detailed comments. We are currently digesting them and prepare an updated version of the draft. Some of your comments have indicated that some parts were unclear, notably for the support of the TFO option. We propose to answer them by simplifying the protocol a bit and move the parts that are required to support TFO and other experimental options in a different draft. The working group document will then focus on the standard TCP options (including MPTCP given that version 1 is final) and the other draft will propose extensions to this base protocol to support TFO and other experimental options. This should make the text easier to read and the base protocol simpler to implement Best regards, Olivier, Med and Benjamin On Thu, Jan 9, 2020 at 10:28 PM Mirja Kuehlewind wrote: > Hi authors, > > I finally did my AD review for draft-ietf-tcpm-converters-14 (actually I'= m > still not fully finished with the review of the appendix but would like t= o > send out this first batch of questions now). > > As you can see below, I have a whole bunch of questions/comments. Some of > these may only be editorial in the end but I would like to make sure that= I > understand all the technical parts correctly before we move on with the > processing. > > I think there are basically two main technical points I would like to get > some clarification on, both probably related to things that have been > introduced later in the life time of the doc but maybe not consequently > been changed throughout the whole doc. > > One is besiaclly point 8 below but there are some related other points > below: It is not fully clear which packets can carry Convert messages. I > think initially Convert messages were only supposed to be in the SYN and > SYN/ACK. But then later you enabled it also for other packets, however, i= t > seem the only real case that needs this is when an error message is send = by > the client. But sending Convert messages in other packet than the SYN and > the SYN/ACK seems more complicated because all TCP payload data is > transmitted reliable and must be ack'ed and evil. retransmitted. Maybe it= =E2=80=99s > okay if only an error message is send and a reset right after (so no > retransmission), however, this is not specified, and I wonder if the > complexity is really needed worth the benefit of being able to log more > concrete errors in the converter. > > The other point is basically point 12 below about the TCP option field in > the Connect TLV (also related to point 17 below). This is not well enough > specified and seem also quite complex as a generic mechanism. I would thi= nk > the converter should usually try to use the same option as the client did > send in his SYN to the converter, if supported by the converter TCP > implementation. The TFO cookie might be a special case. I=E2=80=99m not s= ure if > that needs to be generalised or if having a separate TLV for that one cas= e > might be simpler. Please also reconsider this but in any case it needs mo= re > explanation in the spec. > > Please see all my questions/comments below. I may send another message, > when I have reviewed the appendix tomorrow (hopefully with none or only f= ew > additional comments). > > Thanks! > Mirja > > ---------------------- > > 1) I was initially a bit confused about the setup in Figure 6 and > respectively the paragraph just before that figure in sec 3.2: It wasn't > clear to me how the server might know the converter address (or if the > proxy maybe has to be on path). I assume the =E2=80=9Cuse case=E2=80=9D i= s that there was a > previous connection using the converter and now the server tries to > reconnect but of course only knows the converter address, or something? > Maybe you could add slightly more text here. I also I would recommend to > explicitly mention that this setup still has to be explicitly configured = by > the client but using an out of band protocol (which is out or scope for > this spec). Further I think it would be good to mention here already that > the converter also inserts the respective TCP option in the SYN to the > client (if possible due to space limits) and refer to section 4.2 for a > concrete example. > > Btw. shouldn't there be some discussion about MTU issue if options are > added by the converter? > > 2) The following paragraph in section 3.2. seems to specify protocol > requirements but don=E2=80=99t use normative language: > > "If the downstream (or upstream) connection fails for some reason > (excessive retransmissions, reception of an RST segment, etc.), then > the Converter should force the tear-down of the upstream (or > downstream) connection. > > The same reasoning applies when the upstream connection ends. In > this case, the Converter should also terminate the downstream > connection by using FIN segments. If the downstream connection > terminates with the exchange of FIN segments, the Converter should > initiate a graceful termination of the upstream connection.=E2=80=9D > > I recommend to use normativen language here (SHOULD instead of should; or > maybe even MUST?). However, as this text is part of a kind of overview > section, it doesn=E2=80=99t seem to be a really good fit to use normative= language > in that section. So maybe the whole discussion about use of TFO (or not) > should be moved to an own section? > > > 3) Just to double-check, I'm wondering a bit about this phrasing in sec > 3.3.1: > "If no entry is found, the Transport Converter MUST silently > ignore the packet.=E2=80=9D > That means the converter will drop the packet (with no other action), > right? Why do you use term ignore here (instead of drop or discard)? Or > does this have any other implication? > Note that this term is used several times in the doc. > > 4) Also a quick question about this in sec 3.3.1: > "A Transport Converter may operate in address preservation mode (that > is, the Converter does not rewrite the source IP address (i.e., > C=3D=3DT)) or address sharing mode (that is, an address pool is shared > among all Clients serviced by the Converter (i.e., C!=3DT)); refer to > Appendix D for more details. Which behavior to use by a Transport > Converter is deployment-specific.=E2=80=9D > I guess preservation mode can only be used if the converter is on path. I > think that should be explicitly noted here. > > 5) Sec 3.3.2: To be honest I=E2=80=99m not sure I fully understand this s= ection, > especially this sentence: > "Upon receipt of a secondary subflow by the Transport Converter from a > Client, the Converter follows the same behavior specified in > Section 3.3.1 for processing Non-SYNs.=E2=80=9D > Do you mean by "receipt of a secondary subflow=E2=80=9D the SYN on that s= ubflow or > other data? For the SYN I would expect that there is no payload data and > therefore nothing to proxy. For other subflow packets, I guess you need t= o > reorder first, so probably it would be good to mention that=E2=80=A6? May= be it=E2=80=99s > just me misunderstanding something but I believe more explanation is need= ed > here. > > 6) Can you maybe add some more text (in section 5 maybe) why a separate > port number is used/needed? As the client has to be explicitly configured > it could easily be configured with an address and port number. Is this to > avoid collisions with other protocols? What would be the scenario here? > > 7) Sec 5.1: > "The Unassigned field MUST be set to zero in this version of the > protocol. These bits are available for future use [RFC8126].=E2=80=9D > Why is there a reference to RFC8126 here? > > 8) Also sec 5.1 but probably editorial: > "Data added by the Convert Protocol to the TCP bytestream is > unambiguously distinguished from payload data by the Total Length > field in the Convert messages.=E2=80=9D > I believe what you want to say here is that the total length is used to > figure out where potential other payload data might start. However, what = I > would understand from this sentence is that the total length field can be > used to distinguish SYNs that carry the Convert protocol from SYNs that m= ay > carry other payload only, which I don=E2=80=99t think is the case. > > 8) I first have a more general question about the function of the > protocol. Sec 5 says: > "Convert messages may appear only in a SYN, SYN+ACK, or ACK.=E2=80=9D > I=E2=80=99m not sure I understand the ACK case here because if you add a = CONVERT > message to a TCP packet that means you add payload data. I was reading th= is > as pure ACK but that can't be the case. So do you mean by this you can on= ly > send new data if your previous data was ACK or something else=E2=80=A6? > However, I believe there is usually just one message from the client in > the SYN and the one message from the converter in the SYN/ACK, and then t= he > connection is either closed or switched to the actual payload transmissio= n. > So I was assuming that's the only communication pattern you can have. Or = is > the idea that multiple client-converter exchanges can be done on the same > TCP connection also after the TCP handshake and then any time in the > connection you would be able to switch over to sending other payload data= ? > I think this need further clarification in the draft. > > Note that section 7 also say: > "In this section, we only discuss > the middleboxes that modify SYN and SYN+ACK packets since the Convert > Protocol places its messages in such packets.=E2=80=9D > > 9) This point is probably related to the previous point. In section 5.1 > you say that the connection MUST be reset (if length is zero) but in all > other sections you say the connection must be closed if there is a proble= m. > Assuming the Convert protocol will only be used in SYN and SYN/ACK, reset > is probably more appropriate. If it can be used also in later packets you > probably have to say something like =E2=80=9Cclose or reset if the handsh= ake is not > completed=E2=80=9D=E2=80=A6? > > E.g. see sec 5.2.1: > "If two or more > instances of the same TLV are exchanged over a Convert connection, > the associated TCP connections MUST be closed.=E2=80=9D > Is that close or reset? > > Also related: > The next section (5.2.2) says: > "Type 0x0 is a reserved valued. Implementations MUST discard messages > with such TLV.=E2=80=9D > (Nit s/valued/value/) > And in sec 5.2.5: > "Connect TLVs witch such messages MUST be discarded by the Transport > Converter." > I guess every time you say in the document that a message is discarded > that would also lead somehow to closing the connection most likely by to > sending a reset, no? Or should the SYN just be drop and no reply send for > any reason? Please clarify. > > 10) Probably editorial in sec 5.2.4: > "A Transport Converter SHOULD include in this > list the TCP options that it accepts from Clients; these options are > included by the Transport Converter in the SYN packets that it sends > to initiate connections.=E2=80=9D > I had to read the second half twice because it suddenly talks about a > completely different =E2=80=9Cscenario=E2=80=9D than replying to an Info = TLV. Maybe some > rewording could help a bit like > "A Transport Converter SHOULD include in this > list the TCP options that it accepts from Clients; these options are > also included by the Transport Converter in the SYN packets if it > initiates connections to the client.=E2=80=9D > Or maybe even use normative language here: > =E2=80=9Cthe Transport Convert SHOULD also include the same option in the= SYN if > it initiates a connection to the client.=E2=80=9D > > 11) sec 5.2.5: Maybe also be slightly more clear here: > "For incoming connections destined to a Client > serviced via a Transport Converter, these fields convey the source > port number and IP address.=E2=80=9D > Proposed > "For incoming connections destined to a Client > serviced via a Transport Converter, these fields convey the source > port number and IP address of the SYN packet received by the > Transport Converter from the server.=E2=80=9D > > 12) I have a couple of question about the TCP options field in the Connec= t > TLV, basically this text in section 5.2.5: > " Upon reception of a Connect TLV, and absent any policy (e.g., rate- > limit) or resource exhaustion conditions, a Transport Converter > attempts to establish a connection to the address and port that it > contains. The Transport Converter MUST use by default the TCP > options that correspond to its local policy to establish this > connection. These are the options that it advertises in the > Supported TCP Extensions TLV. > > > Bonaventure, et al. Expires May 7, 2020 [Page 22] > Internet-Draft Convert Protocol November 2019 > > > Upon reception of an extended Connect TLV, and absent any rate limit > policy or resource exhaustion conditions, a Transport Converter MUST > attempt to establish a connection to the address and port that it > contains. It MUST include the options of the 'TCP Options' sub-field > in the SYN sent to the Server in addition to the TCP options that it > would have used according to its local policies. For the TCP options > that are listed without an optional value, the Transport Converter > MUST generate its own value. For the TCP options that are included > in the 'TCP Options' field with an optional value, it MUST copy the > entire option for use in the connection with the destination peer. > This feature is required to support TCP Fast Open.=E2=80=9D > > First of all the upper paragraph is probably old and should have been > removed, right? > > Then I=E2=80=99m not certain about the new approach with the TCP option f= ield. If > the converter actually ends up in a split connection (with e.g. MPTCP on > client side but without it on server side), I thought it can only announc= e > those options in the SYN to the server that are actually implemented in t= he > converter and it will be able to support later in the connection. So > blindly copying the options provided by the client doesn=E2=80=99t seem r= ight. Or > what do I miss? > > I understand the case where you want to use TFO between the client and th= e > convert but can=E2=80=99t use it anymore between the the client and the s= erver > then. However you can only use TFO with the second connection you make to= a > server. So in the first connection either TFO was used between the conver= t > and the server and the convert could now use it again with the cookie it > received or TFO was used end-to-end in the first connection and it now > clear to me why the converter is used now. Maybe I=E2=80=99m missing some= thing but > I think the drafts would at least need more explanation about the > motivation to have this. > > If it=E2=80=99s really only about TFO cookies and we are sure we want to = have that > feature, maybe an own TLV would be simpler? > > 13) In sec 5.2.6 do you mean by "extended TCP header=E2=80=9D the TCP opt= ion > space? I=E2=80=99m not sure that "extended TCP header=E2=80=9D is a clear= ly defined term; > as least I=E2=80=99m not 100% sure what you mean=E2=80=A6 > > 14) nit in sec 5.2.7: > s/The Cookie TLV (Figure 20 is an optional/The Cookie TLV (Figure 20) is > an optional/ -> missing closing bracket > > 15) Sec 5.2.7: > Question about normative language: > "If the received SYN did not contain a Cookie TLV, and cookie > validation is required, the Transport Converter should compute a > Cookie bound to this Client address and return a Convert message > containing the fixed header, an Error TLV set to "Missing Cookie" and > the computed Cookie and close the connection.=E2=80=9D > Is this maybe a MAY condition? All of it? Or something like this > "If the received SYN did not contain a Cookie TLV, and cookie > validation is required, the Transport Converter MAY compute a > Cookie bound to this Client address. It MUST return a Convert message > containing the fixed header and Error TLV set to "Missing Cookie=E2=80= =9D and > MAY add > the computed Cookie. After sending the Error TLV is MUST/SHOULD > close/reset > the connection.=E2=80=9D > Not fully sure what is the intention here=E2=80=A6 > > 15) sec 5.2.8: > What's the purpose of the client sending an Unsupported Version error? If > the converter replies with a different version than requested used by the > client, that's simply a fatal error/implementation error and the client c= an > only reset the connection I think. > > More generally if I read this correctly there are only 3 errors that coul= d > be sent by the client. I guess those errors would be send in the first > packet after the SYN/ACK is received=E2=80=A6? Related to my question abo= ve, I > think it would be much easier to only have Convert message in the SYN and > SYN/ACK and no explicit error message from the client. Otherwise more > explanation in the draft would be need how this actually is supposed to > work. > > 16) sec 5.2.8: > "A Client which receives this error code MUST cache the received > Cookie and include it in subsequent Convert messages sent to that > Transport Converter.=E2=80=9D > This seems to be a slightly weird normative MUST. Sure you have to cache > the cookie in oder to be able to use the converter, however, there may be > cases where you loose the cache and then sending a Connect without the > cookie to get a new Cookie is a valid option. So you may use SHOULD here = or > even better reword it completely... > > 17) There is an Unsupported TCP Option in section 5.2.8. However, this > error is not mentioned in 5.2.5. In contrast sec 5.2.5 says that the > converter MUST open a connection and MUST use these options. This is > related to my point 12 above but it was not clear to me that options can = be > rejected, however, this whole part seems to make the protocol really > complicated and as I said if the only use case is TFO I would prefer to > rather have a separate specific TLV for that case only. > > 18) I think section 6.7 should still say something about if this option i= s > supported or not=E2=80=A6 > > 19) section 7: > "Consider a middlebox that removes the SYN payload. The Client can > detect this problem by looking at the acknowledgment number field of > the SYN+ACK returned by the Transport Converter. The Client MUST > stop to use this Transport Converter given the middlebox > interference.=E2=80=9D > If the converter received a SYN without a Convert message in the payload > on the respective port, it is supposed to anyway send a SYN/ACK? I would > assume it would rather send a RESET, no? I think that needs to be further > specified. > > 20) Sec 7 also says: > =E2=80=9CIf an Error was returned by the Transport Converter, a message t= o close > the connection would normally follow from the Converter.=E2=80=9D > However sec 5.2.8 says: > "Upon reception of an Error TLV, a > Client MUST close the associated connection.=E2=80=9D > I assume one of these is not correct=E2=80=A6 please clarify which end is= suppose > to do what in case of an error. > > 21) The text in sec 7 then further says: > "If no such > message is received, the Client may continue to use this Converter.=E2= =80=9D > Isn=E2=80=99t that a bit dangerous? > > 22) section 8.5: Why are the authentication mechanism discussed in this > section MPTCP specific? I think the same mechanisms could also be applied > to Converters supporting other options, no? > > 23) sec 8.3: > "Means to protect against SYN flooding attacks MUST also be enabled > [RFC4987].=E2=80=9D > Not sure if the use of MUST is clear here. Which part of RFC4987 does thi= s > MUST relate to? All of it? Maybe a SHOULD or no normative language is mor= e > appropriate? > > 24) sec 9.2: Maybe call the new registry the "The TCP Convert Protocol > (Convert) > Parameters=E2=80=9D (TCP added)=E2=80=A6? > > 25) sec 9.2.2: > "The values in the range 192-255 can be assigned for Private Use.=E2=80= =9D > IANA does not assigned any value for Private use, they can just be used, > so this should be > "The values in the range 192-255 are reserved for Private Use.=E2=80=9D > if that is what you want? > > 26) also on section 9.2.X: "Specification Required" includes having an > expert review and RFC8126 says: > "As with Expert Review (Section 4.5), clear guidance to the designated > expert should be provided when defining the registry, and thorough > understanding of Section 5 is important.=E2=80=9D > So please provide further guidance about what the expert is supported to > evaluate. > > 27) Not sure if the following references need to be normative as there no > normative requirement connect to them but only an optional case is > discussed: RFC4279, RFC7250 =E2=80=A6? > > However, RFC7323, RFC2018, RFC6978, RFC6978, RFC2827, RFC6181 should > probably be normative references=E2=80=A6? > > 28) The term =E2=80=9Cexperimental option=E2=80=9D is used with two diffe= rent meaning in > the intro of section 6 (options that are defined in an exp RFC) and in > section 6.9 (options with kind 254 and 255). Please clarify this at both > places. > > > > > > > > > > > --=20 Disclaimer: https://www.tessares.net/mail-disclaimer/=20 --00000000000070068f059cf499f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Mirja,

Thanks again for the detail= ed comments. We are currently digesting them and prepare an updated version= of the draft. Some of your comments have indicated that some parts were un= clear, notably for the support of the TFO option. We propose to answer them= by simplifying=C2=A0the protocol a bit and move the parts that are require= d to support TFO and other experimental options in a different draft. The w= orking group document will then focus on the standard TCP options (includin= g MPTCP given that version 1 is final) and the other draft will propose ext= ensions to this base protocol to support TFO and other experimental options= .=C2=A0

This should make the text easier to read a= nd the base protocol simpler to implement

Best reg= ards,

Olivier, Med and Benjamin

On Thu, Jan 9= , 2020 at 10:28 PM Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
Hi authors,

I finally did my AD review for draft-ietf-tcpm-converters-14 (actually I= 9;m still not fully finished with the review of the appendix but would like= to send out this first batch of questions now).

As you can see below, I have a whole bunch of questions/comments. Some of t= hese may only be editorial in the end but I would like to make sure that I = understand all the technical parts correctly before we move on with the pro= cessing.

I think there are basically two main technical points I would like to get s= ome clarification on, both probably related to things that have been introd= uced later in the life time of the doc but maybe not consequently been chan= ged throughout the whole doc.

One is besiaclly point 8 below but there are some related other points belo= w: It is not fully clear which packets can carry Convert messages. I think = initially Convert messages were only supposed to be in the SYN and SYN/ACK.= But then later you enabled it also for other packets, however, it seem the= only real case that needs this is when an error message is send by the cli= ent. But sending Convert messages in other packet than the SYN and the SYN/= ACK seems more complicated because all TCP payload data is transmitted reli= able and must be ack'ed and evil. retransmitted. Maybe it=E2=80=99s oka= y if only an error message is send and a reset right after (so no retransmi= ssion), however, this is not specified, and I wonder if the complexity is r= eally needed worth the benefit of being able to log more concrete errors in= the converter.

The other point is basically point 12 below about the TCP option field in t= he Connect TLV (also related to point 17 below). This is not well enough sp= ecified and seem also quite complex as a generic mechanism. I would think t= he converter should usually try to use the same option as the client did se= nd in his SYN to the converter, if supported by the converter TCP implement= ation. The TFO cookie might be a special case. I=E2=80=99m not sure if that= needs to be generalised or if having a separate TLV for that one case migh= t be simpler. Please also reconsider this but in any case it needs more exp= lanation in the spec.

Please see all my questions/comments below. I may send another message, whe= n I have reviewed the appendix tomorrow (hopefully with none or only few ad= ditional comments).

Thanks!
Mirja

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

1) I was initially a bit confused about the setup in Figure 6 and respectiv= ely the paragraph just before that figure in sec 3.2: It wasn't clear t= o me how the server might know the converter address (or if the proxy maybe= has to be on path). I assume the =E2=80=9Cuse case=E2=80=9D is that there = was a previous connection using the converter and now the server tries to r= econnect but of course only knows the converter address, or something? Mayb= e you could add slightly more text here. I also I would recommend to explic= itly mention that this setup still has to be explicitly configured by the c= lient but using an out of band protocol (which is out or scope for this spe= c). Further I think it would be good to mention here already that the conve= rter also inserts the respective TCP option in the SYN to the client (if po= ssible due to space limits) and refer to section 4.2 for a concrete example= .

Btw. shouldn't there be some discussion about MTU issue if options are = added by the converter?

2) The following paragraph in section 3.2. seems to specify protocol requir= ements but don=E2=80=99t use normative language:

"If the downstream (or upstream) connection fails for some reason
=C2=A0 =C2=A0(excessive retransmissions, reception of an RST segment, etc.)= , then
=C2=A0 =C2=A0the Converter should force the tear-down of the upstream (or =C2=A0 =C2=A0downstream) connection.

=C2=A0 =C2=A0The same reasoning applies when the upstream connection ends.= =C2=A0 In
=C2=A0 =C2=A0this case, the Converter should also terminate the downstream<= br> =C2=A0 =C2=A0connection by using FIN segments.=C2=A0 If the downstream conn= ection
=C2=A0 =C2=A0terminates with the exchange of FIN segments, the Converter sh= ould
=C2=A0 =C2=A0initiate a graceful termination of the upstream connection.=E2= =80=9D

I recommend to use normativen language here (SHOULD instead of should; or m= aybe even MUST?). However, as this text is part of a kind of overview secti= on, it doesn=E2=80=99t seem to be a really good fit to use normative langua= ge in that section. So maybe the whole discussion about use of TFO (or not)= should be moved to an own section?


3) Just to double-check, I'm wondering a bit about this phrasing in sec= 3.3.1:
"If no entry is found, the Transport Converter MUST silently
=C2=A0 =C2=A0ignore the packet.=E2=80=9D
That means the converter will drop the packet (with no other action), right= ? Why do you use term ignore here (instead of drop or discard)? Or does thi= s have any other implication?
Note that this term is used several times in the doc.

4) Also a quick question about this in sec 3.3.1:
"A Transport Converter may operate in address preservation mode (that<= br> =C2=A0 =C2=A0is, the Converter does not rewrite the source IP address (i.e.= ,
=C2=A0 =C2=A0C=3D=3DT)) or address sharing mode (that is, an address pool i= s shared
=C2=A0 =C2=A0among all Clients serviced by the Converter (i.e., C!=3DT)); r= efer to
=C2=A0 =C2=A0Appendix D for more details.=C2=A0 Which behavior to use by a = Transport
=C2=A0 =C2=A0Converter is deployment-specific.=E2=80=9D
I guess preservation mode can only be used if the converter is on path. I t= hink that should be explicitly noted here.

5) Sec 3.3.2: To be honest I=E2=80=99m not sure I fully understand this sec= tion, especially this sentence:
"Upon receipt of a secondary subflow by the Transport Converter from a=
=C2=A0 =C2=A0Client, the Converter follows the same behavior specified in =C2=A0 =C2=A0Section 3.3.1 for processing Non-SYNs.=E2=80=9D
Do you mean by "receipt of a secondary subflow=E2=80=9D the SYN on tha= t subflow or other data? For the SYN I would expect that there is no payloa= d data and therefore nothing to proxy. For other subflow packets, I guess y= ou need to reorder first, so probably it would be good to mention that=E2= =80=A6? Maybe it=E2=80=99s just me misunderstanding something but I believe= more explanation is needed here.

6) Can you maybe add some more text (in section 5 maybe) why a separate por= t number is used/needed? As the client has to be explicitly configured it c= ould easily be configured with an address and port number. Is this to avoid= collisions with other protocols? What would be the scenario here?

7) Sec 5.1:
"The Unassigned field MUST be set to zero in this version of the
=C2=A0 =C2=A0protocol.=C2=A0 These bits are available for future use [RFC81= 26].=E2=80=9D
Why is there a reference to RFC8126 here?

8) Also sec 5.1 but probably editorial:
"Data added by the Convert Protocol to the TCP bytestream is
=C2=A0 =C2=A0unambiguously distinguished from payload data by the Total Len= gth
=C2=A0 =C2=A0field in the Convert messages.=E2=80=9D
I believe what you want to say here is that the total length is used to fig= ure out where potential other payload data might start. However, what I wou= ld understand from this sentence is that the total length field can be used= to distinguish SYNs that carry the Convert protocol from SYNs that may car= ry other payload only, which I don=E2=80=99t think is the case.

8) I first have a more general question about the function of the protocol.= Sec 5 says:
"Convert messages may appear only in a SYN, SYN+ACK, or ACK.=E2=80=9D<= br> I=E2=80=99m not sure I understand the ACK case here because if you add a CO= NVERT message to a TCP packet that means you add payload data. I was readin= g this as pure ACK but that can't be the case. So do you mean by this y= ou can only send new data if your previous data was ACK or something else= =E2=80=A6?
However, I believe there is usually just one message from the client in the= SYN and the one message from the converter in the SYN/ACK, and then the co= nnection is either closed or switched to the actual payload transmission. S= o I was assuming that's the only communication pattern you can have. Or= is the idea that multiple client-converter exchanges can be done on the sa= me TCP connection also after the TCP handshake and then any time in the con= nection you would be able to switch over to sending other payload data? I t= hink this need further clarification in the draft.

Note that section 7 also say:
"In this section, we only discuss
=C2=A0 =C2=A0the middleboxes that modify SYN and SYN+ACK packets since the = Convert
=C2=A0 =C2=A0Protocol places its messages in such packets.=E2=80=9D

9) This point is probably related to the previous point. In section 5.1 you= say that the connection MUST be reset (if length is zero) but in all other= sections you say the connection must be closed if there is a problem. Assu= ming the Convert protocol will only be used in SYN and SYN/ACK, reset is pr= obably more appropriate. If it can be used also in later packets you probab= ly have to say something like =E2=80=9Cclose or reset if the handshake is n= ot completed=E2=80=9D=E2=80=A6?

E.g. see sec 5.2.1:
"If two or more
=C2=A0 =C2=A0instances of the same TLV are exchanged over a Convert connect= ion,
=C2=A0 =C2=A0the associated TCP connections MUST be closed.=E2=80=9D
Is that close or reset?

Also related:
The next section (5.2.2) says:
"Type 0x0 is a reserved valued.=C2=A0 Implementations MUST discard mes= sages
=C2=A0 =C2=A0with such TLV.=E2=80=9D
(Nit s/valued/value/)
And in sec 5.2.5:
"Connect TLVs witch such messages MUST be discarded by the Transport =C2=A0 =C2=A0Converter."
I guess every time you say in the document that a message is discarded that= would=C2=A0 also lead somehow to closing the connection most likely by to = sending a reset, no? Or should the SYN just be drop and no reply send for a= ny reason? Please clarify.

10) Probably editorial in sec 5.2.4:
"A Transport Converter SHOULD include in this
=C2=A0 =C2=A0list the TCP options that it accepts from Clients; these optio= ns are
=C2=A0 =C2=A0included by the Transport Converter in the SYN packets that it= sends
=C2=A0 =C2=A0to initiate connections.=E2=80=9D
I had to read the second half twice because it suddenly talks about a compl= etely different =E2=80=9Cscenario=E2=80=9D than replying to an Info TLV. Ma= ybe some rewording could help a bit like
"A Transport Converter SHOULD include in this
=C2=A0 =C2=A0list the TCP options that it accepts from Clients; these optio= ns are
=C2=A0 =C2=A0also included by the Transport Converter in the SYN packets if= it
=C2=A0 =C2=A0initiates connections to the client.=E2=80=9D
Or maybe even use normative language here:
=E2=80=9Cthe Transport Convert SHOULD also include the same option in the S= YN if
=C2=A0 =C2=A0it initiates a connection to the client.=E2=80=9D

11) sec 5.2.5: Maybe also be slightly more clear here:
"For incoming connections destined to a Client
=C2=A0 =C2=A0serviced via a Transport Converter, these fields convey the so= urce
=C2=A0 =C2=A0port number and IP address.=E2=80=9D
Proposed
"For incoming connections destined to a Client
=C2=A0 =C2=A0serviced via a Transport Converter, these fields convey the so= urce
=C2=A0 =C2=A0port number and IP address of the SYN packet received by the <= br> =C2=A0 =C2=A0Transport Converter from the server.=E2=80=9D

12) I have a couple of question about the TCP options field in the Connect = TLV, basically this text in section 5.2.5:
"=C2=A0 =C2=A0Upon reception of a Connect TLV, and absent any policy (= e.g., rate-
=C2=A0 =C2=A0limit) or resource exhaustion conditions, a Transport Converte= r
=C2=A0 =C2=A0attempts to establish a connection to the address and port tha= t it
=C2=A0 =C2=A0contains.=C2=A0 The Transport Converter MUST use by default th= e TCP
=C2=A0 =C2=A0options that correspond to its local policy to establish this<= br> =C2=A0 =C2=A0connection.=C2=A0 These are the options that it advertises in = the
=C2=A0 =C2=A0Supported TCP Extensions TLV.


Bonaventure, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires May 7, 2020=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 22]
Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Convert Prot= ocol=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0November 2019

=C2=A0 =C2=A0Upon reception of an extended Connect TLV, and absent any rate= limit
=C2=A0 =C2=A0policy or resource exhaustion conditions, a Transport Converte= r MUST
=C2=A0 =C2=A0attempt to establish a connection to the address and port that= it
=C2=A0 =C2=A0contains.=C2=A0 It MUST include the options of the 'TCP Op= tions' sub-field
=C2=A0 =C2=A0in the SYN sent to the Server in addition to the TCP options t= hat it
=C2=A0 =C2=A0would have used according to its local policies.=C2=A0 For the= TCP options
=C2=A0 =C2=A0that are listed without an optional value, the Transport Conve= rter
=C2=A0 =C2=A0MUST generate its own value.=C2=A0 For the TCP options that ar= e included
=C2=A0 =C2=A0in the 'TCP Options' field with an optional value, it = MUST copy the
=C2=A0 =C2=A0entire option for use in the connection with the destination p= eer.
=C2=A0 =C2=A0This feature is required to support TCP Fast Open.=E2=80=9D
First of all the upper paragraph is probably old and should have been remov= ed, right?

Then I=E2=80=99m not certain about the new approach with the TCP option fie= ld. If the converter actually ends up in a split connection (with e.g. MPTC= P on client side but without it on server side), I thought it can only anno= unce those options in the SYN to the server that are actually implemented i= n the converter and it will be able to support later in the connection. So = blindly copying the options provided by the client doesn=E2=80=99t seem rig= ht. Or what do I miss?

I understand the case where you want to use TFO between the client and the = convert but can=E2=80=99t use it anymore between the the client and the ser= ver then. However you can only use TFO with the second connection you make = to a server. So in the first connection either TFO was used between the con= vert and the server and the convert could now use it again with the cookie = it received or TFO was used end-to-end in the first connection and it now c= lear to me why the converter is used now. Maybe I=E2=80=99m missing somethi= ng but I think the drafts would at least need more explanation about the mo= tivation to have this.

If it=E2=80=99s really only about TFO cookies and we are sure we want to ha= ve that feature, maybe an own TLV would be simpler?

13) In sec 5.2.6 do you mean by "extended TCP header=E2=80=9D the TCP = option space? I=E2=80=99m not sure that "extended TCP header=E2=80=9D = is a clearly defined term; as least I=E2=80=99m not 100% sure what you mean= =E2=80=A6

14) nit in sec 5.2.7:
s/The Cookie TLV (Figure 20 is an optional/The Cookie TLV (Figure 20) is an= optional/ -> missing closing bracket

15) Sec 5.2.7:
Question about normative language:
"If the received SYN did not contain a Cookie TLV, and cookie
=C2=A0 =C2=A0validation is required, the Transport Converter should compute= a
=C2=A0 =C2=A0Cookie bound to this Client address and return a Convert messa= ge
=C2=A0 =C2=A0containing the fixed header, an Error TLV set to "Missing= Cookie" and
=C2=A0 =C2=A0the computed Cookie and close the connection.=E2=80=9D
Is this maybe a MAY condition? All of it? Or something like this
"If the received SYN did not contain a Cookie TLV, and cookie
=C2=A0 =C2=A0validation is required, the Transport Converter MAY compute a<= br> =C2=A0 =C2=A0Cookie bound to this Client address. It MUST return a Convert = message
=C2=A0 =C2=A0containing the fixed header and Error TLV set to "Missing= Cookie=E2=80=9D and MAY add
=C2=A0 =C2=A0the computed Cookie. After sending the Error TLV is MUST/SHOUL= D close/reset=C2=A0 =C2=A0
=C2=A0 =C2=A0the connection.=E2=80=9D
Not fully sure what is the intention here=E2=80=A6

15) sec 5.2.8:
What's the purpose of the client sending an Unsupported Version error? = If the converter replies with a different version than requested used by th= e client, that's simply a fatal error/implementation error and the clie= nt can only reset the connection I think.

More generally if I read this correctly there are only 3 errors that could = be sent by the client. I guess those errors would be send in the first pack= et after the SYN/ACK is received=E2=80=A6? Related to my question above, I = think it would be much easier to only have Convert message in the SYN and S= YN/ACK and no explicit error message from the client. Otherwise more explan= ation in the draft would be need how this actually is supposed to work.

16) sec 5.2.8:
"A Client which receives this error code MUST cache the received
=C2=A0 =C2=A0 =C2=A0 Cookie and include it in subsequent Convert messages s= ent to that
=C2=A0 =C2=A0 =C2=A0 Transport Converter.=E2=80=9D
This seems to be a slightly weird normative MUST. Sure you have to cache th= e cookie in oder to be able to use the converter, however, there may be cas= es where you loose the cache and then sending a Connect without the cookie = to get a new Cookie is a valid option. So you may use SHOULD here or even b= etter reword it completely...

17) There is an Unsupported TCP Option in section 5.2.8. However, this erro= r is not mentioned in 5.2.5. In contrast sec 5.2.5 says that the converter = MUST open a connection and MUST use these options. This is related to my po= int 12 above but it was not clear to me that options can be rejected, howev= er, this whole part seems to make the protocol really complicated and as I = said if the only use case is TFO I would prefer to rather have a separate s= pecific TLV for that case only.

18) I think section 6.7 should still say something about if this option is = supported or not=E2=80=A6

19) section 7:
"Consider a middlebox that removes the SYN payload.=C2=A0 The Client c= an
=C2=A0 =C2=A0detect this problem by looking at the acknowledgment number fi= eld of
=C2=A0 =C2=A0the SYN+ACK returned by the Transport Converter.=C2=A0 The Cli= ent MUST
=C2=A0 =C2=A0stop to use this Transport Converter given the middlebox
=C2=A0 =C2=A0interference.=E2=80=9D
If the converter received a SYN without a Convert message in the payload on= the respective port, it is supposed to anyway send a SYN/ACK? I would assu= me it would rather send a RESET, no? I think that needs to be further speci= fied.

20) Sec 7 also says:
=E2=80=9CIf an Error was returned by the Transport Converter, a message to = close
=C2=A0 =C2=A0the connection would normally follow from the Converter.=E2=80= =9D
However sec 5.2.8 says:
"Upon reception of an Error TLV, a
=C2=A0 =C2=A0Client MUST close the associated connection.=E2=80=9D
I assume one of these is not correct=E2=80=A6 please clarify which end is s= uppose to do what in case of an error.

21) The text in sec 7 then further says:
"If no such
=C2=A0 =C2=A0message is received, the Client may continue to use this Conve= rter.=E2=80=9D
Isn=E2=80=99t that a bit dangerous?=C2=A0

22) section 8.5: Why are the authentication mechanism discussed in this sec= tion MPTCP specific? I think the same mechanisms could also be applied to C= onverters supporting other options, no?

23) sec 8.3:
"Means to protect against SYN flooding attacks MUST also be enabled [R= FC4987].=E2=80=9D
Not sure if the use of MUST is clear here. Which part of RFC4987 does this = MUST relate to? All of it? Maybe a SHOULD or no normative language is more = appropriate?

24) sec 9.2: Maybe call the new registry the "The TCP Convert Protocol= (Convert)
=C2=A0 =C2=A0Parameters=E2=80=9D (TCP added)=E2=80=A6?

25) sec 9.2.2:
"The values in the range 192-255 can be assigned for Private Use.=E2= =80=9D
IANA does not assigned any value for Private use, they can just be used, so= this should be
"The values in the range 192-255 are reserved for Private Use.=E2=80= =9D
if that is what you want?

26) also on section 9.2.X: "Specification Required" includes havi= ng an expert review and RFC8126 says:
"As with Expert Review (Section 4.5), clear guidance to the designated=
=C2=A0 =C2=A0expert should be provided when defining the registry, and thor= ough
=C2=A0 =C2=A0understanding of Section 5 is important.=E2=80=9D
So please provide further guidance about what the expert is supported to ev= aluate.

27) Not sure if the following references need to be normative as there no n= ormative requirement connect to them but only an optional case is discussed= : RFC4279, RFC7250 =E2=80=A6?

However, RFC7323, RFC2018, RFC6978, RFC6978, RFC2827, RFC6181 should probab= ly be normative references=E2=80=A6?

28) The term =E2=80=9Cexperimental option=E2=80=9D is used with two differe= nt meaning in the intro of section 6 (options that are defined in an exp RF= C) and in section 6.9 (options with kind 254 and 255). Please clarify this = at both places.














--00000000000070068f059cf499f7-- From nobody Sat Jan 25 04:02:51 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC3112081C; Sat, 25 Jan 2020 04:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryvac_oB6VGl; Sat, 25 Jan 2020 04:02:44 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 AB4331200C7; Sat, 25 Jan 2020 04:02:43 -0800 (PST) Received: from ip-109-42-0-120.web.vodafone.de ([109.42.0.120] helo=[100.85.241.216]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ivK9A-0002zh-6j; Sat, 25 Jan 2020 13:02:40 +0100 Content-Type: multipart/alternative; boundary=Apple-Mail-F4F3B8F7-2848-430B-8E00-6E9CD477B5AF Content-Transfer-Encoding: 7bit From: =?utf-8?Q?"Mirja_K=C3=BChlewind_=28IETF=29"?= Mime-Version: 1.0 (1.0) Date: Sat, 25 Jan 2020 13:02:38 +0100 Message-Id: References: Cc: draft-ietf-tcpm-converters.all@ietf.org, tcpm IETF list In-Reply-To: To: Olivier Bonaventure X-Mailer: iPhone Mail (17C54) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1579953763;7a712688; X-HE-SMSGID: 1ivK9A-0002zh-6j Archived-At: Subject: Re: [tcpm] AD review of draft-ietf-tcpm-converters-14 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2020 12:02:49 -0000 --Apple-Mail-F4F3B8F7-2848-430B-8E00-6E9CD477B5AF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Olivier, Sounds like a good plan to me. Let=E2=80=99s see how these changes will actu= ally look like but it might be that the chairs should consider in this case t= o run another working group last call. Mirja > Am 25.01.2020 um 11:47 schrieb Olivier Bonaventure : >=20 > =EF=BB=BF > Dear Mirja, >=20 > Thanks again for the detailed comments. We are currently digesting them an= d prepare an updated version of the draft. Some of your comments have indica= ted that some parts were unclear, notably for the support of the TFO option.= We propose to answer them by simplifying the protocol a bit and move the pa= rts that are required to support TFO and other experimental options in a dif= ferent draft. The working group document will then focus on the standard TCP= options (including MPTCP given that version 1 is final) and the other draft= will propose extensions to this base protocol to support TFO and other expe= rimental options.=20 >=20 > This should make the text easier to read and the base protocol simpler to i= mplement >=20 > Best regards, >=20 > Olivier, Med and Benjamin >=20 >> On Thu, Jan 9, 2020 at 10:28 PM Mirja Kuehlewind wr= ote: >> Hi authors, >>=20 >> I finally did my AD review for draft-ietf-tcpm-converters-14 (actually I'= m still not fully finished with the review of the appendix but would like to= send out this first batch of questions now). >>=20 >> As you can see below, I have a whole bunch of questions/comments. Some of= these may only be editorial in the end but I would like to make sure that I= understand all the technical parts correctly before we move on with the pro= cessing.=20 >>=20 >> I think there are basically two main technical points I would like to get= some clarification on, both probably related to things that have been intro= duced later in the life time of the doc but maybe not consequently been chan= ged throughout the whole doc.=20 >>=20 >> One is besiaclly point 8 below but there are some related other points be= low: It is not fully clear which packets can carry Convert messages. I think= initially Convert messages were only supposed to be in the SYN and SYN/ACK.= But then later you enabled it also for other packets, however, it seem the o= nly real case that needs this is when an error message is send by the client= . But sending Convert messages in other packet than the SYN and the SYN/ACK s= eems more complicated because all TCP payload data is transmitted reliable a= nd must be ack'ed and evil. retransmitted. Maybe it=E2=80=99s okay if only a= n error message is send and a reset right after (so no retransmission), howe= ver, this is not specified, and I wonder if the complexity is really needed w= orth the benefit of being able to log more concrete errors in the converter.= >>=20 >> The other point is basically point 12 below about the TCP option field in= the Connect TLV (also related to point 17 below). This is not well enough s= pecified and seem also quite complex as a generic mechanism. I would think t= he converter should usually try to use the same option as the client did sen= d in his SYN to the converter, if supported by the converter TCP implementat= ion. The TFO cookie might be a special case. I=E2=80=99m not sure if that ne= eds to be generalised or if having a separate TLV for that one case might be= simpler. Please also reconsider this but in any case it needs more explanat= ion in the spec. >>=20 >> Please see all my questions/comments below. I may send another message, w= hen I have reviewed the appendix tomorrow (hopefully with none or only few a= dditional comments). >>=20 >> Thanks! >> Mirja >>=20 >> ---------------------- >>=20 >> 1) I was initially a bit confused about the setup in Figure 6 and respect= ively the paragraph just before that figure in sec 3.2: It wasn't clear to m= e how the server might know the converter address (or if the proxy maybe has= to be on path). I assume the =E2=80=9Cuse case=E2=80=9D is that there was a= previous connection using the converter and now the server tries to reconne= ct but of course only knows the converter address, or something? Maybe you c= ould add slightly more text here. I also I would recommend to explicitly men= tion that this setup still has to be explicitly configured by the client but= using an out of band protocol (which is out or scope for this spec). Furthe= r I think it would be good to mention here already that the converter also i= nserts the respective TCP option in the SYN to the client (if possible due t= o space limits) and refer to section 4.2 for a concrete example. >>=20 >> Btw. shouldn't there be some discussion about MTU issue if options are ad= ded by the converter? >>=20 >> 2) The following paragraph in section 3.2. seems to specify protocol requ= irements but don=E2=80=99t use normative language: >>=20 >> "If the downstream (or upstream) connection fails for some reason >> (excessive retransmissions, reception of an RST segment, etc.), then >> the Converter should force the tear-down of the upstream (or >> downstream) connection. >>=20 >> The same reasoning applies when the upstream connection ends. In >> this case, the Converter should also terminate the downstream >> connection by using FIN segments. If the downstream connection >> terminates with the exchange of FIN segments, the Converter should >> initiate a graceful termination of the upstream connection.=E2=80=9D >>=20 >> I recommend to use normativen language here (SHOULD instead of should; or= maybe even MUST?). However, as this text is part of a kind of overview sect= ion, it doesn=E2=80=99t seem to be a really good fit to use normative langua= ge in that section. So maybe the whole discussion about use of TFO (or not) s= hould be moved to an own section? >>=20 >>=20 >> 3) Just to double-check, I'm wondering a bit about this phrasing in sec 3= .3.1: >> "If no entry is found, the Transport Converter MUST silently >> ignore the packet.=E2=80=9D >> That means the converter will drop the packet (with no other action), rig= ht? Why do you use term ignore here (instead of drop or discard)? Or does th= is have any other implication? >> Note that this term is used several times in the doc. >>=20 >> 4) Also a quick question about this in sec 3.3.1: >> "A Transport Converter may operate in address preservation mode (that >> is, the Converter does not rewrite the source IP address (i.e., >> C=3D=3DT)) or address sharing mode (that is, an address pool is shared= >> among all Clients serviced by the Converter (i.e., C!=3DT)); refer to >> Appendix D for more details. Which behavior to use by a Transport >> Converter is deployment-specific.=E2=80=9D >> I guess preservation mode can only be used if the converter is on path. I= think that should be explicitly noted here.=20 >>=20 >> 5) Sec 3.3.2: To be honest I=E2=80=99m not sure I fully understand this s= ection, especially this sentence: >> "Upon receipt of a secondary subflow by the Transport Converter from a >> Client, the Converter follows the same behavior specified in >> Section 3.3.1 for processing Non-SYNs.=E2=80=9D >> Do you mean by "receipt of a secondary subflow=E2=80=9D the SYN on that s= ubflow or other data? For the SYN I would expect that there is no payload da= ta and therefore nothing to proxy. For other subflow packets, I guess you ne= ed to reorder first, so probably it would be good to mention that=E2=80=A6? M= aybe it=E2=80=99s just me misunderstanding something but I believe more expl= anation is needed here. >>=20 >> 6) Can you maybe add some more text (in section 5 maybe) why a separate p= ort number is used/needed? As the client has to be explicitly configured it c= ould easily be configured with an address and port number. Is this to avoid c= ollisions with other protocols? What would be the scenario here? >>=20 >> 7) Sec 5.1: >> "The Unassigned field MUST be set to zero in this version of the >> protocol. These bits are available for future use [RFC8126].=E2=80=9D= >> Why is there a reference to RFC8126 here? >>=20 >> 8) Also sec 5.1 but probably editorial: >> "Data added by the Convert Protocol to the TCP bytestream is >> unambiguously distinguished from payload data by the Total Length >> field in the Convert messages.=E2=80=9D >> I believe what you want to say here is that the total length is used to f= igure out where potential other payload data might start. However, what I wo= uld understand from this sentence is that the total length field can be used= to distinguish SYNs that carry the Convert protocol from SYNs that may carr= y other payload only, which I don=E2=80=99t think is the case. >>=20 >> 8) I first have a more general question about the function of the protoco= l. Sec 5 says: >> "Convert messages may appear only in a SYN, SYN+ACK, or ACK.=E2=80=9D >> I=E2=80=99m not sure I understand the ACK case here because if you add a C= ONVERT message to a TCP packet that means you add payload data. I was readin= g this as pure ACK but that can't be the case. So do you mean by this you ca= n only send new data if your previous data was ACK or something else=E2=80=A6= ? >> However, I believe there is usually just one message from the client in t= he SYN and the one message from the converter in the SYN/ACK, and then the c= onnection is either closed or switched to the actual payload transmission. S= o I was assuming that's the only communication pattern you can have. Or is t= he idea that multiple client-converter exchanges can be done on the same TCP= connection also after the TCP handshake and then any time in the connection= you would be able to switch over to sending other payload data? I think thi= s need further clarification in the draft. >>=20 >> Note that section 7 also say: >> "In this section, we only discuss >> the middleboxes that modify SYN and SYN+ACK packets since the Convert >> Protocol places its messages in such packets.=E2=80=9D >>=20 >> 9) This point is probably related to the previous point. In section 5.1 y= ou say that the connection MUST be reset (if length is zero) but in all othe= r sections you say the connection must be closed if there is a problem. Assu= ming the Convert protocol will only be used in SYN and SYN/ACK, reset is pro= bably more appropriate. If it can be used also in later packets you probably= have to say something like =E2=80=9Cclose or reset if the handshake is not c= ompleted=E2=80=9D=E2=80=A6?=20 >>=20 >> E.g. see sec 5.2.1: >> "If two or more >> instances of the same TLV are exchanged over a Convert connection, >> the associated TCP connections MUST be closed.=E2=80=9D >> Is that close or reset?=20 >>=20 >> Also related: >> The next section (5.2.2) says: >> "Type 0x0 is a reserved valued. Implementations MUST discard messages >> with such TLV.=E2=80=9D >> (Nit s/valued/value/) >> And in sec 5.2.5: >> "Connect TLVs witch such messages MUST be discarded by the Transport >> Converter." >> I guess every time you say in the document that a message is discarded th= at would also lead somehow to closing the connection most likely by to send= ing a reset, no? Or should the SYN just be drop and no reply send for any re= ason? Please clarify. >>=20 >> 10) Probably editorial in sec 5.2.4: >> "A Transport Converter SHOULD include in this >> list the TCP options that it accepts from Clients; these options are >> included by the Transport Converter in the SYN packets that it sends >> to initiate connections.=E2=80=9D >> I had to read the second half twice because it suddenly talks about a com= pletely different =E2=80=9Cscenario=E2=80=9D than replying to an Info TLV. M= aybe some rewording could help a bit like >> "A Transport Converter SHOULD include in this >> list the TCP options that it accepts from Clients; these options are >> also included by the Transport Converter in the SYN packets if it >> initiates connections to the client.=E2=80=9D >> Or maybe even use normative language here:=20 >> =E2=80=9Cthe Transport Convert SHOULD also include the same option in the= SYN if=20 >> it initiates a connection to the client.=E2=80=9D >>=20 >> 11) sec 5.2.5: Maybe also be slightly more clear here: >> "For incoming connections destined to a Client >> serviced via a Transport Converter, these fields convey the source >> port number and IP address.=E2=80=9D >> Proposed >> "For incoming connections destined to a Client >> serviced via a Transport Converter, these fields convey the source >> port number and IP address of the SYN packet received by the=20 >> Transport Converter from the server.=E2=80=9D >>=20 >> 12) I have a couple of question about the TCP options field in the Connec= t TLV, basically this text in section 5.2.5: >> " Upon reception of a Connect TLV, and absent any policy (e.g., rate- >> limit) or resource exhaustion conditions, a Transport Converter >> attempts to establish a connection to the address and port that it >> contains. The Transport Converter MUST use by default the TCP >> options that correspond to its local policy to establish this >> connection. These are the options that it advertises in the >> Supported TCP Extensions TLV. >>=20 >>=20 >> Bonaventure, et al. Expires May 7, 2020 [Page 22] >> Internet-Draft Convert Protocol November 2019 >>=20 >>=20 >> Upon reception of an extended Connect TLV, and absent any rate limit >> policy or resource exhaustion conditions, a Transport Converter MUST >> attempt to establish a connection to the address and port that it >> contains. It MUST include the options of the 'TCP Options' sub-field >> in the SYN sent to the Server in addition to the TCP options that it >> would have used according to its local policies. For the TCP options >> that are listed without an optional value, the Transport Converter >> MUST generate its own value. For the TCP options that are included >> in the 'TCP Options' field with an optional value, it MUST copy the >> entire option for use in the connection with the destination peer. >> This feature is required to support TCP Fast Open.=E2=80=9D >>=20 >> First of all the upper paragraph is probably old and should have been rem= oved, right? >>=20 >> Then I=E2=80=99m not certain about the new approach with the TCP option f= ield. If the converter actually ends up in a split connection (with e.g. MPT= CP on client side but without it on server side), I thought it can only anno= unce those options in the SYN to the server that are actually implemented in= the converter and it will be able to support later in the connection. So bl= indly copying the options provided by the client doesn=E2=80=99t seem right.= Or what do I miss? >>=20 >> I understand the case where you want to use TFO between the client and th= e convert but can=E2=80=99t use it anymore between the the client and the se= rver then. However you can only use TFO with the second connection you make t= o a server. So in the first connection either TFO was used between the conve= rt and the server and the convert could now use it again with the cookie it r= eceived or TFO was used end-to-end in the first connection and it now clear t= o me why the converter is used now. Maybe I=E2=80=99m missing something but I= think the drafts would at least need more explanation about the motivation t= o have this. >>=20 >> If it=E2=80=99s really only about TFO cookies and we are sure we want to h= ave that feature, maybe an own TLV would be simpler? >>=20 >> 13) In sec 5.2.6 do you mean by "extended TCP header=E2=80=9D the TCP opt= ion space? I=E2=80=99m not sure that "extended TCP header=E2=80=9D is a clea= rly defined term; as least I=E2=80=99m not 100% sure what you mean=E2=80=A6 >>=20 >> 14) nit in sec 5.2.7: >> s/The Cookie TLV (Figure 20 is an optional/The Cookie TLV (Figure 20) is a= n optional/ -> missing closing bracket >>=20 >> 15) Sec 5.2.7: >> Question about normative language: >> "If the received SYN did not contain a Cookie TLV, and cookie >> validation is required, the Transport Converter should compute a >> Cookie bound to this Client address and return a Convert message >> containing the fixed header, an Error TLV set to "Missing Cookie" and >> the computed Cookie and close the connection.=E2=80=9D >> Is this maybe a MAY condition? All of it? Or something like this >> "If the received SYN did not contain a Cookie TLV, and cookie >> validation is required, the Transport Converter MAY compute a >> Cookie bound to this Client address. It MUST return a Convert message >> containing the fixed header and Error TLV set to "Missing Cookie=E2=80= =9D and MAY add >> the computed Cookie. After sending the Error TLV is MUST/SHOULD close/= reset =20 >> the connection.=E2=80=9D >> Not fully sure what is the intention here=E2=80=A6 >>=20 >> 15) sec 5.2.8: >> What's the purpose of the client sending an Unsupported Version error? If= the converter replies with a different version than requested used by the c= lient, that's simply a fatal error/implementation error and the client can o= nly reset the connection I think. >>=20 >> More generally if I read this correctly there are only 3 errors that coul= d be sent by the client. I guess those errors would be send in the first pac= ket after the SYN/ACK is received=E2=80=A6? Related to my question above, I t= hink it would be much easier to only have Convert message in the SYN and SYN= /ACK and no explicit error message from the client. Otherwise more explanati= on in the draft would be need how this actually is supposed to work. >>=20 >> 16) sec 5.2.8: >> "A Client which receives this error code MUST cache the received >> Cookie and include it in subsequent Convert messages sent to that >> Transport Converter.=E2=80=9D >> This seems to be a slightly weird normative MUST. Sure you have to cache t= he cookie in oder to be able to use the converter, however, there may be cas= es where you loose the cache and then sending a Connect without the cookie t= o get a new Cookie is a valid option. So you may use SHOULD here or even bet= ter reword it completely... >>=20 >> 17) There is an Unsupported TCP Option in section 5.2.8. However, this er= ror is not mentioned in 5.2.5. In contrast sec 5.2.5 says that the converter= MUST open a connection and MUST use these options. This is related to my po= int 12 above but it was not clear to me that options can be rejected, howeve= r, this whole part seems to make the protocol really complicated and as I sa= id if the only use case is TFO I would prefer to rather have a separate spec= ific TLV for that case only. >>=20 >> 18) I think section 6.7 should still say something about if this option i= s supported or not=E2=80=A6 >>=20 >> 19) section 7: >> "Consider a middlebox that removes the SYN payload. The Client can >> detect this problem by looking at the acknowledgment number field of >> the SYN+ACK returned by the Transport Converter. The Client MUST >> stop to use this Transport Converter given the middlebox >> interference.=E2=80=9D >> If the converter received a SYN without a Convert message in the payload o= n the respective port, it is supposed to anyway send a SYN/ACK? I would assu= me it would rather send a RESET, no? I think that needs to be further specif= ied. >>=20 >> 20) Sec 7 also says: >> =E2=80=9CIf an Error was returned by the Transport Converter, a message t= o close >> the connection would normally follow from the Converter.=E2=80=9D >> However sec 5.2.8 says: >> "Upon reception of an Error TLV, a >> Client MUST close the associated connection.=E2=80=9D >> I assume one of these is not correct=E2=80=A6 please clarify which end is= suppose to do what in case of an error. >>=20 >> 21) The text in sec 7 then further says: >> "If no such >> message is received, the Client may continue to use this Converter.=E2= =80=9D >> Isn=E2=80=99t that a bit dangerous? =20 >>=20 >> 22) section 8.5: Why are the authentication mechanism discussed in this s= ection MPTCP specific? I think the same mechanisms could also be applied to C= onverters supporting other options, no? >>=20 >> 23) sec 8.3: >> "Means to protect against SYN flooding attacks MUST also be enabled [RFC4= 987].=E2=80=9D >> Not sure if the use of MUST is clear here. Which part of RFC4987 does thi= s MUST relate to? All of it? Maybe a SHOULD or no normative language is more= appropriate? >>=20 >> 24) sec 9.2: Maybe call the new registry the "The TCP Convert Protocol (C= onvert) >> Parameters=E2=80=9D (TCP added)=E2=80=A6? >>=20 >> 25) sec 9.2.2: >> "The values in the range 192-255 can be assigned for Private Use.=E2=80=9D= >> IANA does not assigned any value for Private use, they can just be used, s= o this should be >> "The values in the range 192-255 are reserved for Private Use.=E2=80=9D >> if that is what you want? >>=20 >> 26) also on section 9.2.X: "Specification Required" includes having an ex= pert review and RFC8126 says: >> "As with Expert Review (Section 4.5), clear guidance to the designated >> expert should be provided when defining the registry, and thorough >> understanding of Section 5 is important.=E2=80=9D >> So please provide further guidance about what the expert is supported to e= valuate.=20 >>=20 >> 27) Not sure if the following references need to be normative as there no= normative requirement connect to them but only an optional case is discusse= d: RFC4279, RFC7250 =E2=80=A6? >>=20 >> However, RFC7323, RFC2018, RFC6978, RFC6978, RFC2827, RFC6181 should prob= ably be normative references=E2=80=A6? >>=20 >> 28) The term =E2=80=9Cexperimental option=E2=80=9D is used with two diffe= rent meaning in the intro of section 6 (options that are defined in an exp R= FC) and in section 6.9 (options with kind 254 and 255). Please clarify this a= t both places. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 > Disclaimer: https://www.tessares.net/mail-disclaimer/ >=20 >=20 --Apple-Mail-F4F3B8F7-2848-430B-8E00-6E9CD477B5AF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Olivier,

Sounds like a good plan to me. Let=E2=80=99= s see how these changes will actually look like but it might be that the cha= irs should consider in this case to run another working group last call.

Mirja

Am 25.01.2020 um 11:4= 7 schrieb Olivier Bonaventure <olivier.bonaventure@tessares.net>:
<= br>
=EF=BB=BFDear Mirja,

Thanks again for the detailed c= omments. We are currently digesting them and prepare an updated version of t= he draft. Some of your comments have indicated that some parts were unclear,= notably for the support of the TFO option. We propose to answer them by sim= plifying the protocol a bit and move the parts that are required to sup= port TFO and other experimental options in a different draft. The working gr= oup document will then focus on the standard TCP options (including MPTCP gi= ven that version 1 is final) and the other draft will propose extensions to t= his base protocol to support TFO and other experimental options. 
=

This should make the text easier to read and the base pr= otocol simpler to implement

Best regards,

Olivier, Med and Benjamin

On Thu, Jan 9, 2020 at 10:28 P= M Mirja Kuehlewind <ietf@kuehlewin= d.net> wrote:
Hi authors,

I finally did my AD review for draft-ietf-tcpm-converters-14 (actually I'm s= till not fully finished with the review of the appendix but would like to se= nd out this first batch of questions now).

As you can see below, I have a whole bunch of questions/comments. Some of th= ese may only be editorial in the end but I would like to make sure that I un= derstand all the technical parts correctly before we move on with the proces= sing.

I think there are basically two main technical points I would like to get so= me clarification on, both probably related to things that have been introduc= ed later in the life time of the doc but maybe not consequently been changed= throughout the whole doc.

One is besiaclly point 8 below but there are some related other points below= : It is not fully clear which packets can carry Convert messages. I think in= itially Convert messages were only supposed to be in the SYN and SYN/ACK. Bu= t then later you enabled it also for other packets, however, it seem the onl= y real case that needs this is when an error message is send by the client. B= ut sending Convert messages in other packet than the SYN and the SYN/ACK see= ms more complicated because all TCP payload data is transmitted reliable and= must be ack'ed and evil. retransmitted. Maybe it=E2=80=99s okay if only an e= rror message is send and a reset right after (so no retransmission), however= , this is not specified, and I wonder if the complexity is really needed wor= th the benefit of being able to log more concrete errors in the converter.
The other point is basically point 12 below about the TCP option field in th= e Connect TLV (also related to point 17 below). This is not well enough spec= ified and seem also quite complex as a generic mechanism. I would think the c= onverter should usually try to use the same option as the client did send in= his SYN to the converter, if supported by the converter TCP implementation.= The TFO cookie might be a special case. I=E2=80=99m not sure if that needs t= o be generalised or if having a separate TLV for that one case might be simp= ler. Please also reconsider this but in any case it needs more explanation i= n the spec.

Please see all my questions/comments below. I may send another message, when= I have reviewed the appendix tomorrow (hopefully with none or only few addi= tional comments).

Thanks!
Mirja

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

1) I was initially a bit confused about the setup in Figure 6 and respective= ly the paragraph just before that figure in sec 3.2: It wasn't clear to me h= ow the server might know the converter address (or if the proxy maybe has to= be on path). I assume the =E2=80=9Cuse case=E2=80=9D is that there was a pr= evious connection using the converter and now the server tries to reconnect b= ut of course only knows the converter address, or something? Maybe you could= add slightly more text here. I also I would recommend to explicitly mention= that this setup still has to be explicitly configured by the client but usi= ng an out of band protocol (which is out or scope for this spec). Further I t= hink it would be good to mention here already that the converter also insert= s the respective TCP option in the SYN to the client (if possible due to spa= ce limits) and refer to section 4.2 for a concrete example.

Btw. shouldn't there be some discussion about MTU issue if options are added= by the converter?

2) The following paragraph in section 3.2. seems to specify protocol require= ments but don=E2=80=99t use normative language:

"If the downstream (or upstream) connection fails for some reason
   (excessive retransmissions, reception of an RST segment, etc.),= then
   the Converter should force the tear-down of the upstream (or    downstream) connection.

   The same reasoning applies when the upstream connection ends.&n= bsp; In
   this case, the Converter should also terminate the downstream    connection by using FIN segments.  If the downstream conne= ction
   terminates with the exchange of FIN segments, the Converter sho= uld
   initiate a graceful termination of the upstream connection.=E2=80= =9D

I recommend to use normativen language here (SHOULD instead of should; or ma= ybe even MUST?). However, as this text is part of a kind of overview section= , it doesn=E2=80=99t seem to be a really good fit to use normative language i= n that section. So maybe the whole discussion about use of TFO (or not) shou= ld be moved to an own section?


3) Just to double-check, I'm wondering a bit about this phrasing in sec 3.3.= 1:
"If no entry is found, the Transport Converter MUST silently
   ignore the packet.=E2=80=9D
That means the converter will drop the packet (with no other action), right?= Why do you use term ignore here (instead of drop or discard)? Or does this h= ave any other implication?
Note that this term is used several times in the doc.

4) Also a quick question about this in sec 3.3.1:
"A Transport Converter may operate in address preservation mode (that
   is, the Converter does not rewrite the source IP address (i.e.,=
   C=3D=3DT)) or address sharing mode (that is, an address pool is= shared
   among all Clients serviced by the Converter (i.e., C!=3DT)); re= fer to
   Appendix D for more details.  Which behavior to use by a T= ransport
   Converter is deployment-specific.=E2=80=9D
I guess preservation mode can only be used if the converter is on path. I th= ink that should be explicitly noted here.

5) Sec 3.3.2: To be honest I=E2=80=99m not sure I fully understand this sect= ion, especially this sentence:
"Upon receipt of a secondary subflow by the Transport Converter from a
   Client, the Converter follows the same behavior specified in    Section 3.3.1 for processing Non-SYNs.=E2=80=9D
Do you mean by "receipt of a secondary subflow=E2=80=9D the SYN on that subf= low or other data? For the SYN I would expect that there is no payload data a= nd therefore nothing to proxy. For other subflow packets, I guess you need t= o reorder first, so probably it would be good to mention that=E2=80=A6? Mayb= e it=E2=80=99s just me misunderstanding something but I believe more explana= tion is needed here.

6) Can you maybe add some more text (in section 5 maybe) why a separate port= number is used/needed? As the client has to be explicitly configured it cou= ld easily be configured with an address and port number. Is this to avoid co= llisions with other protocols? What would be the scenario here?

7) Sec 5.1:
"The Unassigned field MUST be set to zero in this version of the
   protocol.  These bits are available for future use [RFC812= 6].=E2=80=9D
Why is there a reference to RFC8126 here?

8) Also sec 5.1 but probably editorial:
"Data added by the Convert Protocol to the TCP bytestream is
   unambiguously distinguished from payload data by the Total Leng= th
   field in the Convert messages.=E2=80=9D
I believe what you want to say here is that the total length is used to figu= re out where potential other payload data might start. However, what I would= understand from this sentence is that the total length field can be used to= distinguish SYNs that carry the Convert protocol from SYNs that may carry o= ther payload only, which I don=E2=80=99t think is the case.

8) I first have a more general question about the function of the protocol. S= ec 5 says:
"Convert messages may appear only in a SYN, SYN+ACK, or ACK.=E2=80=9D
I=E2=80=99m not sure I understand the ACK case here because if you add a CON= VERT message to a TCP packet that means you add payload data. I was reading t= his as pure ACK but that can't be the case. So do you mean by this you can o= nly send new data if your previous data was ACK or something else=E2=80=A6?<= br> However, I believe there is usually just one message from the client in the S= YN and the one message from the converter in the SYN/ACK, and then the conne= ction is either closed or switched to the actual payload transmission. So I w= as assuming that's the only communication pattern you can have. Or is the id= ea that multiple client-converter exchanges can be done on the same TCP conn= ection also after the TCP handshake and then any time in the connection you w= ould be able to switch over to sending other payload data? I think this need= further clarification in the draft.

Note that section 7 also say:
"In this section, we only discuss
   the middleboxes that modify SYN and SYN+ACK packets since the C= onvert
   Protocol places its messages in such packets.=E2=80=9D

9) This point is probably related to the previous point. In section 5.1 you s= ay that the connection MUST be reset (if length is zero) but in all other se= ctions you say the connection must be closed if there is a problem. Assuming= the Convert protocol will only be used in SYN and SYN/ACK, reset is probabl= y more appropriate. If it can be used also in later packets you probably hav= e to say something like =E2=80=9Cclose or reset if the handshake is not comp= leted=E2=80=9D=E2=80=A6?

E.g. see sec 5.2.1:
"If two or more
   instances of the same TLV are exchanged over a Convert connecti= on,
   the associated TCP connections MUST be closed.=E2=80=9D
Is that close or reset?

Also related:
The next section (5.2.2) says:
"Type 0x0 is a reserved valued.  Implementations MUST discard messages<= br>    with such TLV.=E2=80=9D
(Nit s/valued/value/)
And in sec 5.2.5:
"Connect TLVs witch such messages MUST be discarded by the Transport
   Converter."
I guess every time you say in the document that a message is discarded that w= ould  also lead somehow to closing the connection most likely by to sen= ding a reset, no? Or should the SYN just be drop and no reply send for any r= eason? Please clarify.

10) Probably editorial in sec 5.2.4:
"A Transport Converter SHOULD include in this
   list the TCP options that it accepts from Clients; these option= s are
   included by the Transport Converter in the SYN packets that it s= ends
   to initiate connections.=E2=80=9D
I had to read the second half twice because it suddenly talks about a comple= tely different =E2=80=9Cscenario=E2=80=9D than replying to an Info TLV. Mayb= e some rewording could help a bit like
"A Transport Converter SHOULD include in this
   list the TCP options that it accepts from Clients; these option= s are
   also included by the Transport Converter in the SYN packets if i= t
   initiates connections to the client.=E2=80=9D
Or maybe even use normative language here:
=E2=80=9Cthe Transport Convert SHOULD also include the same option in the SY= N if
   it initiates a connection to the client.=E2=80=9D

11) sec 5.2.5: Maybe also be slightly more clear here:
"For incoming connections destined to a Client
   serviced via a Transport Converter, these fields convey the sou= rce
   port number and IP address.=E2=80=9D
Proposed
"For incoming connections destined to a Client
   serviced via a Transport Converter, these fields convey the sou= rce
   port number and IP address of the SYN packet received by the    Transport Converter from the server.=E2=80=9D

12) I have a couple of question about the TCP options field in the Connect T= LV, basically this text in section 5.2.5:
"   Upon reception of a Connect TLV, and absent any policy (e.g., r= ate-
   limit) or resource exhaustion conditions, a Transport Converter=
   attempts to establish a connection to the address and port that= it
   contains.  The Transport Converter MUST use by default the= TCP
   options that correspond to its local policy to establish this    connection.  These are the options that it advertises in t= he
   Supported TCP Extensions TLV.


Bonaventure, et al.        Expires May 7, 2020  &nb= sp;              [Page 22]
Internet-Draft              Convert Proto= col               November 2019


   Upon reception of an extended Connect TLV, and absent any rate l= imit
   policy or resource exhaustion conditions, a Transport Converter= MUST
   attempt to establish a connection to the address and port that i= t
   contains.  It MUST include the options of the 'TCP Options= ' sub-field
   in the SYN sent to the Server in addition to the TCP options th= at it
   would have used according to its local policies.  For the T= CP options
   that are listed without an optional value, the Transport Conver= ter
   MUST generate its own value.  For the TCP options that are= included
   in the 'TCP Options' field with an optional value, it MUST copy= the
   entire option for use in the connection with the destination pe= er.
   This feature is required to support TCP Fast Open.=E2=80=9D
=
First of all the upper paragraph is probably old and should have been remove= d, right?

Then I=E2=80=99m not certain about the new approach with the TCP option fiel= d. If the converter actually ends up in a split connection (with e.g. MPTCP o= n client side but without it on server side), I thought it can only announce= those options in the SYN to the server that are actually implemented in the= converter and it will be able to support later in the connection. So blindl= y copying the options provided by the client doesn=E2=80=99t seem right. Or w= hat do I miss?

I understand the case where you want to use TFO between the client and the c= onvert but can=E2=80=99t use it anymore between the the client and the serve= r then. However you can only use TFO with the second connection you make to a= server. So in the first connection either TFO was used between the convert a= nd the server and the convert could now use it again with the cookie it rece= ived or TFO was used end-to-end in the first connection and it now clear to m= e why the converter is used now. Maybe I=E2=80=99m missing something but I t= hink the drafts would at least need more explanation about the motivation to= have this.

If it=E2=80=99s really only about TFO cookies and we are sure we want to hav= e that feature, maybe an own TLV would be simpler?

13) In sec 5.2.6 do you mean by "extended TCP header=E2=80=9D the TCP option= space? I=E2=80=99m not sure that "extended TCP header=E2=80=9D is a clearly= defined term; as least I=E2=80=99m not 100% sure what you mean=E2=80=A6
=
14) nit in sec 5.2.7:
s/The Cookie TLV (Figure 20 is an optional/The Cookie TLV (Figure 20) is an o= ptional/ -> missing closing bracket

15) Sec 5.2.7:
Question about normative language:
"If the received SYN did not contain a Cookie TLV, and cookie
   validation is required, the Transport Converter should compute a=
   Cookie bound to this Client address and return a Convert messag= e
   containing the fixed header, an Error TLV set to "Missing Cooki= e" and
   the computed Cookie and close the connection.=E2=80=9D
Is this maybe a MAY condition? All of it? Or something like this
"If the received SYN did not contain a Cookie TLV, and cookie
   validation is required, the Transport Converter MAY compute a    Cookie bound to this Client address. It MUST return a Convert m= essage
   containing the fixed header and Error TLV set to "Missing Cooki= e=E2=80=9D and MAY add
   the computed Cookie. After sending the Error TLV is MUST/SHOULD= close/reset   
   the connection.=E2=80=9D
Not fully sure what is the intention here=E2=80=A6

15) sec 5.2.8:
What's the purpose of the client sending an Unsupported Version error? If th= e converter replies with a different version than requested used by the clie= nt, that's simply a fatal error/implementation error and the client can only= reset the connection I think.

More generally if I read this correctly there are only 3 errors that could b= e sent by the client. I guess those errors would be send in the first packet= after the SYN/ACK is received=E2=80=A6? Related to my question above, I thi= nk it would be much easier to only have Convert message in the SYN and SYN/A= CK and no explicit error message from the client. Otherwise more explanation= in the draft would be need how this actually is supposed to work.

16) sec 5.2.8:
"A Client which receives this error code MUST cache the received
      Cookie and include it in subsequent Convert messages se= nt to that
      Transport Converter.=E2=80=9D
This seems to be a slightly weird normative MUST. Sure you have to cache the= cookie in oder to be able to use the converter, however, there may be cases= where you loose the cache and then sending a Connect without the cookie to g= et a new Cookie is a valid option. So you may use SHOULD here or even better= reword it completely...

17) There is an Unsupported TCP Option in section 5.2.8. However, this error= is not mentioned in 5.2.5. In contrast sec 5.2.5 says that the converter MU= ST open a connection and MUST use these options. This is related to my point= 12 above but it was not clear to me that options can be rejected, however, t= his whole part seems to make the protocol really complicated and as I said i= f the only use case is TFO I would prefer to rather have a separate specific= TLV for that case only.

18) I think section 6.7 should still say something about if this option is s= upported or not=E2=80=A6

19) section 7:
"Consider a middlebox that removes the SYN payload.  The Client can
=    detect this problem by looking at the acknowledgment number fie= ld of
   the SYN+ACK returned by the Transport Converter.  The Clie= nt MUST
   stop to use this Transport Converter given the middlebox
   interference.=E2=80=9D
If the converter received a SYN without a Convert message in the payload on t= he respective port, it is supposed to anyway send a SYN/ACK? I would assume i= t would rather send a RESET, no? I think that needs to be further specified.=

20) Sec 7 also says:
=E2=80=9CIf an Error was returned by the Transport Converter, a message to c= lose
   the connection would normally follow from the Converter.=E2=80=9D=
However sec 5.2.8 says:
"Upon reception of an Error TLV, a
   Client MUST close the associated connection.=E2=80=9D
I assume one of these is not correct=E2=80=A6 please clarify which end is su= ppose to do what in case of an error.

21) The text in sec 7 then further says:
"If no such
   message is received, the Client may continue to use this Conver= ter.=E2=80=9D
Isn=E2=80=99t that a bit dangerous? 

22) section 8.5: Why are the authentication mechanism discussed in this sect= ion MPTCP specific? I think the same mechanisms could also be applied to Con= verters supporting other options, no?

23) sec 8.3:
"Means to protect against SYN flooding attacks MUST also be enabled [RFC4987= ].=E2=80=9D
Not sure if the use of MUST is clear here. Which part of RFC4987 does this M= UST relate to? All of it? Maybe a SHOULD or no normative language is more ap= propriate?

24) sec 9.2: Maybe call the new registry the "The TCP Convert Protocol (Conv= ert)
   Parameters=E2=80=9D (TCP added)=E2=80=A6?

25) sec 9.2.2:
"The values in the range 192-255 can be assigned for Private Use.=E2=80=9D IANA does not assigned any value for Private use, they can just be used, so t= his should be
"The values in the range 192-255 are reserved for Private Use.=E2=80=9D
if that is what you want?

26) also on section 9.2.X: "Specification Required" includes having an exper= t review and RFC8126 says:
"As with Expert Review (Section 4.5), clear guidance to the designated
   expert should be provided when defining the registry, and thoro= ugh
   understanding of Section 5 is important.=E2=80=9D
So please provide further guidance about what the expert is supported to eva= luate.

27) Not sure if the following references need to be normative as there no no= rmative requirement connect to them but only an optional case is discussed: R= FC4279, RFC7250 =E2=80=A6?

However, RFC7323, RFC2018, RFC6978, RFC6978, RFC2827, RFC6181 should probabl= y be normative references=E2=80=A6?

28) The term =E2=80=9Cexperimental option=E2=80=9D is used with two differen= t meaning in the intro of section 6 (options that are defined in an exp RFC)= and in section 6.9 (options with kind 254 and 255). Please clarify this at b= oth places.














= --Apple-Mail-F4F3B8F7-2848-430B-8E00-6E9CD477B5AF-- From nobody Mon Jan 27 06:29:25 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EEFF12006D; Mon, 27 Jan 2020 06:29:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.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 OKKcfUAaF-E5; Mon, 27 Jan 2020 06:29:18 -0800 (PST) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AB9E12004E; Mon, 27 Jan 2020 06:29:17 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id CC38C25A14; Mon, 27 Jan 2020 15:29:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1580135355; bh=/VkE6r7KvSYIR7xvEhW+iLIyuZ8INzlOlrhFezSh8Gk=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=KDOoT20WU9KU57e+IglMmlmeFH1OLO6QLyM5U7MUmT/g93Im8WbwvRSGLBaqUhmWn CSxVzRW20vJXoAKoyMmE8H9SZfPqz/5O4+xgxW2OGQGmmzoee8bAkSkvziONaT81Qn Nm2S8inJ859q/iXXVifxJzZ8EAyKTL0FvC/BS3Nk= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqKrUNPapbMk; Mon, 27 Jan 2020 15:29:13 +0100 (CET) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Mon, 27 Jan 2020 15:29:13 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.158]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Mon, 27 Jan 2020 15:29:12 +0100 From: "Scharf, Michael" To: =?utf-8?B?IlwiIE1pcmphIEvDvGhsZXdpbmQgKElFVEYpIFwiIg==?= , Olivier Bonaventure CC: "draft-ietf-tcpm-converters.all@ietf.org" , tcpm IETF list Thread-Topic: AD review of draft-ietf-tcpm-converters-14 Thread-Index: AQHVxzOtTdQ3on66zESLLEZ8ge6N86f7OlyAgAAVJQCAA15hGA== Date: Mon, 27 Jan 2020 14:29:12 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D8F5326@rznt8114.rznt.rzdir.fht-esslingen.de> References: , In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D8F5326rznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] AD review of draft-ietf-tcpm-converters-14 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2020 14:29:22 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D8F5326rznt8114rzntrzd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5kZWVkDQoNCkdpdmVuIHRoYXQgVEZPIHN1cHBvcnQgaGFzIGJlZW4gZGlzY3Vzc2VkIGluIHRo ZSB3b3JraW5nIGdyb3VwIHF1aXRlIGEgYml0LCBzdWJzdGFudGlhbCB0ZWNobmljYWwgY2hhbmdl cyBpbiB0aGF0IHNwYWNlIHdvdWxkIElNSE8gcmVxdWlyZSBhbm90aGVyIFdHTEMuIE9mIGNvdXJz ZSwgdGhpcyBjb3VsZCBiZSBkb25lIG9uIGZhc3QgdHJhY2ssIGkuZS4sIGlmIHRoZSBjb21tdW5p dHkgYWdyZWVzLCBpdCB3b3VsZCBub3QgcmVzdWx0IGluIGEgbGFyZ2UgZGVsYXkuDQoNCk1pY2hh ZWwNCg0KDQpQUzogU29tZSBleHBlcmltZW50YWwgVENQIHNwZWNzIChvciBpbmZvcm1hdGlvbmFs IGRvY3VtZW50cykgcHVibGlzaGVkIGJ5IFRDUE0gYXJlIHF1aXRlIHdpZGVseSBkZXBsb3llZC4N Cg0KDQpWb246IE1pcmphIEvDvGhsZXdpbmQgKElFVEYpIDxtYWlsdG86aWV0ZkBrdWVobGV3aW5k Lm5ldD4NCkdlc2VuZGV0OiBTYW1zdGFnLCAyNS4gSmFudWFyIDIwMjAgMTM6MDINCkFuOiBPbGl2 aWVyIEJvbmF2ZW50dXJlPG1haWx0bzpvbGl2aWVyLmJvbmF2ZW50dXJlQHRlc3NhcmVzLm5ldD4N CkNjOiBkcmFmdC1pZXRmLXRjcG0tY29udmVydGVycy5hbGxAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0 LWlldGYtdGNwbS1jb252ZXJ0ZXJzLmFsbEBpZXRmLm9yZz47IHRjcG0gSUVURiBsaXN0PG1haWx0 bzp0Y3BtQGlldGYub3JnPg0KQmV0cmVmZjogUmU6IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLXRj cG0tY29udmVydGVycy0xNA0KDQpIaSBPbGl2aWVyLA0KDQpTb3VuZHMgbGlrZSBhIGdvb2QgcGxh biB0byBtZS4gTGV04oCZcyBzZWUgaG93IHRoZXNlIGNoYW5nZXMgd2lsbCBhY3R1YWxseSBsb29r IGxpa2UgYnV0IGl0IG1pZ2h0IGJlIHRoYXQgdGhlIGNoYWlycyBzaG91bGQgY29uc2lkZXIgaW4g dGhpcyBjYXNlIHRvIHJ1biBhbm90aGVyIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsLg0KDQpNaXJq YQ0KDQoNCkFtIDI1LjAxLjIwMjAgdW0gMTE6NDcgc2NocmllYiBPbGl2aWVyIEJvbmF2ZW50dXJl IDxvbGl2aWVyLmJvbmF2ZW50dXJlQHRlc3NhcmVzLm5ldD46DQoNCu+7vw0KRGVhciBNaXJqYSwN Cg0KVGhhbmtzIGFnYWluIGZvciB0aGUgZGV0YWlsZWQgY29tbWVudHMuIFdlIGFyZSBjdXJyZW50 bHkgZGlnZXN0aW5nIHRoZW0gYW5kIHByZXBhcmUgYW4gdXBkYXRlZCB2ZXJzaW9uIG9mIHRoZSBk cmFmdC4gU29tZSBvZiB5b3VyIGNvbW1lbnRzIGhhdmUgaW5kaWNhdGVkIHRoYXQgc29tZSBwYXJ0 cyB3ZXJlIHVuY2xlYXIsIG5vdGFibHkgZm9yIHRoZSBzdXBwb3J0IG9mIHRoZSBURk8gb3B0aW9u LiBXZSBwcm9wb3NlIHRvIGFuc3dlciB0aGVtIGJ5IHNpbXBsaWZ5aW5nIHRoZSBwcm90b2NvbCBh IGJpdCBhbmQgbW92ZSB0aGUgcGFydHMgdGhhdCBhcmUgcmVxdWlyZWQgdG8gc3VwcG9ydCBURk8g YW5kIG90aGVyIGV4cGVyaW1lbnRhbCBvcHRpb25zIGluIGEgZGlmZmVyZW50IGRyYWZ0LiBUaGUg d29ya2luZyBncm91cCBkb2N1bWVudCB3aWxsIHRoZW4gZm9jdXMgb24gdGhlIHN0YW5kYXJkIFRD UCBvcHRpb25zIChpbmNsdWRpbmcgTVBUQ1AgZ2l2ZW4gdGhhdCB2ZXJzaW9uIDEgaXMgZmluYWwp IGFuZCB0aGUgb3RoZXIgZHJhZnQgd2lsbCBwcm9wb3NlIGV4dGVuc2lvbnMgdG8gdGhpcyBiYXNl IHByb3RvY29sIHRvIHN1cHBvcnQgVEZPIGFuZCBvdGhlciBleHBlcmltZW50YWwgb3B0aW9ucy4N Cg0KVGhpcyBzaG91bGQgbWFrZSB0aGUgdGV4dCBlYXNpZXIgdG8gcmVhZCBhbmQgdGhlIGJhc2Ug cHJvdG9jb2wgc2ltcGxlciB0byBpbXBsZW1lbnQNCg0KQmVzdCByZWdhcmRzLA0KDQpPbGl2aWVy LCBNZWQgYW5kIEJlbmphbWluDQoNCk9uIFRodSwgSmFuIDksIDIwMjAgYXQgMTA6MjggUE0gTWly amEgS3VlaGxld2luZCA8aWV0ZkBrdWVobGV3aW5kLm5ldDxtYWlsdG86aWV0ZkBrdWVobGV3aW5k Lm5ldD4+IHdyb3RlOg0KSGkgYXV0aG9ycywNCg0KSSBmaW5hbGx5IGRpZCBteSBBRCByZXZpZXcg Zm9yIGRyYWZ0LWlldGYtdGNwbS1jb252ZXJ0ZXJzLTE0IChhY3R1YWxseSBJJ20gc3RpbGwgbm90 IGZ1bGx5IGZpbmlzaGVkIHdpdGggdGhlIHJldmlldyBvZiB0aGUgYXBwZW5kaXggYnV0IHdvdWxk IGxpa2UgdG8gc2VuZCBvdXQgdGhpcyBmaXJzdCBiYXRjaCBvZiBxdWVzdGlvbnMgbm93KS4NCg0K QXMgeW91IGNhbiBzZWUgYmVsb3csIEkgaGF2ZSBhIHdob2xlIGJ1bmNoIG9mIHF1ZXN0aW9ucy9j b21tZW50cy4gU29tZSBvZiB0aGVzZSBtYXkgb25seSBiZSBlZGl0b3JpYWwgaW4gdGhlIGVuZCBi dXQgSSB3b3VsZCBsaWtlIHRvIG1ha2Ugc3VyZSB0aGF0IEkgdW5kZXJzdGFuZCBhbGwgdGhlIHRl Y2huaWNhbCBwYXJ0cyBjb3JyZWN0bHkgYmVmb3JlIHdlIG1vdmUgb24gd2l0aCB0aGUgcHJvY2Vz c2luZy4NCg0KSSB0aGluayB0aGVyZSBhcmUgYmFzaWNhbGx5IHR3byBtYWluIHRlY2huaWNhbCBw b2ludHMgSSB3b3VsZCBsaWtlIHRvIGdldCBzb21lIGNsYXJpZmljYXRpb24gb24sIGJvdGggcHJv YmFibHkgcmVsYXRlZCB0byB0aGluZ3MgdGhhdCBoYXZlIGJlZW4gaW50cm9kdWNlZCBsYXRlciBp biB0aGUgbGlmZSB0aW1lIG9mIHRoZSBkb2MgYnV0IG1heWJlIG5vdCBjb25zZXF1ZW50bHkgYmVl biBjaGFuZ2VkIHRocm91Z2hvdXQgdGhlIHdob2xlIGRvYy4NCg0KT25lIGlzIGJlc2lhY2xseSBw b2ludCA4IGJlbG93IGJ1dCB0aGVyZSBhcmUgc29tZSByZWxhdGVkIG90aGVyIHBvaW50cyBiZWxv dzogSXQgaXMgbm90IGZ1bGx5IGNsZWFyIHdoaWNoIHBhY2tldHMgY2FuIGNhcnJ5IENvbnZlcnQg bWVzc2FnZXMuIEkgdGhpbmsgaW5pdGlhbGx5IENvbnZlcnQgbWVzc2FnZXMgd2VyZSBvbmx5IHN1 cHBvc2VkIHRvIGJlIGluIHRoZSBTWU4gYW5kIFNZTi9BQ0suIEJ1dCB0aGVuIGxhdGVyIHlvdSBl bmFibGVkIGl0IGFsc28gZm9yIG90aGVyIHBhY2tldHMsIGhvd2V2ZXIsIGl0IHNlZW0gdGhlIG9u bHkgcmVhbCBjYXNlIHRoYXQgbmVlZHMgdGhpcyBpcyB3aGVuIGFuIGVycm9yIG1lc3NhZ2UgaXMg c2VuZCBieSB0aGUgY2xpZW50LiBCdXQgc2VuZGluZyBDb252ZXJ0IG1lc3NhZ2VzIGluIG90aGVy IHBhY2tldCB0aGFuIHRoZSBTWU4gYW5kIHRoZSBTWU4vQUNLIHNlZW1zIG1vcmUgY29tcGxpY2F0 ZWQgYmVjYXVzZSBhbGwgVENQIHBheWxvYWQgZGF0YSBpcyB0cmFuc21pdHRlZCByZWxpYWJsZSBh bmQgbXVzdCBiZSBhY2snZWQgYW5kIGV2aWwuIHJldHJhbnNtaXR0ZWQuIE1heWJlIGl04oCZcyBv a2F5IGlmIG9ubHkgYW4gZXJyb3IgbWVzc2FnZSBpcyBzZW5kIGFuZCBhIHJlc2V0IHJpZ2h0IGFm dGVyIChzbyBubyByZXRyYW5zbWlzc2lvbiksIGhvd2V2ZXIsIHRoaXMgaXMgbm90IHNwZWNpZmll ZCwgYW5kIEkgd29uZGVyIGlmIHRoZSBjb21wbGV4aXR5IGlzIHJlYWxseSBuZWVkZWQgd29ydGgg dGhlIGJlbmVmaXQgb2YgYmVpbmcgYWJsZSB0byBsb2cgbW9yZSBjb25jcmV0ZSBlcnJvcnMgaW4g dGhlIGNvbnZlcnRlci4NCg0KVGhlIG90aGVyIHBvaW50IGlzIGJhc2ljYWxseSBwb2ludCAxMiBi ZWxvdyBhYm91dCB0aGUgVENQIG9wdGlvbiBmaWVsZCBpbiB0aGUgQ29ubmVjdCBUTFYgKGFsc28g cmVsYXRlZCB0byBwb2ludCAxNyBiZWxvdykuIFRoaXMgaXMgbm90IHdlbGwgZW5vdWdoIHNwZWNp ZmllZCBhbmQgc2VlbSBhbHNvIHF1aXRlIGNvbXBsZXggYXMgYSBnZW5lcmljIG1lY2hhbmlzbS4g SSB3b3VsZCB0aGluayB0aGUgY29udmVydGVyIHNob3VsZCB1c3VhbGx5IHRyeSB0byB1c2UgdGhl IHNhbWUgb3B0aW9uIGFzIHRoZSBjbGllbnQgZGlkIHNlbmQgaW4gaGlzIFNZTiB0byB0aGUgY29u dmVydGVyLCBpZiBzdXBwb3J0ZWQgYnkgdGhlIGNvbnZlcnRlciBUQ1AgaW1wbGVtZW50YXRpb24u IFRoZSBURk8gY29va2llIG1pZ2h0IGJlIGEgc3BlY2lhbCBjYXNlLiBJ4oCZbSBub3Qgc3VyZSBp ZiB0aGF0IG5lZWRzIHRvIGJlIGdlbmVyYWxpc2VkIG9yIGlmIGhhdmluZyBhIHNlcGFyYXRlIFRM ViBmb3IgdGhhdCBvbmUgY2FzZSBtaWdodCBiZSBzaW1wbGVyLiBQbGVhc2UgYWxzbyByZWNvbnNp ZGVyIHRoaXMgYnV0IGluIGFueSBjYXNlIGl0IG5lZWRzIG1vcmUgZXhwbGFuYXRpb24gaW4gdGhl IHNwZWMuDQoNClBsZWFzZSBzZWUgYWxsIG15IHF1ZXN0aW9ucy9jb21tZW50cyBiZWxvdy4gSSBt YXkgc2VuZCBhbm90aGVyIG1lc3NhZ2UsIHdoZW4gSSBoYXZlIHJldmlld2VkIHRoZSBhcHBlbmRp eCB0b21vcnJvdyAoaG9wZWZ1bGx5IHdpdGggbm9uZSBvciBvbmx5IGZldyBhZGRpdGlvbmFsIGNv bW1lbnRzKS4NCg0KVGhhbmtzIQ0KTWlyamENCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQox KSBJIHdhcyBpbml0aWFsbHkgYSBiaXQgY29uZnVzZWQgYWJvdXQgdGhlIHNldHVwIGluIEZpZ3Vy ZSA2IGFuZCByZXNwZWN0aXZlbHkgdGhlIHBhcmFncmFwaCBqdXN0IGJlZm9yZSB0aGF0IGZpZ3Vy ZSBpbiBzZWMgMy4yOiBJdCB3YXNuJ3QgY2xlYXIgdG8gbWUgaG93IHRoZSBzZXJ2ZXIgbWlnaHQg a25vdyB0aGUgY29udmVydGVyIGFkZHJlc3MgKG9yIGlmIHRoZSBwcm94eSBtYXliZSBoYXMgdG8g YmUgb24gcGF0aCkuIEkgYXNzdW1lIHRoZSDigJx1c2UgY2FzZeKAnSBpcyB0aGF0IHRoZXJlIHdh cyBhIHByZXZpb3VzIGNvbm5lY3Rpb24gdXNpbmcgdGhlIGNvbnZlcnRlciBhbmQgbm93IHRoZSBz ZXJ2ZXIgdHJpZXMgdG8gcmVjb25uZWN0IGJ1dCBvZiBjb3Vyc2Ugb25seSBrbm93cyB0aGUgY29u dmVydGVyIGFkZHJlc3MsIG9yIHNvbWV0aGluZz8gTWF5YmUgeW91IGNvdWxkIGFkZCBzbGlnaHRs eSBtb3JlIHRleHQgaGVyZS4gSSBhbHNvIEkgd291bGQgcmVjb21tZW5kIHRvIGV4cGxpY2l0bHkg bWVudGlvbiB0aGF0IHRoaXMgc2V0dXAgc3RpbGwgaGFzIHRvIGJlIGV4cGxpY2l0bHkgY29uZmln dXJlZCBieSB0aGUgY2xpZW50IGJ1dCB1c2luZyBhbiBvdXQgb2YgYmFuZCBwcm90b2NvbCAod2hp Y2ggaXMgb3V0IG9yIHNjb3BlIGZvciB0aGlzIHNwZWMpLiBGdXJ0aGVyIEkgdGhpbmsgaXQgd291 bGQgYmUgZ29vZCB0byBtZW50aW9uIGhlcmUgYWxyZWFkeSB0aGF0IHRoZSBjb252ZXJ0ZXIgYWxz byBpbnNlcnRzIHRoZSByZXNwZWN0aXZlIFRDUCBvcHRpb24gaW4gdGhlIFNZTiB0byB0aGUgY2xp ZW50IChpZiBwb3NzaWJsZSBkdWUgdG8gc3BhY2UgbGltaXRzKSBhbmQgcmVmZXIgdG8gc2VjdGlv biA0LjIgZm9yIGEgY29uY3JldGUgZXhhbXBsZS4NCg0KQnR3LiBzaG91bGRuJ3QgdGhlcmUgYmUg c29tZSBkaXNjdXNzaW9uIGFib3V0IE1UVSBpc3N1ZSBpZiBvcHRpb25zIGFyZSBhZGRlZCBieSB0 aGUgY29udmVydGVyPw0KDQoyKSBUaGUgZm9sbG93aW5nIHBhcmFncmFwaCBpbiBzZWN0aW9uIDMu Mi4gc2VlbXMgdG8gc3BlY2lmeSBwcm90b2NvbCByZXF1aXJlbWVudHMgYnV0IGRvbuKAmXQgdXNl IG5vcm1hdGl2ZSBsYW5ndWFnZToNCg0KIklmIHRoZSBkb3duc3RyZWFtIChvciB1cHN0cmVhbSkg Y29ubmVjdGlvbiBmYWlscyBmb3Igc29tZSByZWFzb24NCiAgIChleGNlc3NpdmUgcmV0cmFuc21p c3Npb25zLCByZWNlcHRpb24gb2YgYW4gUlNUIHNlZ21lbnQsIGV0Yy4pLCB0aGVuDQogICB0aGUg Q29udmVydGVyIHNob3VsZCBmb3JjZSB0aGUgdGVhci1kb3duIG9mIHRoZSB1cHN0cmVhbSAob3IN CiAgIGRvd25zdHJlYW0pIGNvbm5lY3Rpb24uDQoNCiAgIFRoZSBzYW1lIHJlYXNvbmluZyBhcHBs aWVzIHdoZW4gdGhlIHVwc3RyZWFtIGNvbm5lY3Rpb24gZW5kcy4gIEluDQogICB0aGlzIGNhc2Us IHRoZSBDb252ZXJ0ZXIgc2hvdWxkIGFsc28gdGVybWluYXRlIHRoZSBkb3duc3RyZWFtDQogICBj b25uZWN0aW9uIGJ5IHVzaW5nIEZJTiBzZWdtZW50cy4gIElmIHRoZSBkb3duc3RyZWFtIGNvbm5l Y3Rpb24NCiAgIHRlcm1pbmF0ZXMgd2l0aCB0aGUgZXhjaGFuZ2Ugb2YgRklOIHNlZ21lbnRzLCB0 aGUgQ29udmVydGVyIHNob3VsZA0KICAgaW5pdGlhdGUgYSBncmFjZWZ1bCB0ZXJtaW5hdGlvbiBv ZiB0aGUgdXBzdHJlYW0gY29ubmVjdGlvbi7igJ0NCg0KSSByZWNvbW1lbmQgdG8gdXNlIG5vcm1h dGl2ZW4gbGFuZ3VhZ2UgaGVyZSAoU0hPVUxEIGluc3RlYWQgb2Ygc2hvdWxkOyBvciBtYXliZSBl dmVuIE1VU1Q/KS4gSG93ZXZlciwgYXMgdGhpcyB0ZXh0IGlzIHBhcnQgb2YgYSBraW5kIG9mIG92 ZXJ2aWV3IHNlY3Rpb24sIGl0IGRvZXNu4oCZdCBzZWVtIHRvIGJlIGEgcmVhbGx5IGdvb2QgZml0 IHRvIHVzZSBub3JtYXRpdmUgbGFuZ3VhZ2UgaW4gdGhhdCBzZWN0aW9uLiBTbyBtYXliZSB0aGUg d2hvbGUgZGlzY3Vzc2lvbiBhYm91dCB1c2Ugb2YgVEZPIChvciBub3QpIHNob3VsZCBiZSBtb3Zl ZCB0byBhbiBvd24gc2VjdGlvbj8NCg0KDQozKSBKdXN0IHRvIGRvdWJsZS1jaGVjaywgSSdtIHdv bmRlcmluZyBhIGJpdCBhYm91dCB0aGlzIHBocmFzaW5nIGluIHNlYyAzLjMuMToNCiJJZiBubyBl bnRyeSBpcyBmb3VuZCwgdGhlIFRyYW5zcG9ydCBDb252ZXJ0ZXIgTVVTVCBzaWxlbnRseQ0KICAg aWdub3JlIHRoZSBwYWNrZXQu4oCdDQpUaGF0IG1lYW5zIHRoZSBjb252ZXJ0ZXIgd2lsbCBkcm9w IHRoZSBwYWNrZXQgKHdpdGggbm8gb3RoZXIgYWN0aW9uKSwgcmlnaHQ/IFdoeSBkbyB5b3UgdXNl IHRlcm0gaWdub3JlIGhlcmUgKGluc3RlYWQgb2YgZHJvcCBvciBkaXNjYXJkKT8gT3IgZG9lcyB0 aGlzIGhhdmUgYW55IG90aGVyIGltcGxpY2F0aW9uPw0KTm90ZSB0aGF0IHRoaXMgdGVybSBpcyB1 c2VkIHNldmVyYWwgdGltZXMgaW4gdGhlIGRvYy4NCg0KNCkgQWxzbyBhIHF1aWNrIHF1ZXN0aW9u IGFib3V0IHRoaXMgaW4gc2VjIDMuMy4xOg0KIkEgVHJhbnNwb3J0IENvbnZlcnRlciBtYXkgb3Bl cmF0ZSBpbiBhZGRyZXNzIHByZXNlcnZhdGlvbiBtb2RlICh0aGF0DQogICBpcywgdGhlIENvbnZl cnRlciBkb2VzIG5vdCByZXdyaXRlIHRoZSBzb3VyY2UgSVAgYWRkcmVzcyAoaS5lLiwNCiAgIEM9 PVQpKSBvciBhZGRyZXNzIHNoYXJpbmcgbW9kZSAodGhhdCBpcywgYW4gYWRkcmVzcyBwb29sIGlz IHNoYXJlZA0KICAgYW1vbmcgYWxsIENsaWVudHMgc2VydmljZWQgYnkgdGhlIENvbnZlcnRlciAo aS5lLiwgQyE9VCkpOyByZWZlciB0bw0KICAgQXBwZW5kaXggRCBmb3IgbW9yZSBkZXRhaWxzLiAg V2hpY2ggYmVoYXZpb3IgdG8gdXNlIGJ5IGEgVHJhbnNwb3J0DQogICBDb252ZXJ0ZXIgaXMgZGVw bG95bWVudC1zcGVjaWZpYy7igJ0NCkkgZ3Vlc3MgcHJlc2VydmF0aW9uIG1vZGUgY2FuIG9ubHkg YmUgdXNlZCBpZiB0aGUgY29udmVydGVyIGlzIG9uIHBhdGguIEkgdGhpbmsgdGhhdCBzaG91bGQg YmUgZXhwbGljaXRseSBub3RlZCBoZXJlLg0KDQo1KSBTZWMgMy4zLjI6IFRvIGJlIGhvbmVzdCBJ 4oCZbSBub3Qgc3VyZSBJIGZ1bGx5IHVuZGVyc3RhbmQgdGhpcyBzZWN0aW9uLCBlc3BlY2lhbGx5 IHRoaXMgc2VudGVuY2U6DQoiVXBvbiByZWNlaXB0IG9mIGEgc2Vjb25kYXJ5IHN1YmZsb3cgYnkg dGhlIFRyYW5zcG9ydCBDb252ZXJ0ZXIgZnJvbSBhDQogICBDbGllbnQsIHRoZSBDb252ZXJ0ZXIg Zm9sbG93cyB0aGUgc2FtZSBiZWhhdmlvciBzcGVjaWZpZWQgaW4NCiAgIFNlY3Rpb24gMy4zLjEg Zm9yIHByb2Nlc3NpbmcgTm9uLVNZTnMu4oCdDQpEbyB5b3UgbWVhbiBieSAicmVjZWlwdCBvZiBh IHNlY29uZGFyeSBzdWJmbG934oCdIHRoZSBTWU4gb24gdGhhdCBzdWJmbG93IG9yIG90aGVyIGRh dGE/IEZvciB0aGUgU1lOIEkgd291bGQgZXhwZWN0IHRoYXQgdGhlcmUgaXMgbm8gcGF5bG9hZCBk YXRhIGFuZCB0aGVyZWZvcmUgbm90aGluZyB0byBwcm94eS4gRm9yIG90aGVyIHN1YmZsb3cgcGFj a2V0cywgSSBndWVzcyB5b3UgbmVlZCB0byByZW9yZGVyIGZpcnN0LCBzbyBwcm9iYWJseSBpdCB3 b3VsZCBiZSBnb29kIHRvIG1lbnRpb24gdGhhdOKApj8gTWF5YmUgaXTigJlzIGp1c3QgbWUgbWlz dW5kZXJzdGFuZGluZyBzb21ldGhpbmcgYnV0IEkgYmVsaWV2ZSBtb3JlIGV4cGxhbmF0aW9uIGlz IG5lZWRlZCBoZXJlLg0KDQo2KSBDYW4geW91IG1heWJlIGFkZCBzb21lIG1vcmUgdGV4dCAoaW4g c2VjdGlvbiA1IG1heWJlKSB3aHkgYSBzZXBhcmF0ZSBwb3J0IG51bWJlciBpcyB1c2VkL25lZWRl ZD8gQXMgdGhlIGNsaWVudCBoYXMgdG8gYmUgZXhwbGljaXRseSBjb25maWd1cmVkIGl0IGNvdWxk IGVhc2lseSBiZSBjb25maWd1cmVkIHdpdGggYW4gYWRkcmVzcyBhbmQgcG9ydCBudW1iZXIuIElz IHRoaXMgdG8gYXZvaWQgY29sbGlzaW9ucyB3aXRoIG90aGVyIHByb3RvY29scz8gV2hhdCB3b3Vs ZCBiZSB0aGUgc2NlbmFyaW8gaGVyZT8NCg0KNykgU2VjIDUuMToNCiJUaGUgVW5hc3NpZ25lZCBm aWVsZCBNVVNUIGJlIHNldCB0byB6ZXJvIGluIHRoaXMgdmVyc2lvbiBvZiB0aGUNCiAgIHByb3Rv Y29sLiAgVGhlc2UgYml0cyBhcmUgYXZhaWxhYmxlIGZvciBmdXR1cmUgdXNlIFtSRkM4MTI2XS7i gJ0NCldoeSBpcyB0aGVyZSBhIHJlZmVyZW5jZSB0byBSRkM4MTI2IGhlcmU/DQoNCjgpIEFsc28g c2VjIDUuMSBidXQgcHJvYmFibHkgZWRpdG9yaWFsOg0KIkRhdGEgYWRkZWQgYnkgdGhlIENvbnZl cnQgUHJvdG9jb2wgdG8gdGhlIFRDUCBieXRlc3RyZWFtIGlzDQogICB1bmFtYmlndW91c2x5IGRp c3Rpbmd1aXNoZWQgZnJvbSBwYXlsb2FkIGRhdGEgYnkgdGhlIFRvdGFsIExlbmd0aA0KICAgZmll bGQgaW4gdGhlIENvbnZlcnQgbWVzc2FnZXMu4oCdDQpJIGJlbGlldmUgd2hhdCB5b3Ugd2FudCB0 byBzYXkgaGVyZSBpcyB0aGF0IHRoZSB0b3RhbCBsZW5ndGggaXMgdXNlZCB0byBmaWd1cmUgb3V0 IHdoZXJlIHBvdGVudGlhbCBvdGhlciBwYXlsb2FkIGRhdGEgbWlnaHQgc3RhcnQuIEhvd2V2ZXIs IHdoYXQgSSB3b3VsZCB1bmRlcnN0YW5kIGZyb20gdGhpcyBzZW50ZW5jZSBpcyB0aGF0IHRoZSB0 b3RhbCBsZW5ndGggZmllbGQgY2FuIGJlIHVzZWQgdG8gZGlzdGluZ3Vpc2ggU1lOcyB0aGF0IGNh cnJ5IHRoZSBDb252ZXJ0IHByb3RvY29sIGZyb20gU1lOcyB0aGF0IG1heSBjYXJyeSBvdGhlciBw YXlsb2FkIG9ubHksIHdoaWNoIEkgZG9u4oCZdCB0aGluayBpcyB0aGUgY2FzZS4NCg0KOCkgSSBm aXJzdCBoYXZlIGEgbW9yZSBnZW5lcmFsIHF1ZXN0aW9uIGFib3V0IHRoZSBmdW5jdGlvbiBvZiB0 aGUgcHJvdG9jb2wuIFNlYyA1IHNheXM6DQoiQ29udmVydCBtZXNzYWdlcyBtYXkgYXBwZWFyIG9u bHkgaW4gYSBTWU4sIFNZTitBQ0ssIG9yIEFDSy7igJ0NCknigJltIG5vdCBzdXJlIEkgdW5kZXJz dGFuZCB0aGUgQUNLIGNhc2UgaGVyZSBiZWNhdXNlIGlmIHlvdSBhZGQgYSBDT05WRVJUIG1lc3Nh Z2UgdG8gYSBUQ1AgcGFja2V0IHRoYXQgbWVhbnMgeW91IGFkZCBwYXlsb2FkIGRhdGEuIEkgd2Fz IHJlYWRpbmcgdGhpcyBhcyBwdXJlIEFDSyBidXQgdGhhdCBjYW4ndCBiZSB0aGUgY2FzZS4gU28g ZG8geW91IG1lYW4gYnkgdGhpcyB5b3UgY2FuIG9ubHkgc2VuZCBuZXcgZGF0YSBpZiB5b3VyIHBy ZXZpb3VzIGRhdGEgd2FzIEFDSyBvciBzb21ldGhpbmcgZWxzZeKApj8NCkhvd2V2ZXIsIEkgYmVs aWV2ZSB0aGVyZSBpcyB1c3VhbGx5IGp1c3Qgb25lIG1lc3NhZ2UgZnJvbSB0aGUgY2xpZW50IGlu IHRoZSBTWU4gYW5kIHRoZSBvbmUgbWVzc2FnZSBmcm9tIHRoZSBjb252ZXJ0ZXIgaW4gdGhlIFNZ Ti9BQ0ssIGFuZCB0aGVuIHRoZSBjb25uZWN0aW9uIGlzIGVpdGhlciBjbG9zZWQgb3Igc3dpdGNo ZWQgdG8gdGhlIGFjdHVhbCBwYXlsb2FkIHRyYW5zbWlzc2lvbi4gU28gSSB3YXMgYXNzdW1pbmcg dGhhdCdzIHRoZSBvbmx5IGNvbW11bmljYXRpb24gcGF0dGVybiB5b3UgY2FuIGhhdmUuIE9yIGlz IHRoZSBpZGVhIHRoYXQgbXVsdGlwbGUgY2xpZW50LWNvbnZlcnRlciBleGNoYW5nZXMgY2FuIGJl IGRvbmUgb24gdGhlIHNhbWUgVENQIGNvbm5lY3Rpb24gYWxzbyBhZnRlciB0aGUgVENQIGhhbmRz aGFrZSBhbmQgdGhlbiBhbnkgdGltZSBpbiB0aGUgY29ubmVjdGlvbiB5b3Ugd291bGQgYmUgYWJs ZSB0byBzd2l0Y2ggb3ZlciB0byBzZW5kaW5nIG90aGVyIHBheWxvYWQgZGF0YT8gSSB0aGluayB0 aGlzIG5lZWQgZnVydGhlciBjbGFyaWZpY2F0aW9uIGluIHRoZSBkcmFmdC4NCg0KTm90ZSB0aGF0 IHNlY3Rpb24gNyBhbHNvIHNheToNCiJJbiB0aGlzIHNlY3Rpb24sIHdlIG9ubHkgZGlzY3Vzcw0K ICAgdGhlIG1pZGRsZWJveGVzIHRoYXQgbW9kaWZ5IFNZTiBhbmQgU1lOK0FDSyBwYWNrZXRzIHNp bmNlIHRoZSBDb252ZXJ0DQogICBQcm90b2NvbCBwbGFjZXMgaXRzIG1lc3NhZ2VzIGluIHN1Y2gg cGFja2V0cy7igJ0NCg0KOSkgVGhpcyBwb2ludCBpcyBwcm9iYWJseSByZWxhdGVkIHRvIHRoZSBw cmV2aW91cyBwb2ludC4gSW4gc2VjdGlvbiA1LjEgeW91IHNheSB0aGF0IHRoZSBjb25uZWN0aW9u IE1VU1QgYmUgcmVzZXQgKGlmIGxlbmd0aCBpcyB6ZXJvKSBidXQgaW4gYWxsIG90aGVyIHNlY3Rp b25zIHlvdSBzYXkgdGhlIGNvbm5lY3Rpb24gbXVzdCBiZSBjbG9zZWQgaWYgdGhlcmUgaXMgYSBw cm9ibGVtLiBBc3N1bWluZyB0aGUgQ29udmVydCBwcm90b2NvbCB3aWxsIG9ubHkgYmUgdXNlZCBp biBTWU4gYW5kIFNZTi9BQ0ssIHJlc2V0IGlzIHByb2JhYmx5IG1vcmUgYXBwcm9wcmlhdGUuIElm IGl0IGNhbiBiZSB1c2VkIGFsc28gaW4gbGF0ZXIgcGFja2V0cyB5b3UgcHJvYmFibHkgaGF2ZSB0 byBzYXkgc29tZXRoaW5nIGxpa2Ug4oCcY2xvc2Ugb3IgcmVzZXQgaWYgdGhlIGhhbmRzaGFrZSBp cyBub3QgY29tcGxldGVk4oCd4oCmPw0KDQpFLmcuIHNlZSBzZWMgNS4yLjE6DQoiSWYgdHdvIG9y IG1vcmUNCiAgIGluc3RhbmNlcyBvZiB0aGUgc2FtZSBUTFYgYXJlIGV4Y2hhbmdlZCBvdmVyIGEg Q29udmVydCBjb25uZWN0aW9uLA0KICAgdGhlIGFzc29jaWF0ZWQgVENQIGNvbm5lY3Rpb25zIE1V U1QgYmUgY2xvc2VkLuKAnQ0KSXMgdGhhdCBjbG9zZSBvciByZXNldD8NCg0KQWxzbyByZWxhdGVk Og0KVGhlIG5leHQgc2VjdGlvbiAoNS4yLjIpIHNheXM6DQoiVHlwZSAweDAgaXMgYSByZXNlcnZl ZCB2YWx1ZWQuICBJbXBsZW1lbnRhdGlvbnMgTVVTVCBkaXNjYXJkIG1lc3NhZ2VzDQogICB3aXRo IHN1Y2ggVExWLuKAnQ0KKE5pdCBzL3ZhbHVlZC92YWx1ZS8pDQpBbmQgaW4gc2VjIDUuMi41Og0K IkNvbm5lY3QgVExWcyB3aXRjaCBzdWNoIG1lc3NhZ2VzIE1VU1QgYmUgZGlzY2FyZGVkIGJ5IHRo ZSBUcmFuc3BvcnQNCiAgIENvbnZlcnRlci4iDQpJIGd1ZXNzIGV2ZXJ5IHRpbWUgeW91IHNheSBp biB0aGUgZG9jdW1lbnQgdGhhdCBhIG1lc3NhZ2UgaXMgZGlzY2FyZGVkIHRoYXQgd291bGQgIGFs c28gbGVhZCBzb21laG93IHRvIGNsb3NpbmcgdGhlIGNvbm5lY3Rpb24gbW9zdCBsaWtlbHkgYnkg dG8gc2VuZGluZyBhIHJlc2V0LCBubz8gT3Igc2hvdWxkIHRoZSBTWU4ganVzdCBiZSBkcm9wIGFu ZCBubyByZXBseSBzZW5kIGZvciBhbnkgcmVhc29uPyBQbGVhc2UgY2xhcmlmeS4NCg0KMTApIFBy b2JhYmx5IGVkaXRvcmlhbCBpbiBzZWMgNS4yLjQ6DQoiQSBUcmFuc3BvcnQgQ29udmVydGVyIFNI T1VMRCBpbmNsdWRlIGluIHRoaXMNCiAgIGxpc3QgdGhlIFRDUCBvcHRpb25zIHRoYXQgaXQgYWNj ZXB0cyBmcm9tIENsaWVudHM7IHRoZXNlIG9wdGlvbnMgYXJlDQogICBpbmNsdWRlZCBieSB0aGUg VHJhbnNwb3J0IENvbnZlcnRlciBpbiB0aGUgU1lOIHBhY2tldHMgdGhhdCBpdCBzZW5kcw0KICAg dG8gaW5pdGlhdGUgY29ubmVjdGlvbnMu4oCdDQpJIGhhZCB0byByZWFkIHRoZSBzZWNvbmQgaGFs ZiB0d2ljZSBiZWNhdXNlIGl0IHN1ZGRlbmx5IHRhbGtzIGFib3V0IGEgY29tcGxldGVseSBkaWZm ZXJlbnQg4oCcc2NlbmFyaW/igJ0gdGhhbiByZXBseWluZyB0byBhbiBJbmZvIFRMVi4gTWF5YmUg c29tZSByZXdvcmRpbmcgY291bGQgaGVscCBhIGJpdCBsaWtlDQoiQSBUcmFuc3BvcnQgQ29udmVy dGVyIFNIT1VMRCBpbmNsdWRlIGluIHRoaXMNCiAgIGxpc3QgdGhlIFRDUCBvcHRpb25zIHRoYXQg aXQgYWNjZXB0cyBmcm9tIENsaWVudHM7IHRoZXNlIG9wdGlvbnMgYXJlDQogICBhbHNvIGluY2x1 ZGVkIGJ5IHRoZSBUcmFuc3BvcnQgQ29udmVydGVyIGluIHRoZSBTWU4gcGFja2V0cyBpZiBpdA0K ICAgaW5pdGlhdGVzIGNvbm5lY3Rpb25zIHRvIHRoZSBjbGllbnQu4oCdDQpPciBtYXliZSBldmVu IHVzZSBub3JtYXRpdmUgbGFuZ3VhZ2UgaGVyZToNCuKAnHRoZSBUcmFuc3BvcnQgQ29udmVydCBT SE9VTEQgYWxzbyBpbmNsdWRlIHRoZSBzYW1lIG9wdGlvbiBpbiB0aGUgU1lOIGlmDQogICBpdCBp bml0aWF0ZXMgYSBjb25uZWN0aW9uIHRvIHRoZSBjbGllbnQu4oCdDQoNCjExKSBzZWMgNS4yLjU6 IE1heWJlIGFsc28gYmUgc2xpZ2h0bHkgbW9yZSBjbGVhciBoZXJlOg0KIkZvciBpbmNvbWluZyBj b25uZWN0aW9ucyBkZXN0aW5lZCB0byBhIENsaWVudA0KICAgc2VydmljZWQgdmlhIGEgVHJhbnNw b3J0IENvbnZlcnRlciwgdGhlc2UgZmllbGRzIGNvbnZleSB0aGUgc291cmNlDQogICBwb3J0IG51 bWJlciBhbmQgSVAgYWRkcmVzcy7igJ0NClByb3Bvc2VkDQoiRm9yIGluY29taW5nIGNvbm5lY3Rp b25zIGRlc3RpbmVkIHRvIGEgQ2xpZW50DQogICBzZXJ2aWNlZCB2aWEgYSBUcmFuc3BvcnQgQ29u dmVydGVyLCB0aGVzZSBmaWVsZHMgY29udmV5IHRoZSBzb3VyY2UNCiAgIHBvcnQgbnVtYmVyIGFu ZCBJUCBhZGRyZXNzIG9mIHRoZSBTWU4gcGFja2V0IHJlY2VpdmVkIGJ5IHRoZQ0KICAgVHJhbnNw b3J0IENvbnZlcnRlciBmcm9tIHRoZSBzZXJ2ZXIu4oCdDQoNCjEyKSBJIGhhdmUgYSBjb3VwbGUg b2YgcXVlc3Rpb24gYWJvdXQgdGhlIFRDUCBvcHRpb25zIGZpZWxkIGluIHRoZSBDb25uZWN0IFRM ViwgYmFzaWNhbGx5IHRoaXMgdGV4dCBpbiBzZWN0aW9uIDUuMi41Og0KIiAgIFVwb24gcmVjZXB0 aW9uIG9mIGEgQ29ubmVjdCBUTFYsIGFuZCBhYnNlbnQgYW55IHBvbGljeSAoZS5nLiwgcmF0ZS0N CiAgIGxpbWl0KSBvciByZXNvdXJjZSBleGhhdXN0aW9uIGNvbmRpdGlvbnMsIGEgVHJhbnNwb3J0 IENvbnZlcnRlcg0KICAgYXR0ZW1wdHMgdG8gZXN0YWJsaXNoIGEgY29ubmVjdGlvbiB0byB0aGUg YWRkcmVzcyBhbmQgcG9ydCB0aGF0IGl0DQogICBjb250YWlucy4gIFRoZSBUcmFuc3BvcnQgQ29u dmVydGVyIE1VU1QgdXNlIGJ5IGRlZmF1bHQgdGhlIFRDUA0KICAgb3B0aW9ucyB0aGF0IGNvcnJl c3BvbmQgdG8gaXRzIGxvY2FsIHBvbGljeSB0byBlc3RhYmxpc2ggdGhpcw0KICAgY29ubmVjdGlv bi4gIFRoZXNlIGFyZSB0aGUgb3B0aW9ucyB0aGF0IGl0IGFkdmVydGlzZXMgaW4gdGhlDQogICBT dXBwb3J0ZWQgVENQIEV4dGVuc2lvbnMgVExWLg0KDQoNCkJvbmF2ZW50dXJlLCBldCBhbC4gICAg ICAgIEV4cGlyZXMgTWF5IDcsIDIwMjAgICAgICAgICAgICAgICAgIFtQYWdlIDIyXQ0KSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgIENvbnZlcnQgUHJvdG9jb2wgICAgICAgICAgICAgICBOb3Zl bWJlciAyMDE5DQoNCg0KICAgVXBvbiByZWNlcHRpb24gb2YgYW4gZXh0ZW5kZWQgQ29ubmVjdCBU TFYsIGFuZCBhYnNlbnQgYW55IHJhdGUgbGltaXQNCiAgIHBvbGljeSBvciByZXNvdXJjZSBleGhh dXN0aW9uIGNvbmRpdGlvbnMsIGEgVHJhbnNwb3J0IENvbnZlcnRlciBNVVNUDQogICBhdHRlbXB0 IHRvIGVzdGFibGlzaCBhIGNvbm5lY3Rpb24gdG8gdGhlIGFkZHJlc3MgYW5kIHBvcnQgdGhhdCBp dA0KICAgY29udGFpbnMuICBJdCBNVVNUIGluY2x1ZGUgdGhlIG9wdGlvbnMgb2YgdGhlICdUQ1Ag T3B0aW9ucycgc3ViLWZpZWxkDQogICBpbiB0aGUgU1lOIHNlbnQgdG8gdGhlIFNlcnZlciBpbiBh ZGRpdGlvbiB0byB0aGUgVENQIG9wdGlvbnMgdGhhdCBpdA0KICAgd291bGQgaGF2ZSB1c2VkIGFj Y29yZGluZyB0byBpdHMgbG9jYWwgcG9saWNpZXMuICBGb3IgdGhlIFRDUCBvcHRpb25zDQogICB0 aGF0IGFyZSBsaXN0ZWQgd2l0aG91dCBhbiBvcHRpb25hbCB2YWx1ZSwgdGhlIFRyYW5zcG9ydCBD b252ZXJ0ZXINCiAgIE1VU1QgZ2VuZXJhdGUgaXRzIG93biB2YWx1ZS4gIEZvciB0aGUgVENQIG9w dGlvbnMgdGhhdCBhcmUgaW5jbHVkZWQNCiAgIGluIHRoZSAnVENQIE9wdGlvbnMnIGZpZWxkIHdp dGggYW4gb3B0aW9uYWwgdmFsdWUsIGl0IE1VU1QgY29weSB0aGUNCiAgIGVudGlyZSBvcHRpb24g Zm9yIHVzZSBpbiB0aGUgY29ubmVjdGlvbiB3aXRoIHRoZSBkZXN0aW5hdGlvbiBwZWVyLg0KICAg VGhpcyBmZWF0dXJlIGlzIHJlcXVpcmVkIHRvIHN1cHBvcnQgVENQIEZhc3QgT3Blbi7igJ0NCg0K Rmlyc3Qgb2YgYWxsIHRoZSB1cHBlciBwYXJhZ3JhcGggaXMgcHJvYmFibHkgb2xkIGFuZCBzaG91 bGQgaGF2ZSBiZWVuIHJlbW92ZWQsIHJpZ2h0Pw0KDQpUaGVuIEnigJltIG5vdCBjZXJ0YWluIGFi b3V0IHRoZSBuZXcgYXBwcm9hY2ggd2l0aCB0aGUgVENQIG9wdGlvbiBmaWVsZC4gSWYgdGhlIGNv bnZlcnRlciBhY3R1YWxseSBlbmRzIHVwIGluIGEgc3BsaXQgY29ubmVjdGlvbiAod2l0aCBlLmcu IE1QVENQIG9uIGNsaWVudCBzaWRlIGJ1dCB3aXRob3V0IGl0IG9uIHNlcnZlciBzaWRlKSwgSSB0 aG91Z2h0IGl0IGNhbiBvbmx5IGFubm91bmNlIHRob3NlIG9wdGlvbnMgaW4gdGhlIFNZTiB0byB0 aGUgc2VydmVyIHRoYXQgYXJlIGFjdHVhbGx5IGltcGxlbWVudGVkIGluIHRoZSBjb252ZXJ0ZXIg YW5kIGl0IHdpbGwgYmUgYWJsZSB0byBzdXBwb3J0IGxhdGVyIGluIHRoZSBjb25uZWN0aW9uLiBT byBibGluZGx5IGNvcHlpbmcgdGhlIG9wdGlvbnMgcHJvdmlkZWQgYnkgdGhlIGNsaWVudCBkb2Vz buKAmXQgc2VlbSByaWdodC4gT3Igd2hhdCBkbyBJIG1pc3M/DQoNCkkgdW5kZXJzdGFuZCB0aGUg Y2FzZSB3aGVyZSB5b3Ugd2FudCB0byB1c2UgVEZPIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhl IGNvbnZlcnQgYnV0IGNhbuKAmXQgdXNlIGl0IGFueW1vcmUgYmV0d2VlbiB0aGUgdGhlIGNsaWVu dCBhbmQgdGhlIHNlcnZlciB0aGVuLiBIb3dldmVyIHlvdSBjYW4gb25seSB1c2UgVEZPIHdpdGgg dGhlIHNlY29uZCBjb25uZWN0aW9uIHlvdSBtYWtlIHRvIGEgc2VydmVyLiBTbyBpbiB0aGUgZmly c3QgY29ubmVjdGlvbiBlaXRoZXIgVEZPIHdhcyB1c2VkIGJldHdlZW4gdGhlIGNvbnZlcnQgYW5k IHRoZSBzZXJ2ZXIgYW5kIHRoZSBjb252ZXJ0IGNvdWxkIG5vdyB1c2UgaXQgYWdhaW4gd2l0aCB0 aGUgY29va2llIGl0IHJlY2VpdmVkIG9yIFRGTyB3YXMgdXNlZCBlbmQtdG8tZW5kIGluIHRoZSBm aXJzdCBjb25uZWN0aW9uIGFuZCBpdCBub3cgY2xlYXIgdG8gbWUgd2h5IHRoZSBjb252ZXJ0ZXIg aXMgdXNlZCBub3cuIE1heWJlIEnigJltIG1pc3Npbmcgc29tZXRoaW5nIGJ1dCBJIHRoaW5rIHRo ZSBkcmFmdHMgd291bGQgYXQgbGVhc3QgbmVlZCBtb3JlIGV4cGxhbmF0aW9uIGFib3V0IHRoZSBt b3RpdmF0aW9uIHRvIGhhdmUgdGhpcy4NCg0KSWYgaXTigJlzIHJlYWxseSBvbmx5IGFib3V0IFRG TyBjb29raWVzIGFuZCB3ZSBhcmUgc3VyZSB3ZSB3YW50IHRvIGhhdmUgdGhhdCBmZWF0dXJlLCBt YXliZSBhbiBvd24gVExWIHdvdWxkIGJlIHNpbXBsZXI/DQoNCjEzKSBJbiBzZWMgNS4yLjYgZG8g eW91IG1lYW4gYnkgImV4dGVuZGVkIFRDUCBoZWFkZXLigJ0gdGhlIFRDUCBvcHRpb24gc3BhY2U/ IEnigJltIG5vdCBzdXJlIHRoYXQgImV4dGVuZGVkIFRDUCBoZWFkZXLigJ0gaXMgYSBjbGVhcmx5 IGRlZmluZWQgdGVybTsgYXMgbGVhc3QgSeKAmW0gbm90IDEwMCUgc3VyZSB3aGF0IHlvdSBtZWFu 4oCmDQoNCjE0KSBuaXQgaW4gc2VjIDUuMi43Og0Kcy9UaGUgQ29va2llIFRMViAoRmlndXJlIDIw IGlzIGFuIG9wdGlvbmFsL1RoZSBDb29raWUgVExWIChGaWd1cmUgMjApIGlzIGFuIG9wdGlvbmFs LyAtPiBtaXNzaW5nIGNsb3NpbmcgYnJhY2tldA0KDQoxNSkgU2VjIDUuMi43Og0KUXVlc3Rpb24g YWJvdXQgbm9ybWF0aXZlIGxhbmd1YWdlOg0KIklmIHRoZSByZWNlaXZlZCBTWU4gZGlkIG5vdCBj b250YWluIGEgQ29va2llIFRMViwgYW5kIGNvb2tpZQ0KICAgdmFsaWRhdGlvbiBpcyByZXF1aXJl ZCwgdGhlIFRyYW5zcG9ydCBDb252ZXJ0ZXIgc2hvdWxkIGNvbXB1dGUgYQ0KICAgQ29va2llIGJv dW5kIHRvIHRoaXMgQ2xpZW50IGFkZHJlc3MgYW5kIHJldHVybiBhIENvbnZlcnQgbWVzc2FnZQ0K ICAgY29udGFpbmluZyB0aGUgZml4ZWQgaGVhZGVyLCBhbiBFcnJvciBUTFYgc2V0IHRvICJNaXNz aW5nIENvb2tpZSIgYW5kDQogICB0aGUgY29tcHV0ZWQgQ29va2llIGFuZCBjbG9zZSB0aGUgY29u bmVjdGlvbi7igJ0NCklzIHRoaXMgbWF5YmUgYSBNQVkgY29uZGl0aW9uPyBBbGwgb2YgaXQ/IE9y IHNvbWV0aGluZyBsaWtlIHRoaXMNCiJJZiB0aGUgcmVjZWl2ZWQgU1lOIGRpZCBub3QgY29udGFp biBhIENvb2tpZSBUTFYsIGFuZCBjb29raWUNCiAgIHZhbGlkYXRpb24gaXMgcmVxdWlyZWQsIHRo ZSBUcmFuc3BvcnQgQ29udmVydGVyIE1BWSBjb21wdXRlIGENCiAgIENvb2tpZSBib3VuZCB0byB0 aGlzIENsaWVudCBhZGRyZXNzLiBJdCBNVVNUIHJldHVybiBhIENvbnZlcnQgbWVzc2FnZQ0KICAg Y29udGFpbmluZyB0aGUgZml4ZWQgaGVhZGVyIGFuZCBFcnJvciBUTFYgc2V0IHRvICJNaXNzaW5n IENvb2tpZeKAnSBhbmQgTUFZIGFkZA0KICAgdGhlIGNvbXB1dGVkIENvb2tpZS4gQWZ0ZXIgc2Vu ZGluZyB0aGUgRXJyb3IgVExWIGlzIE1VU1QvU0hPVUxEIGNsb3NlL3Jlc2V0DQogICB0aGUgY29u bmVjdGlvbi7igJ0NCk5vdCBmdWxseSBzdXJlIHdoYXQgaXMgdGhlIGludGVudGlvbiBoZXJl4oCm DQoNCjE1KSBzZWMgNS4yLjg6DQpXaGF0J3MgdGhlIHB1cnBvc2Ugb2YgdGhlIGNsaWVudCBzZW5k aW5nIGFuIFVuc3VwcG9ydGVkIFZlcnNpb24gZXJyb3I/IElmIHRoZSBjb252ZXJ0ZXIgcmVwbGll cyB3aXRoIGEgZGlmZmVyZW50IHZlcnNpb24gdGhhbiByZXF1ZXN0ZWQgdXNlZCBieSB0aGUgY2xp ZW50LCB0aGF0J3Mgc2ltcGx5IGEgZmF0YWwgZXJyb3IvaW1wbGVtZW50YXRpb24gZXJyb3IgYW5k IHRoZSBjbGllbnQgY2FuIG9ubHkgcmVzZXQgdGhlIGNvbm5lY3Rpb24gSSB0aGluay4NCg0KTW9y ZSBnZW5lcmFsbHkgaWYgSSByZWFkIHRoaXMgY29ycmVjdGx5IHRoZXJlIGFyZSBvbmx5IDMgZXJy b3JzIHRoYXQgY291bGQgYmUgc2VudCBieSB0aGUgY2xpZW50LiBJIGd1ZXNzIHRob3NlIGVycm9y cyB3b3VsZCBiZSBzZW5kIGluIHRoZSBmaXJzdCBwYWNrZXQgYWZ0ZXIgdGhlIFNZTi9BQ0sgaXMg cmVjZWl2ZWTigKY/IFJlbGF0ZWQgdG8gbXkgcXVlc3Rpb24gYWJvdmUsIEkgdGhpbmsgaXQgd291 bGQgYmUgbXVjaCBlYXNpZXIgdG8gb25seSBoYXZlIENvbnZlcnQgbWVzc2FnZSBpbiB0aGUgU1lO IGFuZCBTWU4vQUNLIGFuZCBubyBleHBsaWNpdCBlcnJvciBtZXNzYWdlIGZyb20gdGhlIGNsaWVu dC4gT3RoZXJ3aXNlIG1vcmUgZXhwbGFuYXRpb24gaW4gdGhlIGRyYWZ0IHdvdWxkIGJlIG5lZWQg aG93IHRoaXMgYWN0dWFsbHkgaXMgc3VwcG9zZWQgdG8gd29yay4NCg0KMTYpIHNlYyA1LjIuODoN CiJBIENsaWVudCB3aGljaCByZWNlaXZlcyB0aGlzIGVycm9yIGNvZGUgTVVTVCBjYWNoZSB0aGUg cmVjZWl2ZWQNCiAgICAgIENvb2tpZSBhbmQgaW5jbHVkZSBpdCBpbiBzdWJzZXF1ZW50IENvbnZl cnQgbWVzc2FnZXMgc2VudCB0byB0aGF0DQogICAgICBUcmFuc3BvcnQgQ29udmVydGVyLuKAnQ0K VGhpcyBzZWVtcyB0byBiZSBhIHNsaWdodGx5IHdlaXJkIG5vcm1hdGl2ZSBNVVNULiBTdXJlIHlv dSBoYXZlIHRvIGNhY2hlIHRoZSBjb29raWUgaW4gb2RlciB0byBiZSBhYmxlIHRvIHVzZSB0aGUg Y29udmVydGVyLCBob3dldmVyLCB0aGVyZSBtYXkgYmUgY2FzZXMgd2hlcmUgeW91IGxvb3NlIHRo ZSBjYWNoZSBhbmQgdGhlbiBzZW5kaW5nIGEgQ29ubmVjdCB3aXRob3V0IHRoZSBjb29raWUgdG8g Z2V0IGEgbmV3IENvb2tpZSBpcyBhIHZhbGlkIG9wdGlvbi4gU28geW91IG1heSB1c2UgU0hPVUxE IGhlcmUgb3IgZXZlbiBiZXR0ZXIgcmV3b3JkIGl0IGNvbXBsZXRlbHkuLi4NCg0KMTcpIFRoZXJl IGlzIGFuIFVuc3VwcG9ydGVkIFRDUCBPcHRpb24gaW4gc2VjdGlvbiA1LjIuOC4gSG93ZXZlciwg dGhpcyBlcnJvciBpcyBub3QgbWVudGlvbmVkIGluIDUuMi41LiBJbiBjb250cmFzdCBzZWMgNS4y LjUgc2F5cyB0aGF0IHRoZSBjb252ZXJ0ZXIgTVVTVCBvcGVuIGEgY29ubmVjdGlvbiBhbmQgTVVT VCB1c2UgdGhlc2Ugb3B0aW9ucy4gVGhpcyBpcyByZWxhdGVkIHRvIG15IHBvaW50IDEyIGFib3Zl IGJ1dCBpdCB3YXMgbm90IGNsZWFyIHRvIG1lIHRoYXQgb3B0aW9ucyBjYW4gYmUgcmVqZWN0ZWQs IGhvd2V2ZXIsIHRoaXMgd2hvbGUgcGFydCBzZWVtcyB0byBtYWtlIHRoZSBwcm90b2NvbCByZWFs bHkgY29tcGxpY2F0ZWQgYW5kIGFzIEkgc2FpZCBpZiB0aGUgb25seSB1c2UgY2FzZSBpcyBURk8g SSB3b3VsZCBwcmVmZXIgdG8gcmF0aGVyIGhhdmUgYSBzZXBhcmF0ZSBzcGVjaWZpYyBUTFYgZm9y IHRoYXQgY2FzZSBvbmx5Lg0KDQoxOCkgSSB0aGluayBzZWN0aW9uIDYuNyBzaG91bGQgc3RpbGwg c2F5IHNvbWV0aGluZyBhYm91dCBpZiB0aGlzIG9wdGlvbiBpcyBzdXBwb3J0ZWQgb3Igbm904oCm DQoNCjE5KSBzZWN0aW9uIDc6DQoiQ29uc2lkZXIgYSBtaWRkbGVib3ggdGhhdCByZW1vdmVzIHRo ZSBTWU4gcGF5bG9hZC4gIFRoZSBDbGllbnQgY2FuDQogICBkZXRlY3QgdGhpcyBwcm9ibGVtIGJ5 IGxvb2tpbmcgYXQgdGhlIGFja25vd2xlZGdtZW50IG51bWJlciBmaWVsZCBvZg0KICAgdGhlIFNZ TitBQ0sgcmV0dXJuZWQgYnkgdGhlIFRyYW5zcG9ydCBDb252ZXJ0ZXIuICBUaGUgQ2xpZW50IE1V U1QNCiAgIHN0b3AgdG8gdXNlIHRoaXMgVHJhbnNwb3J0IENvbnZlcnRlciBnaXZlbiB0aGUgbWlk ZGxlYm94DQogICBpbnRlcmZlcmVuY2Uu4oCdDQpJZiB0aGUgY29udmVydGVyIHJlY2VpdmVkIGEg U1lOIHdpdGhvdXQgYSBDb252ZXJ0IG1lc3NhZ2UgaW4gdGhlIHBheWxvYWQgb24gdGhlIHJlc3Bl Y3RpdmUgcG9ydCwgaXQgaXMgc3VwcG9zZWQgdG8gYW55d2F5IHNlbmQgYSBTWU4vQUNLPyBJIHdv dWxkIGFzc3VtZSBpdCB3b3VsZCByYXRoZXIgc2VuZCBhIFJFU0VULCBubz8gSSB0aGluayB0aGF0 IG5lZWRzIHRvIGJlIGZ1cnRoZXIgc3BlY2lmaWVkLg0KDQoyMCkgU2VjIDcgYWxzbyBzYXlzOg0K 4oCcSWYgYW4gRXJyb3Igd2FzIHJldHVybmVkIGJ5IHRoZSBUcmFuc3BvcnQgQ29udmVydGVyLCBh IG1lc3NhZ2UgdG8gY2xvc2UNCiAgIHRoZSBjb25uZWN0aW9uIHdvdWxkIG5vcm1hbGx5IGZvbGxv dyBmcm9tIHRoZSBDb252ZXJ0ZXIu4oCdDQpIb3dldmVyIHNlYyA1LjIuOCBzYXlzOg0KIlVwb24g cmVjZXB0aW9uIG9mIGFuIEVycm9yIFRMViwgYQ0KICAgQ2xpZW50IE1VU1QgY2xvc2UgdGhlIGFz c29jaWF0ZWQgY29ubmVjdGlvbi7igJ0NCkkgYXNzdW1lIG9uZSBvZiB0aGVzZSBpcyBub3QgY29y cmVjdOKApiBwbGVhc2UgY2xhcmlmeSB3aGljaCBlbmQgaXMgc3VwcG9zZSB0byBkbyB3aGF0IGlu IGNhc2Ugb2YgYW4gZXJyb3IuDQoNCjIxKSBUaGUgdGV4dCBpbiBzZWMgNyB0aGVuIGZ1cnRoZXIg c2F5czoNCiJJZiBubyBzdWNoDQogICBtZXNzYWdlIGlzIHJlY2VpdmVkLCB0aGUgQ2xpZW50IG1h eSBjb250aW51ZSB0byB1c2UgdGhpcyBDb252ZXJ0ZXIu4oCdDQpJc27igJl0IHRoYXQgYSBiaXQg ZGFuZ2Vyb3VzPw0KDQoyMikgc2VjdGlvbiA4LjU6IFdoeSBhcmUgdGhlIGF1dGhlbnRpY2F0aW9u IG1lY2hhbmlzbSBkaXNjdXNzZWQgaW4gdGhpcyBzZWN0aW9uIE1QVENQIHNwZWNpZmljPyBJIHRo aW5rIHRoZSBzYW1lIG1lY2hhbmlzbXMgY291bGQgYWxzbyBiZSBhcHBsaWVkIHRvIENvbnZlcnRl cnMgc3VwcG9ydGluZyBvdGhlciBvcHRpb25zLCBubz8NCg0KMjMpIHNlYyA4LjM6DQoiTWVhbnMg dG8gcHJvdGVjdCBhZ2FpbnN0IFNZTiBmbG9vZGluZyBhdHRhY2tzIE1VU1QgYWxzbyBiZSBlbmFi bGVkIFtSRkM0OTg3XS7igJ0NCk5vdCBzdXJlIGlmIHRoZSB1c2Ugb2YgTVVTVCBpcyBjbGVhciBo ZXJlLiBXaGljaCBwYXJ0IG9mIFJGQzQ5ODcgZG9lcyB0aGlzIE1VU1QgcmVsYXRlIHRvPyBBbGwg b2YgaXQ/IE1heWJlIGEgU0hPVUxEIG9yIG5vIG5vcm1hdGl2ZSBsYW5ndWFnZSBpcyBtb3JlIGFw cHJvcHJpYXRlPw0KDQoyNCkgc2VjIDkuMjogTWF5YmUgY2FsbCB0aGUgbmV3IHJlZ2lzdHJ5IHRo ZSAiVGhlIFRDUCBDb252ZXJ0IFByb3RvY29sIChDb252ZXJ0KQ0KICAgUGFyYW1ldGVyc+KAnSAo VENQIGFkZGVkKeKApj8NCg0KMjUpIHNlYyA5LjIuMjoNCiJUaGUgdmFsdWVzIGluIHRoZSByYW5n ZSAxOTItMjU1IGNhbiBiZSBhc3NpZ25lZCBmb3IgUHJpdmF0ZSBVc2Uu4oCdDQpJQU5BIGRvZXMg bm90IGFzc2lnbmVkIGFueSB2YWx1ZSBmb3IgUHJpdmF0ZSB1c2UsIHRoZXkgY2FuIGp1c3QgYmUg dXNlZCwgc28gdGhpcyBzaG91bGQgYmUNCiJUaGUgdmFsdWVzIGluIHRoZSByYW5nZSAxOTItMjU1 IGFyZSByZXNlcnZlZCBmb3IgUHJpdmF0ZSBVc2Uu4oCdDQppZiB0aGF0IGlzIHdoYXQgeW91IHdh bnQ/DQoNCjI2KSBhbHNvIG9uIHNlY3Rpb24gOS4yLlg6ICJTcGVjaWZpY2F0aW9uIFJlcXVpcmVk IiBpbmNsdWRlcyBoYXZpbmcgYW4gZXhwZXJ0IHJldmlldyBhbmQgUkZDODEyNiBzYXlzOg0KIkFz IHdpdGggRXhwZXJ0IFJldmlldyAoU2VjdGlvbiA0LjUpLCBjbGVhciBndWlkYW5jZSB0byB0aGUg ZGVzaWduYXRlZA0KICAgZXhwZXJ0IHNob3VsZCBiZSBwcm92aWRlZCB3aGVuIGRlZmluaW5nIHRo ZSByZWdpc3RyeSwgYW5kIHRob3JvdWdoDQogICB1bmRlcnN0YW5kaW5nIG9mIFNlY3Rpb24gNSBp cyBpbXBvcnRhbnQu4oCdDQpTbyBwbGVhc2UgcHJvdmlkZSBmdXJ0aGVyIGd1aWRhbmNlIGFib3V0 IHdoYXQgdGhlIGV4cGVydCBpcyBzdXBwb3J0ZWQgdG8gZXZhbHVhdGUuDQoNCjI3KSBOb3Qgc3Vy ZSBpZiB0aGUgZm9sbG93aW5nIHJlZmVyZW5jZXMgbmVlZCB0byBiZSBub3JtYXRpdmUgYXMgdGhl cmUgbm8gbm9ybWF0aXZlIHJlcXVpcmVtZW50IGNvbm5lY3QgdG8gdGhlbSBidXQgb25seSBhbiBv cHRpb25hbCBjYXNlIGlzIGRpc2N1c3NlZDogUkZDNDI3OSwgUkZDNzI1MCDigKY/DQoNCkhvd2V2 ZXIsIFJGQzczMjMsIFJGQzIwMTgsIFJGQzY5NzgsIFJGQzY5NzgsIFJGQzI4MjcsIFJGQzYxODEg c2hvdWxkIHByb2JhYmx5IGJlIG5vcm1hdGl2ZSByZWZlcmVuY2Vz4oCmPw0KDQoyOCkgVGhlIHRl cm0g4oCcZXhwZXJpbWVudGFsIG9wdGlvbuKAnSBpcyB1c2VkIHdpdGggdHdvIGRpZmZlcmVudCBt ZWFuaW5nIGluIHRoZSBpbnRybyBvZiBzZWN0aW9uIDYgKG9wdGlvbnMgdGhhdCBhcmUgZGVmaW5l ZCBpbiBhbiBleHAgUkZDKSBhbmQgaW4gc2VjdGlvbiA2LjkgKG9wdGlvbnMgd2l0aCBraW5kIDI1 NCBhbmQgMjU1KS4gUGxlYXNlIGNsYXJpZnkgdGhpcyBhdCBib3RoIHBsYWNlcy4NCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpEaXNjbGFp bWVyOiBodHRwczovL3d3dy50ZXNzYXJlcy5uZXQvbWFpbC1kaXNjbGFpbWVyLw0KDQoNCg== --_000_6EC6417807D9754DA64F3087E2E2E03E2D8F5326rznt8114rzntrzd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 c3R5bGU+DQo8IS0tDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgifQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpfQ0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmV9DQouTXNvQ2hwRGVmYXVsdA0KCXt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7bWFyZ2luOjcwLjg1cHQgNzAuODVwdCAyLjBjbSA3MC44NXB0fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXt9DQotLT4NCjwvc3R5bGU+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SW5kZWVkPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R2l2ZW4gdGhhdCBURk8gc3VwcG9ydCBoYXMgYmVlbiBk aXNjdXNzZWQgaW4gdGhlIHdvcmtpbmcgZ3JvdXAgcXVpdGUgYSBiaXQsIHN1YnN0YW50aWFsIHRl Y2huaWNhbCBjaGFuZ2VzIGluIHRoYXQgc3BhY2Ugd291bGQgSU1ITyByZXF1aXJlIGFub3RoZXIg V0dMQy4gT2YgY291cnNlLCB0aGlzIGNvdWxkIGJlIGRvbmUgb24gZmFzdCB0cmFjaywgaS5lLiwg aWYgdGhlIGNvbW11bml0eSBhZ3JlZXMsIGl0IHdvdWxkDQogbm90IHJlc3VsdCBpbiBhIGxhcmdl IGRlbGF5LjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk1pY2hhZWw8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QUzog U29tZSBleHBlcmltZW50YWwgVENQIHNwZWNzIChvciBpbmZvcm1hdGlvbmFsIGRvY3VtZW50cykg cHVibGlzaGVkIGJ5IFRDUE0gYXJlIHF1aXRlIHdpZGVseSBkZXBsb3llZC48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTsgYm9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 OyBwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJib3JkZXI6bm9uZTsgcGFkZGluZzowY20iPjxiPlZvbjogPC9iPjxhIGhyZWY9Im1haWx0bzpp ZXRmQGt1ZWhsZXdpbmQubmV0Ij5NaXJqYSBLw7xobGV3aW5kIChJRVRGKQ0KPC9hPjxicj4NCjxi Pkdlc2VuZGV0OiA8L2I+U2Ftc3RhZywgMjUuIEphbnVhciAyMDIwIDEzOjAyPGJyPg0KPGI+QW46 IDwvYj48YSBocmVmPSJtYWlsdG86b2xpdmllci5ib25hdmVudHVyZUB0ZXNzYXJlcy5uZXQiPk9s aXZpZXIgQm9uYXZlbnR1cmU8L2E+PGJyPg0KPGI+Q2M6IDwvYj48YSBocmVmPSJtYWlsdG86ZHJh ZnQtaWV0Zi10Y3BtLWNvbnZlcnRlcnMuYWxsQGlldGYub3JnIj5kcmFmdC1pZXRmLXRjcG0tY29u dmVydGVycy5hbGxAaWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmci PnRjcG0gSUVURiBsaXN0PC9hPjxicj4NCjxiPkJldHJlZmY6IDwvYj5SZTogQUQgcmV2aWV3IG9m IGRyYWZ0LWlldGYtdGNwbS1jb252ZXJ0ZXJzLTE0PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj5IaSBPbGl2 aWVyLDwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj5T b3VuZHMgbGlrZSBhIGdvb2QgcGxhbiB0byBtZS4gTGV04oCZcyBzZWUgaG93IHRoZXNlIGNoYW5n ZXMgd2lsbCBhY3R1YWxseSBsb29rIGxpa2UgYnV0IGl0IG1pZ2h0IGJlIHRoYXQgdGhlIGNoYWly cyBzaG91bGQgY29uc2lkZXIgaW4gdGhpcyBjYXNlIHRvIHJ1biBhbm90aGVyIHdvcmtpbmcgZ3Jv dXAgbGFzdCBjYWxsLjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRp cj0ibHRyIj5NaXJqYTwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRp cj0ibHRyIj48YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5BbSAyNS4wMS4yMDIwIHVtIDEx OjQ3IHNjaHJpZWIgT2xpdmllciBCb25hdmVudHVyZSAmbHQ7b2xpdmllci5ib25hdmVudHVyZUB0 ZXNzYXJlcy5uZXQmZ3Q7Ojxicj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IGRpcj0ibHRyIj7vu78NCjxkaXYgZGlyPSJsdHIiPkRl YXIgTWlyamEsDQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFua3MgYWdhaW4gZm9yIHRoZSBk ZXRhaWxlZCBjb21tZW50cy4gV2UgYXJlIGN1cnJlbnRseSBkaWdlc3RpbmcgdGhlbSBhbmQgcHJl cGFyZSBhbiB1cGRhdGVkIHZlcnNpb24gb2YgdGhlIGRyYWZ0LiBTb21lIG9mIHlvdXIgY29tbWVu dHMgaGF2ZSBpbmRpY2F0ZWQgdGhhdCBzb21lIHBhcnRzIHdlcmUgdW5jbGVhciwgbm90YWJseSBm b3IgdGhlIHN1cHBvcnQgb2YgdGhlIFRGTyBvcHRpb24uIFdlIHByb3Bvc2UgdG8gYW5zd2VyIHRo ZW0NCiBieSBzaW1wbGlmeWluZyZuYnNwO3RoZSBwcm90b2NvbCBhIGJpdCBhbmQgbW92ZSB0aGUg cGFydHMgdGhhdCBhcmUgcmVxdWlyZWQgdG8gc3VwcG9ydCBURk8gYW5kIG90aGVyIGV4cGVyaW1l bnRhbCBvcHRpb25zIGluIGEgZGlmZmVyZW50IGRyYWZ0LiBUaGUgd29ya2luZyBncm91cCBkb2N1 bWVudCB3aWxsIHRoZW4gZm9jdXMgb24gdGhlIHN0YW5kYXJkIFRDUCBvcHRpb25zIChpbmNsdWRp bmcgTVBUQ1AgZ2l2ZW4gdGhhdCB2ZXJzaW9uIDEgaXMgZmluYWwpDQogYW5kIHRoZSBvdGhlciBk cmFmdCB3aWxsIHByb3Bvc2UgZXh0ZW5zaW9ucyB0byB0aGlzIGJhc2UgcHJvdG9jb2wgdG8gc3Vw cG9ydCBURk8gYW5kIG90aGVyIGV4cGVyaW1lbnRhbCBvcHRpb25zLiZuYnNwOzwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhpcyBzaG91bGQgbWFrZSB0aGUgdGV4dCBlYXNpZXIgdG8g cmVhZCBhbmQgdGhlIGJhc2UgcHJvdG9jb2wgc2ltcGxlciB0byBpbXBsZW1lbnQ8L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkJlc3QgcmVnYXJkcyw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2Pk9saXZpZXIsIE1lZCBhbmQgQmVuamFtaW48L2Rpdj4NCjwvZGl2Pg0KPGJyPg0K PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsX2F0 dHIiPk9uIFRodSwgSmFuIDksIDIwMjAgYXQgMTA6MjggUE0gTWlyamEgS3VlaGxld2luZCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmlldGZAa3VlaGxld2luZC5uZXQiPmlldGZAa3VlaGxld2luZC5uZXQ8 L2E+Jmd0OyB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90 ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDsgYm9yZGVyLWxlZnQ6MXB4IHNvbGlk IHJnYigyMDQsMjA0LDIwNCk7IHBhZGRpbmctbGVmdDoxZXgiPg0KSGkgYXV0aG9ycyw8YnI+DQo8 YnI+DQpJIGZpbmFsbHkgZGlkIG15IEFEIHJldmlldyBmb3IgZHJhZnQtaWV0Zi10Y3BtLWNvbnZl cnRlcnMtMTQgKGFjdHVhbGx5IEknbSBzdGlsbCBub3QgZnVsbHkgZmluaXNoZWQgd2l0aCB0aGUg cmV2aWV3IG9mIHRoZSBhcHBlbmRpeCBidXQgd291bGQgbGlrZSB0byBzZW5kIG91dCB0aGlzIGZp cnN0IGJhdGNoIG9mIHF1ZXN0aW9ucyBub3cpLjxicj4NCjxicj4NCkFzIHlvdSBjYW4gc2VlIGJl bG93LCBJIGhhdmUgYSB3aG9sZSBidW5jaCBvZiBxdWVzdGlvbnMvY29tbWVudHMuIFNvbWUgb2Yg dGhlc2UgbWF5IG9ubHkgYmUgZWRpdG9yaWFsIGluIHRoZSBlbmQgYnV0IEkgd291bGQgbGlrZSB0 byBtYWtlIHN1cmUgdGhhdCBJIHVuZGVyc3RhbmQgYWxsIHRoZSB0ZWNobmljYWwgcGFydHMgY29y cmVjdGx5IGJlZm9yZSB3ZSBtb3ZlIG9uIHdpdGggdGhlIHByb2Nlc3NpbmcuDQo8YnI+DQo8YnI+ DQpJIHRoaW5rIHRoZXJlIGFyZSBiYXNpY2FsbHkgdHdvIG1haW4gdGVjaG5pY2FsIHBvaW50cyBJ IHdvdWxkIGxpa2UgdG8gZ2V0IHNvbWUgY2xhcmlmaWNhdGlvbiBvbiwgYm90aCBwcm9iYWJseSBy ZWxhdGVkIHRvIHRoaW5ncyB0aGF0IGhhdmUgYmVlbiBpbnRyb2R1Y2VkIGxhdGVyIGluIHRoZSBs aWZlIHRpbWUgb2YgdGhlIGRvYyBidXQgbWF5YmUgbm90IGNvbnNlcXVlbnRseSBiZWVuIGNoYW5n ZWQgdGhyb3VnaG91dCB0aGUgd2hvbGUgZG9jLg0KPGJyPg0KPGJyPg0KT25lIGlzIGJlc2lhY2xs eSBwb2ludCA4IGJlbG93IGJ1dCB0aGVyZSBhcmUgc29tZSByZWxhdGVkIG90aGVyIHBvaW50cyBi ZWxvdzogSXQgaXMgbm90IGZ1bGx5IGNsZWFyIHdoaWNoIHBhY2tldHMgY2FuIGNhcnJ5IENvbnZl cnQgbWVzc2FnZXMuIEkgdGhpbmsgaW5pdGlhbGx5IENvbnZlcnQgbWVzc2FnZXMgd2VyZSBvbmx5 IHN1cHBvc2VkIHRvIGJlIGluIHRoZSBTWU4gYW5kIFNZTi9BQ0suIEJ1dCB0aGVuIGxhdGVyIHlv dSBlbmFibGVkIGl0IGFsc28NCiBmb3Igb3RoZXIgcGFja2V0cywgaG93ZXZlciwgaXQgc2VlbSB0 aGUgb25seSByZWFsIGNhc2UgdGhhdCBuZWVkcyB0aGlzIGlzIHdoZW4gYW4gZXJyb3IgbWVzc2Fn ZSBpcyBzZW5kIGJ5IHRoZSBjbGllbnQuIEJ1dCBzZW5kaW5nIENvbnZlcnQgbWVzc2FnZXMgaW4g b3RoZXIgcGFja2V0IHRoYW4gdGhlIFNZTiBhbmQgdGhlIFNZTi9BQ0sgc2VlbXMgbW9yZSBjb21w bGljYXRlZCBiZWNhdXNlIGFsbCBUQ1AgcGF5bG9hZCBkYXRhIGlzIHRyYW5zbWl0dGVkDQogcmVs aWFibGUgYW5kIG11c3QgYmUgYWNrJ2VkIGFuZCBldmlsLiByZXRyYW5zbWl0dGVkLiBNYXliZSBp dOKAmXMgb2theSBpZiBvbmx5IGFuIGVycm9yIG1lc3NhZ2UgaXMgc2VuZCBhbmQgYSByZXNldCBy aWdodCBhZnRlciAoc28gbm8gcmV0cmFuc21pc3Npb24pLCBob3dldmVyLCB0aGlzIGlzIG5vdCBz cGVjaWZpZWQsIGFuZCBJIHdvbmRlciBpZiB0aGUgY29tcGxleGl0eSBpcyByZWFsbHkgbmVlZGVk IHdvcnRoIHRoZSBiZW5lZml0IG9mIGJlaW5nDQogYWJsZSB0byBsb2cgbW9yZSBjb25jcmV0ZSBl cnJvcnMgaW4gdGhlIGNvbnZlcnRlci48YnI+DQo8YnI+DQpUaGUgb3RoZXIgcG9pbnQgaXMgYmFz aWNhbGx5IHBvaW50IDEyIGJlbG93IGFib3V0IHRoZSBUQ1Agb3B0aW9uIGZpZWxkIGluIHRoZSBD b25uZWN0IFRMViAoYWxzbyByZWxhdGVkIHRvIHBvaW50IDE3IGJlbG93KS4gVGhpcyBpcyBub3Qg d2VsbCBlbm91Z2ggc3BlY2lmaWVkIGFuZCBzZWVtIGFsc28gcXVpdGUgY29tcGxleCBhcyBhIGdl bmVyaWMgbWVjaGFuaXNtLiBJIHdvdWxkIHRoaW5rIHRoZSBjb252ZXJ0ZXIgc2hvdWxkIHVzdWFs bHkgdHJ5DQogdG8gdXNlIHRoZSBzYW1lIG9wdGlvbiBhcyB0aGUgY2xpZW50IGRpZCBzZW5kIGlu IGhpcyBTWU4gdG8gdGhlIGNvbnZlcnRlciwgaWYgc3VwcG9ydGVkIGJ5IHRoZSBjb252ZXJ0ZXIg VENQIGltcGxlbWVudGF0aW9uLiBUaGUgVEZPIGNvb2tpZSBtaWdodCBiZSBhIHNwZWNpYWwgY2Fz ZS4gSeKAmW0gbm90IHN1cmUgaWYgdGhhdCBuZWVkcyB0byBiZSBnZW5lcmFsaXNlZCBvciBpZiBo YXZpbmcgYSBzZXBhcmF0ZSBUTFYgZm9yIHRoYXQgb25lIGNhc2UNCiBtaWdodCBiZSBzaW1wbGVy LiBQbGVhc2UgYWxzbyByZWNvbnNpZGVyIHRoaXMgYnV0IGluIGFueSBjYXNlIGl0IG5lZWRzIG1v cmUgZXhwbGFuYXRpb24gaW4gdGhlIHNwZWMuPGJyPg0KPGJyPg0KUGxlYXNlIHNlZSBhbGwgbXkg cXVlc3Rpb25zL2NvbW1lbnRzIGJlbG93LiBJIG1heSBzZW5kIGFub3RoZXIgbWVzc2FnZSwgd2hl biBJIGhhdmUgcmV2aWV3ZWQgdGhlIGFwcGVuZGl4IHRvbW9ycm93IChob3BlZnVsbHkgd2l0aCBu b25lIG9yIG9ubHkgZmV3IGFkZGl0aW9uYWwgY29tbWVudHMpLjxicj4NCjxicj4NClRoYW5rcyE8 YnI+DQpNaXJqYTxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQox KSBJIHdhcyBpbml0aWFsbHkgYSBiaXQgY29uZnVzZWQgYWJvdXQgdGhlIHNldHVwIGluIEZpZ3Vy ZSA2IGFuZCByZXNwZWN0aXZlbHkgdGhlIHBhcmFncmFwaCBqdXN0IGJlZm9yZSB0aGF0IGZpZ3Vy ZSBpbiBzZWMgMy4yOiBJdCB3YXNuJ3QgY2xlYXIgdG8gbWUgaG93IHRoZSBzZXJ2ZXIgbWlnaHQg a25vdyB0aGUgY29udmVydGVyIGFkZHJlc3MgKG9yIGlmIHRoZSBwcm94eSBtYXliZSBoYXMgdG8g YmUgb24gcGF0aCkuIEkgYXNzdW1lIHRoZSDigJx1c2UNCiBjYXNl4oCdIGlzIHRoYXQgdGhlcmUg d2FzIGEgcHJldmlvdXMgY29ubmVjdGlvbiB1c2luZyB0aGUgY29udmVydGVyIGFuZCBub3cgdGhl IHNlcnZlciB0cmllcyB0byByZWNvbm5lY3QgYnV0IG9mIGNvdXJzZSBvbmx5IGtub3dzIHRoZSBj b252ZXJ0ZXIgYWRkcmVzcywgb3Igc29tZXRoaW5nPyBNYXliZSB5b3UgY291bGQgYWRkIHNsaWdo dGx5IG1vcmUgdGV4dCBoZXJlLiBJIGFsc28gSSB3b3VsZCByZWNvbW1lbmQgdG8gZXhwbGljaXRs eSBtZW50aW9uDQogdGhhdCB0aGlzIHNldHVwIHN0aWxsIGhhcyB0byBiZSBleHBsaWNpdGx5IGNv bmZpZ3VyZWQgYnkgdGhlIGNsaWVudCBidXQgdXNpbmcgYW4gb3V0IG9mIGJhbmQgcHJvdG9jb2wg KHdoaWNoIGlzIG91dCBvciBzY29wZSBmb3IgdGhpcyBzcGVjKS4gRnVydGhlciBJIHRoaW5rIGl0 IHdvdWxkIGJlIGdvb2QgdG8gbWVudGlvbiBoZXJlIGFscmVhZHkgdGhhdCB0aGUgY29udmVydGVy IGFsc28gaW5zZXJ0cyB0aGUgcmVzcGVjdGl2ZSBUQ1Agb3B0aW9uDQogaW4gdGhlIFNZTiB0byB0 aGUgY2xpZW50IChpZiBwb3NzaWJsZSBkdWUgdG8gc3BhY2UgbGltaXRzKSBhbmQgcmVmZXIgdG8g c2VjdGlvbiA0LjIgZm9yIGEgY29uY3JldGUgZXhhbXBsZS48YnI+DQo8YnI+DQpCdHcuIHNob3Vs ZG4ndCB0aGVyZSBiZSBzb21lIGRpc2N1c3Npb24gYWJvdXQgTVRVIGlzc3VlIGlmIG9wdGlvbnMg YXJlIGFkZGVkIGJ5IHRoZSBjb252ZXJ0ZXI/PGJyPg0KPGJyPg0KMikgVGhlIGZvbGxvd2luZyBw YXJhZ3JhcGggaW4gc2VjdGlvbiAzLjIuIHNlZW1zIHRvIHNwZWNpZnkgcHJvdG9jb2wgcmVxdWly ZW1lbnRzIGJ1dCBkb27igJl0IHVzZSBub3JtYXRpdmUgbGFuZ3VhZ2U6PGJyPg0KPGJyPg0KJnF1 b3Q7SWYgdGhlIGRvd25zdHJlYW0gKG9yIHVwc3RyZWFtKSBjb25uZWN0aW9uIGZhaWxzIGZvciBz b21lIHJlYXNvbjxicj4NCiZuYnNwOyAmbmJzcDsoZXhjZXNzaXZlIHJldHJhbnNtaXNzaW9ucywg cmVjZXB0aW9uIG9mIGFuIFJTVCBzZWdtZW50LCBldGMuKSwgdGhlbjxicj4NCiZuYnNwOyAmbmJz cDt0aGUgQ29udmVydGVyIHNob3VsZCBmb3JjZSB0aGUgdGVhci1kb3duIG9mIHRoZSB1cHN0cmVh bSAob3I8YnI+DQombmJzcDsgJm5ic3A7ZG93bnN0cmVhbSkgY29ubmVjdGlvbi48YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7VGhlIHNhbWUgcmVhc29uaW5nIGFwcGxpZXMgd2hlbiB0aGUgdXBzdHJl YW0gY29ubmVjdGlvbiBlbmRzLiZuYnNwOyBJbjxicj4NCiZuYnNwOyAmbmJzcDt0aGlzIGNhc2Us IHRoZSBDb252ZXJ0ZXIgc2hvdWxkIGFsc28gdGVybWluYXRlIHRoZSBkb3duc3RyZWFtPGJyPg0K Jm5ic3A7ICZuYnNwO2Nvbm5lY3Rpb24gYnkgdXNpbmcgRklOIHNlZ21lbnRzLiZuYnNwOyBJZiB0 aGUgZG93bnN0cmVhbSBjb25uZWN0aW9uPGJyPg0KJm5ic3A7ICZuYnNwO3Rlcm1pbmF0ZXMgd2l0 aCB0aGUgZXhjaGFuZ2Ugb2YgRklOIHNlZ21lbnRzLCB0aGUgQ29udmVydGVyIHNob3VsZDxicj4N CiZuYnNwOyAmbmJzcDtpbml0aWF0ZSBhIGdyYWNlZnVsIHRlcm1pbmF0aW9uIG9mIHRoZSB1cHN0 cmVhbSBjb25uZWN0aW9uLuKAnTxicj4NCjxicj4NCkkgcmVjb21tZW5kIHRvIHVzZSBub3JtYXRp dmVuIGxhbmd1YWdlIGhlcmUgKFNIT1VMRCBpbnN0ZWFkIG9mIHNob3VsZDsgb3IgbWF5YmUgZXZl biBNVVNUPykuIEhvd2V2ZXIsIGFzIHRoaXMgdGV4dCBpcyBwYXJ0IG9mIGEga2luZCBvZiBvdmVy dmlldyBzZWN0aW9uLCBpdCBkb2VzbuKAmXQgc2VlbSB0byBiZSBhIHJlYWxseSBnb29kIGZpdCB0 byB1c2Ugbm9ybWF0aXZlIGxhbmd1YWdlIGluIHRoYXQgc2VjdGlvbi4gU28gbWF5YmUgdGhlIHdo b2xlIGRpc2N1c3Npb24NCiBhYm91dCB1c2Ugb2YgVEZPIChvciBub3QpIHNob3VsZCBiZSBtb3Zl ZCB0byBhbiBvd24gc2VjdGlvbj88YnI+DQo8YnI+DQo8YnI+DQozKSBKdXN0IHRvIGRvdWJsZS1j aGVjaywgSSdtIHdvbmRlcmluZyBhIGJpdCBhYm91dCB0aGlzIHBocmFzaW5nIGluIHNlYyAzLjMu MTo8YnI+DQomcXVvdDtJZiBubyBlbnRyeSBpcyBmb3VuZCwgdGhlIFRyYW5zcG9ydCBDb252ZXJ0 ZXIgTVVTVCBzaWxlbnRseTxicj4NCiZuYnNwOyAmbmJzcDtpZ25vcmUgdGhlIHBhY2tldC7igJ08 YnI+DQpUaGF0IG1lYW5zIHRoZSBjb252ZXJ0ZXIgd2lsbCBkcm9wIHRoZSBwYWNrZXQgKHdpdGgg bm8gb3RoZXIgYWN0aW9uKSwgcmlnaHQ/IFdoeSBkbyB5b3UgdXNlIHRlcm0gaWdub3JlIGhlcmUg KGluc3RlYWQgb2YgZHJvcCBvciBkaXNjYXJkKT8gT3IgZG9lcyB0aGlzIGhhdmUgYW55IG90aGVy IGltcGxpY2F0aW9uPzxicj4NCk5vdGUgdGhhdCB0aGlzIHRlcm0gaXMgdXNlZCBzZXZlcmFsIHRp bWVzIGluIHRoZSBkb2MuPGJyPg0KPGJyPg0KNCkgQWxzbyBhIHF1aWNrIHF1ZXN0aW9uIGFib3V0 IHRoaXMgaW4gc2VjIDMuMy4xOjxicj4NCiZxdW90O0EgVHJhbnNwb3J0IENvbnZlcnRlciBtYXkg b3BlcmF0ZSBpbiBhZGRyZXNzIHByZXNlcnZhdGlvbiBtb2RlICh0aGF0PGJyPg0KJm5ic3A7ICZu YnNwO2lzLCB0aGUgQ29udmVydGVyIGRvZXMgbm90IHJld3JpdGUgdGhlIHNvdXJjZSBJUCBhZGRy ZXNzIChpLmUuLDxicj4NCiZuYnNwOyAmbmJzcDtDPT1UKSkgb3IgYWRkcmVzcyBzaGFyaW5nIG1v ZGUgKHRoYXQgaXMsIGFuIGFkZHJlc3MgcG9vbCBpcyBzaGFyZWQ8YnI+DQombmJzcDsgJm5ic3A7 YW1vbmcgYWxsIENsaWVudHMgc2VydmljZWQgYnkgdGhlIENvbnZlcnRlciAoaS5lLiwgQyE9VCkp OyByZWZlciB0bzxicj4NCiZuYnNwOyAmbmJzcDtBcHBlbmRpeCBEIGZvciBtb3JlIGRldGFpbHMu Jm5ic3A7IFdoaWNoIGJlaGF2aW9yIHRvIHVzZSBieSBhIFRyYW5zcG9ydDxicj4NCiZuYnNwOyAm bmJzcDtDb252ZXJ0ZXIgaXMgZGVwbG95bWVudC1zcGVjaWZpYy7igJ08YnI+DQpJIGd1ZXNzIHBy ZXNlcnZhdGlvbiBtb2RlIGNhbiBvbmx5IGJlIHVzZWQgaWYgdGhlIGNvbnZlcnRlciBpcyBvbiBw YXRoLiBJIHRoaW5rIHRoYXQgc2hvdWxkIGJlIGV4cGxpY2l0bHkgbm90ZWQgaGVyZS4NCjxicj4N Cjxicj4NCjUpIFNlYyAzLjMuMjogVG8gYmUgaG9uZXN0IEnigJltIG5vdCBzdXJlIEkgZnVsbHkg dW5kZXJzdGFuZCB0aGlzIHNlY3Rpb24sIGVzcGVjaWFsbHkgdGhpcyBzZW50ZW5jZTo8YnI+DQom cXVvdDtVcG9uIHJlY2VpcHQgb2YgYSBzZWNvbmRhcnkgc3ViZmxvdyBieSB0aGUgVHJhbnNwb3J0 IENvbnZlcnRlciBmcm9tIGE8YnI+DQombmJzcDsgJm5ic3A7Q2xpZW50LCB0aGUgQ29udmVydGVy IGZvbGxvd3MgdGhlIHNhbWUgYmVoYXZpb3Igc3BlY2lmaWVkIGluPGJyPg0KJm5ic3A7ICZuYnNw O1NlY3Rpb24gMy4zLjEgZm9yIHByb2Nlc3NpbmcgTm9uLVNZTnMu4oCdPGJyPg0KRG8geW91IG1l YW4gYnkgJnF1b3Q7cmVjZWlwdCBvZiBhIHNlY29uZGFyeSBzdWJmbG934oCdIHRoZSBTWU4gb24g dGhhdCBzdWJmbG93IG9yIG90aGVyIGRhdGE/IEZvciB0aGUgU1lOIEkgd291bGQgZXhwZWN0IHRo YXQgdGhlcmUgaXMgbm8gcGF5bG9hZCBkYXRhIGFuZCB0aGVyZWZvcmUgbm90aGluZyB0byBwcm94 eS4gRm9yIG90aGVyIHN1YmZsb3cgcGFja2V0cywgSSBndWVzcyB5b3UgbmVlZCB0byByZW9yZGVy IGZpcnN0LCBzbyBwcm9iYWJseSBpdCB3b3VsZA0KIGJlIGdvb2QgdG8gbWVudGlvbiB0aGF04oCm PyBNYXliZSBpdOKAmXMganVzdCBtZSBtaXN1bmRlcnN0YW5kaW5nIHNvbWV0aGluZyBidXQgSSBi ZWxpZXZlIG1vcmUgZXhwbGFuYXRpb24gaXMgbmVlZGVkIGhlcmUuPGJyPg0KPGJyPg0KNikgQ2Fu IHlvdSBtYXliZSBhZGQgc29tZSBtb3JlIHRleHQgKGluIHNlY3Rpb24gNSBtYXliZSkgd2h5IGEg c2VwYXJhdGUgcG9ydCBudW1iZXIgaXMgdXNlZC9uZWVkZWQ/IEFzIHRoZSBjbGllbnQgaGFzIHRv IGJlIGV4cGxpY2l0bHkgY29uZmlndXJlZCBpdCBjb3VsZCBlYXNpbHkgYmUgY29uZmlndXJlZCB3 aXRoIGFuIGFkZHJlc3MgYW5kIHBvcnQgbnVtYmVyLiBJcyB0aGlzIHRvIGF2b2lkIGNvbGxpc2lv bnMgd2l0aCBvdGhlciBwcm90b2NvbHM/DQogV2hhdCB3b3VsZCBiZSB0aGUgc2NlbmFyaW8gaGVy ZT88YnI+DQo8YnI+DQo3KSBTZWMgNS4xOjxicj4NCiZxdW90O1RoZSBVbmFzc2lnbmVkIGZpZWxk IE1VU1QgYmUgc2V0IHRvIHplcm8gaW4gdGhpcyB2ZXJzaW9uIG9mIHRoZTxicj4NCiZuYnNwOyAm bmJzcDtwcm90b2NvbC4mbmJzcDsgVGhlc2UgYml0cyBhcmUgYXZhaWxhYmxlIGZvciBmdXR1cmUg dXNlIFtSRkM4MTI2XS7igJ08YnI+DQpXaHkgaXMgdGhlcmUgYSByZWZlcmVuY2UgdG8gUkZDODEy NiBoZXJlPzxicj4NCjxicj4NCjgpIEFsc28gc2VjIDUuMSBidXQgcHJvYmFibHkgZWRpdG9yaWFs Ojxicj4NCiZxdW90O0RhdGEgYWRkZWQgYnkgdGhlIENvbnZlcnQgUHJvdG9jb2wgdG8gdGhlIFRD UCBieXRlc3RyZWFtIGlzPGJyPg0KJm5ic3A7ICZuYnNwO3VuYW1iaWd1b3VzbHkgZGlzdGluZ3Vp c2hlZCBmcm9tIHBheWxvYWQgZGF0YSBieSB0aGUgVG90YWwgTGVuZ3RoPGJyPg0KJm5ic3A7ICZu YnNwO2ZpZWxkIGluIHRoZSBDb252ZXJ0IG1lc3NhZ2VzLuKAnTxicj4NCkkgYmVsaWV2ZSB3aGF0 IHlvdSB3YW50IHRvIHNheSBoZXJlIGlzIHRoYXQgdGhlIHRvdGFsIGxlbmd0aCBpcyB1c2VkIHRv IGZpZ3VyZSBvdXQgd2hlcmUgcG90ZW50aWFsIG90aGVyIHBheWxvYWQgZGF0YSBtaWdodCBzdGFy dC4gSG93ZXZlciwgd2hhdCBJIHdvdWxkIHVuZGVyc3RhbmQgZnJvbSB0aGlzIHNlbnRlbmNlIGlz IHRoYXQgdGhlIHRvdGFsIGxlbmd0aCBmaWVsZCBjYW4gYmUgdXNlZCB0byBkaXN0aW5ndWlzaCBT WU5zIHRoYXQgY2FycnkNCiB0aGUgQ29udmVydCBwcm90b2NvbCBmcm9tIFNZTnMgdGhhdCBtYXkg Y2Fycnkgb3RoZXIgcGF5bG9hZCBvbmx5LCB3aGljaCBJIGRvbuKAmXQgdGhpbmsgaXMgdGhlIGNh c2UuPGJyPg0KPGJyPg0KOCkgSSBmaXJzdCBoYXZlIGEgbW9yZSBnZW5lcmFsIHF1ZXN0aW9uIGFi b3V0IHRoZSBmdW5jdGlvbiBvZiB0aGUgcHJvdG9jb2wuIFNlYyA1IHNheXM6PGJyPg0KJnF1b3Q7 Q29udmVydCBtZXNzYWdlcyBtYXkgYXBwZWFyIG9ubHkgaW4gYSBTWU4sIFNZTiYjNDM7QUNLLCBv ciBBQ0su4oCdPGJyPg0KSeKAmW0gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHRoZSBBQ0sgY2FzZSBo ZXJlIGJlY2F1c2UgaWYgeW91IGFkZCBhIENPTlZFUlQgbWVzc2FnZSB0byBhIFRDUCBwYWNrZXQg dGhhdCBtZWFucyB5b3UgYWRkIHBheWxvYWQgZGF0YS4gSSB3YXMgcmVhZGluZyB0aGlzIGFzIHB1 cmUgQUNLIGJ1dCB0aGF0IGNhbid0IGJlIHRoZSBjYXNlLiBTbyBkbyB5b3UgbWVhbiBieSB0aGlz IHlvdSBjYW4gb25seSBzZW5kIG5ldyBkYXRhIGlmIHlvdXIgcHJldmlvdXMgZGF0YQ0KIHdhcyBB Q0sgb3Igc29tZXRoaW5nIGVsc2XigKY/PGJyPg0KSG93ZXZlciwgSSBiZWxpZXZlIHRoZXJlIGlz IHVzdWFsbHkganVzdCBvbmUgbWVzc2FnZSBmcm9tIHRoZSBjbGllbnQgaW4gdGhlIFNZTiBhbmQg dGhlIG9uZSBtZXNzYWdlIGZyb20gdGhlIGNvbnZlcnRlciBpbiB0aGUgU1lOL0FDSywgYW5kIHRo ZW4gdGhlIGNvbm5lY3Rpb24gaXMgZWl0aGVyIGNsb3NlZCBvciBzd2l0Y2hlZCB0byB0aGUgYWN0 dWFsIHBheWxvYWQgdHJhbnNtaXNzaW9uLiBTbyBJIHdhcyBhc3N1bWluZyB0aGF0J3MgdGhlIG9u bHkNCiBjb21tdW5pY2F0aW9uIHBhdHRlcm4geW91IGNhbiBoYXZlLiBPciBpcyB0aGUgaWRlYSB0 aGF0IG11bHRpcGxlIGNsaWVudC1jb252ZXJ0ZXIgZXhjaGFuZ2VzIGNhbiBiZSBkb25lIG9uIHRo ZSBzYW1lIFRDUCBjb25uZWN0aW9uIGFsc28gYWZ0ZXIgdGhlIFRDUCBoYW5kc2hha2UgYW5kIHRo ZW4gYW55IHRpbWUgaW4gdGhlIGNvbm5lY3Rpb24geW91IHdvdWxkIGJlIGFibGUgdG8gc3dpdGNo IG92ZXIgdG8gc2VuZGluZyBvdGhlciBwYXlsb2FkIGRhdGE/DQogSSB0aGluayB0aGlzIG5lZWQg ZnVydGhlciBjbGFyaWZpY2F0aW9uIGluIHRoZSBkcmFmdC48YnI+DQo8YnI+DQpOb3RlIHRoYXQg c2VjdGlvbiA3IGFsc28gc2F5Ojxicj4NCiZxdW90O0luIHRoaXMgc2VjdGlvbiwgd2Ugb25seSBk aXNjdXNzPGJyPg0KJm5ic3A7ICZuYnNwO3RoZSBtaWRkbGVib3hlcyB0aGF0IG1vZGlmeSBTWU4g YW5kIFNZTiYjNDM7QUNLIHBhY2tldHMgc2luY2UgdGhlIENvbnZlcnQ8YnI+DQombmJzcDsgJm5i c3A7UHJvdG9jb2wgcGxhY2VzIGl0cyBtZXNzYWdlcyBpbiBzdWNoIHBhY2tldHMu4oCdPGJyPg0K PGJyPg0KOSkgVGhpcyBwb2ludCBpcyBwcm9iYWJseSByZWxhdGVkIHRvIHRoZSBwcmV2aW91cyBw b2ludC4gSW4gc2VjdGlvbiA1LjEgeW91IHNheSB0aGF0IHRoZSBjb25uZWN0aW9uIE1VU1QgYmUg cmVzZXQgKGlmIGxlbmd0aCBpcyB6ZXJvKSBidXQgaW4gYWxsIG90aGVyIHNlY3Rpb25zIHlvdSBz YXkgdGhlIGNvbm5lY3Rpb24gbXVzdCBiZSBjbG9zZWQgaWYgdGhlcmUgaXMgYSBwcm9ibGVtLiBB c3N1bWluZyB0aGUgQ29udmVydCBwcm90b2NvbCB3aWxsIG9ubHkNCiBiZSB1c2VkIGluIFNZTiBh bmQgU1lOL0FDSywgcmVzZXQgaXMgcHJvYmFibHkgbW9yZSBhcHByb3ByaWF0ZS4gSWYgaXQgY2Fu IGJlIHVzZWQgYWxzbyBpbiBsYXRlciBwYWNrZXRzIHlvdSBwcm9iYWJseSBoYXZlIHRvIHNheSBz b21ldGhpbmcgbGlrZSDigJxjbG9zZSBvciByZXNldCBpZiB0aGUgaGFuZHNoYWtlIGlzIG5vdCBj b21wbGV0ZWTigJ3igKY/DQo8YnI+DQo8YnI+DQpFLmcuIHNlZSBzZWMgNS4yLjE6PGJyPg0KJnF1 b3Q7SWYgdHdvIG9yIG1vcmU8YnI+DQombmJzcDsgJm5ic3A7aW5zdGFuY2VzIG9mIHRoZSBzYW1l IFRMViBhcmUgZXhjaGFuZ2VkIG92ZXIgYSBDb252ZXJ0IGNvbm5lY3Rpb24sPGJyPg0KJm5ic3A7 ICZuYnNwO3RoZSBhc3NvY2lhdGVkIFRDUCBjb25uZWN0aW9ucyBNVVNUIGJlIGNsb3NlZC7igJ08 YnI+DQpJcyB0aGF0IGNsb3NlIG9yIHJlc2V0PyA8YnI+DQo8YnI+DQpBbHNvIHJlbGF0ZWQ6PGJy Pg0KVGhlIG5leHQgc2VjdGlvbiAoNS4yLjIpIHNheXM6PGJyPg0KJnF1b3Q7VHlwZSAweDAgaXMg YSByZXNlcnZlZCB2YWx1ZWQuJm5ic3A7IEltcGxlbWVudGF0aW9ucyBNVVNUIGRpc2NhcmQgbWVz c2FnZXM8YnI+DQombmJzcDsgJm5ic3A7d2l0aCBzdWNoIFRMVi7igJ08YnI+DQooTml0IHMvdmFs dWVkL3ZhbHVlLyk8YnI+DQpBbmQgaW4gc2VjIDUuMi41Ojxicj4NCiZxdW90O0Nvbm5lY3QgVExW cyB3aXRjaCBzdWNoIG1lc3NhZ2VzIE1VU1QgYmUgZGlzY2FyZGVkIGJ5IHRoZSBUcmFuc3BvcnQ8 YnI+DQombmJzcDsgJm5ic3A7Q29udmVydGVyLiZxdW90Ozxicj4NCkkgZ3Vlc3MgZXZlcnkgdGlt ZSB5b3Ugc2F5IGluIHRoZSBkb2N1bWVudCB0aGF0IGEgbWVzc2FnZSBpcyBkaXNjYXJkZWQgdGhh dCB3b3VsZCZuYnNwOyBhbHNvIGxlYWQgc29tZWhvdyB0byBjbG9zaW5nIHRoZSBjb25uZWN0aW9u IG1vc3QgbGlrZWx5IGJ5IHRvIHNlbmRpbmcgYSByZXNldCwgbm8/IE9yIHNob3VsZCB0aGUgU1lO IGp1c3QgYmUgZHJvcCBhbmQgbm8gcmVwbHkgc2VuZCBmb3IgYW55IHJlYXNvbj8gUGxlYXNlIGNs YXJpZnkuPGJyPg0KPGJyPg0KMTApIFByb2JhYmx5IGVkaXRvcmlhbCBpbiBzZWMgNS4yLjQ6PGJy Pg0KJnF1b3Q7QSBUcmFuc3BvcnQgQ29udmVydGVyIFNIT1VMRCBpbmNsdWRlIGluIHRoaXM8YnI+ DQombmJzcDsgJm5ic3A7bGlzdCB0aGUgVENQIG9wdGlvbnMgdGhhdCBpdCBhY2NlcHRzIGZyb20g Q2xpZW50czsgdGhlc2Ugb3B0aW9ucyBhcmU8YnI+DQombmJzcDsgJm5ic3A7aW5jbHVkZWQgYnkg dGhlIFRyYW5zcG9ydCBDb252ZXJ0ZXIgaW4gdGhlIFNZTiBwYWNrZXRzIHRoYXQgaXQgc2VuZHM8 YnI+DQombmJzcDsgJm5ic3A7dG8gaW5pdGlhdGUgY29ubmVjdGlvbnMu4oCdPGJyPg0KSSBoYWQg dG8gcmVhZCB0aGUgc2Vjb25kIGhhbGYgdHdpY2UgYmVjYXVzZSBpdCBzdWRkZW5seSB0YWxrcyBh Ym91dCBhIGNvbXBsZXRlbHkgZGlmZmVyZW50IOKAnHNjZW5hcmlv4oCdIHRoYW4gcmVwbHlpbmcg dG8gYW4gSW5mbyBUTFYuIE1heWJlIHNvbWUgcmV3b3JkaW5nIGNvdWxkIGhlbHAgYSBiaXQgbGlr ZTxicj4NCiZxdW90O0EgVHJhbnNwb3J0IENvbnZlcnRlciBTSE9VTEQgaW5jbHVkZSBpbiB0aGlz PGJyPg0KJm5ic3A7ICZuYnNwO2xpc3QgdGhlIFRDUCBvcHRpb25zIHRoYXQgaXQgYWNjZXB0cyBm cm9tIENsaWVudHM7IHRoZXNlIG9wdGlvbnMgYXJlPGJyPg0KJm5ic3A7ICZuYnNwO2Fsc28gaW5j bHVkZWQgYnkgdGhlIFRyYW5zcG9ydCBDb252ZXJ0ZXIgaW4gdGhlIFNZTiBwYWNrZXRzIGlmIGl0 PGJyPg0KJm5ic3A7ICZuYnNwO2luaXRpYXRlcyBjb25uZWN0aW9ucyB0byB0aGUgY2xpZW50LuKA nTxicj4NCk9yIG1heWJlIGV2ZW4gdXNlIG5vcm1hdGl2ZSBsYW5ndWFnZSBoZXJlOiA8YnI+DQri gJx0aGUgVHJhbnNwb3J0IENvbnZlcnQgU0hPVUxEIGFsc28gaW5jbHVkZSB0aGUgc2FtZSBvcHRp b24gaW4gdGhlIFNZTiBpZiA8YnI+DQombmJzcDsgJm5ic3A7aXQgaW5pdGlhdGVzIGEgY29ubmVj dGlvbiB0byB0aGUgY2xpZW50LuKAnTxicj4NCjxicj4NCjExKSBzZWMgNS4yLjU6IE1heWJlIGFs c28gYmUgc2xpZ2h0bHkgbW9yZSBjbGVhciBoZXJlOjxicj4NCiZxdW90O0ZvciBpbmNvbWluZyBj b25uZWN0aW9ucyBkZXN0aW5lZCB0byBhIENsaWVudDxicj4NCiZuYnNwOyAmbmJzcDtzZXJ2aWNl ZCB2aWEgYSBUcmFuc3BvcnQgQ29udmVydGVyLCB0aGVzZSBmaWVsZHMgY29udmV5IHRoZSBzb3Vy Y2U8YnI+DQombmJzcDsgJm5ic3A7cG9ydCBudW1iZXIgYW5kIElQIGFkZHJlc3Mu4oCdPGJyPg0K UHJvcG9zZWQ8YnI+DQomcXVvdDtGb3IgaW5jb21pbmcgY29ubmVjdGlvbnMgZGVzdGluZWQgdG8g YSBDbGllbnQ8YnI+DQombmJzcDsgJm5ic3A7c2VydmljZWQgdmlhIGEgVHJhbnNwb3J0IENvbnZl cnRlciwgdGhlc2UgZmllbGRzIGNvbnZleSB0aGUgc291cmNlPGJyPg0KJm5ic3A7ICZuYnNwO3Bv cnQgbnVtYmVyIGFuZCBJUCBhZGRyZXNzIG9mIHRoZSBTWU4gcGFja2V0IHJlY2VpdmVkIGJ5IHRo ZSA8YnI+DQombmJzcDsgJm5ic3A7VHJhbnNwb3J0IENvbnZlcnRlciBmcm9tIHRoZSBzZXJ2ZXIu 4oCdPGJyPg0KPGJyPg0KMTIpIEkgaGF2ZSBhIGNvdXBsZSBvZiBxdWVzdGlvbiBhYm91dCB0aGUg VENQIG9wdGlvbnMgZmllbGQgaW4gdGhlIENvbm5lY3QgVExWLCBiYXNpY2FsbHkgdGhpcyB0ZXh0 IGluIHNlY3Rpb24gNS4yLjU6PGJyPg0KJnF1b3Q7Jm5ic3A7ICZuYnNwO1Vwb24gcmVjZXB0aW9u IG9mIGEgQ29ubmVjdCBUTFYsIGFuZCBhYnNlbnQgYW55IHBvbGljeSAoZS5nLiwgcmF0ZS08YnI+ DQombmJzcDsgJm5ic3A7bGltaXQpIG9yIHJlc291cmNlIGV4aGF1c3Rpb24gY29uZGl0aW9ucywg YSBUcmFuc3BvcnQgQ29udmVydGVyPGJyPg0KJm5ic3A7ICZuYnNwO2F0dGVtcHRzIHRvIGVzdGFi bGlzaCBhIGNvbm5lY3Rpb24gdG8gdGhlIGFkZHJlc3MgYW5kIHBvcnQgdGhhdCBpdDxicj4NCiZu YnNwOyAmbmJzcDtjb250YWlucy4mbmJzcDsgVGhlIFRyYW5zcG9ydCBDb252ZXJ0ZXIgTVVTVCB1 c2UgYnkgZGVmYXVsdCB0aGUgVENQPGJyPg0KJm5ic3A7ICZuYnNwO29wdGlvbnMgdGhhdCBjb3Jy ZXNwb25kIHRvIGl0cyBsb2NhbCBwb2xpY3kgdG8gZXN0YWJsaXNoIHRoaXM8YnI+DQombmJzcDsg Jm5ic3A7Y29ubmVjdGlvbi4mbmJzcDsgVGhlc2UgYXJlIHRoZSBvcHRpb25zIHRoYXQgaXQgYWR2 ZXJ0aXNlcyBpbiB0aGU8YnI+DQombmJzcDsgJm5ic3A7U3VwcG9ydGVkIFRDUCBFeHRlbnNpb25z IFRMVi48YnI+DQo8YnI+DQo8YnI+DQpCb25hdmVudHVyZSwgZXQgYWwuJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IEV4cGlyZXMgTWF5IDcsIDIwMjAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tQYWdlIDIyXTxicj4NCkludGVy bmV0LURyYWZ0Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IENvbnZlcnQgUHJvdG9jb2wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Tm92ZW1iZXIgMjAxOTxicj4NCjxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDtVcG9uIHJlY2VwdGlvbiBvZiBhbiBleHRlbmRlZCBDb25uZWN0IFRMViwgYW5kIGFic2VudCBh bnkgcmF0ZSBsaW1pdDxicj4NCiZuYnNwOyAmbmJzcDtwb2xpY3kgb3IgcmVzb3VyY2UgZXhoYXVz dGlvbiBjb25kaXRpb25zLCBhIFRyYW5zcG9ydCBDb252ZXJ0ZXIgTVVTVDxicj4NCiZuYnNwOyAm bmJzcDthdHRlbXB0IHRvIGVzdGFibGlzaCBhIGNvbm5lY3Rpb24gdG8gdGhlIGFkZHJlc3MgYW5k IHBvcnQgdGhhdCBpdDxicj4NCiZuYnNwOyAmbmJzcDtjb250YWlucy4mbmJzcDsgSXQgTVVTVCBp bmNsdWRlIHRoZSBvcHRpb25zIG9mIHRoZSAnVENQIE9wdGlvbnMnIHN1Yi1maWVsZDxicj4NCiZu YnNwOyAmbmJzcDtpbiB0aGUgU1lOIHNlbnQgdG8gdGhlIFNlcnZlciBpbiBhZGRpdGlvbiB0byB0 aGUgVENQIG9wdGlvbnMgdGhhdCBpdDxicj4NCiZuYnNwOyAmbmJzcDt3b3VsZCBoYXZlIHVzZWQg YWNjb3JkaW5nIHRvIGl0cyBsb2NhbCBwb2xpY2llcy4mbmJzcDsgRm9yIHRoZSBUQ1Agb3B0aW9u czxicj4NCiZuYnNwOyAmbmJzcDt0aGF0IGFyZSBsaXN0ZWQgd2l0aG91dCBhbiBvcHRpb25hbCB2 YWx1ZSwgdGhlIFRyYW5zcG9ydCBDb252ZXJ0ZXI8YnI+DQombmJzcDsgJm5ic3A7TVVTVCBnZW5l cmF0ZSBpdHMgb3duIHZhbHVlLiZuYnNwOyBGb3IgdGhlIFRDUCBvcHRpb25zIHRoYXQgYXJlIGlu Y2x1ZGVkPGJyPg0KJm5ic3A7ICZuYnNwO2luIHRoZSAnVENQIE9wdGlvbnMnIGZpZWxkIHdpdGgg YW4gb3B0aW9uYWwgdmFsdWUsIGl0IE1VU1QgY29weSB0aGU8YnI+DQombmJzcDsgJm5ic3A7ZW50 aXJlIG9wdGlvbiBmb3IgdXNlIGluIHRoZSBjb25uZWN0aW9uIHdpdGggdGhlIGRlc3RpbmF0aW9u IHBlZXIuPGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMgZmVhdHVyZSBpcyByZXF1aXJlZCB0byBzdXBw b3J0IFRDUCBGYXN0IE9wZW4u4oCdPGJyPg0KPGJyPg0KRmlyc3Qgb2YgYWxsIHRoZSB1cHBlciBw YXJhZ3JhcGggaXMgcHJvYmFibHkgb2xkIGFuZCBzaG91bGQgaGF2ZSBiZWVuIHJlbW92ZWQsIHJp Z2h0Pzxicj4NCjxicj4NClRoZW4gSeKAmW0gbm90IGNlcnRhaW4gYWJvdXQgdGhlIG5ldyBhcHBy b2FjaCB3aXRoIHRoZSBUQ1Agb3B0aW9uIGZpZWxkLiBJZiB0aGUgY29udmVydGVyIGFjdHVhbGx5 IGVuZHMgdXAgaW4gYSBzcGxpdCBjb25uZWN0aW9uICh3aXRoIGUuZy4gTVBUQ1Agb24gY2xpZW50 IHNpZGUgYnV0IHdpdGhvdXQgaXQgb24gc2VydmVyIHNpZGUpLCBJIHRob3VnaHQgaXQgY2FuIG9u bHkgYW5ub3VuY2UgdGhvc2Ugb3B0aW9ucyBpbiB0aGUgU1lOIHRvIHRoZSBzZXJ2ZXINCiB0aGF0 IGFyZSBhY3R1YWxseSBpbXBsZW1lbnRlZCBpbiB0aGUgY29udmVydGVyIGFuZCBpdCB3aWxsIGJl IGFibGUgdG8gc3VwcG9ydCBsYXRlciBpbiB0aGUgY29ubmVjdGlvbi4gU28gYmxpbmRseSBjb3B5 aW5nIHRoZSBvcHRpb25zIHByb3ZpZGVkIGJ5IHRoZSBjbGllbnQgZG9lc27igJl0IHNlZW0gcmln aHQuIE9yIHdoYXQgZG8gSSBtaXNzPzxicj4NCjxicj4NCkkgdW5kZXJzdGFuZCB0aGUgY2FzZSB3 aGVyZSB5b3Ugd2FudCB0byB1c2UgVEZPIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIGNvbnZl cnQgYnV0IGNhbuKAmXQgdXNlIGl0IGFueW1vcmUgYmV0d2VlbiB0aGUgdGhlIGNsaWVudCBhbmQg dGhlIHNlcnZlciB0aGVuLiBIb3dldmVyIHlvdSBjYW4gb25seSB1c2UgVEZPIHdpdGggdGhlIHNl Y29uZCBjb25uZWN0aW9uIHlvdSBtYWtlIHRvIGEgc2VydmVyLiBTbyBpbiB0aGUgZmlyc3QgY29u bmVjdGlvbg0KIGVpdGhlciBURk8gd2FzIHVzZWQgYmV0d2VlbiB0aGUgY29udmVydCBhbmQgdGhl IHNlcnZlciBhbmQgdGhlIGNvbnZlcnQgY291bGQgbm93IHVzZSBpdCBhZ2FpbiB3aXRoIHRoZSBj b29raWUgaXQgcmVjZWl2ZWQgb3IgVEZPIHdhcyB1c2VkIGVuZC10by1lbmQgaW4gdGhlIGZpcnN0 IGNvbm5lY3Rpb24gYW5kIGl0IG5vdyBjbGVhciB0byBtZSB3aHkgdGhlIGNvbnZlcnRlciBpcyB1 c2VkIG5vdy4gTWF5YmUgSeKAmW0gbWlzc2luZyBzb21ldGhpbmcgYnV0DQogSSB0aGluayB0aGUg ZHJhZnRzIHdvdWxkIGF0IGxlYXN0IG5lZWQgbW9yZSBleHBsYW5hdGlvbiBhYm91dCB0aGUgbW90 aXZhdGlvbiB0byBoYXZlIHRoaXMuPGJyPg0KPGJyPg0KSWYgaXTigJlzIHJlYWxseSBvbmx5IGFi b3V0IFRGTyBjb29raWVzIGFuZCB3ZSBhcmUgc3VyZSB3ZSB3YW50IHRvIGhhdmUgdGhhdCBmZWF0 dXJlLCBtYXliZSBhbiBvd24gVExWIHdvdWxkIGJlIHNpbXBsZXI/PGJyPg0KPGJyPg0KMTMpIElu IHNlYyA1LjIuNiBkbyB5b3UgbWVhbiBieSAmcXVvdDtleHRlbmRlZCBUQ1AgaGVhZGVy4oCdIHRo ZSBUQ1Agb3B0aW9uIHNwYWNlPyBJ4oCZbSBub3Qgc3VyZSB0aGF0ICZxdW90O2V4dGVuZGVkIFRD UCBoZWFkZXLigJ0gaXMgYSBjbGVhcmx5IGRlZmluZWQgdGVybTsgYXMgbGVhc3QgSeKAmW0gbm90 IDEwMCUgc3VyZSB3aGF0IHlvdSBtZWFu4oCmPGJyPg0KPGJyPg0KMTQpIG5pdCBpbiBzZWMgNS4y Ljc6PGJyPg0Kcy9UaGUgQ29va2llIFRMViAoRmlndXJlIDIwIGlzIGFuIG9wdGlvbmFsL1RoZSBD b29raWUgVExWIChGaWd1cmUgMjApIGlzIGFuIG9wdGlvbmFsLyAtJmd0OyBtaXNzaW5nIGNsb3Np bmcgYnJhY2tldDxicj4NCjxicj4NCjE1KSBTZWMgNS4yLjc6PGJyPg0KUXVlc3Rpb24gYWJvdXQg bm9ybWF0aXZlIGxhbmd1YWdlOjxicj4NCiZxdW90O0lmIHRoZSByZWNlaXZlZCBTWU4gZGlkIG5v dCBjb250YWluIGEgQ29va2llIFRMViwgYW5kIGNvb2tpZTxicj4NCiZuYnNwOyAmbmJzcDt2YWxp ZGF0aW9uIGlzIHJlcXVpcmVkLCB0aGUgVHJhbnNwb3J0IENvbnZlcnRlciBzaG91bGQgY29tcHV0 ZSBhPGJyPg0KJm5ic3A7ICZuYnNwO0Nvb2tpZSBib3VuZCB0byB0aGlzIENsaWVudCBhZGRyZXNz IGFuZCByZXR1cm4gYSBDb252ZXJ0IG1lc3NhZ2U8YnI+DQombmJzcDsgJm5ic3A7Y29udGFpbmlu ZyB0aGUgZml4ZWQgaGVhZGVyLCBhbiBFcnJvciBUTFYgc2V0IHRvICZxdW90O01pc3NpbmcgQ29v a2llJnF1b3Q7IGFuZDxicj4NCiZuYnNwOyAmbmJzcDt0aGUgY29tcHV0ZWQgQ29va2llIGFuZCBj bG9zZSB0aGUgY29ubmVjdGlvbi7igJ08YnI+DQpJcyB0aGlzIG1heWJlIGEgTUFZIGNvbmRpdGlv bj8gQWxsIG9mIGl0PyBPciBzb21ldGhpbmcgbGlrZSB0aGlzPGJyPg0KJnF1b3Q7SWYgdGhlIHJl Y2VpdmVkIFNZTiBkaWQgbm90IGNvbnRhaW4gYSBDb29raWUgVExWLCBhbmQgY29va2llPGJyPg0K Jm5ic3A7ICZuYnNwO3ZhbGlkYXRpb24gaXMgcmVxdWlyZWQsIHRoZSBUcmFuc3BvcnQgQ29udmVy dGVyIE1BWSBjb21wdXRlIGE8YnI+DQombmJzcDsgJm5ic3A7Q29va2llIGJvdW5kIHRvIHRoaXMg Q2xpZW50IGFkZHJlc3MuIEl0IE1VU1QgcmV0dXJuIGEgQ29udmVydCBtZXNzYWdlPGJyPg0KJm5i c3A7ICZuYnNwO2NvbnRhaW5pbmcgdGhlIGZpeGVkIGhlYWRlciBhbmQgRXJyb3IgVExWIHNldCB0 byAmcXVvdDtNaXNzaW5nIENvb2tpZeKAnSBhbmQgTUFZIGFkZDxicj4NCiZuYnNwOyAmbmJzcDt0 aGUgY29tcHV0ZWQgQ29va2llLiBBZnRlciBzZW5kaW5nIHRoZSBFcnJvciBUTFYgaXMgTVVTVC9T SE9VTEQgY2xvc2UvcmVzZXQmbmJzcDsgJm5ic3A7PGJyPg0KJm5ic3A7ICZuYnNwO3RoZSBjb25u ZWN0aW9uLuKAnTxicj4NCk5vdCBmdWxseSBzdXJlIHdoYXQgaXMgdGhlIGludGVudGlvbiBoZXJl 4oCmPGJyPg0KPGJyPg0KMTUpIHNlYyA1LjIuODo8YnI+DQpXaGF0J3MgdGhlIHB1cnBvc2Ugb2Yg dGhlIGNsaWVudCBzZW5kaW5nIGFuIFVuc3VwcG9ydGVkIFZlcnNpb24gZXJyb3I/IElmIHRoZSBj b252ZXJ0ZXIgcmVwbGllcyB3aXRoIGEgZGlmZmVyZW50IHZlcnNpb24gdGhhbiByZXF1ZXN0ZWQg dXNlZCBieSB0aGUgY2xpZW50LCB0aGF0J3Mgc2ltcGx5IGEgZmF0YWwgZXJyb3IvaW1wbGVtZW50 YXRpb24gZXJyb3IgYW5kIHRoZSBjbGllbnQgY2FuIG9ubHkgcmVzZXQgdGhlIGNvbm5lY3Rpb24g SSB0aGluay48YnI+DQo8YnI+DQpNb3JlIGdlbmVyYWxseSBpZiBJIHJlYWQgdGhpcyBjb3JyZWN0 bHkgdGhlcmUgYXJlIG9ubHkgMyBlcnJvcnMgdGhhdCBjb3VsZCBiZSBzZW50IGJ5IHRoZSBjbGll bnQuIEkgZ3Vlc3MgdGhvc2UgZXJyb3JzIHdvdWxkIGJlIHNlbmQgaW4gdGhlIGZpcnN0IHBhY2tl dCBhZnRlciB0aGUgU1lOL0FDSyBpcyByZWNlaXZlZOKApj8gUmVsYXRlZCB0byBteSBxdWVzdGlv biBhYm92ZSwgSSB0aGluayBpdCB3b3VsZCBiZSBtdWNoIGVhc2llciB0byBvbmx5IGhhdmUNCiBD b252ZXJ0IG1lc3NhZ2UgaW4gdGhlIFNZTiBhbmQgU1lOL0FDSyBhbmQgbm8gZXhwbGljaXQgZXJy b3IgbWVzc2FnZSBmcm9tIHRoZSBjbGllbnQuIE90aGVyd2lzZSBtb3JlIGV4cGxhbmF0aW9uIGlu IHRoZSBkcmFmdCB3b3VsZCBiZSBuZWVkIGhvdyB0aGlzIGFjdHVhbGx5IGlzIHN1cHBvc2VkIHRv IHdvcmsuPGJyPg0KPGJyPg0KMTYpIHNlYyA1LjIuODo8YnI+DQomcXVvdDtBIENsaWVudCB3aGlj aCByZWNlaXZlcyB0aGlzIGVycm9yIGNvZGUgTVVTVCBjYWNoZSB0aGUgcmVjZWl2ZWQ8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyBDb29raWUgYW5kIGluY2x1ZGUgaXQgaW4gc3Vic2VxdWVudCBD b252ZXJ0IG1lc3NhZ2VzIHNlbnQgdG8gdGhhdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IFRy YW5zcG9ydCBDb252ZXJ0ZXIu4oCdPGJyPg0KVGhpcyBzZWVtcyB0byBiZSBhIHNsaWdodGx5IHdl aXJkIG5vcm1hdGl2ZSBNVVNULiBTdXJlIHlvdSBoYXZlIHRvIGNhY2hlIHRoZSBjb29raWUgaW4g b2RlciB0byBiZSBhYmxlIHRvIHVzZSB0aGUgY29udmVydGVyLCBob3dldmVyLCB0aGVyZSBtYXkg YmUgY2FzZXMgd2hlcmUgeW91IGxvb3NlIHRoZSBjYWNoZSBhbmQgdGhlbiBzZW5kaW5nIGEgQ29u bmVjdCB3aXRob3V0IHRoZSBjb29raWUgdG8gZ2V0IGEgbmV3IENvb2tpZSBpcyBhIHZhbGlkIG9w dGlvbi4NCiBTbyB5b3UgbWF5IHVzZSBTSE9VTEQgaGVyZSBvciBldmVuIGJldHRlciByZXdvcmQg aXQgY29tcGxldGVseS4uLjxicj4NCjxicj4NCjE3KSBUaGVyZSBpcyBhbiBVbnN1cHBvcnRlZCBU Q1AgT3B0aW9uIGluIHNlY3Rpb24gNS4yLjguIEhvd2V2ZXIsIHRoaXMgZXJyb3IgaXMgbm90IG1l bnRpb25lZCBpbiA1LjIuNS4gSW4gY29udHJhc3Qgc2VjIDUuMi41IHNheXMgdGhhdCB0aGUgY29u dmVydGVyIE1VU1Qgb3BlbiBhIGNvbm5lY3Rpb24gYW5kIE1VU1QgdXNlIHRoZXNlIG9wdGlvbnMu IFRoaXMgaXMgcmVsYXRlZCB0byBteSBwb2ludCAxMiBhYm92ZSBidXQgaXQgd2FzIG5vdCBjbGVh cg0KIHRvIG1lIHRoYXQgb3B0aW9ucyBjYW4gYmUgcmVqZWN0ZWQsIGhvd2V2ZXIsIHRoaXMgd2hv bGUgcGFydCBzZWVtcyB0byBtYWtlIHRoZSBwcm90b2NvbCByZWFsbHkgY29tcGxpY2F0ZWQgYW5k IGFzIEkgc2FpZCBpZiB0aGUgb25seSB1c2UgY2FzZSBpcyBURk8gSSB3b3VsZCBwcmVmZXIgdG8g cmF0aGVyIGhhdmUgYSBzZXBhcmF0ZSBzcGVjaWZpYyBUTFYgZm9yIHRoYXQgY2FzZSBvbmx5Ljxi cj4NCjxicj4NCjE4KSBJIHRoaW5rIHNlY3Rpb24gNi43IHNob3VsZCBzdGlsbCBzYXkgc29tZXRo aW5nIGFib3V0IGlmIHRoaXMgb3B0aW9uIGlzIHN1cHBvcnRlZCBvciBub3TigKY8YnI+DQo8YnI+ DQoxOSkgc2VjdGlvbiA3Ojxicj4NCiZxdW90O0NvbnNpZGVyIGEgbWlkZGxlYm94IHRoYXQgcmVt b3ZlcyB0aGUgU1lOIHBheWxvYWQuJm5ic3A7IFRoZSBDbGllbnQgY2FuPGJyPg0KJm5ic3A7ICZu YnNwO2RldGVjdCB0aGlzIHByb2JsZW0gYnkgbG9va2luZyBhdCB0aGUgYWNrbm93bGVkZ21lbnQg bnVtYmVyIGZpZWxkIG9mPGJyPg0KJm5ic3A7ICZuYnNwO3RoZSBTWU4mIzQzO0FDSyByZXR1cm5l ZCBieSB0aGUgVHJhbnNwb3J0IENvbnZlcnRlci4mbmJzcDsgVGhlIENsaWVudCBNVVNUPGJyPg0K Jm5ic3A7ICZuYnNwO3N0b3AgdG8gdXNlIHRoaXMgVHJhbnNwb3J0IENvbnZlcnRlciBnaXZlbiB0 aGUgbWlkZGxlYm94PGJyPg0KJm5ic3A7ICZuYnNwO2ludGVyZmVyZW5jZS7igJ08YnI+DQpJZiB0 aGUgY29udmVydGVyIHJlY2VpdmVkIGEgU1lOIHdpdGhvdXQgYSBDb252ZXJ0IG1lc3NhZ2UgaW4g dGhlIHBheWxvYWQgb24gdGhlIHJlc3BlY3RpdmUgcG9ydCwgaXQgaXMgc3VwcG9zZWQgdG8gYW55 d2F5IHNlbmQgYSBTWU4vQUNLPyBJIHdvdWxkIGFzc3VtZSBpdCB3b3VsZCByYXRoZXIgc2VuZCBh IFJFU0VULCBubz8gSSB0aGluayB0aGF0IG5lZWRzIHRvIGJlIGZ1cnRoZXIgc3BlY2lmaWVkLjxi cj4NCjxicj4NCjIwKSBTZWMgNyBhbHNvIHNheXM6PGJyPg0K4oCcSWYgYW4gRXJyb3Igd2FzIHJl dHVybmVkIGJ5IHRoZSBUcmFuc3BvcnQgQ29udmVydGVyLCBhIG1lc3NhZ2UgdG8gY2xvc2U8YnI+ DQombmJzcDsgJm5ic3A7dGhlIGNvbm5lY3Rpb24gd291bGQgbm9ybWFsbHkgZm9sbG93IGZyb20g dGhlIENvbnZlcnRlci7igJ08YnI+DQpIb3dldmVyIHNlYyA1LjIuOCBzYXlzOjxicj4NCiZxdW90 O1Vwb24gcmVjZXB0aW9uIG9mIGFuIEVycm9yIFRMViwgYTxicj4NCiZuYnNwOyAmbmJzcDtDbGll bnQgTVVTVCBjbG9zZSB0aGUgYXNzb2NpYXRlZCBjb25uZWN0aW9uLuKAnTxicj4NCkkgYXNzdW1l IG9uZSBvZiB0aGVzZSBpcyBub3QgY29ycmVjdOKApiBwbGVhc2UgY2xhcmlmeSB3aGljaCBlbmQg aXMgc3VwcG9zZSB0byBkbyB3aGF0IGluIGNhc2Ugb2YgYW4gZXJyb3IuPGJyPg0KPGJyPg0KMjEp IFRoZSB0ZXh0IGluIHNlYyA3IHRoZW4gZnVydGhlciBzYXlzOjxicj4NCiZxdW90O0lmIG5vIHN1 Y2g8YnI+DQombmJzcDsgJm5ic3A7bWVzc2FnZSBpcyByZWNlaXZlZCwgdGhlIENsaWVudCBtYXkg Y29udGludWUgdG8gdXNlIHRoaXMgQ29udmVydGVyLuKAnTxicj4NCklzbuKAmXQgdGhhdCBhIGJp dCBkYW5nZXJvdXM/Jm5ic3A7IDxicj4NCjxicj4NCjIyKSBzZWN0aW9uIDguNTogV2h5IGFyZSB0 aGUgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtIGRpc2N1c3NlZCBpbiB0aGlzIHNlY3Rpb24gTVBU Q1Agc3BlY2lmaWM/IEkgdGhpbmsgdGhlIHNhbWUgbWVjaGFuaXNtcyBjb3VsZCBhbHNvIGJlIGFw cGxpZWQgdG8gQ29udmVydGVycyBzdXBwb3J0aW5nIG90aGVyIG9wdGlvbnMsIG5vPzxicj4NCjxi cj4NCjIzKSBzZWMgOC4zOjxicj4NCiZxdW90O01lYW5zIHRvIHByb3RlY3QgYWdhaW5zdCBTWU4g Zmxvb2RpbmcgYXR0YWNrcyBNVVNUIGFsc28gYmUgZW5hYmxlZCBbUkZDNDk4N10u4oCdPGJyPg0K Tm90IHN1cmUgaWYgdGhlIHVzZSBvZiBNVVNUIGlzIGNsZWFyIGhlcmUuIFdoaWNoIHBhcnQgb2Yg UkZDNDk4NyBkb2VzIHRoaXMgTVVTVCByZWxhdGUgdG8/IEFsbCBvZiBpdD8gTWF5YmUgYSBTSE9V TEQgb3Igbm8gbm9ybWF0aXZlIGxhbmd1YWdlIGlzIG1vcmUgYXBwcm9wcmlhdGU/PGJyPg0KPGJy Pg0KMjQpIHNlYyA5LjI6IE1heWJlIGNhbGwgdGhlIG5ldyByZWdpc3RyeSB0aGUgJnF1b3Q7VGhl IFRDUCBDb252ZXJ0IFByb3RvY29sIChDb252ZXJ0KTxicj4NCiZuYnNwOyAmbmJzcDtQYXJhbWV0 ZXJz4oCdIChUQ1AgYWRkZWQp4oCmPzxicj4NCjxicj4NCjI1KSBzZWMgOS4yLjI6PGJyPg0KJnF1 b3Q7VGhlIHZhbHVlcyBpbiB0aGUgcmFuZ2UgMTkyLTI1NSBjYW4gYmUgYXNzaWduZWQgZm9yIFBy aXZhdGUgVXNlLuKAnTxicj4NCklBTkEgZG9lcyBub3QgYXNzaWduZWQgYW55IHZhbHVlIGZvciBQ cml2YXRlIHVzZSwgdGhleSBjYW4ganVzdCBiZSB1c2VkLCBzbyB0aGlzIHNob3VsZCBiZTxicj4N CiZxdW90O1RoZSB2YWx1ZXMgaW4gdGhlIHJhbmdlIDE5Mi0yNTUgYXJlIHJlc2VydmVkIGZvciBQ cml2YXRlIFVzZS7igJ08YnI+DQppZiB0aGF0IGlzIHdoYXQgeW91IHdhbnQ/PGJyPg0KPGJyPg0K MjYpIGFsc28gb24gc2VjdGlvbiA5LjIuWDogJnF1b3Q7U3BlY2lmaWNhdGlvbiBSZXF1aXJlZCZx dW90OyBpbmNsdWRlcyBoYXZpbmcgYW4gZXhwZXJ0IHJldmlldyBhbmQgUkZDODEyNiBzYXlzOjxi cj4NCiZxdW90O0FzIHdpdGggRXhwZXJ0IFJldmlldyAoU2VjdGlvbiA0LjUpLCBjbGVhciBndWlk YW5jZSB0byB0aGUgZGVzaWduYXRlZDxicj4NCiZuYnNwOyAmbmJzcDtleHBlcnQgc2hvdWxkIGJl IHByb3ZpZGVkIHdoZW4gZGVmaW5pbmcgdGhlIHJlZ2lzdHJ5LCBhbmQgdGhvcm91Z2g8YnI+DQom bmJzcDsgJm5ic3A7dW5kZXJzdGFuZGluZyBvZiBTZWN0aW9uIDUgaXMgaW1wb3J0YW50LuKAnTxi cj4NClNvIHBsZWFzZSBwcm92aWRlIGZ1cnRoZXIgZ3VpZGFuY2UgYWJvdXQgd2hhdCB0aGUgZXhw ZXJ0IGlzIHN1cHBvcnRlZCB0byBldmFsdWF0ZS4NCjxicj4NCjxicj4NCjI3KSBOb3Qgc3VyZSBp ZiB0aGUgZm9sbG93aW5nIHJlZmVyZW5jZXMgbmVlZCB0byBiZSBub3JtYXRpdmUgYXMgdGhlcmUg bm8gbm9ybWF0aXZlIHJlcXVpcmVtZW50IGNvbm5lY3QgdG8gdGhlbSBidXQgb25seSBhbiBvcHRp b25hbCBjYXNlIGlzIGRpc2N1c3NlZDogUkZDNDI3OSwgUkZDNzI1MCDigKY/PGJyPg0KPGJyPg0K SG93ZXZlciwgUkZDNzMyMywgUkZDMjAxOCwgUkZDNjk3OCwgUkZDNjk3OCwgUkZDMjgyNywgUkZD NjE4MSBzaG91bGQgcHJvYmFibHkgYmUgbm9ybWF0aXZlIHJlZmVyZW5jZXPigKY/PGJyPg0KPGJy Pg0KMjgpIFRoZSB0ZXJtIOKAnGV4cGVyaW1lbnRhbCBvcHRpb27igJ0gaXMgdXNlZCB3aXRoIHR3 byBkaWZmZXJlbnQgbWVhbmluZyBpbiB0aGUgaW50cm8gb2Ygc2VjdGlvbiA2IChvcHRpb25zIHRo YXQgYXJlIGRlZmluZWQgaW4gYW4gZXhwIFJGQykgYW5kIGluIHNlY3Rpb24gNi45IChvcHRpb25z IHdpdGgga2luZCAyNTQgYW5kIDI1NSkuIFBsZWFzZSBjbGFyaWZ5IHRoaXMgYXQgYm90aCBwbGFj ZXMuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8ZGl2Pg0KPGhyPg0KPGJy Pg0KPC9kaXY+DQo8ZGl2PkRpc2NsYWltZXI6IDxhIGhyZWY9Imh0dHBzOi8vd3d3LnRlc3NhcmVz Lm5ldC9tYWlsLWRpc2NsYWltZXIvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy50ZXNz YXJlcy5uZXQvbWFpbC08d2JyPmRpc2NsYWltZXIvPC9hPjwvZGl2Pg0KPGJyPg0KPGJyPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_6EC6417807D9754DA64F3087E2E2E03E2D8F5326rznt8114rzntrzd_-- From nobody Wed Jan 29 16:34:08 2020 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F3E120044; Wed, 29 Jan 2020 16:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.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 8ZRVcEv0j5jY; Wed, 29 Jan 2020 16:34:03 -0800 (PST) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 628EE12003E; Wed, 29 Jan 2020 16:34:03 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 466D525A1A; Thu, 30 Jan 2020 01:28:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1580344132; bh=hkD1jqjMzEUxra10TEcPsGLV6OBBX1kLUDhRDgeyge8=; h=From:To:Subject:Date:From; b=h+jLdXEpavd7IUbzVgthcGThcjyhpfgJPkXY3ewsSTCU5wXILSEX6WS4KB+r5rORI raXcvgmmZCIYGtVsSgHr3CptBvz2YseOJmkPbsbnVryQVelV73mkYLBMlvUMHcTvz0 patn791OOY2sZkfKn+eF8n8sLDWHXsD9BHFETMfc= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CphaXZlJ2gk; Thu, 30 Jan 2020 01:28:51 +0100 (CET) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Thu, 30 Jan 2020 01:28:51 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.158]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Thu, 30 Jan 2020 01:28:50 +0100 From: "Scharf, Michael" To: "draft-ietf-tcpm-2140bis@ietf.org" , tcpm IETF list Thread-Topic: draft-ietf-tcpm-2140bis-01 Thread-Index: AdXXBD5ZlKpuoT6/SW2lbStjVIvRxA== Date: Thu, 30 Jan 2020 00:28:50 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D8FD745@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D8FD745rznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: [tcpm] draft-ietf-tcpm-2140bis-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 00:34:06 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D8FD745rznt8114rzntrzd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgaGF2ZSByZWFkIHRoZSBtb3N0IHJlY2VudCB2ZXJzaW9uIG9mIDIxNDBiaXMuIEFz IHVzdWFsbHksIG15IGNvbW1lbnRzIGFyZSBwb3N0ZWQgd2l0aCBjaGFpciBoYXQgb2ZmLg0KDQpJ IGVuY291cmFnZSBvdGhlcnMgdG8gYWxzbyByZWFkIHRoZSBkb2N1bWVudC4NCg0KSXNzdWVzIC8g Y29tbWVudHM6DQoNCg0KICAqICAgVGhlIGRvY3VtZW50IHN0cnVjdHVyZSBmb2xsb3dzIGluIG1h bnkgY2FzZXMgZXhhY3RseSBSRkMgMjE0MCwgZXZlbiBpZiBjb250ZW50IGhhcyBjaGFuZ2VkLiBJ biBzb21lIGNhc2VzLCB0aGlzIGNvbmZ1c2VzIG1lLiBGb3IgaW5zdGFuY2UsIHRoZSBTZWN0aW9u IOKAnkFuIEVuc2FtcGxlIG9mIFRlbXBvcmFsIFNoYXJpbmfigJwgaW4gUkZDIDIxNDAgaW5kZWVk IGNvbnRhaW5lZCBhbiBpbXBsZW1lbnRhdGlvbiBleGFtcGxlLiBTZWN0aW9uIDYgb2YgUkZDIDIx NDBiaXMgaXMgZ2VuZXJpYy4gVGhpcyByYWlzZXMgYXQgbGVhc3QgdHdvIHF1ZXN0aW9ucyBmw7xy IFNlY3Rpb24gNiBhbmQgc2ltaWxhcmx5IGZvciBTZWN0aW9uIDc6DQoNCiAgMS4gIElzIHRoZSB0 aXRsZSBmb3IgdGhlIHNlY3Rpb24gc3RpbGwgYXBwcm9wcmlhdGU/DQogIDIuICBJcyBzb21lIGFk ZGl0aW9uYWwgZXhwbGFuYXRpb24gbmVlZGVkIGUuZy4gb24gcGFnZSA2IHRoYXQgYW4gaW1wbGVt ZW50YXRpb24gY2FuIGRlY2lkZSB0byBpbXBsZW1lbnQgb25seSBzdWJzZXRzIG9mIHRoZSB0YWJs ZSBvbiBwYWdlIDYsIGFzIGFuIGVhcmx5IGhlYWRzLXVwPw0KDQogICogICBTZWN0aW9ucyA2LCA3 LCA4LCA5IGFuZCAxMCBhcmUgbG9uZ2VyIHRoYW4gdGhlIG9yaWdpbmFsIDIxNDAuIEkgd29uZGVy IGlmIHN1YnNlY3Rpb25zIHdvdWxkIGJlIHVzZWZ1bCB0byBiZXR0ZXIgc3RydWN0dXJlIHRoZW0u IEF0IGxlYXN0IEkgZmluZCBzb21lIG9mIHRoZSBsb25nIHRleHQgYmxvY2tzIGhhcmQgdG8gcmVh ZCBhbmQgaXQgaXMgbm90IGFsd2F5cyBhcHBhcmVudCBob3cgYSBnaXZlbiBwYXJhZ3JhcGggZml0 cyBpbnRvIHRoZSBvdmVyYWxsIHN0b3J5bGluZS4gSSBzdXNwZWN0IHRoYXQgdGhlIGRvY3VtZW50 IHdvdWxkIGJlIGVhc2llciB0byBwYXJzZSB3aXRoIHNvbWUgbW9yZSBzdHJ1Y3R1cmluZyAoZS5n Liwgc3Vic2VjdGlvbnMpLg0KICAqICAgVGhlIGludGVybmFsIHN0cnVjdHVyZSBvZiBTZWN0aW9u IDggaXMgaGFyZCB0byB1bmRlcnN0YW5kLiBGb3IgaW5zdGFuY2UsIEVDTVAgYW5kIExBRyBhcmUg ZGlzY3Vzc2VkIHR3aWNlLiBBbHNvLCB0aGlzIHNlY3Rpb24gZGlzY3Vzc2VzIHF1aXRlIGEgbnVt YmVyIG9mIGRpZmZlcmVudCBhc3BlY3RzLCBpbmNsdWRpbmcgZmFpcm5lc3MsIGNoYWxsZW5nZXMg d2l0aCBFQ01QL0xBRywgaW50ZXJhY3Rpb25zIHdpdGggZmFzdCByZWNvdmVyeSBhbmQgTkFULiBJ IHN1Z2dlc3QgdG8gZWl0aGVyIGFkZCBlYXJseSBhbiBleHBsYW5hdGlvbiB3aGF0IGlzIG1lYW50 IGJ5IOKAnmNvbXBhdGliaWxpdHnigJwsIG9yIHRvIHVzZSBzdWItc2VjdGlvbnMgdG8gbWFrZSBj bGVhciB3aGF0IHRvcGljcyBhcmUgaW4gc2NvcGUgKHNlZSBhYm92ZSkuDQogICogICBUaGUgc2Vw YXJhdGlvbiBvZiB0b3BpY3MgYmV0d2VlbiBTZWN0aW9uIDggYW5kIDkgaXMgbm90IGZ1bGx5IGNs ZWFyIHRvIG1lIChkaWZmZXJlbnQgdG8gUkZDIDIxNDAg4oCTIHByaW9yIHRvIGRlcGxveW1lbnQg dGhlc2Ugc2VjdGlvbnMgaGFkIGEgcmVsYXRpdmVseSBjbGVhciBtZWFuaW5nKS4gRm9yIGluc3Rh bmNlLCBib3RoIHNlY3Rpb25zIGRpc2N1c3MgdHJhZmZpYyB3aXRoIHBvc3NpYmx5IHNob3J0IGZs b3dzIChlLmcuLCBodHRwKS4gSSB0aGluayB0aGUgZXhpc3RpbmcgY29udGVudCBjb3VsZCBiZSBy ZW9yZ2FuaXplZCBieSBjb3B5JnBhc3RlIGluIHNlY3Rpb25zIHdpdGggYSB3ZWxsLWRlZmluZWQg Zm9jdXMuIEV4YW1wbGUgc2VjdGlvbiB0aXRsZXMgY291bGQgYmU6DQogICAgICogICBGYWlybmVz cyBpc3N1ZXMNCiAgICAgKiAgIEltcGFjdCBvbiBhcHBsaWNhdGlvbnMgYW5kIHBlcmZvcm1hbmNl DQogICAgICogICBJbnRlcmFjdGlvbnMgd2l0aCBuZXR3b3JrIG1lY2hhbmlzbQ0KICAgICAqICAg RGlzY3Vzc2lvbiBvZiBkZXNpZ24gYXNwZWN0cyBhbmQgYWx0ZXJuYXRpdmVzDQogICAgICogICDi gKYgKG9yIG90aGVyIHRlcm1zIOKAkyBJIGp1c3QgcG9zdCB0aGlzIGxpc3QgdG8gaWxsdXN0cmF0 ZSB0aGF0IGFsdGVybmF0aXZlcyBjb3VsZCBleGlzdCkNCiAgKiAgIFRoZSB0YWJsZSBvbiBwYWdl IDE1IGlzIGEgYml0IGRhdGVkLiBJIGhvcGUgdGhhdCB3ZSBjb3VsZCB1cGRhdGUgdGhhdCwgc2F5 LCBkdXJpbmcgYSBXR0xDDQogICogICBTZWN0aW9uIDEyOiBJIGFtIG5vdCBzdXJlIGlmIEkgZnVs bHkgdW5kZXJzdGFuZCB0aGUgYXR0YWNrIHZlY3RvcnMgc2VjdGlvbi4gRm9yIGluc3RhbmNlLCBo b3cgd291bGQgYW4gYXR0YWNrIGxpa2Ug4oCeYW4gYXBwbGljYXRpb24gY2FuIG9wZW4gYSBjb25u ZWN0aW9uIGFuZCBzZXQgaXRzIHdpbmRvdyBzaXplIHRvIHplcm8sIGRlbnlpbmcgc2VydmljZSB0 byBhbnkgb3RoZXIgc3Vic2VxdWVudCBjb25uZWN0aW9uIGJldHdlZW4gdGhvc2UgaG9zdHMu4oCc IHdvcmsgaWYgdGhlIHJlY2VpdmUgd2luZG93IGlzIG5vdCBzaGFyZWQ/IEluIGFkZGl0aW9uLCBJ IHdvbmRlciBpZiBwcml2YWN5IG5lZWRzIHRvIGJlIGRpc2N1c3NlZCwgZS5nLiwgd2hldGhlciB1 c2VyIHRyYWNraW5nIG9yIGZpbmdlcnByaW50aW5nIGlzIHBvc3NpYmxlIGJ5IHRoZSBtZXRob2Rz IGRpc2N1c3NlZCBpbiB0aGUgZG9jdW1lbnQuDQogICogICBTZWN0aW9uIDE0OiBJIHdvdWxkIGNs YXNzaWZ5IG1vcmUgcmVmZXJlbmNlcyBhcyDigJ5ub3JtYXRpdmXigJwgKGUuZy4sIFJGQyA3OTMp DQogICogICBBcHBlbmRpeCBDLjM6IEkgcmVhbGx5IHdvbmRlciB3aHkgbm90IHRvIHNwZWNpZnkg dGhlIGFsZ29yaXRobSB3aXRoIChvcHRpb25hbCkgcGVyc2lzdGVuY2UgYWNyb3NzIHJlYm9vdHMN Cg0KRWRpdG9yaWFsIG5pdHM6DQoNCg0KICAqICAgUGxlYXNlIGVuc3VyZSB0aGF0IGNhcGl0YWxp emF0aW9uIG9mIGFsbCBoZWFkbGluZXMgaXMgY29uc2lzdGVudCAoZS5nLiwgdGl0bGUgb2YgQXBl bmRpeCBBKQ0KICAqICAgU2FtZSBmb3IgYWxsIHRhYmxlIGNhcHRpb25zIChlLmcuLCBjYXB0aW9u IOKAnk9wdGlvbiBpbmZv4oCcKQ0KICAqICAgU2VjdGlvbiAyOiBJIGFtIG5vdCBzdXJlIGFib3V0 IHRoaXMgd29yZGluZzogcy9wZXJtaXR0ZWQgYnkgVENQIGltcGxlbWVudGVycy9wZXJtaXR0ZWQg YnkgVENQIHN0YW5kYXJkcy8gPz8/DQogICogICBJbiB0aGUgdGFibGUgb24gU2VjdGlvbiA1LCDi gJ5yb3VuZC10cmlwIHRpbWUgYW5kIHZhcmlhbmNl4oCcIGFwcGVhcnMgdHdpY2UsIGlzIHRoaXMg YSBidWcgb3IgYSBmZWF0dXJlPyAoU2FtZSBhcyBpbiBSRkMgMjE0MCkNCiAgKiAgIFBhZ2UgNyBy ZWZlcnMgdG8gQXBwZW5kaXggQi4gSWYgdGhhdCBhcHBlbmRpeCBzaGFsbCBpbmRlZWQgYmUgcmVt b3ZlZCBwcmlvciB0byBwdWJsaWNhdGlvbiwgdGhhdCByZWZlcmVuY2UgYWxzbyBuZWVkcyB0byBi ZSByZW1vdmVkLiBNYXliZSB0aGF0IHNlbnRlbmNlIHNob3VsZCBiZSBmbGFnZ2VkIGZvciByZW1v dmFsLCB0b28/IQ0KICAqICAgT24gcGFnZSA3IGFuZCA4LCBJIGJlbGlldmUgdGhhdCB0aGUgcG9z aXRpb24gb2YgdGhlIHRhYmxlcyBjb3VsZCBiZSByZWFycmFuZ2VkIHNvIHRoYXQgdGhleSBhcmUg bm90IHJlbmRlcmVkIGJhY2stdG8tYmFjay4gQm90aCB0YWJsZXMgc2VlbSBwYXJ0bHkgdW5yZWxh dGVkIGFuZCB0aGUgY3VycmVudCBwb3NpdGlvbiBtYXkgYmUgYSBiaXQgY29uZnVzaW5nLiBTYW1l IGlzc3VlIGxhdGVyIG9uIHBhZ2UgMTAuIChBbHRlcm5hdGl2ZWx5LCB0aGUgdGFibGVzIGNvdWxk IGJlIG51bWJlcmVkIHRvIG1ha2UgY2xlYXIgdGhhdCB0aGV5IGFyZSBzZXBhcmF0ZS4pDQogICog ICBPbiBwYWdlIDgsIHRoZSBvcmRlciBvZiB0aGUgZW50cmllcyBpbiB0aGUgdGFibGUgYW5kIHRo ZSBvcmRlciBvZiB0aGVpciBleHBsYW5hdGlvbiBpcyBub3Qgd2VsbCBhbGlnbmVkLiBUaGlzIG1h eSBiZSBhIG1hdHRlciBvZiBwZXJzb25hbCB0YXN0ZSwgYnV0IEkgd291bGQgZXhwZWN0IGEgc29t ZXdoYXQgc2ltaWxhciBvcmRlci4NCiAgKiAgIFBhZ2UgOC85OiDigJ5UaGUgbWV0aG9kIGZvciBt ZXJnaW5nIG9sZCBhbmQgY3VycmVudCB2YWx1ZXMgbmVlZHMgdG8gYXR0ZW1wdCB0byByZWR1Y2Ug dGhlIHRyYW5zaWVudCBmb3IgbmV3IGNvbm5lY3Rpb25zLuKAnCBJIGFtIG5vdCBzdXJlIGlmIEkg ZnVsbHkgdW5kZXJzdGFuZCB3aGF0IGlzIG1lYW50IGJ5IHRoaXMgKGFsYmVpdCBJIHN1c3BlY3Qg YSBjZXJ0YWluIG1lYW5pbmcpLg0KICAqICAgUGFnZSA5OiBUaGUgdGFibGUgaW4gdGhlIHVwcGVy IHBhcnQgb2YgdGhlIHBhZ2UgaXMgbm90IGV4cGxhaW5lZC4gSSB0aGluayBpdCB3b3VsZCBtYWtl IHNlbnNlIHRvIGhhdmUgYXQgbGVhc3Qgb25lIHNlbnRlbmNlIHRvIGludHJvZHVjZSBpdC4NCiAg KiAgIFBhZ2UgMTE6IFRoZSBwb3NpdGlvbiBvZiB0aGUgdGFibGUgY29uZnVzZXMgbWUuDQoNCk15 IDIgY2VudHMNCg0KTWljaGFlbA0K --_000_6EC6417807D9754DA64F3087E2E2E03E2D8FD745rznt8114rzntrzd_ Content-Type: text/html; charset="utf-8" Content-ID: <7815BBD433AFB047B480A29D61720383@exchange.hs-esslingen.de> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9t OjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMg Ki8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjM5MTA3OTEzMTsNCgltc28tbGlzdC10eXBlOmh5 YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTI3MjcwNzY5NiAtMSA2NzU2NzYxOSA2NzU2 NzYyMSA2NzU2NzYxNyA2NzU2NzYxOSA2NzU2NzYyMSA2NzU2NzYxNyA2NzU2NzYxOSA2NzU2NzYy MTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDsNCgltc28tZmFyZWFzdC1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEE3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxG MEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEE3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0OlxGMEE3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo2NTUxMTM2NDE7DQoJbXNvLWxp c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE4NTE5MjU5MzYgLTEgNjc1 Njc2NDEgNjc1Njc2NDMgNjc1Njc2MzEgNjc1Njc2NDEgNjc1Njc2NDMgNjc1Njc2MzEgNjc1Njc2 NDEgNjc1Njc2NDM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo1NC4wcHQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjkwLjBwdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjEyNi4wcHQ7DQoJdGV4dC1pbmRl bnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTYyLjBwdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTk4LjBwdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjIzNC4wcHQ7DQoJdGV4dC1pbmRl bnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjcwLjBwdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MzA2LjBwdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjM0Mi4wcHQ7DQoJdGV4dC1pbmRl bnQ6LTkuMHB0O30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjcxNTE1NjQxMDsNCgltc28tbGlz dC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTU3NTgzMzEwIC0xIDY3NTY3 NjE5IDY3NTY3NjIxIDY3NTY3NjE3IDY3NTY3NjE5IDY3NTY3NjIxIDY3NTY3NjE3IDY3NTY3NjE5 IDY3NTY3NjIxO30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCglt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMjps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0OlxGMEE3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjps ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 OlxGMEE3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEE3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMw0K CXttc28tbGlzdC1pZDoxMzgwOTc1OTQyOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczoyMzkzNzYxOTQgLTEgNjc1Njc2MTkgNjc1Njc2MjEgNjc1Njc2MTcg Njc1Njc2MTkgNjc1Njc2MjEgNjc1Njc2MTcgNjc1Njc2MTkgNjc1Njc2MjE7fQ0KQGxpc3QgbDM6 bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0K QGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBBNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDM6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpcRjBBNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDM6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBB NzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+ PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkRFIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSByZWFk IHRoZSBtb3N0IHJlY2VudCB2ZXJzaW9uIG9mIDIxNDBiaXMuIEFzIHVzdWFsbHksIG15IGNvbW1l bnRzIGFyZSBwb3N0ZWQgd2l0aCBjaGFpciBoYXQgb2ZmLjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBlbmNvdXJh Z2Ugb3RoZXJzIHRvIGFsc28gcmVhZCB0aGUgZG9jdW1lbnQuPC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Jc3N1ZXMg LyBjb21tZW50czo8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowY20iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwzIGxldmVs MSBsZm8zIj5UaGUgZG9jdW1lbnQgc3RydWN0dXJlIGZvbGxvd3MgaW4gbWFueSBjYXNlcyBleGFj dGx5IFJGQyAyMTQwLCBldmVuIGlmIGNvbnRlbnQgaGFzIGNoYW5nZWQuIEluIHNvbWUgY2FzZXMs IHRoaXMgY29uZnVzZXMgbWUuIEZvciBpbnN0YW5jZSwgdGhlIFNlY3Rpb24g4oCeQW4gRW5zYW1w bGUgb2YgVGVtcG9yYWwgU2hhcmluZ+KAnA0KIGluIFJGQyAyMTQwIGluZGVlZCBjb250YWluZWQg YW4gaW1wbGVtZW50YXRpb24gZXhhbXBsZS4gU2VjdGlvbiA2IG9mIFJGQyAyMTQwYmlzIGlzIGdl bmVyaWMuIFRoaXMgcmFpc2VzIGF0IGxlYXN0IHR3byBxdWVzdGlvbnMgZsO8ciBTZWN0aW9uIDYg YW5kIHNpbWlsYXJseSBmb3IgU2VjdGlvbiA3OjwvbGk+PC91bD4NCjxvbCBzdHlsZT0ibWFyZ2lu LXRvcDowY20iIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvNCI+SXMg dGhlIHRpdGxlIGZvciB0aGUgc2VjdGlvbiBzdGlsbCBhcHByb3ByaWF0ZT88L2xpPjxsaSBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDttc28tbGlzdDps MSBsZXZlbDEgbGZvNCI+SXMgc29tZSBhZGRpdGlvbmFsIGV4cGxhbmF0aW9uIG5lZWRlZCBlLmcu IG9uIHBhZ2UgNiB0aGF0IGFuIGltcGxlbWVudGF0aW9uIGNhbiBkZWNpZGUgdG8gaW1wbGVtZW50 IG9ubHkgc3Vic2V0cyBvZiB0aGUgdGFibGUgb24gcGFnZSA2LCBhcyBhbiBlYXJseSBoZWFkcy11 cD88L2xpPjwvb2w+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGNtIiB0eXBlPSJkaXNjIj4NCjxs aSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlz dDpsMyBsZXZlbDEgbGZvMyI+U2VjdGlvbnMgNiwgNywgOCwgOSBhbmQgMTAgYXJlIGxvbmdlciB0 aGFuIHRoZSBvcmlnaW5hbCAyMTQwLiBJIHdvbmRlciBpZiBzdWJzZWN0aW9ucyB3b3VsZCBiZSB1 c2VmdWwgdG8gYmV0dGVyIHN0cnVjdHVyZSB0aGVtLiBBdCBsZWFzdCBJIGZpbmQgc29tZSBvZiB0 aGUgbG9uZyB0ZXh0IGJsb2NrcyBoYXJkIHRvDQogcmVhZCBhbmQgaXQgaXMgbm90IGFsd2F5cyBh cHBhcmVudCBob3cgYSBnaXZlbiBwYXJhZ3JhcGggZml0cyBpbnRvIHRoZSBvdmVyYWxsIHN0b3J5 bGluZS4gSSBzdXNwZWN0IHRoYXQgdGhlIGRvY3VtZW50IHdvdWxkIGJlIGVhc2llciB0byBwYXJz ZSB3aXRoIHNvbWUgbW9yZSBzdHJ1Y3R1cmluZyAoZS5nLiwgc3Vic2VjdGlvbnMpLjwvbGk+PGxp IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0 OmwzIGxldmVsMSBsZm8zIj5UaGUgaW50ZXJuYWwgc3RydWN0dXJlIG9mIFNlY3Rpb24gOCBpcyBo YXJkIHRvIHVuZGVyc3RhbmQuIEZvciBpbnN0YW5jZSwgRUNNUCBhbmQgTEFHIGFyZSBkaXNjdXNz ZWQgdHdpY2UuIEFsc28sIHRoaXMgc2VjdGlvbiBkaXNjdXNzZXMgcXVpdGUgYSBudW1iZXIgb2Yg ZGlmZmVyZW50IGFzcGVjdHMsIGluY2x1ZGluZw0KIGZhaXJuZXNzLCBjaGFsbGVuZ2VzIHdpdGgg RUNNUC9MQUcsIGludGVyYWN0aW9ucyB3aXRoIGZhc3QgcmVjb3ZlcnkgYW5kIE5BVC4gSSBzdWdn ZXN0IHRvIGVpdGhlciBhZGQgZWFybHkgYW4gZXhwbGFuYXRpb24gd2hhdCBpcyBtZWFudCBieSDi gJ5jb21wYXRpYmlsaXR54oCcLCBvciB0byB1c2Ugc3ViLXNlY3Rpb25zIHRvIG1ha2UgY2xlYXIg d2hhdCB0b3BpY3MgYXJlIGluIHNjb3BlIChzZWUgYWJvdmUpLg0KPC9saT48bGkgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDMgbGV2ZWwx IGxmbzMiPlRoZSBzZXBhcmF0aW9uIG9mIHRvcGljcyBiZXR3ZWVuIFNlY3Rpb24gOCBhbmQgOSBp cyBub3QgZnVsbHkgY2xlYXIgdG8gbWUgKGRpZmZlcmVudCB0byBSRkMgMjE0MCDigJMgcHJpb3Ig dG8gZGVwbG95bWVudCB0aGVzZSBzZWN0aW9ucyBoYWQgYSByZWxhdGl2ZWx5IGNsZWFyIG1lYW5p bmcpLiBGb3IgaW5zdGFuY2UsDQogYm90aCBzZWN0aW9ucyBkaXNjdXNzIHRyYWZmaWMgd2l0aCBw b3NzaWJseSBzaG9ydCBmbG93cyAoZS5nLiwgaHR0cCkuIEkgdGhpbmsgdGhlIGV4aXN0aW5nIGNv bnRlbnQgY291bGQgYmUgcmVvcmdhbml6ZWQgYnkgY29weSZhbXA7cGFzdGUgaW4gc2VjdGlvbnMg d2l0aCBhIHdlbGwtZGVmaW5lZCBmb2N1cy4gRXhhbXBsZSBzZWN0aW9uIHRpdGxlcyBjb3VsZCBi ZToNCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowY20iIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDMgbGV2 ZWwyIGxmbzMiPkZhaXJuZXNzIGlzc3VlczwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwzIGxldmVsMiBsZm8zIj5JbXBhY3Qg b24gYXBwbGljYXRpb25zIGFuZCBwZXJmb3JtYW5jZTxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDMgbGV2 ZWwyIGxmbzMiPkludGVyYWN0aW9ucyB3aXRoIG5ldHdvcmsgbWVjaGFuaXNtPC9saT48bGkgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDMg bGV2ZWwyIGxmbzMiPkRpc2N1c3Npb24gb2YgZGVzaWduIGFzcGVjdHMgYW5kIGFsdGVybmF0aXZl czwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNt O21zby1saXN0OmwzIGxldmVsMiBsZm8zIj7igKYgKG9yIG90aGVyIHRlcm1zIOKAkyBJIGp1c3Qg cG9zdCB0aGlzIGxpc3QgdG8gaWxsdXN0cmF0ZSB0aGF0IGFsdGVybmF0aXZlcyBjb3VsZCBleGlz dCk8L2xpPjwvdWw+DQo8L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjBjbTttc28tbGlzdDpsMyBsZXZlbDEgbGZvMyI+VGhlIHRhYmxlIG9uIHBhZ2Ug MTUgaXMgYSBiaXQgZGF0ZWQuIEkgaG9wZSB0aGF0IHdlIGNvdWxkIHVwZGF0ZSB0aGF0LCBzYXks IGR1cmluZyBhIFdHTEM8L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjBjbTttc28tbGlzdDpsMyBsZXZlbDEgbGZvMyI+U2VjdGlvbiAxMjogSSBhbSBu b3Qgc3VyZSBpZiBJIGZ1bGx5IHVuZGVyc3RhbmQgdGhlIGF0dGFjayB2ZWN0b3JzIHNlY3Rpb24u IEZvciBpbnN0YW5jZSwgaG93IHdvdWxkIGFuIGF0dGFjayBsaWtlIOKAnmFuIGFwcGxpY2F0aW9u IGNhbiBvcGVuIGEgY29ubmVjdGlvbiBhbmQgc2V0IGl0cyB3aW5kb3cgc2l6ZSB0bw0KIHplcm8s IGRlbnlpbmcgc2VydmljZSB0byBhbnkgb3RoZXIgc3Vic2VxdWVudCBjb25uZWN0aW9uIGJldHdl ZW4gdGhvc2UgaG9zdHMu4oCcIHdvcmsgaWYgdGhlIHJlY2VpdmUgd2luZG93IGlzIG5vdCBzaGFy ZWQ/IEluIGFkZGl0aW9uLCBJIHdvbmRlciBpZiBwcml2YWN5IG5lZWRzIHRvIGJlIGRpc2N1c3Nl ZCwgZS5nLiwgd2hldGhlciB1c2VyIHRyYWNraW5nIG9yIGZpbmdlcnByaW50aW5nIGlzIHBvc3Np YmxlIGJ5IHRoZSBtZXRob2RzIGRpc2N1c3NlZA0KIGluIHRoZSBkb2N1bWVudC48L2xpPjxsaSBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDps MyBsZXZlbDEgbGZvMyI+U2VjdGlvbiAxNDogSSB3b3VsZCBjbGFzc2lmeSBtb3JlIHJlZmVyZW5j ZXMgYXMg4oCebm9ybWF0aXZl4oCcIChlLmcuLCBSRkMgNzkzKTwvbGk+PGxpIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwzIGxldmVsMSBs Zm8zIj5BcHBlbmRpeCBDLjM6IEkgcmVhbGx5IHdvbmRlciB3aHkgbm90IHRvIHNwZWNpZnkgdGhl IGFsZ29yaXRobSB3aXRoIChvcHRpb25hbCkgcGVyc2lzdGVuY2UgYWNyb3NzIHJlYm9vdHM8L2xp PjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkVkaXRvcmlhbCBuaXRzOjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIgdHlwZT0i ZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDow Y207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPlBsZWFzZSBlbnN1cmUgdGhhdCBjYXBpdGFsaXph dGlvbiBvZiBhbGwgaGVhZGxpbmVzIGlzIGNvbnNpc3RlbnQgKGUuZy4sIHRpdGxlIG9mIEFwZW5k aXggQSk8L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjBjbTttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+U2FtZSBmb3IgYWxsIHRhYmxlIGNhcHRpb25z IChlLmcuLCBjYXB0aW9uIOKAnk9wdGlvbiBpbmZv4oCcKTwvbGk+PGxpIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwwIGxldmVsMSBsZm8x Ij5TZWN0aW9uIDI6IEkgYW0gbm90IHN1cmUgYWJvdXQgdGhpcyB3b3JkaW5nOiBzL3Blcm1pdHRl ZCBieSBUQ1AgaW1wbGVtZW50ZXJzL3Blcm1pdHRlZCBieSBUQ1Agc3RhbmRhcmRzLyA/Pz88L2xp PjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28t bGlzdDpsMCBsZXZlbDEgbGZvMSI+SW4gdGhlIHRhYmxlIG9uIFNlY3Rpb24gNSwg4oCecm91bmQt dHJpcCB0aW1lIGFuZCB2YXJpYW5jZeKAnCBhcHBlYXJzIHR3aWNlLCBpcyB0aGlzIGEgYnVnIG9y IGEgZmVhdHVyZT8gKFNhbWUgYXMgaW4gUkZDIDIxNDApPC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEi PlBhZ2UgNyByZWZlcnMgdG8gQXBwZW5kaXggQi4gSWYgdGhhdCBhcHBlbmRpeCBzaGFsbCBpbmRl ZWQgYmUgcmVtb3ZlZCBwcmlvciB0byBwdWJsaWNhdGlvbiwgdGhhdCByZWZlcmVuY2UgYWxzbyBu ZWVkcyB0byBiZSByZW1vdmVkLiBNYXliZSB0aGF0IHNlbnRlbmNlIHNob3VsZCBiZSBmbGFnZ2Vk IGZvciByZW1vdmFsLA0KIHRvbz8hPC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPk9uIHBhZ2UgNyBh bmQgOCwgSSBiZWxpZXZlIHRoYXQgdGhlIHBvc2l0aW9uIG9mIHRoZSB0YWJsZXMgY291bGQgYmUg cmVhcnJhbmdlZCBzbyB0aGF0IHRoZXkgYXJlIG5vdCByZW5kZXJlZCBiYWNrLXRvLWJhY2suIEJv dGggdGFibGVzIHNlZW0gcGFydGx5IHVucmVsYXRlZCBhbmQgdGhlIGN1cnJlbnQgcG9zaXRpb24N CiBtYXkgYmUgYSBiaXQgY29uZnVzaW5nLiBTYW1lIGlzc3VlIGxhdGVyIG9uIHBhZ2UgMTAuIChB bHRlcm5hdGl2ZWx5LCB0aGUgdGFibGVzIGNvdWxkIGJlIG51bWJlcmVkIHRvIG1ha2UgY2xlYXIg dGhhdCB0aGV5IGFyZSBzZXBhcmF0ZS4pPC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPk9uIHBhZ2Ug OCwgdGhlIG9yZGVyIG9mIHRoZSBlbnRyaWVzIGluIHRoZSB0YWJsZSBhbmQgdGhlIG9yZGVyIG9m IHRoZWlyIGV4cGxhbmF0aW9uIGlzIG5vdCB3ZWxsIGFsaWduZWQuIFRoaXMgbWF5IGJlIGEgbWF0 dGVyIG9mIHBlcnNvbmFsIHRhc3RlLCBidXQgSSB3b3VsZCBleHBlY3QgYSBzb21ld2hhdCBzaW1p bGFyDQogb3JkZXIuPC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNr O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5QYWdlIDgvOTog4oCeVGhlIG1ldGhvZCBmb3IgbWVy Z2luZyBvbGQgYW5kIGN1cnJlbnQgdmFsdWVzIG5lZWRzIHRvIGF0dGVtcHQgdG8gcmVkdWNlIHRo ZSB0cmFuc2llbnQgZm9yIG5ldyBjb25uZWN0aW9ucy7igJwgSSBhbSBub3Qgc3VyZSBpZiBJIGZ1 bGx5IHVuZGVyc3RhbmQgd2hhdCBpcyBtZWFudCBieSB0aGlzIChhbGJlaXQgSSBzdXNwZWN0DQog YSBjZXJ0YWluIG1lYW5pbmcpLjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPjwv bzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjBjbTttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+UGFnZSA5OiBUaGUgdGFibGUgaW4g dGhlIHVwcGVyIHBhcnQgb2YgdGhlIHBhZ2UgaXMgbm90IGV4cGxhaW5lZC4gSSB0aGluayBpdCB3 b3VsZCBtYWtlIHNlbnNlIHRvIGhhdmUgYXQgbGVhc3Qgb25lIHNlbnRlbmNlIHRvIGludHJvZHVj ZSBpdC48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjBjbTttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+UGFnZSAxMTogVGhlIHBvc2l0aW9uIG9mIHRo ZSB0YWJsZSBjb25mdXNlcyBtZS48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IDIgY2VudHM8L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk1pY2hhZWw8L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_6EC6417807D9754DA64F3087E2E2E03E2D8FD745rznt8114rzntrzd_--