From nobody Tue Feb 1 04:43:23 2022 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 186E03A088D for ; Tue, 1 Feb 2022 04:43:21 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zySakey9y7_m for ; Tue, 1 Feb 2022 04:43:16 -0800 (PST) Received: from st43p00im-ztdg10071801.me.com (st43p00im-ztdg10071801.me.com [17.58.63.171]) (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 BB60A3A0813 for ; Tue, 1 Feb 2022 04:43:16 -0800 (PST) Received: from smtpclient.apple (c-69-255-21-229.hsd1.va.comcast.net [69.255.21.229]) by st43p00im-ztdg10071801.me.com (Postfix) with ESMTPSA id 04EB83C0F71; Tue, 1 Feb 2022 12:34:51 +0000 (UTC) From: John Curran Message-Id: <45FB4652-FE54-4356-AD24-12CB91495F79@istaff.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_C8F807D5-3CB0-47F4-85C2-3E19F0D8B051" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) Date: Tue, 1 Feb 2022 07:34:50 -0500 In-Reply-To: <004f01d8170a$25c35620$714a0260$@acm.org> Cc: Michael Richardson , n.lukianets@openethics.ai, art@ietf.org, dispatch@ietf.org, hrpc@irtf.org, secdispatch@ietf.org To: Larry Masinter References: <6dac86b0eb3b96490dadffdc0f1d307a@openethics.ai> <3343.1643661981@localhost> <004f01d8170a$25c35620$714a0260$@acm.org> X-Mailer: Apple Mail (2.3693.60.0.1.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.816 definitions=2022-02-01_03:2022-02-01, 2022-02-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1030 mlxscore=0 mlxlogscore=535 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2009150000 definitions=main-2202010069 Archived-At: Subject: Re: [dispatch] [hrpc] [art] [Secdispatch] Open Ethics Transparency Protocol 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, 01 Feb 2022 12:43:21 -0000 --Apple-Mail=_C8F807D5-3CB0-47F4-85C2-3E19F0D8B051 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 31 Jan 2022, at 8:22 PM, Larry Masinter wrote: >=20 > Check out=20 > https://github.com/w3ctag/ethical-web-principles > which seems to have some momentum and some similar goals. Larry -=20 A very interesting initiative - thanks for sharing.=20 After brief review, it would appear that the web folks have a = signficiant advantage in their efforts to protect human rights on the = web, as they are successful in affirmatively stating their desired = outcome for its users =E2=80=93=20 e.g. "The web must make it possible for people to verify the information = they see=E2=80=9D - this speaks directly to the functionality that must = be provided to the users rather than the human rights implications of an = application failing to do so=E2=80=A6 An interesting thought exercise lies in considering why the IETF/IRTF = work in this area differs in this regard - I suspect it is not lack of = desire, but inherent to dealing with many protocols and implied = application contexts rather than one predominant model (i.e. the = user/web browser context). It is quite reasonable that the abundance = of protocols and user contexts results in pragmatic limits in = postulating desired user functionality for an ethical Internet, but it = does raise the question of whether more focused efforts for the most = popular applications (e.g. email, messaging) could be undertaken in = other contexts or for some reason are simply unachievable outside of the = web context... Thanks again for the pointer to this work!=20 /John Disclaimer: my views alone - may cause drowsiness - do not read while = operating heavy machinery. =20 --Apple-Mail=_C8F807D5-3CB0-47F4-85C2-3E19F0D8B051 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 31 Jan 2022, at 8:22 PM, = Larry Masinter <LMM@acm.org> wrote:

Check = out
=             &n= bsp; https://github.com/w3ctag/ethical-web-principles
which seems to have some momentum and some similar = goals.

Larry = - 

A very interesting = initiative - thanks for sharing. 

After brief review, it would appear that the web = folks have a signficiant advantage in their efforts to protect human = rights on the web, as they are successful in affirmatively stating their = desired outcome for its users =E2=80=93 
e.g. "The web must = make it possible for people to verify the information they see=E2=80=9D = - this speaks directly to the functionality that must be provided to the = users rather than the human rights implications of an application = failing to do so=E2=80=A6

An interesting thought exercise lies in = considering why the IETF/IRTF work in this area differs in this regard - = I suspect it is not lack of desire, but inherent to dealing with many = protocols and implied application contexts rather than one predominant = model (i.e. the user/web browser context).   It is quite reasonable = that the abundance of protocols and user contexts results in pragmatic = limits in postulating desired user functionality for an ethical = Internet, but it does raise the question of whether more focused efforts = for the most popular applications (e.g. email, messaging) could be = undertaken in other contexts or for some reason are simply unachievable = outside of the web context...

Thanks again for the pointer to this = work! 
/John

Disclaimer:  my views alone - may cause drowsiness - do = not read while operating heavy machinery.    

= --Apple-Mail=_C8F807D5-3CB0-47F4-85C2-3E19F0D8B051-- From nobody Tue Feb 1 06:03:54 2022 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 3501B3A0E1F; Tue, 1 Feb 2022 06:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.434 X-Spam-Level: X-Spam-Status: No, score=-1.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=openethics.ai 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 OEVHU1Q_OxyD; Tue, 1 Feb 2022 06:03:31 -0800 (PST) Received: from nlskm21.hostsila.org (nlskm21.hostsila.org [88.218.28.6]) (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 8801B3A0E1C; Tue, 1 Feb 2022 06:03:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=openethics.ai; s=default; h=Content-Transfer-Encoding:Content-Type: Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=EdcFijR6lcZqZq5gZAH6j9q5cGhvocgplKVUl60fpH8=; b=a1Ci/qEd3mnRNy+7uqZOARMlGu 57Uo4z/jBs56RjLXPuefYx8j0E/hUw1dGnHbai5xMXGa0kCo12j9BrH3OUYfSGVWh8cITWII/gJey zRl405b5HDUgfG76qjcsSPPD8IdndoRN486cx8MRuDVDM3X9BzAxGIDfXVXqxzF0jFUhGKVhONX6D uddeEFM7DoLVKxURvRQ89IQTxxWGxxbIG018lG4xOz7XLlH4cymDU73Vz7evPO8/rC1G6jsBILBPD HIluV7HDjMSvOfLHQIInX8JaElzI/OZxmjnZVg1kIEC78tAhvDYh4UbJ6Qc+onOJwQtUKF5qHJKj/ Pd3zWuww==; Received: from [127.0.0.1] (port=43946 helo=nlskm21.hostsila.org) by nlskm21.hostsila.org with esmtpa (Exim 4.94.2) (envelope-from ) id 1nEtkl-0008VH-C7; Tue, 01 Feb 2022 16:03:26 +0200 MIME-Version: 1.0 Date: Tue, 01 Feb 2022 16:03:25 +0200 From: n.lukianets@openethics.ai To: John Curran , ghelfrich@internews.org, Michael Richardson , Larry Masinter Cc: art@ietf.org, dispatch@ietf.org, hrpc@irtf.org, secdispatch@ietf.org In-Reply-To: <45FB4652-FE54-4356-AD24-12CB91495F79@istaff.org> References: <6dac86b0eb3b96490dadffdc0f1d307a@openethics.ai> <3343.1643661981@localhost> <004f01d8170a$25c35620$714a0260$@acm.org> <45FB4652-FE54-4356-AD24-12CB91495F79@istaff.org> User-Agent: Roundcube Webmail/1.4.12 Message-ID: <3dc66e6f6ce450f20f5154bdd80a72f8@openethics.ai> X-Sender: n.lukianets@openethics.ai Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - nlskm21.hostsila.org X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - openethics.ai X-Get-Message-Sender-Via: nlskm21.hostsila.org: authenticated_id: n.lukianets@openethics.ai X-Authenticated-Sender: nlskm21.hostsila.org: n.lukianets@openethics.ai X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [dispatch] [hrpc] [art] [Secdispatch] Open Ethics Transparency Protocol 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, 01 Feb 2022 14:03:37 -0000 Thanks a lot John, Gina, Larry, Michael. All your comments are very valuable here I'll try to put my reflections as a response in one single email to continue the conversation. @Michael, > Are you talking about security disclosures? > Or something else? The approach/lens that we're taking here is to allow describing every autonomous system with the help of the ethical "vector". We are aiming to bring at least a very basic formalism to what is now becoming a buzzword. https://openethics.ai/vector/ Security part in the disclosure which forms these vectors is a component, but not everything. In some applications security is key, while in others users are ready to compromise security for other "values" > I don't really understand the semantics of the content When we have a disclosure, we transform it in the machine-readable form (the one you've seen in the section 5). Then we present this disclosure in the machine-readable form - to other machines And to humans - in the form of icons. The basic implementation of the label is available here https://openethics.ai/label/ The machine-readable file and the visual label could be generated here https://openethics.ai/label/generate/ > in some ways it is similiar to securitytxt in syntax Indeed, the securitytxt is similar to the extent that they provide mechanism to the disclosure. In Open Ethics I've decided to bring the infrastructure for the signatures (PGP in the securitytxt implementation). PGP doesn't cover the case of disclosure withdrawal which is critical for the applications that > think you need a more detailed, more well worked set of examples Thank you! This is something that I should focus on, 100% @Gina, > Is this referring to Datasheets for Datasets? Yes, this is very close and linked. Let me explain. 1) Datasheets for Datasets, Google Model Cards, are integral part to describe the Training Datasets. We're augmenting it with Data Passport. The Data Passport has a purpose at depicting the origins of the training datasets by bringing a standardized approach to convey information about data annotation processes, data labelers profiles, and correct scoping of the labeler’s job. https://github.com/OpenEthicsAI/OEDP 2) We insist that the information about training datasets/decision logic is key in the disclosure, however should be augmented by to other pillars to call systems "disclosure-complete". Together they are: (A) Code libraries/components, including the approach to data processing and data transfer. (B) Decision Space, restricted vs unrestricted, plus information about failure modes of the system. (C) Training data and heuristics origins. 3) Transparency Protocol is not only about the process of the disclosure formation, but importantly about how it should be exchanged. The goal is so that transparency will not be only on the "surface", but will also tell us something about the components with their approaches, practices, processes, code put in place. @Larry, @John Thanks a lot, we've been looking at this work at W3C . This is close with the overall mission, but different in implementation. We're guided by a very similar set of assumptions. https://openethics.ai/manifesto/ What we believe is that similar statements should become widespread. However, it is not sufficient for a regulator or a community of "ethical" developers to start using them. They should be communicated in a standard manner. What is crucial is to unlock the bottom-up regulatory mechanisms, and to make sure that every user/consumer with no knowledge of security, privacy, fairness, bias, safety, architecture, etc, will start learning more about labels on the digital products. This has happened in other industries like food, construction, pharma, but not yet in the IT. Looking forward to your feedback and thank you a lot for your contributions and thoughts. Nikita Lukianets --- On 2022-02-01 14:34, John Curran wrote: >> On 31 Jan 2022, at 8:22 PM, Larry Masinter wrote: >> >> Check out >> https://github.com/w3ctag/ethical-web-principles >> which seems to have some momentum and some similar goals. > > Larry - > >> A very interesting initiative - thanks for sharing. >> >> After brief review, it would appear that the web folks have a >> signficiant advantage in their efforts to protect human rights on >> the web, as they are successful in affirmatively stating their >> desired outcome for its users – e.g. "The web must make it >> possible for people to verify the information they see” - this >> speaks directly to the functionality that must be provided to the >> users rather than the human rights implications of an application >> failing to do so… > >> > >> An interesting thought exercise lies in considering why the >> IETF/IRTF work in this area differs in this regard - I suspect it is >> not lack of desire, but inherent to dealing with many protocols and >> implied application contexts rather than one predominant model (i.e. >> the user/web browser context). It is quite reasonable that the >> abundance of protocols and user contexts results in pragmatic limits >> in postulating desired user functionality for an ethical Internet, >> but it does raise the question of whether more focused efforts for >> the most popular applications (e.g. email, messaging) could be >> undertaken in other contexts or for some reason are simply >> unachievable outside of the web context... > > Thanks again for the pointer to this work! > /John > Disclaimer: my views alone - may cause drowsiness - do not read while > operating heavy machinery. From nobody Wed Feb 2 13:31:36 2022 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 9F6C73A2169; Wed, 2 Feb 2022 13:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.675 X-Spam-Level: X-Spam-Status: No, score=-7.675 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H34r603E87j6; Wed, 2 Feb 2022 13:31:29 -0800 (PST) Received: from rn-mailsvcp-ppex-lapp45.apple.com (rn-mailsvcp-ppex-lapp45.rno.apple.com [17.179.253.49]) (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 DE7B13A2167; Wed, 2 Feb 2022 13:31:28 -0800 (PST) Received: from pps.filterd (rn-mailsvcp-ppex-lapp45.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp45.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 212L9QHW003437; Wed, 2 Feb 2022 13:31:22 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=/qwjBQCKGBaHHLgWpt3WubVAnL0eKjeL4FkhwL1dEYo=; b=HUJM/0duQbS7yDcOP9AzVAXhJWYmehpf4AXOFs+NtcOV+aTolE3Yy3Hx1n9eAS7c1Ebu jmtG2EWuUYHjoIfLU1Bdx3EFfxFU/n6IGag87uAkQe6XzF0hjy9DBXmyVmk/vwc/AleJ rkB92sQpXqy1QILtnyb58xNfBfG6DlncQu6ER2aGp1X8voHW1Y/5xxdTDd2FpmBMqcZx mAjNIX70uCHv9ReGHL/mkr9XXzd23W4bB006Bi3Hnk9vbw+bc5AHKHatpTd41wzLWU/Z NQGSFLeoqOxnxZi6z2eI8z5du7X6V+BeJM2eDG/ujfBbM3Cq9poPt0kdrcaj7QTIdrGq VA== Received: from ma-mailsvcp-mta-lapp04.corp.apple.com (ma-mailsvcp-mta-lapp04.corp.apple.com [10.226.18.136]) by rn-mailsvcp-ppex-lapp45.rno.apple.com with ESMTP id 3dw4rx5ruc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 02 Feb 2022 13:31:22 -0800 Received: from ma-mailsvcp-mmp-lapp02.apple.com (ma-mailsvcp-mmp-lapp02.apple.com [17.32.222.15]) by ma-mailsvcp-mta-lapp04.corp.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R6P00JKS5493I30@ma-mailsvcp-mta-lapp04.corp.apple.com>; Wed, 02 Feb 2022 13:31:21 -0800 (PST) Received: from process_milters-daemon.ma-mailsvcp-mmp-lapp02.apple.com by ma-mailsvcp-mmp-lapp02.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R6P008004YK0700@ma-mailsvcp-mmp-lapp02.apple.com>; Wed, 02 Feb 2022 13:31:21 -0800 (PST) X-Va-A: X-Va-T-CD: 802ad90daf1a33e002001086f15e88d7 X-Va-E-CD: 1b2514d45a6cbacdd746d7feed02cb99 X-Va-R-CD: 21f245648979a34695bda2dc7cf5e7b6 X-Va-CD: 0 X-Va-ID: e4b18537-1ef5-497a-b2ec-0d42cddc336c X-V-A: X-V-T-CD: 802ad90daf1a33e002001086f15e88d7 X-V-E-CD: 1b2514d45a6cbacdd746d7feed02cb99 X-V-R-CD: 21f245648979a34695bda2dc7cf5e7b6 X-V-CD: 0 X-V-ID: 53c10eb4-f9da-4128-b77b-333065aa2cc0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.816 definitions=2022-02-02_10:2022-02-01, 2022-02-02 signatures=0 Received: from smtpclient.apple (unknown [17.150.210.35]) by ma-mailsvcp-mmp-lapp02.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R6P00D435484300@ma-mailsvcp-mmp-lapp02.apple.com>; Wed, 02 Feb 2022 13:31:21 -0800 (PST) From: Matthew Byington Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_64AE692A-0B08-4D29-8262-02D3AD9A4F41" MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Wed, 02 Feb 2022 13:31:20 -0800 In-reply-to: <2531793BFFD2289EC9ED5174@PSB> Cc: Eric Rescorla , DISPATCH , Security ADs , Francesca Palombini To: John C Klensin References: <2531793BFFD2289EC9ED5174@PSB> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.816 definitions=2022-02-02_10:2022-02-01, 2022-02-02 signatures=0 Archived-At: Subject: Re: [dispatch] Secure Credential Transfer Charter & BoF 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, 02 Feb 2022 21:31:34 -0000 --Apple-Mail=_64AE692A-0B08-4D29-8262-02D3AD9A4F41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi John, Thank you for your response. I am adding Francesca here to this thread. When I first presented at Dispatch last year they helped guide me and = the other proponents to the right place. I don=E2=80=99t have prior IETF experience myself - I certainly place a = lot of trust in the existing community for where this should live. I should say, I=E2=80=99m not directly opposed to it living in the = Security Area as long as the ADs in general agree. Security does play a large role in our problem statement and = considerations, to your point. Perhaps this is something we could discuss during the BoF? Matt > On Jan 29, 2022, at 10:13 PM, John C Klensin = wrote: >=20 > Hi. >=20 > I've read the thread to date but it seems more appropriate to > respond to this message since this is not about the timing issue > raised by others. >=20 > Having read the charter and other materials, including skimming > the slides, I would like to better understand why this is being > proposed in ART rather than in the Security Area. The expertise > is there (and not in ART except by happy accident) on most of > the "primary goals" and requirements in the charter. It is > clear why an application or application protocol would want to > use the credential-sharing protocol being proposed, but it does > not seem to me that qualifies it as ART work (or, if it does, > why a significant amount of other work in the Security Area does > not belong in ART). >=20 > Just wondering... > john >=20 >=20 > --On Tuesday, January 25, 2022 17:00 -0800 Matthew Byington > > wrote: >=20 >> Hi Eric, >>=20 >> My understanding is that the BoF will be handled virtually >> (not in-person). It has also been scheduled outside of the >> normal IETF week. >>=20 >> The BoF is working-group forming, yes. >>=20 >> Matt >>=20 >>> On Jan 25, 2022, at 11:38 AM, Eric Rescorla >>> wrote: >>>=20 >>> Can you clarify what the status of a "virtual BoF" is, here? >>> I.e., is this in lieu of an actual BoF at the next IETF? Is >>> this WG forming? >>>=20 >>> -Ekr >>>=20 >>>=20 >>> On Tue, Jan 25, 2022 at 11:36 AM Matthew Byington >>> >> >> wrote: Hi there, >>>=20 >>> I wanted to send an email out communicating an upcoming >>> virtual BoF meeting scheduled for Thursday February 10th. >>>=20 >>> This is a follow-on to the initial presentation at IETF week >>> 112 given last year. >>>=20 >>> I am posting the information below to a few different IETF >>> mailing lists, so apologies if you receive duplicate >>> notifications on the subject. >>>=20 >>> A big "thank you" to Francesca for helping us to get this >>> scheduled and organized. >>>=20 >>> Latest draft: >>> https://www.ietf.org/archive/id/draft-secure-credential-tran = >>> sfer-03.html >>> >>> nsfer-03.html> >>>=20 >>> Charter: >>> https://github.com/dimmyvi/secure-credential-transfer/blob/m = >>> ain/charter.md >>> >>> main/charter.md> >>> =09 >>> BoF Request: >>> https://datatracker.ietf.org/doc/bofreq-secure-credential-tr = >>> ansfer-bof-request/ >>> >>> ransfer-bof-request/> >>> =09 >>> Virtual BoF (Francesca is finalizing this schedule still, but >>> this is the proposed date and time): Thursday February 10th >>> 17:00-19:00 UTC >>> (https://www.worldtimebuddy.com/?qm=3D1&lid=3D2673730,5,8,100&h=3D= >>> 2673730&date=3D2022-2-10&sln=3D18-20&hf=3D1 >>> >>> 2673730&date=3D2022-2-10&sln=3D18-20&hf=3D1>) >>>=20 >>> Mailing list: >>> https://www.ietf.org/mailman/listinfo/secret = >>> >=20 >>>=20 >>> Thanks, >>> Matt >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org = > >>> https://www.ietf.org/mailman/listinfo/dispatch = >>> > --Apple-Mail=_64AE692A-0B08-4D29-8262-02D3AD9A4F41 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = John,

Thank you for = your response. I am adding Francesca here to this thread.

When I first presented = at Dispatch last year they helped guide me and the other proponents to = the right place.

I don=E2=80=99t have prior IETF experience myself - I = certainly place a lot of trust in the existing community for where this = should live.

I = should say, I=E2=80=99m not directly opposed to it living in the = Security Area as long as the ADs in general agree.

Security does play a = large role in our problem statement and considerations, to your = point.

Perhaps = this is something we could discuss during the BoF?

Matt

On Jan 29, 2022, at 10:13 PM, John C Klensin <john-ietf@jck.com> = wrote:

Hi.

I've read the thread to date but it seems more appropriate = to
respond to = this message since this is not about the timing issue
raised by others.

Having read the charter and = other materials, including skimming
the slides, I would like to better understand why this is = being
proposed in = ART rather than in the Security Area.  The expertise
is there (and not in ART except = by happy accident) on most of
the "primary goals" and requirements in the charter.  It = is
clear why an = application or application protocol would want to
use the credential-sharing = protocol being proposed, but it does
not seem to me that qualifies it as ART work (or, if it = does,
why a = significant amount of other work in the Security Area does
not belong in ART).

Just wondering...
   john


--On Tuesday, January 25, 2022 = 17:00 -0800 Matthew Byington
<mbyington=3D40apple.com@dmarc.ietf.org> wrote:

Hi = Eric,

My understanding is that the BoF will = be handled virtually
(not in-person). It has also been = scheduled outside of the
normal IETF week.
The BoF is working-group forming, yes.

Matt

On Jan 25, 2022, at 11:38 AM, Eric Rescorla <ekr@rtfm.com>
wrote:

Can you clarify what the = status of a "virtual BoF" is, here?
I.e., is this in lieu = of an actual BoF at the next IETF? Is
this WG forming?

-Ekr


On Tue, Jan 25, 2022 at 11:36 AM Matthew Byington
<mbyington=3D40apple.com@dmarc.ietf.org
<mailto:40apple.com@dmarc.ietf.org>> wrote: Hi = there,

I wanted to send an email out = communicating an upcoming
virtual BoF meeting scheduled = for Thursday February 10th.

This is a = follow-on to the initial presentation at IETF week
112 = given last year.

I am posting the = information below to a few different IETF
mailing lists, = so apologies if you receive duplicate
notifications on the = subject.

A big "thank you" to Francesca for = helping us to get this
scheduled and organized.

Latest draft:
https://www.ietf.org/archive/id/draft-secure-credential-tran

sfer-03.html
<
https://www.ietf.org/archive/id/draft-secure-credential-tra=
nsfer-03.html>

Charter:
= https://github.com/dimmyvi/secure-credential-transfer/blob/m
ain/charter.md
<
https://github.com/dimmyvi/secure-credential-transfer/blob/=
main/charter.md>

BoF Request:
https://datatracker.ietf.org/doc/bofreq-secure-credential-tr
ansfer-bof-request/
<
https://datatracker.ietf.org/doc/bofreq-secure-credential-t=
ransfer-bof-request/>

Virtual BoF (Francesca is finalizing this schedule still, = but
this is the proposed date and time): Thursday February = 10th
17:00-19:00 UTC
(https://www.worldtimebuddy.com/?qm=3D1&lid=3D2673730,5,8,10= 0&h=3D
= 2673730&date=3D2022-2-10&sln=3D18-20&hf=3D1
= <https://www.worldtimebuddy.com/?qm=3D1&lid=3D2673730,5,8,10= 0&h=3D
= 2673730&date=3D2022-2-10&sln=3D18-20&hf=3D1>)

Mailing list:
https://www.ietf.org/mailman/listinfo/secret
= <https://www.ietf.org/mailman/listinfo/secret> 

Thanks,
Matt
_______________________________________________
dispatch mailing list
dispatch@ietf.org <mailto:dispatch@ietf.org>
https://www.ietf.org/mailman/listinfo/dispatch
<https://www.ietf.org/mailman/listinfo/dispatch>

= --Apple-Mail=_64AE692A-0B08-4D29-8262-02D3AD9A4F41-- From nobody Wed Feb 2 14:14:52 2022 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 48F563A1086; Wed, 2 Feb 2022 14:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.897 X-Spam-Level: X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvD3tBJIuZrS; Wed, 2 Feb 2022 14:14:42 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D39533A1E0D; Wed, 2 Feb 2022 14:14:39 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nFNtc-000FtM-A7; Wed, 02 Feb 2022 17:14:36 -0500 Date: Wed, 02 Feb 2022 17:14:30 -0500 From: John C Klensin To: Matthew Byington cc: Eric Rescorla , DISPATCH , Security ADs , Francesca Palombini Message-ID: In-Reply-To: References: <2531793BFFD2289EC9ED5174@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [dispatch] Secure Credential Transfer Charter & BoF 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, 02 Feb 2022 22:14:47 -0000 Matthew, Thanks for the response. For me, it makes perfectly good sense. And, having participated in the DISPATCH discussion, I (and perhaps others) didn't adequately understand how much the work would depend on issues and topics in the Security area.. or we were not paying enough attention. I am actually surprised the question was not raised by ekr or one of the others who spends much more time on security issues than I do. I think discussing this at the BOF would be fine but would strongly encourage Francesca and the Security ADs to have a conversation in advance, either to settle the issue and explain it to those of us who have questions or to make the BOF, even if informally, a joint ART-Security one to increase the odds of the right people being part of that discussion. >From experience, the thing you definitely do not want is to get a document finished and into IETF Last Call and only then have people in the Security Area complain about things you have left out or to which you have paid insufficient attention. The earlier such possibilities are identified and dealt with the better. thanks, john --On Wednesday, February 2, 2022 13:31 -0800 Matthew Byington wrote: > Hi John, > > Thank you for your response. I am adding Francesca here to > this thread. > > When I first presented at Dispatch last year they helped guide > me and the other proponents to the right place. > > I don't have prior IETF experience myself - I certainly > place a lot of trust in the existing community for where this > should live. > > I should say, I'm not directly opposed to it living in the > Security Area as long as the ADs in general agree. > > Security does play a large role in our problem statement and > considerations, to your point. > > Perhaps this is something we could discuss during the BoF? > > Matt > >> On Jan 29, 2022, at 10:13 PM, John C Klensin >> wrote: >> >> Hi. >> >> I've read the thread to date but it seems more appropriate to >> respond to this message since this is not about the timing >> issue raised by others. >> >> Having read the charter and other materials, including >> skimming the slides, I would like to better understand why >> this is being proposed in ART rather than in the Security >> Area. The expertise is there (and not in ART except by happy >> accident) on most of the "primary goals" and requirements in >> the charter. It is clear why an application or application >> protocol would want to use the credential-sharing protocol >> being proposed, but it does not seem to me that qualifies it >> as ART work (or, if it does, why a significant amount of >> other work in the Security Area does not belong in ART). >> >> Just wondering... >> john >> >> >> --On Tuesday, January 25, 2022 17:00 -0800 Matthew Byington >> > > wrote: >> >>> Hi Eric, >>> >>> My understanding is that the BoF will be handled virtually >>> (not in-person). It has also been scheduled outside of the >>> normal IETF week. >>> >>> The BoF is working-group forming, yes. >>> >>> Matt >>> >>>> On Jan 25, 2022, at 11:38 AM, Eric Rescorla >>>> wrote: >>>> >>>> Can you clarify what the status of a "virtual BoF" is, here? >>>> I.e., is this in lieu of an actual BoF at the next IETF? Is >>>> this WG forming? >>>> >>>> -Ekr >>>> >>>> >>>> On Tue, Jan 25, 2022 at 11:36 AM Matthew Byington >>>> >>> >>> >> wrote: Hi there, >>>> >>>> I wanted to send an email out communicating an upcoming >>>> virtual BoF meeting scheduled for Thursday February 10th. >>>> >>>> This is a follow-on to the initial presentation at IETF week >>>> 112 given last year. >>>> >>>> I am posting the information below to a few different IETF >>>> mailing lists, so apologies if you receive duplicate >>>> notifications on the subject. >>>> >>>> A big "thank you" to Francesca for helping us to get this >>>> scheduled and organized. >>>> >>>> Latest draft: >>>> https://www.ietf.org/archive/id/draft-secure-credential-tr >>>> an >>>> >>> ran> sfer-03.html >>>> >>> ra >>>> >>> ra> nsfer-03.html> >>>> >>>> Charter: >>>> https://github.com/dimmyvi/secure-credential-transfer/blob >>>> /m >>>> >>> b/m> ain/charter.md >>>> >>> b/ >>>> >>> b/> main/charter.md> >>>> >>>> BoF Request: >>>> https://datatracker.ietf.org/doc/bofreq-secure-credential- >>>> tr >>>> >>> -tr> ansfer-bof-request/ >>>> >>> -t >>>> >>> -t> ransfer-bof-request/> >>>> >>>> Virtual BoF (Francesca is finalizing this schedule still, >>>> but this is the proposed date and time): Thursday February >>>> 10th 17:00-19:00 UTC >>>> (https://www.worldtimebuddy.com/?qm=1&lid=2673730,5,8,100& >>>> h= >>>> >>> h=> 2673730&date=2022-2-10&sln=18-20&hf=1 >>>> >>> h= >>>> >>> h=> 2673730&date=2022-2-10&sln=18-20&hf=1>) >>>> >>>> Mailing list: >>>> https://www.ietf.org/mailman/listinfo/secret >>>> >>>> >>> > >>>> >>>> Thanks, >>>> Matt >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> > >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>>> >>> > > From nobody Wed Feb 2 14:33:43 2022 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 A94C23A234C for ; Wed, 2 Feb 2022 14:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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=rtfm-com.20210112.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 u4dwQ7EVyzwH for ; Wed, 2 Feb 2022 14:33:33 -0800 (PST) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 C9CBA3A2351 for ; Wed, 2 Feb 2022 14:33:33 -0800 (PST) Received: by mail-io1-xd30.google.com with SMTP id y84so1016505iof.0 for ; Wed, 02 Feb 2022 14:33:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2aW1Pp3NRIl05y8iHKnpOeO3A5F0dDjVk4cqpbBGTGM=; b=Q/RJXQThyg5uA2Zdn3DjxaMjr00SCSzDz+MOZqs2JZKGBFuOq30S9SYkO2w6PtzUAV OnITzmq/79KNDnBKToh4LPcGLOomWcbgvQutrRTnCsKy0IT0rGLcmalp+GJP7HkKsSos /dSfUdO9r62u4rqPjwJZ7qn3OasxV9sbzR3611Y4GoGJgMI+GVYe6HiUJL22a/f06NbI +eI6KWTZxUrsrA0zcAQ6zJpnClx56CIr8s5gmC5SlWejzwF76Jd8q2b5IXpj82fmd0lb W6ln+PVnT7Qrd7sbIApC+80VI1OfuubbOFhN5yyNNiWw3Fa1Z4TuwK4/9y303VKsdJZP 8UIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2aW1Pp3NRIl05y8iHKnpOeO3A5F0dDjVk4cqpbBGTGM=; b=p5X+4fVSQsinaTUXLvUv+ImGAAZC1JBud89QXc2D9V8My2le0aFf8ELxGYbCDQ673T uEfoRGyAjKzwoNThDqKMMelEn/6oIkduqwFNBYA3ZLkcz31oo8VZzbv6hxsMCBdTwhpi vy02vaOj7YDDdc7kr2NypulM/Ip23JdgwoxInxnFW9RaZRnAeMWEbO9o966HZDLUOZjj byd54MghfrIgYKOyQ3uYuabXey2PYdBLwaeqfss1zGnR8IQkSPx4n7Y2mZ81wioNPrz7 dbq+ma7Az1TNNEv1JN4rLaAukoEgpk0q5APWcX+BDLz+lvoClTFgRcZQI5sWddSRCg6w E2aA== X-Gm-Message-State: AOAM532vHBbqepZjgupGk+7YK1S4nsTmmQl2KW1aPc6URadK1H3U7YZV S8eNlQsJa7r0XZW9Qtr6iOjRCg54XvDlONFVLvGiKA== X-Google-Smtp-Source: ABdhPJwXJmsSI7G8x/CwmhhcwTbpDRu16vK+E2KTZDqF7IhE/4p3ZfBzxmgTU2ECRLi29pZYWQtAOudBWoryRXkOStQ= X-Received: by 2002:a6b:710c:: with SMTP id q12mr17367600iog.148.1643841212071; Wed, 02 Feb 2022 14:33:32 -0800 (PST) MIME-Version: 1.0 References: <2531793BFFD2289EC9ED5174@PSB> In-Reply-To: From: Eric Rescorla Date: Wed, 2 Feb 2022 14:32:56 -0800 Message-ID: To: John C Klensin Cc: Matthew Byington , DISPATCH , Security ADs , Francesca Palombini Content-Type: multipart/alternative; boundary="000000000000835b2705d7109bf1" Archived-At: Subject: Re: [dispatch] Secure Credential Transfer Charter & BoF 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, 02 Feb 2022 22:33:41 -0000 --000000000000835b2705d7109bf1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 2, 2022 at 2:14 PM John C Klensin wrote: > Matthew, > > Thanks for the response. For me, it makes perfectly good sense. > And, having participated in the DISPATCH discussion, I (and > perhaps others) didn't adequately understand how much the work > would depend on issues and topics in the Security area.. or we > were not paying enough attention. I am actually surprised the > question was not raised by ekr or one of the others who spends > much more time on security issues than I do. > Hearing my name... This actually was discussed at the meeting [0]. See the end where Richard Barnes says: "don=E2=80=99t think it belongs in sec - the interesting questions are arou= nd the broader architecture. The details of the crypto needs to be arranged properly, but we can bring in exepertise. The work belongs in ART not SEC." I roughly agree with this. The crypto is fairly straightforward but the architecture for moving the data around needs serious consideration.I don't think it would be a disaster in SEC, but based on experience with, for instance ACME, it would need a lot of apps input to avoid screwing that side up. -Ekr [0] https://datatracker.ietf.org/meeting/112/materials/minutes-112-dispatch-00.= html -Ekr > I think discussing this at the BOF would be fine but would > strongly encourage Francesca and the Security ADs to have a > conversation in advance, either to settle the issue and explain > it to those of us who have questions or to make the BOF, even if > informally, a joint ART-Security one to increase the odds of the > right people being part of that discussion. > > >From experience, the thing you definitely do not want is to get > a document finished and into IETF Last Call and only then have > people in the Security Area complain about things you have left > out or to which you have paid insufficient attention. The > earlier such possibilities are identified and dealt with the > better. > > thanks, > john > > --On Wednesday, February 2, 2022 13:31 -0800 Matthew Byington > wrote: > > > Hi John, > > > > Thank you for your response. I am adding Francesca here to > > this thread. > > > > When I first presented at Dispatch last year they helped guide > > me and the other proponents to the right place. > > > > I don't have prior IETF experience myself - I certainly > > place a lot of trust in the existing community for where this > > should live. > > > > I should say, I'm not directly opposed to it living in the > > Security Area as long as the ADs in general agree. > > > > Security does play a large role in our problem statement and > > considerations, to your point. > > > > Perhaps this is something we could discuss during the BoF? > > > > Matt > > > >> On Jan 29, 2022, at 10:13 PM, John C Klensin > >> wrote: > >> > >> Hi. > >> > >> I've read the thread to date but it seems more appropriate to > >> respond to this message since this is not about the timing > >> issue raised by others. > >> > >> Having read the charter and other materials, including > >> skimming the slides, I would like to better understand why > >> this is being proposed in ART rather than in the Security > >> Area. The expertise is there (and not in ART except by happy > >> accident) on most of the "primary goals" and requirements in > >> the charter. It is clear why an application or application > >> protocol would want to use the credential-sharing protocol > >> being proposed, but it does not seem to me that qualifies it > >> as ART work (or, if it does, why a significant amount of > >> other work in the Security Area does not belong in ART). > >> > >> Just wondering... > >> john > >> > >> > >> --On Tuesday, January 25, 2022 17:00 -0800 Matthew Byington > >> >> > wrote: > >> > >>> Hi Eric, > >>> > >>> My understanding is that the BoF will be handled virtually > >>> (not in-person). It has also been scheduled outside of the > >>> normal IETF week. > >>> > >>> The BoF is working-group forming, yes. > >>> > >>> Matt > >>> > >>>> On Jan 25, 2022, at 11:38 AM, Eric Rescorla > >>>> wrote: > >>>> > >>>> Can you clarify what the status of a "virtual BoF" is, here? > >>>> I.e., is this in lieu of an actual BoF at the next IETF? Is > >>>> this WG forming? > >>>> > >>>> -Ekr > >>>> > >>>> > >>>> On Tue, Jan 25, 2022 at 11:36 AM Matthew Byington > >>>> >>>> >>>> >> wrote: Hi there, > >>>> > >>>> I wanted to send an email out communicating an upcoming > >>>> virtual BoF meeting scheduled for Thursday February 10th. > >>>> > >>>> This is a follow-on to the initial presentation at IETF week > >>>> 112 given last year. > >>>> > >>>> I am posting the information below to a few different IETF > >>>> mailing lists, so apologies if you receive duplicate > >>>> notifications on the subject. > >>>> > >>>> A big "thank you" to Francesca for helping us to get this > >>>> scheduled and organized. > >>>> > >>>> Latest draft: > >>>> https://www.ietf.org/archive/id/draft-secure-credential-tr > >>>> an > >>>> >>>> ran> sfer-03.html > >>>> >>>> ra > >>>> >>>> ra> nsfer-03.html> > >>>> > >>>> Charter: > >>>> https://github.com/dimmyvi/secure-credential-transfer/blob > >>>> /m > >>>> >>>> b/m> ain/charter.md > >>>> >>>> b/ > >>>> >>>> b/> main/charter.md> > >>>> > >>>> BoF Request: > >>>> https://datatracker.ietf.org/doc/bofreq-secure-credential- > >>>> tr > >>>> >>>> -tr> ansfer-bof-request/ > >>>> >>>> -t > >>>> >>>> -t> ransfer-bof-request/> > >>>> > >>>> Virtual BoF (Francesca is finalizing this schedule still, > >>>> but this is the proposed date and time): Thursday February > >>>> 10th 17:00-19:00 UTC > >>>> (https://www.worldtimebuddy.com/?qm=3D1&lid=3D2673730,5,8,100& > >>>> h=3D > >>>> >>>> h=3D> 2673730&date=3D2022-2-10&sln=3D18-20&hf=3D1 > >>>> >>>> h=3D > >>>> >>>> h=3D> 2673730&date=3D2022-2-10&sln=3D18-20&hf=3D1>) > >>>> > >>>> Mailing list: > >>>> https://www.ietf.org/mailman/listinfo/secret > >>>> > >>>> >>>> > > >>>> > >>>> Thanks, > >>>> Matt > >>>> _______________________________________________ > >>>> dispatch mailing list > >>>> dispatch@ietf.org > >>>> > > >>>> https://www.ietf.org/mailman/listinfo/dispatch > >>>> > >>>> >>>> > > > > > > --000000000000835b2705d7109bf1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Feb 2, 2022 at 2:14 PM John C= Klensin <john-ietf@jck.com>= wrote:
Matthew,=

Thanks for the response.=C2=A0 For me, it makes perfectly good sense.
And, having participated in the DISPATCH discussion, I (and
perhaps others) didn't adequately understand how much the work
would depend on issues and topics in the Security area.. or we
were not paying enough attention.=C2=A0 I am actually surprised the
question was not raised by ekr or one of the others who spends
much more time on security issues than I do.

Hearing my name...

This actually was discuss= ed at the meeting [0]. See the end where Richard Barnes says:
&qu= ot;don=E2=80=99t think it belongs in sec - the interesting=20 questions are around the broader architecture. The details of the=20 crypto needs to be arranged properly, but we can bring in exepertise. =20 The work belongs in ART not SEC."

I roughly a= gree with this. The crypto is fairly straightforward but the architecture f= or moving the data around needs serious consideration.I don't think it = would be a disaster in SEC, but based on experience with, for instance ACME= , it would need a lot of apps input to avoid screwing that side up.

-Ekr




-Ekr


I think discussing this at the BOF would be fine but would
strongly encourage Francesca and the Security ADs to have a
conversation in advance, either to settle the issue and explain
it to those of us who have questions or to make the BOF, even if
informally, a joint ART-Security one to increase the odds of the
right people being part of that discussion.=C2=A0

>From experience, the thing you definitely do not want is to get
a document finished and into IETF Last Call and only then have
people in the Security Area complain about things you have left
out or to which you have paid insufficient attention.=C2=A0 The
earlier such possibilities are identified and dealt with the
better.

thanks,
=C2=A0 =C2=A0john

--On Wednesday, February 2, 2022 13:31 -0800 Matthew Byington
<mbyington@appl= e.com> wrote:

> Hi John,
>
> Thank you for your response. I am adding Francesca here to
> this thread.
>
> When I first presented at Dispatch last year they helped guide
> me and the other proponents to the right place.
>
> I don't have prior IETF experience myself - I certainly
> place a lot of trust in the existing community for where this
> should live.
>
> I should say, I'm not directly opposed to it living in the
> Security Area as long as the ADs in general agree.
>
> Security does play a large role in our problem statement and
> considerations, to your point.
>
> Perhaps this is something we could discuss during the BoF?
>
> Matt
>
>> On Jan 29, 2022, at 10:13 PM, John C Klensin
>> <john-ie= tf@jck.com> wrote:
>>
>> Hi.
>>
>> I've read the thread to date but it seems more appropriate to<= br> >> respond to this message since this is not about the timing
>> issue raised by others.
>>
>> Having read the charter and other materials, including
>> skimming the slides, I would like to better understand why
>> this is being proposed in ART rather than in the Security
>> Area.=C2=A0 The expertise is there (and not in ART except by happy=
>> accident) on most of the "primary goals" and requirement= s in
>> the charter.=C2=A0 It is clear why an application or application >> protocol would want to use the credential-sharing protocol
>> being proposed, but it does not seem to me that qualifies it
>> as ART work (or, if it does, why a significant amount of
>> other work in the Security Area does not belong in ART).
>>
>> Just wondering...
>>=C2=A0 =C2=A0 john
>>
>>
>> --On Tuesday, January 25, 2022 17:00 -0800 Matthew Byington
>> <mbyington=3D40apple.com@dmarc.ietf.org
>> <mailto:mbyingto= n=3D40a= pple.com@dmarc.ietf.org>> wrote:
>>
>>> Hi Eric,
>>>
>>> My understanding is that the BoF will be handled virtually
>>> (not in-person). It has also been scheduled outside of the
>>> normal IETF week.
>>>
>>> The BoF is working-group forming, yes.
>>>
>>> Matt
>>>
>>>> On Jan 25, 2022, at 11:38 AM, Eric Rescorla <ekr@rtfm.com>
>>>> wrote:
>>>>
>>>> Can you clarify what the status of a "virtual BoF&quo= t; is, here?
>>>> I.e., is this in lieu of an actual BoF at the next IETF? I= s
>>>> this WG forming?
>>>>
>>>> -Ekr
>>>>
>>>>
>>>> On Tue, Jan 25, 2022 at 11:36 AM Matthew Byington
>>>> <mbyington=3D40apple.com@dmarc.ietf.org
>>>> <mailto:40apple.com@dmarc.ietf.org
>>>> <mailto:40apple.com@dmarc.ietf.org>>> wrote: Hi there= ,
>>>>
>>>> I wanted to send an email out communicating an upcoming >>>> virtual BoF meeting scheduled for Thursday February 10th.<= br> >>>>
>>>> This is a follow-on to the initial presentation at IETF we= ek
>>>> 112 given last year.
>>>>
>>>> I am posting the information below to a few different IETF=
>>>> mailing lists, so apologies if you receive duplicate
>>>> notifications on the subject.
>>>>
>>>> A big "thank you" to Francesca for helping us to= get this
>>>> scheduled and organized.
>>>>
>>>> Latest draft:
>>>>=C2=A0 =C2=A0 https://www.= ietf.org/archive/id/draft-secure-credential-tr
>>>>=C2=A0 =C2=A0 an
>>>>=C2=A0 =C2=A0 <https://w= ww.ietf.org/archive/id/draft-secure-credential-t
>>>>=C2=A0 =C2=A0 ran> sfer-03.html
>>>>=C2=A0 =C2=A0 <https://w= ww.ietf.org/archive/id/draft-secure-credential-t
>>>>=C2=A0 =C2=A0 ra
>>>>=C2=A0 =C2=A0 <https://w= ww.ietf.org/archive/id/draft-secure-credential-t
>>>>=C2=A0 =C2=A0 ra> nsfer-03.html>
>>>>
>>>> Charter:
>>>>=C2=A0 =C2=A0 https://gith= ub.com/dimmyvi/secure-credential-transfer/blob
>>>>=C2=A0 =C2=A0 /m
>>>>=C2=A0 =C2=A0 <https://g= ithub.com/dimmyvi/secure-credential-transfer/blo
>>>>=C2=A0 =C2=A0 b/m> ain/charter.md
>>>>=C2=A0 =C2=A0 <https://g= ithub.com/dimmyvi/secure-credential-transfer/blo
>>>>=C2=A0 =C2=A0 b/
>>>>=C2=A0 =C2=A0 <https://g= ithub.com/dimmyvi/secure-credential-transfer/blo
>>>>=C2=A0 =C2=A0 b/> main/charter.md>
>>>>=C2=A0 =C2=A0
>>>> BoF Request:
>>>>=C2=A0 =C2=A0 https://data= tracker.ietf.org/doc/bofreq-secure-credential-
>>>>=C2=A0 =C2=A0 tr
>>>>=C2=A0 =C2=A0 <https://d= atatracker.ietf.org/doc/bofreq-secure-credential
>>>>=C2=A0 =C2=A0 -tr> ansfer-bof-request/
>>>>=C2=A0 =C2=A0 <https://d= atatracker.ietf.org/doc/bofreq-secure-credential
>>>>=C2=A0 =C2=A0 -t
>>>>=C2=A0 =C2=A0 <https://d= atatracker.ietf.org/doc/bofreq-secure-credential
>>>>=C2=A0 =C2=A0 -t> ransfer-bof-request/>
>>>>=C2=A0 =C2=A0
>>>> Virtual BoF (Francesca is finalizing this schedule still,<= br> >>>> but this is the proposed date and time): Thursday February=
>>>> 10th 17:00-19:00 UTC
>>>>=C2=A0 =C2=A0 (= https://www.worldtimebuddy.com/?qm=3D1&lid=3D2673730,5,8,100& >>>>=C2=A0 =C2=A0 h=3D
>>>>=C2=A0 =C2=A0 <https://www.worldtimebuddy.com/?qm=3D1&lid=3D2673730,5,8,100&
>>>>=C2=A0 =C2=A0 h=3D> 2673730&date=3D2022-2-10&sln= =3D18-20&hf=3D1
>>>>=C2=A0 =C2=A0 <
https://www.worldtimebuddy.com/?qm=3D1&lid=3D2673730,5,8,100&
>>>>=C2=A0 =C2=A0 h=3D
>>>>=C2=A0 =C2=A0 <
https://www.worldtimebuddy.com/?qm=3D1&lid=3D2673730,5,8,100&
>>>>=C2=A0 =C2=A0 h=3D> 2673730&date=3D2022-2-10&sln= =3D18-20&hf=3D1>)
>>>>
>>>> Mailing list:
>>>>=C2=A0 =C2=A0
https://www.ietf.org/mailm= an/listinfo/secret
>>>>=C2=A0 =C2=A0 <https://www.ietf.org/m= ailman/listinfo/secret>
>>>>=C2=A0 =C2=A0 <https://www.ietf.org/m= ailman/listinfo/secret
>>>>=C2=A0 =C2=A0 <https://www.ietf.org/m= ailman/listinfo/secret>>
>>>>
>>>> Thanks,
>>>> Matt
>>>> _______________________________________________
>>>> dispatch mailing list
>>>> dis= patch@ietf.org <mailto:dispatch@ietf.org>
>>>> <mailto:dispatch@ietf.org <mailto:dispatch@ietf.org>>
>>>> https://www.ietf.org/mailman/listinfo= /dispatch
>>>> <https://www.ietf.org/mailman/list= info/dispatch>
>>>> <https://www.ietf.org/mailman/list= info/dispatch
>>>> <https://www.ietf.org/mailman/list= info/dispatch>>
>


--000000000000835b2705d7109bf1-- From nobody Wed Feb 2 15:54:42 2022 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 872653A0C82; Wed, 2 Feb 2022 15:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gO5cerq94GdU; Wed, 2 Feb 2022 15:54:35 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5C3D3A0C7A; Wed, 2 Feb 2022 15:54:33 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nFPSH-000G6v-Nx; Wed, 02 Feb 2022 18:54:29 -0500 Date: Wed, 02 Feb 2022 18:54:23 -0500 From: John C Klensin To: Eric Rescorla cc: Matthew Byington , DISPATCH , Security ADs , Francesca Palombini Message-ID: In-Reply-To: References: <2531793BFFD2289EC9ED5174@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [dispatch] Secure Credential Transfer Charter & BoF 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, 02 Feb 2022 23:54:41 -0000 Ekr, Then I'm really glad I mentioned your name :-) I am not opposed to seeing this in ART if you, Richard, and others with more expertise in Security than I have aspired to in the last several decades are persuaded it is the right thing to do... and as long as you (plural) will be sufficiently involved to be sure that, if things drift off in the wrong directions from a security technology standpoint, people are alerted --or, paraphrasing your quote from Richard, that the details are properly arranged and the right expertise is brought in at the right points. Fortunately or unfortunately, I don't know what happened with ACME. I still think that it would be useful to discuss this further at the BOF so everyone who needs it gets a better understanding of where the issues and boundaries lie and to, at least, get agreement from the SEC ADs to help Francesca keep an eye on developments of a WG and any document processing. thanks, john --On Wednesday, February 2, 2022 14:32 -0800 Eric Rescorla wrote: > On Wed, Feb 2, 2022 at 2:14 PM John C Klensin > wrote: > >> Matthew, >> >> Thanks for the response. For me, it makes perfectly good >> sense. And, having participated in the DISPATCH discussion, I >> (and perhaps others) didn't adequately understand how much >> the work would depend on issues and topics in the Security >> area.. or we were not paying enough attention. I am actually >> surprised the question was not raised by ekr or one of the >> others who spends >> > much more time on security issues than I do. >> > > Hearing my name... > > This actually was discussed at the meeting [0]. See the end > where Richard Barnes says: > "don't think it belongs in sec - the interesting questions > are around the broader architecture. The details of the crypto > needs to be arranged properly, but we can bring in exepertise. > The work belongs in ART not SEC." > > I roughly agree with this. The crypto is fairly > straightforward but the architecture for moving the data > around needs serious consideration.I don't think it would be a > disaster in SEC, but based on experience with, for instance > ACME, it would need a lot of apps input to avoid screwing that > side up. > > -Ekr From nobody Wed Feb 2 16:29:53 2022 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 246DE3A0E77 for ; Wed, 2 Feb 2022 16:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_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=W33yGj+z; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bAokFkKX 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 yg0Qa4x-YdCC for ; Wed, 2 Feb 2022 16:29:38 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6296E3A0E3A for ; Wed, 2 Feb 2022 16:29:38 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id DF83C320214F for ; Wed, 2 Feb 2022 19:29:37 -0500 (EST) Received: from imap41 ([10.202.2.91]) by compute2.internal (MEProxy); Wed, 02 Feb 2022 19:29:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; bh=0sGbJctsImRWZtPv+3hBNVqGpyzp4C1ZbQE6jA 2Bf4A=; b=W33yGj+zJgPQIAyhd7qZhydIOUu7O7RTdtx3cqgNoAMeLhPJTrvuEv gK+bjou/N9tY8nK13pq/b7l0Vzvx9gVc7B510HW+6MWsqtfa+vmHDK7IoAGIf2CV 51u79dvkAdU4MHRaSXpTEHtW4+aR+4QanNch0p7WddS2Kuo245tF5Eg/F7/XrUXb QsgOdBFeHbOi2vjHo35HjSBQ5SCSPDyZdRYH9AmRm0KX/of+qfeQcZjEegn+TrSD BhMQA0kbdemXvRXWaAndEL1f8xRsLVLnSZ/kbfkpdh/CBO3K09DmBeBA4fFek7Bt RnOY824Jbz0c+vtgGii+AiDa6tLuPfhA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=0sGbJctsImRWZtPv+ 3hBNVqGpyzp4C1ZbQE6jA2Bf4A=; b=bAokFkKXhFv82nTQ1yZq6CotUpQLXlqzl 8IqFfKPqswil9ltMZn8GQzTjWT4WhJERPuo1Uspb4c3NtqPbHoowIo5g8bheZAVK uN4jXvQjZDLsnQZz7qPCJyaS1MHGh21oRhrDsOS+BTN0x0iZSKXYVjSng325vfxT zXx+iULmFhnSYfbmvF7JtjgFRw34EAbXiJ+1vVkOE0kX7K6HiW2jJTa4P9rKeIYv /Y8MONM0X0Lo1mzlHD9Dk8zOqmlQp2zbeT6QwDKn5aB3fBlRq+wMd6M4qSJ66mGJ regNX7q3AWmPyjfaX2R3iksqK5AaNFe9f8CB/GjclmkVjq6mCkcHQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrgeeigddvtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepkeetueeikedtkeelfeekve fhkeffvedvvefgkefgleeugfdvjeejgeffieegtdejnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 471B43C00CF; Wed, 2 Feb 2022 19:29:37 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4585-ga9d9773056-fm-20220113.001-ga9d97730 Mime-Version: 1.0 Message-Id: <49211a54-213b-4852-8d51-2a2abc8c6533@beta.fastmail.com> In-Reply-To: References: <2531793BFFD2289EC9ED5174@PSB> Date: Thu, 03 Feb 2022 11:29:19 +1100 From: "Martin Thomson" To: dispatch@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [dispatch] Secure Credential Transfer Charter & BoF X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2022 00:29:52 -0000 On Thu, Feb 3, 2022, at 10:54, John C Klensin wrote: > Fortunately or unfortunately, I don't know what happened with > ACME. The details were properly arranged and the right expertise was brought in at the right points. At least from where I stand that was mostly OK. What I think Ekr refers to there is that the work in ACME was overwhelmingly application-side to an extent that surprised some people back then. This made things a little more difficult as a result. Hindsight suggests that this work might be similar. (Ekr and Richard understand this specific proposal better than I do, but their read is similar to my own.) My view here is that this is always going to be hard because a lot of the important work we're doing crosses the artificial boundaries we construct to keep the management manageable. From nobody Wed Feb 2 17:59:05 2022 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 C31B43A1332 for ; Wed, 2 Feb 2022 17:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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.20210112.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 iQj5Oo9YVVZJ for ; Wed, 2 Feb 2022 17:58:58 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0F833A132E for ; Wed, 2 Feb 2022 17:58:57 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id 9so1470469iou.2 for ; Wed, 02 Feb 2022 17:58:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VSIf39oblmMO2gNpkSU4U7PoQHaQHTPszXm7AGhJaR0=; b=P/iZqUOYl4/7MY7m1nMbihzmnbsfD9H1WIUZC78tV53iNNuRVvzDk7whh6Y4tjHDr9 zZRLk3Bn2whVoqflcqiB38747gCqIlh3owQW07llOqTR/T8GxwOYSIhN5Rs/azQEAJIw 4lgz8tE0H+MaYQ4RCwFN39xPWlUW5nc458M5HcGCqxS/p/jp+3Yf29RQ0MANKGz9ocgC 30DCv3WZwfU1zth0oeXVW00kYxaNUjjETw5lRl/h4N/O+c7VT7kBozajO2ZE/I3XUFNH 7ElF3Qb0K7O1iXuItFkvY3s+F+vI/rs9fkQ8yzx5b1HVQ7NPjuL0dvR2lxjXfqITPuA6 r34A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VSIf39oblmMO2gNpkSU4U7PoQHaQHTPszXm7AGhJaR0=; b=ufIVy+5uaB/3jZEcNEJ2Z6h/GbuijWZq4bOpCiXQ7EHAbz6tsUzVD0X3YCqdxsm27b YEMkFfPVqjmUxDOoCNJWWQnFjNCMr6odWyQIpck+zhKIMUxb6DxhRbyFT5NYgmNyKplZ RzHtNkTR7K3cwoMLIHDDJtUraSSe4rQdpks1u1CWtZdvnWmNqUR7Llw0f+IG+RJlr4jO 6SKqCJqIqzYuIW79CabCS+9q9Xm3Ld2XWj2fMrMw1OQO3+VIP+SDbiGTKeY75+B47h5O pPWh3tZgyYXSf3lOGz4ZtYZYvOWVkABK52FGVZbvdHMjNPuYjyiA3iQioQ3pyJ6Wmd8m Co+g== X-Gm-Message-State: AOAM533DtSMXj4uR8+N02Br+s+vSXBuRkQJi/5YZaURKF2V/HLOqPlGn 50SKOm4hu8jGAJcc34MDdOVMbAxGBYgZSvNmZxnzIw== X-Google-Smtp-Source: ABdhPJxJXY89yb4RLwooRcm6mvZZibnThel2QSqOaGgOiZNFwuMP6GqKuYraeyCIWXwWA/inYEZAAdHlbtY5E8fdol0= X-Received: by 2002:a05:6638:380f:: with SMTP id i15mr16084236jav.308.1643853536147; Wed, 02 Feb 2022 17:58:56 -0800 (PST) MIME-Version: 1.0 References: <2531793BFFD2289EC9ED5174@PSB> In-Reply-To: From: Eric Rescorla Date: Wed, 2 Feb 2022 17:58:20 -0800 Message-ID: To: John C Klensin Cc: Matthew Byington , DISPATCH , Security ADs , Francesca Palombini Content-Type: multipart/alternative; boundary="00000000000015d06d05d7137a53" Archived-At: Subject: Re: [dispatch] Secure Credential Transfer Charter & BoF X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2022 01:59:03 -0000 --00000000000015d06d05d7137a53 Content-Type: text/plain; charset="UTF-8" On Wed, Feb 2, 2022 at 3:54 PM John C Klensin wrote: > Ekr, > > Then I'm really glad I mentioned your name :-) > > I am not opposed to seeing this in ART if you, Richard, and > others with more expertise in Security than I have aspired to in > the last several decades are persuaded it is the right thing to > do... and as long as you (plural) will be sufficiently involved > to be sure that, if things drift off in the wrong directions > from a security technology standpoint, people are alerted --or, > paraphrasing your quote from Richard, that the details are > properly arranged and the right expertise is brought in at the > right points. > That seems like a question we would need to resolve at the BOF, perhaps by cutting the BOF questions more finely ("how many security people want to work on this...?") > > Fortunately or unfortunately, I don't know what happened with > ACME. > As MT said, there was just a lot of apps-type work work. > I still think that it would be useful to discuss this further at > the BOF so everyone who needs it gets a better understanding of > where the issues and boundaries lie and to, at least, get > agreement from the SEC ADs to help Francesca keep an eye on > developments of a WG and any document processing. > I agree with this. -Ekr > > thanks, > john > > > --On Wednesday, February 2, 2022 14:32 -0800 Eric Rescorla > wrote: > > > On Wed, Feb 2, 2022 at 2:14 PM John C Klensin > > wrote: > > > >> Matthew, > >> > >> Thanks for the response. For me, it makes perfectly good > >> sense. And, having participated in the DISPATCH discussion, I > >> (and perhaps others) didn't adequately understand how much > >> the work would depend on issues and topics in the Security > >> area.. or we were not paying enough attention. I am actually > >> surprised the question was not raised by ekr or one of the > >> others who spends > >> > > much more time on security issues than I do. > >> > > > > Hearing my name... > > > > This actually was discussed at the meeting [0]. See the end > > where Richard Barnes says: > > "don't think it belongs in sec - the interesting questions > > are around the broader architecture. The details of the crypto > > needs to be arranged properly, but we can bring in exepertise. > > The work belongs in ART not SEC." > > > > I roughly agree with this. The crypto is fairly > > straightforward but the architecture for moving the data > > around needs serious consideration.I don't think it would be a > > disaster in SEC, but based on experience with, for instance > > ACME, it would need a lot of apps input to avoid screwing that > > side up. > > > > -Ekr > > > --00000000000015d06d05d7137a53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Feb 2, 2022 at 3:54 PM John C= Klensin <john-ietf@jck.com>= wrote:
Ekr,

Then I'm really glad I mentioned your name :-)

I am not opposed to seeing this in ART if you, Richard, and
others with more expertise in Security than I have aspired to in
the last several decades are persuaded it is the right thing to
do... and as long as you (plural) will be sufficiently involved
to be sure that, if things drift off in the wrong directions
from a security technology standpoint, people are alerted --or,
paraphrasing your quote from Richard, that the details are
properly arranged and the right expertise is brought in at the
right points.

That seems like a questio= n we would need to resolve at the BOF,
perhaps by cutting the BOF= questions more finely ("how many
security people want to wo= rk on this...?")

=C2=A0

Fortunately or unfortunately, I don't know what happened with
ACME.

As MT said, there was just a lot = of apps-type work work.
=C2=A0
I still think that it would be useful to discuss this further at
the BOF so everyone who needs it gets a better understanding of
where the issues and boundaries lie and to, at least, get
agreement from the SEC ADs to help Francesca keep an eye on
developments of a WG and any document processing.

=
I agree with this.

-Ekr

<= /div>

=C2=A0

thanks,
=C2=A0 =C2=A0john


--On Wednesday, February 2, 2022 14:32 -0800 Eric Rescorla
<ekr@rtfm.com> = wrote:

> On Wed, Feb 2, 2022 at 2:14 PM John C Klensin
> <john-ietf@j= ck.com> wrote:
>
>> Matthew,
>>
>> Thanks for the response.=C2=A0 For me, it makes perfectly good
>> sense. And, having participated in the DISPATCH discussion, I
>> (and perhaps others) didn't adequately understand how much
>> the work would depend on issues and topics in the Security
>> area.. or we were not paying enough attention.=C2=A0 I am actually=
>> surprised the question was not raised by ekr or one of the
>> others who spends
>>
> much more time on security issues than I do.
>>
>
> Hearing my name...
>
> This actually was discussed at the meeting [0]. See the end
> where Richard Barnes says:
> "don't think it belongs in sec - the interesting questions > are around the broader architecture. The details of the crypto
> needs to be arranged properly, but we can bring in exepertise.
> The work belongs in ART not SEC."
>
> I roughly agree with this. The crypto is fairly
> straightforward but the architecture for moving the data
> around needs serious consideration.I don't think it would be a
> disaster in SEC, but based on experience with, for instance
> ACME, it would need a lot of apps input to avoid screwing that
> side up.
>
> -Ekr


--00000000000015d06d05d7137a53-- From nobody Wed Feb 2 18:25:16 2022 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 C4D6E3A143B; Wed, 2 Feb 2022 18:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=seicmu.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrSaivH3ayxN; Wed, 2 Feb 2022 18:25:09 -0800 (PST) Received: from USG02-CY1-obe.outbound.protection.office365.us (mail-cy1usg02on0101.outbound.protection.office365.us [23.103.209.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DB173A1439; Wed, 2 Feb 2022 18:25:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=iRlSUiTUCPtZJhceBdwFey5GxBara0qQNQtSsYdTWPgQ98OX3pDUSLDAdlO/cCt0V2FkteLhohq0ljKJN7VrBl0g8/ETdqtI19PsIhtshJO2mG37KVaD5FoS1uMJlYzTFg40vrhQcfQ7FdEXPgr2wS01wvtp2dwKvva4zmuaRm8Ai4A8cNtGp/l7BPHp1BdS89iBaM/UejGAvRwhfsnSR39XZPbhYCXJH8Qqks7fNVSKTdzyrNTk9y+EiRO7rEnVn6r+uROeb2Egcp9izj91JpzMjaeDwjVB81BcxKHJO7mngRBG+6izU0LILryibEyNRa0o+iMNYPhC8Ql1Jj0CKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zmu8/sXQ0qWS5ny6eJ59bhskic+gT5K2qRDdZdX8qQA=; b=vwsEgqeXs4MafUlPbbBM2EUIno52iwBVhoflzPqF29z/SeooZDazyjmO0+an1HBRTu8swGaTWKC9ilJkeBlVtMK4ixf+lXtjGxhGjHpU9EjXQvZISJfQWnZB0BCsR97qrYFRMPvO+DJLEOltPj58YFb19eynNWLGBBbPxG4tKDRmNmg3bU9fPp9ZY+gZPlqgl0n7ek9YA22ZM2GDImQKtlNeJ/MCfhSivxDgZZgokznxwLjpqIXMISWtYtBOqo/1hIXIXEWtXsv86mc77IxObdvxKZ8HCbZvERFou1Gqx8GGZEs6OzmA69/hAOe71SSiryWvWd/mIwQdkQUN9z4YWg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cert.org; dmarc=pass action=none header.from=cert.org; dkim=pass header.d=cert.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seicmu.onmicrosoft.com; s=selector1-seicmu-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zmu8/sXQ0qWS5ny6eJ59bhskic+gT5K2qRDdZdX8qQA=; b=eilHrfk2gxfirNVk1yI8C0O9Q1mWoPgKGbBoE6C/aWROTFW2g3LRMwWAgHqsS1CQoG53KR8xi7K50TqR6O+G7CpXi7Lp6nVo4D9lMT+OrYRE7oXwU7awxdL18xqOpRceVoQ2+Av5LCSjXCCqC4YNMqPB7F9dcImunwJaqoqUT4k= Received: from BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:168::11) by BN2P110MB1621.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:17b::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.12; Thu, 3 Feb 2022 02:25:05 +0000 Received: from BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM ([fe80::45f0:b470:9c74:ef6e]) by BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM ([fe80::45f0:b470:9c74:ef6e%3]) with mapi id 15.20.4930.020; Thu, 3 Feb 2022 02:25:05 +0000 From: Roman Danyliw To: Eric Rescorla , John C Klensin CC: Matthew Byington , DISPATCH , Security ADs , Francesca Palombini Thread-Topic: [dispatch] Secure Credential Transfer Charter & BoF Thread-Index: AQHYFaB3BSkX6O6GRkey2W3J0DmrZ6yAzS4AgAAMEACAAAUmAIAAFsKAgAAiogCAAAVf8A== Date: Thu, 3 Feb 2022 02:25:04 +0000 Message-ID: References: <2531793BFFD2289EC9ED5174@PSB> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cert.org; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 370e7e85-1877-49e2-1312-08d9e6bc63ad x-ms-traffictypediagnostic: BN2P110MB1621:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dcPGP+XHJu90QUAKq8eNONRjMHjqaVQWpAP4nn24GnDZNp6TrZf6/kKv5iwQMywQ7de6aQfIIKA6m2E8VNYRXn8RpsEtw955789grFeoiSyY4ntjir/bXoN/6jbMP8misCmJTV002C67DVEx2ANA14YLvZH3Vz9yA2pgKJB3iobWl86UmEyqyVRqnII9puuUcuMoNlosSEzdl/OT2zCMlrIBfcM3toIuk0vdPkHR8p7tm7dcddM/+80LTY09BwJK59dlI73hOIybN1edQ/FS749vrkg6t+faqwn6wWhn2tWik6djT4Sy0+9uYgG+v6PuRTXMQxCeB+4KgiBwpRUBcTwruhgCtI7MblpCzvUAvrllKv0neYoUeaP4GMV+MRvOOOmHho4GJmT5hLVFQbotpZ86Axzb9HaDdN4l4WY/as2f6FglLGdotU03WM8bTbEaro6O96G8NKm5Iae/ruRHYTJanAvDKpZJtmonX5VndR+hAviXTK3nJZeFUL0gY1zmVYq7KbSz8uUEd9Avd2UhYilGIMLQYd8W20AB4HSAQOhz0wsdNtdaaYpv0nn2WI9dvnHRAZb/s9vIHnQKBjtFcgPI+PkLx3FFxZZG5RlgQOPGYT/QRMOxyh5D39CAEtZe x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230001)(366004)(2906002)(66946007)(76116006)(66476007)(66556008)(33656002)(64756008)(66446008)(71200400001)(8936002)(83380400001)(7696005)(38070700005)(6506007)(86362001)(8676002)(4326008)(38100700002)(52536014)(9686003)(55016003)(498600001)(186003)(26005)(82960400001)(5660300002)(53546011)(122000001)(110136005)(54906003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: SMrEdaWJc7LVguWF5Smo8RBGNlRUDCdlKphVJsAyrKicuav03CymVTkt1SPa8E2ZVtB3M19bQZssETx11kh6zWuWyojJq7dWlcml5JS9RyOZA312EisgxoIvCWZerQ1Bz7SMb9Bx5d1XexwN4bFRyg== Content-Type: multipart/alternative; boundary="_000_BN2P110MB11078D70177B4F36B6D2CAB4DC289BN2P110MB1107NAMP_" MIME-Version: 1.0 X-OriginatorOrg: cert.org X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 370e7e85-1877-49e2-1312-08d9e6bc63ad X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2022 02:25:04.9225 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 95a9dce2-04f2-4043-995d-1ec3861911c6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN2P110MB1621 Archived-At: Subject: Re: [dispatch] Secure Credential Transfer Charter & BoF X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2022 02:25:14 -0000 --_000_BN2P110MB11078D70177B4F36B6D2CAB4DC289BN2P110MB1107NAMP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkhDQoNCkZyb206IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT4NClNlbnQ6IFdlZG5lc2Rh eSwgRmVicnVhcnkgMiwgMjAyMiA4OjU4IFBNDQpUbzogSm9obiBDIEtsZW5zaW4gPGpvaG4taWV0 ZkBqY2suY29tPg0KQ2M6IE1hdHRoZXcgQnlpbmd0b24gPG1ieWluZ3RvbkBhcHBsZS5jb20+OyBE SVNQQVRDSCA8ZGlzcGF0Y2hAaWV0Zi5vcmc+OyBTZWN1cml0eSBBRHMgPHNlYy1hZHNAaWV0Zi5v cmc+OyBGcmFuY2VzY2EgUGFsb21iaW5pIDxmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNv bT4NClN1YmplY3Q6IFJlOiBbZGlzcGF0Y2hdIFNlY3VyZSBDcmVkZW50aWFsIFRyYW5zZmVyIENo YXJ0ZXIgJiBCb0YNCg0KDQoNCk9uIFdlZCwgRmViIDIsIDIwMjIgYXQgMzo1NCBQTSBKb2huIEMg S2xlbnNpbiA8am9obi1pZXRmQGpjay5jb208bWFpbHRvOmpvaG4taWV0ZkBqY2suY29tPj4gd3Jv dGU6DQoNCkkgc3RpbGwgdGhpbmsgdGhhdCBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gZGlzY3VzcyB0 aGlzIGZ1cnRoZXIgYXQNCnRoZSBCT0Ygc28gZXZlcnlvbmUgd2hvIG5lZWRzIGl0IGdldHMgYSBi ZXR0ZXIgdW5kZXJzdGFuZGluZyBvZg0Kd2hlcmUgdGhlIGlzc3VlcyBhbmQgYm91bmRhcmllcyBs aWUgYW5kIHRvLCBhdCBsZWFzdCwgZ2V0DQphZ3JlZW1lbnQgZnJvbSB0aGUgU0VDIEFEcyB0byBo ZWxwIEZyYW5jZXNjYSBrZWVwIGFuIGV5ZSBvbg0KZGV2ZWxvcG1lbnRzIG9mIGEgV0cgYW5kIGFu eSBkb2N1bWVudCBwcm9jZXNzaW5nLg0KDQpbUm9tYW5dIFdlIChTRUMgQURzKSBhcmUgaW4gbG9j ayBzdGVwIHdpdGggQVJUIChGcmFuY2VzY2EpIHRvIGVuc3VyZSB0aGF0IHRoaXMgd29yayBnZXRz IHRoZSBhcHByb3ByaWF0ZSBjb25zaWRlcmF0aW9uIGR1cmluZyB0aGlzIGZvcm1hdGl2ZSB0aW1l cywgYW5kIHNob3VsZCBpdCBlbmQgdXAgYXMgYSBXRy4gIFRoZSBCb0Ygd2lsbCBoZWxwIHVzIHRl YXNlIG91dCBhIG51bWJlciBvZiB0aGluZ3MsIHRvIGluY2x1ZGUgYW4gYXBwcm9wcmlhdGUgaG9t ZS4gIElmIGl0IGFkdmFuY2VzLCB3ZSBoYXZlIGV4cGVyaW1lbnRlZCB3aXRoIGRpZmZlcmVudCBs ZWFkZXJzaGlwIG1vZGVscyBmb3IgV0dzLiAgRm9yIGV4YW1wbGUsIGFtb25nIHRoZSByZWNlbnRs eSBjaGFydGVyZWQgV0dzLCB3ZSBoYXZlIHZhcmlvdXMgQUQgc3dhcHMgKGUuZy4sIE9IQUkgaW4g U0VDIGFyZWEgYnV0IHdpdGggYW4gQVJUIEFEOyBTQ0lNIGluIEFSVCBidXQgd2l0aCBhIFNFQyBB RCkuDQoNClJlZ2FyZHMsDQpSb21hbg0KDQoNCg0KdGhhbmtzLA0KICAgam9obg0KDQoNCi0tT24g V2VkbmVzZGF5LCBGZWJydWFyeSAyLCAyMDIyIDE0OjMyIC0wODAwIEVyaWMgUmVzY29ybGENCjxl a3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+IHdyb3RlOg0KDQo+IE9uIFdlZCwgRmVi IDIsIDIwMjIgYXQgMjoxNCBQTSBKb2huIEMgS2xlbnNpbg0KPiA8am9obi1pZXRmQGpjay5jb208 bWFpbHRvOmpvaG4taWV0ZkBqY2suY29tPj4gd3JvdGU6DQo+DQo+PiBNYXR0aGV3LA0KPj4NCj4+ IFRoYW5rcyBmb3IgdGhlIHJlc3BvbnNlLiAgRm9yIG1lLCBpdCBtYWtlcyBwZXJmZWN0bHkgZ29v ZA0KPj4gc2Vuc2UuIEFuZCwgaGF2aW5nIHBhcnRpY2lwYXRlZCBpbiB0aGUgRElTUEFUQ0ggZGlz Y3Vzc2lvbiwgSQ0KPj4gKGFuZCBwZXJoYXBzIG90aGVycykgZGlkbid0IGFkZXF1YXRlbHkgdW5k ZXJzdGFuZCBob3cgbXVjaA0KPj4gdGhlIHdvcmsgd291bGQgZGVwZW5kIG9uIGlzc3VlcyBhbmQg dG9waWNzIGluIHRoZSBTZWN1cml0eQ0KPj4gYXJlYS4uIG9yIHdlIHdlcmUgbm90IHBheWluZyBl bm91Z2ggYXR0ZW50aW9uLiAgSSBhbSBhY3R1YWxseQ0KPj4gc3VycHJpc2VkIHRoZSBxdWVzdGlv biB3YXMgbm90IHJhaXNlZCBieSBla3Igb3Igb25lIG9mIHRoZQ0KPj4gb3RoZXJzIHdobyBzcGVu ZHMNCj4+DQo+IG11Y2ggbW9yZSB0aW1lIG9uIHNlY3VyaXR5IGlzc3VlcyB0aGFuIEkgZG8uDQo+ Pg0KPg0KPiBIZWFyaW5nIG15IG5hbWUuLi4NCj4NCj4gVGhpcyBhY3R1YWxseSB3YXMgZGlzY3Vz c2VkIGF0IHRoZSBtZWV0aW5nIFswXS4gU2VlIHRoZSBlbmQNCj4gd2hlcmUgUmljaGFyZCBCYXJu ZXMgc2F5czoNCj4gImRvbid0IHRoaW5rIGl0IGJlbG9uZ3MgaW4gc2VjIC0gdGhlIGludGVyZXN0 aW5nIHF1ZXN0aW9ucw0KPiBhcmUgYXJvdW5kIHRoZSBicm9hZGVyIGFyY2hpdGVjdHVyZS4gVGhl IGRldGFpbHMgb2YgdGhlIGNyeXB0bw0KPiBuZWVkcyB0byBiZSBhcnJhbmdlZCBwcm9wZXJseSwg YnV0IHdlIGNhbiBicmluZyBpbiBleGVwZXJ0aXNlLg0KPiBUaGUgd29yayBiZWxvbmdzIGluIEFS VCBub3QgU0VDLiINCj4NCj4gSSByb3VnaGx5IGFncmVlIHdpdGggdGhpcy4gVGhlIGNyeXB0byBp cyBmYWlybHkNCj4gc3RyYWlnaHRmb3J3YXJkIGJ1dCB0aGUgYXJjaGl0ZWN0dXJlIGZvciBtb3Zp bmcgdGhlIGRhdGENCj4gYXJvdW5kIG5lZWRzIHNlcmlvdXMgY29uc2lkZXJhdGlvbi5JIGRvbid0 IHRoaW5rIGl0IHdvdWxkIGJlIGENCj4gZGlzYXN0ZXIgaW4gU0VDLCBidXQgYmFzZWQgb24gZXhw ZXJpZW5jZSB3aXRoLCBmb3IgaW5zdGFuY2UNCj4gQUNNRSwgaXQgd291bGQgbmVlZCBhIGxvdCBv ZiBhcHBzIGlucHV0IHRvIGF2b2lkIHNjcmV3aW5nIHRoYXQNCj4gc2lkZSB1cC4NCj4NCj4gLUVr cg0KDQo= --_000_BN2P110MB11078D70177B4F36B6D2CAB4DC289BN2P110MB1107NAMP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3Jh cDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IaSE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gRXJpYyBS ZXNjb3JsYSAmbHQ7ZWtyQHJ0Zm0uY29tJmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5 LCBGZWJydWFyeSAyLCAyMDIyIDg6NTggUE08YnI+DQo8Yj5Ubzo8L2I+IEpvaG4gQyBLbGVuc2lu ICZsdDtqb2huLWlldGZAamNrLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IE1hdHRoZXcgQnlpbmd0 b24gJmx0O21ieWluZ3RvbkBhcHBsZS5jb20mZ3Q7OyBESVNQQVRDSCAmbHQ7ZGlzcGF0Y2hAaWV0 Zi5vcmcmZ3Q7OyBTZWN1cml0eSBBRHMgJmx0O3NlYy1hZHNAaWV0Zi5vcmcmZ3Q7OyBGcmFuY2Vz Y2EgUGFsb21iaW5pICZsdDtmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNvbSZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtkaXNwYXRjaF0gU2VjdXJlIENyZWRlbnRpYWwgVHJhbnNm ZXIgQ2hhcnRlciAmYW1wOyBCb0Y8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBXZWQsIEZlYiAyLCAyMDIyIGF0IDM6NTQgUE0gSm9obiBDIEtsZW5z aW4gJmx0OzxhIGhyZWY9Im1haWx0bzpqb2huLWlldGZAamNrLmNvbSI+am9obi1pZXRmQGpjay5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBzdGlsbCB0aGluayB0aGF0IGl0IHdvdWxkIGJlIHVzZWZ1 bCB0byBkaXNjdXNzIHRoaXMgZnVydGhlciBhdDxicj4NCnRoZSBCT0Ygc28gZXZlcnlvbmUgd2hv IG5lZWRzIGl0IGdldHMgYSBiZXR0ZXIgdW5kZXJzdGFuZGluZyBvZjxicj4NCndoZXJlIHRoZSBp c3N1ZXMgYW5kIGJvdW5kYXJpZXMgbGllIGFuZCB0bywgYXQgbGVhc3QsIGdldDxicj4NCmFncmVl bWVudCBmcm9tIHRoZSBTRUMgQURzIHRvIGhlbHAgRnJhbmNlc2NhIGtlZXAgYW4gZXllIG9uPGJy Pg0KZGV2ZWxvcG1lbnRzIG9mIGEgV0cgYW5kIGFueSBkb2N1bWVudCBwcm9jZXNzaW5nLjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ W1JvbWFuXSBXZSAoU0VDIEFEcykgYXJlIGluIGxvY2sgc3RlcCB3aXRoIEFSVCAoRnJhbmNlc2Nh KSB0byBlbnN1cmUgdGhhdCB0aGlzIHdvcmsgZ2V0cyB0aGUgYXBwcm9wcmlhdGUgY29uc2lkZXJh dGlvbiBkdXJpbmcgdGhpcyBmb3JtYXRpdmUgdGltZXMsIGFuZCBzaG91bGQgaXQgZW5kIHVwIGFz IGEgV0cuJm5ic3A7IFRoZSBCb0Ygd2lsbCBoZWxwIHVzIHRlYXNlIG91dCBhIG51bWJlciBvZiB0 aGluZ3MsIHRvIGluY2x1ZGUNCiBhbiBhcHByb3ByaWF0ZSBob21lLiZuYnNwOyBJZiBpdCBhZHZh bmNlcywgd2UgaGF2ZSBleHBlcmltZW50ZWQgd2l0aCBkaWZmZXJlbnQgbGVhZGVyc2hpcCBtb2Rl bHMgZm9yIFdHcy4mbmJzcDsgRm9yIGV4YW1wbGUsIGFtb25nIHRoZSByZWNlbnRseSBjaGFydGVy ZWQgV0dzLCB3ZSBoYXZlIHZhcmlvdXMgQUQgc3dhcHMgKGUuZy4sIE9IQUkgaW4gU0VDIGFyZWEg YnV0IHdpdGggYW4gQVJUIEFEOyBTQ0lNIGluIEFSVCBidXQgd2l0aCBhIFNFQyBBRCkuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Sb21hbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KdGhh bmtzLDxicj4NCiZuYnNwOyAmbmJzcDtqb2huPGJyPg0KPGJyPg0KPGJyPg0KLS1PbiBXZWRuZXNk YXksIEZlYnJ1YXJ5IDIsIDIwMjIgMTQ6MzIgLTA4MDAgRXJpYyBSZXNjb3JsYTxicj4NCiZsdDs8 YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0Zm0uY29t PC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyBPbiBXZWQsIEZlYiAyLCAyMDIyIGF0IDI6 MTQgUE0gSm9obiBDIEtsZW5zaW48YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86am9obi1p ZXRmQGpjay5jb20iIHRhcmdldD0iX2JsYW5rIj5qb2huLWlldGZAamNrLmNvbTwvYT4mZ3Q7IHdy b3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyZndDsgTWF0dGhldyw8YnI+DQomZ3Q7Jmd0OyA8YnI+ DQomZ3Q7Jmd0OyBUaGFua3MgZm9yIHRoZSByZXNwb25zZS4mbmJzcDsgRm9yIG1lLCBpdCBtYWtl cyBwZXJmZWN0bHkgZ29vZDxicj4NCiZndDsmZ3Q7IHNlbnNlLiBBbmQsIGhhdmluZyBwYXJ0aWNp cGF0ZWQgaW4gdGhlIERJU1BBVENIIGRpc2N1c3Npb24sIEk8YnI+DQomZ3Q7Jmd0OyAoYW5kIHBl cmhhcHMgb3RoZXJzKSBkaWRuJ3QgYWRlcXVhdGVseSB1bmRlcnN0YW5kIGhvdyBtdWNoPGJyPg0K Jmd0OyZndDsgdGhlIHdvcmsgd291bGQgZGVwZW5kIG9uIGlzc3VlcyBhbmQgdG9waWNzIGluIHRo ZSBTZWN1cml0eTxicj4NCiZndDsmZ3Q7IGFyZWEuLiBvciB3ZSB3ZXJlIG5vdCBwYXlpbmcgZW5v dWdoIGF0dGVudGlvbi4mbmJzcDsgSSBhbSBhY3R1YWxseTxicj4NCiZndDsmZ3Q7IHN1cnByaXNl ZCB0aGUgcXVlc3Rpb24gd2FzIG5vdCByYWlzZWQgYnkgZWtyIG9yIG9uZSBvZiB0aGU8YnI+DQom Z3Q7Jmd0OyBvdGhlcnMgd2hvIHNwZW5kczxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsgbXVjaCBt b3JlIHRpbWUgb24gc2VjdXJpdHkgaXNzdWVzIHRoYW4gSSBkby48YnI+DQomZ3Q7Jmd0OyA8YnI+ DQomZ3Q7IDxicj4NCiZndDsgSGVhcmluZyBteSBuYW1lLi4uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IFRoaXMgYWN0dWFsbHkgd2FzIGRpc2N1c3NlZCBhdCB0aGUgbWVldGluZyBbMF0uIFNlZSB0aGUg ZW5kPGJyPg0KJmd0OyB3aGVyZSBSaWNoYXJkIEJhcm5lcyBzYXlzOjxicj4NCiZndDsgJnF1b3Q7 ZG9uJ3QgdGhpbmsgaXQgYmVsb25ncyBpbiBzZWMgLSB0aGUgaW50ZXJlc3RpbmcgcXVlc3Rpb25z PGJyPg0KJmd0OyBhcmUgYXJvdW5kIHRoZSBicm9hZGVyIGFyY2hpdGVjdHVyZS4gVGhlIGRldGFp bHMgb2YgdGhlIGNyeXB0bzxicj4NCiZndDsgbmVlZHMgdG8gYmUgYXJyYW5nZWQgcHJvcGVybHks IGJ1dCB3ZSBjYW4gYnJpbmcgaW4gZXhlcGVydGlzZS48YnI+DQomZ3Q7IFRoZSB3b3JrIGJlbG9u Z3MgaW4gQVJUIG5vdCBTRUMuJnF1b3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgcm91Z2hseSBh Z3JlZSB3aXRoIHRoaXMuIFRoZSBjcnlwdG8gaXMgZmFpcmx5PGJyPg0KJmd0OyBzdHJhaWdodGZv cndhcmQgYnV0IHRoZSBhcmNoaXRlY3R1cmUgZm9yIG1vdmluZyB0aGUgZGF0YTxicj4NCiZndDsg YXJvdW5kIG5lZWRzIHNlcmlvdXMgY29uc2lkZXJhdGlvbi5JIGRvbid0IHRoaW5rIGl0IHdvdWxk IGJlIGE8YnI+DQomZ3Q7IGRpc2FzdGVyIGluIFNFQywgYnV0IGJhc2VkIG9uIGV4cGVyaWVuY2Ug d2l0aCwgZm9yIGluc3RhbmNlPGJyPg0KJmd0OyBBQ01FLCBpdCB3b3VsZCBuZWVkIGEgbG90IG9m IGFwcHMgaW5wdXQgdG8gYXZvaWQgc2NyZXdpbmcgdGhhdDxicj4NCiZndDsgc2lkZSB1cC48YnI+ DQomZ3Q7IDxicj4NCiZndDsgLUVrcjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_BN2P110MB11078D70177B4F36B6D2CAB4DC289BN2P110MB1107NAMP_-- From nobody Wed Feb 2 20:44:35 2022 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 F21AA3A196F; Wed, 2 Feb 2022 20:44:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8GxTOCIpNTd; Wed, 2 Feb 2022 20:44:27 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 830353A1968; Wed, 2 Feb 2022 20:44:26 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nFTyk-000GmT-4C; Wed, 02 Feb 2022 23:44:18 -0500 Date: Wed, 02 Feb 2022 23:44:11 -0500 From: John C Klensin To: Roman Danyliw , Eric Rescorla cc: Matthew Byington , DISPATCH , Security ADs , Francesca Palombini Message-ID: <66FFFE879E3D7B5D39B13BF4@PSB> In-Reply-To: References: <2531793BFFD2289EC9ED5174@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [dispatch] Secure Credential Transfer Charter & BoF X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2022 04:44:33 -0000 Roman, Thanks _very_ much. That completely addresses my concerns. john --On Thursday, February 3, 2022 02:25 +0000 Roman Danyliw wrote: > Hi! > > From: Eric Rescorla > Sent: Wednesday, February 2, 2022 8:58 PM > To: John C Klensin > Cc: Matthew Byington ; DISPATCH > ; Security ADs ; > Francesca Palombini > Subject: Re: [dispatch] Secure Credential Transfer Charter & > BoF > > > > On Wed, Feb 2, 2022 at 3:54 PM John C Klensin > > wrote: > > I still think that it would be useful to discuss this further > at the BOF so everyone who needs it gets a better > understanding of where the issues and boundaries lie and to, > at least, get agreement from the SEC ADs to help Francesca > keep an eye on developments of a WG and any document > processing. > > [Roman] We (SEC ADs) are in lock step with ART (Francesca) to > ensure that this work gets the appropriate consideration > during this formative times, and should it end up as a WG. > The BoF will help us tease out a number of things, to include > an appropriate home. If it advances, we have experimented > with different leadership models for WGs. For example, among > the recently chartered WGs, we have various AD swaps (e.g., > OHAI in SEC area but with an ART AD; SCIM in ART but with a > SEC AD). > > Regards, > Roman > > > > thanks, > john > > > --On Wednesday, February 2, 2022 14:32 -0800 Eric Rescorla > > wrote: > >> On Wed, Feb 2, 2022 at 2:14 PM John C Klensin >> > wrote: >> >>> Matthew, >>> >>> Thanks for the response. For me, it makes perfectly good >>> sense. And, having participated in the DISPATCH discussion, I >>> (and perhaps others) didn't adequately understand how much >>> the work would depend on issues and topics in the Security >>> area.. or we were not paying enough attention. I am actually >>> surprised the question was not raised by ekr or one of the >>> others who spends >>> >> much more time on security issues than I do. >>> >> >> Hearing my name... >> >> This actually was discussed at the meeting [0]. See the end >> where Richard Barnes says: >> "don't think it belongs in sec - the interesting questions >> are around the broader architecture. The details of the crypto >> needs to be arranged properly, but we can bring in exepertise. >> The work belongs in ART not SEC." >> >> I roughly agree with this. The crypto is fairly >> straightforward but the architecture for moving the data >> around needs serious consideration.I don't think it would be a >> disaster in SEC, but based on experience with, for instance >> ACME, it would need a lot of apps input to avoid screwing that >> side up. >> >> -Ekr > From nobody Tue Feb 8 07:49:24 2022 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 DB1F43A12CE for ; Tue, 8 Feb 2022 07:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 yXXYvn1F3YCN for ; Tue, 8 Feb 2022 07:49:00 -0800 (PST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 B59C23A11C8 for ; Tue, 8 Feb 2022 07:48:42 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id 200so14028089qki.2 for ; Tue, 08 Feb 2022 07:48:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Vt4enJ+CZiY8/XuEjtSLiYQA4/v+J7yDocuEyQbxE9c=; b=E0cIAjTg6teCDLnY2rhh6uvI28ouMf7uEOYAIalUvXWKGbadjeSssdE8q5xDTDrATM 20ByhFjmijvaiaUPjlmbkjNhQytwbEcZ+yWrhxN/yhXY1neAmKzUmI7q0QxSReqrI0OV AP3PzvjrMxZdC+yC6pjgW1cQlvyG+EgZlQV34= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Vt4enJ+CZiY8/XuEjtSLiYQA4/v+J7yDocuEyQbxE9c=; b=MwKWAjpEQt9GJpMJK5MtkfFGUttAGL/3C18vhsOlp4f/SCwEi8oSrFBlGb/OJQhCGS N9ndrTOzw4n7qbYa4S2bSMKkGod1K9oA1a8CagfT3Kwc4S4SQ6NisXorFYV8ncQDkytG URDb1G14Q/ik+um3Pm0Il+TMp9QESzq/D5nC0EpcvTFB90GedFRrbd69s3aNYTmL1Hta zNWpvnsT2JTpYcnLt+7EHM3X24rdiUYnMQDI1LNQOq35QbAx5gxeTC3octJtpHUJasMq 6w4mvWXyVgHvaBqduW2NUHPB8kWnHI54qa3a8tOdfng5coAYPG43VJtX7HE6NZu0aT9U 1nBQ== X-Gm-Message-State: AOAM532LMTsxE8ZbVBPkl/SQKi0A+MzdLZ14YS9vvQN6U4IdDMW+O9Y9 BpZ6iIhgOo0zVZzwRGIOPF6vZ8jL9dWwmYah X-Google-Smtp-Source: ABdhPJwzrgmpnE//dqMPdQqKTulrrj++6GCihhpoi+gj09om2bv5z1PYVTsDFDfAqC5TtH5qSw0a3g== X-Received: by 2002:a05:620a:c96:: with SMTP id q22mr3000285qki.658.1644335320832; Tue, 08 Feb 2022 07:48:40 -0800 (PST) Received: from smtpclient.apple (pool-71-178-177-131.washdc.fios.verizon.net. [71.178.177.131]) by smtp.gmail.com with ESMTPSA id j15sm7596388qta.83.2022.02.08.07.48.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Feb 2022 07:48:40 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Sean Turner In-Reply-To: <164321863329.27385.6340387845625300575@ietfa.amsl.com> Date: Tue, 8 Feb 2022 10:48:39 -0500 Cc: dispatch@ietf.org, secdispatch@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <164321863329.27385.6340387845625300575@ietfa.amsl.com> To: secret@ietf.org X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [dispatch] Secure Credential Transfer (secret) BOF Virtual Meeting: 2022-02-10 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, 08 Feb 2022 15:49:16 -0000 Apologies for the multiple cross-posts. I have uploaded the slides for Thursday=E2=80=99s BOF. Cheers, spt > On Jan 26, 2022, at 12:37, IESG Secretary = wrote: >=20 > The Secure Credential Transfer (secret) BOF will hold a virtual = interim meeting on 2022-02-10 from 09:00 to 11:00 America/Los_Angeles = (17:00 to 19:00 UTC). >=20 > Agenda: >=20 > Intro > Use cases > Requirements > WG charter discussion: = https://github.com/dimmyvi/secure-credential-transfer/blob/main/charter.md= > Conclusion >=20 > Draft: = https://datatracker.ietf.org/doc/html/draft-secure-credential-transfer-03 >=20 > Information about remote participation: > = https://meetings.conf.meetecho.com/interim/?short=3Dd1a67502-8fe8-4fc2-bb9= b-f2e2f4594bb4 >=20 > The meeting will happen over Meetecho. To join the session, you will = need to use your IETF Datatracker (https://datatracker.ietf.org/) login, = which you should create ahead of time if you don't already have one. If = you have forgotten your IETF Datatracker password, you can request a = reset (https://datatracker.ietf.org/accounts/reset/). For more = information, see the Meetecho guide for participants = (https://www.ietf.org/how/meetings/technology/meetecho-guide-participant/)= . >=20 > BOF Request: = https://datatracker.ietf.org/doc/bofreq-secure-credential-transfer-bof-req= uest/ >=20 > Description: >=20 > We presented the secure credential draft to Dispatch on Monday of IETF = week (2021). There was a lot of interest, but folks asked for additional = detail on the problem statement, requirements, and use cases. It was = decided that we weren=E2=80=99t ready to form a WG right away and = instead endeavored to schedule a BoF to review the above items prior to = forming a WG. The goal is to allow users with secure credentials on = their mobile devices to be able to shares entitlements that these = credentials grant to other users. This would be achieved by defining and = standardizing a protocol that will facilitate such credential transfers = from individual to individual. The protocol will leverage a =E2=80=9Crelay= server=E2=80=9D to transfer data from sender to recipient. The scope of = the transfer is limited to a single origin device and a single = destination device. This system does not exist today in a = standards-based, cross-platform and cross-channel capacity. The goal of = this BoF is to answer some of the questions that came up during the = Dispatch meeting (such as, why can=E2=80=99t these credentials simply be = lifted and cloned and then sent to the recipient?). We also want to = provide additional detail into the applicable use cases, and some of the = security and privacy requirements for the solution. The ultimate goal is = to form a WG to discuss the initiative in an ongoing capacity. >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From nobody Thu Feb 10 09:14:07 2022 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 BFBFE3A0E37; Thu, 10 Feb 2022 09:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.677 X-Spam-Level: X-Spam-Status: No, score=-7.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoKZCtvPskFD; Thu, 10 Feb 2022 09:13:25 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40063.outbound.protection.outlook.com [40.107.4.63]) (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 603C33A0F42; Thu, 10 Feb 2022 09:13:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g89yVsMF1T8pgG6eahHsO0bevGFyQcsiMWSyrDRBwJtsTNBaFzT1ku75eJUdY0UNSySLkIxQokw82rEQZN1mRhGquA+uIvdqAKBPvvwWhmro482BiNIqPZNqO99+O4FhfM+8lxtrdrNrMHM8f9iZg3Sdh/enJBUhW58OtuLVisRYUYdybs2lgMS5GSJBNoPQMtj3erWsgIyC5pz2if0j1Z5Zc4GFh4y7ADrYbO8CCLIlaQtrb5+FhyH7BiomOnv72GF+GqGwJBZ/YRCZ+BYE+ov9XlQb+gb9O1cYGlgk4qFyBfk4M5MqBrdvHRo+i7jXobu7JvLVHMelmqCarMX6yg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Ow8RHGbSChg0A7qhwQeRfYlsYMugvoOcQ9DvYJf4vLY=; b=XqyJaaUxnjLTeQzGoBQAQpu1dFQCk/FgQ0AB2kiLNV+/LWxHrSd0NDCgSVBrqKeoeIb0ffZdvrIIFAd0ZFXL+zwtMKKaK7s+xwMDxC2olcBGjch7T3lrfl9QCU9yAlxjH4DfGkerTu9K935BXGxZ8Oa/KLUgJh6c6nucMqdLIAmPpq0W0sxmlfZyNqPYcs6lDzsrKYZe6joIn+iNLq6mnln/wKCiilGPiRdtb6yrQz3FXtMQhC9RjiPYtZFRkvJQid+yjdo0ckizazw4xr8XxokZ/1kKQKt/mCLOszkXBeRypUH4OzdZ1bBaL5X9zP39B3kLxkE+NjFoKhlCxLqPCQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ow8RHGbSChg0A7qhwQeRfYlsYMugvoOcQ9DvYJf4vLY=; b=E8cArHBWHBMAnDnSi1nsTOVy53OL8Uvhk8qkYZKZHfyPsGR5WdA/N1JbY5Qw1mXRFkl88vOS1JzkQ+mq1Kd+54v36uzYE74+ngcgoqteCQCar/hjZl3wzvS9fQEa7jwEUl4Uj/X0oniBm9qNA6WEYfwN92603o2LSxbP9ezFNDs= Received: from HE1PR07MB4217.eurprd07.prod.outlook.com (2603:10a6:7:96::33) by DB7PR07MB6012.eurprd07.prod.outlook.com (2603:10a6:10:37::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4975.10; Thu, 10 Feb 2022 17:12:52 +0000 Received: from HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::b1e2:6c17:3ba8:9fdc]) by HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::b1e2:6c17:3ba8:9fdc%5]) with mapi id 15.20.4995.006; Thu, 10 Feb 2022 17:12:52 +0000 From: Francesca Palombini To: "dispatch@ietf.org" , "saag@ietf.org" , "secdispatch@ietf.org" Thread-Topic: [Secret] Secure Credential Transfer (secret) BOF Virtual Meeting: 2022-02-10 Thread-Index: AQHYEttrGDmcw5z0QkCuZIEBWQK9xayNHCMw Date: Thu, 10 Feb 2022 17:12:52 +0000 Message-ID: References: <164321863329.27385.6340387845625300575@ietfa.amsl.com> In-Reply-To: <164321863329.27385.6340387845625300575@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0b0aadd1-bb1d-46c0-1e05-08d9ecb89289 x-ms-traffictypediagnostic: DB7PR07MB6012:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: AddXQz/Y2DgU7Rwem8bQN10kACajmyqBxfDGcpErUb0yu7vR28lKYpb+mg3Ms16VZWHCjjb4cFutxOdqYyjR19lV82cJ9y1fCw1FbsGMk3/tLA17hK+Ser2AELZwWDxF636DO38XhDdlJL1P/uUGXs4b3mZTJ6Yx2y8EhpWihxKnxCkrYZipT9aFD1M6BtGlfkIRyRLY+Jji1jQ4ma6amt0/yiDMTck+YVYhBvoCAdFoi38bLjDGFjGtYxhspVj7vi80ksbySiknvj0TQVs7M7Go4yr1UKdHVxcLQD6aQ57I8cMP1Z5dSN09LfdITxNDPJoulBFCoQOj6BmEPRoMhhzHUrK19WMRDlM1Bs/eYDn51nz2e883L24VxAfDijKFy/CRejap1kf+5I+sr4S9Y97YkSSOoXNC08eyAZDX/P14yWQkl8mRX7U9aO35eHuug8nQKEOHlDz++Tw88aSrrmy5JCQilhsMwm3E/i2HEhptSX0L+ZQszRAhmDUDaLEVizvqBMqzM/S/1/f0QLh/Z/FXWvX/YOTIb2wkI7KOAsoDeSoKcv2yit/adRMUbAEqt9GvqjqnWSQHn8mwC/G50GJcDVOz12nOj8j6ILrHO7N/KGGM54QkLRVPu5/0HIgt+doG1L/Vkj8wMe7U8juorZSaosFQjLFX2hHmG3dL9J+dTXaZ6BYouWiZhFfMnVUf9LNpjb8/t66Oh/dhoEJY6YoJDbYpKdjWrmcjGu/XRarZ8CBQqUON3QNXBCDBQYIwm2yyZPFYwcEgQZEI9fQah1u19YlnotiikDeYTRnbm+MSHt4mUr2O+gNdrmfuaS/5LDq9QNDbKxU3TIXqz6FL/bzjl2/hPT04z8RGMqPUyj8= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4217.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(55016003)(38070700005)(966005)(186003)(5660300002)(122000001)(82960400001)(110136005)(316002)(53546011)(450100002)(71200400001)(33656002)(83380400001)(2906002)(166002)(38100700002)(64756008)(76116006)(8676002)(8936002)(86362001)(508600001)(66946007)(6506007)(52536014)(7696005)(44832011)(9686003)(66556008)(66446008)(66476007)(91956017)(219293001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 2 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?zcOBpsUOrgbDYxX0YmOu7kvVn1Il8ys/qtVHpAb8SFELiSU4lGHjlPYL?= =?Windows-1252?Q?WAREgndYKV6iG5A4GJPbVciIBFZ7Th6fhS29rdf9hDTGmCAS3jm2ck2a?= =?Windows-1252?Q?TQwsfR/J++poCmKXdnsAyAvX6NK+eO5SC+q3aGHjw7xSVFbZRQJN6kJp?= =?Windows-1252?Q?9aTOtrucsfp6r9ohwZ5xFH9SoY24DRB54r/zUicbiPA+V9LqBisl5CVr?= =?Windows-1252?Q?xhbbDy4xgKzK5oJbWCUiyAGultsMQ86MFNj8tph4EzLHTtmIiO8U/JnE?= =?Windows-1252?Q?61hq3B7A5QVhX9l2Q7GLfEgUYM4cdw3lrqy72PoVyVh1s+ZQ1Fd+5OZM?= =?Windows-1252?Q?vMGqEGbnYBMdSGVdfD/71+LaM99BOUudxI9kGf6oeyM0CCLAEhnAtoKf?= =?Windows-1252?Q?wWFpDjqhSUPxmBHiPW0hXP4oixyhZM8znJYaVqEUO9PTIRl+iuF08skk?= =?Windows-1252?Q?uveay9H43kbgw4hwitMnlec6Y4Qny9Qj6MyJgysZa2i3tuX9/RHtl4Hw?= =?Windows-1252?Q?0hsOlfPClby2wxaW9OnmxuAWX8CIzJ52Q8vBWBh9KQS69ahr25MMFJLc?= =?Windows-1252?Q?FIwHaLLg0GI87QzSxvTRh8mgD/dGOa4TqtNSudoHLqJd28Hgb/Bk7cTK?= =?Windows-1252?Q?AKN8aS1wPkGZ96FRc9O19Yve4rpx4s4tw41DoQdhTLFH+9rMl2YKOy8o?= =?Windows-1252?Q?OPFaLRc1TWfTixlv0IYP6rZ/nVze6KDSbYN5PA0HRt7muHGFmLa2Y39D?= =?Windows-1252?Q?Gf4tSBMylw3B5tpXGHuEFARc+DUL0j6Uijee/GJLXTogtTFbITrynSZh?= =?Windows-1252?Q?HD5EB08Wcr4jzkSMewmzpBWbWOJvGEcHMtLOqFlpT+OvlQHi5h6JlHii?= =?Windows-1252?Q?68qSxPnaMgjYeXD78FaEx7NI3cTzruD9Q9AFBspHV9ZLAkq2QgkLBMyl?= =?Windows-1252?Q?HUCtEck1Six0uq8yn78YNgvnMylvzGJBiWbxc/MHFN4dDUdKAB87GBpf?= =?Windows-1252?Q?40lYQScgPc5bScvX3oE5JTtFz9kp6VLzTdejpmyuFwKQjLR3lQ/Oyxt2?= =?Windows-1252?Q?YqP2ORdgfC6l47i0ZXP30o0LSXNDg6wbiKJnNtYWSh/O9u8zT3uxxKPZ?= =?Windows-1252?Q?TV23Wa7tJN/v4U1qNlrpjSVwTNMkyR2Sjc99MFDnFmPysFhz7PpaMgsv?= =?Windows-1252?Q?ewSIbnGdMUQCE9QK55Zec5EzuoqZFWdxCAjk9gpuB/uKCEKvlMY2U5q/?= =?Windows-1252?Q?mEll/v9pmGG1Vr8pG6r+jaOYiiseaIr656hn78wIcYNIjUwnfbbN6UiD?= =?Windows-1252?Q?zF+DwNzA2L9YXhMMy1iWToloyEL6xcu7+CD0vpoYOQSa68Rp9+u1pvZg?= =?Windows-1252?Q?ACgmGtODBwKhsRAq1yk1ZeKaeNFy/oXk5cfE/usCi8A753we59Ly9F04?= =?Windows-1252?Q?lurBs3y4pn8WehKnFdccj2cekzjSLUjbEL6RU+rMJU/B03uBGw0WCks6?= =?Windows-1252?Q?uQCBpUWD10X7f2QRUb0ztXXpMjCMLOvC9OO3Hnr6BuYX0wkXtpyw7lKc?= =?Windows-1252?Q?h7o2GJ6WfpBO+xNHbQMWTFcMrOx5jKAIamSmOqS2JnMl7eb+SmMVF2pm?= =?Windows-1252?Q?bDuMoh5Vyc7eCye9J20Wndzpy0OvIak/+U312Ny6BZpqLU2Av+skipgX?= =?Windows-1252?Q?m0NwY+scYlWyEBHL+64A/QW/0IdUxiuLwCGcMcrMprbf0Wz1AZkbjjRo?= =?Windows-1252?Q?Q3yxzKOi0dRsLFiVqQd/agwQIfZt1z2vh/v+1vPBkMru5WUyQ6mImgFJ?= =?Windows-1252?Q?UJqB8hWhgDOkwu24PMXH/O0622c0Gp89mkispXTkoIgGn3pgRNaDB4LF?= =?Windows-1252?Q?itwNU/Pn+PYmcpKS1F0zdP8bYiNrzDqov8UsWykNTNUJPuzAbyNmoxH5?= =?Windows-1252?Q?FencpW+A?= x-ms-exchange-antispam-messagedata-1: Uumxkk9gMlZv2xSmsQD0CveSZS3tAmrSLmw= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB421725F4BC460ED0873AF5FA982F9HE1PR07MB4217eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4217.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0b0aadd1-bb1d-46c0-1e05-08d9ecb89289 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2022 17:12:52.5139 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Da0xs91QgzV622T0GpTbrmKgLQLqh4PFvzmTA2MdPNVoMk0rP0gkObhpsyDzoQ8mUFGOj9GOF9Kb19lWd55pBfEoB0BdkTYInbNcB4KPo/CNvRt2NQSuo22chjOR7cF9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB6012 Archived-At: Subject: Re: [dispatch] [Secret] Secure Credential Transfer (secret) BOF Virtual Meeting: 2022-02-10 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2022 17:13:30 -0000 --_000_HE1PR07MB421725F4BC460ED0873AF5FA982F9HE1PR07MB4217eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable FYI, happening now. Francesca From: Secret on behalf of IESG Secretary Date: Wednesday, 26 January 2022 at 18:37 To: IETF-Announce Cc: secret@ietf.org Subject: [Secret] Secure Credential Transfer (secret) BOF Virtual Meeting: = 2022-02-10 The Secure Credential Transfer (secret) BOF will hold a virtual interim mee= ting on 2022-02-10 from 09:00 to 11:00 America/Los_Angeles (17:00 to 19:00 = UTC). Agenda: Intro Use cases Requirements WG charter discussion: https://github.com/dimmyvi/secure-credential-tra= nsfer/blob/main/charter.md Conclusion Draft: https://datatracker.ietf.org/doc/html/draft-secure-credential-transf= er-03 Information about remote participation: https://ws.conf.meetecho.com/conference/?short=3Dd1a67502-8fe8-4fc2-bb9b-f2= e2f4594bb4 The meeting will happen over Meetecho. To join the session, you will need t= o use your IETF Datatracker (https://datatracker.ietf.org/) login, which yo= u should create ahead of time if you don't already have one. If you have fo= rgotten your IETF Datatracker password, you can request a reset (https://da= tatracker.ietf.org/accounts/reset/). For more information, see the Meetecho= guide for participants (https://www.ietf.org/how/meetings/technology/meete= cho-guide-participant/). BOF Request: https://datatracker.ietf.org/doc/bofreq-secure-credential-tran= sfer-bof-request/ Description: We presented the secure credential draft to Dispatch on Monday of IETF week= (2021). There was a lot of interest, but folks asked for additional detail= on the problem statement, requirements, and use cases. It was decided that= we weren=92t ready to form a WG right away and instead endeavored to sched= ule a BoF to review the above items prior to forming a WG. The goal is to a= llow users with secure credentials on their mobile devices to be able to sh= ares entitlements that these credentials grant to other users. This would b= e achieved by defining and standardizing a protocol that will facilitate su= ch credential transfers from individual to individual. The protocol will le= verage a =93relay server=94 to transfer data from sender to recipient. The = scope of the transfer is limited to a single origin device and a single des= tination device. This system does not exist today in a standards-based, cro= ss-platform and cross-channel capacity. The goal of this BoF is to answer s= ome of the questions that came up during the Dispatch meeting (such as, why= can=92t these credentials simply be lifted and cloned and then sent to the= recipient?). We also want to provide additional detail into the applicable= use cases, and some of the security and privacy requirements for the solut= ion. The ultimate goal is to form a WG to discuss the initiative in an ongo= ing capacity. -- Secret mailing list Secret@ietf.org https://www.ietf.org/mailman/listinfo/secret --_000_HE1PR07MB421725F4BC460ED0873AF5FA982F9HE1PR07MB4217eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

FYI, happ= ening now.

&nbs= p;

Francesca=

&nbs= p;

From: Secret <secret-bounces@ietf.org> o= n behalf of IESG Secretary <iesg-secretary@ietf.org>
Date: Wednesday, 26 January 2022 at 18:37
To: IETF-Announce <ietf-announce@ietf.org>
Cc: secret@ietf.org <secret@ietf.org>
Subject: [Secret] Secure Credential Transfer (secret) BOF Virtual Me= eting: 2022-02-10

The Secure Credential T= ransfer (secret) BOF will hold a virtual interim meeting on 2022-02-10 from= 09:00 to 11:00 America/Los_Angeles (17:00 to 19:00 UTC).

Agenda:

    Intro
    Use cases
    Requirements
    WG charter discussion: https://github.com/dimmyvi/secure-credential-transfer/blob/main/charter.md<= /a>
    Conclusion

Draft:
https://datatracker.ietf.org/doc/html/draft-secure-credential-transfer-03

Information about remote participation:
https://ws.conf.meetecho.com/conference/?short=3Dd1a= 67502-8fe8-4fc2-bb9b-f2e2f4594bb4

The meeting will happen over Meetecho. To join the session, you will need t= o use your IETF Datatracker (http= s://datatracker.ietf.org/) login, which you should create ahead of time= if you don't already have one. If you have forgotten your IETF Datatracker password, you can request a reset= (https://datatrac= ker.ietf.org/accounts/reset/). For more information, see the Meetecho g= uide for participants (https://www.ietf.org/how/meetings/technolo= gy/meetecho-guide-participant/).

BOF Request: https://datatracker.ietf.org/doc/bofreq-secure-credential-transfer-bof-requ= est/

Description:

We presented the secure credential draft to Dispatch on Monday of IETF week= (2021). There was a lot of interest, but folks asked for additional detail= on the problem statement, requirements, and use cases. It was decided that= we weren=92t ready to form a WG right away and instead endeavored to schedule a BoF to review the above items pr= ior to forming a WG. The goal is to allow users with secure credentials on = their mobile devices to be able to shares entitlements that these credentia= ls grant to other users. This would be achieved by defining and standardizing a protocol that will facilitate = such credential transfers from individual to individual. The protocol will = leverage a =93relay server=94 to transfer data from sender to recipient. Th= e scope of the transfer is limited to a single origin device and a single destination device. This system does n= ot exist today in a standards-based, cross-platform and cross-channel capac= ity. The goal of this BoF is to answer some of the questions that came up d= uring the Dispatch meeting (such as, why can=92t these credentials simply be lifted and cloned and then sen= t to the recipient?). We also want to provide additional detail into the ap= plicable use cases, and some of the security and privacy requirements for t= he solution. The ultimate goal is to form a WG to discuss the initiative in an ongoing capacity.

--
Secret mailing list
Secret@ietf.org
https://www.ietf.o= rg/mailman/listinfo/secret

--_000_HE1PR07MB421725F4BC460ED0873AF5FA982F9HE1PR07MB4217eurp_-- From nobody Tue Feb 15 07:17:54 2022 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 8BEE03A0D53; Tue, 15 Feb 2022 07:17:51 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFB6J1OfHPQI; Tue, 15 Feb 2022 07:17:47 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAE3C3A0CEB; Tue, 15 Feb 2022 07:17:46 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id s1so719172ioe.0; Tue, 15 Feb 2022 07:17:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=bP2+AcgNONYyqP+9rWobCaqPt6zPu6GcQdsAMbNXUXQ=; b=ThjrDNpArseP+sGHs59FDdK5uLqfzW7suzMdk1I5pOWr+hKVIh1PdtFLwPT1fTcF6C 2GQ/NXBEB2qrioCTz0tqNrcvtVw1dvdAg7EhocnhhKmpomzVWYpGPPR+lZ8ICChBfJGp Dg8/yIr8GDsxSJx9qMg9LECXdM3EbaWlL+mdtPQ4JVgDRcBk1P39xoYh/+FnjFWGHGaq tc36MqE+YVkbzxlAL4mn2gw3yxX3d0L09zFaKGbgfig3hUjrgCd1egTXOX3i/202krTs Jzy8V9S/O9kXDJMK7SEswDaoTgd5IVTJO79eIcN2Bha0+ps+lrWgBrRzGdtXDCH3GSwn pESw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=bP2+AcgNONYyqP+9rWobCaqPt6zPu6GcQdsAMbNXUXQ=; b=wUbvit249E6vHhkAwiQ7GPzd8NLqGDNTg1IrduiQRlp+DVeGKNM9biAwbffh4NzQ0T nR7piU6H1hSdjYfCCWJlT2vvbTNQXgf0pulUgDxowtUIpHTx3HkKinf1vJw3qErL34Mx 9um3WlfiOEEmqucCKbBXFG+Wzgt5YOkm9eriuwPqhG9aOMmh1XTxLfK/5eiGo7lqLcUg PD7TuAJMP5Av0khAwFaqEnCns4xS37nGCOHhZJYamlIwQrBXs54Z7SejyR0RHmy/OjhY trtVDZmUYUz+/ntZ0KlujfIRdBNdNl0yHaXTyYwDmbhdIx5e//GUoYA8TMZDO7jsQwH6 Pfgw== X-Gm-Message-State: AOAM531LjLNvOE8yNsoyz24xCvYKgJZvP5xQlvPYH0hH7LNluPryxbBN ktCiyRSNki9JrzTNOt/kMgbLuMFJP0jgnFY+LMy63kWf X-Google-Smtp-Source: ABdhPJwEctZR5gnEojIo9mVYr8pYGWKz/GLU0kidRqo8kWLS64klvTvqfsQjZA8ZcEwAnBh5dmFV5I3HOYLXv11cJn0= X-Received: by 2002:a05:6638:a8d:: with SMTP id 13mr3137487jas.104.1644938265540; Tue, 15 Feb 2022 07:17:45 -0800 (PST) MIME-Version: 1.0 From: Kirsty Paine Date: Tue, 15 Feb 2022 15:17:34 +0000 Message-ID: To: dispatch@ietf.org Cc: dispatch chairs Content-Type: multipart/alternative; boundary="000000000000feb88c05d8100842" Archived-At: Subject: [dispatch] IETF 113 - do you have something for 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: Tue, 15 Feb 2022 15:17:52 -0000 --000000000000feb88c05d8100842 Content-Type: text/plain; charset="UTF-8" Hi everyone, It's that time again - we're calling for agenda topics for our next meeting at IETF 113 (21-25 March). No matter how big or small, if you have something you'd like dispatching or that you think will be of interest to the ART AREA, get in touch and get involved. If that's you, and you would like time at the meeting to discuss your work or ideas, please email Patrick and me on the dispatch chairs email (CC'd). We're keen to hear from you! And if you're not really sure what this dispatching thing is for, or if you have any questions about bringing new work, please get in touch with us all the same - we're here to help. We look forward to hearing from you. Kirsty --000000000000feb88c05d8100842 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

It's that time again - we're calling for agenda topics for our next=
 meeting at IETF 113 (21-25 March). No matter how big or small, if you have=
 something you'd like dispatching or that you think will be of interest=
 to the ART AREA, get in touch and get involved.

If that's you, and you would like time at the meeting to discuss your w=
ork or ideas, please email Patrick and me on the dispatch chairs email (CC&=
#39;d). We're keen to hear from you!

And if you're not really sure what this dispatching thing is for, or if=
 you have any questions about bringing new work, please get in touch with u=
s all the same - we're here to help.

We look forward to hearing from you.

Kirsty

--000000000000feb88c05d8100842-- From nobody Thu Feb 17 09:32:22 2022 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 40AC13A0D8B; Thu, 17 Feb 2022 09:32:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.45.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dispatch@ietf.org Message-ID: <164511912112.2065.15524627126448810237@ietfa.amsl.com> Date: Thu, 17 Feb 2022 09:32:01 -0800 Archived-At: Subject: [dispatch] I-D Action: draft-ietf-dispatch-javascript-mjs-15.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2022 17:32:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dispatch WG of the IETF. Title : ECMAScript Media Types Updates Authors : Matthew A. Miller Myles Borins Mathias Bynens Bradley Farias Filename : draft-ietf-dispatch-javascript-mjs-15.txt Pages : 16 Date : 2022-02-17 Abstract: This document describes the registration of media types for the ECMAScript and JavaScript programming languages and conformance requirements for implementations of these types. This document obsoletes RFC4329, "Scripting Media Types", replacing the previous registrations for "text/javascript" and "application/javascript" with information and requirements aligned with common usage and implementation experiences. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-dispatch-javascript-mjs-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dispatch-javascript-mjs-15 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Thu Feb 17 09:40:14 2022 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 B65433A0D9B for ; Thu, 17 Feb 2022 09:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.099 X-Spam-Level: X-Spam-Status: No, score=-17.099 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, 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 vNiMRvWifNpF for ; Thu, 17 Feb 2022 09:40:09 -0800 (PST) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 6F18E3A0DA5 for ; Thu, 17 Feb 2022 09:40:09 -0800 (PST) Received: by mail-pf1-x436.google.com with SMTP id p8so268721pfh.8 for ; Thu, 17 Feb 2022 09:40:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9igbudzTJ40itDknCAbsnBgi7YC7voI6f3pDkk3SQJ0=; b=Wz3Xshxa77CSKyndQlim9mMAF8WJlGluJbiq2/h4zfRf4m6zQJzKuLuXcK+V8Yff+i BgHlgEVcc1UkTwT3fwW/QYksNGtOsSqnT0NLI5eF3NtdQHYzkzbLBUCVIgbZLcJ5N9CR /WSsWaRuRf/fQE+pxDFD3hWSsEFsvK0mzXL4vy3q1x5XDdnUyBC2w4dyxP+ogPgelJsV ZHHwOBdbnCRXKRcbwgHX47v9amtwH9eYDsUW5mQ8SkdGqUFPkkq+YNLh/NNGbdIIPqZk pTrwUOF0c29gXz8ocE2c45nnPL69gLq5FDkwoE8/98+r5/m03bV0vFV4Bv9PiFjjioMI oZGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9igbudzTJ40itDknCAbsnBgi7YC7voI6f3pDkk3SQJ0=; b=42pdsCPyXqRmOohMH8xQBBf/90VmOnCBD0JNwTTRxCSv/HX0oXOhmzah0sjf5XlKTB X8JjZvc6TfQFY8jnK0sh32zzgBRsFtsWUOQ+VKa6XkxGSA9rd2B3grknwQFmrzLc5Gi7 nK+UjHDjXFp3AOFm6yarPVowGwXeUNF9bfD8Crc+mSPr6XXQtsVkHluVXLwnclaxDXoJ sVyMfFGYEU/v0Yy8/63TFvMgPR0ebaQkBcbn/u+sOL9f78iOGx8/qyFKCBGfIx9qU47T k+Ohr3RbFN2yMu/Lw6wg+H9hpE+ESdoEULw2+pY6x/P5R+0Q8aYn5XjE7YP0Xa6VejOq 2gpQ== X-Gm-Message-State: AOAM5339uKI8jfLw8Bxs7o+CaxdtEwz2kWZabTkYYT7AK13nn6+u9WWb YIAKaX+q/PnJEkdDtdrt7599RFdqmQy6vcsIm2Ib0EiAce0beQ== X-Google-Smtp-Source: ABdhPJwW+Ly5FXNYo27/819+IkrsBdpZdXqTPuNe2hdxASGQ4/DQGxpHnc0gcQzKEPjK/oIejVPy1nw4yO8QsVWlTUU= X-Received: by 2002:a05:6a00:234a:b0:4e0:f776:876b with SMTP id j10-20020a056a00234a00b004e0f776876bmr4177636pfj.84.1645119607679; Thu, 17 Feb 2022 09:40:07 -0800 (PST) MIME-Version: 1.0 References: <164511912112.2065.15524627126448810237@ietfa.amsl.com> In-Reply-To: <164511912112.2065.15524627126448810237@ietfa.amsl.com> From: Mathias Bynens Date: Thu, 17 Feb 2022 18:39:56 +0100 Message-ID: To: DISPATCH WG Cc: i-d-announce@ietf.org, Francesca Palombini Content-Type: multipart/alternative; boundary="000000000000d491e905d83a416d" Archived-At: Subject: Re: [dispatch] I-D Action: draft-ietf-dispatch-javascript-mjs-15.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2022 17:40:12 -0000 --000000000000d491e905d83a416d Content-Type: text/plain; charset="UTF-8" Special thanks to Murray S. Kucherawy, who helped us address the last-minute feedback that came up. Much appreciated! On Thu, Feb 17, 2022 at 6:34 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Dispatch WG of the IETF. > > Title : ECMAScript Media Types Updates > Authors : Matthew A. Miller > Myles Borins > Mathias Bynens > Bradley Farias > Filename : draft-ietf-dispatch-javascript-mjs-15.txt > Pages : 16 > Date : 2022-02-17 > > Abstract: > This document describes the registration of media types for the > ECMAScript and JavaScript programming languages and conformance > requirements for implementations of these types. This document > obsoletes RFC4329, "Scripting Media Types", replacing the previous > registrations for "text/javascript" and "application/javascript" with > information and requirements aligned with common usage and > implementation experiences. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-dispatch-javascript-mjs-15 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dispatch-javascript-mjs-15 > > > Internet-Drafts are also available by rsync at rsync.ietf.org: > :internet-drafts > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --000000000000d491e905d83a416d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Special thanks to Murray S. Kucherawy, who helped us addre= ss the last-minute feedback that came up. Much appreciated!

On Thu, Feb = 17, 2022 at 6:34 PM <interne= t-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Dispatch WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= ECMAScript Media Types Updates
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Matt= hew A. Miller
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Myles Borins
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Mathias Bynens
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Bradley Farias
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dispatch-javascript-mjs-15.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 16
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2022-02-17

Abstract:
=C2=A0 =C2=A0This document describes the registration of media types for th= e
=C2=A0 =C2=A0ECMAScript and JavaScript programming languages and conformanc= e
=C2=A0 =C2=A0requirements for implementations of these types.=C2=A0 This do= cument
=C2=A0 =C2=A0obsoletes RFC4329, "Scripting Media Types", replacin= g the previous
=C2=A0 =C2=A0registrations for "text/javascript" and "applic= ation/javascript" with
=C2=A0 =C2=A0information and requirements aligned with common usage and
=C2=A0 =C2=A0implementation experiences.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc= /draft-ietf-dispatch-javascript-mjs/

There is also an htmlized version available at:
https://datatracker.ietf.= org/doc/html/draft-ietf-dispatch-javascript-mjs-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdif= f?url2=3Ddraft-ietf-dispatch-javascript-mjs-15


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-dra= fts


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--000000000000d491e905d83a416d-- From nobody Thu Feb 17 11:58:58 2022 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 424603A1105; Thu, 17 Feb 2022 11:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.714, 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 al5J6LGkY3g5; Thu, 17 Feb 2022 11:58:53 -0800 (PST) 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 7C5A13A1102; Thu, 17 Feb 2022 11:58:53 -0800 (PST) Received: by mail-pf1-x435.google.com with SMTP id p8so568687pfh.8; Thu, 17 Feb 2022 11:58:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=yYBKpN2umxcjlF0Rv7h52d4Hh4wW77nEvm9FrGjyTok=; b=pM5/NJeO34LQDy56OU2SvDU/nJQHgx/Iv+u+5y5VSF+zcTiLa5jfjhFMbvvgyOkgEY qajP50PP3lXC5IEvZ0482bCmX/2iF0X1DJ05wAz2qlBx9fTuCfFDOltdeNe1eW1Nl4kt 7Ygn0yFQM+xd6tM4eQRkPflhrrEKFnZ0jMOcyX7oy5lKnNZCwmcp3v4SszhqwNj3uAhU T/OfUyDv91b/Nd4VSl2p9nrp7x8bgm/tL41abLT/ICdKq2FihK9JhfTFYtPrSjl/lbV9 Jp627W+1dbcujaIJykMwN4zuJPTg9USTCGjuyfYeuGGVJl8eu0PokKS4XwCHw8g//TCA +Wug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=yYBKpN2umxcjlF0Rv7h52d4Hh4wW77nEvm9FrGjyTok=; b=BFuHl4NgCz7NZv9AhcaxxF5P424mTyy7IoYu9Yek/Krn94wnr/Li32ryA1WiN9qWXb BX0o0m40hpjUFAgJDoHJuO5DabZAEYOtjcQsMV5LCTMX6E2lZ1BDHXERLhyq1p+JohNd 5/n+J2WmAV8KzxGjRS9teowqeoXMM1I2ERqiTfVj3GHsvteP5G1V6aGO3w5P01bZIcrG 0dRDt3C4sqw9m9+TCX9iM66HXFZiVlXtMQA2Aa4/zL6XUKj15me46H5Vo3Cz6sk5qT0O rciIAZwQo+z5udxqnx2tQkFb0nP2EQsqECj4hQTNRyQE1TGnad8DwfYqs8oaB3zVvXUM sUHQ== X-Gm-Message-State: AOAM5332QgLekNDl/dKhh95K3LvJSeYqdkvz+D79HHh1SZ9TyzC/ZExx YAjyLpmNI2T3dcFbx4PEt2s= X-Google-Smtp-Source: ABdhPJwiZReKKHNdpxplCqWRC/RfnVafSJO0OJb9ap+7c3TonXRBQSFPl/y+I1tkyJ1p4FbTJ2OWLA== X-Received: by 2002:a63:515d:0:b0:373:8aca:7a40 with SMTP id r29-20020a63515d000000b003738aca7a40mr3626504pgl.284.1645127932534; Thu, 17 Feb 2022 11:58:52 -0800 (PST) Received: from ?IPv6:2406:e003:1005:b501:80b2:5c79:2266:e431? ([2406:e003:1005:b501:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id p4sm8864877pgh.53.2022.02.17.11.58.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Feb 2022 11:58:51 -0800 (PST) From: Brian E Carpenter To: dispatch@ietf.org Cc: dispatch-chairs@ietf.org, Bob Hinden , francesca.palombini@ericsson.com References: <67e55e7b-e23c-71d6-8da6-16ae49a8e35b@gmail.com> Message-ID: <3c47ecf4-f0bc-89a6-3322-4c05b0d4986c@gmail.com> Date: Fri, 18 Feb 2022 08:58:47 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <67e55e7b-e23c-71d6-8da6-16ae49a8e35b@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dispatch] IPv6 Zone Identifiers in URIs (RFC6874bis) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2022 19:58:56 -0000 FYI, we have recently updated this draft at https://www.ietf.org/archive/id/draft-carpenter-6man-rfc6874bis-03.html We opened discussion with various people in the browser community, but did not find much enthusiasm for implementation. Until there is a great increase in demand for link-locals to be supported by browsers, the necessary work seems unlikely to be done. However, we believe that this demand will eventually arise and therefore it's important that the relevant URI syntax is well-defined. There is a significant change in this version. Following the discussions a few month= s ago, and after I spent some time looking into the URI parsers in wget and= Firefox (and a brief look at curl), we propose to drop the "%25" encoding= of "%". The ABNF in this version, originally suggested by Andrew Cady, reflects that proposal. There is extra explanation in the text. The other signficant change is that, as Martin D=C3=BCrst pointed out, we= also need to formally update the IRI syntax. That was an omission in RFC6874. We are not asking for action by DISPATCH, but of course we'd welcome feedback. Regards Brian Carpenter On 09-Jul-21 15:46, Brian E Carpenter wrote: > Hi, >=20 > Bob Hinden and I are working on an update to RFC 6874, "Representing IP= v6 Zone Identifiers in Address Literals and Uniform Resource Identifiers"= : > https://datatracker.ietf.org/doc/draft-carpenter-6man-rfc6874bis/ > There will be an updated version before the cutoff, and there has > been quite a bit of discussion already at > https://mailarchive.ietf.org/arch/browse/ipv6/. >=20 > We expect this to be processed in 6MAN, as RFC 6874 was, but we would l= ike to briefly introduce it to DISPATCH/ART Area since clearly it is not = just an Internet Area topic. We're also very much aware that it needs to = be looked at by the browser community. >=20 > So this is a request for a short slot to raise awareness. We're not qui= te sure who would be presenting due to time zone and agenda clash challen= ges. >=20 > Please keep us in Cc as we are not on the DISPATCH list. >=20 From nobody Sat Feb 19 16:10:37 2022 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 97E623A094A for ; Sat, 19 Feb 2022 16:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.62 X-Spam-Level: X-Spam-Status: No, score=-1.62 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, 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 zslV3VoJBmg3 for ; Sat, 19 Feb 2022 16:10:30 -0800 (PST) Received: from forward105o.mail.yandex.net (forward105o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::608]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFBEC3A0942 for ; Sat, 19 Feb 2022 16:10:29 -0800 (PST) Received: from sas1-f3a441df9f84.qloud-c.yandex.net (sas1-f3a441df9f84.qloud-c.yandex.net [IPv6:2a02:6b8:c14:2726:0:640:f3a4:41df]) by forward105o.mail.yandex.net (Yandex) with ESMTP id 4CD7E4C26B4; Sun, 20 Feb 2022 03:10:26 +0300 (MSK) Received: from 2a02:6b8:c08:8889:0:640:9427:d204 (2a02:6b8:c08:8889:0:640:9427:d204 [2a02:6b8:c08:8889:0:640:9427:d204]) by sas1-f3a441df9f84.qloud-c.yandex.net (mxback/Yandex) with HTTP id AAX8qX1cxGk1-APcK4q9W; Sun, 20 Feb 2022 03:10:26 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1645315826; bh=1Xgr6QiOyW5tElYqd2VeydWHxH8fK+eS1PP3yP9cLp4=; h=Message-Id:Date:Subject:To:From; b=qGdYCCpT/djnG9x0Eif7/W7fwqrLV0iEr7vbxZ4lJ7MIQ9F1W1UI2HcWI66AHdMhr 12MSANO7vm8oFx90bWSY16xkm/aJCInQweWfXOgzXdwSQ+OBDXDI5XBHu9xOAisoPi Rfc5HFC+T0Vt/pfHyGAHdADx5Q8mXVmXiN4+rd4g= Authentication-Results: sas1-f3a441df9f84.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Received: by sas1-9427d2040e72.qloud-c.yandex.net with HTTP; Sun, 20 Feb 2022 03:10:25 +0300 From: Anton Tveretin To: Kirsty Paine , DISPATCH list MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sun, 20 Feb 2022 05:10:25 +0500 Message-Id: <189931645313194@mail.yandex.ru> Content-Transfer-Encoding: 7bit Content-Type: text/html Archived-At: Subject: Re: [dispatch] IETF 113 - do you have something for 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: Sun, 20 Feb 2022 00:10:35 -0000
Hi Kirsty,
I wrote two I-Ds, namely, draft-tveretin-dispatch-l2tp-sdp-02 and draft-tveretin-dispatch-remote-03, but I did not update them for a while (almost 5 years). I don't see any way to proceed with them. Is there any way? Is an implementation the right way? I do not see this as the intended approach to standartization.
I perceive the position of the IETF - and DISPATCH in particular - to suppress any grassroots initiative. I remember the story behind Dmitry Tyurin's HTML 6.0.
Also, I started SIP 2.5, but I never made it into an I-D.
Sincerely yours,
Anton Tveretin
From nobody Sun Feb 20 06:43:51 2022 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 9B0A23A11F1 for ; Sun, 20 Feb 2022 06:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.983 X-Spam-Level: X-Spam-Status: No, score=-0.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCwlE1-5KUWJ for ; Sun, 20 Feb 2022 06:43:45 -0800 (PST) Received: from resqmta-c1p-023464.sys.comcast.net (resqmta-c1p-023464.sys.comcast.net [IPv6:2001:558:fd00:56::b]) (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 3DB3A3A11EB for ; Sun, 20 Feb 2022 06:43:44 -0800 (PST) Received: from resomta-c1p-022589.sys.comcast.net ([96.102.18.236]) by resqmta-c1p-023464.sys.comcast.net with ESMTP id LmThnhmyMbn0tLnR4nvUJS; Sun, 20 Feb 2022 14:43:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20211018a; t=1645368218; bh=f/RgjePpuP//4kBuZR8uCMAfEzuKK0fW4ei0HCjzrX0=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=qD7241mQi6QyC/z8qJUPNvBCY498pcxYCxje/RKbxuKHgklUGqP/yCoIYMpuyfTXB YrCeUAofApWbQ6gdkKAnsDTZi3fFBw8iQ/AzusubkV6v0hQEtLr7+VN/EgGze+tLM2 62DLZjepvzkiRFF0zRtHjyD1v0CdhTr4utYB3qvhGfd4s0qvU+KXcesF2VAsn5f6sv zk12188DAqjU+sBC7RpSkECt/dE916ZIMxUTsSGf1Sxfdc1p3Q+YFiLLhSoc3Vf6oA e3v4VFiEwLyomi+UFmHem1cuhcaQoBONCmS6LmJRbUXIA7bAcBmlg8eK3hLvHD+lqx N0OZTt5NUHt8A== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430::2f20]) by resomta-c1p-022589.sys.comcast.net with ESMTPA id LnR2nHqmrGBB2LnR2nCK7x; Sun, 20 Feb 2022 14:43:37 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit Received: from hobgoblin.ariadne.com (localhost [127.0.0.1]) by hobgoblin.ariadne.com (8.16.1/8.16.1) with ESMTPS id 21KEhZAu105536 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sun, 20 Feb 2022 09:43:35 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.16.1/8.16.1/Submit) id 21KEhZk6105533; Sun, 20 Feb 2022 09:43:35 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Anton Tveretin Cc: kirsty.ietf@gmail.com, dispatch@ietf.org In-Reply-To: <189931645313194@mail.yandex.ru> (tveretinas@yandex.ru) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 20 Feb 2022 09:43:35 -0500 Message-ID: <87bkz18up4.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [dispatch] IETF 113 - do you have something for 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: Sun, 20 Feb 2022 14:43:50 -0000 Anton Tveretin writes: > I wrote two I-Ds, namely, draft-tveretin-dispatch-l2tp-sdp-02 [...] For reference: draft-tveretin-dispatch-l2tp-sdp-02.txt is "This document registeres new media type (application/l2tp) to be used with SDP, and clarifies procedure to be used by peers for L2TP tunnels." As always, the question is "How much support do you have?" That has a lot of aspects. One is, "Are there people interested in working on this document?" Another is "Are there people interested in implementing this?", which is closely related to, "Do people feel a unsatisfied need that this would satisfy?" Often the answers aren't well-correlated with, "Would this be a good idea in principle?" I'm reminded of when I did some work on "Happy Earballs", working out how a SIP client should attempt to contact a SIP server in the general case when the server's hostname resolves into multiple IPv4 and IPv6 addresses of unknown reachability. The problem had even been raised by some of the long-term experts in SIP. But nobody was interested in actually implementing it, which I strongly suspect is because in practice SIP is used to replicate traditional telco networks, with tightly controlled signaling paths in a network that has an overall architecture -- if a client knows of a server's name, the architecture ensures the addresses will connect. (Which is much different from the typical HTTP case.) So the first step is what is called "socializing" your proposal, talking to people in a fairly informal way to determine what interest you can raise in the work. Dale From nobody Mon Feb 21 15:48:59 2022 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 E37D13A0CE8; Mon, 21 Feb 2022 15:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=pWkkyROw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZEhBTLJ9 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 KRYtejmZTwZb; Mon, 21 Feb 2022 15:48:52 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C2543A0C31; Mon, 21 Feb 2022 15:48:52 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 7076032020C1; Mon, 21 Feb 2022 18:48:51 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 21 Feb 2022 18:48:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; bh=DDnRNRE+HuZY1v JDTXjWCf/oINncPQ6UdIvWwpK6Wu4=; b=pWkkyROwWcoP/iRqowVsVf+y+P8fpv oX3cYL1FOblmAsYP6LKPAWc3qkFS0Zv42PbNMUef9WAsOKxgUzxGc+kB9A0cxZVX BG+zkS9cqiu/D88OgeVOPclWrPFuVZ5c2ioGZpGAYRgxN9BnlDc6NKpHJVKfvCQn woTfWBLyDA8GpNv53HLo9HO2gmVwY10d0w6lH6bnqmkC7SNDhEBgG4pewjiYaE8I /h+Cub6ImPVz85QK+wV9EtZrsWrd97m3G19EH8x4l/FbcaR/ZaoPJOmOMMxkudrn 97Imv/5FrftvJvIvBA9RYQ6depibeyvM3MF3aCAYQa7kMwAro2lHcA/Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=DDnRNRE+HuZY1vJDTXjWCf/oINncPQ6UdIvWwpK6W u4=; b=ZEhBTLJ9IsTuc+RznREdkm8aq84+Y35rU1zv1XoMefQ2LGxy9Hf6KaSKQ 6Rnxy9bNVVdpHE2ZLv0XoLSaaHuzPj5vFf5vhigImb+uFQCPhoqY9SGdqU+/uNZ0 nWvx0RJXv4Mc7U0/lzTttlu52HdADWyIf/t/ySplt9dt2ud/5c9bre9rXzL4zcCk fgCzkfAGSeFShon+0Ig3kRMmwkWBnb1uBpaAgUFcJsGO7lpApMY5jsycbJZoFHhP SEniBtp1DNh/tfmg0Wq0NIw7DTcXgxmeKvJuH5uRG3rGmMDL61t81mW9h1PoVlvD Q/g+i+aYFn4/Q9sY5un9uPWOMqetQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrkeejgddugecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepfeegvdfgjeegvdetuedukeevfefhheelieevjeejkefhffehkeejieekjedtheej necuffhomhgrihhnpehivghtfhdrohhrghdpmhhnohhtrdhnvghtnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgv th X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 21 Feb 2022 18:48:49 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) From: Mark Nottingham In-Reply-To: <3c47ecf4-f0bc-89a6-3322-4c05b0d4986c@gmail.com> Date: Tue, 22 Feb 2022 10:48:45 +1100 Cc: dispatch@ietf.org, Bob Hinden , dispatch-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <196FEC4C-0D51-4FB0-9F59-5FD201265F46@mnot.net> References: <67e55e7b-e23c-71d6-8da6-16ae49a8e35b@gmail.com> <3c47ecf4-f0bc-89a6-3322-4c05b0d4986c@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3693.60.0.1.1) Archived-At: Subject: Re: [dispatch] IPv6 Zone Identifiers in URIs (RFC6874bis) 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, 21 Feb 2022 23:48:58 -0000 If we know it's not going to be implemented by browsers for the = foreseeable future and we still choose to publish something, it should = be clearly marked as what's effectively a hope-based standard. Cheers, > On 18 Feb 2022, at 6:58 am, Brian E Carpenter = wrote: >=20 > FYI, we have recently updated this draft at > = https://www.ietf.org/archive/id/draft-carpenter-6man-rfc6874bis-03.html >=20 > We opened discussion with various people in the browser community, but > did not find much enthusiasm for implementation. Until there is a = great > increase in demand for link-locals to be supported by browsers, the > necessary work seems unlikely to be done. >=20 > However, we believe that this demand will eventually arise and = therefore > it's important that the relevant URI syntax is well-defined. There is = a > significant change in this version. Following the discussions a few = months > ago, and after I spent some time looking into the URI parsers in wget = and > Firefox (and a brief look at curl), we propose to drop the "%25" = encoding > of "%". The ABNF in this version, originally suggested by Andrew Cady, > reflects that proposal. There is extra explanation in the text. >=20 > The other signficant change is that, as Martin D=C3=BCrst pointed out, = we > also need to formally update the IRI syntax. That was an omission in > RFC6874. >=20 > We are not asking for action by DISPATCH, but of course we'd welcome > feedback. >=20 > Regards > Brian Carpenter > On 09-Jul-21 15:46, Brian E Carpenter wrote: >> Hi, >> Bob Hinden and I are working on an update to RFC 6874, "Representing = IPv6 Zone Identifiers in Address Literals and Uniform Resource = Identifiers": >> https://datatracker.ietf.org/doc/draft-carpenter-6man-rfc6874bis/ >> There will be an updated version before the cutoff, and there has >> been quite a bit of discussion already at >> https://mailarchive.ietf.org/arch/browse/ipv6/. >> We expect this to be processed in 6MAN, as RFC 6874 was, but we would = like to briefly introduce it to DISPATCH/ART Area since clearly it is = not just an Internet Area topic. We're also very much aware that it = needs to be looked at by the browser community. >> So this is a request for a short slot to raise awareness. We're not = quite sure who would be presenting due to time zone and agenda clash = challenges. >> Please keep us in Cc as we are not on the DISPATCH list. >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Mark Nottingham https://www.mnot.net/ From nobody Mon Feb 21 16:01:25 2022 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 A46B83A0D7C; Mon, 21 Feb 2022 16:01:21 -0800 (PST) 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 affL3jc-teyU; Mon, 21 Feb 2022 16:01:17 -0800 (PST) Received: from mail-oo1-xc2e.google.com (mail-oo1-xc2e.google.com [IPv6:2607:f8b0:4864:20::c2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C27B3A0D53; Mon, 21 Feb 2022 16:01:17 -0800 (PST) Received: by mail-oo1-xc2e.google.com with SMTP id w10-20020a4ae08a000000b0031bdf7a6d76so15215019oos.10; Mon, 21 Feb 2022 16:01:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=1oChqUHDzAp3+WCA2G5SRhqJ+snVjqw65rycqYFTi2Y=; b=QpBa1Y5/pgPGoC0WaZ36qTB6ShH9lW4vCuu8ACc23qwBss1ALp787JcT0IBwJMOYTf zsmMmMfRztXBZMlYQXjDl7AM9X4PAoE1Kdpa7kF1oQwYAly76PPVUPpn2vl92/Y628W5 KtqWPmjF/Fe2WgP98eAkuhH33drvsvLHDQ+ABOOghQk6zKkh2O5giWW0h59ESs/2eX2m gk4wycKpIYQYhRYeXEc6XXBvaH58KJLmPYeSB8csvwzOsLadr+No0mpRD7pu63jcn7dN UJlgkehPaQwZuVo+EWXqlLAsZI0ZQ4D0qWfbLdp6gSZ+p1y91S3qI6PJslLxdpU7oKNY Q0Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=1oChqUHDzAp3+WCA2G5SRhqJ+snVjqw65rycqYFTi2Y=; b=oz8ONVkEAVxh/mMKLfvKZaVauT5k46zvWT6WgiUOZ2VAuFOKjiTJD9OnxGZe20gr3Y LxI550w8GH8XZGXBU3Qvptcip9/xPU4SiLoiKLG7ZLOIkkrQKMfNjdTQ4gXggWo4bmXI gDlcCVGYBPpDTNgNN4TvDqoTsS5HekdD/PNxiEa1l6/BFOcOFvJ80z1ff8mphjioiE7a Znq1mmgs06wX1Wzxuk2Pi1wuMzjubEKNN+UPnsGBTn2uda5cwkq3aRAsNEyAGjKHJEUa K3ufXZBvSWiKrYtwMXZWHiV6u734cvXO6lQylhnJoHoshWy2bQNrAacl4lB6SpUSwxpY ouog== X-Gm-Message-State: AOAM53184VlDZ57kcjl44MAI/ErYwgJvUiRDqP2wp23PkWJ1+qLbYDJu fkQKXQouZ+HEm+Ej1Ql953k= X-Google-Smtp-Source: ABdhPJwyjapyY5p+bBufCDMAjanB9YHHVydN/dMVuHy28a5PKkQlUT943o54tVEHtm2E0RJbsg7pdA== X-Received: by 2002:a05:6870:f706:b0:c4:7dc0:d6f3 with SMTP id ej6-20020a056870f70600b000c47dc0d6f3mr565775oab.198.1645488075838; Mon, 21 Feb 2022 16:01:15 -0800 (PST) Received: from smtpclient.apple ([2600:1700:4383:c05f:10a8:8d3c:da27:f436]) by smtp.gmail.com with ESMTPSA id m18sm5520352otq.31.2022.02.21.16.01.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Feb 2022 16:01:15 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_DEE8E376-FE2E-4A8B-98FC-FF6A54E3090C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) From: Bob Hinden In-Reply-To: <196FEC4C-0D51-4FB0-9F59-5FD201265F46@mnot.net> Date: Mon, 21 Feb 2022 16:01:13 -0800 Cc: Bob Hinden , Brian Carpenter , dispatch@ietf.org, dispatch-chairs@ietf.org Message-Id: <1A9B4202-26F8-4D49-8FC4-F249FFC7ABB3@gmail.com> References: <67e55e7b-e23c-71d6-8da6-16ae49a8e35b@gmail.com> <3c47ecf4-f0bc-89a6-3322-4c05b0d4986c@gmail.com> <196FEC4C-0D51-4FB0-9F59-5FD201265F46@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.3693.60.0.1.1) Archived-At: Subject: Re: [dispatch] IPv6 Zone Identifiers in URIs (RFC6874bis) 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, 22 Feb 2022 00:01:22 -0000 --Apple-Mail=_DEE8E376-FE2E-4A8B-98FC-FF6A54E3090C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Mark, Another way to look at it is =E2=80=9Cif you are going to support it, do = it this way=E2=80=9D. Bob > On Feb 21, 2022, at 3:48 PM, Mark Nottingham wrote: >=20 > If we know it's not going to be implemented by browsers for the = foreseeable future and we still choose to publish something, it should = be clearly marked as what's effectively a hope-based standard. >=20 > Cheers, >=20 >=20 >> On 18 Feb 2022, at 6:58 am, Brian E Carpenter = wrote: >>=20 >> FYI, we have recently updated this draft at >> = https://www.ietf.org/archive/id/draft-carpenter-6man-rfc6874bis-03.html >>=20 >> We opened discussion with various people in the browser community, = but >> did not find much enthusiasm for implementation. Until there is a = great >> increase in demand for link-locals to be supported by browsers, the >> necessary work seems unlikely to be done. >>=20 >> However, we believe that this demand will eventually arise and = therefore >> it's important that the relevant URI syntax is well-defined. There is = a >> significant change in this version. Following the discussions a few = months >> ago, and after I spent some time looking into the URI parsers in wget = and >> Firefox (and a brief look at curl), we propose to drop the "%25" = encoding >> of "%". The ABNF in this version, originally suggested by Andrew = Cady, >> reflects that proposal. There is extra explanation in the text. >>=20 >> The other signficant change is that, as Martin D=C3=BCrst pointed = out, we >> also need to formally update the IRI syntax. That was an omission in >> RFC6874. >>=20 >> We are not asking for action by DISPATCH, but of course we'd welcome >> feedback. >>=20 >> Regards >> Brian Carpenter >> On 09-Jul-21 15:46, Brian E Carpenter wrote: >>> Hi, >>> Bob Hinden and I are working on an update to RFC 6874, "Representing = IPv6 Zone Identifiers in Address Literals and Uniform Resource = Identifiers": >>> https://datatracker.ietf.org/doc/draft-carpenter-6man-rfc6874bis/ >>> There will be an updated version before the cutoff, and there has >>> been quite a bit of discussion already at >>> https://mailarchive.ietf.org/arch/browse/ipv6/. >>> We expect this to be processed in 6MAN, as RFC 6874 was, but we = would like to briefly introduce it to DISPATCH/ART Area since clearly it = is not just an Internet Area topic. We're also very much aware that it = needs to be looked at by the browser community. >>> So this is a request for a short slot to raise awareness. We're not = quite sure who would be presenting due to time zone and agenda clash = challenges. >>> Please keep us in Cc as we are not on the DISPATCH list. >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 --Apple-Mail=_DEE8E376-FE2E-4A8B-98FC-FF6A54E3090C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAmIUJ8kACgkQrut0EXfn u6jKZAf/aaFuR98HvTSXaoIBLaV+6/W5gAqHbKCnELU3CcaT8sU9AERsPP0piO7t hkZ3tEOn7b7nE7Q9DORsPtFfSWVisTx+c1R90mLVNmtRhYxjCX80rtic/CYtmeEm 8xwd+XJwQNoV1z/fB3G+owJQavXwi2vSSvQeviwDryoiUXgY/EYgwl6geWlRjs8j Cx9t3f1oRPF8oHJAkQuhbcPrDYHUxFdwAqE80nxe62k59QBu/F1l/bYmkItKRBkU RxNbUge6VGQNQznhN28IOJemChWDYp+vpx/lI187Z7yhU/0janVVZOH6IpGmonNk 597rBy0xl01XrqjJe5FTT28vCKArOw== =sDT6 -----END PGP SIGNATURE----- --Apple-Mail=_DEE8E376-FE2E-4A8B-98FC-FF6A54E3090C-- From nobody Mon Feb 21 16:05:02 2022 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 7E3953A0D87; Mon, 21 Feb 2022 16:04:59 -0800 (PST) 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=mnot.net header.b=OzqspxTn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FNAnTyq2 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 ZyoJFPHhrK-H; Mon, 21 Feb 2022 16:04:54 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EAA63A0D7C; Mon, 21 Feb 2022 16:04:54 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id BD28B5C0280; Mon, 21 Feb 2022 19:04:53 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 21 Feb 2022 19:04:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; bh=wFOyBnIWe3tFpe zUzNhpqOPj91rEP+y+5UPiL9PAATc=; b=OzqspxTnv8O4Nk3KbdqULU4J1sEFa8 elO+0wcgXHc0QLUkRU0H28QiOa6YbR3xpYlLAZ+cAzKMzeb3+eD/lL2k7cqArhcX rI6mTFEyYvypBMtWTzF9x9TAc6U60RSXNqryAeLMZH+rsqk+25+OLeiqsvGeotOW VBfsIxMLgcka6bik1Qtr/6PBbEsvIeKD9eKU4tS8UrGAL9TJX9FPDdeGwr6vr2UB 7AJ0rXcSGx1oq9IaT4UU5O9DltiXkX9qU/EqFPcpSctwz1B7D7qgcpavhVFJMwtm s9C/uN3dcbLTSn24ToUVLwIcOp6nS0Agv8q9W0kjhx8pSLFvTZN03yUQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=wFOyBnIWe3tFpezUzNhpqOPj91rEP+y+5UPiL9PAA Tc=; b=FNAnTyq2ZluL/kmg1HyviRWiszz724w4axJddBS95kfsiD6U/vhcO70G/ vL8C+NYE0H/eFUxgtDinU5cTHLi7Kp9UvdyKwYnx5C/vL2z2qrGqX3aykRFMtL0J EMA+FrP9eOHhPYCFFXStIb/JfTfh+JS93XFH4DT+X5Akgwj+EqyylgaIhsk+vMS3 qRKwPmIYPyGCDtuuVzfZaVr6zlx9iatEnTksrjQEbpoF2d7B6/MewceVPfw4C5wY gTvowQripp82Zs4I+/rFiqvTj9gipk5MEcQhn7C2JO7Qe77JDbMvPy7VBvCCGzs/ A0tSJQDxOSBpTAJiOBR/iZWi9EJeg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrkeejgddujecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepfeegvdfgjeegvdetuedukeevfefhheelieevjeejkefhffehkeejieekjedtheej necuffhomhgrihhnpehivghtfhdrohhrghdpmhhnohhtrdhnvghtnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgv th X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 21 Feb 2022 19:04:51 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) From: Mark Nottingham In-Reply-To: <1A9B4202-26F8-4D49-8FC4-F249FFC7ABB3@gmail.com> Date: Tue, 22 Feb 2022 11:04:49 +1100 Cc: Brian Carpenter , dispatch@ietf.org, dispatch-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <324008AE-C6C5-4F4F-8925-3383114266F0@mnot.net> References: <67e55e7b-e23c-71d6-8da6-16ae49a8e35b@gmail.com> <3c47ecf4-f0bc-89a6-3322-4c05b0d4986c@gmail.com> <196FEC4C-0D51-4FB0-9F59-5FD201265F46@mnot.net> <1A9B4202-26F8-4D49-8FC4-F249FFC7ABB3@gmail.com> To: Bob Hinden X-Mailer: Apple Mail (2.3693.60.0.1.1) Archived-At: Subject: Re: [dispatch] IPv6 Zone Identifiers in URIs (RFC6874bis) 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, 22 Feb 2022 00:05:00 -0000 Sure. But if it's going to be an RFC, many will read that and expect it = to be supported by browsers. If browsers aren't involved in creating it = and decline to implement, it should set reasonable expectations. > On 22 Feb 2022, at 11:01 am, Bob Hinden wrote: >=20 > Mark, >=20 > Another way to look at it is =E2=80=9Cif you are going to support it, = do it this way=E2=80=9D. >=20 > Bob >=20 >=20 >> On Feb 21, 2022, at 3:48 PM, Mark Nottingham wrote: >>=20 >> If we know it's not going to be implemented by browsers for the = foreseeable future and we still choose to publish something, it should = be clearly marked as what's effectively a hope-based standard. >>=20 >> Cheers, >>=20 >>=20 >>> On 18 Feb 2022, at 6:58 am, Brian E Carpenter = wrote: >>>=20 >>> FYI, we have recently updated this draft at >>> = https://www.ietf.org/archive/id/draft-carpenter-6man-rfc6874bis-03.html >>>=20 >>> We opened discussion with various people in the browser community, = but >>> did not find much enthusiasm for implementation. Until there is a = great >>> increase in demand for link-locals to be supported by browsers, the >>> necessary work seems unlikely to be done. >>>=20 >>> However, we believe that this demand will eventually arise and = therefore >>> it's important that the relevant URI syntax is well-defined. There = is a >>> significant change in this version. Following the discussions a few = months >>> ago, and after I spent some time looking into the URI parsers in = wget and >>> Firefox (and a brief look at curl), we propose to drop the "%25" = encoding >>> of "%". The ABNF in this version, originally suggested by Andrew = Cady, >>> reflects that proposal. There is extra explanation in the text. >>>=20 >>> The other signficant change is that, as Martin D=C3=BCrst pointed = out, we >>> also need to formally update the IRI syntax. That was an omission in >>> RFC6874. >>>=20 >>> We are not asking for action by DISPATCH, but of course we'd welcome >>> feedback. >>>=20 >>> Regards >>> Brian Carpenter >>> On 09-Jul-21 15:46, Brian E Carpenter wrote: >>>> Hi, >>>> Bob Hinden and I are working on an update to RFC 6874, = "Representing IPv6 Zone Identifiers in Address Literals and Uniform = Resource Identifiers": >>>> https://datatracker.ietf.org/doc/draft-carpenter-6man-rfc6874bis/ >>>> There will be an updated version before the cutoff, and there has >>>> been quite a bit of discussion already at >>>> https://mailarchive.ietf.org/arch/browse/ipv6/. >>>> We expect this to be processed in 6MAN, as RFC 6874 was, but we = would like to briefly introduce it to DISPATCH/ART Area since clearly it = is not just an Internet Area topic. We're also very much aware that it = needs to be looked at by the browser community. >>>> So this is a request for a short slot to raise awareness. We're not = quite sure who would be presenting due to time zone and agenda clash = challenges. >>>> Please keep us in Cc as we are not on the DISPATCH list. >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >> -- >> Mark Nottingham https://www.mnot.net/ >>=20 >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Mon Feb 21 17:10:16 2022 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 611B03A0FBE; Mon, 21 Feb 2022 17:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.714, 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 r8e0AGmfGhkz; Mon, 21 Feb 2022 17:10:06 -0800 (PST) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (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 1AC4B3A08B3; Mon, 21 Feb 2022 17:10:06 -0800 (PST) Received: by mail-pj1-x1034.google.com with SMTP id gf13-20020a17090ac7cd00b001bbfb9d760eso775995pjb.2; Mon, 21 Feb 2022 17:10:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=F6Fj4nU3jXXxPrvQe3r0N45I1SvJo38GQ5QMHzvQBsc=; b=QaKt0dc/cNivoqTwyy+f5q2C1sgFmcoDErHsKHEIu8cQQ9Hbwb+VwyHZCIZ+7BVDpf sweAKKFgH6YMF1R6gor3v38sHuw0fIpEYOKtJw0dYn//O2s/AJC0BQTjduwRzaF91FsQ 7Imvh/aFNbKKmV5OPrf32KxbC5/SW2CWcoX7tL2A9qvfoiPO+s26nxFbZC7/rf2RqTUe jcSW4WIxp0uY8Bu6zoyEJ9Wf028MkFIlTGA7PW9CjFXNQvZUgvYV37vKl+6vclaNG3ou BetYyrmnkjbDvIxZliVerN4P2tT+z1NET77fMKIhZ4+r2hj097vRApDJzdrFP378sT8v LkwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=F6Fj4nU3jXXxPrvQe3r0N45I1SvJo38GQ5QMHzvQBsc=; b=xQYP31M+WeKdbzd8zvD+D8G1vl8+O/Tz9zmMkrI/CRR0cb+aOG1uo2awM6lQJpqFM7 1Y+eXUyu03v9bSBdo/aeL/0l+ydiWBKJsEiRZZumAlTGz88ptmpWetHCOLZU1hH1mcbd HBtuQmTG+4kz0QCp9E1iOYx65DaOdVmjW22lM1e8mXzrofHkk0IirFa3jHaE1ljtJnVD Wz/Wl+kXeclv5RhuLSyOZ6Kv4wgh8ej21YOo28ACk269ct0twsfbMCs3zsLO/vw+pYJS 0l52AE8e4uyG4r2vZLip3tvm69VHxifEkyet7u7mk+v4788roFX1F23bJKIzqO8ZmUpW 25uQ== X-Gm-Message-State: AOAM5307RTXRJyH5wA5hvaaWbStS9y+KAsbMDgLTm6Mf0IiJF21rnPZw U8kyoVS9TmN7lu9eandu0okDnE1gsrpbXw== X-Google-Smtp-Source: ABdhPJx9oOkx/+suGdikH7q47PgydgYyBnVcQDnhFfGOd1W+Xfa1RCV683BfZms7AR2rB++xVq3HFA== X-Received: by 2002:a17:903:234f:b0:14f:ba1e:c062 with SMTP id c15-20020a170903234f00b0014fba1ec062mr7070983plh.71.1645492205090; Mon, 21 Feb 2022 17:10:05 -0800 (PST) Received: from ?IPv6:2406:e003:1005:b501:80b2:5c79:2266:e431? ([2406:e003:1005:b501:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id x34sm15790944pfh.178.2022.02.21.17.10.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Feb 2022 17:10:04 -0800 (PST) To: Mark Nottingham , Bob Hinden Cc: dispatch@ietf.org, dispatch-chairs@ietf.org References: <67e55e7b-e23c-71d6-8da6-16ae49a8e35b@gmail.com> <3c47ecf4-f0bc-89a6-3322-4c05b0d4986c@gmail.com> <196FEC4C-0D51-4FB0-9F59-5FD201265F46@mnot.net> <1A9B4202-26F8-4D49-8FC4-F249FFC7ABB3@gmail.com> <324008AE-C6C5-4F4F-8925-3383114266F0@mnot.net> From: Brian E Carpenter Message-ID: <33ddf676-b3d6-6939-6ff1-2f454dd3433a@gmail.com> Date: Tue, 22 Feb 2022 14:09:59 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <324008AE-C6C5-4F4F-8925-3383114266F0@mnot.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dispatch] IPv6 Zone Identifiers in URIs (RFC6874bis) 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, 22 Feb 2022 01:10:12 -0000 Yes, we can add a sentence or two to make that clear. Regards Brian On 22-Feb-22 13:04, Mark Nottingham wrote: > Sure. But if it's going to be an RFC, many will read that and expect it=20 to be supported by browsers. If browsers aren't involved in creating it a= nd decline to implement, it should set reasonable expectations. >=20 >=20 >> On 22 Feb 2022, at 11:01 am, Bob Hinden wrote: >> >> Mark, >> >> Another way to look at it is =E2=80=9Cif you are going to support it, = do it this way=E2=80=9D. >> >> Bob >> >> >>> On Feb 21, 2022, at 3:48 PM, Mark Nottingham wrote: >>> >>> If we know it's not going to be implemented by browsers for the fores= eeable future and we still choose to publish something, it should be clea= rly marked as what's effectively a hope-based standard. >>> >>> Cheers, >>> >>> >>>> On 18 Feb 2022, at 6:58 am, Brian E Carpenter wrote: >>>> >>>> FYI, we have recently updated this draft at >>>> https://www.ietf.org/archive/id/draft-carpenter-6man-rfc6874bis-03.h= tml >>>> >>>> We opened discussion with various people in the browser community, b= ut >>>> did not find much enthusiasm for implementation. Until there is a gr= eat >>>> increase in demand for link-locals to be supported by browsers, the >>>> necessary work seems unlikely to be done. >>>> >>>> However, we believe that this demand will eventually arise and there= fore >>>> it's important that the relevant URI syntax is well-defined. There i= s a >>>> significant change in this version. Following the discussions a few = months >>>> ago, and after I spent some time looking into the URI parsers in wge= t and >>>> Firefox (and a brief look at curl), we propose to drop the "%25" enc= oding >>>> of "%". The ABNF in this version, originally suggested by Andrew Cad= y, >>>> reflects that proposal. There is extra explanation in the text. >>>> >>>> The other signficant change is that, as Martin D=C3=BCrst pointed ou= t, we >>>> also need to formally update the IRI syntax. That was an omission in= >>>> RFC6874. >>>> >>>> We are not asking for action by DISPATCH, but of course we'd welcome= >>>> feedback. >>>> >>>> Regards >>>> Brian Carpenter >>>> On 09-Jul-21 15:46, Brian E Carpenter wrote: >>>>> Hi, >>>>> Bob Hinden and I are working on an update to RFC 6874, "Representin= g IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifi= ers": >>>>> https://datatracker.ietf.org/doc/draft-carpenter-6man-rfc6874bis/ >>>>> There will be an updated version before the cutoff, and there has >>>>> been quite a bit of discussion already at >>>>> https://mailarchive.ietf.org/arch/browse/ipv6/. >>>>> We expect this to be processed in 6MAN, as RFC 6874 was, but we wou= ld like to briefly introduce it to DISPATCH/ART Area since clearly it is = not just an Internet Area topic. We're also very much aware that it needs=20 to be looked at by the browser community. >>>>> So this is a request for a short slot to raise awareness. We're not=20 quite sure who would be presenting due to time zone and agenda clash chal= lenges. >>>>> Please keep us in Cc as we are not on the DISPATCH list. >>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> -- >>> Mark Nottingham https://www.mnot.net/ >>> >> >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 From nobody Tue Feb 22 03:49:10 2022 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 56B283A0E78 for ; Tue, 22 Feb 2022 03:49:08 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUD0JpFbeivK for ; Tue, 22 Feb 2022 03:49:03 -0800 (PST) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 811E53A0E74 for ; Tue, 22 Feb 2022 03:49:03 -0800 (PST) Received: by mail-io1-xd32.google.com with SMTP id e79so19683543iof.13 for ; Tue, 22 Feb 2022 03:49:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XtFp4eqTtyUq7n7twSux0oChgwszklXPdmTKrit7YJc=; b=VumgcbyDI/wEGxAWIIyehKURfKr+zIuo/6Q4JkSFh4rvSCLRZZerFFppJz86LTY6h6 y3q0zrc150uLCvOAKLS1zBqyXL+T3KkFPTOMXss5H9gB3hdf/wyVXMEgwYgVY+d0mD7/ NZc3nbL9XDr4ixoMzN5Apo2UbdscoKEkMjw2Y3/CpnOaQ2Ed97CmDaJMS/zmIPhVyChF JUxfSz4Fzqj76a8rafmjObkPFZ7r1wGCirtLUVReQsgKnSy5RjtQm+u8cz2ZUspJb4vQ fqVQwthkYY0KLIFDDY1b/mQnObFOkeRgPzqqrzuMKApwg3w4cspUA42o6uwqsCvrlTSp RyZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XtFp4eqTtyUq7n7twSux0oChgwszklXPdmTKrit7YJc=; b=d0+6JmR3fd8m7MJIUhWa+BcXCG650PTcZcHop8M6aGllbZe4U4b0MSjFJFNuJChUPs zuNAApcDFWBE1+KxjkfYr/YJHNsksfERAhhFDZArWnI+SIsC0k4/dEZ3NdjNmEEO2wGp 9EUo52xshszWVotZrj5vSpy5vgCy0aDTYPh1yu53eDZ8WbNLGk0pHy/UBgwrjpV0R7Dc ehDub26O/CBHKLBW7dnzDFPiAbuArawU1ateC855UAt4/dDMCiOhEcCXIBBTBP0IHj3k aCBghj9OLJ9xtsDG8zmvbLgEaPrr1xMUu2ioNNmqpOaBiw73Js9kY7pxGePINfWzx8x+ CP0Q== X-Gm-Message-State: AOAM532q9wT/OGXm86ofKBzJOIRV5ep0RCBMm41oLNSl6/MDQSn74wAB OsD3RNJH94SkvQILSpXvQFcQOZXh3Du9TdRYvA4= X-Google-Smtp-Source: ABdhPJylaRCexnlzH929g4zIt0h7h+IoHK6yFtebZtqsrvW6qqHLLcGVK6k0bkhobQHiNUVkR2Icnc079O10ydnZZmg= X-Received: by 2002:a02:cb5b:0:b0:311:c0a0:9e1c with SMTP id k27-20020a02cb5b000000b00311c0a09e1cmr19406464jap.5.1645530542642; Tue, 22 Feb 2022 03:49:02 -0800 (PST) MIME-Version: 1.0 References: <189931645313194@mail.yandex.ru> In-Reply-To: <189931645313194@mail.yandex.ru> From: Kirsty Paine Date: Tue, 22 Feb 2022 11:48:51 +0000 Message-ID: To: Anton Tveretin Cc: DISPATCH list Content-Type: multipart/alternative; boundary="000000000000761f8805d899efa8" Archived-At: Subject: Re: [dispatch] IETF 113 - do you have something for 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: Tue, 22 Feb 2022 11:49:08 -0000 --000000000000761f8805d899efa8 Content-Type: text/plain; charset="UTF-8" Hi Anton, I'm sorry to hear your perception of the IETF to date is that it suppresses grassroots initiatives. DISPATCH is here to help navigate options for new work, explain some of the ways to move work forward, and can be particularly welcoming for those newer to, or less familiar with, the IETF. Patrick and I (dispatch co-chairs) will reach out to you separately, to avoid list noise, about your options to progress your drafts. Kirsty On Sun, Feb 20, 2022 at 12:10 AM Anton Tveretin wrote: > Hi Kirsty, > I wrote two I-Ds, namely, draft-tveretin-dispatch-l2tp-sdp-02 and > draft-tveretin-dispatch-remote-03, but I did not update them for a while > (almost 5 years). I don't see any way to proceed with them. Is there any > way? Is an implementation the right way? I do not see this as the intended > approach to standartization. > I perceive the position of the IETF - and DISPATCH in particular - to > suppress any grassroots initiative. I remember the story behind Dmitry > Tyurin's HTML 6.0. > Also, I started SIP 2.5, but I never made it into an I-D. > Sincerely yours, > Anton Tveretin > --000000000000761f8805d899efa8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Anton,

I'm sorry to hear your pe= rception of the IETF to date is that it suppresses grassroots initiatives. = DISPATCH is here to help navigate options for new work, explain some of the= ways to move work forward, and can be particularly welcoming for those new= er to, or less familiar with, the IETF.=C2=A0

= Patrick and I (dispatch co-chairs) will reach out to you separately, to avo= id list noise, about your options to progress your drafts.=C2=A0
=
Kirsty


On Sun, Feb 20, 2022 at 12:10 AM = Anton Tveretin <tveretinas@yande= x.ru> wrote:
Hi Kirsty,
I wrote two I-Ds, namely, draft-tveretin-disp= atch-l2tp-sdp-02 and draft-tveretin-dispatch-remote-03, but I did not updat= e them for a while (almost 5 years). I don't see any way to proceed wit= h them. Is there any way? Is an implementation the right way? I do not see = this as the intended approach to standartization.
I perceive the = position of the IETF - and DISPATCH in particular - to suppress any grassro= ots initiative. I remember the story behind Dmitry Tyurin's HTML 6.0.
Also, I started SIP 2.5, but I never made it into an I-D.
Sincerely yours,
Anton Tveretin
--000000000000761f8805d899efa8-- From nobody Fri Feb 25 17:38:23 2022 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 7FCD33A11A2; Fri, 25 Feb 2022 17:29:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: dispatch@ietf.org, francesca.palombini@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164583895651.24617.17018086624375768244@ietfa.amsl.com> Date: Fri, 25 Feb 2022 17:29:16 -0800 Archived-At: Subject: [dispatch] dispatch - Requested session has been scheduled for IETF 113 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: Sat, 26 Feb 2022 01:29:25 -0000 Dear Kirsty Paine, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dispatch Session 1 (2:00 requested) Monday, 21 March 2022, Morning Session I 1000-1200 Room Name: Grand Park Hall 3 size: 250 --------------------------------------------- Special Note: Joint with ARTAREA iCalendar: https://datatracker.ietf.org/meeting/113/sessions/dispatch.ics Request Information: --------------------------------------------------------- Working Group Name: Dispatch Area Name: Applications and Real-Time Area Session Requester: Kirsty Paine Number of Sessions: 1 Length of Session(s): Number of Attendees: 150 Conflicts to Avoid: People who must be present: Francesca Palombini Kirsty Paine Murray Kucherawy Patrick McManus Resources Requested: Special Requests: Please schedule in the 1st slot Monday morning, and list as coupled with ARTAREA. Please avoid conflicts with other ART area WGs and BoFs, other area meetings, other dispatch groups, and BoFs. --------------------------------------------------------- From nobody Mon Feb 28 00:28:18 2022 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 2A0853A0D05; Mon, 28 Feb 2022 00:28:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dispatch@ietf.org Message-ID: <164603689508.6113.8819234743954908440@ietfa.amsl.com> Date: Mon, 28 Feb 2022 00:28:15 -0800 Archived-At: Subject: [dispatch] I-D Action: draft-ietf-dispatch-javascript-mjs-16.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2022 08:28:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dispatch WG of the IETF. Title : ECMAScript Media Types Updates Authors : Matthew A. Miller Myles Borins Mathias Bynens Bradley Farias Filename : draft-ietf-dispatch-javascript-mjs-16.txt Pages : 16 Date : 2022-02-28 Abstract: This document describes the registration of media types for the ECMAScript and JavaScript programming languages and conformance requirements for implementations of these types. This document obsoletes RFC4329, "Scripting Media Types", replacing the previous registrations for "text/javascript" and "application/javascript" with information and requirements aligned with common usage and implementation experiences. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-dispatch-javascript-mjs-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dispatch-javascript-mjs-16 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts