From nobody Mon Jun 3 07:37:30 2019 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 942031202BB for ; Mon, 3 Jun 2019 07:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=wizmail.org 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 EhcyVXqq-wHG for ; Mon, 3 Jun 2019 07:37:25 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 564C21202B9 for ; Mon, 3 Jun 2019 07:37:25 -0700 (PDT) ARC-Seal: i=1; cv=none; a=rsa-sha256; d=wizmail.org; s=r201803; t=1559572645; b=J5SspCLMd8sKYMWFweid4W2Qivs1OJ18h3Z8w5bwsMIvfJyXnq0OS743/+eSA+IoYemW69/VZT Fhig5TBEQwqYzQHI0kxygebmn0Nl5E8Z6j4IQCL55FRO2uSP6MWv3l1h/HgD+1b7aZt2sb8Vc6 wpfDVhHC10SAkkau9eA6J70=; ARC-Authentication-Results: i=1; wizmail.org; iprev=fail smtp.remote-ip=2a00:b900:109e:0:855c:1404:1b9d:3a94; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=wizmail.org; s=r201803; t=1559572645; bh=gY5pBgEM7zcrxd8BwM0sZBH6gfGeXy4O14boRTymiDk=; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:DKIM-Signature; b=jvmxk6allS97lKnV1mK5kuxezq99znjNNAhrxUGH64hIleq1N9oBQek90AMCHw0CkNM/e05/BJ FU7IRXEeg+wSCeKjzSzcKpCfkL9tifEF/Zvi1QObsPmLML2Vf4+SIGj9n6BEfwCcRCPB2OcxXa 96/Lwf3gU4etI9BM1jDHSqQ=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r201803; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:From:Sender:Reply-To: Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive; bh=Bpxx8uVwyJUDOFQFQnnUpj78mUhdFXGSjv90nRCtzCM=; b=h KsoUptOcCz1145rTC8edWjd7DlVgMUvG0b5FpsSDbxae7jWNMNLpaDPd2wP7Boryjzchq5qjVxBNk mg+XAoG5aXmywMoJkEKCkNZ3Zg5u1VVOfNqf/xnVPZRe7m9DbgVQwboQY30AhlW1SX1wydQkut+hy uztPQ9CBgYXz9hD0=; Authentication-Results: wizmail.org; iprev=fail smtp.remote-ip=2a00:b900:109e:0:855c:1404:1b9d:3a94; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from [2a00:b900:109e:0:855c:1404:1b9d:3a94] (helo=lap.dom.ain) by wizmail.org (Exim 4.92.114) (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) with esmtpsa id 1hXo5T-0005Mq-6Y for tcpm@ietf.org (return-path ); Mon, 03 Jun 2019 14:37:23 +0000 To: tcpm@ietf.org References: <787AE7BB302AE849A7480A190F8B93302EA8E8EF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA8F7C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <4258DCF5-1588-4B97-9C05-F0722E053072@tessares.net> From: Jeremy Harris Openpgp: preference=signencrypt Autocrypt: addr=jgh@wizmail.org; prefer-encrypt=mutual; keydata= mQENBFWABsQBCADTFfb9EHGGiDel/iFzU0ag1RuoHfL/09z1y7iQlLynOAQTRRNwCWezmqpD p6zDFOf1Ldp0EdEQtUXva5g2lm3o56o+mnXrEQr11uZIcsfGIck7yV/y/17I7ApgXMPg/mcj ifOTM9C7+Ptghf3jUhj4ErYMFQLelBGEZZifnnAoHLOEAH70DENCI08PfYRRG6lZDB09nPW7 vVG8RbRUWjQyxQUWwXuq4gQohSFDqF4NE8zDHE/DgPJ/yFy+wFr2ab90DsE7vOYb42y95keK tTBp98/Y7/2xbzi8EYrXC+291dwZELMHnYLF5sO/fDcrDdwrde2cbZ+wtpJwtSYPNvVxABEB AAG0JkplcmVteSBIYXJyaXMgKG5vbmUpIDxqZ2hAd2l6bWFpbC5vcmc+iQE7BBMBAgAlAhsD BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCVYAYBAIZAQAKCRC85YyM5B8y34iFB/9wozIY RogNdY1aejFFixb6++y4b1riyjMvWEULeEzDlQ0lMT6Z3PxXhZILD4y4aP7Kzx0ozXa5qaKy 41EAPKQoPipnRAH04QytJbIERvz8Tot/LeCVKUc0G9DVxOPBD03czTgqgz4EjV2qvnLF+rTU 0YBevrNCluKosGSd+3RvLWVu0hBhn9pELKfXJNSQXZb+TpHDhSDZ/gCrglBEOhA6YWbDb/4g z+5TFKdk+B++iAQZSHv7zISabjN+BPYgI47A+MU4JycoXaAUnMc0l5ba6fGNaIrzruE4aAZr lP5o+7mlU9Mm0QJqdqYxYPAiplJGrZv+YXH1fp5ueEK3l+NGuQENBFWABsQBCADphLHaKToR uR/E7THerBiCjDatwCaETOKOTY2zRBQpaQ32p/F2XIGLS8Cc27+grZSKQ6ZX0ZN47O+AFyFH F8DH90IXZFpJR3Rb8zgXT8jnLX08DM31eECZHnRzFhGlOmq6WAUlqB3GKCPUCY2c4eTRXyoX LteTxrXCYoj45y/YmvlZrlonBNjPBAyHiO/LNz+V7fZtNsN7N/XGrnLbcdNfNd+SD1ENmbLJ 8RvyymxguTyB/ka9JdjHHIoQEJ6L166B3hhfCHpt8iC0GPZkti9IMl0NoJ029jJm3Jq1qEce EBn5H5QMGn6Fq64iXwTsO1TMNUwpWx8pjvV7wVIxjI8ZABEBAAGJAR8EGAECAAkFAlWABsQC GwwACgkQvOWMjOQfMt9N6Af8CS2CTrMQFdhkGEtBXmL4ifD8UHFkBRBGmM8ZL2fWUBTZXT8m rdRMOK6tcPnKWaCvWvKr0knt970j/DyAgFmH8hgOi3yctigFecVDjjilAeCJMq38s1tYKYiL DbBdHWtdkA9uHZwq3lfd3QxcEEO3QamQF+dO7h8gAOXlG+po87Hm+E0wz4swIB8+S37Jzrx9 uu0LSFDfJCTK+TIKGa5Un8LxPxyq9WnnNDh72zK7BiRidk/s40KcNod83NM4Hn/sbGfyLa8s S0F3ME0S+ocSMOiu/ZHHOiwpLYNbwTJ7stZxGsrguWeT9P+amxbA/YlK95LedstwvN+WcHZ7 d++Arg== Message-ID: <3d979013-16d3-689f-45cb-e5b007fe7f13@wizmail.org> Date: Mon, 3 Jun 2019 15:37:22 +0100 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: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: [2a00:b900:109e:0:855c:1404:1b9d:3a94] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters 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, 03 Jun 2019 14:37:28 -0000 On 29/05/2019 17:27, Praveen Balasubramanian wrote: > 2. Ability to RECEIVE data in SYN payload on server. This is only supported on all OS *after* 3WHS is completed. This is per RFC 793. The only exception is if TFO API is used, and then if cookie is validated the application will receive early-data. There is no way to retrieve early data otherwise. There is a bit in the tcp_fastopen sysctl for Linux described so: 0x200: (server) accept data-in-SYN w/o any cookie option present. It doesn't say explicitly that the data is presented to the application (neither does the doc for the with-cookie server TFO control bit). Does anybody know whether it is? -- Cheers, Jeremy From nobody Mon Jun 3 10:59:26 2019 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 55B0F120108 for ; Mon, 3 Jun 2019 10:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_MED=-0.01, 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 3NOKQCuTBQwz for ; Mon, 3 Jun 2019 10:59:23 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 5751612072D for ; Mon, 3 Jun 2019 10:59:23 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id x4so13070434wrt.6 for ; Mon, 03 Jun 2019 10:59:23 -0700 (PDT) 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=c5RzgHYOrpbf92lR62sgHy0hcnn0/T19up/yDFr60z0=; b=vaY9kHcwihTcrshP+y4zf2dXn9HWfQGU8HW9JDQarJgfreTFZZMAE2GwpeFmoYfrUF dmAkZW+WV2HL74oXOmTYNojTeL+eyzSnUnGZlnUa7fxTMICY1d8dqpKzn4oG8Oa/2OmZ GRlwiBTR0TkvU9di8vwlNDJtsYD9fr/USYxXHfCp0lgpDls+GKarCQVhWES3nlKDylgQ cv7TPiN45vuBBrfrHgcbtTQmVmYGpXLBdkb/xJ+wks3Thw0xeTrLaPXPu46dyk7DeARe BO4QCAr+P0DtuiuU5E2XAP0/TRzqS908zAz0yZegi400TsyvlByfYNDOZ5wjF8So5uiV 9QrA== 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=c5RzgHYOrpbf92lR62sgHy0hcnn0/T19up/yDFr60z0=; b=dCX95rnCbO/IvFekNJh3XTfriBV7Tj/aWLcixfvYx9mNVNzDtzFvzbOXtyFqEyJoyE 4GaIylLq8Xo7EXLNasr5OJPmS71DjbHHOIraXnctu0tFi9dgYM/nn2MopBWv4w+ciImP 7SpjHu+HLn9p2/CQkcGfPpGOHp9nH1ZV+78F+u2KUaHkilJuVlSDWEXSQo5iW0bjbTuD u6GfZh2pZr2J4MYia1JM+vMq63qGjBAyHbibiFQwEXvFm6kuFoZn95nZ+5pODVc0ckYF IX/kKh3mQ5PcMphEc1mzlDYiV8S+zY5Rd3/NYa1+ELmmC3EidXfoCNa8U6qdWro2dcFq 1Dxw== X-Gm-Message-State: APjAAAUmPrWR2Ob8d2scvrLaFlxzBZWtTwedRtU/bGBDZZHcN0Cr9Gjb +Qm2dyFwBQcNOdMggmnlSLa2qte7JN+DqrFe81RvGQmpWpo= X-Google-Smtp-Source: APXvYqx/9VFaHLg9cB9dpoIdnS9QFWW15p7/aDRTUPUMXtxAWvzv8m5SSEMMaT3RyHM+FxdY3u7yj48EbmxmRoIRnOY= X-Received: by 2002:adf:c606:: with SMTP id n6mr16939252wrg.62.1559584761260; Mon, 03 Jun 2019 10:59:21 -0700 (PDT) MIME-Version: 1.0 References: <787AE7BB302AE849A7480A190F8B93302EA8E8EF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA8F7C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <4258DCF5-1588-4B97-9C05-F0722E053072@tessares.net> <3d979013-16d3-689f-45cb-e5b007fe7f13@wizmail.org> In-Reply-To: <3d979013-16d3-689f-45cb-e5b007fe7f13@wizmail.org> From: Yuchung Cheng Date: Mon, 3 Jun 2019 10:58:43 -0700 Message-ID: To: Jeremy Harris Cc: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters 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, 03 Jun 2019 17:59:25 -0000 On Mon, Jun 3, 2019 at 7:37 AM Jeremy Harris wrote: > > On 29/05/2019 17:27, Praveen Balasubramanian wrote: > > 2. Ability to RECEIVE data in SYN payload on server. This is only suppo= rted on all OS *after* 3WHS is completed. This is per RFC 793. The only exc= eption is if TFO API is used, and then if cookie is validated the applicati= on will receive early-data. There is no way to retrieve early data otherwi= se. > > There is a bit in the tcp_fastopen sysctl for Linux described so: > > 0x200: (server) accept data-in-SYN w/o any cookie option present. > > It doesn't say explicitly that the data is presented to the application > (neither does the doc for the with-cookie server TFO control bit). > Does anybody know whether it is? I am not sure what you mean - what is "it" in your last question? when this option is used (0x200), TFO will accept the data in SYN w/o or w/ any cookie. Accept(2) will return in 3WHS. but note that SYN-ACK is returned immediately upon receiving SYN-data in this mode. so this mode will not support the latest tcpm-converter proposal where SYN-ack is delayed upon (in-data) cookie verification and proxy 3WHS completion. This change requires non-trivial implementation for a listener handling millions of requests in Linux. > > -- > Cheers, > Jeremy > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Jun 3 11:01:59 2019 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 B66A5120163 for ; Mon, 3 Jun 2019 11:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_MED=-0.01, 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 GgWBfOpIERGT for ; Mon, 3 Jun 2019 11:01:55 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 84D971202F8 for ; Mon, 3 Jun 2019 11:01:55 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id b18so13030670wrq.12 for ; Mon, 03 Jun 2019 11:01:55 -0700 (PDT) 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=zy1Q1eng08t7HkBdnLNBYc9aBPoHlp6klbL6NNSew6w=; b=oDU+nCuqJL/TUtM7wc+BEZvuf68WcNchMWjmpTD238WwCxE2IdV09XHQKg+olMlxCe g+WVLS2QMCl3Ibjx8yEQO6w1ujFIixezqMb8UAUQBv+jF7H51v731n/9uCZQ8deS+21s NHXxPt/xJMP0h2YNY3aKQUsBp8S8xWfK8A3vtrLtf2L93waVdxY1b7t0X/c5cAsUiUFb xhXCeUE/Pk/Qri0BCWuRAOtuCu/QkAOt+k0VsYXwewkTSUo29gzGo6B5vd46f68nkwOR zkgn42YzY/6JlZotslOXuJeaFJq6EQ3QNFEm6SY09ld7CTUF0dF4jGSwfmQ0zUQff8fZ fUPw== 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=zy1Q1eng08t7HkBdnLNBYc9aBPoHlp6klbL6NNSew6w=; b=uZrf+Ur/1DgQJPSIL01r9DvXLWUMGzGV4kWVsXBb4k/lwHOdJfZPUYULdnSdual6ia QGGJ7WrjAu3Cwx9nDXSNNxCkBZR79T3BW060t7GwnDIFPMCwQEuf1YYSdLsMy+0xIcio 1DVNHeTHddFPxAG6jIW0e9/qATxAjzqii6CuGSaWUFFJeB17zCToQ/AvjS9vjO+0AjM0 V/65fBUav14tnNOCImaixFvTN7I9VZZkW4APvx2dNDcOXbyMrEUFlw1Ez/AyGe+fv4VI keJMr+y0vBxBOPBBwa7CJebr0E7LVG/JjD7pH6NrJKkOViJT7rNzoVdge4cxDVGJ1PTo SGzg== X-Gm-Message-State: APjAAAVMcWz+gKaZqx2BbkCZJNldDyprl+U5YER3qf7/KM9qLiwyTFPf U8ZNEPe4cpKiVgdA7ksfZ16dr43KhAjrxCZ+ACVwvA== X-Google-Smtp-Source: APXvYqzGih13S18zMeORXxj8o+91uITq2jIynDeMMhWfk5A+lPdJGJ4WZgOXoBqm8AmgREh1kj/hecjWNXYFXnWEeaI= X-Received: by 2002:adf:e485:: with SMTP id i5mr3678031wrm.75.1559584913364; Mon, 03 Jun 2019 11:01:53 -0700 (PDT) MIME-Version: 1.0 References: <787AE7BB302AE849A7480A190F8B93302EA8E8EF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA8F7C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA90886@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA9301E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA9301E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Yuchung Cheng Date: Mon, 3 Jun 2019 11:01:16 -0700 Message-ID: To: mohamed.boucadair@orange.com Cc: "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters 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, 03 Jun 2019 18:01:58 -0000 On Fri, May 31, 2019 at 5:17 AM wrote: > > Hi Yuchung, > > Thank you for clarifying your concern. Below a text proposal to address t= his comment: > > > I merely pointed out, if TFO is not used, as the draft and the > > original email refer to, the draft should be explicit this requires a > > change in RFC793. It's rather vague. > > UPDATED: > > Standard TCP ([RFC0793], Section 3.4) allows a SYN packet to carry > data inside its payload but forbids the receiver from delivering it > to the application until completion of the three-way-handshake. To > enable applications to exchange data in a TCP handshake, this > specification follows an approach similar to TCP Fast Open [RFC7413] > and thus removes the constraint by allowing data in SYN packets to be > delivered to the application. > > As discussed in [RFC7413], such change to TCP semantic raises two > issues. First, duplicate SYNs can cause problems for some > applications that rely on TCP. Second, TCP suffers from SYN flooding > attacks [RFC4987]. TFO solves these two problems for applications > that can tolerate replays by using the TCP Fast Open option that > includes a cookie. However, the utilization of this option consumes > space in the limited TCP extended header. Furthermore, there are > situations, as noted in Section 7.3 of [RFC7413] where it is possible > to accept the payload of SYN packets without creating additional > security risks such as a network where addresses cannot be spoofed > and the Transport Converter only serves a set of hosts that are > identified by these addresses. > > For these reasons, this specification does not mandate the use of the > TCP Fast Open option when the Client sends a connection establishment > packet towards a Transport Converter. The Convert protocol includes > an optional Cookie TLV that provides similar protection as the TCP > Fast Open option without consuming space in the extended TCP header. Sorry for the late reply. How about adding to the last sentence: "When TFO is not used, the transport converter needs a corresponding change to RFC793 to allow posting data in SYN to application upon receiving the SYN packet". Thanks for the improved wording. > > > Better? > > Cheers, > Med > > > -----Message d'origine----- > > De : Yuchung Cheng [mailto:ycheng@google.com] > > Envoy=C3=A9 : mercredi 29 mai 2019 23:46 > > =C3=80 : BOUCADAIR Mohamed TGI/OLN > > Cc : tcpm@ietf.org > > Objet : Re: [tcpm] Progressing draft-ietf-tcpm-converters > > > > On Tue, May 28, 2019 at 11:10 PM wrote: > > > > > > Hi Yuchung, > > > > > > This spec is an Experiment which relaxes a constraint in RFC793 in th= e * > > SAME * way the TFO Experiment relaxes that * SAME * constraint. > > > > > > Given that RFC7413 isn't tagged as updating RFC793, we are assuming t= hat > > the same conclusion applies for our spec. > > > > > > I don't think an Experimental RFC can be tagged as updating RFC793, > > anyway. > > ?Which of my emails asks to tag this draft as RFC793-update? > > > > I merely pointed out, if TFO is not used, as the draft and the > > original email refer to, the draft should be explicit this requires a > > change in RFC793. It's rather vague. From nobody Mon Jun 3 11:09:27 2019 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 D350A120461 for ; Mon, 3 Jun 2019 11:09:24 -0700 (PDT) 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, 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=wizmail.org 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 MjbgV4b2du6o for ; Mon, 3 Jun 2019 11:09:23 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 D085712047E for ; Mon, 3 Jun 2019 11:09:20 -0700 (PDT) ARC-Seal: i=1; cv=none; a=rsa-sha256; d=wizmail.org; s=r201803; t=1559585360; b=zOVDb9CD73CKif//m4tOHnanHJjCsfnyp6bQ6xYA3hn+EMU/XEZvY8Lw4M7jiXgC7XO3kYrd70 OF2PfFHvHRFwCwUP5xCGJlZcQRJGSnCpaFAwnKk6QjGfN4BNHiI+Xu4iFpkrl3czL4hN1PYAAt JjwhYeFqtlnZQ7AHO6j5d18=; ARC-Authentication-Results: i=1; wizmail.org; iprev=pass (vgate18.wizint.net) smtp.remote-ip=2a00:1940:107::1:2f:0; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=wizmail.org; s=r201803; t=1559585360; bh=fELKrQbv6cPwvOba1A9rN1RK3ga3DO4ltjy5OKeAJqo=; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:DKIM-Signature; b=rpgTQGEVQ4cBdrEsrVPCcD8malcmhWheIeetkKF5DCIEOdmekXgAEq1oFZfjtx6/KuxKsDeyf1 1ZCtk6eY2hb7D/cHla+OTjmvVTJnf5SRxMkgcl6puIaY0tcgFhTLDhuIj25xC9vX4jh/Znp2Zp SnqR2pjL1EoBOT9fsPvKPWU=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r201803; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:From:Sender:Reply-To: Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive; bh=eYJetdoRnXpk0uo0LoDcHyxF6nvonOpnIu9fJERE34E=; b=Q tDO7XIFOqX8c8I1+e2nIkfc0DoVBua92E9gO4wzyYrfpj/sLyotn9oowefr4Mm5Ke8PnpijMn3RGq 00UZyHHzOZVt458P9Np+khccKThZraQLiNEP48jEHansnsYcKISkirSs0v7uab8X1jfFstBC+gAgi fX7DOkV9n0hjSv6w=; Authentication-Results: wizmail.org; iprev=pass (vgate18.wizint.net) smtp.remote-ip=2a00:1940:107::1:2f:0; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) by wizmail.org (Exim 4.92.114) (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) with esmtpsa id 1hXrOY-0002PS-Vm for tcpm@ietf.org (return-path ); Mon, 03 Jun 2019 18:09:19 +0000 To: "tcpm@ietf.org Extensions" References: <787AE7BB302AE849A7480A190F8B93302EA8E8EF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA8F7C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <4258DCF5-1588-4B97-9C05-F0722E053072@tessares.net> <3d979013-16d3-689f-45cb-e5b007fe7f13@wizmail.org> From: Jeremy Harris Openpgp: preference=signencrypt Autocrypt: addr=jgh@wizmail.org; prefer-encrypt=mutual; keydata= mQENBFWABsQBCADTFfb9EHGGiDel/iFzU0ag1RuoHfL/09z1y7iQlLynOAQTRRNwCWezmqpD p6zDFOf1Ldp0EdEQtUXva5g2lm3o56o+mnXrEQr11uZIcsfGIck7yV/y/17I7ApgXMPg/mcj ifOTM9C7+Ptghf3jUhj4ErYMFQLelBGEZZifnnAoHLOEAH70DENCI08PfYRRG6lZDB09nPW7 vVG8RbRUWjQyxQUWwXuq4gQohSFDqF4NE8zDHE/DgPJ/yFy+wFr2ab90DsE7vOYb42y95keK tTBp98/Y7/2xbzi8EYrXC+291dwZELMHnYLF5sO/fDcrDdwrde2cbZ+wtpJwtSYPNvVxABEB AAG0JkplcmVteSBIYXJyaXMgKG5vbmUpIDxqZ2hAd2l6bWFpbC5vcmc+iQE7BBMBAgAlAhsD BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCVYAYBAIZAQAKCRC85YyM5B8y34iFB/9wozIY RogNdY1aejFFixb6++y4b1riyjMvWEULeEzDlQ0lMT6Z3PxXhZILD4y4aP7Kzx0ozXa5qaKy 41EAPKQoPipnRAH04QytJbIERvz8Tot/LeCVKUc0G9DVxOPBD03czTgqgz4EjV2qvnLF+rTU 0YBevrNCluKosGSd+3RvLWVu0hBhn9pELKfXJNSQXZb+TpHDhSDZ/gCrglBEOhA6YWbDb/4g z+5TFKdk+B++iAQZSHv7zISabjN+BPYgI47A+MU4JycoXaAUnMc0l5ba6fGNaIrzruE4aAZr lP5o+7mlU9Mm0QJqdqYxYPAiplJGrZv+YXH1fp5ueEK3l+NGuQENBFWABsQBCADphLHaKToR uR/E7THerBiCjDatwCaETOKOTY2zRBQpaQ32p/F2XIGLS8Cc27+grZSKQ6ZX0ZN47O+AFyFH F8DH90IXZFpJR3Rb8zgXT8jnLX08DM31eECZHnRzFhGlOmq6WAUlqB3GKCPUCY2c4eTRXyoX LteTxrXCYoj45y/YmvlZrlonBNjPBAyHiO/LNz+V7fZtNsN7N/XGrnLbcdNfNd+SD1ENmbLJ 8RvyymxguTyB/ka9JdjHHIoQEJ6L166B3hhfCHpt8iC0GPZkti9IMl0NoJ029jJm3Jq1qEce EBn5H5QMGn6Fq64iXwTsO1TMNUwpWx8pjvV7wVIxjI8ZABEBAAGJAR8EGAECAAkFAlWABsQC GwwACgkQvOWMjOQfMt9N6Af8CS2CTrMQFdhkGEtBXmL4ifD8UHFkBRBGmM8ZL2fWUBTZXT8m rdRMOK6tcPnKWaCvWvKr0knt970j/DyAgFmH8hgOi3yctigFecVDjjilAeCJMq38s1tYKYiL DbBdHWtdkA9uHZwq3lfd3QxcEEO3QamQF+dO7h8gAOXlG+po87Hm+E0wz4swIB8+S37Jzrx9 uu0LSFDfJCTK+TIKGa5Un8LxPxyq9WnnNDh72zK7BiRidk/s40KcNod83NM4Hn/sbGfyLa8s S0F3ME0S+ocSMOiu/ZHHOiwpLYNbwTJ7stZxGsrguWeT9P+amxbA/YlK95LedstwvN+WcHZ7 d++Arg== Message-ID: <70e482bb-b1d6-f50b-2032-4707013ccfc9@wizmail.org> Date: Mon, 3 Jun 2019 19:09:18 +0100 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: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters 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, 03 Jun 2019 18:09:25 -0000 On 03/06/2019 18:58, Yuchung Cheng wrote: > On Mon, Jun 3, 2019 at 7:37 AM Jeremy Harris wrote: >> >> On 29/05/2019 17:27, Praveen Balasubramanian wrote: >>> 2. Ability to RECEIVE data in SYN payload on server. This is only supported on all OS *after* 3WHS is completed. This is per RFC 793. The only exception is if TFO API is used, and then if cookie is validated the application will receive early-data. There is no way to retrieve early data otherwise. >> >> There is a bit in the tcp_fastopen sysctl for Linux described so: >> >> 0x200: (server) accept data-in-SYN w/o any cookie option present. >> >> It doesn't say explicitly that the data is presented to the application >> (neither does the doc for the with-cookie server TFO control bit). >> Does anybody know whether it is? > I am not sure what you mean - what is "it" in your last question? Whether the data, that arrived on the SYN, is available to the application (before, the item I forgot to specify, the ACK for the SYN,ACK arrives at the server). > when this option is used (0x200), TFO will accept the data in SYN w/o > or w/ any cookie. Accept(2) will return in 3WHS. but note that SYN-ACK > is returned immediately upon receiving SYN-data in this mode. so this > mode will not support the latest tcpm-converter proposal where SYN-ack > is delayed upon (in-data) cookie verification and proxy 3WHS > completion. This change requires non-trivial implementation for a > listener handling millions of requests in Linux. That's a separate point of interest, as is whether it will ever be feasible to carry data on the SYN,ACK (either for cookieless or cookieful mode). -- Cheers, Jeremy From nobody Mon Jun 3 12:10:01 2019 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 AADAC12062A for ; Mon, 3 Jun 2019 12:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_MED=-0.01, 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 nAG6HLsJIMNR for ; Mon, 3 Jun 2019 12:09:57 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 8499F12064B for ; Mon, 3 Jun 2019 12:09:56 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id s3so5039152wms.2 for ; Mon, 03 Jun 2019 12:09:56 -0700 (PDT) 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=zR+EZCGd0ZW062+hVucKrV6DjjeSV80h2Bw0CfaAa5E=; b=kBqG1Lm5CKhJygyjwquU2FRvVwrjvtY/fHqOVMwqkIrMbtyljsTS/DqP2wl/yiAm9q aIKH7zaluIDngglvMySUsCrcCkMnth5wSWmUuv6q+0uHLT/25yrfHWVwqhUYYXSGF9IQ m5g3wDpzos4hG+oWvbABrpiYCxvQQ47yq8LXb3s5LLLMbHiYCQBDYc32nMeY1oPGIt/t iGfZ/3Qe+W1gqszUeMWy6iy6+LjdyWTpbOtYL63C9hoGuBb88gY3sD/yY7YY/oNpjo4G BBqs1cNw9KoZqCWBuLmHqGbci+2JvJvo418J35Cf64GQcBgn0ai8g4mQymXHLmA+8UwI KcLA== 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=zR+EZCGd0ZW062+hVucKrV6DjjeSV80h2Bw0CfaAa5E=; b=VKBgyNmWT6cALFdysGphfLtX43JV7OATbjqJOqtA9nSYyld0tl7gMiG4DZY3B7vATe L1ez03atxIBX/9Tqsrl/Lh6HSkM32PJlVEHtHQCWXQPF63Dc67u5v1oJpsz2BzdIpogw u3lu9P2wDrsQW/eXC+nvCOSgDzVYdDrNldj6QXxND9CqYHBFbL5Jtbs2wfpLsdLeSyFW 6Qh1okw1pHET2iJn3oz97lWsTXBm78fgl0TWqXA9Katsc2GAO7Yn5HcBOIkK2GP45zom ktegvqCL4Xv5c1lAXd7SHIIXjsGDX6FJKYsClChi9eWoSgdbWQ/yQ+7WXk1ZSQbuobJs B8VA== X-Gm-Message-State: APjAAAX9cQw6hp2o+OxX1FwcOKSboZfK0FmZm4xokmTHCOAbrRLvdgV7 IkTAhLfRqt/bKrIrHzmwpZDY5TAiGe4IpVr66TmzfA== X-Google-Smtp-Source: APXvYqzLjgwBlyuKq+loeT3gugdOvk/g+9Ortdw9+0WHm5Ty/kyQ0iT2/EtlNqiFZwZfDHC9E1AbbarzfV0qXDkG3vc= X-Received: by 2002:a05:600c:291:: with SMTP id 17mr4633029wmk.32.1559588994434; Mon, 03 Jun 2019 12:09:54 -0700 (PDT) MIME-Version: 1.0 References: <787AE7BB302AE849A7480A190F8B93302EA8E8EF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA8F7C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <4258DCF5-1588-4B97-9C05-F0722E053072@tessares.net> <3d979013-16d3-689f-45cb-e5b007fe7f13@wizmail.org> <70e482bb-b1d6-f50b-2032-4707013ccfc9@wizmail.org> In-Reply-To: <70e482bb-b1d6-f50b-2032-4707013ccfc9@wizmail.org> From: Yuchung Cheng Date: Mon, 3 Jun 2019 12:09:15 -0700 Message-ID: To: Jeremy Harris Cc: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters 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, 03 Jun 2019 19:10:00 -0000 On Mon, Jun 3, 2019 at 11:09 AM Jeremy Harris wrote: > > On 03/06/2019 18:58, Yuchung Cheng wrote: > > On Mon, Jun 3, 2019 at 7:37 AM Jeremy Harris wrote: > >> > >> On 29/05/2019 17:27, Praveen Balasubramanian wrote: > >>> 2. Ability to RECEIVE data in SYN payload on server. This is only sup= ported on all OS *after* 3WHS is completed. This is per RFC 793. The only e= xception is if TFO API is used, and then if cookie is validated the applica= tion will receive early-data. There is no way to retrieve early data other= wise. > >> > >> There is a bit in the tcp_fastopen sysctl for Linux described so: > >> > >> 0x200: (server) accept data-in-SYN w/o any cookie option present. > >> > >> It doesn't say explicitly that the data is presented to the applicatio= n > >> (neither does the doc for the with-cookie server TFO control bit). > >> Does anybody know whether it is? > > I am not sure what you mean - what is "it" in your last question? > > Whether the data, that arrived on the SYN, is available to the > application (before, the item I forgot to specify, the ACK for the > SYN,ACK arrives at the server). Then answer is yes (if not clear from my previous post). > > > when this option is used (0x200), TFO will accept the data in SYN w/o > > or w/ any cookie. Accept(2) will return in 3WHS. but note that SYN-ACK > > is returned immediately upon receiving SYN-data in this mode. so this > > mode will not support the latest tcpm-converter proposal where SYN-ack > > is delayed upon (in-data) cookie verification and proxy 3WHS > > completion. This change requires non-trivial implementation for a > > listener handling millions of requests in Linux. > > That's a separate point of interest, as is whether it will ever be > feasible to carry data on the SYN,ACK (either for cookieless or > cookieful mode). > > -- > Cheers, > Jeremy > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Jun 3 18:25:46 2019 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 82A7E1200F4; Mon, 3 Jun 2019 18:25:38 -0700 (PDT) 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.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <155961153844.24918.3595391320504211546@ietfa.amsl.com> Date: Mon, 03 Jun 2019 18:25:38 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-13.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: Tue, 04 Jun 2019 01:25:39 -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 : Transmission Control Protocol Specification Author : Wesley M. Eddy Filename : draft-ietf-tcpm-rfc793bis-13.txt Pages : 104 Date : 2019-06-03 Abstract: This document specifies the Internet's Transmission Control Protocol (TCP). TCP is an important transport layer protocol in the Internet stack, and has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFC 1122, and should be considered as a replacement for the portions of that document dealing with TCP requirements. It updates RFC 5961 due to a small clarification in reset handling while in the SYN-RECEIVED state. RFC EDITOR NOTE: If approved for publication as an RFC, this should be marked additionally as "STD: 7" and replace RFC 793 in that role. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-13 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 5 01:19:51 2019 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 12796120620; Wed, 5 Jun 2019 01:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 dI7uvKEuBwdQ; Wed, 5 Jun 2019 01:19:46 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (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 37F6A12061E; Wed, 5 Jun 2019 01:19:45 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id x558Jekb007400; Wed, 5 Jun 2019 10:19:40 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 62B8B1D53C1; Wed, 5 Jun 2019 10:19:40 +0200 (CEST) Received: from 131.111.5.141 by webmail.entel.upc.edu with HTTP; Wed, 5 Jun 2019 10:19:40 +0200 Message-ID: <2f4db25438fcebce3bd2121d8c54628c.squirrel@webmail.entel.upc.edu> Date: Wed, 5 Jun 2019 10:19:40 +0200 From: "Carles Gomez Montenegro" To: lwip@ietf.org, tcpm@ietf.org Cc: jon.crowcroft@cl.cam.ac.uk User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.100.2 at dash X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Wed, 05 Jun 2019 10:19:41 +0200 (CEST) Archived-At: Subject: [tcpm] [Fwd: [Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-08.txt] 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, 05 Jun 2019 08:19:49 -0000 Dear LWIG and TCPM WGs, Please find below the pointers to our latest update (rev -08) of the draft entitled "TCP Usage Guidance in the Internet of Things (IoT)". This revision aims at addressing the comments received during the WGLC. Many thanks to Ilpo, Markku and Ingemar for your thorough reviews and helpful inputs. Cheers, Carles (on behalf of all authors) ---------------------------- Original Message ---------------------------- Subject: [Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-08.txt From: internet-drafts@ietf.org Date: Tue, June 4, 2019 6:22 pm To: i-d-announce@ietf.org Cc: lwip@ietf.org -------------------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Light-Weight Implementation Guidance WG of the IETF. Title : TCP Usage Guidance in the Internet of Things (IoT) Authors : Carles Gomez Jon Crowcroft Michael Scharf Filename : draft-ietf-lwig-tcp-constrained-node-networks-08.txt Pages : 29 Date : 2019-06-04 Abstract: This document provides guidance on how to implement and use the Transmission Control Protocol (TCP) in Constrained-Node Networks (CNNs), which are a characterstic of the Internet of Things (IoT). Such environments require a lightweight TCP implementation and may not make use of optional functionality. This document explains a number of known and deployed techniques to simplify a TCP stack as well as corresponding tradeoffs. The objective is to help embedded developers with decisions on which TCP features to use. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lwig-tcp-constrained-node-networks/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-08 https://datatracker.ietf.org/doc/html/draft-ietf-lwig-tcp-constrained-node-networks-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-tcp-constrained-node-networks-08 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/ _______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip From nobody Wed Jun 5 01:59:06 2019 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 6896A12061E; Wed, 5 Jun 2019 01:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 AKdG1bGN81CB; Wed, 5 Jun 2019 01:58:56 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 8494D1200B6; Wed, 5 Jun 2019 01:58:55 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id x558wkYM025874; Wed, 5 Jun 2019 10:58:46 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 012581D53C1; Wed, 5 Jun 2019 10:58:45 +0200 (CEST) Received: from 131.111.5.141 by webmail.entel.upc.edu with HTTP; Wed, 5 Jun 2019 10:58:45 +0200 Message-ID: <184404a792aadb06ac772ffe05bc3233.squirrel@webmail.entel.upc.edu> In-Reply-To: References: Date: Wed, 5 Jun 2019 10:58:45 +0200 From: "Carles Gomez Montenegro" To: =?iso-8859-1?Q?=22Ilpo_J=E4rvinen=22?= Cc: lwip@ietf.org, michael.scharf@hs-esslingen.de, jon.crowcroft@cl.cam.ac.uk, tcpm@ietf.org User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.100.2 at violet X-Virus-Status: Clean X-Greylist: Delayed for 00:39:06 by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Wed, 05 Jun 2019 10:58:46 +0200 (CEST) Archived-At: Subject: Re: [tcpm] Review of draft-ietf-lwig-tcp-constrained-node-networks-04 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, 05 Jun 2019 08:58:59 -0000 Hi Ilpo, (CC'ing also TCPM.) First of all, sorry for the delay in our response. Thank you very much for reviewing the draft again, and for answering our questions. Your comments have been very useful to improve the quality of the document. Our updates can be found in revision -08. Please find below our inline responses to your comments. > On Sun, 10 Mar 2019, Carles Gomez Montenegro wrote: > >> > General Comments / Structure >> > ---------------------------- > > I've read the document (-07) through once again, and in general I got > a feeling that it has improved substancially! Thank you! >> In the new draft version, in some cases, we have tried to be more >> specific >> (e.g. ?message overhead?, ?memory overhead?, etc.). However, in some >> other >> cases the context may help to better determine the scope of ?overhead?, >> or >> ?overhead? relates with all the dimensions you listed (and for >> simplicity, >> we prefer to keep just ?overhead?). > > I didn't find unqualified "overheads" a problem anymore either (that is, > in case there were some as I didn't even notice them anymore). Thanks for your confirmation. >> > Small Points >> > ------------ >> > >> > Sec 3.2 Usage Scenarios, 3rd para: I fail to get the point of this >> > paragraph. There are two distinct points about the environment: >> > middleboxes on path and asymmetry in end point capabilities. No >> > implications about bringing these two in particular up in the same >> > paragraph are mentioned. That is, why I must note the asymmetry when >> > there's a middlebox? >> >> Because the middlebox will often be transparent to TCP (but not to other >> protocols). Basically, the presence of such middleboxes is a major >> motivation for use of TCP in IoT environments (e.g. RFC 8323). > > I still don't see the connection between a middlebox requiring use of > TCP and that I must note asymmetry in the scenario. But this not all that > important part of the text anyway so I guess it could be left like that. > > There's, however, duplication between the 1st and the last paragraphs > (and also somewhat with this 3rd paragraph text now that I look). In -08, we have merged part of the first and the third paragraph, which helped reduce redundancy. After this change, we believe that the first and the last paragraphs (of section 3.2) do not contain duplicated content. >> > 4.3.2 SACK >> > >> > IMHO, SACK should be subsection of loss recovery or 4.3.1 >> > should be retitled to only FR/FR. >> >> Yes, we agree with the suggestion, and prefer to make SACK a subsection >> of >> 4.3.1. >> >> > Out-of-order queue handling is unrelated to SACK, should be >> > covered somewhere else? There is implicit complexity & TCB >> > impact when the flow may have >1 MSS wnd, maybe group all these >> > (when not related to a particular mechanism that has its own >> > discussion somewhere) under a single section). >> >> Not sure if the current wording may lead to different understandings, >> but >> out-of-order is mentioned here to denote the fact that a few segments >> may >> be lost and the receiver will need to inform about the data blocks >> actually received. > > "The receiver supporting SACK will need to managed the reception of > possible out-of-order received segments, requiring sufficient buffer > space." > > This text seems to imply that because of SACK, managing ofo segments is > necessary but it is a feature that is needed also w/o SACK when TCP > supports multi-segment window. So any loss recovery regardless of SACK > will need to deal with that. What SACK adds to that on the receiver > side, is keeping track of the SACK blocks to send back. The text (after removing the SACK mention) is now before the SACK subsection. We have also added your point on the SACK-specific tasks to be done by a receiver supporting SACK. >> > No sender-side SACK aspect covered? >> >> We currently have: >> ?a sender (having previously sent the SACK-Permitted >> option) can avoid performing unnecessary retransmissions, saving >> energy and bandwidth, as well as reducing latency.? >> Is there any particular aspect you think should be added ? > > When the sender get SACK blocks from the receiver in ACKs, it need to > bookkeep the per seq/segment state to avoid sending the particular > data/segments again during the recovery. > > But perhaps there just isn't a convincing IoT scenario for the device to > be sending enough data to benefit from the sending side SACK in the first > place? Well, perhaps in some cases a device might keep a relatively large file (e.g. containing sensor readings taken over a relatively long time interval). For the sake of completeness, we have added your point on the sender needing to bookkeep the necessary state for resending only the needed data. >> > In general, there's occassionally confusion within the document >> > whether some advice/description is for the receiving or sending >> > side (this is of course scenario dependant which the implementer >> > should consider in his/her own case but the document should cover >> > both cases where applicable). >> >> We?d welcome specific suggestions of document sections where your >> comment >> applies. > > Somehow, I didn't get a similar feeling anymore so I guess some of > edits have done enough to resolve sender/receiver ambiguity below > noticable level! Thanks for your confirmation. > Here are some additional comments that I noted while reading it through > for the second time: > > 4.1.2 ECN > > 3rd para. There is an unresolved contradition related to "throughput" > in the paragraph (none of the text is "wrong" per se but the dots just > don't seem to connect well enough to make sense). ECN with 1 segment is > said to "result in very low throughput" and in the very next sentence it > is said "In addition to better throughtput...". Neither is incorrect but > I wouldn't put those statements next to each other to avoid confusion > it easily causes. Thanks for pointing this out. Markku proposed new text that solves the problem. That text is now included in -08. > Section 4.2 > > "single-MSS", I'd use "single segment" (like the change you made into > the annex table) throughout the document. Done. > The use of "stack" in the 4.2 and its subsections would be better as > "window" because some of the text applies also to the unconstrained > end of the connection that is not a single mss/segment stack > but is only communicating with such a stack. We see your point and we have replaced “stack” with “window” in some instances. However, in some cases “stack” was actually intended as “implementation”, therefore in those cases we have left “stack” unmodified. > Section 4.2.4 > > 2nd para. "cannot use" -> "cannot benefit from". It is possible > to "use" but no benefits can be gained. It's relevant in particular > when the connection is one segment but the sender is unconstrained, > the text now excludes this valid scenario by adding "than for a more > powerful TCP stack" but it shouldn't, IMHO. Agreed. > Nits: > > In the pdf version, the "Subsection x.x.x" meta linkage does begin > only from "section". Perhaps this is something that might be solved at the RFC editor stage... > Section 5.2 2nd para: comsuming -> consuming Done. Once again, thank you very much for all your feedback! Cheers, Carles (on behalf of all coauthors) From nobody Wed Jun 5 02:28:26 2019 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 5C31C120635; Wed, 5 Jun 2019 02:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 gh-kwGU_bU-S; Wed, 5 Jun 2019 02:28:16 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 4B25A120629; Wed, 5 Jun 2019 02:28:16 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id x559S68N039249; Wed, 5 Jun 2019 11:28:07 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id CE21E1D53C1; Wed, 5 Jun 2019 11:28:05 +0200 (CEST) Received: from 131.111.5.141 by webmail.entel.upc.edu with HTTP; Wed, 5 Jun 2019 11:28:06 +0200 Message-ID: In-Reply-To: References: <4de71836-c2d1-2a64-6836-8d69a38d4a3d@ericsson.com> Date: Wed, 5 Jun 2019 11:28:06 +0200 From: "Carles Gomez Montenegro" To: "Markku Kojo" Cc: lwip@ietf.org, tcpm@ietf.org, jon.crowcroft@cl.cam.ac.uk, tcpm@ietf.org User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.100.2 at violet X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Wed, 05 Jun 2019 11:28:07 +0200 (CEST) Archived-At: Subject: Re: [tcpm] [Lwip] WGLC review of draft-ietf-lwig-tcp-constrained-node-networks 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, 05 Jun 2019 09:28:19 -0000 Dear Markku, Thank you very much for your comprehensive and detailed review of the draft. Your constructive comments have been very useful to address issues and improve the quality of the document. Our updates can be found in revision -08. Please find below our inline responses to your comments. > Hi all, > > I have reviewed the -07 version of this draft for the WGLC. > > The draft is very useful for many developpers using or considering of > using TCP in CNN scenarious. It has improved a lot from the previous > versions but there are still a number of issues worth addressing. > > See comments below. > > Best regards, > > /Markku > > Sec 4.1. > > Title: Path properties > - Would it be better to use "Addressing path properties" or something > similar as TCP cannot (much) affect the properties? Sounds good! > Sec. 4.1.1. > > If I understand it correctly, the discussion in this section is intended > to be all about avoiding Path MTU discovery when running TCP oevr IPv6? > Therefore, "Avoiding Path MTU Discovery in IPv6" would probably be > a better title? >From our point of view, the section is actually about setting the MSS to a suitable value, which then may help avoiding the need to support Path MTU Discovery, but also the need to perform IP-layer fragmentation at the source. We have explicitly added the latter in -08. > In addition, to my understanding TCP implementations typically address > the presence of TCP options such that they eat the necessary space for > TCP options from the payload, not by increasing the IP datagram size > if TCP options are present. For example, if SMSS is set to, let's say > 1460 octets, and a TCP sender adds a TCP timestamp option (12 bytes) it > will send only 1448 bytes of payload in a TCP segment? > > What the draft now says in this respect is on the safe side, but it > might be overcautious. I don't remember any RFC saying how SMSS and > adding options to a TCP segment are related. Maybe someone of the TCP > implementors may shed more light to this how? We have tried to address your two comments above. On this matter, we had received feedback that this measure (advertising an MSS smaller than 1220 bytes) would be safe, but we have tried to reflect that this might not be necessary, and even overcautious. > The second but last para discussing IPv4 in this context is very > confusing. In particular, the 2nd sentence > > "In IPv4, the MTU is 576 bytes." > > is simply incorrect. In IPv4 the requirement is that any host must be > able to accept datagrams of up to 576 octets, but there is no upper > limit of 576 for IPv4 MTU! Indeed. The 2nd sentence missed the word “minimum” before “MTU”, and we have made several updates to the paragraph. > Sec. 4.1.2. > > "In such traffic patterns, it is more difficult to > detect packet loss without retransmission timeouts ..." > > -> > > "In such traffic patterns, it is more difficult and often > impossible to detect packet loss without retransmission timeouts > unless ECN is enabled ..." Done. > > "When the congestion window of a TCP sender has a > size of one segment, the TCP sender resets the retransmit timer, and > the sender will only be able to send a new packet when the retransmit > timer expires [RFC3168]. Effectively, the TCP sender reduces at that > moment its sending rate from 1 segment per Round Trip Time (RTT) to 1 > segment per RTO, which can result in a very low throughput. In > addition to better throughput, ECN can also help reducing latency and > ECN can also help reducing latency and jitter." > > This text is somewhat inaccurate in terms of how ECN works if only a > single segment is in flight (cwnd = 1 MSS) and confusing when it says > "which can result in a very low throughput". The latter is kind a true, > but also necessary to avoid congestion and, after all, it may result in > higher throughput compared to the case where ECN is not used and > retransmissions are needed. > > I'd rephrase the above to something along the lines: > > "When the congestion window of a TCP sender has a > size of one segment and a TCP ACK with an ECN signal (ECE flag) arrives > at the TCP sender, the TCP sender resets the retransmit timer, and > the sender will only be able to send a new packet when the retransmit > timer expires. Effectively, the TCP sender reduces at that > moment its sending rate from 1 segment per Round Trip Time (RTT) to 1 > segment per RTO and reduces the sending rate further on each ECN signal > received in subsequent TCP ACKs. Otherwise, if an ECN signal is not > present in a subsequent TCP ACK the TCP sender resumes the normal > ack-clocked transmission of segments [RFC 3168]. Thank you very much for the proposed text. The draft has been updated accordingly. > It might be also good to rearrange the text in the second and third > paragraphs to disscuss the effect of retrasmission and timeouts more > coherently. I may suggest text for this. We will welcome any suggestion you may have in this regard. > Sec 4.2. > > "This section discusses TCP stacks that focus on transferring a single > MSS." > > Maybe better: > > "This section discusses TCP stacks that allow transferring only a single > MSS at a time." Done. > Sec 4.2.1. > > Last sentence: > > "For this use of CoAP, a maximum TCP window > of one MSS will be sufficient." > > This is not necessarily true. If both TCP stacks involved allow a TCP > window larger than 1 MSS and a CoAP request or response larger than one > MSS is in use, it can be delivered more efficiently than in case where > max TCP window is one MSS. > > Furthermore, this may also not be the case if a CoAP over TCP > application uses short-lived TCP connections. Why? Because then the > mandatory CSM message that each CoAP endpoint sends after the 3WHS may > introduce an additional RTT as it cannot necessarily be sent during the > same RTT with the first CoAP request/response. Of course, if the CSM > message and the first CoAP request/response message fit into a single > MSS and the TCP Nagle algorithm is disabled, such a single MSS window > does not result in an additional RTT. We have updated the sentence accordingly. > Sec. 4.2.2. > > "A TCP implementation for a constrained device that uses a single-MSS > TCP receive or transmit window size may not benefit from supporting > the following TCP options: Window scale [RFC7323], TCP Timestamps > [RFC7323], Selective Acknowledgments (SACK) and SACK-Permitted > [RFC2018]." > > It may be useful to mention that a TCP sender can benefit from > Timestamps in detecting spurious RTOs that are quite likely to occur > in CNN scenarios. Done. > > Sec. 4.2.3. > > 2nd para: > > "A device that advertises a single-MSS receive window should avoid use > of Delayed ACKs in order to avoid contributing unnecessary delay (of > up to 500 ms) to the RTT [RFC5681], which limits the throughput and > can increase the data delivery time." > > This should not appear as a generic recommendation as it is not > correct for some typical usage scenarios such as request-response > traffic where the node with a single-MSS receive window is the server > sending the responses. With delayed ACKs it can biggyback the TCP ACK > with the response if the response is sent before the delayed ACK timer > expires, thus avoiding unnecessary pure TCP ACKs. > > So, here, like in Sec 4.3.2., it is important to indicate that it depends > on the communication pattern whether delayed ACKs are useful or harmful. We have modified this text accordingly. > 3rd para: > > "A device that can send at most one MSS of data is significantly > affected if the receiver uses Delayed ACKs, e.g., if a TCP server or > receiver is outside the CNN." > > Again, this does not hold in all cases. E.g., if the server is outside > of the CNN and request-response communication is used. We have modified and reorganized the text accordingly. > The "split hack" is not advisable workaround. First for the reason > stated in the end of the para, but more importantly because it simply > does not necessarily even work; a TCP receiver is requited to > acknowledge every second full-sized segment, but not two consecutive > small segments. Agreed. This comment has been incorporated into the text. We discuss the “split hack”, but we do not recommend it. > 4th para: > > "Similar issues happen when a sender uses the Nagle algorithm. > Disabling the algorithm will not have impact if the sender can only > handle stop-and-wait operation." > > Actually it does have an impact in some specific usage scenarios, e.g., > with CoAP over TCP disabling the Nagle algorithm allows sending the > mandatory CSM message and the first CoAP msg (request) and possibly > also CSM and the first response without unnecessarily waiting for a TCP > ACK of the CSM msg. This is of particular impact if short-lived TCP > connections are in use with CoAP over TCP. The text above refers to stop-and-wait operation. In your example above, were you considering stop-and-wait operation? > Sec. 4.2.4. > > RTO is not estimated but calculated using estimated RTT and deviation > from it. That is, modify: > > RTO estimation -> RTO calculation Done. > 2nd para: > "[RFC6298] describes the standard TCP RTO algorithm." > > You may delete this sentence and cite RFC 6298 in the first sentence > of the Sec 4.2.4 where the algorithm is first mentioned. Done. > 3rd para: > "As an example, an adaptive RTO algorithm for CoAP over UDP has been > defined [I-D.ietf-core-cocoa] that has been found to perform well in > CNN scenarios [Commag]." > > Maybe not a good idea to cite the current version of CoCoA RTO > algorithm (v3) that have been found also to have detrimental behavior? Done. > > Sec. 4.3.1. > > "Assuming that Delayed ACKs are used by the receiver, the > mentioned algorithms work efficiently for window sizes of at least 5 > MSS: If in a given TCP transmission of segments 1, 2, 3, 4, 5, and 6 > the segment 2 gets lost, the sender should get an ACK for segment 1 > when 3 arrives and duplicate acknowledgements when 4, 5, and 6 > arrive. It will retransmit segment 2 when the third duplicate ACK > arrives. In order to have segment 2, 3, 4, 5, and 6 sent, the window > has to be at least 5 MSS. With an MSS of 1220 byte, a buffer of the > size of 5 MSS would require 6100 bytes." > > The requirement for the window size to be of at least 5 segments does > not hold if Limited Transmit is in use. We have updated the text (including that now we mention “up to 5 MSS”), along with updates in the Limited Transmit paragraph. > Also, the requirement of at least 5 segments is valid only if the ACK > for the segment 1 was held by the DelAck timer, i.e., the requirement > holds approx. with 50% probability. That is, if the segment 1 got > acknowledged (because there was also a segment before segment 1 and > that was held by DelAck timer), only a window size of 4 MSS is needed. We have modified the text accordingly. > "For bulk data transfers further TCP improvements may also be useful, > such as limited transmit [RFC3042]. > > Limited Transmit is not useful only for bulk data transfers but for any > transfer that has more than one segment in flight. Small transfers tend > to benefit more, because they are more likely to not receive enough > dupacks. We have modified the paragraph accordingly. > Sec. 4.3.1.1. > > "... a sender (having previously sent the SACK-Permitted > option) can avoid performing unnecessary retransmissions, saving > energy and bandwidth, as well as reducing latency." > > It might be worth mentioning also that SACK often allows for faster > loss recovery when there is more than one lost segment in a window of > data (i.e., recovery with less RTTs). Done. > Sec. 4.3.2. > > Disabling delayed ACKs on a client for infrequent request-response > traffic with small messages might be advisable, too. It would allow > an immediate ACK for the data segment carrying the response. > > This comment holds for Sec. 4.2.3 as well. Added, thanks. > Sec. 5.3. > > "A mean TCP NAT binding timeout of 386 > minutes has been reported, while in some cases, inactivity timeouts > are in the order of a few minutes [HomeGateway]. > > Reporting just the mean TCP NAT binding timeout from [HomeGateway] does > not give a correct view of the results in this study, because the > meaasured timeouts were highly variable and some devices had a very long > timeout (or no timeout at all), yielding a very high mean timeout value. > Therefore, we reported median and it would be more descriptive to report > it here as well. The median of the measured TCP NAT binding timeouts in > this study was around 60 mins, the shortest being around 2 mins. That is, > clearly more than 50% of the devices had timeout shorter than RFC > 5382 recommended minimum of 124 mins. > > In the light of these results, it may be hard to find a proper timeout > value for the application-layer heartbeat messages, and it might be > worth mentioning, I think. We have updated the section based on these comments. > Nits: All done, except for the “Bit-Error Rate” suggestion. The Collins English dictionary uses the non-hyphenated form. > Sec 1: > > 1st para: Add references and cite 6LoWPAN, RPL, and CoAP. > > > 3rd para: "At the application layer, CoAP was developed over UDP > [RFC7252]." > > - this seems to cite UDP incorrectly while the intent is to cite CoAP. > If you cite CoAP in the first para, you do not need to cite here at > all. > > "This the main reason..." -> "This is the main reason..." > > > 5th para: > > "Given the limited resources on constrained devices, careful "tuning" > of the TCP implementation can make an implementation more lightweight." > > Instead of saying "tuning" of the TCP implementation, I'd say that careful > selection of optional TCP features can make an implementation more > lightweight (and improve operation in CNNs). > > 6th para: > > "This document provides guidance on how to implement and use TCP in > CNNs. > > -> > > "This document provides guidance on how to implement and configure TCP > as well as how TCP is advisable to be used by applications in CNNs. > > > Sec 3.1., last para: > > high bit error rate -> high bit-error rate > > > Sec 5., first sentence: > > "how a TCP stack can be used" -> "how TCP can be used" Once again, thank you very much for your comprehensive review and constructive suggestions! Cheers, Carles (on behalf of all authors) From nobody Wed Jun 5 02:35:08 2019 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 9874A12063B; Wed, 5 Jun 2019 02:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 3EYWzWf2dxCs; Wed, 5 Jun 2019 02:35:05 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (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 B1235120135; Wed, 5 Jun 2019 02:35:04 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id x559YwFL048426; Wed, 5 Jun 2019 11:34:58 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 6F09A1D53C1; Wed, 5 Jun 2019 11:34:57 +0200 (CEST) Received: from 131.111.5.141 by webmail.entel.upc.edu with HTTP; Wed, 5 Jun 2019 11:34:58 +0200 Message-ID: In-Reply-To: References: Date: Wed, 5 Jun 2019 11:34:58 +0200 From: "Carles Gomez Montenegro" To: "Ingemar Johansson S" Cc: "tcpm@ietf.org" , "lwip@ietf.org" , jon.crowcroft@cl.cam.ac.uk User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.100.2 at dash X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Wed, 05 Jun 2019 11:34:58 +0200 (CEST) Archived-At: Subject: Re: [tcpm] [Lwip] WGLC review of draft-ietf-lwig-tcp-constrained-node-networks 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, 05 Jun 2019 09:35:06 -0000 Hi Ingemar, Thank you very much for reviewing the draft and for your suggestions. Your feedback is timely and very welcome. Based on your comments, in the last revision of our document (-08) we have added a new subsection (subsection 4.3.3) that discusses the Initial Window setting in the context of CNNs. Cheers, Carles (on behalf of all authors) > Hi > > I hope that I am not too late with the review. > > Perhaps this has been brought up earlier, and it that is the case then > sorry > for kicking in open doors. > > > > I have read but to not seen any mention of the initial congestion window > size. Today the initial window in most TCP stacks is set to 10*MSS and > this > may well be used by Nb-IoT implementers that are unaware of default > settings. > > While this is likely not an issue if he applications transmit small > objects > that fit in a few segments, it can become an issue with larger object > transfers and if a burst of 14600 bytes overflows a tiny network buffer. > > Should this be addressed, possibly with a recommendation to adjust the > initial window based on network constraints ? > > > > /Ingemar > > ================================== > > Ingemar Johansson M.Sc. > > Master Researcher > > > > Ericsson Research > > Network Protocols & E2E Performance > > Labratoriegränd 11 > > 971 28, Luleå, Sweden > > Phone +46-1071 43042 > > SMS/MMS +46-73 078 3289 > > ingemar.s.johansson@ericsson.com > > www.ericsson.com > > > > Nothing to stop this > > being the best day ever > > U2 > > ================================== > > > > _______________________________________________ > Lwip mailing list > Lwip@ietf.org > https://www.ietf.org/mailman/listinfo/lwip > From nobody Wed Jun 5 03:36:16 2019 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 736951200CD; Wed, 5 Jun 2019 03:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNwD9JmYWEho; Wed, 5 Jun 2019 03:36:04 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60065.outbound.protection.outlook.com [40.107.6.65]) (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 47941120649; Wed, 5 Jun 2019 03:36:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4cFAl2Uzc3wk1ZvXJmCOhlEa3zy+DhvgtdbyuRcBdtc=; b=g5wdF4HwZn4lWC4U00EceAGXac0JpcTKjqSvsPxRMpnVQvyrWIPth4yQKDWOHr72LngHrOCgeO2mRsHnDLV0J+SWVZMJ55veKQReubvqjQo18fiWsyLf+eRZcxvKIsGA/CZayyxGGS/8j8g6IHJ3ivZGIiFGL02y7r48dTDdntQ= Received: from HE1PR07MB4425.eurprd07.prod.outlook.com (20.176.167.142) by HE1PR07MB4220.eurprd07.prod.outlook.com (20.176.166.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.12; Wed, 5 Jun 2019 10:36:00 +0000 Received: from HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::802b:5182:975c:99da]) by HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::802b:5182:975c:99da%3]) with mapi id 15.20.1965.011; Wed, 5 Jun 2019 10:36:00 +0000 From: Ingemar Johansson S To: Carles Gomez Montenegro CC: "tcpm@ietf.org" , "lwip@ietf.org" , "jon.crowcroft@cl.cam.ac.uk" , Ingemar Johansson S Thread-Topic: [Lwip] WGLC review of draft-ietf-lwig-tcp-constrained-node-networks Thread-Index: AdUFoNWJ0yX8rjm/R0SxdahRUHAdrAV4RskAAAIZvSA= Date: Wed, 5 Jun 2019 10:36:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.80] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7f94b2d8-74b1-412d-018b-08d6e9a19a25 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:HE1PR07MB4220; x-ms-traffictypediagnostic: HE1PR07MB4220: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4941; x-forefront-prvs: 00594E8DBA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(366004)(396003)(376002)(346002)(13464003)(51914003)(189003)(199004)(14454004)(25786009)(966005)(14444005)(256004)(99936001)(9686003)(71190400001)(478600001)(15974865002)(68736007)(66574012)(74316002)(71200400001)(2171002)(53936002)(81166006)(54906003)(6246003)(107886003)(4326008)(6116002)(81156014)(3846002)(8676002)(99286004)(76176011)(7696005)(8936002)(33656002)(66476007)(76116006)(66946007)(6306002)(316002)(66616009)(73956011)(53546011)(86362001)(6506007)(305945005)(6436002)(2906002)(229853002)(7736002)(55016002)(6916009)(446003)(5660300002)(102836004)(11346002)(66446008)(66066001)(52536014)(476003)(186003)(66556008)(64756008)(26005)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4220; H:HE1PR07MB4425.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 30wXeizIGfHgm2yp8G8rg5kobnmln0US3Hr1OO0ixCk61nKHwdoGdiYD/vNiifSG35l6csMHDFGuhyXPMt5kvZFu2DUAn9EhFflY9f30oQ4/RFCvisEee5d1BybPb6FOCKiJvxlVAloC8aTlDjDezDtj7dTPm9jiCSsdAgcll/gPlq4gc79ALyIu4CoBbWqHqrM/aGj0txn9nl0x2/TVh4sG+m3qqNNl1+8yHrRRocmef3EyDjtMupYJT07XRklpwfMKSVTMDsBVrhVJ+cD/ic+QYIW4UXQKDEtkn4Td+4Iojz98Rvb4ptgDdiu7GpA90OXSEt6L3B453JmsQIBflaV1lV6IQbqANgHc/TnU7s0ivMVTPEBd0LmFf6snlz5MG/giO88jJ+mPFdhRpbG6POQ3/M/k/gPFm8OYTXRAlMc= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_055C_01D51B9B.3A686A60" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7f94b2d8-74b1-412d-018b-08d6e9a19a25 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2019 10:36:00.2807 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ingemar.s.johansson@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4220 Archived-At: Subject: Re: [tcpm] [Lwip] WGLC review of draft-ietf-lwig-tcp-constrained-node-networks 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, 05 Jun 2019 10:36:08 -0000 ------=_NextPart_000_055C_01D51B9B.3A686A60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi And thanks for the update, the added text looks very good /Ingemar > -----Original Message----- > From: Carles Gomez Montenegro > Sent: den 5 juni 2019 11:35 > To: Ingemar Johansson S > Cc: tcpm@ietf.org; lwip@ietf.org; jon.crowcroft@cl.cam.ac.uk > Subject: Re: [Lwip] WGLC review of = draft-ietf-lwig-tcp-constrained-node- > networks >=20 > Hi Ingemar, >=20 > Thank you very much for reviewing the draft and for your suggestions. = Your > feedback is timely and very welcome. >=20 > Based on your comments, in the last revision of our document (-08) we = have > added a new subsection (subsection 4.3.3) that discusses the Initial Window > setting in the context of CNNs. >=20 > Cheers, >=20 > Carles (on behalf of all authors) >=20 >=20 > > Hi > > > > I hope that I am not too late with the review. > > > > Perhaps this has been brought up earlier, and it that is the case = then > > sorry for kicking in open doors. > > > > > > > > I have read but to not seen any mention of the initial congestion > > window size. Today the initial window in most TCP stacks is set to > > 10*MSS and this may well be used by Nb-IoT implementers that are > > unaware of default settings. > > > > While this is likely not an issue if he applications transmit small > > objects that fit in a few segments, it can become an issue with = larger > > object transfers and if a burst of 14600 bytes overflows a tiny > > network buffer. > > > > Should this be addressed, possibly with a recommendation to adjust = the > > initial window based on network constraints ? > > > > > > > > /Ingemar > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Ingemar Johansson M.Sc. > > > > Master Researcher > > > > > > > > Ericsson Research > > > > Network Protocols & E2E Performance > > > > Labratoriegr=E4nd 11 > > > > 971 28, Lule=E5, Sweden > > > > Phone +46-1071 43042 > > > > SMS/MMS +46-73 078 3289 > > > > ingemar.s.johansson@ericsson.com > > > > www.ericsson.com > > > > > > > > Nothing to stop this > > > > being the best day ever > > > > U2 > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > _______________________________________________ > > Lwip mailing list > > Lwip@ietf.org > > https://www.ietf.org/mailman/listinfo/lwip > > >=20 ------=_NextPart_000_055C_01D51B9B.3A686A60 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVfDCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGDTCCA/WgAwIBAgIQ Us79UtuT8yEU6XIq+TroQjANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTI3 MTAxMzQ4WhcNMjAxMTI3MTAxMzQ3WjB0MREwDwYDVQQKDAhFcmljc3NvbjEcMBoGA1UEAwwTSW5n ZW1hciBKb2hhbnNzb24gUzEvMC0GCSqGSIb3DQEJARYgaW5nZW1hci5zLmpvaGFuc3NvbkBlcmlj c3Nvbi5jb20xEDAOBgNVBAUTB0VQTElKT0gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCvxK7X3xRTAzY+JaEVXSFcykcRDnb9xJCcMYXRb7WCh0HpVZ7PThGgp0ZUNQQJ9ypm7YcIcwRD kYdD4fgxGLU1bIUC4GcH7rKiuf93b+Ec3jsrkSEkCsXkO7ROjlS9+7y7H/qC8bB8D4CTQNs15o3J 0njOaYngdmLGb8bwYV47hv3sAiyqoY0aZeGZyk2a/D9Kc28b+towJxQrGnekMxynyQQesKF7mFaA gtlEa5bNbLEfIki5tZWceSZEd5xXxuib7vv0Rb/Gd+Q+jyvobAEyd5RDB6i9HAA/FFPZIJTgM+k9 7yIFPPhpLjjcjeowqH9PlEaody2drdP67tBDnNQTAgMBAAGjggHGMIIBwjBIBgNVHR8EQTA/MD2g O6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMu Y3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxp YS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYzLmNlcjArBgNVHREEJDAigSBpbmdlbWFyLnMuam9oYW5zc29uQGVy aWNzc29uLmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRw czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEF BQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFH5/jYsQz4BrrLa7pwQSkqtzL4EOMB8GA1UdIwQYMBaA FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEA uwe9UtkD6Q6/dW/uQOCxTOaGCX76lOy+a0Fqlyh+ZmlS8qWj8YTCtD866gJOXMzYUMVFrWoeggvP 9j/MBmkDDuuJMgCkN3TEuAu4AF9ekcbm/yjWOUFx3kje0SYL+GNwN50He1tuOlmHrsHo7S89kOL6 Pq8+QMRSESzEqva7nC6sJdYxXGyWAagM1ZWFnJTtFCzsW6Tm6P6rpit4yCPYvPSgNPhPRj7UbHon vU4uwGBiO15aKLwg0jfoJn6wF/CZqtGeza+ucmcuEKA+y/IRnQ2pA5+p3QnX41eypQ7OJfCG5U6k fXjxyu7PGMompQQutZk75tw76wvE8kWj5VpDNf0dRVhq/PQugzqiRjrF5tFSQbOnq1GGQ4X3PhJ8 TBaoC4otM95ZguVQrM8wdYMSxeinbJY4T91eVXYltNgtUd84zbmL/1JgVa7PN3wASXPhguc0WZu3 OWNn31yKlqL/QmgDEoOs8UsNqYU7ngsg620TE9tta4S96LXRhXhBiQCDKR16ZhEITbaJPT7KgoMO 30YCHQa0K7ah5UxC9S6+E6cPK+uKyHvzXzjNdILMh6DXQFMblld6ax+to7tQQEkv1Xr4tjCN2H/z elNX2LGB1lO2qra3MfgaENY5SMk6sIi4Y4QDrVEBnrZeKstS9Qd3TCvc+fHu6bt3wU9Tk3K0dOAw ggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoM C1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEy MTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOC Ag8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM3 0k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5 S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT 05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PV tO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBs bpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUO xSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT 9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx 5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0 dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9z aXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1Ud EwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYs aHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBA oD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3Rj YXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0G A1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuq F+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhlto FS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBAR xr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55d rdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPg vLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+ i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GI Tb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5m dZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeC aPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79 UtuT8yEU6XIq+TroQjAJBgUrDgMCGgUAoIIBfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xOTA2MDUxMDM1NTlaMCMGCSqGSIb3DQEJBDEWBBS7d8Erg1UbYdn3R88E N5ZTF17h9TBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79 UtuT8yEU6XIq+TroQjBsBgsqhkiG9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhBSzv1S25Pz IRTpcir5OuhCMA0GCSqGSIb3DQEBAQUABIIBABIWH273b85gd96L/MISusGtNjVJYfEF2RtvID4p SThDGbymGpq85LYbGG4Qb/jddpspqUsNgzKi2iaW1sAHnz8wPWAiP5idKsALg6uE4S226Bb1Fxlk FRaJUR0/+gbPoAjwC81FfY/n35BdxkKvq4NnZ56gyVb5K6SsR5kdhN0CvNI+kZ5HK7rwDQL3S1AX HpaosTCbmQY4gInCx+8/SG897WbyoVznEdRbi/kqvbTAa4nnWFYFQCiageJRpY+tQls4bFtMxPJ5 8AwD1q3I8STSg+1yukvA2//xhkMqYTdjg+6gJrPtlYQk1rLLfIePuRaOHXjGIiHVxRNpwLp/j4kA AAAAAAA= ------=_NextPart_000_055C_01D51B9B.3A686A60-- From nobody Wed Jun 5 05:18:33 2019 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 44A131200E9 for ; Wed, 5 Jun 2019 05:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 BhSdlav9RzpM for ; Wed, 5 Jun 2019 05:18:30 -0700 (PDT) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 684CB12006E for ; Wed, 5 Jun 2019 05:18:30 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 45JnrN6h78zFr5f; Wed, 5 Jun 2019 14:18:28 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.70]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 45JnrN5MS3z5vMv; Wed, 5 Jun 2019 14:18:28 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM33.corporate.adroot.infra.ftgroup ([fe80::c911:d24e:cc19:afa7%21]) with mapi id 14.03.0439.000; Wed, 5 Jun 2019 14:18:28 +0200 From: To: Yuchung Cheng CC: "tcpm@ietf.org" Thread-Topic: [tcpm] Progressing draft-ietf-tcpm-converters Thread-Index: AQHVGjZWv8JnQKhvd0WO/UEMDkxhS6aM+59A Date: Wed, 5 Jun 2019 12:18:27 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA94D8D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302EA8E8EF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA8F7C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA90886@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA9301E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters 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, 05 Jun 2019 12:18:32 -0000 SGkgWXVjaHVuZywgDQoNClBsZWFzZSBzZWUgaW5saW5lLiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4g LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IFl1Y2h1bmcgQ2hlbmcgW21haWx0 bzp5Y2hlbmdAZ29vZ2xlLmNvbV0NCj4gRW52b3nDqcKgOiBsdW5kaSAzIGp1aW4gMjAxOSAyMDow MQ0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xODQo+IENjwqA6IHRjcG1AaWV0Zi5v cmcNCj4gT2JqZXTCoDogUmU6IFt0Y3BtXSBQcm9ncmVzc2luZyBkcmFmdC1pZXRmLXRjcG0tY29u dmVydGVycw0KPiANCj4gT24gRnJpLCBNYXkgMzEsIDIwMTkgYXQgNToxNyBBTSA8bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBIaSBZdWNodW5nLA0KPiA+DQo+ ID4gVGhhbmsgeW91IGZvciBjbGFyaWZ5aW5nIHlvdXIgY29uY2Vybi4gQmVsb3cgYSB0ZXh0IHBy b3Bvc2FsIHRvIGFkZHJlc3MNCj4gdGhpcyBjb21tZW50Og0KPiA+DQo+ID4gPiBJIG1lcmVseSBw b2ludGVkIG91dCwgaWYgVEZPIGlzIG5vdCB1c2VkLCBhcyB0aGUgZHJhZnQgYW5kIHRoZQ0KPiA+ ID4gb3JpZ2luYWwgZW1haWwgcmVmZXIgdG8sIHRoZSBkcmFmdCBzaG91bGQgYmUgZXhwbGljaXQg dGhpcyByZXF1aXJlcyBhDQo+ID4gPiBjaGFuZ2UgaW4gUkZDNzkzLiBJdCdzIHJhdGhlciB2YWd1 ZS4NCj4gPg0KPiA+IFVQREFURUQ6DQo+ID4NCj4gPiAgICBTdGFuZGFyZCBUQ1AgKFtSRkMwNzkz XSwgU2VjdGlvbiAzLjQpIGFsbG93cyBhIFNZTiBwYWNrZXQgdG8gY2FycnkNCj4gPiAgICBkYXRh IGluc2lkZSBpdHMgcGF5bG9hZCBidXQgZm9yYmlkcyB0aGUgcmVjZWl2ZXIgZnJvbSBkZWxpdmVy aW5nIGl0DQo+ID4gICAgdG8gdGhlIGFwcGxpY2F0aW9uIHVudGlsIGNvbXBsZXRpb24gb2YgdGhl IHRocmVlLXdheS1oYW5kc2hha2UuICBUbw0KPiA+ICAgIGVuYWJsZSBhcHBsaWNhdGlvbnMgdG8g ZXhjaGFuZ2UgZGF0YSBpbiBhIFRDUCBoYW5kc2hha2UsIHRoaXMNCj4gPiAgICBzcGVjaWZpY2F0 aW9uIGZvbGxvd3MgYW4gYXBwcm9hY2ggc2ltaWxhciB0byBUQ1AgRmFzdCBPcGVuIFtSRkM3NDEz XQ0KPiA+ICAgIGFuZCB0aHVzIHJlbW92ZXMgdGhlIGNvbnN0cmFpbnQgYnkgYWxsb3dpbmcgZGF0 YSBpbiBTWU4gcGFja2V0cyB0byBiZQ0KPiA+ICAgIGRlbGl2ZXJlZCB0byB0aGUgYXBwbGljYXRp b24uDQo+ID4NCj4gPiAgICBBcyBkaXNjdXNzZWQgaW4gW1JGQzc0MTNdLCBzdWNoIGNoYW5nZSB0 byBUQ1Agc2VtYW50aWMgcmFpc2VzIHR3bw0KPiA+ICAgIGlzc3Vlcy4gIEZpcnN0LCBkdXBsaWNh dGUgU1lOcyBjYW4gY2F1c2UgcHJvYmxlbXMgZm9yIHNvbWUNCj4gPiAgICBhcHBsaWNhdGlvbnMg dGhhdCByZWx5IG9uIFRDUC4gIFNlY29uZCwgVENQIHN1ZmZlcnMgZnJvbSBTWU4gZmxvb2RpbmcN Cj4gPiAgICBhdHRhY2tzIFtSRkM0OTg3XS4gIFRGTyBzb2x2ZXMgdGhlc2UgdHdvIHByb2JsZW1z IGZvciBhcHBsaWNhdGlvbnMNCj4gPiAgICB0aGF0IGNhbiB0b2xlcmF0ZSByZXBsYXlzIGJ5IHVz aW5nIHRoZSBUQ1AgRmFzdCBPcGVuIG9wdGlvbiB0aGF0DQo+ID4gICAgaW5jbHVkZXMgYSBjb29r aWUuICBIb3dldmVyLCB0aGUgdXRpbGl6YXRpb24gb2YgdGhpcyBvcHRpb24gY29uc3VtZXMNCj4g PiAgICBzcGFjZSBpbiB0aGUgbGltaXRlZCBUQ1AgZXh0ZW5kZWQgaGVhZGVyLiAgRnVydGhlcm1v cmUsIHRoZXJlIGFyZQ0KPiA+ICAgIHNpdHVhdGlvbnMsIGFzIG5vdGVkIGluIFNlY3Rpb24gNy4z IG9mIFtSRkM3NDEzXSB3aGVyZSBpdCBpcyBwb3NzaWJsZQ0KPiA+ICAgIHRvIGFjY2VwdCB0aGUg cGF5bG9hZCBvZiBTWU4gcGFja2V0cyB3aXRob3V0IGNyZWF0aW5nIGFkZGl0aW9uYWwNCj4gPiAg ICBzZWN1cml0eSByaXNrcyBzdWNoIGFzIGEgbmV0d29yayB3aGVyZSBhZGRyZXNzZXMgY2Fubm90 IGJlIHNwb29mZWQNCj4gPiAgICBhbmQgdGhlIFRyYW5zcG9ydCBDb252ZXJ0ZXIgb25seSBzZXJ2 ZXMgYSBzZXQgb2YgaG9zdHMgdGhhdCBhcmUNCj4gPiAgICBpZGVudGlmaWVkIGJ5IHRoZXNlIGFk ZHJlc3Nlcy4NCj4gPg0KPiA+ICAgIEZvciB0aGVzZSByZWFzb25zLCB0aGlzIHNwZWNpZmljYXRp b24gZG9lcyBub3QgbWFuZGF0ZSB0aGUgdXNlIG9mIHRoZQ0KPiA+ICAgIFRDUCBGYXN0IE9wZW4g b3B0aW9uIHdoZW4gdGhlIENsaWVudCBzZW5kcyBhIGNvbm5lY3Rpb24gZXN0YWJsaXNobWVudA0K PiA+ICAgIHBhY2tldCB0b3dhcmRzIGEgVHJhbnNwb3J0IENvbnZlcnRlci4gIFRoZSBDb252ZXJ0 IHByb3RvY29sIGluY2x1ZGVzDQo+ID4gICAgYW4gb3B0aW9uYWwgQ29va2llIFRMViB0aGF0IHBy b3ZpZGVzIHNpbWlsYXIgcHJvdGVjdGlvbiBhcyB0aGUgVENQDQo+ID4gICAgRmFzdCBPcGVuIG9w dGlvbiB3aXRob3V0IGNvbnN1bWluZyBzcGFjZSBpbiB0aGUgZXh0ZW5kZWQgVENQIGhlYWRlci4N Cj4gU29ycnkgZm9yIHRoZSBsYXRlIHJlcGx5LiBIb3cgYWJvdXQgYWRkaW5nIHRvIHRoZSBsYXN0 IHNlbnRlbmNlOg0KPiANCj4gIldoZW4gVEZPIGlzIG5vdCB1c2VkLCB0aGUgdHJhbnNwb3J0IGNv bnZlcnRlciBuZWVkcyBhIGNvcnJlc3BvbmRpbmcNCj4gY2hhbmdlIHRvIFJGQzc5MyB0byBhbGxv dyBwb3N0aW5nIGRhdGEgaW4gU1lOIHRvIGFwcGxpY2F0aW9uIHVwb24NCj4gcmVjZWl2aW5nIHRo ZSBTWU4gcGFja2V0Ii4NCj4gDQoNCltNZWRdIEknbSBhZnJhaWQgdGhhdCB0aGUgcHJvcG9zZWQg c2VudGVuY2UgY2FuIGJlIG1pc2ludGVycHJldGVkIGFzIGlmIHRoZSB1c2Ugb2YgVEZPIHdvdWxk IG5vdCByZXF1aXJlIHRoYXQgY2hhbmdlIHRvIDc5My4gVGhlIGZpcnN0IHBhcmFncmFwaCBvZiB0 aGUgcHJvcG9zZWQgdGV4dCBhbHJlYWR5IGluZGljYXRlIHRoYXQgYSBjaGFuZ2UgaXMgbmVlZGVk LiANCg0KPiBUaGFua3MgZm9yIHRoZSBpbXByb3ZlZCB3b3JkaW5nLg0KPiA+DQo+ID4NCj4gPiBC ZXR0ZXI/DQo+ID4NCj4gPiBDaGVlcnMsDQo+ID4gTWVkDQo+ID4NCj4gPiA+IC0tLS0tTWVzc2Fn ZSBkJ29yaWdpbmUtLS0tLQ0KPiA+ID4gRGUgOiBZdWNodW5nIENoZW5nIFttYWlsdG86eWNoZW5n QGdvb2dsZS5jb21dDQo+ID4gPiBFbnZvecOpIDogbWVyY3JlZGkgMjkgbWFpIDIwMTkgMjM6NDYN Cj4gPiA+IMOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTg0KPiA+ID4gQ2MgOiB0Y3BtQGll dGYub3JnDQo+ID4gPiBPYmpldCA6IFJlOiBbdGNwbV0gUHJvZ3Jlc3NpbmcgZHJhZnQtaWV0Zi10 Y3BtLWNvbnZlcnRlcnMNCj4gPiA+DQo+ID4gPiBPbiBUdWUsIE1heSAyOCwgMjAxOSBhdCAxMTox MCBQTSA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4gd3JvdGU6DQo+ID4gPiA+DQo+ID4g PiA+IEhpIFl1Y2h1bmcsDQo+ID4gPiA+DQo+ID4gPiA+IFRoaXMgc3BlYyBpcyBhbiBFeHBlcmlt ZW50IHdoaWNoIHJlbGF4ZXMgYSBjb25zdHJhaW50IGluIFJGQzc5MyBpbg0KPiB0aGUgKg0KPiA+ ID4gU0FNRSAqICB3YXkgdGhlIFRGTyBFeHBlcmltZW50IHJlbGF4ZXMgdGhhdCAqIFNBTUUgKiBj b25zdHJhaW50Lg0KPiA+ID4gPg0KPiA+ID4gPiBHaXZlbiB0aGF0IFJGQzc0MTMgaXNuJ3QgdGFn Z2VkIGFzIHVwZGF0aW5nIFJGQzc5Mywgd2UgYXJlIGFzc3VtaW5nDQo+IHRoYXQNCj4gPiA+IHRo ZSBzYW1lIGNvbmNsdXNpb24gYXBwbGllcyBmb3Igb3VyIHNwZWMuDQo+ID4gPiA+DQo+ID4gPiA+ IEkgZG9uJ3QgdGhpbmsgYW4gRXhwZXJpbWVudGFsIFJGQyBjYW4gYmUgdGFnZ2VkIGFzIHVwZGF0 aW5nIFJGQzc5MywNCj4gPiA+IGFueXdheS4NCj4gPiA+ID9XaGljaCBvZiBteSBlbWFpbHMgYXNr cyB0byB0YWcgdGhpcyBkcmFmdCBhcyBSRkM3OTMtdXBkYXRlPw0KPiA+ID4NCj4gPiA+IEkgbWVy ZWx5IHBvaW50ZWQgb3V0LCBpZiBURk8gaXMgbm90IHVzZWQsIGFzIHRoZSBkcmFmdCBhbmQgdGhl DQo+ID4gPiBvcmlnaW5hbCBlbWFpbCByZWZlciB0bywgdGhlIGRyYWZ0IHNob3VsZCBiZSBleHBs aWNpdCB0aGlzIHJlcXVpcmVzIGENCj4gPiA+IGNoYW5nZSBpbiBSRkM3OTMuIEl0J3MgcmF0aGVy IHZhZ3VlLg0K From nobody Wed Jun 5 11:00:28 2019 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 E5C7312021F for ; Wed, 5 Jun 2019 11:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_MED=-0.01, 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 rVqoilqKQh32 for ; Wed, 5 Jun 2019 11:00:24 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 2EB951201D6 for ; Wed, 5 Jun 2019 11:00:08 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id m3so4588730wrv.2 for ; Wed, 05 Jun 2019 11:00:08 -0700 (PDT) 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=wS2CgW3IvrjuHajm3TfBO97+9KJTG2qrVmjq7P3FOzc=; b=p6a5C1/ORduDnUTf3tn04qnlZVclsg3IJ4chA27MzXczG+OE/1cIYFfIyJjhbsky8L EbREMlvuTGfjMotz6JLf2ZJAQS45MAHLPz6IytU3/g5h5uBcH0wvZpjdqHP4GCLli54G 888oAVLDY/qAhPvSJ46/Iw3yS+FSBjAsxb1eBXPdPHskqIq71v8OLxPTIpKkSsmfbyB1 emUs49l6DdwIq6UI3xrnqtSQrHyEHh1QlkwDgZYHqEW/tTeCyP4WVfA25sT75sxcjucl aWQAHrXAtt2qgI5bGL8HwxvkX3UVyM7vqWVlFtvF40AP5jmyScns5VnEFezYHE2ktLCe 5SeQ== 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=wS2CgW3IvrjuHajm3TfBO97+9KJTG2qrVmjq7P3FOzc=; b=SHkDSZY7nn6/NzjnY7MLu57FCyMDY/h+jSqN9XqxXCK2nRTXyygCkV9EWt8QeWJdwB OMYCXnfH/7f8Gq1Cedr1klOj5zBOEp5W0yQRhkz6wcaJBgY7jMMO0tHUGscfGJ3VAxUP /Qwd8ePWNqG7mut5NNMAV+4WouPFgpXfPv3NFFjbCa/xgXRZKFFZaloQvKPd0ElLUDUB YiHVWRAHTXPj+mNiFc4Ks0AFh2M+XEWxxr3+zNIrxBnWx/FWGIZCTEX3TLhq7P59cFum HOdjMVmxaTxJ3Ap60/+lGiqJK1XYY8qnrGHDElaDCjyoOCIDvlA1K7FBqeo5q5MIRTYv Depg== X-Gm-Message-State: APjAAAUMRd38WhMUyg07EEebNDBIw4TK1c0teqmmNGIdOTmOZEk4EHIh eZhrv8IqzMmBBjeFfq32CzazHui/C4/mRSIBNpzx3w== X-Google-Smtp-Source: APXvYqzXNroXLWeib2WnFNynBhuPh2AHPlGFyIS9czkOQg82iFpvJc8SUj/AhigpQKpbymS4HQiDf+C9lXCotyAvv/E= X-Received: by 2002:adf:e485:: with SMTP id i5mr13038737wrm.75.1559757606101; Wed, 05 Jun 2019 11:00:06 -0700 (PDT) MIME-Version: 1.0 References: <787AE7BB302AE849A7480A190F8B93302EA8E8EF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA8F7C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA90886@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA9301E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA94D8D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA94D8D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Yuchung Cheng Date: Wed, 5 Jun 2019 10:59:27 -0700 Message-ID: To: mohamed.boucadair@orange.com Cc: "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters 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, 05 Jun 2019 18:00:27 -0000 On Wed, Jun 5, 2019 at 5:18 AM wrote: > > Hi Yuchung, > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : Yuchung Cheng [mailto:ycheng@google.com] > > Envoy=C3=A9 : lundi 3 juin 2019 20:01 > > =C3=80 : BOUCADAIR Mohamed TGI/OLN > > Cc : tcpm@ietf.org > > Objet : Re: [tcpm] Progressing draft-ietf-tcpm-converters > > > > On Fri, May 31, 2019 at 5:17 AM wrote: > > > > > > Hi Yuchung, > > > > > > Thank you for clarifying your concern. Below a text proposal to addre= ss > > this comment: > > > > > > > I merely pointed out, if TFO is not used, as the draft and the > > > > original email refer to, the draft should be explicit this requires= a > > > > change in RFC793. It's rather vague. > > > > > > UPDATED: > > > > > > Standard TCP ([RFC0793], Section 3.4) allows a SYN packet to carry > > > data inside its payload but forbids the receiver from delivering i= t > > > to the application until completion of the three-way-handshake. T= o > > > enable applications to exchange data in a TCP handshake, this > > > specification follows an approach similar to TCP Fast Open [RFC741= 3] > > > and thus removes the constraint by allowing data in SYN packets to= be > > > delivered to the application. > > > > > > As discussed in [RFC7413], such change to TCP semantic raises two > > > issues. First, duplicate SYNs can cause problems for some > > > applications that rely on TCP. Second, TCP suffers from SYN flood= ing > > > attacks [RFC4987]. TFO solves these two problems for applications > > > that can tolerate replays by using the TCP Fast Open option that > > > includes a cookie. However, the utilization of this option consum= es > > > space in the limited TCP extended header. Furthermore, there are > > > situations, as noted in Section 7.3 of [RFC7413] where it is possi= ble > > > to accept the payload of SYN packets without creating additional > > > security risks such as a network where addresses cannot be spoofed > > > and the Transport Converter only serves a set of hosts that are > > > identified by these addresses. > > > > > > For these reasons, this specification does not mandate the use of = the > > > TCP Fast Open option when the Client sends a connection establishm= ent > > > packet towards a Transport Converter. The Convert protocol includ= es > > > an optional Cookie TLV that provides similar protection as the TCP > > > Fast Open option without consuming space in the extended TCP heade= r. > > Sorry for the late reply. How about adding to the last sentence: > > > > "When TFO is not used, the transport converter needs a corresponding > > change to RFC793 to allow posting data in SYN to application upon > > receiving the SYN packet". > > > > [Med] I'm afraid that the proposed sentence can be misinterpreted as if t= he use of TFO would not require that change to 793. The first paragraph of = the proposed text already indicate that a change is needed. Sure that works for me. > > > Thanks for the improved wording. > > > > > > > > > Better? > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De : Yuchung Cheng [mailto:ycheng@google.com] > > > > Envoy=C3=A9 : mercredi 29 mai 2019 23:46 > > > > =C3=80 : BOUCADAIR Mohamed TGI/OLN > > > > Cc : tcpm@ietf.org > > > > Objet : Re: [tcpm] Progressing draft-ietf-tcpm-converters > > > > > > > > On Tue, May 28, 2019 at 11:10 PM wro= te: > > > > > > > > > > Hi Yuchung, > > > > > > > > > > This spec is an Experiment which relaxes a constraint in RFC793 i= n > > the * > > > > SAME * way the TFO Experiment relaxes that * SAME * constraint. > > > > > > > > > > Given that RFC7413 isn't tagged as updating RFC793, we are assumi= ng > > that > > > > the same conclusion applies for our spec. > > > > > > > > > > I don't think an Experimental RFC can be tagged as updating RFC79= 3, > > > > anyway. > > > > ?Which of my emails asks to tag this draft as RFC793-update? > > > > > > > > I merely pointed out, if TFO is not used, as the draft and the > > > > original email refer to, the draft should be explicit this requires= a > > > > change in RFC793. It's rather vague. From nobody Wed Jun 5 22:10:36 2019 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 96271120155 for ; Wed, 5 Jun 2019 22:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 CNpgCRw-ZTq0 for ; Wed, 5 Jun 2019 22:10:31 -0700 (PDT) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64A8812001A for ; Wed, 5 Jun 2019 22:10:31 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 45KDJ54PQQz7xDs; Thu, 6 Jun 2019 07:10:29 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.64]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 45KDJ53XQZz3wbV; Thu, 6 Jun 2019 07:10:29 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBMA3.corporate.adroot.infra.ftgroup ([fe80::90fe:7dc1:fb15:a02b%21]) with mapi id 14.03.0439.000; Thu, 6 Jun 2019 07:10:29 +0200 From: To: Yuchung Cheng CC: "tcpm@ietf.org" Thread-Topic: [tcpm] Progressing draft-ietf-tcpm-converters Thread-Index: AQHVG8iDmtUDPMaDPkybIR3w2SVBOqaOFAkQ Date: Thu, 6 Jun 2019 05:10:28 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA9D704@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302EA8E8EF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA8F7C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA90886@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA9301E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA94D8D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters 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, 06 Jun 2019 05:10:34 -0000 SGkgWXVjaHVuZywgDQoNClRoYW5rIHlvdS4gDQoNCldlIHdpbGwgcmVsZWFzZSBhbiB1cGRhdGVk IHZlcnNpb24gd2l0aCB0aGlzIE5FVyB0ZXh0Lg0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1l c3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogWXVjaHVuZyBDaGVuZyBbbWFpbHRvOnljaGVu Z0Bnb29nbGUuY29tXQ0KPiBFbnZvecOpwqA6IG1lcmNyZWRpIDUganVpbiAyMDE5IDE5OjU5DQo+ IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE4NCj4gQ2PCoDogdGNwbUBpZXRmLm9yZw0K PiBPYmpldMKgOiBSZTogW3RjcG1dIFByb2dyZXNzaW5nIGRyYWZ0LWlldGYtdGNwbS1jb252ZXJ0 ZXJzDQo+IA0KPiBPbiBXZWQsIEp1biA1LCAyMDE5IGF0IDU6MTggQU0gPG1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb20+IHdyb3RlOg0KPiA+DQo+ID4gSGkgWXVjaHVuZywNCj4gPg0KPiA+IFBs ZWFzZSBzZWUgaW5saW5lLg0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+IE1lZA0KPiA+DQo+ID4gPiAt LS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPiA+IERlIDogWXVjaHVuZyBDaGVuZyBbbWFp bHRvOnljaGVuZ0Bnb29nbGUuY29tXQ0KPiA+ID4gRW52b3nDqSA6IGx1bmRpIDMganVpbiAyMDE5 IDIwOjAxDQo+ID4gPiDDgCA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE4NCj4gPiA+IENjIDog dGNwbUBpZXRmLm9yZw0KPiA+ID4gT2JqZXQgOiBSZTogW3RjcG1dIFByb2dyZXNzaW5nIGRyYWZ0 LWlldGYtdGNwbS1jb252ZXJ0ZXJzDQo+ID4gPg0KPiA+ID4gT24gRnJpLCBNYXkgMzEsIDIwMTkg YXQgNToxNyBBTSA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4gd3JvdGU6DQo+ID4gPiA+ DQo+ID4gPiA+IEhpIFl1Y2h1bmcsDQo+ID4gPiA+DQo+ID4gPiA+IFRoYW5rIHlvdSBmb3IgY2xh cmlmeWluZyB5b3VyIGNvbmNlcm4uIEJlbG93IGEgdGV4dCBwcm9wb3NhbCB0bw0KPiBhZGRyZXNz DQo+ID4gPiB0aGlzIGNvbW1lbnQ6DQo+ID4gPiA+DQo+ID4gPiA+ID4gSSBtZXJlbHkgcG9pbnRl ZCBvdXQsIGlmIFRGTyBpcyBub3QgdXNlZCwgYXMgdGhlIGRyYWZ0IGFuZCB0aGUNCj4gPiA+ID4g PiBvcmlnaW5hbCBlbWFpbCByZWZlciB0bywgdGhlIGRyYWZ0IHNob3VsZCBiZSBleHBsaWNpdCB0 aGlzDQo+IHJlcXVpcmVzIGENCj4gPiA+ID4gPiBjaGFuZ2UgaW4gUkZDNzkzLiBJdCdzIHJhdGhl ciB2YWd1ZS4NCj4gPiA+ID4NCj4gPiA+ID4gVVBEQVRFRDoNCj4gPiA+ID4NCj4gPiA+ID4gICAg U3RhbmRhcmQgVENQIChbUkZDMDc5M10sIFNlY3Rpb24gMy40KSBhbGxvd3MgYSBTWU4gcGFja2V0 IHRvDQo+IGNhcnJ5DQo+ID4gPiA+ICAgIGRhdGEgaW5zaWRlIGl0cyBwYXlsb2FkIGJ1dCBmb3Ji aWRzIHRoZSByZWNlaXZlciBmcm9tIGRlbGl2ZXJpbmcNCj4gaXQNCj4gPiA+ID4gICAgdG8gdGhl IGFwcGxpY2F0aW9uIHVudGlsIGNvbXBsZXRpb24gb2YgdGhlIHRocmVlLXdheS1oYW5kc2hha2Uu DQo+IFRvDQo+ID4gPiA+ICAgIGVuYWJsZSBhcHBsaWNhdGlvbnMgdG8gZXhjaGFuZ2UgZGF0YSBp biBhIFRDUCBoYW5kc2hha2UsIHRoaXMNCj4gPiA+ID4gICAgc3BlY2lmaWNhdGlvbiBmb2xsb3dz IGFuIGFwcHJvYWNoIHNpbWlsYXIgdG8gVENQIEZhc3QgT3Blbg0KPiBbUkZDNzQxM10NCj4gPiA+ ID4gICAgYW5kIHRodXMgcmVtb3ZlcyB0aGUgY29uc3RyYWludCBieSBhbGxvd2luZyBkYXRhIGlu IFNZTiBwYWNrZXRzDQo+IHRvIGJlDQo+ID4gPiA+ICAgIGRlbGl2ZXJlZCB0byB0aGUgYXBwbGlj YXRpb24uDQo+ID4gPiA+DQo+ID4gPiA+ICAgIEFzIGRpc2N1c3NlZCBpbiBbUkZDNzQxM10sIHN1 Y2ggY2hhbmdlIHRvIFRDUCBzZW1hbnRpYyByYWlzZXMgdHdvDQo+ID4gPiA+ICAgIGlzc3Vlcy4g IEZpcnN0LCBkdXBsaWNhdGUgU1lOcyBjYW4gY2F1c2UgcHJvYmxlbXMgZm9yIHNvbWUNCj4gPiA+ ID4gICAgYXBwbGljYXRpb25zIHRoYXQgcmVseSBvbiBUQ1AuICBTZWNvbmQsIFRDUCBzdWZmZXJz IGZyb20gU1lODQo+IGZsb29kaW5nDQo+ID4gPiA+ICAgIGF0dGFja3MgW1JGQzQ5ODddLiAgVEZP IHNvbHZlcyB0aGVzZSB0d28gcHJvYmxlbXMgZm9yDQo+IGFwcGxpY2F0aW9ucw0KPiA+ID4gPiAg ICB0aGF0IGNhbiB0b2xlcmF0ZSByZXBsYXlzIGJ5IHVzaW5nIHRoZSBUQ1AgRmFzdCBPcGVuIG9w dGlvbiB0aGF0DQo+ID4gPiA+ICAgIGluY2x1ZGVzIGEgY29va2llLiAgSG93ZXZlciwgdGhlIHV0 aWxpemF0aW9uIG9mIHRoaXMgb3B0aW9uDQo+IGNvbnN1bWVzDQo+ID4gPiA+ICAgIHNwYWNlIGlu IHRoZSBsaW1pdGVkIFRDUCBleHRlbmRlZCBoZWFkZXIuICBGdXJ0aGVybW9yZSwgdGhlcmUgYXJl DQo+ID4gPiA+ICAgIHNpdHVhdGlvbnMsIGFzIG5vdGVkIGluIFNlY3Rpb24gNy4zIG9mIFtSRkM3 NDEzXSB3aGVyZSBpdCBpcw0KPiBwb3NzaWJsZQ0KPiA+ID4gPiAgICB0byBhY2NlcHQgdGhlIHBh eWxvYWQgb2YgU1lOIHBhY2tldHMgd2l0aG91dCBjcmVhdGluZyBhZGRpdGlvbmFsDQo+ID4gPiA+ ICAgIHNlY3VyaXR5IHJpc2tzIHN1Y2ggYXMgYSBuZXR3b3JrIHdoZXJlIGFkZHJlc3NlcyBjYW5u b3QgYmUNCj4gc3Bvb2ZlZA0KPiA+ID4gPiAgICBhbmQgdGhlIFRyYW5zcG9ydCBDb252ZXJ0ZXIg b25seSBzZXJ2ZXMgYSBzZXQgb2YgaG9zdHMgdGhhdCBhcmUNCj4gPiA+ID4gICAgaWRlbnRpZmll ZCBieSB0aGVzZSBhZGRyZXNzZXMuDQo+ID4gPiA+DQo+ID4gPiA+ICAgIEZvciB0aGVzZSByZWFz b25zLCB0aGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFuZGF0ZSB0aGUgdXNlIG9mDQo+IHRo ZQ0KPiA+ID4gPiAgICBUQ1AgRmFzdCBPcGVuIG9wdGlvbiB3aGVuIHRoZSBDbGllbnQgc2VuZHMg YSBjb25uZWN0aW9uDQo+IGVzdGFibGlzaG1lbnQNCj4gPiA+ID4gICAgcGFja2V0IHRvd2FyZHMg YSBUcmFuc3BvcnQgQ29udmVydGVyLiAgVGhlIENvbnZlcnQgcHJvdG9jb2wNCj4gaW5jbHVkZXMN Cj4gPiA+ID4gICAgYW4gb3B0aW9uYWwgQ29va2llIFRMViB0aGF0IHByb3ZpZGVzIHNpbWlsYXIg cHJvdGVjdGlvbiBhcyB0aGUNCj4gVENQDQo+ID4gPiA+ICAgIEZhc3QgT3BlbiBvcHRpb24gd2l0 aG91dCBjb25zdW1pbmcgc3BhY2UgaW4gdGhlIGV4dGVuZGVkIFRDUA0KPiBoZWFkZXIuDQo+ID4g PiBTb3JyeSBmb3IgdGhlIGxhdGUgcmVwbHkuIEhvdyBhYm91dCBhZGRpbmcgdG8gdGhlIGxhc3Qg c2VudGVuY2U6DQo+ID4gPg0KPiA+ID4gIldoZW4gVEZPIGlzIG5vdCB1c2VkLCB0aGUgdHJhbnNw b3J0IGNvbnZlcnRlciBuZWVkcyBhIGNvcnJlc3BvbmRpbmcNCj4gPiA+IGNoYW5nZSB0byBSRkM3 OTMgdG8gYWxsb3cgcG9zdGluZyBkYXRhIGluIFNZTiB0byBhcHBsaWNhdGlvbiB1cG9uDQo+ID4g PiByZWNlaXZpbmcgdGhlIFNZTiBwYWNrZXQiLg0KPiA+ID4NCj4gPg0KPiA+IFtNZWRdIEknbSBh ZnJhaWQgdGhhdCB0aGUgcHJvcG9zZWQgc2VudGVuY2UgY2FuIGJlIG1pc2ludGVycHJldGVkIGFz IGlmDQo+IHRoZSB1c2Ugb2YgVEZPIHdvdWxkIG5vdCByZXF1aXJlIHRoYXQgY2hhbmdlIHRvIDc5 My4gVGhlIGZpcnN0IHBhcmFncmFwaA0KPiBvZiB0aGUgcHJvcG9zZWQgdGV4dCBhbHJlYWR5IGlu ZGljYXRlIHRoYXQgYSBjaGFuZ2UgaXMgbmVlZGVkLg0KPiBTdXJlIHRoYXQgd29ya3MgZm9yIG1l Lg0KPiANCj4gPg0KPiA+ID4gVGhhbmtzIGZvciB0aGUgaW1wcm92ZWQgd29yZGluZy4NCj4gPiA+ ID4NCj4gPiA+ID4NCj4gPiA+ID4gQmV0dGVyPw0KPiA+ID4gPg0KPiA+ID4gPiBDaGVlcnMsDQo+ ID4gPiA+IE1lZA0KPiA+ID4gPg0KPiA+ID4gPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0t LQ0KPiA+ID4gPiA+IERlIDogWXVjaHVuZyBDaGVuZyBbbWFpbHRvOnljaGVuZ0Bnb29nbGUuY29t XQ0KPiA+ID4gPiA+IEVudm95w6kgOiBtZXJjcmVkaSAyOSBtYWkgMjAxOSAyMzo0Ng0KPiA+ID4g PiA+IMOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTg0KPiA+ID4gPiA+IENjIDogdGNwbUBp ZXRmLm9yZw0KPiA+ID4gPiA+IE9iamV0IDogUmU6IFt0Y3BtXSBQcm9ncmVzc2luZyBkcmFmdC1p ZXRmLXRjcG0tY29udmVydGVycw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gT24gVHVlLCBNYXkgMjgs IDIwMTkgYXQgMTE6MTAgUE0gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+IHdyb3Rl Og0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEhpIFl1Y2h1bmcsDQo+ID4gPiA+ID4gPg0KPiA+ ID4gPiA+ID4gVGhpcyBzcGVjIGlzIGFuIEV4cGVyaW1lbnQgd2hpY2ggcmVsYXhlcyBhIGNvbnN0 cmFpbnQgaW4gUkZDNzkzDQo+IGluDQo+ID4gPiB0aGUgKg0KPiA+ID4gPiA+IFNBTUUgKiAgd2F5 IHRoZSBURk8gRXhwZXJpbWVudCByZWxheGVzIHRoYXQgKiBTQU1FICogY29uc3RyYWludC4NCj4g PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBHaXZlbiB0aGF0IFJGQzc0MTMgaXNuJ3QgdGFnZ2VkIGFz IHVwZGF0aW5nIFJGQzc5Mywgd2UgYXJlDQo+IGFzc3VtaW5nDQo+ID4gPiB0aGF0DQo+ID4gPiA+ ID4gdGhlIHNhbWUgY29uY2x1c2lvbiBhcHBsaWVzIGZvciBvdXIgc3BlYy4NCj4gPiA+ID4gPiA+ DQo+ID4gPiA+ID4gPiBJIGRvbid0IHRoaW5rIGFuIEV4cGVyaW1lbnRhbCBSRkMgY2FuIGJlIHRh Z2dlZCBhcyB1cGRhdGluZw0KPiBSRkM3OTMsDQo+ID4gPiA+ID4gYW55d2F5Lg0KPiA+ID4gPiA+ ID9XaGljaCBvZiBteSBlbWFpbHMgYXNrcyB0byB0YWcgdGhpcyBkcmFmdCBhcyBSRkM3OTMtdXBk YXRlPw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSSBtZXJlbHkgcG9pbnRlZCBvdXQsIGlmIFRGTyBp cyBub3QgdXNlZCwgYXMgdGhlIGRyYWZ0IGFuZCB0aGUNCj4gPiA+ID4gPiBvcmlnaW5hbCBlbWFp bCByZWZlciB0bywgdGhlIGRyYWZ0IHNob3VsZCBiZSBleHBsaWNpdCB0aGlzDQo+IHJlcXVpcmVz IGENCj4gPiA+ID4gPiBjaGFuZ2UgaW4gUkZDNzkzLiBJdCdzIHJhdGhlciB2YWd1ZS4NCg== From nobody Tue Jun 11 17:07:20 2019 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 DFC2812001E; Tue, 11 Jun 2019 17:07:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <156029803983.6027.3948881208641567582@ietfa.amsl.com> Date: Tue, 11 Jun 2019 17:07:19 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-converters-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: Wed, 12 Jun 2019 00:07:20 -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 : 0-RTT TCP Convert Protocol Authors : Olivier Bonaventure Mohamed Boucadair Sri Gundavelli SungHoon Seo Benjamin Hesmans Filename : draft-ietf-tcpm-converters-07.txt Pages : 45 Date : 2019-06-11 Abstract: This document specifies an application proxy, called Transport Converter, to assist the deployment of TCP extensions such as Multipath TCP. This proxy is designed to avoid inducing extra delay when involved in a network-assisted connection (that is, 0-RTT). This specification assumes an explicit model, where the proxy is explicitly configured on hosts. -- Editorial Note (To be removed by RFC Editor) Please update these statements with the RFC number to be assigned to this document: [This-RFC] Please update TBA statements with the port number to be assigned to the 0-RTT TCP Convert Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-converters-07 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-converters-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 11 23:36:31 2019 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 B1C8212007A for ; Tue, 11 Jun 2019 23:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 PmnGOZc5aljF for ; Tue, 11 Jun 2019 23:36:28 -0700 (PDT) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5348B120077 for ; Tue, 11 Jun 2019 23:36:28 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 45NxwV4ZX8z12ry for ; Wed, 12 Jun 2019 08:36:26 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.23]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 45NxwV3yb1zDq8w for ; Wed, 12 Jun 2019 08:36:26 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM41.corporate.adroot.infra.ftgroup ([fe80::857d:4f67:b0a7:10d7%21]) with mapi id 14.03.0439.000; Wed, 12 Jun 2019 08:36:26 +0200 From: To: "tcpm@ietf.org" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-converters-07.txt Thread-Index: AQHVILLU5NJXgkQA0kyGw1awwl8KQKaXkB7Q Date: Wed, 12 Jun 2019 06:36:25 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EAA5578@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <156029803983.6027.3948881208641567582@ietfa.amsl.com> In-Reply-To: <156029803983.6027.3948881208641567582@ietfa.amsl.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-converters-07.txt 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, 12 Jun 2019 06:36:31 -0000 Hi all,=20 This new version integrates the following main changes: * include the text agreed with Yuchung (https://mailarchive.ietf.org/arch/m= sg/tcpm/kgHGCgsV2lbaBB6CftbhPRmBjdM) * add a new appendix to discuss API-related considerations=20 We do think that the spec is ready for the WGLC.=20 Cheers, Olivier & Med > -----Message d'origine----- > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=E9=A0: mercredi 12 juin 2019 02:07 > =C0=A0: i-d-announce@ietf.org > Cc=A0: tcpm@ietf.org > Objet=A0: [tcpm] I-D Action: draft-ietf-tcpm-converters-07.txt >=20 >=20 > 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. >=20 > Title : 0-RTT TCP Convert Protocol > Authors : Olivier Bonaventure > Mohamed Boucadair > Sri Gundavelli > SungHoon Seo > Benjamin Hesmans > Filename : draft-ietf-tcpm-converters-07.txt > Pages : 45 > Date : 2019-06-11 >=20 > Abstract: > This document specifies an application proxy, called Transport > Converter, to assist the deployment of TCP extensions such as > Multipath TCP. This proxy is designed to avoid inducing extra delay > when involved in a network-assisted connection (that is, 0-RTT). >=20 > This specification assumes an explicit model, where the proxy is > explicitly configured on hosts. >=20 > -- Editorial Note (To be removed by RFC Editor) >=20 > Please update these statements with the RFC number to be assigned to > this document: [This-RFC] >=20 > Please update TBA statements with the port number to be assigned to > the 0-RTT TCP Convert Protocol. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tcpm-converters-07 > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-07 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-converters-07 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Jun 13 09:48:30 2019 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 A58701200E9; Thu, 13 Jun 2019 09:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 9LP-nbU2C40i; Thu, 13 Jun 2019 09:48:18 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D659120047; Thu, 13 Jun 2019 09:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:MIME-Version:Date:Message-ID:Cc: Subject:From:To:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Vnr3zcv8JQ+9Pht8FIa3d5h3AGxFIVJgCn/TDCFkFz0=; b=0EmJejWLrFImbWqxL5ET8rN74N QOkksxbBgYJU4urWtvgI8XU1RnCoDJipZNoPPDPPWHXs79uFBdmQ0DUpwgVSFUw4ztDGLgK0K+5MY BLRZf7IGdD8x71FDQIEf0X7esUdBT2NIhW86aUMB8Ecs0M2btzcHGyEYqwMo7bDV7hm9M+OYNdquV BAsbhyVfawvsN67zPt3qWhyFtrcekd96f+JVapWnyH0YyW2KmGCY9Uifg1c/iewmHiJu0+4k2rhRN q/SJvjjFIOuF5604w2vYnFLcbLW84YzfppmBg/efdSMTnIo22BFo1hoassfb5AGdQgFesNA+BSR4Z VwwuDH1w==; Received: from [31.185.128.20] (port=36364 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 1hbSta-0003B8-Vn; Thu, 13 Jun 2019 17:48:15 +0100 To: "ecn-sane@lists.bufferbloat.net" , tcpm IETF list From: Bob Briscoe Cc: tsvwg IETF list Message-ID: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> Date: Thu, 13 Jun 2019 17:48:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------CADEF1FB433DB76B60AD3057" 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: [tcpm] ECN CE that was ECT(0) incorrectly classified as L4S 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, 13 Jun 2019 16:48:22 -0000 This is a multi-part message in MIME format. --------------CADEF1FB433DB76B60AD3057 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit [I'm sending this to ecn-sane 'cos that's where I detect that this concern is still rumbling. I'm also sending to tcpm@ietf 'cos there's a question for TCP experts just before the quoted text below. And tsvwg@ietf is where it ought to be discussed.] Now that the IPR issue with L4S has been put to bed, one by one I am going through the other concerns that have been raised about L4S. In the IETF draft that records all the pros and cons of different identifiers to use for L4S, under the "ECT(1) and CE" choice (which is currently the one adopted at the IETF) there was already an explanation of why there would be vanishingly low risk of any harmful consequences from CE that was originally ECT(0) being classified into the L4S queue: https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-06#page-32 Re-reading that, I have found some things unstated that I had thought were obvious. So I've spelled it all out long-hand in the text below, which is now in my local copy of the draft and will be in the next revision unless people suggest improvements/corrections here. *Q#1:* If this glosses over any concerns you have, please explain. Otherwise I will continue to consider that this is effectively a non-issue, which is the conclusion everyone in the TCP community came to at the time the L4S identifier was chosen back in 2015. *Q#2: *The last couple of lines are the only part I am not sure of. Do most of today's TCP implementations recover the reduction in congestion window when they discover later that a fast retransmit was spurious? There's a note at the end of the intro to rfc4015 saying there was insufficient consensus to standardize this behaviour, but that most likely means it's done in different ways, rather than it isn't done at all. Bob ====================================== Risk of reordering classic CE packets: Classifying all CE packets into the L4S queue risks any CE packets that were originally ECT(0) being incorrectly classified as L4S. If there were delay in the Classic queue, these incorrectly classified CE packets would arrive early, which is a form of reordering. Reordering can cause TCP senders (and senders of similar transports) to retransmit spuriously. However, the risk of spurious retransmissions would be extremely low for the following reasons: 1. It is quite unusual to experience queuing at more than one bottleneck on the same path (the available capacities have to be identical). 2. In only a subset of these unusual cases would the first bottleneck support classic ECN marking while the second supported L4S ECN marking, which would be the only scenario where some ECT(0) packets could be CE marked by a non-L4S AQM then the remainder experienced further delay through the Classic side of a subsequent L4S DualQ AQM. 3. Even then, when a few packets are delivered early, it takes very unusual conditions to cause a spurious retransmission, in contrast to when some packets are delivered late. The first bottleneck has to apply CE-marks to at least N contiguous packets and the second bottleneck has to inject an uninterrupted sequence of at least N of these packets between two packets earlier in the stream (where N is the reordering window that the transport protocol allows before it considers a packet is lost). For example consider N=3, and consider the sequence of packets 100, 101, 102, 103,... and imagine that packets 150,151,152 from later in the flow are injected as follows: 100, 150, 151, 101, 152, 102, 103... If this were late reordering, even one packet arriving 50 out of sequence would trigger a spurious retransmission, but there is no spurious retransmission here, because packet 101 moves the cumulative ACK counter forward before 3 packets have arrived out of order. Later, when packets 148, 149, 153... arrive, even though there is a 3-packet hole, there will be no problem, because the packets to fill the hole are already in the receive buffer. 4. Even with the current recommended TCP (N=3) spurious retransmissions will be unlikely for all the above reasons. As RACK [I-D.ietf-tcpm-rack] is becoming widely deployed, it tends to adapt its reordering window to a larger value of N, which will make the chance of a contiguous sequence of N early arrivals vanishingly small. 5. Even a run of 2 CE marks within a classic ECN flow is unlikely, given FQ-CoDel is the only known widely deployed AQM that supports classic ECN marking and it takes great care to separate out flows and to space any markings evenly along each flow. It is extremely unlikely that the above set of 5 eventualities that are each unusual in themselves would all happen simultaneously. But, even if they did, the consequences would hardly be dire: the odd spurious fast retransmission. Admittedly TCP reduces its congestion window when it deems there has been a loss, but even this can be recovered once the sender detects that the retransmission was spurious. -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------CADEF1FB433DB76B60AD3057 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
[I'm sending this to ecn-sane 'cos that's where I detect that this concern is still rumbling.
I'm also sending to tcpm@ietf 'cos there's a question for TCP experts just before the quoted text below.
And tsvwg@ietf is where it ought to be discussed.]

Now that the IPR issue with L4S has been put to bed, one by one I am going through the other concerns that have been raised about L4S.

In the IETF draft that records all the pros and cons of different identifiers to use for L4S, under the "ECT(1) and CE" choice (which is currently the one adopted at the IETF) there was already an explanation of why there would be vanishingly low risk of any harmful consequences from CE that was originally ECT(0) being classified into the L4S queue:
https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-06#page-32

Re-reading that, I have found some things unstated that I had thought were obvious. So I've spelled it all out long-hand in the text below, which is now in my local copy of the draft and will be in the next revision unless people suggest improvements/corrections here.

Q#1: If this glosses over any concerns you have, please explain.
Otherwise I will continue to consider that this is effectively a non-issue, which is the conclusion everyone in the TCP community came to at the time the L4S identifier was chosen back in 2015.

Q#2: The last couple of lines are the only part I am not sure of. Do most of today's TCP implementations recover the reduction in congestion window when they discover later that a fast retransmit was spurious? There's a note at the end of the intro to rfc4015 saying there was insufficient consensus to standardize this behaviour, but that most likely means it's done in different ways, rather than it isn't done at all.


Bob


======================================

   Risk of reordering classic CE packets:  Classifying all CE packets
      into the L4S queue risks any CE packets that were originally
      ECT(0) being incorrectly classified as L4S.  If there were delay
      in the Classic queue, these incorrectly classified CE packets
      would arrive early, which is a form of reordering.  Reordering can
      cause TCP senders (and senders of similar transports) to
      retransmit spuriously.  However, the risk of spurious
      retransmissions would be extremely low for the following reasons:

      1.  It is quite unusual to experience queuing at more than one
          bottleneck on the same path (the available capacities have to
          be identical).

      2.  In only a subset of these unusual cases would the first
          bottleneck support classic ECN marking while the second
          supported L4S ECN marking, which would be the only scenario
          where some ECT(0) packets could be CE marked by a non-L4S AQM
          then the remainder experienced further delay through the
          Classic side of a subsequent L4S DualQ AQM.

      3.  Even then, when a few packets are delivered early, it takes
          very unusual conditions to cause a spurious retransmission, in
          contrast to when some packets are delivered late.  The first
          bottleneck has to apply CE-marks to at least N contiguous
          packets and the second bottleneck has to inject an
          uninterrupted sequence of at least N of these packets between
          two packets earlier in the stream (where N is the reordering
          window that the transport protocol allows before it considers
          a packet is lost).

             For example consider N=3, and consider the sequence of
             packets 100, 101, 102, 103,... and imagine that packets
             150,151,152 from later in the flow are injected as follows:
             100, 150, 151, 101, 152, 102, 103...  If this were late
             reordering, even one packet arriving 50 out of sequence
             would trigger a spurious retransmission, but there is no
             spurious retransmission here, because packet 101 moves the
             cumulative ACK counter forward before 3 packets have
             arrived out of order.  Later, when packets 148, 149, 153...
             arrive, even though there is a 3-packet hole, there will be
             no problem, because the packets to fill the hole are
             already in the receive buffer.

      4.  Even with the current recommended TCP (N=3) spurious
          retransmissions will be unlikely for all the above reasons.
          As RACK [I-D.ietf-tcpm-rack] is becoming widely deployed, it
          tends to adapt its reordering window to a larger value of N,
          which will make the chance of a contiguous sequence of N early
          arrivals vanishingly small.

      5.  Even a run of 2 CE marks within a classic ECN flow is
          unlikely, given FQ-CoDel is the only known widely deployed AQM
          that supports classic ECN marking and it takes great care to
          separate out flows and to space any markings evenly along each
          flow.

      It is extremely unlikely that the above set of 5 eventualities
      that are each unusual in themselves would all happen
      simultaneously.  But, even if they did, the consequences would
      hardly be dire: the odd spurious fast retransmission.  Admittedly
      TCP reduces its congestion window when it deems there has been a
      loss, but even this can be recovered once the sender detects that
      the retransmission was spurious.




-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------CADEF1FB433DB76B60AD3057-- From nobody Thu Jun 13 21:37:48 2019 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 BD35F120139 for ; Thu, 13 Jun 2019 21:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.047 X-Spam-Level: X-Spam-Status: No, score=-4.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=icloud.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 MvjOPTykIVWs for ; Thu, 13 Jun 2019 21:37:43 -0700 (PDT) Received: from mr85p00im-hyfv06011301.me.com (mr85p00im-hyfv06011301.me.com [17.58.23.184]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F5471200B5 for ; Thu, 13 Jun 2019 21:37:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1560487062; bh=ItLiKJJSgPsb8/yJjKmPIO570ZyGe/4YdRWPxLVQBgw=; h=From:Content-Type:Mime-Version:Subject:Date:To:Message-Id; b=PJVbNM/7SWEktpDnixotE6BwZ7ceuG897tnroE07/kiofBjLlsebe9jf/urCO39EC A+i6dogMV4tEmePM9Zve5nPuK3V2YPRA26aitFbmBpd1yZ+1q0ru2uBwFeAUByi5YX ViPFiZXjlcnGZhq9q9Hagg/n+RmvoUU+SnPT0ncP9yLmicyHiUcOnJoEPECFckRH49 aEVGEW1JWLmygU7BuQEOrlwnViCFBFd1RHDS0c7GmKx88/xuBeTCJYeco3Ri+zha8J D6wo4iLa4F+fC/ljfpjBmb2Miu9pfNaKcGg5U0uVI94z1VMeeV+acaUAxqQYfNKpu9 hSlMAVIGjYhkg== Received: from [192.168.1.101] (m201-12.dsl.tsoft.com [198.144.201.12]) by mr85p00im-hyfv06011301.me.com (Postfix) with ESMTPSA id 28646580B02 for ; Fri, 14 Jun 2019 04:37:42 +0000 (UTC) From: Greg Skinner Content-Type: multipart/alternative; boundary="Apple-Mail=_8D68DB98-5796-41FB-8CF5-F16C388DFB01" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 13 Jun 2019 21:37:39 -0700 References: <155961153844.24918.3595391320504211546@ietfa.amsl.com> To: tcpm@ietf.org In-Reply-To: <155961153844.24918.3595391320504211546@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3273) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-14_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=984 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1906140038 Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-13.txt 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, 14 Jun 2019 04:37:46 -0000 --Apple-Mail=_8D68DB98-5796-41FB-8CF5-F16C388DFB01 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I found a few items while referring to this draft. I hope the feedback = will be useful. =C2=A73.4: In the sentence "The principle reason for the three-way handshake is to = prevent old duplicate connection initiations from causing confusion.=E2=80= =9D I believe the correct spelling should be =E2=80=9Cprincipal=E2=80=9D, = because it is being used as an adjective. (More information is = available from the definition of principal at wordreference.com = .)=20 =C2=A73.8.6: The phrase =E2=80=9Crobustness principle=E2=80=9D is used, but not = cited. While most readers of the draft probably know what it is, others = may not. IMO, a citation would be helpful, either from references = already in the draft (RFCs 791, 793), or others such as RFC 1958, =C2=A73.= =20 =C2=A77: s/alphebetically/alphabetically/ BR, Greg > On Jun 3, 2019, at 6:25 PM, internet-drafts@ietf.org wrote: >=20 > 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. >=20 > Title : Transmission Control Protocol Specification > Author : Wesley M. Eddy > Filename : draft-ietf-tcpm-rfc793bis-13.txt > Pages : 104 > Date : 2019-06-03 >=20 > Abstract: > This document specifies the Internet's Transmission Control Protocol > (TCP). TCP is an important transport layer protocol in the Internet > stack, and has continuously evolved over decades of use and growth = of > the Internet. Over this time, a number of changes have been made to > TCP as it was specified in RFC 793, though these have only been > documented in a piecemeal fashion. This document collects and = brings > those changes together with the protocol specification from RFC 793. > This document obsoletes RFC 793, as well as 879, 2873, 6093, 6429, > 6528, and 6691 that updated parts of RFC 793. It updates RFC 1122, > and should be considered as a replacement for the portions of that > document dealing with TCP requirements. It updates RFC 5961 due to = a > small clarification in reset handling while in the SYN-RECEIVED > state. >=20 > RFC EDITOR NOTE: If approved for publication as an RFC, this should > be marked additionally as "STD: 7" and replace RFC 793 in that role. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-13 > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-13 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rfc793bis-13 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 --Apple-Mail=_8D68DB98-5796-41FB-8CF5-F16C388DFB01 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I found a few items while referring to this = draft.  I hope the feedback will be useful.

=C2=A73.4:

In the sentence "The principle reason = for the three-way handshake is to prevent old duplicate connection = initiations from causing confusion.=E2=80=9D I believe the correct = spelling should be =E2=80=9Cprincipal=E2=80=9D, because it is being used = as an adjective.  (More information is available from the definition of principal at = wordreference.com.) 

=C2=A73.8.6:

The phrase =E2=80=9Crobustness = principle=E2=80=9D is used, but not cited.  While most readers of = the draft probably know what it is, others may not.  IMO, a = citation would be helpful, either from references already in the draft = (RFCs 791, 793), or others such as RFC 1958, =C2=A73.
 
=C2=A77:

s/alphebetically/alphabetically/

BR, Greg

On = Jun 3, 2019, at 6:25 PM, internet-drafts@ietf.org wrote:

A = New Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the TCP = Maintenance and Minor Extensions WG of the IETF.

       Title =           : = Transmission Control Protocol Specification
=        Author =          : Wesley M. = Eddy
Filename =        : = draft-ietf-tcpm-rfc793bis-13.txt
Pages =           : 104
= Date =            : = 2019-06-03

Abstract:
=   This document specifies the Internet's Transmission Control = Protocol
  (TCP).  TCP is an important = transport layer protocol in the Internet
=   stack, and has continuously evolved over decades of use and = growth of
  the Internet.  Over this time, = a number of changes have been made to
  TCP as = it was specified in RFC 793, though these have only been
=   documented in a piecemeal fashion.  This document = collects and brings
  those changes together = with the protocol specification from RFC 793.
=   This document obsoletes RFC 793, as well as 879, 2873, 6093, = 6429,
  6528, and 6691 that updated parts of = RFC 793.  It updates RFC 1122,
  and = should be considered as a replacement for the portions of that
  document dealing with TCP requirements.  It = updates RFC 5961 due to a
  small clarification = in reset handling while in the SYN-RECEIVED
=   state.

  RFC EDITOR = NOTE: If approved for publication as an RFC, this should
=   be marked additionally as "STD: 7" and replace RFC 793 in = that role.



The = IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/=

There are also htmlized versions available = at:
https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-13
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis= -13

A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rfc793bis-1= 3


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

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



= --Apple-Mail=_8D68DB98-5796-41FB-8CF5-F16C388DFB01-- From nobody Sun Jun 16 01:28:13 2019 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 4EC391200E5; Sun, 16 Jun 2019 01:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.89 X-Spam-Level: X-Spam-Status: No, score=-0.89 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, 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 hPK6o0U6VsVn; Sun, 16 Jun 2019 01:28:09 -0700 (PDT) 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 26EB912001E; Sun, 16 Jun 2019 01:28:06 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 0687625A1A; Sun, 16 Jun 2019 10:28:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1560673684; bh=NzZckTH8OS8UfJrsa9KMWYXzec+M6VBIgz9qChIGzqY=; h=From:To:CC:Subject:Date:From; b=AvIDipd9Ig244MtAD2rBMF9zkzZ/YR3DFf4gqcJHZJE+oUHynrjLLimNy4hyw0uOR d6LOy9KuuMjQnK8QuRcNVHxg7Jg3xyzoZF4AnZlIz9GHkRJ4MhxpfSyvxvKsvZPLY5 gY+4958nqeZcp4e2WusOFMLcaFuY55W307FFb0I8= 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 4X2FVJBQ5-2s; Sun, 16 Jun 2019 10:28:03 +0200 (CEST) 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; Sun, 16 Jun 2019 10:28:03 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.117]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0415.000; Sun, 16 Jun 2019 10:28:02 +0200 From: "Scharf, Michael" To: "draft-ietf-tcpm-converters@ietf.org" CC: "tcpm@ietf.org Extensions" Thread-Topic: draft-ietf-tcpm-converters Thread-Index: AdUkHWlwWAVA12efRnCFBwL9n6nkWA== Date: Sun, 16 Jun 2019 08:28:01 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D336687@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_6EC6417807D9754DA64F3087E2E2E03E2D336687rznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: [tcpm] draft-ietf-tcpm-converters 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, 16 Jun 2019 08:28:11 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D336687rznt8114rzntrzd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJbiBwcmVwYXJhdGlvbiBvZiBhIHBsYW5uZWQgV0dMQyAoaGVhZHMtdXAgdG8g YWxsKSBJIGhhdmUgcmVhZCBkcmFmdC1pZXRmLXRjcG0tY29udmVydGVycy0wNyBhZ2Fpbi4NCg0K QXMgYSByZXN1bHQsIEkgaGF2ZSB0d28gZnVydGhlciBxdWVzdGlvbnMgKGFzIGluZGl2aWR1YWwg Y29udHJpYnV0b3IsIGlmIHRoYXQgbWF0dGVycykuIElkZWFsbHkgSSBzaG91bGQgaGF2ZSBhbHJl YWR5IG5vdGVkIHdoZW4gcmVhZGluZyB0aGUgZG9jdW1lbnQgbGFzdCB0aW1l4oCmDQoNCjEvIFRo ZSBoYW5kbGluZyBvZiB0aGUgdGhyZWUtd2F5IGhhbmRzaGFrZSBpcyB3ZWxsIHNwZWNpZmllZCBp biB0aGUgZG9jdW1lbnQsIGFuZCB0aGlzIGlzIHdoYXQgdGhlIGNvbnZlcnQgcHJvdG9jb2wgaXMg YWJvdXQuIFlldCwgSSByZWFsbHkgd29uZGVyIGlmIHNvbWUgd29yZHMgYXJlIG5lZWRlZCBvbiB3 aGF0IHRoZSBlbmRwb2ludHMgY2FuIGV4cGVjdCBmcm9tIHRoZSBjb252ZXJ0ZXIgb25jZSB0aGUg Y29ubmVjdGlvbiBpcyBlc3RhYmxpc2hlZD8gSW4gc2VjdGlvbiAxLCB0aGUgZG9jdW1lbnQgc3Bl Y2lmaWVzIHRoYXQgdGhlIGNvbnZlcnRlcnMg4oCecmVsYXkgY29udHJvbCBtZXNzYWdlcyBhbmQg ZGF0YSBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBzZXJ2ZXLigJwuIFdoaWxlIEkgYmVsaWV2 ZSBtb3N0IG9mIHVzIGhhdmUgYW4gaWRlYSB3aGF0IHRoaXMgbWVhbnMsIEkgd29uZGVyIGlmIGl0 IGlzIGZvcm1hbGx5IGNsZWFyIHdoYXQgdGhhdCBpbXBsaWVzIGZvciBhY2tub3dsZWRnZW1lbnRz IGFuZCBjb25uZWN0aW9uIG1hbmFnZW1lbnQgKGUuZy4sIEZJTiwgUlNULCBrZWVwYWxpdmVzKS4g Rm9yIGluc3RhbmNlLCBpZiB0aGUgY2xpZW50IHJlY2VpdmVzIGFuIEFDSyBmb3IgYSBzZWdtZW50 IHdpdGggRklOIGZsYWcsIGNhbiB0aGUgY2xpZW50IGFzc3VtZSB0aGF0IHRoZSBzZXJ2ZXIgaGFz IHJlY2VpdmVkIGEgRklOIGZyb20gdGhlIGNvbnZlcnRlciBhbmQgdGhhdCB0aGUgY29udmVydGVy IGhhcyByZWNlaXZlZCBhbiBBQ0sgZnJvbSB0aGUgU2VydmVyIGZvciB0aGF0IEZJTj8gTXkgdW5k ZXJzdGFuZGluZyBpcyB0aGF0IGEgY29udmVydGVyIGlzIG5vdCByZXF1aXJlZCB0byBndWFyYW50 ZWUgdGhlc2UgZW5kLXRvLWVuZCBzZW1hbnRpY3MuIElmIHRoYXQgaXMgdHJ1ZSwgd291bGRu4oCZ dCBpdCBiZSBiZXR0ZXIgdG8gYmUgZXhwbGljaXQgYWJvdXQgdGhhdD8gVGhpcyBtYXkgYWxzbyBy ZWxhdGUgdG8gd2hhdCBoYXBwZW5zIGluIGNhc2Ugb2YgZmFpbHVyZXMgaW5zaWRlIHRoZSBjb252 ZXJ0ZXIuDQoNCjIvIFRoZSBkb2N1bWVudCB1c2VzIHRoZSB0ZXJtIOKAnlRDUCBleHRlbmRlZCBo ZWFkZXLigJwsIGUuZy4gb24gcGFnZSAxMCBhbmQgMjMuIEFzIGZhciBhcyBJIGtub3csIHdlIHR5 cGljYWxseSBkb27igJl0IHVzZSB0aGlzIHRlcm0gZm9yIHRoZSBzdGFuZGFyZCBUQ1AgaGVhZGVy LCBlaXRoZXIgd2l0aCBvciB3aXRob3V0IG9wdGlvbnMuIGRyYWZ0LWlldGYtdGNwbS10Y3AtZWRv IHVzZXMgYSBzaW1pbGFyIHRlcm0sIGJ1dCBhcyBmYXIgYXMgSSB1bmRlcnN0YW5kIHRoZSBjb252 ZXJ0ZXIgcHJvdG9jb2wgZG9lcyBub3QgcmVseSBvbiBFRE8uIFdvdWxkbuKAmXQgaXQgYmUgbW9y ZSByZWFzb25hYmxlIHRvIHJlcGxhY2Ug4oCeVENQIGV4dGVuZGVkIGhlYWRlcuKAnCBieSBhIG1v cmUgY29tbW9uIHRlcm0sIGUuZy4gYnkg4oCeVENQIGhlYWRlcuKAnD8NCg0KVGhhbmtzDQoNCk1p Y2hhZWwNCg0KDQoNCg== --_000_6EC6417807D9754DA64F3087E2E2E03E2D336687rznt8114rzntrzd_ Content-Type: text/html; charset="utf-8" Content-ID: <48DD3A1979A5C1459C72EA8A5F255DF3@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 b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQg Mi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjg4MDA5NjI1 MTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEyNzU4 NTIyMDAgLTEgNjc1Njc2MTkgNjc1Njc2MjEgNjc1Njc2MTcgNjc1Njc2MTkgNjc1Njc2MjEgNjc1 Njc2MTcgNjc1Njc2MTkgNjc1Njc2MjE7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1z dGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWJp ZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpcRjBBNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBBNzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBBNzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3Qt aWQ6MTI3MzYzNTQxNTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6NTY1ODQ1MjE2IC0xIDY3NTY3NjE5IDY3NTY3NjIxIDY3NTY3NjE3IDY3NTY3NjE5IDY3 NTY3NjIxIDY3NTY3NjE3IDY3NTY3NjE5IDY3NTY3NjIxO30NCkBsaXN0IGwxOmxldmVsMQ0KCXtt c28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i Ow0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6XEYwQTc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxl dmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 XEYwQTc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQTc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdp bi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJERSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SGkgYWxsLDwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gcHJlcGFyYXRpb24gb2Yg YSBwbGFubmVkIFdHTEMgKGhlYWRzLXVwIHRvIGFsbCkgSSBoYXZlIHJlYWQgZHJhZnQtaWV0Zi10 Y3BtLWNvbnZlcnRlcnMtMDcgYWdhaW4uPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBhIHJlc3VsdCwgSSBoYXZl IHR3byBmdXJ0aGVyIHF1ZXN0aW9ucyAoYXMgaW5kaXZpZHVhbCBjb250cmlidXRvciwgaWYgdGhh dCBtYXR0ZXJzKS4gSWRlYWxseSBJIHNob3VsZCBoYXZlIGFscmVhZHkgbm90ZWQgd2hlbiByZWFk aW5nIHRoZSBkb2N1bWVudCBsYXN0IHRpbWXigKY8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEvIFRoZSBoYW5kbGlu ZyBvZiB0aGUgdGhyZWUtd2F5IGhhbmRzaGFrZSBpcyB3ZWxsIHNwZWNpZmllZCBpbiB0aGUgZG9j dW1lbnQsIGFuZCB0aGlzIGlzIHdoYXQgdGhlIGNvbnZlcnQgcHJvdG9jb2wgaXMgYWJvdXQuIFll dCwgSSByZWFsbHkgd29uZGVyIGlmIHNvbWUgd29yZHMgYXJlIG5lZWRlZCBvbiB3aGF0IHRoZSBl bmRwb2ludHMgY2FuIGV4cGVjdCBmcm9tIHRoZSBjb252ZXJ0ZXIgb25jZSB0aGUgY29ubmVjdGlv bg0KIGlzIGVzdGFibGlzaGVkPyBJbiBzZWN0aW9uIDEsIHRoZSBkb2N1bWVudCBzcGVjaWZpZXMg dGhhdCB0aGUgY29udmVydGVycyDigJ5yZWxheSBjb250cm9sIG1lc3NhZ2VzIGFuZCBkYXRhIGJl dHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIHNlcnZlcuKAnC4gV2hpbGUgSSBiZWxpZXZlIG1vc3Qg b2YgdXMgaGF2ZSBhbiBpZGVhIHdoYXQgdGhpcyBtZWFucywgSSB3b25kZXIgaWYgaXQgaXMgZm9y bWFsbHkgY2xlYXIgd2hhdCB0aGF0IGltcGxpZXMgZm9yIGFja25vd2xlZGdlbWVudHMNCiBhbmQg Y29ubmVjdGlvbiBtYW5hZ2VtZW50IChlLmcuLCBGSU4sIFJTVCwga2VlcGFsaXZlcykuIEZvciBp bnN0YW5jZSwgaWYgdGhlIGNsaWVudCByZWNlaXZlcyBhbiBBQ0sgZm9yIGEgc2VnbWVudCB3aXRo IEZJTiBmbGFnLCBjYW4gdGhlIGNsaWVudCBhc3N1bWUgdGhhdCB0aGUgc2VydmVyIGhhcyByZWNl aXZlZCBhIEZJTiBmcm9tIHRoZSBjb252ZXJ0ZXIgYW5kIHRoYXQgdGhlIGNvbnZlcnRlciBoYXMg cmVjZWl2ZWQgYW4gQUNLIGZyb20gdGhlDQogU2VydmVyIGZvciB0aGF0IEZJTj8gTXkgdW5kZXJz dGFuZGluZyBpcyB0aGF0IGEgY29udmVydGVyIGlzIG5vdCByZXF1aXJlZCB0byBndWFyYW50ZWUg dGhlc2UgZW5kLXRvLWVuZCBzZW1hbnRpY3MuIElmIHRoYXQgaXMgdHJ1ZSwgd291bGRu4oCZdCBp dCBiZSBiZXR0ZXIgdG8gYmUgZXhwbGljaXQgYWJvdXQgdGhhdD8gVGhpcyBtYXkgYWxzbyByZWxh dGUgdG8gd2hhdCBoYXBwZW5zIGluIGNhc2Ugb2YgZmFpbHVyZXMgaW5zaWRlIHRoZSBjb252ZXJ0 ZXIuPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4yLyBUaGUgZG9jdW1lbnQgdXNlcyB0aGUgdGVybSDigJ5UQ1AgZXh0 ZW5kZWQgaGVhZGVy4oCcLCBlLmcuIG9uIHBhZ2UgMTAgYW5kIDIzLiBBcyBmYXIgYXMgSSBrbm93 LCB3ZSB0eXBpY2FsbHkgZG9u4oCZdCB1c2UgdGhpcyB0ZXJtIGZvciB0aGUgc3RhbmRhcmQgVENQ IGhlYWRlciwgZWl0aGVyIHdpdGggb3Igd2l0aG91dCBvcHRpb25zLiBkcmFmdC1pZXRmLXRjcG0t dGNwLWVkbyB1c2VzIGEgc2ltaWxhciB0ZXJtLCBidXQNCiBhcyBmYXIgYXMgSSB1bmRlcnN0YW5k IHRoZSBjb252ZXJ0ZXIgcHJvdG9jb2wgZG9lcyBub3QgcmVseSBvbiBFRE8uIFdvdWxkbuKAmXQg aXQgYmUgbW9yZSByZWFzb25hYmxlIHRvIHJlcGxhY2Ug4oCeVENQIGV4dGVuZGVkIGhlYWRlcuKA nCBieSBhIG1vcmUgY29tbW9uIHRlcm0sIGUuZy4gYnkg4oCeVENQIGhlYWRlcuKAnD88L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYW5rczwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWljaGFlbDwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6EC6417807D9754DA64F3087E2E2E03E2D336687rznt8114rzntrzd_-- From nobody Sun Jun 16 23:11:06 2019 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 714001200D6 for ; Sun, 16 Jun 2019 23:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 0KQZ6AGBox9K for ; Sun, 16 Jun 2019 23:11:02 -0700 (PDT) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FBF812007A for ; Sun, 16 Jun 2019 23:11:02 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 45S16r0Dhtz5yWj; Mon, 17 Jun 2019 08:11:00 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.104]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 45S16q6L5VzDq7y; Mon, 17 Jun 2019 08:10:59 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM5F.corporate.adroot.infra.ftgroup ([fe80::193b:bc32:1ad3:362d%21]) with mapi id 14.03.0439.000; Mon, 17 Jun 2019 08:10:59 +0200 From: To: "Scharf, Michael" , "draft-ietf-tcpm-converters@ietf.org" CC: "tcpm@ietf.org Extensions" Thread-Topic: draft-ietf-tcpm-converters Thread-Index: AdUkHWlwWAVA12efRnCFBwL9n6nkWAArZURg Date: Mon, 17 Jun 2019 06:10:59 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EAA7AD7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <6EC6417807D9754DA64F3087E2E2E03E2D336687@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D336687@rznt8114.rznt.rzdir.fht-esslingen.de> 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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302EAA7AD7OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] draft-ietf-tcpm-converters 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, 17 Jun 2019 06:11:04 -0000 --_000_787AE7BB302AE849A7480A190F8B93302EAA7AD7OPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWljaGFlbCwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6 IFNjaGFyZiwgTWljaGFlbCBbbWFpbHRvOk1pY2hhZWwuU2NoYXJmQGhzLWVzc2xpbmdlbi5kZV0N CkVudm95w6kgOiBkaW1hbmNoZSAxNiBqdWluIDIwMTkgMTA6MjgNCsOAIDogZHJhZnQtaWV0Zi10 Y3BtLWNvbnZlcnRlcnNAaWV0Zi5vcmcNCkNjIDogdGNwbUBpZXRmLm9yZyBFeHRlbnNpb25zDQpP YmpldCA6IGRyYWZ0LWlldGYtdGNwbS1jb252ZXJ0ZXJzDQoNCkhpIGFsbCwNCg0KSW4gcHJlcGFy YXRpb24gb2YgYSBwbGFubmVkIFdHTEMgKGhlYWRzLXVwIHRvIGFsbCkgSSBoYXZlIHJlYWQgZHJh ZnQtaWV0Zi10Y3BtLWNvbnZlcnRlcnMtMDcgYWdhaW4uDQoNCkFzIGEgcmVzdWx0LCBJIGhhdmUg dHdvIGZ1cnRoZXIgcXVlc3Rpb25zIChhcyBpbmRpdmlkdWFsIGNvbnRyaWJ1dG9yLCBpZiB0aGF0 IG1hdHRlcnMpLiBJZGVhbGx5IEkgc2hvdWxkIGhhdmUgYWxyZWFkeSBub3RlZCB3aGVuIHJlYWRp bmcgdGhlIGRvY3VtZW50IGxhc3QgdGltZeKApg0KDQoxLyBUaGUgaGFuZGxpbmcgb2YgdGhlIHRo cmVlLXdheSBoYW5kc2hha2UgaXMgd2VsbCBzcGVjaWZpZWQgaW4gdGhlIGRvY3VtZW50LCBhbmQg dGhpcyBpcyB3aGF0IHRoZSBjb252ZXJ0IHByb3RvY29sIGlzIGFib3V0LiBZZXQsIEkgcmVhbGx5 IHdvbmRlciBpZiBzb21lIHdvcmRzIGFyZSBuZWVkZWQgb24gd2hhdCB0aGUgZW5kcG9pbnRzIGNh biBleHBlY3QgZnJvbSB0aGUgY29udmVydGVyIG9uY2UgdGhlIGNvbm5lY3Rpb24gaXMgZXN0YWJs aXNoZWQ/IEluIHNlY3Rpb24gMSwgdGhlIGRvY3VtZW50IHNwZWNpZmllcyB0aGF0IHRoZSBjb252 ZXJ0ZXJzIOKAnnJlbGF5IGNvbnRyb2wgbWVzc2FnZXMgYW5kIGRhdGEgYmV0d2VlbiB0aGUgY2xp ZW50IGFuZCB0aGUgc2VydmVy4oCcLiBXaGlsZSBJIGJlbGlldmUgbW9zdCBvZiB1cyBoYXZlIGFu IGlkZWEgd2hhdCB0aGlzIG1lYW5zLCBJIHdvbmRlciBpZiBpdCBpcyBmb3JtYWxseSBjbGVhciB3 aGF0IHRoYXQgaW1wbGllcyBmb3IgYWNrbm93bGVkZ2VtZW50cyBhbmQgY29ubmVjdGlvbiBtYW5h Z2VtZW50IChlLmcuLCBGSU4sIFJTVCwga2VlcGFsaXZlcykuIEZvciBpbnN0YW5jZSwgaWYgdGhl IGNsaWVudCByZWNlaXZlcyBhbiBBQ0sgZm9yIGEgc2VnbWVudCB3aXRoIEZJTiBmbGFnLCBjYW4g dGhlIGNsaWVudCBhc3N1bWUgdGhhdCB0aGUgc2VydmVyIGhhcyByZWNlaXZlZCBhIEZJTiBmcm9t IHRoZSBjb252ZXJ0ZXIgYW5kIHRoYXQgdGhlIGNvbnZlcnRlciBoYXMgcmVjZWl2ZWQgYW4gQUNL IGZyb20gdGhlIFNlcnZlciBmb3IgdGhhdCBGSU4/IE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBh IGNvbnZlcnRlciBpcyBub3QgcmVxdWlyZWQgdG8gZ3VhcmFudGVlIHRoZXNlIGVuZC10by1lbmQg c2VtYW50aWNzLiBJZiB0aGF0IGlzIHRydWUsIHdvdWxkbuKAmXQgaXQgYmUgYmV0dGVyIHRvIGJl IGV4cGxpY2l0IGFib3V0IHRoYXQ/IFRoaXMgbWF5IGFsc28gcmVsYXRlIHRvIHdoYXQgaGFwcGVu cyBpbiBjYXNlIG9mIGZhaWx1cmVzIGluc2lkZSB0aGUgY29udmVydGVyLg0KDQpbTWVkXSBXZSBj YW4gYWRkIHNvbWUgZGV0YWlscyBpZiB5b3UgdGhuayB0aGlzIGlzIHVzZWZ1bC4gQSBmaXJzdCBh dHRlbXB0IHRvIGFkZHJlc3MgeW91ciBjb21tZW50IGlzIGF2YWlsYWJsZSBhdDogaHR0cHM6Ly9n aXRodWIuY29tL29ib25hdmVudHVyZS9kcmFmdC10Y3AtY29udmVydGVycy9wdWxsLzYwL2ZpbGVz LiBXZSB3aWxsIGZ1cnRoZXIgdHdlYWsgdGhlIHRleHQgYW5kIHJlbGVhc2UgYSBuZXcgcmV2aXNp b24gc29vbi4NCg0KMi8gVGhlIGRvY3VtZW50IHVzZXMgdGhlIHRlcm0g4oCeVENQIGV4dGVuZGVk IGhlYWRlcuKAnCwgZS5nLiBvbiBwYWdlIDEwIGFuZCAyMy4gQXMgZmFyIGFzIEkga25vdywgd2Ug dHlwaWNhbGx5IGRvbuKAmXQgdXNlIHRoaXMgdGVybSBmb3IgdGhlIHN0YW5kYXJkIFRDUCBoZWFk ZXIsIGVpdGhlciB3aXRoIG9yIHdpdGhvdXQgb3B0aW9ucy4gZHJhZnQtaWV0Zi10Y3BtLXRjcC1l ZG8gdXNlcyBhIHNpbWlsYXIgdGVybSwgYnV0IGFzIGZhciBhcyBJIHVuZGVyc3RhbmQgdGhlIGNv bnZlcnRlciBwcm90b2NvbCBkb2VzIG5vdCByZWx5IG9uIEVETy4gV291bGRu4oCZdCBpdCBiZSBt b3JlIHJlYXNvbmFibGUgdG8gcmVwbGFjZSDigJ5UQ1AgZXh0ZW5kZWQgaGVhZGVy4oCcIGJ5IGEg bW9yZSBjb21tb24gdGVybSwgZS5nLiBieSDigJ5UQ1AgaGVhZGVy4oCcPw0KDQpbTWVkXSBXaWxs IGJlIGZpeGVkLg0KDQpUaGFua3MNCg0KTWljaGFlbA0KDQoNCg0K --_000_787AE7BB302AE849A7480A190F8B93302EAA7AD7OPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9t OjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1h bDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDIuMGNtIDcw Ljg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPkhpIE1pY2hhZWwsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlBsZWFzZSBzZWUg aW5saW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFNjaGFyZiwgTWljaGFlbCBbbWFpbHRvOk1pY2hhZWwu U2NoYXJmQGhzLWVzc2xpbmdlbi5kZV0NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBkaW1h bmNoZSAxNiBqdWluIDIwMTkgMTA6Mjg8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IGRyYWZ0LWlldGYt dGNwbS1jb252ZXJ0ZXJzQGlldGYub3JnPGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiB0Y3BtQGlldGYu b3JnIEV4dGVuc2lvbnM8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IGRyYWZ0LWlldGYtdGNwbS1j b252ZXJ0ZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iREUiPkhpIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJERSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iREUiPkluIHByZXBhcmF0aW9uIG9mIGEg cGxhbm5lZCBXR0xDIChoZWFkcy11cCB0byBhbGwpIEkgaGF2ZSByZWFkIGRyYWZ0LWlldGYtdGNw bS1jb252ZXJ0ZXJzLTA3IGFnYWluLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkRFIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJERSI+QXMgYSByZXN1bHQsIEkgaGF2ZSB0 d28gZnVydGhlciBxdWVzdGlvbnMgKGFzIGluZGl2aWR1YWwgY29udHJpYnV0b3IsIGlmIHRoYXQg bWF0dGVycykuIElkZWFsbHkgSSBzaG91bGQgaGF2ZSBhbHJlYWR5IG5vdGVkIHdoZW4gcmVhZGlu ZyB0aGUgZG9jdW1lbnQgbGFzdCB0aW1l4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iREUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkRFIj4xLyBUaGUgaGFuZGxpbmcg b2YgdGhlIHRocmVlLXdheSBoYW5kc2hha2UgaXMgd2VsbCBzcGVjaWZpZWQgaW4gdGhlIGRvY3Vt ZW50LCBhbmQgdGhpcyBpcyB3aGF0IHRoZSBjb252ZXJ0IHByb3RvY29sIGlzIGFib3V0LiBZZXQs IEkgcmVhbGx5IHdvbmRlciBpZiBzb21lIHdvcmRzIGFyZSBuZWVkZWQgb24gd2hhdCB0aGUgZW5k cG9pbnRzIGNhbiBleHBlY3QgZnJvbSB0aGUgY29udmVydGVyDQogb25jZSB0aGUgY29ubmVjdGlv biBpcyBlc3RhYmxpc2hlZD8gSW4gc2VjdGlvbiAxLCB0aGUgZG9jdW1lbnQgc3BlY2lmaWVzIHRo YXQgdGhlIGNvbnZlcnRlcnMg4oCecmVsYXkgY29udHJvbCBtZXNzYWdlcyBhbmQgZGF0YSBiZXR3 ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBzZXJ2ZXLigJwuIFdoaWxlIEkgYmVsaWV2ZSBtb3N0IG9m IHVzIGhhdmUgYW4gaWRlYSB3aGF0IHRoaXMgbWVhbnMsIEkgd29uZGVyIGlmIGl0IGlzIGZvcm1h bGx5IGNsZWFyIHdoYXQNCiB0aGF0IGltcGxpZXMgZm9yIGFja25vd2xlZGdlbWVudHMgYW5kIGNv bm5lY3Rpb24gbWFuYWdlbWVudCAoZS5nLiwgRklOLCBSU1QsIGtlZXBhbGl2ZXMpLiBGb3IgaW5z dGFuY2UsIGlmIHRoZSBjbGllbnQgcmVjZWl2ZXMgYW4gQUNLIGZvciBhIHNlZ21lbnQgd2l0aCBG SU4gZmxhZywgY2FuIHRoZSBjbGllbnQgYXNzdW1lIHRoYXQgdGhlIHNlcnZlciBoYXMgcmVjZWl2 ZWQgYSBGSU4gZnJvbSB0aGUgY29udmVydGVyIGFuZCB0aGF0IHRoZSBjb252ZXJ0ZXINCiBoYXMg cmVjZWl2ZWQgYW4gQUNLIGZyb20gdGhlIFNlcnZlciBmb3IgdGhhdCBGSU4/IE15IHVuZGVyc3Rh bmRpbmcgaXMgdGhhdCBhIGNvbnZlcnRlciBpcyBub3QgcmVxdWlyZWQgdG8gZ3VhcmFudGVlIHRo ZXNlIGVuZC10by1lbmQgc2VtYW50aWNzLiBJZiB0aGF0IGlzIHRydWUsIHdvdWxkbuKAmXQgaXQg YmUgYmV0dGVyIHRvIGJlIGV4cGxpY2l0IGFib3V0IHRoYXQ/IFRoaXMgbWF5IGFsc28gcmVsYXRl IHRvIHdoYXQgaGFwcGVucyBpbiBjYXNlIG9mDQogZmFpbHVyZXMgaW5zaWRlIHRoZSBjb252ZXJ0 ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iREUiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVk XSBXZSBjYW4gYWRkIHNvbWUgZGV0YWlscyBpZiB5b3UgdGhuayB0aGlzIGlzIHVzZWZ1bC4gQSBm aXJzdCBhdHRlbXB0IHRvIGFkZHJlc3MgeW91ciBjb21tZW50IGlzIGF2YWlsYWJsZSBhdDoNCjxh IGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9vYm9uYXZlbnR1cmUvZHJhZnQtdGNwLWNvbnZlcnRl cnMvcHVsbC82MC9maWxlcyI+aHR0cHM6Ly9naXRodWIuY29tL29ib25hdmVudHVyZS9kcmFmdC10 Y3AtY29udmVydGVycy9wdWxsLzYwL2ZpbGVzPC9hPi4gV2Ugd2lsbCBmdXJ0aGVyIHR3ZWFrIHRo ZSB0ZXh0IGFuZCByZWxlYXNlIGEgbmV3IHJldmlzaW9uIHNvb24uDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkRFIj4yLyBUaGUgZG9jdW1lbnQgdXNlcyB0aGUgdGVybSDigJ5UQ1AgZXh0ZW5k ZWQgaGVhZGVy4oCcLCBlLmcuIG9uIHBhZ2UgMTAgYW5kIDIzLiBBcyBmYXIgYXMgSSBrbm93LCB3 ZSB0eXBpY2FsbHkgZG9u4oCZdCB1c2UgdGhpcyB0ZXJtIGZvciB0aGUgc3RhbmRhcmQgVENQIGhl YWRlciwgZWl0aGVyIHdpdGggb3Igd2l0aG91dCBvcHRpb25zLiBkcmFmdC1pZXRmLXRjcG0tdGNw LWVkbyB1c2VzIGENCiBzaW1pbGFyIHRlcm0sIGJ1dCBhcyBmYXIgYXMgSSB1bmRlcnN0YW5kIHRo ZSBjb252ZXJ0ZXIgcHJvdG9jb2wgZG9lcyBub3QgcmVseSBvbiBFRE8uIFdvdWxkbuKAmXQgaXQg YmUgbW9yZSByZWFzb25hYmxlIHRvIHJlcGxhY2Ug4oCeVENQIGV4dGVuZGVkIGhlYWRlcuKAnCBi eSBhIG1vcmUgY29tbW9uIHRlcm0sIGUuZy4gYnkg4oCeVENQIGhlYWRlcuKAnD88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJERSIgc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIFdpbGwgYmUgZml4 ZWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkRFIj5UaGFua3M8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJERSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iREUiPk1p Y2hhZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJERSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iREUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkRFIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B93302EAA7AD7OPEXCAUBMA2corp_-- From nobody Sun Jun 16 23:19:56 2019 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 C4C3412000E for ; Sun, 16 Jun 2019 23:19:54 -0700 (PDT) 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 9F0E3j5EQCPu for ; Sun, 16 Jun 2019 23:19:51 -0700 (PDT) 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 78F67120106 for ; Sun, 16 Jun 2019 23:19:51 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 318D725A13; Mon, 17 Jun 2019 08:19:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1560752389; bh=nz30cA+2B8jgRmCaLTEZlhWDvkL5/ZAgMdSGyPauriI=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=vFalSfyDZWh2K8XcGaLdeWyyQ1rl9CZJCSitil2rxKnIynK2vYYte5bMh0KHMLBfY XwCH/IDJv/6G+wBL4i2GoiCX0cri+YSz/vyr6pwQBsI0EC/oYZilijR55UAEoLHbLQ rgxqVP/ktKil+cY128Eygp1lIA+kZC/UaLEBqLi8= 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 Oun4RJRV5AdX; Mon, 17 Jun 2019 08:19:48 +0200 (CEST) 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, 17 Jun 2019 08:19:48 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.117]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0415.000; Mon, 17 Jun 2019 08:19:47 +0200 From: "Scharf, Michael" To: "mohamed.boucadair@orange.com" , "draft-ietf-tcpm-converters@ietf.org" CC: "tcpm@ietf.org Extensions" Thread-Topic: draft-ietf-tcpm-converters Thread-Index: AdUkHWlwWAVA12efRnCFBwL9n6nkWAArZURgAAJqz1Q= Date: Mon, 17 Jun 2019 06:19:47 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D3378FF@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D336687@rznt8114.rznt.rzdir.fht-esslingen.de>, <787AE7BB302AE849A7480A190F8B93302EAA7AD7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EAA7AD7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D3378FFrznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] draft-ietf-tcpm-converters 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, 17 Jun 2019 06:19:55 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D3378FFrznt8114rzntrzd_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Med, The proposed text would address my concern. Thanks Michael Von: mohamed.boucadair@orange.com Gesendet: Montag, 17. Juni 2019 08:11 An: Scharf, Michael; draft-ietf-tcpm= -converters@ietf.org Cc: tcpm@ietf.org Extensions Betreff: RE: draft-ietf-tcpm-converters Hi Michael, Please see inline. Cheers, Med De : Scharf, Michael [mailto:Michael.Scharf@hs-esslingen.de] Envoy=E9 : dimanche 16 juin 2019 10:28 =C0 : draft-ietf-tcpm-converters@ietf.org Cc : tcpm@ietf.org Extensions Objet : draft-ietf-tcpm-converters Hi all, In preparation of a planned WGLC (heads-up to all) I have read draft-ietf-t= cpm-converters-07 again. As a result, I have two further questions (as individual contributor, if th= at matters). Ideally I should have already noted when reading the document = last time=85 1/ The handling of the three-way handshake is well specified in the documen= t, and this is what the convert protocol is about. Yet, I really wonder if = some words are needed on what the endpoints can expect from the converter o= nce the connection is established? In section 1, the document specifies tha= t the converters =84relay control messages and data between the client and = the server=93. While I believe most of us have an idea what this means, I w= onder if it is formally clear what that implies for acknowledgements and co= nnection management (e.g., FIN, RST, keepalives). For instance, if the clie= nt receives an ACK for a segment with FIN flag, can the client assume that = the server has received a FIN from the converter and that the converter has= received an ACK from the Server for that FIN? My understanding is that a c= onverter is not required to guarantee these end-to-end semantics. If that i= s true, wouldn=92t it be better to be explicit about that? This may also re= late to what happens in case of failures inside the converter. [Med] We can add some details if you thnk this is useful. A first attempt t= o address your comment is available at: https://github.com/obonaventure/dra= ft-tcp-converters/pull/60/files. We will further tweak the text and release= a new revision soon. 2/ The document uses the term =84TCP extended header=93, e.g. on page 10 an= d 23. As far as I know, we typically don=92t use this term for the standard= TCP header, either with or without options. draft-ietf-tcpm-tcp-edo uses a= similar term, but as far as I understand the converter protocol does not r= ely on EDO. Wouldn=92t it be more reasonable to replace =84TCP extended hea= der=93 by a more common term, e.g. by =84TCP header=93? [Med] Will be fixed. Thanks Michael --_000_6EC6417807D9754DA64F3087E2E2E03E2D3378FFrznt8114rzntrzd_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

