From nobody Fri Feb 1 07:50:03 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD0D130EE3 for ; Fri, 1 Feb 2019 07:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 wJUBPsWjxb-r for ; Fri, 1 Feb 2019 07:49:56 -0800 (PST) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 B0D38130EE2 for ; Fri, 1 Feb 2019 07:49:53 -0800 (PST) X-Envelope-From: phils@in-panik.de X-Envelope-To: Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id x11FnoFG018424 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 1 Feb 2019 16:49:50 +0100 Received: from philipp-laptop.ods.tu-berlin.de ([130.149.141.20]) by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1gpb3C-0001Ug-H6 for taps@ietf.org; Fri, 01 Feb 2019 16:48:18 +0100 From: "Philipp S. Tiesel" Content-Type: multipart/signed; boundary="Apple-Mail=_928C74ED-88DC-44E0-992D-45DFB2FB7265"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: <4159A1D5-FA3C-4CC5-9BA4-D4847DE7679C@in-panik.de> Date: Fri, 1 Feb 2019 16:49:49 +0100 To: taps WG X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [Taps] Standardising Transport Property Names X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 15:50:02 -0000 --Apple-Mail=_928C74ED-88DC-44E0-992D-45DFB2FB7265 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, during the January interim, we had some discussions regarding whether we = want to standardise strings for representing Transport Property Names and = whether we may need an IANA registry to keep track of these when new ones get = added. TL;DR =3D=3D=3D=3D=3D In the interim, we roughly agreed that we need to add names for the = Transport Properties to the API draft. Also, we agreed that these property names = can be prefixed with a namespace to separate standard generic properties = from protocol, implementation, or vendor specific properties. Before writing text for that, I volunteered to bring the conclusion from = the interim to the mailing list and ask for feedback. The bloody details =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Transport Property Names ------------------------ Standardised Transport Property Names solve two purposes: - Allow different components of a TAPS implementation to pass Transport Properties, e.g., between a language frontend and a policy manager - Make code of different TAPS implementations look similar / familiar My straw-man proposal to use camelCased strings got a lot criticism as = it discriminates non-camelCased languages. It seems that we need a = canonical string format that can be used across components of a TAPS system and = can be easily translated into strings, symbolic constants or static objects = that match the individual style of the programming APIs. As a first proposal, I favour lower-case strings with underscores as = word separators. Namespaces ---------- Besides the categorisation into Selection, Connection, and Message = Properties, we also have different kinds of Transport Properties: - Generic Properties (most properties in the API draft fall in this = case) - Protocol Specific Properties (e.g., properties to control certain TCP = timers) - Vendor or Implementation Specific Properties To allow a TAPS system to be extendable, we want to separate these out = by adding a namespace prefix to the Transport Properties. As a first proposal, I favour the following - Generic properties from the API draft or defined by an RFC carry no namespace prefix. - Protocol Specific Properties must carry the protocol acronym as prefix, e.g., =E2=80=9Ctcp" for TCP specific Transport Properties. For IETF protocols, property names unter these namespaces should be defined in an RFC. - Vendors or implementation specific properties must prefix with the vendor or implementation=E2=80=99s name. - Experimental or local-use properties must be Prefixed with an X or Y. Open Questions: --------------- - Do we need an IANA registry for Generic Properties? - Do we need an IANA registry for Property Namespaces? - Do we need to request an IANA registry with the API document or may we postpone the above decisions? - Where do we want to define the rules for naming Transport Properties = and Namespaces? AVE! Philipp S. Tiesel / phils=E2=80=A6 -- = {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----, wenn w eine aube ist dn man au dran dre en = | o Schr an muss hc h (Kurt = Schwitters) | :wq! <----(phone: +49-179-6737439)---<---(jabber: = phils@in-panik.de)----' --Apple-Mail=_928C74ED-88DC-44E0-992D-45DFB2FB7265 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEWxyORUfQrk93Q7or9/dp0G7BPC0FAlxUap0ACgkQ9/dp0G7B PC20VRAAq8zo4GpPwKkdPe8DLJVFbK+XjrqXRUWRVTScIctqOBqEt/HNkwhoXFT+ 4/3yjoPGV3XEiflp4nlbO2m+kNKNRblvBe3G6dUIhtj4wuK/BIenRtzLWknU6Vcn j6DoaCDUC2WqJDjXLndQJc7hu7DLmNalpP3Pa8jFapMl1kFNLF9o6z0wbxQxb7T3 NN8S81UAYc7e7szetF0CH9uNmrse1oPqVXXpsO2b3NK/wEQxaudkVqjBGIvyPUDC zQpUVXNdgKeJDUeTVzvKGYcIx4qC2f7NC5enVZDNn2ycs38lCMc53f6u92u8mgu7 ChbZvk4gFnHR+I9I1m7hH8s3ZNOA2LqgOi4EJFRFbJiQqRi95d7FyUJ5oR81ZV0W dNIyeo8vopHu29BT4WFhAWnW6f6bDQmHf5qYA4vNmHwiWWU+c8HTxMXYi9mSaTcz vMKwB2aDraTeb5h6RF0X80+WsFZVSWEmoohP+oHwC547MlpavYUrANd6tBL5weMv O/81UiMxLRpDz75MoDfq6/1vN78k1vZPZMuNXiVQEXl1ExTY9MQXAfyY8OfzHDYT 3Uiqk4pxV3RgLFsYqjUOnGmpejGdLl65gXeWXdq31HKbuo7ZF23LP11ly0J/cVXG h8K9rsB3H6nDyVhsSZdugS8PWO3qqg/bdEBjNK7UDRd5iooruaU= =mWDK -----END PGP SIGNATURE----- --Apple-Mail=_928C74ED-88DC-44E0-992D-45DFB2FB7265-- From nobody Wed Feb 20 08:20:53 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371DC130DC4 for ; Wed, 20 Feb 2019 08:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLRN5XStZ90i for ; Wed, 20 Feb 2019 08:20:48 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2302D130E46 for ; Wed, 20 Feb 2019 08:20:42 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id E6206340FBB; Wed, 20 Feb 2019 17:20:39 +0100 (CET) X-Iway-Path: 0 Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/3959.3504); Wed, 20 Feb 2019 17:20:39 +0100 (CET) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Wed, 20 Feb 2019 17:20:39 +0100 (CET) Received: from [213.55.176.151] (account ietf@trammell.ch HELO [172.20.10.2]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.2.12) with ESMTPSA id 83823902; Wed, 20 Feb 2019 17:20:39 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Brian Trammell (IETF)" In-Reply-To: <4159A1D5-FA3C-4CC5-9BA4-D4847DE7679C@in-panik.de> Date: Wed, 20 Feb 2019 17:20:38 +0100 Cc: taps WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <4159A1D5-FA3C-4CC5-9BA4-D4847DE7679C@in-panik.de> To: "Philipp S. Tiesel" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Taps] Standardising Transport Property Names X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 16:20:51 -0000 hi Philipp, Thanks for pulling this together. I've finally had time to look at it. > On 1 Feb 2019, at 16:49, Philipp S. Tiesel wrote: >=20 > Hi, >=20 > during the January interim, we had some discussions regarding whether = we want > to standardise strings for representing Transport Property Names and = whether > we may need an IANA registry to keep track of these when new ones get = added. >=20 >=20 > TL;DR > =3D=3D=3D=3D=3D > In the interim, we roughly agreed that we need to add names for the = Transport > Properties to the API draft. Also, we agreed that these property names = can > be prefixed with a namespace to separate standard generic properties = from protocol, > implementation, or vendor specific properties. >=20 > Before writing text for that, I volunteered to bring the conclusion = from the > interim to the mailing list and ask for feedback. >=20 >=20 > The bloody details > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Transport Property Names > ------------------------ >=20 > Standardised Transport Property Names solve two purposes: > - Allow different components of a TAPS implementation to pass = Transport > Properties, e.g., between a language frontend and a policy manager > - Make code of different TAPS implementations look similar / familiar >=20 > My straw-man proposal to use camelCased strings got a lot criticism as = it > discriminates non-camelCased languages. It seems that we need a = canonical > string format that can be used across components of a TAPS system and = can > be easily translated into strings, symbolic constants or static = objects that > match the individual style of the programming APIs. >=20 > As a first proposal, I favour lower-case strings with underscores as = word separators. This seems reasonable to me. Alternately we could party like it's 1982 = and we can't afford an 80-column card and do = UNDERSCORE_SEPARATED_UPPERCASE like the TCP RFCs do.=20 (That's not a serious suggestion, but I note that it does make it very = easy to see where the property names are when scanning the document, as = long as we don't name a property RECOMMENDED.) > Namespaces > ---------- >=20 > Besides the categorisation into Selection, Connection, and Message = Properties, > we also have different kinds of Transport Properties: > - Generic Properties (most properties in the API draft fall in this = case) > - Protocol Specific Properties (e.g., properties to control certain = TCP timers) > - Vendor or Implementation Specific Properties >=20 > To allow a TAPS system to be extendable, we want to separate these out = by > adding a namespace prefix to the Transport Properties. So the namespace question only really becomes interesting if we presume = we want to have a registry with other than Standards Action policy. But = if we presume that... Bikeshed question number 1: do we want to separate namespace prefixes = with underscores as with spaces, or with some other character? i.e. to = use a tortured example would it be something like = tcp.retransmission_timeout or tcp_retransmission_timeout? (I'm borrowing = from sysctl namespaces a little here) > As a first proposal, I favour the following > - Generic properties from the API draft or defined by an RFC carry no > namespace prefix. This makes sense. > - Protocol Specific Properties must carry the protocol acronym as > prefix, e.g., =E2=80=9Ctcp" for TCP specific Transport Properties. > For IETF protocols, property names unter these namespaces should > be defined in an RFC. This also makes sense. > - Vendors or implementation specific properties must prefix with the > vendor or implementation=E2=80=99s name. Bikeshed question number 2: you probably need a registry of vendor = namespaces. what's the policy on creating those? Do we really want to = create another PEN-like thing? > - Experimental or local-use properties must be Prefixed with an X or = Y. I don't like this. MIME headers used to use the X- prefix, but this has = been deprecated because the presumptive semantic benefit of this -- you = can see which bits are experimental -- disappears because nobody ever = replaces experimental identifiers when experiments transition to = production. > Open Questions: > --------------- >=20 > - Do we need an IANA registry for Generic Properties? That depends on what we think the extension mechanism for the TAPS API = is. I tend to think no: new extensions to the API will require a = standards action, and probably even need to update the core TAPS API = docs. > - Do we need an IANA registry for Property Namespaces? Maybe? > - Do we need to request an IANA registry with the API document > or may we postpone the above decisions? I'm inclined to assign names (with generic and protocol-specific = namespaces) and leave the whole vendor/registry thing as future work, = because defining a registry well is hard, and I'm not sure such a thing = will ever be used. It's a lot to do up front.=20 > - Where do we want to define the rules for naming Transport Properties = and Namespaces? Consistent with my opinion above: name the transport namespaces in this = doc, leave all other rules as future work. Cheers, Brian >=20 > AVE! > Philipp S. Tiesel / phils=E2=80=A6 > -- > = {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----, > wenn w eine aube ist dn man au dran dre en = | > o Schr an muss hc h (Kurt = Schwitters) | > :wq! <----(phone: +49-179-6737439)---<---(jabber: = phils@in-panik.de)----' >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Wed Feb 20 08:59:04 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB5612870E for ; Wed, 20 Feb 2019 08:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.246 X-Spam-Level: X-Spam-Status: No, score=0.246 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rR1L3jcnbbzg for ; Wed, 20 Feb 2019 08:59:00 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140104.outbound.protection.outlook.com [40.107.14.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1845D130DC4 for ; Wed, 20 Feb 2019 08:58:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=doU0MGnl5plEQSzj8R0RgmXgm7sEbr8q5ZbgY7SHwq4=; b=FoMPmR55ZKTNtQl2G2xHJxO3ZTnvYzGhfsH6J4ujtRoZ9TTeoZJW5PpkeYG6eHjzcoHfvalnjBsqiSNJn1DH+zdrIUM5RRuMsGnyIVouPbxEtncvh8G+f3sUKJlxqx9q4EXmoGoKtOPOWC3DlKH669OVK3vpwW1DeI2bkhjWYh8= Received: from VI1PR07MB3502.eurprd07.prod.outlook.com (10.175.244.156) by VI1PR07MB5822.eurprd07.prod.outlook.com (20.178.122.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.5; Wed, 20 Feb 2019 16:58:57 +0000 Received: from VI1PR07MB3502.eurprd07.prod.outlook.com ([fe80::e143:d88a:9d3c:e681]) by VI1PR07MB3502.eurprd07.prod.outlook.com ([fe80::e143:d88a:9d3c:e681%2]) with mapi id 15.20.1643.012; Wed, 20 Feb 2019 16:58:57 +0000 From: tom petch To: "Brian Trammell (IETF)" , "Philipp S. Tiesel" CC: taps WG Thread-Topic: [Taps] Standardising Transport Property Names Thread-Index: AQHUyT2R06mkdzD72k60gkTJkKxiIQ== Date: Wed, 20 Feb 2019 16:58:57 +0000 Message-ID: <017201d4c93d$53d8eb60$4001a8c0@gateway.2wire.net> References: <4159A1D5-FA3C-4CC5-9BA4-D4847DE7679C@in-panik.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0448.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:e::28) To VI1PR07MB3502.eurprd07.prod.outlook.com (2603:10a6:802:24::28) x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.156.84.54] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ec3b1dfa-52ac-42fb-0089-08d69754b3e3 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB5822; x-ms-traffictypediagnostic: VI1PR07MB5822: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0954EE4910 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(366004)(396003)(346002)(376002)(189003)(199004)(13464003)(66066001)(44736005)(6436002)(52116002)(44716002)(62236002)(6512007)(86152003)(25786009)(81686011)(81816011)(9686003)(76176011)(229853002)(6486002)(84392002)(71190400001)(99286004)(71200400001)(33896004)(561944003)(6306002)(4326008)(446003)(476003)(2906002)(4720700003)(486006)(97736004)(3846002)(86362001)(256004)(14444005)(6116002)(102836004)(53936002)(1556002)(6346003)(26005)(316002)(8676002)(68736007)(478600001)(53546011)(105586002)(106356001)(386003)(6506007)(8936002)(14454004)(110136005)(50226002)(5660300002)(7736002)(305945005)(61296003)(6246003)(81166006)(81156014)(14496001)(186003)(966005)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB5822; H:VI1PR07MB3502.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com; x-microsoft-exchange-diagnostics: =?utf-8?B?MTtWSTFQUjA3TUI1ODIyOzIzOnhrK0RaVnlic25naWs2QUZpak83b0FPUjgv?= =?utf-8?B?UlI0S2ZKR3lhS3NwdXdTem04MUUvRThqeC9jOTd1bXlGSzE0SHp4TEhTT1J4?= =?utf-8?B?YWJCWWZWSmdnQWpmN2UwZ013djhIT0FLRU5rT0Z5c2VaVUQ4b0ptNUJoeklM?= =?utf-8?B?NFV3Ky9NSkZ4UzlLaVN5WEt5UCt0bjJENksydVh0K09Ja2IwV2Z3dXJmelp3?= =?utf-8?B?NHhWN3ZTQVprVmVjelZ3WVlvZGdoMUs4V3hFMUY5bFRDaXZkMjJheDFkMndS?= =?utf-8?B?ZmtTSU5EV1lzdW8wdUk3OUNlZmU0SEpHQzI5WDBYN2VGOGJPVmU2RTBhMVhV?= =?utf-8?B?OHBFM2hyWEo2U013RVUvYXpLQ1ovRnhCWFN1ZkZ2N3lnN1p5OHhSK21wc01H?= =?utf-8?B?SFdaWkl6VGs5MGxCS0QzQmdNYjJPcjNvalJ1TjM1K3BDM1A5Rkp2NmRKWjFM?= =?utf-8?B?dk1nU3pTOWM2V2NmVUFyL1ZTRytWK3d4cndsMU0vY2s3MEM2aldVM3U3UWNU?= =?utf-8?B?SHhsRml2RG94eUdBa1lzVWFhSGtadWtiWDNkUS8vN0FDTGdRS1FhU0ozRmVz?= =?utf-8?B?RUVMLzBiV3djcE50eTFiTkJIVzFTd2p0YUFDSnNhaEVFUjA4Q0k4SkZDQXVW?= =?utf-8?B?ZEloOExOSDlhT21RREkydE1VaFNhTjFoUGZIcUplMVNhTEFINXoxc04wTnZQ?= =?utf-8?B?QkFjUVlkZVFnSXFxbGc3ZzB1bklMMmxWZGxDSGV4anB4LzVIN0hHT0RVdEtU?= =?utf-8?B?QzhyaXlaTFcrSE5WcjdBS2NHZ09rcmJEcWhqM1Q3RXlPaFE0akliQUxsQWxh?= =?utf-8?B?SXU0eGExekRvVDNsajdEUlUrd3d2eDBrN2NEaGExT3FvMGE5elFHQTVGTTFY?= =?utf-8?B?UUJIZ1c2VG5GQVRaRlFaOHB2amFWS0thMGVHQURuM21VZzhWNzNaNmlKLzBE?= =?utf-8?B?c1VuazBVRFNRYjNUOWN2RXpGMFdFYkE2RlBwWE9aa05RMlVBbkNYbzVsN3dn?= =?utf-8?B?eGhtU3IwK0s5N0tycm5zZjlLT1VVaUo2amk0M1NsdVNKSHUvNGlobUh3U2lO?= =?utf-8?B?WUg4Ym1HbGxiSGZPaU82TWlhTHJZZDNneFFxczZlUVFneUo2M1lrTXRqcGtK?= =?utf-8?B?UGFpcW5GVlNEVzVGcWM1dmJ1aG94eXFvZkxmbWJicUpkb2tXaDlGZ3JwWDdl?= =?utf-8?B?UTJmZGEwbGVzVExTdDhsQ2ltdHk5UFdJNS96THZBaXhLOEVaWklZWDI0VTRG?= =?utf-8?B?RUtDM0Z6Kzdwd2hkZ1MvQXhZTHdBb1d5NEJqL0psQlZSbDZWU3Baa3QvWkF3?= =?utf-8?B?M0VVek1TYmY4d0pRaVQ5eE56cmx4MEhqNGxGR1FVY2xQYjlxRzNERXY2N2dJ?= =?utf-8?B?elYxM3EyNUU5YTJrR21tOHFmbkplbUVuRHA1SHFxcDBJZHBOMVVMcVBDK2VR?= =?utf-8?B?STZLUFpWaGN6SnZhalhYR0Y2T09hYlZybThZZjg5ZTNzS3B1NzcvM1h1R1Ni?= =?utf-8?B?NTZSM0V3REJJTG1NZGVYaGNVQU40VWtXcjFhaDVmR3BmYTB6bjZPalZCVUxj?= =?utf-8?B?NWxlMk5vRDJxRmwxSC80Y2JIeVY3ajg4V1NtdHdBQjRMaStyUW9UbEE2Qkwv?= =?utf-8?B?TDNLNVQwMm5WV2Y1bGhTMmVKVVNHK1ZhOG1WeE5aSmRqanh3dFAxc09hV1Nh?= =?utf-8?B?M1pSaGNjb25oSDU1UVJhQXJ3am8zM01rcHNndWltVGlic29hUUtPZTh4L3JF?= =?utf-8?B?M3R6d1lGY3JaL01lbEsvaWx4YnM3VE9laW85R3JFRnllMUZYRUZoV2tMRkhJ?= =?utf-8?B?eFJiKzh1WFp0b2d5aEs3MnN3NUhjWmhTSC8vUWR0VEwrb3pCd21GemFaYTBi?= =?utf-8?B?RjlvQUJGWGNTdG8zYmRsSHNqWnFhZk5GQ0NjZ2dsdVFqR0FJVTdJd2dSZGcr?= =?utf-8?B?YXB0S2dERDNXb1JNck0zamd3eGxFZWtXVmtZR29ybTYwUnp2anNqejJ5SXRF?= =?utf-8?B?Mm92b2hvQTJGbEZMYXcxQ2RQTjJnRlRBZlM1VzlDVXRSMXBxSHEvY29KRlIy?= =?utf-8?B?ejhSbm0xNXhvbUNRZkY0ZGNVUGpiZi9UQjdCb25YTFY0ZUpXWTVSWVdLMHcx?= =?utf-8?Q?Gx0AMcv5mrKaBYp3n1CZy3xqL6giSJ0shn62FEc+nr2a?= x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: giz0s7bqRxJwD+yYkDxhLbYj3ChSzsDK+HPH/4FpEZuivdi4ckRuSojk3rMcjIaSVJ2PgfPd8BdNygard/89VGWYLPSArKojab6skXzVu0XCq3jeFZSdtcDm2dBDnT5uDPE7WGxX5rhPXbTR1Jhmfg0/L2+QWurI0b78Gj/92YLN2lq+ZJi0ZRwWM0Uf7H17nmyDxctGQ4Nurbo3v6xhhwJY/JQXBkguaWRGx4CRG1QO/Dk6JZccCE8JTdT19PJjftKcaKKe5TvrFy46ta/yp3AcFpt/Bhfo0pd5RgXuQTcHb3AoDUAAVGBCCiJMlLqS2YeuIxHHGU8vzHg3kFBHBUlxcR05om6WeJP+g4DionCYeonDapWGO76UyKEPz5prh7vcEZSOX+To/6GGl1lbcQ243P7QZ78LG8flUPWdsxc= Content-Type: text/plain; charset="utf-8" Content-ID: <4417DED7A5ED1C4780D8FC35E6D5BB4E@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: ec3b1dfa-52ac-42fb-0089-08d69754b3e3 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2019 16:58:56.6736 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5822 Archived-At: Subject: Re: [Taps] Standardising Transport Property Names X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 16:59:03 -0000 LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIkJyaWFuIFRyYW1tZWxsIChJRVRG KSIgPGlldGZAdHJhbW1lbGwuY2g+DQpUbzogIlBoaWxpcHAgUy4gVGllc2VsIiA8cGhpbHNAaW4t cGFuaWsuZGU+DQpDYzogInRhcHMgV0ciIDx0YXBzQGlldGYub3JnPg0KU2VudDogV2VkbmVzZGF5 LCBGZWJydWFyeSAyMCwgMjAxOSA0OjIwIFBNDQoNCj4gaGkgUGhpbGlwcCwNCj4NCj4gVGhhbmtz IGZvciBwdWxsaW5nIHRoaXMgdG9nZXRoZXIuIEkndmUgZmluYWxseSBoYWQgdGltZSB0byBsb29r IGF0IGl0Lg0KPg0KPiA+IE9uIDEgRmViIDIwMTksIGF0IDE2OjQ5LCBQaGlsaXBwIFMuIFRpZXNl bCA8cGhpbHNAaW4tcGFuaWsuZGU+DQp3cm90ZToNCj4gPg0KPiA+IEhpLA0KPiA+DQo+ID4gZHVy aW5nIHRoZSBKYW51YXJ5IGludGVyaW0sIHdlIGhhZCBzb21lIGRpc2N1c3Npb25zIHJlZ2FyZGlu Zw0Kd2hldGhlciB3ZSB3YW50DQo+ID4gdG8gc3RhbmRhcmRpc2Ugc3RyaW5ncyBmb3IgcmVwcmVz ZW50aW5nIFRyYW5zcG9ydCBQcm9wZXJ0eSBOYW1lcyBhbmQNCndoZXRoZXINCj4gPiB3ZSBtYXkg bmVlZCBhbiBJQU5BIHJlZ2lzdHJ5IHRvIGtlZXAgdHJhY2sgb2YgdGhlc2Ugd2hlbiBuZXcgb25l cw0KZ2V0IGFkZGVkLg0KPiA+DQo+ID4NCj4gPiBUTDtEUg0KPiA+ID09PT09DQo+ID4gSW4gdGhl IGludGVyaW0sIHdlIHJvdWdobHkgYWdyZWVkIHRoYXQgd2UgbmVlZCB0byBhZGQgbmFtZXMgZm9y IHRoZQ0KVHJhbnNwb3J0DQo+ID4gUHJvcGVydGllcyB0byB0aGUgQVBJIGRyYWZ0LiBBbHNvLCB3 ZSBhZ3JlZWQgdGhhdCB0aGVzZSBwcm9wZXJ0eQ0KbmFtZXMgY2FuDQo+ID4gYmUgcHJlZml4ZWQg d2l0aCBhIG5hbWVzcGFjZSB0byBzZXBhcmF0ZSBzdGFuZGFyZCBnZW5lcmljIHByb3BlcnRpZXMN CmZyb20gcHJvdG9jb2wsDQo+ID4gaW1wbGVtZW50YXRpb24sIG9yIHZlbmRvciBzcGVjaWZpYyBw cm9wZXJ0aWVzLg0KPiA+DQo+ID4gQmVmb3JlIHdyaXRpbmcgdGV4dCBmb3IgdGhhdCwgSSB2b2x1 bnRlZXJlZCB0byBicmluZyB0aGUgY29uY2x1c2lvbg0KZnJvbSB0aGUNCj4gPiBpbnRlcmltIHRv IHRoZSBtYWlsaW5nIGxpc3QgYW5kIGFzayBmb3IgZmVlZGJhY2suDQo+ID4NCj4gPg0KPiA+IFRo ZSBibG9vZHkgZGV0YWlscw0KPiA+ID09PT09PT09PT09PT09PT09PQ0KPiA+DQo+ID4gVHJhbnNw b3J0IFByb3BlcnR5IE5hbWVzDQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4NCj4g PiBTdGFuZGFyZGlzZWQgVHJhbnNwb3J0IFByb3BlcnR5IE5hbWVzIHNvbHZlIHR3byBwdXJwb3Nl czoNCj4gPiAtIEFsbG93IGRpZmZlcmVudCBjb21wb25lbnRzIG9mIGEgVEFQUyBpbXBsZW1lbnRh dGlvbiB0byBwYXNzDQpUcmFuc3BvcnQNCj4gPiAgIFByb3BlcnRpZXMsIGUuZy4sIGJldHdlZW4g YSBsYW5ndWFnZSBmcm9udGVuZCBhbmQgYSBwb2xpY3kgbWFuYWdlcg0KPiA+IC0gTWFrZSBjb2Rl IG9mIGRpZmZlcmVudCBUQVBTIGltcGxlbWVudGF0aW9ucyBsb29rIHNpbWlsYXIgLw0KZmFtaWxp YXINCj4gPg0KPiA+IE15IHN0cmF3LW1hbiBwcm9wb3NhbCB0byB1c2UgY2FtZWxDYXNlZCBzdHJp bmdzIGdvdCBhIGxvdCBjcml0aWNpc20NCmFzIGl0DQo+ID4gZGlzY3JpbWluYXRlcyBub24tY2Ft ZWxDYXNlZCBsYW5ndWFnZXMuIEl0IHNlZW1zIHRoYXQgd2UgbmVlZCBhDQpjYW5vbmljYWwNCj4g PiBzdHJpbmcgZm9ybWF0IHRoYXQgY2FuIGJlIHVzZWQgYWNyb3NzIGNvbXBvbmVudHMgb2YgYSBU QVBTIHN5c3RlbQ0KYW5kIGNhbg0KPiA+IGJlIGVhc2lseSB0cmFuc2xhdGVkIGludG8gc3RyaW5n cywgc3ltYm9saWMgY29uc3RhbnRzIG9yIHN0YXRpYw0Kb2JqZWN0cyB0aGF0DQo+ID4gbWF0Y2gg dGhlIGluZGl2aWR1YWwgc3R5bGUgb2YgdGhlIHByb2dyYW1taW5nIEFQSXMuDQo+ID4NCj4gPiBB cyBhIGZpcnN0IHByb3Bvc2FsLCBJIGZhdm91ciBsb3dlci1jYXNlIHN0cmluZ3Mgd2l0aCB1bmRl cnNjb3JlcyBhcw0Kd29yZCBzZXBhcmF0b3JzLg0KPg0KPiBUaGlzIHNlZW1zIHJlYXNvbmFibGUg dG8gbWUuIEFsdGVybmF0ZWx5IHdlIGNvdWxkIHBhcnR5IGxpa2UgaXQncyAxOTgyDQphbmQgd2Ug Y2FuJ3QgYWZmb3JkIGFuIDgwLWNvbHVtbiBjYXJkIGFuZCBkbw0KVU5ERVJTQ09SRV9TRVBBUkFU RURfVVBQRVJDQVNFIGxpa2UgdGhlIFRDUCBSRkNzIGRvLg0KPg0KPiAoVGhhdCdzIG5vdCBhIHNl cmlvdXMgc3VnZ2VzdGlvbiwgYnV0IEkgbm90ZSB0aGF0IGl0IGRvZXMgbWFrZSBpdCB2ZXJ5DQpl YXN5IHRvIHNlZSB3aGVyZSB0aGUgcHJvcGVydHkgbmFtZXMgYXJlIHdoZW4gc2Nhbm5pbmcgdGhl IGRvY3VtZW50LCBhcw0KbG9uZyBhcyB3ZSBkb24ndCBuYW1lIGEgcHJvcGVydHkgUkVDT01NRU5E RUQuKQ0KDQpvciB3ZSBjb3VsZCBsb29rIGZvcndhcmQgdG8gdGhlIDIxc3QgY2VudHVyeSBhbmQg aW1hZ2luZSB0aGF0IHNvbWV0aW1lDQpzb21lb25lIG1pZ2h0IHdhbnQgdG8gZG8gc29tZSBzb3J0 IG9mIG1hbmFnZW1lbnQgb2YgdGhlc2UgZW50aXRpZXMgYW5kDQptYWtlIHRoZW0gWUFORy1jb21w YXRpYmxlIChob3BpbmcgdGhhdCBZQU5HIGxhc3RzIHRoYXQgbG9uZyEpLg0KDQpBbmQgYSByZWdp c3RyeSBjb3VsZCBiZSBhIFlBTkcgbW9kdWxlIHJlYWR5IHRvIGJlIGltcG9ydGVkIGJ5IGFueW9u ZSB3aG8NCndhbnRzIHRvIHVzZSB0aGUgbmFtZXMuDQoNCkFuZCB0aGF0IGlzIGEgc2VyaW91cyBz dWdnZXN0aW9uLg0KDQpUb20gUGV0Y2gNCg0KPiA+IE5hbWVzcGFjZXMNCj4gPiAtLS0tLS0tLS0t DQo+ID4NCj4gPiBCZXNpZGVzIHRoZSBjYXRlZ29yaXNhdGlvbiBpbnRvIFNlbGVjdGlvbiwgQ29u bmVjdGlvbiwgYW5kIE1lc3NhZ2UNClByb3BlcnRpZXMsDQo+ID4gd2UgYWxzbyBoYXZlIGRpZmZl cmVudCBraW5kcyBvZiBUcmFuc3BvcnQgUHJvcGVydGllczoNCj4gPiAtIEdlbmVyaWMgUHJvcGVy dGllcyAobW9zdCBwcm9wZXJ0aWVzIGluIHRoZSBBUEkgZHJhZnQgZmFsbCBpbiB0aGlzDQpjYXNl KQ0KPiA+IC0gUHJvdG9jb2wgU3BlY2lmaWMgUHJvcGVydGllcyAoZS5nLiwgcHJvcGVydGllcyB0 byBjb250cm9sIGNlcnRhaW4NClRDUCB0aW1lcnMpDQo+ID4gLSBWZW5kb3Igb3IgSW1wbGVtZW50 YXRpb24gU3BlY2lmaWMgUHJvcGVydGllcw0KPiA+DQo+ID4gVG8gYWxsb3cgYSBUQVBTIHN5c3Rl bSB0byBiZSBleHRlbmRhYmxlLCB3ZSB3YW50IHRvIHNlcGFyYXRlIHRoZXNlDQpvdXQgYnkNCj4g PiBhZGRpbmcgYSBuYW1lc3BhY2UgcHJlZml4IHRvIHRoZSBUcmFuc3BvcnQgUHJvcGVydGllcy4N Cj4NCj4gU28gdGhlIG5hbWVzcGFjZSBxdWVzdGlvbiBvbmx5IHJlYWxseSBiZWNvbWVzIGludGVy ZXN0aW5nIGlmIHdlDQpwcmVzdW1lIHdlIHdhbnQgdG8gaGF2ZSBhIHJlZ2lzdHJ5IHdpdGggb3Ro ZXIgdGhhbiBTdGFuZGFyZHMgQWN0aW9uDQpwb2xpY3kuIEJ1dCBpZiB3ZSBwcmVzdW1lIHRoYXQu Li4NCj4NCj4gQmlrZXNoZWQgcXVlc3Rpb24gbnVtYmVyIDE6IGRvIHdlIHdhbnQgdG8gc2VwYXJh dGUgbmFtZXNwYWNlIHByZWZpeGVzDQp3aXRoIHVuZGVyc2NvcmVzIGFzIHdpdGggc3BhY2VzLCBv ciB3aXRoIHNvbWUgb3RoZXIgY2hhcmFjdGVyPyBpLmUuIHRvDQp1c2UgYSB0b3J0dXJlZCBleGFt cGxlIHdvdWxkIGl0IGJlIHNvbWV0aGluZyBsaWtlDQp0Y3AucmV0cmFuc21pc3Npb25fdGltZW91 dCBvciB0Y3BfcmV0cmFuc21pc3Npb25fdGltZW91dD8gKEknbSBib3Jyb3dpbmcNCmZyb20gc3lz Y3RsIG5hbWVzcGFjZXMgYSBsaXR0bGUgaGVyZSkNCj4NCj4NCj4gPiBBcyBhIGZpcnN0IHByb3Bv c2FsLCBJIGZhdm91ciB0aGUgZm9sbG93aW5nDQo+ID4gLSBHZW5lcmljIHByb3BlcnRpZXMgZnJv bSB0aGUgQVBJIGRyYWZ0IG9yIGRlZmluZWQgYnkgYW4gUkZDIGNhcnJ5DQpubw0KPiA+ICAgbmFt ZXNwYWNlIHByZWZpeC4NCj4NCj4gVGhpcyBtYWtlcyBzZW5zZS4NCj4NCj4gPiAtIFByb3RvY29s IFNwZWNpZmljIFByb3BlcnRpZXMgbXVzdCBjYXJyeSB0aGUgcHJvdG9jb2wgYWNyb255bSBhcw0K PiA+ICAgcHJlZml4LCBlLmcuLCDigJx0Y3AiIGZvciBUQ1Agc3BlY2lmaWMgVHJhbnNwb3J0IFBy b3BlcnRpZXMuDQo+ID4gICBGb3IgSUVURiBwcm90b2NvbHMsIHByb3BlcnR5IG5hbWVzIHVudGVy IHRoZXNlIG5hbWVzcGFjZXMgc2hvdWxkDQo+ID4gICBiZSBkZWZpbmVkIGluIGFuIFJGQy4NCj4N Cj4gVGhpcyBhbHNvIG1ha2VzIHNlbnNlLg0KPg0KPiA+IC0gVmVuZG9ycyBvciBpbXBsZW1lbnRh dGlvbiBzcGVjaWZpYyBwcm9wZXJ0aWVzIG11c3QgcHJlZml4IHdpdGggdGhlDQo+ID4gICB2ZW5k b3Igb3IgaW1wbGVtZW50YXRpb27igJlzIG5hbWUuDQo+DQo+IEJpa2VzaGVkIHF1ZXN0aW9uIG51 bWJlciAyOiB5b3UgcHJvYmFibHkgbmVlZCBhIHJlZ2lzdHJ5IG9mIHZlbmRvcg0KbmFtZXNwYWNl cy4gd2hhdCdzIHRoZSBwb2xpY3kgb24gY3JlYXRpbmcgdGhvc2U/IERvIHdlIHJlYWxseSB3YW50 IHRvDQpjcmVhdGUgYW5vdGhlciBQRU4tbGlrZSB0aGluZz8NCj4NCj4gPiAtIEV4cGVyaW1lbnRh bCBvciBsb2NhbC11c2UgcHJvcGVydGllcyBtdXN0IGJlIFByZWZpeGVkIHdpdGggYW4gWCBvcg0K WS4NCj4NCj4gSSBkb24ndCBsaWtlIHRoaXMuIE1JTUUgaGVhZGVycyB1c2VkIHRvIHVzZSB0aGUg WC0gcHJlZml4LCBidXQgdGhpcw0KaGFzIGJlZW4gZGVwcmVjYXRlZCBiZWNhdXNlIHRoZSBwcmVz dW1wdGl2ZSBzZW1hbnRpYyBiZW5lZml0IG9mIHRoaXMgLS0NCnlvdSBjYW4gc2VlIHdoaWNoIGJp dHMgYXJlIGV4cGVyaW1lbnRhbCAtLSBkaXNhcHBlYXJzIGJlY2F1c2Ugbm9ib2R5DQpldmVyIHJl cGxhY2VzIGV4cGVyaW1lbnRhbCBpZGVudGlmaWVycyB3aGVuIGV4cGVyaW1lbnRzIHRyYW5zaXRp b24gdG8NCnByb2R1Y3Rpb24uDQo+DQo+ID4gT3BlbiBRdWVzdGlvbnM6DQo+ID4gLS0tLS0tLS0t LS0tLS0tDQo+ID4NCj4gPiAtIERvIHdlIG5lZWQgYW4gSUFOQSByZWdpc3RyeSBmb3IgR2VuZXJp YyBQcm9wZXJ0aWVzPw0KPg0KPiBUaGF0IGRlcGVuZHMgb24gd2hhdCB3ZSB0aGluayB0aGUgZXh0 ZW5zaW9uIG1lY2hhbmlzbSBmb3IgdGhlIFRBUFMgQVBJDQppcy4gSSB0ZW5kIHRvIHRoaW5rIG5v OiBuZXcgZXh0ZW5zaW9ucyB0byB0aGUgQVBJIHdpbGwgcmVxdWlyZSBhDQpzdGFuZGFyZHMgYWN0 aW9uLCBhbmQgcHJvYmFibHkgZXZlbiBuZWVkIHRvIHVwZGF0ZSB0aGUgY29yZSBUQVBTIEFQSQ0K ZG9jcy4NCj4NCj4gPiAtIERvIHdlIG5lZWQgYW4gSUFOQSByZWdpc3RyeSBmb3IgUHJvcGVydHkg TmFtZXNwYWNlcz8NCj4NCj4gTWF5YmU/DQo+DQo+ID4gLSBEbyB3ZSBuZWVkIHRvIHJlcXVlc3Qg YW4gSUFOQSByZWdpc3RyeSB3aXRoIHRoZSBBUEkgZG9jdW1lbnQNCj4gPiAgb3IgbWF5IHdlIHBv c3Rwb25lIHRoZSBhYm92ZSBkZWNpc2lvbnM/DQo+DQo+IEknbSBpbmNsaW5lZCB0byBhc3NpZ24g bmFtZXMgKHdpdGggZ2VuZXJpYyBhbmQgcHJvdG9jb2wtc3BlY2lmaWMNCm5hbWVzcGFjZXMpIGFu ZCBsZWF2ZSB0aGUgd2hvbGUgdmVuZG9yL3JlZ2lzdHJ5IHRoaW5nIGFzIGZ1dHVyZSB3b3JrLA0K YmVjYXVzZSBkZWZpbmluZyBhIHJlZ2lzdHJ5IHdlbGwgaXMgaGFyZCwgYW5kIEknbSBub3Qgc3Vy ZSBzdWNoIGEgdGhpbmcNCndpbGwgZXZlciBiZSB1c2VkLiBJdCdzIGEgbG90IHRvIGRvIHVwIGZy b250Lg0KPg0KPiA+IC0gV2hlcmUgZG8gd2Ugd2FudCB0byBkZWZpbmUgdGhlIHJ1bGVzIGZvciBu YW1pbmcgVHJhbnNwb3J0DQpQcm9wZXJ0aWVzIGFuZCBOYW1lc3BhY2VzPw0KPg0KPiBDb25zaXN0 ZW50IHdpdGggbXkgb3BpbmlvbiBhYm92ZTogbmFtZSB0aGUgdHJhbnNwb3J0IG5hbWVzcGFjZXMg aW4NCnRoaXMgZG9jLCBsZWF2ZSBhbGwgb3RoZXIgcnVsZXMgYXMgZnV0dXJlIHdvcmsuDQo+DQo+ IENoZWVycywNCj4NCj4gQnJpYW4NCj4NCj4gPg0KPiA+IEFWRSENCj4gPiAgUGhpbGlwcCBTLiBU aWVzZWwgLyBwaGlsc+KApg0KPiA+IC0tDQo+ID4NCntwaGlsc30tLS0+LS0tKHBoaWxzQGluLXBh bmlrLmRlKS0tLT4tLS0oaHR0cDovL3BoaWxzLmluLXBhbmlrLmRlKS0tLS0sDQo+ID4gICAgICB3 ZW5uIHcgZWluZSAgIGF1YmUgaXN0IGRuICAgICAgbWFuIGF1IGRyYW4gZHJlIGVuDQogICAgIHwN Cj4gPiAgICAgICAgICAgbyAgICAgU2NociAgICAgICAgYW4gbXVzcyAgICAgaGMgICAgICAgICBo ICAgKEt1cnQNClNjaHdpdHRlcnMpIHwNCj4gPiA6d3EhICA8LS0tLShwaG9uZTogKzQ5LTE3OS02 NzM3NDM5KS0tLTwtLS0oamFiYmVyOg0KcGhpbHNAaW4tcGFuaWsuZGUpLS0tLScNCj4gPg0KPiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gVGFw cyBtYWlsaW5nIGxpc3QNCj4gPiBUYXBzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby90YXBzDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IFRhcHMgbWFpbGluZyBsaXN0DQo+IFRhcHNAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90YXBzDQo+DQoNCg== From nobody Mon Feb 25 07:05:27 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B05130EE3 for ; Mon, 25 Feb 2019 07:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yg-xcmr2_xv4 for ; Mon, 25 Feb 2019 07:05:19 -0800 (PST) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 9A4741289FA for ; Mon, 25 Feb 2019 07:05:18 -0800 (PST) Received: by mail-qk1-x72a.google.com with SMTP id r21so5421604qkl.11 for ; Mon, 25 Feb 2019 07:05:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:references:mime-version :content-transfer-encoding; bh=SdAFp3EYwTDNr4A6BVvQaUhvwYuugcWQU3/ej38Trsg=; b=Ta4ZEeFbW+QWu8FFga02ebb05DibMAHtpgMJe1Yzz8okHezeCiVRBLdUfAu7hdN+UV cfd8Yewr1YAEaF70BJKaRI0k2IBOmETmLzHDCpcGiQ+KvW5+bEIigcJBxPHjqHE3f9xM lrKup32tX7ovooQiDx5HMs2cj45OViOjVd2t8xsKRkfptzGgh16Lrdul8iqDUqbaUUMP TGDUMwR1uruARl9Ko1a6Suk+rPojWoTFA6S1tFgaMvteZrnCEP9dcq9bJy17ENP4swn4 9fn90EJYfbOu2PM4tMsJ5no1OcbEv+SefCVeagzEeE4EBQJopok7z2CIaNef6SknWvaG NLkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:references :mime-version:content-transfer-encoding; bh=SdAFp3EYwTDNr4A6BVvQaUhvwYuugcWQU3/ej38Trsg=; b=KiORQ61EU2+yrpcppTLPY9QSUY54RhNiZaYFYhruc59cL2pwSjHxzxp15lSSdqkkLa Z7gSgsqRSoBC2mUN/eb2QmmtVcpxNXfZKqY4FqgAkMN8PWfgMwV9Jky3J1VFBAScshrE YQLXWZUVpzIuwFhh7L3y4jfnZmNi34fSyLFxvI3b2uibnSFpNgprOZqOdaQqhqiHTrYb gcEaNqni62H4XW6Rm4Lf7MnkAeKggZN8rCEVPfTT+I1T8wkDI4660R46G60fdi8vJTM+ sI7uaWxm1f7PjQsm5dF/wN7MlSt3WAc5/AinqNuh/JHubBaL+AFChp4QweAHYATRX1PI N8uw== X-Gm-Message-State: AHQUAub3VOpO7q642rVeht/pAdI7L1pkd5XZq7ocZEC7aBw+F8I95zlK 7KJ9c76QKT+b4omd4cRBhgo1HLjI X-Google-Smtp-Source: AHgI3IYsPawjALhy3Mh41MCOx18HLh3JhVBbxRGvGkKOBUReBIhXmjSPqlLIu7e2yEXmmcDzMuAuCQ== X-Received: by 2002:a37:d98c:: with SMTP id q12mr12715220qkl.286.1551107116965; Mon, 25 Feb 2019 07:05:16 -0800 (PST) Received: from [172.19.38.65] ([2001:4878:a000:3000:58f0:ee98:52b0:65bc]) by smtp.gmail.com with ESMTPSA id b24sm6804127qta.76.2019.02.25.07.05.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Feb 2019 07:05:16 -0800 (PST) From: "Aaron Falk" To: "taps WG" Date: Mon, 25 Feb 2019 10:05:12 -0500 X-Mailer: MailMate (1.12.4r5594) Message-ID: <58501444-A2B8-4B1A-9912-90F6D1ECD804@gmail.com> References: <155088034379.5518.4616383450543152946.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_3FE75BB4-47C5-4F80-8B6D-17B9ACB789DC_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: [Taps] TAPS meeting in Prague X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 15:05:26 -0000 --=_MailMate_3FE75BB4-47C5-4F80-8B6D-17B9ACB789DC_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit Just a heads-up that the TAPS session at IETF-104 is currently scheduled for Friday 10:50 - 12:50. The preliminary agenda always changes but you may want to factor this into your travel plans since sometimes folks leave before the Friday sessions conclude. --aaron Forwarded message: > From: IETF Agenda > To: IETF Announcement List > Cc: recentattendees@ietf.org, ietf@ietf.org, 104all@ietf.org > Subject: IETF 104 Preliminary Agenda > Date: Fri, 22 Feb 2019 16:05:43 -0800 > > IETF 104 > Prague, Czech Republic > March 23-29, 2019 > Hosts: Cisco and CZ.NIC > > The IETF 104 Preliminary Agenda has been posted. The final agenda will > be published on Friday, March 1, 2019. > > https://datatracker.ietf.org/meeting/104/agenda.html > https://datatracker.ietf.org/meeting/104/agenda.txt > > > IETF 104 Information: https://www.ietf.org/how/meetings/104/ > Register online at: https://www.ietf.org/how/meetings/register/ > > Don’t forget to register for these exciting IETF 104 events! > > Hackathon > Signup: > https://www.ietf.org/registration/ietf104/hackathonregistration.py > More information: > https://www.ietf.org/how/runningcode/hackathons/104-hackathon/ > Keep up to date by subscribing to: > https://www.ietf.org/mailman/listinfo/hackathon > > Code Sprint > Signup: > https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF104SprintSignUp > More information: > https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF104Sprint --=_MailMate_3FE75BB4-47C5-4F80-8B6D-17B9ACB789DC_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Just a heads-up that the TAPS session at IETF-104 is curre= ntly scheduled for Friday 10:50 - 12:50. The preliminary agenda always c= hanges but you may want to factor this into your travel plans since somet= imes folks leave before the Friday sessions conclude.

--aaron

Forwarded message:

From: IETF Agenda <agenda@ietf.o= rg>
To: IETF Announcement List <ietf-announce@ietf.org>
Cc: recentattendees@ietf.org, ietf@ietf.org, 104all@ietf.org
Subject: IETF 104 Preliminary Agenda
Date: Fri, 22 Feb 2019 16:05:43 -0800

IETF 104
Prague, Czech Republic
March 23-29, 2019
Hosts: Cisco and CZ.NIC

The IETF 104 Preliminary Agenda has been posted. The final agenda will be= published on Friday, March 1, 2019.

https://datatracker.ietf.org/meeting/104/agenda.html
= https://datatracker.ietf.org/meeting/104/agenda.txt


IETF 104 Information: https://www.ietf.org/how/meetings/104/
Register online at: https://www.ietf.org/how/meetings/register/
Don=E2=80=99t forget to register for these exciting IETF 104 events!

Hackathon
Signup: https://www.ietf.org/registration/iet= f104/hackathonregistration.py
More information: https://www.ietf.org/how/runnin= gcode/hackathons/104-hackathon/
Keep up to date by subscribing to:
https://www.ietf.org/mailman/listinfo/hackathon

Code Sprint
Signup: https://trac.tools.ietf.org/tools/ietf= db/wiki/IETF104SprintSignUp
More information: https://trac.tools.ietf.org/tools/= ietfdb/wiki/IETF104Sprint

