From nobody Tue Nov 2 17:58:36 2021 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 7E1023A005C for ; Tue, 2 Nov 2021 17:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ducksong.com header.b=LogQY08e; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=PGQTWgda 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 OpxNwdpq5HaK for ; Tue, 2 Nov 2021 17:58:29 -0700 (PDT) Received: from outbound4v.ore.mailhop.org (outbound4v.ore.mailhop.org [44.233.143.45]) (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 B4F303A0045 for ; Tue, 2 Nov 2021 17:58:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635901109; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=h06WJoVlGj4UpaosmAe0o295xbKhuyQ7wFMuEp2icEYgUr9TOPBSTtXU2lo/TpvN/2MrqX1Q3UsaP En7ODfSrhZI72ub+ZcmrQnCmuth693NcK3wH/q/3YvU4zBNvXTPhQOEekivGcU5OjAg6djl+VpWsIB dkYMy9/3cuEPPXh8eiKJ+8cYP1DMjglnYEWnoQF4uhci45/rHwbI6rHi82pnvktZgTWzPBFOyLB3w+ YfqQEH+AkPF5PvCQQGgKv6ZmfNC661pOSd9ApQ6o26kmeEK487By1VnDUfhYWxhkOHf9/jEnbLM8tQ smz0G4n1UlQ5DJFCx3MJmX2cEHcr8hw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=E1bms0nGthNfmFAAaWs9r60Kt20s7xEGiLaatMlgchM=; b=SI+FlUJQg/oqhgY5wowhOL4QNwO5fhNhtydzeUUuuk/F6LMGxP6i2L1Sr5GJGQ+4FfN60cERwQ2va 9kwlu8vOB7ltwjAQ/lGUOipLlX7O2ldCMHO1uXWIYtPG+xBccSQ27S10QiQ6kjOxC3UZ3VMFsFPXG7 YjklTkyggmSdxxixoOpwghc8kJ771nxSJzU+nlCf7cHZa68AmGopvurlf7HSVP/9eCfw/WylJ6LQAD 8VpehMEYDXkMJcY2dwFGAqPOGaCiaWImlDPErZqxl7Bwwa59ykeD+Iz6BL8VYYj6Ptvja0E2Nlvv9b cWHjqkrLjhpKNfMZ16zN3h+ielLg7bQ== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.161.41; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=E1bms0nGthNfmFAAaWs9r60Kt20s7xEGiLaatMlgchM=; b=LogQY08eAfMcD7dgHn40LNPf3sXnf7+JRFM3U67qgGultuV53YSVMY93OPifEus8f26Pd22rplszh hG4mw4uCDahsV3sDx+w8Z2PgrxDBHq0daUr7THxLOpCyWjQU+xuVdIREyVrbZk18w2ga1qCnnqWjRk GU7eHz18iImgy52E= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=E1bms0nGthNfmFAAaWs9r60Kt20s7xEGiLaatMlgchM=; b=PGQTWgdaoUXDBf7p86wIkpN263Z5TouoVNRJ92vCBdC7Y+M6SSRzWH2QktcyvmbbpDkiNXoWaSBhi /HzDwYQUpCxHw5gvEXJGQhwRe1qwd4BOqxscroW3B7+1/OYLXoaO6Q0zVpNpjTC+9lUUKIvm4vm3sY dG/JTDO6XwCZF7cv4vf7DjmRj1ciuZutgue9+yDUAbkCJOQ1tLVqGUeS/8kR3zVzhkUaBO+bWd8N8n 9/8PArbMlovuzSTyvZwhmzHMqY0wIlFEuCMsaZv8QtllXU48fUCXrVsPZMoezE21vpD+MgVO4uhsqB vlO3s/HG94WMBTtf+UbtzxMuK4l37RA== X-Originating-IP: 209.85.161.41 X-MHO-RoutePath: bWNtYW51cw== X-MHO-User: 2769407b-3c41-11ec-a67d-89389772cfc7 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Mail-Handler: DuoCircle Outbound SMTP Received: from mail-oo1-f41.google.com (mail-oo1-f41.google.com [209.85.161.41]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 2769407b-3c41-11ec-a67d-89389772cfc7; Wed, 03 Nov 2021 00:58:28 +0000 (UTC) Received: by mail-oo1-f41.google.com with SMTP id o26-20020a4abe9a000000b002b74bffdef0so263973oop.12 for ; Tue, 02 Nov 2021 17:58:27 -0700 (PDT) X-Gm-Message-State: AOAM533HhNXXFKTfsWvos7E7DI30V63o/YD/R0WbxFedRgHlAG2B3L57 ytRvnrLrZ35JXu6TGGunqbJerRRfF+NeUuHj9vA= X-Google-Smtp-Source: ABdhPJySVPGIcdOj7SPMCl4MS47JXNERPukGQeoqRqmZeBlI3jNwHBrJklyCsj5kz0hhLOlwR2qVbkEn+EatqesE1IM= X-Received: by 2002:a4a:ea54:: with SMTP id j20mr27332192ooe.22.1635901107127; Tue, 02 Nov 2021 17:58:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Patrick McManus Date: Tue, 2 Nov 2021 20:58:15 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Mary Barnes Cc: DISPATCH Content-Type: multipart/alternative; boundary="00000000000060cc0e05cfd7e8ab" Archived-At: Subject: Re: [dispatch] Updated wiki - where's the history of proposal dispatchments? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2021 00:58:35 -0000 --00000000000060cc0e05cfd7e8ab Content-Type: text/plain; charset="UTF-8" Hi Mary, Yes, the wiki has been updated to focus a little bit higher in the stack than before. We wanted to focus on being an introductory point for new work in the art area to help folks navigate their way towards an outcome (a successful dispatch!). Minutes and updates to the list are hoped to be sufficient for documenting the work product at this point -- Kristy and I think that with a different focus than a traditional WG (with milestones and what not) the emphasis makes sense. I hope that this focus will continue to evolve and reflect the changing needs of dispatch over time. -Patrick On Thu, Oct 28, 2021 at 2:16 PM Mary Barnes wrote: > I noticed the wiki has been updated and I don't see all the past > information about how work items were dispatched. I would have expected to > at least see a link and have an annotation that it's no longer being > updated. I personally found it very helpful (although, I'm biased > because I worked hard to keep it up to date). > > It is available under update 144, however for anyone else that was > wondering: https://trac.ietf.org/trac/dispatch/wiki/WikiStart?version=144 > > It is a good way to easily track stats for how proposals were progressed > (or not). I would periodically go back and update things once WGs were > officially formed, etc. > > Regards, > Mary. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --00000000000060cc0e05cfd7e8ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mary,

Yes, the wiki has b= een updated to focus a little bit higher in the stack than before. We wante= d to focus on being an introductory point for new work in the art area to h= elp folks navigate their way towards an outcome (a successful dispatch!). M= inutes and updates to the list are hoped to be sufficient for documenting t= he work product at this point -- Kristy and I think that with a different f= ocus than a traditional WG (with milestones and what not) the emphasis make= s sense.

I hope that this focus will continue to e= volve and reflect the changing needs of dispatch over time.
<= br>
-Patrick

On Thu, Oct 28, 2021 at 2:16 PM Mary Barnes= <mary.ietf.barnes@gmail.c= om> wrote:
I noticed the wiki has been updated and I don't see = all the past information about how work items were dispatched.=C2=A0 I woul= d have expected to at least see a link and have an annotation that it's= no longer being updated.=C2=A0 =C2=A0 I personally found it very helpful (= although, I'm biased because I worked hard to keep it up to date).
=
It is available under update 144, however for anyone else th= at was wondering: https://trac.ietf.org/trac/dispatch/w= iki/WikiStart?version=3D144

It is a good way t= o easily track stats for how proposals were progressed (or not).=C2=A0 I wo= uld periodically go back and update things once WGs were officially formed,= etc.=C2=A0=C2=A0

Regards,
Mary.=C2=A0
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--00000000000060cc0e05cfd7e8ab-- From nobody Wed Nov 3 06:11:02 2021 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 206A63A141F for ; Wed, 3 Nov 2021 06:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.278 X-Spam-Level: X-Spam-Status: No, score=0.278 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, RCVD_IN_MSPIKE_H2=-0.001, 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 iYklg7iyFW11 for ; Wed, 3 Nov 2021 06:10:48 -0700 (PDT) Received: from forward107j.mail.yandex.net (forward107j.mail.yandex.net [5.45.198.252]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CCF13A13F2 for ; Wed, 3 Nov 2021 06:10:48 -0700 (PDT) Received: from forward100q.mail.yandex.net (forward100q.mail.yandex.net [IPv6:2a02:6b8:c0e:4b:0:640:4012:bb97]) by forward107j.mail.yandex.net (Yandex) with ESMTP id 74F5B884AFE for ; Wed, 3 Nov 2021 16:10:45 +0300 (MSK) Received: from vla1-765d064640cd.qloud-c.yandex.net (vla1-765d064640cd.qloud-c.yandex.net [IPv6:2a02:6b8:c0d:90b:0:640:765d:646]) by forward100q.mail.yandex.net (Yandex) with ESMTP id 70F266F40002 for ; Wed, 3 Nov 2021 16:10:45 +0300 (MSK) Received: from 2a02:6b8:c15:2588:0:640:7d99:8720 (2a02:6b8:c15:2588:0:640:7d99:8720 [2a02:6b8:c15:2588:0:640:7d99:8720]) by vla1-765d064640cd.qloud-c.yandex.net (mxback/Yandex) with HTTP id gAOgsH1CWiE1-AiC4BEuY; Wed, 03 Nov 2021 16:10:45 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1635945045; bh=0yJv8PnOuOdVypyF3E3zYU2gNXSgyzSIXS5W6jOBVuA=; h=Message-Id:Date:Subject:To:From; b=q65zTia2+SzjFH5WbICkcl/DhzYvV5FnYMd/GBo3Q3U4oT9pErCTupgQSwyFZz1z/ bL98C5XJjvp1ZYTW9Fda93gl2rd93mQy8FFvCQFtlVTgYFAFl7MCtTAjCDSbK19hHo LNjxBEHEjL/t6lJ7vod0JcRbwmfFbGOLsOfqFvyU= Authentication-Results: vla1-765d064640cd.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Received: by vla3-7d998720c4bc.qloud-c.yandex.net with HTTP; Wed, 03 Nov 2021 16:10:44 +0300 From: Anton Tveretin To: DISPATCH list MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Wed, 03 Nov 2021 18:10:44 +0500 Message-Id: <795681635944901@mail.yandex.ru> Content-Transfer-Encoding: 7bit Content-Type: text/html Archived-At: Subject: Re: [dispatch] draft-secure-credential-transfer-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2021 13:11:00 -0000
Hi All,
I could not figure out what is "mailbox". Where does this term come from? At least, some clarification is needed. Also, it gives some impression that the draft is related to e-mail... but according to the abstract, it doesn't.
Regards,
Anton.
From nobody Wed Nov 3 15:35:18 2021 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 E47003A1367; Wed, 3 Nov 2021 15:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.1 X-Spam-Level: X-Spam-Status: No, score=-3.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-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 (2048-bit key) header.d=ncsc.gov.uk 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 8ctcPU5kqYy5; Wed, 3 Nov 2021 15:35:12 -0700 (PDT) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-cwlgbr01on072e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe14::72e]) (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 015003A1364; Wed, 3 Nov 2021 15:35:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HlGOqKj80Hy41YmNyNytinBA3h+38DptjD0iPlPvB9sOHUDHXxu5Uedq8YqGgTTq3Y0YeEB07FoP8Ql/WMk2gXedjZ7RIvHjaNGB69mbhehx19GfFnVH9oBUGz90yTjaORfLqfzeSjjAihbrD1rq4rrG3vIgCEWNDEfKtY03Wo0uZzNR6QmLL3FYFlmZDPrO28FrsO2WjdYCywNRUe5wN4XmRWmGXT2UNsBiXDRF4EFnNI7ggI6v2lUy0CPrTcxs25iaRZ/kjIHgF7v1k6yUmkixhcNkwNDnRF1QhLvi7nZndrTBa0wMG8P9HPAC0kzQVaiuzgRSUh6kWrkzv0lO4w== 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=hMJB9gv2YLqaS66hWBCzOrvp3/sg+pEPEqWORY+Si3Y=; b=IhiACbKvtnQ204rqoRqvskQ8XLbvOHsCb13IrOetFg0uLjY+EUxeupnSJg53GJAqb7Oj7ab9N9hvdDO9BE3DtfTYez32W6d+QG90ecagQr2Lt9EZzcAytjrXzwA0Igr/1OiL2hor+hxxNRrIZNXjV5Z1Q9vnEh87bnFppoiIL/1q7U4xNc+hAALeUQLzjIU2vtUkgTVDIXPhwQGc5p1gcLT1Q/ZSk2ksw0YshcmupvND8EuyV2b6kdpMtupYg288iTbzHQ1glQM+Gw+evQQtEuIXWLjelr00HGKaVCB2m6u85bpUuWVyaibfbdsUxvp+Ia0HYKIhldyKIpxmXPVQgA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ncsc.gov.uk; dmarc=pass action=none header.from=ncsc.gov.uk; dkim=pass header.d=ncsc.gov.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hMJB9gv2YLqaS66hWBCzOrvp3/sg+pEPEqWORY+Si3Y=; b=08mhq1bz6V3kr9GHGnDJd/blHrUIItZcefE4l+EI/Ukfnpq+WGkW55iFjD18tBtDjKHApGgV4JwyMV+NxWhBP1Hppxp4EyI2q1q1Kc0xqJUeaZaRiFCh/fgvmJmkGUCp9AuxBjfljgLsqi6cOwyPhtJzFILJ20NltIgxrjwgbhNaGl8jBsjqvxZgH2LkRoqF7Wudx9PEp24pv5hhNKHpjDBMgTkEc+3BAAS2HDpp9CRNc1Rkt2l233YR49kS0iruGg79c+K7qE7yllP3zDrcddt5c33Kd7TOO53piRwBGfXvR3/OSeFRN5fKCJGpNXljyksDQyMpYf/EmtbQuByCPw== Received: from LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:12c::10) by LO2P123MB3856.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:143::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4649.15; Wed, 3 Nov 2021 22:35:05 +0000 Received: from LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM ([fe80::91af:a946:6f54:775a]) by LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM ([fe80::91af:a946:6f54:775a%7]) with mapi id 15.20.4649.021; Wed, 3 Nov 2021 22:35:05 +0000 From: Kirsty P To: "dispatch@ietf.org" CC: dispatch chairs Thread-Topic: IETF 112 agenda Thread-Index: AQHX0Nm0hdfkkmdBC0+GKoxsaVHybw== Date: Wed, 3 Nov 2021 22:35:05 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: a34956d7-be1c-5660-70f5-9c7487337935 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ncsc.gov.uk; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c05121cc-8460-4a37-81c1-08d99f1a2ee2 x-ms-traffictypediagnostic: LO2P123MB3856: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5U+GOZ4lmULSr8sBMZpWVSOae/9+DFoVWyYBDZJZS8vvY5UtFyK7gJ1TafAkHe5CeZcgfheIrDCf2x37F+PHh9NmksMHwOn43/HJsnuQmy4oFJu4A3FiLJ0zCsA9PIPrXTILcj/vU/sD42CQ5H0/3cJdJVaiQr81c47+y37ro/6YDrA5p7Q9bAfwvotVWN/ll8uG/RsHqBzsrQu9WbkXI3e7dNWc2qOmtmEpSaDJyjQpxB+QLngwwhI/vtj7/cJl5iidCiYlBGw199RrsaZ0EqegC7IZII5dk1F/4s9vs4SC0YLnWfSuaBaf6wLhfH5CdJ5s6ZnoBChF5l13o83/ZmkaNDqcx6TMCsJ6QRtxdMBtROwfX26Zy0Mk3japh7GFHfJqDgKrDTvcDrhTe+g9SjURUIp9ZYIg4R/IPPhxYE8oP3Mb7g9NZjhLcFR+/q3E+5PLV7osjKg0w2Y/MmoRxr+GNYxQyPRCN3W5vIqnGFYgkWd9jPo8TZihai4tRICJHdZsyTfsar1dkrQkojdUeGC0M611pyogQ7lAUsRKlSLD5Pz4qOUlvSQOmHxKQ6gYqtiYF2/uPe7EN89QwaLvLzp2pVNrkfeSDBo0B/ZOoo5gmX0ES4tvSOPDMihh7UWIs0o8+LytXI1mYKxkDhcbXh0aFdDCRhJQ2mpalBbhxxfJ0MeDvT0xVXtYikMBHlbIRkWeI1t+/lnPq5NvNsSqnx4LMfTdHKX6gP/YjJ4Qd18VgvWgu1ltonyMMIk00NnbnOihErvn2xv0SIFpHox4c9/5Y5F2mlioS6Ie0Dg0uFU= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(66946007)(55016002)(64756008)(83380400001)(122000001)(316002)(4326008)(38100700002)(71200400001)(6506007)(26005)(966005)(450100002)(9686003)(7696005)(76116006)(508600001)(6916009)(66446008)(66476007)(66556008)(186003)(38070700005)(4744005)(82960400001)(52536014)(33656002)(19627405001)(8936002)(2906002)(5660300002)(86362001)(8676002)(7116003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?/Q1ICtefsKkYQVMQTCwEAbLYizExE2ceAkknOPuh7WScGg2iyWi1DK9Jkr?= =?iso-8859-1?Q?WDipYIu7/hBGE2p5hjPJ06JafqezZgK8MkqbSpxvlMkA4Dpoklgig28GY5?= =?iso-8859-1?Q?qQpXQaSGS+7JEs9RgZlOdmNofsbPLmydzi3Q4CHl65rb5CC7yywtcxtreu?= =?iso-8859-1?Q?m7+7XmQdkZmsnNCyVNlzJPQYTzN9bOVTa8AeXTVgbhrelHFiSdQfwMdK9I?= =?iso-8859-1?Q?yd1tOoejj4Ff6pFhtEM1UoyKOWje2P2xXzUz1mWyckP6FvHLVk33u9So0o?= =?iso-8859-1?Q?TeJDTVyPg890pMmI19hycLOHQ3fmhg3WjRn48kJ4giMWIccGFbB+drgv0h?= =?iso-8859-1?Q?cYvLSwYxnC2Xoo9AUsY8U+vD/NJj97aKoHMfz5D5rTiur55Fj7vi66hY39?= =?iso-8859-1?Q?vc66auVvr2G/8c1E+H/DSJen13ePsUrFFO3V73wCywHLCzxPpX9Otz8NT3?= =?iso-8859-1?Q?OTxhBtEpBFeIjLYs9dAlLexXFhTZUazjgDJzvPt9WX8Z4cU7uo+B6O25ub?= =?iso-8859-1?Q?DRWkjOPNpX3xGJgRSiqr2ZtG473Nh03BCesdZMckvu6Juq/i4itD0Dn+4F?= =?iso-8859-1?Q?J1CCpb8lSUgAitzyJt0BvIWmGF9xn4nkCddgwyGHTx6tPWxIzcSfhnXDgZ?= =?iso-8859-1?Q?R9pmEm4EAffnkqU6IkpOiqpEBOzqDM1tdl1tTYR2jF9kq8e/8myg1ds6hK?= =?iso-8859-1?Q?cVLLF9zfAPwlFlQKSle27LkprR+jYEt7g/uGCo08F44cIhaCTz9AJf7vI1?= =?iso-8859-1?Q?fz6ZG9ZZcuyHaBnwogCYGOkUjRmJQ5Q+CuVDgHczh0aQVjtcO0YF6cVvqx?= =?iso-8859-1?Q?Ef0qQfk6c7F1JGn6FxuO8AcmzOc4kqnlLk/zLoclrXTgVnhPMA494ZIoe+?= =?iso-8859-1?Q?rpbZaTnW3k27lqLMrXTFdBOAVC2SHZpqyumGZxBTgEQ3XNjmHq9/sYoXSa?= =?iso-8859-1?Q?vdOjY+4zEZLh5wOWlYqZmQFvom5LjSOzd7IETDtAfCTardjc4b/U8PNAr9?= =?iso-8859-1?Q?je6aKgEezaUHT5jBTYLyqC/LnK7XcirUV1Po0ACtZD2YYhII2Cmf7Zgtz6?= =?iso-8859-1?Q?TuKy+mgJZg5dWD2VOMXv3jDk82hsLRC0W96ga5nsP00aWeukP9hAGOA0OT?= =?iso-8859-1?Q?+Gb8j7PGeckiB9y6Awd5em9+WfeKmj8C6KSu6U0RisdIQgHtltt5bOcod+?= =?iso-8859-1?Q?20n6jeSjxJ2wb4qVFMt3X/ajfnj0UYoI8cup+pQdCnSGEKr7kbSfsJCbYD?= =?iso-8859-1?Q?0AvERJ2cAudsk/ytXffbxfQf5Cki78g2aib2vLQsyaawaS0pyMc5Nc7OII?= =?iso-8859-1?Q?GI4KCCMvfFFxSWI0nSnzRf2nHOb4+q/xBAV/2MMic+KlIEoD7hXmn8lH16?= =?iso-8859-1?Q?OY4xyOqSqJ/Z3kfOQcKKRggPgBsw5yanKPIGAHhQgY6ubyn1JYXpN7qxUW?= =?iso-8859-1?Q?QxMWOAGUwwL+euujfBqizEC2xenE7r/UnyNq9heAyiqbLCupn0khku5/ih?= =?iso-8859-1?Q?QYIeuYxFApwBXEQnuNKXsqrW8xNNUL+DxvWnBlKL1c8dTeXI+6EZoefju+?= =?iso-8859-1?Q?tJH0qeqhzFvGmhzjB1rELOxhVWj+8YrguX7aDcqexi+6dXRGBdXTUTupjM?= =?iso-8859-1?Q?SISiOT3HdeyhYtSYnGBkVMU8/5uGkCvM2QNjrkoDk/FODw/yhtdVeU2Q?= =?iso-8859-1?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_LO2P123MB35997CAE0F4CEA10B4BF76A8D78C9LO2P123MB3599GBRP_" MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: c05121cc-8460-4a37-81c1-08d99f1a2ee2 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2021 22:35:05.3570 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: BCtq8HgaTsj0a45uUPQRfos+9c5etBcKwjjbD96QB2+whXxGIqTypzF1VGa5m2J5pTjOtGf9/wlxe88u0bKuTg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB3856 Archived-At: Subject: [dispatch] IETF 112 agenda X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2021 22:35:17 -0000 --_000_LO2P123MB35997CAE0F4CEA10B4BF76A8D78C9LO2P123MB3599GBRP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi dispatchers, With apologies for the lateness of this agenda release, our draft agenda fo= r IETF 112 is now up - please let the chairs know of any corrections or omi= ssions: https://datatracker.ietf.org/meeting/112/materials/agenda-112-dispatch-01.t= xt We'll update the list if it's updated, but if you want to check for your ow= n peace of mind, you can always find the latest agenda at: https://datatrac= ker.ietf.org/doc/agenda-112-dispatch/ Kirsty & Patrick This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LO2P123MB35997CAE0F4CEA10B4BF76A8D78C9LO2P123MB3599GBRP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi dispatchers,

With apologies for the lateness of this agenda release, our draft&nbs= p;agenda for IETF 112 is now up - please let the chairs know of any corrections or omissions:
https://datatracker.ietf.org/meeting/112/materials/agenda-112-dispatch-01.t= xt

We'll update the list if it's updated, but if you want to check for your ow= n peace of mind, you can always find the latest agenda at: https://datatracker.ietf.org/doc/agenda-112-dispatch/

Kirsty & Patrick



This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LO2P123MB35997CAE0F4CEA10B4BF76A8D78C9LO2P123MB3599GBRP_-- From nobody Thu Nov 4 02:59:26 2021 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 B55853A0DD7 for ; Thu, 4 Nov 2021 02:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWI9TlVizgCx for ; Thu, 4 Nov 2021 02:59:21 -0700 (PDT) Received: from mail-oo1-xc35.google.com (mail-oo1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (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 DD2D73A0DB9 for ; Thu, 4 Nov 2021 02:59:21 -0700 (PDT) Received: by mail-oo1-xc35.google.com with SMTP id a17-20020a4a6851000000b002b59bfbf669so1733417oof.9 for ; Thu, 04 Nov 2021 02:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=+QlW38iC6pm4zDd7brmKu5B+fVuKKGAI7WTnP/jCnIg=; b=hHVonNZDhmis6GNEvbh6v3rNOD54WH72kFIkH6FzDNFFGKN2kfSCBok7uN3X9ni9JM rXo1NtRc8x0lnCTZ5HoZZss50jLiABwR2g8Vh2XJmqLupVbvz3aYOWHx7WWTZKChWZsh hfWEh4bKzUYuc6kyVoTe2SEa6qNSQ+fZTnBH0pBeZ6BvjZ44eh6wGD3SriL7Pu6nEJWI W4RlzLPwjVVW0iz21+7T5N73BCVCj+v3ZfMSQqZewcUpsSn5wjzThwJcw8/sS9VqV7Pg LCTpvQxRn7EhTzbEflqjKC9lzokD80WGDLSRLUVrBp5rTuKA0hNcsEIiDYwFwA9FxfJS Dx/w== 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; bh=+QlW38iC6pm4zDd7brmKu5B+fVuKKGAI7WTnP/jCnIg=; b=fyDvWG43wQc7CLh0hxTaj7Xg7d0eQKxSeLmTS84VurejSybE4qoiibUtah3XZg3cKz 2s9vkabSWmNXsBz8EXp/vo4V7V5RrNG0JyymCePH32afi/wZwjS5Gj4TrLz9n7Ir3TfD 6j0c6YSB/UMiYEDO0MTawCisQRb/pEoOUeGLlYAFfD9M0jVNQa1Ihu7KYIAQIPxf1+yi FcyQQNgbdXMSa3XpTrJJxYiD7l+hjhpwC2JuaPZFLJg9QTcfxdPSTHaBhouxfbW62KLc VpoDC/EzYhrEz0wZWbE+po+Ms5CuchhYIzDYVJvNWU3fnHRikG5jcUsG74zNCYvVg9a3 Mn4w== X-Gm-Message-State: AOAM530eFVnOXqXbYILYbqOiBt1DH37PAnAl6cK0IWMJ0Fr/+7KvdbYC ey53Le6N8pN/OfWuDyJGcI5d96PtnD/za8gKmAGDv8OnIQnF7g== X-Google-Smtp-Source: ABdhPJyKveUa+NgqU4Re119ba2YPvzlQBnU4kzsF7Mh5boyNE3NoWXgGZjKGXW3+/w2ouopT0apS0lKAwQf+J8N2og8= X-Received: by 2002:a4a:b801:: with SMTP id g1mr2821474oop.41.1636019960059; Thu, 04 Nov 2021 02:59:20 -0700 (PDT) MIME-Version: 1.0 From: Ted Hardie Date: Thu, 4 Nov 2021 09:58:54 +0000 Message-ID: To: Dispatch WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [dispatch] draft-secure-credential-transfer 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, 04 Nov 2021 09:59:25 -0000 As it looks like I will not be able to attend DISPATCH because of the clash with MASQUE, some questions on this draft. First, this motivating text confuses me a bit: Today, there is no standard way of transferring digital credentials securely between two devices belonging to the same platform or two different platforms. This document proposes a solution to this problem by introducing a Relay server which allows two devices to exchange encrypted Provisioning Information securely. The Relay server solves this problem by creating and managing temporary mailbox storage. Based on the rest of the draft, I believe the idea here is that digital credentials being sent in a simple way like and email titled "Here's my public key, Alice" don't meet the need because the result is not machine readable by the systems which would need to associate the credential with a mailbox. Is that correct, or have I missed the point here? If this is the case, you may want to reconsider whether "device" is the right unit of discussion, since even mobile devices can have multiple personae, accounts, and so on. (Think of the Android work profile example). If it is not, then your document needs a good bit of work to rethink some core elements (as an "account claim" would potentially involve more than two devices, since accounts are often on multiple devices). If device is the unit of discussion, I think the use case here needs to be spelled out a bit more, as the privacy and security considerations might be a bit different. (The "Send the secret out of band" bit of this is part of what's hard to resolve with the device-based unit of discussion, but I may be misunderstanding this). I think the security and privacy aspects of this need a fair amount of work, as there are a lot of aspects that can't be verified in the protocol as set out. That leads me to suggest that the answer to the DISPATCH question is that this needs a working group, with both APPs and Security folks involved. On the APPS side, it would be helpful to have folks who dealt with things like the IMAP URLAUTH (aka "pawn ticket") approach, as well as folks with an HTTP background. regards, Ted From nobody Fri Nov 5 11:12:45 2021 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 58EE53A1327 for ; Fri, 5 Nov 2021 11:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79AR3sUFoc2E for ; Fri, 5 Nov 2021 11:12:39 -0700 (PDT) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 EA75D3A1330 for ; Fri, 5 Nov 2021 11:12:38 -0700 (PDT) Received: by mail-oi1-x236.google.com with SMTP id q124so15810535oig.3 for ; Fri, 05 Nov 2021 11:12:38 -0700 (PDT) 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=ALy4QeCJ2sAjFPCB35dwtqYrL5e/hzDG5CUUqDiBaGo=; b=iZQdwSOjVctxAkegqGyK/huS/9pfnCIrrGwVyKvI6WTIqC3PxjiKU+eRZyzdNoiqSx 8pBwytFmVZn3MujwNqDKPxsr1mDzOWOApNKQAb6k5XDlMzcFXd1Qb5vRySjEtJf6x+rn 1uFjIUcjtN7pvKE1pNbmXNoecxHNrCS83fGc6OKDQvzxqTFYCiN9gOAtlkxwBx+PXHhp 6TqMz9HZXIbom6GmVE++ORqptHThzb7WCKuT3gVYW2JwJ6aZzeR3FJDAbC596DWPFII3 Dml2jSgmyCuIQsy9Sjh9ZRq7In+edAv56xWBi75YaDinVMy66VSn1UJl2op+xaHA7ns7 jCdA== 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=ALy4QeCJ2sAjFPCB35dwtqYrL5e/hzDG5CUUqDiBaGo=; b=j/Rc0noO+ITyMtbQ2WDQtE/tzKW+f5FlG7/BLWM7/RMaGbcMkvn/lS6FSzAGOYGrnL cG5PCfVOqDIeoiudz1zlA4JrF+DakHRTVIgKkTG2U5em9xnVgc9QVKaKlqLjaYU5b8W4 qjF3AQbp+slfdwe0+lP/rukAklb+QecWIvkCjxkPsbQsgHpGCkUNb6Vujdr5I4MbrSZa X+6TzORPCgtRqbVMDN/6exPhs28gOFRaLHd0QajpF4GSQEsFEviCf5nej7HDkudC/RTi b7RmX0q6/DgTOO65Ovi/81yXIIjfTz+E91urCg/LcAR07rGB9BuSRPnsMZT5Nq3jkIRz E8+A== X-Gm-Message-State: AOAM533no2Rbmwvuqx6bPq1pBUoAP6Wd2pOh4V8sHQ9sJFSvEABx23s3 4o/4Xuy2n9vscneN8ta3EBT+mtwAFXLjvBcSSWmLCGQ5vl8= X-Google-Smtp-Source: ABdhPJxSBIXyjS68lQicuoDNBoZ2UGuskd1VbhK8fsTXCD/hITxLVuys/0qEQZasiWaHmZqrp2AzlJ0luHKycwSPkMc= X-Received: by 2002:a05:6808:988:: with SMTP id a8mr14470490oic.114.1636135957111; Fri, 05 Nov 2021 11:12:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mary Barnes Date: Fri, 5 Nov 2021 13:12:26 -0500 Message-ID: To: Patrick McManus Cc: DISPATCH Content-Type: multipart/alternative; boundary="00000000000087270d05d00e962d" Archived-At: Subject: Re: [dispatch] Updated wiki - where's the history of proposal dispatchments? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2021 18:12:44 -0000 --00000000000087270d05d00e962d Content-Type: text/plain; charset="UTF-8" Yeah, it makes total sense to update the wiki to more accurately reflect how things currently work and reflect the style of the WG chairs. I wasn't challenging that. And, yes, DISPATCH doesn't work like other WGs and the tools are not geared towards such. As you note, minutes are a snapshot in time and thus are not nearly sufficient to really know what happened to an agenda topic beyond that specific time. The tools aren't geared towards facilitating workflow for WGs like DISPATCH. For one, you can't go to the datatracker or Tools page and see all the drafts that have been submitted. If people submitted the drafts with the -dispatch in the file name then that would help, but it's rare that someone does that. And, yes, you can search the filename in Datatracker and find the draft. However, in the case of documents that go to a WG, unless someone makes sure to indicate that it's replacing the draft submitted for discussion in the DISPATCH WG, you've lost the linkage and ability to use tools to track the draft. And, of course, many items aren't discussed based on a draft(s). For example, when a topic is submitted for discussion and the WG decides to charter a mini-WG, you have to do some digging and correlate mailing list discussion to know ultimately the WG name. And, the reality is that while we say decisions happen on the WG mailing list, for DISPATCH in my experience it's not usual to go back to the mailing to confirm all the decisions made in the meeting, nor following up on how topics were actually dispatched. In the case that a draft will be AD sponsored, again without the -dispatch in the name you don't have a quick place to go to see that's the case. And, of course, there are times when the minutes might suggest something will be AD sponsored, but of course, it's up to the ADs ultimately whether they do. Certainly, everyone can Google, search mailing list archives, etc. and figure this stuff out. But, that ends up being a whole lot more effort than a single person (e.g., WG chair or secretary) doing this task after every meeting and having that one person track the work and keep the wiki updated. It really isn't that time consuming if you do it as you go along and of course, the chair already has a much better idea of what's happened to things over time than the average participant. Now, perhaps I'm more sensitive to this issue having worked in IETF way too long, but when I first started trying to follow WGs, the tools were barebones and it took some time to track things, which I did manually for all the WGs I was following. We often talk about how to get new folks engaged. I can't fathom coming into IETF as a newcomer and being able to fully understand how work progresses through DISPATCH WG. Also, for a new person being able to quickly see items that might have come and know where they've gone can also be helpful. That was the objective of tracking that information in the wiki and that gives you the similar summary of deliverables that the WG accomplished that you get with the Datatracker for regular WGs. As an example, I didn't realize until I was making a pass at updating the historical information and saw that one of the items that the WG had decided not to progress had actually been published via the ISE. While that's not listed as an option for DISPATCHing, it actually is and so seeing that might be helpful to someone. As someone that hasn't been following DISPATCH too closely of late, if I were interested to see how things have gone, I know it would take me some time to gather that information. To me, it's valuable to the community overall to have a single person track and document that as opposed to having anyone new come in and have to do the work themselves. So, perhaps this is a good opportunity to bring a WG secretary since DISPATCH no longer has 3 WG chairs. Regards, Mary. On Tue, Nov 2, 2021 at 7:58 PM Patrick McManus wrote: > Hi Mary, > > Yes, the wiki has been updated to focus a little bit higher in the stack > than before. We wanted to focus on being an introductory point for new work > in the art area to help folks navigate their way towards an outcome (a > successful dispatch!). Minutes and updates to the list are hoped to be > sufficient for documenting the work product at this point -- Kristy and I > think that with a different focus than a traditional WG (with milestones > and what not) the emphasis makes sense. > > I hope that this focus will continue to evolve and reflect the changing > needs of dispatch over time. > > -Patrick > > On Thu, Oct 28, 2021 at 2:16 PM Mary Barnes > wrote: > >> I noticed the wiki has been updated and I don't see all the past >> information about how work items were dispatched. I would have expected to >> at least see a link and have an annotation that it's no longer being >> updated. I personally found it very helpful (although, I'm biased >> because I worked hard to keep it up to date). >> >> It is available under update 144, however for anyone else that was >> wondering: https://trac.ietf.org/trac/dispatch/wiki/WikiStart?version=144 >> >> It is a good way to easily track stats for how proposals were progressed >> (or not). I would periodically go back and update things once WGs were >> officially formed, etc. >> >> Regards, >> Mary. >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > --00000000000087270d05d00e962d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah, it makes total sense to update the wiki to more accu= rately reflect how things currently work and reflect the style of the WG ch= airs.=C2=A0 I wasn't challenging that.=C2=A0

And, yes,=C2=A0 DISPATCH doesn't work like other WGs and t= he tools are not geared towards such.=C2=A0=C2=A0


<= p class=3D"gmail-p1" style=3D"margin:0px;font-variant-numeric:normal;font-v= ariant-east-asian:normal;font-stretch:normal;line-height:normal;font-family= :Helvetica">As you note, minutes are a snapshot in time and thus are not ne= arly sufficient to really know what happened to an agenda topic beyond that= specific time.=C2=A0 =C2=A0=C2= =A0The tools aren't geared towards facilitating workflow for WGs= like DISPATCH.=C2=A0=C2=A0For one, you can't go to the datatracker or Tools page and see all t= he drafts that have been submitted.=C2=A0=C2=A0If people submitted the drafts with the -dispatch in= the file name then that would help, but it's rare that someone does th= at.=C2=A0=C2=A0And, yes,= you can search the filename in Datatracker and find the draft. However, in= the case of documents that go to a WG, unless someone makes sure to indica= te that it's replacing the draft submitted for discussion in=C2=A0=C2=A0the DISPATCH WG, you= 9;ve lost the linkage and ability to use tools to track the draft.=C2=A0 =C2=A0

And, of course, many items aren't discussed based on = a draft(s). For example, when a topic is submitted for discussion and the W= G decides to charter a mini-WG, you have to do some digging and correlate m= ailing list discussion to know ultimately the WG name.=C2=A0 And, the reality is that while we say = decisions happen on the WG mailing list, for DISPATCH in my experience it&#= 39;s not usual to go back to the mailing to confirm all the decisions made = in the meeting,=C2=A0nor following up on how topics were actually dispatche= d.=C2=A0


In the case that a draft will be AD sponsored, again without t= he -dispatch in the name you don't have a quick place to go to see that= 's the case.=C2=A0 And, of course, there are times when the minutes mig= ht suggest something will be AD sponsored, but of course, it's up to th= e ADs ultimately whether they do.=C2=A0=C2=A0


Certainly, everyone can Google, search mailing list archives, = etc. and figure this stuff out.= =C2=A0 But, that ends up being a whole lot more effort than a single= person (e.g., WG chair or secretary) doing this task after every meeting a= nd having that one person track the work and keep the wiki updated.=C2=A0 It really isn't that = time consuming if you do it as you go along and of course, the chair alread= y has a much better idea of what's happened to things over time than th= e average participant.


Now, perhaps I'm more sensitive to this issue having worke= d in IETF way too long, but when I first started trying to follow WGs, the = tools were barebones and it took some time to track things, which I did man= ually for all the WGs I was following.=C2=A0 We often talk about how to get new folks engaged. I ca= n't fathom coming into IETF as a newcomer and being able to fully under= stand how work progresses through DISPATCH WG.=C2=A0=C2=A0Also, for a new person being able to quic= kly see items that might have come and know where they've gone can also= be helpful.=C2=A0 =C2=A0That was the objective of tracking that informatio= n in the wiki and that gives you the similar summary of deliverables that t= he WG accomplished that you get with the Datatracker for regular WGs. =C2=A0 As an example, I didn&= #39;t realize until I was making a pass at updating the historical informat= ion and saw that one of the items that the WG had decided not to progress h= ad actually been published via the ISE.=C2=A0 While that's not listed as an option for DISPATCH= ing, it actually is and so seeing that might be helpful to someone.=C2=A0 =C2=A0

As someone that hasn't been following DISPATCH too closely o= f=C2=A0late, if I were=C2=A0 interested to see how things have gone, I know= it would take me some time to gather that information.=C2=A0 =C2=A0=


To me, it's valuable to the community= overall to have a single person track and document that as opposed to havi= ng anyone new come in and have to do the work themselves.=C2=A0 So, perhaps this is a go= od opportunity to bring a WG secretary since DISPATCH no longer has 3 WG ch= airs.=C2=A0 =C2=A0


Regards,

Mary.=C2=A0


On Tue, Nov 2, 2021 at 7:58 PM Patrick McManus <mcmanus@ducksong.com> wrote:
Hi Mary,

Yes, the wiki has been updated to focus a little bit high= er in the stack than before. We wanted to focus on being an introductory po= int for new work in the art area to help folks navigate their way towards a= n outcome (a successful dispatch!). Minutes and updates to the list are hop= ed to be sufficient for documenting the work product at this point -- Krist= y and I think that with a different focus than a traditional WG (with miles= tones and what not) the emphasis makes sense.

I ho= pe that this focus will continue to evolve and reflect the changing needs o= f dispatch over time.

-Patrick
=
On Thu= , Oct 28, 2021 at 2:16 PM Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
I= noticed the wiki has been updated and I don't see all the past informa= tion about how work items were dispatched.=C2=A0 I would have expected to a= t least see a link and have an annotation that it's no longer being upd= ated.=C2=A0 =C2=A0 I personally found it very helpful (although, I'm bi= ased because I worked hard to keep it up to date).

It is= available under update 144, however for anyone else that was wondering: https://trac.ietf.org/trac/dispatch/wiki/WikiStart?versio= n=3D144

It is a good way to easily track stats= for how proposals were progressed (or not).=C2=A0 I would periodically go = back and update things once WGs were officially formed, etc.=C2=A0=C2=A0

Regards,
Mary.=C2=A0
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--00000000000087270d05d00e962d-- From nobody Sat Nov 6 16:53:32 2021 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 101B53A1318 for ; Sat, 6 Nov 2021 16:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ducksong.com header.b=piCD45HI; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=E54oppyy 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 MXE8QzgLEsWN for ; Sat, 6 Nov 2021 16:53:25 -0700 (PDT) Received: from outbound2k.ore.mailhop.org (outbound2k.ore.mailhop.org [54.148.219.64]) (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 7C4AE3A1316 for ; Sat, 6 Nov 2021 16:53:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1636242805; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=n5G32OTtxCOgQeV11vdPs5lPFTvEEOx3hUPeSSYWSi5VVM01fuSya/qxVkw4zaz+bVTE89Ui6kK1a jGie0M1SSx1B9RkcI39ZC3HD7cObXTVRuzJnsDcGh87ONfvjdY+p7APbJ0B/Xpr+XADY8hkjU4ku2K ddqPAjr14B9tRBR1JYpPWsDc4l8ZcvLg4Gnfyp/KKhmI8hHmzaKQztbDFjrxpkkr0OaZVfaXyvuUdc Ah9hkhgfkyszo9N5B+LzKxYLyFMbOT3TQqq7IvvKjeraDFjgb0hqAg7XJ849wwLVOlrBh/mNer9A93 3WDzNEHlKsqgGROGTTOIPvFWVu887Mg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=OOQcwpIVtEQlHSHC1Iaz6XANMMcXl9/FvIzs/cO3cg4=; b=VR/+h67OjmEdJi5SCXCr2v2j0fKkr/gK6uwsY9bIC9pfX6T+p0YKMPCeQSDNTyTN05jR4tmKjv7Vl kBYOTAP2jdh93br3Z4nCLWOjQwJ1x9A1i9zccd90iYamFNxgCz3uLwrwsGF+3g3qwfl4tJ7V1LNRB2 7YmDReoTbuHhjn4o460IQ2xYacI4QfaHrw4aT85cxIBLDXuqEIpL7YLpYSfUWvlHNlNPy0vZhF2gbs TmeF/M/VbxjWqZrnJkf9hg7yIMsIQ0f722WTOHj8pDKUqUUpOl6kvDxVKOfkH6R9VDXP1aWnXmKgTt rP0FGTxmLkXiXWzq0sRuxPZQ6EGWXSQ== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.210.52; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=OOQcwpIVtEQlHSHC1Iaz6XANMMcXl9/FvIzs/cO3cg4=; b=piCD45HIln4KmeCESLzROPpUYVe/Ij/GWLSNbg4+1e2QugqT1VdUvawGaiATYPrm+ox7wXck7yM7R 2b1M8PtdVCWWB+K/XO8m6Zjw6stOTWp6cGPH4EdqgjM6L8FeyjcdpE8qB2Br/UKy2+7nZX1rHSZdsg /Y/lOimth9IDfg7o= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=OOQcwpIVtEQlHSHC1Iaz6XANMMcXl9/FvIzs/cO3cg4=; b=E54oppyyUlXAlhqiorYcu36yNigrlmatzKD+c3C1WyCr8ZROyI82fDeHqHvng+tuBsbKZEO8MkxwU /4o03R9FQzGkbPi08n7Xr7IzhuR4irYEkFRbr8HwqZ0OB4zyFlKFxHjiJrEuxXnPrQUPw8kMtXE85U cFpiJK5ofSofQGI5T3u4AQaIWmHs+ybnZHQTMUtvGCxM0ujm9tXjoz7TIXbAI9DYPrQeyJspHwMTVo Nf78Vi83cEe2eWM0oVaVMsab4UcOcivkTR0eJAGjArUpWdqhq++Fww8iX0G7seuiBt4MwtFJQpvxjb hv5sXV/8rF5jMK4JiKm50YAzmNfZRPQ== X-Originating-IP: 209.85.210.52 X-MHO-RoutePath: bWNtYW51cw== X-MHO-User: ba65d835-3f5c-11ec-a67d-89389772cfc7 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Mail-Handler: DuoCircle Outbound SMTP Received: from mail-ot1-f52.google.com (mail-ot1-f52.google.com [209.85.210.52]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id ba65d835-3f5c-11ec-a67d-89389772cfc7; Sat, 06 Nov 2021 23:53:24 +0000 (UTC) Received: by mail-ot1-f52.google.com with SMTP id h12-20020a056830034c00b0055c8458126fso266942ote.0 for ; Sat, 06 Nov 2021 16:53:24 -0700 (PDT) X-Gm-Message-State: AOAM533qM8KSPC8PkgzlQIwlHyjQDLvsKZM3DpAapYNkaZYsSHPyu0Rt d8E5137k56HIVTn6koZyLj8v0EvT7dMG4BhtsqI= X-Google-Smtp-Source: ABdhPJwgEYBEMnNO8hu1VX3ttK0uSVruyzzAhuXwUElO2Qgh4e3XQ7zll7WbjMldP6hRrF6+G0bX40afHtBsrqF8DcY= X-Received: by 2002:a9d:5c2:: with SMTP id 60mr5711485otd.104.1636242803605; Sat, 06 Nov 2021 16:53:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Patrick McManus Date: Sat, 6 Nov 2021 19:53:12 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Mary Barnes Cc: Patrick McManus , DISPATCH Content-Type: multipart/alternative; boundary="0000000000001346e005d027770b" Archived-At: Subject: Re: [dispatch] Updated wiki - where's the history of proposal dispatchments? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2021 23:53:30 -0000 --0000000000001346e005d027770b Content-Type: text/plain; charset="UTF-8" Thanks for the thoughts Mary. We'll make sure to include them in our post 112 discussion with the ADs. Less important than the big picture, I did want to make a note about one point: WG had decided not to progress had actually been published via the ISE. While > that's not listed as an option for DISPATCHing, it actually is and so > seeing that might be helpful to someone. > That's a fine line though, right? The iSE is, by definition, Independent. We cannot dispatch things to the ISE. OTOH, work that might not have a home in the IETF might have a home with the ISE (as this one did!) and it makes sense for folks to be aware of that if they are looking for other avenues to pursue (similarly there are other SDOs, or just publishing it on a blog or in a public github repo, etc..). That's just being helpful. But there isn't much dispatch can (or should imo) do to facilitate or track that. It's out of our hands. --0000000000001346e005d027770b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the thoughts Mary. We'll make sure to = include them in our post 112 discussion with the ADs.

<= div>Less important than the big picture, I did want to make a note about on= e point:

=C2=A0WG had decided no= t to progress had actually been published via the ISE.=C2=A0 W= hile that's not listed as an option for DISPATCHing, it actually is and= so seeing that might be helpful to someone.=C2=A0 =C2=A0

That's a fine line though, right? The= iSE is, by definition, Independent. We cannot dispatch things to the ISE. = OTOH, work that might not have a home in the IETF might have a home with th= e ISE (as this one did!) and it makes sense for folks to be aware of that i= f they are looking for other avenues to pursue (similarly there are other S= DOs, or just publishing it on a blog or in a public github repo, etc..). Th= at's just being helpful. But there isn't much dispatch can (or shou= ld imo) do to facilitate or track that. It's out of our hands.

--0000000000001346e005d027770b-- From nobody Sun Nov 7 11:04:10 2021 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 0D0893A1162 for ; Sun, 7 Nov 2021 11:04:09 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 sVrP2GDkYSfK for ; Sun, 7 Nov 2021 11:04:04 -0800 (PST) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 819B33A1160 for ; Sun, 7 Nov 2021 11:04:04 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id x10so2515699ioj.9 for ; Sun, 07 Nov 2021 11:04:04 -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=Tw6ED5i1AFRvusEDZwil0DxXrSInYDr2zNhcfoGurEY=; b=Hwa1fr78xaAHtAFH4k3ZYqdErCRNJfRAEQ1UczNqYs1SoHDSL+kUTIMOEYG7fwM9On t7IkcstnQkV7MMzlkvPw5q1afdg1m/N2cQJK0R8Y8UhjM3MSCS8KS/2bwzRrtVus4RIf NaVjCd4P1g6OWfoIEGqfMQL9PYB7i6lKjR/IVPHKQxq1jM8bqt1rbCbZFP6Rx5ugEZGi oviahr0NSf0hYcjTr+hyu1Cekz5xJCMA683euIbidtoV9ZIZ17UFYez0Ir1fFL39dbQH 8i3Os+jYv5Gcni+ru3EJKdZQuBI/l0BuPO3xjQ66/I6QnwJge4/YuDGIYOe8LdJdHOYq yaUw== 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=Tw6ED5i1AFRvusEDZwil0DxXrSInYDr2zNhcfoGurEY=; b=tgdzhG8dSoHY+PoyRYV5IgMH5eOM8iJh7ROtmyvioms5gLBgbncnLNFjjRXvsmqY5F EgBun8SlzNmCThFP+6mbK/1/c0kKs9Lwj/WIzNNCtkdnl0RPg0kh9p1td7LHPxjY7hv6 jW91/APSaQuccqQ4C+ZYwSdJhypeposktMOZWmutK20bJP+aVesqQPOp/NrNbRLtY81k euDwYENqMbaR3MoN2dZjUccag0HHtAp4HtlY2LdwCBKN9HVJypZkiPxHc+yTXzgrLbB6 kZlpDyGYHYZquQ6Z1eK/X+fkeGMf/0somDzUXivSb3/rZOf1bMmcSlCfuD9gWJCQqPQw 4ASQ== X-Gm-Message-State: AOAM532mkyVZam/zftkWQ6FDpQtIFZOYAg8R7dMavdDZF/dtGEtgqLFu ogXUOECj4d//lr8WsQUP/0z25rh/gGnXRH/qEzKOJg== X-Google-Smtp-Source: ABdhPJwo8Mt5CmPBXp6IJIECZG2oAXotniHOpTYePOUrfNQ3fGZLhrvgp8o2V7XN3hQlu7wto1fyH2AQsgZUwmGooB4= X-Received: by 2002:a05:6638:24ca:: with SMTP id y10mr15319197jat.109.1636311842921; Sun, 07 Nov 2021 11:04:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Sun, 7 Nov 2021 11:03:27 -0800 Message-ID: To: Matthew Byington Cc: DISPATCH , Dmitry Vinokurov , Matthias Lerch , Nick Sha , Crystal Qin , Ben Chester Content-Type: multipart/alternative; boundary="00000000000023b39905d0378aae" Archived-At: Subject: Re: [dispatch] Discussion and Schedule for draft-secure-credential-transfer-01 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, 07 Nov 2021 19:04:09 -0000 --00000000000023b39905d0378aae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have reviewed this draft. I have provided a number of technical comments below, but to answer the relevant DISPATCH questions: 1. I do not think that this work is ready for IETF. You present a specific technical solution. I have concerns about that solution, I but I also don't really understand the requirements. If we were to work on this, I think we'd first need to see them laid out. 2. Once that happens, this should probably go to SECDISPATCH. OVERALL COMMENTS I'm having trouble understanding the threat/deployment model of this system. As I understand the situation for the simple case: - The sender generates a random Secret and uses it to encrypt the credential for the Receiver. - The sender stores the encrypted credential on the Relay server, and learns the URL (provided by the server) - The sender sends the Secret and the URL to the receiver via some (unspecified) secure channel. My first question here is why the sender doesn't just use the secure channel that it uses to send the Secret/URL to the receiver to send the credential? These credentials don't generally seem that large. I don't really think it's a reasonable assumption that you have this kind of secure channel. Indeed, establishing peer authentication and shared cryptographic keys seems like the most challenging part of this entire space, so it's somewhat odd to just assume a solution. As a concrete example, a huge fraction of the complexity in Firefox Sync is associated with trying to bootstrap a relatively short secret into a strong encryption key. Therefore, I think this document really does need to try to address this point; it may also turn out that once you have, you have also solved whatever problem motivated the use of the Relay. I'm not sure why you are defining a specific API for this system; the Relay seems primarily responsible for allowing one side to store values and the other side to receive them. What functionality does it require that couldn't be provided via WebDAV [RFC 4918]. I see two main pieces: - Creation of the URL. This seems like it could be done by the client. - Notification. This is a useful function, but seems separable into a distinct notification server. This comment also applies the the Mailbox-Correlation-ID, which seems like it could just be in the URL. DETAILED COMMENTS - It's not clear to me why the URL has to be secret. Is this an access control measure because it is intended as a capability URL? Presumably the Secret is sufficient to protect against decryption. - A lot of the metainformation seems to be in the clear rather than encrypted. This seems very unsafe, as one could mount cut-and-paste attacks. - Instead of inventing your own encrypted payload format, why not just use CBOR or JOSE? - In the stateful case, it's not clear to me what prevents substitution attacks. For instance, can the Relay take the sender's first message and provide it to the receiver as the sender's third message? Is this just down to the internal message context? If so, that's pretty brittle. On Fri, Oct 22, 2021 at 11:31 AM Matthew Byington wrote: > Hello Dispatch, > > Recently, we published a new draft to IETF entitled > "draft-secure-credential-transfer=E2=80=9D. > > The current revision is 01. > > I am sending this email to the Dispatch distribution in order to kick off > a discussion around the draft, and establish the appropriate working grou= p. > > The working group may be an existing working group or we may endeavor to > create a new one. If the dispatch team could assist us with this decision > that would be great. > > A link to our draft is here: > https://www.ietf.org/archive/id/draft-secure-credential-transfer-01.html > > The required participants for the initial discussion would be, at a > minimum, the full list of authors: > > Dmitry Vinokurov > Apple Inc > Email: dvinokurov@apple.com > > Matt Byington > Apple Inc > Email: mbyington@apple.com > > Ben Chester > Apple Inc > Email: bchester@apple.com > > Matthias Lerch > Apple Inc > Email: mlerch@apple.com > > Crystal Qin > Alphabet Inc > Email: crystalyq@google.com > > Adam Bar-Niv > Alphabet Inc > Email: adambn@google.com > > Nick Sha > Alphabet Inc > Email: nicksha@google.com > > Thank you, > Matt Byington > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --00000000000023b39905d0378aae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I have reviewed this draft. I have provided a number o= f technical
comments below, but to answer the relevant DISPATCH question= s:

1. I do not think that this work is ready for IETF. You present a=
=C2=A0 =C2=A0specific technical solution. I have concerns about that so= lution, I
=C2=A0 =C2=A0but I also don't really understand the requir= ements. If we were to
=C2=A0 =C2=A0work on this, I think we'd first = need to see them laid out.

2. Once that happens, this should probabl= y go to SECDISPATCH.


OVERALL COMMENTS
I'm having trouble = understanding the threat/deployment model of
this system. As I understan= d the situation for the simple case:

- The sender generates a random= Secret and uses it to encrypt
=C2=A0 the credential for the Receiver.
- The sender stores the encrypted credential on the Relay server,
= =C2=A0 and learns the URL (provided by the server)

- The sender send= s the Secret and the URL to the receiver via
=C2=A0 some (unspecified) s= ecure channel.

My first question here is why the sender doesn't = just use the
secure channel that it uses to send the Secret/URL to the r= eceiver
to send the credential? These credentials don't generally se= em
that large.


I don't really think it's a reasonable= assumption that
you have this kind of secure channel. Indeed, establish= ing
peer authentication and shared cryptographic keys seems like
the = most challenging part of this entire space, so it's somewhat
odd to = just assume a solution. As a concrete example, a huge
fraction of the co= mplexity in Firefox Sync is associated with
trying to bootstrap a relati= vely short secret into a strong
encryption key. Therefore, I think this = document really does
need to try to address this point; it may also turn= out that
once you have, you have also solved whatever problem motivated=
the use of the Relay.


I'm not sure why you are defining = a specific API for this
system; the Relay seems primarily responsible fo= r allowing
one side to store values and the other side to receive them.<= br>What functionality does it require that couldn't be provided
via = WebDAV [RFC 4918]. I see two main pieces:

- Creation of the URL. Thi= s seems like it could be done by the client.

- Notification. This is= a useful function, but seems separable
=C2=A0 into a distinct notificat= ion server.

This comment also applies the the Mailbox-Correlation-ID= ,
which seems like it could just be in the URL.


DETAILED COMM= ENTS
- It's not clear to me why the URL has to be secret. Is
=C2= =A0 this an access control measure because it is intended
=C2=A0 as a ca= pability URL? Presumably the Secret is sufficient
=C2=A0 to protect agai= nst decryption.

- A lot of the metainformation seems to be in the cl= ear
=C2=A0 rather than encrypted. This seems very unsafe, as one
=C2= =A0 could mount cut-and-paste attacks.

- Instead of inventing your o= wn encrypted payload format,
=C2=A0 why not just use CBOR or JOSE?
- In the stateful case, it's not clear to me what prevents
=C2=A0 = substitution attacks. For instance, can the Relay take
=C2=A0 the sender= 's first message and provide it to the receiver
=C2=A0 as the sender= 's third message? Is this just down to
=C2=A0 the internal message c= ontext? If so, that's pretty brittle.
=C2=A0



<= br>
On Fri,= Oct 22, 2021 at 11:31 AM Matthew Byington <mbyington=3D40apple.com@dmarc.ietf.org> wrote:
=
Hello Dispatch,

Recently, we published a new draft to IETF entitled "draft-secure-cred= ential-transfer=E2=80=9D.

The current revision is 01.

I am sending this email to the Dispatch distribution in order to kick off a= discussion around the draft, and establish the appropriate working group.<= br>
The working group may be an existing working group or we may endeavor to cr= eate a new one. If the dispatch team could assist us with this decision tha= t would be great.

A link to our draft is here:
https://www.ietf.org/archive= /id/draft-secure-credential-transfer-01.html

The required participants for the initial discussion would be, at a minimum= , the full list of authors:

Dmitry Vinokurov
Apple Inc
Email: dvinokurov= @apple.com

Matt Byington
Apple Inc
Email: mbyington@a= pple.com

Ben Chester
Apple Inc
Email: bchester@app= le.com

Matthias Lerch
Apple Inc
Email: mlerch@apple.c= om

Crystal Qin
Alphabet Inc
Email: crystalyq@= google.com

Adam Bar-Niv
Alphabet Inc
Email: adambn@google= .com

Nick Sha
Alphabet Inc
Email: nicksha@goog= le.com

Thank you,
Matt Byington
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--00000000000023b39905d0378aae-- From nobody Sun Nov 7 12:20:55 2021 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 8F1923A0B67 for ; Sun, 7 Nov 2021 12:20:54 -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, 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 MkubevtQz2DP for ; Sun, 7 Nov 2021 12:20:49 -0800 (PST) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFDA23A0B42 for ; Sun, 7 Nov 2021 12:20:49 -0800 (PST) Received: by mail-oi1-x22e.google.com with SMTP id n66so864801oia.9 for ; Sun, 07 Nov 2021 12:20:49 -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=Whf8i2VrvH/nqxuO8xPVMU+qbssAOs7gvS5YQO8qTKY=; b=TG+QF/gdZ8OY4rG6TQIqX6/qfPmgze+0G3BuyokMt805wv/H5jhma2lH9xwFMA0Rk6 O7ntPZA3PCFJgGrYvOCpWaivsNW2iJHmWB5IjSuXs9bjXDFkU6X7+v2SkWBaCQweQV6E 5O+vGj1p7QsGgo9rE7URDEwKtEIyKl2cXsa8x4cLFOJoAn9NE+fwP3p8Igki1WKdkNU6 ZtKR3GbIm5dilbo34JIRWDZ+RrkqIRg0Md3JF/iHnDrSpkSy4w4lsNJXk1EtWU2HsK6d OUYP84fyCnhz3qmMC+0d5qmb63zsTMOVt8pFQX8XBQAKxseRuG7YA/Uq8q9/f50OGe75 vP+A== 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=Whf8i2VrvH/nqxuO8xPVMU+qbssAOs7gvS5YQO8qTKY=; b=UDwl50mrOxWsE9IERZSuDfkcseR994BjbNa/CTOYMa/aoVbYqcQeX5ajofHUpvTSgF UnBehqdFtwGwQMTHULrRwRoJcXrt+LJBJACSlLuHdT05fsVW72ZXdrX/BVSUR2fARYLd 8ER2DGIGMQNvXOotq6S+fCXt93UvEEdj5OzWhMoou9Y3BnaISZ9pl3yZO1VfFVuivSmY yW9hgk1d7fgg5hrLeW0rXKSctLe2W+/O+jNwYoEiIvkzec8rYKQ+pOBJuQboT7+LekdI Vt23JfIWN/GBbMFuiBUFxxtMnQ1SpqJKoPYcbg46ePcbiZEAzZZCxLApXQWpg/J17vGQ ydiw== X-Gm-Message-State: AOAM532F7oThmEJAU2kAhNqwkH06B19gv65JNsoN8uznToeI3sp6JF2Q NW2eK/We/0VbDjyP9veKYIICkMxdFTGi0CSG6Y7w/xFVOuI= X-Google-Smtp-Source: ABdhPJxGHqbFNcoeq42vWI3M3LYMF9bp4AuPQkUvACngbqBVO7sU5JjwokMY1spHryBBYgGzsX4d6CITwKb0Pb9xyCo= X-Received: by 2002:a54:4791:: with SMTP id o17mr6164303oic.114.1636316448687; Sun, 07 Nov 2021 12:20:48 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Mary Barnes Date: Sun, 7 Nov 2021 14:20:37 -0600 Message-ID: To: Patrick McManus Cc: DISPATCH Content-Type: multipart/alternative; boundary="000000000000aa0ccd05d0389c4b" Archived-At: Subject: Re: [dispatch] Updated wiki - where's the history of proposal dispatchments? 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, 07 Nov 2021 20:20:55 -0000 --000000000000aa0ccd05d0389c4b Content-Type: text/plain; charset="UTF-8" Just to be clear my suggestion wasn't that you all should maintain that history just because that's how we did it before. I was trying to explain the value of maintaining that history so that it's easier for the community to track the work. I don't see this as an AD discussion. It wasn't ADs that suggested we do that in the first place. And, current ADs weren't around when WG was created. As I said, it makes *total* sense to be more flexible nowadays with deadlines as the volume of incoming work has declined. AFAIK that's the primary process change you all have implemented. If otherwise, then perhaps RFC 7957 (and related RFC require changes). As the RFC notes, DISPATCH WG was a RAI area creation. It was created to try to add some focus to work in the RAI area ( and alleviate the volume of work in the SIPPING WG - 55 RFCs published in 8 years): https://datatracker.ietf.org/wg/sipping/documents/ My fundamental point is the fact that the tools don't support tracking work that is input and output of WGs like DISPATCH. That hasn't changed. And, as a regular community member, I think it's really helpful to have that information all in one place. A lot happens outside the WG after DISPATCH sessions and the WG doesn't always have visibility. The summaries give the community that visibility without having to dig through mailing lists which often don't give the complete picture or google drafts whose names may well have changed. In particular, in cases for docs that require further discussion after the meeting. And, yes, ISE is not a decision DISPATCH WG can make. But, as you note, it is certainly a viable path for a document submitted by a regular community member that the WG decides not to DISPATCH due to lack of interest. Again, my point is that keeping that info in the Wiki helps the community better navigate the work. It puts that idea on their radar - i.e., this is how you can make them aware. Regards, Mary. On Sat, Nov 6, 2021 at 6:53 PM Patrick McManus wrote: > Thanks for the thoughts Mary. We'll make sure to include them in our post > 112 discussion with the ADs. > > Less important than the big picture, I did want to make a note about one > point: > > WG had decided not to progress had actually been published via the ISE. While >> that's not listed as an option for DISPATCHing, it actually is and so >> seeing that might be helpful to someone. >> > > That's a fine line though, right? The iSE is, by definition, Independent. > We cannot dispatch things to the ISE. OTOH, work that might not have a home > in the IETF might have a home with the ISE (as this one did!) and it makes > sense for folks to be aware of that if they are looking for other avenues > to pursue (similarly there are other SDOs, or just publishing it on a blog > or in a public github repo, etc..). That's just being helpful. But there > isn't much dispatch can (or should imo) do to facilitate or track that. > It's out of our hands. > > --000000000000aa0ccd05d0389c4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Just to be clear my suggestion wasn't that = you all should maintain that history just because that's how we did it = before.=C2=A0 I was tryi= ng to explain the value of maintaining that history so that it's easier= for the community to track the work.=C2=A0 I don't see this as an AD discussion.=C2=A0 It wasn't ADs that suggeste= d we do that in the first place.=C2=A0 And, current ADs weren't around when WG was created.


=C2= =A0As I said, it makes *total* sense to be more flexible nowadays wi= th deadlines as the volume of incoming work has declined.=C2=A0 AFAIK that's the primary proces= s change you all have implemented.=C2=A0 If otherwise, then perhaps RFC 7957 (and related RFC requi= re changes).=C2=A0 As th= e RFC notes, DISPATCH WG was a RAI area creation.=C2=A0 It was created to try to add some focus to = work in the RAI area=C2=A0 ( and alleviate the volume of work in the SIPPING WG - 55 RFCs published= in 8 years): =C2=A0 https://datatra= cker.ietf.org/wg/sipping/documents/


My fundamental point is the fact that the tools= don't support tracking work that is input and output of WGs like DISPA= TCH.=C2=A0 That hasn'= ;t changed.=C2=A0 And, a= s a regular community member, I think it's really helpful to have that = information all in one place.= =C2=A0 A lot happens outside the WG after DISPATCH sessions and the = WG doesn't always have visibility. The summaries give the community tha= t visibility without having to dig through mailing lists which often don= 9;t give the complete picture or google drafts whose names may well have ch= anged.=C2=A0 In particul= ar, in cases for docs that require further discussion after the meeting. =C2=A0


And, yes, ISE is not a decision DISPATCH WG can= make.=C2=A0 But, as you note, it is certainly a viable path for a document submitted by a regular = community member that the WG decides not to DISPATCH due to lack of interes= t.=C2=A0 Again, my point= is that keeping that info in the Wiki helps the community better navigate = the work.=C2=A0 It puts that idea on their radar - i.e., this is how you ca= n make them aware.=C2=A0


Regards,

Mary.=C2=A0


On Sat, Nov 6, 2021 at 6:53 PM Patrick McManus <mcmanus@ducksong.com> wrote:
<= /div>
Thanks for the thoughts Mary. We'll make sure to include them in our = post 112 discussion with the ADs.

Less important t= han the big picture, I did want to make a note about one point:

=C2=A0WG had decided not to progress had ac= tually been published via the ISE.=C2=A0 While that's not = listed as an option for DISPATCHing, it actually is and so seeing that migh= t be helpful to someone.=C2=A0 =C2=A0
<= br>
That's a fine line though, right? The iSE is, by definiti= on, Independent. We cannot dispatch things to the ISE. OTOH, work that migh= t not have a home in the IETF might have a home with the ISE (as this one d= id!) and it makes sense for folks to be aware of that if they are looking f= or other avenues to pursue (similarly there are other SDOs, or just publish= ing it on a blog or in a public github repo, etc..). That's just being = helpful. But there isn't much dispatch can (or should imo) do to facili= tate or track that. It's out of our hands.

<= /div>
--000000000000aa0ccd05d0389c4b-- From nobody Sun Nov 7 12:35:04 2021 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 1D4693A0C81 for ; Sun, 7 Nov 2021 12:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.001 X-Spam-Level: X-Spam-Status: No, score=-3.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ncsc.gov.uk 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 LTHfT_EHofBo for ; Sun, 7 Nov 2021 12:34:57 -0800 (PST) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110114.outbound.protection.outlook.com [40.107.11.114]) (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 832F53A0C80 for ; Sun, 7 Nov 2021 12:34:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NbHcvmO+1TuD8Ge03Aut0cVn8LAPNgIWhuCDI+CvLbYugdBqlAYNmpbp5GBrKX0aFoZ9e/NP0vbcHRyqZgY1EEaMWDx4rDV1UwrhuGEw9EI0ik3VS1Ks5LHpA5h2WtCuk3D9cDv9nrUDSqk3R0YmHlL3Ercgiz9W7zi9TjqzNBtpY3BSXmI38gg6addoAbSqBKjEisYA/61TppytWs4SfjBsgaiLiWRIoEvD9gmyS+S1+t6pPuJ2MwiLwOp7XPU8RPeHmQN5bN2dJ8T2yBytjldQIqXwacMBKFTTS1YSKRYiFfC3EAPN6fGZjkQp3YlulX7m+9bNHBu+St5uC2OBhQ== 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=X3w+YLU3uAQeL27vOWs5YozXgkKB/ZUv13z2DrNP7tE=; b=CHhneElwOQlZsNAtDKprgLF4uu0f1iCxQt2pEtlX/kW7f09blUkeLjOC4KQgw844aFphXczVdj+JMwy6FCANT8mw+mWC3MGk4ApHdUg2YK0weCEp8Lj7elIQq+TSliCh2oA2z37wcOEVbx51wYcsZfvjwL63etlvA2PoMxJjtp4L3nE0dLvUPLGTGH4lokIVgfU9Hh36C+CzE1ixynbLcaq1I8CdLSoXefIboVRd8Ik8yN/kja+cj9hGVy4kAwhfEuAfM0TTUM8eliSp9RiQw6w7c6ORpMhr/CIikJI1Hyj518dNq7LEKAlb2/tAM+DO2S3G+DAXdoatjvgB7G2s0Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ncsc.gov.uk; dmarc=pass action=none header.from=ncsc.gov.uk; dkim=pass header.d=ncsc.gov.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X3w+YLU3uAQeL27vOWs5YozXgkKB/ZUv13z2DrNP7tE=; b=lSrv6nZrdSm2ieRKmJWSu2DJKj5zE+5FNk5INuKDUiKAiI2CPwY3/i2hLR27Yd/RLdXVwu6Na/XVz4iL0tyJnWdnaks1ckcznzWx78lce/yJKKZcZHHpN57CdLIO2WJL6MdZA+mWfGMXqtXF+pqKeNfjeQDJPTvUtrVrFLf7CUjWwX+sivBdRpkc6F3UuRuSbVCOB8ID1tLR844DqNjlFGjqDkWCOwWd5mkFka0H4YbzaJVXlCyxcxDidfVtZOApYR5iugh/VOkUiBA/aUQz7y5ZLTk/e3GzIi4ObPj5X+L1fBBg54KiRUIdon8ra+GTT+XrcenT1LjYmA5W5vYOkg== Received: from LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:12c::10) by LO2P123MB5109.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1ec::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.11; Sun, 7 Nov 2021 20:34:54 +0000 Received: from LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM ([fe80::91af:a946:6f54:775a]) by LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM ([fe80::91af:a946:6f54:775a%9]) with mapi id 15.20.4669.016; Sun, 7 Nov 2021 20:34:54 +0000 From: Kirsty P To: Mary Barnes , Patrick McManus CC: "dispatch@ietf.org" Thread-Topic: [dispatch] Updated wiki - where's the history of proposal dispatchments? Thread-Index: AQHXzCgaO8QfbHdvdkWWfH2P+xbi8avxA3OAgARFnACAAfGKAIABVvCAgAABEEw= Date: Sun, 7 Nov 2021 20:34:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 5fed6845-4ad9-730a-695b-551e86524d42 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ncsc.gov.uk; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eb3e14af-b8ce-4e58-a4dd-08d9a22e0e53 x-ms-traffictypediagnostic: LO2P123MB5109: 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: QUCxGKjlZ1UV+pvDavPvAerwEmBKjSL8JbKK/1XMcOFOlKIfVB3TFUkXbz6wCYn6Eahd+Ol1DIcGiXX8qpPHVmy7W24tDNnLjPO8Q+gNPlFbSx8L6WVvAKrohNdVN9QJuXzFEtHXJ7+a1MAqpeD23VaGCFJN2fj4Lv1NpR1QPJO/RLaDx/4C1r+d+mEY+WWPqHjOrt0zxOjwOhIQHiHtV0wHDNv+AGcOM1u7PM+L1R9YH0+EvXnmeynGpKMqwAkO1jqyPpVi/97r1PR4+rDXYdHb7Vh3Qb2N+IzQOx2581d9SLFtSYB1UDfeDOxn3qAXtS7MkJDaEY5rUlFmgL3wsNrQewq9BkiUoBCUk1fgCgMZzbQLhAkv6nOANxV/3eNXhH2bK3EmsdA+ybhYVWd8kaKxeSApSfK+JDY+xvq6XCjIuDIKjZF5+bDk2hQSBoX/OOtvWBwHLF7soYSI/CSNw34d7lG+isPgN/qNMUjYKrFQlW80X29ctM71HOpkF5R6++DW7pLYpHOAzhXi3ej3WVwSvMDyBmCnDPDfkqlQLctSssGTZnO/WcfN3UOuQKkKfvg25zA7pToUyuiyVV2pocSkbdnxwpKcGi6RNk2Zhxh1EhB3tHlLsjn8SvxeT4lfM3RzVM4z5ziBjP4BeQMBTb0K561+sNfMq9lApndYJi9eoGXKkX+r/LdDgjKsqX0XYrIjXdZE22oeqXHlJDtwvcKGUlCJMVKQhw+H68qizjf/jwR7wAZpoiO8ysP8eCN9b9akzm32G8UUazUnFxDQBcCGLxiX7Y4Eu1Q/5PBqYHw= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(86362001)(64756008)(76116006)(66556008)(66946007)(66476007)(66446008)(71200400001)(316002)(55016002)(8676002)(8936002)(966005)(82960400001)(7696005)(38070700005)(508600001)(166002)(83380400001)(33656002)(9686003)(110136005)(5660300002)(15650500001)(52536014)(186003)(38100700002)(122000001)(16350225007)(53546011)(26005)(6506007)(2906002)(4326008)(19627405001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?XVyUj+S5DFiYpOm5hiP1E0X60DyiA8CqcNA9GicjSkYpbfP2dhI3zESNae?= =?iso-8859-1?Q?nBHekATtiDCRRTO25SKzc4Va2lQKF+19hnC1mVuv4LmW7b2KugHv294H1f?= =?iso-8859-1?Q?QgqEVVP5NHWJBHgnVqjeoZ3GdDxc8qBJvC5V3vfjgBsczLrIiFuy5Ml1pW?= =?iso-8859-1?Q?xOxR5uPniZZVJLRrSrzeS5uNZQSID1vq9+V5Ep9s+m/jp1qznLuzUrzWKf?= =?iso-8859-1?Q?ac0acKtYEPB4vB7pfa+EJguH2tFL1a+hpjSQ6qVIzaznwPRCdDOW+wzDMt?= =?iso-8859-1?Q?7Go5WiMw1lIYlKWYpHNoBuRXny8Pq1S4aJRO5JJ/TcgdIKBGfSiUTZFwnF?= =?iso-8859-1?Q?eBbJIYG+HBhPcI6nF2kCmVOwH56bgfqtS5QneX+4NnqjS+s9GTv2pHYemv?= =?iso-8859-1?Q?n2EwPqn9vFSnmxbo21jEa25nono7Jv0Lxke6jhQzhYLWuPZYX/HgJrXjK4?= =?iso-8859-1?Q?EBiZITvf0DdvodKHDwQH/aWbLPjCY7rfEJRyiiFrDtTKKTGGQMWe5yQmpC?= =?iso-8859-1?Q?Pp1vrf+PLk4YJyYq7Jv/8EU2k6ibtcOqsP1VRAaDTjnuT/1EyAnZOO10/K?= =?iso-8859-1?Q?bsqS+otWG4VUP8RwRphgPMv/gjuPZ+0xXSv7BNo0UPlL8D0K11fXURtQVP?= =?iso-8859-1?Q?tLSbJdi4tMc6oeQostURr2KWsZ6kNL2+TzNEgwe2F8AZ1hRgIa76NL19OJ?= =?iso-8859-1?Q?2CjLmcH7IhjyWTpEala/iDed0MXq3V7O0VyRdgxrhmU1de4e8H58Yaus3c?= =?iso-8859-1?Q?4ooRu4LSSZ0x5cIkjjRJyqi4UYAUZ8J5Zspa5UCafRAXm+ESlUVtsDjIQF?= =?iso-8859-1?Q?CFikSWe91FzyTru/00XuTxH+huCbt7xFAb3khIVixZ+q/Xp/klSJVrweJy?= =?iso-8859-1?Q?B/q7pKqmY4hxUVFlTG4D5R/me2/UbPoIE/1MIVfe7Gfk81YPPxDkCEKKan?= =?iso-8859-1?Q?aw+cKS9utZ1j5Rsk7Xh/vp9CXlLI1tjxa37+Gv+9UmB+XpnqHdRiip/onH?= =?iso-8859-1?Q?mO/TVV4wYzSHH/EABvqyxpklQVktSCsS255VpbLLSJXuGC4ykJr0VJNkcn?= =?iso-8859-1?Q?zCtDKqy1U/Cn3IxgvWfMa1htL8qVDksQX1Y34Ox3ocrgAqCJ/gZtVpTLFU?= =?iso-8859-1?Q?BBoUaTOPIs87O5jPcl0vLpxwdJ3nQ9ztk2Khk1JGt0UnwsyrmjVH/Ak1SK?= =?iso-8859-1?Q?4CzwN+HpYvtiXfbfAJpXbKwHv/6/QdFvLCo9y9hovnW7K37gF9c0UgeNYg?= =?iso-8859-1?Q?tzP2xvhsLBdDSEHcK5ddNMEXb28+wTLdku6YFsEfgKMqiQqWms6CsIGjij?= =?iso-8859-1?Q?FtYygBk6ApSCq8ZsmIe9cnQPLTEftkZtNu6gVjFvVPNMwjZXcF66aK7XT8?= =?iso-8859-1?Q?jo6W1X3zN6v3ZTUkgntiEnD8VqxwYuxmQdRHYCIXNyJFRlC5lIjkFX34DP?= =?iso-8859-1?Q?WUSodwswiNn0J48b0zqEDnBRH4V7HOmZE+AcBoL4es6U2yAbK6PpM6X4vn?= =?iso-8859-1?Q?WeaRgxGrcMfvcFWqhP+OC8Y48EmQNEJ3Y2YPfmC0UA/sekvL+K+FHp5sH/?= =?iso-8859-1?Q?eDML88NNIK8Y1nhAE2hIH5vpaeYwVjYPPpyy9D7e5YTbuSGnlS5+to4CCQ?= =?iso-8859-1?Q?Ahkt8t/4LM200zj7bYSJqG+YVrdHDjzy1bH2Y8AQjMVVlMNJwaUKkXXQ?= =?iso-8859-1?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_LO2P123MB3599A3271247EB2DB85EEF25D7909LO2P123MB3599GBRP_" MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: eb3e14af-b8ce-4e58-a4dd-08d9a22e0e53 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2021 20:34:54.1457 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5DeBcrNKcKhO2qA0qR2DhROgVRf45SP7dcNlk32H5tJOHa8Xu6yC3Zoupb4N92nopaRWbcj5Lj4wOzOA/PAd5Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB5109 Archived-At: Subject: Re: [dispatch] Updated wiki - where's the history of proposal dispatchments? 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, 07 Nov 2021 20:35:03 -0000 --_000_LO2P123MB3599A3271247EB2DB85EEF25D7909LO2P123MB3599GBRP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mary, I hear your rationale and explanation of why keeping a note of the history = is valuable. I suggest we see if anyone else from the community feels simil= arly about keeping the history recorded in one place (as opposed to minutes= and the list), and then we can work out the best way to collate that infor= mation, which may include doing it in the wiki as it was done before. Talki= ng to the ADs makes sense to me, as recording the history might be a wider = requirement wanted in other dispatching groups as well, and of course the A= Ds are part of the community from whom we'd like feedback! Thanks for raising the question and giving your view; let's get feedback an= d take it from there. Kirsty ________________________________ From: dispatch on behalf of Mary Barnes Sent: 07 November 2021 20:20 To: Patrick McManus Cc: DISPATCH Subject: Re: [dispatch] Updated wiki - where's the history of proposal disp= atchments? Just to be clear my suggestion wasn't that you all should maintain that his= tory just because that's how we did it before. I was trying to explain the= value of maintaining that history so that it's easier for the community to= track the work. I don't see this as an AD discussion. It wasn't ADs that= suggested we do that in the first place. And, current ADs weren't around = when WG was created. As I said, it makes *total* sense to be more flexible nowadays with deadli= nes as the volume of incoming work has declined. AFAIK that's the primary = process change you all have implemented. If otherwise, then perhaps RFC 79= 57 (and related RFC require changes). As the RFC notes, DISPATCH WG was a = RAI area creation. It was created to try to add some focus to work in the = RAI area ( and alleviate the volume of work in the SIPPING WG - 55 RFCs pu= blished in 8 years): https://datatracker.ietf.org/wg/sipping/documents/ My fundamental point is the fact that the tools don't support tracking work= that is input and output of WGs like DISPATCH. That hasn't changed. And,= as a regular community member, I think it's really helpful to have that in= formation all in one place. A lot happens outside the WG after DISPATCH se= ssions and the WG doesn't always have visibility. The summaries give the co= mmunity that visibility without having to dig through mailing lists which o= ften don't give the complete picture or google drafts whose names may well = have changed. In particular, in cases for docs that require further discus= sion after the meeting. And, yes, ISE is not a decision DISPATCH WG can make. But, as you note, it= is certainly a viable path for a document submitted by a regular community= member that the WG decides not to DISPATCH due to lack of interest. Again= , my point is that keeping that info in the Wiki helps the community better= navigate the work. It puts that idea on their radar - i.e., this is how y= ou can make them aware. Regards, Mary. On Sat, Nov 6, 2021 at 6:53 PM Patrick McManus > wrote: Thanks for the thoughts Mary. We'll make sure to include them in our post 1= 12 discussion with the ADs. Less important than the big picture, I did want to make a note about one po= int: WG had decided not to progress had actually been published via the ISE. W= hile that's not listed as an option for DISPATCHing, it actually is and so = seeing that might be helpful to someone. That's a fine line though, right? The iSE is, by definition, Independent. W= e cannot dispatch things to the ISE. OTOH, work that might not have a home = in the IETF might have a home with the ISE (as this one did!) and it makes = sense for folks to be aware of that if they are looking for other avenues t= o pursue (similarly there are other SDOs, or just publishing it on a blog o= r in a public github repo, etc..). That's just being helpful. But there isn= 't much dispatch can (or should imo) do to facilitate or track that. It's o= ut of our hands. This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LO2P123MB3599A3271247EB2DB85EEF25D7909LO2P123MB3599GBRP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Mary,

I hear your rationale and explanation of why keeping a note of the history = is valuable. I suggest we see if anyone else from the community feels simil= arly about keeping the history recorded in one place (as opposed to minutes= and the list), and then we can work out the best way to collate that information, which may include doing= it in the wiki as it was done before. Talking to the ADs makes sense to me= , as recording the history might be a wider requirement wanted in other dis= patching groups as well, and of course the ADs are part of the community from whom we'd like feedback!

Thanks for raising the question and giving your view; let's get feedback an= d take it from there.

Kirsty


From: dispatch <dispatch= -bounces@ietf.org> on behalf of Mary Barnes <mary.ietf.barnes@gmail.c= om>
Sent: 07 November 2021 20:20
To: Patrick McManus <mcmanus@ducksong.com>
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [dispatch] Updated wiki - where's the history of propos= al dispatchments?
 

Just to be clear my suggestion wasn't that you all should maintain that his= tory just because that's how we did it before.  I was trying to explain the value of maintaining that history so tha= t it's easier for the community to track the work.  I don't see this as an AD discussion.  It wasn't ADs that suggested we do that in the first place.  And, current ADs weren't around when WG was created.


 As I said, it ma= kes *total* sense to be more flexible nowadays with deadlines as the volume= of incoming work has declined.  AFAIK that's the primary process change you all have implemented.  If otherwise, then perhaps RFC 7957 (and related RFC require changes= ).  As the RFC notes, DISPATCH WG was a RAI area creation.  It was created to try to add some focus to work in the RAI area  ( and alleviate the volume of work in the SIPPING WG - 55 RFCs publi= shed in 8 years):   https://datatracker.ietf.org/wg/sipping/documents/


My fundamental point is the fact that the tools don't support tracking work= that is input and output of WGs like DISPATCH.  That hasn't changed.&n= bsp; And, as a regular community member, I think it's really helpful= to have that information all in one place.  A lot happens outside the WG after DISPATCH sessions and the WG does= n't always have visibility. The summaries give the community that visibilit= y without having to dig through mailing lists which often don't give the co= mplete picture or google drafts whose names may well have changed.  In particular, in cases for docs that require further discussion after the = meeting.  


And, yes, ISE is not a decision DISPATCH WG can make.  But, as you note, it is certainly a v= iable path for a document submitted by a regular community member that the = WG decides not to DISPATCH due to lack of interest.  Ag= ain, my point is that keeping that info in the Wiki helps the community bet= ter navigate the work.  It puts that idea on their radar - i.e., this = is how you can make them aware. 


Regards,

Mary. 


On Sat, Nov 6, 2021 at 6:53 PM Patr= ick McManus <mcmanus@ducksong.co= m> wrote:
Thanks for the thoughts Mary. We'll make sure to include them in our p= ost 112 discussion with the ADs.

Less important than the big picture, I did want to make a note about o= ne point:

 WG had decided not to progress had actually been pub= lished via the ISE.  While that's not listed as an option for DISPATCHing, it actually is= and so seeing that might be helpful to someone.   <= /div>

That's a fine line though, right? The iSE is, by definition, Independe= nt. We cannot dispatch things to the ISE. OTOH, work that might not have a = home in the IETF might have a home with the ISE (as this one did!) and it m= akes sense for folks to be aware of that if they are looking for other avenues to pursue (similarly there a= re other SDOs, or just publishing it on a blog or in a public github repo, = etc..). That's just being helpful. But there isn't much dispatch can (or sh= ould imo) do to facilitate or track that. It's out of our hands.

This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9
--_000_LO2P123MB3599A3271247EB2DB85EEF25D7909LO2P123MB3599GBRP_-- From nobody Sun Nov 7 17:01:29 2021 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 5333D3A13A0; Sun, 7 Nov 2021 17:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.121 X-Spam-Level: * X-Spam-Status: No, score=1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.4, MAY_BE_FORGED=2.399, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UXvE3gYpIT7; Sun, 7 Nov 2021 17:01:22 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB1653A13A1; Sun, 7 Nov 2021 17:01:21 -0800 (PST) Received: from smtpclient.apple (mta-70-120-133-87.satx.rr.com [70.120.133.87] (may be forged)) (authenticated bits=0) by nostrum.com (8.17.1/8.16.1) with ESMTPSA id 1A811FD1068435 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 7 Nov 2021 19:01:16 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1636333276; bh=Atq03vWNiqOihfFO/NjtBJvzSUwKIm2j9caW9zFAR4I=; h=From:Subject:Date:To; b=PpPmQ4Prbo0PXyvDLHLLk4d6/yQBfxHSeCtTrcf3WfRxoZlzD8QgMIox/scLD6IRi RSYx+98B4j9xUEbGcJRgTnRltOhbJiGVtkj+h+OORR1QKSb45ca9pzAwZFGCeeVcqr WqNrN+cPr3Nonb4SxkqWa+0cSDWEORunqF0uWhT8= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-133-87.satx.rr.com [70.120.133.87] (may be forged) claimed to be smtpclient.apple From: Ben Campbell Content-Type: multipart/alternative; boundary="Apple-Mail=_90437C3A-B2E3-479E-B9A7-40D0DF91A656" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Message-Id: <6168919A-809C-47A7-B53E-E408343BB477@nostrum.com> Date: Sun, 7 Nov 2021 19:01:10 -0600 To: dispatch@ietf.org, dispatch-chairs@ietf.org, art-ads@ietf.org X-Mailer: Apple Mail (2.3693.20.0.1.32) Archived-At: Subject: [dispatch] Incorrect DISPATCH Agenda 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, 08 Nov 2021 01:01:27 -0000 --Apple-Mail=_90437C3A-B2E3-479E-B9A7-40D0DF91A656 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I just noticed that the datatracker agenda link for DISPATCH [1] returns = the agenda for GENDISPATCH. The Agenda that Kirsty sent out last week [2] looks correct, assuming it = is current. [1] = https://datatracker.ietf.org/meeting/112/materials/agenda-112-dispatch-03 = [2] = https://datatracker.ietf.org/meeting/112/materials/agenda-112-dispatch-01.= txt Thanks! Ben.= --Apple-Mail=_90437C3A-B2E3-479E-B9A7-40D0DF91A656 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

I = just noticed that the datatracker agenda link for DISPATCH [1] returns = the agenda for GENDISPATCH.

The Agenda that Kirsty sent out last week [2] looks correct, = assuming it is current.

[1] https://datatracker.ietf.org/meeting/112/materials/agenda-112-d= ispatch-03

[2] https://datatracker.ietf.org/meeting/112/materials/agenda-112-d= ispatch-01.txt

Thanks!

Ben.
= --Apple-Mail=_90437C3A-B2E3-479E-B9A7-40D0DF91A656-- From nobody Sun Nov 7 18:17:29 2021 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 028153A046A for ; Sun, 7 Nov 2021 18:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.409 X-Spam-Level: X-Spam-Status: No, score=-5.409 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, NICE_REPLY_A=-3.33, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0pK3yL0h_1j for ; Sun, 7 Nov 2021 18:17:23 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A77A43A045B for ; Sun, 7 Nov 2021 18:17:22 -0800 (PST) Received: from [192.168.1.114] ([47.186.34.206]) (authenticated bits=0) by nostrum.com (8.17.1/8.16.1) with ESMTPSA id 1A82HKBL081478 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sun, 7 Nov 2021 20:17:20 -0600 (CST) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1636337840; bh=YKtSOJesiD9ijwlP5eoW/kkheQpHHiJeY0qkXFTisEc=; h=Date:Subject:To:References:From:In-Reply-To; b=ZQGxCkgca5LNGqBxBMokmlndJrzOeeSOXoKggv8Z0/hi0oFviD7BPoIOX12UrEsuf dOJL1gsx72t+UtQqCsYL4mf4Nv+tOjBC2LPT32TRWAOyg6FH7v1aPeQ0450zKQH56r Zny2CV00l/uwpmiVT918yYLalOxt+zURybd06Vxg= X-Authentication-Warning: raven.nostrum.com: Host [47.186.34.206] claimed to be [192.168.1.114] Message-ID: Date: Sun, 7 Nov 2021 20:17:14 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Content-Language: en-US To: dispatch@ietf.org References: <6168919A-809C-47A7-B53E-E408343BB477@nostrum.com> From: Robert Sparks In-Reply-To: <6168919A-809C-47A7-B53E-E408343BB477@nostrum.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] Incorrect DISPATCH Agenda 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, 08 Nov 2021 02:17:28 -0000 My fault - I was helping Kirsty and hit a wrong target - will correct. RjS On 11/7/21 7:01 PM, Ben Campbell wrote: > Hi, > > I just noticed that the datatracker agenda link for DISPATCH [1] > returns the agenda for GENDISPATCH. > > The Agenda that Kirsty sent out last week [2] looks correct, assuming > it is current. > > [1] > https://datatracker.ietf.org/meeting/112/materials/agenda-112-dispatch-03 > > [2] > https://datatracker.ietf.org/meeting/112/materials/agenda-112-dispatch-01.txt > > Thanks! > > Ben. From nobody Mon Nov 8 05:37:09 2021 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 138793A0418; Mon, 8 Nov 2021 05:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.1 X-Spam-Level: X-Spam-Status: No, score=-3.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ncsc.gov.uk 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 PA8maCa3PgKs; Mon, 8 Nov 2021 05:37:03 -0800 (PST) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-cwlgbr01on0727.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe14::727]) (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 069C23A040A; Mon, 8 Nov 2021 05:37:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UnJwu7vt8z881VZL17PHDQngMLG6i4FdB1MuyhwnD22pdvSP7RSZgo0kQQrj6LkhQWGiG+PtuH4h5jTGmgjnAODMq0/6+4+mlduo+NFu6eJzPKGrEwGus0zT4liIebri5DUQzQAgMMvky3bU0vX5HnYg5TgaZyCJkL8hIa5ymDJ4pC++xN/Lu2tcBd/HWyjfIzqBF0ZZuV4bTAOwuEUaz0cGeX2ZyRYNXoan4MBKf9FzjeYTKO//JlvlipPaXQbnks9714t250iANgJXGTgtqpuSKs6RPKPDhYiUOPdJ7tCiBNTnGWdokYhGa2CsPNE+MkikgmykQ0X3XthjGspWWA== 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=bHpGDkpuxCI6dEHXF9ELniAREEDa9P4SSyqiI9cNv+8=; b=kS2c67BJjMWvrjjIPCudZkC3eiY6hbbFaOZuX3oZ4bt2wCPI96YplDVTDe5nm8aAsQ+t3MUYeXTYSlceq02TQJS9p5ZgD6heDpSLGbtQozWwj6Lribl0zTXzic+zsUxRxe1PfbwV1DBZcSA4FBM3p0v8BcrN4hykeucxwpN6kfILrebdgzmZXZ7rYmSPtbVKOBvD2BZrx+fHNklkJ7BNMTkbtb5BrKqEdqFXOc9hoayl28iSX76FICHJ4AdMPqMSUaSxNhVr30b+pDw+kR29ASiOtc/Pwj8DKWs1RP56LLTkZgGGwQN/iJhLVdngKJX7tquB4oVr29RHW2CbQqxMQw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ncsc.gov.uk; dmarc=pass action=none header.from=ncsc.gov.uk; dkim=pass header.d=ncsc.gov.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bHpGDkpuxCI6dEHXF9ELniAREEDa9P4SSyqiI9cNv+8=; b=GuFiXJ6xccGOpe/KPD0lHdWOYs/7vqM7lDEBcqvFMvj7RVY2iO3RU8kmgE6cSJZ4eapytOIhym1ESo+HJIW0pxdULdDlHSldr1qApczVNqTlVM+JpL6SM8ITQY0aRP6Pokxs7ZiWQ//DrVo5E7VdkjmeGrO4kzVqKConltIm6qmqh9SdzyEwAOOAYYdhE2FgZNrbqkvSvt3nJ7R/2MQ+ah+BUSqGFgMdQ+7eGTZa6wNEvIT7V2J8RCnzqiEHtSv0GfK/lfWz32sp67ZYJDytCHrtSb+h8atZqwBvuAot42VNYNyNP4UJn9dAsax/yBs9nivyatoEfHo7D2IhbLMRxw== Received: from LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:12c::10) by LO2P123MB4877.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1e1::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.10; Mon, 8 Nov 2021 13:36:53 +0000 Received: from LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM ([fe80::91af:a946:6f54:775a]) by LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM ([fe80::91af:a946:6f54:775a%9]) with mapi id 15.20.4669.016; Mon, 8 Nov 2021 13:36:52 +0000 From: Kirsty P To: "dispatch@ietf.org" CC: Matthew Byington , dispatch chairs Thread-Topic: DISPATCH 112 Meeting: Dispatch Outcomes Thread-Index: AQHX1KP5NjWfioj410er2HYdIgGdBA== Date: Mon, 8 Nov 2021 13:36:52 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: c59e074c-35cb-31bb-b690-34bc88f28596 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ncsc.gov.uk; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 605b939d-2482-41d8-bdfc-08d9a2bcd322 x-ms-traffictypediagnostic: LO2P123MB4877: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gCPmHqxZYLZQyo3h5JmtT+zKaEJL9rqo9Do/9D+U1ofaONR+cTMALQVUBOuAqwofu7eUdxJFsv/D8WQWY00PfuViY1t/xy+sZbZYJm4mDFVZpkTJ6WwW913eDa64pXxQVxuzqQ1uIipjfsRmKqqsdAL96MDJwGwg+dSJczyI88bB/bhTKK7AVQgZyGpyXfyrHVwpw5Vkj9g3g2hfbsbQWlW+P/G2fbadCP3Uu8ZdV/66QE4rW5+v60pgnX0GjZZACdXbYtXl5uysj76lr2Xne8VDqcLQAXALATEs3A6QDhO/oCVhKBDbymyr2KIc9yoSG/bUZ3ZSfk1rc4BSKTUu3NEM/DlHKYY9lJsW/eHbuQim34+mDT2O4Qerc2WHbNZFOVdOJehfXf9pNOzGuMpJAjgB4JmMgN6t5lZ1dHGL8jlaZDokmKrxUjpXTI9NnqhZElKCYWiMQBGYmVkRcU+vsLFFsybCMMuTxh+l9lYungCxbfjuH8iSfnaoStGFbk0Cn7HBrCbHPJe2k2Tbuq0tsQud5bJinBdipVVxN5k7IfqC3u7jFjH61dzg/sO4i/B09H3s8Qynh39BMiLnKJDcHvytwGsUSQokeevxPUfz7KQW3WhntaGDV0vW41Af1Y42A6cV75hMjMutMK2mouCmJsNpt08FWfSMmqU+eW+aJl+SXH3ikny4GzgcDWt6LdJS+Su/3l9FLqMaTlgxj8BSRIJxW2XWDIPTnaUboRa/oN5WmDMij/zBZHVubiIE1nevmUYiziCgzDIF3iV8+7RO3vbg2nU6gESzGH/TzMUXMfQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(38070700005)(6916009)(9686003)(83380400001)(8936002)(4326008)(33656002)(122000001)(38100700002)(66946007)(8676002)(6506007)(66446008)(64756008)(66476007)(66556008)(82960400001)(316002)(26005)(2906002)(54906003)(186003)(52536014)(5660300002)(76116006)(86362001)(55016002)(508600001)(19627405001)(7696005)(71200400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?kfC6JJbfJRRPvGNoztT/Fff9uF0rXGR2s2NTMhtdXrDZLV+XRlDhea8BJy?= =?iso-8859-1?Q?LnF9VTvcXA4BaeWFyoTu9Yjhf/XdOK38qLup8P4J1Cy27hWYxkyCpkM+ul?= =?iso-8859-1?Q?uUmP6N4qYahcO19bT7Ylvl4VEfCA3Vsuzrxp2gBpq/AoESKvP0BnXzfuX0?= =?iso-8859-1?Q?akzKkQv2LS/Fi6wUuREcD504ax+RvN/o93H51w2Q8767bZmOJp6Qrz9Jdq?= =?iso-8859-1?Q?JLY5jRFiyZUfxr1EpHjdM8+XBLJIoEtQpv1vyvsUno0hBNpJ8Cw3N19Kcc?= =?iso-8859-1?Q?593nAz8Er87J6raRy3lTLwyiVpEcQsDjYa8Wffa0k5sfw2/kxwVN8ZFiel?= =?iso-8859-1?Q?PHdcjrtF76wMPBMLgz2gbfKefXu9x7piKFLce7sYqCw56MQEZVIiIhN47m?= =?iso-8859-1?Q?SFtSdtRwx3hvdnu/pTtSQhh9ykZFeY2qZJdOY/gwJT1wq3zhWAoO/wqiLk?= =?iso-8859-1?Q?UjzeYI+JkH3x7lXkOA0nqmeLAV+xavhjKwUJeqGAPG7WAhEkd5gFlF84Xd?= =?iso-8859-1?Q?u1sRq3J9ymKkXQeCkYnEGu/2kwM9tKnsKzKnzqTw6OZwHqvjHrySUvomp8?= =?iso-8859-1?Q?CEm6JEceXK4zFfy33u9f/L5dFswSgSxkf4sWA2T5g66H3UH3z5qtWmBWM9?= =?iso-8859-1?Q?Y74bVMYY4Bn8+Y7KjJS2vX+w7BEjvvXMcgJ5eWmA5amD2PB81me/asDqCp?= =?iso-8859-1?Q?8eDT0f05arpikiTZ2in43yNpe6DBf6Y8JaFz6872CLH69LRm0+Orp9IoVH?= =?iso-8859-1?Q?bn2M9x9N6fcdn7HRnKi2yZUi5TkdDtmM8onuSFJKHOx/AHBViZwBBbJCx0?= =?iso-8859-1?Q?gs/Y9fUBEcNrL4Niwxh8x9E/ysOrgIro1DdRkoqiKGFftP/u8ZgmIoqxvn?= =?iso-8859-1?Q?Az7tT9/KJ+Xu+uo+WTvoESRcL0X7iYTlXnmiqjWfvny6Yyuon8rLxutOtf?= =?iso-8859-1?Q?yKI0j+L/HPUootSvS+bn5lBCfCED5WUEyo3H0S4j+mMMmtCHETZ70vBz6g?= =?iso-8859-1?Q?22YH9Ti1PkU8X1Bx/cZuE0xFIUbD3sRMUQG9cWohZvGi+yy/Y7i/6aNhg6?= =?iso-8859-1?Q?dzdYdyOLwbFASSThrTuJHZ5b2UF6Sjci/I1+wG8Z6PN7SFrBW0mxrOoDJq?= =?iso-8859-1?Q?CL9O7EAhOrnpZ4fTV0Itc+wLuNKdcvMyGmMcowgfnm+uPxb5aNKDZfR6zH?= =?iso-8859-1?Q?z9EySnJe+dXJosepOkMAl43Su4oKr8y+iifC2fI8ZzkxlRZA2OgijkCjQa?= =?iso-8859-1?Q?tmkKxL72IQYsd5v9CuUwJY9bSpN0iznc+JqiEUeMuH5BMKcUDcG8sfjYWr?= =?iso-8859-1?Q?Tyn1c09gu2Iz2GTFPHIW6jppM+/ul9IPQ7t750W9lmWlHl2UasM+O56Ujq?= =?iso-8859-1?Q?y+HG4j4weAHBFyzZB9nBij8EhWZUkIbjsjYGjeEaojJModOTTPIvuOcrTA?= =?iso-8859-1?Q?58MLgNZNosAi0nIt0D19OYNoh4lVPWqGxRqCXPe9oBlhHT7hT+tOt1w7/y?= =?iso-8859-1?Q?viRSdPuggV0ON6dmx59XSmGzHdtQSY8+6lxz5+2chEuzx9gB95fXMK2Oxg?= =?iso-8859-1?Q?FFynFH8WKtbRmwwDKg9NcI5pcD8zxZhFUir/9dTWr1JdFCt4M15VAKm80Z?= =?iso-8859-1?Q?lFhKvhKN5j3SU9ZMBJffLMYLmFeOwF1D7fEbice4zjyuYhvvm82OUARQ?= =?iso-8859-1?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_LO2P123MB3599BDDAABA460C4B978B82ED7919LO2P123MB3599GBRP_" MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 605b939d-2482-41d8-bdfc-08d9a2bcd322 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2021 13:36:52.9138 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: lOa3HgWMPJtJxNCIJEGLCjaZhOWtHxM1cQE1aXkULFc2nhO48p/UkvnFrKEZX6FQONjjzFezdmL+MkUnPxHlIw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB4877 Archived-At: Subject: [dispatch] DISPATCH 112 Meeting: Dispatch Outcomes 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, 08 Nov 2021 13:37:08 -0000 --_000_LO2P123MB3599BDDAABA460C4B978B82ED7919LO2P123MB3599GBRP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks everyone for your discussion in DISPATCH and ART AREA today, and tha= nks to our presenters for bringing their work and ideas to the group. This = email just records the dispatch outcomes for the draft-secure-credential-tr= ansfer draft (https://datatracker.ietf.org/doc/draft-secure-credential-tran= sfer/) after the group discussion today: 1. The consensus was to have a BoF (virtual or otherwise) on the problem= space/constraints/requirements. 2. Dispatch also recommended giving this work a shout-out in secdispatch= (just for awareness, not to re-dispatch), and to make sure both the ART an= d SEC communities get to weigh in on the BoF. 3. When asked, dispatch was split on whether this work belongs more in S= EC than ART. In general, the view was that a BoF was needed to decide that,= so the ADs will discuss offline what is most appropriate, including a join= t ART/SEC BoF, and update the list. Additional feedback or corrections to any of the points above are welcome, = otherwise please continue discussions about the draft on list, and have a g= reat IETF week! Kirsty & Patrick This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LO2P123MB3599BDDAABA460C4B978B82ED7919LO2P123MB3599GBRP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks everyone for your discussion in DISPATCH and ART AREA today, and tha= nks to our presenters for bringing their work and ideas to the group. This = email just records the dispatch outcomes for the draft-secure-credential-transfer draft (https://datatracker.ie= tf.org/doc/draft-secure-credential-transfer/) after the group discussion today:
  1. The consensus was to = have a BoF (virtual or otherwise) on the problem space/constraints/requirem= ents.
  2. Dispatch also recomme= nded giving this work a shout-out in secdispatch (just for awareness, not t= o re-dispatch), and to make sure both the ART and SEC communities get to weigh in on the BoF.
  3. When asked, dispatch = was split on whether this work belongs more in SEC than ART. In general, th= e view was that a BoF was needed to decide that, so the ADs will discuss offline what is most appropriate, including a joint ART/S= EC BoF, and update the list.
Additional feedback or corrections to any of the points above are welc= ome, otherwise please continue discussions about the draft on list, and hav= e a great IETF week!

Kirsty & Patrick




This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LO2P123MB3599BDDAABA460C4B978B82ED7919LO2P123MB3599GBRP_-- From nobody Wed Nov 10 08:36:24 2021 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 C1C6B3A11A8 for ; Wed, 10 Nov 2021 08:36:22 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=lFgbwJLV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=O02juJzM 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 pim48R_4TsrO for ; Wed, 10 Nov 2021 08:36:17 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 718583A11A9 for ; Wed, 10 Nov 2021 08:36:17 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 5D6E73201EF0; Wed, 10 Nov 2021 11:36:12 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Wed, 10 Nov 2021 11:36:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-type:message-id:date:mime-version:to:from:subject:cc; s= fm1; bh=pfIJycYY4WNaprMI/stz4ay4jEdwvcy59CIo3DYgZq8=; b=lFgbwJLV 50iGSodELTgnX1LbA6EzDnJTFeY1WLbzLBhh7BRSAdi4igWmjLJYaQZuFoAy6ZVt Hd/8WbwaCG36v89/HE6yIY/YGFO9CdZDT2dy0SJxOfK4ikMAcAtpoFCd2UAuI4Hi BJ4NjcjJXaLP96BqRJrVhT6xIzGYuNFfRr8g27QZEMiahWy7rtJDUHJ47e+iogDY Q5tcFZOpVOQJGMBniPTSgB+1avNEd2Sdk+Gpw1b9MGsYu4L5j097pF2WGotdk2fv 0hBfROQvzNMcZ09WqN8e1vznM6jBNhJjEjVABO+wd84eO+EgMuZvcxfq8eEiMGXy jTkwPb842WrPog== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=pfIJycYY4WNaprMI/stz4ay4jEdwv cy59CIo3DYgZq8=; b=O02juJzML3CDfZS/e3aCeFUwW0daJWhHpkzlMXuQc3PQ5 B8b1ATar/at2xBbAXC+PfmY2e2rV2nTuemsudIVhs0SxCOunmkH0BY/KR3pUHxfH fC6qs8Crr1jjnr24F1ac+Yurfi6yYKuUoqjD/0bfuNn+fUYcGV9Qwrozur3ZQBEH /bYjXUKKryqjrojxsAR3LxWPyYXPSp1kar3Q/GYrXm8j+TXYyBMfyDGfbO0IxlQJ TPUrxxVOPdcU2jF3PvaIWFyJ6BEw4fRKNOm/pjw1HOumv7fKgOK6hxqacDCcxa/g C69AwPy0RB0w5IZMnOYyOUl30WlKbc602kbZOUuPw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudejgdeklecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtkfffgggfvffhufesrgdtreertdefjeenucfhrhhomhepmfgvnhcuofhurhgt hhhishhonhcuoehmuhhrtghhsehfrghsthhmrghilhdrtghomheqnecuggftrfgrthhtvg hrnhepgfekgffghffhgfdtueekudevvddtffekgfdvgeevkedvieehvedugfffieeiuddu necuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehmuhhrtghhsehfrghsthhmrghilhdrtghomh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 10 Nov 2021 11:36:10 -0500 (EST) Content-Type: multipart/alternative; boundary="------------Kt8aHBTxQqUKW8tU5N5YZvwA" Message-ID: <2b51160c-af50-c1fb-d9da-5ae3f9425f2e@fastmail.com> Date: Wed, 10 Nov 2021 11:36:09 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0 To: "dispatch@ietf.org" Content-Language: en-US From: Ken Murchison Cc: Paul Eggert , Arthur David Olson Archived-At: Subject: [dispatch] draft-murchison-rfc8536bis-02 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, 10 Nov 2021 16:36:23 -0000 This is a multi-part message in MIME format. --------------Kt8aHBTxQqUKW8tU5N5YZvwA Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi all, I was traveling during DISPATCH this week and wasn't able to ask this question there, so I'm bringing it to the list.  I'm looking to dispatch draft-murchison-rfc8536bis . RFC 8536 was previously handled on the tzdist-bis mailing list and was shepherded by Eliot Lear.  Per the introduction in the draft: This document obsoletesRFC 8536 , providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format ofRFC 8536 . Additionally, a new version of the format is defined. The changes fromRFC 8536 are summarized in Appendix C . I, along with my co-authors, would be happy to continue this work wherever this group deems suitable.  I don't believe that we expect too much churn at this point, unless serious technical issues are raised. FWIW, recent versions of tzcode already are capable of using the v4 format where appropriate. Regards, Ken -- Kenneth Murchison Senior Software Developer Fastmail US LLC --------------Kt8aHBTxQqUKW8tU5N5YZvwA Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hi all,

I was traveling during DISPATCH this week and wasn't able to ask this question there, so I'm bringing it to the list.  I'm looking to dispatch draft-murchison-rfc8536bis.  RFC 8536 was previously handled on the tzdist-bis mailing list and was shepherded by Eliot Lear.  Per the introduction in the draft:

   This document obsoletes RFC 8536, providing editorial improvements,
   new details, and errata fixes while keeping full compatibility with
   the interchange format of RFC 8536.  Additionally, a new version of
   the format is defined.  The changes from RFC 8536 are summarized in
   Appendix C.

I, along with my co-authors, would be happy to continue this work wherever this group deems suitable.  I don't believe that we expect too much churn at this point, unless serious technical issues are raised.

FWIW, recent versions of tzcode already are capable of using the v4 format where appropriate.

Regards,
Ken

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC
--------------Kt8aHBTxQqUKW8tU5N5YZvwA-- From nobody Thu Nov 11 13:29:28 2021 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 0676B3A10FD; Thu, 11 Nov 2021 13:29:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks via Datatracker To: Cc: dispatch@ietf.org, draft-ietf-dispatch-javascript-mjs.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163666615497.23068.10861141804252308923@ietfa.amsl.com> Reply-To: Robert Sparks Date: Thu, 11 Nov 2021 13:29:15 -0800 Archived-At: Subject: [dispatch] Genart last call review of draft-ietf-dispatch-javascript-mjs-10 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, 11 Nov 2021 21:29:22 -0000 Reviewer: Robert Sparks Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-dispatch-javascript-mjs-10 Reviewer: Robert Sparks Review Date: 2021-11-11 IETF LC End Date: 2021-11-15 IESG Telechat date: Not scheduled for a telechat Summary: Ready (but with nits) for publication as an Informational RFC The number of messages in the archive about the draft are impressive, if not daunting. Apologies if any of my nits tread old ground. I'm glad this has seen attention from many people better with i18n than I am. I'm curious why the registrations choose to declare the .mjs extension in anything but the now preferred type. If they're in all the obsoleted type registrations because they're used in the wild with those types, fine. But if it was a template replication process that put them there, maybe reconsider? I agree with Mark that the form and repetition of variants of 'not part of this document' is unusual. Consider saying it less, and maybe consolidating what you do need to say. There are a few places where the document says implementations or scripts MUST consider something. Neither of those things can consider. Please consider rephrasing those to speak of the implementers or script creators. This is also not a great use of 2119/8174 terms. Think about using plain words instead. The last sentence of the second paragraph of section 3 doesn't fit with the first. Perhaps it should stand alone. Please point explicitly to the types registry in the text of the document. Micro-nit: search for timin`g