The proposed text would address my concern.

 

Thanks

 

Michael

 

 

Von: mohamed.boucadair@orange.com=
Gesendet: Montag, 17. Juni 2019 08:11
An: Scharf, Michae= l; draft-ietf-tcpm-converters@ietf.org
Cc: tcpm@ietf.org Extensions Betreff: RE: draft-ietf-tcpm-converters

 

Hi Michael,

 

Please see inline.

 

Cheers,

Med

 

De : Sc= harf, Michael [mailto:Michael.Scharf@hs-esslingen.de]
Envoy=E9 : dimanche 16 juin 2019 10:28
=C0 : draft-ietf-tcpm-converters@ietf.org
Cc : tcpm@ietf.org Extensions
Objet : draft-ietf-tcpm-converters

 

Hi all,

 

In preparation of a planned WGLC (= heads-up to all) I have read draft-ietf-tcpm-converters-07 again.

 

As a result, I have two further qu= estions (as individual contributor, if that matters). Ideally I should have= already noted when reading the document last time=85

 

1/ The handling of the three-way h= andshake is well specified in the document, and this is what the convert pr= otocol is about. Yet, I really wonder if some words are needed on what the = endpoints can expect from the converter once the connection is established? In section 1, the document specifies t= hat the converters =84relay control messages and data between the client an= d the server=93. While I believe most of us have an idea what this means, I= wonder if it is formally clear what that implies for acknowledgements and connection management (e.g., FIN, RS= T, keepalives). For instance, if the client receives an ACK for a segment w= ith FIN flag, can the client assume that the server has received a FIN from= the converter and that the converter has received an ACK from the Server for that FIN? My understanding is that= a converter is not required to guarantee these end-to-end semantics. If th= at is true, wouldn=92t it be better to be explicit about that? This may als= o relate to what happens in case of failures inside the converter.

 

