From nobody Wed Jun 3 16:13:51 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 AB1043A091E for ; Wed, 3 Jun 2020 16:13:50 -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 94vGIx1htlg8 for ; Wed, 3 Jun 2020 16:13:49 -0700 (PDT) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 B59853A0920 for ; Wed, 3 Jun 2020 16:13:49 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id a21so3390490oic.8 for ; Wed, 03 Jun 2020 16:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=T7Gn+wWYy9+M7/4l0JCjb9mjNOA5aS6CmaGY7kyiaAI=; b=t8eE2cmFp6X/gvkpqcSFsRBI0uAEvUNYK1Xnjudo+McCLYkGKHD8u7O/xb5TzBzDZJ ZETCY4mc9FcnNjIc4nkdOFWhnzCG4yT69JvdXfmPpX3TMocvNLtfJeof5jh0Fw4Id0S6 zmEVmeUeNrhBjo1gYVTYog1SkkQZriEOw3jGFRfKKjF/oo49NXqeFci+QQ4/Cg5xEza9 sVg6MjYb8Kqv1SNeY87U89PdPDi0BPtm1hUhAcoZGWkgUWdFymF38cZdKnyAI/mh2aZb fpxXAeNARV6P2sEVpu+vGlU1V6q6hbbyNLxjGBuU0ITQg4bFfhjCDxr+7EwR0ZS0aE6K PQlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=T7Gn+wWYy9+M7/4l0JCjb9mjNOA5aS6CmaGY7kyiaAI=; b=Ug67AAwt92jJ77/my1Fs8jdCCBRLniLqTjzpq/Y2Z6yBoUczUlsusPmRDkF3h5XPdT /EI760Xc2gSQ5TaI4aPc0BlrdSg0/pRCy2o5KUEjJZBrIR9Rim9FdJpADTjgGJGJYWHx 5pECh4B591BWZsLvxkAJ7vBYYDqsCrQBrO6PZrPD6P2dworQUxUNYQVd+STxGhH4qkQw LZShBtB9DOc8U2sBfywK1xvug40EELNDnjKP4l4Ld2X4XR6KTz33P5wZ5TkKe+FiYiIl oS7/MaMFnSWPHoEeJbI7KDWhXjVwhomcPjzkDoa10RqQOyaMqDgbiXzv45B0nOlyKwBm hbGg== X-Gm-Message-State: AOAM530q2eU4lgalENfIUbpjk7klOCm/Aeri3447gVBA+mm+jjO50g+N z1AAHrRkk1x9UJ6CsPHqKKf4oL2P+7yluooqGSOSh4HT X-Google-Smtp-Source: ABdhPJx4vVSdEKvINyAzpdYqSV3znIh4b2iIRrUTDpyJahwRbXRI/uiVMU5OQM3StBu8QgynqOkZqOEECT6jCoSvzEM= X-Received: by 2002:a54:4495:: with SMTP id v21mr1362149oiv.35.1591226027633; Wed, 03 Jun 2020 16:13:47 -0700 (PDT) MIME-Version: 1.0 From: Ted Hardie Date: Wed, 3 Jun 2020 16:13:21 -0700 Message-ID: To: Dispatch WG Content-Type: multipart/alternative; boundary="0000000000002272f905a7362e03" Archived-At: Subject: [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, 03 Jun 2020 23:13:51 -0000 --0000000000002272f905a7362e03 Content-Type: text/plain; charset="UTF-8" Howdy, This is one the shortest drafts I've ever written: 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 --0000000000002272f905a7362e03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

This is one the short= est drafts I've ever written:=C2=A0 https://datatracker.ietf.or= g/doc/draft-hardie-dispatch-rfc3405-update/ .=C2=A0=C2=A0 Basically, RF= C 3405 used to require that registrations in URI.ARPA be from the "IET= F Tree".=C2=A0 That tree was deprecated after the document was publish= ed.=C2=A0 As it happens, there are very few registrations in URI.ARPA, so w= e did not catch it and fix it before now.=C2=A0

This draft updates RFC 3405 to require "permanent" scheme regi= strations.=C2=A0 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 Hardi=
e
--0000000000002272f905a7362e03-- From nobody Thu Jun 4 17:08:27 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 DD81F3A109A for ; Thu, 4 Jun 2020 17:08:24 -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, 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 (1024-bit key) header.d=ducksong.com header.b=hL9c1y/W; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=YT+45002 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 yyQaJjntCt09 for ; Thu, 4 Jun 2020 17:08:23 -0700 (PDT) Received: from outbound5d.ore.mailhop.org (outbound5d.ore.mailhop.org [100.20.105.3]) (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 014213A1098 for ; Thu, 4 Jun 2020 17:08:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591315702; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=QVbAcRVUr8jGfnyP4lWBITlB7FfIHKBOINu6XoZUsMHJ9QFQUM9hJ84rpuwZbdG8axxRRUJfiZZ6z oCGR+mJs+osngQGa6bUrN+dToKYqL4oo2muc646xaAZb5ADSyVwaw8va08fHNVrzw85XjH6k0ZKT5P rQQ7lyTG+6aDt6IebdTiE3unmITAD4hvfaot4SAKJNi7CcJMrQ4MP0yLljJHqxrZw/RP8+7lupwPPB eHAqSQngPOe0nnDsNuC1MJZYGhSebJJsByASpacT/K6iilIdUSEtjuiIVDmnJaOacYXX01QfQMtkzt JM12bkuHqTzjg8Z8i30/FIDKWnH7V3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=w5zZa8P4DdJ5FN8E+8to4umOhcQtz0MtQEosCuoDAjU=; b=Lc3Mo+QAam5+74nibs8T0W2j0Lj06PKfM/jPgnoHLYEfGDiczk7MwDmJxrnl1V8kdLw7Qn/smOYyQ vn19n2Xz3zmdUD/HOYLSZitJhBq0GNh41RaIN248Jr0jPEk1GS2oEyydUaOoPRxqBfxv14GNFOS2N+ eLT6VOZXxUXmzcL1qwnqp8KE9tj2a+YW4XYOmsRvh1im1w+AdVkeaYVJ6wezR+kqm68cWV1YWSULC4 5PHCxp6jfwouemsJHAeYG/XdCKedl77ij/CZTwCa08JHV/kXCDyUmGauAxQ6YLEgImkgos20mZTdaM eYxKYZ9omRqDqLPD+m29RwGmFQs5pcw== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.167.180; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=w5zZa8P4DdJ5FN8E+8to4umOhcQtz0MtQEosCuoDAjU=; b=hL9c1y/WWD8kTlzFwv5fPtL608gZr59BN+KW6kbuZdGX7Yw/qoShRc6YlmLFaMIsuZ5N6AufZ7RRO QykFoelFCqwsV9STUX4XGk0wfRHMrUg47RaGwZHZXCRRLlWW545JasEhBKX5IbiA3UjlHox6YZIYvk EWihlj27jbY/35gg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=w5zZa8P4DdJ5FN8E+8to4umOhcQtz0MtQEosCuoDAjU=; b=YT+45002ZH3j6vqHDb/J3+n3I6O/KRn7U6lhV5BBFF5iEU1M9WqwbV8oERNq1LCr6iK2NJxVSFJio ZRqus0cy3Kzx1lRw2HAx/IJQ2Oo2hx2G1jYdVy5PG8Em+w++IGnbJ8unvHnfInSbwiHk2AuvDPY0BK gOns7CIJmtZbWBOnUjYyoxFtp6Wm9uyLJ6YbiK/7cuttgtXAPGh2hTl7CjbgdJRrRghSM43StZwtvx pljQFsPt+A2MPhEAZcpOsCD11xn6/VDrSR940iYprANp9POOPWNBhoJ1+20nQ4bNIDNhBrVo/vpsB1 Wfh9kyhmse+/PWueMCU8mPTKuC+YqKA== X-MHO-RoutePath: bWNtYW51cw== X-MHO-User: a9ce60a0-a6c0-11ea-b10c-b5956a7dd1a1 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 209.85.167.180 X-Mail-Handler: DuoCircle Outbound SMTP Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com [209.85.167.180]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id a9ce60a0-a6c0-11ea-b10c-b5956a7dd1a1; Fri, 05 Jun 2020 00:08:20 +0000 (UTC) Received: by mail-oi1-f180.google.com with SMTP id 25so5803734oiy.13 for ; Thu, 04 Jun 2020 17:08:20 -0700 (PDT) X-Gm-Message-State: AOAM530mQLKqkNhHyot3B7aVRayl85KLrVG9E3lEa9KyW57L2aw3hxUx gQ9Ky2PWjpdq4NtJdhRNz5uGe2Aa/2+qWu+IFUg= X-Google-Smtp-Source: ABdhPJzyf5PDlE1GMKiDlufQ6LelY/6xGpPHAPey/+/QKJr1nVT+yAS1QcmA3Fz6C7t4Cnn0MeWYoqSSI9HytLza2P8= X-Received: by 2002:aca:5b0b:: with SMTP id p11mr307343oib.82.1591315699919; Thu, 04 Jun 2020 17:08:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Patrick McManus Date: Thu, 4 Jun 2020 20:08:08 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Ted Hardie Cc: Dispatch WG Content-Type: multipart/alternative; boundary="00000000000004ef4b05a74b0fc7" 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: Fri, 05 Jun 2020 00:08:25 -0000 --00000000000004ef4b05a74b0fc7 Content-Type: text/plain; charset="UTF-8" does the group have any thoughts on what the appropriate dispatch for Ted's work (below) would be? We certainly can do this outside of a list if there is participation and rough consensus.. would be good to build that skill in this remote-only period, right? -Patrick On Wed, Jun 3, 2020 at 7:13 PM Ted Hardie wrote: > Howdy, > > This is one the shortest drafts I've ever written: > 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 > --00000000000004ef4b05a74b0fc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
does the group have any thoughts on what the appropriate d= ispatch for Ted's work (below) would be?

We certainly can do thi= s outside of a list if there is participation and rough consensus.. would b= e good to build that skill in this remote-only period, right?

-Patrick


On Wed, Jun 3, 2020 at 7:13 PM Ted Hardi= e <ted.ietf@gmail.com> wrot= e:
Howdy,

This is one the shortest drafts I&= #39;ve ever written:=C2=A0 https://datatracker.i= etf.org/doc/draft-hardie-dispatch-rfc3405-update/ .=C2=A0=C2=A0 Basical= ly, RFC 3405 used to require that registrations in URI.ARPA be from the &qu= ot;IETF Tree".=C2=A0 That tree was deprecated after the document was p= ublished.=C2=A0 As it happens, there are very few registrations in URI.ARPA= , so we did not catch it and fix it before now.=C2=A0

This draft updates RFC 3405 to require "permanent" schem= e registrations.=C2=A0 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 Hardi=
e
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--00000000000004ef4b05a74b0fc7-- From nobody Thu Jun 4 17:30: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 70B143A10C5 for ; Thu, 4 Jun 2020 17:30:20 -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_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=Rg6XA+O+; dkim=pass (2048-bit key) header.d=kitterman.com header.b=AGnko6os 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 fTqj8duakvL6 for ; Thu, 4 Jun 2020 17:30:17 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 763663A10D7 for ; Thu, 4 Jun 2020 17:29:58 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id C343EF8030C; Thu, 4 Jun 2020 20:29:54 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1591316994; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=dUzElARHvl/14DCmNovfrkt/IPZ2Z86fwskCw14RphQ=; b=Rg6XA+O+z0hKt7uO1UCHTeLwj5P1F/1UsdVwscjQRwnQdCiXfXX8X17yhstfyZWM4Y4qv Nba55m9su6ZZWPICw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1591316994; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=dUzElARHvl/14DCmNovfrkt/IPZ2Z86fwskCw14RphQ=; b=AGnko6osqV9PyiZi8LLAOrMJW1k4lN13/xc49TuP6TLZDjRHfxMBnv7Qi5RUzumF9eJoX qPN2lAWRpQNKhBCn9iclrBOUKi+qke1+Yl4JAQxDfTA2fCTtzcOfmuc3UVK5QVM7QlmDDYs yB4g34YPDk0E5d3XOTgP221wZMI7i/0O8v2s+gklBQOfHWxlLgT3YrjaXggnHbkwjyJjU4U C526dC+kgVNWs56tFvTgCnGn90lnoizVUMSjBgGvas7pxdXoNAlNx2pfhrY8N+eMX5dqYfU R8lPKh/kOSaJsNRwHTfjYCnEItkJYlTAx5oMub8gZy1eDA/UPL0rshZF1VRg== Received: from [192.168.1.184] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 8DA09F80256; Thu, 4 Jun 2020 20:29:54 -0400 (EDT) Date: Fri, 05 Jun 2020 00:29:53 +0000 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dispatch@ietf.org From: Scott Kitterman Message-ID: <836C0462-1643-45E2-AD78-84B1F1BF3534@kitterman.com> 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: Fri, 05 Jun 2020 00:30:20 -0000 What did you have in mind as an alternative to an mailing list? Scott K On June 5, 2020 12:08:08 AM UTC, Patrick McManus = wrote: >does the group have any thoughts on what the appropriate dispatch for >Ted's >work (below) would be? > >We certainly can do this outside of a list if there is participation >and >rough consensus=2E=2E would be good to build that skill in this remote-on= ly >period, right? > >-Patrick > > >On Wed, Jun 3, 2020 at 7:13 PM Ted Hardie wrote: > >> Howdy, >> >> This is one the shortest drafts I've ever written: >> >https://datatracker=2Eietf=2Eorg/doc/draft-hardie-dispatch-rfc3405-update= / >> > >> =2E Basically, RFC 3405 used to require that registrations in >URI=2EARPA be >> from the "IETF Tree"=2E That tree was deprecated after the document >was >> published=2E As it happens, there are very few registrations in >URI=2EARPA, so >> we did not catch it and fix it before now=2E >> >> This draft updates RFC 3405 to require "permanent" scheme >registrations=2E >> The salient bit is this: >> >> All registrations in URI=2EARPA MUST be for schemes which are permanent >> registrations, as they are described in BCP 35=2E >> >> I'm hoping for a quick dispatch of this, but happy to discuss=2E >> >> regards, >> >> Ted Hardie >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf=2Eorg >> https://www=2Eietf=2Eorg/mailman/listinfo/dispatch >> From nobody Fri Jun 5 12:03:09 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 3A2693A0D14 for ; Fri, 5 Jun 2020 12:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 m0k9_ZmuJAtu for ; Fri, 5 Jun 2020 12:03:05 -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 1612E3A0E52 for ; Fri, 5 Jun 2020 12:02:37 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 055J2Uek018065 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 5 Jun 2020 14:02:31 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1591383751; bh=uFJsds6C+Je3uAoWDOg6vLbZoU+d957hcrp0ntVZqSA=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=PesPEUmx/BdADLJerzpO2YKo38BqDtT7JMhYE5Tp2AWAUB639zNlzM1wekZfEuaZa JQGoxsT0mxVJzRZGuXvkFUxT/0OHgtLpiyohzi5EPRjo3PN29VnltEhUl9dwHVENYK Z5hCH9yCy+sQripIn4uRXc4CjAXsBeDPhKbsu01I= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: Patrick McManus , Ted Hardie Cc: Dispatch WG References: From: Robert Sparks Message-ID: <71571b9b-4bbd-47bb-c6db-bf0b91ef5a53@nostrum.com> Date: Fri, 5 Jun 2020 14:02:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3319ED88A868445271B52AAC" Content-Language: en-US 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: Fri, 05 Jun 2020 19:03:07 -0000 This is a multi-part message in MIME format. --------------3319ED88A868445271B52AAC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I don't think there's work to do here that Ted's not already done - the draft looks ready to IETF LC. My preference would be to dispatch this to an AD to sponsor it, and let it go. RjS On 6/4/20 7:08 PM, Patrick McManus wrote: > does the group have any thoughts on what the appropriate dispatch for > Ted's work (below) would be? > > We certainly can do this outside of a list if there is participation > and rough consensus.. would be good to build that skill in this > remote-only period, right? > > -Patrick > > > On Wed, Jun 3, 2020 at 7:13 PM Ted Hardie > wrote: > > Howdy, > > This is one the shortest drafts I've ever written: > 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 --------------3319ED88A868445271B52AAC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I don't think there's work to do here that Ted's not already done - the draft looks ready to IETF LC. My preference would be to dispatch this to an AD to sponsor it, and let it go.

RjS

On 6/4/20 7:08 PM, Patrick McManus wrote:
does the group have any thoughts on what the appropriate dispatch for Ted's work (below) would be?

We certainly can do this outside of a list if there is participation and rough consensus.. would be good to build that skill in this remote-only period, right?

-Patrick


On Wed, Jun 3, 2020 at 7: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/ .   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
--------------3319ED88A868445271B52AAC-- From nobody Tue Jun 9 07:42:51 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 0BE603A0789; Tue, 9 Jun 2020 07:42:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: mcmanus@ducksong.com, dispatch@ietf.org, barryleiba@computer.org, dispatch-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159171376897.13693.10181570440307581475@ietfa.amsl.com> Date: Tue, 09 Jun 2020 07:42:48 -0700 Archived-At: Subject: [dispatch] dispatch - New Meeting Session Request for IETF 108 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, 09 Jun 2020 14:42:49 -0000 A new meeting session request has just been submitted by Patrick McManus, a Chair of the dispatch working group. --------------------------------------------------------- Working Group Name: Dispatch Area Name: Applications and Real-Time Area Session Requester: Patrick McManus Number of Sessions: 1 Length of Session(s): 100 Minutes Number of Attendees: 90 Conflicts to Avoid: Chair Conflict: rum ice stir sipcore mmusic ecrit avtcore cfrg quic httpbis add Technology Overlap: perc cellar capport dmarc jmap uta rmcat extra core opsarea tsvarea tsvwg tram secdispatch Key Participant Conflict: acme cose dprive lamps tls mls People who must be present: Barry Leiba Ben Campbell Murray Kucherawy Patrick McManus Resources Requested: Special Requests: Please schedule in the 1st slot on Monday morning, list the meeting as coupled with ARTAREA. Please avoid conflicts with other ART area WGs and BoFs, other area meetings, and Bofs.. --------------------------------------------------------- From nobody Tue Jun 9 13:22:47 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 5C5B43A097A for ; Tue, 9 Jun 2020 13:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 ZCJH2tQ7rySR for ; Tue, 9 Jun 2020 13:22:37 -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 E4BF03A0969 for ; Tue, 9 Jun 2020 13:22:23 -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 059KMEPD031871 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 9 Jun 2020 15:22:15 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1591734135; bh=5vVNWD0sNiqulT2Wv/FjHglq5Xurz3vO0CoCD+UrPYE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=SLEajkQr0nPcSOkIDmhyD42iKnuI2OIANi7FSeqOPR1x+gxTCFxPewvLI9geh5HWB pCxqAOfbbLMCpOwiANZ7U2JuAYWlgKkqQaUxUYzt7Fj4IcxEB8EybL9g6ALs0uTTBc 55WSZO4IXMaCCQGyzbcc0vGRrcHaO81G+j4sGthc= 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.80.23.2.2\)) From: Ben Campbell In-Reply-To: Date: Tue, 9 Jun 2020 15:22:07 -0500 Cc: Dispatch WG Content-Transfer-Encoding: quoted-printable Message-Id: <67C68A2B-77E6-4828-AF33-7675893255DB@nostrum.com> References: To: Ted Hardie X-Mailer: Apple Mail (2.3608.80.23.2.2) 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: Tue, 09 Jun 2020 20:22:46 -0000 (no hats) I agree with Robert that this is a reasonable candidate to be AD = sponsored. I propose the following edit to section 2, just to be formal about = things. (I recognize it=E2=80=99s a bit pedantic :-) ) OLD: All registrations in URI.ARPA MUST be for schemes which are permanent = registrations, as they are described in BCP 35 . NEW:=20 This document removes the normative requirement in [RFC 3405] for = registrations in URI.ARPA to be in the IETF URI Tree.=20 All registrations in URI.ARPA MUST be for schemes which are permanent = registrations, as they are described in BCP 35. Ben. > On Jun 3, 2020, at 6:13 PM, Ted Hardie wrote: >=20 > Howdy, >=20 > This is one the shortest drafts I've ever written: = 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. =20 >=20 > This draft updates RFC 3405 to require "permanent" scheme = registrations. The salient bit is this: >=20 > All registrations in URI.ARPA MUST be for schemes which are permanent > registrations, as they are described in BCP 35. >=20 >=20 > I'm hoping for a quick dispatch of this, but happy to discuss. >=20 > regards, >=20 > Ted Hardie > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Tue Jun 9 13:35:51 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 B7F413A0817 for ; Tue, 9 Jun 2020 13:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 WeRdsITms-oz for ; Tue, 9 Jun 2020 13:35:47 -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 984DC3A0812 for ; Tue, 9 Jun 2020 13:35:47 -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 059KZiqZ034694 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 9 Jun 2020 15:35:45 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1591734945; bh=cg2OBjqrABCpKZB5VZBhWo4iNA/rHe+1+3byolH9W7I=; h=From:Subject:Date:To; b=VTlgEgVwJ+qMjm/HV8Wn3yRgo5wQQmAQ1rEB69N3BiSoJWiwvVnJWTndQvUsIJ9y4 tDd8qPd6tGHq8XDL7Mam7qdm8nxFpJfKKS0oAh42nh6UMBE7MbIrH2m4B7BH+ESqIU kzb+lvNZxXi5auBu2BI7P2PUPNmYUzL3VPm4oPKk= 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=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <755A78AD-7285-4B88-9170-4B30E5249012@nostrum.com> Date: Tue, 9 Jun 2020 15:35:36 -0500 To: Dispatch WG X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [dispatch] IETF 108 Topics 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, 09 Jun 2020 20:35:51 -0000 Hi Everyone, The DISPATCH chairs need to come up with an agenda for our IETF108 = meeting (the meeting formerly known as Madrid). Are people aware of = topics that need higher-bandwidth discussion, either for DISPATCH or the = ART Area? Thanks! Ben.= From nobody Tue Jun 9 13:43:27 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 26BDD3A08D5 for ; Tue, 9 Jun 2020 13:43:19 -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 3bG2w3Dj6tRG for ; Tue, 9 Jun 2020 13:43:16 -0700 (PDT) Received: from mail-oo1-xc31.google.com (mail-oo1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) (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 AC43B3A08FF for ; Tue, 9 Jun 2020 13:43:15 -0700 (PDT) Received: by mail-oo1-xc31.google.com with SMTP id h7so29918ooc.9 for ; Tue, 09 Jun 2020 13:43:15 -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=OTGlhdC98UwFqXPCUJwWDFAAm4DSObgsUFMZ0cU4ktM=; b=m5eVJFdRmy7FraMlqFc1WN4xSQqzeHAprWtPzIaO12PhQEPHLnbZqD31Ci8gic2LVr xs7s2OdSJMD1tc4AXhuAA/auc7b4oybcpm3whT+uJSHWDuhuM8BTCUkHAEs00ro1eI2U AYrpUXLFX+2ipHq+HhUweq+r4jh0+yItbrnEMDZbKezpdBSDlEdseCg9g+OrgLsZxlTK r2gBODNlVPxu4VfVfgKUNhIMUsdFZgvQPzoLBZ0gwRxsOW99xuMEHsDGO5tBROkO7YTj 36Si2mFSsi3P50PNXF/HZrZgAAr2cOgNsf59V7bxdDQTiE37dTpzXeth8+qGgZ4iW0G3 9HpA== 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=OTGlhdC98UwFqXPCUJwWDFAAm4DSObgsUFMZ0cU4ktM=; b=GiBPPQR4Eelh+M60UTBzDM/IJAL4u9Njip8NKneRRrAp6M+4umwAivyOnTqMmLVD/5 AZ5itX0docj7a1nz7vSVPJbtBh1FEKw3mVi0L8FgCr3LoITFx3Tk7bM1bqy8JQKN6obG XlLk1y3TyLPnIjgz8RhvBdX2yUABWJ7LmtdyWr/b0kJSu/LcFlErPwG+/YxcCTj/8jVB 4tlmUr1FVrOGSMWx0jqwmgjSCfQEmKwKe9gt93g53/6Tw1qes70RBNiI1CexEH+hq/Rq WawlR+Vpj2PTLBkT2c+UWb+IEtj/0pOd5JYttruX3Lmt0Efpe1PxEXk2WLlYq0eegSVu tPZw== X-Gm-Message-State: AOAM531ArGp4zzKu312ABp3KoFGgy2LwHqNOT0wMl7aUG7NpuMzbb5vR 2WaMb40+wA7pydJKJigk6E++ziPnYqL0FmhZduXRIQ== X-Google-Smtp-Source: ABdhPJzkivz1Xea4JyYyGiyRLm3a4LN4cg5cLsROTfdMyyBkz3mxGGawf+fh9eoEqdtpeXHMnt8YOefSnbXom77xw5Q= X-Received: by 2002:a4a:345b:: with SMTP id n27mr2640126oof.25.1591735394994; Tue, 09 Jun 2020 13:43:14 -0700 (PDT) MIME-Version: 1.0 References: <67C68A2B-77E6-4828-AF33-7675893255DB@nostrum.com> In-Reply-To: <67C68A2B-77E6-4828-AF33-7675893255DB@nostrum.com> From: Ted Hardie Date: Tue, 9 Jun 2020 13:42:48 -0700 Message-ID: To: Ben Campbell Cc: Dispatch WG Content-Type: multipart/alternative; boundary="000000000000cb8c2605a7acc6f8" 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: Tue, 09 Jun 2020 20:43:25 -0000 --000000000000cb8c2605a7acc6f8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the review, Ben. This change is made in my working copy; I'll upload that when we get a dispatch decision or after receiving other updates. Ted On Tue, Jun 9, 2020 at 1:22 PM Ben Campbell wrote: > (no hats) > > I agree with Robert that this is a reasonable candidate to be AD sponsore= d. > > I propose the following edit to section 2, just to be formal about things= . > (I recognize it=E2=80=99s a bit pedantic :-) ) > > OLD: > All registrations in URI.ARPA MUST be for schemes which are permanent > registrations, as they are described in BCP 35 > . > NEW: > This document removes the normative requirement in [RFC 3405] for > registrations in URI.ARPA to be in the IETF URI Tree. > > All registrations in URI.ARPA MUST be for schemes which are permanent > registrations, as they are described in BCP 35. > > Ben. > > > > > > On Jun 3, 2020, at 6:13 PM, Ted Hardie wrote: > > > > Howdy, > > > > This is one the shortest drafts I've ever written: > https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ . > Basically, RFC 3405 used to require that registrations in URI.ARPA be fr= om > 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 > > --000000000000cb8c2605a7acc6f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review, Ben.=C2=A0 This change is made= in my working copy; I'll upload that when we get a dispatch decision o= r after receiving other updates.

Ted

On T= ue, Jun 9, 2020 at 1:22 PM Ben Campbell <ben@nostrum.com> wrote:
(no hats)

I agree with Robert that this is a reasonable candidate to be AD sponsored.=

I propose the following edit to section 2, just to be formal about things. = (I recognize it=E2=80=99s a bit pedantic :-) )

OLD:
All registrations in URI.ARPA MUST be for schemes which are permanent regis= trations, as they are described in BCP 35
.
NEW:
This document removes the normative requirement in [RFC 3405] for registrat= ions in URI.ARPA to be in the IETF URI Tree.

All registrations in URI.ARPA MUST be for schemes which are permanent regis= trations, as they are described in BCP 35.

Ben.