--=_MailMate_3FE75BB4-47C5-4F80-8B6D-17B9ACB789DC_=-- From nobody Tue Feb 26 21:29:23 2019 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A85B130E2E; Tue, 26 Feb 2019 21:29:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: taps@ietf.org Message-ID: <155124535499.707.1548277438288651136@ietfa.amsl.com> Date: Tue, 26 Feb 2019 21:29:15 -0800 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-transport-security-05.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 05:29:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services WG of the IETF. Title : A Survey of Transport Security Protocols Authors : Christopher A. Wood Theresa Enghardt Tommy Pauly Colin Perkins Kyle Rose Filename : draft-ietf-taps-transport-security-05.txt Pages : 37 Date : 2019-02-26 Abstract: This document provides a survey of commonly used or notable network security protocols, with a focus on how they interact and integrate with applications and transport protocols. Its goal is to supplement efforts to define and catalog transport services [RFC8095] by describing the interfaces required to add security protocols. It examines Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + TLS), tcpcrypt, Internet Key Exchange with Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, CurveCP, MinimalT. This survey is not limited to protocols developed within the scope or context of the IETF, and those included represent a superset of features a TAPS system may need to support. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-transport-security-05 https://datatracker.ietf.org/doc/html/draft-ietf-taps-transport-security-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transport-security-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 26 21:33:48 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E633C130E2E; Tue, 26 Feb 2019 21:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fvz7owjMh_xy; Tue, 26 Feb 2019 21:33:43 -0800 (PST) Received: from mail-yw1-xc29.google.com (mail-yw1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (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 22B8812D4EC; Tue, 26 Feb 2019 21:33:40 -0800 (PST) Received: by mail-yw1-xc29.google.com with SMTP id k14so7169880ywe.4; Tue, 26 Feb 2019 21:33:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=d1PRIgTVME4dLtjoPufWhRCZNNYWoTIfO7kQHxKjirQ=; b=AMi6JvyiVG8gn5bBriwD3I+4nOns8gLrXMGCWGQpjJxkufFtVg1vpQUr2jq9ub3Su3 QUefIHohbYBOjFYcJF3vYEJaS3xr7AofbyMPl6r4hijaCCtDGoh/ResoePoAMjmfdkIP ACXMnWXUVsgpcUYoG2j3B3czJo3dLmw2b9BtLdoI6Tl8QUSiO1rI/C3BMqDFEyZqQ504 8HntodNJCgBrwJ7Sr5C56ds1Oz8nukVMfNxVU/dn6VYJYWphRZm9HSXh9MZYoQn3Me5E T8r3ZoDZhbtZOB7y+85EFYvQMmlGdO1AM6WDjhC3dw0NVdRCqoWivoA0YlmeuwM36RHM p/jw== 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=d1PRIgTVME4dLtjoPufWhRCZNNYWoTIfO7kQHxKjirQ=; b=saUpNvJ+f1wtFV6UKGQGFoypx3Tp9cAigm0JOPl9HdFVj2oQB7tjnNCF38oHux7YMq 1LRonByAOr4JcTAvNU76klWWzhDPa/sVD8jqD8ZUk8j0/L1B99ukOdWDSyGzq/saCpkL fF87I16qOsRIXZKj/wEA03ngEEfyluSqxdGkvwCSsxNeARYmpwNK9miLJy6o6dCFvOsc YPKKrYC4uCF2Ni8k7qeWjg557wHGkJqCydtoQ1WzCbE5YCSnbd7icmshSDcLUKkbTWPq H4Y68p3fXAnW0pyRSLXr3HKg20PJ/GblsGXzawDCjDiNFNy/03+V5acjSLa331EiqQeo 2S6Q== X-Gm-Message-State: AHQUAuadSN8NDAXL/mmwpnddIqwyFK0a+GYn0lCA4BEBxiA+fGaUMYMb Gsnbk3QrB1QtVNW0Q4aoSaSC2rTQeEI1zfE7Cic7Is/w X-Google-Smtp-Source: AHgI3IaT6N1Hi07uqA+URfVilYQsqxskDxGqLALTLD1js/YsLsWTDH4IbHZOkveaEhB5LHOH03yXb33kG44aaR29Myo= X-Received: by 2002:a81:83c1:: with SMTP id t184mr21543529ywf.350.1551245619057; Tue, 26 Feb 2019 21:33:39 -0800 (PST) MIME-Version: 1.0 References: <154321083813.24275.4373340388504093292@ietfa.amsl.com> <03808BD3-11AA-4010-9B8D-7E33EC1FE39B@gmail.com> In-Reply-To: <03808BD3-11AA-4010-9B8D-7E33EC1FE39B@gmail.com> From: Christopher Wood Date: Tue, 26 Feb 2019 21:33:27 -0800 Message-ID: To: Paul Wouters Cc: secdir@ietf.org, draft-ietf-taps-transport-security.all@ietf.org, taps WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Taps] Secdir early review of draft-ietf-taps-transport-security-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 05:33:47 -0000 Hi Paul, We just posted a revision to this document incorporating updates based on your comments [1]. (Thanks again for your careful review!) If you have time to check the diffs, we would greatly appreciate any more feedback you may have. Best, Chris [1] https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ On Mon, Dec 3, 2018 at 7:56 AM Christopher Wood wrote: > > (ietf to bcc to minimize spam) > > Hi Paul, > > Thanks for the feedback! Please see inline below. > > On 25 Nov 2018, at 21:40, Paul Wouters wrote: > > > Reviewer: Paul Wouters > > Review result: Has Issues > > > > Review of draft-ietf-taps-transport-security-04 > > > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the > > IESG. These comments were written primarily for the benefit of the > > security area directors. Document editors and WG chairs should treat > > these comments just like any other last call comments. > > > > The summary of the review is HAS ISSUES. > > > > SecDir tools note: The secdir review link refers to an abstract > > containing the > > text: > > > > This draft summarizes a number of IETF transport security > > protocols a > > > > Note the word "IETF ... protocols". I don't actually see that in any > > of the > > revisions 00 to 04? Where did this comment/text come from? > > As Spencer noted, it likely originated from the early review request. > > > > > Reading the introduction, this draft's goal is: > > > > This document provides a survey of commonly used or notable network > > security protocols, with a focus on how they interact and integrate > > with applications and transport protocols. Its goal is to > > supplement > > efforts to define and catalog transport services [RFC8095] by > > describing the interfaces required to add security protocols. > > > > My first comment is regarding "commonly used or notable". Especially > > the latter one is odd. Why should the IETF reader be aware of > > "notable" but "not commonly used" protocols? And the reason I > > say this is because it lists CurveCP and MinimalT, which as far > > as I know are not deployed at all. While openvpn, which has a > > serious userbase, is not mentioned at all. And openconnect, an open > > specification compatible with Cisco Anyconnect, which even has a > > draft, > > draft-mavrogiannopoulos-openconnect-02, is not mentioned at all. In my > > opinion, the document would be improved by adding Openvpn and > > Openconnect, > > and removing CurveCP and MinimalT. > > > > My second comment is regarding IETF vs non-IETF protocols. Or even > > "specified in a draft or RFC" versus "there is an academic paper and > > some > > implementation and it's not clear what's what". The reason I am saying > > this is that for instance the protocol "specification" of WireGuard > > keeps > > changing. Their website lists a "whitepaper" that is changing over > > time > > with no changelog, and wild claims that I've spend time in the last > > few > > years to counter, upon which it gets rewritten with new misleading or > > wrong claims. > > > > It is kind of hard to do an IETF style summary of protocols when the > > "specification" includes phrases like: > > > > the tunnel simply works. Key exchanges, connections, > > disconnections, > > reconnections, discovery, and so forth happen behind the > > scenes > > transparently and reliably, and the administrator does not > > need to > > worry about these details. In other words, from the > > perspective of > > administration, the WireGuard interface appears to be > > stateless. > > > > This is not a white paper but a Public Relations document. > > > > None of the other discussed protocols in this document require > > administrators to "worry" about those "details" either. > > > > At the IETF, we recommend IETF protocols. If someone comes up with an > > alternative protocol that accomplishes the same as an existing one, we > > tend to tell people to use the existing IETF protocol instead. Or, we > > think their new protocol merits further standarization, and we ask > > them > > to produce either a ISE or IETF stream document that people can > > reference, > > comment, improve and discuss openly on its technical merits. > > > > It is also clear the white paper is not a good complete formal > > specification like we do at IETF. For example, if there is packetloss, > > the "specification" does not at all specify which of the parties (or > > both?) are responsible for retransmission. Can one spoofed packet lead > > a WireGuard endpoint to retransmit its response repeatedly? > > > > This further weakens their "stateless" claim. (and if it sounds like I > > am being harsh, I know I am. It is because previously, I had to > > counter > > false claims about IPsec speed, and IKE "being noisy" where as having > > looked again at "the whitepaper" (which keeps changing every time I > > look > > at it) it seems to now have a new hobby horse in the word "stateless". > > the > > openvpn tun0: is also "stateless", so is the VTI IPsec based interface > > vti0: > > > > Because of these reasons, I am a bit worried that an IETF document is > > making any claims about WireGuard features, as there is no way to know > > what the protocol will be like by the time this document is published, > > and this document cannot even point to a stable reference of te > > specification > > at the time of review. > > > > If this document wants to mention WireGuard as a protocol to take note > > of, > > I would like to see at least some text there urging WireGuard to write > > up > > (and version) their protocol in an IETF draft/RFC or other > > proper/formal > > specification. > > > > Now, having said all of this about WireGuard, I do agree with > > mentioning > > WireGuard in this document as it does have an actual userbase. Let's > > just urge and help them with their specification. (and If the > > author(s) > > of WireGuard are reading this, I am more than happy to help you with > > this) > > > > As for CurveCP and MinimalT, as far as I can see, these are just > > academic > > exercises with no serious deployment. While the IRTF might be > > discussing > > the these, I don't think an IETF document should reference these two > > proof of concept ideas until they have matured more. > > Protocol selection criteria was admittedly sort of ad-hoc in the > beginning. For starters, we included CurveCP and MinimalT because they > are unique in one way or another in contrast to the other protocols > considered. We then included WireGuard specifically because of its > (growing) popularity. And while it continues to grow, we are careful to > ensure the core feature set described remains stable. The informal > criteria we=E2=80=99ve established now is that any new protocol must brin= g > something new to the table. For example, we added protocols such as SRTP > because they had features not yet covered by other protocols. > > That said, we can certainly add OpenVPN and OpenConnect to round things > out. Though I see no issue with including CurveCP and MinimalT. As > stated in the introduction, this document is not restricted to IETF > protocols. Rather, it aims to survey any protocol that might influence > the API surface exposed. It is our opinion that the set of protocols > included meets this goal. If necessary, we can move the more esoteric > protocols to the appendix, though we should certainly not remove them > for lack of a specification. > > > > > Introduction / Abstract: > > > > Expand/explain TAPS on first use? > > > > Section 4.4.1.1: > > > > IKEv2 is a control protocol that runs on UDP port 500 > > > > Change to: > > > > IKEv2 is a control protocol that runs on UDP or TCP port 4500 and UDP > > port 500. > > > > Note you don't mention the one big drawback, that it cannot be run on > > any UDP > > port (although at least now we can run on any TCP port) which is an > > important > > problem when networks block IKE/IPsec on purpose compared to non-IETF > > VPN > > protocols. > > > > It then > > goes through a phase of authentication in which both peers > > present > > blobs signed by a shared secret or private key, after which > > another > > set of keys is derived, referred to as the "Child SA". These > > Child > > SA keys are used by ESP. > > > > This text makes it appear only the blob's are authenticated, but the > > entire > > IKE exchange is authenticated. Also sessions keys are not all that is > > a > > Child SA. So perhaps: > > > > IKE then > > performs a phase of authentication in which both peers present > > blobs signed by a shared secret or private key that authenticates > > the entire IKE exchange and the IKE identities. IKE then derives > > further sets of keys on demand, which together with traffic policies > > are referred to as the "Child SA". These Child SA keys are used by > > ESP. > > > > Each proposal may contain an encryption algorithm, an > > authentication > > algorithm > > > > This is a bit misleading with both the "may" and the lack of AEAD > > discussion? > > Perhaps: > > > > Each proposal contains an encryption with authentication algorithm or > > an AEAD > > algorithm, > > > > Any SA used by IKEv2 can be rekeyed upon expiration, > > > > Rekeying happens before expiration, not upon (which would imply > > trafficflow > > interuption) Similarly to how it is described for tcpcrypt in the > > document. So > > perhaps just change "upon" to "before" ? Or go in a little more detail > > with: > > > > Any SA used by IKE/IPsec can be rekeyed before expiration. It does so > > by > > negotiating a second SA, and once confirmed up and running, the old SA > > is > > deleted. This guarantees there is no slowdown or halt of traffic flow > > during > > rekeying. > > > > that allows a set of Security Associations to migrate over > > different > > addresses and interfaces > > > > I would say "different outer IP addresses and interfaces" > > > > Each SA is > > identified by a Security Parameter Index (SPI), which is > > marked on > > each encrypted ESP packet. > > > > I would avoid the word "mark" here, since to me that more presents > > internal > > state inside a kernel (eg iptables MARK) and not something that goes > > over the > > wire. So perhaps: > > > > The SA of an encrypted packet is identified by its Security Parameter > > Index > > (SPI) [which is send as part of the ESP header) > > These are all great suggestions! We will include them. > > > > > an anti-replay service (a form of partial sequence integrity) > > > > What is partial about this? Perhaps you meant to say ESP, like UDP, > > does not > > provide guaranteed delivery? Anyway, a "partial" security function > > reads odd :) > > This is quoted text from RFC4303. > > > > > and limited traffic flow confidentiality. > > > > What is "limited" about it? You can generate bogus traffic and pad > > traffic to > > any size (most common max mtu). What would you want in additional to > > make it > > not "limited" ? > > This text is also quoted from RFC4303, so we left it as is. Though I > think your suggestions point to what the authors are leading towards: > traffic analysis. > > > > > One thing I would add to the ESP section is mentioning it acts like > > UDP. It > > cannot be reset by a single TCP RST packet, and you don't have two > > layers of > > netflows doing retransmission. This feature of ESP (and some UDP based > > protocols in this document) is fairly important. > > > > Section 4.4.2.1: > > > > Mutual Authentication > > > > It is possible to do server-only or opportunistic/anonymous IKE as > > well. Maybe > > add "Usually" ? > > ACK =E2=80=94 will do. > > > > > 4.6.1: > > > > Tcpcrypt exposes a universally-unique connection-specific > > session ID > > to the application, suitable for application-level endpoint > > authentication either in-band or out-of-band. > > > > This kind of conflicts with the introduction that claims this is only > > an > > opportunistic encryption protocol? Maybe merge this part into the > > description > > text? > > Good observation. Yes, that is misleading. We=E2=80=99ll try to fix it. > > > > > 4.6.2: > > > > I might say here something about only passive attacker protection? > > That seems > > like an important difference compared to the other protocols. Or > > perhaps make > > this clear in the introduction text when mentioning opportunistic > > encryption. > > Yes, good point. We=E2=80=99ll fix that. > > > > > 4.7: > > > > WireGuard is a layer 3 protocol designed to complement or > > replace > > IPsec [WireGuard] for certain use cases. > > > > I am confused about how it "complements" IPsec? Perhaps you mean it is > > an > > "alternative" (and perhaps a non-IETF alternative) ? > > > > I think "replace" is very misleading, as IPsec has a vast number of > > different > > use cases compared to WireGuard's "static VPN configuration". > > Yes, we should drop =E2=80=9Cto complement or replace=E2=80=9D and say th= at it=E2=80=99s > an alternative. > > > > > WireGuard is designed to be entirely stateless, modulo the > > CryptoKey > > routing table, > > > > Wouldn't you be able to say the same about the ESP SPD/SAD table? I'm > > not sure > > how different the ESP/wireguard statelessness is on a scale or truly > > stateless > > to NFS > > > > You don't mention anything about port preconfiguartion and the "port > > knocking" > > thing? > > > > o Record replay prevention (Stateful, timestamp-based). > > > > I thought it was stateless module CryptoKey routing? :) > > > > You do not mention mobility or session resumption for WireGuard. Since > > it is > > all about static inner IP addresses over arbitrary outer addresses, it > > has > > mobility. And I guess the 1RTT means it has session resumption? > > > > Can you add a description of rekeying for WireGuard similar to > > IKEv2/ESP? I > > thought there was an issue there that during rekey, there is no > > continued data > > flow possible, so connections briefly slow down or halt when the > > channel is > > being rekeyed. > > I=E2=80=99m on the fence about this suggestion (and about keeping the > IKEv2/ESP rekeying text). Some of the feedback we=E2=80=99ve received thu= s far > is that the internal protocol details are irrelevant to the overall > story. Rekeying might fall in that category. We=E2=80=99ll play with it a= nd > see if we can find a happy medium. > > > > > Does WireGuard not offer padding or any other kind of Traffic > > Confidentiality > > options ? > > As far as I know, it does not. > > > > > 4.8: > > > > The MinimalT section seems to lack some information bullet points > > compared to > > the other sections? eg shouldn't it have things like: o Datagram > > Transport ? > > Indeed! This section needs some improvement. > > > > > Misc: > > > > Should tor be added to the list of protocols? > > We hadn=E2=80=99t considered it, though it might be worth including. If w= e can > find a new feature not yet exposed by the others, then yes, by our > criteria outlined above. > > > > > Why are MinimalT and CurveCP part of this list? Is there any actual > > deployment > > out there? I thought this document described actual transport security > > protocols people can pick. I don't see CurveCP as a real candidate for > > this. I > > don't know about MinimalT. > > As stated above, ease of use or popularity in practice is not the only > filter we used. I=E2=80=99m therefore inclined to keep these. > > > > > 5: > > > > I'm a little confused by the term Application in this section. Is this > > the > > enduser application or the userland part of the security protocol (eg > > IKE). I > > think you mean the application of the enduser? > > Yes, the application of the enduser. > > > > > > 5.1: > > > > Listed as mandatory feature is: > > > > o Public-key certificate based authentication. > > > > Yet you have mentioned that neither WireGuard or CurveCP can do > > authentication > > based on certificates? > > Indeed. This should read, =E2=80=9CPublic-key (raw or certificate) based > authentication.=E2=80=9D > > > > > 5.2: > > > > o Length-hiding padding (LHP): > > > > * Application dependency: Knowledge of desired padding > > policies. > > > > This is not (always?) true? For example ESP can do padding after IKE > > negotiated > > it, and do it based on MTU ? The (end user) application does not have > > to be > > aware of anything? > > That=E2=80=99s a fair point, though (in my view) padding without applicat= ion > input seems incomplete. Perhaps we can rephrase this to: > > =E2=80=9C(Optional) Application dependency: Knowledge of desired paddi= ng > policies. Some protocols, such as IKE, can negotiate > application-agnostic padding policies.=E2=80=9D > > > > > 5.3: > > > > The definition of "Mandatory" within this section is confusing. Maybe > > use > > another word like "Core" to indicate it is part of the core of the > > protocol and > > cannot be disabled? > > We used mandatory to be consistent with the section above. > > > > > NITS: > > > > spelling error: defailt > > Oops. Will fix! > > Thanks again for your careful review and feedback. We greatly appreciate > it. > > Best, > Chris et al. From nobody Wed Feb 27 07:29:57 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE64F130E71; Wed, 27 Feb 2019 07:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 QbpCOdfxGjK0; Wed, 27 Feb 2019 07:29:48 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.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 47CAA128CE4; Wed, 27 Feb 2019 07:29:48 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 448fkK3LKkzCg1; Wed, 27 Feb 2019 16:29:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1551281385; bh=Qb+o0RP13xCIrNfXz4k5c4WRkjyZWnAEySpGwVNZ8jU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=iHjG3WoY7BHNGNj/WItz7XvI9G8qTqMk8rXmbfsJI30B6FATOw3jetjXSmirDiss0 I8v4yu0SOK27QhReiapoW++UXm4Gkyx1avS+KRCuYVRK4EsWKSZCZBd9NtpRIgXPfg oRdY07PPuGFCqBA1pzb9+83oe4qdYtYqdh1VKznk= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id F_EQq6YB9K63; Wed, 27 Feb 2019 16:29:43 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 27 Feb 2019 16:29:43 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 362EFA7E0C; Wed, 27 Feb 2019 10:29:42 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 362EFA7E0C Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2CB9940D358A; Wed, 27 Feb 2019 10:29:42 -0500 (EST) Date: Wed, 27 Feb 2019 10:29:42 -0500 (EST) From: Paul Wouters To: Christopher Wood cc: secdir , draft-ietf-taps-transport-security.all@ietf.org, taps WG In-Reply-To: Message-ID: References: <154321083813.24275.4373340388504093292@ietfa.amsl.com> <03808BD3-11AA-4010-9B8D-7E33EC1FE39B@gmail.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [Taps] Secdir early review of draft-ietf-taps-transport-security-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 15:29:51 -0000 On Tue, 26 Feb 2019, Christopher Wood wrote: > We just posted a revision to this document incorporating updates based > on your comments [1]. (Thanks again for your careful review!) If you > have time to check the diffs, we would greatly appreciate any more > feedback you may have. In general, the changes look good to me, although I still have reservations about some of the toy protocols mentioned which just gives them too much credibility. Thanks for adding openvpn. I see you did not add openconnect/anyconnect, and kept in curvecp/minimalt. Not my preference but if that's what the WG wants, I'm okay with it. Note that the latest openvpn version now uses AES-GCM per default, so perhaps you can excorsise blowfish from the document because Bruce said not to use it like over a decade ago. If you do mention blowfish, I think it should come with a big disclaimer to ensure people don't think IETF belives it's okay to use. And I don't think we need to point people to blowfish in the reference section. (see https://openvpn.net/community-downloads/) Just a few remaining questionts/comments left: >>> WireGuard is designed to be entirely stateless, modulo the >>> CryptoKey >>> routing table, >>> >>> Wouldn't you be able to say the same about the ESP SPD/SAD table? I'm >>> not sure >>> how different the ESP/wireguard statelessness is on a scale or truly >>> stateless >>> to NFS I'm still a bit concerned about the "designed to be entirely stateless". As I said before, that's more of a marketing gimmick than an actual technical property. Every VPN like protocol is stateless except for the state it needs (a rule database, counters, crypto keys). I would suggest removing this entire sentence: WireGuard is designed to be entirely stateless, modulo the CryptoKey routing table, which has size linear with the number of trusted peers. >>> You do not mention mobility or session resumption for WireGuard. Since >>> it is >>> all about static inner IP addresses over arbitrary outer addresses, it >>> has >>> mobility. And I guess the 1RTT means it has session resumption? You did not add these to the wireguard feature list. >>> 5.1: >>> >>> Listed as mandatory feature is: >>> >>> o Public-key certificate based authentication. >>> >>> Yet you have mentioned that neither WireGuard or CurveCP can do >>> authentication >>> based on certificates? >> >> Indeed. This should read, “Public-key (raw or certificate) based >> authentication.” It seems you decided to completely remove the mandatory requirement? What that on purpose or by accident? Paul From nobody Wed Feb 27 07:49:07 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1135131023; Wed, 27 Feb 2019 07:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bw_ZfavhSN8F; Wed, 27 Feb 2019 07:48:37 -0800 (PST) Received: from mail-yw1-xc2e.google.com (mail-yw1-xc2e.google.com [IPv6:2607:f8b0:4864:20::c2e]) (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 8F8DE130FE9; Wed, 27 Feb 2019 07:48:37 -0800 (PST) Received: by mail-yw1-xc2e.google.com with SMTP id k14so8436586ywe.4; Wed, 27 Feb 2019 07:48:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0gm1MZ+OidvCx0F6JPOEA4VUppThM82emWOOoB3LTgw=; b=cW05JHvv6GY/UoCHXvU6SZDwoGCOmnbgnKoc0RNky5oeXzzSx1HX0+GQ7ghIJctpWp 5b4AnguREaansjdiGhe0QSqFGi+W30DyxcjrBydwIRoM38KQ4naBHztwrOnRIbJ8sEY7 uUxiA3a8T6nyJZR1o45DKgQwu2kQBXivzWtG8+s0msSWDEW076wuWIwzt6uAzyrdF/PE kZxf+L0akWewPs4HT82WGzX3okvgNjpQajtSsQm8aT92A66WeMS3CK228n6M20Z61ijo JVGIjWI2o6mpY7WGS0kDFbJZFHaN5ZS1cGeEhj8sQcivWYl0ocVVW2+tPaRJEOcJ12V8 Livg== 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=0gm1MZ+OidvCx0F6JPOEA4VUppThM82emWOOoB3LTgw=; b=jLxpkFBYeF4qQpaXqFN+cFB8mncsp5HQSa1klTeuCk96fodlwt/W1UlsBzblELkjCm b2UcdUqERN3Tm63F0jnCOpFodtwozql0hLBXa2IUCVRYzKaoFCfQr2i6t2NDB00+3thn XMWAuCdDqdxPgtg7vZoZQPlyOdW8GAHNXi8lIwJJ8s6VDY5SAPNMw2JYzqWk2RWD9+RQ 3nf5rxblVZdLyY90xbd8iER8d5U/xEzV/1scp56Zg5mvDlDePex4RMnuB3uvZ4QwlW6Y eC8UkVS1e7OERCYyqdk3MVvjig+VHDemhslEoPqHZKfjQiGeWD8dSm+epwWzBcWDCDTv hthw== X-Gm-Message-State: AHQUAuYawn5xttWB0pP93Fd3buGFHB67uOX387XRBO2pfeTJ1ihxON5f lkAUjXgi5gPnaI1Ox3aD/vfw+Vrqg7VGvqsvTrs= X-Google-Smtp-Source: AHgI3IY/7b8EpWev6dZJSMh+U7ZgNkEna/oNa/zZC4HxHD0iryUOZcl9AI3jQbbSul6e+1+iSZyD/w/xlxMC0K2jau4= X-Received: by 2002:a25:d64e:: with SMTP id n75mr2424522ybg.199.1551282516499; Wed, 27 Feb 2019 07:48:36 -0800 (PST) MIME-Version: 1.0 References: <154321083813.24275.4373340388504093292@ietfa.amsl.com> <03808BD3-11AA-4010-9B8D-7E33EC1FE39B@gmail.com> In-Reply-To: From: Christopher Wood Date: Wed, 27 Feb 2019 07:48:25 -0800 Message-ID: To: Paul Wouters Cc: secdir , draft-ietf-taps-transport-security.all@ietf.org, taps WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Taps] Secdir early review of draft-ietf-taps-transport-security-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 15:48:47 -0000 On Wed, Feb 27, 2019 at 7:29 AM Paul Wouters wrote: > > On Tue, 26 Feb 2019, Christopher Wood wrote: > > > We just posted a revision to this document incorporating updates based > > on your comments [1]. (Thanks again for your careful review!) If you > > have time to check the diffs, we would greatly appreciate any more > > feedback you may have. > > In general, the changes look good to me, although I still have > reservations about some of the toy protocols mentioned which just gives > them too much credibility. Thanks for adding openvpn. I see you did not > add openconnect/anyconnect, and kept in curvecp/minimalt. Not my > preference but if that's what the WG wants, I'm okay with it. > > Note that the latest openvpn version now uses AES-GCM per default, so > perhaps you can excorsise blowfish from the document because Bruce > said not to use it like over a decade ago. If you do mention blowfish, > I think it should come with a big disclaimer to ensure people don't > think IETF belives it's okay to use. And I don't think we need to > point people to blowfish in the reference section. > (see https://openvpn.net/community-downloads/) Good to know. Consider blowfish gone. > Just a few remaining questionts/comments left: > > >>> WireGuard is designed to be entirely stateless, modulo the > >>> CryptoKey > >>> routing table, > >>> > >>> Wouldn't you be able to say the same about the ESP SPD/SAD table? I'm > >>> not sure > >>> how different the ESP/wireguard statelessness is on a scale or truly > >>> stateless > >>> to NFS > > I'm still a bit concerned about the "designed to be entirely stateless". > As I said before, that's more of a marketing gimmick than an actual > technical property. Every VPN like protocol is stateless except for the > state it needs (a rule database, counters, crypto keys). I would suggest > removing this entire sentence: > > WireGuard is designed to be entirely stateless, modulo the CryptoKey > routing table, which has size linear with the number of trusted > peers. Good suggestion! I'll take it for the next update. > > >>> You do not mention mobility or session resumption for WireGuard. Sinc= e > >>> it is > >>> all about static inner IP addresses over arbitrary outer addresses, i= t > >>> has > >>> mobility. And I guess the 1RTT means it has session resumption? > > You did not add these to the wireguard feature list. Whoops -- missed this. I'll add mobility (they call it roaming), though there is no session resumption, if I understand correctly. I'll work with Jason afterwards to make sure this section is accurate. > > >>> 5.1: > >>> > >>> Listed as mandatory feature is: > >>> > >>> o Public-key certificate based authentication. > >>> > >>> Yet you have mentioned that neither WireGuard or CurveCP can do > >>> authentication > >>> based on certificates? > >> > >> Indeed. This should read, =E2=80=9CPublic-key (raw or certificate) bas= ed > >> authentication.=E2=80=9D > > It seems you decided to completely remove the mandatory requirement? > What that on purpose or by accident? Intentional! We felt that unilateral responder authentication was more fitting here. Thanks again, Chris From nobody Thu Feb 28 02:18:57 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA62130EE0 for ; Thu, 28 Feb 2019 02:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Hk2PztjO; dkim=pass (1024-bit key) header.d=ericsson.com header.b=jqa80Pxw 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 3yY3-bAmkjOg for ; Thu, 28 Feb 2019 02:18:54 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 75590128BCC for ; Thu, 28 Feb 2019 02:18:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551349131; x=1553941131; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9i2Gv/C1svoatilVplFFIE7qsk9QUAdQ/U63x+A2uko=; b=Hk2PztjO4/bYy7XfLzQ5K4JgUCwdVXeFfJvyWgfa9bvdUz0h+ucAXn7b2btq5xi0 dAdVxFq046n8kPzNR1oTVRsNW4d8TzW9ftgsLKIpTfeCjA/r4j0gi1w0i0OATjaH 1lmO521GX7P26GU9TRpmgNYm0S5J8h6dXngIiVpIWkk=; X-AuditID: c1b4fb30-f93ff7000000355c-55-5c77b58b6c9a Received: from ESESBMB504.ericsson.se (Unknown_Domain [153.88.183.117]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C2.2F.13660.B85B77C5; Thu, 28 Feb 2019 11:18:51 +0100 (CET) Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 28 Feb 2019 11:18:51 +0100 Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 28 Feb 2019 11:18:51 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9i2Gv/C1svoatilVplFFIE7qsk9QUAdQ/U63x+A2uko=; b=jqa80PxwBWNUkFZm3C3R0H/NKrgBpH388lgJ/3thehSbN/K9scfXqXjkexE0lyXBq9G72efxTxGP31YdPv/+7iK5MqEW+wGPZytkFE40QgJ726N0s2/YgVli6vNum1nYKXNiW5iSCcBW7WB3NIcy1DTEqn2RySNIFtUIw4suv2c= Received: from HE1PR0701MB3020.eurprd07.prod.outlook.com (10.168.93.142) by HE1PR0701MB2332.eurprd07.prod.outlook.com (10.168.124.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.14; Thu, 28 Feb 2019 10:18:50 +0000 Received: from HE1PR0701MB3020.eurprd07.prod.outlook.com ([fe80::20ab:1417:b887:a821]) by HE1PR0701MB3020.eurprd07.prod.outlook.com ([fe80::20ab:1417:b887:a821%6]) with mapi id 15.20.1686.004; Thu, 28 Feb 2019 10:18:50 +0000 From: Zaheduzzaman Sarker To: "taps@ietf.org" Thread-Topic: TAPS GitHub organization Thread-Index: AQHUz07/vh9zLDpX90qDAx6eVAYn8A== Date: Thu, 28 Feb 2019 10:18:49 +0000 Message-ID: <102D7766-F397-4CE7-A3B1-B8143B684411@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.15.0.190117 x-originating-ip: [85.238.211.27] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dd7f8635-c16d-47a2-80cb-08d69d6621f4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2332; x-ms-traffictypediagnostic: HE1PR0701MB2332: x-ms-exchange-purlcount: 2 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtIRTFQUjA3MDFNQjIzMzI7MjM6aFVKNURjck5jcVdUbG5vdDdseXE1NXp2?= =?utf-8?B?Tlo2YkJCQ1N6RS80ZG1HVWIrMGtDUjBpeERrQVFtc2VJaUF6djE3UVVZbHY2?= =?utf-8?B?eHhYSG1yTzVkNzA3a1dRUzg5bzU4SDdjMzJhSjI5RzI1NndMdWJYNkdRQWo0?= =?utf-8?B?cUgwbk1tZXpiSmtNa3F6OW5wQTkycmhzVEJDSkFITERIcnh3RE9IT2FBenU3?= =?utf-8?B?WVdGRWVFb1oyNDRBbUYxY01nMVBtOFdrQXUrQ2tOK2EwaGk1RWJTcEs2OHA2?= =?utf-8?B?QXhUcG51ZnQvd3I0aGdwZFpib3hFZkd4UDJaN202QUxzb3B0TVJ0RG1McTNi?= =?utf-8?B?N25IZlIxS3VoeW5NcWdjYnNXUGxvczRFSmFTOTRzN2FzVTFucWljdXh2bFhZ?= =?utf-8?B?Q3Bid1UwQUxGM2hyU1cwaHNXTURlOWdzdW9nVWdpYVU4MWRtbDNMRytPRHJH?= =?utf-8?B?ODBpZDk2S0cxNnVjL3Buc2RDOEsrMmtyZnQ1R0lPcEFRVG0wQ2lxWXdPaFdr?= =?utf-8?B?ajBTdWxCZm5pRGtOb2lVWVNEN0tVaFNrM2RqRnNaR083UlFsQWs2emVzVk0y?= =?utf-8?B?Yk1aMGx6MlUrRFMvMk54TW5LWS9pVDJnUXUvanEwd0xvbFFSTGJHazFhQ0tU?= =?utf-8?B?cEc5TzNhOUtENENTMjNEZ2xyQXlQNTRKNk9xOUM1eTEwZXJVVGxoaEErWXFi?= =?utf-8?B?eU5hMzlVMzE0aEFVbmZiNmdZWHZKVVBnN0NNcGZpdFoyUlRRb2V2MUN3M1lt?= =?utf-8?B?RklEWWt2STVuRTF3ZFBldlFzcW9kcmtQK2dRSHg2Nyt5SitMUXNqRjZOWnhK?= =?utf-8?B?Z3FWOHhVOXVpcGh1SDBjd1RDVEx3UXcvWm9xUUdjeldmSVp2WFFaS1Zybnc2?= =?utf-8?B?ZTBUUHRiSklxaEorcXhBMHVjOGNqV1dUM2xIbVJlSUZEUkdpZ3liMGpQTUJu?= =?utf-8?B?cWhaNG1kNDNWYXY4N0ZHZkFDNmtJVkdyeDA4bmt0SzU4QXV5UllydUowT1l1?= =?utf-8?B?RGxtbkZ3WFZNSjQ1Z2RrYVRPV0lCREFmMVhreVh1cWJFSElYS2hHYzkyZEVR?= =?utf-8?B?T1plTlFPUEozNnMyb2pDcU15YmZRZWlKY1BFdENmWFhDNUl2enBCaTg5eHI3?= =?utf-8?B?dTdXYTQzV2krVVdYSWh1MWJDNVJ2aHh0VzZ2UlRIZDJ3ZDYzOUJoSWdrRmlE?= =?utf-8?B?Y0d4VkViNUR5Zkg4UjdxMHcyenBqdHpIekdIMkVyQ0dIR2FmRHpVbDBvQlRE?= =?utf-8?B?VlhLdWI0Y2hkZ3BrWTFJSVVYZUpMb1dZL1lBMWtxT0kzWldHUGIwU0xQdml6?= =?utf-8?B?b2l4eDJNcHJnM0QyVDlvQmtsaGhseVh4ZmdUTDJOdHljUU1vK2h1Uk85Ylp3?= =?utf-8?B?VlJ2ZitLb3llOTVGV3JmbmdrV3ZyaklBa3JHeFFMK1FuYzhibFYzTzVsRUpZ?= =?utf-8?B?WkxHeDcrN1Vqa1REK2kyVUpWdkt3RWJRTXh0bGF6L0t3YkhNZU1XOFN2dkds?= =?utf-8?B?WE1nWjFaY3IybGV6bTFrVXpvZXRuM2dnYlJGaEoyRC9UNTE1MVVaRlk0TTFO?= =?utf-8?B?US9SNUFGTThVOCtQSHhQWkJIaGlYcE9sUEcyMXM5b0pKOUJvN0FZd2FmV2Jy?= =?utf-8?B?WEhnNGNqTlJua1l6NTNmRDJBbFhRZHQzUlZJUm50OFhFSmpvZHRxN1FBa09r?= =?utf-8?B?ZUpqa1FadGgycHVzVk5maFMwQlRmRmE3Y0NqZytmZDBxWC8rNU9iVUxQZE96?= =?utf-8?B?Y0NPMk1CM1NISS9CK3FmaG05UVU1NGRTaVUxdlg4bWt6QnlGdGNOZjJRRSth?= =?utf-8?B?dTJycUhVTW9mYWlJVTVrcEJPbk9mRDduanFGL1VQWThabVQ5K0UvaytteDd6?= =?utf-8?B?V3k0T3g0eExUQlhocFU4a1FpVUwxWW9YMzRUQlBYVVJjOU5ZemxPSnB1YzJN?= =?utf-8?B?UmFtUTBuL0xITUE9PQ==?= x-microsoft-antispam-prvs: x-forefront-prvs: 0962D394D2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(396003)(39860400002)(136003)(376002)(279900001)(53754006)(189003)(199004)(58126008)(26005)(316002)(6346003)(14454004)(6436002)(6486002)(6512007)(53936002)(5640700003)(606006)(102836004)(25786009)(6306002)(236005)(54896002)(6916009)(2906002)(6506007)(86362001)(3846002)(6116002)(478600001)(33656002)(7116003)(966005)(99286004)(4743002)(256004)(71190400001)(82746002)(3480700005)(71200400001)(83716004)(97736004)(5660300002)(66066001)(8936002)(105586002)(81166006)(81156014)(1730700003)(8676002)(106356001)(2616005)(68736007)(186003)(2351001)(7736002)(486006)(44832011)(36756003)(476003)(2501003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2332; H:HE1PR0701MB3020.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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=zaheduzzaman.sarker@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: FH/ytjLMILqMcCqXintUwCixaRoGlcEkS3AFwXyPhc6nUIUJYALereDjsmgfLRnG/9o99KPVEAuYy9qkkYe/N8hvR9wpEbsSp3xRzFGStNyg/A87WFMAYO+6iwrIxFRMtrOsu1DHqsWEpwzEMPIYievixxddXIRGldeyRLf5enc3wecPtYc+abIrtX7IwNBbJySusqEPk7YON5bjr1dURFCgPUSucpjGcA2ccjmpYgQ2D8eomXJ3CjGwcqp9VZsDqRFDTrDXjfgaK2rE83/bYmpBmiKf2p0/UAHcXlf6Tf2YtV/CDnn5PyGxD9keYLiNwQh3HU4qMc4aQwwMb2zIXERgVi1k2+nq4OlGh3+TEuperS69LwSMKsGnT5hhv/ryPfGEW+AW7OJ3btCzsuhTcWE7/o1NdJPIp3dD53xsays= Content-Type: multipart/alternative; boundary="_000_102D7766F3974CE7A3B1B8143B684411ericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: dd7f8635-c16d-47a2-80cb-08d69d6621f4 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2019 10:18:49.9509 (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-Transport-CrossTenantHeadersStamped: HE1PR0701MB2332 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTYRTGe3fvtutodJ0fO0wrXKiVpSZDoiSTCCWopL9ER7nmRS2dcq+f KWbWsrY+NqhEU5Y6Gy3XSDNNhNQMv4KoLCMVNVdhGHQFP8rStt0F/vc7z3ne87zn5SUwiZUv IzI1eRStUWXJBSK8Oqk9f7e+rVAZWd0dtndceRAlmM2/eIkoWRSTRmVlFlB0xIFUUcZHdk2Y O7+/6OV3m7AcVe3TIS8CSAWYViuRDokICdmHgJ2qwLliEcGz2isYV5h5oBuec9tw0oDBYMOI x1bFg6aJi54BXxF09ph4OkQQAjIGZhqPuUJ8yW3w7vljgYt9SDl0Tej5nB4KayuNAo7DoXLO hFyMk8HQzdp5LhaTsXDjMou7GJH+sDTU7NYxUgqfHCYetwQJ5q7XGMd+MDuz6p7vR0bAimUY 5/QgsFzo8/g3w1uTHnF8FIZtRp7r/kCOIah4NCjgGrtgZOim57AMlmZYIWdq8IHRPgOfa+SA /fO8JzkQmi6NY5ypXgA27aR7koSkwGLTIm4FNdxe0HoStoD1+jRuQGE16zbiWA135trwGvcL eMNgtcPJhFPfAfbOCM4SBLf000KOt4O2ts7DCeBobsTWe+4hwor8GIo5nZ0eFRVO0ZlqhsnR hGuovBbk/EE9T1YiO9Dst7heRBJIvlH81F6olPBVBUxxdi8CApP7ilmbUxKnqYrPUXTOKTo/ i2J6UQCBy6XiPxJvpYRMV+VRZykql6L/d3mEl6wcgXGg//xSaVhw7AdtWcuZpMkjW5NlxgDH 79RXKSf5cfrFFE3g3dC/J6QNwmWL+JD2YXLJe/7Ag3YBW7dBHVT8YxNz7epUtLU+fij0p1S/ SsS/oWSKkuwXyn5liC0xamFUUaQom2K9g7pZY4D//dZo2jAytnxYW2MLOd7aUfpFjjMZqj07 MZpR/QP3lklyPQMAAA== Archived-At: Subject: [Taps] TAPS GitHub organization X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 10:18:56 -0000 --_000_102D7766F3974CE7A3B1B8143B684411ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpBY2NvcmRpbmcgdG8gdGhlIGRlY2lzaW9uIG1hZGUgaW4gdGhlIGxhdGVzdCBU QVBTIGludGVyaW0gbWVldGluZyAoaGVsZCBvbiAxNXRoIEphbnVhcnksIDIwMTkg4oCTIGNoZWNr IHRoZSBtaW51dGVzIGhlcmUgLSBodHRwOi8vZXRoZXJwYWQudG9vbHMuaWV0Zi5vcmc6OTAwMC9w L25vdGVzLWlldGYtaW50ZXJpbS0yMDE5LXRhcHMtMDE/dXNlTW9ub3NwYWNlRm9udD10cnVlICks IHdlIG5vdyBoYXZlIGNyZWF0ZWQgYSBHaXRodWIgb3JnYW5pemF0aW9uIGZvciBUQVBTIHdvcmtp bmcgZ3JvdXAgKGh0dHBzOi8vZ2l0aHViLmNvbS9pZXRmLXRhcHN3ZykuIFRoZSBpZGVhIGlzIHRv IHVzZSB0aGUgcmVwb3NpdG9yaWVzIGluIHRoaXMgb3JnYW5pemF0aW9uIHRvIGFsbG93IGNvbGxh Ym9yYXRpb24gb24gd29ya2luZyBncm91cCBkcmFmdHMuDQoNCkFzIHdlIGtub3csIHRoZXJlIGhh cyBiZWVuIG5pY2UgY29sbGFib3JhdGlvbiBnb2luZyBvbiBhcmNoaXRlY3R1cmUsIGludGVyZmFj ZSBhbmQgaW1wbGVtZW50YXRpb24gZHJhZnRzIGF0IGh0dHBzOi8vZ2l0aHViLmNvbS90YXBzLWFw aS9kcmFmdHMsIHRoaXMgcmVxdWlyZXMgYSBtaWdyYXRpb24gb2YgcmVwbyhzKSBmcm9tIHRoZSB0 YXBzLWFwaS9kcmFmdHMgcmVwbyB0byB0aGUgbmV3IFRBUFMgZ2l0aHViIG9yZ2FuaXphdGlvbi4g QnJpYW4gVHJhbW1lbGwgaGFzIGFncmVlZCB0byBoZWxwIHVzIHdpdGggdGhlIG1pZ3JhdGlvbiAo VGhhbmtzIGJyaWFuKSBhbmQgc2V0dXAgc2NyaXB0cyB0byBnZW5lcmF0ZSBkYWlseSBkaWdlc3Qg ZnJvbSB0aGUgZGlzY3Vzc2lvbnMgb24gdGhlIGdpdGh1YiByZXBvc2l0b3JpZXMuIFRoZSBkYWls eSBkaWdlc3Qgd2lsbCBiZSBzZW50IHRvIHRoZSBUQVBTIG1haWxpbmcgbGlzdC4NCg0KVGhlIG1p Z3JhdGlvbiB3aWxsIGhhcHBlbiBieSA1dGggbWFyY2gsIDIwMTkgYW5kIHRoZXJlIHdpbGwgYmUg YW4gZW1haWwgc2VuZCB0byB0aGUgVEFQUyBtYWlsaW5nIGxpc3Qgd2l0aCBtb3JlIGRldGFpbCBp bnN0cnVjdGlvbnMgb24gd2hhdCB5b3Ugd2lsbCBuZWVkIHRvIGRvIHRvIHVwc3RyZWFtIHlvdXIg bG9jYWwgY2hhbmdlcyB0byB0aGUgVEFQUyBvcmdhbml6YXRpb24gcmVwbyhzKSBmb3IgdGhvc2Ug d2hvIGFyZSBhbHJlYWR5IGNvbGxhYm9yYXRpbmcgb24gaHR0cHM6Ly9naXRodWIuY29tL3RhcHMt YXBpL2RyYWZ0cy4gIFVudGlsIHRoZW4gcGxlYXNlIHJldGFpbiB5b3Vyc2VsZiB0byBjcmVhdGUg YW55IG5ldyBQUi8gaXNzdWVzIG9uIHRoZSBodHRwczovL2dpdGh1Yi5jb20vdGFwcy1hcGkvZHJh ZnRzIHJlcG9zaXRvcnkuDQoNCkJSDQoNClphaGVkICYgQWFyb24NCg== --_000_102D7766F3974CE7A3B1B8143B684411ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <6F440DB53296B746B8F9AE7E01F33749@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IlNWIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IaSBhbGwsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFjY29y ZGluZyB0byB0aGUgZGVjaXNpb24gbWFkZSBpbiB0aGUgbGF0ZXN0IFRBUFMgaW50ZXJpbSBtZWV0 aW5nIChoZWxkIG9uIDE1PHN1cD50aDwvc3VwPiBKYW51YXJ5LCAyMDE5IOKAkyBjaGVjayB0aGUg bWludXRlcyBoZXJlIC0gaHR0cDovL2V0aGVycGFkLnRvb2xzLmlldGYub3JnOjkwMDAvcC9ub3Rl cy1pZXRmLWludGVyaW0tMjAxOS10YXBzLTAxP3VzZU1vbm9zcGFjZUZvbnQ9dHJ1ZQ0KICksIHdl IG5vdyBoYXZlIGNyZWF0ZWQgYSBHaXRodWIgb3JnYW5pemF0aW9uIGZvciBUQVBTIHdvcmtpbmcg Z3JvdXAgKDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9pZXRmLXRhcHN3ZyI+aHR0cHM6Ly9n aXRodWIuY29tL2lldGYtdGFwc3dnPC9hPikuIFRoZSBpZGVhIGlzIHRvIHVzZSB0aGUgcmVwb3Np dG9yaWVzIGluIHRoaXMgb3JnYW5pemF0aW9uIHRvIGFsbG93IGNvbGxhYm9yYXRpb24gb24gd29y a2luZyBncm91cCBkcmFmdHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFzIHdlIGtub3csIHRoZXJlIGhhcyBiZWVu IG5pY2UgY29sbGFib3JhdGlvbiBnb2luZyBvbiBhcmNoaXRlY3R1cmUsIGludGVyZmFjZSBhbmQg aW1wbGVtZW50YXRpb24gZHJhZnRzIGF0DQo8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vdGFw cy1hcGkvZHJhZnRzIj5odHRwczovL2dpdGh1Yi5jb20vdGFwcy1hcGkvZHJhZnRzPC9hPiwgdGhp cyByZXF1aXJlcyBhIG1pZ3JhdGlvbiBvZiByZXBvKHMpIGZyb20gdGhlIHRhcHMtYXBpL2RyYWZ0 cyByZXBvIHRvIHRoZSBuZXcgVEFQUyBnaXRodWIgb3JnYW5pemF0aW9uLiBCcmlhbiBUcmFtbWVs bCBoYXMgYWdyZWVkIHRvIGhlbHAgdXMgd2l0aCB0aGUgbWlncmF0aW9uIChUaGFua3MgYnJpYW4p DQogYW5kIHNldHVwIHNjcmlwdHMgdG8gZ2VuZXJhdGUgZGFpbHkgZGlnZXN0IGZyb20gdGhlIGRp c2N1c3Npb25zIG9uIHRoZSBnaXRodWIgcmVwb3NpdG9yaWVzLiBUaGUgZGFpbHkgZGlnZXN0IHdp bGwgYmUgc2VudCB0byB0aGUgVEFQUyBtYWlsaW5nIGxpc3QuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoZSBtaWdy YXRpb24gd2lsbCBoYXBwZW4gYnkgNTxzdXA+dGg8L3N1cD4gbWFyY2gsIDIwMTkgYW5kIHRoZXJl IHdpbGwgYmUgYW4gZW1haWwgc2VuZCB0byB0aGUgVEFQUyBtYWlsaW5nIGxpc3Qgd2l0aCBtb3Jl IGRldGFpbCBpbnN0cnVjdGlvbnMgb24gd2hhdCB5b3Ugd2lsbCBuZWVkIHRvIGRvIHRvIHVwc3Ry ZWFtIHlvdXIgbG9jYWwNCiBjaGFuZ2VzIHRvIHRoZSBUQVBTIG9yZ2FuaXphdGlvbiByZXBvKHMp IGZvciB0aG9zZSB3aG8gYXJlIGFscmVhZHkgY29sbGFib3JhdGluZyBvbg0KPGEgaHJlZj0iaHR0 cHM6Ly9naXRodWIuY29tL3RhcHMtYXBpL2RyYWZ0cyI+aHR0cHM6Ly9naXRodWIuY29tL3RhcHMt YXBpL2RyYWZ0czwvYT4uJm5ic3A7IFVudGlsIHRoZW4gcGxlYXNlIHJldGFpbiB5b3Vyc2VsZiB0 byBjcmVhdGUgYW55IG5ldyBQUi8gaXNzdWVzIG9uIHRoZQ0KPGEgaHJlZj0iaHR0cHM6Ly9naXRo dWIuY29tL3RhcHMtYXBpL2RyYWZ0cyI+aHR0cHM6Ly9naXRodWIuY29tL3RhcHMtYXBpL2RyYWZ0 czwvYT4gcmVwb3NpdG9yeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QlI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+WmFoZWQgJmFtcDsg QWFyb248L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_102D7766F3974CE7A3B1B8143B684411ericssoncom_-- From nobody Thu Feb 28 07:41:54 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909AA130EC5 for ; Thu, 28 Feb 2019 07:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBAiJMctl21r for ; Thu, 28 Feb 2019 07:41:51 -0800 (PST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 EAC43130E27 for ; Thu, 28 Feb 2019 07:41:50 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id d18so23918976qtg.12 for ; Thu, 28 Feb 2019 07:41:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version; bh=tYTQpy3pF9+kPls5L6giog/WnCFD4rwQq9t2s6vk5zI=; b=cVU64vtg1Xu/TXuCXaqJyzrpO/Ear6xZC1pPAGGJio7PeA0FjsOQvnV2+C9Q5KTd4t STxl3Nd6WC2wnepalHER7FSkdhFyxWZGFKqW/4ZpeAcQM7y12lMOxStITHn0WqHZN1rD UFqz4Pi3XZ3Sga15Ip0lIRES/vS2E97Jg54qcVcyM0H9tVenHsgoycvCLaJMAhLWe54K v2KoTP8TW/9d3Eh/0/EgxrAmHBvqrxjZxeXyk0fa1LvDFS7BpFN58KBbyL7arPkO6nUw b4Xc9JGPqPDSupnFAZKHcQeDS7xFLByXHBQxCAusZjWIr7Cvq4Im/PgivWXp6V3Eslgr Cw4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version; bh=tYTQpy3pF9+kPls5L6giog/WnCFD4rwQq9t2s6vk5zI=; b=rEPouoDemDXwe+jI44dbZLaub8/hykamo4lRGFwKihFaAy/18zcJZM7bZFJBJ6omyI 81h7bxMYiKSw7/blWKrQfHkA0DVVEKtCqjDnS29Y34l85cwqWlQYJEZs11+//J9WXrFg h8jwWkvq4urVE24zCzzexyo7dO+vipXZhDfDVV2XcXTHil9bH14/fx8rOlOqkisdsnui oAEM1/Smpk/0KQC3qSgrJJU0XwnaAiP16zjJRbb2jbyLzsG19qPRcIHkUzJ3VbOwQ/UR VL7eQQKxOZiyYOMs0oLWf2AvO8Qu62HfFQgTAo2/vC6+YmKo0RLCHkLBpEIPMvD7mHO3 zeYg== X-Gm-Message-State: APjAAAWLxltRYbA1PqXRM1ksJTmSLF5aM80cuwm1BCAavFbDcty355yK cXLc52+SbveeUdoQtn06VIDisbux X-Google-Smtp-Source: APXvYqz85ZStcYfC27NyfgCO3zT3UgC8q/VZWWp3xU+aFsPBX3nQRym+vx/MmdphLt1gmq65bzHtkA== X-Received: by 2002:a0c:d165:: with SMTP id c34mr6935736qvh.64.1551368509129; Thu, 28 Feb 2019 07:41:49 -0800 (PST) Received: from [172.19.35.103] ([2001:4878:a000:3000:9137:199:92c4:88da]) by smtp.gmail.com with ESMTPSA id f29sm14233150qte.11.2019.02.28.07.41.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Feb 2019 07:41:48 -0800 (PST) From: "Aaron Falk" To: "taps WG" Cc: "Zaheduzzaman Sarker" Date: Thu, 28 Feb 2019 10:41:47 -0500 X-Mailer: MailMate (1.12.4r5594) Message-ID: <69DB0BA3-33B4-4860-ABD0-F249E6B9ED7A@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_3A1F8330-2CF1-4EC6-B026-C3D61A462672_=" Archived-At: Subject: [Taps] minutes from Jan 15 interim X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 15:41:53 -0000 --=_MailMate_3A1F8330-2CF1-4EC6-B026-C3D61A462672_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable Zahed reminded me that we haven=E2=80=99t posted minutes from the January= = interim. Could folks take a look at [the = Etherpad](http://etherpad.tools.ietf.org:9000/p/notes-ietf-interim-2019-t= aps-01?useMonospaceFont=3Dtrue) = and add needed fixes / revisions. I=E2=80=99ll post them to the datatrac= ker = next week. --aaron --=_MailMate_3A1F8330-2CF1-4EC6-B026-C3D61A462672_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Zahed reminded me that we haven=E2=80=99t posted minutes = from the January interim. Could folks take a look at the Etherpad and add needed fix= es / revisions. I=E2=80=99ll post them to the datatracker next week.

=

--aaron

--=_MailMate_3A1F8330-2CF1-4EC6-B026-C3D61A462672_=--