[Med] We can add some details if= you thnk this is useful. A first attempt to address your comment is availa= ble at: https://github.com/obonaventure/draft-tcp-converters/pull/60/files.= We will further tweak the text and release a new revision soon.

 

2/ The document uses the term =84T= CP extended header=93, e.g. on page 10 and 23. As far as I know, we typical= ly don=92t use this term for the standard TCP header, either with or withou= t options. draft-ietf-tcpm-tcp-edo uses a similar term, but as far as I understand the converter protocol does not r= ely on EDO. Wouldn=92t it be more reasonable to replace =84TCP extended hea= der=93 by a more common term, e.g. by =84TCP header=93?

 

[Med] Will be fixed.

 

Thanks

 

Michael

 

 

 

--_000_6EC6417807D9754DA64F3087E2E2E03E2D3378FFrznt8114rzntrzd_-- From nobody Wed Jun 19 16:22:35 2019 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 22010120189; Wed, 19 Jun 2019 16:22:28 -0700 (PDT) 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.98.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <156098654804.12176.1402102848439954711@ietfa.amsl.com> Date: Wed, 19 Jun 2019 16:22:28 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-converters-08.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: Wed, 19 Jun 2019 23:22:28 -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 : 0-RTT TCP Convert Protocol Authors : Olivier Bonaventure Mohamed Boucadair Sri Gundavelli SungHoon Seo Benjamin Hesmans Filename : draft-ietf-tcpm-converters-08.txt Pages : 46 Date : 2019-06-19 Abstract: This document specifies an application proxy, called Transport Converter, to assist the deployment of TCP extensions such as Multipath TCP. This proxy is designed to avoid inducing extra delay when involved in a network-assisted connection (that is, 0-RTT). This specification assumes an explicit model, where the proxy is explicitly configured on hosts. -- Editorial Note (To be removed by RFC Editor) Please update these statements with the RFC number to be assigned to this document: [This-RFC] Please update TBA statements with the port number to be assigned to the 0-RTT TCP Convert Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-converters-08 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-converters-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 19 22:19:58 2019 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 8F84312047F; Wed, 19 Jun 2019 22:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 6FIPDaNtjHtz; Wed, 19 Jun 2019 22:19:53 -0700 (PDT) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43ABC120440; Wed, 19 Jun 2019 22:19:53 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 45TqrR2GJJz30cS; Thu, 20 Jun 2019 07:19:51 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.73]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 45TqrR19Cdz1xp2; Thu, 20 Jun 2019 07:19:51 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM23.corporate.adroot.infra.ftgroup ([fe80::9108:27dc:3496:8db3%21]) with mapi id 14.03.0439.000; Thu, 20 Jun 2019 07:19:51 +0200 From: To: "Scharf, Michael" CC: "tcpm@ietf.org Extensions" , "draft-ietf-tcpm-converters@ietf.org" , "adi@apple.com" Thread-Topic: draft-ietf-tcpm-converters Thread-Index: AdUkHWlwWAVA12efRnCFBwL9n6nkWAArZURgAAJqz1QAlKNUYA== Date: Thu, 20 Jun 2019 05:19:49 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EAA9B66@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <6EC6417807D9754DA64F3087E2E2E03E2D336687@rznt8114.rznt.rzdir.fht-esslingen.de>, <787AE7BB302AE849A7480A190F8B93302EAA7AD7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <6EC6417807D9754DA64F3087E2E2E03E2D3378FF@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D3378FF@rznt8114.rznt.rzdir.fht-esslingen.de> 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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302EAA9B66OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] draft-ietf-tcpm-converters 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, 20 Jun 2019 05:19:57 -0000 --_000_787AE7BB302AE849A7480A190F8B93302EAA9B66OPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Michael, FWIW, these changes are now implemented in -08. We also fixed some nits (th= anks Adi). Looking forward the WGLC. Cheers, Olivier & Med De : Scharf, Michael [mailto:Michael.Scharf@hs-esslingen.de] Envoy=E9 : lundi 17 juin 2019 08:20 =C0 : BOUCADAIR Mohamed TGI/OLN; draft-ietf-tcpm-converters@ietf.org Cc : tcpm@ietf.org Extensions Objet : Re: draft-ietf-tcpm-converters Hi Med, The proposed text would address my concern. Thanks Michael Von: mohamed.boucadair@orange.com Gesendet: Montag, 17. Juni 2019 08:11 An: Scharf, Michael; draft-ietf-tcpm= -converters@ietf.org Cc: tcpm@ietf.org Extensions Betreff: RE: draft-ietf-tcpm-converters Hi Michael, Please see inline. Cheers, Med De : Scharf, Michael [mailto:Michael.Scharf@hs-esslingen.de] Envoy=E9 : dimanche 16 juin 2019 10:28 =C0 : draft-ietf-tcpm-converters@ietf.org Cc : tcpm@ietf.org Extensions Objet : draft-ietf-tcpm-converters Hi all, In preparation of a planned WGLC (heads-up to all) I have read draft-ietf-t= cpm-converters-07 again. As a result, I have two further questions (as individual contributor, if th= at matters). Ideally I should have already noted when reading the document = last time... 1/ The handling of the three-way handshake is well specified in the documen= t, and this is what the convert protocol is about. Yet, I really wonder if = some words are needed on what the endpoints can expect from the converter o= nce the connection is established? In section 1, the document specifies tha= t the converters "relay control messages and data between the client and th= e server". While I believe most of us have an idea what this means, I wonde= r if it is formally clear what that implies for acknowledgements and connec= tion management (e.g., FIN, RST, keepalives). For instance, if the client r= eceives an ACK for a segment with FIN flag, can the client assume that the = server has received a FIN from the converter and that the converter has rec= eived an ACK from the Server for that FIN? My understanding is that a conve= rter is not required to guarantee these end-to-end semantics. If that is tr= ue, wouldn't it be better to be explicit about that? This may also relate t= o what happens in case of failures inside the converter. [Med] We can add some details if you thnk this is useful. A first attempt t= o address your comment is available at: https://github.com/obonaventure/dra= ft-tcp-converters/pull/60/files. We will further tweak the text and release= a new revision soon. 2/ The document uses the term "TCP extended header", e.g. on page 10 and 23= . As far as I know, we typically don't use this term for the standard TCP h= eader, either with or without options. draft-ietf-tcpm-tcp-edo uses a simil= ar term, but as far as I understand the converter protocol does not rely on= EDO. Wouldn't it be more reasonable to replace "TCP extended header" by a = more common term, e.g. by "TCP header"? [Med] Will be fixed. Thanks Michael --_000_787AE7BB302AE849A7480A190F8B93302EAA9B66OPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Michael,

 