> 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:=C2=A0 https://datatracker.ietf.org/doc/draf= t-hardie-dispatch-rfc3405-update/ .=C2=A0 =C2=A0Basically, RFC 3405 use= d to require that registrations in URI.ARPA be from the "IETF Tree&quo= t;.=C2=A0 That tree was deprecated after the document was published.=C2=A0 = As it happens, there are very few registrations in URI.ARPA, so we did not = catch it and fix it before now.=C2=A0
>
> This draft updates RFC 3405 to require "permanent" scheme re= gistrations.=C2=A0 The salient bit is this:
>
> All registrations in URI.ARPA MUST be for schemes which are permanent<= br> >=C2=A0 =C2=A0 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.o= rg
> https://www.ietf.org/mailman/listinfo/dispatch

--000000000000cb8c2605a7acc6f8-- From nobody Tue Jun 9 13:56: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 D69003A086C for ; Tue, 9 Jun 2020 13:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, 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 K-swPQPTn9Kw for ; Tue, 9 Jun 2020 13:56:49 -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 246EB3A0921 for ; Tue, 9 Jun 2020 13:56:43 -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 059Kub5U038889 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 9 Jun 2020 15:56:38 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1591736199; bh=zjJOqEFIrciDnDY9iiiKIAv4HSinuMtIEwjispMqHk0=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=v/VgTPZerZsmNtUQ3Jdxbo6OXESuBEmrU/nLlNrwgjShkVHhxRJi5tejGQ80iQ7pJ BfEUNmE22NzJCKNQqL96Ps+kp8tte8xJlVpxHNVk7hyUBRkb4czLtehwQmemDi+If1 B9KJPXyODgBYninZViEgWEJpCucAL9ymZkjeugPQ= 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 Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_463A8557-AA4E-47E6-9837-883957452DFC" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 9 Jun 2020 15:56:30 -0500 In-Reply-To: <71571b9b-4bbd-47bb-c6db-bf0b91ef5a53@nostrum.com> Cc: Patrick McManus , Ted Hardie , Dispatch WG To: Robert Sparks References: <71571b9b-4bbd-47bb-c6db-bf0b91ef5a53@nostrum.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) 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: Tue, 09 Jun 2020 20:56:52 -0000 --Apple-Mail=_463A8557-AA4E-47E6-9837-883957452DFC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Does anyone disagree with Robert=E2=80=99s recommendation for DISPATCH = to recommend this become AD sponsored? Thanks! Ben. > On Jun 5, 2020, at 2:02 PM, Robert Sparks = wrote: >=20 > I don't think there's work to do here that Ted's not already done - = the draft looks ready to IETF LC. My preference would be to dispatch = this to an AD to sponsor it, and let it go. >=20 > RjS >=20 > On 6/4/20 7:08 PM, Patrick McManus wrote: >> does the group have any thoughts on what the appropriate dispatch for = Ted's work (below) would be? >>=20 >> We certainly can do this outside of a list if there is participation = and rough consensus.. would be good to build that skill in this = remote-only period, right? >>=20 >> -Patrick >>=20 >>=20 >> On Wed, Jun 3, 2020 at 7:13 PM Ted Hardie > wrote: >> Howdy, >>=20 >> This is one the shortest drafts I've ever written: = 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. =20 >>=20 >> This draft updates RFC 3405 to require "permanent" scheme = registrations. The salient bit is this: >>=20 >> All registrations in URI.ARPA MUST be for schemes which are permanent >> registrations, as they are described in BCP 35. >>=20 >> I'm hoping for a quick dispatch of this, but happy to discuss. >>=20 >> regards, >>=20 >> Ted Hardie >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch = >>=20 >>=20 >> _______________________________________________ >> 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 --Apple-Mail=_463A8557-AA4E-47E6-9837-883957452DFC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Does = anyone disagree with Robert=E2=80=99s recommendation for DISPATCH to = recommend this become AD sponsored?

Thanks!

Ben.

On Jun = 5, 2020, at 2:02 PM, Robert Sparks <rjsparks@nostrum.com> wrote:

=20 =20

I don't think there's work to do here = that Ted's not already done - the draft looks ready to IETF LC. My preference would be to dispatch this to an AD to sponsor it, and let it go.

RjS

On 6/4/20 7:08 PM, Patrick McManus wrote:
does the group have any thoughts on = what the appropriate dispatch for Ted's work (below) would be?

We certainly can do this outside of a list if there is participation and rough consensus.. would be good to build that skill in this remote-only period, right?

-Patrick


On Wed, Jun 3, 2020 at = 7: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/ .   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.o=
rg/mailman/listinfo/dispatch
_______________________________________________
dispatch = mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --Apple-Mail=_463A8557-AA4E-47E6-9837-883957452DFC-- From nobody Tue Jun 9 13:58:00 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 B7AC53A086E for ; Tue, 9 Jun 2020 13:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.276, 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 9Nr66RDboNTE for ; Tue, 9 Jun 2020 13:57:57 -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 708613A086B for ; Tue, 9 Jun 2020 13:57:57 -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 059Kvr9Z039223 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 9 Jun 2020 15:57:55 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1591736275; bh=QMDZIxWo01t0Ivcs7ptBSmDu4DyGfw5kWfYT+MePk9o=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=gNzdPbiW9qy1TCMLOJfCruN9gmkBhdBABA8L+Z9tjFHbrCHVRo5nLfmXpqxQi5odl 2K0DjFS0hcxzsjD8/+wvUxjgj6ghVvhuQkAohXn1D85M8upKa4Qc9ClCyPFLNrU4f0 Xq5BlAi9U4xJI495njSLfDigb4gV0io6RdCgWDJM= 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.80.23.2.2\)) From: Ben Campbell In-Reply-To: <836C0462-1643-45E2-AD78-84B1F1BF3534@kitterman.com> Date: Tue, 9 Jun 2020 15:57:45 -0500 Cc: Dispatch WG , Patrick McManus Content-Transfer-Encoding: quoted-printable Message-Id: <49903CF4-A164-4350-AC1F-4DF7A1A75440@nostrum.com> References: <836C0462-1643-45E2-AD78-84B1F1BF3534@kitterman.com> To: Scott Kitterman X-Mailer: Apple Mail (2.3608.80.23.2.2) 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: Tue, 09 Jun 2020 20:57:59 -0000 I suspect Patrick meant =E2=80=9Coutside of a working group=E2=80=9D. = Patrick? > On Jun 4, 2020, at 7:29 PM, Scott Kitterman = wrote: >=20 > What did you have in mind as an alternative to an mailing list? >=20 > Scott K >=20 > On June 5, 2020 12:08:08 AM UTC, Patrick McManus = wrote: >> does the group have any thoughts on what the appropriate dispatch for >> Ted's >> work (below) would be? >>=20 >> We certainly can do this outside of a list if there is participation >> and >> rough consensus.. would be good to build that skill in this = remote-only >> period, right? >>=20 >> -Patrick >>=20 >>=20 >> On Wed, Jun 3, 2020 at 7:13 PM Ted Hardie wrote: >>=20 >>> Howdy, >>>=20 >>> This is one the shortest drafts I've ever written: >>>=20 >> = https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ >>>=20 >> = >>> . 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. >>>=20 >>> This draft updates RFC 3405 to require "permanent" scheme >> registrations. >>> The salient bit is this: >>>=20 >>> All registrations in URI.ARPA MUST be for schemes which are = permanent >>> registrations, as they are described in BCP 35. >>>=20 >>> I'm hoping for a quick dispatch of this, but happy to discuss. >>>=20 >>> regards, >>>=20 >>> Ted Hardie >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>>=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Tue Jun 9 14:13:00 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 985E03A08E1 for ; Tue, 9 Jun 2020 14:12:59 -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 wQ7dNtvJccVa for ; Tue, 9 Jun 2020 14:12:58 -0700 (PDT) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 218BA3A08CB for ; Tue, 9 Jun 2020 14:12:58 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id t25so71079oij.7 for ; Tue, 09 Jun 2020 14:12: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=kvtLAEz80TNXrIMiMVeaBzg2W9bq1lYfWHZ+X0j2CAo=; b=Sfpj1eL1MgZhi7VjUUpHy2ZYiWsRA77T2/2lMLXFAlFs8oVNipvAU23S6O7P/9LaTE E2KGhWAq2okTfMmp8HLi1UfqDX+OyVaCmIj4ScMDrrFwVqxbayVdBQbvhQdb5KjHiRQP KMS+4w2u605qMI2Q84ok3zeNWUNKfFjPdJ2QK4EuiViadyku0FDQLkv7Q8ZeI/pCeH7c 6cj67e2futpktJ/Ig308Ib9tg5xuqxQJ8ZUb2HjrqgCA+pc4FgM8jgXeCYR+bj+imgY0 D1zazbTSRmBqaKanDOqQ7IAcEmAsCu5yKLJ9uA8oJ0cRIxY6DycHkMnTTp71w8+i57X8 JTSA== 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=kvtLAEz80TNXrIMiMVeaBzg2W9bq1lYfWHZ+X0j2CAo=; b=P+sWPK2J0wbphXfy58IMW4OCTDFcBEz0XH/JtvvqgQR1r4LawE7IRhnDee/bfKTb2E UGWZdcNYgDV3N3R1ZTN/ic9eZt7GivWuCRmdyKlgtPyFzPFVB4so5tu8CtjYTCLoB+RC nwFJIevwYX9d5rjHotU8oEvzBodStLPVwhmj92YuqANsTfqYuglcNfDQ6BKRX/1zSj16 xU2TjFoXlsPsw1eLcnC58zKCf/+xG3jOA3NoUY273XH5BvEAa/RCwqYt9gBWZd/Iav4X fED7c/MAIlzvzmEvxL9d1+rdfZrbxGzYDBZxDfDyTpqcM+8vM/EGf1YtdjZbv+adv0nC tjvw== X-Gm-Message-State: AOAM530qEw70z56fqHnIs+94LUnf+soZ9MAN8lxpIKk10zjwJ9KghG/5 KdKTa+rG/T3tdDneCzAx1M6Y+4WQrMpam5cRD+ejyPGs X-Google-Smtp-Source: ABdhPJwuVPlrWH78DXKkj3QEtTazom2HnWzhrEBkzBKGSmPpWV0CTwGKnosOht3xz/dL+CBBRrHVGd1KgQ+t2spPNv8= X-Received: by 2002:aca:5b0b:: with SMTP id p11mr207389oib.82.1591737176811; Tue, 09 Jun 2020 14:12:56 -0700 (PDT) MIME-Version: 1.0 References: <836C0462-1643-45E2-AD78-84B1F1BF3534@kitterman.com> <49903CF4-A164-4350-AC1F-4DF7A1A75440@nostrum.com> In-Reply-To: <49903CF4-A164-4350-AC1F-4DF7A1A75440@nostrum.com> From: Patrick McManus Date: Tue, 9 Jun 2020 17:12:45 -0400 Message-ID: To: Ben Campbell Cc: Scott Kitterman , Dispatch WG Content-Type: multipart/alternative; boundary="000000000000ffed1205a7ad301d" 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: Tue, 09 Jun 2020 21:13:00 -0000 --000000000000ffed1205a7ad301d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I asked the question in an open ended spirit with all of the usual dispatch outcomes on the table. (but expressed it in phone keyboard speak - sorry.) I would anticipate that this would generate an AD sponsored recommendation due to its nature, but it would be nice to hear a few more comments responsive to that before considering the consensus question.. On Tue, Jun 9, 2020 at 4:57 PM Ben Campbell wrote: > I suspect Patrick meant =E2=80=9Coutside of a working group=E2=80=9D. Pat= rick? > > > On Jun 4, 2020, at 7:29 PM, Scott Kitterman > wrote: > > > > What did you have in mind as an alternative to an mailing list? > > > > Scott K > > > > On June 5, 2020 12:08:08 AM UTC, Patrick McManus > wrote: > >> does the group have any thoughts on what the appropriate dispatch for > >> Ted's > >> work (below) would be? > >> > >> We certainly can do this outside of a list if there is participation > >> and > >> rough consensus.. would be good to build that skill in this remote-onl= y > >> period, right? > >> > >> -Patrick > >> > >> > >> On Wed, Jun 3, 2020 at 7:13 PM Ted Hardie wrote: > >> > >>> Howdy, > >>> > >>> This is one the shortest drafts I've ever written: > >>> > >> https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ > >>> > >> .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 > > --000000000000ffed1205a7ad301d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I asked the question in an open ended spirit with all of t= he usual dispatch outcomes on the table. (but expressed it in phone keyboar= d speak - sorry.)

I would anticipate=C2=A0that this would generate a= n AD sponsored recommendation due to its nature, but it would be nice to he= ar a few more comments responsive to that before considering the consensus = question..

On Tue, Jun 9, 2020 at 4:57 PM Ben Campbell <ben@nostrum.com> wrote:
I suspect Patrick meant =E2=80=9Coutside o= f a working group=E2=80=9D. Patrick?

> On Jun 4, 2020, at 7:29 PM, Scott Kitterman <sklist@kitterman.com> wrote:
>
> What did you have in mind as an alternative to an mailing list?
>
> Scott K
>
> On June 5, 2020 12:08:08 AM UTC, Patrick McManus <mcmanus@ducksong.com> wrote= :
>> does the group have any thoughts on what the appropriate dispatch = for
>> Ted's
>> work (below) would be?
>>
>> We certainly can do this outside of a list if there is participati= on
>> and
>> rough consensus.. would be good to build that skill in this remote= -only
>> period, right?
>>
>> -Patrick
>>
>>
>> On Wed, Jun 3, 2020 at 7:13 PM Ted Hardie <ted.ietf@gmail.com> wrote:
>>
>>> Howdy,
>>>
>>> This is one the shortest drafts I've ever written:
>>>
>> https://datatracker.i= etf.org/doc/draft-hardie-dispatch-rfc3405-update/
>>>
>> <https://datatracker.ietf..org/doc/draft-hardie-dispatch-rf= c3405-update/>
>>> .=C2=A0 =C2=A0Basically, RFC 3405 used to require that registr= ations in
>> URI.ARPA be
>>> from the "IETF Tree".=C2=A0 That tree was deprecated= after the document
>> was
>>> published.=C2=A0 As it happens, there are very few registratio= ns in
>> URI.ARPA, so
>>> we did not catch it and fix it before now.
>>>
>>> This draft updates RFC 3405 to require "permanent" s= cheme
>> registrations.
>>> The salient bit is this:
>>>
>>> All registrations in URI.ARPA MUST be for schemes which are pe= rmanent
>>>=C2=A0 =C2=A0registrations, as they are described in BCP 35. >>>
>>> I'm hoping for a quick dispatch of this, but happy to disc= uss.
>>>
>>> regards,
>>>
>>> Ted Hardie
>>>
>>> _______________________________________________
>>> dispatch mailing list
>>> dispatc= h@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dis= patch
>>>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/dispatch

--000000000000ffed1205a7ad301d-- From nobody Tue Jun 9 14:18: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 E8B6D3A08E7 for ; Tue, 9 Jun 2020 14:18:37 -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_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=QK6hD6mD; dkim=pass (2048-bit key) header.d=kitterman.com header.b=GCWWzOQe 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 nM3bLBSrjcso for ; Tue, 9 Jun 2020 14:18:36 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B67A3A08E5 for ; Tue, 9 Jun 2020 14:18:35 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id A6059F80316 for ; Tue, 9 Jun 2020 17:18:32 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1591737512; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=TeYhlp8V1+IW2oM8JhCvOwgUOGFVCXrjVXgMBReQez0=; b=QK6hD6mDwEy7hKn873n0qAOttogn5Op9lXhiR6hSPQzwJNqUKbRweDDRDTecl8/5C9Ceu SsnbF9CVkdPnXbvBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1591737512; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=TeYhlp8V1+IW2oM8JhCvOwgUOGFVCXrjVXgMBReQez0=; b=GCWWzOQe/U1MGnIfj9+6AYjfDmXeCnTvdLTckbBpjTReXbRJKyhdKScaJpfmpC50nPX1M fxC2G3X9laGQW+hHlNyS9vy5nknQ5ZgzMJzI8bLFciy5pAMi1qN3UlYwojwaz/y7cYxUMDk iDE1Pg8zOUoJjclEuYAVdJDRYB3nlST4wFfq8w4Cm6euIxUarEbuuhJNfGI56n0Ys+D84vQ ipgqhWtrpaR8nsR1HpcLbpnalzxs/EmKQUOeXqenMMIZsD2/dRv/cd3C6d8QIi2lCvQRjwj fUKx2VUvGCwIKOUBvOtNfBoSUkAh8Oe7nIYY8vZkqwY4D+Punfra76wRipcA== Received: from sk-desktop.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id 78DEAF801F6 for ; Tue, 9 Jun 2020 17:18:32 -0400 (EDT) From: Scott Kitterman To: Dispatch WG Date: Tue, 09 Jun 2020 17:18:32 -0400 Message-ID: <2011234.mNb5IxkY0x@sk-desktop> In-Reply-To: References: <49903CF4-A164-4350-AC1F-4DF7A1A75440@nostrum.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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: Tue, 09 Jun 2020 21:18:38 -0000 Thanks. I have no issue with that. I think it makes sense. I was worried alternative to a mailing list was going to turn out to be som= e=20 horrendous piece of web forum software. Scott K On Tuesday, June 9, 2020 5:12:45 PM EDT Patrick McManus wrote: > I asked the question in an open ended spirit with all of the usual dispat= ch > outcomes on the table. (but expressed it in phone keyboard speak - sorry.) >=20 > I would anticipate that this would generate an AD sponsored recommendation > due to its nature, but it would be nice to hear a few more comments > responsive to that before considering the consensus question.. >=20 > On Tue, Jun 9, 2020 at 4:57 PM Ben Campbell wrote: > > I suspect Patrick meant =E2=80=9Coutside of a working group=E2=80=9D. P= atrick? > >=20 > > > On Jun 4, 2020, at 7:29 PM, Scott Kitterman > >=20 > > wrote: > > > What did you have in mind as an alternative to an mailing list? > > >=20 > > > Scott K > > >=20 > > > On June 5, 2020 12:08:08 AM UTC, Patrick McManus > >=20 > > wrote: > > >> does the group have any thoughts on what the appropriate dispatch for > > >> Ted's > > >> work (below) would be? > > >>=20 > > >> We certainly can do this outside of a list if there is participation > > >> and > > >> rough consensus.. would be good to build that skill in this remote-o= nly > > >> period, right? > > >>=20 > > >> -Patrick > > >>=20 > > >> On Wed, Jun 3, 2020 at 7:13 PM Ted Hardie wrote: > > >>> Howdy, > > >>=20 > > >>> This is one the shortest drafts I've ever written: > > >> https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-updat= e/ > > >>=20 > > >> >=20 > > .org/doc/draft-hardie-dispatch-rfc3405-update/> > >=20 > > >>> . Basically, RFC 3405 used to require that registrations in > > >>=20 > > >> URI.ARPA be > > >>=20 > > >>> from the "IETF Tree". That tree was deprecated after the document > > >>=20 > > >> was > > >>=20 > > >>> published. As it happens, there are very few registrations in > > >>=20 > > >> URI.ARPA, so > > >>=20 > > >>> we did not catch it and fix it before now. > > >>>=20 > > >>> This draft updates RFC 3405 to require "permanent" scheme > > >>=20 > > >> registrations. > > >>=20 > > >>> The salient bit is this: > > >>>=20 > > >>> All registrations in URI.ARPA MUST be for schemes which are permane= nt > > >>>=20 > > >>> registrations, as they are described in BCP 35. > > >>>=20 > > >>> I'm hoping for a quick dispatch of this, but happy to discuss. > > >>>=20 > > >>> regards, > > >>>=20 > > >>> Ted Hardie > > >>>=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 From nobody Mon Jun 15 10:32: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 F16F83A05A0 for ; Mon, 15 Jun 2020 10:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.339 X-Spam-Level: X-Spam-Status: No, score=-17.339 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, HTML_OBFUSCATE_05_10=0.26, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9u_jcsKNrjW for ; Mon, 15 Jun 2020 10:32:42 -0700 (PDT) Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 A48333A077D for ; Mon, 15 Jun 2020 10:32:42 -0700 (PDT) Received: by mail-ej1-x62b.google.com with SMTP id dp18so133986ejc.8 for ; Mon, 15 Jun 2020 10:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=i2AtmdcUHK/08n463ylex7KYoonH7f4mhV8ymlTaFx4=; b=jnL9trnp24dRa/hdf+r4SJ/kin5S9frhG9f0Tz7VdvnEg1v/xRE7upncwaDVlTjepD Gyb9hxSgUTqKyoR8KfwajICgMVFrnwRpl5aHzZqB5jOGNN72tkO4sFS3O0OF3DbAVyqQ j1Cy27nbNqnQAZ+lJqDcYjnjQkzIOCtNBqmZ5zbQF9Cu3cqQBv3BpaWcGs9sCCEFCKmA YseNe2smUMX9w9Vpn6C4Dgm75faW1EGJWlnmcX123q2ixerdGCs0+M0huH+IAHnODTyW 5IrzWQXYLjsC7L5T4AQ3Y5kSBGxjOBll4FhnzNP1IVQ46eartzEkjflM6l7KIZffR/Wg IdoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=i2AtmdcUHK/08n463ylex7KYoonH7f4mhV8ymlTaFx4=; b=fvBq1gG0ZR1bNOYEwDUA0zA5rGUZFw59maXXYMe7nzfqp7Dktw5E/svktyTH9v3rT1 LVTyjXrmABRWtD96b0A9dL3MrocY/I6qHJdt+rXC/1fCTzI6WdQXpOe8pNCxR1NHDbAW OBuE2YTRHZx+4ePTyFnZuw1J1nh2CsNMAjOTCyHOE+ro/1WcRs+uNkAjNzIb7bteXRgO PHFKQr1C2pMCn5I38hlPOsCaLiScpbu4MTk3fWBvXYCWtgnFhIRGxbYn/fNU12wr/TVD 7MtbY/1a6ZJkYC6A117vtdhXrsv92kuEV1+Qg+rcLP9X4vbScq0N99jBTj5G3ObrkqLo oJlA== X-Gm-Message-State: AOAM530iMLugrcBxrYkvwnrqvIWduIMriow1MZwHkmH7JnzNGQNIr9A3 C0/iZlB0I1kfL0hzqfG9zpMQBj5o4Cz7D6u4p9Ve60Xonw== X-Google-Smtp-Source: ABdhPJyglFS4pgUKAt+tJy5QpIbLfX1DJ7FOlFdHhqVZFz3ElO+WDyRPLJfJqG19u/lHceyREwTwOhNrWSZd5Pk7srk= X-Received: by 2002:a17:906:22d0:: with SMTP id q16mr13852423eja.455.1592242360913; Mon, 15 Jun 2020 10:32:40 -0700 (PDT) MIME-Version: 1.0 From: Emad Omara Date: Mon, 15 Jun 2020 10:32:29 -0700 Message-ID: To: session-request@ietf.org, dispatch@ietf.org Cc: sframe@ietf.org Content-Type: multipart/alternative; boundary="00000000000052047605a822d02e" Archived-At: Subject: [dispatch] Request session at IETF 108 dispatch 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, 15 Jun 2020 17:32:44 -0000 --00000000000052047605a822d02e Content-Type: text/plain; charset="UTF-8" Hi, We would like to have a session in the next IETF to discuss the SFrame draft Can you please help scheduling this? Thanks Emad --00000000000052047605a822d02e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

We would like to have a session in = the next IETF to discuss the SFrame draft=C2=A0Can you please help scheduling this?<= /div>

Thanks
Emad
--00000000000052047605a822d02e-- From nobody Mon Jun 15 11:02:49 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 14BE93A0827; Mon, 15 Jun 2020 11:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, 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 i-7T_MzaRug2; Mon, 15 Jun 2020 11:02:46 -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 BFDE83A0837; Mon, 15 Jun 2020 11:02:46 -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 05FI2c4K074313 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 15 Jun 2020 13:02:39 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1592244160; bh=Drx7FVDaN7vYeoxyaG0Q+rW/xy17m5NzYU/IjE1tO8w=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=dneW+LfMuKUu9QnbDSkyj3vfGz7UFOWGhMugd/pVXLEM6owzheZcukNwJAMh5L2MR z5OWJXellV5iUAkvIS0pzFjBdCdv/WrmIHNRpUlLIVpD+goXqoIrfEjphPt5niGBbs WxFIrqyse2Yq47zg3p/N0zZ8Ia8FKJmofiTM9oLc= 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 Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_00EE1CC8-65CF-417F-848E-8EE5C12EF5B9" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 15 Jun 2020 13:02:31 -0500 In-Reply-To: Cc: Dispatch WG , sframe@ietf.org, Patrick McManus To: Emad Omara References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dispatch] Request session at IETF 108 dispatch 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, 15 Jun 2020 18:02:48 -0000 --Apple-Mail=_00EE1CC8-65CF-417F-848E-8EE5C12EF5B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Emad, We prioritize DISPATCH meeting time to focus on topics that have had = DISPATCH list discussion and need high-bandwidth time to resolve. Unless = I=E2=80=99ve missed something, this topic has not previously come up in = DISPATCH. I suggest sending a note to this list with some background = about the draft and how you would like to see it progress. Thanks! Ben. > On Jun 15, 2020, at 12:32 PM, Emad Omara = wrote: >=20 > Hi, >=20 > We would like to have a session in the next IETF to discuss the SFrame = draft Can you please = help scheduling this? >=20 > Thanks > Emad > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_00EE1CC8-65CF-417F-848E-8EE5C12EF5B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Emad,

We prioritize = DISPATCH meeting time to focus on topics that have had DISPATCH list = discussion and need high-bandwidth time to resolve. Unless I=E2=80=99ve = missed something, this topic has not previously come up in DISPATCH. I = suggest sending a note to this list with some background about the draft = and how you would like to see it progress.

Thanks!

Ben.

On Jun = 15, 2020, at 12:32 PM, Emad Omara <emadomara=3D40google.com@dmarc.ietf.org> = wrote:

Hi,

We would like to have a session in the next IETF to discuss = the SFrame draft Can you please help scheduling = this?

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

