From nobody Sat Aug 1 20:18:34 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4394C3A0B5F for ; Sat, 1 Aug 2020 20:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8hRA4GGJJmy for ; Sat, 1 Aug 2020 20:18:29 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650133.outbound.protection.outlook.com [40.107.65.133]) (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 5596A3A0B6F for ; Sat, 1 Aug 2020 20:18:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R1JBbz1sTyiBKBi/FBk2/w2fJ+cYg/3JNHPEk0fm+D/4kIeEGIMARRGVzP3yg5IZ1w23zxCZF/K/FU6YSEZIzz2ScNijtN5ZImNS6qfC1bhDIolyBzpSIiXRh+Sk8/i4yPxNCUR4mzv092BssB6jaaNzKkCSpEzaoJmfgHLzN3L3V/d0vw5ahu/9h5FiH7YziCoDg0oorJGisqzqjQjWNbC7/Ro9m4j/2wqy0sOXkx7K9fUojkGJ5cRFyDOQrsjIPUJXMI4rqO5RJd8lJ+JLpQKI+YmKt+Duq/2LKAkeguAyv65RVx33tnKiEceyhf4JbcOsTzqnyJLahvl+xapweg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ocRX/KGunbC9vHdv3oWeZr/7dPbVOJlSkhKBJl1iVeg=; b=Ka1QDFBGWcV7ap5WCdlFV/iqwKYa/cnmg6E3T6EQ6Krga7ITB/faUSjur+u7sYpJefglqfVDha0clAVc9f2LEp+w0OWXyduyVZB33eA8hDjpKioopr/ctMWz/pZOT/tSIUcnWpAVNAlkhGqyGUgwzNF/8C3Z/vpG5Q/BYk6bCjeT913mPgWWFYHR/jkeyaY9Bitt8EnRa2+ym2hWA5MqUXlfybvXd9YRlRW1FmXzsRbwI2U1nX4zKNGX1Je5ceP6sdzOFCv5XMhvOQkMYpXJN5+Zo9J8AMPbZ4rHIpb23VZ2KM6QhGHJw2go6nlFB0tO4EniTNt+t05hoiGwqh04Ow== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ocRX/KGunbC9vHdv3oWeZr/7dPbVOJlSkhKBJl1iVeg=; b=ZI8o+vEL0xkjKGvx0EaBEe4nc/biSM3ixPjpxycFyByWzqlzOMV9CCnmoftKX+N0l1zBJgH4y4Z4vTQMl0S2PdIGo848pf/11sBa6N9mK3w/Rm3ZmK3B+TSyJYRDpkVa2AzTfcGXzRgVVNScSIbWFFacIyA8GiszOMMa2mfxlSw= Received: from CH2PR00MB0844.namprd00.prod.outlook.com (2603:10b6:610:6f::23) by CH2PR00MB0679.namprd00.prod.outlook.com (2603:10b6:610:af::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3291.0; Sun, 2 Aug 2020 03:18:26 +0000 Received: from CH2PR00MB0844.namprd00.prod.outlook.com ([fe80::d4ca:3e4:4c23:3aea]) by CH2PR00MB0844.namprd00.prod.outlook.com ([fe80::d4ca:3e4:4c23:3aea%7]) with mapi id 15.20.3292.000; Sun, 2 Aug 2020 03:18:26 +0000 From: Darrel Miller To: Rob Sayre , Mark Nottingham CC: DISPATCH WG Thread-Topic: [dispatch] Building Blocks for HTTP APIs - next steps Thread-Index: AQHWZzKma9xoffc2Rk6RrnEK27+sSqkiZESAgAHACHY= Date: Sun, 2 Aug 2020 03:18:26 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-08-02T03:02:24.7542040Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Privileged authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [69.159.101.65] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: edd2a428-e52d-4fdd-9069-08d83692b8a8 x-ms-traffictypediagnostic: CH2PR00MB0679: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IyJiOULY80hOPRZd+Mx4GYqQlA313YFLTQJ1iunCc79YVhQ8zGKaVTSnY4SDXDtwqvLpHdcZvADWJHU1GxuVYTYMep0VnTwtqKLemC6WYkpyIBsQFsW9tplanfmi0W2NrlSoasVLwzFcUmSLqoEZpbp9gLX+2nx9LTv3ShYBCtSImTve92UdLLZwEojWT00SUkx6w+ONdDL9/1d6DDbSAGU/O2T5EmwN2gJ6bAylv7o3TLZdpjAb+xifb0dFpnUlADj4kbUNsaQhhmWZoqRcUVkjxE2tCKOUbKZ2G9wlAW8F46FOwV1JOhLyJrFafLj6RrEu9P3pY+i62MFBOBWPTNrbWCoGQpKe5R2zsJiyk4I6eA7PlKWTkCL5IZb+mL8mWVcQ4Rrl76VHOX84wjHwbA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0844.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(366004)(136003)(346002)(39860400002)(2906002)(166002)(8676002)(71200400001)(186003)(33656002)(966005)(478600001)(7696005)(82950400001)(83380400001)(82960400001)(86362001)(110136005)(316002)(5660300002)(66476007)(66556008)(66446008)(64756008)(8936002)(26005)(8990500004)(55016002)(53546011)(6506007)(9326002)(4326008)(52536014)(91956017)(10290500003)(66946007)(76116006)(9686003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: +fzdBxq5tz84zRy/C0zdWPNuvsat2c3Zy3PYMaJDULNi2HnXsjtc0iUPExim0tIe43X1JnyetM5meADbfdCG6rBNTDjm/WQNqlzAe01sWi9nf9f7Ub4gv2VcP4Mnt7zaU4Qmd8EqEKRftpibjyLuI5zbiDgwlJRdtE116TLpb3JZfVXA2X8w0ZE2gqKGavNHXaJI3zkZvY3RQ73r7MHo8d6v/iPMKD5SNn35Ab6gMeEQAgZmRc74QgBbKFVA1Ju6ohB+4yU+rbhIfPZgq/UTKVXQkucwbCNob6VIlGpvXKnIXZkugtnBPc5+7NM9AmD/O6R4NwYDPn9yuY/PLf6py0HfCBSdVC5s2FkNEvezjDgSo6WXrhTqpPtglwEI/CAyt3aGUC+VX0BuGTarokgoFFBeE/FuqVivMWOomCZTPjRnICylUsVFebgFO1TwWD7l/v9fC7siXfZcxJGAPc+vnTQQwmXxh0hoGk67OHLmeldMBFl8iGqeR9U/Oj4+urBn9gaEFY8dALV/FqJt6I9gMjLJRb0JJhk1+NDSBqqfo847E67aw/8DLR3tJAFQYynBYcZOs7i7k+KY+L7fO3APnssgDrpEiiQgy19ndXzaeAk4T6nuKMUoT7T8uDx+V4fRn/ScL15jcNdR+qHDuTTkzA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR00MB084497EEB38BC0EFED683165F04C0CH2PR00MB0844namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0844.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: edd2a428-e52d-4fdd-9069-08d83692b8a8 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2020 03:18:26.2213 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZztV7ZkIsLs7Ks+ierkdWLG6WGyYczmLBsFg4GttXog6A8s+wZXBHPoNTLQsmdm2rHunBjpjWDXzzh9NtNzhlg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0679 Archived-At: Subject: Re: [dispatch] Building Blocks for HTTP APIs - next steps X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 03:18:32 -0000 --_000_CH2PR00MB084497EEB38BC0EFED683165F04C0CH2PR00MB0844namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Rob, There is a sub group within the Linux Foundation GraphQL project that is fo= cused on creating a specification of how GraphQL should be layered on HTTP.= https://github.com/graphql/graphql-over-http/blob/master/spec/GraphQLOverH= TTP.md I think the HTTP API Working group could co-ordinate with that group to ide= ntify any gaps in HTTP conventions/patterns or guidance that would help wit= h GraphQL layering over HTTP. >From the perspective of HTTP, GraphQL is media type for the query and one f= or the schema. The response is application/json. GraphQL could definitely= make use of the SEARCH method. I see efforts such as GraphQL, JSON API, OpenAPI, RAML, OData as being =93c= ustomers=94 of the work of the HTTP API working group. I don=92t know if t= he charter needs to reflect that. Darrel From: Rob Sayre Sent: July 31, 2020 8:19 PM To: Mark Nottingham Cc: DISPATCH WG Subject: Re: [dispatch] Building Blocks for HTTP APIs - next steps On Fri, Jul 31, 2020 at 5:03 AM Mark Nottingham > wrote: Hi everyone, After some tweaks resulting from the meeting discussion, I think this chart= er proposal is ready to go to the ADs. Any last comments? It might be good to address the value this effort will add in addition to t= hings like GraphQL: https://thenewstack.io/graphql-gets-its-own-foundation/ thanks, Rob --_000_CH2PR00MB084497EEB38BC0EFED683165F04C0CH2PR00MB0844namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Rob,

 

There is a sub group within the Linux Foundation Gra= phQL project that is focused on creating a specification of how GraphQL sho= uld be layered on HTTP. https://github.com/graphql/graphql-over-http/blob/master/spec/GraphQLOverHT= TP.md

 

I think the HTTP API Working group could co-ordinate= with that group to identify any gaps in HTTP conventions/patterns or guida= nce that would help with GraphQL layering over HTTP.

 

From the perspective of HTTP, GraphQL is media type = for the query and one for the schema.  The response is application/jso= n.  GraphQL could definitely make use of the SEARCH method.=

 

I see efforts such as GraphQL, JSON API, OpenAPI, RA= ML, OData as being =93customers=94 of the work of the HTTP API working grou= p.  I don=92t know if the charter needs to reflect that.

 

Darrel

 

 

 

From: Rob Sayre
Sent: July 31, 2020 8:19 PM
To: Mark Nottingham
Cc: DISPATCH WG
Subject: Re: [dispatch] Building Blocks for HTTP APIs - next steps

 

On Fri, Jul 31, 2020 at 5:03 AM Mark Nottingham <= mnot@mnot.net> wrote:

Hi everyone,

After some tweaks resulting from the meeting discussion, I think this chart= er proposal is ready to go to the ADs. Any last comments?

 

It might be good to address the value this effort wi= ll add in addition to things like GraphQL:

 

 

thanks,

Rob

 

 

--_000_CH2PR00MB084497EEB38BC0EFED683165F04C0CH2PR00MB0844namp_-- From nobody Mon Aug 3 06:27:25 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765533A09AD for ; Mon, 3 Aug 2020 06:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0hrI3DrhgSi for ; Mon, 3 Aug 2020 06:27:22 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640125.outbound.protection.outlook.com [40.107.64.125]) (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 084B43A09A9 for ; Mon, 3 Aug 2020 06:27:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hE/eFIacdYQTOrJFsvXk/7EkzmVja2pr0IXpF/b0C44GMaG6Q2EPRYvb4TaaQcNimc1U5XbqsbB+DQuZ3d0aaF7dfeKYcQmxBZd+x8eowoCKhOmyQbgWJWfGXh8zHA6woeYxN2TVP6jtM9Ou9IytImuNscSvpBlKEMafP9yTBCMqS9VJpt19fYutDVO113RIcG8nHepHsq/pHM9+6wDTlogHcgb943n1tG2Ix7ghLEVmsHY7PCY5wdqMw/XjGqVcx2ezfKaNNYChOu0czaX2+6QuRVeqVl483fTcdZJO0GqRj02Y4vbIoHDfFm9S92EQczUrOMRO6UEPrXfxk2wl5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rtXjJgYHzwYXNyNpOBbzsx5zRp62OAeGJcPghhzMnok=; b=hleVk8DrRuEBICJKndJBdoR8IB2iLZAiR+0j8u435Ktx4hAO0fAfSYSjH6uXzLvnUnr4f+rqeUV8oysueUgp4c1rp3BHaxyIbKFfYRUjyFpfPhAFxpfwxpzlPTHgtGEEMwHT4I3EX2J4B0kAJrfrChOGF+wxLj4eq5mefalAZ2hOI9q5sSlfEUjtnph9Bn4dNU0GxBOxHUhu78FAk+CStVL0fgd/+ukn+mOdSod4o5tYDsozhR8PJoYV3tDLLF+lgCFsXXXI/XRjn9aDCaKc5lCGyQMnNR4etepSe4uOqcKY4hzADy5LItTxKjiO0kusFCa8172F70ouG/9TKLuPrA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rtXjJgYHzwYXNyNpOBbzsx5zRp62OAeGJcPghhzMnok=; b=O5++1YfefNW1J+FeLAGBO3kOkuXykWshOdJi10BspI0aHPGtfBACZr+RtXgGCk6OsnCygoCEwlyZIekbJvajUwBBeBrjD/manFkRYfSDpRitF5sAfcXbDo/VPp4qlScf42/h/Mu4XiaELOVrUdMeXnCjmFzionQwBYVFxGI6RZ4= Received: from CH2PR00MB0844.namprd00.prod.outlook.com (2603:10b6:610:6f::23) by CH2PR00MB0762.namprd00.prod.outlook.com (2603:10b6:610:61::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3296.0; Mon, 3 Aug 2020 13:27:12 +0000 Received: from CH2PR00MB0844.namprd00.prod.outlook.com ([fe80::d4ca:3e4:4c23:3aea]) by CH2PR00MB0844.namprd00.prod.outlook.com ([fe80::d4ca:3e4:4c23:3aea%7]) with mapi id 15.20.3296.000; Mon, 3 Aug 2020 13:27:12 +0000 From: Darrel Miller To: "dispatch@ietf.org" Thread-Topic: JSONPath or JMESPath? Thread-Index: AQHWaZZ7NPtRChyZ5EOmdm2UGgqlJQ== Date: Mon, 3 Aug 2020 13:27:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-08-03T13:03:29.0202224Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Privileged authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [184.145.227.145] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 80f24e50-19f9-4405-9273-08d837b0ee25 x-ms-traffictypediagnostic: CH2PR00MB0762: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +BlMUM8I/v2v2SFnW6nvyMmwfsRm7vrUC6xHLp++c34E60ld7L+CbwPiNMEjRpMVvX38hKFO0qo4VjoGVjdfvL9AkIgWUyUyPhNBX+uA7mnHeDQtPpCJZEn68lRybHMQM6lvQWvGYGY1ZcobwtNAzMhUhCxn5o5hJMVZWfl2JxtlyJbMeKakowhmS+KlbdOAYcpY3/7IXypZ6OqyRPoBgs88+2dEp47HQNBgcP2Fg40H4H15Ym07KyoqdugLVNhmA6g2qrWRLXQWCTPZ+iHo00eGnsAI2Q/WIQ4V6WSDWv0NcqhhCUexx7BLx/mxZJQAsDofurgvmJc/r3uoed3E/iRvD24/hcRmR68XlEuYhaYmYblLlnbJk2MHaeNu2IYXjvaiNCdKZtnrz8mMQBHM+A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0844.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(366004)(396003)(39860400002)(136003)(6486002)(166002)(7116003)(71200400001)(8676002)(26005)(3480700007)(186003)(52536014)(478600001)(8990500004)(5660300002)(86362001)(6916009)(9686003)(6512007)(82960400001)(82950400001)(8936002)(966005)(10290500003)(33656002)(6506007)(76116006)(2906002)(316002)(66446008)(64756008)(66556008)(66476007)(21615005)(66946007)(83380400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: KOdVLgpwvtuQV6Xo2fLMQQ9HzqeizmVa/oLgobDSPaiLL1nT0L17HGbPwLAfSPvHOJvSKY3oatdlMwknQY4b3s2J6kLzGLnzrywaNzIlOTOecQEXEiF0H4VXZcvhJiQ+HSUAEXnB6c3TSm4cwAdgv5L5HVeDVkJkOufMKR0XsqhAXx0qVkhifp1FfB/kS0hq9gWLS1fgSzIxpotQ3ZyrldL2ieq4pB6QxMKa2Pmxzgrxcat7e9KEs4wnCh9FM9mA/WMffA/E0fx/sVZn+NuLAD28MYcgHOmgAULoCkzPsj1jyDgmHSZgTAcXsaaQixZCtWrUSkEavLC5egJThsT05pz/qDC6543XV7Q6opOqSFOWjvLPoQGGsz7B/Th/haH48s3s0yar7MkRPpCfSiXMMsPWEB3EmATY9uiXQHa+HHT2oO/Ca5uMM3H/Aqn0iWhqEUCetSfwx8anRav7qqUeeXp8UTahxIM7PXbZqVjrLPLODEG7X+K4iTSYar5UhMN1IC1Kyjl9qSnHmuKMf8lv/n7MAoAPg3nRCYoYaBPULp9EOlowqSwdAOpUeXN+zZPxy2cwxvwWS7creECFMqt8XKbayqZdNMhMDT0RnNtW7XqxoyOa4lftX91nDudhVGSPubll5QkUpmChGFEkBCBRgg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB08482BB8234F35A07BCC1F93F04D0DM6PR00MB0848namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0844.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 80f24e50-19f9-4405-9273-08d837b0ee25 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2020 13:27:12.0364 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1hvcVAM1mWMl82v7uuruGJx5mlmMnztmrORVlixjKDfxARwDKgLNsTUXqJWYk6DEx7C7sPGGmiYLepav1hR3Dg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0762 Archived-At: Subject: [dispatch] JSONPath or JMESPath? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 13:27:23 -0000 --_000_DM6PR00MB08482BB8234F35A07BCC1F93F04D0DM6PR00MB0848namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable After reviewing the discussion from the Dispatch meeting related to the JSO= NPath standardization effort I noticed there was no mention of JMESPath (pr= onounced JamesPath) (https://www.jmespath.org ). In some recent specification work I was involved with, we were faced with t= he need for this type of query capability. Our investigation led us to mov= e forward with JMESPath instead of JSONPath. The reasons included: * It has a complete ABNF description https://jmespath.org/specification= .html * It has a compliance suite https://jmespath.org/compliance.html * It has a reasonable set of language support https://jmespath.org/libr= aries.html * JMESPath doesn=92t have a dependency on an underlying scripting langu= age JMESPath came from the Python world and has been picked up by both AWS and = Azure as a query capability in their command line tools. This drives a sig= nificant amount of exposure to developers. https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-output.html#cli-= usage-output-filter https://docs.microsoft.com/en-us/cli/azure/query-azure-cli?view=3Dazure-cli= -latest While I do believe there is value in standardizing a tech that has wide usa= ge like JSONPath, due to the current challenges with JSONPath implementatio= n variations, would it more valuable to try and coalesce the industry aroun= d an option that already has a formally defined grammar and compliance test= s? Darrel --_000_DM6PR00MB08482BB8234F35A07BCC1F93F04D0DM6PR00MB0848namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

After reviewing the discussion from the Dispatch mee= ting related to the JSONPath standardization effort I noticed there was no = mention of JMESPath (pronounced JamesPath)  (https://www.jmespath.org ).

 

In some recent specification work I was involved wit= h, we were faced with the need for this type of query capability.  Our= investigation led us to move forward with JMESPath instead of JSONPath.&nb= sp; The reasons included:

 

 

JMESPath came from the Python world and has been pic= ked up by both AWS and Azure as a query capability in their command line to= ols.  This drives a significant amount of exposure to developers.

https://docs.aws.ama= zon.com/cli/latest/userguide/cli-usage-output.html#cli-usage-output-filter<= /a>

https://docs.microsoft.com/en-us= /cli/azure/query-azure-cli?view=3Dazure-cli-latest

 

While I do believe there is value in standardizing a= tech that has wide usage like JSONPath, due to the current challenges with= JSONPath implementation variations, would it more valuable to try and coal= esce the industry around an option that already has a formally defined grammar and compliance tests?

 

Darrel



 

--_000_DM6PR00MB08482BB8234F35A07BCC1F93F04D0DM6PR00MB0848namp_-- From nobody Mon Aug 3 07:06:39 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8AA3A0AB0 for ; Mon, 3 Aug 2020 07:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=vmware.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 lTUcEwqzRbkI for ; Mon, 3 Aug 2020 07:06:37 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2087.outbound.protection.outlook.com [40.107.237.87]) (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 13C963A0AAE for ; Mon, 3 Aug 2020 07:06:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dldWB7sXp1+IjIeZt1ElNoTrGSH/t5dtEcc2IvJrHjq5FK2xG0ib5Q/NrCHCiq8piRnyTmaxddXEJk7YoWqVuVjYS8ou3E9XBa1kGMR/4gO6LC8xX4yE7Rqhhz+GEmLOhvPonFc1OhccXNxdmRscHrAl/APHANfKUFr/J+TojfgKFAsAGivmJ19/hbMAnHo+GYoG1UFnK+T5gWhqSQ68jpSjVfa8KlPQLkSq4VTLr1LYlmG2P4WD8uNUazxmlYDFZLYXFBUBTGHJC2tITarOp2S+cYxsTkdwAP8xtEn0ZXzXoQRtD45hfms2ZYjKueARIOaMqyg2vqPHvwM/RddNjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FHTgj//pIPCeABf4YtJlVWp0prPvCTTg470o7CrBE28=; b=WFLjl+j89okOTqSyo9CWgxbfPv1e271RFdC6r+sDmP/OdT6/DHUYnNsAMbopPO80VKdbSshccsyXChXhPT4d1fYngWtpFAqh4LrAfleXcJZj/zHtwST3FFnyHx7q2qkbMBBbRQXGodnhnPB/MfrX/vtQsyAK4GQO1LI8av+NYP7X133gY3DS2rhVy3j3f0+sJBP784KirOcXD/lTM//5lCBocytprmpifUjz1Jlla4+KkVwktZP5ry4SzW3q2Fca/VO1F9UxWxK8w21N0pyUpjvI2nNtAbOr2W/wtKqgup7dxlvKgT4rxYdCyb/pOqa5zKtsOwG6FYZJHjPLk6q1Mw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=vmware.com; dmarc=pass action=none header.from=vmware.com; dkim=pass header.d=vmware.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vmware.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FHTgj//pIPCeABf4YtJlVWp0prPvCTTg470o7CrBE28=; b=kKh1s7lYpcOiDA0biTaLKZvCVdQQZB7G8DsUsKS0WcKQaCKd2N2pZghxWlBcxOZ1Y3vf1/ipDUL2wz9MsANyDvMqzjExVY7JttdG7m2CpYfaWVcHRlL4pHi3tDMVWv6IrVK5Kw9Jfugq2E6obSHtO1Tk/jLRayt2pycymBhYB4Y= Received: from DM5PR0501MB3766.namprd05.prod.outlook.com (2603:10b6:4:7c::29) by DM6PR05MB4314.namprd05.prod.outlook.com (2603:10b6:5:9e::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.9; Mon, 3 Aug 2020 14:06:32 +0000 Received: from DM5PR0501MB3766.namprd05.prod.outlook.com ([fe80::e93d:dbc3:e9ce:7bc8]) by DM5PR0501MB3766.namprd05.prod.outlook.com ([fe80::e93d:dbc3:e9ce:7bc8%3]) with mapi id 15.20.3261.014; Mon, 3 Aug 2020 14:06:32 +0000 From: Glyn Normington To: Darrel Miller CC: "dispatch@ietf.org" Thread-Topic: [dispatch] JSONPath or JMESPath? Thread-Index: AQHWaZZ7NPtRChyZ5EOmdm2UGgqlJakma2aA Date: Mon, 3 Aug 2020 14:06:32 +0000 Message-ID: <1E1CECE4-8E69-4E1C-8429-70CBD044522A@vmware.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=vmware.com; x-originating-ip: [195.213.80.251] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 83a43280-027e-4e26-ccc6-08d837b66ce1 x-ms-traffictypediagnostic: DM6PR05MB4314: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +QlzpQZQjbqWdbYc7ahKKzwbWqbfLn3E3yi3jQsXkWWXYfY2AAq+KyIEqLeJ+8+4fFXYv0iLK7QTScpL5WgDJOiaJFavY7jouiJHdapmkyKzxV26M3Fofs0og7/xc1TlUqczpoqTYdOiEilWrrczdl8YNnfoS4FcXIMkdZT2haiaS3VMKLEeRGdaf8c8VWyLV9bXqDbSUGw79ATFnfLXZsxdOgaUT4OIcuKsynQrnc3Y3dwyRWqK3ghEfFg94RVoUpB+2PmoINs85ydm9q9riT/ZCAxGHhK7T5B5iQpyYpfPevclqko/t1HHr6aN5WnTkq5aMMRhLIB8QaNRAkPKAIeRrbi15gsI2nK0UB44cOFBbHlGOxfxL4X2zngFlqR23XsbzcJFLJubog/DykP+vQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR0501MB3766.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(396003)(376002)(39860400002)(366004)(136003)(26005)(5660300002)(186003)(53546011)(6506007)(2906002)(45080400002)(2616005)(478600001)(6486002)(8936002)(36756003)(316002)(8676002)(966005)(86362001)(71200400001)(66476007)(66556008)(91956017)(76116006)(83380400001)(64756008)(33656002)(66946007)(4326008)(6512007)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: +iRhrpXMb7kCt/HIeHOVg5e+Ay7h089oeSWRfnTwmI3huVDKHZOsJ6VQZ2mRjAmGUi3ChIW4PdN8+FI04FxB/S37P5LZz6CXThnrW2SQfMqXsPiJWtxDUGi7WiCKj8P1eBBnqr39ewXO+8xHPnJJMxQqLrCJ9rG9HidBULL38bt+kmk2o1cZ+oNsF6esrshuON0YKX4tKO2RhallQT8LoLngMoh2qUaBX5av0j7maqcpKL+6GDum77UDNuoYEP6/1v4fs84Rkq/vkF8W3k1dejexf/mjhh/cbBzHSrsfde93hyEY6I8JtZd5N4WUp0+aFUPf8AVh7TYNWM6hljVR/YVQIRrkHzl3vK4FiFeteyUl2oGZAX7uKJZG33jQy+YG9fDqhQYW8jfi+IEyCfgpOjDCO5vIRiL0W2bpGxZgjorQe7j1Z8uyaiz9ribJs3NRwS3iT8chZMFJjYiprtaZNtua7k6LEYH+u0/ogRQ3z4V+nZBbamH8knv5lV/KkWIeAoK04lZYXWmVSoeC3VoHw2nWERdDiJWB87GU4Hxbnek8DsCUAclhe8zcqCXq52lmWJrRYqW1StQv6w1XbIjDV/utdABvWEmZeI0doukpnaKt3e5TyH/TFoHr8r6jlZB0HoYLwMfDETdxWMbD6BsnJA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR0501MB3766.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 83a43280-027e-4e26-ccc6-08d837b66ce1 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2020 14:06:32.1808 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FQi/Amb9EkUFqv/d4Wsa0Pms1i2p2KRxrD+HGRmxXSj9dyn7QzH1z/VVP5abd9XwZzy+X4oBXYKOiQsCb5ggig== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4314 Archived-At: Subject: Re: [dispatch] JSONPath or JMESPath? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 14:06:38 -0000 SGkgRGFycmVsDQoNClRoYW5rcyBmb3IgYnJpbmdpbmcgdXAgSk1FU1BhdGguIEl04oCZcyBjZXJ0 YWlubHkgYW4gZXhjZWxsZW50IHByb2plY3QuIFdlIGhhdmUgeWV0IHRvIGFncmVlIGEgY2hhcnRl ciBmb3IgdGhlIHN0YW5kYXJkaXNhdGlvbiBvZiBKU09OUGF0aC4gSSBwZXJzb25hbGx5IGJlbGll dmUgb25lIGdvYWwgc2hvdWxkIGJlIHRvIG1pbmltaXNlIHRoZSBtaWdyYXRpb24gY29zdCwgYm90 aCBmb3IgdXNlcnMgYW5kIG1haW50YWluZXJzIG9mIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucy4g T1RPSCBhZG9wdGluZyBKTUVTUGF0aCB3b3VsZCBzYXZlIGEgdG9ubmUgb2Ygc3BlYyB3b3JrLCBz byBJIGd1ZXNzIGl0IGFsbCBkZXBlbmRzIG9uIHRoZSBnb2FscyB3ZSBhZ3JlZSBpbiB0aGUgY2hh cnRlci4gSSBob3BlIHlvdSBjYW4gam9pbiBpbiB0aGF0IGRpc2N1c3Npb24gKHdoZW4gaXQgZ2V0 cyBnb2luZykgb3ZlciBhdCBqc29ucGF0aEBpZXRmLm9yZy4NCg0KUmVnYXJkcywNCkdseW4NCg0K PiBPbiAzIEF1ZyAyMDIwLCBhdCAxNDoyNywgRGFycmVsIE1pbGxlciA8RGFycmVsLk1pbGxlcj00 MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KPiANCj4gQWZ0ZXIgcmV2aWV3 aW5nIHRoZSBkaXNjdXNzaW9uIGZyb20gdGhlIERpc3BhdGNoIG1lZXRpbmcgcmVsYXRlZCB0byB0 aGUgSlNPTlBhdGggc3RhbmRhcmRpemF0aW9uIGVmZm9ydCBJIG5vdGljZWQgdGhlcmUgd2FzIG5v IG1lbnRpb24gb2YgSk1FU1BhdGggKHByb25vdW5jZWQgSmFtZXNQYXRoKSAgKGh0dHBzOi8vd3d3 LmptZXNwYXRoLm9yZyApLg0KPiAgDQo+IEluIHNvbWUgcmVjZW50IHNwZWNpZmljYXRpb24gd29y ayBJIHdhcyBpbnZvbHZlZCB3aXRoLCB3ZSB3ZXJlIGZhY2VkIHdpdGggdGhlIG5lZWQgZm9yIHRo aXMgdHlwZSBvZiBxdWVyeSBjYXBhYmlsaXR5LiAgT3VyIGludmVzdGlnYXRpb24gbGVkIHVzIHRv IG1vdmUgZm9yd2FyZCB3aXRoIEpNRVNQYXRoIGluc3RlYWQgb2YgSlNPTlBhdGguICBUaGUgcmVh c29ucyBpbmNsdWRlZDoNCj4gCeKAoiBJdCBoYXMgYSBjb21wbGV0ZSBBQk5GIGRlc2NyaXB0aW9u IGh0dHBzOi8vam1lc3BhdGgub3JnL3NwZWNpZmljYXRpb24uaHRtbA0KPiAJ4oCiIEl0IGhhcyBh IGNvbXBsaWFuY2Ugc3VpdGUgaHR0cHM6Ly9qbWVzcGF0aC5vcmcvY29tcGxpYW5jZS5odG1sDQo+ IAnigKIgSXQgaGFzIGEgcmVhc29uYWJsZSBzZXQgb2YgbGFuZ3VhZ2Ugc3VwcG9ydCBodHRwczov L2ptZXNwYXRoLm9yZy9saWJyYXJpZXMuaHRtbA0KPiAJ4oCiIEpNRVNQYXRoIGRvZXNu4oCZdCBo YXZlIGEgZGVwZW5kZW5jeSBvbiBhbiB1bmRlcmx5aW5nIHNjcmlwdGluZyBsYW5ndWFnZQ0KPiAg DQo+ICANCj4gSk1FU1BhdGggY2FtZSBmcm9tIHRoZSBQeXRob24gd29ybGQgYW5kIGhhcyBiZWVu IHBpY2tlZCB1cCBieSBib3RoIEFXUyBhbmQgQXp1cmUgYXMgYSBxdWVyeSBjYXBhYmlsaXR5IGlu IHRoZWlyIGNvbW1hbmQgbGluZSB0b29scy4gIFRoaXMgZHJpdmVzIGEgc2lnbmlmaWNhbnQgYW1v dW50IG9mIGV4cG9zdXJlIHRvIGRldmVsb3BlcnMuDQo+IGh0dHBzOi8vZG9jcy5hd3MuYW1hem9u LmNvbS9jbGkvbGF0ZXN0L3VzZXJndWlkZS9jbGktdXNhZ2Utb3V0cHV0Lmh0bWwjY2xpLXVzYWdl LW91dHB1dC1maWx0ZXINCj4gaHR0cHM6Ly9kb2NzLm1pY3Jvc29mdC5jb20vZW4tdXMvY2xpL2F6 dXJlL3F1ZXJ5LWF6dXJlLWNsaT92aWV3PWF6dXJlLWNsaS1sYXRlc3QNCj4gIA0KPiBXaGlsZSBJ IGRvIGJlbGlldmUgdGhlcmUgaXMgdmFsdWUgaW4gc3RhbmRhcmRpemluZyBhIHRlY2ggdGhhdCBo YXMgd2lkZSB1c2FnZSBsaWtlIEpTT05QYXRoLCBkdWUgdG8gdGhlIGN1cnJlbnQgY2hhbGxlbmdl cyB3aXRoIEpTT05QYXRoIGltcGxlbWVudGF0aW9uIHZhcmlhdGlvbnMsIHdvdWxkIGl0IG1vcmUg dmFsdWFibGUgdG8gdHJ5IGFuZCBjb2FsZXNjZSB0aGUgaW5kdXN0cnkgYXJvdW5kIGFuIG9wdGlv biB0aGF0IGFscmVhZHkgaGFzIGEgZm9ybWFsbHkgZGVmaW5lZCBncmFtbWFyIGFuZCBjb21wbGlh bmNlIHRlc3RzPw0KPiAgDQo+IERhcnJlbA0KPiANCj4gDQo+ICANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZGlzcGF0Y2ggbWFpbGluZyBsaXN0 DQo+IGRpc3BhdGNoQGlldGYub3JnDQo+IGh0dHBzOi8vbmFtMDQuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4l MkZsaXN0aW5mbyUyRmRpc3BhdGNoJmFtcDtkYXRhPTAyJTdDMDElN0Nub3JtaW5ndG9uZyU0MHZt d2FyZS5jb20lN0M0YjZlZGUxN2M1Mjg0ZWE0YWIxMjA4ZDgzN2IwZmJmYiU3Q2IzOTEzOGNhM2Nl ZTRiNGFhNGQ2Y2Q4M2Q5ZGQ2MmYwJTdDMCU3QzAlN0M2MzczMjA1ODA1NzExNjA0NTcmYW1wO3Nk YXRhPWlkNThkMnYxbjYxbmxPYldOWEx0MjNwdjJHSVZ4d0VZdFp5N3h1clZIakUlM0QmYW1wO3Jl c2VydmVkPTANCg0K From nobody Tue Aug 4 06:48:48 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27013A07E0 for ; Tue, 4 Aug 2020 06:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ispirata.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 lcncVInz38GJ for ; Tue, 4 Aug 2020 06:48:45 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 29A6A3A07DB for ; Tue, 4 Aug 2020 06:48:40 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id c15so1252002wrs.11 for ; Tue, 04 Aug 2020 06:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ispirata.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=T01UKvLM6ACjIWDk4D2xSZOmChLFJgV54mnje+Ru/mU=; b=H3n1JFvYjpThTt9rxZFJADSDf0Y4UtYYJ5N/YaBZEPMwXJdZ+UO7cbtH9M03NBluUM ThD+tLfUU+KXuahu0xIqgslbn1KEwSrmRQZMVjNWt/eSaBbf8DjwL/QUhdJf0gzHJ86b r8WAwR9T6fM8thdbTrmqfVx1QtWoJsy/EHWpb5ocWz7iCNQUiIpYBNEotvg6UN+SQSf4 djQLSkFd05J/HbBMU2BH6inUT0Dmsm7GtMT6RrPShsF8Z96duFP3UhXTFOvzliVdz88E +wBehT2U5evUHj+MV+IPnxahxZXeDYuNab+dU6TGhaBplrm1fesz4g96vaw2RTsKQGMZ Hf/g== 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=T01UKvLM6ACjIWDk4D2xSZOmChLFJgV54mnje+Ru/mU=; b=J6gvhEBYp0fqtsTM+7IfroegoaNJkpjBK4IOqJDzgIG3OTeK24khzM1B/1yZZSazac 988sWNcd9i+dGq4zSNV9d0klXGhPT//4CApgF2GaIGYk6lSraPgS+MdBygHBAImtQYZX vgbaa1YF0JkJGZPJTNppGObxrA5Y/PzhiXabx46H6m9i9pbE+6lD477nG+9GrInZhzrx b/LpsTZZXoadY+aWw96Ca1MmSERrbkflNhRBsP7Z3kfSlygo4hW5i/AFJMnDEVamnKsM VWE/5QxhcEIzph9CxJcPxaGAVjTYImNGVEEyZzZAGgZg7XZb04OOWN27Lge6xRwNC9w1 uQwg== X-Gm-Message-State: AOAM533iwd50ftdfWzzPlb7Whs4jobA0mPUfMF/HDS+4XylEyUSTAlWc /c6PejFzlfsOvNE1KbFn3F2N85/xUrmavqsrsCwLaRYIQ+o= X-Google-Smtp-Source: ABdhPJxGX1AYXhX19HxnB76ewa6FY6xqSpR/mb9jQeNJ6fVhj96p7x72nFi2d0mTQfO1LoHSYFyzu7UMc7D179ak0vY= X-Received: by 2002:adf:efd2:: with SMTP id i18mr18908845wrp.32.1596548918468; Tue, 04 Aug 2020 06:48:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Davide Bettio Date: Tue, 4 Aug 2020 15:48:02 +0200 Message-ID: To: Darrel Miller Cc: "dispatch@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dispatch] JSONPath or JMESPath? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 13:48:47 -0000 Hello, I agree, JMESPath looks excellent however I would like to raise points on this topic: * both JMESPath and JSONPath have a number of users and softwares which are using them (JSONPath: [1], [2], etc...) * JSONPath is easier to implement compared to JMESPath * JSONPath has wider number of different implementations (and different supported languages) * without a JSONPath standard people will continue using and implementing it, but all inconsistencies will stay there without any fix (and standard) * a number of supported JSONPath paths are also valid JMESPath paths * most JSONPath inconsistencies come out when dealing with corner cases and nearly ill formed paths * a JSONPath consensus can be easily found when dealing with all the most common use cases * JSONPath "scripting" is mostly used for filtering, a strict spec is required, but I don't see it as a stopper issue * JMESPath has support for some useful functions such as sort, ceil, etc. which they enable more powerful operations So what I really see here as a major key difference is that JMESPath has support for functions, which they require a more complex implementation, and I'm not sure if JSONPath users are interested in them (to be fairly honest I would find them useful, but I'm not sure about any other else). Regards, Davide Bettio. [1]: https://kubernetes.io/docs/reference/kubectl/jsonpath/ [2]: https://docs.oracle.com/en/database/oracle/oracle-database/12.2/adjsn/= json-path-expressions.html#GUID-2DC05D71-3D62-4A14-855F-76E054032494 Il giorno lun 3 ago 2020 alle ore 15:27 Darrel Miller ha scritto: > > After reviewing the discussion from the Dispatch meeting related to the J= SONPath standardization effort I noticed there was no mention of JMESPath (= pronounced JamesPath) (https://www.jmespath.org ). > > > > In some recent specification work I was involved with, we were faced with= the need for this type of query capability. Our investigation led us to m= ove forward with JMESPath instead of JSONPath. The reasons included: > > It has a complete ABNF description https://jmespath.org/specification.htm= l > It has a compliance suite https://jmespath.org/compliance.html > It has a reasonable set of language support https://jmespath.org/librarie= s.html > JMESPath doesn=E2=80=99t have a dependency on an underlying scripting lan= guage > > > > > > JMESPath came from the Python world and has been picked up by both AWS an= d Azure as a query capability in their command line tools. This drives a s= ignificant amount of exposure to developers. > > https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-output.html#cl= i-usage-output-filter > > https://docs.microsoft.com/en-us/cli/azure/query-azure-cli?view=3Dazure-c= li-latest > > > > While I do believe there is value in standardizing a tech that has wide u= sage like JSONPath, due to the current challenges with JSONPath implementat= ion variations, would it more valuable to try and coalesce the industry aro= und an option that already has a formally defined grammar and compliance te= sts? > > > > Darrel > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Tue Aug 4 16:16:53 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2E73A1229 for ; Tue, 4 Aug 2020 16:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=ZCbLcOTu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TfEIvAgV 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 30753cVLu5G2 for ; Tue, 4 Aug 2020 16:16:43 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D51783A1228 for ; Tue, 4 Aug 2020 16:16:42 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id E0E45BA1; Tue, 4 Aug 2020 19:16:41 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 04 Aug 2020 19:16:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=Y /OnNYqkFUaw8pUlKZrTLFo1myCA6ZJTJ2oilwWuQsA=; b=ZCbLcOTu4rYmraR2w TJixCRj+k1mr87bYdp8bOjBD28da8xabUUvQ0S59z52FwpNjeOb/s7WYWmEMDu6Y Vb/R1Vy7sq7qgic58/5Z+nOekfWNft6fqu/mMsCRPsPPsfYgISlue9+dAcNun9GV RxCyhYfldWaKIRz7H+E4lQRjcdftvA7eMqsIIkBm7GmINfwyEMvNGC8JZuidk6bU PTMn9R6uRKNiVrUBJimAozz2aE93uApZXyqsaCtmsbKmQe8LiGl+oW2PjTlMMcoB WZgoXBLOwtCYw19IOAm+Xjrglpme5nItrXaFiYupei0Faurv6G5ji+AWeIw/d261 UFhkQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=Y/OnNYqkFUaw8pUlKZrTLFo1myCA6ZJTJ2oilwWuQ sA=; b=TfEIvAgV6hFe/svLMJtEE2kIZpOKNR5SseV0OlLbm6kLawOxJDCSMIfj/ d6pbO7iaw3VsdQuBYTmvN11N+NwIGfFmsQVyaP2Ha/5UC0kF083RaafUFWDtUFYE CbqnWpH9aKESjvUwU2Y1NjOti6jyU1jDhDzuT/OB6VAtNi03/8yD5nA512a4sOgd f8ANJfUA+hyDpx5pc4rk9dNYlwo37oLW0GBX0vj6HYnYUUGLbgwBUPfuuSu8JEKC w6gd1Q5bcDy4Ao7UIbM6fopEB7agNA38WCCJmG9HeM+Yy6nXS94SLcH4uEKYAP+i WBUh5Ev/gYOXChMVrNOtlTq2FsAqw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrjeejgddvtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepjeevheelieekueeutddthfekgfeuvdehvedtuefhfffflefgjeeljeeggedufeeh necuffhomhgrihhnpehkuhgsvghrnhgvthgvshdrihhopdhorhgrtghlvgdrtghomhdpjh hmvghsphgrthhhrdhorhhgpdgrmhgriihonhdrtghomhdpmhhitghrohhsohhfthdrtgho mhdpihgvthhfrdhorhhgpdhmnhhothdrnhgvthenucfkphepudduledrudejrdduheekrd dvhedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep mhhnohhtsehmnhhothdrnhgvth X-ME-Proxy: Received: from marks-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 1BB1330600A6; Tue, 4 Aug 2020 19:16:38 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: Date: Wed, 5 Aug 2020 09:16:36 +1000 Cc: Darrel Miller , "dispatch@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Davide Bettio X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dispatch] JSONPath or JMESPath? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 23:16:52 -0000 Just some general comments (I don't have any particular insights or = preferences regarding technology here): > On 4 Aug 2020, at 11:48 pm, Davide Bettio = wrote: >=20 > Hello, >=20 > I agree, JMESPath looks excellent however I would like to raise points > on this topic: >=20 > * both JMESPath and JSONPath have a number of users and softwares > which are using them (JSONPath: [1], [2], etc...) > * JSONPath is easier to implement compared to JMESPath > * JSONPath has wider number of different implementations (and > different supported languages) > * without a JSONPath standard people will continue using and > implementing it, but all inconsistencies will stay there without any > fix (and standard) The purpose of standardisation isn't to preclude all other approaches = being used, nor is it to address all possible problems in the world. = What we're trying to do is choose a suitable basis for future work -- = one that will result in the best combination of interoperability, = deployment, and functionality. > * a number of supported JSONPath paths are also valid JMESPath paths > * most JSONPath inconsistencies come out when dealing with corner > cases and nearly ill formed paths Unfortunately, those are the usual places that interoperability becomes = hard - and eventually necessary to consider. Consider the history of = HTML. > * a JSONPath consensus can be easily found when dealing with all the > most common use cases That's only something we can find out by actually trying to achieve = consensus; it's premature to say it's easy. > * JSONPath "scripting" is mostly used for filtering, a strict spec is > required, but I don't see it as a stopper issue > * JMESPath has support for some useful functions such as sort, ceil, > etc. which they enable more powerful operations >=20 > So what I really see here as a major key difference is that JMESPath > has support for functions, which they require a more complex > implementation, and I'm not sure if JSONPath users are interested in > them (to be fairly honest I would find them useful, but I'm not sure > about any other else). >=20 > Regards, > Davide Bettio. >=20 > [1]: https://kubernetes.io/docs/reference/kubectl/jsonpath/ > [2]: = https://docs.oracle.com/en/database/oracle/oracle-database/12.2/adjsn/json= -path-expressions.html#GUID-2DC05D71-3D62-4A14-855F-76E054032494 >=20 > Il giorno lun 3 ago 2020 alle ore 15:27 Darrel Miller > ha scritto: >>=20 >> After reviewing the discussion from the Dispatch meeting related to = the JSONPath standardization effort I noticed there was no mention of = JMESPath (pronounced JamesPath) (https://www.jmespath.org ). >>=20 >>=20 >>=20 >> In some recent specification work I was involved with, we were faced = with the need for this type of query capability. Our investigation led = us to move forward with JMESPath instead of JSONPath. The reasons = included: >>=20 >> It has a complete ABNF description = https://jmespath.org/specification.html >> It has a compliance suite https://jmespath.org/compliance.html >> It has a reasonable set of language support = https://jmespath.org/libraries.html >> JMESPath doesn=E2=80=99t have a dependency on an underlying scripting = language >>=20 >>=20 >>=20 >>=20 >>=20 >> JMESPath came from the Python world and has been picked up by both = AWS and Azure as a query capability in their command line tools. This = drives a significant amount of exposure to developers. >>=20 >> = https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-output.html#cli= -usage-output-filter >>=20 >> = https://docs.microsoft.com/en-us/cli/azure/query-azure-cli?view=3Dazure-cl= i-latest >>=20 >>=20 >>=20 >> While I do believe there is value in standardizing a tech that has = wide usage like JSONPath, due to the current challenges with JSONPath = implementation variations, would it more valuable to try and coalesce = the industry around an option that already has a formally defined = grammar and compliance tests? >>=20 >>=20 >>=20 >> Darrel >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Mark Nottingham https://www.mnot.net/ From nobody Tue Aug 4 21:37:06 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831C23A0A9D for ; Tue, 4 Aug 2020 21:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=Td/dQvOM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=evMYSmKX 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 1rHoAXlEfxtD for ; Tue, 4 Aug 2020 21:37:03 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11B7C3A0128 for ; Tue, 4 Aug 2020 21:37:02 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 3B9C35C013C; Wed, 5 Aug 2020 00:37:02 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 05 Aug 2020 00:37:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=L rC5RqLp2AuziWRBLmOs1e7D5Rrq1NSsdYhc/wxYhbY=; b=Td/dQvOMYjt+xVaPE P596fpbHvT58kWTQdobDhMfH/m8MbjKUxZ4wdxPD8f1z1+8STnRl0MDTsXP1e5Fn bA1a0Nv+sFfeiApNJYU83u4l2mXviCs6LFgoN+akfuccLW8jS1LokPig7lfCMFu6 oiS43XvG8tNZlJMAe2ojidbzX2kpFHYJ1eDQfBDKKaxnUzIvSqWz84/kBDyTwYl0 +bdKHMCpXacA6qflv7WKOpXOR+JaFaSR7NcpcUe5P0fkNw6+Ebg1KfeaOJRAB2l8 p6ZiyMCeTLuJaOU/0D/3Trqfhyv/nh4n67tFz5RtY1Z0eN8OVY9fZO7e/YAY892h 3RYkw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=LrC5RqLp2AuziWRBLmOs1e7D5Rrq1NSsdYhc/wxYh bY=; b=evMYSmKXVTlLIyScPMIEMYdyDYl4FOcN4oaowhsD4FIITU0HYfIXCDDNf RoPyENozwQHojzvyOqkWohzoAy9m1Z7QpidsbXxaeG+uS81xWQ3mRx3tbayo+IC5 dCJh+FluSyvVSux4v2eRN5PvYPtmvfpC1ilSsSWoZ2SCkxOlfDUep7COr3SvYzpZ b9SxEJHjebVAQInGoWwcIczVh4FishANOkykmdq1IXr5Uoo5NBFHLKmgF+NtPsMZ xJBkItvo0h38gdZ4HyeObWnERGfUib/1yGctXVDkI4ee5an1DNv84k9lRxmvIXJP sXdLUHUdRtnEkR4yTEPxHSVpExjxA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrjeejgdekiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepvefffffhudetveevhfeuffeigedtuedtheffleetffeftddtgeegjeehieeuteet necuffhomhgrihhnpehmnhhothdrnhgvthenucfkphepudduledrudejrdduheekrddvhe dunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhn ohhtsehmnhhothdrnhgvth X-ME-Proxy: Received: from marks-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id BCC3F328005A; Wed, 5 Aug 2020 00:36:59 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: Date: Wed, 5 Aug 2020 14:36:56 +1000 Cc: DISPATCH WG Content-Transfer-Encoding: quoted-printable Message-Id: <0B33EE11-84E6-4ED0-B1E0-713A4F75FBFD@mnot.net> References: <667c26a0-c0a3-96a8-4bd9-18568607ca5f@gmx.de> To: Wenbo Zhu X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dispatch] Building Blocks for HTTP APIs - next steps X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 04:37:06 -0000 > On 1 Aug 2020, at 3:46 am, Wenbo Zhu = wrote: >=20 > > HTTP is often for not only Web browsing, but also machine-to-machine = communication .... >=20 > Are we talking about "HTTP as a transport" here, which includes e.g. = "apis" (external consumption, e.g.. ws), micro-services (rpcs), = messaging frameworks, non-browser-clients etc etc ... ? Yes. The charter frames the work by starting with 'HTTP is often for not = only Web browsing, but also machine-to-machine communication'... >=20 > > broad representation from across the industry -- e.g., API gateway = vendors (and other intermediaries), API consultants, API tool vendors, = in-house API team >=20 > This seems to suggest we are only interested in use cases when HTTP is = used as the transport for public API end-points I think that's a primary interest; this being the IETF, we're interested = in the Internet, and if private networks can get benefit / leverage from = what we do, that's great, but we shouldn't be constrained by them. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Tue Aug 4 22:10:06 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8943A0B3A for ; Tue, 4 Aug 2020 22:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BheWNAAO2Nbb for ; Tue, 4 Aug 2020 22:10:04 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 E441B3A0B38 for ; Tue, 4 Aug 2020 22:10:03 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id a5so29373023ioa.13 for ; Tue, 04 Aug 2020 22:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Cd25bFF36OB1uINhNlAvbCNgBWdliynWepGSet+gAY4=; b=hJKwgacZuE32pLzYPk6FHEAeZKBw3bkLFNDcKuLF7a9Wm1RkySEcln0+dy8uSuZ04a jRH7LxpTKtkg/Erz7s+x5HKqY48h8ceiussOtqvxGOyvbzdTEjHhghuYzQ6Ke9wXIL48 xbW/SelSp8xYwyBC2RKtOuz4rfVRsb8xh7EEMUEdFJdL0Hsf2F7YYiNOpui++EbYWdog UAkFk1so1H78EUkMbEsCpL+av9AHqHTvh3JF9ZQNtuG6Jx9wk/eoXne08K8byc9j82gG QZDIgQiCAFajHLW1HBLv3g3AWrQD3/kIDX6nHjmvsQBJptZnBn5nxMzEr91KgcpPZDt8 5GGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Cd25bFF36OB1uINhNlAvbCNgBWdliynWepGSet+gAY4=; b=b83szMSPcrZnrhg7ZHqIwF2RRDSviaXc5GZLFYsggweIHrg5Wlz71DgLsudmE2d4uz AqyqnOVMzGPGW9nAVUrEGg2CttnDlIItrYEzp2xPazXY484SpTBCpaSlNZB4CcLKYqWu gCAGyiOcUQZq6ptYrB/xXciaPmdRU7ep7tMLXpicl9Md0pNkCoLDDwfwvWeKkkYDvL9Z mG7P3nG9lAt8L6qTvwbTsCVPHnDZ06Is4GM9UlPmOCLVQWjX7dP9OXePDcYQ8GG06YUN /qwBKe6H9w1bIu+Wt0nnAbbW0Hnuu4hukG8B3y1KTDuDAAzyJLsAwk28kdJ79skgDZAf Q9Zg== X-Gm-Message-State: AOAM530guIoCd2QZRuTfsiiz1fd/1SCOSGvTycroVZJ0GFC8ehlJy9SC bLUFHoa1w9SSpZ/D4kyx3Pynen8sN6VSYPQIN+E= X-Google-Smtp-Source: ABdhPJw3RLiWA3qFT3P9ptos/7OON/zBLPO8W2+BZrH09PSZH25AwvewvZauRwE2+wTBMEFHOc2irJT65Q/tAn9ACFo= X-Received: by 2002:a05:6602:2417:: with SMTP id s23mr1544090ioa.94.1596604203053; Tue, 04 Aug 2020 22:10:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Tue, 4 Aug 2020 22:09:48 -0700 Message-ID: To: Darrel Miller Cc: Mark Nottingham , DISPATCH WG Content-Type: multipart/alternative; boundary="0000000000005eb6a105ac1a62c1" Archived-At: Subject: Re: [dispatch] Building Blocks for HTTP APIs - next steps X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 05:10:05 -0000 --0000000000005eb6a105ac1a62c1 Content-Type: text/plain; charset="UTF-8" On Sat, Aug 1, 2020 at 8:18 PM Darrel Miller wrote: > Hi Rob, > > > > There is a sub group within the Linux Foundation GraphQL project that is > focused on creating a specification of how GraphQL should be layered on > HTTP. > https://github.com/graphql/graphql-over-http/blob/master/spec/GraphQLOverHTTP.md > > > > I think the HTTP API Working group could co-ordinate with that group to > identify any gaps in HTTP conventions/patterns or guidance that would help > with GraphQL layering over HTTP. > > > > From the perspective of HTTP, GraphQL is media type for the query and one > for the schema. The response is application/json... > I don't agree. The reference implementations of GraphQL expect application/json, but higher-traffic services do not tend to use that format. See: https://spec.graphql.org/June2018/#sec-Serialization-Format While this is not an objection, I think the WG might want to avoid defining APIs in terms of links and JSON, when that is becoming a less common tactic. thanks, Rob --0000000000005eb6a105ac1a62c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Aug 1, 2020 at 8:18 PM Darrel Mil= ler <Darrel.Miller@micros= oft.com> wrote:

Hi Rob,

=C2=A0

There is a sub group within the Linux Foundation Gra= phQL project that is focused on creating a specification of how GraphQL sho= uld be layered on HTTP. https://github.com/graphql/graphql-over-http/blob/master/spec/GraphQLOverHT= TP.md

=C2=A0

I think the HTTP API Working group could co-ordinate= with that group to identify any gaps in HTTP conventions/patterns or guida= nce that would help with GraphQL layering over HTTP.

=C2=A0

From the perspective of HTTP, GraphQL is media type = for the query and one for the schema.=C2=A0 The response is application/jso= n...

=C2=A0
I don't agree. T= he reference implementations of GraphQL expect application/json, but higher= -traffic services do not tend to use=C2=A0that format. See:=C2=A0https://spec.= graphql.org/June2018/#sec-Serialization-Format

While this is not an objection, I think=C2=A0the WG might want to avoid de= fining APIs in terms of links and JSON, when that is becoming a less common= tactic.

thanks,
Rob

--0000000000005eb6a105ac1a62c1-- From nobody Wed Aug 5 07:34:22 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC2A3A090F; Wed, 5 Aug 2020 07:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09M9_pKOZlBY; Wed, 5 Aug 2020 07:34:19 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00060.outbound.protection.outlook.com [40.107.0.60]) (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 3A7563A0918; Wed, 5 Aug 2020 07:34:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FqtyvYdqOQ7k80cTorwGp/2/mImgY0wCXuWfkYmVpoKGjLNcE9mKsy0twM2g8DOjiQSHI8p+JspUEJLBRnUWSCtEshA2V8Vecf1mzv8ZXjGB6Vm6FnfyCtnlZxQh6E4QyEbY2WnMUUeCyCPrbSnWSCXqPwb+6AHBOOz/3rzrCparENIXFpaV594yPptRbyyFLIxfFn+gmdM9fzvHfYX3gQYg5A8WGE8hcSGJRn/d7Yxh0D43DXovfx4KCPeQhrx+3aV1V28wYwn3Yc31wll7m8ska8FvDLoDivwoAjQitIvTA50pIPIPZDGncdbr787oO4VGtTO15HhInPNw5ztU2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9+K4nwNxPYxNiAot6mzXqjST9rr60fyDrX3NxibSU2M=; b=NrFjreN7oP5jj5VnhNJptU34EiDHrjh8dG/G+GkWfWcsEUCQXJMCJyqUgUmfmcoPjt0GpZfMRPcwodJo0tmWVBGI1APXuXMBnIQoU4JFvIobsVbwQilzAUsOUmnJ78gS3+Oe5efLpMsD4Fl/Tl3Xp+9c6DDy+pWffI3ilAN3iKbO/2vqhfqOPGbckQvPasVxlFKXQ2Zf6gU1vp8oksRL9y0JlHH3nXYnl1AOQJOOfHZooTgY4sbq6KTk+9epr9To/4vKtPadM4wp5qMOYmdZeJRR6aPSisePTFC43BOEiQ+GdDcL7KqN3g/onVScNwPQllK2kXi8vC5/rdNGeBAi/g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=9+K4nwNxPYxNiAot6mzXqjST9rr60fyDrX3NxibSU2M=; b=guzh30GU8DFGABcv8sJr+rFKIDdOxC63O3enkvlagk8QRcIp/16BpNWtBk9AJfttSDUClXa+5NzMFdQzZ1L4116BlJ+dnAl2eAX+0awyqyTDzI/3aOXL/Cnd489NdtYiJgZRwUClFJb+PQvW8qWmZJvqNct4oS5lslQWZ8dxW4Y= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR07MB3097.eurprd07.prod.outlook.com (2603:10a6:7:32::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.16; Wed, 5 Aug 2020 14:34:13 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::d95a:be8:b97b:582d]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::d95a:be8:b97b:582d%5]) with mapi id 15.20.3261.016; Wed, 5 Aug 2020 14:34:13 +0000 From: Magnus Westerlund To: "ben@nostrum.com" , "rlb@ipv.sx" CC: "emadomara=40google.com@dmarc.ietf.org" , "dispatch@ietf.org" , "sframe@ietf.org" Thread-Topic: [dispatch] SFRame Next Steps (was Re: SFrame proposed WG charter) Thread-Index: AQHWZ16R4N9P2bY+DUCbQ3y9KXPWG6kpnDqA Date: Wed, 5 Aug 2020 14:34:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2 authentication-results: nostrum.com; dkim=none (message not signed) header.d=none;nostrum.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [98.128.243.14] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c678c91e-1ab8-4a75-bc04-08d8394c9fd1 x-ms-traffictypediagnostic: HE1PR07MB3097: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Uq7DKu4IRCtE/7G4w7jYqWbKkq7ICsBuRQX7RdG5wWarXRmWhYATPL+SWieLV7idOPPkcHrRd4HN8z16hiJKsyOT4TmH6rpIiQmHjzHc9IVISky0ES0qZlxkKyEoBxGg1imxzvrJFLsGKFc6PtKMK0excSM1e1/28nGeInKAO+UAAl9JoBa8XUxXfsfdOhFE02iCJphO6GIibY3uuZTx5YVos7BmSsArdSzjRHkpuugGiVkWfpDXLwr3Nb++A7mEOlKQn9WHdVyCj2aKNp0sd7b6cvuFhc6EipFoRAo0+7WaGflaiANAcIjEdQkF+gX+ptFXyV66TVNZsYM/ECMI1N52+/t3ntKjy2NCTNaA7nohZowYrGNpGgDdqYnepykj4MYCHaa3tT60B3mdYzY0lhLed4XRo79l6QB7txorJCVLjYT/YdfV1QzmREDEMNSPtm8P62GS9dvKQcuBKx/fjw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(396003)(366004)(346002)(39860400002)(66556008)(76116006)(5660300002)(2906002)(66946007)(66446008)(64756008)(66476007)(71200400001)(83380400001)(478600001)(966005)(6512007)(36756003)(186003)(6506007)(53546011)(8936002)(4326008)(110136005)(54906003)(316002)(2616005)(44832011)(6486002)(26005)(86362001)(8676002)(99106002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 3ACB0urKxUwBifblmjqFF+J88IZPMX02Qcf9Xuwf3IZFnvWutEfB3hGFsSO9prXJje09WgRsUILt2B2zzSBZD2XinVXYn89YMJy12HbZfXJbc0xD2ETNbcRLpiLZexWUChR7mjKk2Fgkrv0MSR0Hb5IqqUQm/BOVoyWqD/kXWj4RWGf0L7M0to01NiyPBzOfbuze8eMHhInXGqYhbiWonxm4pxNtKJ9heA24Far1dUtcHsUs1JhDzQdK5PbvfbfrHC+dAfN2DqvnE4Lg5GEItEJrpBk6a2E87a5VOXzXpd/Jg9Igy/+MKs63W9tz3rUz8bPxTCdxX9/3D8f5OOqf48oGGhWVplvClsnQozj8+qLUl+c0IMj3OKciDAU7vqUYrXWo3DFXDCruH6OYaZInMSFSI5YqDFYDXxtECYI5xqKJzEMlK6JMocWsBU66PHikRF2NMZ+cfIrH8hSzTlZz+kGBJrHk9Z0OITSG6NSMz4WfqffSIXEBh2PwIIyP+yfnaC49tl+UKDl/Hv/z1vB30wXpkQUA9+HIpPtz0Dml8an4UPv+EuKFHmMSETtSbPV4jlx73i0HaAP3Jn5P5qzxgk+9wGYP+xFGk2BnwthfxSYNlV+8ji6hqHBFmOZzeQ693BbDNT7vPvnIC/brwggXuw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c678c91e-1ab8-4a75-bc04-08d8394c9fd1 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2020 14:34:13.2706 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /dvB1EZLihYxLUM/ucmeUwd4UKWT1f3PLtEldbftK3peKUHC1hCPRnA1xtS5fWZWHHMThSEpcf6Hca361XaljwNSKIR1uWWnUBdfmELg4fg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3097 Archived-At: Subject: Re: [dispatch] SFRame Next Steps (was Re: SFrame proposed WG charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 14:34:21 -0000 SGksDQoNCkkgd2FudCB0byBtYWtlIG9uZSBoaWdoIGxldmVsIGNvbW1lbnRzIG9uIHRoZSBwcm9w b3NlZCBjaGFydGVyIGZvciBTRlJBTUUuIA0KDQpUaGUgY2hhcnRlciBhdHRlbXB0cyB0byBiZSB0 cmFuc3BvcnQgYWdub3N0aWMuIEhvd2V2ZXIsIHdlIGtub3cgdGhlcmUgYXJlDQpjZXJ0YWluIHVz ZSBjYXNlcyB0aGlzIHNvbHV0aW9uIG5lZWRzIHRvIHN1cHBvcnQuIEFuZCBJIHRoaW5rIG9uZSBv ZiB0aGUgaGFyZGVzdA0KZnJvbSBhIHNlY3VyaXR5IHBlcnNwZWN0aXZlIGlzIHRoZSBtdWx0aS1w YXJ0eSBjZW50cmFsaXNlZCBvbmUgd2l0aCBvbmUgb3IgbW9yZQ0KU0ZVcy4gQmFzZWQgb24gdGhl IHNpZ25pZmljYW50IGRpc2N1c3Npb24gd2UgaGFkIGluIFBFUkMgYXJvdW5kIHRocmVhdCBtb2Rl bCwgSQ0KdGhpbmsgdGhpcyBjaGFydGVyIGRvIG5lZWQgdG8gaGF2ZSBpbiBpdHMgZGVzY3JpcHRp b24gd29yayB0byBleHBsaWNpdGx5IGRldmVsb3ANCnRoZSB0aHJlYXQgbW9kZWwgYXMgd2VsbCBk ZXNjcmliZSB3aGljaCBhc3BlY3RzIG9mIHRoZSB0aHJlYXQgbW9kZWwgdGhhdCBvbmUgY2FuDQph ZGRyZXNzLiBGb3IgZXhhbXBsZSBJIHRoaW5rIHRoZSBzZWN1cml0eSB0aHJlYXQgb2YgbWVkaWEg ZGVsYXkgd2hpY2ggaXMgYW4NCmludGVyZXN0aW5nIHZhcmlhbnQgb2YgInJlcGxheSIgYXR0YWNr IHRoYXQgZXhpc3QgZm9yIHJlYWwtdGltZSBtZWRpYQ0KY29udmVyc2F0aW9uIHdoZXJlIHRoZXJl IGFyZSBsb2dpYyB0aGF0IHNlbGVjdHMgd2hhdCB0byBmb3J3YXJkLiANCg0KQ2hlZXJzDQoNCk1h Z251cyBXZXN0ZXJsdW5kDQoNCg0KT24gRnJpLCAyMDIwLTA3LTMxIGF0IDEzOjE1IC0wNDAwLCBS aWNoYXJkIEJhcm5lcyB3cm90ZToNCj4gVGhlIGxpbmsgRW1hZCBwb3N0ZWQgc2hvdWxkIGFsbG93 IGZvciBjb21tZW50cywgc28gcGxlYXNlIGZlZWwgZnJlZSB0byBjb21tZW50DQo+IGRpcmVjdGx5 IG9uIHRoZSBkb2MuDQo+IA0KPiBPciB5b3UgY2FuIHJlcGx5IHdpdGggY29tbWVudHMgaGVyZSBh bmQgd2UnbGwgZ2V0IHRoZW0gaW5jb3Jwb3JhdGVkLg0KPiANCj4gT24gVGh1LCBKdWwgMzAsIDIw MjAgYXQgNTo1OSBQTSBCZW4gQ2FtcGJlbGwgPGJlbkBub3N0cnVtLmNvbT4gd3JvdGU6DQo+ID4g SGkgZXZlcnlvbmUsDQo+ID4gDQo+ID4gV2UgaGFkIGEgZ29vZCBkaXNjdXNzaW9uIG9uIFNGcmFt ZSBpbiB0aGUgZGlzcGF0Y2ggbWVldGluZywgYW5kIGEgbG90IG9mDQo+ID4gaW50ZXJlc3QgaW4g cHJvZ3Jlc3NpbmcgaXQuIFRoZSBjaGFpcnMgd291bGQgbG92ZSBpdCBpZiB3ZSBjYW4gZ2V0IHNv bWUNCj4gPiBkaXNjdXNzaW9uIG9mIHRoZSBwcm9wb3NlZCBjaGFydGVyIChiZWxvdykgbm93LCB3 aGlsZSBpdOKAmXMgc3RpbGwgZnJlc2ggaW4NCj4gPiBwZW9wbGXigJlzIG1pbmRzLiBJZiB3ZSBk b27igJl0IHNlZSBmZWVkYmFjayB0byB0aGUgY29udHJhcnkgd2l0aGluIGEgY291cGxlIG9mDQo+ ID4gd2Vla3MgKGxldOKAmXMgY2FsbCB0aGF0IDE0IEF1ZyksIHdlIHdpbGwgaGFuZCBpdCBvdmVy IHRvIHRoZSBBUlQgQURzLg0KPiA+IA0KPiA+IFRoYW5rcyENCj4gPiANCj4gPiBCZW4uDQo+ID4g DQo+ID4gPiBPbiBKdWwgMjcsIDIwMjAsIGF0IDEyOjM0IFBNLCBFbWFkIE9tYXJhIDwNCj4gPiA+ IGVtYWRvbWFyYT00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KPiA+ID4gDQo+ ID4gPiBIaSBkaXNwYXRjaCwNCj4gPiA+IA0KPiA+ID4gRm9sbG93aW5nIHVwIG9uIHRoZSBkaXNj dXNzaW9uIHdlIGhhZCB0aGlzIG1vcm5pbmcgaW4gSUVURiAxMDggZGlzcGF0Y2gNCj4gPiA+IHNl c3Npb24gYWJvdXQgU0ZyYW1lLCBpdCBzZWVtcyB0aGVyZSBpcyBlbm91Z2ggaW50ZXJlc3QgdG8g Zm9ybSBhIGZvY3VzZWQNCj4gPiA+IFdHIGZvciB0aGlzIHdvcmsuIA0KPiA+ID4gDQo+ID4gPiBS aWNoYXJkIEJhcm5lcyBwcm9wb3NlZCB0aGlzIGNoYXJ0ZXIgZm9yIHRoZSBXRy4gUGxlYXNlIHRh a2UgYSBsb29rIGFuZA0KPiA+ID4gZmVlbCBmcmVlIHRvIGNvbW1lbnQgb24gdGhlIGRvYyBkaXJl Y3RseSBhbmQgcHJvcG9zZSBvdGhlciBjaGFuZ2VzIGFzDQo+ID4gPiB3ZWxsLg0KPiA+ID4gDQo+ ID4gPiBUaGFua3MNCj4gPiA+IEVtYWQNCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCj4gPiA+ IGRpc3BhdGNoQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2Rpc3BhdGNoDQo+ID4gDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPiBkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCj4gPiBkaXNwYXRj aEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlz cGF0Y2gNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IGRpc3BhdGNoIG1haWxpbmcgbGlzdA0KPiBkaXNwYXRjaEBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQotLSANCkNoZWVycw0K DQpNYWdudXMgV2VzdGVybHVuZCANCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpOZXR3b3JrcywgRXJpY3Nz b24gUmVzZWFyY2gNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkVyaWNzc29uIEFCICAgICAgICAgICAgICAgICB8 IFBob25lICArNDYgMTAgNzE0ODI4Nw0KVG9yc2hhbW5zZ2F0YW4gMjMgICAgICAgICAgIHwgTW9i aWxlICs0NiA3MyAwOTQ5MDc5DQpTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW4gfCBtYWlsdG86 IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg== From nobody Wed Aug 5 13:15:36 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B493A0F3B; Wed, 5 Aug 2020 13:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 BGRczUfIL0GE; Wed, 5 Aug 2020 13:15:29 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 1C4C63A0F33; Wed, 5 Aug 2020 13:15:29 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id k8so7579401wma.2; Wed, 05 Aug 2020 13:15:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=A8ysl9rSXkzRt/J4/FBm1XQAthQLIeQPn67EenAEKbU=; b=sh8D3o3UY5baMCtcnQZnw39hK3urbb6EiwmCjBAtbFZwLBiKcDeig+7eFWfExyJCMr ZKXqv/9TKHPIhFm21U1zTWmbzyca7NhuUckdnRcYKWkWzic7lcQSGjvCab5/T6Aqg3Yv PKRz1C+agtKC65Ym9CTu93rNki92ixqsEdEbHzb5i8YtOhuxb9/YpvjTORVCqUdfnb+R FTaUt0oP1MIZTSNpNQlpEdyrXuectvabtTgpMY1awli5UKj4WIBtJNZcWpfZ5jB6sAH0 hn8NhOPtdn/yQk0R790mC7G0s7fbaHxz5xxENQx4GgWzcAJ1whavuF5kDdkn09fP0uXX gXFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=A8ysl9rSXkzRt/J4/FBm1XQAthQLIeQPn67EenAEKbU=; b=HbwhPMOPGGDDcmtuQSHZNUhVLb8kC1cD5IuF0thB63oWW/0i8rT+4sY9J6wFiS1rQk A1vaTDYaug65AIbv+jetmb4hkvOrpE/T1+vg9yXBLcUtB83jAjFTzEehx7uJ5qbQIqsX 1rD6Jk5CG5f4/B/fxoXhvMODeHU85cLs/+Z/dpLzqtHxpAgaNXF+OtJgINqdEoPG/ODP 8jAYVH1f2Kygvx2xFXMgTd08jI3oWB3R/yVWCpz9/cT9yaPt8dJEXRk2pBOejzQ7ogvP fWAf4sU9Qjam8AuRHVOUIzceW5LBsK6z9QoIrGhW06kdQsYe5YWKtEAfBvxiHU64cmCC kZDw== X-Gm-Message-State: AOAM532hOfTj8kdKZsgaWJf9eioPxfLGfrplhQ545mL+7x3i5Wa8tNax GeVU/X7/kTmERdnPdkqL+afCbWggN4c= X-Google-Smtp-Source: ABdhPJw+BxxCtUCQ2bZVWKI/GRZeptasjKM/Q99KhUZ32dQ9mXgrjEzC3962QDjgjvki9DVXEHzaSw== X-Received: by 2002:a7b:c84f:: with SMTP id c15mr5056738wml.133.1596658527356; Wed, 05 Aug 2020 13:15:27 -0700 (PDT) Received: from [192.168.1.36] (118.red-79-151-172.dynamicip.rima-tde.net. [79.151.172.118]) by smtp.googlemail.com with ESMTPSA id b77sm3209722wmb.3.2020.08.05.13.15.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Aug 2020 13:15:26 -0700 (PDT) To: Magnus Westerlund , "ben@nostrum.com" , "rlb@ipv.sx" Cc: "emadomara=40google.com@dmarc.ietf.org" , "dispatch@ietf.org" , "sframe@ietf.org" References: From: Sergio Garcia Murillo Message-ID: <69181ed1-d72a-99de-8b4d-9e10276ced91@gmail.com> Date: Wed, 5 Aug 2020 22:15:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dispatch] SFRame Next Steps (was SFrame proposed WG charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 20:15:31 -0000 But shouldn't the "delayed media" attack still be transport agnostic? I mean, this can happen on QUIC and WebRTC SFUs. Anyway, I agree that while SFrame is transport agnostic, the chapter should not ignore the interactions with webrtc/quic and we must ensure that we provide a complete working solution regardless of the transport. If we identify that any further working items are required for a particular transport, we should at liaise with the appropriate working group for providing a solution. Best regards Sergio On 05/08/2020 16:34, Magnus Westerlund wrote: > Hi, > > I want to make one high level comments on the proposed charter for SFRAME. > > The charter attempts to be transport agnostic. However, we know there are > certain use cases this solution needs to support. And I think one of the hardest > from a security perspective is the multi-party centralised one with one or more > SFUs. Based on the significant discussion we had in PERC around threat model, I > think this charter do need to have in its description work to explicitly develop > the threat model as well describe which aspects of the threat model that one can > address. For example I think the security threat of media delay which is an > interesting variant of "replay" attack that exist for real-time media > conversation where there are logic that selects what to forward. > > Cheers > > Magnus Westerlund > > > On Fri, 2020-07-31 at 13:15 -0400, Richard Barnes wrote: >> The link Emad posted should allow for comments, so please feel free to comment >> directly on the doc. >> >> Or you can reply with comments here and we'll get them incorporated. >> >> On Thu, Jul 30, 2020 at 5:59 PM Ben Campbell wrote: >>> Hi everyone, >>> >>> We had a good discussion on SFrame in the dispatch meeting, and a lot of >>> interest in progressing it. The chairs would love it if we can get some >>> discussion of the proposed charter (below) now, while it’s still fresh in >>> people’s minds. If we don’t see feedback to the contrary within a couple of >>> weeks (let’s call that 14 Aug), we will hand it over to the ART ADs. >>> >>> Thanks! >>> >>> Ben. >>> >>>> On Jul 27, 2020, at 12:34 PM, Emad Omara < >>>> emadomara=40google.com@dmarc.ietf.org> wrote: >>>> >>>> Hi dispatch, >>>> >>>> Following up on the discussion we had this morning in IETF 108 dispatch >>>> session about SFrame, it seems there is enough interest to form a focused >>>> WG for this work. >>>> >>>> Richard Barnes proposed this charter for the WG. Please take a look and >>>> feel free to comment on the doc directly and propose other changes as >>>> well. >>>> >>>> Thanks >>>> Emad >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch From nobody Wed Aug 5 13:41:35 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56213A0F6F for ; Wed, 5 Aug 2020 13:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OH1eoI1PpDLY for ; Wed, 5 Aug 2020 13:41:32 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (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 B2DF73A0F6A for ; Wed, 5 Aug 2020 13:41:31 -0700 (PDT) Received: from oxusgaltgw05.schlund.de ([10.72.72.51]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0M4G3R-1ktbL70MpH-00rr7i; Wed, 05 Aug 2020 22:41:30 +0200 Date: Wed, 5 Aug 2020 16:41:29 -0400 (EDT) From: Timothy Mcsweeney Reply-To: Timothy Mcsweeney To: Ted Hardie Cc: DISPATCH WG Message-ID: <814993411.851567.1596660089989@email.ionos.com> In-Reply-To: References: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> <1580898449.190942.1594130597348@email.ionos.com> <3A1C3068-717D-4822-A110-9F91272B04CB@nostrum.com> <2116535970.9156.1594304410818@email.ionos.com> <1777741348.21431.1594315737558@email.ionos.com> <166222013.29010.1594323818783@email.ionos.com> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.1-Rev32 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:hutag6UjPO93D5dCFMLSYl1ROp3dkD1QueHEh9Zfqh7b+lkgRhg B3zkNM0uKuI6xiBQosryc7+V1rzWS6ee9VZoygXxKbtetM6iGhnE92hgODZC9YqdaVWM0wX qaymb50mSUC6KnH/aqIF9HlxpVICwjUP6CQBsCWw7o+EsIID9xo08EtdWVQJcEFJf41+nDl mz7QLFqLccsa8fMqYXvRw== X-UI-Out-Filterresults: notjunk:1;V03:K0:Sf0IIPOxMmo=:Tu0PjLyfefbLOxrv1dK1Z2 HBNqR+zvnMgomok8QXw28XQfEkquQ+68OAKj2VHzPfhg2wu1oUsa8qh7lbH41OEOOfwtG/ihh jEyAEar/i2Pka2+0blHOLQNDBRVXRxQYsyXM3jrgaj/8qLsneobW8cMN0N8IGML2K+W9bwbi9 0VKLkY3wf4r/O+iXYlbhclG6ysUKy4IK2OD1GpQKcVSmNsBk7VaDHybRCVmilwHuc6uUbLu16 MFmQTduv7ixF4MfxS9XamYssF/CDwFgeAVkkQmv4dSmrFoYnXJNMQ1PVM9MEzDf3I/7RowozY LmML/LQkkBkNXp+orgmvInwZFrHrPuiY/EaBT42fK1XBBIn2nkOaf+WddsBWo7QNpqxyVz7DF R5c+zerNVF4UixOxUla4y/S9YAEiPtHP8qFZgFpyzmk3yVHgqmwpTfhVqV/RoVLTC/udd8H8Z 5CVdlO/UPn9gf/EkYMLvVToMzAVmG7bjgeYVPtJGyTW33/oW63oZwWMZirIFfs4i1BOY8w/3k 4nn1b4Z6i0SZrfWoM7sQSF2JsX2izzuSU02lD8FjUa1T3Ko+dc69WR86OcRTpYzn3PXJcqjxk JhfWD9XdwQCbmfY2W4zUO2go5DMkQ9o9FLjRJHqfipw8h1HpLd8g2bCBID4yBH2HYJ9TyC1sz SYGJkTl83fs1N8nHkAMOWEba3L83RefWG6sYFyO/rgtnsRdeSOdQzX49mD3s4ktHltNq0lkFE cds35M++Bc6hkkrtS8zX29Xyez65ysgvw40+/nB3YEjiEbgvb/P4TFQxpHX33IspRXtVjFbpI 7UXzbTjcM4i6Tt0FtfV/wCZybYsiW4EJX5XnS81vBqhi7avsqa8BwaPlZWO+8BlP37YdtHD Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 20:41:34 -0000 =20 =20
Hi Ted, 

In the abstract of your most recent draft.....how about using "...from S= ections 3 & 6..."  instead of "...from the procedures..."?  I= wouldn't want anyone to confuse it with the sections that use the word pro= cedures. 

Tim



On July 9, 2020 at 4:03 PM Ted Hardie <ted.ietf@gmail.com> wrote:= =20

On Thu, Jul 9, 2020 at 12:43 PM Timothy Mcsweeney <=20 tim@dropnumber.com> wrote= :=20
You're talking about the [=20 10] reference in section=20 3.1.1 in 3405 and when I click on the ref= erence it sends me right to=20 BCP35.

>The reason for the update is that IETF tree registrations *are*= required.

That is now, scheme registration is required, including provisional= s.  See, no bug.

Tim



Quite simply, that's not what the document says.  The previous e= ffort to simply re-interpret it (see=20 https://www.rfc= -editor.org/errata/eid2842) was already rejected.=20

regards,

Ted=20






On July 9, 2020 at 3:09 PM Ted Hardie <=20 ted.ietf@gmail.com> wrote:=20

On Thu, Jul 9, 2020 at 10:28 AM Timothy Mcsweeney <=20 tim@dropnumber.com> wrote:=20
Ted, 

Section 2 (Updated Requirements) of your draft says:
"All registrations in URI.ARPA MUST be for schemes which are p= ermanent registrations, as they are described in BCP 35."

I take that as:
We must update this because permanent registrations are not re= quired.  Otherwise there is no reason for an update. 

The reason for the update is that IETF tree registrations *are* = required.  That effectively closes the registry, without the community= having made the affirmative decision to do so.  I want to fix that bu= g. =20

I currently think that the closest replacement to the IETF tree = would be permanent registration and that we should fix this by requiring th= at.  But I'm happy to see a clear draft espousing some other way of fi= xing the bug; if you have an idea about that, please write the draft.

regards,

Ted=20





If you are going to argue both sides, my draft and I will just= stay out of it.  Here is your pointer.  =20 https://www= .ietf.org/id/draft-hardie-dispatch-rfc3405-update-01.html#section-2

Tim


On July 9, 2020 at 11:57 AM Ted Hardie <=20 ted.ietf@gmail.com> wrote:=20

Howdy,=20

On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney <=20 tim@dropnumber.com> wrote:=20
Hi Ben, 

Thanks for the heads up on the deadline,

I am a little surprised that you are choosing to discuss = this at all with pending 
registrations and I obviously disagree with that.  B= ut if there are more than 5 people besides Ted that think the current rules= for provisionals in the zone

I don't think I've seen anyone but you argue that the curre= nt rules permit provisionals in the zone; if I have missed others reading t= he rules that way, I'd appreciate a pointer.

I think, though, that the key thing is to get some clarity = on what the rules should be after the elimination of the IETF tree.  S= ince you obviously disagree with my proposal, having your alternative spell= ed in a draft does seem like the best way forward.  Wherever dispatch = sends the question would then have two clear proposals to choose between.= =20

regards,

Ted Hardie=20
are
too open and need to be further constrained then I w= ill submit a draft that does
just that before the deadline. 


On July 8, 2020 at 10:36 PM Ben Campbell <=20 ben@nostrum.com> wrote:=20

Hi Tim,

Do you plan to submit an internet-draft? If so, please b= e advised that the deadline for drafts prior to IETF108 is this coming Mond= ay (7/13). If you submit a draft prior to the deadline, we can consider it = along with Ted=E2=80=99s draft (either on the list or possibly in the IETF1= 08 DISPATCH meeting).

Thanks,

Ben.=20

On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney <=20 tim@dropnumber.com> wrote:

Hi All,

Updating RFC3405 will necessarily require changes = to RFC3401 as stated in its 
introduction.  "This document will be updated= and or obsoleted when changes
are made to the DDDS specifications."

We are now changing two RFCs so I don't think this= fits as a
"simple administrative".

But, I may have a work around that is simple and a= lso solves the provisional registration problem as stated by Ted.  I c= ould have ready in a day or so.

Tim
On July 7, 2020 at 3:34 AM "Martin J. D=C3=BCrst" = <=20 duerst@it.aoyama.ac.jp> wrote:


On 23/06/2020 07:51, Ben Campbell wrote:
Hi Everyone,

The ART ADs have reminded the chairs that our cha= rter allows us to adopt =E2=80=9Csimple administrative=E2=80=9D work such a= s IANA registration documents. This draft seems to fit squarely in that cat= egory. Does anyone see a reason we shouldn=E2=80=99t just adopt it, with th= e expectation of going immediately to WGLC? (The last-call timeline is the = same either way, either 2 weeks WGLC and 2 weeks IETF LC for a working grou= p draft, or 4 weeks IETF LC for an AD sponsored draft.)

Triggered by the recent discussion, I had a look a= t Ted's draft and the
mail up to today. To me, both AD sponsored and Dis= patch WG look
reasonable, with a slight preference for the forme= r (if asked to express
such a preference).

With respect to "pending registrations", I do not = think these are
relevant, in particular because the thing in quest= ion isn't actually a
scheme, as discussed on the relevant list.

I have one comment: The abstract currently reads
"This document removes references to the IETF tree= of URI registrations
for registrations in URI.ARPA.". I found this hard= to read, and I guess
it's because of the "registrations for registratio= ns" piece. Unless one
is very familiar with the matter at hand, it's eas= y to think that both
occurrences of "registration" are referencing the = same thing. While I'm
at it, it would also be good if the abstract menti= oned something
positive. I think a less normative version of (the= single sentence that
is) Section 2 would serve well as the abstract.

Regards, Martin.

Thanks!

Ben (as co-chair)

On Jun 3, 2020, at 6:13 PM, Ted Hardie <=20 ted.ietf@gmail..com> wrote:

Howdy,

This is one the shortest drafts I've ever writte= n:=20 https= ://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ <= =20 http= s://datatracker.ietf...org/doc/draft-hardie-dispatch-rfc3405-update/>= ; .. Basically, RFC 3405 used to require that registrations in URI.ARPA be = from the "IETF Tree". That tree was deprecated after the document was publi= shed.. As it happens, there are very few registrations in URI.ARPA, so we d= id not catch it and fix it before now.

This draft updates RFC 3405 to require "permanen= t" scheme registrations. The salient bit is this:

All registrations in URI.ARPA MUST be for scheme= s which are permanent
registrations, as they are described in BCP 35.

I'm hoping for a quick dispatch of this, but hap= py to discuss.

regards,

Ted Hardie
_______________________________________________
dispatch mailing list



_______________________________________________
dispatch mailing list


--
Prof. Dr.sc. Martin J. D=C3=BCrst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan

_______________________________________________
dispatch mailing list
_______________________________________________= =20
dispatch mailing list=20
dispatch@ietf.org=20
https://www.ietf.org/mailman/listi= nfo/dispatch=20


 
_______________________________________________=20
dispatch mailing list=20
dispatch@ietf.org=20
https://www.ietf.org/mailman/listinfo/di= spatch=20

 

 

 
=20 From nobody Wed Aug 5 13:51:02 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE693A0F82 for ; Wed, 5 Aug 2020 13:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 972cDvSpv6RY for ; Wed, 5 Aug 2020 13:50:58 -0700 (PDT) Received: from mail-oo1-xc2b.google.com (mail-oo1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) (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 5BD6C3A0F80 for ; Wed, 5 Aug 2020 13:50:58 -0700 (PDT) Received: by mail-oo1-xc2b.google.com with SMTP id y30so1343565ooj.3 for ; Wed, 05 Aug 2020 13:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ftZCV+blWsUu0qggYOHDtQgTA5pifeaaIIK+52Qdb5Y=; b=i2V1fTLn5gTz32T9fHe8ZnOxQn7u0ntNAshZiGGPtvHoqXv5MvZdmlQjrXW/AiWYCG slnbueB99QzC0SYISYf1sNAeCyD6r+B8TX4fBIOzMRmIPqxAwQEhFCglv9iC3rxDxk1j dycuankZFdyESDhhVevjTJhaZKGnTkj1OjDiBQSGD+qOucLNbRuZvvSanDJTg/ixhMhh Kp3cR8i5hZVnBNQMLUFfNyUyQ5h0BnhKVnFkamXukEBrZSBJwWYwwAZ+EQrcc9SChLf7 DdCpzn4xGyr0aTXO1xyJyc2cIX6IY46hTGMOxNB64LOPXLyhy0GRSSE2YqaQnGtPFI/c FVyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ftZCV+blWsUu0qggYOHDtQgTA5pifeaaIIK+52Qdb5Y=; b=bySH+mV1KGRvr8D3VXOTiDgo+dzW8tRHv3/ZxKb72Hk79ivg5D/sdHaFYHstrL9gIq 2KNkP4w42/wzTvjOOlgyMoPtItUTOQgsI1xn+0E5GMZtV7TVVV4JbUWL8d6iV75gHiIS CgrFym2IeZiETczTs37Ln4PvB0NeJ4y+Hfvf7TXfkgQWuA2zdzKUGUNY0nQt2Ugu8klA OgDlcQjePrzaQxsj6l3LzT5NWflqEASdjeG5pgLTF3YdhBpCnr4rH50DGOXqALhSqKfd tJAWzjKay3PQ8iLNBT++6SHC9A/BntmAZOayQzuEpHm6bDQOV2tGQrFxeumPquuRQOmG c7Mw== X-Gm-Message-State: AOAM5329t6YUTnajVY6KsB+SpcZZk9oKea+yDG0BAML68BZCpdlGAJOw ZcMXE64Oap0764QZiiaEwfJAWDIRXJ+9hl8jMXpjIoHH X-Google-Smtp-Source: ABdhPJxBXvFfW9KtkxEZlGB1A6uBZOugcGbTvZMfit531JQtxLA2N0rPomRWQ3QPJXtwZeFtrg+OlR9VLH8iMOf9PVE= X-Received: by 2002:a4a:a60a:: with SMTP id e10mr4625857oom.25.1596660657582; Wed, 05 Aug 2020 13:50:57 -0700 (PDT) MIME-Version: 1.0 References: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> <1580898449.190942.1594130597348@email.ionos.com> <3A1C3068-717D-4822-A110-9F91272B04CB@nostrum.com> <2116535970.9156.1594304410818@email.ionos.com> <1777741348.21431.1594315737558@email.ionos.com> <166222013.29010.1594323818783@email.ionos.com> <814993411.851567.1596660089989@email.ionos.com> In-Reply-To: <814993411.851567.1596660089989@email.ionos.com> From: Ted Hardie Date: Wed, 5 Aug 2020 13:50:30 -0700 Message-ID: To: Timothy Mcsweeney Cc: DISPATCH WG Content-Type: multipart/alternative; boundary="00000000000052755605ac2787b5" Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 20:51:01 -0000 --00000000000052755605ac2787b5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 5, 2020 at 1:41 PM Timothy Mcsweeney wrote= : > Hi Ted, > > In the abstract of your most recent draft.....how about using "...from > Sections 3 & 6..." instead of "...from the procedures..."? I wouldn't > want anyone to confuse it with the sections that use the word procedures. > > Thanks for the comment. The previous version used "registration" twice in quick succession, which Martin D=C3=BCrst found hard to follow, and the swi= tch to "procedures" was to accommodate that. I'll think about how to reword again and fold any resulting change into an update after Last Call (assuming that the consensus of the list is still AD sponsorship, there will be a four-week last call). regards, Ted Hardie > Tim > > > > On July 9, 2020 at 4:03 PM Ted Hardie wrote: > > On Thu, Jul 9, 2020 at 12:43 PM Timothy Mcsweeney < tim@dropnumber.com> > wrote: > > You're talking about the [ 10 ] > reference in section 3.1.1 in 3405 > and when I click on > the reference it sends me right to BCP35 > . > > >The reason for the update is that IETF tree registrations *are* required= . > > That is now, scheme registration is required, including provisionals. > See, no bug. > > Tim > > > > Quite simply, that's not what the document says. The previous effort to > simply re-interpret it (see https://www.rfc-editor.org/errata/eid2842) > was already rejected. > > regards, > > Ted > > > > > > > On July 9, 2020 at 3:09 PM Ted Hardie < ted.ietf@gmail.com> wrote: > > On Thu, Jul 9, 2020 at 10:28 AM Timothy Mcsweeney < tim@dropnumber.com> > wrote: > > Ted, > > Section 2 (Updated Requirements) of your draft says: > "All registrations in URI.ARPA MUST be for schemes which are permanent > registrations, as they are described in BCP 35." > > I take that as: > We must update this because permanent registrations are not required. > Otherwise there is no reason for an update. > > > The reason for the update is that IETF tree registrations *are* required. > That effectively closes the registry, without the community having made t= he > affirmative decision to do so. I want to fix that bug. > > I currently think that the closest replacement to the IETF tree would be > permanent registration and that we should fix this by requiring that. Bu= t > I'm happy to see a clear draft espousing some other way of fixing the bug= ; > if you have an idea about that, please write the draft. > > regards, > > Ted > > > > > > If you are going to argue both sides, my draft and I will just stay out o= f > it. Here is your pointer. > https://www.ietf.org/id/draft-hardie-dispatch-rfc3405-update-01.html#sect= ion-2 > > Tim > > > On July 9, 2020 at 11:57 AM Ted Hardie < ted.ietf@gmail.com> wrote: > > Howdy, > > On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney < tim@dropnumber.com> > wrote: > > Hi Ben, > > Thanks for the heads up on the deadline, > > I am a little surprised that you are choosing to discuss this at all with > pending > registrations and I obviously disagree with that. But if there are more > than 5 people besides Ted that think the current rules for provisionals i= n > the zone > > > I don't think I've seen anyone but you argue that the current rules permi= t > provisionals in the zone; if I have missed others reading the rules that > way, I'd appreciate a pointer. > > I think, though, that the key thing is to get some clarity on what the > rules should be after the elimination of the IETF tree. Since you > obviously disagree with my proposal, having your alternative spelled in a > draft does seem like the best way forward. Wherever dispatch sends the > question would then have two clear proposals to choose between. > > regards, > > Ted Hardie > > are > too open and need to be further constrained then I will submit a draft > that does > just that before the deadline. > > > On July 8, 2020 at 10:36 PM Ben Campbell < ben@nostrum.com> wrote: > > Hi Tim, > > Do you plan to submit an internet-draft? If so, please be advised that th= e > deadline for drafts prior to IETF108 is this coming Monday (7/13). If you > submit a draft prior to the deadline, we can consider it along with Ted= =E2=80=99s > draft (either on the list or possibly in the IETF108 DISPATCH meeting). > > Thanks, > > Ben. > > On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney < tim@dropnumber.com> > wrote: > > Hi All, > > Updating RFC3405 will necessarily require changes to RFC3401 as stated in > its > introduction. "This document will be updated and or obsoleted when > changes > are made to the DDDS specifications." > > We are now changing two RFCs so I don't think this fits as a > "simple administrative". > > But, I may have a work around that is simple and also solves the > provisional registration problem as stated by Ted. I could have ready in= a > day or so. > > Tim > > On July 7, 2020 at 3:34 AM "Martin J. D=C3=BCrst" < duerst@it.aoyama.ac.j= p> > wrote: > > > On 23/06/2020 07:51, Ben Campbell wrote: > > Hi Everyone, > > The ART ADs have reminded the chairs that our charter allows us to adopt > =E2=80=9Csimple administrative=E2=80=9D work such as IANA registration do= cuments. This > draft seems to fit squarely in that category. Does anyone see a reason we > shouldn=E2=80=99t just adopt it, with the expectation of going immediatel= y to WGLC? > (The last-call timeline is the same either way, either 2 weeks WGLC and 2 > weeks IETF LC for a working group draft, or 4 weeks IETF LC for an AD > sponsored draft.) > > > Triggered by the recent discussion, I had a look at Ted's draft and the > mail up to today. To me, both AD sponsored and Dispatch WG look > reasonable, with a slight preference for the former (if asked to express > such a preference). > > With respect to "pending registrations", I do not think these are > relevant, in particular because the thing in question isn't actually a > scheme, as discussed on the relevant list. > > I have one comment: The abstract currently reads > "This document removes references to the IETF tree of URI registrations > for registrations in URI.ARPA.". I found this hard to read, and I guess > it's because of the "registrations for registrations" piece. Unless one > is very familiar with the matter at hand, it's easy to think that both > occurrences of "registration" are referencing the same thing. While I'm > at it, it would also be good if the abstract mentioned something > positive. I think a less normative version of (the single sentence that > is) Section 2 would serve well as the abstract. > > Regards, Martin. > > Thanks! > > Ben (as co-chair) > > On Jun 3, 2020, at 6:13 PM, Ted Hardie < ted.ietf@gmail..com > > wrote: > > Howdy, > > This is one the shortest drafts I've ever written: > https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ < > https://datatracker.ietf...org/doc/draft-hardie-dispatch-rfc3405-update/ > = > > .. Basically, RFC 3405 used to require that registrations in URI.ARPA be > from the "IETF Tree". That tree was deprecated after the document was > published.. As it happens, there are very few registrations in URI.ARPA, = so > we did not catch it and fix it before now. > > This draft updates RFC 3405 to require "permanent" scheme registrations. > The salient bit is this: > > All registrations in URI.ARPA MUST be for schemes which are permanent > registrations, as they are described in BCP 35. > > I'm hoping for a quick dispatch of this, but happy to discuss. > > regards, > > Ted Hardie > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > -- > Prof. Dr.sc. Martin J. D=C3=BCrst > Department of Intelligent Information Technology > College of Science and Engineering > Aoyama Gakuin University > Fuchinobe 5-1-10, Chuo-ku, Sagamihara > 252-5258 Japan > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > > > > > --00000000000052755605ac2787b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Aug 5, 2020 at 1:41 PM Timothy Mc= sweeney <tim@dro= pnumber.com> wrote:
=20 =20 =20
Hi Ted,=C2=A0

In the abstract of your most recent draft.....how about using "...f= rom Sections 3 & 6..."=C2=A0 instead of "...from the procedur= es..."?=C2=A0 I wouldn't want anyone to confuse it with the sectio= ns that use the word procedures.=C2=A0


=
Thanks for the comment.=C2=A0 The previous versi= on used "registration" twice in quick succession, which Martin D= =C3=BCrst found hard to follow, and the switch to "procedures" wa= s to accommodate that. I'll think about how to reword again and fold an= y resulting change into an update after Last Call (assuming that the consen= sus of the list is still AD sponsorship, there will be a four-week last cal= l).

regards,

Ted Hardie
=C2=A0
Tim



On July 9, 2020 at 4:03 PM Ted Hardie <ted.ietf@gmail.com> wrote:=20

On Thu, Jul 9, 2020 at 12:43 PM Timothy Mcsweeney <=20 tim@dropnumber= .com> wrote:=20
You're talking about the [=20 10] reference in section=20 3.1.1 in 3405 and when I click on the r= eference it sends me right to=20 BCP35.

>The reason for the update is that IETF tree registrations *are*= required.

That is now, scheme registration is required, including provisional= s.=C2=A0 See, no bug.

Tim



Quite simply, that's not what the document says.=C2=A0 The previo= us effort to simply re-interpret it (see=20 https://www.rfc-editor.org/errata/eid2842) was already rejected.=20

regards,

Ted=20






On July 9, 2020 at 3:09 PM Ted Hardie <=20 ted.ietf@gmail.com> wrote:=20

On Thu, Jul 9, 2020 at 10:28 AM Timothy Mcsweeney <=20 tim@dropnumber.com> wrote:=20
Ted,=C2=A0

Section 2 (Updated Requirements) of your draft says:
"All registrations in URI.ARPA MUST be for schemes which = are permanent registrations, as they are described in BCP 35."

I take that as:
We must update this because permanent registrations are not re= quired.=C2=A0 Otherwise there is no reason for an update.=C2=A0

The reason for the update is that IETF tree registrations *are* = required.=C2=A0 That effectively closes the registry, without the community= having made the affirmative decision to do so.=C2=A0 I want to fix that bu= g.=C2=A0=20

I currently think that the closest replacement to the IETF tree = would be permanent registration and that we should fix this by requiring th= at.=C2=A0 But I'm happy to see a clear draft espousing some other way o= f fixing the bug; if you have an idea about that, please write the draft.

regards,

Ted=20





If you are going to argue both sides, my draft and I will just= stay out of it.=C2=A0 Here is your pointer.=C2=A0=C2=A0=20 https://www= .ietf.org/id/draft-hardie-dispatch-rfc3405-update-01.html#section-2

Tim


On July 9, 2020 at 11:57 AM Ted Hardie <=20 ted.ietf@gmail.com> wrote:=20

Howdy,=20

On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney <=20 tim@dropnumber.com> wrote:=20
Hi Ben,=C2=A0

Thanks for the heads up on the deadline,

I am a little surprised that you are choosing to discuss = this at all with pending=C2=A0
registrations and I obviously disagree with that.=C2=A0 B= ut if there are more than 5 people besides Ted that think the current rules= for provisionals in the zone

I don't think I've seen anyone but you argue that t= he current rules permit provisionals in the zone; if I have missed others r= eading the rules that way, I'd appreciate a pointer.

I think, though, that the key thing is to get some clarity = on what the rules should be after the elimination of the IETF tree.=C2=A0 S= ince you obviously disagree with my proposal, having your alternative spell= ed in a draft does seem like the best way forward.=C2=A0 Wherever dispatch = sends the question would then have two clear proposals to choose between.= =20

regards,

Ted Hardie=20
are
too open and need to be further constrained=C2=A0then I w= ill submit a draft that does
just that before the deadline.=C2=A0


On July 8, 2020 at 10:36 PM Ben Campbell <=20 ben@nostrum.com> wrote:=20

Hi Tim,

Do you plan to submit an internet-draft? If so, please b= e advised that the deadline for drafts prior to IETF108 is this coming Mond= ay (7/13). If you submit a draft prior to the deadline, we can consider it = along with Ted=E2=80=99s draft (either on the list or possibly in the IETF1= 08 DISPATCH meeting).

Thanks,

Ben.=20

On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney <=20 tim@dropnumber.com> wrote:

Hi All,

Updating RFC3405 will necessarily require changes = to RFC3401 as stated in its=C2=A0
introduction.=C2=A0 "This document will be up= dated and or obsoleted when changes
are made to the DDDS specifications."

We are now changing two RFCs so I don't think = this fits as a
"simple administrative".

But, I may have a work around that is simple and a= lso solves the provisional registration problem as stated by Ted.=C2=A0 I c= ould have ready in a day or so.

Tim
On July 7, 2020 at 3:34 AM "Martin J. D=C3=BC= rst" <=20 duerst@it.aoyama.ac.jp> wrote:


On 23/06/2020 07:51, Ben Campbell wrote:
Hi Everyone,

The ART ADs have reminded the chairs that our cha= rter allows us to adopt =E2=80=9Csimple administrative=E2=80=9D work such a= s IANA registration documents. This draft seems to fit squarely in that cat= egory. Does anyone see a reason we shouldn=E2=80=99t just adopt it, with th= e expectation of going immediately to WGLC? (The last-call timeline is the = same either way, either 2 weeks WGLC and 2 weeks IETF LC for a working grou= p draft, or 4 weeks IETF LC for an AD sponsored draft.)

Triggered by the recent discussion, I had a look a= t Ted's draft and the
mail up to today. To me, both AD sponsored and Dis= patch WG look
reasonable, with a slight preference for the forme= r (if asked to express
such a preference).

With respect to "pending registrations",= I do not think these are
relevant, in particular because the thing in quest= ion isn't actually a
scheme, as discussed on the relevant list.

I have one comment: The abstract currently reads
"This document removes references to the IETF= tree of URI registrations
for registrations in URI.ARPA.". I found this= hard to read, and I guess
it's because of the "registrations for re= gistrations" piece. Unless one
is very familiar with the matter at hand, it's= easy to think that both
occurrences of "registration" are refere= ncing the same thing. While I'm
at it, it would also be good if the abstract menti= oned something
positive. I think a less normative version of (the= single sentence that
is) Section 2 would serve well as the abstract.

Regards, Martin.

Thanks!

Ben (as co-chair)

On Jun 3, 2020, at 6:13 PM, Ted Hardie <=20 ted.ietf@gmail..com> wrote:

Howdy,

This is one the shortest drafts I've ever wr= itten:=20 https= ://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ <= =20 http= s://datatracker.ietf...org/doc/draft-hardie-dispatch-rfc3405-update/>= ; .. Basically, RFC 3405 used to require that registrations in URI.ARPA be = from the "IETF Tree". That tree was deprecated after the document= was published.. As it happens, there are very few registrations in URI.ARP= A, so we did not catch it and fix it before now.

This draft updates RFC 3405 to require "per= manent" scheme registrations. The salient bit is this:

All registrations in URI.ARPA MUST be for scheme= s which are permanent
registrations, as they are described in BCP 35.

I'm hoping for a quick dispatch of this, but= happy to discuss.

regards,

Ted Hardie
_______________________________________________
dispatch mailing list



_______________________________________________
dispatch mailing list


--
Prof. Dr.sc. Martin J. D=C3=BCrst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan

_______________________________________________
dispatch mailing list
_______________________________________________= =20
dispatch mailing list=20
dispatch@ietf.org=20
https://www.ietf.org/mailman/listi= nfo/dispatch=20


=C2=A0
_______________________________________________=20
dispatch mailing list=20
dispatch@ietf.org=20
https://www.ietf.org/mailman/listinfo/di= spatch=20

=C2=A0

=C2=A0

=C2=A0
=20
--00000000000052755605ac2787b5-- From nobody Thu Aug 6 01:56:23 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4B83A1023; Thu, 6 Aug 2020 01:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWXSfCgTIRjy; Thu, 6 Aug 2020 01:56:21 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50081.outbound.protection.outlook.com [40.107.5.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6593A3A100E; Thu, 6 Aug 2020 01:56:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FqPjg/0qOOqMFXn9vN4FWvn+4z5BbQvzJZZIE0iMOImyOxuumFfEvWXt4MPcDiB3Go9sYwfBRWcxVSrggt1luITBN68YjfDwe8C/Rgxm8h8CePCNLB1daYCAVG7sWddB03BC84b3BJW/4vvOFYjqQ2DHRxlUgpbCIRmx4xzjrBSFrS6KtbmecC3pBe2Jvzl0arpeMb4kxRlxvfkwVGaiH8HMiZ62lWMHjHmPVE9qSobbvr3qhY/Cee/XN31x4cruFqABk7v1uCOkSNrarJPJ8PHrL0mTodHeJ8kxi64S3kSOFao8f/1cmY7e1Mq8MaqQI86sRcvXw+ZsIIvmUnr0DQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GDtl7CvHPnlatE0xz7l+7Sa2+7uglgohhOPkiz/GJfI=; b=hTh1LtUF0sr1uLozdeFCIe3LFPOYond4SaX76yD1GsB1u9Mj4MuPWMrt+MtvFLqV/6EHUIdBsJ2KqY0WSX7bdtcgByCiE3ErDdD/80J3AVQLPUOA2MKjE7LNn0USS3yuYjREZNDtp5kk1bw+EaUf+LEZa0j7VYgp1rL0wlRx9Q6zdAupaJGHowcpKTWc4ZvB/+fYUVx4lAVuvB9j0FjJQ8QfFI7UYSFBtyxmadc6vMKGskz0auAusFpeWpTe549uc8Xvim+yjPSv8LRRWqPxWG+YG3ykV1G+5lkNtZ7EpQUr1dgSthbh02C5DtrzQjseUxnz4xXVYHOH4WWygnU6Yw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=GDtl7CvHPnlatE0xz7l+7Sa2+7uglgohhOPkiz/GJfI=; b=MHps0eehZEPk4VeErNZjEao063LsmWgrp8JF8g9jcT/PCr4MbQyGBKli9mtFglp8pjhmgNg3GHt9DmqPnVB4xJU4bXIBlW7ANrt12dtutxgkBwSL0F7tHcNwQ+jWIXfofWiEY7SM8XLwB2qfb1S12CmlzELLOYZG4kqPlqmyY0Y= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR07MB3098.eurprd07.prod.outlook.com (2603:10a6:7:38::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.14; Thu, 6 Aug 2020 08:56:17 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::d95a:be8:b97b:582d]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::d95a:be8:b97b:582d%5]) with mapi id 15.20.3261.016; Thu, 6 Aug 2020 08:56:17 +0000 From: Magnus Westerlund To: "ben@nostrum.com" , "rlb@ipv.sx" , "sergio.garcia.murillo@gmail.com" CC: "dispatch@ietf.org" , "sframe@ietf.org" , "emadomara@google.com" Thread-Topic: [dispatch] SFRame Next Steps (was SFrame proposed WG charter) Thread-Index: AQHWa2UvSRWiVT7MukOqMgZDT9IOv6kqyBeA Date: Thu, 6 Aug 2020 08:56:16 +0000 Message-ID: <771e108a9f25c1bec04d5fcdad58eb55bbb1533d.camel@ericsson.com> References: <69181ed1-d72a-99de-8b4d-9e10276ced91@gmail.com> In-Reply-To: <69181ed1-d72a-99de-8b4d-9e10276ced91@gmail.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2 authentication-results: nostrum.com; dkim=none (message not signed) header.d=none;nostrum.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [98.128.243.14] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 66917b51-16bc-4812-d73b-08d839e69495 x-ms-traffictypediagnostic: HE1PR07MB3098: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tYJ12woz666PCayrUtgEvmMEzfBbhX5ZkqXZKGeLiW8SX2q4IFpiZl+S2CGjW47uACIVqCMRZKAA22JXTon3WEBmqRQXAk3V7QoEconHrC+ucrh3cr4mpKoSDwuv3gdOlTM6DR1TeGxPjAljbvP3+0OkY2AH3sxZQacLivsDahqMxdIFHK35JloxLV7q2+zOefFMtWML/atID/bOPW8faRBRZcm3eU50O8KoR3lpRYrPX/1JGI1Gi1G+W6pk/mxlaKaMRafZNy7lbUuHaKvbCI35Mu7wVT1KhY/ZQvEV8a0YwF3zMLh93T79AWMyzzpkhsA/vt/zL8/2TqdfgJvFBpXbShhxnaZWw61taA32wG24JoS9MwM9J41hXk9biSxY x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(396003)(136003)(376002)(39860400002)(366004)(2906002)(71200400001)(8676002)(6512007)(5660300002)(36756003)(26005)(66446008)(8936002)(66476007)(66556008)(64756008)(186003)(76116006)(66946007)(2616005)(54906003)(6506007)(478600001)(83380400001)(6486002)(44832011)(86362001)(110136005)(316002)(4326008)(99106002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: NDeoNyXkAvYIAWVhVrmjmAZEluGUZ3vm3J/IxCtdPyKkxKnl8BBNY1QokHTwLef5rpKUy+9BC14JQPqWnh5KTur7xNTNAEGbOL8qyGcUfcBrFCcTa978tuitc/lhFvGAoGTaSGGfQpJXVzm9VCXoCMk4DnaPCOciEIz7mSxvjZ6F3uBI+aoF57W0z+7rwHT/f17c1AmUl4PvxUCUEQ46YZaqTPJKQY7S9+uDGMWTMz5ACOxzjkLYdMc+b2xsLsA70JEvXQ1d7xrAlLd8kyuERWof75ysY/yBOvks7RnisKNIoBTUlxb8lG0GyPxD8QfiYfUp20Xyoaph4YEhFVLVsxgUuRup/Dm5XsuTWHr0/iaExasU9z3kGI0rfgRBOyBarAHMCjwr81Y1+9aB5A592lNRv869cwmoissWJpRPwHoT4u3f+BJdxI5P9cp8oqVNCm66Cyj4cdltIq2VCHzUoSnuo+4Z6r7gaCTjEdPmBJHPqByd01uiDjRWWrj/QzQRjx6iSpt23NmLu6ujuJQeQNQKyIfrJzEy10p5bKoqcPS1d89C7CXLONhLV33NO8pNTScvvdzv0mo5cA1nSfHKy6BP8bX5JXSGdujtGGez5XEizlDcLzyQmnxFTsEFSjy6ffYH9en9Ts6LBdWqP+98jw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 66917b51-16bc-4812-d73b-08d839e69495 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2020 08:56:16.9645 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: R2CrkpUDhINf+RtFCLXoPNDuzvUihloAe/wLtg4AU+r+g5P6BKtiDA+tq2Xb2T3J6EOItwaRZxgpXEUWWCSmtQtMiZgOsYlDkeFIWsM4Am8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3098 Archived-At: Subject: Re: [dispatch] SFRame Next Steps (was SFrame proposed WG charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2020 08:56:22 -0000 SGksDQoNCk9uIFdlZCwgMjAyMC0wOC0wNSBhdCAyMjoxNSArMDIwMCwgU2VyZ2lvIEdhcmNpYSBN dXJpbGxvIHdyb3RlOg0KPiBCdXQgc2hvdWxkbid0IHRoZSAiZGVsYXllZCBtZWRpYSIgYXR0YWNr IHN0aWxsIGJlIHRyYW5zcG9ydCBhZ25vc3RpYz8gSSANCj4gbWVhbiwgdGhpcyBjYW4gaGFwcGVu IG9uIFFVSUMgYW5kIFdlYlJUQyBTRlVzLg0KDQpTb3JyeSBpZiBJIGdhdmUgdGhlIGltcHJlc3Np b24gdGhhdCBpdCBpcyBub3QgdHJhbnNwb3J0IGFnbm9zdGljLiBJdCBpcyB1c2UgY2FzZQ0KZGVw ZW5kZW50LCBhbnkgdXNlIGNhc2UgdGhhdCBpc24ndCBwb2ludCB0byBwb2ludCwgd2hlcmUgdGhl cmUgaXMgbW9yZSB0aGFuIG9uZQ0KZW50aXR5IHRoYXQgY2FuIGludGVudGlvbmFsbHkgcmVtb3Zl IFNGUkFNRSBjcmVhdGluZyBnYXBzIGluIHRoZSBTRlJBTUUNCnNlcXVlbmNlLiBJbiBhIHBvaW50 IHRvIHBvaW50IHNjZW5hcmlvIG9uZSBjYW4gY29ycmVsYXRlIHRyYW5zcG9ydCBsb3NzZXMgd2l0 aA0KU0ZSQU1FIGdhcHMgdG8ga25vdyBnaXZlIGEgcmVhc29uYWJseSBzdHJvbmcgbWl0aWdhdGlv biBhZ2FpbnN0IGFueSB0aGlyZCBwYXJ0eQ0KcmVtb3ZpbmcgU0ZSQU1FcyBvciBkZWxheWluZyB0 aGVtLiBUaGF0IGlzIG11Y2ggaGFyZGVyIGluIGEgY2VudHJhbGl6ZWQNCmNvbmZlcmVuY2Ugd2l0 aCBvbmUgb3IgbW9yZSBTRlUuDQoNCj4gDQo+IEFueXdheSwgSSBhZ3JlZSB0aGF0IHdoaWxlIFNG cmFtZSBpcyB0cmFuc3BvcnQgYWdub3N0aWMsIHRoZSBjaGFwdGVyIA0KPiBzaG91bGQgbm90IGln bm9yZSB0aGUgaW50ZXJhY3Rpb25zIHdpdGggd2VicnRjL3F1aWMgYW5kIHdlIG11c3QgZW5zdXJl IA0KPiB0aGF0IHdlIHByb3ZpZGUgYSBjb21wbGV0ZSB3b3JraW5nIHNvbHV0aW9uIHJlZ2FyZGxl c3Mgb2YgdGhlIHRyYW5zcG9ydC4gDQo+IElmIHdlIGlkZW50aWZ5IHRoYXQgYW55IGZ1cnRoZXIg d29ya2luZyBpdGVtcyBhcmUgcmVxdWlyZWQgZm9yIGEgDQo+IHBhcnRpY3VsYXIgdHJhbnNwb3J0 LCB3ZSBzaG91bGQgYXQgbGlhaXNlIHdpdGggdGhlIGFwcHJvcHJpYXRlIHdvcmtpbmcgDQo+IGdy b3VwIGZvciBwcm92aWRpbmcgYSBzb2x1dGlvbi4NCg0KTXkgbWFpbiBwb2ludCBpcyB0aGF0IFNG UkFNRSBhY3R1YWxseSBuZWVkcyB0byBkaXNjdXNzIHRoZSB0aHJlYXQgbW9kZWwgZm9yIHRoZQ0K dXNlIGNhc2VzIGl0IGludGVuZGVzIHRvIHNvbHZlLiBBbmQgdGhlIG1pdGlnYXRpb24gY2FuIHBv dGVudGlhbGx5IGluY2x1ZGUNCmZ1bmN0aW9uYWxpdHkgb24gdGhlIHRyYW5zcG9ydCBsZXZlbC4g QnV0IHRoZSByaXNrcyB0byBtZWRpYSBzZWN1cml0eSBpbg0KY2VudHJhbGl6ZWQgY29uZmVyZW5j aW5nIG5lZWRzIHRvIGJlIGRpc2N1c3NlZC4gQW5kIGNlbnRyYWxpemVkIGNvbmZlcmVuY2luZw0K d2lsbCBzdGlsbCBoYXZlIHRoZSBzZW1pLXRydXN0ZWQgU0ZVcyBhbmQgYWxsIHRoZSByZXN0IG9m IHRoZSB0aGlyZCBwYXJ0aWVzIGluDQphZGRpdGlvbiB0byB0aGUgZW5kLXBvaW50cy4gDQoNCkFs c28gd2hhdCBwcm9wZXJ0aWVzIG9uZSBoYXZlIGFyb3VuZCBlbmQtcG9pbnRzIGludml0ZWQgaW50 byB0aGUgY29uZmVyZW5jZSBoYXMNCmEgbnVtYmVyIG9mIHF1ZXN0aW9uIGFyb3VuZCBzZWN1cml0 eSBwcm9wZXJ0aWVzIHRoYXQgbmVlZHMgdG8gYmUgZGlzY3Vzc2VkIGFuZA0KZG9jdW1lbnRlZC4g U29tZSBleGFtcGxlcyB0aGF0IEkga25vdyBhcmUgcmVsZXZhbnQ6DQoNCi0gU291cmNlIGF1dGhl bnRpY2F0aW9uOiBTUlRQIHVubGVzcyBvbmUgdXNlIFRFU0xBICh3aGljaCBpc24ndCByZWFsbHkg dXNlZCkNCmRvZXMgb25seSBwcm92aWRlZCB0aGUgcHJvcGVydHk6IFNvbWVvbmUgdGhhdCBoYXMg dGhlIGtleSBzZW50IHRoaXMuIE9uZSBkb24ndA0Ka25vdyB0aGF0IGl0IGNvbWVzIGZyb20gYSBw YXJ0aWN1bGFyIGVuZHBvaW50LiANCg0KLSBDb25maWRlbnRpYWxpdHkgd2hlbiBncm91cCBtZW1i ZXJzaGlwIGNoYW5nZXM6IFNvIHdpbGwgU0ZSQU1FIGtleWluZyBzdXBwb3J0IGENCnVzZSBjYXNl IHdoZXJlIG9ubHkgdGhlIGN1cnJlbnQgc2V0IG9mIG1lbWJlcnMgaW4gYSBjb25mZXJlbmNlIGNh biBkZWNyeXB0IHRoZQ0KbWVkaWEgYW5kIG9uZSByZWtleSB0aGUgbWVkaWEgc2Vzc2lvbiBrZXkg Zm9yIGVhY2ggdGltZSB0aGUgbWVtYmVyc2hpcCBjaGFuZ2VzPw0KUEVSQyBkbyBzdXBwb3J0IHRo aXMsIHdpbGwgU0ZSQU1FPyANCg0KVGhlcmUgYXJlIGxpa2VseSBtb3JlIHF1ZXN0aW9ucyB0aGF0 IG5lZWRzIGRpc2N1c3Npb24uIFRoZSBQRVJDIGRpc2N1c3Npb24gaXMgYQ0KZ29vZCBzdGFydGlu ZyBwb2ludCwgYnV0IEkgdGhpbmsgd2hlbiBnb2luZyB0cmFuc3BvcnQgYWdub3N0aWMgc29tZSBv ZiB0aGUNCmlzc3VlcyBuZWVkcyB0byBiZSBtb3JlIGNsZWFybHkgZGlzY3Vzc2VkIGFzIHRoZSBS VFAgdHJhbnNwb3J0IGNhbiBoYXZlIGFmZmVjdGVkDQpob3cgaXQgd2FzIGRpc2N1c3NlZCwgYW5k IHdoYXQgcmVsaWFuY2Ugb24gZXhpc3RpbmcgbWVjaGFuaXNtLiBXaGljaCBmb3IgU0ZSQU1FDQps aWtlbHkgcmVxdWlyZSBhIGdlbmVyYWwgZGlzY3Vzc2lvbiBhbmQgdGhlbiByZXF1aXJlbWVudHMg b24gdGhlIHRyYW5zcG9ydCBhbmQNCmludm92bGVkIGVuZHBvaW50cyBhbmQgU0ZVIHRvIGFjY29t cGxpc2ggbWl0aWdhdGlvbnMuIEFuZCB0aHVzIGFsc28gd2hhdCB0aGUNCnJpc2tzIGFyZSBvZiBo YXZpbmcgbm8gbWl0aWdhdGlvbiBpbiBwbGFjZS4gDQoNCkkgd291bGQgcmVhbGx5IHByb3Bvc2Ug dGhhdCBTRlJBTUUgaXMgY2hhcnRlcmVkIHdpdGggcHVibGlzaGluZyBhIHNlY3VyaXR5DQpjb25z aWRlcmF0aW9uIGFuZCB0aHJlYXQgbW9kZWwgZG9jdW1lbnQgdGhhdCBpcyBzZXBlcmF0ZSBmcm9t IHRoZSBzb2x1dGlvbiB0bw0KZ2l2ZSB0aGlzIHRvcGljIGZ1bGwgZm9jdXMuIFRoZSBzb2x1dGlv biB3aWxsIG9mIG5lY2Vzc2l0eSBuZWVkIHRvIHJlZmVyZW5jZQ0KdGhhdCBhbmQgZG9jdW1lbnQg d2hhdCBtaWdpdGFndGlvbnMgdGhhdCBleGlzdHMgaW4gdGhlIFNGUkFNRSBsYXllciBhbmQgd2hh dA0KYmVjb21lcyByZXF1aXJlbWVudHMgb24gdGhlIHRyYW5zcG9ydC4gDQoNCkNoZWVycw0KDQpN YWdudXMgV2VzdGVybHVuZCANCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpOZXR3b3JrcywgRXJpY3Nzb24g UmVzZWFyY2gNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkVyaWNzc29uIEFCICAgICAgICAgICAgICAgICB8IFBo b25lICArNDYgMTAgNzE0ODI4Nw0KVG9yc2hhbW5zZ2F0YW4gMjMgICAgICAgICAgIHwgTW9iaWxl ICs0NiA3MyAwOTQ5MDc5DQpTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW4gfCBtYWlsdG86IG1h Z251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg== From nobody Thu Aug 6 11:02:43 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8543A0D6E for ; Thu, 6 Aug 2020 11:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qPx9Jmmy4mQ for ; Thu, 6 Aug 2020 11:02:40 -0700 (PDT) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 B94763A0D6D for ; Thu, 6 Aug 2020 11:02:39 -0700 (PDT) Received: by mail-ed1-x52d.google.com with SMTP id a14so18833710edx.7 for ; Thu, 06 Aug 2020 11:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KwWIcyCIpEZLiY5RPZx1QFB0bGnEaVlxTKu1/3XZeuk=; b=tdhjNHILmReN6y3K9Uwjw5DWhVLBTd0BCb/4KF2tgIT82VqDvQQqHYMhg0Vbo/uoll 8T7Qsl3HQQzvDLXp4AqKcNfyCe/RwIMP8eWFkXvXrxmYgx3dPJ2nIMNri+tAE2LET/Qb DQcHlfHXf7wBUqj+8yQAoXCFyDqnVIIYjVq9kyrSQxzjMcKXY8aIAzIqBql7okdW1OCQ +a7oF3qlJJjwoZwsDksU6H10jgFIk0htxu4VMM6csuYoAusxz85MXGu+OkajDi1P183w FfP2pivv4TsmHU9ffArW3kHxMOeFvyxI5FCJss/vLBcRuMuGhV09n17pAj3NFThpjicE VxxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KwWIcyCIpEZLiY5RPZx1QFB0bGnEaVlxTKu1/3XZeuk=; b=njrCmH4SECuRWPs8dLICszGBps3lk83oFpOeb/L5S2coiobitBRL3KcID9KQh5Oc3i tplzGWgm0fKHFQULnZ6EWK5xSDdOvAAQXREZj8cF9NioAbWdiMO0pMrgdt+9K1vqlWbN yQ+eGWBbAprviNOThypTHicEBuPjZs046uCbftdqG2PGjt7dyeNO29Fu0wT8XF92xdWZ cL7A5MPWRser6V05aRNdHSegrQoi/xGREHGX3mdTMapmMWSjzn1E4aRYxTQQw951lp0m qd6FCIpjrT3kjWqhU3YUSnoH6NK0q6EcjMk5ozQ+bEWTLt+W3utkQACz+KifrG0t/ept ardA== X-Gm-Message-State: AOAM530pEBTVR8pOz2tzSQ4TgXV5xENtMC+GzO6jjQUcb/rU/oAmqyuv S9Gg0tTe7zA+gqMywBokEq1N+dQIYU7pnFtIiJoF X-Google-Smtp-Source: ABdhPJxdtdp0dHp6mqoPZqKCH7Y9fCguRSV4dObIJ14Qs371M5dngjz4pYBRZg6qj29wHjKvS3brK6dN8rj4l63KxoY= X-Received: by 2002:aa7:cd46:: with SMTP id v6mr4951572edw.21.1596736957845; Thu, 06 Aug 2020 11:02:37 -0700 (PDT) MIME-Version: 1.0 References: <69181ed1-d72a-99de-8b4d-9e10276ced91@gmail.com> <771e108a9f25c1bec04d5fcdad58eb55bbb1533d.camel@ericsson.com> In-Reply-To: <771e108a9f25c1bec04d5fcdad58eb55bbb1533d.camel@ericsson.com> From: Emad Omara Date: Thu, 6 Aug 2020 11:02:26 -0700 Message-ID: To: Magnus Westerlund Cc: "ben@nostrum.com" , "rlb@ipv.sx" , "sergio.garcia.murillo@gmail.com" , "dispatch@ietf.org" , "sframe@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002c5c9f05ac394b45" Archived-At: Subject: Re: [dispatch] SFRame Next Steps (was SFrame proposed WG charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2020 18:02:42 -0000 --0000000000002c5c9f05ac394b45 Content-Type: text/plain; charset="UTF-8" Thanks Magnus. I like the idea to explicitly call out the threat model, I think it will be good foundations that control all future design decisions, however I'm not sure if the charter is the right place to call this out. I'd recommend having a separate document that describes the system architecture, goals and threat model. What do you think? Emad On Thu, Aug 6, 2020 at 1:56 AM Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > On Wed, 2020-08-05 at 22:15 +0200, Sergio Garcia Murillo wrote: > > But shouldn't the "delayed media" attack still be transport agnostic? I > > mean, this can happen on QUIC and WebRTC SFUs. > > Sorry if I gave the impression that it is not transport agnostic. It is > use case > dependent, any use case that isn't point to point, where there is more > than one > entity that can intentionally remove SFRAME creating gaps in the SFRAME > sequence. In a point to point scenario one can correlate transport losses > with > SFRAME gaps to know give a reasonably strong mitigation against any third > party > removing SFRAMEs or delaying them. That is much harder in a centralized > conference with one or more SFU. > > > > > Anyway, I agree that while SFrame is transport agnostic, the chapter > > should not ignore the interactions with webrtc/quic and we must ensure > > that we provide a complete working solution regardless of the transport. > > If we identify that any further working items are required for a > > particular transport, we should at liaise with the appropriate working > > group for providing a solution. > > My main point is that SFRAME actually needs to discuss the threat model > for the > use cases it intendes to solve. And the mitigation can potentially include > functionality on the transport level. But the risks to media security in > centralized conferencing needs to be discussed. And centralized > conferencing > will still have the semi-trusted SFUs and all the rest of the third > parties in > addition to the end-points. > > Also what properties one have around end-points invited into the > conference has > a number of question around security properties that needs to be discussed > and > documented. Some examples that I know are relevant: > > - Source authentication: SRTP unless one use TESLA (which isn't really > used) > does only provided the property: Someone that has the key sent this. One > don't > know that it comes from a particular endpoint. > > - Confidentiality when group membership changes: So will SFRAME keying > support a > use case where only the current set of members in a conference can decrypt > the > media and one rekey the media session key for each time the membership > changes? > PERC do support this, will SFRAME? > > There are likely more questions that needs discussion. The PERC discussion > is a > good starting point, but I think when going transport agnostic some of the > issues needs to be more clearly discussed as the RTP transport can have > affected > how it was discussed, and what reliance on existing mechanism. Which for > SFRAME > likely require a general discussion and then requirements on the transport > and > invovled endpoints and SFU to accomplish mitigations. And thus also what > the > risks are of having no mitigation in place. > > I would really propose that SFRAME is chartered with publishing a security > consideration and threat model document that is seperate from the solution > to > give this topic full focus. The solution will of necessity need to > reference > that and document what migitagtions that exists in the SFRAME layer and > what > becomes requirements on the transport. > > Cheers > > Magnus Westerlund > > > ---------------------------------------------------------------------- > Networks, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > <+46%2010%20714%2082%2087> > Torshamnsgatan 23 | Mobile +46 73 0949079 > <+46%2073%20094%2090%2079> > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > > --0000000000002c5c9f05ac394b45 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Magnus. I like the idea to explicitly call out the = threat model, I think it will be good foundations that control all future d= esign decisions, however I'm not sure if the charter is the right place= to call this out. I'd recommend having a separate document that descri= bes=C2=A0the system architecture, goals and threat model. What do you think= ?

Emad

On Thu, Aug 6, 2020 at 1:56 AM Magnus Wester= lund <magnus.westerlun= d@ericsson.com> wrote:
Hi,

On Wed, 2020-08-05 at 22:15 +0200, Sergio Garcia Murillo wrote:
> But shouldn't the "delayed media" attack still be transp= ort agnostic? I
> mean, this can happen on QUIC and WebRTC SFUs.

Sorry if I gave the impression that it is not transport agnostic. It is use= case
dependent, any use case that isn't point to point, where there is more = than one
entity that can intentionally remove SFRAME creating gaps in the SFRAME
sequence. In a point to point scenario one can correlate transport losses w= ith
SFRAME gaps to know give a reasonably strong mitigation against any third p= arty
removing SFRAMEs or delaying them. That is much harder in a centralized
conference with one or more SFU.

>
> Anyway, I agree that while SFrame is transport agnostic, the chapter <= br> > should not ignore the interactions with webrtc/quic and we must ensure=
> that we provide a complete working solution regardless of the transpor= t.
> If we identify that any further working items are required for a
> particular transport, we should at liaise with the appropriate working=
> group for providing a solution.

My main point is that SFRAME actually needs to discuss the threat model for= the
use cases it intendes to solve. And the mitigation can potentially include<= br> functionality on the transport level. But the risks to media security in centralized conferencing needs to be discussed. And centralized conferencin= g
will still have the semi-trusted SFUs and all the rest of the third parties= in
addition to the end-points.

Also what properties one have around end-points invited into the conference= has
a number of question around security properties that needs to be discussed = and
documented. Some examples that I know are relevant:

- Source authentication: SRTP unless one use TESLA (which isn't really = used)
does only provided the property: Someone that has the key sent this. One do= n't
know that it comes from a particular endpoint.

- Confidentiality when group membership changes: So will SFRAME keying supp= ort a
use case where only the current set of members in a conference can decrypt = the
media and one rekey the media session key for each time the membership chan= ges?
PERC do support this, will SFRAME?

There are likely more questions that needs discussion. The PERC discussion = is a
good starting point, but I think when going transport agnostic some of the<= br> issues needs to be more clearly discussed as the RTP transport can have aff= ected
how it was discussed, and what reliance on existing mechanism. Which for SF= RAME
likely require a general discussion and then requirements on the transport = and
invovled endpoints and SFU to accomplish mitigations. And thus also what th= e
risks are of having no mitigation in place.

I would really propose that SFRAME is chartered with publishing a security<= br> consideration and threat model document that is seperate from the solution = to
give this topic full focus. The solution will of necessity need to referenc= e
that and document what migitagtions that exists in the SFRAME layer and wha= t
becomes requirements on the transport.

Cheers

Magnus Westerlund


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Mobile = +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--0000000000002c5c9f05ac394b45-- From nobody Thu Aug 6 21:34:37 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF1F3A073D for ; Thu, 6 Aug 2020 21:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=MJopL1eT; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=br5vVPY+ 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 eaX1vC6u2ugS for ; Thu, 6 Aug 2020 21:34:30 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF4433A0598 for ; Thu, 6 Aug 2020 21:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=93913; q=dns/txt; s=iport; t=1596774870; x=1597984470; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1YKReLIHyIsqR6nhoDYgX3y+TthsvdU3ZGM7yLD3+pU=; b=MJopL1eTpHdqKRTjD47tCbKM3pM5JoU5mySNRfR2ZG5lkDXzEnWVwdVt K4PBELkPa1dlWxf46DZfQyjKqYgkTWCoyBxIaBVz+vvOUpA0zd+WNA6MI iA1Rsp5hna+srqi1dk1ImZzp6VebZRgM9nJlJmndrOa28jm+IVzoGnfLY k=; IronPort-PHdr: =?us-ascii?q?9a23=3AwUDQLhOc4+QAxBOdoD0l6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvK8x3lPMVJ/QrfNJl+SQtLrvCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFHXq2e5qz8fBh?= =?us-ascii?q?u5MhB6daz5H4fIhJGx0Oa/s5TYfwRPgm+7ZrV/ZBW7pAncrI8Ym4xnf60w0R?= =?us-ascii?q?DO5HBPfrdb?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DKCQAr2Sxf/40NJK1ggQmCbQEuIwY?= =?us-ascii?q?oB29YLywKh3ADjU+KBY5egUKBEQNQBQsBAQEMAQEYAQoKAgQBAYQIRAKCLAI?= =?us-ascii?q?kOBMCAwEBCwEBBQEBAQIBBgRthVwMhXEBAQEDAQEBEAgBJQEBJQcLAQQLAgE?= =?us-ascii?q?IEQECAQEBDRQBBgchBgsUAwYIAgQOBQgTBAOCOUyBfk0DDh8BAQ6pVAKBOYh?= =?us-ascii?q?hdIE0gwEBAQWBR0GDJA0Lgg4DBoE4gnCKHhqBQT+BEUOCTT6CGkIBAQIBAYE?= =?us-ascii?q?dCQEMBgEJCREdAQcGCQKDEoItjz0VDgoqAYlJi1uPZhMkTwqCYohhgg2DbIY?= =?us-ascii?q?/hRqCfIlUkzmRKQyLMIJkkhICBAIEBQIOAQEFgWojKj1wcBU7gjUBM1AXAg2?= =?us-ascii?q?OJoEeAQmCQoUUhUJ0AgE0AgYIAQEDCXyNHwEBAiSBDQGBEAEB?= X-IronPort-AV: E=Sophos;i="5.75,444,1589241600"; d="scan'208,217";a="808696135" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Aug 2020 04:34:28 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 0774YSdK020177 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 7 Aug 2020 04:34:28 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 6 Aug 2020 23:34:16 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 6 Aug 2020 23:34:15 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 7 Aug 2020 00:34:15 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dA89nOh8qUyuR+ynjWStNV5udKEVY3ZyO1m9cK5tINIQRLG8CtYJ3jvfu30Tes5xyyYupo6E/GRW5pqqpqq0ZSerbfNcEM/9wqPnkpt7v2Se33YXcQd81VWJKTlwiIYeqJac5kXZYE4S5vU69RVcg0EsrhpqVQiZHAZUkBsly+gX1v4STsPiv1RAbnNFA4s+gwKYJ3qeDCxLQhfjmK3A93ckBIuN/NwQqgkD/1SK3SENGu0Vqtuz28RVtCkOcrQB5xq/u8pC7hmkGGeNeXg+E9vIQACevDktK6ngqAp1raiHP6D8Qec1jqIOvIG1hKJUxjBAx6//O34BilwikuNPLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=V7qd1U8WAxcrAZ0bTeSgBLXQjlOorqBUR/KLEXGp504=; b=K+BqTWfuW0/eIcJvhNu0Mt56Nuj7KHSAPUB9EvEWGQ6x2S6xUjQIHbpXMvVBeQT/j+wODUHCrrxwephyk3/JpUK6o8H9GfxEpa1O0I8Z5wPds9uSCdGF1FUhd5Q9v0ZhBLwjVIJz2N+n9kNj62u8FcgBNTKV5GvlrChmt+tUb0NDP6e8h0gf2jOwapl+FZqytUFkVzKaKZ4W8S8GsL9MNGNlocAKuzSUPp4H+ETHcEESpLPmdkDS4LLlXq85FmOsu7qRj26tbdMTd9qtipAHKHquRT++XlqCftX7XtQ8JVEjjdL6hZFO/UK58tXvcC3K1zkIh87CJJNidBwjNmCf7w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=V7qd1U8WAxcrAZ0bTeSgBLXQjlOorqBUR/KLEXGp504=; b=br5vVPY+l2ogsQTwAFjmNe56FNHjPGTRWl72zWeIy4whCmxqUnlH4+YRgQjMvx7BLeE4BvVA0oOkUEg3GmtVWeGuvfjnbmkjglWeASSN1AJQ73O8jruEdeuLdT52D610lZBjEsXFdio8WtGn41und+wLSI9iA2fYJx9OV4VZNF0= Received: from BYAPR11MB2821.namprd11.prod.outlook.com (2603:10b6:a02:c9::29) by BY5PR11MB3863.namprd11.prod.outlook.com (2603:10b6:a03:18a::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.15; Fri, 7 Aug 2020 04:34:11 +0000 Received: from BYAPR11MB2821.namprd11.prod.outlook.com ([fe80::2014:1885:9028:fa74]) by BYAPR11MB2821.namprd11.prod.outlook.com ([fe80::2014:1885:9028:fa74%7]) with mapi id 15.20.3261.020; Fri, 7 Aug 2020 04:34:11 +0000 From: "Sreekanth Narayanan (sreenara)" To: Christer Holmberg CC: "Kaustubh Inamdar (kinamdar)" , "dispatch@ietf.org" Thread-Topic: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP trunking And Peering) Thread-Index: AQHV7fJsGco3tkiq3Ey8OuVoB7iPT6hD+imAgAF/nACADiqZAIAAZF+AgABIJGSAAIy5gIAADBmjgABzaYCAAFwopYAErQMLgALQBwCAz9Ea5g== Date: Fri, 7 Aug 2020 04:34:11 +0000 Message-ID: References: <73852274-8033-4864-94AC-AAC149A9E4E0@nostrum.com> <77C1ACC4-D5CA-4A27-8507-580304CC4655@nostrum.com> <2844E7A0-171E-41CA-B08E-55CADEE48BB0@nostrum.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [202.38.182.198] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 62cb3dd3-5958-417a-8d00-08d83a8b21a2 x-ms-traffictypediagnostic: BY5PR11MB3863: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: lg9vYbQr4xaTNUF/xFXazc0wnWhSGpidQEvLlpxE9YRK70UxQWBUjH1I/xZzBXpCFKF50cjExVbA0GnolLA6vpORG1Y2kJPZHb/kwQmxRhH/b7zycbMFlsqUEeCQRmLE3gMWnCZONfUmtD4CQiGvTcD5Vp5OvCNq8pkG+Np7hCzMJhSHVb2FmdbR3FKwtEYxQkpnTUIvLkMMBUqqw/iADaTZGH32QBZB7vmxcIV2+1bUUh0CttAD36Dm5mN28tGv1QiHdx3ss0u/lo4ubJ7qDba/Evm29NiWP0p3n8uk1QYd1khEcmzcL0huKAFyx0xdCF+IljEiVt9VZgyCRmFGtUvNPPS9rw7OkQTd2D5LjbTP3zBTual10jS0Gad+X8N35LVz/Itu+HD5nA1cUTuhCw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2821.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(376002)(396003)(39860400002)(136003)(346002)(8676002)(71200400001)(166002)(2906002)(478600001)(66574015)(52536014)(83380400001)(966005)(8936002)(86362001)(33656002)(54906003)(316002)(30864003)(4326008)(9686003)(186003)(66946007)(91956017)(66476007)(66556008)(64756008)(19627405001)(55016002)(26005)(7696005)(5660300002)(53546011)(6506007)(66446008)(76116006)(579004)(559001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 0Rv26fnschlb14xYdF+jbtHY3WmkXJKAYqD84FkjpVuu+qVrOcq0xc2XEaC3Qucjn0QyCYdzQngtSRdmJVRJ9jrXh8kHs+g0IUzK5c8psi5Ra7UcgHKsLYsKukc5LA/+sKqv9DwLPoekkAOogj7xtl+aZEejsAohc0LtBJuyJiiVG34sFdGtxrgbV3Wp1ru0k4aR2tHe57bdLm7VRqR3HLbPgQmScHtujL6Iqb4P8iSX/F0hbKeomtnf12aFBOti4AHfLqzUlyD/6+TvDtq2wWSb6oESuLy7xPMZ6+o2K/qR+H3QXpfVaPWMa5KLHNLRr87F202EsZ9dwRIEiFE6KEVdecsq3RmrH+GXZwFYiPFmgL87heJ2DtwhXe1//53IC7i3dDYus28tt8b2AOuOtCup7kgRwhYvlzsYavS+erL1v5WqmWlGdg2/EmPnJF/iz1V18VUuCMuMYjiSsmJadv7uefR8N76OkDPxXqSVMqytjMjlulruxjqZIlS3mLgoqABzbaA5k/WHGxnKc6Wi7W5o6DHM5egGDX4vAVUquvn207bajG5Mjvnh19ZjpPhv03EwUZ9Wc49wh8gbHWs1ysFF6SlEw5tZbFWClKGz8qFWkyqNS+tkactUEOn+RhPsMdfEkFK4Vt0s7Q01NrNL7w== Content-Type: multipart/alternative; boundary="_000_BYAPR11MB2821B2334F8410D4EF72472EDD490BYAPR11MB2821namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2821.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 62cb3dd3-5958-417a-8d00-08d83a8b21a2 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2020 04:34:11.1131 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: I0bk2quTPaGSCwxF+dBk+549juQ5R3nMUx+W2NiCMblUVbOb6dQT1881SLvGdSqakZ4zYL16OerXbifwEnPhAQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB3863 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP trunking And Peering) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 04:34:36 -0000 --_000_BYAPR11MB2821B2334F8410D4EF72472EDD490BYAPR11MB2821namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Christer, As a follow up to the charter for ASAP, I wanted to inform you that a workg= roup has been formed. Details of the workgroup are provided below. Automatic SIP trunking And Peering (asap) Current status: Active WG Chairs: Adam Roach adam@nostrum.com Gonzalo Salgueiro gsalguei@cisco.com Assigned Area Director: Murray Kucherawy superuser@gmail.com Applications and Real-Time Area Directors: Barry Leiba barryleiba@computer.org Murray Kucherawy superuser@gmail.com Mailing list: Address: asap@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/asap Archive: https://mailarchive.ietf.org/arch/browse/asap/ Group page: https://datatracker.ietf.org/group/asap/ Charter: https://datatracker.ietf.org/doc/charter-ietf-asap/ -sreekanth ________________________________ From: Christer Holmberg Sent: Saturday, March 28, 2020 2:13 AM To: Sreekanth Narayanan (sreenara) ; Ben Campbell ; dispatch@ietf.org Cc: Kaustubh Inamdar (kinamdar) ; dispatch-chairs@ietf.= org Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP trunking A= nd Peering) Hi, I am ok with the latest version of the proposed charter text. Thanks! Regards, Christer From: "Sreekanth Narayanan (sreenara)" Date: Thursday, 26 March 2020 at 6.07 To: Christer Holmberg , Ben Campbell , "dispatch@ietf.org" Cc: "Kaustubh Inamdar (kinamdar)" , "dispatch-chairs@ie= tf.org" Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP trunking A= nd Peering) All, Here's the the updated version of the proposed charter of ASAP (Automatic S= IP trunking And Peering) after addressing all concerns and comments so far.= Further suggestions/comments are welcome. The deployment of a Session Initiation Protocol (SIP)-based infrastructure = in enterprise and service provider communication networks has been increasi= ng gradually over the last few years. Consequently, direct IP peering betwe= en enterprise and service provider networks is replacing traditional method= s of interconnection between enterprise and service provider networks. Currently published standards provide a strong foundation over which direct= IP peering can be realized. However, given the sheer number of these stand= ards, it is often not clear which behavioural subsets, extensions to baseli= ne protocols and operating principles ought to be configured by the enterpr= ise network administrator to ensure successful peering with a SIP service p= rovider network. This lack of context often leads to interoperability issue= s between enterprise and service provider SIP networks resulting in a consi= derable number of support cases being opened with enterprise equipment manu= facturers and SIP service providers. Subsequently, deployment times for SIP= trunking between enterprise and service provider networks increase. This work would define a descriptive capability set, which is populated by = a SIP service provider, and which, when communicated to an enterprise netwo= rk, provides the enterprise network with sufficient information to setup SI= P trunking with the SIP service provider. Such a capability set would not o= nly result in SIP trunking deployment times being scaled down, but also wou= ld result in reduction of interoperability issues between enterprise and se= rvice provider network. Over the long run, operational costs for service pr= oviders and enterprise equipment manufactures would likely decrease as a re= sult of fewer support cases. This work would make use of HTTPS based framework that allows a SIP service= provider to offload a detailed capability set to the enterprise network. H= TTPS is used in favor of SIP for the following reasons: 1. Most SIP service providers require the enterprise network to first re= gister a SIP trunk before any SIP traffic can be exchanged between the two = networks. Accordingly, using a SIP-based method to obtain a detailed capabi= lity set from the SIP service provider (for example, SIP OPTIONS) would req= uire the service provider to relax the requirement of enterprise networks f= irst registering SIP trunks. This is a significant change and could serve a= s a barrier to adoption of the framework this work aims to produce. 2. Any modifications to existing SIP-based extensions to fit the objecti= ve of this work would require equipment manufacturers to upgrade their SIP = stacks. The scope of activity includes: * Define a robust capability set which encapsulates sufficient informat= ion to ensure smooth IP peering between enterprise and service provider SIP= networks. * Define a data model for the capability set. * Extensibility of the data model to allow proprietary parameters to be= encoded. * A HTTPS-based transport mechanism using which the capability set is c= ommunicated from the service provider network to the enterprise network. * A mechanism to discover the capability server hosted in the SIP servi= ce provider network The following is out of scope: * Extensions to SIP that enable an enterprise network to solicit and ob= tain a descriptive capability set from a SIP service provider. * A workflow/mechanism that allows service providers to directly config= ure devices in the enterprise network. The group will produce * Requirements, Use Cases and Architecture draft. * Specification for SIP Auto Peer. * This group will co-ordinate with the SIP core workgroup and the SIPCo= nnect efforts carried out by the SIP Forum. Milestones: Send protocol specification to IESG Regards Sreekanth ________________________________ From: Sreekanth Narayanan (sreenara) Sent: Monday, March 23, 2020 9:53 AM To: Christer Holmberg ; = Ben Campbell ; dispatch@ietf.org Cc: Kaustubh Inamdar (kinamdar) ; dispatch-chairs@ietf.= org Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP trunking A= nd Peering) Hi Christer, > >The SBC isn=92t required to modify the capability set - it simply source= s the HTTPS GET and parses the response. In what scenario would the SBC req= uire to modify the capabilities? >Assume you e.g., have some kind of transit network, which may limit the ca= pabilities. The capability set is provided by the ITSP that the enterprise trunk(s) reg= isters to. Therefore, the ITSP that provided the capability set is expected= to be the one that directly peers with the enterprise network. If however,= in the event there is an intermediary, the ITSP that generates the capabil= ity set must include the caps of the network that directly peers with the e= nterprise, which in this case is the intermediary (after all, SIP trunk reg= istration and call sending and receiving will be directly between the inter= mediary and the enterprise). This aspect will be discussed in the draft... Regards Sreekanth ________________________________ From: Christer Holmberg Sent: Monday, March 23, 2020 2:22 AM To: Sreekanth Narayanan (sreenara) ; Ben Campbell ; dispatch@ietf.org Cc: Kaustubh Inamdar (kinamdar) ; dispatch-chairs@ietf.= org Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP trunking A= nd Peering) Hi, >> Having to exchange capabilities before the registration/session is estab= lished is a concrete justification. Please explain that in the proposed cha= rter, >> because that would probably be one of the >most important inputs for thi= s work :) > > We can accommodate this in the charter. Thanks! >> Regarding SBCs, one of the issues by using a non-SIP mechanism is that S= BCs won=92t be able to modify the capabilities =96 unless you intend to rou= te the HTTPS traffic through the SBCs too. >> Perhaps there won=92t be any such intermediaries in the use-cases you ha= ve in mind, but we should discuss whether we are ok with that. My point is = that, before we discuss protocol details, we >> should be clear about what functionality, and what use-cases, we want to= support. > >The SBC isn=92t required to modify the capability set - it simply sources = the HTTPS GET and parses the response. In what scenario would the SBC requi= re to modify the capabilities? Assume you e.g., have some kind of transit network, which may limit the cap= abilities. Regards, Christer ________________________________ From: Christer Holmberg Sent: Sunday, March 22, 2020 6:45 PM To: Sreekanth Narayanan (sreenara) ; Ben Campbell ; dispatch@ietf.org Cc: Kaustubh Inamdar (kinamdar) ; dispatch-chairs@ietf.= org Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP trunking A= nd Peering) Hi, >What are the SIP-based mechanisms you have in mind? If there are more than= one, I assume the exchange of OPTIONS/200OK (with cap set in the body of t= he response) is one of them. Yes. Most mechanisms can also be used with non-OPTION methods. >Theoretically, while it is possible to leverage something like SIP OPTIONS= , SIP trunking deployment realities between enterprise and service provider= networks >require the trunk to first be registered (SIP REGISTER/200OK) before any S= IP traffic can be exchanged between the two networks, for example, an OPTIO= NS >or even an INVITE to setup calls. Having to exchange capabilities before the registration/session is establis= hed is a concrete justification. Please explain that in the proposed charte= r, because that would probably be one of the most important inputs for this= work :) >To that end, for a SIP-based solution to work, the service provider ought = to change this behaviour, why would that method be advocated when there >is an alternative? While this entire framework attempts to ease SIP trunki= ng between enterprise and service provider networks, why must the framework >use SIP? Why not HTTPS? Is is purely because this framework is related to = "SIP" trunking? > > What are the advantages of using SIP over HTTPS in this specific scenario= ? > What is the barrier to deployment of a SIP-based method as opposed to a H= TTPS based method? I suspect the former is more difficult. I am not saying it must use SIP =96 I am asking for a justification why HTT= PS would be more feasible than SIP. If we are going to use a non-SIP protoc= ol for exchanging SIP capabilities I think it is important for people to kn= ow why we want to use a non-SIP protocol. >Here are some of the advantages for HTTPS: > >The service providers need only deploy HTTPS servers accessible over the I= nternet so that the enterprise can obtain a capability set. >There is no change on the part of the service provider in terms of how the= y handle SIP.. >There is also very little change required on part of enterprise SBC vendor= s. Almost all SBCs today support HTTPS, XML & YANG. >I would like to reiterate that using HTTPS in this context doesn't in any = way mean that this is the new "normal" for soliciting and obtaining a remot= e SIP peers capability - the OPTIONS method >was designed for that. This is= A scenario for which HTTPS is conducive and has nothing to do with creatin= g a new way of communicating capabilities. Regarding SBCs, one of the issues by using a non-SIP mechanism is that SBCs= won=92t be able to modify the capabilities =96 unless you intend to route = the HTTPS traffic through the SBCs too. Perhaps there won=92t be any such intermediaries in the use-cases you have = in mind, but we should discuss whether we are ok with that. My point is tha= t, before we discuss protocol details, we should be clear about what functi= onality, and what use-cases, we want to support. Thanks! Regards, Christer ________________________________ From: Christer Holmberg Sent: Sunday, March 22, 2020 6:03 AM To: Ben Campbell ; dispatch@ietf.org Cc: Sreekanth Narayanan (sreenara) ; Kaustubh Inamdar (= kinamdar) ; dispatch-chairs@ietf.org Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP trunking A= nd Peering) Hi, AFAIK, the authors of the proposed charter didn=92t reply to my latest comm= ents (which I sent twice). They may have tried to address them in the lates= t version of the proposed charter, but I think it would have been useful to= have a discussion on the list. I think my main issue was describing why the existing SIP capability exchan= ge mechanisms cannot be used. The proposed charter now says: >1. While there are extensions to baseline SIP that could potentially allow= a capability set to be communicated from the service provider to the enter= prise network, >none of these extensions are readily usable to achieve the objective of th= is work. This doesn=92t say much. It would be useful with some text on why none of t= he extensions are readily usable. >2. Any modifications to existing SIP-based extensions to fit the objective= of this work would require equipment manufacturers to upgrade their SIP st= acks. This would also need more justification, because doesn=92t SIP extensions i= n general require upgrading of SIP stacks? Regards, Christer From: dispatch on behalf of Ben Campbell Date: Saturday, 21 March 2020 at 22.35 To: "dispatch@ietf.org" Cc: "Sreekanth Narayanan (sreenara)" , "Kaustubh Inamdar (kinamdar)" , "dispatch-chairs@iet= f.org" Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP trunking A= nd Peering) Hi Everyone, Gonzalo S. wins the chair-appreciation award for being the first to respond= to a chair request for input :-) Anyone else? We will have a tight agenda on Monday; any chance we could clo= se this topic prior to the meeting? On Mar 12, 2020, at 3:14 PM, Ben Campbell > wrote: Hi Again Everyone, I know people have been more caught up in how we handle the cancelation of = the IETF107 in-person meeting than in day to day DISPATCH email. One way we= can handle that is to complete discussions on list rather than taking meet= ing time. This seems like a good candidate for that. Thanks! Ben. On Mar 11, 2020, at 4:21 PM, Ben Campbell > wrote: Hi Everyone, The proponents have gone through a few revisions of the proposed charter (b= elow) based on list feedback. At this point, we=92d like to call the questi= ons on what to recommend to to the ART ADs. Please respond to the following= questions: 1. Is the topic described suitable for a reasonably short-lived mini-workin= g group, without requiring a separate BoF first? 2. Is the charter a good starting point from which to develop a final chart= er (through the usual charter review process for new working groups) 3. Would you participate in a working group with a charter substantially si= milar to this one? Note that we have agenda time allocated for this on an upcoming virtual mee= ting (details TBD), but if we can close these questions via email, we can g= ive that time back to other things. Thanks! Ben. On Feb 27, 2020, at 10:56 PM, Sreekanth Narayanan (sreenara) > = wrote: All, Here are the revisions to the proposed charter of ASAP (Automatic SIP trunk= ing And Peering) after incorporating the latest comments. Suggestions/comme= nts are welcome. The deployment of a Session Initiation Protocol (SIP)-based infrastructure = in enterprise and service provider communication networks is increasing at = a rapid pace. Consequently, direct IP peering between enterprise and servic= e provider networks is quickly replacing traditional methods of interconnec= tion between enterprise and service provider networks. Currently published standards provide a strong foundation over which direct= IP peering can be realized. However, given the sheer number of these stand= ards, it is often not clear which behavioural subsets, extensions to baseli= ne protocols and operating principles ought to be configured by the enterpr= ise network administrator to ensure successful peering with a SIP service p= rovider network. This lack of context often leads to interoperability issue= s between enterprise and service provider SIP networks resulting in a large= number of support cases being opened with enterprise equipment manufacture= rs and SIP service providers. Subsequently, deployment times for SIP trunki= ng between enterprise and service provider networks increase significantly. This work would define a descriptive capability set, which is populated by = a SIP service provider, and which, when communicated to an enterprise netwo= rk, provides the enterprise network with sufficient information to setup SI= P trunking with the SIP service provider. Such a capability set would not o= nly result in SIP trunking deployment times being drastically scaled down, = but also would result in a significant decrease in interoperability issues = between enterprise and service provider network. Over the long run, operati= onal costs for service providers and enterprise equipment manufactures woul= d likely decrease as a result of fewer support cases. This work would make use of HTTPS based framework that allows a SIP service= provider to offload a detailed capability set to the enterprise network. H= TTPS is used in favor of SIP for the following reasons: 1. While there are extensions to baseline SIP that could potentially allow = a capability set to be communicated from the service provider to the enterp= rise network, none of these extensions are readily usable to achieve the ob= jective of this work. 2. Any modifications to existing SIP-based extensions to fit the objective = of this work would require equipment manufacturers to upgrade their SIP sta= cks. The scope of activity includes: * Define a robust capability set which encapsulates sufficient information = to ensure smooth IP peering between enterprise and service provider SIP net= works. * Define a data model for the capability set. * Extensibility of the data model to allow proprietary parameters to be enc= oded. * A HTTPS-based transport mechanism using which the capability set is commu= nicated from the service provider network to the enterprise network. * A mechanism to discover the capability server hosted in the SIP service p= rovider network The following is out of scope: * Extensions to SIP that enable an enterprise network to solicit and obtain= a descriptive capability set from a SIP service provider. * A workflow/mechanism that allows service providers to directly configure = devices in the enterprise network. The group will produce * Requirements, Use Cases and Architecture draft. * Specification for SIP Auto Peer. This group will co-ordinate with the SIP core workgroup and the SIPConnect = efforts carried out by the SIP Forum. Milestones: Send protocol specification to IESG _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_BYAPR11MB2821B2334F8410D4EF72472EDD490BYAPR11MB2821namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Christer,

As a follow up to the charter for ASAP, I wanted to inform you that a workg= roup has been formed.
Details of the workgroup are provided below.

Automatic SIP trunking And Peering (asap)
Current status: Active WG

Chairs:
Adam Roach adam@nostrum.com
Gonzalo Salgueiro gsalguei@cisco.com

Assigned Area Director:
Murray Kucherawy superuser@gmail.com

Applications and Real-Time Area Directors:
Barry Leiba barryleiba@computer.org
Murray Kucherawy superuser@gmail.com

Mailing list:
Address: asap@ietf.org

Charter: https://datatracker.ietf.org/doc/charter-ietf-asap/

-sreekanth

From: Christer Holmberg &= lt;christer.holmberg=3D40ericsson.com@dmarc.ietf.org>
Sent: Saturday, March 28, 2020 2:13 AM
To: Sreekanth Narayanan (sreenara) <sreenara@cisco.com>; Ben C= ampbell <ben@nostrum.com>; dispatch@ietf.org <dispatch@ietf.org>= ;
Cc: Kaustubh Inamdar (kinamdar) <kinamdar@cisco.com>; dispatch= -chairs@ietf.org <dispatch-chairs@ietf.org>
Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP tru= nking And Peering)
 

Hi,

 

I am ok with the latest version of the prop= osed charter text. Thanks!

 

Regards,

 

Christer

 

From: "Sreekanth Narayanan (sreenara)&q= uot; <sreenara=3D40cisco.com@dmarc.ietf.org>
Date: Thursday, 26 March 2020 at 6.07
To: Christer Holmberg <christer.holmberg@ericsson.com>, Ben Ca= mpbell <ben@nostrum.com>, "dispatch@ietf.org" <dispatch@= ietf.org>
Cc: "Kaustubh Inamdar (kinamdar)" <kinamdar@cisco.com&g= t;, "dispatch-chairs@ietf.org" <dispatch-chairs@ietf.org> Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP tru= nking And Peering)

 

All,

 = ;

Here's the the updated version of the proposed = charter of ASAP (Automatic SIP trunking And Peering) after addressing all c= oncerns and comments so far. Further suggestions/comments are welcome.

 = ;

The deployment of a Session Initiation Protocol= (SIP)-based infrastructure in enterprise and service provider communicatio= n networks has been increasing gradually over the last few years. Consequen= tly, direct IP peering between enterprise and service provider networks is replacing traditional methods of intercon= nection between enterprise and service provider networks.

 = ;

Currently published standards provide a strong = foundation over which direct IP peering can be realized. However, given the= sheer number of these standards, it is often not clear which behavioural s= ubsets, extensions to baseline protocols and operating principles ought to be configured by the enterprise network = administrator to ensure successful peering with a SIP service provider netw= ork. This lack of context often leads to interoperability issues between en= terprise and service provider SIP networks resulting in a considerable number of support cases being opened = with enterprise equipment manufacturers and SIP service providers. Subseque= ntly, deployment times for SIP trunking between enterprise and service prov= ider networks increase.

 = ;

This work would define a descriptive capability= set, which is populated by a SIP service provider, and which, when communi= cated to an enterprise network, provides the enterprise network with suffic= ient information to setup SIP trunking with the SIP service provider. Such a capability set would not only result= in SIP trunking deployment times being scaled down, but also would result = in reduction of interoperability issues between enterprise and service prov= ider network. Over the long run, operational costs for service providers and enterprise equipment manufactu= res would likely decrease as a result of fewer support cases.

 = ;

This work would make use of HTTPS based framewo= rk that allows a SIP service provider to offload a detailed capability set = to the enterprise network. HTTPS is used in favor of SIP for the following = reasons:

 = ;

  1. Most SIP service providers require the enterprise network to first register= a SIP trunk before any SIP traffic can be exchanged between the two networ= ks. Accordingly, using a SIP-based method to obtain a detailed capability s= et from the SIP service provider (for example, SIP OPTIONS) would require the service provider to relax the= requirement of enterprise networks first registering SIP trunks. This is a= significant change and could serve as a barrier to adoption of the framewo= rk this work aims to produce.
  2. Any modifications to existing SIP-based extensions to fit the objective of = this work would require equipment manufacturers to upgrade their SIP stacks= .

 = ;

The scope of activity includes:

  • Define a robust capability set which encapsulates sufficient information to= ensure smooth IP peering between enterprise and service provider SIP netwo= rks.
    • Define a data model for the capability set.
  • Extensibility of the data model to allow proprietary parameters to be encod= ed.
    • A HTTPS-based transport mechanism using which the capability set is communi= cated from the service provider network to the enterprise network.
  • A mechanism to discover the capability server hosted in the SIP service pro= vider network

 = ;

The following is out of scope:

  • Extensions to SIP that enable an enterprise network to solicit and obtain a= descriptive capability set from a SIP service provider.
  • A workflow/mechanism that allows service providers to directly configure de= vices in the enterprise network.

 = ;

The group will produce

  • Requirements, Use Cases and Architecture draft.
  • Specification for SIP Auto Peer.
  • This group will co-ordinate with the SIP core workgroup and the SIPConnect = efforts carried out by the SIP Forum.

 = ;

Milestones:

<Date TBD> Send protocol specification to= IESG

 = ;

 = ;

Regards

Sreekanth

 = ;

From:= Sreekanth Narayanan (sreenara) <sreenara@cisco.com>
Sent: Monday, March 23, 2020 9:53 AM
To: Christer Holmberg <christer.holmberg=3D40ericsson.com@dmarc.i= etf.org>; Ben Campbell <ben@nostrum.com>; dispatch@ietf.org <di= spatch@ietf.org>
Cc: Kaustubh Inamdar (kinamdar) <kinamdar@cisco.com>; dispatch= -chairs@ietf.org <dispatch-chairs@ietf.org>
Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP tru= nking And Peering)

 

Hi Ch= rister,

 = ;

> >Th= e SBC isn=92t required to modify the capability set - it simply sources the= HTTPS GET and parses the response. In what scenario would= the SBC require to modify the capabilities?

 

>Assume = you e.g., have some kind of transit network, which may limit the capabiliti= es.



 The capabil= ity set is provided by the ITSP that the enterprise trunk(s) registers to. = Therefore, the ITSP that provided the capability set is expected to be the = one that directly peers with the enterprise network. If however, in the event there is an intermediary, the ITSP that = generates the capability set must include the caps of the network that dire= ctly peers with the enterprise, which in this case is the intermediary (aft= er all, SIP trunk registration and call sending and receiving will be directly between the intermediary and t= he enterprise). This aspect will be discussed in the draft...

 = ;

Regards

Sreekanth

 = ;

From:= Christer Holmberg <christer.holmberg=3D40ericsson.com@dmarc.ietf.org>= ;
Sent: Monday, March 23, 2020 2:22 AM
To: Sreekanth Narayanan (sreenara) <sreenara@cisco.com>; Ben C= ampbell <ben@nostrum.com>; dispatch@ietf.org <dispatch@ietf.org>= ;
Cc: Kaustubh Inamdar (kinamdar) <kinamdar@cisco.com>; dispatch= -chairs@ietf.org <dispatch-chairs@ietf.org>
Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP tru= nking And Peering)

 

Hi,

 

>> Having to exchange capabilities before the registration/session is establis= hed is a concrete justification. Please explain that in the proposed charte= r,

>> because that w= ould probably be one of the >most important inputs for this work :)

>= ; 

>= ; We can accommodate this in the charter.

 

Thanks!

 = ;

>> Regarding SBCs= , one of the issues by using a non-SIP mechanism is that SBCs won=92t be ab= le to modify the capabilities =96 unless you intend to route the HTTPS traf= fic through the SBCs too.

>> Perhaps there = won=92t be any such intermediaries in the use-cases you have in mind, but w= e should discuss whether we are ok with that. My point is that, before we d= iscuss protocol details, we

>> should be clea= r about what functionality, and what use-cases, we want to support.<= /span>

>= ; 

>= ;The SBC isn=92t required to modify the capabil= ity set - it simply sources the HTTPS GET and parses the response. In what scenario would the SBC require to modify the capabilities?

 

Ass= ume you e.g., have some kind of transit network, which may limit the capabi= lities.

&nb= sp;

Reg= ards,

&nb= sp;

Chr= ister

&nb= sp;

 

 

 

From:= Christer Holmberg <christer.holmberg=3D40ericsson.com@dmarc.ietf.org>= ;
Sent: Sunday, March 22, 2020 6:45 PM
To: Sreekanth Narayanan (sreenara) <sreenara@cisco.com>; Ben C= ampbell <ben@nostrum.com>; dispatch@ietf.org <dispatch@ietf.org>= ;
Cc: Kaustubh Inamdar (kinamdar) <kinamdar@cisco.com>; dispatch= -chairs@ietf.org <dispatch-chairs@ietf.org>
Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP tru= nking And Peering)

 

Hi,

 = ;

>= ;What are the SIP-based mechanisms you have in = mind? If there are more than one, I assume the exchange of OPTIONS/200OK= (with cap set in the body of the response) is one of them.

 

Yes. Most mechanisms can also be used with non-OPTION = methods.

 

>= ;Theoretically, while it is possible to leverag= e something like SIP OPTIONS, SIP trunking deployment realities between ent= erprise and service provider networks

>require the trunk to first be reg= istered (SIP REGISTER/200OK) before any SIP traffic can be exchanged betwee= n the two networks, for example, an OPTIONS

>or even an INVITE to setup calls.

 

Having to exchange capabilities before the registratio= n/session is established is a concrete justification. Please explain that i= n the proposed charter, because that would probably be one of the most impo= rtant inputs for this work :)

 

>= ;To that end, for a SIP-based solution to work,= the service provider ought to change this behaviour, why would that method= be advocated when there

>is an alternative? While this ent= ire framework attempts to ease SIP trunking between enterprise and service = provider networks, why must the framework

>u= se SIP? Why not HTTPS? Is is purely because this framework is related to &q= uot;SIP" trunking?

> <= /p>

> What are the advantages of using SIP over HTTPS in this spe= cific scenario?

> What is the barrier to deployment of a SIP-based method as = opposed to a HTTPS based method? I suspect the former is more difficult.

 

I am not saying it must use SIP =96 I am asking for a = justification why HTTPS would be more feasible than SIP. If we are going to= use a non-SIP protocol for exchanging SIP capabilities I think it is impor= tant for people to know why we want to use a non-SIP protocol.

 

>= ;Here are some of the advantages for HTTPS:

>= ; 

>= ;The service providers need only deploy HTTPS s= ervers accessible over the Internet so that the enterprise can obtain a cap= ability set.

>There is no change on the part of= the service provider in terms of how they handle SIP..

>= ;There is also very little change required on p= art of enterprise SBC vendors. Almost all SBCs today support HTTPS, XML & YANG.

>= ;I would like to reiterate that using HTTPS in = this context doesn't in any way mean that this is the new "normal"= ; for soliciting and obtaining a remote SIP peers capability - the OPTIONS method >was designed f= or that.  

Regarding SBCs, one of the issues by using a non-SIP m= echanism is that SBCs won=92t be able to modify the capabilities =96 unless= you intend to route the HTTPS traffic through the SBCs too.

Perhaps there won=92t be any such intermediaries in th= e use-cases you have in mind, but we should discuss whether we are ok with = that. My point is that, before we discuss protocol details, we should be cl= ear about what functionality, and what use-cases, we want to support.

 

Thanks!

 

Regards,

 

Christer

 

 

 

From:= Christer Holmberg <christer.holmberg=3D40ericsson.com@dmarc.ietf.org>= ;
Sent: Sunday, March 22, 2020 6:03 AM
To: Ben Campbell <ben@nostrum.com>; dispatch@ietf.org <disp= atch@ietf.org>
Cc: Sreekanth Narayanan (sreenara) <sreenara@cisco.com>; Kaust= ubh Inamdar (kinamdar) <kinamdar@cisco.com>; dispatch-chairs@ietf.org= <dispatch-chairs@ietf.org>
Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP tru= nking And Peering)

 

Hi,

 

AFAIK, the authors of the proposed charter didn=92t re= ply to my latest comments (which I sent twice). They may have tried to addr= ess them in the latest version of the proposed charter, but I think it woul= d have been useful to have a discussion on the list.

 

I think my main issue was describing why the existing = SIP capability exchange mechanisms cannot be used.

 

The proposed charter now says:

 

>1. While there are extensions to baseline SIP that= could potentially allow a capability set to be communicated from the servi= ce provider to the enterprise network,

>none of these extensions are readily usable to ach= ieve the objective of this work.

 

This doesn=92t say much. It would be useful with some = text on why none of the extensions are readily usable.

 

>2. Any modifications to existing SIP-based extensi= ons to fit the objective of this work would require equipment manufacturers= to upgrade their SIP stacks.

 

This would also need more justification, because doesn= =92t SIP extensions in general require upgrading of SIP stacks?

 

Regards,

 

Christer

 

 

 

From: dispatch <dispatch-bounces@ietf.org= > on behalf of Ben Campbell <ben@nostrum.com>
Date: Saturday, 21 March 2020 at 22.35
To: "dispatch@ietf.org" <dispatch@ietf.org>
Cc: "Sreekanth Narayanan (sreenara)" <sreenara=3D40cisc= o.com@dmarc.ietf.org>, "Kaustubh Inamdar (kinamdar)" <kinam= dar@cisco.com>, "dispatch-chairs@ietf.org" <dispatch-chairs= @ietf.org>
Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP tru= nking And Peering)

 

Hi Everyone,

 

Gonzalo S. wins the chair-appreciation award for being the first to respond= to a chair request for input :-) 

 

Anyone else? We will have a tight agenda on Monday; any chance we could clo= se this topic prior to the meeting?

 

On Mar 12, 2020, at 3:14 PM, Ben Campbell <ben@nostrum.com> wrote:

 

Hi Again Everyone,

 

I know people have been more caught up in how we handle the cancelation of = the IETF107 in-person meeting than in day to day DISPATCH email. One way we= can handle that is to complete discussions on list rather than taking meet= ing time. This seems like a good candidate for that.

 

Thanks!

 

Ben.

 

On Mar 11, 2020, at 4:21 PM, Ben Campbell <ben@nostrum.com> wrote:

 

Hi Everyone,

 

The proponents have gone through a few revisions of the proposed charter (b= elow) based on list feedback. At this point, we=92d like to call the questi= ons on what to recommend to to the ART ADs. Please respond to the following= questions:

 

1. Is the topic described suitable for a reasonably short-lived mini-workin= g group, without requiring a separate BoF first?

 

2. Is the charter a good starting point from which to develop a final chart= er (through the usual charter review process for new working groups)

 

3. Would you participate in a working group with a charter substantially si= milar to this one?

 

Note that we have agenda time allocated for this on an upcoming virtual mee= ting (details TBD), but if we can close these questions via email, we can g= ive that time back to other things.

 

Thanks!

 

Ben.

 

On Feb 27, 2020, at 10:56 PM, Sreekanth Narayanan (sreenara) <sreenara=3D40cisco.com@dmarc= ....ietf.org> wrote:

 

All,

 

Here are the revis= ions to the proposed charter of ASAP (Automatic SIP trunking And Peering) a= fter incorporating the latest comments. Suggestions/comments are welcome.

 

 

The deployment of = a Session Initiation Protocol (SIP)-based infrastructure in enterprise and = service provider communication networks is increasing at a rapid pace. Cons= equently, direct IP peering between enterprise and service provider networks is quickly replacing traditional methods of = interconnection between enterprise and service provider networks.

 

Currently publishe= d standards provide a strong foundation over which direct IP peering can be= realized. However, given the sheer number of these standards, it is often = not clear which behavioural subsets, extensions to baseline protocols and operating principles ought to be configured by t= he enterprise network administrator to ensure successful peering with a SIP= service provider network. This lack of context often leads to interoperabi= lity issues between enterprise and service provider SIP networks resulting in a large number of support cases= being opened with enterprise equipment manufacturers and SIP service provi= ders. Subsequently, deployment times for SIP trunking between enterprise an= d service provider networks increase significantly.

 

This work would de= fine a descriptive capability set, which is populated by a SIP service prov= ider, and which, when communicated to an enterprise network, provides the e= nterprise network with sufficient information to setup SIP trunking with the SIP service provider. Such a capability set= would not only result in SIP trunking deployment times being drastically s= caled down, but also would result in a significant decrease in interoperabi= lity issues between enterprise and service provider network. Over the long run, operational costs for service= providers and enterprise equipment manufactures would likely decrease as a= result of fewer support cases.

 

This work would ma= ke use of HTTPS based framework that allows a SIP service provider to offlo= ad a detailed capability set to the enterprise network. HTTPS is used in fa= vor of SIP for the following reasons:

1. While there are= extensions to baseline SIP that could potentially allow a capability set t= o be communicated from the service provider to the enterprise network, none= of these extensions are readily usable to achieve the objective of this work.

2. Any modificatio= ns to existing SIP-based extensions to fit the objective of this work would= require equipment manufacturers to upgrade their SIP stacks.

 

The scope of activ= ity includes:

 

* Define a robust = capability set which encapsulates sufficient information to ensure smooth I= P peering between enterprise and service provider SIP networks.

* Define a data mo= del for the capability set.

* Extensibility of= the data model to allow proprietary parameters to be encoded.

* A HTTPS-based tr= ansport mechanism using which the capability set is communicated from the s= ervice provider network to the enterprise network.

* A mechanism to d= iscover the capability server hosted in the SIP service provider network

 

The following is o= ut of scope:

* Extensions to SI= P that enable an enterprise network to solicit and obtain a descriptive cap= ability set from a SIP service provider.

* A workflow/mecha= nism that allows service providers to directly configure devices in the ent= erprise network.

 

The group will pro= duce

* Requirements, Us= e Cases and Architecture draft.

* Specification fo= r SIP Auto Peer.

 

This group will co= -ordinate with the SIP core workgroup and the SIPConnect efforts carried ou= t by the SIP Forum.

 

Milestones:=

<Date TBD> S= end protocol specification to IESG

 

____________________= ___________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/= listinfo/dispatch

 

 

 

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

 

--_000_BYAPR11MB2821B2334F8410D4EF72472EDD490BYAPR11MB2821namp_-- From nobody Fri Aug 7 20:51:25 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB0C3A0C32 for ; Fri, 7 Aug 2020 20:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cosmosoftware-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOnaf9qka-JL for ; Fri, 7 Aug 2020 20:51:16 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 D52443A0C39 for ; Fri, 7 Aug 2020 20:51:16 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id r21so3168281ota.10 for ; Fri, 07 Aug 2020 20:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cosmosoftware-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=imSr3jez8a6v0Nn3rBShIoMEgthfm8/4ZGv9IAvcv1g=; b=Jwnl7fmEJGrW/o8WBsKXr++b2O3TLfcSjhXVyJKWlMDebADHRRuGNrQFhiyXGvz8qB x5EftS06YHy0A2Lx81A5PQfdI/zTc8UcS/u3pA8y96tAqDB86HS6VyzbpGis0tWhg4aP vGSrDn4/zmxd4cjYrMOz6DCmGnYjR1ncHOIyhDhdM4zcgNd3pSSfuWmWz+oI48cv/A9F G2T/UBcvtOFHhKpLD/ONvdqf5Idi2efMDkd6rLgn8HnAZQg8MsCOVTBz1nrHSMiFasGV cE4JNX3uESMU/fBXOuIz8gtwSrwgWMqWGx3dflzEUXV/5TUfESZ/nVr2USJaAbAO4GRO fcDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=imSr3jez8a6v0Nn3rBShIoMEgthfm8/4ZGv9IAvcv1g=; b=Mu1AdOWFClGwMn3KFJ00oJg6HQ2pxBSYSqwyxR9VLTS4sboJV+b1gVCU8Hli8g1SiP qJKALQo/wXIyF63U38uDMhhEgqUAMy9qL7RVaaVBXfzBc675nC5LxjS6nfxtDksoOKR7 cmYO8zJH3fknBvPwg1VhxJTEiVlfQIVR3yzrneCUBh2s0FLYX84aeJ15WF/uTpyvatlW 8+UVEqPtfCebai11Jt7PwPx0YqnAXzz+LmrSm3cOnTPV1K0Z6VgPXdYozMV2UQz36T+R X0DwzKtKqT81zwW3PTML8Y2n4BeG5TNqbHAPbVVJyJoQmiJYBNeMqBCzPHomeyRwvXy+ 34nQ== X-Gm-Message-State: AOAM530yvgW+IYMpik0k0sC6EnmZm/OQGntaMxg+w1D85a05+va8UQyW UWz/ah8scUBgXk+ioxhJuOV2d9KxvX2d2fvXzG+S2w== X-Google-Smtp-Source: ABdhPJwuhUadYuOal9JFmTPyTMZ+lCXl0yWGONerFVzCqHt1kixUz+Tv/0rNDZdQbqiRU6b5+XgyZ7Xz1goe/UF1PhE= X-Received: by 2002:a9d:5616:: with SMTP id e22mr15491969oti.255.1596858676027; Fri, 07 Aug 2020 20:51:16 -0700 (PDT) MIME-Version: 1.0 References: <69181ed1-d72a-99de-8b4d-9e10276ced91@gmail.com> <771e108a9f25c1bec04d5fcdad58eb55bbb1533d.camel@ericsson.com> In-Reply-To: From: Alexandre GOUAILLARD Date: Sat, 8 Aug 2020 11:51:05 +0800 Message-ID: To: Emad Omara Cc: Magnus Westerlund , "rlb@ipv.sx" , "ben@nostrum.com" , "dispatch@ietf.org" , "sergio.garcia.murillo@gmail.com" , "sframe@ietf.org" Content-Type: multipart/alternative; boundary="000000000000243a0005ac55a264" Archived-At: Subject: Re: [dispatch] [Sframe] SFRame Next Steps (was SFrame proposed WG charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2020 03:51:20 -0000 --000000000000243a0005ac55a264 Content-Type: text/plain; charset="UTF-8" guys, sorry for jumping in so late, quarantine here is very strict. We had long discussions about this specific point ahead of the draft submission. We had reached the following consensus: - there are multiple usage of media over the internet, e.g. conferencing and streaming/broadcast - they have very different threat/trust models, with different solutions implemented today (transport layer E / E2EE / DRM / Encrypted Media Extentions / ...) - they all can benefit from SFrame PERC was, by design, limited to RTP and to Conferencing. Many other use case coul benefit from Enhanced Privacy. We concluded that it would be better to keep SFrame (the media encryption part, equivalent to PERC double conceptually), and to have separated documents that describe the threat models and the corresponding key exchange, signaling and system level decision for each use case. Emad had taken an action item for example to make two additional documents to describe the Video Conferencing use case, and how SFrame could be used in conjunction with MLS to address that specific use case. Someone else could take the different use case of the Browsers (which have a specific trust model) and make a document showing how SFrame con work with Insertable Frame API (and likely some more) to address that use case. CoSMo is interested in doing the same thing for Real-Time streaming/Broadcasting. I think it is a more reasonable approach as, even spending a lot of time brainstorming with everyone around the tabel including bernard, we couldn't think about one solution to fit all the different "media over internet"'s threat model. In my mind, each case should first have an informal document to define scope and threat model, and subsequent document to define the corresponding specifications. - Secure Conferencing Threat model (emad and co.) - Secure Conferencing Signalling using MLS (emad and co.) - Secure Conferencing using MLS In the browser (contributed by w3c people) Magnus, what do you think? Regards, Dr. ALex. On Fri, Aug 7, 2020 at 2:02 AM Emad Omara wrote: > Thanks Magnus. I like the idea to explicitly call out the threat model, I > think it will be good foundations that control all future design decisions, > however I'm not sure if the charter is the right place to call this out. > I'd recommend having a separate document that describes the system > architecture, goals and threat model. What do you think? > > Emad > > On Thu, Aug 6, 2020 at 1:56 AM Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: > >> Hi, >> >> On Wed, 2020-08-05 at 22:15 +0200, Sergio Garcia Murillo wrote: >> > But shouldn't the "delayed media" attack still be transport agnostic? I >> > mean, this can happen on QUIC and WebRTC SFUs. >> >> Sorry if I gave the impression that it is not transport agnostic. It is >> use case >> dependent, any use case that isn't point to point, where there is more >> than one >> entity that can intentionally remove SFRAME creating gaps in the SFRAME >> sequence. In a point to point scenario one can correlate transport losses >> with >> SFRAME gaps to know give a reasonably strong mitigation against any third >> party >> removing SFRAMEs or delaying them. That is much harder in a centralized >> conference with one or more SFU. >> >> > >> > Anyway, I agree that while SFrame is transport agnostic, the chapter >> > should not ignore the interactions with webrtc/quic and we must ensure >> > that we provide a complete working solution regardless of the >> transport. >> > If we identify that any further working items are required for a >> > particular transport, we should at liaise with the appropriate working >> > group for providing a solution. >> >> My main point is that SFRAME actually needs to discuss the threat model >> for the >> use cases it intendes to solve. And the mitigation can potentially include >> functionality on the transport level. But the risks to media security in >> centralized conferencing needs to be discussed. And centralized >> conferencing >> will still have the semi-trusted SFUs and all the rest of the third >> parties in >> addition to the end-points. >> >> Also what properties one have around end-points invited into the >> conference has >> a number of question around security properties that needs to be >> discussed and >> documented. Some examples that I know are relevant: >> >> - Source authentication: SRTP unless one use TESLA (which isn't really >> used) >> does only provided the property: Someone that has the key sent this. One >> don't >> know that it comes from a particular endpoint. >> >> - Confidentiality when group membership changes: So will SFRAME keying >> support a >> use case where only the current set of members in a conference can >> decrypt the >> media and one rekey the media session key for each time the membership >> changes? >> PERC do support this, will SFRAME? >> >> There are likely more questions that needs discussion. The PERC >> discussion is a >> good starting point, but I think when going transport agnostic some of the >> issues needs to be more clearly discussed as the RTP transport can have >> affected >> how it was discussed, and what reliance on existing mechanism. Which for >> SFRAME >> likely require a general discussion and then requirements on the >> transport and >> invovled endpoints and SFU to accomplish mitigations. And thus also what >> the >> risks are of having no mitigation in place. >> >> I would really propose that SFRAME is chartered with publishing a security >> consideration and threat model document that is seperate from the >> solution to >> give this topic full focus. The solution will of necessity need to >> reference >> that and document what migitagtions that exists in the SFRAME layer and >> what >> becomes requirements on the transport. >> >> Cheers >> >> Magnus Westerlund >> >> >> ---------------------------------------------------------------------- >> Networks, Ericsson Research >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> <+46%2010%20714%2082%2087> >> Torshamnsgatan 23 | Mobile +46 73 0949079 >> <+46%2073%20094%2090%2079> >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> >> -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --000000000000243a0005ac55a264 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
guys,

sorry for jumping in so late, qua= rantine here is very strict.

We had long discussio= ns about this specific point ahead of the draft submission.
We ha= d reached the following consensus:
- there are multiple usage of = media over the internet, e.g. conferencing and streaming/broadcast
- they have very different threat/trust models, with different solutions = implemented today (transport layer E / E2EE / DRM / Encrypted Media Extenti= ons / ...)
- they all can benefit from SFrame

PERC was, by design, limited to RTP and to Conferencing. Many other u= se case coul benefit=C2=A0from Enhanced=C2=A0Privacy.

<= div>We concluded that it would be better to keep SFrame (the media encrypti= on part, equivalent to PERC double conceptually), and to have separated doc= uments that=C2=A0describe the threat models and the corresponding key excha= nge,=C2=A0signaling=C2=A0and system level decision for each use case. Emad = had taken an action item for example to make two additional=C2=A0documents = to describe the Video Conferencing use case,=C2=A0and how SFrame could be u= sed in conjunction with MLS to address that specific use case. Someone else= could take the different use case of the Browsers=C2=A0(which have a speci= fic trust model) and make a document showing how SFrame con work with Inser= table Frame API (and likely some more) to address that use case. CoSMo is i= nterested in doing the same thing for Real-Time streaming/Broadcasting.

I think it is a more reasonable=C2=A0approach as, eve= n spending a lot of time brainstorming with everyone around the tabel inclu= ding bernard, we couldn't think about one solution to fit all the diffe= rent "media over internet"'s threat model. In my mind, each c= ase should first have an informal document to define scope and threat model= , and subsequent document to define the corresponding specifications.=C2=A0=
- Secure Conferencing Threat model (emad and co.)
- Se= cure Conferencing Signalling using MLS (emad and co.)
- Secure Co= nferencing using MLS In the browser (contributed by w3c people)
<= br>
Magnus, what do you think?

Regards,= =C2=A0

Dr. ALex.



On Fri, Aug 7, 2020 at 2:02 AM Emad Omara <emadomara=3D40google.com@dmarc.ietf.org> wrote:<= br>
Thanks Magnus. I like the idea t= o explicitly call out the threat model, I think it will be good foundations= that control all future design decisions, however I'm not sure if the = charter is the right place to call this out. I'd recommend having a sep= arate document that describes=C2=A0the system architecture, goals and threa= t model. What do you think?

Emad

On Thu, Aug 6, 202= 0 at 1:56 AM Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
Hi,

On Wed, 2020-08-05 at 22:15 +0200, Sergio Garcia Murillo wrote:
> But shouldn't the "delayed media" attack still be transp= ort agnostic? I
> mean, this can happen on QUIC and WebRTC SFUs.

Sorry if I gave the impression that it is not transport agnostic. It is use= case
dependent, any use case that isn't point to point, where there is more = than one
entity that can intentionally remove SFRAME creating gaps in the SFRAME
sequence. In a point to point scenario one can correlate transport losses w= ith
SFRAME gaps to know give a reasonably strong mitigation against any third p= arty
removing SFRAMEs or delaying them. That is much harder in a centralized
conference with one or more SFU.

>
> Anyway, I agree that while SFrame is transport agnostic, the chapter <= br> > should not ignore the interactions with webrtc/quic and we must ensure=
> that we provide a complete working solution regardless of the transpor= t.
> If we identify that any further working items are required for a
> particular transport, we should at liaise with the appropriate working=
> group for providing a solution.

My main point is that SFRAME actually needs to discuss the threat model for= the
use cases it intendes to solve. And the mitigation can potentially include<= br> functionality on the transport level. But the risks to media security in centralized conferencing needs to be discussed. And centralized conferencin= g
will still have the semi-trusted SFUs and all the rest of the third parties= in
addition to the end-points.

Also what properties one have around end-points invited into the conference= has
a number of question around security properties that needs to be discussed = and
documented. Some examples that I know are relevant:

- Source authentication: SRTP unless one use TESLA (which isn't really = used)
does only provided the property: Someone that has the key sent this. One do= n't
know that it comes from a particular endpoint.

- Confidentiality when group membership changes: So will SFRAME keying supp= ort a
use case where only the current set of members in a conference can decrypt = the
media and one rekey the media session key for each time the membership chan= ges?
PERC do support this, will SFRAME?

There are likely more questions that needs discussion. The PERC discussion = is a
good starting point, but I think when going transport agnostic some of the<= br> issues needs to be more clearly discussed as the RTP transport can have aff= ected
how it was discussed, and what reliance on existing mechanism. Which for SF= RAME
likely require a general discussion and then requirements on the transport = and
invovled endpoints and SFU to accomplish mitigations. And thus also what th= e
risks are of having no mitigation in place.

I would really propose that SFRAME is chartered with publishing a security<= br> consideration and threat model document that is seperate from the solution = to
give this topic full focus. The solution will of necessity need to referenc= e
that and document what migitagtions that exists in the SFRAME layer and wha= t
becomes requirements on the transport.

Cheers

Magnus Westerlund


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Mobile = +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--000000000000243a0005ac55a264-- From nobody Mon Aug 10 06:00:54 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3933A0CE7 for ; Mon, 10 Aug 2020 06:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7agtwf9k1K4 for ; Mon, 10 Aug 2020 06:00:49 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19FC63A09AC for ; Mon, 10 Aug 2020 06:00:48 -0700 (PDT) Received: from [172.16.42.101] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BQGKq02TMzyYL; Mon, 10 Aug 2020 15:00:46 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 618757244.117569-b3808dc533ddf65cc1a8632a8be50bdb Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Mon, 10 Aug 2020 15:00:44 +0200 Message-Id: To: dispatch@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [dispatch] Discuss JSONPath charter over at jsonpath@ietf.org X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 13:00:53 -0000 I hope everyone has been able to use the last week to recover from the = IETF108 meeting. In the dispatch meeting 14 d ago, we decided to start work on a JSONPath = charter over at the JSONPath mailing list; details below. So now would = be a good time to join that if you care about JSONPath (or its = alternatives). There are some 25 subscribers already, but I don=E2=80=99t= find all names over there yet that have contributed to the discussion = here. Gr=C3=BC=C3=9Fe, Carsten A new IETF non-working group email list has been created. List address: jsonpath@ietf.org Archive: https://mailarchive.ietf.org/arch/browse/jsonpath/ To subscribe: https://www.ietf.org/mailman/listinfo/jsonpath Purpose: For matching and selecting parts of a data item tree, XML has XPath. In = 2007, Stefan Goessner proposed JSONPath as an analogue for JSON. This = format has seen wide use, with dozens of implementations, but has not = yet been formally standardized. The conditions for standardizing now = seem to align. This mailing list is intended for discussing the creation = of an IETF activity for this (likely in the form of a WG), initially by = agreeing a proposed charter for this WG. This charter proposal will then = receive further discussion in the DISPATCH WG. Concurrently, discussions = about technical issues in JSONPath standardization are also welcome.= From nobody Mon Aug 10 19:07:48 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D523A0ECF; Mon, 10 Aug 2020 19:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.466 X-Spam-Level: X-Spam-Status: No, score=-1.466 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.212, MAY_BE_FORGED=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 CMD2PcgDQCJs; Mon, 10 Aug 2020 19:07:45 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 EB2913A0EC2; Mon, 10 Aug 2020 19:07:44 -0700 (PDT) Received: from bens-macbook.lan (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 07B27agf091345 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 10 Aug 2020 21:07:37 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1597111659; bh=6eLtE2fttOphGNBEnSEI/5FZl5FA3MZ9vu8SINCrrfQ=; h=From:Subject:Date:Cc:To; b=Y2iYriq84y8ekVl+j+HfwEpF8G18mFH8gkUi5BzBfAntiRCxrkWZmW6FM/scuAaF7 v0yovijy2siYHVR/lENjxevElKZUrL4lkHEVRAd8FFYPUzXOSsQEd2ZU2HZIGvxEtS +RdjD/ZtJIAQuE/QwIBUQvD9gKtQyKidkcGwCPK4= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be bens-macbook.lan From: Ben Campbell Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: Date: Mon, 10 Aug 2020 21:07:29 -0500 Cc: Mark Nottingham , Patrick McManus To: ART ADs , Dispatch WG X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [dispatch] HTTPAPI Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 02:07:46 -0000 Hi Everyone, Based on discussion in the IETF108 meeting and followup on the list, the = chairs think that the HTTPAPI charter [1] is ready to go to the ADs. If = people have additional feedback, there will be opportunity to refine it = further during the cross-IETF external review period. [1] https://gist.github.com/mnot/8a29455df65df33d92902a1ecc3e7e68 = (pasted below for convenience) Thanks! The DISPATCH Chairs. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94 Building Blocks for HTTP APIs Working Group (HTTPAPI) HTTP is often for not only Web browsing, but also machine-to-machine = communication, often called 'HTTP APIs'. This Working Group will = standardise HTTP protocol extensions for use in such cases, with a focus = on building blocks for separate or combined use. Its output can include: =E2=80=A2 Specifications for new HTTP header and/or trailer = fields =E2=80=A2 Specifications for new message body formats, or = conventions for use in them (e.g., patterns of JSON objects) =E2=80=A2 Proposals for new HTTP status codes, methods, or other = generic extensions, to be considered by the HTTP Working Group =E2=80=A2 Best practices and other documentation for HTTP API = designers, consumers, implementers, operators, etc. Other items are out of scope. In particular, this WG will not take on = work items for APIs for specific use cases or applications, and it will = not define new HTTP extension points, or new extensions that are likely = to be implemented by Web browsers (based upon consultation with the HTTP = WG). APIs for HTTP itself (e.g., in clients and servers) are also out of = scope. New work items can be added after a Call for Adoption on the working = group mailing list and consultation with the Area Director. To be successful, this Working Group will need to have active and broad = representation from across the industry -- e.g., API gateway vendors = (and other intermediaries), API consultants, API tool vendors, in-house = API teams. Therefore, adopted proposals should have public support from = multiple implementers and/or deployments before being sent to the IESG. This Working Group will need to coordinate closely with the HTTP Working = Group. From nobody Tue Aug 11 01:07:45 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243E93A0E4F; Tue, 11 Aug 2020 01:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.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 YFqMGLkycuvs; Tue, 11 Aug 2020 01:07:41 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410101.outbound.protection.outlook.com [40.107.141.101]) (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 209A33A0E4B; Tue, 11 Aug 2020 01:07:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L16If2H2z0Wv0kPjUdpVOXmik9IKqVA1Liiz59PxAsEUjqX3KrCckHEonu2pD9ZFtjxe4TFltb30+eSjJHZV6BMroQz1puN6cz/z83noXT4h8laT3kL6Uc3E0rIr0pMvNa3DZnZN/I1xf6Pn9Z5vqipSsN6SKrhA7VKWR2dCaEdN4+DDEm2L+T80WrQK7l+iGEv+cAAdp6K2hA0f9EWPuSwOg/Teswk0igZ6USqnlocjBbjrhFruipYen4DubUkDVHz69nFgaiHD46MwwQ3QErKo4m2J7XwI+hme3Mmsz62mluiTlZGhBD5YULemGaru5wBCfiK/LgsBaKj+xMId5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=80w0Ut2l9fF8LUszB+bfLv1XQJPizlfuMFmWNdbC5gQ=; b=n+LeM6HFI2rEM1NzLsUy1h4goPOtIwWI+xLjcBn9s/akmwc6mFmRM40MSI47y+uQbMWoowCd3lO9gsK9JtxJKemhtE4G/68HfPBb4HnzuuL/e8wJ50WxydJ76Gf25kaeOLpCLSrQxkrmhhOzjQIbTzfWt5u5o6pXv3SOKOSro33lyQBZQFOrSgklPXXzNRD98VL00hOpCw2zyH8yb5slVb7Wco0GE2uo+hCwqqQje/s6ItTMsoEKbe0t3S0DnRR660852cH+n5dTqKztum30rvsJ2Pc5gq1AD2q3Ekzb/zuzv/FgkTP/43oBJlWfL8Qh8Jf/Jub/OnL2lDhQEwn93Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=80w0Ut2l9fF8LUszB+bfLv1XQJPizlfuMFmWNdbC5gQ=; b=JnUj6Rr0bR93b3ppoBSRFfrJdyTSX6fe+SoecKllsR7l3ig2toCRYdnG0IIakYjx8x0J05Ez2GtCtwfm3uGB2+BBV+gNvZB7fDrxjm7f3Y0/IcO4E8l4vQNH3ov2sp1M4/rB2/IEuOK2AwJyDMwEldUPV/o/jtqnZ5jBx6t9/7E= Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from OSBPR01MB2566.jpnprd01.prod.outlook.com (2603:1096:604:1c::13) by OSAPR01MB3091.jpnprd01.prod.outlook.com (2603:1096:603:39::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.19; Tue, 11 Aug 2020 08:07:38 +0000 Received: from OSBPR01MB2566.jpnprd01.prod.outlook.com ([fe80::d1a0:ea71:e6f9:9778]) by OSBPR01MB2566.jpnprd01.prod.outlook.com ([fe80::d1a0:ea71:e6f9:9778%7]) with mapi id 15.20.3261.022; Tue, 11 Aug 2020 08:07:38 +0000 To: Ben Campbell , ART ADs , Dispatch WG Cc: Patrick McManus References: From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <59896111-b7dd-e699-0925-869ec4e6d560@it.aoyama.ac.jp> Date: Tue, 11 Aug 2020 17:07:35 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TYAPR01CA0050.jpnprd01.prod.outlook.com (2603:1096:404:2b::14) To OSBPR01MB2566.jpnprd01.prod.outlook.com (2603:1096:604:1c::13) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.6] (114.182.253.12) by TYAPR01CA0050.jpnprd01.prod.outlook.com (2603:1096:404:2b::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.15 via Frontend Transport; Tue, 11 Aug 2020 08:07:37 +0000 X-Originating-IP: [114.182.253.12] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: daac16ef-819a-4355-1274-08d83dcd9cb5 X-MS-TrafficTypeDiagnostic: OSAPR01MB3091: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 29JvrIaqW+UT7aZXyIH7RhJYVrmNSJIMVQ9jnsfCCSfCFu5Jx+acJPhQ+qPZ6SZM7gb3K6szPj4JWNvRBNSI4Yg2/sEJLOa7JQFjrWxcGLyc54Yxs2vJAACeCXIGOww3/w/y9aMbJr6YetYOJA0fB/jwWeFt++0i8znHCsngsIdhlvI8GOUiQosM2AkOOL9b0vBWVWoJobYg/3Sh4gAVOe46KfkzPM7TXZxmvf3UcdLwPEqlbqI/GBsZFHsm6O89WkpqOrAYFNDi3IdZq02+M8B52+ak9LRMg2MigVvWOd6SfdwvK8OdJ/VLfW8CRB59tflEoVBIhk76L/zHfgK1EPzaq/MsCJYnSXy84hw8k9ouQ8RCXKr05dIVhv9iNGOtveovTYAvlHeQ9iKf3bkBJdy1WwTEtbhCNdehjyhSi6vXMZMg/5MM1//uomADRidwULCEcBp2at53zkNJkSKvZA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:OSBPR01MB2566.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(366004)(376002)(346002)(136003)(396003)(39840400004)(6486002)(31686004)(186003)(16526019)(316002)(16576012)(786003)(2906002)(66946007)(2616005)(66556008)(66476007)(5660300002)(966005)(8936002)(956004)(26005)(8676002)(110136005)(83380400001)(508600001)(52116002)(36916002)(31696002)(4326008)(86362001)(53546011)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: HfkqIElXzxEXdkUh5FmefCKfyghCUiz8QrpvvZWFgNhI7Q6BzwnxJqQpvmcWqZ9qUaHe3bPmkIBggLVxCUbiOqvPzBweQHH2lQ8dE1lYluWmEbv8B8F6q9xp2UWx3m8TrZJlDLl8V2mtjbLDDCsdXpLXnrBb8z/cJMbS0Xc1yhEf2cIyD+tUzBg/mIkeCPxEBywovulje0sSrlbiU//EQjNnWZHACUKuBLIXHmGptXMpTgrG4K1gEjDyWsUAn6LoZCjkF9HpES7ybspxHihI0+yYV05T9RqD/Yb0OIOekNLrjpMqDQA0IylCpOycGjdAxYUNlDR/J5/Nz0dY65jbEwpUCvYXAsm8gE3d3dGifWL5tuhrXIclX2bpPU3cG4r0sBqwJ5dX//gDSMaEi9TMV0gPPHgrSBGUBRioajpMXIoyi4XrksCWWRA0oSPaHfwROObirugJ3wy8QPBm9+B7ZLJ1gG+whOr4mO/edQb9H3CUZEQ7E8pJI3nyFZttnWXwVECxlG2Zkv7V6QONcRmbmBYw0D2ZGwF48/fuROszEeI/nTO2vMdjdzUS2sFXONCHILwFdJeoZLh4lBDEoQsVGl1NUBYyIPJG8XkEgsGc8ASWx0S2+OLcSy4vn0ruLpL9ObLSOcHWVMIa0+SOE1UhJg== X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: daac16ef-819a-4355-1274-08d83dcd9cb5 X-MS-Exchange-CrossTenant-AuthSource: OSBPR01MB2566.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2020 08:07:38.2307 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Fz8VO6lrnMJG1ii5n/KvMMojAv5UZQkKYowhli9l9GoO2V45g1b41ZEMYLDE3zQwB+/tdRMoU7f2TxSLWVyI5w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSAPR01MB3091 Archived-At: Subject: Re: [dispatch] HTTPAPI Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 08:07:43 -0000 Hello Ben, others, I suggest the following (purely editorial) change: OLD HTTP is often for not only Web browsing NEW HTTP is often used for not only Web browsing EVEN BETTER HTTP is often used not only for Web browsing Regards, Martin. On 11/08/2020 11:07, Ben Campbell wrote: > Hi Everyone, > > Based on discussion in the IETF108 meeting and followup on the list, the chairs think that the HTTPAPI charter [1] is ready to go to the ADs. If people have additional feedback, there will be opportunity to refine it further during the cross-IETF external review period. > > [1] https://gist.github.com/mnot/8a29455df65df33d92902a1ecc3e7e68 (pasted below for convenience) > > Thanks! > > The DISPATCH Chairs. > > —————————————————— > > Building Blocks for HTTP APIs Working Group (HTTPAPI) > > HTTP is often for not only Web browsing, but also machine-to-machine communication, often called 'HTTP APIs'. This Working Group will standardise HTTP protocol extensions for use in such cases, with a focus on building blocks for separate or combined use. > > Its output can include: > > • Specifications for new HTTP header and/or trailer fields > • Specifications for new message body formats, or conventions for use in them (e.g., patterns of JSON objects) > • Proposals for new HTTP status codes, methods, or other generic extensions, to be considered by the HTTP Working Group > • Best practices and other documentation for HTTP API designers, consumers, implementers, operators, etc. > Other items are out of scope. In particular, this WG will not take on work items for APIs for specific use cases or applications, and it will not define new HTTP extension points, or new extensions that are likely to be implemented by Web browsers (based upon consultation with the HTTP WG). APIs for HTTP itself (e.g., in clients and servers) are also out of scope. > > New work items can be added after a Call for Adoption on the working group mailing list and consultation with the Area Director. > > To be successful, this Working Group will need to have active and broad representation from across the industry -- e.g., API gateway vendors (and other intermediaries), API consultants, API tool vendors, in-house API teams. Therefore, adopted proposals should have public support from multiple implementers and/or deployments before being sent to the IESG. > > This Working Group will need to coordinate closely with the HTTP Working Group. > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > -- Prof. Dr.sc. Martin J. Dürst Department of Intelligent Information Technology College of Science and Engineering Aoyama Gakuin University Fuchinobe 5-1-10, Chuo-ku, Sagamihara 252-5258 Japan From nobody Wed Aug 12 08:11:52 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A362E3A13D1 for ; Wed, 12 Aug 2020 08:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heY6ZotlPJ21 for ; Wed, 12 Aug 2020 08:11:49 -0700 (PDT) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 5B68D3A13CF for ; Wed, 12 Aug 2020 08:11:49 -0700 (PDT) Received: by mail-qv1-xf29.google.com with SMTP id o2so1164798qvk.6 for ; Wed, 12 Aug 2020 08:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HB6JIsnOjLHWtBADwjN3QcY1OaXtIYAdm8jtbNL5TBM=; b=e3tBpUbnB0nHO42z0K3TXlOm2UU0fTFVYlyfuVGzpQd81ENhOtoFdw5WxphVgN/e9n cy1GgnulCtbNV68RvQSpuhiWdByFMLw2K8hBp7vVJJMb+F0T58DTqatWVQWOn8+omo4s YlP/KlZT2O7EoCo1rYMPrzRLvUdVeIjcJevM3VAy2QlCZtvrySdtZfuO1LaxAB7RKiHq 5AmfTWrqjz1i8iYxsJK9/gdLsMW7PqoeNNNZUXHEeTvL62yCL9axYB+cUyUYmmbw/i7K 6RrJnaEMIR6k02j6ByvRPuPowBhBo7/UIPz2iNskvHZLnDE7NqmXT486gTqDGytl4md4 rz0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HB6JIsnOjLHWtBADwjN3QcY1OaXtIYAdm8jtbNL5TBM=; b=FB5un6z/BnlSJF8dN89CbzSKNnBDteUt9b7TlxIpu7nOfv7OT6Ah+okn4w/8sessxm 7rKtIr5i8XvRmm/pfitTv+kHeFDOSb+oyPyZje6IGEl9XREPIC9He4ATcURfUuxhk36B OiRePq5sW/QCHKwXpOuuCcYydNrenaVh/I+ckyEzRdKrrsCA7b7YFOb12vWmgL1tYRxL 6Gy9HHSNllb4bnUzpHRmFqLBDvxvZWztBHQDnxgICvpdP6XcuHgI1wrmc/H/HYPaL7Oo 02H39WeFEgOjeSR7RLUcX1NVUdes/QpMrg8uiV4rXqZt8oEZQOklAUX+UodDqDpe2dsU RFZw== X-Gm-Message-State: AOAM530lfC7X916C/OfDbXEN/IA2YlblvjNeAagGTbm/oH+d5I50U2hU o7Xow68yw0CvrgALx2NggDNpRcoEsZkRGUBgVbDmMg== X-Google-Smtp-Source: ABdhPJxfff1rdUVBskUGn92bY190knYNWAoaeMM4PIiR585WjcZnCYp3lecBMuHu3tGRnKnMl7WzaYoMyscmRivzlW0= X-Received: by 2002:a0c:fc07:: with SMTP id z7mr4805qvo.65.1597245108190; Wed, 12 Aug 2020 08:11:48 -0700 (PDT) MIME-Version: 1.0 References: <69181ed1-d72a-99de-8b4d-9e10276ced91@gmail.com> <771e108a9f25c1bec04d5fcdad58eb55bbb1533d.camel@ericsson.com> In-Reply-To: From: Richard Barnes Date: Wed, 12 Aug 2020 11:11:33 -0400 Message-ID: To: Alexandre GOUAILLARD Cc: Emad Omara , Magnus Westerlund , "ben@nostrum.com" , "dispatch@ietf.org" , "sergio.garcia.murillo@gmail.com" , "sframe@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004b16af05acaf9b2d" Archived-At: Subject: Re: [dispatch] [Sframe] SFRame Next Steps (was SFrame proposed WG charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 15:11:52 -0000 --0000000000004b16af05acaf9b2d Content-Type: text/plain; charset="UTF-8" Hey all, I agree that all of this stuff is valuable to capture somewhere. In the interest of keeping the charter fairly succinct, I've added the following: """ The SFrame specification will detail the specific security properties that the encapsulation provides, and discuss their implications under common usage scenarios / threat models. """ With that, I think that all the comments we've gotten so far have been addressed. --Richard On Fri, Aug 7, 2020 at 11:51 PM Alexandre GOUAILLARD < Alex.GOUAILLARD@cosmosoftware.io> wrote: > guys, > > sorry for jumping in so late, quarantine here is very strict. > > We had long discussions about this specific point ahead of the draft > submission. > We had reached the following consensus: > - there are multiple usage of media over the internet, e.g. conferencing > and streaming/broadcast > - they have very different threat/trust models, with different solutions > implemented today (transport layer E / E2EE / DRM / Encrypted Media > Extentions / ...) > - they all can benefit from SFrame > > PERC was, by design, limited to RTP and to Conferencing. Many other use > case coul benefit from Enhanced Privacy. > > We concluded that it would be better to keep SFrame (the media encryption > part, equivalent to PERC double conceptually), and to have separated > documents that describe the threat models and the corresponding key > exchange, signaling and system level decision for each use case. Emad had > taken an action item for example to make two additional documents to > describe the Video Conferencing use case, and how SFrame could be used in > conjunction with MLS to address that specific use case. Someone else could > take the different use case of the Browsers (which have a specific trust > model) and make a document showing how SFrame con work with Insertable > Frame API (and likely some more) to address that use case. CoSMo is > interested in doing the same thing for Real-Time streaming/Broadcasting. > > I think it is a more reasonable approach as, even spending a lot of time > brainstorming with everyone around the tabel including bernard, we couldn't > think about one solution to fit all the different "media over internet"'s > threat model. In my mind, each case should first have an informal document > to define scope and threat model, and subsequent document to define the > corresponding specifications. > - Secure Conferencing Threat model (emad and co.) > - Secure Conferencing Signalling using MLS (emad and co.) > - Secure Conferencing using MLS In the browser (contributed by w3c people) > > Magnus, what do you think? > > Regards, > > Dr. ALex. > > > > On Fri, Aug 7, 2020 at 2:02 AM Emad Omara 40google.com@dmarc.ietf.org> wrote: > >> Thanks Magnus. I like the idea to explicitly call out the threat model, I >> think it will be good foundations that control all future design decisions, >> however I'm not sure if the charter is the right place to call this out. >> I'd recommend having a separate document that describes the system >> architecture, goals and threat model. What do you think? >> >> Emad >> >> On Thu, Aug 6, 2020 at 1:56 AM Magnus Westerlund < >> magnus.westerlund@ericsson.com> wrote: >> >>> Hi, >>> >>> On Wed, 2020-08-05 at 22:15 +0200, Sergio Garcia Murillo wrote: >>> > But shouldn't the "delayed media" attack still be transport agnostic? >>> I >>> > mean, this can happen on QUIC and WebRTC SFUs. >>> >>> Sorry if I gave the impression that it is not transport agnostic. It is >>> use case >>> dependent, any use case that isn't point to point, where there is more >>> than one >>> entity that can intentionally remove SFRAME creating gaps in the SFRAME >>> sequence. In a point to point scenario one can correlate transport >>> losses with >>> SFRAME gaps to know give a reasonably strong mitigation against any >>> third party >>> removing SFRAMEs or delaying them. That is much harder in a centralized >>> conference with one or more SFU. >>> >>> > >>> > Anyway, I agree that while SFrame is transport agnostic, the chapter >>> > should not ignore the interactions with webrtc/quic and we must ensure >>> > that we provide a complete working solution regardless of the >>> transport. >>> > If we identify that any further working items are required for a >>> > particular transport, we should at liaise with the appropriate working >>> > group for providing a solution. >>> >>> My main point is that SFRAME actually needs to discuss the threat model >>> for the >>> use cases it intendes to solve. And the mitigation can potentially >>> include >>> functionality on the transport level. But the risks to media security in >>> centralized conferencing needs to be discussed. And centralized >>> conferencing >>> will still have the semi-trusted SFUs and all the rest of the third >>> parties in >>> addition to the end-points. >>> >>> Also what properties one have around end-points invited into the >>> conference has >>> a number of question around security properties that needs to be >>> discussed and >>> documented. Some examples that I know are relevant: >>> >>> - Source authentication: SRTP unless one use TESLA (which isn't really >>> used) >>> does only provided the property: Someone that has the key sent this. One >>> don't >>> know that it comes from a particular endpoint. >>> >>> - Confidentiality when group membership changes: So will SFRAME keying >>> support a >>> use case where only the current set of members in a conference can >>> decrypt the >>> media and one rekey the media session key for each time the membership >>> changes? >>> PERC do support this, will SFRAME? >>> >>> There are likely more questions that needs discussion. The PERC >>> discussion is a >>> good starting point, but I think when going transport agnostic some of >>> the >>> issues needs to be more clearly discussed as the RTP transport can have >>> affected >>> how it was discussed, and what reliance on existing mechanism. Which for >>> SFRAME >>> likely require a general discussion and then requirements on the >>> transport and >>> invovled endpoints and SFU to accomplish mitigations. And thus also what >>> the >>> risks are of having no mitigation in place. >>> >>> I would really propose that SFRAME is chartered with publishing a >>> security >>> consideration and threat model document that is seperate from the >>> solution to >>> give this topic full focus. The solution will of necessity need to >>> reference >>> that and document what migitagtions that exists in the SFRAME layer and >>> what >>> becomes requirements on the transport. >>> >>> Cheers >>> >>> Magnus Westerlund >>> >>> >>> ---------------------------------------------------------------------- >>> Networks, Ericsson Research >>> ---------------------------------------------------------------------- >>> Ericsson AB | Phone +46 10 7148287 >>> <+46%2010%20714%2082%2087> >>> Torshamnsgatan 23 | Mobile +46 73 0949079 >>> <+46%2073%20094%2090%2079> >>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>> ---------------------------------------------------------------------- >>> >>> >>> -- >> Sframe mailing list >> Sframe@ietf.org >> https://www.ietf.org/mailman/listinfo/sframe >> > --0000000000004b16af05acaf9b2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,

I agree that all of= this stuff is valuable to capture somewhere.=C2=A0 In the interest of keep= ing the charter fairly succinct, I've added the following:

"= ;""
The SFrame specification will detail the specific s= ecurity properties that the encapsulation provides, and discuss their impli= cations under common usage scenarios / threat models.
""= ;"

With that, I think that all the comments w= e've gotten so far have been addressed.

--Rich= ard


On Fri, Aug 7, 2020 at 11:51 PM Alexandre GOU= AILLARD <Alex.GOUAIL= LARD@cosmosoftware.io> wrote:
guys,

sorry for ju= mping in so late, quarantine here is very strict.

= We had long discussions about this specific point ahead of the draft submis= sion.
We had reached the following consensus:
- there a= re multiple usage of media over the internet, e.g. conferencing and streami= ng/broadcast
- they have very different threat/trust models, with= different solutions implemented today (transport layer E / E2EE / DRM / En= crypted Media Extentions / ...)
- they all can benefit from SFram= e

PERC was, by design, limited to RTP and to Confe= rencing. Many other use case coul benefit=C2=A0from Enhanced=C2=A0Privacy.<= /div>

We concluded that it would be better to keep SFram= e (the media encryption part, equivalent to PERC double conceptually), and = to have separated documents that=C2=A0describe the threat models and the co= rresponding key exchange,=C2=A0signaling=C2=A0and system level decision for= each use case. Emad had taken an action item for example to make two addit= ional=C2=A0documents to describe the Video Conferencing use case,=C2=A0and = how SFrame could be used in conjunction with MLS to address that specific u= se case. Someone else could take the different use case of the Browsers=C2= =A0(which have a specific trust model) and make a document showing how SFra= me con work with Insertable Frame API (and likely some more) to address tha= t use case. CoSMo is interested in doing the same thing for Real-Time strea= ming/Broadcasting.

I think it is a more reasonable= =C2=A0approach as, even spending a lot of time brainstorming with everyone = around the tabel including bernard, we couldn't think about one solutio= n to fit all the different "media over internet"'s threat mod= el. In my mind, each case should first have an informal document to define = scope and threat model, and subsequent document to define the corresponding= specifications.=C2=A0
- Secure Conferencing Threat model (emad a= nd co.)
- Secure Conferencing Signalling using MLS (emad and co.)=
- Secure Conferencing using MLS In the browser (contributed by w= 3c people)

Magnus, what do you think?
Regards,=C2=A0

Dr. ALex.


On Fri, Aug 7, 2020 at 2:02 AM Emad Omara <emadom= ara=3D40go= ogle.com@dmarc.ietf.org> wrote:
Thanks Magnus. I like the idea to e= xplicitly call out the threat model, I think it will be good foundations th= at control all future design decisions, however I'm not sure if the cha= rter is the right place to call this out. I'd recommend having a separa= te document that describes=C2=A0the system architecture, goals and threat m= odel. What do you think?

Emad

On Thu, Aug 6, 2020 = at 1:56 AM Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
=
Hi,

On Wed, 2020-08-05 at 22:15 +0200, Sergio Garcia Murillo wrote:
> But shouldn't the "delayed media" attack still be transp= ort agnostic? I
> mean, this can happen on QUIC and WebRTC SFUs.

Sorry if I gave the impression that it is not transport agnostic. It is use= case
dependent, any use case that isn't point to point, where there is more = than one
entity that can intentionally remove SFRAME creating gaps in the SFRAME
sequence. In a point to point scenario one can correlate transport losses w= ith
SFRAME gaps to know give a reasonably strong mitigation against any third p= arty
removing SFRAMEs or delaying them. That is much harder in a centralized
conference with one or more SFU.

>
> Anyway, I agree that while SFrame is transport agnostic, the chapter <= br> > should not ignore the interactions with webrtc/quic and we must ensure=
> that we provide a complete working solution regardless of the transpor= t.
> If we identify that any further working items are required for a
> particular transport, we should at liaise with the appropriate working=
> group for providing a solution.

My main point is that SFRAME actually needs to discuss the threat model for= the
use cases it intendes to solve. And the mitigation can potentially include<= br> functionality on the transport level. But the risks to media security in centralized conferencing needs to be discussed. And centralized conferencin= g
will still have the semi-trusted SFUs and all the rest of the third parties= in
addition to the end-points.

Also what properties one have around end-points invited into the conference= has
a number of question around security properties that needs to be discussed = and
documented. Some examples that I know are relevant:

- Source authentication: SRTP unless one use TESLA (which isn't really = used)
does only provided the property: Someone that has the key sent this. One do= n't
know that it comes from a particular endpoint.

- Confidentiality when group membership changes: So will SFRAME keying supp= ort a
use case where only the current set of members in a conference can decrypt = the
media and one rekey the media session key for each time the membership chan= ges?
PERC do support this, will SFRAME?

There are likely more questions that needs discussion. The PERC discussion = is a
good starting point, but I think when going transport agnostic some of the<= br> issues needs to be more clearly discussed as the RTP transport can have aff= ected
how it was discussed, and what reliance on existing mechanism. Which for SF= RAME
likely require a general discussion and then requirements on the transport = and
invovled endpoints and SFU to accomplish mitigations. And thus also what th= e
risks are of having no mitigation in place.

I would really propose that SFRAME is chartered with publishing a security<= br> consideration and threat model document that is seperate from the solution = to
give this topic full focus. The solution will of necessity need to referenc= e
that and document what migitagtions that exists in the SFRAME layer and wha= t
becomes requirements on the transport.

Cheers

Magnus Westerlund


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Mobile = +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--0000000000004b16af05acaf9b2d-- From nobody Wed Aug 12 16:30:39 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CE33A0D65 for ; Wed, 12 Aug 2020 16:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2_RRJFE-2Ee for ; Wed, 12 Aug 2020 16:30:36 -0700 (PDT) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 359B43A0D42 for ; Wed, 12 Aug 2020 16:30:36 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id r11so1804112pfl.11 for ; Wed, 12 Aug 2020 16:30:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:date:subject:message-id :to; bh=dUfTrE1nNQzHKHVqNkJqNPCKRZy7CLx6mO5q1BA41j0=; b=VP9781M1T8Fl4c+k9/6yaZMsyryBZepqtavmCrct++dJXJYGA1HJNeYxZMtvV1i9f9 Ltzz6dT1qUxJ1Mnxt70EhV3TdUeVFlZii9BVINagsEcL1hhmerZr7A24f2RHbinYpOIr 3O00vh/Ha1+/vZ2ppNnR1xnck7uQbv5pOQyCHcsCTpDYEAxWx6XE81AYXwZyrZ8vNmNM fd/gdMOaTdVVMp0siSjeUlyZjgguhuIF1DNuPSwj2usCnjQ955qXumyPDHYRyoWek8fX mQHmGIKsn3DTWuv5AjRIG7SjX+f5Ud3v8KDivVbYlk3uwpap+ZbXZYbXkrDYJcJM6WQG lf2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version:date :subject:message-id:to; bh=dUfTrE1nNQzHKHVqNkJqNPCKRZy7CLx6mO5q1BA41j0=; b=pDnMDk/Jk9cPzGFgMQf4WZG9ZXSN/2/Z7nHsNC+ruIs/92yA/j1/ssopKGNYWN/U7n XakXAGDz6d+C1oSiq8wAynkV4JZUwN+by8YVfhGnV4DK6gbSBpPWYD/qNdboK9Tuqsgd pjvTOyQS1y5avdr4RG6V2mtBxTSM3el1J4TMRREMK4dd3T3eqNegR3FKEBdaybN1w19v eYbl1b23dvXa/CmtsD9NSqB/C03/nMVkFdlbXprgLvI4Hczuh9cv5Y6sX2qnGq3+teGK 0AO9PPfCaX9ZdJCDjy4XUwlUWYYDAOh2fd6RPV7t+L/hzR35Ac84wbjghMEYLoH0+hSv P94Q== X-Gm-Message-State: AOAM530fnnighpJd6M1qw8Dx/lL3se7ajakNACNxU2wV7d9iq6s4/o53 UzlvefZrZdK8Xh5OpxVwcN0F2nOM X-Google-Smtp-Source: ABdhPJx1euVk5SB/IF/E1jFbeG0xNi99/DNho1oFQIN9QpBc6KEx68QLrswW7Vch0SYmUL3N3yneXA== X-Received: by 2002:a63:5a59:: with SMTP id k25mr1311307pgm.116.1597275034934; Wed, 12 Aug 2020 16:30:34 -0700 (PDT) Received: from ?IPv6:2600:380:7000:f7ab:1cf4:b8c1:dae4:9f1e? ([2600:380:7000:f7ab:1cf4:b8c1:dae4:9f1e]) by smtp.gmail.com with ESMTPSA id w9sm3288088pgg.76.2020.08.12.16.30.33 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Aug 2020 16:30:34 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-272F4EB4-8464-48DF-B245-2668E96474F6 Content-Transfer-Encoding: 7bit From: Bernard Aboba Mime-Version: 1.0 (1.0) Date: Wed, 12 Aug 2020 16:30:32 -0700 Message-Id: <1B05BA17-64CC-45FD-9217-7897F0E86B9D@gmail.com> To: dispatch@ietf.org X-Mailer: iPhone Mail (17G68) Archived-At: Subject: Re: [dispatch] SFrame WG Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 23:30:38 -0000 --Apple-Mail-272F4EB4-8464-48DF-B245-2668E96474F6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable """ The SFrame specification will detail the specific security properties that the encapsulation provides, and discuss their implications under common usage scenarios / threat models. """ [BA] This seems to be putting the cart before the horse. It is the combinati= on of SFrame, the negotiated ciphersuite and the key exchange mechanism that= provides a system whose security properties can be analyzed. So you can=E2=80= =99t just look at SFrame security properties. The point of RFC 7202 was that RTP usage scenarios require different securit= y solutions and therefore mandating a single mandatory key exchange mechanis= m does not make sense. Given the potential wide applicability of SFrame, the argument is even stron= ger here. So I agree with Dr. Alex that multiple use cases will need to be a= nalyzed. The RTC and streaming use cases could in particular generate quite d= ifferent requirements (e.g. need for DRM). Even within RTC use cases we will= need to separate out the requirements on the authentication system and medi= a protection given frequently cited concerns anout =E2=80=9Chidden participa= nts=E2=80=9D, =E2=80=9Cunauthorized recording=E2=80=9D and =E2=80=9Cdeep fak= es=E2=80=9D. Based on those analyses one can then look at the use case requirements and d= etail which ones are addressed by SFrame, the ciphersuites, underlying platf= orm security and potential key exchange mechanisms.=20 I am reminded of the importance of a thorough use case analysis as I talk to= customers and hear *very* different use cases, each of which a customer bel= ieves are solved by E2E security. Unfortunately the use cases differ in thei= r threat models, desired security properties and (probably) key exchange req= uirements. >> On Fri, Aug 7, 2020 at 11:51 PM Alexandre GOUAILLARD < >> Alex.GOUAILLARD@cosmosoftware.io> wrote: >>=20 >> guys, >>=20 >> sorry for jumping in so late, quarantine here is very strict. >>=20 >> We had long discussions about this specific point ahead of the draft >> submission. >> We had reached the following consensus: >> - there are multiple usage of media over the internet, e.g. conferencing >> and streaming/broadcast >> - they have very different threat/trust models, with different solutions >> implemented today (transport layer E / E2EE / DRM / Encrypted Media >> Extentions / ...) >> - they all can benefit from SFrame >>=20 >> PERC was, by design, limited to RTP and to Conferencing. Many other use >> case coul benefit from Enhanced Privacy. >>=20 >> We concluded that it would be better to keep SFrame (the media encryption= >> part, equivalent to PERC double conceptually), and to have separated >> documents that describe the threat models and the corresponding key >> exchange, signaling and system level decision for each use case. Emad had= >> taken an action item for example to make two additional documents to >> describe the Video Conferencing use case, and how SFrame could be used in= >> conjunction with MLS to address that specific use case. Someone else coul= d >> take the different use case of the Browsers (which have a specific trust >> model) and make a document showing how SFrame con work with Insertable >> Frame API (and likely some more) to address that use case. CoSMo is >> interested in doing the same thing for Real-Time streaming/Broadcasting. >>=20 >> I think it is a more reasonable approach as, even spending a lot of time >> brainstorming with everyone around the tabel including bernard, we couldn= 't >> think about one solution to fit all the different "media over internet"'s= >> threat model. In my mind, each case should first have an informal documen= t >> to define scope and threat model, and subsequent document to define the >> corresponding specifications. >> - Secure Conferencing Threat model (emad and co.) >> - Secure Conferencing Signalling using MLS (emad and co.) >> - Secure Conferencing using MLS In the browser (contributed by w3c people= ) >>=20 >> Magnus, what do you think? >>=20 >> Regards, >>=20 >> Dr. ALex. --Apple-Mail-272F4EB4-8464-48DF-B245-2668E96474F6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable 
"""
The SFrame specification will detail the specific security properties that
the encapsulation provides, and discuss their implications under common
usage scenarios / threat models.
"""
[BA] This s=
eems to be putting the cart before the horse. It is the combination of SFram=
e, the negotiated ciphersuite and the key exchange mechanism that provides a=
 system whose security properties can be analyzed. So you can=E2=80=99t just=
 look at SFrame security properties.
The point of RFC 7202 was that RTP usage scenarios re=
quire different security solutions and therefore mandating a single mandator=
y key exchange mechanism does not make sense.
Given the potential wide applicability of SFra=
me, the argument is even stronger here. So I agree with Dr. Alex that multip=
le use cases will need to be analyzed. The RTC and streaming use cases could=
 in particular generate quite different requirements (e.g. need for DRM). Ev=
en within RTC use cases we will need to separate out the requirements on the=
 authentication system and media protection given frequently cited concerns a=
nout =E2=80=9Chidden participants=E2=80=9D, =E2=80=9Cunauthorized recording=E2=
=80=9D and =E2=80=9Cdeep fakes=E2=80=9D.
Based on those analyses one can then look at the us=
e case requirements and detail which ones are addressed by SFrame, the ciphe=
rsuites, underlying platform security and potential key exchange mechanisms.=
 
I am reminde=
d of the importance of a thorough use case analysis as I talk to customers a=
nd hear *very* different use cases, each of which a customer believes are so=
lved by E2E security. Unfortunately the use cases differ in their threat mod=
els, desired security properties and (probably) key exchange requirements.

On Fri, Aug 7= , 2020 at 11:51 PM Alexandre GOUAILLARD <
Alex.GOUAILLARD= @cosmosoftware.io> wrote:

guys,

sorry for jumping in so= late, quarantine here is very strict.

We= had long discussions about this specific point ahead of the draft
submission.
We had reached the following consensus:=
- there are multiple= usage of media over the internet, e.g. conferencing
=
and streaming/broadcast
- they have very different threat/trust m= odels, with different solutions
implemented today (transport layer E / E2EE / DRM / Encrypted Med= ia
Extentions / ...)<= /span>
- they all can benefi= t from SFrame
=
PERC was, by design, limite= d to RTP and to Conferencing. Many other use
case coul benefit from Enhanced Privacy.
<= /blockquote>

We concluded that it would be better to keep SFrame (= the media encryption
= part, equivalent to PERC double conceptually), and to have separated<= br>
documents that describe the t= hreat models and the corresponding key
exchange, signaling and system level decision for each use= case. Emad had
taken= an action item for example to make two additional documents to
describe the Video Conferencing u= se case, and how SFrame could be used in
conjunction with MLS to address that specific use case. S= omeone else could
tak= e the different use case of the Browsers (which have a specific trust=
model) and make a document s= howing how SFrame con work with Insertable
Frame API (and likely some more) to address that use c= ase. CoSMo is
interes= ted in doing the same thing for Real-Time streaming/Broadcasting.
=

I think it is a more reasonable approach as, even s= pending a lot of time
brainstorming with everyone around the tabel including bernard, we couldn't=
think about one solu= tion to fit all the different "media over internet"'s
threat model. In my mind, each case should f= irst have an informal document
to define scope and threat model, and subsequent document to defin= e the
corresponding s= pecifications.
- Secu= re Conferencing Threat model (emad and co.)
- Secure Conferencing Signalling using MLS (emad and c= o.)
- Secure Conferen= cing using MLS In the browser (contributed by w3c people)

Magnus, what do you think?

Regards,
Dr. ALex.
=
= --Apple-Mail-272F4EB4-8464-48DF-B245-2668E96474F6-- From nobody Tue Aug 18 14:55:41 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893C13A0DD7; Tue, 18 Aug 2020 14:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.466 X-Spam-Level: X-Spam-Status: No, score=-1.466 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.212, MAY_BE_FORGED=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 b4Wyq54qpOZP; Tue, 18 Aug 2020 14:55:38 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 58C5E3A0DD6; Tue, 18 Aug 2020 14:55:38 -0700 (PDT) Received: from bens-macbook.lan (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 07ILtW6K016199 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 18 Aug 2020 16:55:33 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1597787734; bh=LpsXaGaT1l/2JUJnnN57ZVe+9AKF0J6v+yscdlFmEt4=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=YLa3u1QIOTMk7DNeMiEN5BYHdbcNm4r77TPYGLQr6It5x3UrDUfbW1ZFyP1NVrKqZ i+e49aSu84xnuvJtPcURiXsQvIVb6kdgX9zbcPbn/Jnt/mR3Camyfl9crIu8hI1Id9 kEc4P++ajCx+TPYq3p53zxVSjaV16rbjoov95eJY= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be bens-macbook.lan Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Ben Campbell In-Reply-To: Date: Tue, 18 Aug 2020 16:55:26 -0500 Cc: Patrick McManus , Richard Barnes , Emad Omara Content-Transfer-Encoding: quoted-printable Message-Id: <826A251D-B007-4A29-B4DA-C35BEB5A0D62@nostrum.com> References: To: Dispatch WG , ART ADs X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [dispatch] SFRame Next Steps (was Re: SFrame proposed WG charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 21:55:40 -0000 Hi Everyone, I have not seen any comments that suggest this should not proceed. = Therefore, we are dispatching the current proposed charter[1] to the ART = ADs to move things forward. There will be additional opportunities for = feedback during the IESG review process. [1] = https://docs.google.com/document/d/10rG8nAR0U6cBBPffzXnLaPPYL4uzxYViAvgiSe= zoa7o/edit?usp=3Dsharing Thanks! Ben. > On Jul 30, 2020, at 4:57 PM, Ben Campbell wrote: >=20 > Hi everyone, >=20 > We had a good discussion on SFrame in the dispatch meeting, and a lot = of interest in progressing it. The chairs would love it if we can get = some discussion of the proposed charter (below) now, while it=E2=80=99s = still fresh in people=E2=80=99s minds. If we don=E2=80=99t see feedback = to the contrary within a couple of weeks (let=E2=80=99s call that 14 = Aug), we will hand it over to the ART ADs. >=20 > Thanks! >=20 > Ben. >=20 >> On Jul 27, 2020, at 12:34 PM, Emad Omara = wrote: >>=20 >> Hi dispatch, >>=20 >> Following up on the discussion we had this morning in IETF 108 = dispatch session about SFrame, it seems there is enough interest to form = a focused WG for this work.=20 >>=20 >> Richard Barnes proposed this charter for the WG. Please take a look = and feel free to comment on the doc directly and propose other changes = as well. >>=20 >> Thanks >> Emad >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 From nobody Tue Aug 18 16:23:21 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC8A3A0F33; Tue, 18 Aug 2020 16:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkHvIXa-jdog; Tue, 18 Aug 2020 16:23:17 -0700 (PDT) Received: from mail-il1-f175.google.com (mail-il1-f175.google.com [209.85.166.175]) (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 A9CC63A0F30; Tue, 18 Aug 2020 16:23:17 -0700 (PDT) Received: by mail-il1-f175.google.com with SMTP id c6so19102452ilo.13; Tue, 18 Aug 2020 16:23:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sb87PeDmOnYu1XGv7U+QbcPVEZrgdu7JAe0NwGoJrT0=; b=IJn9f/I+3ge99Pw3hw7S4CP5XQMWYzkdiMRl9kZW++4sCkTN1cCNqYjgAwlqmKMCKM qHxAYoOUGuWLWueakHjB6CJ4GMGG/vpVIPpHTryyfpVxhmmGmNyMPXndS3dxJMG7qnEa NEm4JQJvgUo5LaJcO3LAHFbngeVUGPENbrvUi6wTldbSpIzQ4P9lz7lI17j6cuVRYVAY Jfj04paCZAqiAidPB+WMqovLUbzwQgKDH6V/PTTPEWybIHpsIqKZafJZiR0F3VDyDYTU WcueWNh1xCSVaht+CmapwRVZJhnWR7C+IVQjnw3RDL7UQcGMKeIaynX9i+lUPHTfopoQ gmog== X-Gm-Message-State: AOAM531fneag755C4mYhwX4v0mKewtbVeL+9X2tVktkIoZ7MOSt9gQGH 2JI473deJKWbjFBkDr6/SfF6zRfs2B4H+iLHNvs= X-Google-Smtp-Source: ABdhPJzQwo+PLuP7ZFMlBTeCb6NGUUbEeu5vJU9YbMFlMJQfjGoc3RAfDRXYlj+07rRN0f/aXTNhnL4SPi/NmNSVlyk= X-Received: by 2002:a92:418b:: with SMTP id o133mr18593258ila.277.1597792996563; Tue, 18 Aug 2020 16:23:16 -0700 (PDT) MIME-Version: 1.0 References: <826A251D-B007-4A29-B4DA-C35BEB5A0D62@nostrum.com> In-Reply-To: <826A251D-B007-4A29-B4DA-C35BEB5A0D62@nostrum.com> From: Barry Leiba Date: Tue, 18 Aug 2020 19:23:05 -0400 Message-ID: To: Ben Campbell Cc: ART ADs , Dispatch WG , Emad Omara , Patrick McManus , Richard Barnes Content-Type: multipart/alternative; boundary="000000000000fc210705ad2f2bcb" Archived-At: Subject: Re: [dispatch] SFRame Next Steps (was Re: SFrame proposed WG charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 23:23:20 -0000 --000000000000fc210705ad2f2bcb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I will put this into the datatracker and tag it for Murray; he=E2=80=99ll h= andle it when he returns from vay-cay. Barry On Tue, Aug 18, 2020 at 5:55 PM Ben Campbell wrote: > Hi Everyone, > > > > I have not seen any comments that suggest this should not proceed. > Therefore, we are dispatching the current proposed charter[1] to the ART > ADs to move things forward. There will be additional opportunities for > feedback during the IESG review process. > > > > [1] > https://docs.google.com/document/d/10rG8nAR0U6cBBPffzXnLaPPYL4uzxYViAvgiS= ezoa7o/edit?usp=3Dsharing > > > > Thanks! > > > > Ben. > > > > > On Jul 30, 2020, at 4:57 PM, Ben Campbell wrote: > > > > > > Hi everyone, > > > > > > We had a good discussion on SFrame in the dispatch meeting, and a lot o= f > interest in progressing it. The chairs would love it if we can get some > discussion of the proposed charter (below) now, while it=E2=80=99s still = fresh in > people=E2=80=99s minds. If we don=E2=80=99t see feedback to the contrary = within a couple of > weeks (let=E2=80=99s call that 14 Aug), we will hand it over to the ART A= Ds. > > > > > > Thanks! > > > > > > Ben. > > > > > >> On Jul 27, 2020, at 12:34 PM, Emad Omara 40google.com@dmarc.ietf.org> wrote: > > >> > > >> Hi dispatch, > > >> > > >> Following up on the discussion we had this morning in IETF 108 dispatc= h > session about SFrame, it seems there is enough interest to form a focused > WG for this work. > > >> > > >> Richard Barnes proposed this charter for the WG. Please take a look an= d > feel free to comment on the doc directly and propose other changes as wel= l. > > >> > > >> Thanks > > >> Emad > > >> _______________________________________________ > > >> dispatch mailing list > > >> dispatch@ietf.org > > >> https://www.ietf.org/mailman/listinfo/dispatch > > > > > > > --000000000000fc210705ad2f2bcb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I will put this into the datatracker and tag it for = Murray; he=E2=80=99ll handle it when he returns from vay-cay.

Barry

On Tue, Aug 18, 2020= at 5:55 PM Ben Campbell <ben@nostrum= .com> wrote:
Hi Everyone,


I have not seen any comments that suggest this should not proc= eed. Therefore, we are dispatching the current proposed charter[1] to the A= RT ADs to move things forward. There will be additional opportunities for f= eedback during the IESG review process.



[1] https://docs.googl= e.com/document/d/10rG8nAR0U6cBBPffzXnLaPPYL4uzxYViAvgiSezoa7o/edit?usp=3Dsh= aring



Thanks!



Ben.



> On= Jul 30, 2020, at 4:57 PM, Ben Campbell <ben@nostrum.com> wrote:

>

&g= t; Hi everyone,

>

> We had a good discussion on SFrame= in the dispatch meeting, and a lot of interest in progressing it. The chai= rs would love it if we can get some discussion of the proposed charter (bel= ow) now, while it=E2=80=99s still fresh in people=E2=80=99s minds. If we do= n=E2=80=99t see feedback to the contrary within a couple of weeks (let=E2= =80=99s call that 14 Aug), we will hand it over to the ART ADs.

>=

> Thanks!

>

> Ben.

>

>= ;> On Jul 27, 2020, at 12:34 PM, Emad Omara <emadomara=3D40google.com@dmarc.iet= f.org> wrote:

>>

>> Hi dispatch,

&= gt;>

>> Following up on the discussion we had this morning= in IETF 108 dispatch session about SFrame, it seems there is enough intere= st to form a focused WG for this work.

>>

>> Ri= chard Barnes proposed this charter for the WG. Please take a look and feel = free to comment on the doc directly and propose other changes as well.
<= br>>>

>> Thanks

>> Emad

>> __= _____________________________________________

>> dispatch mail= ing list

>> dispatch@ietf.org

>> https://www= .ietf.org/mailman/listinfo/dispatch

>



--000000000000fc210705ad2f2bcb-- From nobody Wed Aug 26 09:39:55 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D44873A1072; Wed, 26 Aug 2020 09:39:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159845999084.24987.16211185546146840126@ietfa.amsl.com> Date: Wed, 26 Aug 2020 09:39:50 -0700 Archived-At: Subject: [dispatch] New Version Notification - draft-hardie-dispatch-rfc3405-update-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 16:39:51 -0000 A new version (-03) has been submitted for draft-hardie-dispatch-rfc3405-update: https://www.ietf.org/internet-drafts/draft-hardie-dispatch-rfc3405-update-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-hardie-dispatch-rfc3405-update-03 Please note that it may take a couple of minutes from the time of submission until the diff is available at tools.ietf.org. IETF Secretariat. From nobody Thu Aug 27 11:43:18 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB76F3A07F9; Thu, 27 Aug 2020 11:43:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159855379534.1234.11339789433973689150@ietfa.amsl.com> Date: Thu, 27 Aug 2020 11:43:15 -0700 From: IETF Secretariat Archived-At: Subject: [dispatch] Datatracker State Update Notice: X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 18:43:16 -0000 IESG state changed: New State: AD Evaluation (The previous state was Publication Requested) Datatracker URL: https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ From nobody Thu Aug 27 11:44:06 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A523A0826; Thu, 27 Aug 2020 11:44:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159855384514.13957.10952144625991691057@ietfa.amsl.com> Date: Thu, 27 Aug 2020 11:44:05 -0700 From: IETF Secretariat Archived-At: Subject: [dispatch] Datatracker State Update Notice: X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 18:44:06 -0000 IESG state changed: New State: Last Call Requested (The previous state was AD Evaluation) Datatracker URL: https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ From nobody Thu Aug 27 11:44:11 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 188F23A11DD; Thu, 27 Aug 2020 11:44:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "DraftTracker Mail System" To: Cc: barryleiba@gmail.com, dispatch@ietf.org, spencerdawkins.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159855384608.13957.5462564798764434739@ietfa.amsl.com> Date: Thu, 27 Aug 2020 11:44:06 -0700 Archived-At: Subject: [dispatch] Last Call: X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 18:44:06 -0000 Last Call Request has been submitted for https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ From nobody Thu Aug 27 12:24:44 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C314D3A123B; Thu, 27 Aug 2020 12:24:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk CC: barryleiba@gmail.com, draft-hardie-dispatch-rfc3405-update@ietf.org, dispatch@ietf.org, spencerdawkins.ietf@gmail.com Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <159855628229.21847.10038855304956233232@ietfa.amsl.com> Date: Thu, 27 Aug 2020 12:24:42 -0700 Archived-At: Subject: [dispatch] Last Call: (Updated registration rules for URI.ARPA) to Best Current Practice X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 19:24:43 -0000 The IESG has received a request from an individual submitter to consider the following document: - 'Updated registration rules for URI.ARPA' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-09-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document updates RFC 3405 by removing references to the IETF tree from the procedures for requesting that a URI scheme be inserted into the uri.arpa zone. The file can be obtained via https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ No IPR declarations have been submitted directly on this I-D. From nobody Sat Aug 29 19:22:34 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C18703A131D; Sat, 29 Aug 2020 19:22:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159875413977.30454.265363319066638174@ietfa.amsl.com> Date: Sat, 29 Aug 2020 19:22:19 -0700 From: IETF Secretariat Archived-At: Subject: [dispatch] Datatracker State Update Notice: X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2020 02:22:20 -0000 State changed to Start Chartering/Rechartering (Internal Steering Group/IAB Review). Datatracker URL: https://datatracker.ietf.org/doc/charter-ietf-sframe/ From nobody Sun Aug 30 19:58:50 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 76AC93A0D3C; Sun, 30 Aug 2020 19:58:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: "The IESG" , , , X-Test-IDTracker: no X-IETF-IDTracker: 7.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159884272193.28763.2492110706571435177@ietfa.amsl.com> Date: Sun, 30 Aug 2020 19:58:42 -0700 From: IETF Secretariat Archived-At: Subject: [dispatch] Telechat update notice: X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 02:58:43 -0000 Placed on agenda for telechat - 2020-09-10 Datatracker URL: https://datatracker.ietf.org/doc/charter-ietf-sframe/ From nobody Mon Aug 31 07:06:18 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6833A13C0; Mon, 31 Aug 2020 07:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2O2to1y27iTm; Mon, 31 Aug 2020 07:06:15 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on0603.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::603]) (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 E3A193A13C5; Mon, 31 Aug 2020 07:06:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bUjcdGLKMhS1ybm07BJwPTlIm+dbNPW8oSAFHY4yWGEbcHB+XvDk/9rPoTJIfpUn2vQE7DbNuO/2kb/oZuF9qArkZghKu+ssp72urRrq1A68JhlUiMbjrzIjBix0OMkpIUDgcSBTJ6Zd2E7fXrnwnT8P4QX09v8kT3R2NyHR0mMAcHvwGDbXQifV/I7AMYcxtV2YIA5/44NpXhbg5gBJzjZzErcmkHYwyMwhVVu9Ca/N8NdBDV6vW3oI5DJrNwoaoxsi60maIJFUsvXz96WFpcuAzE2WyyDAjvyIHSYjFvKhPxdTDrNjuRDfbohU0hLTkSZ5BIPgDYWdhhNs6QKvYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Mxh++eJCYuw+Q1S0kTPlhMYBGRrDHNIOjsO9kq8OOzI=; b=h6ejl7NyQibMPajJADizRTndxV4E3EDBxovuVbtFJ+SMwS4CiVmVAMIll7hEyQ7YYk+MtkVCu5cXmYj1kPmEKIs7wBmNKQGy2neLlZU8kuItqm9ANomEaqiWmQ1tDVvOZUotCOVxfWkfvsjL5zWUEWWbsVdYO5rNITTX/Ya7j/+NmF9j9hyWTV+YXGguGtDHJGqMpc7Srl35VH3hrKCtne7d/Biqc63gHjVJNhArtgGi3H/QdQ49R56ji7rYCf5xojLjEyWR3a2OC+MRwomnQAsEJZDGyMd3BeFbg2rXSaPAi2LzE/5vHTsnjeB5sUfrWUpuC5ul3byCAG6fQdzzZw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=Mxh++eJCYuw+Q1S0kTPlhMYBGRrDHNIOjsO9kq8OOzI=; b=Utcou7MovFovwKsNmaYs2MjKETm4YDJGlgd3Cgna0bh9wkX+39tFries0STpRf2lIUI1YmgM1P9wpGF5etfOVBVTMUa9CC0nFA16rHcLg8HeJe9cLTbKeWEHTih8L0LmL1bBGZGTeRgslnnaLX7HXpp8t9BkQ61bGACuOH/whig= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR0701MB2684.eurprd07.prod.outlook.com (2603:10a6:3:8f::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.5; Mon, 31 Aug 2020 14:06:07 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::b56f:9a8e:3399:aaa3]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::b56f:9a8e:3399:aaa3%7]) with mapi id 15.20.3348.013; Mon, 31 Aug 2020 14:06:07 +0000 From: Magnus Westerlund To: "Alex.GOUAILLARD@cosmosoftware.io" , "rlb@ipv.sx" CC: "ben@nostrum.com" , "emadomara=40google.com@dmarc.ietf.org" , "dispatch@ietf.org" , "sframe@ietf.org" , "sergio.garcia.murillo@gmail.com" Thread-Topic: [Sframe] [dispatch] SFRame Next Steps (was SFrame proposed WG charter) Thread-Index: AQHWa2UvSRWiVT7MukOqMgZDT9IOv6kqyBeAgACYmgCAAjbMgIAHB3KAgB3KAwA= Date: Mon, 31 Aug 2020 14:06:07 +0000 Message-ID: References: <69181ed1-d72a-99de-8b4d-9e10276ced91@gmail.com> <771e108a9f25c1bec04d5fcdad58eb55bbb1533d.camel@ericsson.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2 authentication-results: cosmosoftware.io; dkim=none (message not signed) header.d=none;cosmosoftware.io; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.82] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c7ff1093-c580-449c-643b-08d84db701bd x-ms-traffictypediagnostic: HE1PR0701MB2684: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: y8Vgxonwb4D9UxfavlNPca0diwLzYeZeYFBWVeeePVafFCGriTFJWKrG96R1WAB0eOARWDb/UUwLF/6lcAv4ZmrWr1pfqO7eSAgXDf/nxDKjiSXrIJaVYTsy1db9wuIQSFMULvn1uuKKTCqwsgQWEwQiqY9OIh5nTTt/gqwn6B0Kw9PVTmhOZpupGhXFm20COPUxJGzsi5lymJEERcEWRxPfQ6AO28A2d1j4z0YH1rwIBjiLE3RYtT5MVeIdS14YRPa8pMWq6c2//tMPoBtMoYKwDMGHAW2XvGcuHAF44Nry7g6m3qPPlKlJ//RsVv0eRbipYZ0G4CXFC6QkZ7Vn/a3lgMS3HFBotYPQMMCpKo3RkBJv7hkjemeaf/9sMuqn x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(39860400002)(376002)(346002)(366004)(8676002)(2906002)(4326008)(6506007)(5660300002)(71200400001)(66574015)(8936002)(2616005)(26005)(66946007)(44832011)(54906003)(91956017)(76116006)(86362001)(83380400001)(110136005)(316002)(6486002)(186003)(53546011)(36756003)(66476007)(66446008)(66556008)(64756008)(478600001)(6512007)(99106002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: JJrrmyh8jI3FV/IWeLj06cWbCCJd8Ebo8KTKULhemlT7WjLFP2vwtDDJVIKyLjP6ZqBy4f2BTBx6ZLTmVGo0mEfSdd2zrZ4Qz48HIyoIOReERpxfsqynco3V/gV7gQVKKOPwVc7gptSZGw9T2oJzL1NWpzkGqA3o5bndYxuNDbfTnIatzVFYTyfp/PYzBoKPAnZYSAEUJd4JX4p+VfJT6XZZ7CmIyohSXg0Ub9wodE9s2BIVhzUWRvvbDnUe2I4nirEDEPVl4YBy1I62eD7NvT4vLMlp4Ma0KI7jMd8h56Od84SzFSxMjkyNew4CmrxmTGYHWouex19pizcjUnqy8tbPm3rikcLAWQYJde8W/rdsQ9yT9/M5a/bbWJIZo4OvmnFNwMPtXI/tmYO2H2pXyI5AWaARCU7nTDVp2qB30Lh3Xxtq7TpTyKqFHJjW0CkEj8c/1saJcksBlNEn/aMIoRAhX6zHemVWDroRK8DGLiVYanroCIjXstiICUcN82XASlje8OG24qglr/XGnnYdDGbj9rswibYlvO+ppQEaDulQ9pi5o1sPSWVgYDbe2x1raID1VERhJL0kyiuWHkHqiSRYXuSPXJYa7POZaisiyXyeaQayOEiWz4Dxw/RmeFMWT+oFEf9ohtmGVmTIEh/1WQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <5BAF39630585E24CB8FE8BCFF2975B67@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c7ff1093-c580-449c-643b-08d84db701bd X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2020 14:06:07.4919 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ka1oWKRDcEG482p1fYTHfI1dDw+mDKL+PxbzF6Gr5wkNgA+TyD3XfZ9pDn9S5okfyafpPxopBhtg8Io8/mMCG8bItL4FYxCYEKKM7pvVYXQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2684 Archived-At: Subject: Re: [dispatch] [Sframe] SFRame Next Steps (was SFrame proposed WG charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 14:06:17 -0000 SGksDQoNClRoYW5rcyBmb3Igd29ya2luZyBvbiBhZGRyZXNzaW5nIG15IGNvbW1lbnRzIHdoZW4g b24gdmFjYXRpb24uDQoNCkkgdGhpbmsgeW91IG1vc3RseSBhcnJhdmllZCBhdCBhIGdvb2QgcGxh Y2UuIEhvd2V2ZXIsIEkgd291bGQgbGlrZSB0byBtYWtlIG9uZQ0KcmVtYXJrIGFib3V0IHRoZSBh ZGRlZCBsYW5ndWFnZS4NCg0KV2hlbiBpdCBjb21lcyB0byB0aHJlYXQgbW9kZWxzIGl0IGNhbid0 IGJlIHRoZSBpbnRlcnNlY3Rpb24gb2YgdGhyZWF0cyBhY3Jvc3MNCnRob3NlIHRoYXQgb2NjdXIg aW4gdGhlIGludGVuZGVkIHVzYWdlcywgaXQgbmVlZHMgdG8gYmUgdGhlIHVuaW9uIG9mIHRocmVh dHMuDQpUaGUgZm9ybXVsYXRpb24gYWRkZWQgaW1wbGllcyBpbnRlcnNlY3Rpb24gdG8gbWUuIA0K DQpDaGVlcnMNCg0KTWFnbnVzDQoNCk9uIFdlZCwgMjAyMC0wOC0xMiBhdCAxMToxMSAtMDQwMCwg UmljaGFyZCBCYXJuZXMgd3JvdGU6DQo+IEhleSBhbGwsDQo+IA0KPiBJIGFncmVlIHRoYXQgYWxs IG9mIHRoaXMgc3R1ZmYgaXMgdmFsdWFibGUgdG8gY2FwdHVyZSBzb21ld2hlcmUuICBJbiB0aGUN Cj4gaW50ZXJlc3Qgb2Yga2VlcGluZyB0aGUgY2hhcnRlciBmYWlybHkgc3VjY2luY3QsIEkndmUg YWRkZWQgdGhlIGZvbGxvd2luZzoNCj4gDQo+ICIiIg0KPiBUaGUgU0ZyYW1lIHNwZWNpZmljYXRp b24gd2lsbCBkZXRhaWwgdGhlIHNwZWNpZmljIHNlY3VyaXR5IHByb3BlcnRpZXMgdGhhdCB0aGUN Cj4gZW5jYXBzdWxhdGlvbiBwcm92aWRlcywgYW5kIGRpc2N1c3MgdGhlaXIgaW1wbGljYXRpb25z IHVuZGVyIGNvbW1vbiB1c2FnZQ0KPiBzY2VuYXJpb3MgLyB0aHJlYXQgbW9kZWxzLg0KPiAiIiIN Cj4gDQo+IFdpdGggdGhhdCwgSSB0aGluayB0aGF0IGFsbCB0aGUgY29tbWVudHMgd2UndmUgZ290 dGVuIHNvIGZhciBoYXZlIGJlZW4NCj4gYWRkcmVzc2VkLg0KPiANCj4gLS1SaWNoYXJkDQo+IA0K PiANCj4gT24gRnJpLCBBdWcgNywgMjAyMCBhdCAxMTo1MSBQTSBBbGV4YW5kcmUgR09VQUlMTEFS RCA8DQo+IEFsZXguR09VQUlMTEFSREBjb3Ntb3NvZnR3YXJlLmlvPiB3cm90ZToNCj4gPiBndXlz LA0KPiA+IA0KPiA+IHNvcnJ5IGZvciBqdW1waW5nIGluIHNvIGxhdGUsIHF1YXJhbnRpbmUgaGVy ZSBpcyB2ZXJ5IHN0cmljdC4NCj4gPiANCj4gPiBXZSBoYWQgbG9uZyBkaXNjdXNzaW9ucyBhYm91 dCB0aGlzIHNwZWNpZmljIHBvaW50IGFoZWFkIG9mIHRoZSBkcmFmdA0KPiA+IHN1Ym1pc3Npb24u DQo+ID4gV2UgaGFkIHJlYWNoZWQgdGhlIGZvbGxvd2luZyBjb25zZW5zdXM6DQo+ID4gLSB0aGVy ZSBhcmUgbXVsdGlwbGUgdXNhZ2Ugb2YgbWVkaWEgb3ZlciB0aGUgaW50ZXJuZXQsIGUuZy4gY29u ZmVyZW5jaW5nIGFuZA0KPiA+IHN0cmVhbWluZy9icm9hZGNhc3QNCj4gPiAtIHRoZXkgaGF2ZSB2 ZXJ5IGRpZmZlcmVudCB0aHJlYXQvdHJ1c3QgbW9kZWxzLCB3aXRoIGRpZmZlcmVudCBzb2x1dGlv bnMNCj4gPiBpbXBsZW1lbnRlZCB0b2RheSAodHJhbnNwb3J0IGxheWVyIEUgLyBFMkVFIC8gRFJN IC8gRW5jcnlwdGVkIE1lZGlhDQo+ID4gRXh0ZW50aW9ucyAvIC4uLikNCj4gPiAtIHRoZXkgYWxs IGNhbiBiZW5lZml0IGZyb20gU0ZyYW1lDQo+ID4gDQo+ID4gUEVSQyB3YXMsIGJ5IGRlc2lnbiwg bGltaXRlZCB0byBSVFAgYW5kIHRvIENvbmZlcmVuY2luZy4gTWFueSBvdGhlciB1c2UgY2FzZQ0K PiA+IGNvdWwgYmVuZWZpdCBmcm9tIEVuaGFuY2VkIFByaXZhY3kuDQo+ID4gDQo+ID4gV2UgY29u Y2x1ZGVkIHRoYXQgaXQgd291bGQgYmUgYmV0dGVyIHRvIGtlZXAgU0ZyYW1lICh0aGUgbWVkaWEg ZW5jcnlwdGlvbg0KPiA+IHBhcnQsIGVxdWl2YWxlbnQgdG8gUEVSQyBkb3VibGUgY29uY2VwdHVh bGx5KSwgYW5kIHRvIGhhdmUgc2VwYXJhdGVkDQo+ID4gZG9jdW1lbnRzIHRoYXQgZGVzY3JpYmUg dGhlIHRocmVhdCBtb2RlbHMgYW5kIHRoZSBjb3JyZXNwb25kaW5nIGtleQ0KPiA+IGV4Y2hhbmdl LCBzaWduYWxpbmcgYW5kIHN5c3RlbSBsZXZlbCBkZWNpc2lvbiBmb3IgZWFjaCB1c2UgY2FzZS4g RW1hZCBoYWQNCj4gPiB0YWtlbiBhbiBhY3Rpb24gaXRlbSBmb3IgZXhhbXBsZSB0byBtYWtlIHR3 byBhZGRpdGlvbmFsIGRvY3VtZW50cyB0bw0KPiA+IGRlc2NyaWJlIHRoZSBWaWRlbyBDb25mZXJl bmNpbmcgdXNlIGNhc2UsIGFuZCBob3cgU0ZyYW1lIGNvdWxkIGJlIHVzZWQgaW4NCj4gPiBjb25q dW5jdGlvbiB3aXRoIE1MUyB0byBhZGRyZXNzIHRoYXQgc3BlY2lmaWMgdXNlIGNhc2UuIFNvbWVv bmUgZWxzZSBjb3VsZA0KPiA+IHRha2UgdGhlIGRpZmZlcmVudCB1c2UgY2FzZSBvZiB0aGUgQnJv d3NlcnMgKHdoaWNoIGhhdmUgYSBzcGVjaWZpYyB0cnVzdA0KPiA+IG1vZGVsKSBhbmQgbWFrZSBh IGRvY3VtZW50IHNob3dpbmcgaG93IFNGcmFtZSBjb24gd29yayB3aXRoIEluc2VydGFibGUgRnJh bWUNCj4gPiBBUEkgKGFuZCBsaWtlbHkgc29tZSBtb3JlKSB0byBhZGRyZXNzIHRoYXQgdXNlIGNh c2UuIENvU01vIGlzIGludGVyZXN0ZWQgaW4NCj4gPiBkb2luZyB0aGUgc2FtZSB0aGluZyBmb3Ig UmVhbC1UaW1lIHN0cmVhbWluZy9Ccm9hZGNhc3RpbmcuDQo+ID4gDQo+ID4gSSB0aGluayBpdCBp cyBhIG1vcmUgcmVhc29uYWJsZSBhcHByb2FjaCBhcywgZXZlbiBzcGVuZGluZyBhIGxvdCBvZiB0 aW1lDQo+ID4gYnJhaW5zdG9ybWluZyB3aXRoIGV2ZXJ5b25lIGFyb3VuZCB0aGUgdGFiZWwgaW5j bHVkaW5nIGJlcm5hcmQsIHdlIGNvdWxkbid0DQo+ID4gdGhpbmsgYWJvdXQgb25lIHNvbHV0aW9u IHRvIGZpdCBhbGwgdGhlIGRpZmZlcmVudCAibWVkaWEgb3ZlciBpbnRlcm5ldCIncw0KPiA+IHRo cmVhdCBtb2RlbC4gSW4gbXkgbWluZCwgZWFjaCBjYXNlIHNob3VsZCBmaXJzdCBoYXZlIGFuIGlu Zm9ybWFsIGRvY3VtZW50DQo+ID4gdG8gZGVmaW5lIHNjb3BlIGFuZCB0aHJlYXQgbW9kZWwsIGFu ZCBzdWJzZXF1ZW50IGRvY3VtZW50IHRvIGRlZmluZSB0aGUNCj4gPiBjb3JyZXNwb25kaW5nIHNw ZWNpZmljYXRpb25zLiANCj4gPiAtIFNlY3VyZSBDb25mZXJlbmNpbmcgVGhyZWF0IG1vZGVsIChl bWFkIGFuZCBjby4pDQo+ID4gLSBTZWN1cmUgQ29uZmVyZW5jaW5nIFNpZ25hbGxpbmcgdXNpbmcg TUxTIChlbWFkIGFuZCBjby4pDQo+ID4gLSBTZWN1cmUgQ29uZmVyZW5jaW5nIHVzaW5nIE1MUyBJ biB0aGUgYnJvd3NlciAoY29udHJpYnV0ZWQgYnkgdzNjIHBlb3BsZSkNCj4gPiANCj4gPiBNYWdu dXMsIHdoYXQgZG8geW91IHRoaW5rPw0KPiA+IA0KPiA+IFJlZ2FyZHMsIA0KPiA+IA0KPiA+IERy LiBBTGV4Lg0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IE9uIEZyaSwgQXVnIDcsIDIwMjAgYXQgMjow MiBBTSBFbWFkIE9tYXJhIDwNCj4gPiBlbWFkb21hcmE9NDBnb29nbGUuY29tQGRtYXJjLmlldGYu b3JnPiB3cm90ZToNCj4gPiA+IFRoYW5rcyBNYWdudXMuIEkgbGlrZSB0aGUgaWRlYSB0byBleHBs aWNpdGx5IGNhbGwgb3V0IHRoZSB0aHJlYXQgbW9kZWwsIEkNCj4gPiA+IHRoaW5rIGl0IHdpbGwg YmUgZ29vZCBmb3VuZGF0aW9ucyB0aGF0IGNvbnRyb2wgYWxsIGZ1dHVyZSBkZXNpZ24NCj4gPiA+ IGRlY2lzaW9ucywgaG93ZXZlciBJJ20gbm90IHN1cmUgaWYgdGhlIGNoYXJ0ZXIgaXMgdGhlIHJp Z2h0IHBsYWNlIHRvIGNhbGwNCj4gPiA+IHRoaXMgb3V0LiBJJ2QgcmVjb21tZW5kIGhhdmluZyBh IHNlcGFyYXRlIGRvY3VtZW50IHRoYXQgZGVzY3JpYmVzIHRoZQ0KPiA+ID4gc3lzdGVtIGFyY2hp dGVjdHVyZSwgZ29hbHMgYW5kIHRocmVhdCBtb2RlbC4gV2hhdCBkbyB5b3UgdGhpbms/DQo+ID4g PiANCj4gPiA+IEVtYWQNCj4gPiA+IA0KPiA+ID4gT24gVGh1LCBBdWcgNiwgMjAyMCBhdCAxOjU2 IEFNIE1hZ251cyBXZXN0ZXJsdW5kIDwNCj4gPiA+IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29u LmNvbT4gd3JvdGU6DQo+ID4gPiA+IEhpLA0KPiA+ID4gPiANCj4gPiA+ID4gT24gV2VkLCAyMDIw LTA4LTA1IGF0IDIyOjE1ICswMjAwLCBTZXJnaW8gR2FyY2lhIE11cmlsbG8gd3JvdGU6DQo+ID4g PiA+ID4gQnV0IHNob3VsZG4ndCB0aGUgImRlbGF5ZWQgbWVkaWEiIGF0dGFjayBzdGlsbCBiZSB0 cmFuc3BvcnQgYWdub3N0aWM/DQo+ID4gPiA+IEkgDQo+ID4gPiA+ID4gbWVhbiwgdGhpcyBjYW4g aGFwcGVuIG9uIFFVSUMgYW5kIFdlYlJUQyBTRlVzLg0KPiA+ID4gPiANCj4gPiA+ID4gU29ycnkg aWYgSSBnYXZlIHRoZSBpbXByZXNzaW9uIHRoYXQgaXQgaXMgbm90IHRyYW5zcG9ydCBhZ25vc3Rp Yy4gSXQgaXMNCj4gPiA+ID4gdXNlIGNhc2UNCj4gPiA+ID4gZGVwZW5kZW50LCBhbnkgdXNlIGNh c2UgdGhhdCBpc24ndCBwb2ludCB0byBwb2ludCwgd2hlcmUgdGhlcmUgaXMgbW9yZQ0KPiA+ID4g PiB0aGFuIG9uZQ0KPiA+ID4gPiBlbnRpdHkgdGhhdCBjYW4gaW50ZW50aW9uYWxseSByZW1vdmUg U0ZSQU1FIGNyZWF0aW5nIGdhcHMgaW4gdGhlIFNGUkFNRQ0KPiA+ID4gPiBzZXF1ZW5jZS4gSW4g YSBwb2ludCB0byBwb2ludCBzY2VuYXJpbyBvbmUgY2FuIGNvcnJlbGF0ZSB0cmFuc3BvcnQNCj4g PiA+ID4gbG9zc2VzIHdpdGgNCj4gPiA+ID4gU0ZSQU1FIGdhcHMgdG8ga25vdyBnaXZlIGEgcmVh c29uYWJseSBzdHJvbmcgbWl0aWdhdGlvbiBhZ2FpbnN0IGFueQ0KPiA+ID4gPiB0aGlyZCBwYXJ0 eQ0KPiA+ID4gPiByZW1vdmluZyBTRlJBTUVzIG9yIGRlbGF5aW5nIHRoZW0uIFRoYXQgaXMgbXVj aCBoYXJkZXIgaW4gYSBjZW50cmFsaXplZA0KPiA+ID4gPiBjb25mZXJlbmNlIHdpdGggb25lIG9y IG1vcmUgU0ZVLg0KPiA+ID4gPiANCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBBbnl3YXksIEkgYWdy ZWUgdGhhdCB3aGlsZSBTRnJhbWUgaXMgdHJhbnNwb3J0IGFnbm9zdGljLCB0aGUgY2hhcHRlciAN Cj4gPiA+ID4gPiBzaG91bGQgbm90IGlnbm9yZSB0aGUgaW50ZXJhY3Rpb25zIHdpdGggd2VicnRj L3F1aWMgYW5kIHdlIG11c3QNCj4gPiA+ID4gZW5zdXJlIA0KPiA+ID4gPiA+IHRoYXQgd2UgcHJv dmlkZSBhIGNvbXBsZXRlIHdvcmtpbmcgc29sdXRpb24gcmVnYXJkbGVzcyBvZiB0aGUNCj4gPiA+ ID4gdHJhbnNwb3J0LiANCj4gPiA+ID4gPiBJZiB3ZSBpZGVudGlmeSB0aGF0IGFueSBmdXJ0aGVy IHdvcmtpbmcgaXRlbXMgYXJlIHJlcXVpcmVkIGZvciBhIA0KPiA+ID4gPiA+IHBhcnRpY3VsYXIg dHJhbnNwb3J0LCB3ZSBzaG91bGQgYXQgbGlhaXNlIHdpdGggdGhlIGFwcHJvcHJpYXRlDQo+ID4g PiA+IHdvcmtpbmcgDQo+ID4gPiA+ID4gZ3JvdXAgZm9yIHByb3ZpZGluZyBhIHNvbHV0aW9uLg0K PiA+ID4gPiANCj4gPiA+ID4gTXkgbWFpbiBwb2ludCBpcyB0aGF0IFNGUkFNRSBhY3R1YWxseSBu ZWVkcyB0byBkaXNjdXNzIHRoZSB0aHJlYXQgbW9kZWwNCj4gPiA+ID4gZm9yIHRoZQ0KPiA+ID4g PiB1c2UgY2FzZXMgaXQgaW50ZW5kZXMgdG8gc29sdmUuIEFuZCB0aGUgbWl0aWdhdGlvbiBjYW4g cG90ZW50aWFsbHkNCj4gPiA+ID4gaW5jbHVkZQ0KPiA+ID4gPiBmdW5jdGlvbmFsaXR5IG9uIHRo ZSB0cmFuc3BvcnQgbGV2ZWwuIEJ1dCB0aGUgcmlza3MgdG8gbWVkaWEgc2VjdXJpdHkgaW4NCj4g PiA+ID4gY2VudHJhbGl6ZWQgY29uZmVyZW5jaW5nIG5lZWRzIHRvIGJlIGRpc2N1c3NlZC4gQW5k IGNlbnRyYWxpemVkDQo+ID4gPiA+IGNvbmZlcmVuY2luZw0KPiA+ID4gPiB3aWxsIHN0aWxsIGhh dmUgdGhlIHNlbWktdHJ1c3RlZCBTRlVzIGFuZCBhbGwgdGhlIHJlc3Qgb2YgdGhlIHRoaXJkDQo+ ID4gPiA+IHBhcnRpZXMgaW4NCj4gPiA+ID4gYWRkaXRpb24gdG8gdGhlIGVuZC1wb2ludHMuIA0K PiA+ID4gPiANCj4gPiA+ID4gQWxzbyB3aGF0IHByb3BlcnRpZXMgb25lIGhhdmUgYXJvdW5kIGVu ZC1wb2ludHMgaW52aXRlZCBpbnRvIHRoZQ0KPiA+ID4gPiBjb25mZXJlbmNlIGhhcw0KPiA+ID4g PiBhIG51bWJlciBvZiBxdWVzdGlvbiBhcm91bmQgc2VjdXJpdHkgcHJvcGVydGllcyB0aGF0IG5l ZWRzIHRvIGJlDQo+ID4gPiA+IGRpc2N1c3NlZCBhbmQNCj4gPiA+ID4gZG9jdW1lbnRlZC4gU29t ZSBleGFtcGxlcyB0aGF0IEkga25vdyBhcmUgcmVsZXZhbnQ6DQo+ID4gPiA+IA0KPiA+ID4gPiAt IFNvdXJjZSBhdXRoZW50aWNhdGlvbjogU1JUUCB1bmxlc3Mgb25lIHVzZSBURVNMQSAod2hpY2gg aXNuJ3QgcmVhbGx5DQo+ID4gPiA+IHVzZWQpDQo+ID4gPiA+IGRvZXMgb25seSBwcm92aWRlZCB0 aGUgcHJvcGVydHk6IFNvbWVvbmUgdGhhdCBoYXMgdGhlIGtleSBzZW50IHRoaXMuIE9uZQ0KPiA+ ID4gPiBkb24ndA0KPiA+ID4gPiBrbm93IHRoYXQgaXQgY29tZXMgZnJvbSBhIHBhcnRpY3VsYXIg ZW5kcG9pbnQuIA0KPiA+ID4gPiANCj4gPiA+ID4gLSBDb25maWRlbnRpYWxpdHkgd2hlbiBncm91 cCBtZW1iZXJzaGlwIGNoYW5nZXM6IFNvIHdpbGwgU0ZSQU1FIGtleWluZw0KPiA+ID4gPiBzdXBw b3J0IGENCj4gPiA+ID4gdXNlIGNhc2Ugd2hlcmUgb25seSB0aGUgY3VycmVudCBzZXQgb2YgbWVt YmVycyBpbiBhIGNvbmZlcmVuY2UgY2FuDQo+ID4gPiA+IGRlY3J5cHQgdGhlDQo+ID4gPiA+IG1l ZGlhIGFuZCBvbmUgcmVrZXkgdGhlIG1lZGlhIHNlc3Npb24ga2V5IGZvciBlYWNoIHRpbWUgdGhl IG1lbWJlcnNoaXANCj4gPiA+ID4gY2hhbmdlcz8NCj4gPiA+ID4gUEVSQyBkbyBzdXBwb3J0IHRo aXMsIHdpbGwgU0ZSQU1FPyANCj4gPiA+ID4gDQo+ID4gPiA+IFRoZXJlIGFyZSBsaWtlbHkgbW9y ZSBxdWVzdGlvbnMgdGhhdCBuZWVkcyBkaXNjdXNzaW9uLiBUaGUgUEVSQw0KPiA+ID4gPiBkaXNj dXNzaW9uIGlzIGENCj4gPiA+ID4gZ29vZCBzdGFydGluZyBwb2ludCwgYnV0IEkgdGhpbmsgd2hl biBnb2luZyB0cmFuc3BvcnQgYWdub3N0aWMgc29tZSBvZg0KPiA+ID4gPiB0aGUNCj4gPiA+ID4g aXNzdWVzIG5lZWRzIHRvIGJlIG1vcmUgY2xlYXJseSBkaXNjdXNzZWQgYXMgdGhlIFJUUCB0cmFu c3BvcnQgY2FuIGhhdmUNCj4gPiA+ID4gYWZmZWN0ZWQNCj4gPiA+ID4gaG93IGl0IHdhcyBkaXNj dXNzZWQsIGFuZCB3aGF0IHJlbGlhbmNlIG9uIGV4aXN0aW5nIG1lY2hhbmlzbS4gV2hpY2ggZm9y DQo+ID4gPiA+IFNGUkFNRQ0KPiA+ID4gPiBsaWtlbHkgcmVxdWlyZSBhIGdlbmVyYWwgZGlzY3Vz c2lvbiBhbmQgdGhlbiByZXF1aXJlbWVudHMgb24gdGhlDQo+ID4gPiA+IHRyYW5zcG9ydCBhbmQN Cj4gPiA+ID4gaW52b3ZsZWQgZW5kcG9pbnRzIGFuZCBTRlUgdG8gYWNjb21wbGlzaCBtaXRpZ2F0 aW9ucy4gQW5kIHRodXMgYWxzbyB3aGF0DQo+ID4gPiA+IHRoZQ0KPiA+ID4gPiByaXNrcyBhcmUg b2YgaGF2aW5nIG5vIG1pdGlnYXRpb24gaW4gcGxhY2UuIA0KPiA+ID4gPiANCj4gPiA+ID4gSSB3 b3VsZCByZWFsbHkgcHJvcG9zZSB0aGF0IFNGUkFNRSBpcyBjaGFydGVyZWQgd2l0aCBwdWJsaXNo aW5nIGENCj4gPiA+ID4gc2VjdXJpdHkNCj4gPiA+ID4gY29uc2lkZXJhdGlvbiBhbmQgdGhyZWF0 IG1vZGVsIGRvY3VtZW50IHRoYXQgaXMgc2VwZXJhdGUgZnJvbSB0aGUNCj4gPiA+ID4gc29sdXRp b24gdG8NCj4gPiA+ID4gZ2l2ZSB0aGlzIHRvcGljIGZ1bGwgZm9jdXMuIFRoZSBzb2x1dGlvbiB3 aWxsIG9mIG5lY2Vzc2l0eSBuZWVkIHRvDQo+ID4gPiA+IHJlZmVyZW5jZQ0KPiA+ID4gPiB0aGF0 IGFuZCBkb2N1bWVudCB3aGF0IG1pZ2l0YWd0aW9ucyB0aGF0IGV4aXN0cyBpbiB0aGUgU0ZSQU1F IGxheWVyIGFuZA0KPiA+ID4gPiB3aGF0DQo+ID4gPiA+IGJlY29tZXMgcmVxdWlyZW1lbnRzIG9u IHRoZSB0cmFuc3BvcnQuIA0KPiA+ID4gPiANCj4gPiA+ID4gQ2hlZXJzDQo+ID4gPiA+IA0KPiA+ ID4gPiBNYWdudXMgV2VzdGVybHVuZCANCj4gPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+ID4gPiA+IE5ldHdvcmtzLCBFcmljc3NvbiBSZXNlYXJjaA0KPiA+ID4gPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+ID4gPiA+IEVyaWNzc29uIEFCICAgICAgICAgICAgICAgICB8IFBob25l ICArNDYgMTAgNzE0ODI4Nw0KPiA+ID4gPiBUb3JzaGFtbnNnYXRhbiAyMyAgICAgICAgICAgfCBN b2JpbGUgKzQ2IDczIDA5NDkwNzkNCj4gPiA+ID4gU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVu IHwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCj4gPiA+ID4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiA+ID4gPiANCj4gPiA+ID4gDQotLSANCkNoZWVycw0KDQpNYWdudXMgV2VzdGVy bHVuZCANCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpOZXR3b3JrcywgRXJpY3Nzb24gUmVzZWFyY2gNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCkVyaWNzc29uIEFCICAgICAgICAgICAgICAgICB8IFBob25lICArNDYgMTAg NzE0ODI4Nw0KVG9yc2hhbW5zZ2F0YW4gMjMgICAgICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5 MDc5DQpTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW4gfCBtYWlsdG86IG1hZ251cy53ZXN0ZXJs dW5kQGVyaWNzc29uLmNvbQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg== From nobody Mon Aug 31 08:40:55 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63C73A161F for ; Mon, 31 Aug 2020 08:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHE7QkYCunJ6 for ; Mon, 31 Aug 2020 08:40:40 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 811193A1618 for ; Mon, 31 Aug 2020 08:40:38 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id f2so3921305qkh.3 for ; Mon, 31 Aug 2020 08:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rAE6OwkwC75tsYTi9hxQQavng3YWDDaQpR0yCqymdH0=; b=MjQGQCMP6IGtlkns9CKsneCTx6tbvpN0011wkCPQ2uaKoRVpk757OwhiNwUvwDdpf+ M9DxbM+cWRFIPufrwLbmSOiapi5cV1DQkKD2kFLyf1n80lD9Nmw8yvuRPIZ1cqF6DHdw Gcoju18JMOCM2FM7Ud/0eZ2/oeYMjRPvp0Z2/0a9TryRFAkvGUgTc03ytfQt6iCf2Tui CUFsBKQzDVERD/muPZ14SXHOnx+zHkhycTzym9vzbHBwsAxAsw16qxuvMoXAyGFyAHQ8 ddmJlhqgy8CKwswaqd8F08it3KoiU9zCPaful9unh/7IV2oBxk//7hdfP/jmx2ayldgl EHQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rAE6OwkwC75tsYTi9hxQQavng3YWDDaQpR0yCqymdH0=; b=haGDF13sYqdtRByvM2fICUoAwE6Adp82tgGmHg7tdlXPAy3cIqffm7VzB8z4FRgKKE W2ialazb5xXAUZPBm1PVLEByTrTa0PHx5E/qE0LlG8OF2w/AKCuXnI5sGug5N3r728Vq 7GS0edPzgwEmEeNuNiakAWKfFfVamiNBwXrAxKhmhcqJtTWyDYBAJ1doTgNI7kNO5PqY A07TGRyjMFd3UU+p/1wJxWaOh7tc9/fp3efH6eaDODvT2B/RNwQ9i77ksa57ClBO7xBl AOgy+0zt+FKivxx0HXDagFEJgzFZ7QTrmjXmeF7KBFMVFHenuN0UQ6MsGZwL0vVqVnPg 1/kQ== X-Gm-Message-State: AOAM532Nj4yRN86MxkKSsmYdcZhzd2xQUQ3yfiuwNgeZTNhe+pVHTSdx 9YoHD5CrwMtCoK8owvZfj6JCkA7b7Mgcs/Rez5DwwQ== X-Google-Smtp-Source: ABdhPJyv7bKwL8Rg908LpkNcs4Ufpoh88Q7un5O9Vj5CDpGm6xfqCMTLjTpqlo52PiZOU1DTV4ZaSwQHnsIqeMjYW3s= X-Received: by 2002:a05:620a:125b:: with SMTP id a27mr1952520qkl.371.1598888437288; Mon, 31 Aug 2020 08:40:37 -0700 (PDT) MIME-Version: 1.0 References: <69181ed1-d72a-99de-8b4d-9e10276ced91@gmail.com> <771e108a9f25c1bec04d5fcdad58eb55bbb1533d.camel@ericsson.com> In-Reply-To: From: Richard Barnes Date: Mon, 31 Aug 2020 11:40:09 -0400 Message-ID: To: Magnus Westerlund Cc: "Alex.GOUAILLARD@cosmosoftware.io" , "ben@nostrum.com" , "emadomara=40google.com@dmarc.ietf.org" , "dispatch@ietf.org" , "sframe@ietf.org" , "sergio.garcia.murillo@gmail.com" Content-Type: multipart/alternative; boundary="00000000000057254505ae2e3930" Archived-At: Subject: Re: [dispatch] [Sframe] SFRame Next Steps (was SFrame proposed WG charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 15:40:50 -0000 --00000000000057254505ae2e3930 Content-Type: text/plain; charset="UTF-8" Hi Magnus, I think the intent here is to have a mechanism that provides a subset of the security properties required for a given scenario, but which can be augmented with additional mechanisms to provide the rest. For example, even in the most obvious SFrame+SRTP case, there's a division of labor between the two protocols, where SFrame only protects content, and SRTP also protects the RTP header and guards against reply by network attackers. So in a sense it is an intersection (in that it does something that is needed by all the use cases), but it might need other things to provide all the properties you need in a given scenario. --Richard On Mon, Aug 31, 2020 at 10:06 AM Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > Thanks for working on addressing my comments when on vacation. > > I think you mostly arravied at a good place. However, I would like to make > one > remark about the added language. > > When it comes to threat models it can't be the intersection of threats > across > those that occur in the intended usages, it needs to be the union of > threats. > The formulation added implies intersection to me. > > Cheers > > Magnus > > On Wed, 2020-08-12 at 11:11 -0400, Richard Barnes wrote: > > Hey all, > > > > I agree that all of this stuff is valuable to capture somewhere. In the > > interest of keeping the charter fairly succinct, I've added the > following: > > > > """ > > The SFrame specification will detail the specific security properties > that the > > encapsulation provides, and discuss their implications under common usage > > scenarios / threat models. > > """ > > > > With that, I think that all the comments we've gotten so far have been > > addressed. > > > > --Richard > > > > > > On Fri, Aug 7, 2020 at 11:51 PM Alexandre GOUAILLARD < > > Alex.GOUAILLARD@cosmosoftware.io> wrote: > > > guys, > > > > > > sorry for jumping in so late, quarantine here is very strict. > > > > > > We had long discussions about this specific point ahead of the draft > > > submission. > > > We had reached the following consensus: > > > - there are multiple usage of media over the internet, e.g. > conferencing and > > > streaming/broadcast > > > - they have very different threat/trust models, with different > solutions > > > implemented today (transport layer E / E2EE / DRM / Encrypted Media > > > Extentions / ...) > > > - they all can benefit from SFrame > > > > > > PERC was, by design, limited to RTP and to Conferencing. Many other > use case > > > coul benefit from Enhanced Privacy. > > > > > > We concluded that it would be better to keep SFrame (the media > encryption > > > part, equivalent to PERC double conceptually), and to have separated > > > documents that describe the threat models and the corresponding key > > > exchange, signaling and system level decision for each use case. Emad > had > > > taken an action item for example to make two additional documents to > > > describe the Video Conferencing use case, and how SFrame could be used > in > > > conjunction with MLS to address that specific use case. Someone else > could > > > take the different use case of the Browsers (which have a specific > trust > > > model) and make a document showing how SFrame con work with Insertable > Frame > > > API (and likely some more) to address that use case. CoSMo is > interested in > > > doing the same thing for Real-Time streaming/Broadcasting. > > > > > > I think it is a more reasonable approach as, even spending a lot of > time > > > brainstorming with everyone around the tabel including bernard, we > couldn't > > > think about one solution to fit all the different "media over > internet"'s > > > threat model. In my mind, each case should first have an informal > document > > > to define scope and threat model, and subsequent document to define the > > > corresponding specifications. > > > - Secure Conferencing Threat model (emad and co.) > > > - Secure Conferencing Signalling using MLS (emad and co.) > > > - Secure Conferencing using MLS In the browser (contributed by w3c > people) > > > > > > Magnus, what do you think? > > > > > > Regards, > > > > > > Dr. ALex. > > > > > > > > > > > > On Fri, Aug 7, 2020 at 2:02 AM Emad Omara < > > > emadomara=40google.com@dmarc.ietf.org> wrote: > > > > Thanks Magnus. I like the idea to explicitly call out the threat > model, I > > > > think it will be good foundations that control all future design > > > > decisions, however I'm not sure if the charter is the right place to > call > > > > this out. I'd recommend having a separate document that describes the > > > > system architecture, goals and threat model. What do you think? > > > > > > > > Emad > > > > > > > > On Thu, Aug 6, 2020 at 1:56 AM Magnus Westerlund < > > > > magnus.westerlund@ericsson.com> wrote: > > > > > Hi, > > > > > > > > > > On Wed, 2020-08-05 at 22:15 +0200, Sergio Garcia Murillo wrote: > > > > > > But shouldn't the "delayed media" attack still be transport > agnostic? > > > > > I > > > > > > mean, this can happen on QUIC and WebRTC SFUs. > > > > > > > > > > Sorry if I gave the impression that it is not transport agnostic. > It is > > > > > use case > > > > > dependent, any use case that isn't point to point, where there is > more > > > > > than one > > > > > entity that can intentionally remove SFRAME creating gaps in the > SFRAME > > > > > sequence. In a point to point scenario one can correlate transport > > > > > losses with > > > > > SFRAME gaps to know give a reasonably strong mitigation against any > > > > > third party > > > > > removing SFRAMEs or delaying them. That is much harder in a > centralized > > > > > conference with one or more SFU. > > > > > > > > > > > > > > > > > Anyway, I agree that while SFrame is transport agnostic, the > chapter > > > > > > should not ignore the interactions with webrtc/quic and we must > > > > > ensure > > > > > > that we provide a complete working solution regardless of the > > > > > transport. > > > > > > If we identify that any further working items are required for a > > > > > > particular transport, we should at liaise with the appropriate > > > > > working > > > > > > group for providing a solution. > > > > > > > > > > My main point is that SFRAME actually needs to discuss the threat > model > > > > > for the > > > > > use cases it intendes to solve. And the mitigation can potentially > > > > > include > > > > > functionality on the transport level. But the risks to media > security in > > > > > centralized conferencing needs to be discussed. And centralized > > > > > conferencing > > > > > will still have the semi-trusted SFUs and all the rest of the third > > > > > parties in > > > > > addition to the end-points. > > > > > > > > > > Also what properties one have around end-points invited into the > > > > > conference has > > > > > a number of question around security properties that needs to be > > > > > discussed and > > > > > documented. Some examples that I know are relevant: > > > > > > > > > > - Source authentication: SRTP unless one use TESLA (which isn't > really > > > > > used) > > > > > does only provided the property: Someone that has the key sent > this. One > > > > > don't > > > > > know that it comes from a particular endpoint. > > > > > > > > > > - Confidentiality when group membership changes: So will SFRAME > keying > > > > > support a > > > > > use case where only the current set of members in a conference can > > > > > decrypt the > > > > > media and one rekey the media session key for each time the > membership > > > > > changes? > > > > > PERC do support this, will SFRAME? > > > > > > > > > > There are likely more questions that needs discussion. The PERC > > > > > discussion is a > > > > > good starting point, but I think when going transport agnostic > some of > > > > > the > > > > > issues needs to be more clearly discussed as the RTP transport can > have > > > > > affected > > > > > how it was discussed, and what reliance on existing mechanism. > Which for > > > > > SFRAME > > > > > likely require a general discussion and then requirements on the > > > > > transport and > > > > > invovled endpoints and SFU to accomplish mitigations. And thus > also what > > > > > the > > > > > risks are of having no mitigation in place. > > > > > > > > > > I would really propose that SFRAME is chartered with publishing a > > > > > security > > > > > consideration and threat model document that is seperate from the > > > > > solution to > > > > > give this topic full focus. The solution will of necessity need to > > > > > reference > > > > > that and document what migitagtions that exists in the SFRAME > layer and > > > > > what > > > > > becomes requirements on the transport. > > > > > > > > > > Cheers > > > > > > > > > > Magnus Westerlund > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > Networks, Ericsson Research > > > > > > ---------------------------------------------------------------------- > > > > > Ericsson AB | Phone +46 10 7148287 > > > > > Torshamnsgatan 23 | Mobile +46 73 0949079 > > > > > SE-164 80 Stockholm, Sweden | mailto: > magnus.westerlund@ericsson.com > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > > -- > Cheers > > Magnus Westerlund > > > ---------------------------------------------------------------------- > Networks, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > > --00000000000057254505ae2e3930 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Magnus,

I think the inten= t here is to have a mechanism that provides a subset of the security proper= ties required for a given scenario, but which can be augmented with additio= nal mechanisms to provide the rest.=C2=A0 For example, even in the most obv= ious SFrame+SRTP case, there's a division of labor between the two prot= ocols, where SFrame only protects content, and SRTP also protects the RTP h= eader and guards against reply by network attackers.

So in a sense it is an intersection (in that it does something that is n= eeded by all the use cases), but it might need other things to provide all = the properties you need in a given scenario.

--Ric= hard

On Mon, Aug 31, 2020 at 10:06 AM Magnus Westerlund <magnus.westerlund@ericsson.com>= ; wrote:
Hi,

Thanks for working on addressing my comments when on vacation.

I think you mostly arravied at a good place. However, I would like to make = one
remark about the added language.

When it comes to threat models it can't be the intersection of threats = across
those that occur in the intended usages, it needs to be the union of threat= s.
The formulation added implies intersection to me.

Cheers

Magnus

On Wed, 2020-08-12 at 11:11 -0400, Richard Barnes wrote:
> Hey all,
>
> I agree that all of this stuff is valuable to capture somewhere.=C2=A0= In the
> interest of keeping the charter fairly succinct, I've added the fo= llowing:
>
> """
> The SFrame specification will detail the specific security properties = that the
> encapsulation provides, and discuss their implications under common us= age
> scenarios / threat models.
> """
>
> With that, I think that all the comments we've gotten so far have = been
> addressed.
>
> --Richard
>
>
> On Fri, Aug 7, 2020 at 11:51 PM Alexandre GOUAILLARD <
> = Alex.GOUAILLARD@cosmosoftware.io> wrote:
> > guys,
> >
> > sorry for jumping in so late, quarantine here is very strict.
> >
> > We had long discussions about this specific point ahead of the dr= aft
> > submission.
> > We had reached the following consensus:
> > - there are multiple usage of media over the internet, e.g. confe= rencing and
> > streaming/broadcast
> > - they have very different threat/trust models, with different so= lutions
> > implemented today (transport layer E / E2EE / DRM / Encrypted Med= ia
> > Extentions / ...)
> > - they all can benefit from SFrame
> >
> > PERC was, by design, limited to RTP and to Conferencing. Many oth= er use case
> > coul benefit from Enhanced Privacy.
> >
> > We concluded that it would be better to keep SFrame (the media en= cryption
> > part, equivalent to PERC double conceptually), and to have separa= ted
> > documents that describe the threat models and the corresponding k= ey
> > exchange, signaling and system level decision for each use case. = Emad had
> > taken an action item for example to make two additional documents= to
> > describe the Video Conferencing use case, and how SFrame could be= used in
> > conjunction with MLS to address that specific use case. Someone e= lse could
> > take the different use case of the Browsers (which have a specifi= c trust
> > model) and make a document showing how SFrame con work with Inser= table Frame
> > API (and likely some more) to address that use case. CoSMo is int= erested in
> > doing the same thing for Real-Time streaming/Broadcasting.
> >
> > I think it is a more reasonable approach as, even spending a lot = of time
> > brainstorming with everyone around the tabel including bernard, w= e couldn't
> > think about one solution to fit all the different "media ove= r internet"'s
> > threat model. In my mind, each case should first have an informal= document
> > to define scope and threat model, and subsequent document to defi= ne the
> > corresponding specifications.
> > - Secure Conferencing Threat model (emad and co.)
> > - Secure Conferencing Signalling using MLS (emad and co.)
> > - Secure Conferencing using MLS In the browser (contributed by w3= c people)
> >
> > Magnus, what do you think?
> >
> > Regards,
> >
> > Dr. ALex.
> >
> >
> >
> > On Fri, Aug 7, 2020 at 2:02 AM Emad Omara <
> > emadomara=3D40google.com@dmarc.ietf.org> wrote:
> > > Thanks Magnus. I like the idea to explicitly call out the th= reat model, I
> > > think it will be good foundations that control all future de= sign
> > > decisions, however I'm not sure if the charter is the ri= ght place to call
> > > this out. I'd recommend having a separate document that = describes the
> > > system architecture, goals and threat model. What do you thi= nk?
> > >
> > > Emad
> > >
> > > On Thu, Aug 6, 2020 at 1:56 AM Magnus Westerlund <
> > > magnus.westerlund@ericsson.com> wrote:
> > > > Hi,
> > > >
> > > > On Wed, 2020-08-05 at 22:15 +0200, Sergio Garcia Murill= o wrote:
> > > > > But shouldn't the "delayed media" at= tack still be transport agnostic?
> > > > I
> > > > > mean, this can happen on QUIC and WebRTC SFUs.
> > > >
> > > > Sorry if I gave the impression that it is not transport= agnostic. It is
> > > > use case
> > > > dependent, any use case that isn't point to point, = where there is more
> > > > than one
> > > > entity that can intentionally remove SFRAME creating ga= ps in the SFRAME
> > > > sequence. In a point to point scenario one can correlat= e transport
> > > > losses with
> > > > SFRAME gaps to know give a reasonably strong mitigation= against any
> > > > third party
> > > > removing SFRAMEs or delaying them. That is much harder = in a centralized
> > > > conference with one or more SFU.
> > > >
> > > > >
> > > > > Anyway, I agree that while SFrame is transport agn= ostic, the chapter
> > > > > should not ignore the interactions with webrtc/qui= c and we must
> > > > ensure
> > > > > that we provide a complete working solution regard= less of the
> > > > transport.
> > > > > If we identify that any further working items are = required for a
> > > > > particular transport, we should at liaise with the= appropriate
> > > > working
> > > > > group for providing a solution.
> > > >
> > > > My main point is that SFRAME actually needs to discuss = the threat model
> > > > for the
> > > > use cases it intendes to solve. And the mitigation can = potentially
> > > > include
> > > > functionality on the transport level. But the risks to = media security in
> > > > centralized conferencing needs to be discussed. And cen= tralized
> > > > conferencing
> > > > will still have the semi-trusted SFUs and all the rest = of the third
> > > > parties in
> > > > addition to the end-points.
> > > >
> > > > Also what properties one have around end-points invited= into the
> > > > conference has
> > > > a number of question around security properties that ne= eds to be
> > > > discussed and
> > > > documented. Some examples that I know are relevant:
> > > >
> > > > - Source authentication: SRTP unless one use TESLA (whi= ch isn't really
> > > > used)
> > > > does only provided the property: Someone that has the k= ey sent this. One
> > > > don't
> > > > know that it comes from a particular endpoint.
> > > >
> > > > - Confidentiality when group membership changes: So wil= l SFRAME keying
> > > > support a
> > > > use case where only the current set of members in a con= ference can
> > > > decrypt the
> > > > media and one rekey the media session key for each time= the membership
> > > > changes?
> > > > PERC do support this, will SFRAME?
> > > >
> > > > There are likely more questions that needs discussion. = The PERC
> > > > discussion is a
> > > > good starting point, but I think when going transport a= gnostic some of
> > > > the
> > > > issues needs to be more clearly discussed as the RTP tr= ansport can have
> > > > affected
> > > > how it was discussed, and what reliance on existing mec= hanism. Which for
> > > > SFRAME
> > > > likely require a general discussion and then requiremen= ts on the
> > > > transport and
> > > > invovled endpoints and SFU to accomplish mitigations. A= nd thus also what
> > > > the
> > > > risks are of having no mitigation in place.
> > > >
> > > > I would really propose that SFRAME is chartered with pu= blishing a
> > > > security
> > > > consideration and threat model document that is seperat= e from the
> > > > solution to
> > > > give this topic full focus. The solution will of necess= ity need to
> > > > reference
> > > > that and document what migitagtions that exists in the = SFRAME layer and
> > > > what
> > > > becomes requirements on the transport.
> > > >
> > > > Cheers
> > > >
> > > > Magnus Westerlund
> > > >
> > > >
> > > > -------------------------------------------------------= ---------------
> > > > Networks, Ericsson Research
> > > > -------------------------------------------------------= ---------------
> > > > Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| Phone=C2=A0 +46 10 7148287
> > > > Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| Mobile +46 73 0949079
> > > > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericss= on.com
> > > > -------------------------------------------------------= ---------------
> > > >
> > > >
--
Cheers

Magnus Westerlund


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Mobile +46 73 0= 949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--00000000000057254505ae2e3930-- From nobody Mon Aug 31 12:27:24 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4F23A1903; Mon, 31 Aug 2020 12:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqaytFwrzO88; Mon, 31 Aug 2020 12:27:21 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 90DC03A1900; Mon, 31 Aug 2020 12:27:20 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id w14so8057496ljj.4; Mon, 31 Aug 2020 12:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GGG5x5NZ0c31nkuiFGU60jF8vwJkoSCFAyW3tOPG88I=; b=fN9vNZc8JPeYVjqYcTpycaICydZekXOZ+CKmWyWfsOZamj6Yk5QwxLCj/lSCZpdqcs 34T826vaQYZXr/CM8Rx+8vzVuJY2XJA39OE1imqnqEg+x4CG71FFiO190QnTfzB87gER 29WdXiSyP6gdL8s8dR9lsIuufSSYUrLNdadgftYrdag3olE5dy0dKoT/tht8XD5DZAed nqt7WhlfJFJSwUxkJ+rNwI+UPDjcU87kWWkjSQLn15+r7/PDekrOp8oXlohj+Sqosj4A POaoBR/sqpBXvd0f4tC0DbkzNwAeazoJUbqg2lrHRZmWQ+XbkpatbUYE0NKAZxNUdL/9 laKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GGG5x5NZ0c31nkuiFGU60jF8vwJkoSCFAyW3tOPG88I=; b=lZLyZ/hkjT+U+XLhIgCgElyKtH9I7S5vXA0nsqzDmddva274B881lAHzk5wpCZjFuS Ua8oZcMo+TMV9Mep7qvhDZMAThfRHMOJFHvQ6V7RX2mSj8wSP2Q36pRKtgdyojmAjzsa wSeDkfXw8Fn5XNEZldIpgSNqXoSRbgKcYiwEnpgmnX6A76d9OdHKkI4dPGClthZalSXR uExgiskl+WCNBVL1DS8Q3I4YbrmU4NGlMgy8n87W8wE0opjMmG3QY8QJRUMOwwWOzSnu 2sM20+814Lz/RcgcN3rSQLR5m5RGoII8QMX7IL6fCXXFAOgP8/u476JpKtchr8t02OjP jV9A== X-Gm-Message-State: AOAM5321phbRxMCVJyQxpPQaJlMDx58V/xjSc28VWpIO6AK9YaTIVu1i rfPSN2AfymSqJQ+bUGk96fLqf143LhgZvCt1ob4= X-Google-Smtp-Source: ABdhPJzzDQqiWpy9PZW6dJ+qS0Pc/DB/GvgsqXhVibFZEmkZXHUk1fePtUMdDiPqg7h+aDUHL9P3eqCe5vh8WGicBn4= X-Received: by 2002:a2e:6819:: with SMTP id c25mr1340827lja.187.1598902038388; Mon, 31 Aug 2020 12:27:18 -0700 (PDT) MIME-Version: 1.0 References: <69181ed1-d72a-99de-8b4d-9e10276ced91@gmail.com> <771e108a9f25c1bec04d5fcdad58eb55bbb1533d.camel@ericsson.com> In-Reply-To: From: Bernard Aboba Date: Mon, 31 Aug 2020 12:27:07 -0700 Message-ID: To: Richard Barnes Cc: Magnus Westerlund , "emadomara=40google.com@dmarc.ietf.org" , "ben@nostrum.com" , "dispatch@ietf.org" , "sframe@ietf.org" , "sergio.garcia.murillo@gmail.com" , "Alex.GOUAILLARD@cosmosoftware.io" Content-Type: multipart/alternative; boundary="00000000000007618e05ae31647f" Archived-At: Subject: Re: [dispatch] [Sframe] SFRame Next Steps (was SFrame proposed WG charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 19:27:23 -0000 --00000000000007618e05ae31647f Content-Type: text/plain; charset="UTF-8" Richard said: "in the most obvious SFrame+SRTP case, there's a division of labor between the two protocols, " [BA] There is also an interaction between E2E encryption and packetization that needs to be captured somewhere. In SFrame, the packetization model is potentially different from PERC, because the SFrame packetizer may not have visibility into the E2E encrypted payload (e.g. the packetizer may not have access to the cleartext payload). The implication is that the information needed to packetize the E2E encrypted frame (e.g. the metadata) needs to be provided to the packetizer. This info must be sufficient to fill in the RTP header fields as well as RTP header extensions, including those RTP header extensions used by an SFU for forwarding (e.g. frame-marking or Dependency Descriptor). I'd note that the current SFrame draft does not address this yet, except for a figure including a "payload header" in section 1. It is my understanding that the "Payload Header" represents info provided in the clear (such as the VP8 header), which is needed by the packetizer. Implementations that have encrypted this field or have not provided what was expected (e.g. attempts to utilize the H.264/AVC codec) have encountered E2E encryption failures. One approach to addressing this is to define a "generic packetizer" for a transport that will be able to packetize and depacketize the E2E encrypted frame in any codec. If that work is indeed needed, then it should be described somewhere. On Mon, Aug 31, 2020 at 8:41 AM Richard Barnes wrote: > Hi Magnus, > > I think the intent here is to have a mechanism that provides a subset of > the security properties required for a given scenario, but which can be > augmented with additional mechanisms to provide the rest. For example, > even in the most obvious SFrame+SRTP case, there's a division of labor > between the two protocols, where SFrame only protects content, and SRTP > also protects the RTP header and guards against reply by network attackers. > > So in a sense it is an intersection (in that it does something that is > needed by all the use cases), but it might need other things to provide all > the properties you need in a given scenario. > > --Richard > > On Mon, Aug 31, 2020 at 10:06 AM Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: > >> Hi, >> >> Thanks for working on addressing my comments when on vacation. >> >> I think you mostly arravied at a good place. However, I would like to >> make one >> remark about the added language. >> >> When it comes to threat models it can't be the intersection of threats >> across >> those that occur in the intended usages, it needs to be the union of >> threats. >> The formulation added implies intersection to me. >> >> Cheers >> >> Magnus >> >> On Wed, 2020-08-12 at 11:11 -0400, Richard Barnes wrote: >> > Hey all, >> > >> > I agree that all of this stuff is valuable to capture somewhere. In the >> > interest of keeping the charter fairly succinct, I've added the >> following: >> > >> > """ >> > The SFrame specification will detail the specific security properties >> that the >> > encapsulation provides, and discuss their implications under common >> usage >> > scenarios / threat models. >> > """ >> > >> > With that, I think that all the comments we've gotten so far have been >> > addressed. >> > >> > --Richard >> > >> > >> > On Fri, Aug 7, 2020 at 11:51 PM Alexandre GOUAILLARD < >> > Alex.GOUAILLARD@cosmosoftware.io> wrote: >> > > guys, >> > > >> > > sorry for jumping in so late, quarantine here is very strict. >> > > >> > > We had long discussions about this specific point ahead of the draft >> > > submission. >> > > We had reached the following consensus: >> > > - there are multiple usage of media over the internet, e.g. >> conferencing and >> > > streaming/broadcast >> > > - they have very different threat/trust models, with different >> solutions >> > > implemented today (transport layer E / E2EE / DRM / Encrypted Media >> > > Extentions / ...) >> > > - they all can benefit from SFrame >> > > >> > > PERC was, by design, limited to RTP and to Conferencing. Many other >> use case >> > > coul benefit from Enhanced Privacy. >> > > >> > > We concluded that it would be better to keep SFrame (the media >> encryption >> > > part, equivalent to PERC double conceptually), and to have separated >> > > documents that describe the threat models and the corresponding key >> > > exchange, signaling and system level decision for each use case. Emad >> had >> > > taken an action item for example to make two additional documents to >> > > describe the Video Conferencing use case, and how SFrame could be >> used in >> > > conjunction with MLS to address that specific use case. Someone else >> could >> > > take the different use case of the Browsers (which have a specific >> trust >> > > model) and make a document showing how SFrame con work with >> Insertable Frame >> > > API (and likely some more) to address that use case. CoSMo is >> interested in >> > > doing the same thing for Real-Time streaming/Broadcasting. >> > > >> > > I think it is a more reasonable approach as, even spending a lot of >> time >> > > brainstorming with everyone around the tabel including bernard, we >> couldn't >> > > think about one solution to fit all the different "media over >> internet"'s >> > > threat model. In my mind, each case should first have an informal >> document >> > > to define scope and threat model, and subsequent document to define >> the >> > > corresponding specifications. >> > > - Secure Conferencing Threat model (emad and co.) >> > > - Secure Conferencing Signalling using MLS (emad and co.) >> > > - Secure Conferencing using MLS In the browser (contributed by w3c >> people) >> > > >> > > Magnus, what do you think? >> > > >> > > Regards, >> > > >> > > Dr. ALex. >> > > >> > > >> > > >> > > On Fri, Aug 7, 2020 at 2:02 AM Emad Omara < >> > > emadomara=40google.com@dmarc.ietf.org> wrote: >> > > > Thanks Magnus. I like the idea to explicitly call out the threat >> model, I >> > > > think it will be good foundations that control all future design >> > > > decisions, however I'm not sure if the charter is the right place >> to call >> > > > this out. I'd recommend having a separate document that describes >> the >> > > > system architecture, goals and threat model. What do you think? >> > > > >> > > > Emad >> > > > >> > > > On Thu, Aug 6, 2020 at 1:56 AM Magnus Westerlund < >> > > > magnus.westerlund@ericsson.com> wrote: >> > > > > Hi, >> > > > > >> > > > > On Wed, 2020-08-05 at 22:15 +0200, Sergio Garcia Murillo wrote: >> > > > > > But shouldn't the "delayed media" attack still be transport >> agnostic? >> > > > > I >> > > > > > mean, this can happen on QUIC and WebRTC SFUs. >> > > > > >> > > > > Sorry if I gave the impression that it is not transport agnostic. >> It is >> > > > > use case >> > > > > dependent, any use case that isn't point to point, where there is >> more >> > > > > than one >> > > > > entity that can intentionally remove SFRAME creating gaps in the >> SFRAME >> > > > > sequence. In a point to point scenario one can correlate transport >> > > > > losses with >> > > > > SFRAME gaps to know give a reasonably strong mitigation against >> any >> > > > > third party >> > > > > removing SFRAMEs or delaying them. That is much harder in a >> centralized >> > > > > conference with one or more SFU. >> > > > > >> > > > > > >> > > > > > Anyway, I agree that while SFrame is transport agnostic, the >> chapter >> > > > > > should not ignore the interactions with webrtc/quic and we must >> > > > > ensure >> > > > > > that we provide a complete working solution regardless of the >> > > > > transport. >> > > > > > If we identify that any further working items are required for >> a >> > > > > > particular transport, we should at liaise with the appropriate >> > > > > working >> > > > > > group for providing a solution. >> > > > > >> > > > > My main point is that SFRAME actually needs to discuss the threat >> model >> > > > > for the >> > > > > use cases it intendes to solve. And the mitigation can potentially >> > > > > include >> > > > > functionality on the transport level. But the risks to media >> security in >> > > > > centralized conferencing needs to be discussed. And centralized >> > > > > conferencing >> > > > > will still have the semi-trusted SFUs and all the rest of the >> third >> > > > > parties in >> > > > > addition to the end-points. >> > > > > >> > > > > Also what properties one have around end-points invited into the >> > > > > conference has >> > > > > a number of question around security properties that needs to be >> > > > > discussed and >> > > > > documented. Some examples that I know are relevant: >> > > > > >> > > > > - Source authentication: SRTP unless one use TESLA (which isn't >> really >> > > > > used) >> > > > > does only provided the property: Someone that has the key sent >> this. One >> > > > > don't >> > > > > know that it comes from a particular endpoint. >> > > > > >> > > > > - Confidentiality when group membership changes: So will SFRAME >> keying >> > > > > support a >> > > > > use case where only the current set of members in a conference can >> > > > > decrypt the >> > > > > media and one rekey the media session key for each time the >> membership >> > > > > changes? >> > > > > PERC do support this, will SFRAME? >> > > > > >> > > > > There are likely more questions that needs discussion. The PERC >> > > > > discussion is a >> > > > > good starting point, but I think when going transport agnostic >> some of >> > > > > the >> > > > > issues needs to be more clearly discussed as the RTP transport >> can have >> > > > > affected >> > > > > how it was discussed, and what reliance on existing mechanism. >> Which for >> > > > > SFRAME >> > > > > likely require a general discussion and then requirements on the >> > > > > transport and >> > > > > invovled endpoints and SFU to accomplish mitigations. And thus >> also what >> > > > > the >> > > > > risks are of having no mitigation in place. >> > > > > >> > > > > I would really propose that SFRAME is chartered with publishing a >> > > > > security >> > > > > consideration and threat model document that is seperate from the >> > > > > solution to >> > > > > give this topic full focus. The solution will of necessity need to >> > > > > reference >> > > > > that and document what migitagtions that exists in the SFRAME >> layer and >> > > > > what >> > > > > becomes requirements on the transport. >> > > > > >> > > > > Cheers >> > > > > >> > > > > Magnus Westerlund >> > > > > >> > > > > >> > > > > >> ---------------------------------------------------------------------- >> > > > > Networks, Ericsson Research >> > > > > >> ---------------------------------------------------------------------- >> > > > > Ericsson AB | Phone +46 10 7148287 >> > > > > Torshamnsgatan 23 | Mobile +46 73 0949079 >> > > > > SE-164 80 Stockholm, Sweden | mailto: >> magnus.westerlund@ericsson.com >> > > > > >> ---------------------------------------------------------------------- >> > > > > >> > > > > >> -- >> Cheers >> >> Magnus Westerlund >> >> >> ---------------------------------------------------------------------- >> Networks, Ericsson Research >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Torshamnsgatan 23 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> >> -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --00000000000007618e05ae31647f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Richard said:=C2=A0

&q= uot;in the most obvious SFrame+SRTP case, there's a division of labor b= etween the two protocols,=C2=A0"

[BA] There i= s also an interaction between E2E encryption and packetization that needs t= o be captured somewhere. In SFrame, the packetization model is potentially = different from PERC, because the SFrame packetizer may not have visibility = into the E2E encrypted payload (e.g. the packetizer may not have access to = the cleartext payload).=C2=A0 The implication is that the information neede= d to packetize the E2E encrypted frame (e.g. the metadata) needs to be prov= ided to the packetizer.=C2=A0 This info must be sufficient to fill in the R= TP header fields as well as RTP header extensions, including those RTP head= er extensions used by an SFU for forwarding (e.g. frame-marking or Dependen= cy Descriptor).=C2=A0=C2=A0

I'd note that the = current SFrame draft does not address this yet, except for a figure includi= ng a "payload header" in section 1.=C2=A0 It is my understanding = that the "Payload Header" represents info provided in the clear (= such as the VP8 header), which is needed by the packetizer.=C2=A0 Implement= ations that have encrypted this field or have not provided what was expecte= d (e.g. attempts to utilize the H.264/AVC codec) have encountered E2E encry= ption failures.=C2=A0

One approach to addressing t= his is to define a "generic packetizer" for a transport that will= be able to packetize and depacketize the E2E encrypted frame in any codec.= =C2=A0 If that work is indeed needed, then it should be described somewhere= .=C2=A0

On Mon, Aug 31, 2020 at 8:41 AM Richard Barnes <rlb@i= pv.sx> wrote:
Hi Magnus,

I think the inte= nt here is to have a mechanism that provides a subset of the security prope= rties required for a given scenario, but which can be augmented with additi= onal mechanisms to provide the rest.=C2=A0 For example, even in the most ob= vious SFrame+SRTP case, there's a division of labor between the two pro= tocols, where SFrame only protects content, and SRTP also protects the RTP = header and guards against reply by network attackers.

<= div>So in a sense it is an intersection (in that it does something that is = needed by all the use cases), but it might need other things to provide all= the properties you need in a given scenario.

--Ri= chard

On Mon, Aug 31, 2020 at 10:06 AM Magnus Westerlund <magnus.westerlund@= ericsson.com> wrote:
Hi,

Thanks for working on addressing my comments when on vacation.

I think you mostly arravied at a good place. However, I would like to make = one
remark about the added language.

When it comes to threat models it can't be the intersection of threats = across
those that occur in the intended usages, it needs to be the union of threat= s.
The formulation added implies intersection to me.

Cheers

Magnus

On Wed, 2020-08-12 at 11:11 -0400, Richard Barnes wrote:
> Hey all,
>
> I agree that all of this stuff is valuable to capture somewhere.=C2=A0= In the
> interest of keeping the charter fairly succinct, I've added the fo= llowing:
>
> """
> The SFrame specification will detail the specific security properties = that the
> encapsulation provides, and discuss their implications under common us= age
> scenarios / threat models.
> """
>
> With that, I think that all the comments we've gotten so far have = been
> addressed.
>
> --Richard
>
>
> On Fri, Aug 7, 2020 at 11:51 PM Alexandre GOUAILLARD <
> = Alex.GOUAILLARD@cosmosoftware.io> wrote:
> > guys,
> >
> > sorry for jumping in so late, quarantine here is very strict.
> >
> > We had long discussions about this specific point ahead of the dr= aft
> > submission.
> > We had reached the following consensus:
> > - there are multiple usage of media over the internet, e.g. confe= rencing and
> > streaming/broadcast
> > - they have very different threat/trust models, with different so= lutions
> > implemented today (transport layer E / E2EE / DRM / Encrypted Med= ia
> > Extentions / ...)
> > - they all can benefit from SFrame
> >
> > PERC was, by design, limited to RTP and to Conferencing. Many oth= er use case
> > coul benefit from Enhanced Privacy.
> >
> > We concluded that it would be better to keep SFrame (the media en= cryption
> > part, equivalent to PERC double conceptually), and to have separa= ted
> > documents that describe the threat models and the corresponding k= ey
> > exchange, signaling and system level decision for each use case. = Emad had
> > taken an action item for example to make two additional documents= to
> > describe the Video Conferencing use case, and how SFrame could be= used in
> > conjunction with MLS to address that specific use case. Someone e= lse could
> > take the different use case of the Browsers (which have a specifi= c trust
> > model) and make a document showing how SFrame con work with Inser= table Frame
> > API (and likely some more) to address that use case. CoSMo is int= erested in
> > doing the same thing for Real-Time streaming/Broadcasting.
> >
> > I think it is a more reasonable approach as, even spending a lot = of time
> > brainstorming with everyone around the tabel including bernard, w= e couldn't
> > think about one solution to fit all the different "media ove= r internet"'s
> > threat model. In my mind, each case should first have an informal= document
> > to define scope and threat model, and subsequent document to defi= ne the
> > corresponding specifications.
> > - Secure Conferencing Threat model (emad and co.)
> > - Secure Conferencing Signalling using MLS (emad and co.)
> > - Secure Conferencing using MLS In the browser (contributed by w3= c people)
> >
> > Magnus, what do you think?
> >
> > Regards,
> >
> > Dr. ALex.
> >
> >
> >
> > On Fri, Aug 7, 2020 at 2:02 AM Emad Omara <
> > emadomara=3D40google.com@dmarc.ietf.org> wrote:
> > > Thanks Magnus. I like the idea to explicitly call out the th= reat model, I
> > > think it will be good foundations that control all future de= sign
> > > decisions, however I'm not sure if the charter is the ri= ght place to call
> > > this out. I'd recommend having a separate document that = describes the
> > > system architecture, goals and threat model. What do you thi= nk?
> > >
> > > Emad
> > >
> > > On Thu, Aug 6, 2020 at 1:56 AM Magnus Westerlund <
> > > magnus.westerlund@ericsson.com> wrote:
> > > > Hi,
> > > >
> > > > On Wed, 2020-08-05 at 22:15 +0200, Sergio Garcia Murill= o wrote:
> > > > > But shouldn't the "delayed media" at= tack still be transport agnostic?
> > > > I
> > > > > mean, this can happen on QUIC and WebRTC SFUs.
> > > >
> > > > Sorry if I gave the impression that it is not transport= agnostic. It is
> > > > use case
> > > > dependent, any use case that isn't point to point, = where there is more
> > > > than one
> > > > entity that can intentionally remove SFRAME creating ga= ps in the SFRAME
> > > > sequence. In a point to point scenario one can correlat= e transport
> > > > losses with
> > > > SFRAME gaps to know give a reasonably strong mitigation= against any
> > > > third party
> > > > removing SFRAMEs or delaying them. That is much harder = in a centralized
> > > > conference with one or more SFU.
> > > >
> > > > >
> > > > > Anyway, I agree that while SFrame is transport agn= ostic, the chapter
> > > > > should not ignore the interactions with webrtc/qui= c and we must
> > > > ensure
> > > > > that we provide a complete working solution regard= less of the
> > > > transport.
> > > > > If we identify that any further working items are = required for a
> > > > > particular transport, we should at liaise with the= appropriate
> > > > working
> > > > > group for providing a solution.
> > > >
> > > > My main point is that SFRAME actually needs to discuss = the threat model
> > > > for the
> > > > use cases it intendes to solve. And the mitigation can = potentially
> > > > include
> > > > functionality on the transport level. But the risks to = media security in
> > > > centralized conferencing needs to be discussed. And cen= tralized
> > > > conferencing
> > > > will still have the semi-trusted SFUs and all the rest = of the third
> > > > parties in
> > > > addition to the end-points.
> > > >
> > > > Also what properties one have around end-points invited= into the
> > > > conference has
> > > > a number of question around security properties that ne= eds to be
> > > > discussed and
> > > > documented. Some examples that I know are relevant:
> > > >
> > > > - Source authentication: SRTP unless one use TESLA (whi= ch isn't really
> > > > used)
> > > > does only provided the property: Someone that has the k= ey sent this. One
> > > > don't
> > > > know that it comes from a particular endpoint.
> > > >
> > > > - Confidentiality when group membership changes: So wil= l SFRAME keying
> > > > support a
> > > > use case where only the current set of members in a con= ference can
> > > > decrypt the
> > > > media and one rekey the media session key for each time= the membership
> > > > changes?
> > > > PERC do support this, will SFRAME?
> > > >
> > > > There are likely more questions that needs discussion. = The PERC
> > > > discussion is a
> > > > good starting point, but I think when going transport a= gnostic some of
> > > > the
> > > > issues needs to be more clearly discussed as the RTP tr= ansport can have
> > > > affected
> > > > how it was discussed, and what reliance on existing mec= hanism. Which for
> > > > SFRAME
> > > > likely require a general discussion and then requiremen= ts on the
> > > > transport and
> > > > invovled endpoints and SFU to accomplish mitigations. A= nd thus also what
> > > > the
> > > > risks are of having no mitigation in place.
> > > >
> > > > I would really propose that SFRAME is chartered with pu= blishing a
> > > > security
> > > > consideration and threat model document that is seperat= e from the
> > > > solution to
> > > > give this topic full focus. The solution will of necess= ity need to
> > > > reference
> > > > that and document what migitagtions that exists in the = SFRAME layer and
> > > > what
> > > > becomes requirements on the transport.
> > > >
> > > > Cheers
> > > >
> > > > Magnus Westerlund
> > > >
> > > >
> > > > -------------------------------------------------------= ---------------
> > > > Networks, Ericsson Research
> > > > -------------------------------------------------------= ---------------
> > > > Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| Phone=C2=A0 +46 10 7148287
> > > > Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| Mobile +46 73 0949079
> > > > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericss= on.com
> > > > -------------------------------------------------------= ---------------
> > > >
> > > >
--
Cheers

Magnus Westerlund


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Mobile +46 73 0= 949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--00000000000007618e05ae31647f-- From nobody Mon Aug 31 15:14:34 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20ABA3A0123 for ; Mon, 31 Aug 2020 15:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxXtNCqlwHhz for ; Mon, 31 Aug 2020 15:14:25 -0700 (PDT) Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com [IPv6:2607:f8b0:4864:20::a32]) (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 138EE3A012A for ; Mon, 31 Aug 2020 15:14:24 -0700 (PDT) Received: by mail-vk1-xa32.google.com with SMTP id n193so1663716vkf.12 for ; Mon, 31 Aug 2020 15:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=29FKiT3Guy44TmMTR5FyPow58HeKb7l/XnyrcQ5plQM=; b=HrGXALltT69zp+6XRX++7UcKJ1Cj/SYd0sa52pckq7BRpIKyHPh/IVXomU+B60cWjT uI+JeyedhY+v3ToBROcmLn5XxNlkkwK6gLZCha9l+vAvF8DftUSr4b7wCGj3Q7nJt7z5 YqaC36uEC8pNxF2DwjJWUESSgg7EPqGhpbGjkx7wE00qmoF/TWTmDHRK/SGon7bCHFvZ YbvwfBuIXyqn5uJWfgLsx1RVR+dPurFr5qPF+X+SpavqBhas868NsIyNqBiti8Vs4o7J CdTa7UBgK6uECUrLTdEgL47qo1JrVU7nvF2XTlIjrsIh+2rHYyd+rLfMuOqmX2LGRuXN 3pcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=29FKiT3Guy44TmMTR5FyPow58HeKb7l/XnyrcQ5plQM=; b=l0SV3ekiil3sRgww8edhwoXVnFuLBVdv77qG9MqSwAqbB9LP9UYy92IuYAW/dbZWa8 A2bA6B+HBoHT+xAPboWWG+TZEnZDuT5Nhli0BlX0CWyxEc/dvdQxYnVliEpL662AHfMg 3+iAB4PSmxCgQmrzpuCYznormDtpWCiLUqHJw+YonhPoy0tz1XGzNNZBW+j078WMj8wL 9Mz3AaqopI2c2bUnAXJFSXYGo6uS32yVkWbNs173fImeC+ChmHgpNcLKQhfUCJvqnP7m 6WGl3tObtWiK0CzFINfCOvGL6vog2JS9Y65v1NQmL04ukWq5BI2Ml9rASr3n9p2WU2pI ul1A== X-Gm-Message-State: AOAM5305Mz5LoM0PSFGXWMpd5gDsm1YLHjWF/GVAU7rZVnDLeG4JmpPY F52XkR22SgJeoFQQorfrVyEz3kCzZoqnoAVwcOKu X-Google-Smtp-Source: ABdhPJxZfxNUzfW27NUix8mD1O92dBXlpd0xXgkaZRtAR0URBps6Irk0rtSMrwlCopRlGVy4MCm+bocuzOxDNJn5dDs= X-Received: by 2002:a1f:286:: with SMTP id 128mr3102129vkc.96.1598912063660; Mon, 31 Aug 2020 15:14:23 -0700 (PDT) MIME-Version: 1.0 References: <69181ed1-d72a-99de-8b4d-9e10276ced91@gmail.com> <771e108a9f25c1bec04d5fcdad58eb55bbb1533d.camel@ericsson.com> In-Reply-To: From: Emad Omara Date: Mon, 31 Aug 2020 15:14:11 -0700 Message-ID: To: Bernard Aboba Cc: Richard Barnes , Magnus Westerlund , "ben@nostrum.com" , "dispatch@ietf.org" , "sframe@ietf.org" , "sergio.garcia.murillo@gmail.com" , "Alex.GOUAILLARD@cosmosoftware.io" Content-Type: multipart/alternative; boundary="00000000000095450005ae33b9b2" Archived-At: Subject: Re: [dispatch] [Sframe] SFRame Next Steps (was SFrame proposed WG charter) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 22:14:29 -0000 --00000000000095450005ae33b9b2 Content-Type: text/plain; charset="UTF-8" Thanks Bernard. The SFrame draft intentionally avoided any RTP dependencies, but as referenced a generic frame marking extension could be used to pass the media metadata in plaintext (but authenticated). Of course the RTP header ext should be HBH encrypted. Regarding packetization, yes a generic RTP packetizer will be used since the media will be encrypted. The frame marking ext will be used to define the frame boundaries. That being said, we need a 2nd draft for SFrame-RTP integration to cover this topic and potentially other topics as well, which I promised I will work on sometime soon :-) On Mon, Aug 31, 2020 at 12:27 PM Bernard Aboba wrote: > Richard said: > > "in the most obvious SFrame+SRTP case, there's a division of labor between > the two protocols, " > > [BA] There is also an interaction between E2E encryption and packetization > that needs to be captured somewhere. In SFrame, the packetization model is > potentially different from PERC, because the SFrame packetizer may not have > visibility into the E2E encrypted payload (e.g. the packetizer may not have > access to the cleartext payload). The implication is that the information > needed to packetize the E2E encrypted frame (e.g. the metadata) needs to be > provided to the packetizer. This info must be sufficient to fill in the > RTP header fields as well as RTP header extensions, including those RTP > header extensions used by an SFU for forwarding (e.g. frame-marking or > Dependency Descriptor). > > I'd note that the current SFrame draft does not address this yet, except > for a figure including a "payload header" in section 1. It is my > understanding that the "Payload Header" represents info provided in the > clear (such as the VP8 header), which is needed by the packetizer. > Implementations that have encrypted this field or have not provided what > was expected (e.g. attempts to utilize the H.264/AVC codec) have > encountered E2E encryption failures. > > One approach to addressing this is to define a "generic packetizer" for a > transport that will be able to packetize and depacketize the E2E encrypted > frame in any codec. If that work is indeed needed, then it should be > described somewhere. > > On Mon, Aug 31, 2020 at 8:41 AM Richard Barnes wrote: > >> Hi Magnus, >> >> I think the intent here is to have a mechanism that provides a subset of >> the security properties required for a given scenario, but which can be >> augmented with additional mechanisms to provide the rest. For example, >> even in the most obvious SFrame+SRTP case, there's a division of labor >> between the two protocols, where SFrame only protects content, and SRTP >> also protects the RTP header and guards against reply by network attackers. >> >> So in a sense it is an intersection (in that it does something that is >> needed by all the use cases), but it might need other things to provide all >> the properties you need in a given scenario. >> >> --Richard >> >> On Mon, Aug 31, 2020 at 10:06 AM Magnus Westerlund < >> magnus.westerlund@ericsson.com> wrote: >> >>> Hi, >>> >>> Thanks for working on addressing my comments when on vacation. >>> >>> I think you mostly arravied at a good place. However, I would like to >>> make one >>> remark about the added language. >>> >>> When it comes to threat models it can't be the intersection of threats >>> across >>> those that occur in the intended usages, it needs to be the union of >>> threats. >>> The formulation added implies intersection to me. >>> >>> Cheers >>> >>> Magnus >>> >>> On Wed, 2020-08-12 at 11:11 -0400, Richard Barnes wrote: >>> > Hey all, >>> > >>> > I agree that all of this stuff is valuable to capture somewhere. In >>> the >>> > interest of keeping the charter fairly succinct, I've added the >>> following: >>> > >>> > """ >>> > The SFrame specification will detail the specific security properties >>> that the >>> > encapsulation provides, and discuss their implications under common >>> usage >>> > scenarios / threat models. >>> > """ >>> > >>> > With that, I think that all the comments we've gotten so far have been >>> > addressed. >>> > >>> > --Richard >>> > >>> > >>> > On Fri, Aug 7, 2020 at 11:51 PM Alexandre GOUAILLARD < >>> > Alex.GOUAILLARD@cosmosoftware.io> wrote: >>> > > guys, >>> > > >>> > > sorry for jumping in so late, quarantine here is very strict. >>> > > >>> > > We had long discussions about this specific point ahead of the draft >>> > > submission. >>> > > We had reached the following consensus: >>> > > - there are multiple usage of media over the internet, e.g. >>> conferencing and >>> > > streaming/broadcast >>> > > - they have very different threat/trust models, with different >>> solutions >>> > > implemented today (transport layer E / E2EE / DRM / Encrypted Media >>> > > Extentions / ...) >>> > > - they all can benefit from SFrame >>> > > >>> > > PERC was, by design, limited to RTP and to Conferencing. Many other >>> use case >>> > > coul benefit from Enhanced Privacy. >>> > > >>> > > We concluded that it would be better to keep SFrame (the media >>> encryption >>> > > part, equivalent to PERC double conceptually), and to have separated >>> > > documents that describe the threat models and the corresponding key >>> > > exchange, signaling and system level decision for each use case. >>> Emad had >>> > > taken an action item for example to make two additional documents to >>> > > describe the Video Conferencing use case, and how SFrame could be >>> used in >>> > > conjunction with MLS to address that specific use case. Someone else >>> could >>> > > take the different use case of the Browsers (which have a specific >>> trust >>> > > model) and make a document showing how SFrame con work with >>> Insertable Frame >>> > > API (and likely some more) to address that use case. CoSMo is >>> interested in >>> > > doing the same thing for Real-Time streaming/Broadcasting. >>> > > >>> > > I think it is a more reasonable approach as, even spending a lot of >>> time >>> > > brainstorming with everyone around the tabel including bernard, we >>> couldn't >>> > > think about one solution to fit all the different "media over >>> internet"'s >>> > > threat model. In my mind, each case should first have an informal >>> document >>> > > to define scope and threat model, and subsequent document to define >>> the >>> > > corresponding specifications. >>> > > - Secure Conferencing Threat model (emad and co.) >>> > > - Secure Conferencing Signalling using MLS (emad and co.) >>> > > - Secure Conferencing using MLS In the browser (contributed by w3c >>> people) >>> > > >>> > > Magnus, what do you think? >>> > > >>> > > Regards, >>> > > >>> > > Dr. ALex. >>> > > >>> > > >>> > > >>> > > On Fri, Aug 7, 2020 at 2:02 AM Emad Omara < >>> > > emadomara=40google.com@dmarc.ietf.org> wrote: >>> > > > Thanks Magnus. I like the idea to explicitly call out the threat >>> model, I >>> > > > think it will be good foundations that control all future design >>> > > > decisions, however I'm not sure if the charter is the right place >>> to call >>> > > > this out. I'd recommend having a separate document that describes >>> the >>> > > > system architecture, goals and threat model. What do you think? >>> > > > >>> > > > Emad >>> > > > >>> > > > On Thu, Aug 6, 2020 at 1:56 AM Magnus Westerlund < >>> > > > magnus.westerlund@ericsson.com> wrote: >>> > > > > Hi, >>> > > > > >>> > > > > On Wed, 2020-08-05 at 22:15 +0200, Sergio Garcia Murillo wrote: >>> > > > > > But shouldn't the "delayed media" attack still be transport >>> agnostic? >>> > > > > I >>> > > > > > mean, this can happen on QUIC and WebRTC SFUs. >>> > > > > >>> > > > > Sorry if I gave the impression that it is not transport >>> agnostic. It is >>> > > > > use case >>> > > > > dependent, any use case that isn't point to point, where there >>> is more >>> > > > > than one >>> > > > > entity that can intentionally remove SFRAME creating gaps in the >>> SFRAME >>> > > > > sequence. In a point to point scenario one can correlate >>> transport >>> > > > > losses with >>> > > > > SFRAME gaps to know give a reasonably strong mitigation against >>> any >>> > > > > third party >>> > > > > removing SFRAMEs or delaying them. That is much harder in a >>> centralized >>> > > > > conference with one or more SFU. >>> > > > > >>> > > > > > >>> > > > > > Anyway, I agree that while SFrame is transport agnostic, the >>> chapter >>> > > > > > should not ignore the interactions with webrtc/quic and we must >>> > > > > ensure >>> > > > > > that we provide a complete working solution regardless of the >>> > > > > transport. >>> > > > > > If we identify that any further working items are required for >>> a >>> > > > > > particular transport, we should at liaise with the appropriate >>> > > > > working >>> > > > > > group for providing a solution. >>> > > > > >>> > > > > My main point is that SFRAME actually needs to discuss the >>> threat model >>> > > > > for the >>> > > > > use cases it intendes to solve. And the mitigation can >>> potentially >>> > > > > include >>> > > > > functionality on the transport level. But the risks to media >>> security in >>> > > > > centralized conferencing needs to be discussed. And centralized >>> > > > > conferencing >>> > > > > will still have the semi-trusted SFUs and all the rest of the >>> third >>> > > > > parties in >>> > > > > addition to the end-points. >>> > > > > >>> > > > > Also what properties one have around end-points invited into the >>> > > > > conference has >>> > > > > a number of question around security properties that needs to be >>> > > > > discussed and >>> > > > > documented. Some examples that I know are relevant: >>> > > > > >>> > > > > - Source authentication: SRTP unless one use TESLA (which isn't >>> really >>> > > > > used) >>> > > > > does only provided the property: Someone that has the key sent >>> this. One >>> > > > > don't >>> > > > > know that it comes from a particular endpoint. >>> > > > > >>> > > > > - Confidentiality when group membership changes: So will SFRAME >>> keying >>> > > > > support a >>> > > > > use case where only the current set of members in a conference >>> can >>> > > > > decrypt the >>> > > > > media and one rekey the media session key for each time the >>> membership >>> > > > > changes? >>> > > > > PERC do support this, will SFRAME? >>> > > > > >>> > > > > There are likely more questions that needs discussion. The PERC >>> > > > > discussion is a >>> > > > > good starting point, but I think when going transport agnostic >>> some of >>> > > > > the >>> > > > > issues needs to be more clearly discussed as the RTP transport >>> can have >>> > > > > affected >>> > > > > how it was discussed, and what reliance on existing mechanism. >>> Which for >>> > > > > SFRAME >>> > > > > likely require a general discussion and then requirements on the >>> > > > > transport and >>> > > > > invovled endpoints and SFU to accomplish mitigations. And thus >>> also what >>> > > > > the >>> > > > > risks are of having no mitigation in place. >>> > > > > >>> > > > > I would really propose that SFRAME is chartered with publishing a >>> > > > > security >>> > > > > consideration and threat model document that is seperate from the >>> > > > > solution to >>> > > > > give this topic full focus. The solution will of necessity need >>> to >>> > > > > reference >>> > > > > that and document what migitagtions that exists in the SFRAME >>> layer and >>> > > > > what >>> > > > > becomes requirements on the transport. >>> > > > > >>> > > > > Cheers >>> > > > > >>> > > > > Magnus Westerlund >>> > > > > >>> > > > > >>> > > > > >>> ---------------------------------------------------------------------- >>> > > > > Networks, Ericsson Research >>> > > > > >>> ---------------------------------------------------------------------- >>> > > > > Ericsson AB | Phone +46 10 7148287 >>> <+46%2010%20714%2082%2087> >>> > > > > Torshamnsgatan 23 | Mobile +46 73 0949079 >>> <+46%2073%20094%2090%2079> >>> > > > > SE-164 80 Stockholm, Sweden | mailto: >>> magnus.westerlund@ericsson.com >>> > > > > >>> ---------------------------------------------------------------------- >>> > > > > >>> > > > > >>> -- >>> Cheers >>> >>> Magnus Westerlund >>> >>> >>> ---------------------------------------------------------------------- >>> Networks, Ericsson Research >>> ---------------------------------------------------------------------- >>> Ericsson AB | Phone +46 10 7148287 >>> <+46%2010%20714%2082%2087> >>> Torshamnsgatan 23 | Mobile +46 73 0949079 >>> <+46%2073%20094%2090%2079> >>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>> ---------------------------------------------------------------------- >>> >>> >>> -- >> Sframe mailing list >> Sframe@ietf.org >> https://www.ietf.org/mailman/listinfo/sframe >> > --00000000000095450005ae33b9b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks=C2=A0Bernard. The SFrame draft intentionally avoide= d any RTP dependencies, but as referenced a generic frame marking extension= could be used to pass the media metadata in plaintext (but authenticated).= Of course the RTP header ext should be HBH encrypted.=C2=A0 Regarding pack= etization, yes a generic RTP packetizer will be used since the media will b= e encrypted. The frame=C2=A0marking ext will be used to define the frame bo= undaries.=C2=A0

That being said, we need a 2nd draft for= SFrame-RTP integration to cover this topic and potentially other=C2=A0topi= cs as well, which I promised I will work on sometime soon :-)=C2=A0

On= Mon, Aug 31, 2020 at 12:27 PM Bernard Aboba <bernard.aboba@gmail.com> wrote:
R= ichard said:=C2=A0

"in the most obvious SFrame+SRTP= case, there's a division of labor between the two protocols,=C2=A0&quo= t;

[BA] There is also an interaction between E2E e= ncryption and packetization that needs to be captured somewhere. In SFrame,= the packetization model is potentially different from PERC, because the SF= rame packetizer may not have visibility into the E2E encrypted payload (e.g= . the packetizer may not have access to the cleartext payload).=C2=A0 The i= mplication is that the information needed to packetize the E2E encrypted fr= ame (e.g. the metadata) needs to be provided to the packetizer.=C2=A0 This = info must be sufficient to fill in the RTP header fields as well as RTP hea= der extensions, including those RTP header extensions used by an SFU for fo= rwarding (e.g. frame-marking or Dependency Descriptor).=C2=A0=C2=A0

I'd note that the current SFrame draft does not addre= ss this yet, except for a figure including a "payload header" in = section 1.=C2=A0 It is my understanding that the "Payload Header"= represents info provided in the clear (such as the VP8 header), which is n= eeded by the packetizer.=C2=A0 Implementations that have encrypted this fie= ld or have not provided what was expected (e.g. attempts to utilize the H.2= 64/AVC codec) have encountered E2E encryption failures.=C2=A0
One approach to addressing this is to define a "generic pa= cketizer" for a transport that will be able to packetize and depacketi= ze the E2E encrypted frame in any codec.=C2=A0 If that work is indeed neede= d, then it should be described somewhere.=C2=A0

On Mon, Aug 31, = 2020 at 8:41 AM Richard Barnes <rlb@ipv.sx> wrote:
Hi Magnus,

I think the intent here is to have a mechanism that provides a subset of t= he security properties required for a given scenario, but which can be augm= ented with additional mechanisms to provide the rest.=C2=A0 For example, ev= en in the most obvious SFrame+SRTP case, there's a division of labor be= tween the two protocols, where SFrame only protects content, and SRTP also = protects the RTP header and guards against reply by network attackers.

So in a sense it is an intersection (in that it does s= omething that is needed by all the use cases), but it might need other thin= gs to provide all the properties you need in a given scenario.
--Richard

On Mon, Aug 31, 2020 at 10:06 AM Magnus Westerlun= d <m= agnus.westerlund@ericsson.com> wrote:
Hi,

Thanks for working on addressing my comments when on vacation.

I think you mostly arravied at a good place. However, I would like to make = one
remark about the added language.

When it comes to threat models it can't be the intersection of threats = across
those that occur in the intended usages, it needs to be the union of threat= s.
The formulation added implies intersection to me.

Cheers

Magnus

On Wed, 2020-08-12 at 11:11 -0400, Richard Barnes wrote:
> Hey all,
>
> I agree that all of this stuff is valuable to capture somewhere.=C2=A0= In the
> interest of keeping the charter fairly succinct, I've added the fo= llowing:
>
> """
> The SFrame specification will detail the specific security properties = that the
> encapsulation provides, and discuss their implications under common us= age
> scenarios / threat models.
> """
>
> With that, I think that all the comments we've gotten so far have = been
> addressed.
>
> --Richard
>
>
> On Fri, Aug 7, 2020 at 11:51 PM Alexandre GOUAILLARD <
> = Alex.GOUAILLARD@cosmosoftware.io> wrote:
> > guys,
> >
> > sorry for jumping in so late, quarantine here is very strict.
> >
> > We had long discussions about this specific point ahead of the dr= aft
> > submission.
> > We had reached the following consensus:
> > - there are multiple usage of media over the internet, e.g. confe= rencing and
> > streaming/broadcast
> > - they have very different threat/trust models, with different so= lutions
> > implemented today (transport layer E / E2EE / DRM / Encrypted Med= ia
> > Extentions / ...)
> > - they all can benefit from SFrame
> >
> > PERC was, by design, limited to RTP and to Conferencing. Many oth= er use case
> > coul benefit from Enhanced Privacy.
> >
> > We concluded that it would be better to keep SFrame (the media en= cryption
> > part, equivalent to PERC double conceptually), and to have separa= ted
> > documents that describe the threat models and the corresponding k= ey
> > exchange, signaling and system level decision for each use case. = Emad had
> > taken an action item for example to make two additional documents= to
> > describe the Video Conferencing use case, and how SFrame could be= used in
> > conjunction with MLS to address that specific use case. Someone e= lse could
> > take the different use case of the Browsers (which have a specifi= c trust
> > model) and make a document showing how SFrame con work with Inser= table Frame
> > API (and likely some more) to address that use case. CoSMo is int= erested in
> > doing the same thing for Real-Time streaming/Broadcasting.
> >
> > I think it is a more reasonable approach as, even spending a lot = of time
> > brainstorming with everyone around the tabel including bernard, w= e couldn't
> > think about one solution to fit all the different "media ove= r internet"'s
> > threat model. In my mind, each case should first have an informal= document
> > to define scope and threat model, and subsequent document to defi= ne the
> > corresponding specifications.
> > - Secure Conferencing Threat model (emad and co.)
> > - Secure Conferencing Signalling using MLS (emad and co.)
> > - Secure Conferencing using MLS In the browser (contributed by w3= c people)
> >
> > Magnus, what do you think?
> >
> > Regards,
> >
> > Dr. ALex.
> >
> >
> >
> > On Fri, Aug 7, 2020 at 2:02 AM Emad Omara <
> > emadomara=3D40google.com@dmarc.ietf.org> wrote:
> > > Thanks Magnus. I like the idea to explicitly call out the th= reat model, I
> > > think it will be good foundations that control all future de= sign
> > > decisions, however I'm not sure if the charter is the ri= ght place to call
> > > this out. I'd recommend having a separate document that = describes the
> > > system architecture, goals and threat model. What do you thi= nk?
> > >
> > > Emad
> > >
> > > On Thu, Aug 6, 2020 at 1:56 AM Magnus Westerlund <
> > > magnus.westerlund@ericsson.com> wrote:
> > > > Hi,
> > > >
> > > > On Wed, 2020-08-05 at 22:15 +0200, Sergio Garcia Murill= o wrote:
> > > > > But shouldn't the "delayed media" at= tack still be transport agnostic?
> > > > I
> > > > > mean, this can happen on QUIC and WebRTC SFUs.
> > > >
> > > > Sorry if I gave the impression that it is not transport= agnostic. It is
> > > > use case
> > > > dependent, any use case that isn't point to point, = where there is more
> > > > than one
> > > > entity that can intentionally remove SFRAME creating ga= ps in the SFRAME
> > > > sequence. In a point to point scenario one can correlat= e transport
> > > > losses with
> > > > SFRAME gaps to know give a reasonably strong mitigation= against any
> > > > third party
> > > > removing SFRAMEs or delaying them. That is much harder = in a centralized
> > > > conference with one or more SFU.
> > > >
> > > > >
> > > > > Anyway, I agree that while SFrame is transport agn= ostic, the chapter
> > > > > should not ignore the interactions with webrtc/qui= c and we must
> > > > ensure
> > > > > that we provide a complete working solution regard= less of the
> > > > transport.
> > > > > If we identify that any further working items are = required for a
> > > > > particular transport, we should at liaise with the= appropriate
> > > > working
> > > > > group for providing a solution.
> > > >
> > > > My main point is that SFRAME actually needs to discuss = the threat model
> > > > for the
> > > > use cases it intendes to solve. And the mitigation can = potentially
> > > > include
> > > > functionality on the transport level. But the risks to = media security in
> > > > centralized conferencing needs to be discussed. And cen= tralized
> > > > conferencing
> > > > will still have the semi-trusted SFUs and all the rest = of the third
> > > > parties in
> > > > addition to the end-points.
> > > >
> > > > Also what properties one have around end-points invited= into the
> > > > conference has
> > > > a number of question around security properties that ne= eds to be
> > > > discussed and
> > > > documented. Some examples that I know are relevant:
> > > >
> > > > - Source authentication: SRTP unless one use TESLA (whi= ch isn't really
> > > > used)
> > > > does only provided the property: Someone that has the k= ey sent this. One
> > > > don't
> > > > know that it comes from a particular endpoint.
> > > >
> > > > - Confidentiality when group membership changes: So wil= l SFRAME keying
> > > > support a
> > > > use case where only the current set of members in a con= ference can
> > > > decrypt the
> > > > media and one rekey the media session key for each time= the membership
> > > > changes?
> > > > PERC do support this, will SFRAME?
> > > >
> > > > There are likely more questions that needs discussion. = The PERC
> > > > discussion is a
> > > > good starting point, but I think when going transport a= gnostic some of
> > > > the
> > > > issues needs to be more clearly discussed as the RTP tr= ansport can have
> > > > affected
> > > > how it was discussed, and what reliance on existing mec= hanism. Which for
> > > > SFRAME
> > > > likely require a general discussion and then requiremen= ts on the
> > > > transport and
> > > > invovled endpoints and SFU to accomplish mitigations. A= nd thus also what
> > > > the
> > > > risks are of having no mitigation in place.
> > > >
> > > > I would really propose that SFRAME is chartered with pu= blishing a
> > > > security
> > > > consideration and threat model document that is seperat= e from the
> > > > solution to
> > > > give this topic full focus. The solution will of necess= ity need to
> > > > reference
> > > > that and document what migitagtions that exists in the = SFRAME layer and
> > > > what
> > > > becomes requirements on the transport.
> > > >
> > > > Cheers
> > > >
> > > > Magnus Westerlund
> > > >
> > > >
> > > > -------------------------------------------------------= ---------------
> > > > Networks, Ericsson Research
> > > > -------------------------------------------------------= ---------------
> > > > Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| Phone=C2=A0 +46 10 7148287
> > > > Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| Mobile +46 73 0949079
> > > > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericss= on.com
> > > > -------------------------------------------------------= ---------------
> > > >
> > > >
--
Cheers

Magnus Westerlund


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Mobile = +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--00000000000095450005ae33b9b2-- From nobody Mon Aug 31 20:23:16 2020 Return-Path: X-Original-To: expand-draft-hardie-dispatch-rfc3405-update.all@virtual.ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 5C99E3A094A; Mon, 31 Aug 2020 20:23:07 -0700 (PDT) X-Original-To: draft-hardie-dispatch-rfc3405-update.all@ietf.org Delivered-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B99233A093C; Mon, 31 Aug 2020 20:23:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Carpenter via Datatracker To: Cc: last-call@ietf.org, draft-hardie-dispatch-rfc3405-update.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159893058662.23844.17177953972396775177@ietfa.amsl.com> Reply-To: Brian Carpenter Date: Mon, 31 Aug 2020 20:23:06 -0700 Resent-From: Resent-To: ted.ietf@gmail.com, barryleiba@computer.org, superuser@gmail.com, barryleiba@gmail.com, spencerdawkins.ietf@gmail.com, dispatch@ietf.org Resent-Message-Id: <20200901032307.5C99E3A094A@ietfa.amsl.com> Resent-Date: Mon, 31 Aug 2020 20:23:07 -0700 (PDT) Archived-At: Subject: [dispatch] Genart last call review of draft-hardie-dispatch-rfc3405-update-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 03:23:07 -0000 Reviewer: Brian Carpenter Review result: Ready Gen-ART Last Call review of draft-hardie-dispatch-rfc3405-update-03 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-hardie-dispatch-rfc3405-update-03 Reviewer: Brian Carpenter Review Date: 2020-09-01 IETF LC End Date: 2020-09-24 IESG Telechat date: Summary: Ready (with micro-nit) -------- Nits: ----- > 1. Introduction > > Part five of the Dynamic Delegation Discovery System (DDDS), RFC 3405 > [RFC3405], describes the registration procedures for assignments in > URI.ARPA. The document requires that registrations be in the "IETF > tree" of URI registrations. The use of URI scheme name trees was > defined in RFC 2717 [RFC2717] but discontinued by RFC 4395 [RFC4395]. > Since the use of trees was discontinued, there is no way in the > current process set out in BCP 35 [RFC7595] to meet the requirement. This is indeed a nit, but I'd prefer s/the requirement/the above requirement/. The current text did make me briefly think "Which requirement?".