FWIW, these changes are now imp= lemented in -08. We also fixed some nits (thanks Adi).

 

Looking forward the WGLC.

 

Cheers,

Olivier & Med

 

De : Scha= rf, Michael [mailto:Michael.Scharf@hs-esslingen.de]
Envoy=E9 : lundi 17 juin 2019 08:20
=C0 : BOUCADAIR Mohamed TGI/OLN; draft-ietf-tcpm-converters@iet= f.org
Cc : tcpm@ietf.org Extensions
Objet : Re: draft-ietf-tcpm-converters

 

Hi Med,

 

The proposed text would address my concern.

 

Thanks

 

Michael

 

 

Von: mohamed.boucadair@orange.com
Gesendet: Montag, 17. Juni 2019 08:11
An: Scharf, Michae= l; draft-ietf-tcpm-converters@ietf.org
Cc: tcpm@ietf.org Extensions Betreff: RE: draft-ietf-tcpm-converters

 

Hi Michael,

 

Please see inline.

 

Cheers,

Med

 

De : Scha= rf, Michael [mailto:Michael.Scharf@hs-esslingen.de]
Envoy=E9 : dimanche 16 juin 2019 10:28
=C0 : draft-ietf-tcpm-converters@ietf.org
Cc : tcpm@ietf.org Extensions
Objet : draft-ietf-tcpm-converters

 