= --Apple-Mail=_00EE1CC8-65CF-417F-848E-8EE5C12EF5B9-- From nobody Mon Jun 15 11:33:27 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 934CA3A0838 for ; Mon, 15 Jun 2020 11:33:23 -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 Atn0scnhuRZq for ; Mon, 15 Jun 2020 11:33:21 -0700 (PDT) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (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 F28693A0843 for ; Mon, 15 Jun 2020 11:33:20 -0700 (PDT) Received: by mail-ej1-x632.google.com with SMTP id mb16so18532405ejb.4 for ; Mon, 15 Jun 2020 11:33:20 -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=S+42B0sMuRzRUyhk2p/H6NJ0mMFM1Yb596K3W5LJSo4=; b=aXQJTP1Z5PAXl7LIE7pKvEylNotSIwDiIqWFB7Jd9FLD2RODNFRhMMIoY3wpVF6r4U gR9R8Eti3fEBTreHFZb3uy0IvittbSjSf7XEaHQFRXOjuw8XnYLjIy3/cLnz5brVd9+K dlXm1QlDG49z+d+8m5cLcvvoxJCJSAba9TihI/CD8aB6NaxONsdKT1NhMoWWG0vF+BIW 7Jg+LXg63bmyuUZ5WrvbCVXXWoihjwlASO6XLbBnjoKybfy5zpX0ya+uNNrRQ19cSYSk N6s6CIDJvz3Oy7bgZ1QkDzWlTuOEM6X4z9TCFN2rIrsOMhHmIpqCg8Fl9VU7pUiaKCPJ wbaQ== 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=S+42B0sMuRzRUyhk2p/H6NJ0mMFM1Yb596K3W5LJSo4=; b=P5BNpJytn9b91c3Fr37tH0yWbjMCgDcqiA3WczUb4g8HXc8YA929yAE8kO/74Zzznd SrgtEDKAlThMYUrxTOSAnWp+UHApVyjQVCe2txXb2UFJeHoul1zaVcZhBpy6j9+Bh6i9 smLgF8wr9wUIKW9rVFGBQ6zo7gY0YyZMeR2JikruBC3H+RhbABvqRSNmmB16vTO4mtCN zhyxoSbPXIrGcU37aaE6N5epiL1kyFjH3tN69W3w/PDNyE+sh9jujCQ3dvrFIiLZys/Y kx0K4MP5k11LS7ku4GvbDh7Uam76B17jRizxOp2n0Bc+Ce2c2n/te7TWaAwWxo1DkAFS 3F0g== X-Gm-Message-State: AOAM531VevoTsne7gYYpy5w1/Gjz/6SATUnM8kj8xURYCD7b9JaynrRB Wx9Ynuexnmim+x94wNFIcB0tpaeObWVXqgYeWfcXL5wYiw== X-Google-Smtp-Source: ABdhPJyPfdGkyRtw4Hq21YOZvE9pe1sOpgZLnwyT2ZZahgtSgD0NPY7G2FP0TVDrSb4HkZ7uv4HKrVLZm2JkZtKugqY= X-Received: by 2002:a17:906:22d0:: with SMTP id q16mr14077150eja.455.1592245998943; Mon, 15 Jun 2020 11:33:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Emad Omara Date: Mon, 15 Jun 2020 11:33:07 -0700 Message-ID: To: Ben Campbell Cc: Dispatch WG , sframe@ietf.org, Patrick McManus Content-Type: multipart/alternative; boundary="00000000000029e31305a823a908" Archived-At: Subject: Re: [dispatch] Request session at IETF 108 dispatch 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, 15 Jun 2020 18:33:24 -0000 --00000000000029e31305a823a908 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ben, This draft proposes a solution for end-to-end encrypted conference calls. We implemented this in Google a couple of years ago in Duo, but the draft was only published last month given the current interest in the topic. The goal of the session is to go through the proposal and see if there is interest to continue working on this, and if so what will be the best WG to host this work. Thanks Emad On Mon, Jun 15, 2020 at 11:02 AM Ben Campbell wrote: > Hi Emad, > > We prioritize DISPATCH meeting time to focus on topics that have had > DISPATCH list discussion and need high-bandwidth time to resolve. Unless > I=E2=80=99ve missed something, this topic has not previously come up in D= ISPATCH. I > suggest sending a note to this list with some background about the draft > and how you would like to see it progress. > > Thanks! > > Ben. > > On Jun 15, 2020, at 12:32 PM, Emad Omara < > emadomara=3D40google.com@dmarc.ietf.org> wrote: > > Hi, > > We would like to have a session in the next IETF to discuss the SFrame > draft Can you please > help scheduling this? > > Thanks > Emad > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > --00000000000029e31305a823a908 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,

This draft proposes a solution = for end-to-end encrypted conference calls. We implemented=C2=A0this in Goog= le a couple of years ago in Duo, but the draft was only published last mont= h given the current interest in the topic.

The goa= l of the session is to go through the proposal and see if there is interest= to continue working on this, and if so what will be the best WG to host th= is work.=C2=A0

Thanks
Emad
On Mon, = Jun 15, 2020 at 11:02 AM Ben Campbell <ben@nostrum.com> wrote:
Hi Emad,
We prioritize DISPATCH meeting time to focus on topics that hav= e had DISPATCH list discussion and need high-bandwidth time to resolve. Unl= ess I=E2=80=99ve missed something, this topic has not previously come up in= DISPATCH. I suggest sending a note to this list with some background about= the draft and how you would like to see it progress.

<= div>Thanks!

Ben.

On Jun 15, 2020, at 12:32 PM, Emad Omara <emadomara=3D40goog= le.com@dmarc.ietf.org> wrote:

Hi,
We would like to have a session in the next IETF to discuss= the SFrame draft=C2=A0Can you please help scheduling this?

Thanks
Emad
_______________________________________________
dispatch mailing listdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--00000000000029e31305a823a908-- From nobody Mon Jun 15 11:43:19 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 573F13A092D; Mon, 15 Jun 2020 11:43:13 -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 vvzgY635vSd6; Mon, 15 Jun 2020 11:43:10 -0700 (PDT) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5EF33A0926; Mon, 15 Jun 2020 11:43:10 -0700 (PDT) Received: by mail-ot1-x330.google.com with SMTP id g5so13916074otg.6; Mon, 15 Jun 2020 11:43:10 -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=i2v/d08OHEPd+AR18JS6apn9EPHprIGOZ2OIam59E4w=; b=RFeD8OIyYI+uTxxvJH8Dub5x2SU6fLGGYNcge4o/it6ytdE9yDvgs9+pRaHDl4S6DM R0n8PegyNi/orPbl4krgee0IMgCk3HP1/LjHG57ZahLikzIdALC9tvRwrZngj1fgOvGp EQ3D7lfVuoW5AjvMDQ13n+8nf2kw+Fc/odw25PS49GogqQRSKOYFLWpbiP0oehMK8Qvu n1JcQMbv8VXhI9ZsPt+PPR+5ei3eSPjwBcsABiypRZqo/3U+aXWeFerKjoTBL0plyc2o Up8u+3T2JA/gU3XdHJyPZ4TnOl6grzZRxQs4JylYJgCODYivfzvMd6NMoNw5KZR0liu/ h2ZA== 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=i2v/d08OHEPd+AR18JS6apn9EPHprIGOZ2OIam59E4w=; b=V1xAzK35OZjRfUsRIIfbNR6FtTGPKMksigA0j/Q94phm/UpjbkEK7CDW64tNnecKdo WydiRkH40gN5CA7Ei6pq/2wGY8KcLwLVlj2ta4x4pWZ0coCa7Y2sf1mEgRvHvfxQIjCS UeijzSqlA1xw1cNtQHvESusXcTbYf8VIYTuC4I/rI7xXaQvuTzvqkMj5jRekZnXqnUfC z+hc9XnY5vNbmtFqFMlEGhCNZCp2ubLEUshNUfcXWKUaSGsvQO9zuTm08iLtdUIEePkO Gp2X60PLQ13nUZO3kZoeKvrTuFxGjaLAlNDIHPlpg8F18CZIibyxHFkpE5zwkJw3hsRA nrdg== X-Gm-Message-State: AOAM532bmfOyoSbLs8eP5afiPPrl1LoQ8K4U11M/6n6APnK2X7gAcQ/h QchaoIUpm6CU0rafsaC2OJFLo2tamAdz2kYzRns= X-Google-Smtp-Source: ABdhPJxIR0Hix3uq9ryahDwXIhyvjpRXLsu7PVESqjnoQnhAsSfeeNgHcgUvhS1Hv81B9CgjvOzmaA5DCW1JcNT0fJQ= X-Received: by 2002:a9d:61ca:: with SMTP id h10mr9666005otk.154.1592246589838; Mon, 15 Jun 2020 11:43:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Patrick McManus Date: Mon, 15 Jun 2020 14:42:58 -0400 Message-ID: To: Emad Omara Cc: Ben Campbell , Dispatch WG , sframe@ietf.org Content-Type: multipart/alternative; boundary="00000000000061d98605a823cc6e" Archived-At: Subject: Re: [dispatch] Request session at IETF 108 dispatch 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, 15 Jun 2020 18:43:13 -0000 --00000000000061d98605a823cc6e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sounds really interesting Emad and there's obviously related work going on (at least perc, maybe even mls..). Sending that email Ben mentions to the dispatch list to raise awareness with a link to the draft would be helpful in getting the process started.. On Mon, Jun 15, 2020 at 2:33 PM Emad Omara wrote: > Hi Ben, > > This draft proposes a solution for end-to-end encrypted conference calls. > We implemented this in Google a couple of years ago in Duo, but the draft > was only published last month given the current interest in the topic. > > The goal of the session is to go through the proposal and see if there is > interest to continue working on this, and if so what will be the best WG = to > host this work. > > Thanks > Emad > > On Mon, Jun 15, 2020 at 11:02 AM Ben Campbell wrote: > >> Hi Emad, >> >> We prioritize DISPATCH meeting time to focus on topics that have had >> DISPATCH list discussion and need high-bandwidth time to resolve. Unless >> I=E2=80=99ve missed something, this topic has not previously come up in = DISPATCH. I >> suggest sending a note to this list with some background about the draft >> and how you would like to see it progress. >> >> Thanks! >> >> Ben. >> >> On Jun 15, 2020, at 12:32 PM, Emad Omara < >> emadomara=3D40google.com@dmarc.ietf.org> wrote: >> >> Hi, >> >> We would like to have a session in the next IETF to discuss the SFrame >> draft Can you please >> help scheduling this? >> >> Thanks >> Emad >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> >> --00000000000061d98605a823cc6e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sounds really interesting Emad and there's obviously r= elated=C2=A0work going on (at least perc, maybe even mls..).

=
Sending that email Ben mentions to the dispatch list to raise awarenes= s with a link to the draft would be helpful in getting the process started.= .

On Mon, Jun 15, 2020 at 2:33 PM Emad Omara <emadomara@google.com> wrote:
Hi Ben,

This draft proposes a solution for end-to-end encrypted conference = calls. We implemented=C2=A0this in Google a couple of years ago in Duo, but= the draft was only published last month given the current interest in the = topic.

The goal of the session is to go through th= e proposal and see if there is interest to continue working on this, and if= so what will be the best WG to host this work.=C2=A0

<= div>Thanks
Emad

On Mon, Jun 15, 2020 at 11:02 AM Ben Campbel= l <ben@nostrum.com<= /a>> wrote:
<= div>Hi Emad,

--00000000000061d98605a823cc6e-- From nobody Mon Jun 15 12:06:07 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 8DC083A0958; Mon, 15 Jun 2020 12:06:00 -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, RCVD_IN_DNSWL_BLOCKED=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 QkZgmmfaIOYa; Mon, 15 Jun 2020 12:05:59 -0700 (PDT) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0: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 DEB593A0975; Mon, 15 Jun 2020 12:05:58 -0700 (PDT) Received: by mail-oi1-x22c.google.com with SMTP id i74so16938318oib.0; Mon, 15 Jun 2020 12:05: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=8a4FoPWqjEn/8SuPin5DWTs/gxY0RxYgI2LlMTlLmLc=; b=AXLzZcCRDK0xvE+Hv1k1CDP7IGnlXzMheMAJE7RH4hvSLJehdWj8imxEz2ABYFCeD9 vgOB3BX9Ti0izQeKYaXfrv57yCxW96pl5eX0JgAO/urF5ncGNxfuLfc4bluceIwCZo48 N7WBj1C0SvIDAfYFfirQ6mYx2fNh1Hq8jtF3Zv+DUCgZimly+vQAFJCs94BvnMlIt1/O gFCJfAFoWwhxdSjSmcXlsbRXa+gI48Vw5IbRivmxgu6mHLS3EXTqIMYhTVhcD8btanAh 7fBmrP459PhrVZB8lfWp99h0fZCsh5dwMqP7+Spa23t+Ajknn8qdCLTxDlwfRMSETPFv zaTg== 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=8a4FoPWqjEn/8SuPin5DWTs/gxY0RxYgI2LlMTlLmLc=; b=ktLsy8/khx0WjMUp/UZCLK2mtMS3d5WyydnXRK84YcnG6OdIiZ0XIElk9X0dw4GYm0 Z/Mwb7PLy0ro/j3YG0Q0o+YkP0qDQalJJakkInFtgKwNnj+76HJXtMNlQw5BO5bXqL1n NigdN8LSWgOzSGXoqAsia80UOFhnSA7YiaRiP3V/SHmODS/f0J9AlFSYGp9Jk4d9UuwQ ZK5ek5tVqUS2ylU3VaQ3Iq1TAV5t/w6DwqWruzNRRCCegqjliVApJT5+MxNW/LCTa/P+ rIJA+D4kgPMmXYTXY5tBL8BPqdGFPP4CdR28rzuGKcq8XEyL+FnaI2q52Dd4NETHQt9+ mK1g== X-Gm-Message-State: AOAM5334v8s1khRte85alghX7t0OcfTZIYUthtyGKEe2bEpEeRpS4iiv qPfPHvuS3eAOVOl50sg99r5o0isy8xLhURlBKCA= X-Google-Smtp-Source: ABdhPJzSHexTDKNi6UWt2lS4sFlU3izbQzhwFcj/rvCZEBbKJlxDEwRn4VMAqENM/Idx7RH05OS11khpq5vP0jBJRoU= X-Received: by 2002:aca:b357:: with SMTP id c84mr667974oif.118.1592247958114; Mon, 15 Jun 2020 12:05:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Patrick McManus Date: Mon, 15 Jun 2020 15:05:47 -0400 Message-ID: To: Emad Omara Cc: Ben Campbell , Dispatch WG , sframe@ietf.org Content-Type: multipart/alternative; boundary="000000000000f0173005a8241dbc" Archived-At: Subject: [dispatch] Dispatch of SFrame for End-To-End Encrypted Conference Calls 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, 15 Jun 2020 19:06:01 -0000 --000000000000f0173005a8241dbc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All - I failed to note the link highlighting in Emad's mail to the list which already contained the draft. Sorry about that. (It's https://tools.ietf.org/html/draft-omara-sframe-00 if you too missed it). There's also a github and mailing list referenced: https://github.com/eomara/sframe https://mailarchive.ietf.org/arch/browse/sframe/? [I've also forked the Subject Line to help interested readers] On Mon, Jun 15, 2020 at 2:42 PM Patrick McManus wrote: > Sounds really interesting Emad and there's obviously related work going o= n > (at least perc, maybe even mls..). > > Sending that email Ben mentions to the dispatch list to raise awareness > with a link to the draft would be helpful in getting the process started.= . > > On Mon, Jun 15, 2020 at 2:33 PM Emad Omara wrote: > >> Hi Ben, >> >> This draft proposes a solution for end-to-end encrypted conference calls= . >> We implemented this in Google a couple of years ago in Duo, but the draf= t >> was only published last month given the current interest in the topic. >> >> The goal of the session is to go through the proposal and see if there i= s >> interest to continue working on this, and if so what will be the best WG= to >> host this work. >> >> Thanks >> Emad >> >> On Mon, Jun 15, 2020 at 11:02 AM Ben Campbell wrote: >> >>> Hi Emad, >>> >>> We prioritize DISPATCH meeting time to focus on topics that have had >>> DISPATCH list discussion and need high-bandwidth time to resolve. Unles= s >>> I=E2=80=99ve missed something, this topic has not previously come up in= DISPATCH. I >>> suggest sending a note to this list with some background about the draf= t >>> and how you would like to see it progress. >>> >>> Thanks! >>> >>> Ben. >>> >>> On Jun 15, 2020, at 12:32 PM, Emad Omara < >>> emadomara=3D40google.com@dmarc.ietf.org> wrote: >>> >>> Hi, >>> >>> We would like to have a session in the next IETF to discuss the SFrame >>> draft Can you >>> please help scheduling this? >>> >>> Thanks >>> Emad >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> >>> --000000000000f0173005a8241dbc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All -

I failed to note the link= highlighting in Emad's mail to the list which already contained the dr= aft. Sorry about that. (It's=C2=A0https://tools.ietf.org/html/draft-omara-sframe-00<= /a>=C2=A0if you too missed it).

There's also a github and mailin= g list referenced:
https://= github.com/eomara/sframe
https://mailarchive.ietf.org/arch/browse/sframe/?

[I've also forked the Subject Line to help interes= ted readers]

On Mon, Jun 15, 2020 at 2:42 PM Patrick McManus <patrick.ducksong@gmail.com>= wrote:
Sounds really interesting Emad and there's obviously related= =C2=A0work going on (at least perc, maybe even mls..).

S= ending that email Ben mentions to the dispatch list to raise awareness with= a link to the draft would be helpful in getting the process started..

On Mon, Jun 15, 2020 at 2:33 PM Emad Omara <emadomara@google.com> wrote:
Hi Ben,=

This draft proposes a solution for end-to-end encrypted= conference calls. We implemented=C2=A0this in Google a couple of years ago= in Duo, but the draft was only published last month given the current inte= rest in the topic.

The goal of the session is to g= o through the proposal and see if there is interest to continue working on = this, and if so what will be the best WG to host this work.=C2=A0

Thanks
Emad

On Mon, Jun 15, 2020 at 11:02 AM= Ben Campbell <ben@= nostrum.com> wrote:
Hi Emad,

We prioritize DISPATCH meeting = time to focus on topics that have had DISPATCH list discussion and need hig= h-bandwidth time to resolve. Unless I=E2=80=99ve missed something, this top= ic has not previously come up in DISPATCH. I suggest sending a note to this= list with some background about the draft and how you would like to see it= progress.

Thanks!

Ben.

On Jun 15, 2020, at 12:32 PM, Ema= d Omara <emadomara=3D40google.com@dmarc.ietf.org> wrote:
<= br>
Hi,

We would like to have a ses= sion in the next IETF to discuss the SFrame draft=C2=A0Can you ple= ase help scheduling this?

Thanks
Emad
_______________________________________________
dispatch mailing listdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--000000000000f0173005a8241dbc-- From nobody Mon Jun 15 12:13:19 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 71C473A0C94; Mon, 15 Jun 2020 12:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MAY_BE_FORGED=0.001, RCVD_IN_DNSWL_BLOCKED=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 LdoCwqwpNGvG; Mon, 15 Jun 2020 12:13:16 -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 E2A173A0C93; Mon, 15 Jun 2020 12:13:15 -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 05FJD8U8090099 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 15 Jun 2020 14:13:09 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1592248390; bh=sTUerH3PZbJZxIzZ+L4zTozKdsYyROqW2O1mr2ynnRo=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=fYJQ3BRo7w4sTpoP6jmdPYAS3CU0IEzzxc3uACCNybBwDZWgbYawD74+SUEK/eUt8 wMIJ0pl0uyynwyipea1soqlr0jklAIIBEj6kQDIE5OZXCrVMjIG4TNBpFRd3jYgNtU mt+ksrV/5WRlcAtWkp8gXq6B7MxA1BYWiJezNT6c= 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 Message-Id: <4425D473-7A6A-4AF5-BA53-635255D6EC55@nostrum.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E949626B-39E1-4C79-8B8B-9F526A7869E8" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 15 Jun 2020 14:13:02 -0500 In-Reply-To: Cc: Emad Omara , Dispatch WG , sframe@ietf.org To: Patrick McManus References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dispatch] Dispatch of SFrame for End-To-End Encrypted Conference Calls 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, 15 Jun 2020 19:13:17 -0000 --Apple-Mail=_E949626B-39E1-4C79-8B8B-9F526A7869E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks, Patrick. Authors: It would be helpful to get a little more background:=20 - How does this work relate to PERC? What problem does it solve that = PERC doesn=E2=80=99t? - Do you expect this to become an IETF standard available to anyone to = implement? Who do you think would implement it?=20 - Is anyone outside of Google working on the spec or implementing the = protocol? Has anyone outside of Google expressed interest in doing so? - Anything else you think would help motivate people to read the draft = and give feedback :-) Thanks! Ben. > On Jun 15, 2020, at 2:05 PM, Patrick McManus = wrote: >=20 > Hi All - >=20 > I failed to note the link highlighting in Emad's mail to the list = which already contained the draft. Sorry about that. (It's = https://tools.ietf.org/html/draft-omara-sframe-00 = if you too missed = it). >=20 > There's also a github and mailing list referenced: > https://github.com/eomara/sframe > https://mailarchive.ietf.org/arch/browse/sframe/? = >=20 > [I've also forked the Subject Line to help interested readers] >=20 > On Mon, Jun 15, 2020 at 2:42 PM Patrick McManus = > wrote: > Sounds really interesting Emad and there's obviously related work = going on (at least perc, maybe even mls..). >=20 > Sending that email Ben mentions to the dispatch list to raise = awareness with a link to the draft would be helpful in getting the = process started.. >=20 > On Mon, Jun 15, 2020 at 2:33 PM Emad Omara > wrote: > Hi Ben, >=20 > This draft proposes a solution for end-to-end encrypted conference = calls. We implemented this in Google a couple of years ago in Duo, but = the draft was only published last month given the current interest in = the topic. >=20 > The goal of the session is to go through the proposal and see if there = is interest to continue working on this, and if so what will be the best = WG to host this work.=20 >=20 > Thanks > Emad >=20 > On Mon, Jun 15, 2020 at 11:02 AM Ben Campbell > wrote: > Hi Emad, >=20 > We prioritize DISPATCH meeting time to focus on topics that have had = DISPATCH list discussion and need high-bandwidth time to resolve. Unless = I=E2=80=99ve missed something, this topic has not previously come up in = DISPATCH. I suggest sending a note to this list with some background = about the draft and how you would like to see it progress. >=20 > Thanks! >=20 > Ben. >=20 >> On Jun 15, 2020, at 12:32 PM, Emad Omara = > wrote: >>=20 >> Hi, >>=20 >> We would like to have a session in the next IETF to discuss the = SFrame draft Can you = please help scheduling this? >>=20 >> Thanks >> Emad >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch = >=20 --Apple-Mail=_E949626B-39E1-4C79-8B8B-9F526A7869E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks, Patrick.

Authors: It would be helpful to get a little more = background: 

- How does this work relate to PERC? What problem does it = solve that PERC doesn=E2=80=99t?
- Do you expect = this to become an IETF standard available to anyone to implement? Who do = you think would implement it? 
- Is anyone = outside of Google working on the spec or implementing the protocol? Has = anyone outside of Google expressed interest in doing so?
- Anything else you think would help motivate people to read = the draft and give feedback :-)

Thanks!

Ben.

On Jun 15, 2020, at 2:05 PM, Patrick McManus = <patrick.ducksong@gmail.com> wrote:

Hi All -

I failed to note the link highlighting in Emad's mail to the = list which already contained the draft. Sorry about that. (It's https://tools.ietf.org/html/draft-omara-sframe-00 if = you too missed it).

There's also a github = and mailing list referenced:
https://github.com/eomara/sframe
https://mailarchive.ietf.org/arch/browse/sframe/?

[I've = also forked the Subject Line to help interested readers]

On Mon, Jun 15, 2020 at 2:42 PM Patrick McManus = <patrick.ducksong@gmail.com> wrote:
Sounds = really interesting Emad and there's obviously related work going on = (at least perc, maybe even mls..).

Sending that email Ben mentions to the = dispatch list to raise awareness with a link to the draft would be = helpful in getting the process started..

On Mon, Jun = 15, 2020 at 2:33 PM Emad Omara <emadomara@google.com> wrote:
Hi = Ben,

This draft = proposes a solution for end-to-end encrypted conference calls. We = implemented this in Google a couple of years ago in Duo, but the = draft was only published last month given the current interest in the = topic.

The = goal of the session is to go through the proposal and see if there is = interest to continue working on this, and if so what will be the best WG = to host this work. 

Thanks
Emad

On Mon, Jun = 15, 2020 at 11:02 AM Ben Campbell <ben@nostrum.com> wrote:
Hi Emad,

We prioritize DISPATCH = meeting time to focus on topics that have had DISPATCH list discussion = and need high-bandwidth time to resolve. Unless I=E2=80=99ve missed = something, this topic has not previously come up in DISPATCH. I suggest = sending a note to this list with some background about the draft and how = you would like to see it progress.

Thanks!

Ben.

On Jun = 15, 2020, at 12:32 PM, Emad Omara <emadomara=3D40google.com@dmarc.ietf.org> = wrote:

Hi,

We = would like to have a session in the next IETF to discuss the SFrame draft Can you please help = scheduling this?

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


= --Apple-Mail=_E949626B-39E1-4C79-8B8B-9F526A7869E8-- From nobody Mon Jun 15 12:20:49 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 624873A0CE0 for ; Mon, 15 Jun 2020 12:20:45 -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 d4lluBZq3ufY for ; Mon, 15 Jun 2020 12:20:42 -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 8F0563A0CDF for ; Mon, 15 Jun 2020 12:20:42 -0700 (PDT) Received: by mail-ed1-x52d.google.com with SMTP id d15so12348233edm.10 for ; Mon, 15 Jun 2020 12:20:42 -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=GfxJedznmf2If8mWtVOIgELXnAT/bMiy+EnCZ7gIqQM=; b=vw5mzSPKVa90s3LheNs/GN1u5fcR3PfV/mE1gODQLh6023KTmLZGuFNvcqBA3pUoON QiX4loerpX+xaxK7Uhe4AN3Sm6Wgx2TpgvvdSVcg6CFxAJQdEkVTWRyZ+142KUZOfH9T NHQ2UtL3uEqeO0HuJRfkU3c5YHeD8KHKJtLUHSFx2BDQyh5Ripu3CkQ0r8j16DUI53on vDqvAtUVYEIDRBk+vbKAspW4p54cr7WmWiROLGqfxR99kO3bixhwwXGVO6UDZz8+xd6J lFyDrMZgoeiNJIeKt1vPGrmjxxCu1HSQVUcndY78KTZTuwNziMsliB0O/PsBwyUHh00c ElBw== 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=GfxJedznmf2If8mWtVOIgELXnAT/bMiy+EnCZ7gIqQM=; b=FAV0rCfsQYmLKx4sgjuPOBMOTLm4fndF/NIeqA/DuSWVdeeJqHDQ6Mcrx1pyeXV4vM fJjBkp+CcoLeg63VjsX6OmM+tRcfnj5sqdSDtUt8C+enltA5fA6Dl+wIgRualN6UOtN5 G9GadoTxN1zQ/KJXX/ZP9JJXrTFAmnQLq3VrKbetBeDifWAG/wYn2f5xWbqqV4e6HYkV Xif/2K/tlryexHjwOh3KVqGNW+QPdo1g9u27TyiO8y7UdRnIRPlIm2SV5236uizqMRKM OlXqiaFjC7Fp+0lwBHEb3RW5LkgP6LZrQVXb143dHCO5GKXPPsb0Owx0qFQMfIQzRf4u qmtA== X-Gm-Message-State: AOAM531Bt6MU4W63SYf0+39JPQ6HHtvrO6ZMWgzwfIU5gQN7LC+eOKeQ 3xiaGVHklSQ5zhJLJwkho0CR0ZjpibXttUCebGZz X-Google-Smtp-Source: ABdhPJwSeQVh+ac72SQN3bt4Eyyh+6RdeMUBuYTztgHDFhe0Ne8Ce7yotGE/hpA1PhPqKR1mEQ1VpVjfM1JcOjcfQ5E= X-Received: by 2002:aa7:cb94:: with SMTP id r20mr25514539edt.215.1592248840601; Mon, 15 Jun 2020 12:20:40 -0700 (PDT) MIME-Version: 1.0 References: <4425D473-7A6A-4AF5-BA53-635255D6EC55@nostrum.com> In-Reply-To: <4425D473-7A6A-4AF5-BA53-635255D6EC55@nostrum.com> From: Emad Omara Date: Mon, 15 Jun 2020 12:20:29 -0700 Message-ID: To: Ben Campbell , Sergio murillo , Alexandre GOUAILLARD Cc: Patrick McManus , Dispatch WG , sframe@ietf.org Content-Type: multipart/alternative; boundary="0000000000008a3de905a82452be" Archived-At: Subject: Re: [dispatch] Dispatch of SFrame for End-To-End Encrypted Conference Calls 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, 15 Jun 2020 19:20:45 -0000 --0000000000008a3de905a82452be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks. Some responses inline. Other authors please feel free to add more. Emad On Mon, Jun 15, 2020 at 12:13 PM Ben Campbell wrote: > Thanks, Patrick. > > Authors: It would be helpful to get a little more background: > > - How does this work relate to PERC? What problem does it solve that PERC > doesn=E2=80=99t? > This is a completely different approach than PERC. THis draft aims for simplicity and efficiency. The sdrame draft itself has some benchmarks against the PERC approach. That being said the sframe draft focuses mainly on the media encryption part and touches slightly other parts in the system like key management and integration with WebRTC. If this became a standard we will have to write a separate draft for each of these two topics. > - Do you expect this to become an IETF standard available to anyone to > implement? Who do you think would implement it? > Yes. This will be implemented by the video conference providers. The core protocol implementation is on the client side. > - Is anyone outside of Google working on the spec or implementing the > protocol? Has anyone outside of Google expressed interest in doing so? > Yes, the document is co-authored by +Sergio murillo & +Alexandre GOUAILLARD from Cosmos Software. > - Anything else you think would help motivate people to read the draft an= d > give feedback :-) > > Thanks! > > Ben. > > On Jun 15, 2020, at 2:05 PM, Patrick McManus > wrote: > > Hi All - > > I failed to note the link highlighting in Emad's mail to the list which > already contained the draft. Sorry about that. (It's > https://tools.ietf.org/html/draft-omara-sframe-00 if you too missed it). > > There's also a github and mailing list referenced: > https://github.com/eomara/sframe > https://mailarchive.ietf.org/arch/browse/sframe/? > > [I've also forked the Subject Line to help interested readers] > > On Mon, Jun 15, 2020 at 2:42 PM Patrick McManus < > patrick.ducksong@gmail.com> wrote: > >> Sounds really interesting Emad and there's obviously related work going >> on (at least perc, maybe even mls..). >> >> Sending that email Ben mentions to the dispatch list to raise awareness >> with a link to the draft would be helpful in getting the process started= .. >> >> On Mon, Jun 15, 2020 at 2:33 PM Emad Omara wrote: >> >>> Hi Ben, >>> >>> This draft proposes a solution for end-to-end encrypted conference >>> calls. We implemented this in Google a couple of years ago in Duo, but = the >>> draft was only published last month given the current interest in the t= opic. >>> >>> The goal of the session is to go through the proposal and see if there >>> is interest to continue working on this, and if so what will be the bes= t WG >>> to host this work. >>> >>> Thanks >>> Emad >>> >>> On Mon, Jun 15, 2020 at 11:02 AM Ben Campbell wrote: >>> >>>> Hi Emad, >>>> >>>> We prioritize DISPATCH meeting time to focus on topics that have had >>>> DISPATCH list discussion and need high-bandwidth time to resolve. Unle= ss >>>> I=E2=80=99ve missed something, this topic has not previously come up i= n DISPATCH. I >>>> suggest sending a note to this list with some background about the dra= ft >>>> and how you would like to see it progress. >>>> >>>> Thanks! >>>> >>>> Ben. >>>> >>>> On Jun 15, 2020, at 12:32 PM, Emad Omara < >>>> emadomara=3D40google.com@dmarc.ietf.org> wrote: >>>> >>>> Hi, >>>> >>>> We would like to have a session in the next IETF to discuss the SFrame >>>> draft Can you >>>> please help scheduling this? >>>> >>>> Thanks >>>> Emad >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>>> >>>> > --0000000000008a3de905a82452be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks.

Some responses inline. Ot= her authors please feel free to add more.

Emad

On Mo= n, Jun 15, 2020 at 12:13 PM Ben Campbell <ben@nostrum.com> wrote:
Thanks, Patri= ck.

Authors: It would be helpful to get a little more ba= ckground:=C2=A0

- How does this work relate to PER= C? What problem does it solve that PERC doesn=E2=80=99t?
This is a completely different approach than PERC. THis draft ai= ms for simplicity and efficiency. The sdrame draft itself has some benchmar= ks against the PERC approach.=C2=A0 That being said the sframe draft focuse= s mainly on the media encryption part and touches slightly other parts in t= he system like key management and integration with WebRTC. If this became a= standard we will have to write a separate=C2=A0draft for each of these two= topics.=C2=A0
- Do you expect this to become an= IETF standard available to anyone to implement? Who do you think would imp= lement it?=C2=A0
Yes. This will be implemented= =C2=A0by the=C2=A0 video conference providers. The core protocol implementa= tion is on the client side.
- Is anyone outside = of Google working on the spec or implementing the protocol? Has anyone outs= ide of Google expressed interest in doing so?
= Yes, the document is co-authored by=C2=A0+Sergio murillo=C2=A0&=C2=A0+Alexandre GOUAILLARD=C2=A0from Cosmos Software.=C2=A0=
- Anything else you think would help motivate p= eople to read the draft and give feedback :-)