Hi all,

 

In preparation of a planned WGLC (= heads-up to all) I have read draft-ietf-tcpm-converters-07 again.

 

As a result, I have two further qu= estions (as individual contributor, if that matters). Ideally I should have= already noted when reading the document last time…=

 

1/ The handling of the three-way h= andshake is well specified in the document, and this is what the convert pr= otocol is about. Yet, I really wonder if some words are needed on what the = endpoints can expect from the converter once the connection is established? In section 1, the document specifies t= hat the converters „relay control messages and data between the clien= t and the server“. While I believe most of us have an idea what this = means, I wonder if it is formally clear what that implies for acknowledgements and connection management (e.g., FIN, RS= T, keepalives). For instance, if the client receives an ACK for a segment w= ith FIN flag, can the client assume that the server has received a FIN from= the converter and that the converter has received an ACK from the Server for that FIN? My understanding is that= a converter is not required to guarantee these end-to-end semantics. If th= at is true, wouldn’t it be better to be explicit about that? This may= also relate to what happens in case of failures inside the converter.

 

[Med] We can add some details if y= ou thnk this is useful. A first attempt to address your comment is availabl= e at: https://github.com/obonaventure/draft-tcp-converters/pull/60/files.= We will further tweak the text and release a new revision soon.

 

2/ The document uses the term R= 22;TCP extended header“, e.g. on page 10 and 23. As far as I know, we= typically don’t use this term for the standard TCP header, either wi= th or without options. draft-ietf-tcpm-tcp-edo uses a similar term, but as far as I understand the converter protocol does not r= ely on EDO. Wouldn’t it be more reasonable to replace „TCP exte= nded header“ by a more common term, e.g. by „TCP header“?=

 