Than= ks!

Ben.

On Jun 15, 2020, at 2:05 PM, Patrick McManus <patrick.ducksong@= gmail.com> wrote:

Hi= All -

I failed to note the link highlighting in Emad's mail to = the list which already contained the draft. Sorry about that. (It's=C2= =A0https://tools.ietf.org/html/draft-omara-sframe-00=C2=A0if you t= oo missed it).

There's also a github and mailing list referenced= :
https:/= /github.com/eomara/sframe
https://mailarchive.ietf.org/arch/bro= wse/sframe/?

[I've also forked the Subject L= ine to help interested readers]

<= div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jun 15, 2020 at 2:42 PM Patric= k McManus <patrick.ducksong@gmail.com> wrote:
Sounds really interesting Ema= d and there's obviously related=C2=A0work going on (at least perc, mayb= e even mls..).

Sending that email Ben mentions to the di= spatch list to raise awareness with a link to the draft would be helpful in= getting the process started..

On Mon, Jun 15, 2020 at 2:33 PM Emad Om= ara <emadomara= @google.com> wrote:
Hi Ben,

This draft proposes = a solution for end-to-end encrypted conference calls. We implemented=C2=A0t= his in Google a couple of years ago in Duo, but the draft was only publishe= d last month given the current interest in the topic.

<= div>The goal of the session is to go through the proposal and see if there = is interest to continue working on this, and if so what will be the best WG= to host this work.=C2=A0

Thanks
Emad

On Mon, Jun 15, 2020 at 11:02 AM Ben Campbell <ben@nostrum.com> wrote:
Hi Emad,

<= div>We prioritize DISPATCH meeting time to focus on topics that have had DI= SPATCH list discussion and need high-bandwidth time to resolve. Unless I=E2= =80=99ve missed something, this topic has not previously come up in DISPATC= H. I suggest sending a note to this list with some background about the dra= ft and how you would like to see it progress.

Than= ks!

Ben.

On Jun 15, 2020, at 12:32 PM, Emad Omara <emadomara=3D40google.com@= dmarc.ietf.org> wrote:

Hi,

We would like to have a session in the next IETF to discuss the SFrame draft=C2=A0Can you please help scheduling this?
Thanks
Emad
_______________________________________________
dispatch mailing listdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


--0000000000008a3de905a82452be-- From nobody Mon Jun 15 12:29: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 5ABE63A091C for ; Mon, 15 Jun 2020 12:29:31 -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 abO5Z3O-DG2U for ; Mon, 15 Jun 2020 12:29:28 -0700 (PDT) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (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 32F253A0912 for ; Mon, 15 Jun 2020 12:29:28 -0700 (PDT) Received: by mail-qv1-xf35.google.com with SMTP id d12so5503684qvn.0 for ; Mon, 15 Jun 2020 12:29:28 -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=usmSYOdrwAP4QhCy2FKKUHSQsgQ641y04x27a6Q08zo=; b=FFX3QlBoe+FWt0QSE0jzpySi/ZKZ3+aqf/97hZ3tQXCtEUZq7ZpWrr1fs351f/Cb4C xAtfosWoiiHePD/vtsVV90AM5iIATSiOkgVkhrD+KToUL0anQRQGOC17aa310OU2Accf NZGT46TtH3dvXY1jqyzsekU0uHpSPRjozxnuo8ztrfloAnm7OlGk2niqMZxCDVPP5PmY ovWNeyx8elKtRLryKBV6pE150xZqjgBuLLO/Ut14fDVbbbJ0QsqZOM+PbH2nQlnDUwe9 NafhcxtMqtHko6H5Xb+QZ5WX/ASF66r46ELqq7DhN79y3YveEG+WlXBNMgrm9UzWObUO 0X7A== 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=usmSYOdrwAP4QhCy2FKKUHSQsgQ641y04x27a6Q08zo=; b=XiHU5S0+2/lm80iFOV/wIXP7l9qLgAx3zWX+TnvY/W1p/gW9Vj+KDK3qy0IU0ILu+D 6wgiYbthWXYL21WhhF/HZ8aicpQSOhh/cn8XtUatr+1jPmBgkuQwvdCyZd9H7vYKKDJV rdl4glirI2FelpX+hSRIxYm/ukT1FbcfE2e2UYqyBhZUFVyFYxSwQl05Qvzws9/MyFgv Hx7qyomw7KRlpNqrDNpyzuBAXokbUBMRq4wtT5UGxGpsyFOFMg1p2ogr6oNHyrGJgdn3 c54+0hdAvIiGZynDpjX7PKk252Or+Z9dPjmpuVvI44PE6zSapG+2y3Srt2a+Kc/SNHqr I/ug== X-Gm-Message-State: AOAM530WQZ+RNqbZMAyOV0CvmLg69PMh3qe9VBkkPbY/Uitr5CcyFWq9 5X4YKCRLoUAQfA/nZtvW+gQ9eJGpjg2Gi1ySQVOBSQ== X-Google-Smtp-Source: ABdhPJwy+/0jfk1j7N6SP8sUJhNki1R2HXtSxzj8xjoDknZHdVT6upW09VreXttTSUQgfk/No30uNNCN0H0dtccyTLQ= X-Received: by 2002:a0c:8482:: with SMTP id m2mr27024380qva.65.1592249366986; Mon, 15 Jun 2020 12:29:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Mon, 15 Jun 2020 15:29:11 -0400 Message-ID: To: Patrick McManus Cc: Emad Omara , Ben Campbell , Dispatch WG , sframe@ietf.org Content-Type: multipart/alternative; boundary="000000000000e9d2bc05a8247197" Archived-At: Subject: Re: [dispatch] [Sframe] Request session at IETF 108 dispatch 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, 15 Jun 2020 19:29:31 -0000 --000000000000e9d2bc05a8247197 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To address the related work point: You're correct that PERC is the main touch point, MLS less so; also RTCWeb if that were still going on. Very directly, this work is doing basically the same thing as PERC double encryption (RFC 8723). The key difference is decoupling between the hop-by-hop and end-to-end security contexts. In PERC, the E2E context uses some information from the HBH SRTP packet. So the fields used by the E2E context have to be unmodified, well, end to end, so that a clean media path is a prerequisite for E2E. (Where "clean" means "don't modify" or "modify in accordance with PERC") This dependency makes it much harder to deploy E2E in practices. In addition, once the E2E layer is decoupled from the HBH layer, it is much easier to transmit it over alternative HBH-secure transports, such as QUIC datagrams, WebTransport, or RIPT. FWIW, if I were to suggest a DISPATCH outcome, a focused WG seems like the right level of attention to me. The topic is worth working on and would benefit from an IETF-consensus specification, but the document isn't yet mature enough for AD sponsorship. --Richard On Mon, Jun 15, 2020 at 2:43 PM Patrick McManus wrote: > Sounds really interesting Emad and there's obviously related work going o= n > (at least perc, maybe even mls..). > > Sending that email Ben mentions to the dispatch list to raise awareness > with a link to the draft would be helpful in getting the process started.= .. > > On Mon, Jun 15, 2020 at 2:33 PM Emad Omara wrote: > >> Hi Ben, >> >> This draft proposes a solution for end-to-end encrypted conference calls= . >> We implemented this in Google a couple of years ago in Duo, but the draf= t >> was only published last month given the current interest in the topic. >> >> The goal of the session is to go through the proposal and see if there i= s >> interest to continue working on this, and if so what will be the best WG= to >> host this work. >> >> Thanks >> Emad >> >> On Mon, Jun 15, 2020 at 11:02 AM Ben Campbell wrote: >> >>> Hi Emad, >>> >>> We prioritize DISPATCH meeting time to focus on topics that have had >>> DISPATCH list discussion and need high-bandwidth time to resolve. Unles= s >>> I=E2=80=99ve missed something, this topic has not previously come up in= DISPATCH. I >>> suggest sending a note to this list with some background about the draf= t >>> and how you would like to see it progress. >>> >>> Thanks! >>> >>> Ben. >>> >>> On Jun 15, 2020, at 12:32 PM, Emad Omara < >>> emadomara=3D40google.com@dmarc.ietf.org> wrote: >>> >>> Hi, >>> >>> We would like to have a session in the next IETF to discuss the SFrame >>> draft Can you >>> please help scheduling this? >>> >>> Thanks >>> Emad >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> >>> -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --000000000000e9d2bc05a8247197 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To address the related work point:

You're correct that PERC is the main touch point, MLS less so; a= lso RTCWeb if that were still going on.=C2=A0 Very directly, this work is d= oing basically the same thing as PERC double encryption (RFC 8723).=C2=A0 T= he key difference is decoupling between the hop-by-hop and end-to-end secur= ity contexts.=C2=A0 In PERC, the E2E context uses some information from the= HBH SRTP packet.=C2=A0 So the fields used by the E2E context have to be un= modified, well, end to end, so that a clean media path is a prerequisite fo= r E2E.=C2=A0 (Where "clean" means "don't modify" or= "modify in accordance with PERC")=C2=A0 This dependency makes it= much harder to deploy E2E in practices.=C2=A0 In addition, once the E2E la= yer is decoupled from the HBH layer, it is much easier to transmit it over = alternative HBH-secure transports, such as QUIC datagrams, WebTransport, or= RIPT.

FWIW, if I were to suggest a DISPATCH outco= me, a focused WG seems like the right level of attention to me.=C2=A0 The t= opic is worth working on and would benefit from an IETF-consensus specifica= tion, but the document isn't yet mature enough for AD sponsorship.

--Richard



On Mo= n, Jun 15, 2020 at 2:43 PM Patrick McManus <patrick.ducksong@gmail.com> wrote:
Sounds really = interesting Emad and there's obviously related=C2=A0work going on (at l= east perc, maybe even mls..).

Sending that email Ben men= tions to the dispatch list to raise awareness with a link to the draft woul= d be helpful in getting the process started...

On Mon, Jun 15, 2020 at= 2:33 PM Emad Omara <emadomara@google.com> wrote:
Hi Ben,

This= draft proposes a solution for end-to-end encrypted conference calls. We im= plemented=C2=A0this in Google a couple of years ago in Duo, but the draft w= as only published last month given the current interest in the topic.
=

The goal of the session is to go through the proposal a= nd see if there is interest to continue working on this, and if so what wil= l be the best WG to host this work.=C2=A0

Thanks
Emad

On Mon, Jun 15, 2020 at 11:02 AM Ben Campbell <ben@nostrum.com> wrot= e:
Hi Emad,=

We prioritize DISPATCH meeting time to focus on topics = that have had DISPATCH list discussion and need high-bandwidth time to reso= lve. Unless I=E2=80=99ve missed something, this topic has not previously co= me up in DISPATCH. I suggest sending a note to this list with some backgrou= nd about the draft and how you would like to see it progress.
Thanks!

Ben.

On Jun 15, 2020, at 12:32 PM, Emad Omara <emadomara= =3D40google.com@dmarc.ietf.org> wrote:

Hi,

We would like to have a session in the next IETF t= o discuss the SFrame draft=C2=A0Can you please help scheduling thi= s?

Thanks
Emad
_______________________________________________
dispatch mailing listdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--000000000000e9d2bc05a8247197-- From nobody Mon Jun 15 12:30: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 CAB723A091A for ; Mon, 15 Jun 2020 12:30:30 -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 kPzU8MMsUP07 for ; Mon, 15 Jun 2020 12:30:29 -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 042353A0912 for ; Mon, 15 Jun 2020 12:30:28 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id n11so16916813qkn.8 for ; Mon, 15 Jun 2020 12:30:28 -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=LeNI+1yuLit3/ZWjjJEGC312MJLgqZEh0xA2ccRhqdU=; b=k9ghVVZh7l+bYKjMniVq9UQTl/yQ33JPZj9uOCC6avlnyb/agd91eMHTBDez9hlNOs zv0GxiQt0Vd/KnCc7rpdkHYVRjjBaohvdZkuvz+NZnvuAjKA0uFDygYamlqt9kxHHBxT pTqVLyKPONOcA8NDJeoSLDmcwhPXO5T6IA+wnGxnECFytsyaWHE/Wbp4s985NlpI21bn ZerAPDNYdaMFg2MldmwZJG2Kp3QA7g8wmgJGeJqVBlasSRM7eDyv7mm8PTyh9ZVLxjYN Yj9RQVVXBa2wWqY/UHkwLyGR0APrMuRN/Bs3aBlEuYMWbVtTQXfz4kkjaLTQE2Gx845x O+HQ== 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=LeNI+1yuLit3/ZWjjJEGC312MJLgqZEh0xA2ccRhqdU=; b=O2dViPIKfFoaJnd6rulwV3Bv0YaHyK4gHT0Xcpi7lNMj9EGl4E4NTog62vSS0OxqS9 ScTeE8rqpfrhs8UJZFVMIFurU+qtJKQgmIF0yQJuswhxNxVdt/DYQzXQpoj+PxhsI2oc Eau8nCkJ4cZDCTacoHrPmQ0AobWYZe3rGekLqKaxI63Wo1DTdsbdpICrnOmDSEkHqj0u 4ihX8T8lYXS1lRVKLVpqnu7yN4AujzWAuuQ/pJ++tjDqn+2N2M7RwsKxmmrWjyVqoshI iPT6d8j2B3oIPpPt2Wm+WZ3P6R26APZ3GfYjfhJKQSVWH7vCWIpzjGiCk9DR8beOlPqu U4sQ== X-Gm-Message-State: AOAM532WYve1Sp7iK+x6MOFYLgZtBG7MwHPYcoArpC/oob2wpXy7hu9T 1qk/J6HfoNyZRpk6k/6qQnGS/fOsE4CB+dJ9ZD6G2g== X-Google-Smtp-Source: ABdhPJxJJGQnMuwUdtw6GoJjHj04m1NXopWdO2wERsaMjPU/S8+dPvk0tJ0FegD7Ya18k2Qk6VdYtKi/agjHOGNkGpE= X-Received: by 2002:a37:5842:: with SMTP id m63mr17034695qkb.347.1592249427887; Mon, 15 Jun 2020 12:30:27 -0700 (PDT) MIME-Version: 1.0 References: <4425D473-7A6A-4AF5-BA53-635255D6EC55@nostrum.com> In-Reply-To: From: Richard Barnes Date: Mon, 15 Jun 2020 15:30:12 -0400 Message-ID: To: Emad Omara Cc: Ben Campbell , Sergio murillo , Alexandre GOUAILLARD , Patrick McManus , Dispatch WG , sframe@ietf.org Content-Type: multipart/alternative; boundary="0000000000008b1cfe05a82475ee" Archived-At: Subject: Re: [dispatch] [Sframe] Dispatch of SFrame for End-To-End Encrypted Conference Calls 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, 15 Jun 2020 19:30:31 -0000 --0000000000008b1cfe05a82475ee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 15, 2020 at 3:20 PM Emad Omara wrote: > Thanks. > > Some responses inline. Other authors please feel free to add more. > > Emad > > On Mon, Jun 15, 2020 at 12:13 PM Ben Campbell wrote: > >> Thanks, Patrick. >> >> Authors: It would be helpful to get a little more background: >> >> - How does this work relate to PERC? What problem does it solve that PER= C >> doesn=E2=80=99t? >> > This is a completely different approach than PERC. THis draft aims for > simplicity and efficiency. The sdrame draft itself has some benchmarks > against the PERC approach. That being said the sframe draft focuses main= ly > on the media encryption part and touches slightly other parts in the syst= em > like key management and integration with WebRTC. If this became a standar= d > we will have to write a separate draft for each of these two topics. > >> - Do you expect this to become an IETF standard available to anyone to >> implement? Who do you think would implement it? >> > Yes. This will be implemented by the video conference providers. The cor= e > protocol implementation is on the client side. > >> - Is anyone outside of Google working on the spec or implementing the >> protocol? Has anyone outside of Google expressed interest in doing so? >> > Yes, the document is co-authored by +Sergio murillo > & +Alexandre GOUAILLARD > from Cosmos Software. > On this last point: We are considering this for some projects at Cisco. --Richard > - Anything else you think would help motivate people to read the draft an= d >> give feedback :-) >> >> Thanks! >> >> Ben. >> >> On Jun 15, 2020, at 2:05 PM, Patrick McManus >> wrote: >> >> Hi All - >> >> I failed to note the link highlighting in Emad's mail to the list which >> already contained the draft. Sorry about that. (It's >> https://tools.ietf.org/html/draft-omara-sframe-00 if you too missed it). >> >> There's also a github and mailing list referenced: >> https://github.com/eomara/sframe >> https://mailarchive.ietf.org/arch/browse/sframe/? >> >> [I've also forked the Subject Line to help interested readers] >> >> On Mon, Jun 15, 2020 at 2:42 PM Patrick McManus < >> patrick.ducksong@gmail.com> wrote: >> >>> Sounds really interesting Emad and there's obviously related work going >>> on (at least perc, maybe even mls..). >>> >>> Sending that email Ben mentions to the dispatch list to raise awareness >>> with a link to the draft would be helpful in getting the process starte= d.. >>> >>> On Mon, Jun 15, 2020 at 2:33 PM Emad Omara wrote= : >>> >>>> Hi Ben, >>>> >>>> This draft proposes a solution for end-to-end encrypted conference >>>> calls. We implemented this in Google a couple of years ago in Duo, but= the >>>> draft was only published last month given the current interest in the = topic. >>>> >>>> The goal of the session is to go through the proposal and see if there >>>> is interest to continue working on this, and if so what will be the be= st WG >>>> to host this work. >>>> >>>> Thanks >>>> Emad >>>> >>>> On Mon, Jun 15, 2020 at 11:02 AM Ben Campbell wrote: >>>> >>>>> Hi Emad, >>>>> >>>>> We prioritize DISPATCH meeting time to focus on topics that have had >>>>> DISPATCH list discussion and need high-bandwidth time to resolve. Unl= ess >>>>> I=E2=80=99ve missed something, this topic has not previously come up = in DISPATCH. I >>>>> suggest sending a note to this list with some background about the dr= aft >>>>> and how you would like to see it progress. >>>>> >>>>> Thanks! >>>>> >>>>> Ben. >>>>> >>>>> On Jun 15, 2020, at 12:32 PM, Emad Omara < >>>>> emadomara=3D40google.com@dmarc.ietf.org> wrote: >>>>> >>>>> Hi, >>>>> >>>>> We would like to have a session in the next IETF to discuss the SFram= e >>>>> draft Can you >>>>> please help scheduling this? >>>>> >>>>> Thanks >>>>> Emad >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>> >>>>> >>>>> >> -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --0000000000008b1cfe05a82475ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jun 15, 2020 at 3:20 PM Emad = Omara <emadomara=3D40goog= le.com@dmarc.ietf.org> wrote:
Thanks.

Some= responses inline. Other authors please feel free to add more.

Emad

On Mon, Jun 15, 2020 at 12:13 PM Ben Campbell <ben@nostrum.com> wrote= :
Thanks, P= atrick.

Authors: It would be helpful to get a little mor= e background:=C2=A0

- How does this work relate to= PERC? What problem does it solve that PERC doesn=E2=80=99t?
This is a completely different approach than PERC. THis draf= t aims for simplicity and efficiency. The sdrame draft itself has some benc= hmarks against the PERC approach.=C2=A0 That being said the sframe draft fo= cuses mainly on the media encryption part and touches slightly other parts = in the system like key management and integration with WebRTC. If this beca= me a standard we will have to write a separate=C2=A0draft for each of these= two topics.=C2=A0
<= div>
- Do you expect this to become an IETF standard available to anyon= e to implement? Who do you think would implement it?=C2=A0
Yes. This will be implemented=C2=A0by the=C2=A0 video conferen= ce providers. The core protocol implementation is on the client side.
=
- Is anyone out= side of Google working on the spec or implementing the protocol? Has anyone= outside of Google expressed interest in doing so?
=
Yes, the document is co-authored by=C2=A0+Sergio murillo=C2=A0&a= mp;=C2=A0+Alexandre GOUAILLARD=C2=A0from Cosmos Software.=C2=A0
=

On this last point: We are con= sidering this for some projects at Cisco.

--Richar= d

=C2=A0
- Anything else you thi= nk would help motivate people to read the draft and give feedback :-)
=

Thanks!

Ben.

On Jun 15, 2020, at 2:05 PM, Pa= trick McManus <patrick.ducksong@gmail.com> wrote:

Hi All -

I failed to note the link highlightin= g in Emad's mail to the list which already contained the draft. Sorry a= bout that. (It's=C2=A0https://tools.ietf.org/html/draft-omara-sfra= me-00=C2=A0if you too missed it).

There's also a github and = mailing list referenced:
https://github.com/eomara/sframe
https://mailar= chive.ietf.org/arch/browse/sframe/?

[I've al= so forked the Subject Line to help interested readers]

On Mon, Jun 15,= 2020 at 2:42 PM Patrick McManus <patrick.ducksong@gmail.com> wrote:
Sounds= really interesting Emad and there's obviously related=C2=A0work going = on (at least perc, maybe even mls..).

Sending that email= Ben mentions to the dispatch list to raise awareness with a link to the dr= aft would be helpful in getting the process started..

On Mon, Jun 15, = 2020 at 2:33 PM Emad Omara <emadomara@google.com> wrote:
Hi Ben,

This draft proposes a solution for end-to-end encrypted conference calls= . We implemented=C2=A0this in Google a couple of years ago in Duo, but the = draft was only published last month given the current interest in the topic= .

The goal of the session is to go through the pro= posal and see if there is interest to continue working on this, and if so w= hat will be the best WG to host this work.=C2=A0

T= hanks
Emad

On Mon, Jun 15, 2020 at 11:02 AM Ben Campbell <= ;ben@nostrum.com&g= t; wrote:
H= i Emad,

We prioritize DISPATCH meeting time to focus on = topics that have had DISPATCH list discussion and need high-bandwidth time = to resolve. Unless I=E2=80=99ve missed something, this topic has not previo= usly come up in DISPATCH. I suggest sending a note to this list with some b= ackground about the draft and how you would like to see it progress.
<= div>
Thanks!

Ben.

On Jun 15, 2020, at 12:32 PM, Emad Omara <ema= domara=3D40google.com@dmarc.ietf.org> wrote:

Hi,

We would like to have a session in the next= IETF to discuss the SFrame draft=C2=A0Can you please help schedul= ing this?

Thanks
Emad
_______________________________________________
dispatch mailing listdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--0000000000008b1cfe05a82475ee-- From nobody Mon Jun 15 13:13: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 E36023A0999; Mon, 15 Jun 2020 13:13:19 -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 qiKnF-_kyxvM; Mon, 15 Jun 2020 13:13:14 -0700 (PDT) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450: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 31F1D3A0985; Mon, 15 Jun 2020 13:13:02 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id l26so798014wme.3; Mon, 15 Jun 2020 13:13:02 -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-language; bh=ojtXvp9gp2tUZp2czMuWbXwG4Esmq4fvjvV4BClrv5g=; b=GY07vcS5Fo2cRHj+D1ddG0NNiAhn8++La8n/a2D8Q9tGVvnwK7HakC+DLbQt68CvYu 0eXMulr20cUvV46hRtfe8bWopWDCd1SylmWSfacPseiC9sgPjrC2kji8c0x4l9kfnUGa UYC/ZNc/ZMVi2vQDbKqRhDEMdTEAYU7bBvdzgdya6n0e3qlsgEHObZni9l6ya84m4n1/ 4KHFBNLgOAT9S7UxtYSDY1VpZ3g96WJkSWJLpqVVBTiDxtFYOs6EMap6q3vERjZvLss4 dsBeb2SGVePnLa/etCj4LIlMUVicuYj8PRvO6GoBocz7KLCXKTdJxDu0pR6CHulvkb2e HTNg== 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-language; bh=ojtXvp9gp2tUZp2czMuWbXwG4Esmq4fvjvV4BClrv5g=; b=N9gmGD8zatzTVdMGL7q3NGNuUym5WSCEUslq+B/ySswztKdIk1BceRT2WDyzU+dks+ LHH32n7T38K24lLnAOB8zCkTJax8SanKBHpiE1IDOUCbq0n92DYX2RDaqmIr0vxSCQyY nmMIkPvPg+42eGTq0LIPmYoor83EijdevFFkzNU+lOxbZOWK9+Bn/3sAc/9wxL7P7Xjf WE+NWCEph3nBzToMDv9ZueLz4qOxHoZGt7q7Sp++thgU0JqWk7HBEITFzYwap3mg4XmF JKMgpdRrtvPQly6yPF2vrxs0cYo3NXdOkqmqxBhyl1wBdIxbMxC0gNjFwcGTw2ypXv77 Dx/g== X-Gm-Message-State: AOAM530bvsGMTjyPdkqTDLT5m3BoWzxso6ODyGEgdROH7BHeUsEvH8YZ 9w6F+WgTIwxre53dPdC91Ak/ikci8Yo= X-Google-Smtp-Source: ABdhPJy8yWh0GOaCNivkEO2EtbqBmKoZbwMtQVeBF3qNC5og0rplPKYq+dQ1Yh89pMs+RGbPKp7Ydw== X-Received: by 2002:a05:600c:4152:: with SMTP id h18mr1014270wmm.189.1592251979321; Mon, 15 Jun 2020 13:12:59 -0700 (PDT) Received: from [192.168.0.11] (79.108.125.160.dyn.user.ono.com. [79.108.125.160]) by smtp.googlemail.com with ESMTPSA id b185sm1498554wmd.3.2020.06.15.13.12.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Jun 2020 13:12:58 -0700 (PDT) To: Ben Campbell , Patrick McManus Cc: Dispatch WG , Emad Omara , sframe@ietf.org References: <4425D473-7A6A-4AF5-BA53-635255D6EC55@nostrum.com> From: Sergio Garcia Murillo Message-ID: Date: Mon, 15 Jun 2020 22:13:00 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <4425D473-7A6A-4AF5-BA53-635255D6EC55@nostrum.com> Content-Type: multipart/alternative; boundary="------------4034487050AB7305F7FC3CD3" Content-Language: en-US Archived-At: Subject: Re: [dispatch] Dispatch of SFrame for End-To-End Encrypted Conference Calls 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, 15 Jun 2020 20:13:20 -0000 This is a multi-part message in MIME format. --------------4034487050AB7305F7FC3CD3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 15/06/2020 21:13, Ben Campbell wrote: > - Do you expect this to become an IETF standard available to anyone to > implement? Who do you think would implement it? > - Is anyone outside of Google working on the spec or implementing the > protocol? Has anyone outside of Google expressed interest in doing so? Cosmo has co-authored the spec and we have released an open source pure javascript implementation based on webcrypto (https://github.com/medooze/sframe) and using with w3c insertable streams (https://github.com/w3c/webrtc-insertable-streams) It is already integrated in Medooze products: https://medium.com/@medooze/sframe-js-end-to-end-encryption-for-webrtc-f9a83a997d6d And in Janus: https://www.meetecho.com/blog/janus-e2ee-sframe/ Best regards Sergio --------------4034487050AB7305F7FC3CD3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 15/06/2020 21:13, Ben Campbell wrote:
- Do you expect this to become an IETF standard available to anyone to implement? Who do you think would implement it?
- Is anyone outside of Google working on the spec or implementing the protocol? Has anyone outside of Google expressed interest in doing so?

Cosmo has co-authored the spec and we have released an open source pure javascript implementation based on webcrypto (https://github.com/medooze/sframe) and using with w3c insertable streams (https://github.com/w3c/webrtc-insertable-streams)

It is already integrated in Medooze products:

https://medium.com/@medooze/sframe-js-end-to-end-encryption-for-webrtc-f9a83a997d6d

And in Janus:

https://www.meetecho.com/blog/janus-e2ee-sframe/


Best regards

Sergio
--------------4034487050AB7305F7FC3CD3-- From nobody Mon Jun 15 13:21:40 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 5FA1C3A0C81 for ; Mon, 15 Jun 2020 13:21:37 -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=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 R1vP8voJW7wC for ; Mon, 15 Jun 2020 13:21:35 -0700 (PDT) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 61D4C3A0B21 for ; Mon, 15 Jun 2020 13:21:34 -0700 (PDT) Received: by mail-ot1-x32e.google.com with SMTP id k15so14161770otp.8 for ; Mon, 15 Jun 2020 13:21:34 -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=dc0FiEAGsa+M6f8l6fn/fgt01MGnlCUXqt5yDoKd+3M=; b=eHJZ9yT13U3Xo5I6nETVv+qLUY/kK77wMFp+RZYDscoEf4W2v9bPUcyTfYueXIBFfT QxJgCQ1iTASCAdn5ZLD5zXz39vdBWtxDhUrwsorVLzjzt2O0u25UPDM+TsxVvS74v3cw X2xWj7Sg6RlivtIZjqxMXU5EdDHm2ckrnTQQ95QrLAM/v/C2P7wqBgCuJUxffx+IIoOR kTK25qtAphFDIgrBLv1btM1Vy6HkrGSWOXxagtzsuPqWfHMx+N1DWHxfoMHgXffACKF3 GflK3YAS0fpwZcSDOHc5mXuJLumqg4GHFShogBn7KuQ/FdHt/aejC6754GbSGNejCqcF vvyg== 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=dc0FiEAGsa+M6f8l6fn/fgt01MGnlCUXqt5yDoKd+3M=; b=qkLVfbwt6XU0vCoet5fCHZdoW54Hjebyv6XYc18XQAt5pEnA5IGqUb2VYy77o2cyz2 mmwTENrJL8Ky5if2QaHXhVhkfk5a3yn19wdK5dcXaJuAYjxDndyyBhHFPzIgutY3KmB9 3jv1gCE0JBmxKnUOcjr3G+93bp0tkxOKa9nNiMUgpg7b5ZSAHAVdZd0UQJJO7cQoRui3 9+x/Lwkrm/Gbn0Y2HIAQARQBfs4WTuhfDFyabV1zInL8b8M4XvOrQ/UVtoQJ0eKYp7uO qegEXv3SvIBfyQEohtlbTpHdKpR3PNb9QvgNQD3S0PyPxy5PKSbXJXSydqxhRYnRdlg0 yscQ== X-Gm-Message-State: AOAM530w688q2hQVjfLV7t0VRdsWfiysmfdo0Rygr1gY3Mu05AxzZeIj Jzjqjffj8unMzDY+JmASKydtIBP6Oy2v6t9PUuxeCw== X-Google-Smtp-Source: ABdhPJzm0FHJuJqDEYk1TPW2v9pnHS9CQn6E8ku5gS6ZxryB+DBnu+wH7kYOWzOa+RINxLXJ1dOOzcCoss+B/667VoQ= X-Received: by 2002:a9d:3f37:: with SMTP id m52mr24573281otc.255.1592252493171; Mon, 15 Jun 2020 13:21:33 -0700 (PDT) MIME-Version: 1.0 References: <4425D473-7A6A-4AF5-BA53-635255D6EC55@nostrum.com> In-Reply-To: From: Alexandre GOUAILLARD Date: Mon, 15 Jun 2020 22:21:22 +0200 Message-ID: To: Sergio Garcia Murillo Cc: Ben Campbell , Patrick McManus , Emad Omara , Dispatch WG , sframe@ietf.org Content-Type: multipart/alternative; boundary="0000000000003fa0c205a8252c70" Archived-At: Subject: Re: [dispatch] [Sframe] Dispatch of SFrame for End-To-End Encrypted Conference Calls 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, 15 Jun 2020 20:21:37 -0000 --0000000000003fa0c205a8252c70 Content-Type: text/plain; charset="UTF-8" With respect to PERC, SFrame is media transport agnostic, and would work with QUIC, while PERC is Rtp-Based only.Conferencing only, and assume e.g. SRTP. On Mon, Jun 15, 2020 at 10:13 PM Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > > On 15/06/2020 21:13, Ben Campbell wrote: > > - Do you expect this to become an IETF standard available to anyone to > implement? Who do you think would implement it? > - Is anyone outside of Google working on the spec or implementing the > protocol? Has anyone outside of Google expressed interest in doing so? > > > Cosmo has co-authored the spec and we have released an open source pure > javascript implementation based on webcrypto ( > https://github.com/medooze/sframe) and using with w3c insertable streams ( > https://github.com/w3c/webrtc-insertable-streams) > > It is already integrated in Medooze products: > > > https://medium.com/@medooze/sframe-js-end-to-end-encryption-for-webrtc-f9a83a997d6d > > And in Janus: > > https://www.meetecho.com/blog/janus-e2ee-sframe/ > > > Best regards > > Sergio > -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --0000000000003fa0c205a8252c70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
With respect to PERC,
SFrame is media transport agnost= ic, and would work with=C2=A0QUIC, while PERC is Rtp-Based only.Conferencin= g only, and assume e.g. SRTP.

On Mon, Jun 15, 2020 at 10:13 PM Sergio = Garcia Murillo <sergi= o.garcia.murillo@gmail.com> wrote:
=20 =20 =20

On 15/06/2020 21:13, Ben Campbell wrote:
- Do you expect th= is to become an IETF standard available to anyone to implement? Who do you think would implement it?
- Is anyone outside of Google working on the spec or implementing the protocol? Has anyone outside of Google expressed interest in doing so?

Cosmo has co-authored the spec and we have released an open source pure javascript implementation based on webcrypto (https://github.com/medooze/sfra= me) and using with w3c insertable streams (https://github.com/w3c/webrt= c-insertable-streams)

It is already integrated in Medooze products:

https://medium.com/@medooze/sfra= me-js-end-to-end-encryption-for-webrtc-f9a83a997d6d

And in Janus:

https://www.meetecho.com/blog/janus-e2ee-sframe/


Best regards

Sergio
--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--0000000000003fa0c205a8252c70-- From nobody Mon Jun 15 21:48: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 981EA3A102F for ; Mon, 15 Jun 2020 21:48:24 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pnTlOqYjbiv for ; Mon, 15 Jun 2020 21:48:23 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0020C3A102D for ; Mon, 15 Jun 2020 21:48:22 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id i3so17330200ljg.3 for ; Mon, 15 Jun 2020 21:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=51YtsT86R0euVT3k2cWdgzHE+Eu6bN3UKGhZSfy5SMc=; b=dpBlaI54mi4mnuV9znpdjfkY4rJlCNkCxF/oQrlqxqOqe/NkACfOOMax+1ghbLKQ2i t9A8Cn7cG78LyJDEuPBwVhTU7+LjWH1PH03GPgKHYfrXFB5wZyRtUan7cf/Jff0cIe5n kPO1s/fhzInniG+4eRBSEgMERUtU9lzQAT4k5dOJyXz8zVMwSEy6B+YzwskbKm9L8VaY pNRBydKUdk04oRp8VuvbXpkc4z75H6KS49WON8qd9DGYfC6LrTu9WwpHwr8I8Kt5VHGr lNEpQ7Mq4FifdV0UaoO00uVGI+iHDUnYWbs3OkrnMKbq+ja7R2+y4GWXaHnb/FTatknW cMQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=51YtsT86R0euVT3k2cWdgzHE+Eu6bN3UKGhZSfy5SMc=; b=bp/6OU6GjZ1KfFwhW1oVG3WINXtt6pwjwLfIAJo+zBUy2ik423B4CiIY+V3R6vr9Gs nA++VywMGQWp8IpTkrC+SxuWS1IUndFx049IzTorZr4Leo4M+8Sa83LDyhtB42LSWU8J pXiYivt5jW852N+an66ElYBo0iGcmKk2iWQx7OcNMWIdqjYg3TrW4yFzvT6cWhPLzXVQ tR7ERiVgEPjOidjWElZjUFku5fGEdENhBKk52lpfxhr16/rIPxjKn4fKs1W1IndcXJEe WSA7+xzEtbOeD0K+KxSjgzUbpmkhZm/29v1FGtj08RcbptDiiOClBlBUqgKiofXsy+bZ RwUA== X-Gm-Message-State: AOAM530hM0sO6Z/Q160AeKY7dckKR3WZtWf2y3MdPTmsJzD+pXMTDjK1 E5qcUcmF4yMlPBbb+11yLBZ4NzifpX/g3gB5K2oLzuW9 X-Google-Smtp-Source: ABdhPJztmWW4vPuoeH7uyB4Iyn/+WLcS3MBsNTtWbsKZhUI9NBGKjDjEIuhHQOWoxsdIhKWK3hv6+gs8gbKxLt2F1Pg= X-Received: by 2002:a2e:8e22:: with SMTP id r2mr506132ljk.240.1592282900508; Mon, 15 Jun 2020 21:48:20 -0700 (PDT) MIME-Version: 1.0 From: Bernard Aboba Date: Mon, 15 Jun 2020 21:48:09 -0700 Message-ID: To: DISPATCH list Content-Type: multipart/alternative; boundary="000000000000aab3e705a82c4023" Archived-At: Subject: Re: [dispatch] [Sframe] Dispatch of SFrame 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, 16 Jun 2020 04:48:25 -0000 --000000000000aab3e705a82c4023 Content-Type: text/plain; charset="UTF-8" Dr. Alexandre Gouailard said: "With respect to PERC, SFrame is media transport agnostic, and would work with QUIC, while PERC is RTP-based only. Conferencing only, and assumes SRTP." [BA] Compared with PERC, SFrame is more efficient and transport agnostic, more compatible with existing codec-independent SFUs, and more flexible in terms of the scenarios it can potentially support. The efficiency point is important for large scale deployments where even a few percent savings in overhead or CPU consumption can translate to savings of millions of dollars in bandwidth, hardware, etc. Transport independence is inherent to the Web architecture, which via Media Source Extensions (MSE) enables media to be transported and rendered via any transport. This includes the WebRTC data channel (used by game streaming services such as parsec) and QuicTransport (now in Origin Trial) as well as today's more common http/https-based streaming mechanisms. While MSE requires the media to be containerized, the WebCodecs API aims to remove this restriction. Since only RTP utilizes SRTP, a transport independent solution cannot be tied to SRTP as PERC double is. Seamless integration with SFUs is also a major advantage. Assuming that the SFU is already codec agnostic (e.g. uses framemarking or the dependency descriptor to forward), very little code (or none) needs to be changed within the SFU, which can continue to do things such as SSRC translation that are prohibited in PERC. In addition, SFrame does not require that the SFU make any modifications to its robustness code (RTX, FEC or RED). Incompatibility with existing SFUs (and RTP implementations in general) was one of the major objections to PERC pointed out in IETF last call. For this reason alone, PERC will never be widely deployed. Finally, SFrame is not tied to a key management scheme, which allows it to be potentially adapted for use in scenarios which may have quite different threat models. This may include 1-1 calls, conference calls, partially or fully anonymous meetings (where some media streams may not be available to some participants), and "protected meetings" (where the recordings are protected from modification). Several commenters in IETF last call pointed out scenarios in which the PERC threat model was insufficient (e.g. PERC allows participants to impersonate each other). In addition, the lack of a key management tie-in in SFrame allows for multiple deployment models, where components of the system may be integrated within the client, or deployed in an on-premise or cloud server, or some hybrid of these. In short, SFrame is simultaneously more efficient, more flexible, more compatible and more deployable than PERC. --000000000000aab3e705a82c4023 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dr. Alexandre Gouailard = said:=C2=A0

"With respect to PERC= , SFrame is media transport agnostic, and would work with QUIC, while PERC = is RTP-based only.=C2=A0 Conferencing only, and assumes SRTP."

[BA] Compared with PERC, SFrame is more efficient and tra= nsport agnostic, more compatible with existing codec-independent SFUs, and = more flexible in terms of the scenarios it can potentially support.

The efficiency point is important for large scale deploym= ents where even a few percent savings in overhead or CPU consumption can tr= anslate to savings of millions of dollars in bandwidth, hardware, etc.=C2= =A0

Transport independence is inherent to the Web = architecture, which via Media Source Extensions (MSE) enables media to be t= ransported and rendered via any transport. This includes the WebRTC data ch= annel (used by game streaming services such as parsec) and QuicTransport=C2= =A0(now in Origin Trial) as well as today's more common http/https-base= d streaming mechanisms.=C2=A0 While MSE requires the media to be containeri= zed, the WebCodecs API aims to remove this restriction. Since only RTP util= izes SRTP, a transport independent solution cannot be tied to SRTP as PERC = double is.=C2=A0

Seamless integration with SFUs is= also a major advantage. Assuming that the SFU is already codec agnostic (e= .g. uses framemarking or the dependency descriptor to forward), very little= code (or none) needs to be changed within the SFU, which can continue to d= o things such as SSRC translation that are prohibited in PERC.=C2=A0 In add= ition, SFrame does not require that the SFU make any modifications to its r= obustness code (RTX, FEC or RED). Incompatibility with existing SFUs (and R= TP implementations in general) was one of the major objections to PERC poin= ted out in IETF last call.=C2=A0 For this reason alone, PERC will never be = widely deployed.

Finally, SFrame is not tied to a = key management scheme, which allows it to be potentially adapted for use in= scenarios which may have quite different threat models.=C2=A0 This may inc= lude 1-1 calls, conference calls, partially or fully anonymous meetings (wh= ere some media streams may not be available to some participants), and &quo= t;protected meetings" (where the recordings are protected from modific= ation).=C2=A0 Several commenters in IETF last call pointed out scenarios in= which the PERC threat model was insufficient (e.g. PERC allows participant= s to impersonate each other).=C2=A0

In addition, t= he lack of a key management tie-in in=C2=A0SFrame allows for multiple deplo= yment models, where components of the system may be integrated within the c= lient, or deployed in an on-premise or cloud server, or some hybrid of thes= e.

In short, SFrame is simultaneously more efficie= nt, more flexible, more compatible and more deployable than PERC.

--000000000000aab3e705a82c4023-- From nobody Tue Jun 16 06:02: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 2E14D3A158A for ; Tue, 16 Jun 2020 06:02:14 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4PVTw7Aal8D for ; Tue, 16 Jun 2020 06:02:12 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 6C8BF3A158B for ; Tue, 16 Jun 2020 06:02:11 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id 9so23445239ljc.8 for ; Tue, 16 Jun 2020 06:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZYl2azHEder9dIbeaETnmv6HLconUhEHS/0Zx/kmnqo=; b=ZQHl9uf3DYtHM6hFpUxK0lTlwaid22jUArEmIHDu9VywSVMSY7RsnKcB6FhmouIv/v e81gDSZzbuyTUE9fqnil9e96sI5wqyeo9cSBuXG673XbQTWuPUvOXBKLroHo0EJ/bbS9 1KhM8GQkUx146sNC68p97kpbhkc2fmIfR45AjZMOEOzrorBmJ4HCaVO2jiwua8embMat 67u+5tX4Llfb1K7C4a8HLM89FYPRWW9v1U6YuHHCdEfgCOy5TkDgPJ5pRuZOZcAeLJQK 4t1eOWWclHjJQDc5tt6Ozf5XpTZj50X6lyTfPZ0rBUhti+xGjqsiRpvHw5zUZZmW+Onv 4viQ== 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=ZYl2azHEder9dIbeaETnmv6HLconUhEHS/0Zx/kmnqo=; b=fRPSqcKQRprQJIlPrIDAKWh0agyzdewC/ye5JQdp3KGIufGLW7WSBvDL+/47KwNsp/ nqA9cuqfKd0qFA2vRNmYvZMi8Uw+A8r4W3XRH0KQ0H/gH1mYjRW9pmknNJ2Voed1iFBx Z6jIUvTfTINZ19iZ4jWCjEFCYTI4Fr/ad0/qFG82KoHPQkphnl8iOx3FOGYf+Sgzdgvx dwziPjxMQ9b2T5DKJnJ5Nq/D3QeUJniEnV/E6l15yYutz1Gl8aM0YdXJ/0Bs6ISBouj0 LQBwS51a4T/9RZynVWqZ/vF3hhKk81j5G1ayHfhS1eqb0EeK8890FRnkKnKt3LnSPRZ1 mfCA== X-Gm-Message-State: AOAM533GG9z/PlquYIqntuKTKrdGSpudEcvMo3EZqfW7U3oB0qGk5siI 7YfjfIQ55fgoFZ/4+e6R9ijUK8pvlOEZwWCIHTvOPA== X-Google-Smtp-Source: ABdhPJyo4uOMatVPjL9lNaFx5eFZ7xSfMxI2uWsx8MrtfXdivdAnyBwL/ktAWD0BczKK5D6Xkhrcfq7QS5YTMrVDdxI= X-Received: by 2002:a2e:9cd4:: with SMTP id g20mr1365251ljj.371.1592312529448; Tue, 16 Jun 2020 06:02:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Tue, 16 Jun 2020 06:01:33 -0700 Message-ID: To: Bernard Aboba Cc: DISPATCH list Content-Type: multipart/alternative; boundary="000000000000b0859e05a8332696" Archived-At: Subject: Re: [dispatch] [Sframe] Dispatch of SFrame 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, 16 Jun 2020 13:02:20 -0000 --000000000000b0859e05a8332696 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 15, 2020 at 9:48 PM Bernard Aboba wrote: > > Finally, SFrame is not tied to a key management scheme, which allows it to > be potentially adapted for use in scenarios which may have quite different > threat models. This may include 1-1 calls, conference calls, partially or > fully anonymous meetings (where some media streams may not be available to > some participants), and "protected meetings" (where the recordings are > protected from modification). Several commenters in IETF last call pointed > out scenarios in which the PERC threat model was insufficient (e.g. PERC > allows participants to impersonate each other). > Note that this is also true of SFrame. It's a property of using MACs rather than signatures. Yes, I know one could add signatures to SFrame, but then one could have added that to PERC as well. -Ekr --000000000000b0859e05a8332696 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jun 15, 2020 at 9:48 PM Berna= rd Aboba <bernard.aboba@gmail= .com> wrote:

Finally, SFrame is not tied = to a key management scheme, which allows it to be potentially adapted for u= se in scenarios which may have quite different threat models.=C2=A0 This ma= y include 1-1 calls, conference calls, partially or fully anonymous meeting= s (where some media streams may not be available to some participants), and= "protected meetings" (where the recordings are protected from mo= dification).=C2=A0 Several commenters in IETF last call pointed out scenari= os in which the PERC threat model was insufficient (e.g. PERC allows partic= ipants to impersonate each other).=C2=A0

Note that this is also true of SFrame. It's a property = of using MACs rather than signatures. Yes, I know one could add signatures = to SFrame, but then one could have added that to PERC as well.

-Ekr
--000000000000b0859e05a8332696-- From nobody Tue Jun 16 06:45:01 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 B7E303A1560 for ; Tue, 16 Jun 2020 06:44:59 -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 6QRK5d1WcLfa for ; Tue, 16 Jun 2020 06:44:58 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450: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 1F5123A1567 for ; Tue, 16 Jun 2020 06:44:58 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id q11so20857315wrp.3 for ; Tue, 16 Jun 2020 06:44: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=yi2n/jLzYgcqoQdFdAOLO3xtjT/VJEhvT22lyv/aSL0=; b=GZbEpmAJ2ZFf1F1uknd31MIsc8XUd1arXZUh4xN0lxe6/MkGcLyfVPOl+DinPde5Pl 5kaYyARS94YndnLRU/O9hgy+avcA4wmJgI0hE6BG0t7Ky9C/QBq5ncJf4hlTAc6fqmBL JGNOs6ZUjSiR8ZvfZRc5JMPMuSpnxGA0PH1xdWfZD3S43m8tW6DSkpoxbt/CYtJKdTOz 98il2ZnY8TwnRTs8/Mn9l3rI/sN9vwZxUc0TMu7cWPxhtxXD/9ReaXDN3vhEOb2avZc6 1cVdOzBlaF7ueKCZR6bEzL7mqYNcvXpT7lgP5xu9ebyYqFimqin7vW4ULnIIAwJWDle1 CcCw== 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=yi2n/jLzYgcqoQdFdAOLO3xtjT/VJEhvT22lyv/aSL0=; b=bfWWW3amCmId1DO+mGBJioDZUz5oHCNPCC3wB6ctTv/Bvlys+4g5lFYSlDXOzAcgn6 TSmuxTN3a1Gq3T5DQIlM+IPXIH8MwLL6Ko0zthcgaW03on8tfeg6JYgasdOL/SMA39ht Iswle0hj4hrjfWGQS7sriGQ1dlh7dJi2PUahwHX99T76jkwQEWlKl1kmyAJWTICzZsDr 0xwfPkIeXWoWp8zSvN3rDOLcyRbNXScsatj4oZ6V7r7d13nqh+wuHIiUI9Z8XMY+D3LC jL4h5eGzk2GXfONBuUu8T2JnTI3opVpb23P4k5eCRGvme5Cit1EbuWXeyHoTuZFC5kWF p0Og== X-Gm-Message-State: AOAM530IFF60u4utM7jeAcVLB+CXSX6CUooZ7s+AtrrDJ/zw5aKzhEGy g6LLQtflmaGX0aWFRoP3kxv4d+40fMEimLocl04= X-Google-Smtp-Source: ABdhPJyIOZ5gRWIdgIQQgZS4fxvg1n1n/E4X2JCoNLn9kxcZNw9hGU2jxaY+JQhLEZVO33B4v7BVrJNXA2ROIyLwS6o= X-Received: by 2002:adf:9205:: with SMTP id 5mr3039373wrj.232.1592315096540; Tue, 16 Jun 2020 06:44:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Sergio Garcia Murillo Date: Tue, 16 Jun 2020 15:44:45 +0200 Message-ID: To: Eric Rescorla Cc: Bernard Aboba , DISPATCH list Content-Type: multipart/alternative; boundary="000000000000b32a8c05a833bf12" Archived-At: Subject: Re: [dispatch] [Sframe] Dispatch of SFrame 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, 16 Jun 2020 13:45:00 -0000 --000000000000b32a8c05a833bf12 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Eric, Sframe already support signatures as well. It is also implemented on my js library. Best regards Sergio El mar., 16 jun. 2020 15:03, Eric Rescorla escribi=C3=B3: > > > On Mon, Jun 15, 2020 at 9:48 PM Bernard Aboba > wrote: > >> >> Finally, SFrame is not tied to a key management scheme, which allows it >> to be potentially adapted for use in scenarios which may have quite >> different threat models. This may include 1-1 calls, conference calls, >> partially or fully anonymous meetings (where some media streams may not = be >> available to some participants), and "protected meetings" (where the >> recordings are protected from modification). Several commenters in IETF >> last call pointed out scenarios in which the PERC threat model was >> insufficient (e.g. PERC allows participants to impersonate each other). >> > > Note that this is also true of SFrame. It's a property of using MACs > rather than signatures. Yes, I know one could add signatures to SFrame, b= ut > then one could have added that to PERC as well. > > -Ekr > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --000000000000b32a8c05a833bf12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eric,

=C2= =A0Sframe already support signatures as well. It is also implemented on my = js library.

Best regards=
Sergio

El mar., 16 jun. 2020 15:03, Eric Resco= rla <ekr@rtfm.com> escribi=C3=B3:


On Mon, Jun 15, 2020 at 9:48 PM Be= rnard Aboba <bernard.aboba@gmail..com> wrote:
=

Finally, SFrame is not tied to a key management sch= eme, which allows it to be potentially adapted for use in scenarios which m= ay have quite different threat models.=C2=A0 This may include 1-1 calls, co= nference calls, partially or fully anonymous meetings (where some media str= eams may not be available to some participants), and "protected meetin= gs" (where the recordings are protected from modification).=C2=A0 Seve= ral commenters in IETF last call pointed out scenarios in which the PERC th= reat model was insufficient (e.g. PERC allows participants to impersonate e= ach other).=C2=A0

Note th= at this is also true of SFrame. It's a property of using MACs rather th= an signatures. Yes, I know one could add signatures to SFrame, but then one= could have added that to PERC as well.

-Ekr
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/lis= tinfo/dispatch
--000000000000b32a8c05a833bf12-- From nobody Tue Jun 16 06:53:50 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 870413A1575 for ; Tue, 16 Jun 2020 06:53:48 -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=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDmVf9julXDQ for ; Tue, 16 Jun 2020 06:53:46 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 7A12F3A1574 for ; Tue, 16 Jun 2020 06:53:46 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id z206so11809525lfc.6 for ; Tue, 16 Jun 2020 06:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Il2751urRN0cFhcEA4qNj+subw3RiYw42zNV5Xr4fe0=; b=XZYyldJHP9UcGr6xG+G9lBmUsgp/xEpgBLgq0Qg9VBSv+3XYSFsKPYNdBoFMxtQFEa nn4WssJ6iV6EiIhO6NEI8RSyQq1h+lQ4xmXLbO5Txb7jrhkQp9v9mY36ZVxhzMvGSil4 MRE/R14PjtvPRASgPv4rf4+KzcCdPfaN01NLlXMrFchaM+Iitp19yTZ0DbKnPnYDjFu/ wgZoCbMZUi/nQLD+EPe1sP+AVILa1M1dc+LNlbPFRCkZAQvtc7k3vfBzWV4pNu6V1XuY Gk2NS+EDeKSKCw3giM1SRu5OYyLhjSvbk/hyEe8Ftse5eRj1PFLAwl3ssecS3kPnusA4 s0Nw== 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=Il2751urRN0cFhcEA4qNj+subw3RiYw42zNV5Xr4fe0=; b=Lqgl57JNrKNtE20WBkarqnDtR0y8iGJPJWacXX7DNzNwtoMVdbHQXAz/aoBCk3aKRH 01tjqhUApAhq+OLKwt0kdst85+/AFPUsAuMdBfP31RY1vYqixm26wgMeGcQjPWeMBfpu qdUWX+5DNAg8kcCxKTJfU7csLheNMTeP/SoLfC9XVmQS25yIP4r+twjiLTrOQWS/d7c1 Lb+ZSKNB4Vpn2gF2UZi4Wjd4RhKBFRZOfpdj2BGhTHpcXh2omZ93TQPrHUF6JC7wATSf 3QU0Yl/wcHnTrdoDB7twrNaDokcwRp0Ib6eznP8Lb9Wub16JWYSk+WmLG2d/3bsLim7w khzA== X-Gm-Message-State: AOAM532KY2xmuoRwz+C1kHXxcxGrVu+106z2ioTnswHVqRL9cB5d0N0r luKsbuff4wWQsroMFvk822QUUHNiXuSpU/O2jZ/e/A== X-Google-Smtp-Source: ABdhPJx4cSBobwMIfIweFfzobnVqDB2NhYaRrJQgrRAnSorXfdUmSWWi+GxW71UNUgDPPPhAoC/kSzMm5UfaOIl4txQ= X-Received: by 2002:ac2:55b2:: with SMTP id y18mr1826047lfg.55.1592315624381; Tue, 16 Jun 2020 06:53:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Tue, 16 Jun 2020 06:53:08 -0700 Message-ID: To: Sergio Garcia Murillo Cc: Bernard Aboba , DISPATCH list Content-Type: multipart/alternative; boundary="00000000000029764c05a833df32" Archived-At: Subject: Re: [dispatch] [Sframe] Dispatch of SFrame 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, 16 Jun 2020 13:53:49 -0000 --00000000000029764c05a833df32 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 16, 2020 at 6:44 AM Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > Hi Eric, > > Sframe already support signatures as well. It is also implemented on my > js library. > Yes, I understand that the wire encoding supports signatures, but in the discussions I've had (including with Emac) I don't think that people believe that the latency/bandwidth/computation tradeoff is viable. -Ekr > Best regards > Sergio > > El mar., 16 jun. 2020 15:03, Eric Rescorla escribi=C3=B3: > >> >> >> On Mon, Jun 15, 2020 at 9:48 PM Bernard Aboba > > wrote: >> >>> >>> Finally, SFrame is not tied to a key management scheme, which allows it >>> to be potentially adapted for use in scenarios which may have quite >>> different threat models. This may include 1-1 calls, conference calls, >>> partially or fully anonymous meetings (where some media streams may not= be >>> available to some participants), and "protected meetings" (where the >>> recordings are protected from modification). Several commenters in IET= F >>> last call pointed out scenarios in which the PERC threat model was >>> insufficient (e.g. PERC allows participants to impersonate each other). >>> >> >> Note that this is also true of SFrame. It's a property of using MACs >> rather than signatures. Yes, I know one could add signatures to SFrame, = but >> then one could have added that to PERC as well. >> >> -Ekr >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > --00000000000029764c05a833df32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jun 16, 2020 at 6:44 AM Sergi= o Garcia Murillo <ser= gio.garcia.murillo@gmail.com> wrote:
Hi Eric,
=C2=A0Sframe already support signatures as well. I= t is also implemented on my js library.

Yes, I understand that the wire encoding supports signatures, but = in the discussions I've had (including with Emac) I don't think tha= t people believe that the latency/bandwidth/computation tradeoff is viable.=

-Ekr


Best regards
Sergio
El mar.,= 16 jun. 2020 15:03, Eric Rescorla <ekr@rtfm.com> escribi=C3=B3:


On Mon, Jun 15, 2020 at 9:48 PM Bernard Aboba <bernard.aboba@gmail..com> wrote:

Finally, SFrame is not tied to a key management scheme, which allows it to= be potentially adapted for use in scenarios which may have quite different= threat models.=C2=A0 This may include 1-1 calls, conference calls, partial= ly or fully anonymous meetings (where some media streams may not be availab= le to some participants), and "protected meetings" (where the rec= ordings are protected from modification).=C2=A0 Several commenters in IETF = last call pointed out scenarios in which the PERC threat model was insuffic= ient (e.g. PERC allows participants to impersonate each other).=C2=A0
=

Note that this is also true of= SFrame. It's a property of using MACs rather than signatures. Yes, I k= now one could add signatures to SFrame, but then one could have added that = to PERC as well.

-Ekr
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/lis= tinfo/dispatch
--00000000000029764c05a833df32-- From nobody Tue Jun 16 07:27:29 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 BF6153A15B9 for ; Tue, 16 Jun 2020 07:27:27 -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, FREEMAIL_FROM=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 bG5NsPsY7ATV for ; Tue, 16 Jun 2020 07:27:26 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 CF9193A15B8 for ; Tue, 16 Jun 2020 07:27:26 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id j1so9585782pfe.4 for ; Tue, 16 Jun 2020 07:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=+mcJxFvfPGwGfR1/7BeZxjOC3N8p1xxgQzqyTtqeoXs=; b=BRnVGYobPYpnia/mYw7ZN7VUijMgqPEOb3zRGxcWoYkVZGJddmsVbIZ8o0kI1LtJ6S HO2wnasEKR32PP/lXTZB136s3Q0QQneit0cBCHwxwhoTSbtgBnBupL1XKvvADYivM7Fc 9M23uIaUdB/m281FH18i0nXFMyABvpud1Ly1T4SKDV+3tDqSKYGvAI3hYW3M2Hsk4kzv pzh6wTvU2NyNWE/aK+K9zYZhcGnqylilhvG7F0Uiy5Y+6YjkWytb/aL4g3EQ2FBEM6eX ICilhxTKrg2uDR3SZolFwNruFZ6f4GEw+sIEffb/5aLYGp4SdCtKywBY8w16vp9YTpGr yVcw== 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 :subject:date:message-id:references:cc:in-reply-to:to; bh=+mcJxFvfPGwGfR1/7BeZxjOC3N8p1xxgQzqyTtqeoXs=; b=LcRdoBix2noNlgTjgqneQeHNwArf14r5iCkXbZxwuA7C2hHFmlxX9YguO0+CmYjCRQ fStwGsspMqlPZGi/CaV0toZDy4ZU/Gz2gRszkccsnxGadgy1WABjmDdbN1Tk75DRuhLT BXMFEhuvHsREPYAjeY+AHsz6bpznIBy0Ak55cKiSQqRBl1z3nmtolOOEno6XYPjZECR+ Quq8c4rAIu04FQoZisVC1UQNND6zGYYpTteeucKBRQVhQgAdCT9WmV5UluKUYOMUTKol faoPjBonuitYr8gFtNNpQARRvR5ChIQ0DQZXm2CjomgB5nK4R3MSuybBno8uSiU5ckaS 6dxQ== X-Gm-Message-State: AOAM531T4sgzlhFDEtPhymx5KlL4w3DaEmIiyls/F8uD4p/ViaAbClzA eg4RTbNFoXIHjWUHGb3/ORx7p0Kz02U= X-Google-Smtp-Source: ABdhPJyPjoxjgWxSThRTDiqk/HkOpW8+0jBJIYCEqn4SyqoF16vVf6XCwUvpSPzeu0DFveeIeoQs8g== X-Received: by 2002:a63:3814:: with SMTP id f20mr2277127pga.266.1592317645648; Tue, 16 Jun 2020 07:27:25 -0700 (PDT) Received: from [192.168.1.103] (c-71-227-236-207.hsd1.wa.comcast.net. [71.227.236.207]) by smtp.gmail.com with ESMTPSA id u61sm2953864pjb.7.2020.06.16.07.27.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Jun 2020 07:27:24 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Bernard Aboba Mime-Version: 1.0 (1.0) Date: Tue, 16 Jun 2020 07:27:23 -0700 Message-Id: <355B2449-D396-4528-896B-CA2ED630ED35@gmail.com> References: Cc: Sergio Garcia Murillo , DISPATCH list In-Reply-To: To: Eric Rescorla X-Mailer: iPhone Mail (17F80) Archived-At: Subject: Re: [dispatch] [Sframe] Dispatch of SFrame 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, 16 Jun 2020 14:27:28 -0000 On Jun 16, 2020, at 6:53 AM, Eric Rescorla wrote: >=20 > Yes, I understand that the wire encoding supports signatures, but in the d= iscussions I've had (including with Emac) I don't think that people believe t= hat the latency/bandwidth/computation tradeoff is viable. [BA] Depends on the scenario. We are in a pandemic where conferences are be= ing used for all kinds of things that we haven=E2=80=99t seen before. For ex= ample, consider a situation in which participants are answering a binding po= ll and the responses (voice or data) need to be authenticated. SFrame can ha= ndle that. PERC cannot.= From nobody Tue Jun 16 07:36:00 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 538A33A163A for ; Tue, 16 Jun 2020 07:35:59 -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 IYm290zNCDKS for ; Tue, 16 Jun 2020 07:35:58 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 04C353A16C0 for ; Tue, 16 Jun 2020 07:35:08 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id l17so3122820wmj.0 for ; Tue, 16 Jun 2020 07:35:08 -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=9dOau02OZWjIwl+IO35+U2Dz7mFHwPwcSdIJ9Gby4WQ=; b=EnHjb/Fxb1079IevF6Y9avdVvjF+yZoA5xhueCnZuJSM/S2bSFfYzkoBdMGwffhUBd 8ycpUDYZ7OMZdgoTdC4/VD/QyCDW0IvYsXQ+dTldlaU39XVHJa74LlpiideZWGocOstk RtN4RQbI+IhtyYrqm2z9cyUDxgXMTpfzmEYu5CPmganYkXF/uUkb2PvT3Od1o6hCwdDl mWwbVRYPXDHqRebCmR8bucBIhQZo0HpOrQqVkWcFg+qHKtLQ8qbsfJTKotqekMKetW0O 6U0KxCuNNpAE4mGLfB6Y/iULnrW8y4/z1wuM2xpLAn/FxB7/aMJoMN7pAe+OnpuYxaoZ o5ww== 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=9dOau02OZWjIwl+IO35+U2Dz7mFHwPwcSdIJ9Gby4WQ=; b=oWDqoz07VIyAGEynab43oUXGVw1mthvt+thYBDYshGvRODvxix+KeBr0u/+Px0HsLj Q7tWluNqrdRfxzckPxyaGJzHoIC99mQsVz5rnarzHLW3Hh8k5h4+562UIDm/RAMqViri uwOhRoqj4HfDhedLZra9OvCOLgGvgjwXDMj0IwFatkU7NJZcKmNNip8MVtZUWXy4AYio 8Psjr2YnBxahiB8pbUi8IzvMIzGe065VwfUyPxcfOTqCoiPpeZPufO/X0EKM3uxuNoaf 53Kel+1B1Ki3YXZshqHka+Hzf3BtipXfqdPNWbTgiX8CzFjsFZvx9EkYL2nbaJCWknU6 gZjQ== X-Gm-Message-State: AOAM530FM1v42FAqEMK39ZWcPE0a56P7QMc/DmMG06cgYVQLnO3olP08 amno6PIaq1UO9wiaZPdnDiiX6uEz7Kc9PriHlF4= X-Google-Smtp-Source: ABdhPJyu4Kec5oX0uAsAFf6L1+Wy34AYQqYdi3lHA5BBkooon/zeqkZ8tPSfpvF8ALaNQvFH8PNqHciau3I2tdlLrRM= X-Received: by 2002:a1c:2082:: with SMTP id g124mr3689170wmg.21.1592318107391; Tue, 16 Jun 2020 07:35:07 -0700 (PDT) MIME-Version: 1.0 References: <355B2449-D396-4528-896B-CA2ED630ED35@gmail.com> In-Reply-To: <355B2449-D396-4528-896B-CA2ED630ED35@gmail.com> From: Sergio Garcia Murillo Date: Tue, 16 Jun 2020 16:34:56 +0200 Message-ID: To: Bernard Aboba Cc: Eric Rescorla , DISPATCH list Content-Type: multipart/alternative; boundary="000000000000291e9f05a83473bd" Archived-At: Subject: Re: [dispatch] [Sframe] Dispatch of SFrame 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, 16 Jun 2020 14:35:59 -0000 --000000000000291e9f05a83473bd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable El mar., 16 jun. 2020 16:27, Bernard Aboba escribi=C3=B3: > On Jun 16, 2020, at 6:53 AM, Eric Rescorla wrote: > > > > Yes, I understand that the wire encoding supports signatures, but in th= e > discussions I've had (including with Emac) I don't think that people > believe that the latency/bandwidth/computation tradeoff is viable. > > [BA] Depends on the scenario. We are in a pandemic where conferences are > being used for all kinds of things that we haven=E2=80=99t seen before. F= or > example, consider a situation in which participants are answering a bindi= ng > poll and the responses (voice or data) need to be authenticated. SFrame c= an > handle that. PERC cannot. The good thing is, as I said before, I have already implemented it in my js lib. I will add some stats and run some tests with different policies and provide feedback about added overhead and encryption times. Anyway, as Bernard says, it is a trade off, and some people may be willing to pay for it based on their use case. Best regards Sergio --000000000000291e9f05a83473bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


El mar., 16 jun. 2020 16:27, Bernard Aboba <bernard.aboba@gmail.com> escribi= =C3=B3:
On Jun 16, 2020, at 6:53 AM= , Eric Rescorla <ekr@rtfm.com> wrote:
>
> Yes, I understand that the wire encoding supports signatures, but in t= he discussions I've had (including with Emac) I don't think that pe= ople believe that the latency/bandwidth/computation tradeoff is viable.

[BA] Depends on the scenario.=C2=A0 We are in a pandemic where conferences = are being used for all kinds of things that we haven=E2=80=99t seen before.= For example, consider a situation in which participants are answering a bi= nding poll and the responses (voice or data) need to be authenticated. SFra= me can handle that. PERC cannot.
=
The good thing is, as I said before, I have alr= eady implemented it in my js lib. I will add some stats and run some tests = with different policies and provide feedback about added overhead and encry= ption times.

Anyway, as = Bernard says, it is a trade off, and some people may be willing to pay for = it based on their use case.

Best regards
Sergio

<= /div>

--000000000000291e9f05a83473bd-- From nobody Tue Jun 16 07:53:08 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 530013A162E for ; Tue, 16 Jun 2020 07:53:07 -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=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRRGTAOBSIrv for ; Tue, 16 Jun 2020 07:53:06 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 D08803A1625 for ; Tue, 16 Jun 2020 07:53:05 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id w15so11901253lfe.11 for ; Tue, 16 Jun 2020 07:53:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y/8c4eC6Cvpk+tAyqMWRca8WAyD2Hce1KdRO+3W1QOI=; b=M9ulJLrLk44jsLLmaSnIy25+RPID3vMPW8kTYGDP2OA6/MpMRVuymVPbqSRLHpvki8 4wP9qCb7Z1s95yVdFhw4XQYPnUnSf5R0OajyvjHt1uglpr2LgUpfF/kCrbOg6e5IroQw YMPSp91RCswjEhN05WDY/G70FoTbUIh+q7q8rr8XDyr9RM2cVEYWW/gQ94DqsSbrFG4m Dq3K/Ohg6qzuproF4DBTUsr/UCU62Fv41G20MIoyiV6hVblCv/U6KnOLd/YRflPDrpCe uEUKTiF1kSu2g3XqMCdgo+qArbcEkxOSdffyhqL7KACBy7j+jgIVaKToJmojHXDQFlm5 oSFQ== 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=y/8c4eC6Cvpk+tAyqMWRca8WAyD2Hce1KdRO+3W1QOI=; b=mk8S1CtH4sffq0DWEj+H/vnJNJLyLRQy0qlVkq0vUr4VhAvKQoccOapS1WUnTBUX0m 2VurIr88XcGLej+xadiyEnk0b3sjm8LfLcXMN5fHLGpnPEkyX3VnILttZmog+cqLYPLF CtLiJ7tzdn15hqje1eAm6sCfo8t4gSdA1goVOtTqob3EEiq6x1dIYeHZS32u7wn76gL1 pRIfGujPZEWvG+3hlE1GAxGQvOlFH8pqxwBrN5e4nFphNPT2Bz1r6vN0n3wyV/05cawW yo4fOHj2gCZTC8aW76wY4GD/7kXpa1xyTEE9xNPxklwJMdV7Gi9bKMa1XZ6BFTIhCGjC t2SQ== X-Gm-Message-State: AOAM533DmohBQhLYw87edArl09UaEEdTMwtRabBtiE6avD+t8ZyvP8xx AB5bBPcxTw6ID7bAhBeiWICinf171pnIiLMXIflc1g== X-Google-Smtp-Source: ABdhPJxd5qAGBFHbsDVxt9XswD/vzDJiSbiivn2tnGw2crmg0WkyDDvRXRbrX0JsznCabtfOXuoMcFbrSp9u1HouWDM= X-Received: by 2002:a19:7714:: with SMTP id s20mr1940141lfc.161.1592319184005; Tue, 16 Jun 2020 07:53:04 -0700 (PDT) MIME-Version: 1.0 References: <355B2449-D396-4528-896B-CA2ED630ED35@gmail.com> In-Reply-To: <355B2449-D396-4528-896B-CA2ED630ED35@gmail.com> From: Eric Rescorla Date: Tue, 16 Jun 2020 07:52:27 -0700 Message-ID: To: Bernard Aboba Cc: Sergio Garcia Murillo , DISPATCH list Content-Type: multipart/alternative; boundary="00000000000055004705a834b319" Archived-At: Subject: Re: [dispatch] [Sframe] Dispatch of SFrame 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, 16 Jun 2020 14:53:07 -0000 --00000000000055004705a834b319 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 16, 2020 at 7:27 AM Bernard Aboba wrote: > On Jun 16, 2020, at 6:53 AM, Eric Rescorla wrote: > > > > Yes, I understand that the wire encoding supports signatures, but in th= e > discussions I've had (including with Emac) I don't think that people > believe that the latency/bandwidth/computation tradeoff is viable. > > [BA] Depends on the scenario. We are in a pandemic where conferences are > being used for all kinds of things that we haven=E2=80=99t seen before. F= or > example, consider a situation in which participants are answering a bindi= ng > poll and the responses (voice or data) need to be authenticated. SFrame c= an > handle that. PERC cannot. I don't really think framing this as "PERC vs. SFrame" is that helpful, but there's no in principle reason PERC couldn't have signatures, though of course one would need to define new algorithms. -Ekr --00000000000055004705a834b319 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jun 16, 2020 at 7:27 AM Berna= rd Aboba <bernard.aboba@gmail= .com> wrote:
On Jun 16, 2020, at 6:53 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> Yes, I understand that the wire encoding supports signatures, but in t= he discussions I've had (including with Emac) I don't think that pe= ople believe that the latency/bandwidth/computation tradeoff is viable.

[BA] Depends on the scenario.=C2=A0 We are in a pandemic where conferences = are being used for all kinds of things that we haven=E2=80=99t seen before.= For example, consider a situation in which participants are answering a bi= nding poll and the responses (voice or data) need to be authenticated. SFra= me can handle that. PERC cannot.

I do= n't really think framing this as "PERC vs. SFrame" is that he= lpful, but there's no in principle reason PERC couldn't have signat= ures, though of course one would need to define new algorithms.
<= br>
-Ekr

--00000000000055004705a834b319-- From nobody Tue Jun 16 19:11: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 B3EBD3A0D98 for ; Tue, 16 Jun 2020 19:11:16 -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_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=lowentropy.net header.b=E1iriWx7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nRb8mn8b 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 WDER_b0mRAan for ; Tue, 16 Jun 2020 19:11:15 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 421543A0D97 for ; Tue, 16 Jun 2020 19:11:15 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 76EF67B1 for ; Tue, 16 Jun 2020 22:11:14 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Tue, 16 Jun 2020 22:11:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=090fGtDlexoiOO2o35E5K8enWf7lxny +Mc8abWTg3mM=; b=E1iriWx7PX7nKTSZtTOMb1CejMH/I4C9mTnvmtXRx6YOsfK aJ7ez3SM5pXIZ5cGQs3lAbl1+iUNOUyu4pPSL+0rSxcnz69HEBchIlElDgZm9bf4 WVotc/vQNpj/mhYAtPxjEnpOwaOGje+6Rd5ykbLzSnhkmXBnoNp478bBTPkxFeyc H3LRGg04hCQxe4BonY9xs6CLqCHY/dOjkr3RPBHGea9NgTx5wG0EZ6UccgtrKhkp 5cYencnz4cjFXGkFO8sq5AhQNeN+KNlqW+LtpNZM9hkDOZpnC9WTnrEC0l3mMVGn AUWQ/U7FO4a/KxPby+3v6wVV0UZsgfNGRpfPsrw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=090fGt DlexoiOO2o35E5K8enWf7lxny+Mc8abWTg3mM=; b=nRb8mn8bcjSp/R/WhgxKbH 8lK8TStS/veegrZaVS7wZjl3T07ZuBTiiAPPPMAwL4hhDKmYRgK3FMVOdaYL/jGF +WMJOxafjXbVedC+pWxpPO0jW0d9PucRdfb/9JAheDlsML+etDP9vuiGQnKXIV5q 2yspE2PWYg4SgBvnrUFeHO/6t0r92st9YARqfWlHDcz6TUoTltMZT+JfSzi2jQBD OEdHVZ0p+erz9JjIDzHfRGAP+FBsvzUp08Zh4VwmX3Gb8W8vN/N0tJc3ZTyhtyUg mxW1D3K+3BHVMfnBuJoUsstpnQSTAhKecefW42dDQYA8xcotASB0TCWdbwp6522Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudejuddgheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B5C55E00D2; Tue, 16 Jun 2020 22:11:13 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-529-g3ee424a-fm-20200611.001-g3ee424a1 Mime-Version: 1.0 Message-Id: <3e0d6d89-1a4b-4988-812a-c1fbb3c6e1a0@www.fastmail.com> In-Reply-To: References: Date: Wed, 17 Jun 2020 12:10:54 +1000 From: "Martin Thomson" To: dispatch@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [dispatch] [Sframe] Dispatch of SFrame 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, 17 Jun 2020 02:11:17 -0000 On Tue, Jun 16, 2020, at 14:48, Bernard Aboba wrote: > [BA] Compared with PERC, SFrame is more efficient and transport > agnostic, more compatible with existing codec-independent SFUs, and > more flexible in terms of the scenarios it can potentially support. I think that a more relevant comparison point would be between giving someone an COSE (analogous to SFrame) vs. TLS (analogous to PERC). Sure, COSE has the ability to do more than an AEAD, but it also does far less. I'm not really sure why people feel the need to dump on PERC. It's fairly clear that it hasn't been successful, but that's just what happens with these things sometimes. I see SFrame as an attempt to approach this problem more incrementally. That's fine. Maybe this effort will result in adoption, which is what I care about. While I might be less than thrilled with yet another cryptographic protection scheme, especially one with a custom AEAD and 32-bit authentication tags, those are details that a working group - in the security area - seems pretty well equipped to handle. From nobody Tue Jun 16 19:25:33 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 61C303A0DAD for ; Tue, 16 Jun 2020 19:25:32 -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=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 UVDFYuQOzG4s for ; Tue, 16 Jun 2020 19:25:31 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A83D73A0DAB for ; Tue, 16 Jun 2020 19:25:30 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id 9so923297ljc.8 for ; Tue, 16 Jun 2020 19:25:30 -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=FpEgH1KdVEUzaT7Hi2H9ahSPHNlWHQckYRKSl3HF9iI=; b=hRWVi7XdsSMZHjWRqe3DrmMpjwhKA3aUiZ0fB6sdJ7DcLnPaRSKghssesm4LprpKCJ 7d2zwVXrhuvS2RGpy3nfOSTBxiftP7T9VjIQ2n8zzTGkUzs/c/ip8Ua2iYSH07ftTdPx 9uIl598IdIF43ENtGelmH4dODrv4wg5IlDZVZ+8JhDXXqaEd+9kAuI5BbhFqu7qjpuB1 wzdYgb2O/ONCr/hb0wz/q3iO/5UxRhEX1YIf3LtU/lAELHNoAfCx9l34ILEkMh7p1Ffs IkZTc+L+Skz1/ZnSIFZWdRxEBgUMWv1dfWLw6PIOOQkTHp00vZ3a/FVLLqv3DWpegtIh XYMg== 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=FpEgH1KdVEUzaT7Hi2H9ahSPHNlWHQckYRKSl3HF9iI=; b=NXyoABzlaf3ph0sDpUsWHe8HMuO2WJ5TYs8cix9iuBddYhvYqfgi+e+CN8IrwWgeap ZnChlfprkqE5QrM/IRHeaJlX/2FnsNaJ+UKCynDWkR9MX9ux9zEerY9WHfG6xb/P2zIr Q9piqAtl6CePA2+23j/LWHiHymNWLAW+M3i/Q//dIM5JOE4zBI5b4VcATEcnZ1D0RC6d DYBCtDKC3Kgr7YaXZWJhrSJOYvjM/fcaxQFbyYgZxIG+dh6Ub7w6SVL+OENgtxhIGak4 pPwulzjdBUYyXCsUJ9pPDT0M1gJ2mEfcE0jEWRDVKTEUmqovliqdeO+aLFtTZ9JXVffC 7ODg== X-Gm-Message-State: AOAM530FVGGwGVjPARsfrtWE0S1un4xJfiElT0sa0uW4J5nZO2/0ty8y HzcrTcimeQcACma3eK63iNdzfF9k+gZHfvEVNHadpw== X-Google-Smtp-Source: ABdhPJzuPiQUKYF5j0pHBw/Co5qN04Gz0ZSi+91kUy6cZwxwYWYhq515rbWlbjvuPPgoa2FLcHer1bd6AesSLbsmtc8= X-Received: by 2002:a2e:b818:: with SMTP id u24mr2571692ljo.94.1592360728627; Tue, 16 Jun 2020 19:25:28 -0700 (PDT) MIME-Version: 1.0 References: <355B2449-D396-4528-896B-CA2ED630ED35@gmail.com> In-Reply-To: From: Victor Vasiliev Date: Tue, 16 Jun 2020 22:25:17 -0400 Message-ID: To: Eric Rescorla Cc: Bernard Aboba , DISPATCH list Content-Type: multipart/alternative; boundary="00000000000096067905a83e5f7a" Archived-At: Subject: Re: [dispatch] [Sframe] Dispatch of SFrame 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, 17 Jun 2020 02:25:32 -0000 --00000000000096067905a83e5f7a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I imagine that for high-bitrate traffic, the difference between encrypting every packet and encrypting an entire frame at once is substantial enough to make using asymmetric crypto feasible in practice. On Tue, Jun 16, 2020 at 10:53 AM Eric Rescorla wrote: > > > On Tue, Jun 16, 2020 at 7:27 AM Bernard Aboba > wrote: > >> On Jun 16, 2020, at 6:53 AM, Eric Rescorla wrote: >> > >> > Yes, I understand that the wire encoding supports signatures, but in >> the discussions I've had (including with Emac) I don't think that people >> believe that the latency/bandwidth/computation tradeoff is viable. >> >> [BA] Depends on the scenario. We are in a pandemic where conferences ar= e >> being used for all kinds of things that we haven=E2=80=99t seen before. = For >> example, consider a situation in which participants are answering a bind= ing >> poll and the responses (voice or data) need to be authenticated. SFrame = can >> handle that. PERC cannot. > > > I don't really think framing this as "PERC vs. SFrame" is that helpful, > but there's no in principle reason PERC couldn't have signatures, though = of > course one would need to define new algorithms. > > -Ekr > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --00000000000096067905a83e5f7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I imagine that for high-bitrate traffic, the difference be= tween encrypting every packet and encrypting an entire frame at once is sub= stantial enough to make using asymmetric crypto feasible in practice.
=
On Tue= , Jun 16, 2020 at 10:53 AM Eric Rescorla <ekr@rtfm.com> wrote:


On Tue, Jun 16, 2020 at= 7:27 AM Bernard Aboba <bernard.aboba@gmail..com> wrote:
On Jun 16, 2020, at 6:53 AM, Eric Resc= orla <ekr@rtfm.com= > wrote:
>
> Yes, I understand that the wire encoding supports signatures, but in t= he discussions I've had (including with Emac) I don't think that pe= ople believe that the latency/bandwidth/computation tradeoff is viable.

[BA] Depends on the scenario.=C2=A0 We are in a pandemic where conferences = are being used for all kinds of things that we haven=E2=80=99t seen before.= For example, consider a situation in which participants are answering a bi= nding poll and the responses (voice or data) need to be authenticated. SFra= me can handle that. PERC cannot.

I do= n't really think framing this as "PERC vs. SFrame" is that he= lpful, but there's no in principle reason PERC couldn't have signat= ures, though of course one would need to define new algorithms.
<= br>
-Ekr

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--00000000000096067905a83e5f7a-- From nobody Tue Jun 16 20:44: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 B23D33A0E1A for ; Tue, 16 Jun 2020 20:44:41 -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 LD20DXKTGSsV for ; Tue, 16 Jun 2020 20:44:40 -0700 (PDT) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 2C1903A0E1D for ; Tue, 16 Jun 2020 20:44:40 -0700 (PDT) Received: by mail-pj1-x102f.google.com with SMTP id m2so388179pjv.2 for ; Tue, 16 Jun 2020 20:44:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=t1nt5ThDIpq1r6aHWcBgHfHHL3CtHJ3D7lizEj+MMSk=; b=VN+Xyywi0fy5q1GNIGbuyjbm16yV7TnYv1kOGqNLjW4qdH2S+SsixjQz4mtCyLLZ4z 8K1T3Jd+RIeIYaf0+J1dqXn8iP8wsCoKqwiN6EZyopfQTj6Moaibkiy+9J0YDLjDCPGC aVMt2wPri3Xx+f9mBcpM+vrpkzUilLpXPliobV4RgEgLQNinRvOOL5JD5MQ7vY1HDEiQ 9MRt4TDg9rANCPs6vqy1Zd5aI8zkEKSdm3CLKlsAThSqV+h4V3dSdlq1++10yxvqTW3g LgkRE1stjpZMzR1M/8am5aXHP9+r1NUygrLRRd8b3CHFvmvJcQyXAhJOXhXL+Ko547mQ KZJg== 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 :subject:date:message-id:references:cc:in-reply-to:to; bh=t1nt5ThDIpq1r6aHWcBgHfHHL3CtHJ3D7lizEj+MMSk=; b=Lt/svOTzuuI34wQxFRsmLPFYhCge+/0iLH4LYV3bC9zJkQXpN4rIGryKJVKjL8Sp5i C1nIBZLBN97gjpwgioZDK0WbjmGPhiWv+1RmyhmatH392C3qoH8Yt7foMITWUeap/xVH UjWDZmI8uor9IbEAisH58q/piJPLjMVPYrGOvnZxLP5UmLtzoYZxmMZ9e2s8UZdgYU45 1fq4ez/f8NShA5MbdwrU9sd6vANc9Dxt2nvNDUl1xH6OAWw58oQ9Zp7V3SEi66bFHNfi uN7+x5oPhtnGu76uF4vGPBLxCQzn1zoUPP4X5NdAvNu3MXQvqDDAxo+geiAlwOLWb0bw 16nQ== X-Gm-Message-State: AOAM530Z0w738hujpNKJzHfWJLmbjLle7emcFULM+mCsrPzw9bzJHFDi EHzDc2o6rACsK9y7VdZkefI= X-Google-Smtp-Source: ABdhPJzCCRiYXJFGwAG8S48wZ4kfTEMegtTZZC1xUEMDeX6cbPJFf0f0oi8Jr6AQch3EwOjnVQZN8Q== X-Received: by 2002:a17:902:8304:: with SMTP id bd4mr4811099plb.8.1592365479351; Tue, 16 Jun 2020 20:44:39 -0700 (PDT) Received: from [192.168.1.197] (c-71-227-236-207.hsd1.wa.comcast.net. [71.227.236.207]) by smtp.gmail.com with ESMTPSA id j17sm12223385pgn.87.2020.06.16.20.44.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Jun 2020 20:44:38 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-45A5C78A-A27B-4E31-88E1-2ACEC2DA628A Content-Transfer-Encoding: 7bit From: Bernard Aboba Mime-Version: 1.0 (1.0) Date: Tue, 16 Jun 2020 20:44:37 -0700 Message-Id: <8ACE39EA-BC17-4E8A-8D5C-1FF1247171C3@gmail.com> References: Cc: Eric Rescorla , DISPATCH list In-Reply-To: To: Victor Vasiliev X-Mailer: iPad Mail (17F80) Archived-At: Subject: Re: [dispatch] [Sframe] Dispatch of SFrame 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, 17 Jun 2020 03:44:42 -0000 --Apple-Mail-45A5C78A-A27B-4E31-88E1-2ACEC2DA628A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable For a key frame, SFrame can reduce the overhead of non-repudiation by two or= ders of magnitude.=20 > On Jun 16, 2020, at 19:25, Victor Vasiliev wrote: >=20 > I imagine that for high-bitrate traffic, the difference between encrypting= every packet and encrypting an entire frame at once is substantial enough t= o make using asymmetric crypto feasible in practice. >=20 >> On Tue, Jun 16, 2020 at 10:53 AM Eric Rescorla wrote: >>=20 >>=20 >>> On Tue, Jun 16, 2020 at 7:27 AM Bernard Aboba = wrote: >>> On Jun 16, 2020, at 6:53 AM, Eric Rescorla wrote: >>> >=20 >>> > Yes, I understand that the wire encoding supports signatures, but in t= he discussions I've had (including with Emac) I don't think that people beli= eve that the latency/bandwidth/computation tradeoff is viable. >>>=20 >>> [BA] Depends on the scenario. We are in a pandemic where conferences ar= e being used for all kinds of things that we haven=E2=80=99t seen before. Fo= r example, consider a situation in which participants are answering a bindin= g poll and the responses (voice or data) need to be authenticated. SFrame ca= n handle that. PERC cannot. >>=20 >> I don't really think framing this as "PERC vs. SFrame" is that helpful, b= ut there's no in principle reason PERC couldn't have signatures, though of c= ourse one would need to define new algorithms. >>=20 >> -Ekr >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail-45A5C78A-A27B-4E31-88E1-2ACEC2DA628A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
For a key frame, SFrame ca= n reduce the overhead of non-repudiation by two orders of magnitude. 

On Jun 16, 2020, at 19:25= , Victor Vasiliev <vasilvv@google.com> wrote:

I imagine that= for high-bitrate traffic, the difference between encrypting every packet an= d encrypting an entire frame at once is substantial enough to make using asy= mmetric crypto feasible in practice.

On Tue, Jun 16, 2020 at 10:53 AM Eric Res= corla <ekr@rtfm.com> wrote:


On Tue, Jun 16, 2020 at 7:27 AM Bernard Aboba <bernard.aboba@gmail..com= > wrote:
On Jun= 16, 2020, at 6:53 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> Yes, I understand that the wire encoding supports signatures, but in th= e discussions I've had (including with Emac) I don't think that people belie= ve that the latency/bandwidth/computation tradeoff is viable.

[BA] Depends on the scenario.  We are in a pandemic where conferences a= re being used for all kinds of things that we haven=E2=80=99t seen before. Fo= r example, consider a situation in which participants are answering a bindin= g poll and the responses (voice or data) need to be authenticated. SFrame ca= n handle that. PERC cannot.

I don't re= ally think framing this as "PERC vs. SFrame" is that helpful, but there's no= in principle reason PERC couldn't have signatures, though of course one wou= ld need to define new algorithms.

-Ekr
_______________________________________________
dispatch mailing list
dispatch@ietf.org=
https://www.ietf.org/mailman/listinfo/dispatch
= --Apple-Mail-45A5C78A-A27B-4E31-88E1-2ACEC2DA628A-- From nobody Wed Jun 17 06:20:44 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 95FB23A0063 for ; Wed, 17 Jun 2020 06:20:31 -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=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aB4q894sBrg0 for ; Wed, 17 Jun 2020 06:20:29 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 2466B3A077D for ; Wed, 17 Jun 2020 06:20:29 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id t74so1292253lff.2 for ; Wed, 17 Jun 2020 06:20:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e310yIn66AhApc2VGX2pFSpmG6R3vmL2+8lmaisRc2c=; b=eqPD6d3gundWP7qPWQdrFBYY3UrFFhMnaJ53/w3Zxu6KMYrSXgYO2295M4068sP2xa 208WCYmO/T19Qby5B2hZ9jZTlbPORKxm9dDUHBa2kJe1sRK9/ih8GsGTyohCjuo1iRVG Sl/v/mH+DXmBAQx3bKbLZ1iFPez/m8/9j486hV1MeOYFle6pBSo39sMPaQG46BAEVRmy vy++67392krqQCoSIkhi7z7r5xKHiEUwWE2Hh06FRW4g1KMz5v/oy87BPLS78M5p0UQv EX34SDuxntF/dmvSVPrPzHacNafDqbDypaD/jUWoXMsHpoJDrtkeYWrwNA53y2YSY88q 6lZg== 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=e310yIn66AhApc2VGX2pFSpmG6R3vmL2+8lmaisRc2c=; b=R9jefU0W0IKozXFrF5n1fXQjFnXnItg6TnAySN8l63RTUimhjggxyi/Ju+qDn+AdfY PTIJyc+VKP4QppB7t4FuaQ32Uk9TdR6MiBxLNqzUnqT3/4TjI74m3PRKU9ZMYl0mScmw GD5oUunxAEht0GMOMVhrGA/dA32/9ZC4GAwfHC7ar2DG1+gnmCLXTBxJCWuqe5hhShCR VB0cHhTnsccD82I4hXUnz664wS0VOkdXf1wAv2qPFsrGr1aDfZJvjfZwglo8MwfD2qCQ 4A7d9AjjM2zckqTM32F6Y37jXOudwLecYJ2IEMwdDeEEOs38gE5Zy0mN9UTqBhDjnCAt 8/Fw== X-Gm-Message-State: AOAM530hwug8uAHEmLKw2zARBujXSzTuYDfOqFpFG6/5DjMA+mFHWCFA qy9Vjz2iXz2TgmxIT2n4c6By4bktr2+80jpNwbZ2vw== X-Google-Smtp-Source: ABdhPJwPRk02aXE56zY5cmQX0R93dZWpFMwA4WPPisXYF7t5m6OXFb5jxIEYnuoKl8b+ZLQllYiL7pbw0JB0sDUgCE8= X-Received: by 2002:ac2:5197:: with SMTP id u23mr4627598lfi.109.1592400027297; Wed, 17 Jun 2020 06:20:27 -0700 (PDT) MIME-Version: 1.0 References: <355B2449-D396-4528-896B-CA2ED630ED35@gmail.com> In-Reply-To: From: Eric Rescorla Date: Wed, 17 Jun 2020 06:19:50 -0700 Message-ID: To: Victor Vasiliev Cc: Bernard Aboba , DISPATCH list Content-Type: multipart/alternative; boundary="000000000000f7bdd805a84785c7" Archived-At: Subject: Re: [dispatch] [Sframe] Dispatch of SFrame 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, 17 Jun 2020 13:20:43 -0000 --000000000000f7bdd805a84785c7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 16, 2020 at 7:25 PM Victor Vasiliev wrote: > I imagine that for high-bitrate traffic, the difference between encryptin= g > every packet and encrypting an entire frame at once is substantial enough > to make using asymmetric crypto feasible in practice. > A few points: 1. The current SFrame draft does not in fact sign every frame. Rather it signs the past N frames ( https://tools.ietf.org/html/draft-omara-sframe-00#section-4.4) "Adding a digital signature to each encrypted frame will be an overkill, instead we propose adding signature over multiple frames." 2. This is maybe sorta true for video in which the frames are large (though see below) but remember that audio frames are small and have to have low latency. 3. For video, it's true that I-Frames are enormous but the bulk of the frames are P-Frames and those would generally be on the order of 1 packet, at which point you're not getting much improvement. IOW, it's complicated, but if you're not a fan of the "sign every packet" strategy, you probably are going to find that "sign every frame" doesn't work super well either. -Ekr > On Tue, Jun 16, 2020 at 10:53 AM Eric Rescorla wrote: > >> >> >> On Tue, Jun 16, 2020 at 7:27 AM Bernard Aboba > > wrote: >> >>> On Jun 16, 2020, at 6:53 AM, Eric Rescorla wrote: >>> > >>> > Yes, I understand that the wire encoding supports signatures, but in >>> the discussions I've had (including with Emac) I don't think that peopl= e >>> believe that the latency/bandwidth/computation tradeoff is viable. >>> >>> [BA] Depends on the scenario. We are in a pandemic where conferences >>> are being used for all kinds of things that we haven=E2=80=99t seen bef= ore. For >>> example, consider a situation in which participants are answering a bin= ding >>> poll and the responses (voice or data) need to be authenticated. SFrame= can >>> handle that. PERC cannot. >> >> >> I don't really think framing this as "PERC vs. SFrame" is that helpful, >> but there's no in principle reason PERC couldn't have signatures, though= of >> course one would need to define new algorithms. >> >> -Ekr >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > --000000000000f7bdd805a84785c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jun 16, 2020 at 7:25 PM Victo= r Vasiliev <vasi= lvv@google.com> wrote:
I imagine that for high-bitrate traffic, the= difference between encrypting every packet and encrypting an entire frame = at once is substantial enough to make using asymmetric crypto feasible in p= ractice.

A few points:

=
1. The current SFrame draft does not in fact sign every frame. R= ather it signs the past N frames (https://tools.ietf.org/h= tml/draft-omara-sframe-00#section-4.4) "Adding a digital signature= to each encrypted frame will be an overkill, instead we propose adding s= ignature over multiple frames."
2. This is maybe sorta true = for video in which the frames are large (though see below) but remember tha= t audio frames are small and have to have low latency.
3. For vid= eo, it's true that I-Frames are enormous but the bulk of the frames are= P-Frames and those would generally be on the order of 1 packet, at which p= oint you're not getting much improvement.

= IOW, it's complicated, but if you're not a fan of the "sign ev= ery packet" strategy, you probably are going to find that "sign e= very frame" doesn't work super well either.

-Ekr


On = Tue, Jun 16, 2020 at 10:53 AM Eric Rescorla <ekr@rtfm.com> wrote:


On= Tue, Jun 16, 2020 at 7:27 AM Bernard Aboba <bernard.aboba@gmail..com> wrote:
On Jun 16, 2020, = at 6:53 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> Yes, I understand that the wire encoding supports signatures, but in t= he discussions I've had (including with Emac) I don't think that pe= ople believe that the latency/bandwidth/computation tradeoff is viable.

[BA] Depends on the scenario.=C2=A0 We are in a pandemic where conferences = are being used for all kinds of things that we haven=E2=80=99t seen before.= For example, consider a situation in which participants are answering a bi= nding poll and the responses (voice or data) need to be authenticated. SFra= me can handle that. PERC cannot.

I do= n't really think framing this as "PERC vs. SFrame" is that he= lpful, but there's no in principle reason PERC couldn't have signat= ures, though of course one would need to define new algorithms.
<= br>
-Ekr

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--000000000000f7bdd805a84785c7-- From nobody Mon Jun 22 09:29: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 265953A0F1B for ; Mon, 22 Jun 2020 09:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.279 X-Spam-Level: X-Spam-Status: No, score=0.279 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yandex.ru 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 XvOc-gj1nu_t for ; Mon, 22 Jun 2020 09:29:45 -0700 (PDT) Received: from forward104j.mail.yandex.net (forward104j.mail.yandex.net [5.45.198.247]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C90953A0F0A for ; Mon, 22 Jun 2020 09:29:44 -0700 (PDT) Received: from mxback10g.mail.yandex.net (mxback10g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:171]) by forward104j.mail.yandex.net (Yandex) with ESMTP id DD5464A026C for ; Mon, 22 Jun 2020 19:29:42 +0300 (MSK) Received: from localhost (localhost [::1]) by mxback10g.mail.yandex.net (mxback/Yandex) with ESMTP id jJCC2tvE69-Tg0CSRFq; Mon, 22 Jun 2020 19:29:42 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1592843382; bh=rN5ZB0UleLR05b0uy0hmvpIZxhQ5BG3o5Kg51QHZXiM=; h=Message-Id:Date:Subject:To:From; b=mztOWLy/zicV+NFJB6xK4FvFXAmIU7w7OXhjlZ8jHCFYEQes/JumWBggzasjeVabO SxkMQD46CQJVIuj4NwRvpmo4CkkSE73YBAx3wUlQq+Z6TR+yb4/3OWKXwplhqLAtdH 0prSK4gI7WP37qlnrUHVQMY3nZ2sYHYdDrjm8SMw= Authentication-Results: mxback10g.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by iva4-64850291ca1c.qloud-c.yandex.net with HTTP; Mon, 22 Jun 2020 19:29:42 +0300 From: Anton Tveretin To: DISPATCH list MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Mon, 22 Jun 2020 21:29:42 +0500 Message-Id: <676431592769707@mail.yandex.ru> Content-Transfer-Encoding: 8bit Content-Type: text/html; charset=utf-8 Archived-At: Subject: [dispatch] It's weird 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, 22 Jun 2020 16:29:46 -0000
Hello,
Now we are striving to have several standards of overlapping applicability, namely for VoIP. At first, this looks like against the term "standard". Historically, however, that's fine; otherwise we would not have HTTP. More important for is that now IETF (and W3C) ignores all grassroots input. Consider HTML 6.0 as an example.
So, should we go to Internet 2.0 or whatever?
Sincerely yours.
 
From nobody Mon Jun 22 15:51: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 7658B3A1239 for ; Mon, 22 Jun 2020 15:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 eUwoLGsCdJZG for ; Mon, 22 Jun 2020 15:51:39 -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 E29063A1234 for ; Mon, 22 Jun 2020 15:51:39 -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 05MMpTfM012647 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 22 Jun 2020 17:51:30 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1592866291; bh=JktENNFSsSXDmKJAD3XCCa4YO513E4t5x6ckK6jl5pk=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=mDNyxvFuNzbWVkNpIJpOhcylSPOQt0f4UvH1048zlBfEzepPyoshgCKieyvnlkf+G WclI91dhdCXRQWs+fk+IHjr/bsIeQAycthazC3crCJH/4qAPya/XNJ8sTiw5YlVJHH l2mVVvSJ8+4n/+K/7I7yPazVEC+fFvS2Kx3RQjv4= 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 Message-Id: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B919AD65-501C-4CCB-81CE-B52559889995" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 22 Jun 2020 17:51:23 -0500 In-Reply-To: To: Dispatch WG References: X-Mailer: Apple Mail (2.3608.80.23.2.2) 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: Mon, 22 Jun 2020 22:51:42 -0000 --Apple-Mail=_B919AD65-501C-4CCB-81CE-B52559889995 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 = documents. 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 immediately 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.) Thanks! Ben (as co-chair) > On Jun 3, 2020, at 6:13 PM, Ted Hardie wrote: >=20 > Howdy, >=20 > This is one the shortest drafts I've ever written: = 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. =20 >=20 > This draft updates RFC 3405 to require "permanent" scheme = registrations. The salient bit is this: >=20 > All registrations in URI.ARPA MUST be for schemes which are permanent > registrations, as they are described in BCP 35. >=20 > I'm hoping for a quick dispatch of this, but happy to discuss. >=20 > regards, >=20 > Ted Hardie > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_B919AD65-501C-4CCB-81CE-B52559889995 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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 = documents. 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 immediately 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.)

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/ .   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

= --Apple-Mail=_B919AD65-501C-4CCB-81CE-B52559889995-- From nobody Tue Jun 23 07:12:16 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 E4EB63A0E19 for ; Tue, 23 Jun 2020 07:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 5jtGvQqXt9uQ for ; Tue, 23 Jun 2020 07:12:13 -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 513FD3A0E1F for ; Tue, 23 Jun 2020 07:12:13 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 05NECA5i004139 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 23 Jun 2020 09:12:11 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1592921532; bh=SXM7BdzDIPpHZ5KQ+8u7NjEu/jtPT1/GIuq4MveFejQ=; h=Subject:To:References:From:Date:In-Reply-To; b=R5hX1ejEUYteRf+F7MyS5F/rC92n/freUpvLo+bUIcj1w35p1THLAzwLO5i7LgPzP 6tUCkrcUePIbIhBgXFUA9rIiB+SfCuOdiNpROki5zUh5OrW1yTe/rNrXykJB5WVccr +9VapaI09/BstRKP3gMgIm0t/5kxeP4Aq0sdJHsA= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: dispatch@ietf.org References: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> From: Robert Sparks Message-ID: Date: Tue, 23 Jun 2020 09:12:10 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> Content-Type: multipart/alternative; boundary="------------1AE4A72983988DD438EF1DB6" Content-Language: en-US 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: Tue, 23 Jun 2020 14:12:15 -0000 This is a multi-part message in MIME format. --------------1AE4A72983988DD438EF1DB6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I can live with either path, but I still think allowing Dispatch to adopt work was a step onto the slippery slope mistake. On 6/22/20 5:51 PM, Ben Campbell wrote: > Hi Everyone, > > The ART ADs have reminded the chairs that our charter allows us to > adopt “simple administrative” work such as IANA registration > documents. This draft seems to fit squarely in that category. Does > anyone see a reason we shouldn’t just adopt it, with the 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 > group draft, or 4 weeks IETF LC for an AD sponsored draft.) > > Thanks! > > Ben (as co-chair) > >> On Jun 3, 2020, at 6:13 PM, Ted Hardie > > wrote: >> >> Howdy, >> >> This is one the shortest drafts I've ever written: >> 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 --------------1AE4A72983988DD438EF1DB6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I can live with either path, but I still think allowing Dispatch to adopt work was a step onto the slippery slope mistake.

On 6/22/20 5:51 PM, Ben Campbell wrote:
Hi Everyone,

The ART ADs have reminded the chairs that our charter allows us to adopt “simple administrative” work such as IANA registration documents. This draft seems to fit squarely in that category. Does anyone see a reason we shouldn’t just adopt it, with the 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 group draft, or 4 weeks IETF LC for an AD sponsored draft.)

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/ .   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
--------------1AE4A72983988DD438EF1DB6-- From nobody Tue Jun 23 09:30:11 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 1CB043A07E3 for ; Tue, 23 Jun 2020 09:30:10 -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 ipmMIBK1wvLj for ; Tue, 23 Jun 2020 09:30:08 -0700 (PDT) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 88D1E3A07E2 for ; Tue, 23 Jun 2020 09:30:08 -0700 (PDT) Received: by mail-pj1-x1031.google.com with SMTP id ne5so1682147pjb.5 for ; Tue, 23 Jun 2020 09:30:08 -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=A9+O/Ce/DkuvgAyVOjiWf4NWDZE4MkJbV11kGs+7mS4=; b=WZV/yAy3ER9kDePIEUTNpS3njPW4yiMGiBCb2g/XFOwPCeXt+x/4jPAt7wJBqILChW JuOBMrqfQOtpyhH7Hgg92X/bwA39bDbfqZKEN8782UWhJ0TsN9pB4HXi8nBzbRoGNn4Q 7KIJGnpmmNJiIIX3KfZeDHezaiBrRUjGLNfh8Ij1PqPfnZXRliRB2W17xwgWqAmxY3Ki QBrHkMYCypHBbGbrCxZOYCKNtqsXb6BJKO6DxVvP2UB4jPIrZvJqLpj+tKrzQoHfJyx7 aM8rj2Nr6hs3J+r6MBvBkfgNQnL+V/XSXnIy+Q98ofZRS2ZK96ogmfyiufeOBtFK7m9y WqKA== 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=A9+O/Ce/DkuvgAyVOjiWf4NWDZE4MkJbV11kGs+7mS4=; b=WChS3NjjVWqOB6EGKHlxlLOaWok9lgXMRzd/0cne8hzLJvSFABK9wjFgKEAqnR8G+w xAtERchqQDLR4RgAea+7XWP0ZjKwP40IFMkznA+R1azBvmuYSVHwgHF1NFc7LH5PtyJR 2nfCLKH8bhkhY4GZ2VeM6mTRKAADPiGVqwOzDGrYfVkV7vn5cxcQsCU7MDh+P0U8qbjs v41FQq22uagr6xAkMJAacK3XoKLJQOeCJykkCesXGmtdN8gyc4KWDq0nxNfBrShNEPCe b6Ov4VmC/4P2ZgRMq7ZwpRAGUGYsvoOUcLBvJpjQQIM56QQ8DtdVKjfhhTDa32y7JcIw b5vw== X-Gm-Message-State: AOAM530+NOhfEWnIm1/BPpQiFNKmdGgLoS/+bFormL/fx6TXbYwd7Rfy TtnuiefGIDargkuWvYUlEQ6hkUU3n0WkEuYfRp2YQA== X-Google-Smtp-Source: ABdhPJz07vQPwe2frqA4ykQpgRFIOaHF6Ay+Pic1uQ9Pvo1+bPk1OgtgBQwGBTjs4onA3uE4toCJVNYm9xdRTDF8VEo= X-Received: by 2002:a17:90a:e02:: with SMTP id v2mr24235178pje.90.1592929807077; Tue, 23 Jun 2020 09:30:07 -0700 (PDT) MIME-Version: 1.0 References: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> In-Reply-To: From: Mary Barnes Date: Tue, 23 Jun 2020 11:29:55 -0500 Message-ID: To: Robert Sparks Cc: DISPATCH Content-Type: multipart/alternative; boundary="0000000000004d9c2405a8c2dfe8" 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: Tue, 23 Jun 2020 16:30:10 -0000 --0000000000004d9c2405a8c2dfe8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I totally agree with Robert. On Tue, Jun 23, 2020 at 9:12 AM Robert Sparks wrote: > I can live with either path, but I still think allowing Dispatch to adopt > work was a step onto the slippery slope mistake. > On 6/22/20 5:51 PM, 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.) > > Thanks! > > Ben (as co-chair) > > On Jun 3, 2020, at 6:13 PM, Ted Hardie wrote: > > Howdy, > > This is one the shortest drafts I've ever written: > 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 listdispatch@ietf.orghttps://www.ietf.org/mailman/listin= fo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --0000000000004d9c2405a8c2dfe8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I totally agree with Robert.=C2=A0


=

On Tue, Jun 23, 2020 at 9:12 AM Robert Sparks <rjsparks@nostrum.com> wrote:
=20 =20 =20

I can live with either path, but I still think allowing Dispatch to adopt work was a step onto the slippery slope mistake.

On 6/22/20 5:51 PM, Ben Campbell wrote:
=20 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 documents. This draft seems to fit squarely in that category. Does anyone see a reason we shouldn=E2=80=99t just a= dopt it, with the 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 group draft, or 4 weeks IETF LC for an AD sponsored draft.)

Thanks!

Ben (as co-chair)

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

This is one the shortest drafts I've ever written:=C2=A0 https://datatra= cker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ .=C2=A0=C2=A0 Basically, RFC 3405 used to require that registrations in URI.ARPA be from the "IETF Tree&quo= t;.=C2=A0 That tree was deprecated after the document was published.=C2=A0 As it happens, there are very few registrations in URI.ARPA, so we did not catch it and fix it before now.=C2=A0

This draft updates RFC 3405 to require "permanent" scheme registrations.=C2=A0 The sal= ient bit is this:

All registrations in URI.ARPA MUST be for schemes wh=
ich 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
dispat= ch@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
--0000000000004d9c2405a8c2dfe8-- From nobody Fri Jun 26 01:18:01 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 36EE33A11E7; Fri, 26 Jun 2020 01:18:00 -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 oDSyfv5eM7IR; Fri, 26 Jun 2020 01:17:58 -0700 (PDT) Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (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 0D2E53A11E5; Fri, 26 Jun 2020 01:17:58 -0700 (PDT) Received: by mail-wm1-x344.google.com with SMTP id 22so7986239wmg.1; Fri, 26 Jun 2020 01:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-language:thread-index; bh=ejA36kwyyKDA5CQeNHVvIwfcfNCHK2A3qlZGlH62xuE=; b=rSbkZMN2q+6xCKLSAm5APx6fQvhwkvqcUyio578CjQbZM3MKJTpCzuwYHF4aLyIqhz qicuxD/Trfy9DD4f9U915Vg9UuKPJywuoI/CaqWAh8tr+0hsbWmlnLQ3Ut6lBOxjiQvK hMDqgXCwZ8fJkzf6AO4Ewcq6SLlYTbh4TNWbsenrwMNVabBux+ViboZcbMqQJ9Uu4Yg6 q7nGCMsEsxIWR3dLgZX7ZN108UyGWreJD4ix6/CkP8DVS5/g7j8KLfZ/8fwj49m4gwoI NoPxnyIeUPZA2H74V+hh6mAljL7BA9K9KL6f5A7vwhogpm1bj0LM7vaal3KAXj4TgJpV 7bUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-language:thread-index; bh=ejA36kwyyKDA5CQeNHVvIwfcfNCHK2A3qlZGlH62xuE=; b=Fqp/6ZwOM89ysxhH3K81gKdt25NQHLUOrQVXT55J1h2RTbaVrSX8v2FquQSEXrikTp JBIfnyoku+vQz0UJOqVG80mRqPt8qZHL9CQfQP2qNiQ3hF84ElYDS0pRyi6QvWzBAoah 4UiVfaETVG3/YWoqCfxXB491wCYUHIZcozF1Y1x/jNh/t/FqWL5TFcJUdMUOWVDLDCVO QM/0i5jc+hfANQC4ImgsAoK/IjHDwKr/pDDdyehm9IHYTLH4csSKAR5jlIF3O9eWwpEw 5upLHBOKf27HCfiqSED7FFvn7OUrLZ9lXIeyKzE4t99HqLt8uC/EBDGUEUibMfmqPx0N bBDw== X-Gm-Message-State: AOAM530sKRY57t2xAyH7Axp3qNU/FGnl/qYfR9uy7xN1j9nLk8VLWdQD Vv1AYCneoF6MNJHO2oB6QEoAZGbz X-Google-Smtp-Source: ABdhPJxm0Y3jGON/FnVmDe/GNXdK4/d4BN2hobAlspfTOrjIudjyQfkIzelEk2v527f+cJr3ZLoOqQ== X-Received: by 2002:a1c:7d54:: with SMTP id y81mr2206571wmc.110.1593159476459; Fri, 26 Jun 2020 01:17:56 -0700 (PDT) Received: from RoniPC (bzq-79-180-107-12.red.bezeqint.net. [79.180.107.12]) by smtp.gmail.com with ESMTPSA id h12sm15522218wmm.42.2020.06.26.01.17.54 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Fri, 26 Jun 2020 01:17:55 -0700 (PDT) From: "Roni Even" To: "'Patrick McManus'" , "'Emad Omara'" Cc: "'Ben Campbell'" , "'Dispatch WG'" , References: In-Reply-To: Date: Fri, 26 Jun 2020 11:17:51 +0300 Message-ID: <0e4d01d64b92$49cf5040$dd6df0c0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E4E_01D64BAB.6F1DC0C0" X-Mailer: Microsoft Outlook 14.0 Content-Language: he Thread-Index: AQH9xWGrhZcH8B5JF584hFypOrcytwNgTgg2AiD2rEYCDEUinwIlhVpuqE4AxRA= Archived-At: Subject: Re: [dispatch] Dispatch of SFrame for End-To-End Encrypted Conference Calls 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, 26 Jun 2020 08:18:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0E4E_01D64BAB.6F1DC0C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, =20 I find this proposal interesting since the issue of key distribution in = multipoint conferences is a problem even if the media mixer (any = topology) is a trusted entity and wants to distribute the encrypted = media without doing decrypt/encrypt cycle. One point to look at is that = in the past when we designed RFC5764 (DTLS/SRTP) the consensus was that = key exchange must be done in-band.=20 As far as I remember one of the motivation point for EKT in AVT was to = address the key distribution for multipoint conferences.=20 =20 As for the work, if there is a consensus to accept this work, it will = require support for RTP. How to signal that this is such a payload and = what should be the RTP PT in the RTP header. (how to negotiate what is = the secure payload inside the SFRAME) On one hand it may look like a new RTP payload (similar to MPEG2 RTP = payload (RFC2250)) and as such is in scope for AVTCore but as for the = framework I think this is not AVTCore work. =20 Roni Even AVTCore co-chair =20 =20 =20 From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Patrick = McManus Sent: Monday, June 15, 2020 10:06 PM To: Emad Omara Cc: Ben Campbell; Dispatch WG; sframe@ietf.org Subject: [dispatch] Dispatch of SFrame for End-To-End Encrypted = Conference Calls =20 Hi All - I failed to note the link highlighting in Emad's mail to the list which = already contained the draft. Sorry about that. (It's = https://tools.ietf.org/html/draft-omara-sframe-00 if you too missed it). There's also a github and mailing list referenced: https://github.com/eomara/sframe https://mailarchive.ietf.org/arch/browse/sframe/? =20 [I've also forked the Subject Line to help interested readers] =20 On Mon, Jun 15, 2020 at 2:42 PM Patrick McManus = wrote: Sounds really interesting Emad and there's obviously related work going = on (at least perc, maybe even mls..). =20 Sending that email Ben mentions to the dispatch list to raise awareness = with a link to the draft would be helpful in getting the process = started.. =20 On Mon, Jun 15, 2020 at 2:33 PM Emad Omara wrote: Hi Ben, =20 This draft proposes a solution for end-to-end encrypted conference = calls. We implemented this in Google a couple of years ago in Duo, but = the draft was only published last month given the current interest in = the topic. =20 The goal of the session is to go through the proposal and see if there = is interest to continue working on this, and if so what will be the best = WG to host this work.=20 =20 Thanks Emad =20 On Mon, Jun 15, 2020 at 11:02 AM Ben Campbell wrote: Hi Emad, =20 We prioritize DISPATCH meeting time to focus on topics that have had = DISPATCH list discussion and need high-bandwidth time to resolve. Unless = I=E2=80=99ve missed something, this topic has not previously come up in = DISPATCH. I suggest sending a note to this list with some background = about the draft and how you would like to see it progress. =20 Thanks! =20 Ben. On Jun 15, 2020, at 12:32 PM, Emad Omara = wrote: =20 Hi, =20 We would like to have a session in the next IETF to discuss the SFrame = draft Can you = please help scheduling this? =20 Thanks Emad _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch =20 ------=_NextPart_000_0E4E_01D64BAB.6F1DC0C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi,

 

I find this proposal interesting since the issue of key distribution = in multipoint conferences is a problem even if the media mixer (any = topology) is a trusted entity and wants to distribute the encrypted = media without doing decrypt/encrypt cycle.  One point to look at is = that in the past when we designed RFC5764 (DTLS/SRTP) the consensus was = that key exchange must be done in-band.

As far as I remember one of the motivation point for EKT in AVT was = to address the key distribution for multipoint conferences. =

 

As for the work, if there is a consensus to accept this work, it will = require support for RTP. How to signal that this is such a payload and = what should be the RTP PT in the RTP header. (how to negotiate what is = the secure payload inside the SFRAME)

On one hand it may look like a new RTP payload (similar to MPEG2 RTP = payload (RFC2250)) and as such is in scope for AVTCore but as for the = framework I think this is not AVTCore work.

 

Roni Even

AVTCore co-chair

 

 

 

From:= = dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Patrick = McManus
Sent: Monday, June 15, 2020 10:06 PM
To: = Emad Omara
Cc: Ben Campbell; Dispatch WG; = sframe@ietf.org
Subject: [dispatch] Dispatch of SFrame for = End-To-End Encrypted Conference = Calls

 

Hi = All -

I failed to note the link highlighting in Emad's mail to = the list which already contained the draft. Sorry about that. = (It's https://tools.= ietf.org/html/draft-omara-sframe-00 if you too missed = it).

There's also a github and mailing list referenced:
https://github.com/eomara/sfram= e
https://mailar= chive.ietf.org/arch/browse/sframe/?

 

[I've also forked the Subject Line to help interested = readers]

 

On = Mon, Jun 15, 2020 at 2:42 PM Patrick McManus <patrick.ducksong@gmail.com= > wrote:

Sounds really interesting Emad and there's obviously = related work going on (at least perc, maybe even = mls..).

 

Sending that email Ben mentions to the dispatch list = to raise awareness with a link to the draft would be helpful in getting = the process started..

 

On = Mon, Jun 15, 2020 at 2:33 PM Emad Omara <emadomara@google.com> = wrote:

Hi = Ben,

 

This draft proposes a solution for end-to-end = encrypted conference calls. We implemented this in Google a couple = of years ago in Duo, but the draft was only published last month given = the current interest in the topic.

 

The goal of the session is to go through the proposal = and see if there is interest to continue working on this, and if so what = will be the best WG to host this work. 

 

Thanks

Emad

 

On = Mon, Jun 15, 2020 at 11:02 AM Ben Campbell <ben@nostrum.com> = wrote:

Hi = Emad,

 

We prioritize DISPATCH meeting time to focus on topics = that have had DISPATCH list discussion and need high-bandwidth time to = resolve. Unless I=E2=80=99ve missed something, this topic has not = previously come up in DISPATCH. I suggest sending a note to this list = with some background about the draft and how you would like to see it = progress.

 

Thanks!

 

Ben.



On = Jun 15, 2020, at 12:32 PM, Emad Omara <emadomara=3D40google.com@dmarc.ietf.org> = wrote:

 

Hi,

 

We would like to have a session in the next IETF to = discuss the SFrame draft Can you please help scheduling = this?

 

Thanks

Emad

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

 

------=_NextPart_000_0E4E_01D64BAB.6F1DC0C0-- From nobody Fri Jun 26 04:05:38 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 CEA543A1228 for ; Fri, 26 Jun 2020 04:05:32 -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 7IlP8FLelTFC for ; Fri, 26 Jun 2020 04:05:31 -0700 (PDT) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 EAFA63A118E for ; Fri, 26 Jun 2020 04:05:30 -0700 (PDT) Received: by mail-ot1-x32c.google.com with SMTP id w17so356175otl.4 for ; Fri, 26 Jun 2020 04:05:30 -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=CgH5sOaS1TmobupByT6mIWRGVrweS/5r4u0AwlA4mH4=; b=NPL23DxBN7YSE3whtgifrAzolyXCLQd0xEpJFdFq93Ek3R7o0zI6kTe1t/dUb7Eot9 TpGTKpaetpwxQWwiNNuNR1i8pTcj0Zh/TdcgHB69V7S0SBiHGZRGLCsnS4sxECh0yFof kgqadf14c+JzzNlVBEu1Ym2mtr5MucaNY5nbI9TMPVEnfdui4OASEGhPxJG8emroeUjS 3Xnwaak3Vr32MJ4XNVHjJM1TDO4+3jYVsG76V2y8TyKztarluW90ytZKQNa7NN5h4s+y av3qmX387ZLSisbh545rs5676XEsCk+tduKq8tqXnBgt4KMp8wj6Q+1+q+znneqZ8c1F mMXg== 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=CgH5sOaS1TmobupByT6mIWRGVrweS/5r4u0AwlA4mH4=; b=ctNjRS8ABX4bRE98i1hVbwQzQd+7ylJYK8+sGaD5viXP2SzXpA+WmRCcE3DNMDQVkR 77e51ERmEfp1XLc74DOoxvzD2TQxxWmpPHH63rbA5goodyho8TgxbD/H8zAcwuXHc+/d D5rPDOQzIHadwW/9lVVWAxp5PDSOCQ6dQV8KaEqqSGWkJSBp4ZOPBcBYcVziKt9YUkae CFLo4jNrDUluuZJ/WSPM6NOYgZs8JtxgrwaMvQTxh1LnZEixrOwKoiLY4ZglrYC0+kbx ExREhjQWGupuD5EFryACoFu/9KQ3m4EJVCeC/nFdQmXH/sw04M3SxnTRUyUDyREhMCtt QdIw== X-Gm-Message-State: AOAM5306dtWhkVlzf2+bDIWHZvi6eFB5XdPN4bwyiAWAGnvHr5fLRov4 rpEVfR+nSHw8V1qN+Mjx2vJvnjZ5fhcVHbFSWeCcRQ== X-Google-Smtp-Source: ABdhPJxb6JimmdVnIfEr4V9hMSXPC4YH7rkuMpoVcABzfE086iOImgn6PR58qcuLkTOTA8cgiUDYsuh1Ltc1fP0+8f4= X-Received: by 2002:a05:6830:452:: with SMTP id d18mr1839186otc.164.1593169530073; Fri, 26 Jun 2020 04:05:30 -0700 (PDT) MIME-Version: 1.0 References: <0e4d01d64b92$49cf5040$dd6df0c0$@gmail.com> In-Reply-To: <0e4d01d64b92$49cf5040$dd6df0c0$@gmail.com> From: Alexandre GOUAILLARD Date: Fri, 26 Jun 2020 13:05:19 +0200 Message-ID: To: Roni Even Cc: Patrick McManus , Emad Omara , Ben Campbell , Dispatch WG , sframe@ietf.org Content-Type: multipart/alternative; boundary="000000000000e849e605a8faaf32" Archived-At: Subject: Re: [dispatch] [Sframe] Dispatch of SFrame for End-To-End Encrypted Conference Calls 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, 26 Jun 2020 11:05:33 -0000 --000000000000e849e605a8faaf32 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi roni, Those are great points. With respect to EKT, we believe that just like double and EKT were two separate matters even though there were both needed to get a complete system to work, media encryption (SFrame) and key distribution should be separated. One of the argument in favor of separation is that while media encryption will likely be the same in nature whether you do video conferencing, or streaming, or other media use cases, the trust / threat model can be vastly different, and thus require different key exchange mechanisms. With respect to RTP, and I believe emad is working on writing a draft as we speak. regards, On Fri, Jun 26, 2020 at 10:18 AM Roni Even wrote: > Hi, > > > > I find this proposal interesting since the issue of key distribution in > multipoint conferences is a problem even if the media mixer (any topology= ) > is a trusted entity and wants to distribute the encrypted media without > doing decrypt/encrypt cycle. One point to look at is that in the past wh= en > we designed RFC5764 (DTLS/SRTP) the consensus was that key exchange must = be > done in-band. > > As far as I remember one of the motivation point for EKT in AVT was to > address the key distribution for multipoint conferences. > > > > As for the work, if there is a consensus to accept this work, it will > require support for RTP. How to signal that this is such a payload and wh= at > should be the RTP PT in the RTP header. (how to negotiate what is the > secure payload inside the SFRAME) > > On one hand it may look like a new RTP payload (similar to MPEG2 RTP > payload (RFC2250)) and as such is in scope for AVTCore but as for the > framework I think this is not AVTCore work. > > > > Roni Even > > AVTCore co-chair > > > > > > > > *From:* dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of *Patric= k > McManus > *Sent:* Monday, June 15, 2020 10:06 PM > *To:* Emad Omara > *Cc:* Ben Campbell; Dispatch WG; sframe@ietf.org > *Subject:* [dispatch] Dispatch of SFrame for End-To-End Encrypted > Conference Calls > > > > Hi All - > > I failed to note the link highlighting in Emad's mail to the list which > already contained the draft. Sorry about that. (It's > https://tools.ietf.org/html/draft-omara-sframe-00 if you too missed it). > > There's also a github and mailing list referenced: > https://github.com/eomara/sframe > https://mailarchive.ietf.org/arch/browse/sframe/? > > > > [I've also forked the Subject Line to help interested readers] > > > > On Mon, Jun 15, 2020 at 2:42 PM Patrick McManus < > patrick.ducksong@gmail.com> wrote: > > Sounds really interesting Emad and there's obviously related work going o= n > (at least perc, maybe even mls..). > > > > Sending that email Ben mentions to the dispatch list to raise awareness > with a link to the draft would be helpful in getting the process started.= . > > > > On Mon, Jun 15, 2020 at 2:33 PM Emad Omara wrote: > > Hi Ben, > > > > This draft proposes a solution for end-to-end encrypted conference calls. > We implemented this in Google a couple of years ago in Duo, but the draft > was only published last month given the current interest in the topic. > > > > The goal of the session is to go through the proposal and see if there is > interest to continue working on this, and if so what will be the best WG = to > host this work. > > > > Thanks > > Emad > > > > On Mon, Jun 15, 2020 at 11:02 AM Ben Campbell wrote: > > Hi Emad, > > > > We prioritize DISPATCH meeting time to focus on topics that have had > DISPATCH list discussion and need high-bandwidth time to resolve. Unless > I=E2=80=99ve missed something, this topic has not previously come up in D= ISPATCH. I > suggest sending a note to this list with some background about the draft > and how you would like to see it progress. > > > > Thanks! > > > > Ben. > > > > On Jun 15, 2020, at 12:32 PM, Emad Omara < > emadomara=3D40google.com@dmarc.ietf.org> wrote: > > > > Hi, > > > > We would like to have a session in the next IETF to discuss the SFrame > draft Can you please > help scheduling this? > > > > Thanks > > Emad > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --000000000000e849e605a8faaf32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi roni,

Those are great points.
<= div>
With respect to EKT, we believe that just=C2=A0like doub= le and EKT were two separate matters even though there=C2=A0were both neede= d to get a complete system to work, media encryption (SFrame) and key distr= ibution should be separated. One of the argument in favor of separation is = that while media encryption will likely be the same in nature whether you d= o video conferencing, or streaming, or other media use cases, the trust / t= hreat=C2=A0model can be vastly different, and thus require different key ex= change mechanisms.

With respect to RTP, and I beli= eve emad is working on writing a draft as we speak.

regards,


On Fri, Jun 26, 2020 at 10:18 AM Roni Even &= lt;ron.even.tlv@gmail.com>= wrote:

Hi,

<= u>=C2=A0

I find this pr= oposal interesting since the issue of key distribution in multipoint confer= ences is a problem even if the media mixer (any topology) is a trusted enti= ty and wants to distribute the encrypted media without doing decrypt/encryp= t cycle.=C2=A0 One point to look at is that in the past when we designed RF= C5764 (DTLS/SRTP) the consensus was that key exchange must be done in-band.=

As far as I rememb= er one of the motivation point for EKT in AVT was to address the key distri= bution for multipoint conferences.

=C2=A0

As for the work, if there is a consensus to accept this work, it will re= quire support for RTP. How to signal that this is such a payload and what s= hould be the RTP PT in the RTP header. (how to negotiate what is the secure= payload inside the SFRAME)

= On one hand it may look like a new RTP payload (similar to MPEG2 RT= P payload (RFC2250)) and as such is in scope for AVTCore but as for the fra= mework I think this is not AVTCore work.

=C2=A0

Roni Even

= AVTCore co-chair

= =C2=A0

=C2=A0=

=C2=A0

From: dispatch [mailto:dispatch-bounces@ietf.org] = On Behalf Of Patrick McManus
Sent: Monday, June 15, 2020 10:0= 6 PM
To: Emad Omara
Cc: Ben Campbell; Dispatch WG; sframe@ietf.org
= Subject: [dispatch] Dispatch of SFrame for End-To-End Encrypted Confere= nce Calls

=C2=A0

Hi All -

I failed= to note the link highlighting in Emad's mail to the list which already= contained the draft. Sorry about that. (It's=C2=A0https://tools.i= etf.org/html/draft-omara-sframe-00=C2=A0if you too missed it).

T= here's also a github and mailing list referenced:
https://github.com/eomara/sfra= me
https://mailarchive.ietf.org/arch/browse/sframe/?=

=C2=A0

<= p class=3D"MsoNormal">[I've also forked the Subject Line to help intere= sted readers]

= =C2=A0

On Mon, Jun 15, 2020 at 2= :42 PM Patrick McManus <patrick.ducksong@gmail.com> wrote:

=

Sounds really inter= esting Emad and there's obviously related=C2=A0work going on (at least = perc, maybe even mls..).

=C2=A0

Sending that email Ben= mentions to the dispatch list to raise awareness with a link to the draft = would be helpful in getting the process started..

=C2=A0

On Mon, Jun 15, 2020 at 2:33 PM Emad Omara <emadomara@google.com> wrote:<= u>

Hi= Ben,

=C2=A0

=

This draft proposes a solution for end-to= -end encrypted conference calls. We implemented=C2=A0this in Google a coupl= e of years ago in Duo, but the draft was only published last month given th= e current interest in the topic.

=C2=A0

The goal= of the session is to go through the proposal and see if there is interest = to continue working on this, and if so what will be the best WG to host thi= s work.=C2=A0

=C2= =A0

Thanks

Emad

=C2=A0

On = Mon, Jun 15, 2020 at 11:02 AM Ben Campbell <ben@nostrum.com> wrote:

Hi Emad,

=C2=A0

We prioritize DISPATCH meeting time to focus on topics that= have had DISPATCH list discussion and need high-bandwidth time to resolve.= Unless I=E2=80=99ve missed something, this topic has not previously come u= p in DISPATCH. I suggest sending a note to this list with some background a= bout the draft and how you would like to see it progress.

=

=C2=A0

Thanks!

=C2=A0

Ben.



On Jun 15, 2020, at 12:32 PM, Emad Omara <emadomara=3D4= 0google.com@dmarc.ietf.org> wrote:

=C2=A0

Hi,=

=C2=A0

We would like to have a session in the next IE= TF to discuss the SFrame draft=C2=A0Can you please help scheduling= this?

=C2=A0<= /u>

Thanks

Emad

_______________________________________________
dispatch mailing l= ist
dispatch@ietf= .org
https://www.ietf.org/mailman/listinfo/dispatch<= /u>

=C2=A0

--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--000000000000e849e605a8faaf32-- From nobody Fri Jun 26 08:41:03 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 0395B3A0825 for ; Fri, 26 Jun 2020 08:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, 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 U9-ttXl6IiDe for ; Fri, 26 Jun 2020 08:40:59 -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 69F463A0820 for ; Fri, 26 Jun 2020 08:40:59 -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 05QFemKL002034 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 26 Jun 2020 10:40:49 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1593186050; bh=ige/flTs6xcaKVTw4oKL3XxK7/hzSSVX9CTix37mU3M=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=ZyoLkkt8C+GmLJyNVKjBwzZAbGDQtw0qVOXM+Tv+rzwvWuwe3QTCh4voMyVkyMaql fzAUhOyFS6c0FASVJ81eEhn028383qRpQ4U7caVvNG+9xL/cqWUbjqi3ESj58rJzCb mtarvCXShsIjx8Mv0zAQl7lFEHqKSRACQIdr7qeI= 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 Message-Id: <7048289C-B091-40AB-9013-D1F415A340F2@nostrum.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_737EA961-CD42-48B9-BEE9-9C1B537EDB5E" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 26 Jun 2020 10:40:39 -0500 In-Reply-To: Cc: Robert Sparks , DISPATCH To: Mary Barnes References: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) 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: Fri, 26 Jun 2020 15:41:02 -0000 --Apple-Mail=_737EA961-CD42-48B9-BEE9-9C1B537EDB5E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I read Robert=E2=80=99s email to be an objection to the fact that our = existing charter allows us to adopt certain documents at all, not an = objection that this draft does not fit under the charter. If that=E2=80=99= s not the case, please correct me. Ben. > On Jun 23, 2020, at 11:29 AM, Mary Barnes = wrote: >=20 > I totally agree with Robert.=20 >=20 >=20 >=20 > On Tue, Jun 23, 2020 at 9:12 AM Robert Sparks > wrote: > I can live with either path, but I still think allowing Dispatch to = adopt work was a step onto the slippery slope mistake. >=20 > On 6/22/20 5:51 PM, Ben Campbell wrote: >> Hi Everyone, >>=20 >> 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 documents. 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 immediately 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.) >>=20 >> Thanks! >>=20 >> Ben (as co-chair) >>=20 >>> On Jun 3, 2020, at 6:13 PM, Ted Hardie > wrote: >>>=20 >>> Howdy, >>>=20 >>> This is one the shortest drafts I've ever written: = 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. =20 >>>=20 >>> This draft updates RFC 3405 to require "permanent" scheme = registrations. The salient bit is this: >>>=20 >>> All registrations in URI.ARPA MUST be for schemes which are = permanent >>> registrations, as they are described in BCP 35. >>>=20 >>> I'm hoping for a quick dispatch of this, but happy to discuss. >>>=20 >>> regards, >>>=20 >>> Ted Hardie >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch = >>=20 >>=20 >>=20 >> _______________________________________________ >> 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 --Apple-Mail=_737EA961-CD42-48B9-BEE9-9C1B537EDB5E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = read Robert=E2=80=99s email to be an objection to the fact that our = existing charter allows us to adopt certain documents at all, not an = objection that this draft does not fit under the charter. If that=E2=80=99= s not the case, please correct me.

Ben.

On Jun 23, 2020, at 11:29 AM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

I totally agree with Robert. 



On Tue, Jun 23, 2020 at 9:12 AM Robert Sparks = <rjsparks@nostrum.com> wrote:
=20 =20 =20

I can live with either path, but I still = think allowing Dispatch to adopt work was a step onto the slippery slope mistake.

On 6/22/20 5:51 PM, Ben Campbell wrote:
=
=20 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 documents. 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 immediately 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.)

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/ .   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
_______________________________________________
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

= --Apple-Mail=_737EA961-CD42-48B9-BEE9-9C1B537EDB5E--