[Med] Will be fixed.

 

Thanks

 

Michael

 

 

 

--_000_787AE7BB302AE849A7480A190F8B93302EAA9B66OPEXCAUBMA2corp_-- From nobody Fri Jun 21 12:40:28 2019 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 7BF2E120155 for ; Fri, 21 Jun 2019 12:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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_NONE=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=mti-systems-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMAxg_WsezIy for ; Fri, 21 Jun 2019 12:40:23 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 B98A3120365 for ; Fri, 21 Jun 2019 12:40:18 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id a15so8110437qtn.7 for ; Fri, 21 Jun 2019 12:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=ry2rpOujHMLmvHtBeZT7YE9WP5EgMAaimo9N7tE/wJ4=; b=YBEcvAOAPG80bZNUW55Bs4eMQWWvhXWTSBoFwEhampbFR98BDcDDbm12Ykb2yD1rrG Hn1kLg7stKGyvFQLKmiYvDaeYRK0Y22wfGgaUkRTbIjxFn7VKOUk28ZkYCTEF6TikRC7 xibDB7HC3BYuaQLnsliYKUCvwhjQG1Pmy73YbAchKG/PWO2kmXdWRqNXDbUEkxdq+seV ZgdpoFqX1D4OrEK3qWb25Y92frKSki5bpTj1E+oApQ10r64vUSYW2NM+3u4DmR6NyWS5 TLQwqnW9J2Z1qot3MoFpOZm82YV+1Jty6UYilFFKZJLboNngON0u4eMMq4FoHiXyL5pk Pu+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=ry2rpOujHMLmvHtBeZT7YE9WP5EgMAaimo9N7tE/wJ4=; b=EGHlACaj8kzoUmBNpKmcZK6QwcujjuznF6VHLW4r+Veexsjgi1usZk9mgh5RFHRxTm PoUpBUhA5hQVNJl2KbL9Rb+CT73WTuuGE9ySJvAr9SEzQSmWQ4Qgi2zeOtP9OvIKFW3F 2LLeYW01hW9li30Mgb1poZH+pVrfGYi/jPDJXsJxTmMAXMWdw7OZoqB9R5cGgp1UdjF3 lNzfmsRzaLxMD37cS+MJSz2Zif0EH6owkfizpAuh8XL906fP7iSr7GxKd7xqm2pHPhYv q8F6jCbCc8Xy7w6mbInOR9k5j0KtV6yhrsWN4bCPQP8stpDfgFxFog1Bq9XmTt0z3BL5 7CYw== X-Gm-Message-State: APjAAAVa78zF7zYDlTwCRPzqrSe0FhfjQO+Tz1ey59bysS25fmZlnrQU 9wYfqnqOQ+j801Y/mW3xz+jk3A1k2Jg= X-Google-Smtp-Source: APXvYqwx58xZGpA/hfYkyXZnXM0T94MI0q+aW3xCR+vxczFm/PDp+s7/Y4N1SC87llpuUkEx9TTfUg== X-Received: by 2002:a0c:d09c:: with SMTP id z28mr46102808qvg.149.1561146017711; Fri, 21 Jun 2019 12:40:17 -0700 (PDT) Received: from [192.168.1.119] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id c4sm2063453qkd.24.2019.06.21.12.40.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jun 2019 12:40:16 -0700 (PDT) To: tcpm@ietf.org References: <155961153844.24918.3595391320504211546@ietfa.amsl.com> From: Wesley Eddy Message-ID: <309fa0fa-b43a-509d-2adb-f3154579702f@mti-systems.com> Date: Fri, 21 Jun 2019 15:40:14 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0C4A0F80AE2FCA1772A70836" Content-Language: en-US Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-13.txt 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, 21 Jun 2019 19:40:27 -0000 This is a multi-part message in MIME format. --------------0C4A0F80AE2FCA1772A70836 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks Greg, I've made all 3 changes suggested below in my working copy. On 6/14/2019 12:37 AM, Greg Skinner wrote: > I found a few items while referring to this draft.  I hope the > feedback will be useful. > > §3.4: > > In the sentence "The principle reason for the three-way handshake is > to prevent old duplicate connection initiations from causing > confusion.†I believe the correct spelling should be “principalâ€, > because it is being used as an adjective.  (More information is > available from the definition of principal at wordreference.com > .) > > §3.8.6: > > The phrase “robustness principle†is used, but not cited.  While most > readers of the draft probably know what it is, others may not.  IMO, a > citation would be helpful, either from references already in the draft > (RFCs 791, 793), or others such as RFC 1958, §3. > §7: > > s/alphebetically/alphabetically/ > > BR, Greg > >> On Jun 3, 2019, at 6:25 PM, internet-drafts@ietf.org >> wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the TCP Maintenance and Minor Extensions >> WG of the IETF. >> >>        Title           : Transmission Control Protocol Specification >>        Author          : Wesley M. Eddy >> Filename        : draft-ietf-tcpm-rfc793bis-13.txt >> Pages           : 104 >> Date            : 2019-06-03 >> >> Abstract: >>   This document specifies the Internet's Transmission Control Protocol >>   (TCP).  TCP is an important transport layer protocol in the Internet >>   stack, and has continuously evolved over decades of use and growth of >>   the Internet.  Over this time, a number of changes have been made to >>   TCP as it was specified in RFC 793, though these have only been >>   documented in a piecemeal fashion.  This document collects and brings >>   those changes together with the protocol specification from RFC 793. >>   This document obsoletes RFC 793, as well as 879, 2873, 6093, 6429, >>   6528, and 6691 that updated parts of RFC 793.  It updates RFC 1122, >>   and should be considered as a replacement for the portions of that >>   document dealing with TCP requirements.  It updates RFC 5961 due to a >>   small clarification in reset handling while in the SYN-RECEIVED >>   state. >> >>   RFC EDITOR NOTE: If approved for publication as an RFC, this should >>   be marked additionally as "STD: 7" and replace RFC 793 in that role. >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-13 >> https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-13 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-13 >> >> >> 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/ >> >> > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------0C4A0F80AE2FCA1772A70836 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Thanks Greg, I've made all 3 changes suggested below in my working copy.


On 6/14/2019 12:37 AM, Greg Skinner wrote:
I found a few items while referring to this draft.  I hope the feedback will be useful.

§3.4:

In the sentence "The principle reason for the three-way handshake is to prevent old duplicate connection initiations from causing confusion.†I believe the correct spelling should be “principalâ€, because it is being used as an adjective.  (More information is available from the definition of principal at wordreference.com.) 

§3.8.6:

The phrase “robustness principle†is used, but not cited.  While most readers of the draft probably know what it is, others may not.  IMO, a citation would be helpful, either from references already in the draft (RFCs 791, 793), or others such as RFC 1958, §3.
 
§7:

s/alphebetically/alphabetically/

BR, Greg

On Jun 3, 2019, at 6:25 PM, internet-drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF.

       Title           : Transmission Control Protocol Specification
       Author          : Wesley M. Eddy
Filename        : draft-ietf-tcpm-rfc793bis-13.txt
Pages           : 104
Date            : 2019-06-03

Abstract:
  This document specifies the Internet's Transmission Control Protocol
  (TCP).  TCP is an important transport layer protocol in the Internet
  stack, and has continuously evolved over decades of use and growth of
  the Internet.  Over this time, a number of changes have been made to
  TCP as it was specified in RFC 793, though these have only been
  documented in a piecemeal fashion.  This document collects and brings
  those changes together with the protocol specification from RFC 793.
  This document obsoletes RFC 793, as well as 879, 2873, 6093, 6429,
  6528, and 6691 that updated parts of RFC 793.  It updates RFC 1122,
  and should be considered as a replacement for the portions of that
  document dealing with TCP requirements.  It updates RFC 5961 due to a
  small clarification in reset handling while in the SYN-RECEIVED
  state.

  RFC EDITOR NOTE: If approved for publication as an RFC, this should
  be marked additionally as "STD: 7" and replace RFC 793 in that role.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-13
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-13


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/




_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--------------0C4A0F80AE2FCA1772A70836-- From nobody Tue Jun 25 09:39:00 2019 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 DEC29120846; Tue, 25 Jun 2019 09:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 05YF4j2bACWl; Tue, 25 Jun 2019 09:38:57 -0700 (PDT) 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 C76BC120842; Tue, 25 Jun 2019 09:38:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id C430A25A14; Tue, 25 Jun 2019 18:38:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1561480734; bh=6zO3hUWWiZK20LZlgSUyHhwESqGt7rsHVCOrX6IUHlk=; h=From:To:CC:Subject:Date:From; b=uFTYy6b6wXdohBq1BOAVzp/o6TrY4LE58u1rDGbCqAwCOJcBKtcSQQJtxtjfD3r75 9pAe/IIDsvqAzDJbDeJZcRwSGHCdKlPhU/Rdct/lWIIpvM4zWQUzWAuqmKfLRuKs6U L6MWdeVHtWEx8mgdKJdLmp73R8zG4miRMZq0tsIg= 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 4GQQJ_vMobmt; Tue, 25 Jun 2019 18:38:54 +0200 (CEST) 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; Tue, 25 Jun 2019 18:38:54 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.38]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0415.000; Tue, 25 Jun 2019 18:38:53 +0200 From: "Scharf, Michael" To: "tcpm@ietf.org Extensions" CC: "tcpm-chairs@ietf.org" Thread-Topic: WGLC for draft-ietf-tcpm-converters-08 Thread-Index: AdUrckm1sQAV9Sf8TqW1iT6fsU2Dwg== Date: Tue, 25 Jun 2019 16:38:52 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D35AB8E@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.57.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] WGLC for draft-ietf-tcpm-converters-08 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, 25 Jun 2019 16:38:59 -0000 Hi all, draft-ietf-tcpm-converters has been discussed and reviewed quite a bit. Therefore, this e-mail starts a working group last call (WGLC) for draft-ie= tf-tcpm-converters-08 that will run until ***July 14, 2019***. Please let us know if there are any remaining open issues regarding this do= cument. Statements supporting publication are also welcome. In absence of f= eedback we will assume that the TCPM consensus is to move the document to t= he IESG. As discussed in the past, the intended status of the document is e= xperimental. Thanks a lot Michael (TCPM co-chair)=20 From nobody Tue Jun 25 23:36:06 2019 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 228C912022C; Tue, 25 Jun 2019 23:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 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_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuNCN3vaG63i; Tue, 25 Jun 2019 23:36:03 -0700 (PDT) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 D817E12016B; Tue, 25 Jun 2019 23:36:02 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x5Q6Vtjt034504; Tue, 25 Jun 2019 23:35:57 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=20180706; bh=ZrotzEr3msdZ7argMctajWvVjq91jcXKeViStTOFeKs=; b=q80xGiGmqAJdO+Eaay1u3iiW8ZwvDkP9mQkHP7lcckwJs2JfAoaKa/D2+NytYNZpslQo hX3EpCzUZE2xWXNPqu3ugE42+h1MMFsl6xMYig1j4G9RTG5bPZBlLC/izOPVpX8TNtjG Q0aPiEqG3Kv98ZzDFXpHjSkPhFIGykexWeFwj5WgHkUXLmt1M8ejExdImNzLbzousTP5 KL06BrLI0a9EN2ZlHJBgLeX+vgN7x5oLV65HBoq9aYh970CJyON+zka/l+xs8Ht1bp1U SoAXu6bA3/aDX9MSGyptbpNclKvpdHd/7X0DZAD8eLfNlW77IhjjdKyk0nXx8es55U+p rg== Received: from mr2-mtap-s01.rno.apple.com (mr2-mtap-s01.rno.apple.com [17.179.226.133]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2t9h0th7xs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 25 Jun 2019 23:35:57 -0700 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by mr2-mtap-s01.rno.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PTP00CLF0ZW1530@mr2-mtap-s01.rno.apple.com>; Tue, 25 Jun 2019 23:35:56 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PTP00G000YBRD00@nwk-mmpp-sz12.apple.com>; Tue, 25 Jun 2019 23:35:56 -0700 (PDT) X-Va-A: X-Va-T-CD: a5a5c5a748212a9211481a7ac32aaf74 X-Va-E-CD: 0689e333ab00510ac494074dfa5a6cfe X-Va-R-CD: 5c660c27528d0830921e32befcf2e127 X-Va-CD: 0 X-Va-ID: 1ad8910e-65d7-464a-b7a5-3fdb78ace453 X-V-A: X-V-T-CD: a5a5c5a748212a9211481a7ac32aaf74 X-V-E-CD: 0689e333ab00510ac494074dfa5a6cfe X-V-R-CD: 5c660c27528d0830921e32befcf2e127 X-V-CD: 0 X-V-ID: efd511b3-b9de-4f8f-b4fb-6f52bee0c8fb X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-06-26_03:,, signatures=0 Received: from localhost ([17.234.72.59]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PTP00AVM0ZWXQ20@nwk-mmpp-sz12.apple.com>; Tue, 25 Jun 2019 23:35:56 -0700 (PDT) Sender: cpaasch@apple.com Date: Tue, 25 Jun 2019 23:35:56 -0700 From: Christoph Paasch To: "Scharf, Michael" Cc: "tcpm@ietf.org Extensions" , "tcpm-chairs@ietf.org" Message-id: <20190626063556.GK5495@MacBook-Pro-64.local> References: <6EC6417807D9754DA64F3087E2E2E03E2D35AB8E@rznt8114.rznt.rzdir.fht-esslingen.de> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline In-reply-to: <6EC6417807D9754DA64F3087E2E2E03E2D35AB8E@rznt8114.rznt.rzdir.fht-esslingen.de> User-Agent: Mutt/1.11.4 (2019-03-13) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-26_02:, , signatures=0 Archived-At: Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-converters-08 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, 26 Jun 2019 06:36:05 -0000 Hello, On 25/06/19 - 16:38:52, Scharf, Michael wrote: > Hi all, > > draft-ietf-tcpm-converters has been discussed and reviewed quite a bit. > > Therefore, this e-mail starts a working group last call (WGLC) for draft-ietf-tcpm-converters-08 that will run until ***July 14, 2019***. > > Please let us know if there are any remaining open issues regarding this document. Statements supporting publication are also welcome. In absence of feedback we will assume that the TCPM consensus is to move the document to the IESG. As discussed in the past, the intended status of the document is experimental. I support this document. In cellular networks proxies are very common and won't go away for various reasons. Having a standardized way for proxying - with the goal of allowing extensibility - will bring some structure in this environment. Christoph From nobody Wed Jun 26 01:16:21 2019 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 0AE4D12011E; Wed, 26 Jun 2019 01:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GY8QzmP_i0rH; Wed, 26 Jun 2019 01:16:18 -0700 (PDT) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 21765120219; Wed, 26 Jun 2019 01:16:18 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id x5Q8CHo3000701; Wed, 26 Jun 2019 01:16:13 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : sender : from : message-id : content-type : subject : date : in-reply-to : cc : to : references; s=20180706; bh=61jktvmmU3feWdXwy60az1ypYN8hWmfIwkWhds/NdIw=; b=T9ONvjHdvCKHxeZKe9490s+pD0K23Hl9V6AkMg4ZfpfIEs9TuC58+AdZEMNGhNk0GctA YzlSIEWY3rIC8xT6DADVl8WAHT6K8B9TBShhsukND4sTurN3R+MG1gJwNqeKkm4wPRBD 1Kzt1C9JhLNfBQaKLTziTq1LES7W4tHPteBY414eXpS6z6Fo5hPEHew8Pw6RuGgZWpwA MBMD9xlWwFLWUWk9J/MI1QggBhNDkGxSfsXG0UNsH8qs6hnEVGzI7utgv+unHUhcv7CS LY8ti26xwJtOXrBerKEJNHcLgihV7zWynVNO4wnam5b9d86Ig1Kd3BMdzkwczJN+Ja3B TQ== Received: from cistus.asia.apple.com (cistus.asia.apple.com [17.84.80.83]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2t9kb8f03w-11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 26 Jun 2019 01:16:13 -0700 MIME-version: 1.0 Received: from sng-mmpp-sz02.asia.apple.com (sng-mmpp-sz02.asia.apple.com [17.84.80.27]) by cistus.asia.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PTP00J885MXZT00@cistus.asia.apple.com>; Wed, 26 Jun 2019 16:16:09 +0800 (+08) Received: from process_milters-daemon.sng-mmpp-sz02.asia.apple.com by sng-mmpp-sz02.asia.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PTP00M004ZEDK00@sng-mmpp-sz02.asia.apple.com>; Wed, 26 Jun 2019 16:16:09 +0800 (+08) X-Va-A: X-Va-T-CD: a5a5c5a748212a9211481a7ac32aaf74 X-Va-E-CD: ccbbdba3356014f2780f871a428842f6 X-Va-R-CD: 99f478189850bdc6e25c38349ff91258 X-Va-CD: 0 X-Va-ID: a076e0b4-a244-4c41-91f5-1e28f44dc10b X-V-A: X-V-T-CD: a5a5c5a748212a9211481a7ac32aaf74 X-V-E-CD: ccbbdba3356014f2780f871a428842f6 X-V-R-CD: 99f478189850bdc6e25c38349ff91258 X-V-CD: 0 X-V-ID: 79c963d7-fca1-4455-bd5e-c703ebe2849e X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-06-26_04:,, signatures=0 Received: from [17.235.132.128] (unknown [17.235.132.128]) by sng-mmpp-sz02.asia.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PTP008PW5MKUF50@sng-mmpp-sz02.asia.apple.com>; Wed, 26 Jun 2019 16:16:00 +0800 (+08) Sender: adi@apple.com From: Adi Masputra Message-id: Content-type: multipart/signed; boundary="Apple-Mail=_8EFF125B-312B-4F1F-BC18-071A4F9CA0B7"; protocol="application/pkcs7-signature"; micalg=sha-256 Date: Wed, 26 Jun 2019 17:15:56 +0900 In-reply-to: <6EC6417807D9754DA64F3087E2E2E03E2D35AB8E@rznt8114.rznt.rzdir.fht-esslingen.de> Cc: adi masputra , Krisztian Kiss , "tcpm@ietf.org Extensions" , "tcpm-chairs@ietf.org" To: "Scharf, Michael" References: <6EC6417807D9754DA64F3087E2E2E03E2D35AB8E@rznt8114.rznt.rzdir.fht-esslingen.de> X-Mailer: Apple Mail (2.3445.104.11) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-26_04:, , signatures=0 X-Proofpoint-AD-Result: pass Archived-At: Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-converters-08 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, 26 Jun 2019 08:16:20 -0000 --Apple-Mail=_8EFF125B-312B-4F1F-BC18-071A4F9CA0B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I support this document. Adi > On Jun 26, 2019, at 01:38, Scharf, Michael = wrote: >=20 > Hi all, >=20 > draft-ietf-tcpm-converters has been discussed and reviewed quite a = bit. >=20 > Therefore, this e-mail starts a working group last call (WGLC) for = draft-ietf-tcpm-converters-08 that will run until ***July 14, 2019***. >=20 > Please let us know if there are any remaining open issues regarding = this document. Statements supporting publication are also welcome. In = absence of feedback we will assume that the TCPM consensus is to move = the document to the IESG. As discussed in the past, the intended status = of the document is experimental. >=20 > Thanks a lot >=20 > Michael > (TCPM co-chair)=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_8EFF125B-312B-4F1F-BC18-071A4F9CA0B7 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCf0w ggRAMIIDKKADAgECAgMCOnUwDQYJKoZIhvcNAQELBQAwQjELMAkGA1UEBhMCVVMxFjAUBgNVBAoT DUdlb1RydXN0IEluYy4xGzAZBgNVBAMTEkdlb1RydXN0IEdsb2JhbCBDQTAeFw0xNDA2MTYxNTQy NDNaFw0yMjA1MjAxNTQyNDNaMGIxHDAaBgNVBAMTE0FwcGxlIElTVCBDQSA1IC0gRzExIDAeBgNV BAsTF0NlcnRpZmljYXRpb24gQXV0aG9yaXR5MRMwEQYDVQQKEwpBcHBsZSBJbmMuMQswCQYDVQQG EwJVUzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAPCKCLosE1xa8Zj9MVlmwlZ6fkAq TJTJaLazI71gGzvn/T1dcCbFOqqwymlkC2I+SelMBSG+NPSqcyETMYTozu84z1fp28vO0W36yIGS LSLOFX5+sQesiMcYksGWxgyQJhdVXxkbJc+eUTT68+exHHgY2uQ5GpEbwt+oAFtfTsQitLpk4kp3 uu0s6/6LYZbwHoQtdAp7F83D7gBu12Z5i1DpT6+mPZExL8qHK8/3CEkUio5ifa1WqpVi4+lrTmRB 4k8i90tW8SyocRE4CYuXuQi/zzAmg0CQYxq2abp5t65Z7GsNhEenrgtHTAb7doJpe14jYFI10KxG HOqgtlqL2e0CAwEAAaOCAR0wggEZMB8GA1UdIwQYMBaAFMB6mGiNifurBWQMEX2qfWW4ysxOMB0G A1UdDgQWBBRWM5AvnfTSMNANYiUTeB0hp1ESDzASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBBjA1BgNVHR8ELjAsMCqgKKAmhiRodHRwOi8vZy5zeW1jYi5jb20vY3Jscy9ndGdsb2Jh bC5jcmwwLgYIKwYBBQUHAQEEIjAgMB4GCCsGAQUFBzABhhJodHRwOi8vZy5zeW1jZC5jb20wTAYD VR0gBEUwQzBBBgpghkgBhvhFAQc2MDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly93d3cuZ2VvdHJ1c3Qu Y29tL3Jlc291cmNlcy9jcHMwDQYJKoZIhvcNAQELBQADggEBAJj6vyN+UNrcbZlal2HjomcAdSOY r5+tITWoeIujrxw6HkDghDlqhNXUqJ/+vbIHdnRQsL9qABn0vdL2VX2TDBTNE+zFMWa09FBQcd7e /M4zn/7lFKUXTBCk2Tp+pOfgvVN//eqMgFV8vJWoH8cwQRuS+NflQrlx1ylwRFVC1XcStYCtVV/D W5PAW9aXx40xSbcwiDPYxlAXwbCUDIjjMyitMAQFbdwjzXZPHNC0F3oEQguz2+Q7vn5t5eFgkX4k 0d9uwMmXJhcD2exbUV+NKMkOJZZcmAEQGWsXWnKF8FpwEFlKQ4WibPgtmEzr4yBz6RLqA2oGs71B yhxX3x/1xDcwggW1MIIEnaADAgECAhAm2t57xfMy+ninm822kUCLMA0GCSqGSIb3DQEBCwUAMGIx HDAaBgNVBAMTE0FwcGxlIElTVCBDQSA1IC0gRzExIDAeBgNVBAsTF0NlcnRpZmljYXRpb24gQXV0 aG9yaXR5MRMwEQYDVQQKEwpBcHBsZSBJbmMuMQswCQYDVQQGEwJVUzAeFw0xOTA0MjYyMjA3MTha Fw0yMTA1MjUyMjA3MThaME8xFjAUBgNVBAMMDWFkaUBhcHBsZS5jb20xEzARBgNVBAoMCkFwcGxl IEluYy4xEzARBgNVBAgMCkNhbGlmb3JuaWExCzAJBgNVBAYTAlVTMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEApdoDlDyE12vDw5pXeO3E7M6kV5CTpmwo/0MNe3oVwVDCD3wJYG1Qrao/ am1dQbX5hIT01L6uPtoJ9H5pkNPOvgEQbIltrAfQgYjtGpRKkI9XKdR+2wZlot+upuutgUboOOSU zeLeber2lbcShqM5EFuT1EwSjDClaouH2O3tpHa6gSwWQEa4qqVY6SZW+POMeyVU3fAwCSOFksLQ LLlVjLPKgaUymZfxnmY5Io4VVHubUs22Bj8e2E/A7+k85l66jOtCpQxBpnzle4mIwuqXQ1fjryPb GXsjnJPN8dnbFroZr8f2ZjH0ejz4ebSn/TFZE86Pwsls0buHgzP+b4na7wIDAQABo4ICeDCCAnQw DAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBRWM5AvnfTSMNANYiUTeB0hp1ESDzB+BggrBgEFBQcB AQRyMHAwNAYIKwYBBQUHMAKGKGh0dHA6Ly9jZXJ0cy5hcHBsZS5jb20vYXBwbGVpc3RjYTVnMS5k ZXIwOAYIKwYBBQUHMAGGLGh0dHA6Ly9vY3NwLmFwcGxlLmNvbS9vY3NwMDMtYXBwbGVpc3RjYTVn MTAxMBgGA1UdEQQRMA+BDWFkaUBhcHBsZS5jb20wggEqBgNVHSAEggEhMIIBHTCCARkGCyqGSIb3 Y2QFCwUBMIIBCDCBygYIKwYBBQUHAgIwgb0MgbpSZWxpYW5jZSBvbiB0aGlzIGNlcnRpZmljYXRl IGFzc3VtZXMgYWNjZXB0YW5jZSBvZiBhbnkgYXBwbGljYWJsZSB0ZXJtcyBvZiB1c2UgYW5kIGNl cnRpZmljYXRpb24gcHJhY3RpY2Ugc3RhdGVtZW50cy4gVGhpcyBjZXJ0aWZpY2F0ZSBzaGFsbCBu b3Qgc2VydmUgYXMsIG9yIHJlcGxhY2UgYSB3cml0dGVuIHNpZ25hdHVyZS4wOQYIKwYBBQUHAgEW LWh0dHA6Ly93d3cuYXBwbGUuY29tL2NlcnRpZmljYXRlYXV0aG9yaXR5L3JwYTATBgNVHSUEDDAK BggrBgEFBQcDBDA3BgNVHR8EMDAuMCygKqAohiZodHRwOi8vY3JsLmFwcGxlLmNvbS9hcHBsZWlz dGNhNWcxLmNybDAdBgNVHQ4EFgQUg+iqPCua3BX6Wp2Tze7Hq0/PPv4wDgYDVR0PAQH/BAQDAgWg MA0GCSqGSIb3DQEBCwUAA4IBAQBHXu5hml9yxHaM4OkV+JCrZ7/M7zenW7+O+4IPO7CbG7oui52F NSyGdxem1uJ8I3jV4Ngf1os3Pw4t6P2RYgfUtDKYl8stuj+tIF8LsZq/9ebBi7TXv7C5XaRacu1C I7Vik/U7veo4LVHkifiDm2QzGEwqzMRMQfWfndBSzM5yTQv5zPJalcv8qOo868wABjGah/uGO9IL 9BsP0tbreGSNVGNAIuf91VO4P56ymnQA1e0ca0RgKH3fqhJOrZKlrEJVdtrSA3yzy9Fdw3sTBELw 9vlglu3Io8a74n2Rnd4nlni6KM+ymPWJuqUgD2ainXVk2F2hDPdy9/vX2zzQQI5EMYIDIDCCAxwC AQEwdjBiMRwwGgYDVQQDExNBcHBsZSBJU1QgQ0EgNSAtIEcxMSAwHgYDVQQLExdDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTETMBEGA1UEChMKQXBwbGUgSW5jLjELMAkGA1UEBhMCVVMCECba3nvF8zL6 eKebzbaRQIswDQYJYIZIAWUDBAIBBQCgggF7MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTE5MDYyNjA4MTU1NlowLwYJKoZIhvcNAQkEMSIEIANaZ32+1GhiQZJqZ5sH o+RmFDLqDjIq1/cuI3DZVxNuMIGFBgkrBgEEAYI3EAQxeDB2MGIxHDAaBgNVBAMTE0FwcGxlIElT VCBDQSA1IC0gRzExIDAeBgNVBAsTF0NlcnRpZmljYXRpb24gQXV0aG9yaXR5MRMwEQYDVQQKEwpB cHBsZSBJbmMuMQswCQYDVQQGEwJVUwIQJtree8XzMvp4p5vNtpFAizCBhwYLKoZIhvcNAQkQAgsx eKB2MGIxHDAaBgNVBAMTE0FwcGxlIElTVCBDQSA1IC0gRzExIDAeBgNVBAsTF0NlcnRpZmljYXRp b24gQXV0aG9yaXR5MRMwEQYDVQQKEwpBcHBsZSBJbmMuMQswCQYDVQQGEwJVUwIQJtree8XzMvp4 p5vNtpFAizANBgkqhkiG9w0BAQEFAASCAQAdUd4vewQ1lhkg2pn51G/mxrpiI7eIYmadw7HlxsK0 ndklgNvjigl8Yw/NDf4HzP1NKKSxbx0miXyH4JOE7R0RtGvXxfxudAeMm7PbFfzoYyrG/w5AGr4T bvhX54d9y+ANKVRmubihH0gYz95dTYvU09HabonZ9xhSR3EHLbi1ONsyJtadQ0CduT9o0Tgl2zs9 gKUUDpkKtgur3WlwyR4ovYMKn53YE6BrIi2yg3mGjBycyr5g1p79sHsac4v+/P2h/XCbvg4eWVaV ZLTcFux+ioV0PMPHKDUQT1BUfa2n6jjkNjXa5d0iXSdmZ+rB066l9An2KGtYVUctuRXqOVyYAAAA AAAA --Apple-Mail=_8EFF125B-312B-4F1F-BC18-071A4F9CA0B7-- From nobody Wed Jun 26 02:01:15 2019 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 10C2F12022E for ; Wed, 26 Jun 2019 02:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_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 (1024-bit key) header.d=broadcom.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 QQa3q5lobL35 for ; Wed, 26 Jun 2019 02:01:11 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 3613A120170 for ; Wed, 26 Jun 2019 02:01:11 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id k20so3295791ios.10 for ; Wed, 26 Jun 2019 02:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ng/PwfkdKIgEbCm02ilM0hmzLebyG7sVdYpYqdyOu1w=; b=AIjnTaJOv2N6IZvxlhskWanW8pVQppIEqEqNiV3DV0t6I+BtdOGBQyeAM1FyDjOgsC v4zkJt3dEOXgGQ7NFayI0Fi6PPTL4IBSrxab0Elh2iskoCOLz5eAIA4PjCFZVJKIUKfB mzypzlWE8VORFp+X8pDfHcvr52Iq8eXisVD90= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ng/PwfkdKIgEbCm02ilM0hmzLebyG7sVdYpYqdyOu1w=; b=gGIeEUK0hvvWznHTi8qseSqaU8iGiMKsOXMIlQbQjSZ0K5z0iNOBVTiouFCBNEOqIF 14voFF10GSBt/Iwowrv2PPQzXDWOcTstCLJUSj+NqhKy8fqKihkH/ouMmfu2sxqUVvIr ip5ll1vNu+f6xFlfwcHY7hGrC2Vr4OajzXkvjxq97bL6lorhh5H/6YdBaalHEiZ3fJLN g1j/jkBlyG37oId4wgKugV3A0zbSmbv2U7eDoid6ly8p6NspNBWWvzDt4OUp3J3+i6LD /9l5Xeu6knqVkeY04QWVw8C1pSui6VH3vHjqBDoJ1F63bn969OmP+2v2+ZSmpHWswapw 9fGw== X-Gm-Message-State: APjAAAVq6vzFkErhKyv5wGXsi8uXVIgDQIMqCZQgPuSKIsCYdpRhnnpK 5h1Rjj6sJRbBLBIqpLJuDyDxEw== X-Google-Smtp-Source: APXvYqzv/8TDR0luteezUl3zj8EkeJViTFWkF4hYjuH/cJUxeFX3zXG7KVQDqmlNaWmGPeZH6rnghQ== X-Received: by 2002:a6b:cb07:: with SMTP id b7mr3640841iog.7.1561539670480; Wed, 26 Jun 2019 02:01:10 -0700 (PDT) Received: from [21.110.153.121] (ip-99-203-143-71.pools.cgn.spcsdns.net. [99.203.143.71]) by smtp.gmail.com with ESMTPSA id d17sm19053660iom.28.2019.06.26.02.01.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Jun 2019 02:01:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Florin Baboescu X-Mailer: iPhone Mail (16F203) In-Reply-To: Date: Wed, 26 Jun 2019 18:01:07 +0900 Cc: "Scharf, Michael" , "tcpm@ietf.org Extensions" , Krisztian Kiss , "tcpm-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <6EC6417807D9754DA64F3087E2E2E03E2D35AB8E@rznt8114.rznt.rzdir.fht-esslingen.de> To: Adi Masputra Archived-At: Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-converters-08 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, 26 Jun 2019 09:01:14 -0000 Dear all, I support this document. - Florin=20 > On Jun 26, 2019, at 5:15 PM, Adi Masputra wrote: >=20 > I support this document. >=20 > Adi >=20 >> On Jun 26, 2019, at 01:38, Scharf, Michael wrote: >>=20 >> Hi all, >>=20 >> draft-ietf-tcpm-converters has been discussed and reviewed quite a bit. >>=20 >> Therefore, this e-mail starts a working group last call (WGLC) for draft-= ietf-tcpm-converters-08 that will run until ***July 14, 2019***. >>=20 >> Please let us know if there are any remaining open issues regarding this d= ocument. Statements supporting publication are also welcome. In absence of f= eedback we will assume that the TCPM consensus is to move the document to th= e IESG. As discussed in the past, the intended status of the document is exp= erimental. >>=20 >> Thanks a lot >>=20 >> Michael >> (TCPM co-chair)=20 >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 From nobody Thu Jun 27 08:58:10 2019 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 23AF812013D; Thu, 27 Jun 2019 08:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=bt.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 8tV81kdU4QFl; Thu, 27 Jun 2019 08:58:05 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [213.121.35.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A0BC12004D; Thu, 27 Jun 2019 08:58:04 -0700 (PDT) Received: from tpw09926dag10e.domain1.systemhost.net (10.9.202.37) by BWP09926079.bt.com (10.36.82.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Thu, 27 Jun 2019 16:58:02 +0100 Received: from tpw09926dag13g.domain1.systemhost.net (10.9.212.29) by tpw09926dag10e.domain1.systemhost.net (10.9.202.37) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 27 Jun 2019 16:58:02 +0100 Received: from bwp09926076.bt.com (10.36.82.107) by tpw09926dag13g.domain1.systemhost.net (10.9.212.29) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 27 Jun 2019 16:58:02 +0100 Received: from GBR01-CWL-obe.outbound.protection.outlook.com (104.47.20.54) by smtpe1.intersmtp.com (10.36.82.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Thu, 27 Jun 2019 16:57:49 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bt.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r+/ejBaX16GdV/WLC7roFWwFZQbPu0GM+sWbr9gYqT0=; b=XqSykpvONtChtR1R/pqvB4Y1v35pB6qE+1GgNUzwTwqqi1psPLCAsN3ggTCDKZHynNpt7UxITJB2Arn05zD5fdQ2pthfoymStKrGBZwF05XOhi9Dbdouz4Ylb0pIZRDp2k0cRl5IW9gpWv3FooEZNaPjk/0D+NtbW9NR2+3Qbd0= Received: from LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM (20.179.128.78) by LNXP123MB1994.GBRP123.PROD.OUTLOOK.COM (20.179.128.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Thu, 27 Jun 2019 15:58:01 +0000 Received: from LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM ([fe80::10d8:71fc:f4d3:8074]) by LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM ([fe80::10d8:71fc:f4d3:8074%7]) with mapi id 15.20.2008.014; Thu, 27 Jun 2019 15:58:01 +0000 From: To: , CC: Thread-Topic: WGLC for draft-ietf-tcpm-converters-08 Thread-Index: AdUrckm1sQAV9Sf8TqW1iT6fsU2DwgBZdsDw Date: Thu, 27 Jun 2019 15:58:01 +0000 Message-ID: References: <6EC6417807D9754DA64F3087E2E2E03E2D35AB8E@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D35AB8E@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=philip.eardley@bt.com; x-originating-ip: [193.113.37.9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6813bf8d-6032-4677-41d5-08d6fb183b51 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LNXP123MB1994; x-ms-traffictypediagnostic: LNXP123MB1994: x-ms-exchange-purlcount: 2 x-antispam-2: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 008184426E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(396003)(376002)(346002)(366004)(136003)(39860400002)(13464003)(53754006)(189003)(199004)(54534003)(305945005)(99286004)(7736002)(2906002)(6246003)(14444005)(11346002)(486006)(256004)(476003)(8676002)(966005)(14454004)(55016002)(316002)(64756008)(52536014)(68736007)(6116002)(3846002)(4326008)(446003)(478600001)(5660300002)(66556008)(25786009)(110136005)(9686003)(6306002)(73956011)(66446008)(66476007)(66946007)(74316002)(53936002)(6436002)(6506007)(26005)(66574012)(76176011)(66066001)(81156014)(229853002)(8936002)(102836004)(71200400001)(7696005)(53546011)(186003)(71190400001)(81166006)(86362001)(33656002)(76116006)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:LNXP123MB1994; H:LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: YnAMjQ4Ohj43DWN30mEPDW14e2agGRsliDfJaEyvSQJrMcH6P7n2uthbQdsFL1qaJqOB7A9mQRPhDJsiXOzDzuTSs3kd7dPdhTEmHgf0g/mT+ZNe//91Pe7J9F4Gc9bxhSe97ax9mrInUxJzwjoHVrKfhxkxCC01e1bSHJHxuR9Vjz3sb0fMydFlm/eWWLCKgVeSzzKHjAq37QJtzy0wGK9kLp8S03aoVFyTnY4tSIYW3NfMD5fDQwBjHJMw2eK2IWOiRKmdnuRN16Kk+sdhGkL6djY/swBrZ2ooV93j7PHjFKHnrYzt//sWGtJhPo72wei1FPxjnTFA8eAT0FalXZDpufqiZGV5VWVcRjXqZZpQpPw60A2ueK/L88GpcHNu9uOerzE2p4Us50xxr+uCGltC21UiMRZY4/ga60JZ7b4= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6813bf8d-6032-4677-41d5-08d6fb183b51 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2019 15:58:01.1662 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: philip.eardley@bt.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: LNXP123MB1994 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Report: 4 Rules triggered * 0.1 -- THREAD_INDX_INVALD_VAL * 0 -- EDT_SDHA_ADR_FRG * 0 -- EDT_SDHA_DMN_FRG * 0 -- RV6578 X-NAI-Spam-Version: 2.2.0.9309 : core <6578> : inlines <7111> : streams <1825718> : uri <2860983> X-OriginatorOrg: bt.com Archived-At: Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-converters-08 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, 27 Jun 2019 15:58:09 -0000 I support this document. Thanks to the authors for the nice work.=20 Here are some comments /questions and suggested clarifications. Questions: Section 4.1 " The Client and the Transport Converter MUST send the fixed-sized header, shown in Figure 9, as the first four bytes of the bytestream." Are there any other protocols that claim rights on the first bytes of the b= ytestream? Even in the context of signalling as indicated by the port# (to = be assigned), is this certain? " Data added by the Convert protocol to the TCP bytestream in the upstream connection is unambiguously distinguished from payload data in the downstream connection by the Total Length field in the Convert messages." Is it required that the Convert data is at a fixed point in the bytestream?= Think you've assumed it's at the start? (Also, I think you could delete 'upstream' and 'downstream' in the quoted s= entence - in any case, presumably they should both be one or the other) Convert protocol: How do the messages with the Supported TCP Extensions TLV and Connect TLV r= elate to each other? Is it required to learn through the "Supported TCP Ext= ensions" that a Converter supports a particular TCP option before sending a= Connect with that Option? I assume not - and that it's just a MAY to send = the Supported TCP Extensions - as it seems to me like an optimisation and n= ot too much harm happens if you send a Connect for an unsupported extension= .=20 -------------- Suggested clarifications - significant:- I think it would be great if Section 3 was expanded into a "protocol model"= https://tools.ietf.org/html/rfc4101 in particular to expand on << 2. What messages are being transmitted and what do they mean?>> - figu= res show the basic msg exchanges (info, connect, extended, supported, cooki= e and error) << 3. What are the important, but unobvious, features of the protocol?>> = eg use of assigned port# ; use of first bytes of bytestream ;etc. I think you could distinguish more carefully between: the initiator of the = TCP convert protocol and the other 'legacy' end point versus the end device= downstream on a broadband line and the server upstream in the internet. Th= e language of the doc basically assumes that a "Client" fulfils both the fi= rst roles and a "Server" fulfils both the last roles, but this needs not al= ways be the case. I realised this reading Section 4.2.8, but I suspect it's= true in many other places.=20 ---------------- Suggested clarifications - other:- Section 1: Para " There are some situations..." I think you could slightly adjust the = mention of PEPs. For example, a PEP that re-spaces TCP ACKs doesn't have an= ything to do with the problem mentioned in the first part of the para (abou= t the difficulty of ensuring both clients and servers are upgraded) Para " More recently, experimentation" I found the first sentence hard to p= arse. The para seems to use latency to refer to two things (without pointin= g this out): packet forwarding latency and set-up signalling latency List of bullets about what a transport converter achieves. I 'd add one to = say it achieves 0-RTT - and to explain what 0-RTT means (quite a bit later = before the reader discovers this) (and expand the RTT abbreviation) Section 3: Figure 2: explain "R" " Further, the architecture allows for making use of new TCP extensions even if those are not supported by a given server." I find the sentence a bit awkward. Maybe: Further, the architecture enables= the use of new TCP extensions between the client and Transport Converter w= hen they are not supported by a server. Figure 3: I didn't understand why the note is needed "* TLS messages exhang= ed between the Client and the Server are not shown." Para under figure 3: This mentions Connect TLVs, which is a mystery concept= at this stage.=20 Section 1 mostly says TCP extensions, with an occasional TCP options. Be co= nsistent? Section 3.2: Figure 5: in the figure title there's "(1)" - what does this mean or is it = a typo? Para " A Transport Converter MAY operate" "external address" - what does 'external' mean? Section 4 Should there be a new Section 4.1 that explains the use of port # (to be as= signed) to identify Convert protocol messages? S4.1 title "fixed header" - is "fixed" needed? Figure 10: I think the first "(optional)" should be deleted (ie in bytes 3 & 4) " In general zero padding MUST be added if the value's length in bytes can not be expressed as 2+(4 * n)." better, something like: If necessary, Value MUST be padded with zeroes so t= hat the length of the TLV is a multiple of 32 bits. " As a general rule, when an error is encountered an Error TLV with the appropriate error code MUST be returned by the Transport Converter." 'As a general rule' seems to conflict with 'MUST' " Transport Converter SHOULD include in this list the TCP options that it accepts from Clients and that it includes the SYN packets that it sends to initiate connections." I couldn't parse the second part of the sentence ("and that it...") " The list of Supported TCP Extension is padded with 0 to end on a 32 bits boundary." Replace: The list of Supported TCP Extensions MUST be padded with 0 to end = on a 32 bits boundary. Section 6 This section actually only discusses one type of middlebox (removes SYN). C= an the discussion be widened slightly - or maybe simply say that if middleb= ox interference detected, then MUST stop using the Converter (with SYN remo= val given as an example)? Not yet read Section 7 onwards, comments to follow. Section 10 Change log There's lots of really useful info about why the design is as it is (eg the= use of TLV rather than Options). It would be a shame if this was lost from= the rfc - please can info be extracted into a section "how implementation = experiences have influenced design decisions" or similar? Thanks phil -----Original Message----- From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael Sent: 25 June 2019 17:39 To: tcpm@ietf.org Extensions Cc: tcpm-chairs@ietf.org Subject: [tcpm] WGLC for draft-ietf-tcpm-converters-08 Hi all, draft-ietf-tcpm-converters has been discussed and reviewed quite a bit. Therefore, this e-mail starts a working group last call (WGLC) for draft-ie= tf-tcpm-converters-08 that will run until ***July 14, 2019***. Please let us know if there are any remaining open issues regarding this do= cument. Statements supporting publication are also welcome. In absence of f= eedback we will assume that the TCPM consensus is to move the document to t= he IESG. As discussed in the past, the intended status of the document is e= xperimental. Thanks a lot Michael (TCPM co-chair)=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Jun 28 01:15:25 2019 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 2846D120041; Fri, 28 Jun 2019 01:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vSj8sk-06rj3; Fri, 28 Jun 2019 01:15:19 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93D6012016F; Fri, 28 Jun 2019 01:15:19 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 45ZqM972kvz8yYv; Fri, 28 Jun 2019 10:15:17 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.98]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 45ZqM95tw5zCqkR; Fri, 28 Jun 2019 10:15:17 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7F.corporate.adroot.infra.ftgroup ([fe80::d9:d3cd:85bd:d331%21]) with mapi id 14.03.0439.000; Fri, 28 Jun 2019 10:15:17 +0200 From: To: "philip.eardley@bt.com" , "Michael.Scharf@hs-esslingen.de" , "tcpm@ietf.org" CC: "tcpm-chairs@ietf.org" Thread-Topic: WGLC for draft-ietf-tcpm-converters-08 Thread-Index: AdUrckm1sQAV9Sf8TqW1iT6fsU2DwgBZdsDwACioYfA= Date: Fri, 28 Jun 2019 08:15:16 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EAAF3AA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <6EC6417807D9754DA64F3087E2E2E03E2D35AB8E@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-converters-08 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, 28 Jun 2019 08:15:22 -0000 Hi Phil, Thank you for the review. Much appreciated. Changes to address almost all your comments (except the protocol model one)= can be seen at: https://github.com/obonaventure/draft-tcp-converters/pull/62/files=20 Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de > philip.eardley@bt.com > Envoy=E9=A0: jeudi 27 juin 2019 17:58 > =C0=A0: Michael.Scharf@hs-esslingen.de; tcpm@ietf.org > Cc=A0: tcpm-chairs@ietf.org > Objet=A0: Re: [tcpm] WGLC for draft-ietf-tcpm-converters-08 >=20 > I support this document. Thanks to the authors for the nice work. >=20 > Here are some comments /questions and suggested clarifications. >=20 > Questions: > Section 4.1 > " The Client and the Transport Converter MUST send the fixed-sized > header, shown in Figure 9, as the first four bytes of the bytestream." > Are there any other protocols that claim rights on the first bytes of the > bytestream? Even in the context of signalling as indicated by the port# > (to be assigned), is this certain? [Med] I'm not aware of any. The point here is to unambiguously identify Con= vert data.=20 >=20 > " Data added by the Convert protocol to the TCP bytestream in the > upstream connection is unambiguously distinguished from payload data > in the downstream connection by the Total Length field in the Convert > messages." > Is it required that the Convert data is at a fixed point in the > bytestream? Think you've assumed it's at the start? [Med] Yes, we assume that Convert data is at the start.=20 > (Also, I think you could delete 'upstream' and 'downstream' in the quoted > sentence - in any case, presumably they should both be one or the other) >=20 [Med] Fixed.=20 > Convert protocol: > How do the messages with the Supported TCP Extensions TLV and Connect TLV > relate to each other? Is it required to learn through the "Supported TCP > Extensions" that a Converter supports a particular TCP option before > sending a Connect with that Option? I assume not - and that it's just a > MAY to send the Supported TCP Extensions - as it seems to me like an > optimisation and not too much harm happens if you send a Connect for an > unsupported extension. [Med] Yes, this is optional. The expected behavior is covered by this text:= =20 The Info TLV (Figure 12) is an optional TLV which can be sent by a Client to request the TCP extensions that are supported by a Transport Converter. It is typically sent on the first connection = =20 that a Client establishes with a Transport Converter to learn its capabilities. Assuming a Client is entitled to invoke the Transport Converter, the latter replies with the Supported TCP Extensions TLV described in Section 4.2.4. >=20 > -------------- > Suggested clarifications - significant:- >=20 [Med] Snipped. Will cover this one in a separate message > ---------------- > Suggested clarifications - other:- > Section 1: >=20 > Para " There are some situations..." I think you could slightly adjust th= e > mention of PEPs. For example, a PEP that re-spaces TCP ACKs doesn't have > anything to do with the problem mentioned in the first part of the para > (about the difficulty of ensuring both clients and servers are upgraded) [Med] What about updating it as follows:=20 OLD: Performance Enhancing Proxies [RFC3135], and other service functions have been deployed as solutions to improve TCP performance over links with specific characteristics. NEW: Some assistance from the network to make use of these features=20 is valuable. For example, Performance Enhancing Proxies [RFC3135],=20 and other service functions have been deployed as solutions=20 to improve TCP performance over links with specific characteristics. >=20 > Para " More recently, experimentation" I found the first sentence hard to > parse.=20 [Med] Will reword.=20 The para seems to use latency to refer to two things (without > pointing this out): packet forwarding latency and set-up signalling > latency >=20 > List of bullets about what a transport converter achieves. I 'd add one t= o > say it achieves 0-RTT - and to explain what 0-RTT means (quite a bit late= r > before the reader discovers this) (and expand the RTT abbreviation) >=20 [Med] Good point. This will be introduced before that bullet list since tha= t list is built in reference to RFC1919. > Section 3: > Figure 2: explain "R" [Med] Fixed. This refers to "router". >=20 > " Further, the architecture allows for making use of new TCP extensions > even if those are not supported by a given server." > I find the sentence a bit awkward. Maybe: Further, the architecture > enables the use of new TCP extensions between the client and Transport > Converter when they are not supported by a server. [Med] What about the following:=20 Furthermore, the architecture enables the use of=20 new TCP extensions by the clients even if those are=20 not supported by a given server. This is achieved=20 owing to the assistance of a Transport Converter. >=20 > Figure 3: I didn't understand why the note is needed "* TLS messages > exhanged between the Client and the Server are not shown." [Med] This is to make it clear that the TLS connection is handled directly = between the client and the server. The converter does not interfere with th= at.=20 >=20 > Para under figure 3: This mentions Connect TLVs, which is a mystery > concept at this stage. [Med] changes to "Convert messages". >=20 > Section 1 mostly says TCP extensions, with an occasional TCP options. Be > consistent? [Med] OK >=20 > Section 3.2: > Figure 5: in the figure title there's "(1)" - what does this mean or is i= t > a typo? [Med] Fixed. We used to have two figures with the same title (1) and (2). >=20 > Para " A Transport Converter MAY operate" > "external address" - what does 'external' mean? [Med] Changed to "source".=20 "external" was used in reference to the source address of a packet as relay= ed by a converter. This is further discussed in 3.4. >=20 > Section 4 > Should there be a new Section 4.1 that explains the use of port # (to be > assigned) to identify Convert protocol messages? [Med] Fixed.=20 >=20 > S4.1 title > "fixed header" - is "fixed" needed? [Med] It is fixed because it is present in all convert messages. Do you pre= fer "common" ? >=20 > Figure 10: > I think the first "(optional)" should be deleted (ie in bytes 3 & 4) [Med] Deleted the second one.=20 >=20 > " In general > zero padding MUST be added if the value's length in bytes can not be > expressed as 2+(4 * n)." > better, something like: If necessary, Value MUST be padded with zeroes so > that the length of the TLV is a multiple of 32 bits. >=20 [Med] That is better. Thanks.=20 > " As a general rule, when an error is encountered an Error TLV with the > appropriate error code MUST be returned by the Transport Converter." > 'As a general rule' seems to conflict with 'MUST' >=20 [Med] Fixed.=20 > " Transport Converter SHOULD include in this > list the TCP options that it accepts from Clients and that it > includes the SYN packets that it sends to initiate connections." > I couldn't parse the second part of the sentence ("and that it...") >=20 [Med] Changed to: " A Transport Converter SHOULD include in this list the TCP options that it accepts from Clients; these options are=20 included by the Transport Converter in the SYN packets that it sends to ini= tiate connections." Better?=20 > " The list of Supported TCP Extension is padded with 0 to end on a 32 > bits boundary." > Replace: The list of Supported TCP Extensions MUST be padded with 0 to en= d > on a 32 > bits boundary. >=20 [Med] Deal! > Section 6 > This section actually only discusses one type of middlebox (removes SYN). > Can the discussion be widened slightly [Med] This section only focuses on SYN/SYN-ACK because these are used by th= e Convert protocol. Do you have in mind a particular case (specific to the Convert protocol) th= at may be problematic? - or maybe simply say that if > middlebox interference detected, then MUST stop using the Converter (with > SYN removal given as an example)? >=20 > Not yet read Section 7 onwards, comments to follow. >=20 > Section 10 Change log > There's lots of really useful info about why the design is as it is (eg > the use of TLV rather than Options). It would be a shame if this was lost > from the rfc - please can info be extracted into a section "how > implementation experiences have influenced design decisions" or similar? >=20 > Thanks > phil >=20 > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael > Sent: 25 June 2019 17:39 > To: tcpm@ietf.org Extensions > Cc: tcpm-chairs@ietf.org > Subject: [tcpm] WGLC for draft-ietf-tcpm-converters-08 >=20 > Hi all, >=20 > draft-ietf-tcpm-converters has been discussed and reviewed quite a bit. >=20 > Therefore, this e-mail starts a working group last call (WGLC) for draft- > ietf-tcpm-converters-08 that will run until ***July 14, 2019***. >=20 > Please let us know if there are any remaining open issues regarding this > document. Statements supporting publication are also welcome. In absence > of feedback we will assume that the TCPM consensus is to move the documen= t > to the IESG. As discussed in the past, the intended status of the documen= t > is experimental. >=20 > Thanks a lot >=20 > Michael > (TCPM co-chair) >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Jun 28 02:27:09 2019 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 0EFD11201C5; Fri, 28 Jun 2019 02:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 v5QQeiBz7_WN; Fri, 28 Jun 2019 02:27:06 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F2B7120096; Fri, 28 Jun 2019 02:27:06 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 45Zry06fs7z8yBS; Fri, 28 Jun 2019 11:27:04 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 45Zry05VF8zCqkc; Fri, 28 Jun 2019 11:27:04 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM44.corporate.adroot.infra.ftgroup ([fe80::e8a4:8bb:d7c2:f4e2%21]) with mapi id 14.03.0439.000; Fri, 28 Jun 2019 11:27:04 +0200 From: To: "philip.eardley@bt.com" , "Michael.Scharf@hs-esslingen.de" , "tcpm@ietf.org" CC: "tcpm-chairs@ietf.org" Thread-Topic: WGLC for draft-ietf-tcpm-converters-08 Thread-Index: AdUrckm1sQAV9Sf8TqW1iT6fsU2DwgBZdsDwACyBV3A= Date: Fri, 28 Jun 2019 09:27:03 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EAAF429@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <6EC6417807D9754DA64F3087E2E2E03E2D35AB8E@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-converters-08 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, 28 Jun 2019 09:27:08 -0000 Re-, Focusing on this part of the review.=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de > philip.eardley@bt.com > Envoy=E9=A0: jeudi 27 juin 2019 17:58 > =C0=A0: Michael.Scharf@hs-esslingen.de; tcpm@ietf.org > Cc=A0: tcpm-chairs@ietf.org > Objet=A0: Re: [tcpm] WGLC for draft-ietf-tcpm-converters-08 >=20 > I support this document. Thanks to the authors for the nice work. >=20 >=20 > -------------- > Suggested clarifications - significant:- >=20 > I think it would be great if Section 3 was expanded into a "protocol > model" https://tools.ietf.org/html/rfc4101 in particular to expand on [Med] Section 3 is purposely edited "to quickly grasp the essence of" the c= onvert protocol. It focuses on the main design rationale that is use one si= ngle SYN to supply data to a converter. That supplied data is unambiguously= distinguished by means of TLVs and location within the payload. =20 > << 2. What messages are being transmitted and what do they mean?>> - > figures show the basic msg exchanges (info, connect, extended, supported, > cookie and error) [Med] There is a risk to be redundant with Section 4 (4.2.2, in particular)= + discuss messages that are not defined yet. We may consider adding figure= s to section 4, though.=20 > << 3. What are the important, but unobvious, features of the protocol?>= > > eg use of assigned port# ; use of first bytes of bytestream ;etc. [Med] Again, there is a risk to be redundant here. Will think about this fu= rther.=20 >=20 > I think you could distinguish more carefully between: the initiator of th= e > TCP convert protocol and the other 'legacy' end point versus the end > device downstream on a broadband line and the server upstream in the > internet. The language of the doc basically assumes that a "Client" > fulfils both the first roles and a "Server" fulfils both the last roles, > but this needs not always be the case. I realised this reading Section > 4.2.8, but I suspect it's true in many other places. [Med] I agree with the comment.=20 The assumption are as follows: * The default communication direction is assumed to be from a host (Client = role) to a remote host (Server role): denoted as "outgoing" * A host (which is used to be a client for outgoing connections) may accept= incoming connections because it embeds an application server. We called th= at "client" too for simplification reasons.=20 Point taken, we will need to figure out how to make this better.=20 >=20 >=20 From nobody Fri Jun 28 15:58:58 2019 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 87D8012092F; Fri, 28 Jun 2019 15:57:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: tcpm@ietf.org, ietf@kuehlewind.net X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156176267055.11015.3097975952886164511.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2019 15:57:50 -0700 Archived-At: Subject: [tcpm] tcpm - Requested session has been scheduled for IETF 105 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, 28 Jun 2019 22:57:52 -0000 Dear Michael Scharf, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tcpm Session 1 (2:00 requested) Thursday, 25 July 2019, Afternoon Session I 1330-1530 Room Name: Centre Ville size: 200 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/105/sessions/tcpm.ics Request Information: --------------------------------------------------------- Working Group Name: TCP Maintenance and Minor Extensions Area Name: Transport Area Session Requester: Michael Scharf Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: iccrg tcpinc mptcp taps tsvarea tsvwg quic Second Priority: httpbis lwig rmcat teas detnet Third Priority: rtcweb maprg panrg People who must be present: Yoshifumi Nishida Michael Tuexen Michael Scharf Mirja Kuehlewind Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Jun 29 04:58:56 2019 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 9D4C412017F; Sat, 29 Jun 2019 04:58:55 -0700 (PDT) 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 FjvUsr26-TXF; Sat, 29 Jun 2019 04:58:53 -0700 (PDT) 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 4C54D120176; Sat, 29 Jun 2019 04:58:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 4E15125A25; Sat, 29 Jun 2019 13:58:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1561809531; bh=sFBzYmRpEDCmNRtms2zYC0G50MU4Gv7IfWM5IIJjgIc=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=vXyH7KuNoEJDr/lAI40V5n2+niblcHheK49JWs5z9VQqgo4cBHeOGsMECNp1+/Rjj ILtvtf7qF/y1y52W65lSs+BoYcM0gcraEZKJdKJn7jM40H2Ns+021YKlIZEjZVcdKk a7L6UqnD3d4qR3l8h81ZMqt/Gn5dq3o/x1YqhMgg= 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 rcJwXGXu2Hqt; Sat, 29 Jun 2019 13:58:50 +0200 (CEST) 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; Sat, 29 Jun 2019 13:58:50 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.38]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0415.000; Sat, 29 Jun 2019 13:58:50 +0200 From: "Scharf, Michael" To: "draft-ietf-tcpm-converters@ietf.org" CC: "tcpm@ietf.org Extensions" Thread-Topic: IPR poll for draft-ietf-tcpm-converters Thread-Index: AQHVLnIDTXNv04YI7U2lMwCokCEJ6A== Date: Sat, 29 Jun 2019 11:58:49 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D366722@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D35AB8E@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D35AB8E@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_6EC6417807D9754DA64F3087E2E2E03E2D366722rznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: [tcpm] IPR poll for draft-ietf-tcpm-converters 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, 29 Jun 2019 11:58:56 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D366722rznt8114rzntrzd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear authors, The document shepherd has to ensure compliance with the IPR guidelines of t= he IETF. Can each author please confirm that their direct, personal knowledge of any= IPR related to this document has already been disclosed, in conformance wi= th BCPs 78 and 79? Note that an answer is required from all authors of the document. The TCPM = lists is added in CC for the sake of transparency. Thanks Michael Von: Scharf, Michael Gesendet: Dienstag, 25. Juni 2019 18:39 An: tcpm@ietf.org Extensions Cc: tcpm-chairs@ietf.org Betreff: WGLC for draft-ietf-tcpm-converters-08 Hi all, draft-ietf-tcpm-converters has been discussed and reviewed quite a bit. Therefore, this e-mail starts a working group last call (WGLC) for draft-ie= tf-tcpm-converters-08 that will run until ***July 14, 2019***. Please let us know if there are any remaining open issues regarding this do= cument. Statements supporting publication are also welcome. In absence of f= eedback we will assume that the TCPM consensus is to move the document to t= he IESG. As discussed in the past, the intended status of the document is e= xperimental. Thanks a lot Michael (TCPM co-chair) --_000_6EC6417807D9754DA64F3087E2E2E03E2D366722rznt8114rzntrzd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear authors,

 

The document shepherd has to ensure compliance wit= h the IPR guidelines of the IETF.

 

Can each author please confirm that their direct, personal knowledge of any IPR related to th= is document has already been disclosed, in conformance with BCPs 78 and 79?

 

Note that an answe= r is required from all authors of the document. The TCPM lists is added in = CC for the sake of transparency.

 

Thanks

 

Michael

 

 

Von: Scharf, Michael
Gesendet: Dienstag, 25. Juni 2019 18:39
An: tcpm@ietf.org Extensions Cc: tcpm-chairs@ietf.org=
Betreff: WGLC for draft-ietf-tcpm-converters-08

 

Hi all,

draft-ietf-tcpm-converters has been discussed and reviewed quite a bit.

Therefore, this e-mail starts a working group last call (WGLC) for draft-ie= tf-tcpm-converters-08 that will run until ***July 14, 2019***.

Please let us know if there are any remaining open issues regarding this do= cument. Statements supporting publication are also welcome. In absence of f= eedback we will assume that the TCPM consensus is to move the document to t= he IESG. As discussed in the past, the intended status of the document is experimental.

Thanks a lot

Michael
(TCPM co-chair)
--_000_6EC6417807D9754DA64F3087E2E2E03E2D366722rznt8114rzntrzd_-- From nobody Sun Jun 30 09:54:45 2019 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 1537212015C; Sun, 30 Jun 2019 09:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 eMDguJvj_G6v; Sun, 30 Jun 2019 09:54:42 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3B612015F; Sun, 30 Jun 2019 09:54:41 -0700 (PDT) Received: from [IPv6:2a02:8109:1140:c3d:90fb:9847:c425:656b] (unknown [IPv6:2a02:8109:1140:c3d:90fb:9847:c425:656b]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 36A6D721E282E; Sun, 30 Jun 2019 18:54:38 +0200 (CEST) From: Michael Tuexen Content-Type: multipart/signed; boundary="Apple-Mail=_02150466-4F83-4CFD-8656-F78FF3FBF49C"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Sun, 30 Jun 2019 18:54:37 +0200 Cc: tcpm-chairs@ietf.org To: tcpm IETF list X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [tcpm] Agenda requests for TCPM@IETF105 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, 30 Jun 2019 16:54:44 -0000 --Apple-Mail=_02150466-4F83-4CFD-8656-F78FF3FBF49C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, TCPM has a 2 hour time slot, currently scheduled at Thursday afternoon. If you would like to present during this meeting, please provide by the end of Monday, July 8th: * Title of the presentation * Name of the presenter * Name of the Internet Draft * Time required (including Q/A) * Whether the presentation will be local or remote Please send us the slides for your presentations by Sunday, July 21st, = latest. Looking forward to seeing you in Montreal! Best regards Michael --Apple-Mail=_02150466-4F83-4CFD-8656-F78FF3FBF49C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEKow ggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRFMSsw KQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQLDBZULVN5 c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9vdCBDbGFzcyAy MB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNVBAYTAkRFMUUwQwYDVQQK EzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMg ZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERGTi1WZXJlaW4gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtg1/9moUHN0vqH l4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZsFVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8F XRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0peQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+Ba L2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qL NupOkSk9s1FcragMvp0049ENF4N1xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz 9AkH4wKGMUZrAcUQDBHHWekCAwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU k+PYMiba1fFKpZFK4OpL4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYD VR0TAQH/BAgwBgEB/wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGC LB4wCAYGZ4EMAQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv cmwvVGVsZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5jZXIw DQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4eTizDnS6 dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/MOaZ/SLick0+ hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3SPXez7vTXTf/D6OWS T1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc22CzeIs2LgtjZeOJVEqM7 h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bPZYoaorVyGTkwggWsMIIElKAD AgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJERTFFMEMGA1UEChM8VmVy ZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYu MRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRERk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcNMzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUx RTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5n c25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9i YWwgSXNzdWluZyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp 1xCeOdfZojDbchwFfylfS2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6W LkDh0YNMZj0cZGnlm6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mI TQ5HjUhfZZkQ0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUk P7agCwf9TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22M ZD08WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAdBgNV HQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK4OpL4qIM z+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYBBQUHAQEEgdAwgc0wMwYI KwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBKBggrBgEF BQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY2FjZXJ0 L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJv b3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/ DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCN T1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7Ln8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+ lgQCXISoKTlslPwQkgZ7nu7YRrQbtQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v 9NsH1VuEGMGpuEvObJAaguS5Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7 EUkp2KgtdRXYShjqFu9VNCIaE40GMIIF4DCCBMigAwIBAgIMIRX9tDE2QqO3mVLXMA0GCSqGSIb3 DQEBCwUAMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVp bmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUw IwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDYwNDE0MjkxMFoXDTIy MDYwMzE0MjkxMFowfDELMAkGA1UEBhMCREUxIDAeBgNVBAoMF0ZhY2hob2Noc2NodWxlIE11ZW5z dGVyMTIwMAYDVQQLDClGYWNoYmVyZWljaCBFbGVrdHJvdGVjaG5payB1bmQgSW5mb3JtYXRpazEX MBUGA1UEAwwOTWljaGFlbCBUdWV4ZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM r8qQcPxLFCxzPtXvRyM9KeQaxyMA8gwUNc7IIiATs6mRQFe5ib/mvwT9nc0bAa+94go6HJDiD3FJ NkTo4u8aBsIcTt5pJtdBQLm88PLakbe3+fp/00//n7xxbTh7mAtFVCf25LxDCKkrdGk/+jglRq/R VdwhZZ3VpYCrx8YfI/hIzdRL3+4I4z/mnQ8K0X8d2MVVPG+9nBEngdnYGez5f/8wIVOgEYYBc21k yvMnVXLu2Ing+LwBd0gDG9Vasv87MNHCOZfJTNBlLhI2UDei/uNg9Zd4ynlMpPWZ7v0oiDWvmv8E OuD4oric8heyD0OYK2FL4qcVC4dn4pnyulfHAgMBAAGjggJOMIICSjA+BgNVHSAENzA1MA8GDSsG AQQBga0hgiwBAQQwEAYOKwYBBAGBrSGCLAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIw ADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBTxiodBVL/lA4p5iNesIsJRhhgd6zAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDAg BgNVHREEGTAXgRV0dWV4ZW5AZmgtbXVlbnN0ZXIuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0 cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tY2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+g PaA7hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNy bC5jcmwwgdsGCCsGAQUFBwEBBIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZu LmRlL09DU1AtU2VydmVyL09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv ZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQw DQYJKoZIhvcNAQELBQADggEBABs3VlmIZ1VF3HkaQdjInZYmamRabbdgJ7cz6m6o/agKL7+Vhwx7 1BaaYs2gMa5Nu/GJ3YfdqIsUlYtKdl58Yhp/89E6xBfJkItS+rE8RFdf2XgklGlx7GmsvdA3tId5 b6K6r9a5wpVN0epxY6K8wwpzEib6fJLcHylybQXZ7JSOaLRLp6WU3QPoyTT7FpvAe/0b2MSCbPX4 fc53PCn2aGgXuRFVQeCn1SP1BF3QW1ppkFhcF6G+0JcUxYFAXE6r/71WZBvUHqoG/th2hAwQnS+Y KhUYh4SZQH3/ursXXJYXQ5vyIhkN1FZlmtWA8+ofdCnoqSTbiSX2Aa/kKbTapwgxggOdMIIDmQIB ATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5l cyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMG A1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIRX9tDE2QqO3mVLXMA0GCWCGSAFl AwQCAQUAoIIBzzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTA2 MzAxNjU0MzdaMC8GCSqGSIb3DQEJBDEiBCBuvwNZJCvvefKLS2nwSgogTytqRnh+2l6b15y63wOw EzCBrwYJKwYBBAGCNxAEMYGhMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1 ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD VQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwhFf20 MTZCo7eZUtcwgbEGCyqGSIb3DQEJEAILMYGhoIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8 VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu IFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5n IENBAgwhFf20MTZCo7eZUtcwDQYJKoZIhvcNAQEBBQAEggEAP2Dp5VjVqyKRCyQJ4s0rCvhRU0aM DQCz5Rbiy9KLkV8wacFyO9P8MiPcmK1QlEuixPJgxmbqIE7jDfA3ecwEcMbGT5itbGOtuekPIfg0 dXETSsFgdOyqQIiSYEexVdeUh3xogOt/5O8fDbZUeAmogk/eE7iMeFuVTBIUVJ79ICJ5v/0SRFgP ovZ++yRYQfsOY6vIWbTOTOP5J1MjRG0gRZhPAQbMyj1hNRzbhmRIAsiTKLgXxyfGFDYNteEugTH+ sms+suJrbtGpQc1bN300QOutAXO5jSKgccfzxJ3Q+ziTYFQSjX4F2bRUVr19QJh8l1KMQiDRrFjZ 52s68CWSzQAAAAAAAA== --Apple-Mail=_02150466-4F83-4CFD-8656-F78FF3FBF49C--