From nobody Fri Mar 1 13:15:31 2019 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 577D1130F52; Fri, 1 Mar 2019 13:10:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: dispatch@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155147460935.6101.13461653268386864139.idtracker@ietfa.amsl.com> Date: Fri, 01 Mar 2019 13:10:09 -0800 Archived-At: Subject: [dispatch] dispatch - Requested session has been scheduled for IETF 104 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: Fri, 01 Mar 2019 21:10:23 -0000 Dear Mary Barnes, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dispatch Session 1 (2:00 requested) Monday, 25 March 2019, Morning Session I 0900-1100 Room Name: Congress Hall 3 size: 250 --------------------------------------------- Special Note: Joint with ARTAREA iCalendar: https://datatracker.ietf.org/meeting/104/sessions/dispatch.ics Request Information: --------------------------------------------------------- Working Group Name: Dispatch Area Name: Applications and Real-Time Area Session Requester: Mary Barnes Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: secdispatch cfrg extra doh core clue bfcpbis avtcore ecrit mmusic netvc payload rmcat rtcweb sipcore stir xrblock dmarc uta jmap Second Priority: tram tsvwg tsvarea opsarea People who must be present: Alexey Melnikov Mary Barnes Adam Roach Ben Campbell Resources Requested: Special Requests: Please schedule in the 1st slot on Monday morning, list the meeting as coupled with ARTAREA, and avoid the same kind of conflicts with other area meetings and any Bofs and potential new ART WGs. --------------------------------------------------------- From nobody Sun Mar 3 14:23:13 2019 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 AF905124BF6 for ; Sun, 3 Mar 2019 14:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 5CaQcP3BIXVm for ; Sun, 3 Mar 2019 14:23:07 -0800 (PST) Received: from forward101o.mail.yandex.net (forward101o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::601]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F4D21200B3 for ; Sun, 3 Mar 2019 14:23:06 -0800 (PST) Received: from mxback5j.mail.yandex.net (mxback5j.mail.yandex.net [IPv6:2a02:6b8:0:1619::10e]) by forward101o.mail.yandex.net (Yandex) with ESMTP id 2FCCE3C0086C; Mon, 4 Mar 2019 01:23:03 +0300 (MSK) Received: from localhost (localhost [::1]) by mxback5j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id rN845CkBEY-N1Cqhh6w; Mon, 04 Mar 2019 01:23:02 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1551651782; bh=YiGPX+izENXCKymSalvQdUzGQbW5FPUv79sAkf/HlKI=; h=Message-Id:Date:Cc:Subject:To:From; b=VL8gpBUKKq2UFMAPNmheAL0k1mP6xfyq5/cwr6yQ0/Npa8kMG3PbRupCaptnfkr0U FS0U7CSOucLe68JC3QAGYmTyj/MUJnhWEVJGzBbr2U6s7OzBScB7uBR+hFJhb1kzEi b8SLu7+B4wbTScgyuYRe7Xgm/wwSubkYEbDxDf/c= Authentication-Results: mxback5j.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by myt3-c7e5d17fe013.qloud-c.yandex.net with HTTP; Mon, 04 Mar 2019 01:23:01 +0300 From: Anton Tveretin To: "dold@taler.net" , "christian.grothoff@bfh.ch" Cc: DISPATCH list MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Mon, 04 Mar 2019 03:23:01 +0500 Message-Id: <12857181551651781@myt3-c7e5d17fe013.qloud-c.yandex.net> Content-Transfer-Encoding: 7bit Content-Type: text/plain Archived-At: Subject: [dispatch] draft-dold-payto 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, 03 Mar 2019 22:23:12 -0000 Hello! Did you check my specifications of CoABoS and AC3H? See https://antontveretin.000webhostapp.com/ngmtp/ I do not pass these to IETF for a reason. Once I mentioned them in W3C (payment WG), however. I would also discuss differences in URL/MIME type approaches. From florian.dold@gmail.com Tue Mar 5 05:23:03 2019 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 33B7B130F3E for ; Tue, 5 Mar 2019 05:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMl8-2yHwDqf for ; Tue, 5 Mar 2019 05:23:00 -0800 (PST) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 36AD512867A for ; Tue, 5 Mar 2019 05:23:00 -0800 (PST) Received: by mail-wm1-x32a.google.com with SMTP id n19so2550574wmi.1 for ; Tue, 05 Mar 2019 05:23:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:openpgp:autocrypt:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=XUvKLfsveOai0Bi57jsgwjSyb6LAaOYpvPnp119+tUs=; b=nuJLDVr5gme+qUCng8O3yknZPjDU3m22UIxjOPh5OVMQgox+eqbTKLnmhHsfAaQ/bA Dt3yy1nmAeu2YnETvB324jAeMeXluuDnDCL0EXEe2Ie4XFKuddv93jjGFAI4Z+Uj9RZ2 L4mk6tFzYns7WUQcDJfKG0UhmXr2TFoEmEg9+3fap3lRnwM/AUpAYP13ErUt2s7hLE+s 6INFCHpq0MuAZfllvIIvQ4VAN2xLGoi+8D5WHGFO7ylQ/7DtoEl5bIcQ01t1b4QSzM+p tx+5XQWIdagOdXCGsi1wN56IJynFjFUT/G2WroHUWnDXyg0+4agpc9WGk9PSvyOwueYs /BNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:openpgp:autocrypt:message-id :date:user-agent:mime-version:content-language :content-transfer-encoding; bh=XUvKLfsveOai0Bi57jsgwjSyb6LAaOYpvPnp119+tUs=; b=hWsSPHA89+B0yE9o5IygdHgk2DreEhV9DB4xIzIrsVzzH7JStP5+qplrmkAAOX6w6x Ycbw/8o21p/CaItsOCj6jBlDxIffVWb/ml7da8o9TJDDZ7zaRZSRSFVtrPj0vnzdzakY 3vYjn9HbZzVwnD12AF5+8/RE9tbrUt2YYKhf41e0a8WdvD1uuXM9fIlTCyTIvJsAi2DI r2H9gceci6nfX8zJoJFCz6WY1JIMGPDFiatuqYSG6oYcCnucEA/uaxg8xiq8xebGgFjE /crdQiyx+qV4Q/nQeuLpCIilfgQRTxJ29xSNcCgX+7ryxjc0laAzZsxTXmDcygA4pXBw OavA== X-Gm-Message-State: APjAAAWFCnuelpVACPe83Msefihcnvw04uLinrtdXr7NzIlaIFj9sINW xxzqWP7SgMmyj1kctrSixyTCH5lC X-Google-Smtp-Source: APXvYqxCeQA18MALUTP74WDuAd3/F96FMJqYEtAaMIUrjdo9VgQa5K4ZdwOzF07ssXn1n+YeogcHQQ== X-Received: by 2002:a1c:6643:: with SMTP id a64mr2708321wmc.90.1551792177892; Tue, 05 Mar 2019 05:22:57 -0800 (PST) Received: from [192.168.2.100] (dslb-188-104-254-088.188.104.pools.vodafone-ip.de. [188.104.254.88]) by smtp.gmail.com with ESMTPSA id y22sm6354584wmj.6.2019.03.05.05.22.57 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 05 Mar 2019 05:22:57 -0800 (PST) To: dispatch@ietf.org From: Florian Dold Openpgp: preference=signencrypt Autocrypt: addr=florian.dold@gmail.com; keydata= mQENBFr0DFABCADIf6L8MOVfrvjN8vTPngMjxGk4gpaRAYydTYMt8I7A746E8fI4vIp66b7x ZmT+RwnR+nydTLdAMEpwsqxOUtBLBG+63v/pOFEqHaWWjoWB9tC2GKa23o5accKdeVwZAUSC d8PMCTY0An25yjspAPFeSuS8OVhNcJgqwMRLrGAeb6nOiHzNgbcH3x+z8pvZ6uEmfxOmnPxz eJ2YkRB8EZtdz2kVSAs8hnDXXhA2kPYu299N42iOnsAI/ZQLw4L4CciFD9g7yHyjSGf2ugLd v2MY/e7bg2MbrpOjl9F6tkWcMG47Q15Zg5h5i1TUWb5u6BYwTWegxjoF8aghsD4YmlDdABEB AAG0JUZsb3JpYW4gRG9sZCA8Zmxvcmlhbi5kb2xkQGdtYWlsLmNvbT6JAVQEEwEIAD4WIQTS icR018Yz2C9+q1hf73L/w6CZwgUCWvQMUQIbAwUJAeEzgAULCQgHAgYVCgkICwIEFgIDAQIe AQIXgAAKCRBf73L/w6CZwsutCACiK6SMco78RVXS0zx7nQZl5BwHr8hVj4NjMT2PgMy/HvBN kgE6QZ+nCyu4Oc25xg7Rzj0Msp66eFGJzDI9EHM0yNOvWuIrySihESd9cp8kn5oe27Wds356 MW/TVYn/S2qKAiEFzAa+pq4H7kYqOfcG3uqNH5wf1DfCKQFW3+1CBR5H2lATLqJLHDybr4S9 h+9+8LUw3KBw99mwi4UjYYyCApmXH1IuOMOMDG0r8zGxyT6SNb/A1BcCD6bjcfy8IXrNgq00 trnLEYqil17lWwV3TcHQVsMWDU2NzwX4+4rBELlLR/TOYK+XRZhgFiBH9OlvKQ+iMSdDf1SS G8YxoBP+uQENBFr0DFABCADBYR9GXjzz2FoWRTPUM9IpHBwJuBfxo/ITjwjY1+4LMnoZQjV1 TugJJoDFRQdTXod+w1iGtLCpZnWc8cgatmEPv7U6X9++X/RjrOtP/RBFRIx2gFg+QNXluxut U6aX4ag2EQSrst4CGtAJIXZvpNqv6GP11NO9aqTkrHnjAMLyO1MbtSXv3wohGtBPjGOCXmhG kOu0o27edqMPyoTjntksg6gTQoh1I1jQLVH5W1HWr0TxQnzSTloqHGf+rRYBlu5F4COeb2JD c1bqxaJMpXzA0IMGEFOeUPN6k6fvaadAcdGN6apLmU4jhhizAC0FvQNEWChd5WTVWR7DP5Uc gOSHABEBAAGJATwEGAEIACYWIQTSicR018Yz2C9+q1hf73L/w6CZwgUCWvQMUAIbDAUJAeEz gAAKCRBf73L/w6CZwjXsB/0QCZvO+chvdd719yAFLEAkhGxPeolvJaGudg1AY37dx0NaeBhG DzE6kWXCSD0Sp/1+36hTv680+I+L9gQW9p3mZRyT/syI63aEMIPAWCCVy7OokujVs0F8oozI CJexqdMP7jho5zDU9ecIMNo7zOo7+U4mfNPnS70wJmdBO2s9edVmXkfkEzuL6fGuDFdjC3le AfLLDlYsZ/7jUWX9UF+U05mjSI+1w3vmUigufKdf3h65s4xcgRr+BR0uuAG81oJ+/eiEyv+i yo2U+n+RaH9yqO4rrMgQFnMrfr0JQ6CDSklup4LRPjpjvdqX900QkVWErvMxDnC66pyur0o/ 3rSx Message-ID: <64394269-b734-95d1-a18c-cb1e70daa449@gmail.com> Date: Tue, 5 Mar 2019 14:22:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US-large Content-Transfer-Encoding: 7bit Archived-At: Subject: [dispatch] draft-dold-payto-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 13:45:22 -0000 Dear all, We've updated the payto:// URI draft, based on the previous feedback on this mailing list: https://datatracker.ietf.org/doc/draft-dold-payto/ After consulting with a domain expert for SEPA, we've also changed the "sepa" payment target type into a more general "iban" target type (as both SEPA and SWIFT use IBANs). Now an IBAN (International Bank Account Number) can optionally be scoped within a BIC (Bank Identifier Scope). We'd be happy to hear more feedback on this decision. We've tried to explain the question of "why does there need to be a unified payto scheme, instead of many schemes for different payment systems" in the introduction. Various applications detect certain URIs and make them interactive (mail clients, chat applications, ...). When there is one URI to address payment targets, adding a new payment system does not require all these applications to be updated. For smaller or very regional payment systems, it might be impossible to get enough recognition to be detected as clickable links in common applications otherwise. Additionally the "container format" addresses common issues like the amount format, as well the distinction between a "message" for humans and a machine-readable "instruction" that can't be subject to lossy conversions. Similarly, security and encoding considerations apply to all payment target types. Both authors will be present at IETF 104. Would it be possible to present/discuss this draft as part of the dispatch session there? Best regards, Florian From nobody Wed Mar 6 12:15:46 2019 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 88A3E12D4F3; Wed, 6 Mar 2019 12:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, 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 UgGVMrh9PZ1l; Wed, 6 Mar 2019 12:15:43 -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 2753712D4EB; Wed, 6 Mar 2019 12:15:40 -0800 (PST) Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x26KFaUB086911 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 6 Mar 2019 14:15:37 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1551903338; bh=RR+I1DXJWM4jPO9zA7jPFtdgiZSpbfc15GR0Xcgys98=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=F+Dg9r01eV3aRzYiPR9lFyJXQLdYEsDhiS3k/yHwko3oQbNGth/OnLor00IYiNYW8 2IPUjD3ipmEzZvf1RRwk3DChKFsBJCjMe+wFpoMLYi5zs8CylSMbLyLoslNlVAiz8W nXFmRaBu8nKtYkqae0n8QpZ6LEWnQYkyU/7MFQQM= X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan From: Ben Campbell Message-Id: <265F0A34-4229-4B0D-9D32-A15B93234B4D@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_2824FC82-F5E6-42B4-B74D-F947E447E5BD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 6 Mar 2019 14:15:29 -0600 In-Reply-To: <64394269-b734-95d1-a18c-cb1e70daa449@gmail.com> Cc: dispatch@ietf.org, dispatch chairs , ART ADs To: Florian Dold , draft-dold-payto.all@ietf.org References: <64394269-b734-95d1-a18c-cb1e70daa449@gmail.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [dispatch] draft-dold-payto-04 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, 06 Mar 2019 20:15:45 -0000 --Apple-Mail=_2824FC82-F5E6-42B4-B74D-F947E447E5BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Florian, (Apologies if I=E2=80=99m repeating something another AD may have = already told you.) The ART ADs have discussed this, and we wonder why this needs to be an = IETF stream RFC. The URI schemes registry is only =E2=80=9Cfirst come first serve=E2=80=9D = *FCFS) for provisional schemes. FCFS registration does not require an = RFC. I see that the draft requests a permanent scheme, however = =E2=80=9Cpermanent=E2=80=9D status is not appropriate for a new scheme. = The normal procedure is to register it as provisional, and later promote = it to permanent if it sees widespread use. Based on that, we don=E2=80=99t see the need to spend DISPATCH agenda = time on it. Is there some reason that we are missing? Thanks! Ben. > On Mar 5, 2019, at 7:22 AM, Florian Dold = wrote: >=20 > Dear all, >=20 > We've updated the payto:// URI draft, based on the previous feedback = on > this mailing list: >=20 > https://datatracker.ietf.org/doc/draft-dold-payto/ >=20 > After consulting with a domain expert for SEPA, we've also changed the > "sepa" payment target type into a more general "iban" target type (as > both SEPA and SWIFT use IBANs). Now an IBAN (International Bank > Account Number) can optionally be scoped within a BIC (Bank Identifier > Scope). >=20 > We'd be happy to hear more feedback on this decision. >=20 > We've tried to explain the question of "why does there need to be a > unified payto scheme, instead of many schemes for different payment > systems" in the introduction. Various applications detect certain = URIs > and make them interactive (mail clients, chat applications, ...). = When > there is one URI to address payment targets, adding a new payment = system > does not require all these applications to be updated. For smaller or > very regional payment systems, it might be impossible to get enough > recognition to be detected as clickable links in common applications > otherwise. >=20 > Additionally the "container format" addresses common issues like the > amount format, as well the distinction between a "message" for humans > and a machine-readable "instruction" that can't be subject to lossy > conversions. Similarly, security and encoding considerations apply to > all payment target types. >=20 > Both authors will be present at IETF 104. Would it be possible to > present/discuss this draft as part of the dispatch session there? >=20 > Best regards, > Florian >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_2824FC82-F5E6-42B4-B74D-F947E447E5BD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlyAKmEACgkQgFZKbJXz 1A06nQ/+O328SY10BZv3pguWAfo4R9nhAhEN15SrqZRxjxHVo6VkdbeygIZlIzet 56ZC0NHI97rdeH/e7Ac/QkXtEzVpVGT4SWEIwFbT93PvDX4/zHlBpXmI7+aBopi9 7WxZG/OacY7GFllaTopkjxGs5F9XngZ3wgvgSv+By5oLmbzLH/hInFTihPFo0me7 TPl3D6eTMRvta9OFt8Bvbq2wVrnZeYE3OhPtwOsvPDvSvtH1za2WtlcWv9QO5Anx DlwRKAPgU9R9a67pitzVSKqrte5UnzfbI2bfBfVPIrBeAtnjzOWFMoQCa1cxFZbk 8SRTFe+4XkHvyfP7RzRSYbbiVWIofuwvDVWGEnk5RMu3lPNFu9NpDGcDBJTv+gMK QxwM4rVaR0xtR+/RYsqkfx+oxAkTZKC+zCVNAOYIi0F//W9iGKHof3CxoHpnqVmL jsRy94M+dRa4rNJEq74WWUudQrN/HNjY5KiYaL0rwZg/mYomz2I9yEPQoA7DE3FM PRZMewDjltg8Azcek9oVwoyGrdqstR2zmQwxVlNLjiniCS+RbbgLAzQJkVhZU5Mt cd87w+sS46FXSWUTFzTCAh9ZAwijC7ZSGPaJHpXekxQresrZavHsunQURrGSGFzA Dhb1kGtCz9xXraNKIblIYbTpFxygaGiS3PS/oqnX8G9ki8IIBYI= =hHgV -----END PGP SIGNATURE----- --Apple-Mail=_2824FC82-F5E6-42B4-B74D-F947E447E5BD-- From nobody Wed Mar 6 20:08:23 2019 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 A4302130E57 for ; Wed, 6 Mar 2019 20:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIxxHlppEF6E for ; Wed, 6 Mar 2019 20:08:20 -0800 (PST) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 DB9E412F295 for ; Wed, 6 Mar 2019 20:08:19 -0800 (PST) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-06v.sys.comcast.net with ESMTP id 1kC6hMGNqvmyQ1kKQhH0hX; Thu, 07 Mar 2019 04:08:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1551931698; bh=weTEFUd0/7u52w5TJV5uFz3FHfcWnNzD6MtAZw0G9dM=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=Xoav4QhzZ0pGRsqIgwthSjIxnSxQBidOW3ihZglq06ihw6fDLIDWFp/m0Fcj12TKQ 6dETmMPv6zimfDKypQoJrrjqp6rfe3a6cEqR9DT7wc4hu0sYtQzB+x/rN39r/VeovZ XfFbMtkjoptxDr8fPnTwm4oFRHIC5LKMtV7ikEaLeaOqUqJF0riDegKOIVDK+pNWwB H+Mh56s/cUB7AsC2LjRvN6vx+ZHr1RCOAwYExHaF2ETiPh1025ZlcCGDxdYIfH5D4n IUepaAfbpfwR5TnVIxCNflyLWVwy3h8k+W8MDJ+niYRhd+BIcEnKIfQvmpDG3ZSLrG keQnw6dwer0aA== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-16v.sys.comcast.net with ESMTPA id 1kKQhnSWUcxRX1kKQhr744; Thu, 07 Mar 2019 04:08:18 +0000 X-Xfinity-VMeta: sc=-100;st=legit Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id x2748HBj025472; Wed, 6 Mar 2019 23:08:17 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id x2748HIl025469; Wed, 6 Mar 2019 23:08:17 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Florian Dold Cc: dispatch@ietf.org In-Reply-To: <64394269-b734-95d1-a18c-cb1e70daa449@gmail.com> (florian.dold@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 06 Mar 2019 23:08:17 -0500 Message-ID: <878sxrconi.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [dispatch] draft-dold-payto-04 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, 07 Mar 2019 04:08:21 -0000 Florian Dold writes: > We've updated the payto:// URI draft, based on the previous feedback on > this mailing list: > > https://datatracker.ietf.org/doc/draft-dold-payto/ Looking at draft-dold-payto-04, I see the BNF: opts = opt *( "&" opt ) I suspect that "&" is a remainder from some conversion process, and you intend "&". Also, in: opt = (generic-opt / authority-specific-opt) "=" *( pchar ) note that "&" is admissible in pchar because "&" is in sub-delims, which makes parsing an opts difficult. (Annoyingly, the current IETF BNF doesn't seem to have a simple way of saying "a pchar that is not &".) Dale From nobody Thu Mar 7 05:54:04 2019 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 42C92124184; Thu, 7 Mar 2019 05:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WpfRMqpQoWZ; Thu, 7 Mar 2019 05:54:00 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) (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 7CA0612008F; Thu, 7 Mar 2019 05:54:00 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.86_2) (envelope-from ) id 1h1tTC-00057W-5y; Thu, 07 Mar 2019 14:53:58 +0100 Date: Thu, 7 Mar 2019 14:53:58 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: IETF DISPATCH list , IETF SEC DISPATCH list , IETF SAAG list Message-ID: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Archived-At: Subject: [dispatch] New Version Notification for draft-birk-pep-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 13:54:03 -0000 Please be informed that an update of the Internet-Draft draft-birk-pep-03 has just been published (see also below). It describes in general how pEp (pretty Easy privacy) works and it serves as a starting point for the MEDUP (Missing Elements for Decentralized and Usable Privacy) discussions. Discussion of this Internet-Draft and other pEp related matters is taking place on the new MEDUP mailing list (medup@ietf.org) from now on. To subscribe: https://www.ietf.org/mailman/listinfo/medup Looking forward to all your comments and feedback on the new MEDUP mailing list! All the best, Bernie ---------- Forwarded message ---------- Date: Thu, 7 Mar 2019 14:15:11 From: internet-drafts@ietf.org Subject: New Version Notification for draft-birk-pep-03.txt A new version of I-D, draft-birk-pep-03.txt has been successfully submitted by Hernani Marques and posted to the IETF repository. Name: draft-birk-pep Revision: 03 Title: pretty Easy privacy (pEp): Privacy by Default Document date: 2019-03-07 Group: Individual Submission Pages: 31 URL: https://www.ietf.org/internet-drafts/draft-birk-pep-03.txt Status: https://datatracker.ietf.org/doc/draft-birk-pep/ Htmlized: https://tools.ietf.org/html/draft-birk-pep-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-birk-pep Diff: https://www.ietf.org/rfcdiff?url2=draft-birk-pep-03 Abstract: The pretty Easy privacy (pEp) protocols describe a set of conventions for the automation of operations traditionally seen as barriers to the use and deployment of secure end-to-end interpersonal messaging. These include, but are not limited to, key management, key discovery, and private key handling (including peer-to-peer synchronization of private keys and other user data across devices). pEp also introduces means to verify communication peers and proposes a trust-rating system to denote secure types of communications and signal the privacy level available on a per-user and per-message level. Significantly, the pEp protocols build on already available security formats and message transports (e.g., PGP/MIME), and are written with the intent to be interoperable with already widely-deployed systems in order to facilitate and ease adoption and implementation. This document outlines the general design choices and principles of pEp. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Mar 7 07:59:30 2019 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 C6A5B12B001; Thu, 7 Mar 2019 07:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sY2kWyKmfEyY; Thu, 7 Mar 2019 07:59:26 -0800 (PST) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 7AA0D127971; Thu, 7 Mar 2019 07:59:26 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id d14so14689418ljl.9; Thu, 07 Mar 2019 07:59:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=e3sIBLH/yxYg3XFJ/EV7D5g9ehDdCqthYfkR9Jcsux8=; b=r96nNYEi6Brexkw44ixqOX20fRlhmtpgrJ5iHo0HeQtT6tHFRR5D3p1haej3BSNhw4 J2DyMDkFt5GrnZimJ6DDoR2/qMVSLTHv0Ehr/j6a9THEE8J8MQ3EEpKSIkNK1BQD6z2I xgkJ+hL1WP68JkC/SCbycKB9awIICsDqkWbYDQlS4ZIPC1oNpTODg3MafGXTXBJYodJs +KcH8rrh1p8tcJTiSvfbvDGPbTpSUvbUEebmA7siPOFBULfcAvBlUjpDXMCdB9SldWEA X3rzInZ2Kr4iaw4itbzOl7pCTGXSLjcFnvApPLkteNs7PTYA3hrqrAR6Jir8YRV2mRyH +jaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=e3sIBLH/yxYg3XFJ/EV7D5g9ehDdCqthYfkR9Jcsux8=; b=Mmqz4ObTcXevbS3TIWhCcRmcHTJCVUljmEiwAaaR+KFCaogGqQTFud0Cr2JYrwBJxt BheHyhJXzZe3lbWzCRpqyXHL3fzKfZ+zYwy/H7W3N+Y6FiOyc14OeFpG6vnwlA1TAmr1 dHT7IdeH4ApkOOF28Park0ktfnErpoCFwcbngbPSmQ0n528KDDX5PyqWRM4bAed8Z4gY gNq8aQ1TfVQ9INHZMC+jOdBz92mwSq1iMAYAwe+Isq77YzZ35Ofzvd8u+zEY0fUUx8rN 0QUoNquFLYzSA0uqDebU2GS//DvfvPwkElWZQg6smE2/WuKA6xSJloxIXSC8lZgrW3U3 Q4gg== X-Gm-Message-State: APjAAAWaM9X5Xnw3S5JNwzJ8oHemf8Ax73QG+cplHIrOnIDAWpfy/V7k LDhFxGdELjvp9TTDo9XMbv9Ld/C19j4s9soj78DYdimg X-Google-Smtp-Source: APXvYqyad5v3bPOzz9qf0w1n9hoWQTiQp3L2Yea39GvV4po92MyhAqIJ14rvy21LHZj4FvIUwiHG3FF0uvG7t2POvAc= X-Received: by 2002:a2e:9703:: with SMTP id r3mr6287515lji.1.1551974361037; Thu, 07 Mar 2019 07:59:21 -0800 (PST) MIME-Version: 1.0 From: Mary Barnes Date: Thu, 7 Mar 2019 09:59:09 -0600 Message-ID: To: DISPATCH Cc: ART ADs , dispatch chairs Content-Type: multipart/alternative; boundary="0000000000007d8030058383306c" Archived-At: Subject: [dispatch] Topics for DISPATCH @ IETF-104 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, 07 Mar 2019 15:59:29 -0000 --0000000000007d8030058383306c Content-Type: text/plain; charset="UTF-8" Hi all, The wiki has been updated with the topics that have been agreed to be discussed at IETF-104: https://trac.ietf.org/trac/dispatch/wiki/WikiStart The proposal for moving forward draft-dold-payto is still being discussed amongst ADS/chairs as is the JSON Canonicalization that had been proposed as a BoF in the SEC Area, but was not approved. We will post any updates to the wiki and will post an agenda shortly. As a reminder, if you are submitting drafts for discussion in the dispatch working group following the standard convention of including the WG name in the draft name (i.e., draft--dispatch-blah-blah) makes it *much* easier for me as chair to make sure I have the right documents identified on the wiki and on the agenda. The tool will allow you to indicate that the document with the new name replaces the document with the old name if that's a concern. Regards, Mary DISPATCH WG co-chair --0000000000007d8030058383306c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

The wiki has b= een updated with the topics that have been agreed to be discussed at IETF-1= 04:=C2=A0=C2=A0https://trac.ietf.org/trac/dispatch/wiki/WikiStart

The proposal for moving forward draft-dold-payto is still being dis= cussed amongst ADS/chairs as is the JSON Canonicalization that had been pro= posed as a BoF in the SEC Area, but was not approved.=C2=A0

<= /div>
We will post any updates to the wiki and will post an agenda shor= tly.=C2=A0 =C2=A0

As a reminder, if you are submit= ting drafts for discussion in the dispatch working group following the stan= dard convention of including the WG name in the draft name (i.e., draft-<= ;name>-dispatch-blah-blah)=C2=A0 makes it *much* easier for me as chair = to make sure I have the right documents identified on the wiki and on the a= genda.=C2=A0 =C2=A0The tool will allow you to indicate that the document wi= th the new name replaces the document with the old name if that's a con= cern.=C2=A0=C2=A0

Regards,
Mary
DISPATCH WG co-chair
--0000000000007d8030058383306c-- From nobody Sat Mar 9 02:42:18 2019 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 A68AC12B001; Sat, 9 Mar 2019 02:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyIi7YScgmU8; Sat, 9 Mar 2019 02:42:07 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C289B12870E; Sat, 9 Mar 2019 02:42:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 7CF801C1C11; Sat, 9 Mar 2019 02:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoP3top9pKx8; Sat, 9 Mar 2019 02:42:04 -0800 (PST) Received: from www.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 569BC1C1888; Sat, 9 Mar 2019 02:42:04 -0800 (PST) Received: from 87.112.237.8 (SquirrelMail authenticated user rfcpise) by www.amsl.com with HTTP; Sat, 9 Mar 2019 02:42:04 -0800 Message-ID: <1d369e948382f1431f6e67abce4ca0c8.squirrel@www.amsl.com> Date: Sat, 9 Mar 2019 02:42:04 -0800 From: "RFC ISE (Adrian Farrel)" To: secdispatch@ietf.org, dispatch@ietf.org Cc: sec-ads@ietf.org, art-ads@ietf.org, draft-gwerder-messagevortexmain@ietf.org, "Adrian Farrel" Reply-To: rfc-ise@rfc-editor.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Subject: [dispatch] A protocol for anonymity 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, 09 Mar 2019 10:42:10 -0000 Hi, Martin Gwerder has presented his draft to me for publication on the Independent Stream. https://datatracker.ietf.org/doc/draft-gwerder-messagevortexmain/ The document describes and specifies a protocol designed to achieve anonymity by embedding messages within existing transfer protocols such as SMTP or XMPP. Martin tells me that he has made some overtures to the IETF, but has been unable to find an opening to discuss his work. I think that may be because it can sometimes be quite hard for a newcomer to work out how to find a way in, especially for a topic that is not easily aligned with what we're currently working on. So, before I take this under my wing, I wondered whether you see a place where you think this should be discussed within the IETF. Thanks for any clues, Adrian -- Adrian Farrel (ISE), rfc-ise@rfc-editor.org From nobody Sat Mar 9 04:42:59 2019 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 1C41F124B0C; Sat, 9 Mar 2019 04:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.62 X-Spam-Level: X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00dKRb3s7-pI; Sat, 9 Mar 2019 04:42:54 -0800 (PST) Received: from dragon.pibit.ch (dragon.pibit.ch [94.231.81.244]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B3E912787D; Sat, 9 Mar 2019 04:42:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by dragon.pibit.ch (Postfix) with ESMTP id 255B2171C06D; Sat, 9 Mar 2019 13:42:46 +0100 (CET) Received: from dragon.pibit.ch ([127.0.0.1]) by localhost (dragon.pibit.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHAad8Hsb8QM; Sat, 9 Mar 2019 13:42:43 +0100 (CET) Received: from [192.168.43.249] (120.233.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch [178.197.233.120]) by dragon.pibit.ch (Postfix) with ESMTPSA id 32D90171C05E; Sat, 9 Mar 2019 13:42:43 +0100 (CET) To: draft-gwerder-messagevortexmain@ietf.org, draft-luck-lamps-pep-header-protection@ietf.org Cc: rfc-ise@rfc-editor.org, secdispatch@ietf.org, dispatch@ietf.org, sec-ads@ietf.org, art-ads@ietf.org, medup@ietf.org References: <1d369e948382f1431f6e67abce4ca0c8.squirrel@www.amsl.com> From: =?UTF-8?B?SGVybsOibmkgTWFycXVlcyAocOKJoXAgcHJvamVjdCk=?= Openpgp: preference=signencrypt Message-ID: Date: Sat, 9 Mar 2019 13:42:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <1d369e948382f1431f6e67abce4ca0c8.squirrel@www.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="15GsM9x9sqOeANIq7pH6mHs3e60SJeu85" Archived-At: Subject: Re: [dispatch] A protocol for anonymity 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, 09 Mar 2019 12:42:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --15GsM9x9sqOeANIq7pH6mHs3e60SJeu85 Content-Type: multipart/mixed; boundary="FDxD1FKgPrZRoNOImPXXM468qv53hOI6p"; protected-headers="v1" From: =?UTF-8?B?SGVybsOibmkgTWFycXVlcyAocOKJoXAgcHJvamVjdCk=?= To: draft-gwerder-messagevortexmain@ietf.org, draft-luck-lamps-pep-header-protection@ietf.org Cc: rfc-ise@rfc-editor.org, secdispatch@ietf.org, dispatch@ietf.org, sec-ads@ietf.org, art-ads@ietf.org, medup@ietf.org Message-ID: Subject: Re: [dispatch] A protocol for anonymity References: <1d369e948382f1431f6e67abce4ca0c8.squirrel@www.amsl.com> In-Reply-To: <1d369e948382f1431f6e67abce4ca0c8.squirrel@www.amsl.com> --FDxD1FKgPrZRoNOImPXXM468qv53hOI6p Content-Type: multipart/mixed; boundary="------------3C4B95A2605C1E2783AAC03A" Content-Language: en-US This is a multi-part message in MIME format. --------------3C4B95A2605C1E2783AAC03A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Martin Thanks for this contribution: that sounds very interesting -- we already had such ideas already in within pretty Easy privacy (pEp); by instance, for PGP/MIME with the SMTP transport, which is one of the reasons why we do header protection by encapsulation (cf. https://tools.ietf.org/html/draft-luck-lamps-pep-header-protection-00) ; not sure yet if your approach works on the same application level, but discussions on such approaches should go forward. =46rom pEp side we would also be interested to contribute to actual implementations in such directions. Is there already any practical work? Cannot grasp that from the draft. :)= Greets Hernani PS: I also added the MEDUP list CC, which exists to discuss concrete drafts (ideally with Running Code) to achieve decentralized privacy forms: https://www.ietf.org/mailman/listinfo/MEDUP On 09.03.19 11:42, RFC ISE (Adrian Farrel) wrote: > Hi, >=20 > Martin Gwerder has presented his draft to me for publication on the > Independent Stream. >=20 > https://datatracker.ietf.org/doc/draft-gwerder-messagevortexmain/ >=20 > The document describes and specifies a protocol designed to achieve > anonymity by embedding messages within existing transfer protocols such= as > SMTP or XMPP. >=20 > Martin tells me that he has made some overtures to the IETF, but has be= en > unable to find an opening to discuss his work. I think that may be beca= use > it can sometimes be quite hard for a newcomer to work out how to find a= > way in, especially for a topic that is not easily aligned with what we'= re > currently working on. >=20 > So, before I take this under my wing, I wondered whether you see a plac= e > where you think this should be discussed within the IETF. >=20 > Thanks for any clues, > Adrian >=20 --------------3C4B95A2605C1E2783AAC03A Content-Type: application/pgp-keys; name="0xCB5738652768F7E9.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0xCB5738652768F7E9.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFWozlEBEADAIFgjylzzPH7JKRJPbiEGoSsrSaCrbWLdy4sNGD4fS7GsuZ9f o/E9iYzC7WwGhN8rB4jsLv/ZfGVbAsmpypvZdReVs/BPidR8Vo1WMOK3lww1L6j8 7UV7TwUzG72u0zMXCUWMtX3+7kWZVlohXPCzDe7xyLu5tdfPWIAxDrI3h/+a4qAR ySVo8RwzILDwjbLF8at0w52oTRIWcr9CAus8ktRKBhc3MiUsSXHGgZLujUsXKAYg Vmh53uEVsjigeHZh6XPrzQPTnQ/VDcqNSRl4n+fQ2e/sZV7CQttcqb9zfj8P6Lyk jG3pe1AUSm9A0o75bi8PUluPWyH0wdt4D29xabFFyBANyYqKiLyZvnBqGSkqswnW 00QoYtMaEBh7nyuoUCa0bTMCRn8NaXRCnuINx+E2llqJqeQ0sMJ5WSQe4RbkWRsF PJOdiouLyHEZUpyQlMFesu/mN565eZsw3a7u9hxnoFgX0tF0hoONMRSAU1y3aZeb a+DvwXDQcSaHmBARQ2v8qWdql16Zhvf7KFo5Cris9jNknInzs2L6pHVZN8AY2ESO 2UXQJ+Fyy5BEHXS4LzEnWRPLYkAE5eVi+ZDcRMQeO2L3ZenqhcRRcQUAaRObho0L WzE+EE8ZvQxlA5hn/4/lHQLk8ZiEgenl+y/mtL8TeXB1HO4DrqahXvlu2QARAQAB tDxIZXJuw6JuaSBNYXJxdWVzIChw4omhcCBmb3VuZGF0aW9uKSA8aGVybmFuaUBw ZXAuZm91bmRhdGlvbj6JAjkEEwEIACMFAlcnOjUCGyMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDLVzhlJ2j36SSQEAC7L0ZgFNXZAsXUzDIj7ZcyG41jcIaF oBz+VyIz/72zsr7tR469bq9QulnEdhr5Zxa+sZauT+tktmehpQpkwAZRXb4jHawS MVGwzssKehUe+sN9rrkIKvFbKMHcL/ZUiaFKNL0dX/tbtA/lZGwMSGlE9x1BWPKX JrqiKUpvk278jFwkOfx+mzVSuuIcIn2o25BM6n4wxQnDizcES2Z9nXyYzSBagvW0 v2LsOEatYgCFoTxuO37uPHXL3NlhipRx5dfIxKjX5zr2DOxKcS7SPio9cGJ8Z5gB jfC3ByoZfQVmrR0lfIxZVtFTzR8my+fOLDhL5U+3RVbGHHHjzJZY03a8RUpcWsMr +lsogSH4h5z8QgkwfhTyBAUIcewHU5128dRG8m+wfTTHnQFCpmd0Ql3beRbAhN/e xQx5aJq81rPD7dunQtKB7iyiDpHjLWJ22aBr75GjSfF05Gr4LgLMFkATzrpnlXyR uLtZ0TTURWw+pximLJu/Smn5CKUClJayGOgp8a6bmNlxn6li6SZVoyu/S9RCUWTB z2dsv+iDjk/La7gcLxwrtkf2wFxvauaax5BjXoEnOAsD12wF3Snr6ymARh65rZ+C /HaiRpUXoUFIWUh0gRnJHa+EOxXq2wKBJul5toTlOEiqK93vVwKLlPgjiEY5NHEU 7zpE7skkXYqKhIkCPAQTAQgAJgIbIwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheA BQJXJzpdAhkBAAoJEMtXOGUnaPfpktIP/iTLClFO8y+KN00z7cHxbistBKjkFlS+ Q4RzNmXQXgXMaB9pMvIbCP6Fm11q13GGT2MLm5gpoIBH50/fCXxWPGaeMRyKvv3p PDbSwm7J7hDP5H2yCGclkzs0NntiZXbOmLhFdZjsIhi2GnNSrUve6MOUM18p0ph3 f0+Ia3Ki3HaURLD4sGUJ12ig8tLI82nt+NaxEKCaD7b7KtV2XtMQ7RAVwax8to2m PBWzZReX4nMmqX8LNXhn1DFkCSGCl45umK7i39Em4+OYpLyWy3vMmKuGXA6uVenl WQbKuaw+Rer+MUOTM2sABfm5ffiNMGBO94JEGvgwSVUCmrqyBsZ846q+FTlJnapY /D63bIeINuX20TYxpzZSKh0U9sVKU6cd3koeH6CFYPLEICQBzDFZ7GTg9MJbAbGp y/P3klwdfHo8AcM6QIH7MIdfrkk5WljF1vz3FvWcGmoqmGRdrHt/JBsDw94p/d6G n/HWAX3gJvrF6+BTDUZ6pmhRFXrk71/M7Qz7FI2NzIv5XWmzYhxkQ58om1adBhx/ PQZmCFJeXkp0pIBSWa3vuca6LOwsvipRoMhXSm9UCYFmYtsny871dIEMWfDaYisV mBSKRw2mZnAo/sjARxjqrPUEAIbzGJL3ePnyqj0P0mLYOqiEi+wxMEUzYpCn9WZc r1I/JWQ1Bri+iQIcBBIBCAAGBQJXe+cuAAoJEH+zxRJjw92vLy8P/1xWquKLJ1E6 n0aDRPLRKV3dcdTS1CzXLbGOp1IkPrg35hAJtiqhlYDWqY7Ff/oHzYFwi1iClHwq FCTx3U2nGAU6O7/TVR99c9FTV4UdbO/et3J+rb6dRm3e+DoqCgBq/uvCrg7I8Gcw vTLOnIxXeL9N7ZIzV7Ac5rdowvzCMhGClRrT3im3fBpbe4EbHPfrTtBclZhL52rg 2EYrfwu8b3OeNgNzEfS+T0GM9O9ZeTVU6xqtqCfyYYzTSOTL0nLxabl5QjSq+Xn1 9Ye7tDGDIE47Tt1XCMQANwpfQzDYbJhYeXhX9fUw1oDIX0EbGJI/X7aHhDPn+bFY RsBUS7x/tuD6STnbDLanNjRvyBpttMkMwW9udO0QmMwApZ1PqyB+xGoKQCQhnN6y 6RQDUjMBD180J0i6f9K5zezwrAqWjQo8fU7S5Q02d91iRk3msZtbNR6nM+ulVX8s 8iKhHDBiJdzW8WT/wc2R06ch8LQ20sNscU4ZrdcC5IOL5uadCT0NTCr85vC47Qgw 2Ywe7lYwvamkU9GeM0xIs5ZaLkC9PpWOGnQbrpFDod0nL+mot+/bdtI8fX+p99aC xmHAG9GIt4V0unAVvFo6HQUKN5h49sfLQk5nZqAfhrxFgoKPeL5IvTxls+D1+/1W UHBc9FkdnBLYOQz+IXKfpjf6Gus5u2dTtERIZXJuw6JuaSBNYXJxdWVzIChw4omh cCBmb3VuZGF0aW9uKSA8aGVybmFuaS5tYXJxdWVzQHBlcC5mb3VuZGF0aW9uPokC OQQTAQgAIwUCVyc6TgIbIwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEMtX OGUnaPfpn3gP/1V3n9Xt8ha1juDe11jq0y0g1jQr1JMhZOoBOp6ttSpYCe9HCoJw VyvO1iGLex6XHSe8zrWvP38aihFoK7jQBc8xwYht1DcpTM7HFyXJ5/Pch8BNS4ds c8eozvm96pBPPmFDcm+igG6dkO81/9oLqP8+Bagz8G58BktcFhvnjmLrkJftJAJQ 4LyP5KlXgmUIxu9l//Wa8AMkty+feHTIIbrQGDTM44a9N+uHwJ4OQjHNvvOprg4U ZAhehLAzCk+gi68uHfhH0AtKwZ/v/lag7OYle0KZelxFsHnVE+Dhe8HlyKqtCCOC vkWGtz5CBJDO/V/xUQXBSJxJd4Q4w9Gyf0mJ+Ljr8iu1fyaEor68u1ZGkaWbzQSF 8Ycx7o6MWV1fAyFpUNUs3M3vpmJpwrWQdNeCpQaczexnNcrzrYdFDLx8z7MMHEy8 6QSmjmaDSA+VgAHzV3oo4R3Wu3wZKDwm4eFDBj8N5IBxMMfjfinnJb01WkAeRtAq K9KdXeWGs6eO6OBm8OSpao2V/lw3IZIiCdowPaEFzw96DwmES/zTAis74mENrhnb vDrzFVFkNOUdf2Sn9x81FJ7X13TEjENUhJJI87W+Ttk9eKUarkjtKdHfVpEMnO3L g6NJiAvwpcYfarzfmorrwp1pscLZBEFGiAuHVgNzY1YwXMirPVnY7MnziQIcBBIB CAAGBQJXe+cvAAoJEH+zxRJjw92v9lAP/2LhBOb9ztjDKSNJMn1IXJK9ALYor7wG 3JrQvwJGdfKRj8b3p8nlGCtFpo32h/7t/9lNxPJmONJcc76Y+fqviseRNk05iGCO IycL8Q+2bLvzQP1w3exvo2imgJGgtZFZqQR6K/D70TrTwcyzpW6h+lN3ZmZu4Izv 2pdtJMh83PZus0A1cHQUhIjCl46+uNT0BaEAdDpqcC59EWFFwPj+zEhZgTtrAU9c hSXj6s4254WMKa3BIuy90bWqyMuJt8+mLYTfnpNxaYrMX/puC5hs1WQi0BQVXdLR ooSOgYDaip0mXiOyqXHS0V94fuiONqzYYBjQBkpheorVuMDZL49bh2c2VyANxAaf cZSN82isbQG1anl6LJRRiGm6BYC+Ew8OWmVkCEWOK43G6IQ+Nl5Bmv+FyIoBQzaZ 4ioR987nC82cLCbtaMMs9ib5cTZBEIAeDaD0THl08pCLkfR4nPLG/u+dTE5zxSrC P4o7OKLLnYTcOkU9WdhfZV/6a6iBJy3uvuFDoeoJG3Zv037gHFsmd83mo6xm9qls RyY3vOTtxJRxsn6mn4/RetutDxJxvubNZaxxL33coGm8GcMM3BaOdZiRgPOR9E5S MUrlnpaMwWno/mO9ivifW/BFSetfGN37wGeOcoMwwSCfj4OK9WVhfJFqFweL4StM BCQ6OZLcxWb3tDpIZXJuw6JuaSBNYXJxdWVzIChw4omhcCBwcm9qZWN0KSA8aGVy bmFuaUBwZXAtcHJvamVjdC5vcmc+iQI5BBMBCAAjBQJXJzp2AhsjBwsJCAcDAgEG FQgCCQoLBBYCAwECHgECF4AACgkQy1c4ZSdo9+kEng//VY+l7xtGPe9q/FwmZ4Zy APJn/hnwDjGhPeuEgsT4IgX220NB3UEXFAx8tCSuGY85862dC/AGQeGnzoM5u7rl TRFGuv92EtE2n/2Lfbte6yb5MRmzTgdR7cP1aNpvjCN+kEp4FfmHl1XPBFyX6WLE QG+ZnUDFIyHt2I7dehdN8UogJHdIfZ9y3IEhwPqAYq4CRkf7P8Zkk2km2Jh8Xjjg L5dsjCQKuNAnyktDpxUM3N/ifsOfrNulEIKlDA2yW3kcGL3CPj2ugwXgkSykeXaB zVoqbqRcPOO8/J7mVEOoLVjPwYq8f5NGWq2U0rbJnRTHX4benaxw7rCi+6nbAEHT j0zbpx6FH8fezuzx86dWlFngqzQDOkiZWzc7ql/eb7pzHXuQ3QC1D+zzNn9TSTSD AjRFpgIuPWkAb/7/WyRfwqd0XzqinisA78I+E+0MOhjpQab/i9hoQRB2LfGaI+gB taRX3aRotXNT1E5R1fq67r890Sjt3XTzADK9B6RqpMa6T0LDe4zS2CYnDbUBjljs YGR5WZ7K03Qx2p9qfCFBTt2wvy2J0b526b0yCRINc6TWDs/SlRqSs/ATaPSbOKfV UhXI8k0k2SV6FSBEPwIY0cUSRPSoANfv+IXjiW3RBbjNkvpbVtu98CDSbMBefAc3 X8oVtrZ+rigZzd41QAhaOp2JAhwEEgEIAAYFAld75y8ACgkQf7PFEmPD3a8pNw// fQnOl3/RamWxLz3Vs2Righ3M1kZg+NjQ48mIqmSZLzwu9MQTn71nOUdyBnkmEm+b sYviNPQha93wYx4i2ioLKNSXyDa1dBbQloidQm0b3TkeU+5a/CN7r2OauReNvc4V gVupxaeUyEToFW/RnQihbu17zZkwqTmKolQ3hd//1P9nFGccYU/G4DQUonuBzCV6 uOIKZ43KBA8vm4nk8uAW0PNLJHOaVM+vuDgLqx/r703RE1YaebvNC3IuXTfXpQHC GMa/gJQpxGmqLjlKDC63k1lYAk5gApkfj36+RPAiWYpGvo3i0EXTrXlwehqRJoYA 8lNswk7LcvSFXfKugomMtCtH4vJUNL1sgE8tpWhQD73K8q3cHXLPIC3Tk0If+7h3 xdnZArLLQrXEWFsIoRcQDLGVmJhy0Bynl+uNuTwmJRTvMUfXZk0PDu+UdjaK2rDv t38i/K9DkOa5lT39M0yV/RX1W286cjXnKdrHRp4lC9QN9soFuEuCzgjiSKYl+xKa oLGaJwvoxNAmduuLmuVitsriNFf+bi1PSEfDBBHq521Q9D5u3jhGZofGu2HOazCO GhZs041SQ/OP1P8+LjjxwSEpGsQJFdET87oqApCkMy43IEOB0DtOIKSVrdE46QBZ MAGA1KyssNkVozEKH0NU/gGOmjzkt7nS8qWvYIvcKN60Qkhlcm7Dom5pIE1hcnF1 ZXMgKHDiiaFwIHByb2plY3QpIDxoZXJuYW5pLm1hcnF1ZXNAcGVwLXByb2plY3Qu b3JnPokCOQQTAQgAIwUCVyc6hgIbIwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheA AAoJEMtXOGUnaPfprZcQAL4wyuQHrMUb56gfvipTZNAV0YQopEeUtJlNPT3MDYTy D4AiTDmsDZwYaPI7O5m2bNSeLOmhAdqkUXhUOvEIWI0ABqkWVHL93nSEzFiI5HYI bmh0UqpYf0myXQdWE1qjN6n1xnqk1mmZ7RSuIJ/9zwliiX5Qyr/RVfxOVU3iBskn 5iwGNs0N2anU6oA6EoD3VsuV650aIJN1c1e7bOd0QT4Z+FuYHPqsuZ/gnbD7AKJI rpO/DoWMG/Ayzw3M746Ff6GKlQFaCmMja6pkfX8NqylbPY+lDlznu9LYXK3z/7gc NSZL3y53d1G5DvbK33sDXpHEpQOVbl6cAR6cgN0jyjh5Pg4VXKWTntAMlK9E/f+3 HmH7EILxF6x9kl/TJet94igOvAU3v6Ktd3CPhc2XLvp6oik7NbE4hOFmkgJYq1pW 9hffzh9NGzF5l10r9Z4j0bvxbbqXZCsn2/WvK4FhidZhyHgceM/kbH6jZdOEZPw+ Kxxlfsy4CeNDexas2OO1coz68lBiO6uD9+QgoV207hy4D5txTRF3YnR3TDdPbxiX nA8T/xNKOfMvWzfT4pmsuQdK9+DLmDPHDCZli3/5fLh2B2tb/r/SxLRNEaJjLEzb gPxxH53G5FOvjGR4isUbsZz0n2K2KZSxzVAEpkG1qmMhtGM4KZB2l+KTHBpxzElR iQIcBBIBCAAGBQJXe+cvAAoJEH+zxRJjw92vLwsP/RnUNo/RJim4FlBbQ9l5sbcp aCMyEKRMv0YYLT6QpoNziseauPxpQ1ITLeruwuq4C7ZkTNy+sj9NsC4R360YR0Dl 10rLmYEM49gPOO5RQXpJFQsmpwZRFqFN0Ct2lIFYD3XhMyH8/yV+DPJ9EafZQlC9 L6+Q+up9iK1JdnqisdPGHduXK9sApujb6lkS8kF3PV2BitdLTgsVk0tGrs182Fkg Q68rMpubCB/IUkTuuU58VWKGfsXhrndxRb9g7l2/6S+1MWUXochI5Bl3D/XtemP9 aIL21EApXj32/rfczx/y34okbs1ePPGJDTC2Qwprkcna5VPQWOE0Aq+Ic/Dy3GPW T67IfblVV3/iar7z01L8nKkCBWx3VVLOFgVpOeGKEjttHlqK+xaamIgHKRi4blqX GXIT19RQ8o/krDV3U1EOC/vLQn168vGJ3iOI/zISEG6Va0hYAV10ebhGi7S9VIrZ 9qM4gA26RhP0i4JtxPo0gjdbtUMosTxBrDKLZyAqgRn2eNOaRz/aO0xtj/HrUbUV yDZANaVf69rn03yejq1/pNrDHfPwPma3TmEBM1ieZ1ciGT9uwnIQOde5pNsYGk6B 5M85ZgDgj9YaPrKobL1lDcq7KddAks/L+SHWI9o1jj799FJJwukwTUsPe4LRmxny dcdD3O0O7RzdwurQV1jjtC9IZXJuYW5pIE1hcnF1ZXMgKHBFcCkgPGhlcm5hbmlA cGVwLXByb2plY3Qub3JnPohGBBMRAgAGBQJV7/dAAAoJEHuDbkH3q5zl2OgAn12X bKVf0usg/exDv8tOxOzPTr8eAJ9b4QFCS/Bayw5zE3Fy650owknfJIkCHAQQAQIA BgUCVfCW0wAKCRA9g02NGPgJNGo+D/0ew5kut7hDw8dADIPpHaaSHfCu+7TskdQx Usbrg/4wvmiQ5lZvFBDtbqvtBHXVQ1Oj2xtPRRdlL5wuiBqf6hpnR8dQclggnALa kVi8D+c38AKQFFBpAPTraa6bCRawSS74+nOyrSpR/hUsYXmDyOvQCBxKpwS7Qi/O b/JpfVZpLwD+297Z+ILNFixbYlYuA7V8z+ErQdkhSpkgtBoeB20gbw/FmqyQKvtM 0ul43mINJpNzYP4yvU4YsDCNClGOYWLLPFLcnvVowmhRmMO7rM0eF6FfhLOGhbb3 1H8akl2Op2C7EiMv2D8DGiZtV5QtVt9r/PCdl9LLEnw1kjULA50yCD0F4eXFLPLU 1S6APqKFtSv9esSINLjo0q1b4S5ekmUEqhBMRHvREPwGmsWjodp7pe1QPNPqb7pr NAOwBxyKveXWIbL0TaYbPhBQ4az7cUsWmlW9Bgn08zu9Jl9t9SdoEp6BV8qk7y6V mimMLYe2pST5dZjweb7+u4Sfnfttxlt6kwu+hyz/c1RX9VdvgkzaJ+8i+pWvHyij miStQTiHtJEcKbzhgHcEDfOkvFMGmNpHlVuB8skUnb9HeGheb6QZ2mRmCwZlKQQI MDYHE6xOIw8RJBHiIhvXOr73mXcORAsBvEAkGKQRldjtuQpb2dWEaL8oz3p4TA6v I/8y4qj7mYkCHAQQAQgABgUCVe/3TgAKCRBLSiQj0EHGPcmQD/9ngwa9R8nsM0CT CMioJEbWJ4INnaDND8uvnPzRT+vyUkTJzM+RCvVOoGgrmCFeqOeCQhdf20ExsANs qtv9XQEyDDI7PvnAnprJLSYozfpYscPe7N2MSwTBiPz70t03L5j6YfJhooCok921 U0+xCNUl3LXzfIkXTxMC0z77VxSqEiHiPgQH4owqnDuEhRPte/ZtzvMgCRIk8L8+ 9UZazl8hF4r9XPP+h8EFVJW0MB2ANICvmHcspiVd6QJdPTYHZIwZ2LMrb5Dt1Qwy NkTDKvoImgR6qiaR06GDyMhis6l8seu6GuAtOZGh2RGsGGPDPozcTi1kdytFmGC0 W2J+bMoYeEMiAH4Ip4o4KvLwvEIhU1RTMWg3Qo172w1Y2FLQSQLar5kVvjHfAdpg AeZMliPl7+ydziDF+EYP2p4d6kw6aPZNoB7uD1mhdgxts0lBuU3iRQwhOQTcrrJj /2DtUPdoFGoR5OTVDrmb1lodw5WWzI8FtTZ7C6ZyGPjj+V7COTSHGP4R7YLXKrPF K+5AjxzozK+cIgvYSZol8ZfAusxzz5mHXeTZqpHkQNdfCCHWCJ7og2W5baprUgkQ n2O9AqEMSLQW9hpMGbzKIVh6ZFl6n2is/dZubS5aCH9+bNJqEi8Vd/pMsW9MMEet eGKc1WoGtDFFDM0YocgvF1CsSfGfMIkCOQQTAQgAIwUCVajOUQIbIwcLCQgHAwIB BhUIAgkKCwQWAgMBAh4BAheAAAoJEMtXOGUnaPfpw2sP/3YEftsFv83sPLBclsA5 HFNRr4FsXzbRv9F7grDsqnvecgD8ItwUJ0G/Z/0uqXCPKecnq6mNhRZiX+AtNkGi Mle6xcWI2kacAi/L61GPyXWohsy7d42ej+FK2/lyKScTg979XBAXGJCCfyGoaVU0 Rt9zlHyOOB3091YC4gSYkMJ2i7jsdp7lqqvTwM6oPnEQkS75XliTDKesvYdrK87M TcF5tlBNVq0ycGmpGDOY5+d5HvkaJyhfUeJcknvMPIcObsH674vyhTejXabQg2uU hiWyOFEz4T2Xw72XdvtXhB8eIGNJOrGP8HqG0fhejoyXV7m2n0X9taYB+VqFrRnT 9WeoStaMHzLhEAvOgLIXGe5bDPVkE0fV6SASvClAATtgsrunsYIuhQ5qHmcAxofC r0D4CA4YDhnRQbdbRaEKrHPFKkdtw9W8D2HO8X0xq6FmykYNuKI9k7w5oPgzuGnf tBX/8VpKEaSAOaIX4q4MrelsbyaJ8Ujx4fUFaGHQW2s1rmmJf8BnEEntyDSi3Tq7 JABSeA0O5/JUJS9a4rSMvvssdtYSSAtBD0N8yZTtdjdhaFffPbpv0PKmuNbjX1Fs 0NOJDPWKwrSohXDWqr36ott5ap3/3wf/5upgKNR8AKoqjCF0hmPS2L3S+LNnqlZY 8eomhf9YA1gSN49yR+2hAje7iQI8BBMBCAAmAhsjBwsJCAcDAgEGFQgCCQoLBBYC AwECHgECF4AFAlZfiokCGQEACgkQy1c4ZSdo9+lrTg/9FOyKWzceXttk0a3cnUpo p7AQkQC9FfE9QQzFOW4VHk1ZKTlH7V1QrOrzU5fadd8C71oHbf75fVTlmNtcl9OE 0fnx0T6G+FKvTyJV+W9LIRbsNe8+q7eRRtf/HsjQdblEIqkdUlAhVRgCjBI6K/re MYVoz5FxSGoIMjfxds1K3kQICxS+uu+zRm6ff8VuWHMSESC34IxlIvfBf3vbPYnU Phu4Cn0UTxH3pmHmk+teJ1uFWiX98HAxDpv0ZobKNa9imcSCKhYTqdm89XBXND01 bUd44w3RCmSqgzEQoRi0Jj+ieg4XSn98lOItIBPE2pi92NskdSJr7C5++0fO9xrz URZjqGiEPmiegW+OMvnI6X9O2SBzXYU7GBiqpprWsa/y0WKRJ8O+kEVzGUI1Bnge qvZ52QHGN9v5Wnho0gvAWgiAmDVn6n3yfcnI+SBJHmvy+Im6TI8aNSX4G9xQjVuk M/iWyjsNzAyxjtdkbuOBiKAOADDqTC39HwsGoHXuKIzEZMGTFx7vA1yutogtg8Mf UsqX18Ilt8p6v+dtJJY14MzF9fyVIfVr83Fc0IPuv3f59+7VQPY4AO9rUN+bcjgg dKY9peLGizcT1msWew4byIIjU39EfCx1ojfYkDFmV6fQOMOLWT62RgIiyORRKI0M a2LnrHUqPDU6kWM78skVH+eJAhwEEgEIAAYFAld75y8ACgkQf7PFEmPD3a8koxAA joGdnDNipBywNv9l5QW0pdKesUwSKNA4lxfIuSwDLw7ZTabmMHH6WBZjNmcbw7ro kvuSV5+njrkFG1qTumy+JXtniT7dboEr/lXkibu2EEB8z0QNShMxm3Cf68HRsGQR lAwglnqDnZEOkv5AGWYjxqOfRRCKCIGCGHZkKYVK3K8DU+09ifaAxuR2KLJuPMzY wD8moZkBlyEzT5FhOb6hVCG9uHBeCZcayrMsTFhOKU4Y5GKTNgsE4x6FbZoGCFhT wx1MGkoCvzScPhxmes5kpr/AUZgwaseHWfsaC5XgDqji3Hhu21e6Ez4NkH3Z1CUH LEHzGodxpKJ2EkWVi5ofSzD+19MI3A0qwUgDdGVNMDP0k9SvwMPngA5s6hht7sD+ 6mtSnuHwiNLNZk39Qt7sHUYg4AQRCIwzUrQuJ0PUtFIzox+pMQcVIgVM5rwxnNbq U+iWgSBeadc3PfAr6yF3gJy8U7pN7JSjiEuhNWu83cPm3zuIIVhDwjJKQzs+rNun M4PtithYloEgpoG5tMtbK5qIGIQixddlqXcUQtoiA3gFXO6xQjeqKWJMnxp9q+cB +LhKromZENljj8M0UCtzB4UGu4UIeDGKAPsZUCHjwL3LThyK+9EtLH97oz/Q9IgX H9cEW4Ksisct3MAscra29MPACt2xTRKUiXzNVBlhcAa0Pkhlcm5hbmkgTWFycXVl cyAocEVwIENvdW5jaWwpIDxoZXJuYW5pLm1hcnF1ZXNAcGVwLmZvdW5kYXRpb24+ iQI5BBMBCAAjBQJWX4p+AhsjBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQ y1c4ZSdo9+lsdw/9Ea0y2n0Indyhw8RaC7u/Lu+OV5a03ATiWuV16vyYFXiJaVTC ildscXCRpSRHrT84zk4eYf6ysRuzlXZUcg009nF6lajuzDm6E66ZJXkoInGpwEcG Mx5odUeSKxcaZ5IQveEWyJahLbHf4FgQts2r8BsChkoSEvhxojBhHQT5FYxdYNcK nrNj63UZw+xwTbg/79PWOjB141OEwNOT4rggXSZ67w8O1JtMtMGYAgI2KiHIxUPr uEudiJI8DvXUakX9LJRTpJnqSacgkC/ahL8m5//7ePriUO2FR6ZeDkGp5z6g59+l iruJhOcmbjpr7wAo6hVzdkpLT8qu4uuoaWM/kRayEKfhlUj0SCcG751ucTE+yH9H MRBDUV/8fhVuoLsEHnq49/J/cVx7qr1y4EfDDaN8zW8ILe4vcZwGgbD0lI5r6tey 2YyvwVEKDEe1vIiarbRsHa+6haX885SAyooIfdqKDcn6NGM12AVAPOIe2+2Q7GZV 6AACD+j7GWX/jiNaV4HwJ2/SsNBFPw2/lDowsHnhFdvwEROynRlGG3FbHMGJ5HrN hQJWWZDPF40hDpuJpQRUuc5uzOzQUptag9m5gfxCQNQXCtlIpIJ3CdlJJjPzndIH ktV6/eo2xiAn24b2yBeiBnKjET6OE5iswAd4DO3BjAKTBYYmqD2OMC+QCzSJAhwE EgEIAAYFAld75y8ACgkQf7PFEmPD3a9w/hAAnMSIrMoIVgk/o7Xlyh/9TR3WTRsm cxM3Vmz+KI4hzCXde9JK8a+vrZMhSH/ZBBanFPQolu7zRbj7+MeY/g4cJZDsuHBM 1+vhwjxwFPWXRBWdNZFJIzz14PF1TVGbsaQw2r9q6cg6u64pZYA3G/scfcRxPMsb QnVBz0Lg7f2Jrav3TkuwvjnKpnZc0iZ6QuIyAwUdth8TY7y3hXY56VwT1rrtOHXX E0RKaDfCoyep8rRG/+qhiZT1WGzq7LDAIeCR5DdleCaT+bXMsK1N6Xk2il6vXjed vGOtl12I9IgqC30tqqJMpWrRb1KFX60l6oCOYqrAqysajf1BFJeDmiZgpxLcePLD 9XrzNHqKrK7ZRVGmc7aKSvxIyWRrorYDh42MEtw8b/k6ZkXdH2yk+PZUPDMNXGVk 6o4kNhV0g0xL8lIqCk+Oo823F0jTYcasf3vRe1OxsKPJuH+INOJMAkmYUvi/QOKz /pycJLPadN/PVuLD/yTkdfnPP9rcj73uQpjgwTfG8N7XVgmYrbYmT21PWU4cHprU AVexEBMaQtaz7k37rgfqjZyIfGFzrBAVBRmnDm/+KZid4SnHvIMQqC5UaZFImxfY ZcgSY5sqLjNJmiaTKpKBcE/vss7hyZvsmwvlxT652CNvdtYSehDO/F9LZBlIZojv 5RO7TalIRpTCERS5Ag0EVajOUQEQALy+1UBEbXWX5iE1YezJ1qHy2DtT+0JUHiEM bY2iGO/cV4qXOwC5+w6ASp2Udoy52iHznW6AcktoQF/bf8JCxXGGISJMI0tS+1b6 1NuKW+vkXDiSgYn5X5V+mjqS4fFmTMoqo5ig4jqIunmEuwLlJxkP30s8tUeGMRzc WSF5MvSKqQu0yXqg7N4MhEzMt4M4dV+I59HyoORJ805VBOFhr8jCtlg4ug0HrySl LqRp20hhKL8lBUA5opyQkMNSbA+I0S5gFq9sZz31lLVC7sYm6ckap6FBziAwcfnT fnFL4YFfTH4CIdkDFElCZ9318/cSnqbbhilRzvXh8aZfZl5wGntS6cIMJYbbKKGw dsPTkA5IR5yEVH1RbvD/m1d4cu5jqGfTeeRNMIngVirIa7W1Z49x/tTKykUM6/mh eqnzEqbbJsXLrnKN6Y+eu6mJLQgQhj/HNfk09j/wtgo1aRQgL/UVZDVTcuP0MuG9 tTeZ39nt6dFaI3+IsTa4QhnDcO1dJ+eYsuCJmVY3CtuZ5Sh3GcNGk6sX+eeEMkfZ 0jN9uwIWqhva5dqvetoO0VMfQyZiAauNxB0cjo2Cpl+xv+vQHEqPfFcYdY3QCay5 Alsn3ttd6Ht+S2IB/BukcO9N+EmYT1HgJkS1c4UR6x512b0NTGRC6yMFAGSshsx3 z9DInGvRABEBAAGJAh8EGAEIAAkFAlWozlECGwwACgkQy1c4ZSdo9+kphw//Sw7J i9eTyfJHdzRXNa1cA335dY1QYKq9/6eGhSjcyRGz4bHyHUDt5G5dmKwmaYrPGS3H r2H1+Z3w9BD5X/V1ZVgsKYYVM18N0CsnarJdcugdwC1difyMzo2NJGz6btuFey6Z iMZo6EQKgsH/0sLChHSLM5sjBgdmWswkWh7L8oNrFv/p091FVj6rFeda/e7g3xK2 NjPSk3+oX5aLgcCrUSeWJCZflyEL6NEf3EOAahzzoqUfN9D6aTjZWPSmTVTO21t8 s86XeSPuYBVGGODyIkCXWJxkm2WXY5AoPLYJWmmm9TwOJE0FgM/nTj04cBNW91q8 tCCaCx//2dGfW+EdAMew/G8aa2cJgbF7iJs5IWpMRUxujMM7rWJdxXjAh6Y3FiVc 5UtYO87HmthC953QiJntDTa/72Oi7HrGw/wUtSRm2S9G/jdpXZ7WBaPD0R4/QcXS 9590nMfFahWfQs6cdAOtLBJzCL6JMX4sHqaycwxErzd0jvtohCGJW0Ksc8GjTxWt mgBpCVzkTidkWgXICzd7EKE36z5Ir6jvN7NLe4qbPQF+uDWmxQqAK92/Iwt/NBAL Q2oWAiHN5j8v2/ObJDuZH5Q4DGzzVmXYAeKjVMyH9Upsutnu8iYrvghKyC1RKKPP jqzJvcZkDO24NIw8RM1VxPH/3UxXFg+hWD+7KMw=3D =3DNrbg -----END PGP PUBLIC KEY BLOCK----- --------------3C4B95A2605C1E2783AAC03A-- --FDxD1FKgPrZRoNOImPXXM468qv53hOI6p-- --15GsM9x9sqOeANIq7pH6mHs3e60SJeu85 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEMXM+DFmNOhz3CVXWy1c4ZSdo9+kFAlyDtMIACgkQy1c4ZSdo 9+mQWxAAo7ywlxfoAhD1aEQ3Bx5ZPxfmlp/2Mrr8r1f62Lbx/jmt1oCsWi7ET0KO ZMJxVjCEddB/LWeAG7tfWDwZ+13YG+pZV7s02RhqgyDD/4cAetB57Tr0qgVZIm8L H8hiDq/gvYyQodZLtFqZPSfCMjgX+lkIsXU5NKmvUf+UD+LXjt+3Vi8VnQ4rlhdT tZuAu9U6mwDnG/GjyzdelGnGELfRuTF8DcI8Vc+81/fsDCxkeIiV1Q7+V9JD1q1Q K+8KgXJWKcu4MVJiYRgR/89dM8Ki4GL2RPgUR1P1cRYUCLph5RTXyfBnU9LrEaYw S5oyJO0eNanPvoFD5sYU/Hn0LhTOy12GIjiVVJOWNT2dMBMgTm0vPucbA6NRCTNG KKzuovkuvWyXkXyHquW2ZNnnA/biWd9FGI7VK8QMH0bGCcX1dob+GWU9xtMgFQdY fmiHvPtY/pXZ/wh1BsE2yfjByFjiSIGaSvqjX9jUA4vOm/dF0eWOTx6uO8WncYJL BTXoYO7Ywjfkup9tNoGxioUXcDWZ57CQBJtq+W4YjLweo+QUPkX2CfoRMlxlalNq YYiREHAWTv5ME/ii8ZGqgBehhPI65SFOVpTuRomq7EIuzTmRCaQHuQISXMRZ5qnk xVorMO1jjgBQX5kkzZZb2y69D7YTAmXRnxpupgxMHOEflu9xC40= =7Vov -----END PGP SIGNATURE----- --15GsM9x9sqOeANIq7pH6mHs3e60SJeu85-- From nobody Sat Mar 9 04:54:31 2019 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 A5DCF130E83; Sat, 9 Mar 2019 04:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=cs.tcd.ie 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 cXcWDzZ8sBqY; Sat, 9 Mar 2019 04:54:18 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D01C6130DE7; Sat, 9 Mar 2019 04:54:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E39B6BE3E; Sat, 9 Mar 2019 12:54:15 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvYVMvH8El9u; Sat, 9 Mar 2019 12:54:14 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2D222BE38; Sat, 9 Mar 2019 12:54:14 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1552136054; bh=yWI6crjnmjA/p2iUJG81sMPuan2MiaJxI8RIFEYBe9c=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=s7nVowUDZ15SvMPrbUF5+MfdTLyL3Qs5/r+PieCjRTcMtnXlWMqFVuKsQk34BMVS1 iGcHib2dcEGInCD22l0J/IUkECfrihf+Gh5Ma1RuSCgIlj3Esxv9o4ESEmP0LebAX/ x/3cnwEF+TQp2XMGXroIZO7P1O2zzjZHR7JOJVw4= To: rfc-ise@rfc-editor.org, secdispatch@ietf.org, dispatch@ietf.org Cc: sec-ads@ietf.org, art-ads@ietf.org, draft-gwerder-messagevortexmain@ietf.org References: <1d369e948382f1431f6e67abce4ca0c8.squirrel@www.amsl.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <00254c7e-50b5-3a15-16cb-d8747f85a843@cs.tcd.ie> Date: Sat, 9 Mar 2019 12:54:13 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <1d369e948382f1431f6e67abce4ca0c8.squirrel@www.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jCXuSoD378n6OHYJ3P8mnMOr8CupAkccs" Archived-At: Subject: Re: [dispatch] [Secdispatch] A protocol for anonymity 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, 09 Mar 2019 12:54:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jCXuSoD378n6OHYJ3P8mnMOr8CupAkccs Content-Type: multipart/mixed; boundary="BgyVqaU5yxM5JuojLgpIzAfUrCgzpaNhV"; protected-headers="v1" From: Stephen Farrell To: rfc-ise@rfc-editor.org, secdispatch@ietf.org, dispatch@ietf.org Cc: sec-ads@ietf.org, art-ads@ietf.org, draft-gwerder-messagevortexmain@ietf.org Message-ID: <00254c7e-50b5-3a15-16cb-d8747f85a843@cs.tcd.ie> Subject: Re: [Secdispatch] A protocol for anonymity References: <1d369e948382f1431f6e67abce4ca0c8.squirrel@www.amsl.com> In-Reply-To: <1d369e948382f1431f6e67abce4ca0c8.squirrel@www.amsl.com> --BgyVqaU5yxM5JuojLgpIzAfUrCgzpaNhV Content-Type: multipart/mixed; boundary="------------097E96B077561FBCC54895E5" Content-Language: en-GB This is a multi-part message in MIME format. --------------097E96B077561FBCC54895E5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 09/03/2019 10:42, RFC ISE (Adrian Farrel) wrote: > Hi, >=20 > Martin Gwerder has presented his draft to me for publication on the > Independent Stream. Seems like something that ought be relevant for the pearg. [1] S. [1] https://irtf.org/pearg >=20 > https://datatracker.ietf.org/doc/draft-gwerder-messagevortexmain/ >=20 > The document describes and specifies a protocol designed to achieve > anonymity by embedding messages within existing transfer protocols such= as > SMTP or XMPP. >=20 > Martin tells me that he has made some overtures to the IETF, but has be= en > unable to find an opening to discuss his work. I think that may be beca= use > it can sometimes be quite hard for a newcomer to work out how to find a= > way in, especially for a topic that is not easily aligned with what we'= re > currently working on. >=20 > So, before I take this under my wing, I wondered whether you see a plac= e > where you think this should be discussed within the IETF. >=20 > Thanks for any clues, > Adrian >=20 --------------097E96B077561FBCC54895E5 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------097E96B077561FBCC54895E5-- --BgyVqaU5yxM5JuojLgpIzAfUrCgzpaNhV-- --jCXuSoD378n6OHYJ3P8mnMOr8CupAkccs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlyDt3UACgkQWrL68XsX K+oInhAApeQXdZrSh0x3fYT24lXjumdiuNMj8zmexI0oyOipL5CTxh8lCJ2++1Jb GfK9Xxn/VNp0YuAKaD592nEAquFGpxPhmkiXOf3tbfe/xCiXxKGhb8Dvokk0dkQc wPN96ur97Ki2N39RUbU2Pg2Fkk663aQx1CWluMGZdvk+LcezrNX69u+U0EXi4ply ZfRKuQfj+a1qyaDjjZLTV3qo+z4pZsbAvcfI8lnf98TbVqrkuKuSYQUfNvIRCWrv Nh6pfGYgpgIQF7rXpxCVmIofuQXd37J4PYdD9VcWPg2DSVFgAz18wMCcEeY7sL1S Nys1nV47+SZP0DbD+9Km1RlfN93dOwevIvJIyFiWk6KvPDjFJjegKJUg0jysNsej XAJNCi3QVLPwM7z8WwGxYXWd9HsoBO3HTO7YUcR/+FEH3G3mYHvPysq07mClfJVs zRoff18zLVT/e/GTI8pZk7oGNVIxyF2j/CCHv6/K8BqNPVWRsH/EWKOsuPFh7Gi+ E5PQ35FOf9FHO+b78fYLEAtxWYjDMtpdCFHIDbmyHuFpcNxA/g8/7Gtgww2pJyl9 HCQI+R3thZJyqqQ4eZchY8zeoMRQdl2oRqbhgkdgDXd5+52veaqEdHeXYY4EVkw/ Euv4o5ftWX8+119uvg7EIvaxzP0PfbgwbLfOozVvUq9gJf2RMtk= =qpGT -----END PGP SIGNATURE----- --jCXuSoD378n6OHYJ3P8mnMOr8CupAkccs-- From nobody Sun Mar 10 19:20:35 2019 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 0AAED130E66; Sun, 10 Mar 2019 19:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 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, KHOP_DYNAMIC=1.468, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 3z7aoy_khJVF; Sun, 10 Mar 2019 19:20:27 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 F1D01127918; Sun, 10 Mar 2019 19:20:26 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x2B2Bg3L010706; Mon, 11 Mar 2019 02:20:25 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=xt8jTvZA5cwzKfaDZMTcUSE/THGmKssAv0TzIcG/AT8=; b=Wx1WLChybYh1RM222sOr3j33mopGk8QHG3o5Inf8jSwhnBt3PzBf+SKuxvBcvtEqak0+ fcpXBW9UWcWjt8tgsnskn9VcRL03P/F8vsTIQfU57Abeuqi4c0+ZIeeaBv9q4YNsD8eN 3HdX6HNzhdNL48e+buG2tw5zzknLVvbvwKb+/WETLBvPW6dYOjeH6KQ0XjTAj8edmGUZ k8kN14lvDIgWQS8o0N1Ekj3JJmxKPAkVops70fzReSSI1eRkAVfCngdjfOk21YDH6XIj SwHxzpXSf741GYHAzkFIqFIZI9ZQyj9Zp9wmy7I/CkhbKJg9RClMEFW0FffhYrI7OQg+ Hw== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2r46dme2ha-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Mar 2019 02:20:25 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x2B2GrIm002168; Sun, 10 Mar 2019 22:20:24 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint3.akamai.com with ESMTP id 2r49q0pmff-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 10 Mar 2019 22:20:24 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 10 Mar 2019 21:20:23 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1473.003; Sun, 10 Mar 2019 21:20:23 -0500 From: "Salz, Rich" To: "rfc-ise@rfc-editor.org" , "secdispatch@ietf.org" , "dispatch@ietf.org" CC: "sec-ads@ietf.org" , "art-ads@ietf.org" , "draft-gwerder-messagevortexmain@ietf.org" Thread-Topic: [Secdispatch] A protocol for anonymity Thread-Index: AQHU1mTElzSXRlTSiEG3u7jzdKIFFaYFxe8A Date: Mon, 11 Mar 2019 02:20:23 +0000 Message-ID: References: <1d369e948382f1431f6e67abce4ca0c8.squirrel@www.amsl.com> In-Reply-To: <1d369e948382f1431f6e67abce4ca0c8.squirrel@www.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.0.190303 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.41.106] Content-Type: text/plain; charset="utf-8" Content-ID: <3F36473A1124744BA09B267244F994B4@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-11_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=582 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903110015 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-11_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=595 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903110015 Archived-At: Subject: Re: [dispatch] [Secdispatch] A protocol for anonymity 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, 11 Mar 2019 02:20:28 -0000 PiAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1nd2VyZGVyLW1lc3Nh Z2V2b3J0ZXhtYWluLw0KICANCkkgYW0gVkVSWSBjb25jZXJuZWQgYWJvdXQgcHVibGlzaGluZyBz b21ldGhpbmcgdGhhdCBjbGFpbXMgdG8gYmUgYSBwcm90b2NvbCBmb3IgYW5vbnltaXR5IHRoYXQg aGFzIG5vIHNlY3VyaXR5IGFuYWx5c2lzIGFuZCBzZWVtcyB0byBiZSB0aGUgd29yayBvZiBvbmUg cGVyc29uLg0KDQo= From nobody Sun Mar 10 22:31:15 2019 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 98F6E130F32; Sun, 10 Mar 2019 22:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtVxWp3sNt2e; Sun, 10 Mar 2019 22:31:11 -0700 (PDT) Received: from horus.gwerder.net (horus.gwerder.net [IPv6:2a01:4f8:161:5211::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C221130F0B; Sun, 10 Mar 2019 22:31:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by horus.gwerder.net (Postfix) with ESMTP id 51CE8E29E58; Mon, 11 Mar 2019 06:31:09 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at horus.gwerder.net Received: from horus.gwerder.net ([127.0.0.1]) by localhost (horus.gwerder.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyJq1vtdl0EA; Mon, 11 Mar 2019 06:31:03 +0100 (CET) Received: from [192.168.244.105] (145.180.195.178.dynamic.wline.res.cust.swisscom.ch [178.195.180.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: mgwerder) by horus.gwerder.net (Postfix) with ESMTPSA id C7C7DE2A48A; Mon, 11 Mar 2019 06:31:02 +0100 (CET) To: "Salz, Rich" , "rfc-ise@rfc-editor.org" , "secdispatch@ietf.org" , "dispatch@ietf.org" Cc: "sec-ads@ietf.org" , "art-ads@ietf.org" , "draft-gwerder-messagevortexmain@ietf.org" References: <1d369e948382f1431f6e67abce4ca0c8.squirrel@www.amsl.com> From: Martin Message-ID: <336679b2-abd1-6372-050e-974530088821@gwerder.net> Date: Mon, 11 Mar 2019 06:31:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: de-CH Archived-At: Subject: Re: [dispatch] [Secdispatch] A protocol for anonymity 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, 11 Mar 2019 05:31:14 -0000 Hi Rich Thanks for your concern. I understand where it is coming from. The reason why Security Considerations are so small is that there is another (academia) document dealing mainly with the security of the protocol. Although the thesis has not been published (still needs lecturing, a couple of attentive eyes questioning everything, and extension of some sections), it is linked in the document, and you may read it. I felt that including this into the RFC is too much by far. I, therefore, referenced it in the first paragraph. Do you think that this was the wrong decision? You made definitely a valid point: Why believe a single person (in terms of an administrator of a system or writer of a paper)? My reply is: You should not. Read it and build your own opinion. There are a lot of minor flaws in the protocol depending on how your adversary looks like. A lot of "do's" and "donts's." If you are looking for the "why's" then reading [MVAnalysis] is mandatory. Another main problem is censorship resistance. The more you regulate the behavior of the node, the easier it is to identify nodes (at least in some points). I, therefore, tried to integrate all absolute mandatory rules and to leave freedom to all other rules. I am sure willing to change that decision if you think it should be entirely included in the document instead of linking, but the document is already far from being lightweight. Regards Martin Am 11.03.2019 um 03:20 schrieb Salz, Rich: >> https://datatracker.ietf.org/doc/draft-gwerder-messagevortexmain/ > > I am VERY concerned about publishing something that claims to be a protocol for anonymity that has no security analysis and seems to be the work of one person. > From nobody Mon Mar 11 07:31:59 2019 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 503A9131055; Mon, 11 Mar 2019 07:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 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, KHOP_DYNAMIC=1.468, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 hSvDuHBQBzL8; Mon, 11 Mar 2019 07:31:51 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 7CD1F1310C4; Mon, 11 Mar 2019 07:31:47 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x2BEROkV003283; Mon, 11 Mar 2019 14:31:42 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=ug8YOoS7UMyFI6wl51vxJHEqK7Wt3krVs1xph2R/WD4=; b=SRhVGIgjg9z8ltnD+s+KrEPmlAoGi5AmhZflrwVjZ6ASV6uikjGy8a0JJDjnUcIiKxK/ CFmr6/3uBXKzS5+mul3pCuzG5gIrI7QCb2MYR4On9yIBclr6oNinRg8amb6Ah/+rBKCP wOOn4QHJEgdXE5h6cVQU9DmSr93aIiEeTLUOntDqvfj6ohtTzrdXSAqfR46YDyEiTR7g HAINqjcFrGPr4Xrf37CgdNdTkja4XAjtpkid+fWzbLdnuQHIPcENI8skSC0tkPpmnCff jEopeN8pnQDVyjuZNfo5VqlPQpAiUx/rGM2uK7bGpPufVc0uuyRtItjPsJGjpeemZvC1 bg== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2r45mb0dnu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Mar 2019 14:31:41 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x2BEHJK6025693; Mon, 11 Mar 2019 10:31:40 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2r49pygpc9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 11 Mar 2019 10:31:40 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 11 Mar 2019 09:31:38 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1473.003; Mon, 11 Mar 2019 09:31:38 -0500 From: "Salz, Rich" To: Martin , "rfc-ise@rfc-editor.org" , "secdispatch@ietf.org" , "dispatch@ietf.org" CC: "sec-ads@ietf.org" , "art-ads@ietf.org" , "draft-gwerder-messagevortexmain@ietf.org" Thread-Topic: [Secdispatch] A protocol for anonymity Thread-Index: AQHU1mTElzSXRlTSiEG3u7jzdKIFFaYFxe8AgAB4UoCAAFOjAA== Date: Mon, 11 Mar 2019 14:31:37 +0000 Message-ID: <26313F4A-06FF-4155-B646-09C96F370894@akamai.com> References: <1d369e948382f1431f6e67abce4ca0c8.squirrel@www.amsl.com> <336679b2-abd1-6372-050e-974530088821@gwerder.net> In-Reply-To: <336679b2-abd1-6372-050e-974530088821@gwerder.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.0.190303 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.39.18] Content-Type: text/plain; charset="utf-8" Content-ID: <0F9033F6212DAD43B4210F6EA3DFC176@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-11_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=608 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903110104 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-11_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=634 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903110105 Archived-At: Subject: Re: [dispatch] [Secdispatch] A protocol for anonymity 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, 11 Mar 2019 14:31:53 -0000 SSB3b3VsZCB0dXJuIHRoaXMgYXJvdW5kOiB3aHkgZG9lcyB0aGlzIGhhdmUgdG8gYmUgYW4gUkZD Pw0KDQo= From nobody Mon Mar 11 23:19:00 2019 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 02DE2130EF9; Mon, 11 Mar 2019 23:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiqlLinFam2V; Mon, 11 Mar 2019 23:18:56 -0700 (PDT) Received: from horus.gwerder.net (horus.gwerder.net [5.9.56.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B961130E64; Mon, 11 Mar 2019 23:18:55 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by horus.gwerder.net (Postfix) with ESMTP id ECD0AE2AC93; Tue, 12 Mar 2019 07:18:52 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at horus.gwerder.net Received: from horus.gwerder.net ([127.0.0.1]) by localhost (horus.gwerder.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmLtote-Bb0h; Tue, 12 Mar 2019 07:18:52 +0100 (CET) Received: from [192.168.244.105] (145.180.195.178.dynamic.wline.res.cust.swisscom.ch [178.195.180.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: mgwerder) by horus.gwerder.net (Postfix) with ESMTPSA id 309D5E2AC96; Tue, 12 Mar 2019 07:18:52 +0100 (CET) To: "Salz, Rich" , "rfc-ise@rfc-editor.org" , "secdispatch@ietf.org" , "dispatch@ietf.org" Cc: "sec-ads@ietf.org" , "art-ads@ietf.org" , "draft-gwerder-messagevortexmain@ietf.org" References: <1d369e948382f1431f6e67abce4ca0c8.squirrel@www.amsl.com> <336679b2-abd1-6372-050e-974530088821@gwerder.net> <26313F4A-06FF-4155-B646-09C96F370894@akamai.com> From: Martin Message-ID: <6dd6ed2c-b2a6-f42f-9edc-25c9607bf173@gwerder.net> Date: Tue, 12 Mar 2019 07:18:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <26313F4A-06FF-4155-B646-09C96F370894@akamai.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dispatch] [Secdispatch] A protocol for anonymity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 06:18:58 -0000 Hi Rich This is a valid point. Requested status is experimental. This allows going for a standard later. So the primary goal is to become a standard on the long term and to expose the protocol to a broader public. In my eyes, for the standard, it would require that we have two seconding documents — one dealing with best current practices and one focusing security considerations (maybe both in one document). The main problem with those two documents is not the protocol itself. As SMTP or HTTP in its pure form, this is a transport protocol only. It does not deal with the client side or the content itself. Anonymity is broken easily by the users themselves. As an example, you may take the fact that almost no user is ready to write emails in plain text. They want to embed graphics and emoticons. Allowing HTML encoding on the other side makes the protocol vulnerable to bugging attacks. At the moment I am using Thunderbird as the client and the MessageVortex node as "local mail server." While this makes sense from the user perspective (no new client), it is maybe not the wisest decision from an anonymity perspective. This, however, is not a problem of the protocol. MessageVortex allows transferring any message and is not limited to emails. These possibilities should be further explored. At least for my person, this protocol opens a whole new world full of possibilities. So I am very keen to see what it can do. Regards Martin Am 11.03.2019 um 15:31 schrieb Salz, Rich: > I would turn this around: why does this have to be an RFC? > From nobody Mon Mar 11 23:41:34 2019 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 46739130EFB; Mon, 11 Mar 2019 23:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfCiD0pIFXA3; Mon, 11 Mar 2019 23:41:25 -0700 (PDT) Received: from mail-it1-f174.google.com (mail-it1-f174.google.com [209.85.166.174]) (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 B374F130EE7; Mon, 11 Mar 2019 23:41:25 -0700 (PDT) Received: by mail-it1-f174.google.com with SMTP id f186so1652979ita.0; Mon, 11 Mar 2019 23:41:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=lvL7Zr8CD6DG7tH2Qoqa0p+CbWWKZRPY7xCdNas71OY=; b=iPP93guhdbm+JsQ2suyMjkvJGDomcItXAmjYfd+sics9x24uPFaZhEcyVfD79zeLsu UsSR5jNQN+VfrhxbrdsVZn+2+18Tk3WtfjaqBPSSkk6LmIpQSNW3XsqjvCKxLpViyhH+ Twai6kfQH+nV6un48GrWgT2+s0WmXOGIPrMxGrvyySur9Yhr5f2vKF3/XPYPMyt8FYcA M/R0KjNJYeSlWTOEiIG1VsN2PQlKP0Qv0YHotefPhyWQz38tzo8v0W7j+F6Tb4bIhLnI P2nuYkSTeZopa299rEUl+7+Ca1dFUs6+9DWplbx1qhEkL8hVswpN40aVg3YCPEN4CsSZ SafQ== X-Gm-Message-State: APjAAAWbJlbryTDcVerXOi2iQ3vjJDD6m46WD6lLgrNG0o2uJTEtJGcF 3nZdWTZNxitNWa8Q6w/nO5gW4SuUV273efpK1dk= X-Google-Smtp-Source: APXvYqwLUvDItNtfr7+3SML7qiiBXjy3tX7i/PeWvTJf7zNiijumSBt/EO8iQmRSg2rORba7LGzVDQYGUouY/cboD/Q= X-Received: by 2002:a02:984d:: with SMTP id x13mr18575051jaj.140.1552372884460; Mon, 11 Mar 2019 23:41:24 -0700 (PDT) MIME-Version: 1.0 References: <1d369e948382f1431f6e67abce4ca0c8.squirrel@www.amsl.com> <336679b2-abd1-6372-050e-974530088821@gwerder.net> <26313F4A-06FF-4155-B646-09C96F370894@akamai.com> <6dd6ed2c-b2a6-f42f-9edc-25c9607bf173@gwerder.net> In-Reply-To: <6dd6ed2c-b2a6-f42f-9edc-25c9607bf173@gwerder.net> From: Barry Leiba Date: Tue, 12 Mar 2019 15:41:13 +0900 Message-ID: To: Martin Cc: "Salz, Rich" , "rfc-ise@rfc-editor.org" , "secdispatch@ietf.org" , "dispatch@ietf.org" , "sec-ads@ietf.org" , "art-ads@ietf.org" , "draft-gwerder-messagevortexmain@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dispatch] [Secdispatch] A protocol for anonymity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 06:41:28 -0000 I would feel better about this if it were done as an Experimental RFC in the IETF stream, ideally through an ART/SEC working group, as it's too much to be AD-sponsored. As such, it should go through secdispatch or dispatch, and it's a bit late to do that for Prague. I'd be hesitant to actually *block* it from the Independent stream (more specifically, asking the ISE not to publish it because it needs IETF review), but I'd rather see it in the IETF stream. I also don't know the history here, as I'm just stepping in as AD now, so perhaps the issue of doing it in the IETF stream has already been hashed out. If so, please clue me in. Barry On Tue, Mar 12, 2019 at 3:19 PM Martin wrote: > > Hi Rich > > This is a valid point. Requested status is experimental. This allows > going for a standard later. So the primary goal is to become a standard > on the long term and to expose the protocol to a broader public. In my > eyes, for the standard, it would require that we have two seconding > documents =E2=80=94 one dealing with best current practices and one focus= ing > security considerations (maybe both in one document). The main problem > with those two documents is not the protocol itself. As SMTP or HTTP in > its pure form, this is a transport protocol only. It does not deal with > the client side or the content itself. > > Anonymity is broken easily by the users themselves. As an example, you > may take the fact that almost no user is ready to write emails in plain > text. They want to embed graphics and emoticons. Allowing HTML encoding > on the other side makes the protocol vulnerable to bugging attacks. At > the moment I am using Thunderbird as the client and the MessageVortex > node as "local mail server." While this makes sense from the user > perspective (no new client), it is maybe not the wisest decision from an > anonymity perspective. This, however, is not a problem of the protocol. > MessageVortex allows transferring any message and is not limited to > emails. These possibilities should be further explored. > > At least for my person, this protocol opens a whole new world full of > possibilities. So I am very keen to see what it can do. > > Regards > Martin > > > Am 11.03.2019 um 15:31 schrieb Salz, Rich: > > I would turn this around: why does this have to be an RFC? > > From nobody Tue Mar 12 00:22:33 2019 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 57062130EE7 for ; Tue, 12 Mar 2019 00:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=standardstrack.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 a2_TYa-nyewx for ; Tue, 12 Mar 2019 00:22:29 -0700 (PDT) Received: from biz221.inmotionhosting.com (biz221.inmotionhosting.com [198.46.93.79]) (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 A2B84130E64 for ; Tue, 12 Mar 2019 00:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=References:To:Cc:In-Reply-To:Date:Subject: Mime-Version:Content-Type:Message-Id:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=BwDEBbftYs6pQ5rkIZqLuSb7pcH0UHkkE4mZik5h0xA=; b=Ohy5rsgHuew0SyHdnmG0jfemo 2noYwf8bvfBYEubLVLcnVGT4zysl+rAdWUDqH17BfydGGcFUN2DzIcqacge9gBSx2v+q1KiazLSmz b2YAPL5elYVnYDKs7DNBBwp4n0Trtk47XyUKR3hZUrcxfn3Weyqc1D4YpeAtK8GHocmHs=; Received: from [68.100.196.217] (port=63396 helo=[192.168.10.26]) by biz221.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h3bjq-00CEvJ-MK; Tue, 12 Mar 2019 00:22:28 -0700 From: Eric Burger Message-Id: <5DC4D2CC-E344-4640-B797-9B51A21198F3@standardstrack.com> Content-Type: multipart/signed; boundary="Apple-Mail=_01DCB60D-616D-4585-9FCB-94EF42856E68"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 12 Mar 2019 03:22:12 -0400 In-Reply-To: <336679b2-abd1-6372-050e-974530088821@gwerder.net> Cc: "dispatch@ietf.org" To: Martin References: <1d369e948382f1431f6e67abce4ca0c8.squirrel@www.amsl.com> <336679b2-abd1-6372-050e-974530088821@gwerder.net> X-Mailer: Apple Mail (2.3445.102.3) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz221.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz221.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: biz221.inmotionhosting.com: eburger@standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [dispatch] [Secdispatch] A protocol for anonymity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 07:22:31 -0000 --Apple-Mail=_01DCB60D-616D-4585-9FCB-94EF42856E68 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m curious about the =E2=80=98main=E2=80=99 document. Is the = document you mention below supposed to be at https://messagevortex.net/devel/messageVortex.pdf? If so, the document is broken. As in unretrievable, not a value = judgement of the technical content. It may be that, too, but I=E2=80=99ll = reserve judgement. IMHO the world of anonymous communication is full of ToR knockoffs and = protocol steganographies. I would be curious to learn how Message Vortex = is different and advances the state of the art. See, for example: = https://www.darpa.mil/program/resilient-anonymous-communication-for-everyo= ne A *very* quick read of the I-D indicates there is a lot left = unspecified. For example: - key distribution is done by magic - accounting is disturbing: that implies nodes have a *lot* of tracking = capability - I=E2=80=99m not sure blending will work, but that will require a bit = more reading on my part (anyone else want to chime in)? - the hand wave of Dead Parrot is fatal: one can tell these are Message = Vortex messages by simple inspection. That defeats the purpose, no? Finally, ASN.1? Really? I suppose we could use X.500 for message = transport :-) > On Mar 11, 2019, at 1:31 AM, Martin wrote: >=20 > Hi Rich >=20 > Thanks for your concern. I understand where it is coming from. The > reason why Security Considerations are so small is that there is = another > (academia) document dealing mainly with the security of the protocol. > Although the thesis has not been published (still needs lecturing, a > couple of attentive eyes questioning everything, and extension of some > sections), it is linked in the document, and you may read it. I felt > that including this into the RFC is too much by far. I, therefore, > referenced it in the first paragraph. Do you think that this was the > wrong decision? >=20 > You made definitely a valid point: Why believe a single person (in = terms > of an administrator of a system or writer of a paper)? My reply is: = You > should not. Read it and build your own opinion. There are a lot of = minor > flaws in the protocol depending on how your adversary looks like. A = lot > of "do's" and "donts's." If you are looking for the "why's" then = reading > [MVAnalysis] is mandatory. >=20 > Another main problem is censorship resistance. The more you regulate = the > behavior of the node, the easier it is to identify nodes (at least in > some points). I, therefore, tried to integrate all absolute mandatory > rules and to leave freedom to all other rules. I am sure willing to > change that decision if you think it should be entirely included in = the > document instead of linking, but the document is already far from = being > lightweight. >=20 > Regards > Martin >=20 >=20 > Am 11.03.2019 um 03:20 schrieb Salz, Rich: >>> https://datatracker.ietf.org/doc/draft-gwerder-messagevortexmain/ >>=20 >> I am VERY concerned about publishing something that claims to be a = protocol for anonymity that has no security analysis and seems to be the = work of one person. >>=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_01DCB60D-616D-4585-9FCB-94EF42856E68 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEfEc/N7T7IfiAuDEHDDCGh758rskFAlyHXiQACgkQDDCGh758 rsnT9g/8Ca8jZyYxiRsphdlmeI5ESq6Qi8rncqt7ccI3ElRInUXz3hXnSYY44Ap4 jETVkK4SdTAW4gXXbFvxuQk7owTGQ6GrNfiobXRvZWxQz30BCtHjzPJtskGtO1bl S1GHMYnROY9Wq3BRZCGdYtiqfJhwQmx8RhUiyBdwdHH7s2Fddtl5tv4ULQFR94YU L7rYQtycjaXNkTvy+wXhO/XsBxQ1Kax5uMLB6IbPZWGjiBW+wS1rqR0SbPfwu8R7 Et0g7vjZNrlkNtKHOWevpe57sDPPYaeUI/xhZir3UbvftxLza7f3CC3LD1t09jS4 pFaP8yevUVM+dlkVMR02c227gEYLpembH57XFEBGTyp1C79lhaZs/C+f2UEsOxLI jYk0QZlhBAVubDtAhdOCzI+L2mIeJ79GrY3f4KnjdWjkKqkiWOXJ9S5ydPWoLx1T JXaDAqHSZy6whffypkMNzNcA52KB1Owo6uH6ch4FDcuFlfxLdQ58clgAfvT7/tyu AvfJaSEOBuAro+0llMw6hZDXoJrTsLGHxTv7XoiFCpfaD7bmoMVt30CjL/i14FQ2 tSj+T8s4kTGlL1bYaVGEbeZLiHx/ff1PazIulzPFfLMfdWLShZWZrdywhmjsqdzR VZLKgDOESOHc2SRYpIWf1KplQOUQuczbg2V8UFL0DIQQvt82T/k= =pGrM -----END PGP SIGNATURE----- --Apple-Mail=_01DCB60D-616D-4585-9FCB-94EF42856E68-- From nobody Tue Mar 12 03:43:00 2019 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 1CA4812E036; Tue, 12 Mar 2019 03:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUVMMiW6bjjF; Tue, 12 Mar 2019 03:42:56 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72C89129A85; Tue, 12 Mar 2019 03:42:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id AB9931C3F62; Tue, 12 Mar 2019 03:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zwglBV-4VP8; Tue, 12 Mar 2019 03:42:49 -0700 (PDT) Received: from www.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 441AB1C3F4D; Tue, 12 Mar 2019 03:42:49 -0700 (PDT) Received: from 87.112.237.8 (SquirrelMail authenticated user rfcpise) by www.amsl.com with HTTP; Tue, 12 Mar 2019 03:42:49 -0700 Message-ID: <2512b74994985f18b6967c4cef8e41ed.squirrel@www.amsl.com> In-Reply-To: References: <1d369e948382f1431f6e67abce4ca0c8.squirrel@www.amsl.com> <336679b2-abd1-6372-050e-974530088821@gwerder.net> <26313F4A-06FF-4155-B646-09C96F370894@akamai.com> <6dd6ed2c-b2a6-f42f-9edc-25c9607bf173@gwerder.net> Date: Tue, 12 Mar 2019 03:42:49 -0700 From: "RFC ISE (Adrian Farrel)" To: "Barry Leiba" Cc: "Martin" , "Salz, Rich" , "rfc-ise@rfc-editor.org" , "secdispatch@ietf.org" , "dispatch@ietf.org" , "sec-ads@ietf.org" , "art-ads@ietf.org" , "draft-gwerder-messagevortexmain@ietf.org" Reply-To: rfc-ise@rfc-editor.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Subject: Re: [dispatch] [Secdispatch] A protocol for anonymity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 10:42:58 -0000 Thanks Barry, Useful comments. To be clear on the ISE position, here... If there is a home for this work in the IETF (or possibly the IRTF), I would be delighted to see the work moved there, discussed, updated, and published with IETF consensus. That is, in fact, the purpose of this thread. Although it may be late for a presentation in Prague, I believe that the corridors in the Hilton will be fully functional, and that the mailing lists run 24x7 so we should at least be able to get an idea of whether there is support to look at this in the IETF. (I am getting a strong hint that that is the case, but as yet no firm commitment from a WG chair that their mailing list is the place to focus the conversation.) Thanks, Adrian Barry Leiba wrote: > I would feel better about this if it were done as an Experimental RFC > in the IETF stream, ideally through an ART/SEC working group, as it's > too much to be AD-sponsored. As such, it should go through > secdispatch or dispatch, and it's a bit late to do that for Prague. > > I'd be hesitant to actually *block* it from the Independent stream > (more specifically, asking the ISE not to publish it because it needs > IETF review), but I'd rather see it in the IETF stream. I also don't > know the history here, as I'm just stepping in as AD now, so perhaps > the issue of doing it in the IETF stream has already been hashed out. > If so, please clue me in. > > Barry > > On Tue, Mar 12, 2019 at 3:19 PM Martin wrote: >> >> Hi Rich >> >> This is a valid point. Requested status is experimental. This allows >> going for a standard later. So the primary goal is to become a standard >> on the long term and to expose the protocol to a broader public. In my >> eyes, for the standard, it would require that we have two seconding >> documents — one dealing with best current practices and one focusing >> security considerations (maybe both in one document). The main problem >> with those two documents is not the protocol itself. As SMTP or HTTP in >> its pure form, this is a transport protocol only. It does not deal with >> the client side or the content itself. >> >> Anonymity is broken easily by the users themselves. As an example, you >> may take the fact that almost no user is ready to write emails in plain >> text. They want to embed graphics and emoticons. Allowing HTML encoding >> on the other side makes the protocol vulnerable to bugging attacks. At >> the moment I am using Thunderbird as the client and the MessageVortex >> node as "local mail server." While this makes sense from the user >> perspective (no new client), it is maybe not the wisest decision from an >> anonymity perspective. This, however, is not a problem of the protocol. >> MessageVortex allows transferring any message and is not limited to >> emails. These possibilities should be further explored. >> >> At least for my person, this protocol opens a whole new world full of >> possibilities. So I am very keen to see what it can do. >> >> Regards >> Martin >> >> >> Am 11.03.2019 um 15:31 schrieb Salz, Rich: >> > I would turn this around: why does this have to be an RFC? >> > > > -- Adrian Farrel (ISE), rfc-ise@rfc-editor.org From nobody Wed Mar 13 10:13:37 2019 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 1D34C131193 for ; Wed, 13 Mar 2019 10:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otKb0c5S77ZE for ; Wed, 13 Mar 2019 10:13:31 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFFFA1310E7 for ; Wed, 13 Mar 2019 10:13:30 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id z20so2281277ljj.10 for ; Wed, 13 Mar 2019 10:13:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=rkfgyykEnW8fZw5CgZJBp9A8F0/mhLdLHBaB5/J0k4I=; b=TjtphhCyDYgHQLFUb3nQLglOlzPyp20fAjtSSmHU/+Tqx0zyRMFeUf5s6ovrTdO+dH +1Henp8UlKpxUfIhoFOnRtYq1/zM5Wz6fCR+8vLXqfUFh3YlLuF1F2ROkg+ew28+dKne C4XplNHOz50h0vRmX7hSaPFyb4MHC/KkK2uvdINpxex9pr+cpp8q9LZuXNQC+sy+wXNI PquGgAKmPV8sDQLjdKAzgWZx73lNBDvPLWjQuit1GjBC9wB4oXVv99OxaMOXaPTgw7Sq LuLD4Gpv7FTmgi/wHogCVOs3aisT5qjHFijJ8P7AHPnJFhB5nHGftpUqd2JfRkVW+Se/ HMKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=rkfgyykEnW8fZw5CgZJBp9A8F0/mhLdLHBaB5/J0k4I=; b=O8CNEZGfEl/A25xVFyKNY4wDEy7exK4LqXTQ80e5Q9tJGNVHEuM8ENA4IpIlMK/qG+ 3onPmQVbQfqY5MafTnAxwKLSU7ZEtExy8wA/2JQQQQTqnKJLMhbTRp0BfMvuFpupv8Mn +brfrMV95uRGPMJXgPVS93DO+qPymIMFYj016zajxd7wqMMqiJqUthYL9hS7DO94kiKk CFrcDkV3LSEOPaf2A6f3t0Lz169YaNx+YF85jaDYxiem08fSLetYaBXDTbrUCvUh3UzO oWZmgWzlQXmqvnY2x0Uw79YhIpFungZNC0mbTQOKHIxpM35aCRYh56QFddmoX0l9vQt0 YSfg== X-Gm-Message-State: APjAAAVNVb7zPVIwo2xqlf898/Y3aDh81TMTeZsMnSgyrCaGAKmzOLyk oit4dM0LDino1rr/nDkHhJQU4fqsQNTqj/x6ObZLiy7n X-Google-Smtp-Source: APXvYqzUXDdMFUHjcI4FGamyIaxEV/thVzwdawyil3SQ4uGLuAqKzv3AYBUwzVhsTegiLgp3exYX7IeVFnf5hfAA/TI= X-Received: by 2002:a2e:4:: with SMTP id 4mr23621373lja.165.1552497208448; Wed, 13 Mar 2019 10:13:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mary Barnes Date: Wed, 13 Mar 2019 12:13:17 -0500 Message-ID: To: DISPATCH Content-Type: multipart/alternative; boundary="0000000000009fda160583fcec38" Archived-At: Subject: [dispatch] DISPATCH agenda @ IETF-104 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, 13 Mar 2019 17:13:35 -0000 --0000000000009fda160583fcec38 Content-Type: text/plain; charset="UTF-8" Hi all, We have uploaded a preliminary agenda for DISPATCH: https://datatracker.ietf.org/meeting/materials/ Regards, Mary. DISPATCH WG co-chair ---------- Forwarded message --------- From: Mary Barnes Date: Thu, Mar 7, 2019 at 9:59 AM Subject: Topics for DISPATCH @ IETF-104 To: DISPATCH Cc: ART ADs , dispatch chairs Hi all, The wiki has been updated with the topics that have been agreed to be discussed at IETF-104: https://trac.ietf.org/trac/dispatch/wiki/WikiStart The proposal for moving forward draft-dold-payto is still being discussed amongst ADS/chairs as is the JSON Canonicalization that had been proposed as a BoF in the SEC Area, but was not approved. We will post any updates to the wiki and will post an agenda shortly. As a reminder, if you are submitting drafts for discussion in the dispatch working group following the standard convention of including the WG name in the draft name (i.e., draft--dispatch-blah-blah) makes it *much* easier for me as chair to make sure I have the right documents identified on the wiki and on the agenda. The tool will allow you to indicate that the document with the new name replaces the document with the old name if that's a concern. Regards, Mary DISPATCH WG co-chair --0000000000009fda160583fcec38 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

We have upload= ed a preliminary agenda for DISPATCH:

Regards,
Mary.
DISPA= TCH WG co-chair

---------- Forwarded message ---------
From: Mary Barnes <mary.ietf.barnes@gma= il.com>
Date: Thu, Mar 7, 2019 at 9:59 AM
Subject: Topi= cs for DISPATCH @ IETF-104
To: DISPATCH <dispatch@ietf.org>
Cc: ART ADs <art-ads@ietf.org>, dispatch chairs <dispatch-chairs@ietf.org>

Hi all,

The wiki = has been updated with the topics that have been agreed to be discussed at I= ETF-104:=C2=A0=C2=A0https://trac.ietf.org/trac/dispatch/wiki/WikiStar= t

The proposal for moving forward draft-dold-p= ayto is still being discussed amongst ADS/chairs as is the JSON Canonicaliz= ation that had been proposed as a BoF in the SEC Area, but was not approved= .=C2=A0

We will post any updates to the wiki and w= ill post an agenda shortly.=C2=A0 =C2=A0

As a remi= nder, if you are submitting drafts for discussion in the dispatch working g= roup following the standard convention of including the WG name in the draf= t name (i.e., draft-<name>-dispatch-blah-blah)=C2=A0 makes it *much* = easier for me as chair to make sure I have the right documents identified o= n the wiki and on the agenda.=C2=A0 =C2=A0The tool will allow you to indica= te that the document with the new name replaces the document with the old n= ame if that's a concern.=C2=A0=C2=A0

Regards,<= /div>
Mary
DISPATCH WG co-chair
--0000000000009fda160583fcec38-- From nobody Wed Mar 13 20:07:05 2019 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 DC029131264 for ; Wed, 13 Mar 2019 20:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=dPSdl+zt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RM/frydD 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 Hd2q1fkBk2rR for ; Wed, 13 Mar 2019 20:07:01 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7D6013125A for ; Wed, 13 Mar 2019 20:07:00 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 245FB235F8 for ; Wed, 13 Mar 2019 23:07:00 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 13 Mar 2019 23:07:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:in-reply-to:references:date:from:to:subject :content-type:content-transfer-encoding; s=fm1; bh=EYN7NjJoQ/zLt CIIy2eQz397tG8gWfLmkXQd3PxEfd4=; b=dPSdl+ztd8IeE2MBeMWIuN8LOyRsN qbggm9mz4gq1OboUM29FjAEBHP4ptyWdUiAdKY16LcY4ccX7ZSRieDuIB6g2ZELm c+ayfXtdcPp+5XyI2vNC1dLs4uPdWYiu/pSBjweq9Iwy6Fngo08qSutC76mW6tzV 1TE7yjHUqVph3Un/6doZGgo5+wZfCw7Glu6Wl25HWvIhop9EkIGCMJILnj2hwKGP ffdN9/c3YfelRGwooL3MF8njzZkxO2ilA/LxZJv4sh9oIiY9gFIvl1hQylhYQxAq Zix24aoGrpO2ONHHeaef2fYVG6N0ZvbmbCFPpO/VBOIdMhlVDByB/p25w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:references:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=EYN7NjJoQ/zLtCIIy2eQz397tG8gWfLmkXQd3PxEfd4=; b=RM/frydD ouaWEWctYDgkwqouIGH9wJ83xkct2k+VKf0CguvOuqxz/TF7BB2fyijRpKcIIULC 11XhLUjAGNjmM4xfoceo8R8GnQJm5U9ME60vVl0PyEIMPhGsNU1csE3r6hcfFckA 8A9SpFpnI+z7iZAupfg7Q7qau3ZMaiUfdwMPtmMGaflrANKuJo8G6uNHhMt+LmGc bbdCVXAr5DY4JpoXgBYIwqv2Cm+EW+G7jfKD8CBJvFSoJCLG2dR+nRKFabj8i17s zGVb+SzlHfw5lrEkdG1HjoJj+X+uAjJOBOGLOXfMemeEMey7Q9QxD0KHWPhNX6Ou DXR1XFwImOCEYg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrhedugdehhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfkfgjfhffhffvufgtgfesthhqre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehhthhtphhinhhithhsphhurhgvfh horhhmthhhihhsihhsrghtrhgrnhhsphhorhhtphhrohhtohgtohhlohhnlhihrdhithdp ihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrh hophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6A33E7C32E; Wed, 13 Mar 2019 23:06:59 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-925-g644bf8c-fmstable-20190228v5 X-Me-Personality: 92534000 Message-Id: In-Reply-To: <2512b74994985f18b6967c4cef8e41ed.squirrel@www.amsl.com> References: <1d369e948382f1431f6e67abce4ca0c8.squirrel@www.amsl.com> <336679b2-abd1-6372-050e-974530088821@gwerder.net> <26313F4A-06FF-4155-B646-09C96F370894@akamai.com> <6dd6ed2c-b2a6-f42f-9edc-25c9607bf173@gwerder.net> <2512b74994985f18b6967c4cef8e41ed.squirrel@www.amsl.com> Date: Wed, 13 Mar 2019 23:06:59 -0400 From: "Martin Thomson" To: dispatch@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dispatch] [Secdispatch] A protocol for anonymity 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, 14 Mar 2019 03:07:04 -0000 The challenging thing with a proposal that is as broad as this is findin= g a home. There are, to varying degrees, lots of different pieces to th= is design. Without going into the design in more detail, I see both cry= ptographic and transport elements. Both of which are similar in the abs= tract to existing work in the IETF, but entirely dissimilar in form. A = dispatch group is likely the best target for this, but even then it is l= ikely to contain elements for multiple areas (there's a whole section on= routing that I think is probably not routing in the sense that it would= fit in RTG, but it's still an entirely separate part of the design; the= re is also a section on accounting that might or might not be suitable f= or OPS). That alone isn't information you could use to decide anything here (othe= r than perhaps the shortcomings of the IETF when it comes to dealing wit= h cross-area stuff). I have some reservations about the lack of context in the proposal. For= instance, the section on accounting launches into mechanisms without es= tablishing what is being accounted for and to whom. A protocol like thi= s would also typically require considerable security analysis. This looks like a specification at the sort of level that would be appro= priate for a BoF or dispatch session. If there was significant interest= in this, then I would expect to see - over time - those details filled = in. Using the dispatch process is probably right, and either would be f= ine. On Tue, Mar 12, 2019, at 21:43, RFC ISE (Adrian Farrel) wrote: > Thanks Barry, >=20 > Useful comments. >=20 > To be clear on the ISE position, here... >=20 > If there is a home for this work in the IETF (or possibly the IRTF), I= > would be delighted to see the work moved there, discussed, updated, an= d > published with IETF consensus. That is, in fact, the purpose of this > thread. >=20 > Although it may be late for a presentation in Prague, I believe that t= he > corridors in the Hilton will be fully functional, and that the mailing= > lists run 24x7 so we should at least be able to get an idea of whether= > there is support to look at this in the IETF. (I am getting a strong h= int > that that is the case, but as yet no firm commitment from a WG chair t= hat > their mailing list is the place to focus the conversation.) >=20 > Thanks, > Adrian >=20 > Barry Leiba wrote: > > I would feel better about this if it were done as an Experimental RF= C > > in the IETF stream, ideally through an ART/SEC working group, as it'= s > > too much to be AD-sponsored. As such, it should go through > > secdispatch or dispatch, and it's a bit late to do that for Prague. > > > > I'd be hesitant to actually *block* it from the Independent stream > > (more specifically, asking the ISE not to publish it because it need= s > > IETF review), but I'd rather see it in the IETF stream. I also don'= t > > know the history here, as I'm just stepping in as AD now, so perhaps= > > the issue of doing it in the IETF stream has already been hashed out= . > > If so, please clue me in. > > > > Barry > > > > On Tue, Mar 12, 2019 at 3:19 PM Martin wrote: > >> > >> Hi Rich > >> > >> This is a valid point. Requested status is experimental. This allow= s > >> going for a standard later. So the primary goal is to become a stan= dard > >> on the long term and to expose the protocol to a broader public. In= my > >> eyes, for the standard, it would require that we have two seconding= > >> documents =C3=A2=C2=80=C2=94 one dealing with best current practice= s and one focusing > >> security considerations (maybe both in one document). The main prob= lem > >> with those two documents is not the protocol itself. As SMTP or HTT= P in > >> its pure form, this is a transport protocol only. It does not deal = with > >> the client side or the content itself. > >> > >> Anonymity is broken easily by the users themselves. As an example, = you > >> may take the fact that almost no user is ready to write emails in p= lain > >> text. They want to embed graphics and emoticons. Allowing HTML enco= ding > >> on the other side makes the protocol vulnerable to bugging attacks.= At > >> the moment I am using Thunderbird as the client and the MessageVort= ex > >> node as "local mail server." While this makes sense from the user > >> perspective (no new client), it is maybe not the wisest decision fr= om an > >> anonymity perspective. This, however, is not a problem of the proto= col. > >> MessageVortex allows transferring any message and is not limited to= > >> emails. These possibilities should be further explored. > >> > >> At least for my person, this protocol opens a whole new world full = of > >> possibilities. So I am very keen to see what it can do. > >> > >> Regards > >> Martin > >> > >> > >> Am 11.03.2019 um 15:31 schrieb Salz, Rich: > >> > I would turn this around: why does this have to be an RFC? > >> > > > > > >=20 >=20 > --=20 > Adrian Farrel (ISE), > rfc-ise@rfc-editor.org >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Wed Mar 13 20:09:34 2019 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 3FCEC13125D for ; Wed, 13 Mar 2019 20:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGza4Cd8qETs for ; Wed, 13 Mar 2019 20:09:30 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 029AA13125A for ; Wed, 13 Mar 2019 20:09:30 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id a132so1618459lfa.13 for ; Wed, 13 Mar 2019 20:09:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G6hrZ27yDxk2g+3UKtAiEYBCbbfmcq2stButHD90+W4=; b=EA1rJXU72pcyVJc1z/hZD7hPsVf0u4duVbJKxS4Q6khST2o/KsE+uIVUEACrxCDO6f a6K9U4zzi94oLjQFb6yv5kuRXVdj7cD2jO6Fbio2rBfmy+mljmvfo0Ya4m2/OAOFoMMX LjOaoLWfa5l9SqHRuk/ycK0h75nEOWdz7PICONXNUz1w53Uu8oGNI0PxDAuCUJ/7eSiw TGC6N7kbQkRaEXjfGAeEz+4VLExrrPkehnH4Q8jMtZs527PB5jAh6vPPTJq3FZrdu4aT s9QpZ1PDHZ8sDMbAXaEMLCdCY8xSVqwZCIQypQ6rzCJML1E1IhixjCbcJb4foyX52wTO ty7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G6hrZ27yDxk2g+3UKtAiEYBCbbfmcq2stButHD90+W4=; b=dIfyg4TEEzvKQO/uPQ/BOWx5ozAGqN8w7j4R3sp3BGa3JS/BdStrVxF8xL5xLO3La0 ThdsxYXGJI4U0uP4Crlt5F3LPaNmHCvQaYqOMbR/nihZlxkARTqhGWmFkXIwCBaKc0ae Lvlp93HR2ufvmI4ak0eypsmRrsu/4sFgPCAi4S0DE52iH4TvB/b1UosoZH9183KYV3ce yMHiyj/QsYDyr1ehEzG5liTT5CljnRazJ3ui5atUXyRGld+KG2QCJV4s7arFtuSmp7Io ciigCPlUuf6g8aAi/b7U/EJlz9OZybB8ZbWBW8oDr/farFBC45mVYr/EWVVAEEcfTmgv Lssg== X-Gm-Message-State: APjAAAWRDP/bSYFOqFq/u+2nAO9zqqKV5CkcHUJf3hH3Lpw6GIfXkY/f BmzdpcIu4SwUcigLgsrjJZbWtTOLq+NpF9FIJPhk4A== X-Google-Smtp-Source: APXvYqynk4GV7i+cTLmt4QGZJdZyxog8yBu3I+j6F6sIUb1YIwIQDQLBV4ym39DhkZHCrvRcEVtOGAuUolJ2qkoWzMg= X-Received: by 2002:ac2:4191:: with SMTP id z17mr26217505lfh.78.1552532967995; Wed, 13 Mar 2019 20:09:27 -0700 (PDT) MIME-Version: 1.0 References: <1d369e948382f1431f6e67abce4ca0c8.squirrel@www.amsl.com> <336679b2-abd1-6372-050e-974530088821@gwerder.net> <26313F4A-06FF-4155-B646-09C96F370894@akamai.com> <6dd6ed2c-b2a6-f42f-9edc-25c9607bf173@gwerder.net> <2512b74994985f18b6967c4cef8e41ed.squirrel@www.amsl.com> In-Reply-To: From: Eric Rescorla Date: Wed, 13 Mar 2019 20:08:50 -0700 Message-ID: To: Martin Thomson Cc: DISPATCH Content-Type: multipart/alternative; boundary="0000000000000f4ef70584054061" Archived-At: Subject: Re: [dispatch] [Secdispatch] A protocol for anonymity 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, 14 Mar 2019 03:09:33 -0000 --0000000000000f4ef70584054061 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 13, 2019 at 8:07 PM Martin Thomson wrote: > The challenging thing with a proposal that is as broad as this is finding > a home. There are, to varying degrees, lots of different pieces to this > design. Without going into the design in more detail, I see both > cryptographic and transport elements. Both of which are similar in the > abstract to existing work in the IETF, but entirely dissimilar in form. = A > dispatch group is likely the best target for this, but even then it is > likely to contain elements for multiple areas (there's a whole section on > routing that I think is probably not routing in the sense that it would f= it > in RTG, but it's still an entirely separate part of the design; there is > also a section on accounting that might or might not be suitable for OPS)= . > > That alone isn't information you could use to decide anything here (other > than perhaps the shortcomings of the IETF when it comes to dealing with > cross-area stuff). > > I have some reservations about the lack of context in the proposal. For > instance, the section on accounting launches into mechanisms without > establishing what is being accounted for and to whom. A protocol like th= is > would also typically require considerable security analysis. > > This looks like a specification at the sort of level that would be > appropriate for a BoF or dispatch session. If there was significant > interest in this, then I would expect to see - over time - those details > filled in. Using the dispatch process is probably right, and either woul= d > be fine. > This all seems right, but I think the first question we would need to ask is "who is planning to implement this"? -Ekr > On Tue, Mar 12, 2019, at 21:43, RFC ISE (Adrian Farrel) wrote: > > Thanks Barry, > > > > Useful comments. > > > > To be clear on the ISE position, here... > > > > If there is a home for this work in the IETF (or possibly the IRTF), I > > would be delighted to see the work moved there, discussed, updated, and > > published with IETF consensus. That is, in fact, the purpose of this > > thread. > > > > Although it may be late for a presentation in Prague, I believe that th= e > > corridors in the Hilton will be fully functional, and that the mailing > > lists run 24x7 so we should at least be able to get an idea of whether > > there is support to look at this in the IETF. (I am getting a strong hi= nt > > that that is the case, but as yet no firm commitment from a WG chair th= at > > their mailing list is the place to focus the conversation.) > > > > Thanks, > > Adrian > > > > Barry Leiba wrote: > > > I would feel better about this if it were done as an Experimental RFC > > > in the IETF stream, ideally through an ART/SEC working group, as it's > > > too much to be AD-sponsored. As such, it should go through > > > secdispatch or dispatch, and it's a bit late to do that for Prague. > > > > > > I'd be hesitant to actually *block* it from the Independent stream > > > (more specifically, asking the ISE not to publish it because it needs > > > IETF review), but I'd rather see it in the IETF stream. I also don't > > > know the history here, as I'm just stepping in as AD now, so perhaps > > > the issue of doing it in the IETF stream has already been hashed out. > > > If so, please clue me in. > > > > > > Barry > > > > > > On Tue, Mar 12, 2019 at 3:19 PM Martin wrote: > > >> > > >> Hi Rich > > >> > > >> This is a valid point. Requested status is experimental. This allows > > >> going for a standard later. So the primary goal is to become a > standard > > >> on the long term and to expose the protocol to a broader public. In = my > > >> eyes, for the standard, it would require that we have two seconding > > >> documents =C3=A2=E2=82=AC=E2=80=9D one dealing with best current pra= ctices and one focusing > > >> security considerations (maybe both in one document). The main probl= em > > >> with those two documents is not the protocol itself. As SMTP or HTTP > in > > >> its pure form, this is a transport protocol only. It does not deal > with > > >> the client side or the content itself. > > >> > > >> Anonymity is broken easily by the users themselves. As an example, y= ou > > >> may take the fact that almost no user is ready to write emails in > plain > > >> text. They want to embed graphics and emoticons. Allowing HTML > encoding > > >> on the other side makes the protocol vulnerable to bugging attacks. = At > > >> the moment I am using Thunderbird as the client and the MessageVorte= x > > >> node as "local mail server." While this makes sense from the user > > >> perspective (no new client), it is maybe not the wisest decision fro= m > an > > >> anonymity perspective. This, however, is not a problem of the > protocol. > > >> MessageVortex allows transferring any message and is not limited to > > >> emails. These possibilities should be further explored. > > >> > > >> At least for my person, this protocol opens a whole new world full o= f > > >> possibilities. So I am very keen to see what it can do. > > >> > > >> Regards > > >> Martin > > >> > > >> > > >> Am 11.03.2019 um 15:31 schrieb Salz, Rich: > > >> > I would turn this around: why does this have to be an RFC? > > >> > > > > > > > > > > > > > -- > > Adrian Farrel (ISE), > > rfc-ise@rfc-editor.org > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --0000000000000f4ef70584054061 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Mar 13, 2019 at 8:07 PM Marti= n Thomson <mt@lowentropy.net>= ; wrote:
The cha= llenging thing with a proposal that is as broad as this is finding a home.= =C2=A0 There are, to varying degrees, lots of different pieces to this desi= gn.=C2=A0 Without going into the design in more detail, I see both cryptogr= aphic and transport elements.=C2=A0 Both of which are similar in the abstra= ct to existing work in the IETF, but entirely dissimilar in form.=C2=A0 A d= ispatch group is likely the best target for this, but even then it is likel= y to contain elements for multiple areas (there's a whole section on ro= uting that I think is probably not routing in the sense that it would fit i= n RTG, but it's still an entirely separate part of the design; there is= also a section on accounting that might or might not be suitable for OPS).=

That alone isn't information you could use to decide anything here (oth= er than perhaps the shortcomings of the IETF when it comes to dealing with = cross-area stuff).

I have some reservations about the lack of context in the proposal.=C2=A0 F= or instance, the section on accounting launches into mechanisms without est= ablishing what is being accounted for and to whom.=C2=A0 A protocol like th= is would also typically require considerable security analysis.

This looks like a specification at the sort of level that would be appropri= ate for a BoF or dispatch session.=C2=A0 If there was significant interest = in this, then I would expect to see - over time - those details filled in.= =C2=A0 Using the dispatch process is probably right, and either would be fi= ne.

This all seems right, but I think t= he first question we would need to ask is "who is planning to implemen= t this"?

-Ekr


On Tue, Mar 12, 2019, at 21:43, RFC ISE (Adrian Farrel) wrote:
> Thanks Barry,
>
> Useful comments.
>
> To be clear on the ISE position, here...
>
> If there is a home for this work in the IETF (or possibly the IRTF), I=
> would be delighted to see the work moved there, discussed, updated, an= d
> published with IETF consensus. That is, in fact, the purpose of this > thread.
>
> Although it may be late for a presentation in Prague, I believe that t= he
> corridors in the Hilton will be fully functional, and that the mailing=
> lists run 24x7 so we should at least be able to get an idea of whether=
> there is support to look at this in the IETF. (I am getting a strong h= int
> that that is the case, but as yet no firm commitment from a WG chair t= hat
> their mailing list is the place to focus the conversation.)
>
> Thanks,
> Adrian
>
> Barry Leiba wrote:
> > I would feel better about this if it were done as an Experimental= RFC
> > in the IETF stream, ideally through an ART/SEC working group, as = it's
> > too much to be AD-sponsored.=C2=A0 As such, it should go through<= br> > > secdispatch or dispatch, and it's a bit late to do that for P= rague.
> >
> > I'd be hesitant to actually *block* it from the Independent s= tream
> > (more specifically, asking the ISE not to publish it because it n= eeds
> > IETF review), but I'd rather see it in the IETF stream.=C2=A0= I also don't
> > know the history here, as I'm just stepping in as AD now, so = perhaps
> > the issue of doing it in the IETF stream has already been hashed = out.
> > If so, please clue me in.
> >
> > Barry
> >
> > On Tue, Mar 12, 2019 at 3:19 PM Martin <martin@gwerder.net> wrote:
> >>
> >> Hi Rich
> >>
> >> This is a valid point. Requested status is experimental. This= allows
> >> going for a standard later. So the primary goal is to become = a standard
> >> on the long term and to expose the protocol to a broader publ= ic. In my
> >> eyes, for the standard, it would require that we have two sec= onding
> >> documents =C3=A2=E2=82=AC=E2=80=9D one dealing with best curr= ent practices and one focusing
> >> security considerations (maybe both in one document). The mai= n problem
> >> with those two documents is not the protocol itself. As SMTP = or HTTP in
> >> its pure form, this is a transport protocol only. It does not= deal with
> >> the client side or the content itself.
> >>
> >> Anonymity is broken easily by the users themselves. As an exa= mple, you
> >> may take the fact that almost no user is ready to write email= s in plain
> >> text. They want to embed graphics and emoticons. Allowing HTM= L encoding
> >> on the other side makes the protocol vulnerable to bugging at= tacks. At
> >> the moment I am using Thunderbird as the client and the Messa= geVortex
> >> node as "local mail server." While this makes sense= from the user
> >> perspective (no new client), it is maybe not the wisest decis= ion from an
> >> anonymity perspective. This, however, is not a problem of the= protocol.
> >> MessageVortex allows transferring any message and is not limi= ted to
> >> emails. These possibilities should be further explored.
> >>
> >> At least for my person, this protocol opens a whole new world= full of
> >> possibilities. So I am very keen to see what it can do.
> >>
> >> Regards
> >> Martin
> >>
> >>
> >> Am 11.03.2019 um 15:31 schrieb Salz, Rich:
> >> > I would turn this around: why does this have to be an RF= C?
> >> >
> >
> >
>
>
> --
> Adrian Farrel (ISE),
> rfc-ise@rf= c-editor.org
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/dispatch
>

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--0000000000000f4ef70584054061-- From nobody Wed Mar 13 22:16:45 2019 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 99EA1127978 for ; Wed, 13 Mar 2019 22:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.922 X-Spam-Level: X-Spam-Status: No, score=-0.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKJP24Y5UPjr for ; Wed, 13 Mar 2019 22:16:41 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410134.outbound.protection.outlook.com [40.107.141.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 113E212705F for ; Wed, 13 Mar 2019 22:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XMx8AiQ+aYvTOdT1ikSZ0UrCNgCWdN3d99OycnsoARc=; b=fi1VTO46x6Nu4O77H92FYjGzGEtZU3NMCsKzkvPM7DJo2AnEf8SyF8bXDV4KC0tYgPAYJeErW6rfY2/GNKP98LgZAjBvMYC/Ny01y6yZVbEp2K68Pg4z8qwNzseP10eoefcmCDUa26cZjkuPpKBt4CcL9ddenzyrQHkhbcppkj0= Received: from TYAPR01MB5149.jpnprd01.prod.outlook.com (20.179.187.18) by TYAPR01MB4799.jpnprd01.prod.outlook.com (20.179.175.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.14; Thu, 14 Mar 2019 05:16:38 +0000 Received: from TYAPR01MB5149.jpnprd01.prod.outlook.com ([fe80::98b6:d90e:9ae7:302]) by TYAPR01MB5149.jpnprd01.prod.outlook.com ([fe80::98b6:d90e:9ae7:302%3]) with mapi id 15.20.1709.011; Thu, 14 Mar 2019 05:16:38 +0000 From: =?utf-8?B?TWFydGluIEouIETDvHJzdA==?= To: Mary Barnes , DISPATCH Thread-Topic: [dispatch] DISPATCH agenda @ IETF-104 Thread-Index: AQHU2cAgIgwxcXFR2kWLubb43zM8k6YKlq+A Date: Thu, 14 Mar 2019 05:16:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: TYAPR03CA0017.apcprd03.prod.outlook.com (2603:1096:404:14::29) To TYAPR01MB5149.jpnprd01.prod.outlook.com (2603:1096:404:12e::18) authentication-results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [133.2.210.64] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 62af25ca-6fd3-4827-2273-08d6a83c3bfa x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7025125)(7027125)(7023125)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:TYAPR01MB4799; x-ms-traffictypediagnostic: TYAPR01MB4799: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 09760A0505 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(366004)(136003)(396003)(39830400003)(53754006)(189003)(199004)(25786009)(53936002)(8936002)(74482002)(66066001)(786003)(97736004)(14454004)(966005)(2906002)(85182001)(256004)(68736007)(6116002)(561944003)(5660300002)(508600001)(316002)(14444005)(3846002)(110136005)(76176011)(2616005)(52116002)(86362001)(486006)(31696002)(71190400001)(71200400001)(229853002)(6306002)(6436002)(6486002)(85202003)(53546011)(386003)(106356001)(446003)(6506007)(11346002)(102836004)(105586002)(186003)(26005)(8676002)(81156014)(99286004)(7736002)(31686004)(305945005)(476003)(6512007)(6246003)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:TYAPR01MB4799; H:TYAPR01MB5149.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: QpuUVzt+vNCGoRo35Wbu6vcYqT6quUixXn+nAwdNKvehJGIPCldyOb1uEDv/6Lv6O7m6bALl/jrJG8563MWaTj/7gLJB97N95Q4wu6E6WMtVmxFJ5QZq3Bu+RC327DOBjMnACkHo39BswGFSXA4drs/d5nAt70JPpi/ooFankmoUwh/mtm3WIb6YxeP6g3ayKwPPDhBULxI2rpkOvrdXs2PbH4sVwUJmPCNh6gCgZyEJRMeIj1nXTJA3xzfRfZKI6qMaEtzyp1dUfj6MYfAGXJ3xTIwOHynIy8ObvB9S69lQ7CKFmiX9xjG+PKP463djeNnHpe2T6xFZE7ieNmNM1uEnCTrIPokfnbuXT3CWDsh/DveH/ecdJZvw3Sb+1PrXJdEStes5PoTWMarFraH/wLi31PIq5ZHS7WK0AK7bODI= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 62af25ca-6fd3-4827-2273-08d6a83c3bfa X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2019 05:16:37.9308 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB4799 Archived-At: Subject: Re: [dispatch] DISPATCH agenda @ IETF-104 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, 14 Mar 2019 05:16:44 -0000 SGVsbG8gZXZlcnlib2R5LA0KDQpPbiAyMDE5LzAzLzE0IDAyOjEzLCBNYXJ5IEJhcm5lcyB3cm90 ZToNCj4gSGkgYWxsLA0KPiANCj4gV2UgaGF2ZSB1cGxvYWRlZCBhIHByZWxpbWluYXJ5IGFnZW5k YSBmb3IgRElTUEFUQ0g6DQoNClRoYW5rcyBmb3IgcHV0dGluZyB0aGlzIHRvZ2V0aGVyLg0KDQo+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy9tYXRlcmlhbHMvDQoNClRoaXMg bWF5IGJlIGp1c3QgYW4gb3ZlcnNpZ2h0LCBidXQgaW4gZ2VuZXJhbCwgSSB2ZXJ5IG11Y2ggcHJl ZmVyIHRvIA0KaGF2ZSB0aGUgYWdlbmRhIChhbmQgb3RoZXIsIHNpbWlsYXJseSBzaG9ydCBzdHVm ZikgaW5saW5lIGluIG15IGluYm94LiANClRoYXQgc2F2ZXMgbWUgKGFuZCBldmVyeWJvZHkgZWxz ZSkgYSBjbGljayAob3IgdHdvLCBwbHVzIHNvbWUgb24tcGFnZSANCnNlYXJjaCB0aW1lLCB0aGlz IHRpbWUpLiBPZiBjb3Vyc2UgaXQgY2FuIGNoYW5nZSBsYXRlciwgYnV0IHdlIGFsbCBrbm93IA0K dGhhdC4NCg0KVGhlIGFjdHVhbCBhZ2VuZGEgaXMgYXQNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvbWVldGluZy8xMDQvbWF0ZXJpYWxzL2FnZW5kYS0xMDQtZGlzcGF0Y2gtMDAuIA0KSW4g dGhlIGZ1dHVyZSwgcHJlY2lzZSBsaW5rcyB3b3VsZCBiZSBhcHByZWNpYXRlZC4NCg0KVGhlIGFn ZW5kYSBjdXJyZW50bHkgcmVhZHMgYXMgZm9sbG93czoNCg0KIyBEcmFmdCBBZ2VuZGEgRGlzcGF0 Y2ggQElFVEYtMTA0IC0gdjENCg0KRElTUEFUQ0ggTWVldGluZw0KLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQojIFN0YXR1cyBhbmQgYWdlbmRhIGJhc2ggLSBDaGFpcnMgKDEwIG1pbikNCg0KIyBSZWxh eSBVc2VyIE1hY2hpbmUgKFJVTSkgLSBCcmlhbiBSb3NlbiAoMjAgbWluKQ0KDQojIEpTT04gQ29u dGFjdCAtIEJyb24gR29uZHdhbmEgKDIwIG1pbikNCg0KIyBXZWIgUGFja2FnaW5nIC0gSmVmZnJl eSBZYXNza2luICgyMCBtaW4pDQoNCk5vdGU6IHNlZSBESVNQQVRDSCB3aWtpIGZvciBhZGRpdGlv bmFsIGxpbmtzIHRvIG1hdGVyaWFscw0KDQoNCkFSVCBBUkVBIE1lZXRpbmcNCi0tLS0tLS0tLS0t LS0tLS0tLS0NCg0KIyBCb2ZzIGFuZCBtZWV0aW5ncyBvZiBpbnRlcmVzdCAtIEFEcyAoNSBtaW4p DQoNCiMgSlNPTiBDYW5vbmljYWxpemF0aW9uIFNjaGVtZSAoSkNTKSAtIEFuZGVycyBSdW5kZ3Jl biAoMjApDQogICBEb2N1bWVudDogZHJhZnQtcnVuZGdyZW4tanNvbi1jYW5vbmljYWxpemF0aW9u LXNjaGVtZQ0KDQojIEFPQg0KDQoNCj4gUmVnYXJkcywNCj4gTWFyeS4NCj4gRElTUEFUQ0ggV0cg Y28tY2hhaXINCj4gDQo+IC0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tDQo+ IEZyb206IE1hcnkgQmFybmVzIDxtYXJ5LmlldGYuYmFybmVzQGdtYWlsLmNvbT4NCj4gRGF0ZTog VGh1LCBNYXIgNywgMjAxOSBhdCA5OjU5IEFNDQo+IFN1YmplY3Q6IFRvcGljcyBmb3IgRElTUEFU Q0ggQCBJRVRGLTEwNA0KPiBUbzogRElTUEFUQ0ggPGRpc3BhdGNoQGlldGYub3JnPg0KPiBDYzog QVJUIEFEcyA8YXJ0LWFkc0BpZXRmLm9yZz4sIGRpc3BhdGNoIGNoYWlycyA8ZGlzcGF0Y2gtY2hh aXJzQGlldGYub3JnPg0KPiANCj4gDQo+IEhpIGFsbCwNCj4gDQo+IFRoZSB3aWtpIGhhcyBiZWVu IHVwZGF0ZWQgd2l0aCB0aGUgdG9waWNzIHRoYXQgaGF2ZSBiZWVuIGFncmVlZCB0byBiZQ0KPiBk aXNjdXNzZWQgYXQgSUVURi0xMDQ6ICBodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9kaXNwYXRj aC93aWtpL1dpa2lTdGFydA0KPiANCj4gVGhlIHByb3Bvc2FsIGZvciBtb3ZpbmcgZm9yd2FyZCBk cmFmdC1kb2xkLXBheXRvIGlzIHN0aWxsIGJlaW5nIGRpc2N1c3NlZA0KPiBhbW9uZ3N0IEFEUy9j aGFpcnMgYXMgaXMgdGhlIEpTT04gQ2Fub25pY2FsaXphdGlvbiB0aGF0IGhhZCBiZWVuIHByb3Bv c2VkDQo+IGFzIGEgQm9GIGluIHRoZSBTRUMgQXJlYSwgYnV0IHdhcyBub3QgYXBwcm92ZWQuDQo+ IA0KPiBXZSB3aWxsIHBvc3QgYW55IHVwZGF0ZXMgdG8gdGhlIHdpa2kgYW5kIHdpbGwgcG9zdCBh biBhZ2VuZGEgc2hvcnRseS4NCj4gDQo+IEFzIGEgcmVtaW5kZXIsIGlmIHlvdSBhcmUgc3VibWl0 dGluZyBkcmFmdHMgZm9yIGRpc2N1c3Npb24gaW4gdGhlIGRpc3BhdGNoDQo+IHdvcmtpbmcgZ3Jv dXAgZm9sbG93aW5nIHRoZSBzdGFuZGFyZCBjb252ZW50aW9uIG9mIGluY2x1ZGluZyB0aGUgV0cg bmFtZSBpbg0KPiB0aGUgZHJhZnQgbmFtZSAoaS5lLiwgZHJhZnQtPG5hbWU+LWRpc3BhdGNoLWJs YWgtYmxhaCkgIG1ha2VzIGl0ICptdWNoKg0KPiBlYXNpZXIgZm9yIG1lIGFzIGNoYWlyIHRvIG1h a2Ugc3VyZSBJIGhhdmUgdGhlIHJpZ2h0IGRvY3VtZW50cyBpZGVudGlmaWVkDQo+IG9uIHRoZSB3 aWtpIGFuZCBvbiB0aGUgYWdlbmRhLiAgIFRoZSB0b29sIHdpbGwgYWxsb3cgeW91IHRvIGluZGlj YXRlIHRoYXQNCj4gdGhlIGRvY3VtZW50IHdpdGggdGhlIG5ldyBuYW1lIHJlcGxhY2VzIHRoZSBk b2N1bWVudCB3aXRoIHRoZSBvbGQgbmFtZSBpZg0KPiB0aGF0J3MgYSBjb25jZXJuLg0KPiANCj4g UmVnYXJkcywNCj4gTWFyeQ0KPiBESVNQQVRDSCBXRyBjby1jaGFpcg0KPiANCg== From nobody Tue Mar 19 15:35:27 2019 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 EA37C131083 for ; Tue, 19 Mar 2019 15:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=lN1gxB7x; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=n3Z2h5fs 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 WMygwE5oGVPr for ; Tue, 19 Mar 2019 15:35:23 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A519E130E8B for ; Tue, 19 Mar 2019 15:35:23 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E7BCD220C6 for ; Tue, 19 Mar 2019 18:35:22 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Tue, 19 Mar 2019 18:35:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=vcdlW vGuPz8yyzu97UdKvQKQhwREiiD5Lw5+ggYJqfQ=; b=lN1gxB7xhGBuUIHhmd+Ni QO8v3yNu0g+63/NCnd9R6UAU0/wzZc12GfeuL2VbpPH6UxftTj4gTBToAerswYBe lcdPY8FrtnebqzhTLLIinB8GG/ECCk/aUMKIP898xHAwSEcFwY7EgWKChueeT3AU Vz2wdv+AUTeWziCL/cpw6fi3jdtjjrz9OiaYfmD/tWAlMhWjyjAiOkNJYTsZSf2U B6PauskFtRD6YXG2t4/RtLGmK20wcyJBtfZoFYvIQPBe0So6vZRhdGXJbdTDJqx5 jxDDUIJ2KOQh4ZDRhfhTpvl4NkP2BCkNGtplEwBez+k2BGVJJQKPPbv3HoNvlSuv w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=vcdlWvGuPz8yyzu97UdKvQKQhwREiiD5Lw5+ggYJq fQ=; b=n3Z2h5fsk2wqrHyxdf+DZu8mfko/amIYHbFRsWuOQAV+k6Dz/4indd9i7 b4G8PTRRvxHJBic64qTkD7L9cyMJgu7HZaOi5MpbqeoU8FFFZUkeDrsMMVLkrLWw FNCRvhJfEuksQ6rdFEBSaF61nNuCWyEQmCd+I5OA6tvSrtqY00xy0bcK00TpUXnE AwjXxaD8/7YDu5M534gBgbmcYhgTuoxjnFh9K0oBJj4hIO4joV+J5Pkae3rAEOv8 GQT03IqG7TRO5nRNLfRh6DFQrbW4h4yAK45f/YkZFJe5zJRRXVAAqiQuvIHEHykP 38W+2LS4kZ3Ul/AmKlFTW/hY9JEGg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrieehucetufdoteggodetrfdotffvucfrrh hofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgenuceurghi lhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesthhqredtre erjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghn thhrohhphidrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfrrghrrghmpe hmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushhtvghr ufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 79F387C6B6; Tue, 19 Mar 2019 18:35:22 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-976-g376b1f3-fmstable-20190314v3 Mime-Version: 1.0 X-Me-Personality: 92534000 Message-Id: <3c9085a4-3348-489b-8a42-545f686c017a@www.fastmail.com> In-Reply-To: References: Date: Tue, 19 Mar 2019 18:35:18 -0400 From: "Martin Thomson" To: dispatch@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dispatch] DISPATCH agenda @ IETF-104 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 22:35:26 -0000 I agree with Martin. I don't know how to find these documents. Where is = the wiki? The URL is the answer. On Thu, Mar 14, 2019, at 16:16, Martin J. D=C3=BCrst wrote: > Hello everybody, >=20 > On 2019/03/14 02:13, Mary Barnes wrote: > > Hi all, > >=20 > > We have uploaded a preliminary agenda for DISPATCH: >=20 > Thanks for putting this together. >=20 > > https://datatracker.ietf.org/meeting/materials/ >=20 > This may be just an oversight, but in general, I very much prefer to=20= > have the agenda (and other, similarly short stuff) inline in my inbox.= =20 > That saves me (and everybody else) a click (or two, plus some on-page=20= > search time, this time). Of course it can change later, but we all kno= w=20 > that. >=20 > The actual agenda is at > https://datatracker.ietf.org/meeting/104/materials/agenda-104-dispatch= -00.=20 > In the future, precise links would be appreciated. >=20 > The agenda currently reads as follows: >=20 > # Draft Agenda Dispatch @IETF-104 - v1 >=20 > DISPATCH Meeting > ------------------- >=20 > # Status and agenda bash - Chairs (10 min) >=20 > # Relay User Machine (RUM) - Brian Rosen (20 min) >=20 > # JSON Contact - Bron Gondwana (20 min) >=20 > # Web Packaging - Jeffrey Yasskin (20 min) >=20 > Note: see DISPATCH wiki for additional links to materials >=20 >=20 > ART AREA Meeting > ------------------- >=20 > # Bofs and meetings of interest - ADs (5 min) >=20 > # JSON Canonicalization Scheme (JCS) - Anders Rundgren (20) > Document: draft-rundgren-json-canonicalization-scheme >=20 > # AOB >=20 >=20 > > Regards, > > Mary. > > DISPATCH WG co-chair > >=20 > > ---------- Forwarded message --------- > > From: Mary Barnes > > Date: Thu, Mar 7, 2019 at 9:59 AM > > Subject: Topics for DISPATCH @ IETF-104 > > To: DISPATCH > > Cc: ART ADs , dispatch chairs > >=20 > >=20 > > Hi all, > >=20 > > The wiki has been updated with the topics that have been agreed to b= e > > discussed at IETF-104: https://trac.ietf.org/trac/dispatch/wiki/Wik= iStart > >=20 > > The proposal for moving forward draft-dold-payto is still being disc= ussed > > amongst ADS/chairs as is the JSON Canonicalization that had been pro= posed > > as a BoF in the SEC Area, but was not approved. > >=20 > > We will post any updates to the wiki and will post an agenda shortly= . > >=20 > > As a reminder, if you are submitting drafts for discussion in the di= spatch > > working group following the standard convention of including the WG = name in > > the draft name (i.e., draft--dispatch-blah-blah) makes it *mu= ch* > > easier for me as chair to make sure I have the right documents ident= ified > > on the wiki and on the agenda. The tool will allow you to indicate= that > > the document with the new name replaces the document with the old na= me if > > that's a concern. > >=20 > > Regards, > > Mary > > DISPATCH WG co-chair > >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Tue Mar 19 16:07:06 2019 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 B1E1E127133 for ; Tue, 19 Mar 2019 16:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKQjl0QeKjAq for ; Tue, 19 Mar 2019 16:07:03 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 68B7512008F for ; Tue, 19 Mar 2019 16:07:02 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id y6so541715ljd.12 for ; Tue, 19 Mar 2019 16:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=O9+PqL/ICL0OuDBCZCyP7lWsEJ0Wgi4/JaQpeF3n3IU=; b=RxSPId0GA/ltGeYuF7PFRo2Vh6xU8IFTs7PCxn1MfS5M7GM5IXiePuLQvTsqOfONDA VaOvzGQecEmzLS5KLNajHVqaVb6HVsWbZAPVqNS0JpfQY+8G+9ridW/Ts+s//tT5mhyJ KhbEa/p7YVm5YQfp3G5YQi9XbsaSREjX01dlgbkTJDXMtnwmv47Mu2SPO7hiSJLqIUxT wf48UJYO71/Q+lf1J7bHQ2sbLdXEOkoM8xxfC7YkeIuNqK82iRSlYISvpMd/pq5iy1PD ZB39I1sb+rkf/HqM/y5P9Ij9s6Yd4VedhM2FO0/qhrcecmbIkI/lfwaLh7k5f1txh32N z7GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=O9+PqL/ICL0OuDBCZCyP7lWsEJ0Wgi4/JaQpeF3n3IU=; b=ldgFJCQ8ovBhfPod0HYr/khlBCP6fdoyRmB3Mvb12XOaU+Tj0LxdAK1vIn1rha9rkB q8DtJXppmAjgGTQj1zE9hXgrP2/1MN7cwG1QEvRhjN/nx0Dmkp3s7A0yDYbmx7628RQk XtX/qqCDPM13UFNk7YN+pLXJlL10M5wU+xrdfkIENPEvXavTF+U6nEMT4HzQ+YCZaxiS o2BGBg3NzKwjDb3+rEtCTv2KhxNBBoEixceria6xUD0/CaShyXUM9EWuyMHClnIYAwjC KSF/jKY6KdQNbaMghYcQr/QkTD7BtDhboqIzAwHv3r45TTP8BdZuEb/afdGeeqGaU2U0 5InA== X-Gm-Message-State: APjAAAXA1IXyrBobOD63JGymxzJyE0YERpP/QMFACwa7lTBqZZxMJcKL Qn3rTaMTcYs5HAfW7L3IxecIKsxzOGVyxAczNy+y9Q== X-Google-Smtp-Source: APXvYqyAfHjE7EuFac/iNxA3zRPi5xnFVw29InoIqqx/B6eQ/SW8ryKwWXvOEm9Fikl/m9SnMUE8e/b3ZrD4sCk4PxA= X-Received: by 2002:a2e:9ec2:: with SMTP id h2mr15185573ljk.186.1553036820450; Tue, 19 Mar 2019 16:07:00 -0700 (PDT) MIME-Version: 1.0 References: <3c9085a4-3348-489b-8a42-545f686c017a@www.fastmail.com> In-Reply-To: From: Mary Barnes Date: Tue, 19 Mar 2019 18:06:49 -0500 Message-ID: To: DISPATCH Content-Type: multipart/alternative; boundary="0000000000000192dd05847a90e4" Archived-At: Subject: [dispatch] Fwd: DISPATCH agenda @ IETF-104 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 23:07:06 -0000 --0000000000000192dd05847a90e4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DISPATCH wiki is here and was posted in earlier email messages: https://trac.ietf.org/trac/dispatch/wiki Every WG has such a wiki although few use it. It would be super easy to find the documents if authors would actually follow the recommendation and include -dispatch in the document name. It's not clear to me why folks can't seem to follow that. You can find links to relevant documents in the threads posted on the wiki. We actually haven't routinely sent an email when we've uploaded the agenda. I think I'll not bother doing that next time since I assume everyone knows how to find meeting materials and knows how to click links to find WG agendas. Regards, Mary. On Tue, Mar 19, 2019 at 5:35 PM Martin Thomson wrote: > I agree with Martin. I don't know how to find these documents. Where is > the wiki? > > The URL is the answer. > > On Thu, Mar 14, 2019, at 16:16, Martin J. D=C3=BCrst wrote: > > Hello everybody, > > > > On 2019/03/14 02:13, Mary Barnes wrote: > > > Hi all, > > > > > > We have uploaded a preliminary agenda for DISPATCH: > > > > Thanks for putting this together. > > > > > https://datatracker.ietf.org/meeting/materials/ > > > > This may be just an oversight, but in general, I very much prefer to > > have the agenda (and other, similarly short stuff) inline in my inbox. > > That saves me (and everybody else) a click (or two, plus some on-page > > search time, this time). Of course it can change later, but we all know > > that. > > > > The actual agenda is at > > > https://datatracker.ietf.org/meeting/104/materials/agenda-104-dispatch-00= . > > > In the future, precise links would be appreciated. > > > > The agenda currently reads as follows: > > > > # Draft Agenda Dispatch @IETF-104 - v1 > > > > DISPATCH Meeting > > ------------------- > > > > # Status and agenda bash - Chairs (10 min) > > > > # Relay User Machine (RUM) - Brian Rosen (20 min) > > > > # JSON Contact - Bron Gondwana (20 min) > > > > # Web Packaging - Jeffrey Yasskin (20 min) > > > > Note: see DISPATCH wiki for additional links to materials > > > > > > ART AREA Meeting > > ------------------- > > > > # Bofs and meetings of interest - ADs (5 min) > > > > # JSON Canonicalization Scheme (JCS) - Anders Rundgren (20) > > Document: draft-rundgren-json-canonicalization-scheme > > > > # AOB > > > > > > > Regards, > > > Mary. > > > DISPATCH WG co-chair > > > > > > ---------- Forwarded message --------- > > > From: Mary Barnes > > > Date: Thu, Mar 7, 2019 at 9:59 AM > > > Subject: Topics for DISPATCH @ IETF-104 > > > To: DISPATCH > > > Cc: ART ADs , dispatch chairs < > dispatch-chairs@ietf.org> > > > > > > > > > Hi all, > > > > > > The wiki has been updated with the topics that have been agreed to be > > > discussed at IETF-104: > https://trac.ietf.org/trac/dispatch/wiki/WikiStart > > > > > > The proposal for moving forward draft-dold-payto is still being > discussed > > > amongst ADS/chairs as is the JSON Canonicalization that had been > proposed > > > as a BoF in the SEC Area, but was not approved. > > > > > > We will post any updates to the wiki and will post an agenda shortly. > > > > > > As a reminder, if you are submitting drafts for discussion in the > dispatch > > > working group following the standard convention of including the WG > name in > > > the draft name (i.e., draft--dispatch-blah-blah) makes it *muc= h* > > > easier for me as chair to make sure I have the right documents > identified > > > on the wiki and on the agenda. The tool will allow you to indicate > that > > > the document with the new name replaces the document with the old nam= e > if > > > that's a concern. > > > > > > Regards, > > > Mary > > > DISPATCH WG co-chair > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --0000000000000192dd05847a90e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

DISPATCH wiki is here and was posted in earlier email message= s:
Every W= G has such a wiki although few use it.=C2=A0

I= t would be super easy to find the documents if authors would actually follo= w the recommendation and include -dispatch in the document name.=C2=A0 It&#= 39;s not clear to me why folks can't seem to follow that.=C2=A0 You can= find links to relevant documents in the threads posted on the wiki.=C2=A0 = =C2=A0

We actually haven't routinely sent an e= mail when we've uploaded the agenda.=C2=A0 =C2=A0I think I'll not b= other doing that next time since I assume everyone knows how to find meetin= g materials and knows how to click links to find WG agendas.=C2=A0 =C2=A0

Regards,
Mary.=C2=A0

On Tue, Mar 19, 2019= at 5:35 PM Martin Thomson <mt@lowentropy.net> wrote:
I agree with Martin. I don't know how to f= ind these documents. Where is the wiki?

The URL is the answer.

On Thu, Mar 14, 2019, at 16:16, Martin J. D=C3=BCrst wrote:
> Hello everybody,
>
> On 2019/03/14 02:13, Mary Barnes wrote:
> > Hi all,
> >
> > We have uploaded a preliminary agenda for DISPATCH:
>
> Thanks for putting this together.
>
> > https://datatracker.ietf.org/meeting/mate= rials/
>
> This may be just an oversight, but in general, I very much prefer to <= br> > have the agenda (and other, similarly short stuff) inline in my inbox.=
> That saves me (and everybody else) a click (or two, plus some on-page =
> search time, this time). Of course it can change later, but we all kno= w
> that.
>
> The actual agenda is at
> https://datatracker.ie= tf.org/meeting/104/materials/agenda-104-dispatch-00.
> In the future, precise links would be appreciated.
>
> The agenda currently reads as follows:
>
> # Draft Agenda Dispatch @IETF-104 - v1
>
> DISPATCH Meeting
> -------------------
>
> # Status and agenda bash - Chairs (10 min)
>
> # Relay User Machine (RUM) - Brian Rosen (20 min)
>
> # JSON Contact - Bron Gondwana (20 min)
>
> # Web Packaging - Jeffrey Yasskin (20 min)
>
> Note: see DISPATCH wiki for additional links to materials
>
>
> ART AREA Meeting
> -------------------
>
> # Bofs and meetings of interest - ADs (5 min)
>
> # JSON Canonicalization Scheme (JCS) - Anders Rundgren (20)
>=C2=A0 =C2=A0 Document: draft-rundgren-json-canonicalization-scheme
>
> # AOB
>
>
> > Regards,
> > Mary.
> > DISPATCH WG co-chair
> >
> > ---------- Forwarded message ---------
> > From: Mary Barnes <mary.ietf.barnes@gmail.com>
> > Date: Thu, Mar 7, 2019 at 9:59 AM
> > Subject: Topics for DISPATCH @ IETF-104
> > To: DISPATCH <dispatch@ietf.org>
> > Cc: ART ADs <art-ads@ietf.org>, dispatch chairs <dispatch-chairs@ietf.org>
> >
> >
> > Hi all,
> >
> > The wiki has been updated with the topics that have been agreed t= o be
> > discussed at IETF-104:=C2=A0 https://tra= c.ietf.org/trac/dispatch/wiki/WikiStart
> >
> > The proposal for moving forward draft-dold-payto is still being d= iscussed
> > amongst ADS/chairs as is the JSON Canonicalization that had been = proposed
> > as a BoF in the SEC Area, but was not approved.
> >
> > We will post any updates to the wiki and will post an agenda shor= tly.
> >
> > As a reminder, if you are submitting drafts for discussion in the= dispatch
> > working group following the standard convention of including the = WG name in
> > the draft name (i.e., draft-<name>-dispatch-blah-blah)=C2= =A0 makes it *much*
> > easier for me as chair to make sure I have the right documents id= entified
> > on the wiki and on the agenda.=C2=A0 =C2=A0The tool will allow yo= u to indicate that
> > the document with the new name replaces the document with the old= name if
> > that's a concern.
> >
> > Regards,
> > Mary
> > DISPATCH WG co-chair
> >
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/dispatch
>

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--0000000000000192dd05847a90e4-- From nobody Tue Mar 19 19:56:12 2019 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 BECE01311A5 for ; Tue, 19 Mar 2019 19:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.923 X-Spam-Level: X-Spam-Status: No, score=-0.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebyAFmyTri11 for ; Tue, 19 Mar 2019 19:56:08 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410107.outbound.protection.outlook.com [40.107.141.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9821B130EDB for ; Tue, 19 Mar 2019 19:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kDOy9ETdvzrZ80kijK/Sr5yXIlsV3V3qAvQ+HVxER9M=; b=fVHlFHidZWLimSuZ/FYOUuYcUBZW1vK6oH4C8DUyUJx1Ol9Qv6s9LRBj7KoShwItT7AQLIvFVVwGgyXyhIkzKxVFLQJuq7hMR0XimvrGjxq+ISbthB9ppaH45o5xnM507xoseXXwJqfU89C9dUU5X6IK8FjVNCBdNNftDJh8U18= Received: from TYAPR01MB5149.jpnprd01.prod.outlook.com (20.179.187.18) by TYAPR01MB3872.jpnprd01.prod.outlook.com (20.178.138.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.14; Wed, 20 Mar 2019 02:56:06 +0000 Received: from TYAPR01MB5149.jpnprd01.prod.outlook.com ([fe80::98b6:d90e:9ae7:302]) by TYAPR01MB5149.jpnprd01.prod.outlook.com ([fe80::98b6:d90e:9ae7:302%3]) with mapi id 15.20.1709.015; Wed, 20 Mar 2019 02:56:06 +0000 From: =?utf-8?B?TWFydGluIEouIETDvHJzdA==?= To: Mary Barnes CC: DISPATCH Thread-Topic: [dispatch] Fwd: DISPATCH agenda @ IETF-104 Thread-Index: AQHU3sh26DrF0OpPt0y62hjCs4MHwQ== Date: Wed, 20 Mar 2019 02:56:05 +0000 Message-ID: <3baa9d13-400a-bdda-0eb7-2bb759c4a04b@it.aoyama.ac.jp> References: <3c9085a4-3348-489b-8a42-545f686c017a@www.fastmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: TYCPR01CA0101.jpnprd01.prod.outlook.com (2603:1096:405:4::17) To TYAPR01MB5149.jpnprd01.prod.outlook.com (2603:1096:404:12e::18) authentication-results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [133.2.210.64] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 380fbbe4-28cf-42a7-18a9-08d6acdf9893 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7025125)(7027125)(7023125)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:TYAPR01MB3872; x-ms-traffictypediagnostic: TYAPR01MB3872: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-forefront-prvs: 098291215C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400003)(376002)(346002)(396003)(366004)(136003)(53754006)(189003)(199004)(508600001)(85182001)(74482002)(2616005)(66574012)(561944003)(11346002)(6246003)(476003)(6436002)(486006)(6486002)(229853002)(6306002)(5660300002)(99286004)(76176011)(446003)(66066001)(6512007)(53936002)(52116002)(7736002)(305945005)(2906002)(8676002)(81156014)(81166006)(85202003)(31686004)(106356001)(105586002)(86362001)(26005)(8936002)(53546011)(386003)(93886005)(6506007)(786003)(3846002)(68736007)(316002)(4326008)(102836004)(25786009)(6116002)(71200400001)(966005)(71190400001)(14454004)(14444005)(256004)(97736004)(31696002)(6916009)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:TYAPR01MB3872; H:TYAPR01MB5149.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: GCfLr7hhAR3MOaOSOKOmKDTVul6JKPhx9zku7JTtPxNyXJthc5tXke//gJVF5l2eBK5JuFN1+MUrG38R5Ro5JrdTWWKc+kSrROrsWD48s9yRnuo/+VpW6kdZL00o+eTFSf6rfzkcZGOCqptOEBo6HYqSUPX2cF+TMybpyl/MhODPyr5Ufodwev5hHPnowOkShAixriL/Z5zUmge42QvXMhT2M2V+hurRy7wYDedhgBT2nlWQ4KL6AG0Z+ix/aNmwUKGLd07IDwzcxGAbiMPkCq3Dgp3UuhG6POD6CGURIoJzzyVkrdjhGdrk3Xvyx4zdmVt9mezl1xqARsOaxDEwb/dWYvikI1G2vLBNcFsNBwsSuGneBBWhcg8o1xtf0SNIqg7cDV1+VSL0zQ0B8UHunk3cPnKkbrw7gYNU/T6ldcw= Content-Type: text/plain; charset="utf-8" Content-ID: <584FC74577F4B3438CC107454056A1EB@jpnprd01.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 380fbbe4-28cf-42a7-18a9-08d6acdf9893 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2019 02:56:05.9106 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB3872 Archived-At: Subject: Re: [dispatch] Fwd: DISPATCH agenda @ IETF-104 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, 20 Mar 2019 02:56:11 -0000 SGVsbG8gTWFyeSwNCg0KT24gMjAxOS8wMy8yMCAwODowNiwgTWFyeSBCYXJuZXMgd3JvdGU6DQo+ IERJU1BBVENIIHdpa2kgaXMgaGVyZSBhbmQgd2FzIHBvc3RlZCBpbiBlYXJsaWVyIGVtYWlsIG1l c3NhZ2VzOg0KPiBodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9kaXNwYXRjaC93aWtpDQo+IEV2 ZXJ5IFdHIGhhcyBzdWNoIGEgd2lraSBhbHRob3VnaCBmZXcgdXNlIGl0Lg0KDQpZZXMgaW5kZWVk LiBJbiBteSBtb3JlIHRoYW4gMjUgeWVhcnMgb2YgSUVURiBpbnZvbHZlbWVudCAob24gYW5kIG9m ZiksIA0KaXQncyBwcm9iYWJseSB0aGUgZmlyc3QgdGltZSBJIGhhdmUgbG9va2VkIGF0IHN1Y2gg YSB3aWtpLiBJZiBvdGhlciBXR3MgDQpkb24ndCB1c2UgaXQsIGl0J3MgZGlmZmljdWx0IHRvIGdl dCB0aGUgaGFuZyBvZiBpdC4NCg0KQWxzbywgaWYgeW91IHRoaW5rIHRoZSB3aWtpIGlzIGltcG9y dGFudCwgaXQgd291bGQgYmUgZ29vZCB0byBhZGQgYSBsaW5rIA0KdG8gdGhlIGFnZW5kYS4gQ3Vy cmVudGx5LCB0aGUgd2lraSBvbmx5IHNob3dzIHdoaWNoIGRyYWZ0cyBhcmUgdXAsIGJ1dCANCm5v dCB0aW1pbmcgb3IgcHJlc2VudGVycy4NCg0KQW5kIGl0J3Mgbm90IHJlYWxseSBhYm91dCBtZSBv ciB0aGUgb3RoZXIgTWFydGluLCBpdCdzIGFsc28gYWJvdXQgbmV3Y29tZXJzLg0KDQo+IEl0IHdv dWxkIGJlIHN1cGVyIGVhc3kgdG8gZmluZCB0aGUgZG9jdW1lbnRzIGlmIGF1dGhvcnMgd291bGQg YWN0dWFsbHkNCj4gZm9sbG93IHRoZSByZWNvbW1lbmRhdGlvbiBhbmQgaW5jbHVkZSAtZGlzcGF0 Y2ggaW4gdGhlIGRvY3VtZW50IG5hbWUuICBJdCdzDQo+IG5vdCBjbGVhciB0byBtZSB3aHkgZm9s a3MgY2FuJ3Qgc2VlbSB0byBmb2xsb3cgdGhhdC4gIFlvdSBjYW4gZmluZCBsaW5rcyB0bw0KPiBy ZWxldmFudCBkb2N1bWVudHMgaW4gdGhlIHRocmVhZHMgcG9zdGVkIG9uIHRoZSB3aWtpLg0KPiAN Cj4gV2UgYWN0dWFsbHkgaGF2ZW4ndCByb3V0aW5lbHkgc2VudCBhbiBlbWFpbCB3aGVuIHdlJ3Zl IHVwbG9hZGVkIHRoZQ0KPiBhZ2VuZGEuICAgSSB0aGluayBJJ2xsIG5vdCBib3RoZXIgZG9pbmcg dGhhdCBuZXh0IHRpbWUgc2luY2UgSSBhc3N1bWUNCj4gZXZlcnlvbmUga25vd3MgaG93IHRvIGZp bmQgbWVldGluZyBtYXRlcmlhbHMgYW5kIGtub3dzIGhvdyB0byBjbGljayBsaW5rcw0KPiB0byBm aW5kIFdHIGFnZW5kYXMuDQoNCkZpcnN0LCBJIGRvbid0IHRoaW5rIGV2ZXJ5Ym9keSBkb2VzIGtu b3cgYWxsIHRoZXNlIGRldGFpbHMuIEFuZCBldmVuIGlmIA0KdGhleSBrbm93LCBpdCdzIHF1aXRl IGEgZmV3IGNsaWNrcy4NCg0KQnV0IHdoYXQncyBtdWNoIG1vcmUgaW1wb3J0YW50IGlzIHRoYXQg aWYgeW91IGRvbid0IGFubm91bmNlIHRoYXQgdGhlIFdHIA0KYWdlbmRhIGlzIHVwLCBub2JvZHkg ZXhjZXB0IHlvdSBrbm93cyB3aGVuIHRvIGdvIGFuZCBjaGVjayBvdXQgdGhlIA0KYWdlbmRhLiBJ IHRoaW5rIHBlb3BsZSBoYXZlIGJldHRlciB3YXlzIHRvIHNwZW5kIHRoZWlyIHRpbWUgdGhhbiAN CmNoZWNraW5nIGV2ZXJ5IGRheSB3aGV0aGVyIHRoZSBhZ2VuZGEgaXMgdXAuDQoNClNlbmRpbmcg dGhpbmdzIHN1Y2ggYXMgdGhlIGFnZW5kYSAob3IgYXQgbGVhc3QgYW4gJ2FnZW5kYSBpcyB1cCwg aXQncyANCmhlcmUnIHNpZ25hbCkgdG8gdGhlIG1haWxpbmcgbGlzdCBjYW4gYWxzbyBiZSBzZWVu IGFzIHBhcnQgb2YgdGhlIA0KcHJpbmNpcGxlIHRoYXQgYWxsIFdHIGRlY2lzaW9ucyBhcmUgY29u ZmlybWVkIG9uIHRoZSBtYWlsaW5nIGxpc3QuDQoNClJlZ2FyZHMsICAgTWFydGluLg0KDQoNCj4g UmVnYXJkcywNCj4gTWFyeS4NCj4gDQo+IE9uIFR1ZSwgTWFyIDE5LCAyMDE5IGF0IDU6MzUgUE0g TWFydGluIFRob21zb24gPG10QGxvd2VudHJvcHkubmV0PiB3cm90ZToNCj4gDQo+PiBJIGFncmVl IHdpdGggTWFydGluLiBJIGRvbid0IGtub3cgaG93IHRvIGZpbmQgdGhlc2UgZG9jdW1lbnRzLiBX aGVyZSBpcw0KPj4gdGhlIHdpa2k/DQo+Pg0KPj4gVGhlIFVSTCBpcyB0aGUgYW5zd2VyLg0KPj4N Cj4+IE9uIFRodSwgTWFyIDE0LCAyMDE5LCBhdCAxNjoxNiwgTWFydGluIEouIETDvHJzdCB3cm90 ZToNCj4+PiBIZWxsbyBldmVyeWJvZHksDQo+Pj4NCj4+PiBPbiAyMDE5LzAzLzE0IDAyOjEzLCBN YXJ5IEJhcm5lcyB3cm90ZToNCj4+Pj4gSGkgYWxsLA0KPj4+Pg0KPj4+PiBXZSBoYXZlIHVwbG9h ZGVkIGEgcHJlbGltaW5hcnkgYWdlbmRhIGZvciBESVNQQVRDSDoNCj4+Pg0KPj4+IFRoYW5rcyBm b3IgcHV0dGluZyB0aGlzIHRvZ2V0aGVyLg0KPj4+DQo+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvbWVldGluZy9tYXRlcmlhbHMvDQo+Pj4NCj4+PiBUaGlzIG1heSBiZSBqdXN0IGFu IG92ZXJzaWdodCwgYnV0IGluIGdlbmVyYWwsIEkgdmVyeSBtdWNoIHByZWZlciB0bw0KPj4+IGhh dmUgdGhlIGFnZW5kYSAoYW5kIG90aGVyLCBzaW1pbGFybHkgc2hvcnQgc3R1ZmYpIGlubGluZSBp biBteSBpbmJveC4NCj4+PiBUaGF0IHNhdmVzIG1lIChhbmQgZXZlcnlib2R5IGVsc2UpIGEgY2xp Y2sgKG9yIHR3bywgcGx1cyBzb21lIG9uLXBhZ2UNCj4+PiBzZWFyY2ggdGltZSwgdGhpcyB0aW1l KS4gT2YgY291cnNlIGl0IGNhbiBjaGFuZ2UgbGF0ZXIsIGJ1dCB3ZSBhbGwga25vdw0KPj4+IHRo YXQuDQo+Pj4NCj4+PiBUaGUgYWN0dWFsIGFnZW5kYSBpcyBhdA0KPj4+DQo+PiBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTA0L21hdGVyaWFscy9hZ2VuZGEtMTA0LWRpc3Bh dGNoLTAwLi4NCj4+DQo+Pj4gSW4gdGhlIGZ1dHVyZSwgcHJlY2lzZSBsaW5rcyB3b3VsZCBiZSBh cHByZWNpYXRlZC4NCj4+Pg0KPj4+IFRoZSBhZ2VuZGEgY3VycmVudGx5IHJlYWRzIGFzIGZvbGxv d3M6DQo+Pj4NCj4+PiAjIERyYWZ0IEFnZW5kYSBEaXNwYXRjaCBASUVURi0xMDQgLSB2MQ0KPj4+ DQo+Pj4gRElTUEFUQ0ggTWVldGluZw0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pg0KPj4+ ICMgU3RhdHVzIGFuZCBhZ2VuZGEgYmFzaCAtIENoYWlycyAoMTAgbWluKQ0KPj4+DQo+Pj4gIyBS ZWxheSBVc2VyIE1hY2hpbmUgKFJVTSkgLSBCcmlhbiBSb3NlbiAoMjAgbWluKQ0KPj4+DQo+Pj4g IyBKU09OIENvbnRhY3QgLSBCcm9uIEdvbmR3YW5hICgyMCBtaW4pDQo+Pj4NCj4+PiAjIFdlYiBQ YWNrYWdpbmcgLSBKZWZmcmV5IFlhc3NraW4gKDIwIG1pbikNCj4+Pg0KPj4+IE5vdGU6IHNlZSBE SVNQQVRDSCB3aWtpIGZvciBhZGRpdGlvbmFsIGxpbmtzIHRvIG1hdGVyaWFscw0KPj4+DQo+Pj4N Cj4+PiBBUlQgQVJFQSBNZWV0aW5nDQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+DQo+Pj4g IyBCb2ZzIGFuZCBtZWV0aW5ncyBvZiBpbnRlcmVzdCAtIEFEcyAoNSBtaW4pDQo+Pj4NCj4+PiAj IEpTT04gQ2Fub25pY2FsaXphdGlvbiBTY2hlbWUgKEpDUykgLSBBbmRlcnMgUnVuZGdyZW4gKDIw KQ0KPj4+ICAgICBEb2N1bWVudDogZHJhZnQtcnVuZGdyZW4tanNvbi1jYW5vbmljYWxpemF0aW9u LXNjaGVtZQ0KPj4+DQo+Pj4gIyBBT0INCj4+Pg0KPj4+DQo+Pj4+IFJlZ2FyZHMsDQo+Pj4+IE1h cnkuDQo+Pj4+IERJU1BBVENIIFdHIGNvLWNoYWlyDQo+Pj4+DQo+Pj4+IC0tLS0tLS0tLS0gRm9y d2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tDQo+Pj4+IEZyb206IE1hcnkgQmFybmVzIDxtYXJ5Lmll dGYuYmFybmVzQGdtYWlsLmNvbT4NCj4+Pj4gRGF0ZTogVGh1LCBNYXIgNywgMjAxOSBhdCA5OjU5 IEFNDQo+Pj4+IFN1YmplY3Q6IFRvcGljcyBmb3IgRElTUEFUQ0ggQCBJRVRGLTEwNA0KPj4+PiBU bzogRElTUEFUQ0ggPGRpc3BhdGNoQGlldGYub3JnPg0KPj4+PiBDYzogQVJUIEFEcyA8YXJ0LWFk c0BpZXRmLm9yZz4sIGRpc3BhdGNoIGNoYWlycyA8DQo+PiBkaXNwYXRjaC1jaGFpcnNAaWV0Zi5v cmc+DQo+Pj4+DQo+Pj4+DQo+Pj4+IEhpIGFsbCwNCj4+Pj4NCj4+Pj4gVGhlIHdpa2kgaGFzIGJl ZW4gdXBkYXRlZCB3aXRoIHRoZSB0b3BpY3MgdGhhdCBoYXZlIGJlZW4gYWdyZWVkIHRvIGJlDQo+ Pj4+IGRpc2N1c3NlZCBhdCBJRVRGLTEwNDoNCj4+IGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFj L2Rpc3BhdGNoL3dpa2kvV2lraVN0YXJ0DQo+Pj4+DQo+Pj4+IFRoZSBwcm9wb3NhbCBmb3IgbW92 aW5nIGZvcndhcmQgZHJhZnQtZG9sZC1wYXl0byBpcyBzdGlsbCBiZWluZw0KPj4gZGlzY3Vzc2Vk DQo+Pj4+IGFtb25nc3QgQURTL2NoYWlycyBhcyBpcyB0aGUgSlNPTiBDYW5vbmljYWxpemF0aW9u IHRoYXQgaGFkIGJlZW4NCj4+IHByb3Bvc2VkDQo+Pj4+IGFzIGEgQm9GIGluIHRoZSBTRUMgQXJl YSwgYnV0IHdhcyBub3QgYXBwcm92ZWQuDQo+Pj4+DQo+Pj4+IFdlIHdpbGwgcG9zdCBhbnkgdXBk YXRlcyB0byB0aGUgd2lraSBhbmQgd2lsbCBwb3N0IGFuIGFnZW5kYSBzaG9ydGx5Lg0KPj4+Pg0K Pj4+PiBBcyBhIHJlbWluZGVyLCBpZiB5b3UgYXJlIHN1Ym1pdHRpbmcgZHJhZnRzIGZvciBkaXNj dXNzaW9uIGluIHRoZQ0KPj4gZGlzcGF0Y2gNCj4+Pj4gd29ya2luZyBncm91cCBmb2xsb3dpbmcg dGhlIHN0YW5kYXJkIGNvbnZlbnRpb24gb2YgaW5jbHVkaW5nIHRoZSBXRw0KPj4gbmFtZSBpbg0K Pj4+PiB0aGUgZHJhZnQgbmFtZSAoaS5lLiwgZHJhZnQtPG5hbWU+LWRpc3BhdGNoLWJsYWgtYmxh aCkgIG1ha2VzIGl0ICptdWNoKg0KPj4+PiBlYXNpZXIgZm9yIG1lIGFzIGNoYWlyIHRvIG1ha2Ug c3VyZSBJIGhhdmUgdGhlIHJpZ2h0IGRvY3VtZW50cw0KPj4gaWRlbnRpZmllZA0KPj4+PiBvbiB0 aGUgd2lraSBhbmQgb24gdGhlIGFnZW5kYS4gICBUaGUgdG9vbCB3aWxsIGFsbG93IHlvdSB0byBp bmRpY2F0ZQ0KPj4gdGhhdA0KPj4+PiB0aGUgZG9jdW1lbnQgd2l0aCB0aGUgbmV3IG5hbWUgcmVw bGFjZXMgdGhlIGRvY3VtZW50IHdpdGggdGhlIG9sZCBuYW1lDQo+PiBpZg0KPj4+PiB0aGF0J3Mg YSBjb25jZXJuLg0KPj4+Pg0KPj4+PiBSZWdhcmRzLA0KPj4+PiBNYXJ5DQo+Pj4+IERJU1BBVENI IFdHIGNvLWNoYWlyDQoNCg== From nobody Wed Mar 20 07:30:49 2019 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 38A4312799B for ; Wed, 20 Mar 2019 07:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 V7nXsh1obQp8 for ; Wed, 20 Mar 2019 07:30:45 -0700 (PDT) Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) (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 6D9DE126D00 for ; Wed, 20 Mar 2019 07:30:44 -0700 (PDT) Received: by mail-lf1-x141.google.com with SMTP id d18so2077150lfn.3 for ; Wed, 20 Mar 2019 07:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=26QdEFVT05B7vDeH/h/lorBBRZP7pKWLn3zaObaWIQ4=; b=cWt4KzURZnpU2OKrcunokYIJsAXN+zLFLempEP1o3jiPQshbv3Hlzf0aeiG961S6ba OWyPFp8atJobTI9BCTLj69COuvbhv9xf0zZQTef7MSk5c2J5ljYKtGVusVaE9YtFue08 IP0hgkOOuEf9Oouwu4khN0gS2Fb387MMZ/w8W3rDFom8za6A2PnKDX56yQZUtPRHaoP/ Ddhffpdp2x80RcVXNyKKPPjDGOZvOqD5MWeOF/rgfeO1lCsv0101L6Xl73/BieD0LB/v 1m+taiF+huCBI8AU73RCt2C09UVcnViylJ/diNLAq6b5U912QJ4Zr4ra7GkrcoNNSy+f gjBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=26QdEFVT05B7vDeH/h/lorBBRZP7pKWLn3zaObaWIQ4=; b=cjhGuCgvmjiWWr0Wx2Uc1HO7kahAkTqe9kruWS8HdHVKrV7oQB4QpHUAQSOs62xIBM taHFW2L/gDat6Q5d3iIL5xhElT42tt3LD+Tj9C8CClSI2K8NEVxGNsHbohpf4fcKEbii mx9ua0qWikJq2bJEWxLuZSjit33qjZUmaF4YH0B2ykg99O3ChMovIm5kmakI9gYt9HxV RZgX1cAewUDPMVbvo7P2X+mQos55ID/m6Kd/5eyGi9XQZspHLMgw5VQazM7so3aaZqb9 qX66PNW29VRyOmQrQulMYG+ivXk6iwtodTMNlh7PNZuDGLKwP27T733fCsNQHj4XBfAA WOZA== X-Gm-Message-State: APjAAAVchg7tB/3UWqJb+sN9Hyc5U2xS/uHRbtw+/XHAhybe9c++DTWH WrUE/+7z7CTgphV0cdW+LTzc5bapWRWaf1L5xghY5Fnw X-Google-Smtp-Source: APXvYqwXghEmU2aShkrZKm4mxcsY9lkATk67dKdKv0YLZUuuqIiY5nBnor4363YE2xubFBak9mXKy1cn1xPM9l4v7c4= X-Received: by 2002:ac2:55ba:: with SMTP id y26mr6486575lfg.145.1553092242424; Wed, 20 Mar 2019 07:30:42 -0700 (PDT) MIME-Version: 1.0 References: <3c9085a4-3348-489b-8a42-545f686c017a@www.fastmail.com> <3baa9d13-400a-bdda-0eb7-2bb759c4a04b@it.aoyama.ac.jp> In-Reply-To: <3baa9d13-400a-bdda-0eb7-2bb759c4a04b@it.aoyama.ac.jp> From: Mary Barnes Date: Wed, 20 Mar 2019 09:30:30 -0500 Message-ID: To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Cc: DISPATCH Content-Type: multipart/alternative; boundary="00000000000069c6bd058487774a" Archived-At: Subject: Re: [dispatch] Fwd: DISPATCH agenda @ IETF-104 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, 20 Mar 2019 14:30:48 -0000 --00000000000069c6bd058487774a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Responses below [MB] On Tue, Mar 19, 2019 at 9:56 PM Martin J. D=C3=BCrst wrote: > Hello Mary, > > On 2019/03/20 08:06, Mary Barnes wrote: > > DISPATCH wiki is here and was posted in earlier email messages: > > https://trac.ietf.org/trac/dispatch/wiki > > Every WG has such a wiki although few use it. > > Yes indeed. In my more than 25 years of IETF involvement (on and off), > it's probably the first time I have looked at such a wiki. If other WGs > don't use it, it's difficult to get the hang of it. > [MB] Well, we've been using it in dispatch for 10 years and anytime I mention deadlines, etc., I always point to the wiki. You can google IETF and wiki and see many. And, if you're not aware there is also an IETF meeting wiki for each meeting. So, I'm surprised actually that experienced people don't know about wikis. [/MB] > > Also, if you think the wiki is important, it would be good to add a link > to the agenda. Currently, the wiki only shows which drafts are up, but > not timing or presenters. > [MB] I added it just after I sent the email yesterday. And, the agenda shows the timing, so I'm not sure the concern. [/MB] > > And it's not really about me or the other Martin, it's also about > newcomers. [MB] Given as you note below that work happens on the mailing list, I would expect newcomers interested in the WG to have at least browsed the mailing list archives. The email about the topics shows up nicely on the first screen whenlooking at the archives. [/MB] > > > It would be super easy to find the documents if authors would actually > > follow the recommendation and include -dispatch in the document name. > It's > > not clear to me why folks can't seem to follow that. You can find link= s > to > > relevant documents in the threads posted on the wiki. > > > > We actually haven't routinely sent an email when we've uploaded the > > agenda. I think I'll not bother doing that next time since I assume > > everyone knows how to find meeting materials and knows how to click lin= ks > > to find WG agendas. > > First, I don't think everybody does know all these details. And even if > they know, it's quite a few clicks. > [MB] Honestly, since the website update, I can't find a single thing without oodles of clicks. IF I don't have something book marked, I find it far easier to just google to find that right page - the new IETF homepage might be pretty for the world, but it doesn't facilitate finding stuff for those of us doing the work. [/MB] > > But what's much more important is that if you don't announce that the WG > agenda is up, nobody except you knows when to go and check out the > agenda. I think people have better ways to spend their time than > checking every day whether the agenda is up. > > Sending things such as the agenda (or at least an 'agenda is up, it's > here' signal) to the mailing list can also be seen as part of the > principle that all WG decisions are confirmed on the mailing list. > [MB] And, that I did. The fact that one of your complaints is that you had to scroll and then click is the thing I find a little strange. Usually before a meeting I go to the exact page I pointed you too, and pull down materials for each of the WGs I'm attending, so I never imagined that posting that link would be deemed a terrible inconvenience. I followed the format for agenda that Murray had been using since he became a co-chair - zero complaints ever that we didn't post an agenda nor about the format. I thought the links in the wiki for the discussion, which has links to the documents was far more useful. IN particular, DISPATCH isn't about reviewing a single document. It's about discussing topics and deciding if there's a problem there that we think needs to be solved and review a proposal on how to do that, which might or might not have a related draft or charter. I only posted the note about the agenda as a courtesy because we didn't have it fully settled by the time I updated the wiki and posted that email. You might want to bring up this point to other WG chairs as I've only seen one other WG post an agenda for this meeting (that was actually TSV Area I think). Of course, only 7 of 15 WGs have posted agendas at this time although a couple aren't meeting. If posting the content of agendas on the list is deemed a requirement in following our process, someone should probably add that to the WG chairs wiki. I used to do beautiful agendas with all the hyperlinks, etc. and not a single time did anyone ever say thanks for theoretically making their job easier. Of course, that's the IETF way - never thank someone for doing something, but always complain if they've done something you deem wrong. So, hopefully this thread provides a nice introduction for newcomers on how we interact in IETF as a whole. [/MB] > > Regards, Martin. > > > > Regards, > > Mary. > > > > On Tue, Mar 19, 2019 at 5:35 PM Martin Thomson > wrote: > > > >> I agree with Martin. I don't know how to find these documents. Where i= s > >> the wiki? > >> > >> The URL is the answer. > >> > >> On Thu, Mar 14, 2019, at 16:16, Martin J. D=C3=BCrst wrote: > >>> Hello everybody, > >>> > >>> On 2019/03/14 02:13, Mary Barnes wrote: > >>>> Hi all, > >>>> > >>>> We have uploaded a preliminary agenda for DISPATCH: > >>> > >>> Thanks for putting this together. > >>> > >>>> https://datatracker.ietf.org/meeting/materials/ > >>> > >>> This may be just an oversight, but in general, I very much prefer to > >>> have the agenda (and other, similarly short stuff) inline in my inbox= . > >>> That saves me (and everybody else) a click (or two, plus some on-page > >>> search time, this time). Of course it can change later, but we all kn= ow > >>> that. > >>> > >>> The actual agenda is at > >>> > >> > https://datatracker.ietf.org/meeting/104/materials/agenda-104-dispatch-00 > .. > >> > >>> In the future, precise links would be appreciated. > >>> > >>> The agenda currently reads as follows: > >>> > >>> # Draft Agenda Dispatch @IETF-104 - v1 > >>> > >>> DISPATCH Meeting > >>> ------------------- > >>> > >>> # Status and agenda bash - Chairs (10 min) > >>> > >>> # Relay User Machine (RUM) - Brian Rosen (20 min) > >>> > >>> # JSON Contact - Bron Gondwana (20 min) > >>> > >>> # Web Packaging - Jeffrey Yasskin (20 min) > >>> > >>> Note: see DISPATCH wiki for additional links to materials > >>> > >>> > >>> ART AREA Meeting > >>> ------------------- > >>> > >>> # Bofs and meetings of interest - ADs (5 min) > >>> > >>> # JSON Canonicalization Scheme (JCS) - Anders Rundgren (20) > >>> Document: draft-rundgren-json-canonicalization-scheme > >>> > >>> # AOB > >>> > >>> > >>>> Regards, > >>>> Mary. > >>>> DISPATCH WG co-chair > >>>> > >>>> ---------- Forwarded message --------- > >>>> From: Mary Barnes > >>>> Date: Thu, Mar 7, 2019 at 9:59 AM > >>>> Subject: Topics for DISPATCH @ IETF-104 > >>>> To: DISPATCH > >>>> Cc: ART ADs , dispatch chairs < > >> dispatch-chairs@ietf.org> > >>>> > >>>> > >>>> Hi all, > >>>> > >>>> The wiki has been updated with the topics that have been agreed to b= e > >>>> discussed at IETF-104: > >> https://trac.ietf.org/trac/dispatch/wiki/WikiStart > >>>> > >>>> The proposal for moving forward draft-dold-payto is still being > >> discussed > >>>> amongst ADS/chairs as is the JSON Canonicalization that had been > >> proposed > >>>> as a BoF in the SEC Area, but was not approved. > >>>> > >>>> We will post any updates to the wiki and will post an agenda shortly= . > >>>> > >>>> As a reminder, if you are submitting drafts for discussion in the > >> dispatch > >>>> working group following the standard convention of including the WG > >> name in > >>>> the draft name (i.e., draft--dispatch-blah-blah) makes it > *much* > >>>> easier for me as chair to make sure I have the right documents > >> identified > >>>> on the wiki and on the agenda. The tool will allow you to indicate > >> that > >>>> the document with the new name replaces the document with the old na= me > >> if > >>>> that's a concern. > >>>> > >>>> Regards, > >>>> Mary > >>>> DISPATCH WG co-chair > > --00000000000069c6bd058487774a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Responses below [MB]

On Tue, Mar 19, 2019 at 9:56 PM M= artin J. D=C3=BCrst <duerst@it= .aoyama.ac.jp> wrote:
Hello Mary,

On 2019/03/20 08:06, Mary Barnes wrote:
> DISPATCH wiki is here and was posted in earlier email messages:
> https://trac.ietf.org/trac/dispatch/wiki
> Every WG has such a wiki although few use it.

Yes indeed. In my more than 25 years of IETF involvement (on and off),
it's probably the first time I have looked at such a wiki. If other WGs=
don't use it, it's difficult to get the hang of it.
[MB] Well, we've been using it in dispatch for 10 years and anyti= me I mention deadlines, etc., I always point to the wiki.=C2=A0 =C2=A0You c= an google IETF and wiki and see many.=C2=A0 And, if you're not aware th= ere is also an IETF meeting wiki for each meeting. So, I'm surprised ac= tually that experienced people don't know about wikis.=C2=A0=C2=A0[/MB]= =C2=A0

Also, if you think the wiki is important, it would be good to add a link to the agenda. Currently, the wiki only shows which drafts are up, but
not timing or presenters.
[MB] I added it just after I= sent the email yesterday. And, the agenda shows the timing, so I'm not= sure the concern. [/MB]=C2=A0

And it's not really about me or the other Martin, it's also about n= ewcomers.
[MB] Given as you note below that work happens o= n the mailing list, I would expect newcomers interested in the WG to have a= t least browsed the mailing list archives. The email about the topics shows= up nicely on the first screen whenlooking at the archives. [/MB]=C2=A0
=C2=A0

> It would be super easy to find the documents if authors would actually=
> follow the recommendation and include -dispatch in the document name.= =C2=A0 It's
> not clear to me why folks can't seem to follow that.=C2=A0 You can= find links to
> relevant documents in the threads posted on the wiki.
>
> We actually haven't routinely sent an email when we've uploade= d the
> agenda.=C2=A0 =C2=A0I think I'll not bother doing that next time s= ince I assume
> everyone knows how to find meeting materials and knows how to click li= nks
> to find WG agendas.

First, I don't think everybody does know all these details. And even if=
they know, it's quite a few clicks.

[MB] Honestly, since the website update, I can't find a single thing w= ithout oodles of clicks.=C2=A0 IF I don't have something book marked, I= find it far easier to just google to find that right page - the new IETF h= omepage might be pretty for the world, but it doesn't facilitate findin= g stuff for those of us doing the work. [/MB]=C2=A0

But what's much more important is that if you don't announce that t= he WG
agenda is up, nobody except you knows when to go and check out the
agenda. I think people have better ways to spend their time than
checking every day whether the agenda is up.

Sending things such as the agenda (or at least an 'agenda is up, it'= ;s
here' signal) to the mailing list can also be seen as part of the
principle that all WG decisions are confirmed on the mailing list.
[MB] And, that I did. The fact that one of your complaints is = that you had to scroll and then click is the thing I find a little strange.= =C2=A0 Usually before a meeting I go to the exact page I pointed you too, a= nd pull down materials for each of the WGs I'm attending, so I never im= agined that posting that link would be deemed a terrible inconvenience.=C2= =A0 =C2=A0I followed the format for agenda that Murray had been using since= he became a co-chair - zero complaints ever that we didn't post an age= nda nor about the format.=C2=A0 I thought the links in the wiki for the dis= cussion, which has links to the documents was far more useful.=C2=A0 IN par= ticular, DISPATCH isn't about reviewing a single document. It's abo= ut discussing topics and deciding if there's a problem there that we th= ink needs to be solved and review a proposal on how to do that, which might= or might not have a related draft or charter.=C2=A0

I only posted the note about the agenda=C2=A0 as a courtesy because we d= idn't have it fully settled by the time I updated the wiki and posted t= hat email.=C2=A0 =C2=A0You might want to bring up this point to other WG ch= airs as I've only seen one other WG post an agenda for this meeting (th= at was actually TSV Area I think).=C2=A0 Of course, only 7 of 15 WGs have p= osted agendas at this time although a couple aren't meeting.=C2=A0 If p= osting the content of agendas on the list is deemed a requirement in follow= ing our process, someone should probably add that to the WG chairs wiki.=C2= =A0 =C2=A0

I used to do beautiful agendas with all= the hyperlinks, etc. and not a single time did anyone ever say thanks for = theoretically making their job easier. Of course, that's the IETF way -= never thank someone for doing something, but always complain if they'v= e done something you deem wrong.=C2=A0 So, hopefully this thread provides a= nice introduction for newcomers on how we interact in IETF as a whole.=C2= =A0 [/MB]

Regards,=C2=A0 =C2=A0Martin.


> Regards,
> Mary.
>
> On Tue, Mar 19, 2019 at 5:35 PM Martin Thomson <mt@lowentropy.net> wrote:
>
>> I agree with Martin. I don't know how to find these documents.= Where is
>> the wiki?
>>
>> The URL is the answer.
>>
>> On Thu, Mar 14, 2019, at 16:16, Martin J. D=C3=BCrst wrote:
>>> Hello everybody,
>>>
>>> On 2019/03/14 02:13, Mary Barnes wrote:
>>>> Hi all,
>>>>
>>>> We have uploaded a preliminary agenda for DISPATCH:
>>>
>>> Thanks for putting this together.
>>>
>>>> https://datatracker.ietf.org/meeting= /materials/
>>>
>>> This may be just an oversight, but in general, I very much pre= fer to
>>> have the agenda (and other, similarly short stuff) inline in m= y inbox.
>>> That saves me (and everybody else) a click (or two, plus some = on-page
>>> search time, this time). Of course it can change later, but we= all know
>>> that.
>>>
>>> The actual agenda is at
>>>
>> https://datatracke= r.ietf.org/meeting/104/materials/agenda-104-dispatch-00..
>>
>>> In the future, precise links would be appreciated.
>>>
>>> The agenda currently reads as follows:
>>>
>>> # Draft Agenda Dispatch @IETF-104 - v1
>>>
>>> DISPATCH Meeting
>>> -------------------
>>>
>>> # Status and agenda bash - Chairs (10 min)
>>>
>>> # Relay User Machine (RUM) - Brian Rosen (20 min)
>>>
>>> # JSON Contact - Bron Gondwana (20 min)
>>>
>>> # Web Packaging - Jeffrey Yasskin (20 min)
>>>
>>> Note: see DISPATCH wiki for additional links to materials
>>>
>>>
>>> ART AREA Meeting
>>> -------------------
>>>
>>> # Bofs and meetings of interest - ADs (5 min)
>>>
>>> # JSON Canonicalization Scheme (JCS) - Anders Rundgren (20) >>>=C2=A0 =C2=A0 =C2=A0Document: draft-rundgren-json-canonicalizat= ion-scheme
>>>
>>> # AOB
>>>
>>>
>>>> Regards,
>>>> Mary.
>>>> DISPATCH WG co-chair
>>>>
>>>> ---------- Forwarded message ---------
>>>> From: Mary Barnes <mary.ietf.barnes@gmail.com>
>>>> Date: Thu, Mar 7, 2019 at 9:59 AM
>>>> Subject: Topics for DISPATCH @ IETF-104
>>>> To: DISPATCH <dispatch@ietf.org>
>>>> Cc: ART ADs <art-ads@ietf.org>, dispatch chairs <
>> disp= atch-chairs@ietf.org>
>>>>
>>>>
>>>> Hi all,
>>>>
>>>> The wiki has been updated with the topics that have been a= greed to be
>>>> discussed at IETF-104:
>> https://trac.ietf.org/trac/dispatch/wiki/= WikiStart
>>>>
>>>> The proposal for moving forward draft-dold-payto is still = being
>> discussed
>>>> amongst ADS/chairs as is the JSON Canonicalization that ha= d been
>> proposed
>>>> as a BoF in the SEC Area, but was not approved.
>>>>
>>>> We will post any updates to the wiki and will post an agen= da shortly.
>>>>
>>>> As a reminder, if you are submitting drafts for discussion= in the
>> dispatch
>>>> working group following the standard convention of includi= ng the WG
>> name in
>>>> the draft name (i.e., draft-<name>-dispatch-blah-bla= h)=C2=A0 makes it *much*
>>>> easier for me as chair to make sure I have the right docum= ents
>> identified
>>>> on the wiki and on the agenda.=C2=A0 =C2=A0The tool will a= llow you to indicate
>> that
>>>> the document with the new name replaces the document with = the old name
>> if
>>>> that's a concern.
>>>>
>>>> Regards,
>>>> Mary
>>>> DISPATCH WG co-chair

--00000000000069c6bd058487774a-- From nobody Thu Mar 21 08:00:41 2019 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 55A951311E3 for ; Thu, 21 Mar 2019 08:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxWvGcwzJexQ for ; Thu, 21 Mar 2019 08:00:37 -0700 (PDT) Received: from smtp122.iad3a.emailsrvr.com (smtp122.iad3a.emailsrvr.com [173.203.187.122]) (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 F3D10130FCF for ; Thu, 21 Mar 2019 08:00:36 -0700 (PDT) Received: from smtp24.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp24.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id E43D724AF6; Thu, 21 Mar 2019 11:00:35 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp24.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 83D5424B90; Thu, 21 Mar 2019 11:00:35 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Thu, 21 Mar 2019 11:00:35 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Cullen Jennings In-Reply-To: <3c9085a4-3348-489b-8a42-545f686c017a@www.fastmail.com> Date: Thu, 21 Mar 2019 09:00:34 -0600 Cc: dispatch@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <892FDB9A-DC09-44BB-A540-61727F581C71@iii.ca> References: <3c9085a4-3348-489b-8a42-545f686c017a@www.fastmail.com> To: Martin Thomson X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [dispatch] DISPATCH agenda @ IETF-104 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, 21 Mar 2019 15:00:40 -0000 I=E2=80=99m reading this on a plane and don=E2=80=99t have access to the = WIKI, and 10 years from now when I am trying to find prior are for a = patent trial, all the content of the Wiki will not be archived.=20 > On Mar 19, 2019, at 4:35 PM, Martin Thomson wrote: >=20 > I agree with Martin. I don't know how to find these documents. Where = is the wiki? >=20 > The URL is the answer. >=20 > On Thu, Mar 14, 2019, at 16:16, Martin J. D=C3=BCrst wrote: >> Hello everybody, >>=20 >> On 2019/03/14 02:13, Mary Barnes wrote: >>> Hi all, >>>=20 >>> We have uploaded a preliminary agenda for DISPATCH: >>=20 >> Thanks for putting this together. >>=20 >>> https://datatracker.ietf.org/meeting/materials/ >>=20 >> This may be just an oversight, but in general, I very much prefer to=20= >> have the agenda (and other, similarly short stuff) inline in my = inbox.=20 >> That saves me (and everybody else) a click (or two, plus some on-page=20= >> search time, this time). Of course it can change later, but we all = know=20 >> that. >>=20 >> The actual agenda is at >> = https://datatracker.ietf.org/meeting/104/materials/agenda-104-dispatch-00.= =20 >> In the future, precise links would be appreciated. >>=20 >> The agenda currently reads as follows: >>=20 >> # Draft Agenda Dispatch @IETF-104 - v1 >>=20 >> DISPATCH Meeting >> ------------------- >>=20 >> # Status and agenda bash - Chairs (10 min) >>=20 >> # Relay User Machine (RUM) - Brian Rosen (20 min) >>=20 >> # JSON Contact - Bron Gondwana (20 min) >>=20 >> # Web Packaging - Jeffrey Yasskin (20 min) >>=20 >> Note: see DISPATCH wiki for additional links to materials >>=20 >>=20 >> ART AREA Meeting >> ------------------- >>=20 >> # Bofs and meetings of interest - ADs (5 min) >>=20 >> # JSON Canonicalization Scheme (JCS) - Anders Rundgren (20) >> Document: draft-rundgren-json-canonicalization-scheme >>=20 >> # AOB >>=20 >>=20 >>> Regards, >>> Mary. >>> DISPATCH WG co-chair >>>=20 >>> ---------- Forwarded message --------- >>> From: Mary Barnes >>> Date: Thu, Mar 7, 2019 at 9:59 AM >>> Subject: Topics for DISPATCH @ IETF-104 >>> To: DISPATCH >>> Cc: ART ADs , dispatch chairs = >>>=20 >>>=20 >>> Hi all, >>>=20 >>> The wiki has been updated with the topics that have been agreed to = be >>> discussed at IETF-104: = https://trac.ietf.org/trac/dispatch/wiki/WikiStart >>>=20 >>> The proposal for moving forward draft-dold-payto is still being = discussed >>> amongst ADS/chairs as is the JSON Canonicalization that had been = proposed >>> as a BoF in the SEC Area, but was not approved. >>>=20 >>> We will post any updates to the wiki and will post an agenda = shortly. >>>=20 >>> As a reminder, if you are submitting drafts for discussion in the = dispatch >>> working group following the standard convention of including the WG = name in >>> the draft name (i.e., draft--dispatch-blah-blah) makes it = *much* >>> easier for me as chair to make sure I have the right documents = identified >>> on the wiki and on the agenda. The tool will allow you to indicate = that >>> the document with the new name replaces the document with the old = name if >>> that's a concern. >>>=20 >>> Regards, >>> Mary >>> DISPATCH WG co-chair >>>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Mar 21 08:18:50 2019 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 ABF3F1312C6 for ; Thu, 21 Mar 2019 08:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-FRNp9si82q for ; Thu, 21 Mar 2019 08:18:34 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 424FD1312A9 for ; Thu, 21 Mar 2019 08:18:29 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id y18so4901474lfe.1 for ; Thu, 21 Mar 2019 08:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7ssfPMRtGQNyhLmdTdU68nC787bwf7cX0Tv+s0EB2DA=; b=DJEHlnqgVIWfW+0ozV2rpMuof1KH6y0qR+0b3yet0UKMGzBebrPOGDz3bCk/gcewU7 IDyv/0PyPONkOlcAEZLJ0YCWnvogs2iUNDllJvk5rnAD+T7L4vXgkoEwKA9kA7Pi84xB sK2xxz2uRDf2+Ng3TS8FH58oiDV/L/1xXg5Dj6NqRwmIjLaHeBqt8De03T5dwWCodgXh gnsMGKgpiJwIbcKJzcORQRkWaT0WifhXkKM4NKLzB+rC6m5FmFa58sRPEM0FZYE3Xz45 Y/tsfsgMSjZSl87dh20/EtKqH3uGXrq1PSApzEksUqXvHGb0zUSo7jZtYZsx42LbOdbO TaRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7ssfPMRtGQNyhLmdTdU68nC787bwf7cX0Tv+s0EB2DA=; b=P7sHLS6aC6z3jtoGHIfiJvaaEwf2kNAkYIskBi+oV5uuRu9oMHM/qGppwESuSZ5WZ3 O33TkiVb0lGGB+UvJz05stBykTXpZphuVr3gfkPmMvSYuJOMDk01z9UYiEYN4vmgtpxS GPA0zYtpaoL8Wn0KnNXxJIFSgiqgyWQ5ATRrG6JHR2xlEEf6a6zo+KFBlP2xT9JmmpYe 2DDoYt6qrtwgm/I61uUebevE4bw3bXBQJ/AEDtD8MKjdnrP5LWGIcDSh7oBvbyubqYY7 3S8ZyPvgnwO9XULY0a53zuvGsn7hfaSakuJG7IK+25Jws3PVQgfEJbNgq5qNrJmH5i6d NDeg== X-Gm-Message-State: APjAAAUmk0HV+bBxznLSJBXX6EDY8CBVHhXKXZgDHHhekvTof5IlV5Pi XCc8lxXKu8cynzsrrIdBSaVpjIzNMH6gE29ILDnFLQ== X-Google-Smtp-Source: APXvYqymKZ9CAKNcN9KylHg+ZSM8T5PmsGzRZNHqXkd3aAM+jmj7I+DuyBOEbX7S9zuNucysMrEgad7BRPfSFT1cjJw= X-Received: by 2002:a19:a40b:: with SMTP id q11mr2356175lfc.33.1553181507393; Thu, 21 Mar 2019 08:18:27 -0700 (PDT) MIME-Version: 1.0 References: <3c9085a4-3348-489b-8a42-545f686c017a@www.fastmail.com> <892FDB9A-DC09-44BB-A540-61727F581C71@iii.ca> In-Reply-To: <892FDB9A-DC09-44BB-A540-61727F581C71@iii.ca> From: Mary Barnes Date: Thu, 21 Mar 2019 10:18:15 -0500 Message-ID: To: Cullen Jennings Cc: Martin Thomson , DISPATCH Content-Type: multipart/alternative; boundary="000000000000051c3205849c407c" Archived-At: Subject: Re: [dispatch] DISPATCH agenda @ IETF-104 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, 21 Mar 2019 15:18:45 -0000 --000000000000051c3205849c407c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So, where do you propose we store all this information for archival? This really comes down to an earlier discussion on one of the other general lists that a lot of history is lost. That wiki is the history of what happened to all the work items since we started DISPATCH. Yes, we have minutes, etc. but that doesn't give you the complete picture as a lot of things happen actually NOT on public lists - e.g., the AD sponsored documents go off and discussions are between AD and authors, when WGs are chartered, there's a lot of out of band discussion, etc. Do you propose that all those discussions happen on the mailing list for archival? Can we add a page to the datatracker for each WG so that we can store information like this? The only other thing I can think of is that we just post it periodically on the mailing list if you want guaranteed archival. Regards, Mary. On Thu, Mar 21, 2019 at 10:00 AM Cullen Jennings wrote: > > I=E2=80=99m reading this on a plane and don=E2=80=99t have access to the = WIKI, and 10 > years from now when I am trying to find prior are for a patent trial, all > the content of the Wiki will not be archived. > > > > On Mar 19, 2019, at 4:35 PM, Martin Thomson wrote: > > > > I agree with Martin. I don't know how to find these documents. Where is > the wiki? > > > > The URL is the answer. > > > > On Thu, Mar 14, 2019, at 16:16, Martin J. D=C3=BCrst wrote: > >> Hello everybody, > >> > >> On 2019/03/14 02:13, Mary Barnes wrote: > >>> Hi all, > >>> > >>> We have uploaded a preliminary agenda for DISPATCH: > >> > >> Thanks for putting this together. > >> > >>> https://datatracker.ietf.org/meeting/materials/ > >> > >> This may be just an oversight, but in general, I very much prefer to > >> have the agenda (and other, similarly short stuff) inline in my inbox. > >> That saves me (and everybody else) a click (or two, plus some on-page > >> search time, this time). Of course it can change later, but we all kno= w > >> that. > >> > >> The actual agenda is at > >> > https://datatracker.ietf.org/meeting/104/materials/agenda-104-dispatch-00= . > > >> In the future, precise links would be appreciated. > >> > >> The agenda currently reads as follows: > >> > >> # Draft Agenda Dispatch @IETF-104 - v1 > >> > >> DISPATCH Meeting > >> ------------------- > >> > >> # Status and agenda bash - Chairs (10 min) > >> > >> # Relay User Machine (RUM) - Brian Rosen (20 min) > >> > >> # JSON Contact - Bron Gondwana (20 min) > >> > >> # Web Packaging - Jeffrey Yasskin (20 min) > >> > >> Note: see DISPATCH wiki for additional links to materials > >> > >> > >> ART AREA Meeting > >> ------------------- > >> > >> # Bofs and meetings of interest - ADs (5 min) > >> > >> # JSON Canonicalization Scheme (JCS) - Anders Rundgren (20) > >> Document: draft-rundgren-json-canonicalization-scheme > >> > >> # AOB > >> > >> > >>> Regards, > >>> Mary. > >>> DISPATCH WG co-chair > >>> > >>> ---------- Forwarded message --------- > >>> From: Mary Barnes > >>> Date: Thu, Mar 7, 2019 at 9:59 AM > >>> Subject: Topics for DISPATCH @ IETF-104 > >>> To: DISPATCH > >>> Cc: ART ADs , dispatch chairs < > dispatch-chairs@ietf.org> > >>> > >>> > >>> Hi all, > >>> > >>> The wiki has been updated with the topics that have been agreed to be > >>> discussed at IETF-104: > https://trac.ietf.org/trac/dispatch/wiki/WikiStart > >>> > >>> The proposal for moving forward draft-dold-payto is still being > discussed > >>> amongst ADS/chairs as is the JSON Canonicalization that had been > proposed > >>> as a BoF in the SEC Area, but was not approved. > >>> > >>> We will post any updates to the wiki and will post an agenda shortly. > >>> > >>> As a reminder, if you are submitting drafts for discussion in the > dispatch > >>> working group following the standard convention of including the WG > name in > >>> the draft name (i.e., draft--dispatch-blah-blah) makes it *muc= h* > >>> easier for me as chair to make sure I have the right documents > identified > >>> on the wiki and on the agenda. The tool will allow you to indicate > that > >>> the document with the new name replaces the document with the old nam= e > if > >>> that's a concern. > >>> > >>> Regards, > >>> Mary > >>> DISPATCH WG co-chair > >>> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > >> > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --000000000000051c3205849c407c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So, where do you propose we store all this information for= archival?

This really comes down to an earlier discussi= on on one of the other general lists that a lot of history is lost.=C2=A0 T= hat wiki is the history of what happened to all the work items since we sta= rted DISPATCH.=C2=A0 Yes, we have minutes, etc. but that doesn't give y= ou the complete picture as a lot of things happen actually NOT on public li= sts - e.g., the AD sponsored documents go off and discussions are between A= D and authors, when WGs are chartered, there's a lot of out of band dis= cussion, etc.=C2=A0 =C2=A0Do you propose that all those discussions happen = on the mailing list for archival?=C2=A0

Can we add= a page to the datatracker for each WG so that we can store information lik= e this?=C2=A0 =C2=A0The only other thing I can think of is that we just pos= t it periodically on the mailing list if you want guaranteed archival.=C2= =A0=C2=A0

Regards,
Mary.

=
On Thu, Ma= r 21, 2019 at 10:00 AM Cullen Jennings <fluffy@iii.ca> wrote:

I=E2=80=99m reading this on a plane and don=E2=80=99t have access to the WI= KI, and 10 years from now when I am trying to find prior are for a patent t= rial, all the content of the Wiki will not be archived.


> On Mar 19, 2019, at 4:35 PM, Martin Thomson <mt@lowentropy.net> wrote:
>
> I agree with Martin. I don't know how to find these documents. Whe= re is the wiki?
>
> The URL is the answer.
>
> On Thu, Mar 14, 2019, at 16:16, Martin J. D=C3=BCrst wrote:
>> Hello everybody,
>>
>> On 2019/03/14 02:13, Mary Barnes wrote:
>>> Hi all,
>>>
>>> We have uploaded a preliminary agenda for DISPATCH:
>>
>> Thanks for putting this together.
>>
>>> https://datatracker.ietf.org/meeting/mat= erials/
>>
>> This may be just an oversight, but in general, I very much prefer = to
>> have the agenda (and other, similarly short stuff) inline in my in= box.
>> That saves me (and everybody else) a click (or two, plus some on-p= age
>> search time, this time). Of course it can change later, but we all= know
>> that.
>>
>> The actual agenda is at
>> https://datatracke= r.ietf.org/meeting/104/materials/agenda-104-dispatch-00.
>> In the future, precise links would be appreciated.
>>
>> The agenda currently reads as follows:
>>
>> # Draft Agenda Dispatch @IETF-104 - v1
>>
>> DISPATCH Meeting
>> -------------------
>>
>> # Status and agenda bash - Chairs (10 min)
>>
>> # Relay User Machine (RUM) - Brian Rosen (20 min)
>>
>> # JSON Contact - Bron Gondwana (20 min)
>>
>> # Web Packaging - Jeffrey Yasskin (20 min)
>>
>> Note: see DISPATCH wiki for additional links to materials
>>
>>
>> ART AREA Meeting
>> -------------------
>>
>> # Bofs and meetings of interest - ADs (5 min)
>>
>> # JSON Canonicalization Scheme (JCS) - Anders Rundgren (20)
>>=C2=A0 =C2=A0Document: draft-rundgren-json-canonicalization-scheme<= br> >>
>> # AOB
>>
>>
>>> Regards,
>>> Mary.
>>> DISPATCH WG co-chair
>>>
>>> ---------- Forwarded message ---------
>>> From: Mary Barnes <mary.ietf.barnes@gmail.com>
>>> Date: Thu, Mar 7, 2019 at 9:59 AM
>>> Subject: Topics for DISPATCH @ IETF-104
>>> To: DISPATCH <dispatch@ietf.org>
>>> Cc: ART ADs <art-ads@ietf.org>, dispatch chairs <dispatch-chairs@ietf.org> >>>
>>>
>>> Hi all,
>>>
>>> The wiki has been updated with the topics that have been agree= d to be
>>> discussed at IETF-104:=C2=A0 https://= trac.ietf.org/trac/dispatch/wiki/WikiStart
>>>
>>> The proposal for moving forward draft-dold-payto is still bein= g discussed
>>> amongst ADS/chairs as is the JSON Canonicalization that had be= en proposed
>>> as a BoF in the SEC Area, but was not approved.
>>>
>>> We will post any updates to the wiki and will post an agenda s= hortly.
>>>
>>> As a reminder, if you are submitting drafts for discussion in = the dispatch
>>> working group following the standard convention of including t= he WG name in
>>> the draft name (i.e., draft-<name>-dispatch-blah-blah)= =C2=A0 makes it *much*
>>> easier for me as chair to make sure I have the right documents= identified
>>> on the wiki and on the agenda.=C2=A0 =C2=A0The tool will allow= you to indicate that
>>> the document with the new name replaces the document with the = old name if
>>> that's a concern.
>>>
>>> Regards,
>>> Mary
>>> DISPATCH WG co-chair
>>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ie= tf.org
>> https://www.ietf.org/mailman/listinfo/dispatc= h
>>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--000000000000051c3205849c407c-- From nobody Thu Mar 21 08:44:37 2019 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 1A0D81312D8 for ; Thu, 21 Mar 2019 08:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=kuPJpwI6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QS3TPguy 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 BTOJycxUoDsX for ; Thu, 21 Mar 2019 08:44:33 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4C341312EB for ; Thu, 21 Mar 2019 08:44:30 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id C2EEB466E; Thu, 21 Mar 2019 11:44:29 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 21 Mar 2019 11:44:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm1; bh=OS EwgjyPWd6P9JIGFIpalMnuYon2BSQQ8MqCrhtcDSA=; b=kuPJpwI6iel1kKFlGP p1BMfLU+lsFRsYQFvYCSfSulsIIg8RiVbOucwB1BkD685gzwRIiyvlUnCbXhYy5p nApTJiAI7/4fKBmIv1Tcddn1lAREafQb+KYyjA0gN6lOLW8rj+8jbtHf8cPq6RND BAil+p7FhLsfBluYNM6jySahFIPSEmS94TRQpdM5SgR6WYz+DLJUCF+4TcW3rx6z fgUo7THbto20bFBkRP2w+UF6HdWVAGLpWRrbOh14bxbN/8KlOaI4wY4goF4q8r+Q SZsVkNvVSHK0W/bgumVL9rLav+vz/qvjiWdpdWaIpvdYxvWxgykr46GsARM3u0qM zClQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=OSEwgjyPWd6P9JIGFIpalMnuYon2BSQQ8MqCrhtcD SA=; b=QS3TPguyTq9YReo2tESBW/DCG1lHt+Z5LIr+v84Oc+/yZhfWX6FAee3+P KrGwnEe3JgnYyaqvKqnPcsZ+iA+tTJCGN4uaX4kydRRDy9CFktw89EaRF0XMtOlu 0+1YwbA+ypXVRsm/P9equZhW/FwiF7VMQznlJ7ZMOtYCRnGLZmutMYSgXjQE+1zl iNlBLvsBN7u9ZKj/a366mIkHpyp4sID4s041310rg0zeoXTFCuLrZ2GV+GbMRGSA eM7mOREPaSuV0abAMQVXq8dDW8g4FyVMNeKxQJMsg2CwNAZD/wheMnWGGVE//qE+ GLcSU6WeP9mqTLSDizpp5Ul7N0w7Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrieelgdeihecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecuff homhgrihhnpehivghtfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehl ohifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id CE2727C1B9; Thu, 21 Mar 2019 11:44:28 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-976-g376b1f3-fmstable-20190314v3 Mime-Version: 1.0 X-Me-Personality: 92534000 Message-Id: In-Reply-To: References: <3c9085a4-3348-489b-8a42-545f686c017a@www.fastmail.com> <892FDB9A-DC09-44BB-A540-61727F581C71@iii.ca> Date: Thu, 21 Mar 2019 11:44:29 -0400 From: "Martin Thomson" To: "Mary Barnes" , "Cullen Jennings" Cc: DISPATCH Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dispatch] DISPATCH agenda @ IETF-104 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, 21 Mar 2019 15:44:36 -0000 Cullen's points are valid here, but I was making a simple request for co= urtesy and respect. If the critical information is in an email, it is more readily available= . That's a tiny bit more work to provide, but a great help to people lo= oking to prepare for the meeting. The TLS agenda, for example, was very= helpful. For instance, I had real trouble finding Bron's post until I went to the= wiki. I started to look for a draft, draft-gondwana-*, draft-*-jmap-*,= draft-jenkins-*, no luck. I searched my mail for emails, I got none bec= ause the email had a misspelled title, and the journey to find the wiki = on a phone is distressingly long and the site agonizingly slow. The dir= ect link, once I had it, was fine, of course. None of this is terribly hard to deal with, but it's a bit of burden. I= t's possible that it is harder for me because I have inbuilt expectation= s about how people present their ideas. I wonder if there is a tools enhancement we might have: the ability to b= uild an agenda based on drafts (and uploaded slides). Manually building= all that stuff only takes 10 minutes, but I'll bet that it could be cut= down to 2 minutes for most groups, and produce a more usable product. --Martin p.s., I don't think anyone was asking you not to use the wiki. Though C= ullen is right that all the stuff that happens out of sight without a go= od record is not good. On Fri, Mar 22, 2019, at 02:18, Mary Barnes wrote: > So, where do you propose we store all this information for archival? >=20 > This really comes down to an earlier discussion on one of the other=20= > general lists that a lot of history is lost. That wiki is the history=20= > of what happened to all the work items since we started DISPATCH. Yes,= =20 > we have minutes, etc. but that doesn't give you the complete picture a= s=20 > a lot of things happen actually NOT on public lists - e.g., the AD=20 > sponsored documents go off and discussions are between AD and authors,= =20 > when WGs are chartered, there's a lot of out of band discussion, etc.=20= > Do you propose that all those discussions happen on the mailing list=20= > for archival?=20 >=20 > Can we add a page to the datatracker for each WG so that we can store=20= > information like this? The only other thing I can think of is that we=20= > just post it periodically on the mailing list if you want guaranteed=20= > archival.=20 >=20 > Regards, > Mary. >=20 > On Thu, Mar 21, 2019 at 10:00 AM Cullen Jennings wrote= : > >=20 > > I=E2=80=99m reading this on a plane and don=E2=80=99t have access t= o the WIKI, and 10 years from now when I am trying to find prior are for= a patent trial, all the content of the Wiki will not be archived.=20 > >=20 > >=20 > > > On Mar 19, 2019, at 4:35 PM, Martin Thomson w= rote: > > >=20 > > > I agree with Martin. I don't know how to find these documents. Wh= ere is the wiki? > > >=20 > > > The URL is the answer. > > >=20 > > > On Thu, Mar 14, 2019, at 16:16, Martin J. D=C3=BCrst wrote: > > >> Hello everybody, > > >>=20 > > >> On 2019/03/14 02:13, Mary Barnes wrote: > > >>> Hi all, > > >>>=20 > > >>> We have uploaded a preliminary agenda for DISPATCH: > > >>=20 > > >> Thanks for putting this together. > > >>=20 > > >>> https://datatracker.ietf.org/meeting/materials/ > > >>=20 > > >> This may be just an oversight, but in general, I very much prefe= r to=20 > > >> have the agenda (and other, similarly short stuff) inline in my = inbox.=20 > > >> That saves me (and everybody else) a click (or two, plus some on= -page=20 > > >> search time, this time). Of course it can change later, but we a= ll know=20 > > >> that. > > >>=20 > > >> The actual agenda is at > > >> https://datatracker.ietf.org/meeting/104/materials/agenda-104-di= spatch-00.=20 > > >> In the future, precise links would be appreciated. > > >>=20 > > >> The agenda currently reads as follows: > > >>=20 > > >> # Draft Agenda Dispatch @IETF-104 - v1 > > >>=20 > > >> DISPATCH Meeting > > >> ------------------- > > >>=20 > > >> # Status and agenda bash - Chairs (10 min) > > >>=20 > > >> # Relay User Machine (RUM) - Brian Rosen (20 min) > > >>=20 > > >> # JSON Contact - Bron Gondwana (20 min) > > >>=20 > > >> # Web Packaging - Jeffrey Yasskin (20 min) > > >>=20 > > >> Note: see DISPATCH wiki for additional links to materials > > >>=20 > > >>=20 > > >> ART AREA Meeting > > >> ------------------- > > >>=20 > > >> # Bofs and meetings of interest - ADs (5 min) > > >>=20 > > >> # JSON Canonicalization Scheme (JCS) - Anders Rundgren (20) > > >> Document: draft-rundgren-json-canonicalization-scheme > > >>=20 > > >> # AOB > > >>=20 > > >>=20 > > >>> Regards, > > >>> Mary. > > >>> DISPATCH WG co-chair > > >>>=20 > > >>> ---------- Forwarded message --------- > > >>> From: Mary Barnes > > >>> Date: Thu, Mar 7, 2019 at 9:59 AM > > >>> Subject: Topics for DISPATCH @ IETF-104 > > >>> To: DISPATCH > > >>> Cc: ART ADs , dispatch chairs > > >>>=20 > > >>>=20 > > >>> Hi all, > > >>>=20 > > >>> The wiki has been updated with the topics that have been agreed= to be > > >>> discussed at IETF-104: https://trac.ietf.org/trac/dispatch/wiki= /WikiStart > > >>>=20 > > >>> The proposal for moving forward draft-dold-payto is still being= discussed > > >>> amongst ADS/chairs as is the JSON Canonicalization that had bee= n proposed > > >>> as a BoF in the SEC Area, but was not approved. > > >>>=20 > > >>> We will post any updates to the wiki and will post an agenda sh= ortly. > > >>>=20 > > >>> As a reminder, if you are submitting drafts for discussion in t= he dispatch > > >>> working group following the standard convention of including th= e WG name in > > >>> the draft name (i.e., draft--dispatch-blah-blah) makes it= *much* > > >>> easier for me as chair to make sure I have the right documents = identified > > >>> on the wiki and on the agenda. The tool will allow you to indic= ate that > > >>> the document with the new name replaces the document with the o= ld name if > > >>> that's a concern. > > >>>=20 > > >>> Regards, > > >>> Mary > > >>> DISPATCH WG co-chair > > >>>=20 > > >> _______________________________________________ > > >> dispatch mailing list > > >> dispatch@ietf.org > > >> https://www.ietf.org/mailman/listinfo/dispatch > > >>=20 > > >=20 > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > >=20 > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Mar 21 09:15:25 2019 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 E138B1313BF for ; Thu, 21 Mar 2019 09:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTm-Mh_N3efy for ; Thu, 21 Mar 2019 09:15:20 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 E3D361313C7 for ; Thu, 21 Mar 2019 09:15:13 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id f18so5660242lja.10 for ; Thu, 21 Mar 2019 09:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=38DEiMC64nH9LsuzuScJ3puQS7WxLrq4+fGsLxweBUg=; b=n8FH67QVwy4wePsREslDBkkQXa8VzZAESePrb2NvAIFDcU0KlYNUeTEYUa+cwZqHG4 KhxsVqaMaMwXXytj4n4U7XK+z8Dud85hFMPxueFVjxkkYuL/RJss2gjwGM4ojbHeb2MF JErMVtHEjD9yTuOkgrMh1tQJ5sb0oSPpPGoLOuAgSWViflW654ZNMfkTGmV41DfMmrXS UfdTU9rUwQ7Se9uN9EW48quImEFQrFmDP4zdav1hxud32fF4w+FqsaGCwoOXVKh8R16P HX/nG8Ot2MyagqQhlh2dHrW0a3Wa+sSMrvD799AVQB5Rampk2EXUFpIeO+OZnN1v1GS3 KmbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=38DEiMC64nH9LsuzuScJ3puQS7WxLrq4+fGsLxweBUg=; b=htYQn0YfN+scTvILzghyhg6Zy44NI84RdFLMI5KiYKEoP2jxG6THYr6dELel/4Qzf0 ijyuRa28sP5RXPmodXsVxd+Gr4NiEsrT8p+V3Mryr9y96v+ay7GMCkV2RDOFRIKUXaBv Z3LY67LzHwyG+onpibH261x4KwhSM9dP8uEeilB/+7no4pxVPMha5TKtj3my+ZeteCDu yHTHzZtyAs5XepZ7gdGj99lRJohmMySySpwjA/KD3mq+d+cOun5mBue/ZNMG2/ewrE95 n4jVtWkS6lb2TPOlkZBJVvWtns5gYTxkEOMTAZDStBevO9i8CG5SFTAqOdtZDsrpUnK3 l9RQ== X-Gm-Message-State: APjAAAXa84vo7cBBN4A5CXiWlEjTfPlAYuLbSIcz/Q4p08zJg5aBhDw4 Cenyn4+Ad0hc5ThhpO8zMidZJDlYgJfWD4QmVMs= X-Google-Smtp-Source: APXvYqxwZlhYgSyiBT4L9JOz5uRnMeHCiKGd/UOIzd6MKWo066dohRX2Y6nP4c3szUo09Y6RnG/8fSRg/wP/THst5DA= X-Received: by 2002:a2e:810d:: with SMTP id d13mr2560563ljg.1.1553184911816; Thu, 21 Mar 2019 09:15:11 -0700 (PDT) MIME-Version: 1.0 References: <3c9085a4-3348-489b-8a42-545f686c017a@www.fastmail.com> <892FDB9A-DC09-44BB-A540-61727F581C71@iii.ca> In-Reply-To: From: Mary Barnes Date: Thu, 21 Mar 2019 11:14:59 -0500 Message-ID: To: Martin Thomson Cc: Cullen Jennings , DISPATCH Content-Type: multipart/alternative; boundary="000000000000f07e7f05849d0a3e" Archived-At: Subject: Re: [dispatch] DISPATCH agenda @ IETF-104 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, 21 Mar 2019 16:15:24 -0000 --000000000000f07e7f05849d0a3e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm not debating some of your points, which are very good when it comes to building an agenda. If I post the agenda ahead of time, next time I will include a link to the wiki and just cut and paste from there into the body of the email. While your time estimate on the agenda is probably about right, it takes me much longer than that to go dig up threads and figure out what documents we are talking about and make sure I'm not missing anything. And, I have the same problem finding drafts, as well, which is why I'm suggesting the -dispatch so they'll easily show up on the WG page - that lets me double check I haven't missed anything. Per discussion yesterday, it's not clear that the contributors/authors can indicate replaces for their own drafts. That may be a chair only option? In which case, I think there is the need for a tool enhancement. And the same with having the ability to have a wiki in the datatracker as opposed to tools page. The latter brings up another question for Cullen as to whether earlier versions of drafts that have never been adopted, and thus fall out of the datatracker when they expire, are relevant? I would think absolutely so as they document prior art. But, I honestly don't know the official status of the tools pages when it comes to the legal aspects. So, that is a general question - if we answer it for the drafts, then it should equally apply to the wiki. As an aside, the datatracker does point to the Tools page for each WG and once there, it's one click to get to a wiki. So, I don't think it's super hidden. And, of course, this whole discussion is more general. Per my email yesterday it gets into tracking/documenting history in general, which also relates to Cullen's point. Although, it's a very curious one to be having in the DISPATCH WG since it's been around for 10 years. Regards, Mary. On Thu, Mar 21, 2019 at 10:44 AM Martin Thomson wrote: > Cullen's points are valid here, but I was making a simple request for > courtesy and respect. > > If the critical information is in an email, it is more readily available. > That's a tiny bit more work to provide, but a great help to people lookin= g > to prepare for the meeting. The TLS agenda, for example, was very helpfu= l. > > For instance, I had real trouble finding Bron's post until I went to the > wiki. I started to look for a draft, draft-gondwana-*, draft-*-jmap-*, > draft-jenkins-*, no luck. I searched my mail for emails, I got none becau= se > the email had a misspelled title, and the journey to find the wiki on a > phone is distressingly long and the site agonizingly slow. The direct > link, once I had it, was fine, of course. > > None of this is terribly hard to deal with, but it's a bit of burden. > It's possible that it is harder for me because I have inbuilt expectation= s > about how people present their ideas. > > I wonder if there is a tools enhancement we might have: the ability to > build an agenda based on drafts (and uploaded slides). Manually building > all that stuff only takes 10 minutes, but I'll bet that it could be cut > down to 2 minutes for most groups, and produce a more usable product. > > --Martin > > p.s., I don't think anyone was asking you not to use the wiki. Though > Cullen is right that all the stuff that happens out of sight without a go= od > record is not good. > > On Fri, Mar 22, 2019, at 02:18, Mary Barnes wrote: > > So, where do you propose we store all this information for archival? > > > > This really comes down to an earlier discussion on one of the other > > general lists that a lot of history is lost. That wiki is the history > > of what happened to all the work items since we started DISPATCH. Yes, > > we have minutes, etc. but that doesn't give you the complete picture as > > a lot of things happen actually NOT on public lists - e.g., the AD > > sponsored documents go off and discussions are between AD and authors, > > when WGs are chartered, there's a lot of out of band discussion, etc. > > Do you propose that all those discussions happen on the mailing list > > for archival? > > > > Can we add a page to the datatracker for each WG so that we can store > > information like this? The only other thing I can think of is that we > > just post it periodically on the mailing list if you want guaranteed > > archival. > > > > Regards, > > Mary. > > > > On Thu, Mar 21, 2019 at 10:00 AM Cullen Jennings wrote: > > > > > > I=E2=80=99m reading this on a plane and don=E2=80=99t have access to= the WIKI, and 10 > years from now when I am trying to find prior are for a patent trial, all > the content of the Wiki will not be archived. > > > > > > > > > > On Mar 19, 2019, at 4:35 PM, Martin Thomson > wrote: > > > > > > > > I agree with Martin. I don't know how to find these documents. > Where is the wiki? > > > > > > > > The URL is the answer. > > > > > > > > On Thu, Mar 14, 2019, at 16:16, Martin J. D=C3=BCrst wrote: > > > >> Hello everybody, > > > >> > > > >> On 2019/03/14 02:13, Mary Barnes wrote: > > > >>> Hi all, > > > >>> > > > >>> We have uploaded a preliminary agenda for DISPATCH: > > > >> > > > >> Thanks for putting this together. > > > >> > > > >>> https://datatracker.ietf.org/meeting/materials/ > > > >> > > > >> This may be just an oversight, but in general, I very much prefer > to > > > >> have the agenda (and other, similarly short stuff) inline in my > inbox. > > > >> That saves me (and everybody else) a click (or two, plus some > on-page > > > >> search time, this time). Of course it can change later, but we al= l > know > > > >> that. > > > >> > > > >> The actual agenda is at > > > >> > https://datatracker.ietf.org/meeting/104/materials/agenda-104-dispatch-00= . > > > > >> In the future, precise links would be appreciated. > > > >> > > > >> The agenda currently reads as follows: > > > >> > > > >> # Draft Agenda Dispatch @IETF-104 - v1 > > > >> > > > >> DISPATCH Meeting > > > >> ------------------- > > > >> > > > >> # Status and agenda bash - Chairs (10 min) > > > >> > > > >> # Relay User Machine (RUM) - Brian Rosen (20 min) > > > >> > > > >> # JSON Contact - Bron Gondwana (20 min) > > > >> > > > >> # Web Packaging - Jeffrey Yasskin (20 min) > > > >> > > > >> Note: see DISPATCH wiki for additional links to materials > > > >> > > > >> > > > >> ART AREA Meeting > > > >> ------------------- > > > >> > > > >> # Bofs and meetings of interest - ADs (5 min) > > > >> > > > >> # JSON Canonicalization Scheme (JCS) - Anders Rundgren (20) > > > >> Document: draft-rundgren-json-canonicalization-scheme > > > >> > > > >> # AOB > > > >> > > > >> > > > >>> Regards, > > > >>> Mary. > > > >>> DISPATCH WG co-chair > > > >>> > > > >>> ---------- Forwarded message --------- > > > >>> From: Mary Barnes > > > >>> Date: Thu, Mar 7, 2019 at 9:59 AM > > > >>> Subject: Topics for DISPATCH @ IETF-104 > > > >>> To: DISPATCH > > > >>> Cc: ART ADs , dispatch chairs < > dispatch-chairs@ietf.org> > > > >>> > > > >>> > > > >>> Hi all, > > > >>> > > > >>> The wiki has been updated with the topics that have been agreed > to be > > > >>> discussed at IETF-104: > https://trac.ietf.org/trac/dispatch/wiki/WikiStart > > > >>> > > > >>> The proposal for moving forward draft-dold-payto is still being > discussed > > > >>> amongst ADS/chairs as is the JSON Canonicalization that had been > proposed > > > >>> as a BoF in the SEC Area, but was not approved. > > > >>> > > > >>> We will post any updates to the wiki and will post an agenda > shortly. > > > >>> > > > >>> As a reminder, if you are submitting drafts for discussion in th= e > dispatch > > > >>> working group following the standard convention of including the > WG name in > > > >>> the draft name (i.e., draft--dispatch-blah-blah) makes it > *much* > > > >>> easier for me as chair to make sure I have the right documents > identified > > > >>> on the wiki and on the agenda. The tool will allow you to > indicate that > > > >>> the document with the new name replaces the document with the ol= d > name if > > > >>> that's a concern. > > > >>> > > > >>> Regards, > > > >>> Mary > > > >>> DISPATCH WG co-chair > > > >>> > > > >> _______________________________________________ > > > >> dispatch mailing list > > > >> dispatch@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/dispatch > > > >> > > > > > > > > _______________________________________________ > > > > dispatch mailing list > > > > dispatch@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > --000000000000f07e7f05849d0a3e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not debating some of your points, which are very g= ood when it comes to building an agenda.=C2=A0 =C2=A0If I post the agenda a= head of time, next time I will include a link to the wiki and just cut and = paste from there into the body of the email.=C2=A0 While your time estimate= on the agenda is probably about right, it takes me much longer than that t= o go dig up threads and figure out what documents we are talking about and = make sure I'm not missing anything.=C2=A0 =C2=A0And, I have the same pr= oblem finding drafts, as well, which is why I'm suggesting the -dispatc= h so they'll easily show up on the WG page - that lets me double check = I haven't missed anything.=C2=A0 Per discussion yesterday, it's not= clear that the contributors/authors can indicate replaces for their own dr= afts. That may be a chair only option?=C2=A0 =C2=A0In which case, I think t= here is the need for a tool enhancement.=C2=A0 =C2=A0And the same with havi= ng the ability to have a wiki in the datatracker as opposed to tools page.= =C2=A0

The latter brings up another question for Cu= llen as to whether earlier versions of drafts that have never been adopted,= and thus fall out of the datatracker when they expire, are relevant?=C2=A0= I would think absolutely so as they document prior art.=C2=A0 But, I hones= tly don't know the official status of the tools pages when it comes to = the legal aspects. So, that is a general question - if we answer it for the= drafts, then it should equally apply to the wiki.=C2=A0=C2=A0
As an aside, the datatracker does point to the Tools page for = each WG and once there, it's one click to get to a wiki.=C2=A0 So, I do= n't think it's super hidden.=C2=A0

And, of= course, this whole discussion is more general.=C2=A0 Per my email yesterda= y it gets into tracking/documenting history in general, which also relates = to Cullen's point.=C2=A0 =C2=A0Although, it's a very curious one to= be having in the DISPATCH WG since it's been around for 10 years.=C2= =A0

Regards,
Mary.=C2=A0

On T= hu, Mar 21, 2019 at 10:44 AM Martin Thomson <mt@lowentropy.net> wrote:
Cullen's points are valid here, but I was ma= king a simple request for courtesy and respect.

If the critical information is in an email, it is more readily available.= =C2=A0 That's a tiny bit more work to provide, but a great help to peop= le looking to prepare for the meeting.=C2=A0 The TLS agenda, for example, w= as very helpful.

For instance, I had real trouble finding Bron's post until I went to th= e wiki.=C2=A0 I started to look for a draft, draft-gondwana-*, draft-*-jmap= -*, draft-jenkins-*, no luck. I searched my mail for emails, I got none bec= ause the email had a misspelled title, and the journey to find the wiki on = a phone is distressingly long and the site agonizingly slow.=C2=A0 The dire= ct link, once I had it, was fine, of course.

None of this is terribly hard to deal with, but it's a bit of burden.= =C2=A0 It's possible that it is harder for me because I have inbuilt ex= pectations about how people present their ideas.

I wonder if there is a tools enhancement we might have: the ability to buil= d an agenda based on drafts (and uploaded slides).=C2=A0 Manually building = all that stuff only takes 10 minutes, but I'll bet that it could be cut= down to 2 minutes for most groups, and produce a more usable product.

--Martin

p.s., I don't think anyone was asking you not to use the wiki.=C2=A0 Th= ough Cullen is right that all the stuff that happens out of sight without a= good record is not good.

On Fri, Mar 22, 2019, at 02:18, Mary Barnes wrote:
> So, where do you propose we store all this information for archival? >
> This really comes down to an earlier discussion on one of the other > general lists that a lot of history is lost. That wiki is the history =
> of what happened to all the work items since we started DISPATCH. Yes,=
> we have minutes, etc. but that doesn't give you the complete pictu= re as
> a lot of things happen actually NOT on public lists - e.g., the AD > sponsored documents go off and discussions are between AD and authors,=
> when WGs are chartered, there's a lot of out of band discussion, e= tc.
> Do you propose that all those discussions happen on the mailing list <= br> > for archival?
>
> Can we add a page to the datatracker for each WG so that we can store =
> information like this? The only other thing I can think of is that we =
> just post it periodically on the mailing list if you want guaranteed <= br> > archival.
>
> Regards,
> Mary.
>
> On Thu, Mar 21, 2019 at 10:00 AM Cullen Jennings <fluffy@iii.ca> wrote:
> >
> >=C2=A0 I=E2=80=99m reading this on a plane and don=E2=80=99t have = access to the WIKI, and 10 years from now when I am trying to find prior ar= e for a patent trial, all the content of the Wiki will not be archived. > >
> >
> >=C2=A0 > On Mar 19, 2019, at 4:35 PM, Martin Thomson <mt@lowentropy.net> = wrote:
> >=C2=A0 >
> >=C2=A0 > I agree with Martin. I don't know how to find thes= e documents. Where is the wiki?
> >=C2=A0 >
> >=C2=A0 > The URL is the answer.
> >=C2=A0 >
> >=C2=A0 > On Thu, Mar 14, 2019, at 16:16, Martin J. D=C3=BCrst w= rote:
> >=C2=A0 >> Hello everybody,
> >=C2=A0 >>
> >=C2=A0 >> On 2019/03/14 02:13, Mary Barnes wrote:
> >=C2=A0 >>> Hi all,
> >=C2=A0 >>>
> >=C2=A0 >>> We have uploaded a preliminary agenda for DISP= ATCH:
> >=C2=A0 >>
> >=C2=A0 >> Thanks for putting this together.
> >=C2=A0 >>
> >=C2=A0 >>> https://datatracker.ietf= .org/meeting/materials/
> >=C2=A0 >>
> >=C2=A0 >> This may be just an oversight, but in general, I v= ery much prefer to
> >=C2=A0 >> have the agenda (and other, similarly short stuff)= inline in my inbox.
> >=C2=A0 >> That saves me (and everybody else) a click (or two= , plus some on-page
> >=C2=A0 >> search time, this time). Of course it can change l= ater, but we all know
> >=C2=A0 >> that.
> >=C2=A0 >>
> >=C2=A0 >> The actual agenda is at
> >=C2=A0 >> ht= tps://datatracker.ietf.org/meeting/104/materials/agenda-104-dispatch-00= .
> >=C2=A0 >> In the future, precise links would be appreciated.=
> >=C2=A0 >>
> >=C2=A0 >> The agenda currently reads as follows:
> >=C2=A0 >>
> >=C2=A0 >> # Draft Agenda Dispatch @IETF-104 - v1
> >=C2=A0 >>
> >=C2=A0 >> DISPATCH Meeting
> >=C2=A0 >> -------------------
> >=C2=A0 >>
> >=C2=A0 >> # Status and agenda bash - Chairs (10 min)
> >=C2=A0 >>
> >=C2=A0 >> # Relay User Machine (RUM) - Brian Rosen (20 min)<= br> > >=C2=A0 >>
> >=C2=A0 >> # JSON Contact - Bron Gondwana (20 min)
> >=C2=A0 >>
> >=C2=A0 >> # Web Packaging - Jeffrey Yasskin (20 min)
> >=C2=A0 >>
> >=C2=A0 >> Note: see DISPATCH wiki for additional links to ma= terials
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> ART AREA Meeting
> >=C2=A0 >> -------------------
> >=C2=A0 >>
> >=C2=A0 >> # Bofs and meetings of interest - ADs (5 min)
> >=C2=A0 >>
> >=C2=A0 >> # JSON Canonicalization Scheme (JCS) - Anders Rund= gren (20)
> >=C2=A0 >> Document: draft-rundgren-json-canonicalization-sch= eme
> >=C2=A0 >>
> >=C2=A0 >> # AOB
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>> Regards,
> >=C2=A0 >>> Mary.
> >=C2=A0 >>> DISPATCH WG co-chair
> >=C2=A0 >>>
> >=C2=A0 >>> ---------- Forwarded message ---------
> >=C2=A0 >>> From: Mary Barnes <mary.ietf.barnes@gmail.com><= br> > >=C2=A0 >>> Date: Thu, Mar 7, 2019 at 9:59 AM
> >=C2=A0 >>> Subject: Topics for DISPATCH @ IETF-104
> >=C2=A0 >>> To: DISPATCH <dispatch@ietf.org>
> >=C2=A0 >>> Cc: ART ADs <art-ads@ietf.org>, dispatch chairs <dispatch-chairs@ie= tf.org>
> >=C2=A0 >>>
> >=C2=A0 >>>
> >=C2=A0 >>> Hi all,
> >=C2=A0 >>>
> >=C2=A0 >>> The wiki has been updated with the topics that= have been agreed to be
> >=C2=A0 >>> discussed at IETF-104: https://trac.ietf.org/trac/dispatch/wiki/WikiStart
> >=C2=A0 >>>
> >=C2=A0 >>> The proposal for moving forward draft-dold-pay= to is still being discussed
> >=C2=A0 >>> amongst ADS/chairs as is the JSON Canonicaliza= tion that had been proposed
> >=C2=A0 >>> as a BoF in the SEC Area, but was not approved= .
> >=C2=A0 >>>
> >=C2=A0 >>> We will post any updates to the wiki and will = post an agenda shortly.
> >=C2=A0 >>>
> >=C2=A0 >>> As a reminder, if you are submitting drafts fo= r discussion in the dispatch
> >=C2=A0 >>> working group following the standard conventio= n of including the WG name in
> >=C2=A0 >>> the draft name (i.e., draft-<name>-dispa= tch-blah-blah) makes it *much*
> >=C2=A0 >>> easier for me as chair to make sure I have the= right documents identified
> >=C2=A0 >>> on the wiki and on the agenda. The tool will a= llow you to indicate that
> >=C2=A0 >>> the document with the new name replaces the do= cument with the old name if
> >=C2=A0 >>> that's a concern.
> >=C2=A0 >>>
> >=C2=A0 >>> Regards,
> >=C2=A0 >>> Mary
> >=C2=A0 >>> DISPATCH WG co-chair
> >=C2=A0 >>>
> >=C2=A0 >> _______________________________________________ > >=C2=A0 >> dispatch mailing list
> >=C2=A0 >> dispatch@ietf.org
> >=C2=A0 >> https://www.ietf.org/mailman/= listinfo/dispatch
> >=C2=A0 >>
> >=C2=A0 >
> >=C2=A0 > _______________________________________________
> >=C2=A0 > dispatch mailing list
> >=C2=A0 > dispatch@ietf.org
> >=C2=A0 > https://www.ietf.org/mailman/list= info/dispatch
> >
> >=C2=A0 _______________________________________________
> >=C2=A0 dispatch mailing list
> > dispatch@i= etf.org
> > https://www.ietf.org/mailman/listinfo/dispat= ch
--000000000000f07e7f05849d0a3e-- From nobody Thu Mar 21 09:24:10 2019 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 2A717131362 for ; Thu, 21 Mar 2019 09:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxgGCqbsZqBI for ; Thu, 21 Mar 2019 09:24:04 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2B0C131364 for ; Thu, 21 Mar 2019 09:23:59 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id v22so5804421lje.9 for ; Thu, 21 Mar 2019 09:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=IXzDzExDM45zf+6NJWht6LcrX8pUAT1s3IjMVY9fdWE=; b=UbXmCrHGYvNWikrNlhr7ihPLExiecdthsHr5Xh4kiTjlz1jk6o87rGNXTK0d5UX5BI mBfNbcaipewcAJ5vna1tFCekANQ3DGmP/v84rJoKcicnD1wj7BdyFgYxGHh8T3cNaERV 6hnTPB/N0r9pPcY1HsNGTu88Vzkqd45mmrsx67fdFGpy0FvVSS33EAhTWfiIsWUAEvMZ 9MlxTavzMnp3a5Lz5GPoNPgUTG+Zgpzhd01hdYnW68SJ2IOYpZW/jH90b1EciLd1tc5o 7HINqojY90o0OBQt26pi3w+XFPLDy3n3lJ5wTKvQE36LCmmPGabnzQsm+8IRDo16r+dk vmWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=IXzDzExDM45zf+6NJWht6LcrX8pUAT1s3IjMVY9fdWE=; b=eX3r3HHtdPKwsYoav8vjESfUaXTwQFcrY1oKPaHNDfCTTFC+3YrAIGAa1Xn5DEOrIg u3/f9AX0nAyxPJuZwAvoa6MKcEQ1dAjWXez8Mw5gwQyS83igfFDxC9xphaz5O63qXYnu OhT3fW4T1ZMGtFVXQP5bQNYwRysp+1WfxK4YISD79m9Isssv45POzcXl+5tsCiIJ3GEk sb4HpYMfIl8cSSGDOPVZq2sYJMK0nZDg/2lBux4KKuQgH3YU8ZzHZtfffvMouNxfz3gv PLXgKAwKZrzwLXOPZDZ3aM292rPr149M4KFLGKG2HQL9W/XPiVBugNKcwOpUFo60B8PN h12g== X-Gm-Message-State: APjAAAWY+qfF6Ic7krhxw9kLEWrwdpIfdRITJ4mXm9lvYqum3bEQswuh ZYPtuKSpMPVU932v1MJeXch6ANEJbnfQQQiRPU+sVxbF X-Google-Smtp-Source: APXvYqwNjwaghcPVt3BDOUGRY1nD1VpUazdQOThxpsJJCQ15xMW8+3CCemIe7bYOQRXM699OpV1poHWHB0an9t0ohnM= X-Received: by 2002:a2e:808e:: with SMTP id i14mr2525729ljg.103.1553185437379; Thu, 21 Mar 2019 09:23:57 -0700 (PDT) MIME-Version: 1.0 From: Mary Barnes Date: Thu, 21 Mar 2019 11:23:45 -0500 Message-ID: To: DISPATCH Content-Type: multipart/alternative; boundary="00000000000043f30505849d2aea" Archived-At: Subject: [dispatch] Summary: DISPATCH WG items March 2009-March 2019 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, 21 Mar 2019 16:24:09 -0000 --00000000000043f30505849d2aea Content-Type: text/plain; charset="UTF-8" Here is a snapshot of what is on the DISPATCH WG wiki since a point was raised about the need to archive such. https://trac.ietf.org/trac/dispatch By the way, I went through recently and updated the information to include published RFC #s, etc. There are handful of individual drafts for which the meeting conclusion was that more discussion was needed. If one of those is yours and there has been subsequent discussion and the way forward agreed with an AD, for example, OR you are not planning to pursue the topic, I can update the wiki to reflect such. Regards, Mary DISPATCH WG co-chair Welcome to the IETF DISPATCH WG Wiki The DISPATCH WG in the ART area is chartered to review new work in the ART area. Based on mailing list discussion, if there is sufficient interest, willingness to contribute and WG consensus, new work items are dispatched in various ways depending upon the scope and applicability of the work. Mailing list discussions should focus on the problem statement, objectives and deliverables in the form of a proposed charter. Note, that not all new work items are required to be discussed in the DISPATCH WG - exceptions are items that clearly fit within the chart of an existing WG (in this case those WG chairs should be contacted) and in the case of topics that would clearly require an official Bof (in which case the ADs should be contacted). The following summarizes the current dispatchment options: - New work item in DISPATCH WG for registrations only - New work item in currently chartered WG - New WG - IETF official BoF - typically for work items that are of broad interest and potential impact within the ART area and across areas. - Individual/AD sponsored - for items limited in scope and applicability IETF-104 Deadlines - February 8, 2019. Cutoff date for IETF BoF submissions. - February 15, 2019. Cutoff date to notify the chairs/DISPATCH WG of plans to submit a proposal/topic. - February 22, 2019. Cutoff for proposals (i.e., problem statement and proposed deliverables) for topics posted to the DISPATCH WG mailing list. - March 1, 2019. Announcement of topics that have been dispatched for IETF-104. - March 11, 2019. Draft submission deadline. A complete list of deadlines for IETF-104 is available here: https://datatracker.ietf.org/meeting/important-dates/ Working with Deadlines - If you make the deadlines, you go to the front of the list for agenda time. - If you miss the deadlines, you go behind "Any Other Business" in terms of priority. - *Please* start draft names with: draft--dispatch- DISPATCHed Topics The following summarizes the work items that have been dispatched or are in the process of being dispatched. Please note that this is *not* a complete summary of the topics discussed in DISPATCH, but rather the items that have been put forth for discussion at the meetings and/or agreed to be progressed. The status of the work items still underway is periodically posted to the DISPATCH WG mailing list. Please note that up-to-date charters are available on the DISPATCH or topic specific mailing list (s). IETF-104 topics - Relay User Machine (RUM) : Pre-IETF-104 WG agreement to charter WG. - Charter proposal: https://mailarchive.ietf.org/arch/msg/dispatch/DulYa-smNK96RXGos_x_lEjeUw8 - JSON Contact: - Discussion: https://mailarchive.ietf.org/arch/msg/dispatch/IEwBrtBUZfAsD_usDt40HDBBTB0 - Web Packaging: - Discussion and Document links: https://mailarchive.ietf.org/arch/msg/dispatch/e6ZSh7ocW6n2afnbwGzBlX1WT8Y IETF-103 topics - HTTP Header Registry: Agreement with proposal to split. - The Secret Token URI scheme: Agreed to be progressed as *AD sponsored*. - Document: https://datatracker.ietf.org/doc/draft-nottingham-how-did-that-get-into-the-repo/ - Regular Expressions for Internet Mail: Agreed to be progressed as *AD sponsored*. - Document: https://datatracker.ietf.org/doc/draft-seantek-mail-regexen/ IETF-102 topics - HELIUM: Discussion to continue on DISPATCH WG mailing list. - Document: https://datatracker.ietf.org/doc/draft-schwartz-httpbis-helium/ IETF-101 topics - JSON Content Rules: Discussion to continue on ART list. - Documents: - https://datatracker.ietf.org/doc/draft-newton-json-content-rules/ - https://datatracker.ietf.org/doc/draft-newton-rdap-jcr/ - Defining Well-Known URI: Agreed to be progressed as *AD sponsored*. - Document: https://datatracker.ietf.org/doc/draft-nottingham-rfc5785bis/ - New Media Stack: Discussion to continue on a new dedicated mailing list. - Document: https://datatracker.ietf.org/doc/draft-jennings-dispatch-new-media/ IETF-100 topics - i18n - Internationalization (Again): Discussion to continue on ART list. ADs to consider how to progress documents. - Documents: - https://datatracker.ietf.org/doc/draft-klensin-idna-rfc5891bis - https://datatracker.ietf.org/doc/draft-freytag-troublesome-characters - https://datatracker.ietf.org/doc/draft-klensin-idna-5892upd-unicode70 - E2E Secure Messaging for SIP/SIMPLE: Agreed to be progressed as *AD sponsored*. - Document: https://datatracker.ietf.org/doc/draft-campbell-sip-messaging-smime - Zstandard compression: *AD sponsored*. Published as *RFC 8478 *. IETF-99 topics - ECMAscript Media type updates: Dispatched to *DISPATCH WG* - DNS Over HTTPS: *DOH WG* chartered. - Web Packaging: See IETF-104. IETF-98 topics - Path MTU Discovery (PMTUD) for RTP/RTCP: Will not be progressed. - Document: https://datatracker.ietf.org/doc/draft-petithuguenin-dispatch-rtp-pmtud - Web Linking: *AD sponsored*. Published as *RFC 8288 *. - Q.850 Reason Location: Dispatched to *SIPCORE WG*. - Cryptographic Update to DKIM: *DCRUP WG* chartered. IETF-97 topics - VoIP Spam: Dispatched to *SIPCORE WG*. - Regular Expressions for Email: See IETF-103. IETF-96 topics - Glass to Glass Internet Ecosystem (GGIE): Interest in proponents refining work. More discussion needed. - Documents: - https://datatracker.ietf.org/doc/draft-deen-daigle-ggie/ - https://datatracker.ietf.org/doc/draft-deen-naik-ggie-men-mpeg-dash/ - Signalling one-click functionality for list email headers: *AD sponsored*. Published as *RFC 8058 *. - Using a DNS SRV Record to Locate an X.509 Certificate Store: Agreed to be progressed as *AD sponsored*. - Document: https://datatracker.ietf.org/doc/draft-bhjl-x509-srv/ IETF-95 topics - Best Practices for Securing RTP Media Signaled with SIP: *SIPBrandy WG* chartered. - IANA Registration of SIP Resource- Priority Namespace for Mission Critical Push To Talk service: *AD sponsored*. Published as *RFC 8101 *. - Last Diverting Line Identity: Needs more discussion. - Document: https://datatracker.ietf.org/doc/draft-weinronk-dispatch-last-diverting-line-id/ IETF-94 topics - An Opportunistic Approach for Secure Real-time Transport Protocol: See IETF-95 *SIPBrandy WG*. IETF-93 topics - GEOJson: *GEOJSON WG* chartered. - FFV1/Matroska: Proposed *CELLAR WG*. - Location Source Parameter: - Document: http://datatracker.ietf.org/doc/draft-winterbottom-dispatch-locparam/ - Via header field parameter for received realm: *AD sponsored*. Published as *RFC 8055 *. - Selection of Language for Internet Media (SLIM): *SLIM WG* chartered. IETF-92 topics - Routing out of dialog requests: Needs more discussion. - Document: https://datatracker.ietf.org/doc/draft-allen-dispatch-routing-out-of-dialog-request/ - GEOJson: see IETF-93 - Calling name identity Trust (CNIT): Post IETF-92 discussion on cnit mailing list. See draft-ietf-stir-passport-rcd in *STIR WG*. - VRS purpose for the Call Info header: Needs more discussion - Document: https://datatracker.ietf.org/doc/draft-kyzivat-dispatch-trs-call-info-purpose/ - Cause URI for service number translation. *AD sponsored*. Published as *RFC 8119 * IETF-91 topics - Correlation of multiple responses of forked INVITES in Back to Back User Agents: Needs more discussion. - Document: http://tools.ietf.org/html/draft-jesske-dispatch-forking-answer-correlation-00 - Mailing list discussion: http://www.ietf.org/mail-archive/web/dispatch/current/msg05625.html IETF-90 topics - Webpush: *WEBPUSH WG* chartered. - SIP URI Inter Operator Traffic Leg (IOTL) parameter: *AD sponsored*. Published as *RFC 7549 * - Mobile Equipment Identity (MEID) URNs: *AD sponsored*. Published as *RFC 8464 * IETF-89 topics - OpenBTS: Needs more mailing list discussion and a firmer proposal of problems being solved and deliverables. - Proposal: http://www.ietf.org/mail-archive/web/dispatch/current/msg05233.html - References: - Architecture Diagram - Source code: https://wush.net/trac/rangepublic IETF-88 topics - SDP negotiation of Data Channel sub-protocols: Dispatched to *MMUSIC WG*. IETF-87 topics No topics dispatched. See mailing list for some of the topics that were proposed: http://www.ietf.org/mail-archive/web/dispatch/current/msg04969.html IETF-86 topics - SIP/XMPP: *STOX WG* chartered - Logging: General support for adopting this work. Dispatched to *INSIPID WG*. - SIP Usage for Trickle ICE: Dispatched to *MMUSIC WG*. - BFCP over websockets: Dispatched to *BFCPBIS WG*. - MSRP over Websockets: *AD sponsored*. Published as *RFC 7977 * IETF-85 topics - Indicating Fax over IP Capability in SIP: *AD sponsored*. Published as *RFC 6913 * - Telephone-Related Queries (TERQ): *MODERN WG* chartered. IETF-84 topics - Combined Use of SIP and XMPP (CUSAX): *AD sponsored*. Published as *RFC 7081 * IETF-83 topics - SIP Traversal Required for Applications to Work (STRAW): *STRAW WG* chartered. - Media Stream Signaling (MESS): Dispatched to *AVTEXT WG* - Telephone-Related Queries (TERQ): See IETF-85. IETF-82 topics - Remote Call, Device Control: Post-IETF-82 decision not to charter. - (Original) Charter: http://www.ietf.org/mail-archive/web/dispatch/current/msg03778.html - Referencing and Verifying User Attributes: Interest in topic. Discussion to continue on the mailing list. - Related document: http://datatracker.ietf.org/doc/draft-ono-dispatch-attribute-validation/ IETF-81 topics - Session-ID: *INSIPID WG* chartered. - Load Balancing: WG interest but needs more discussion. - Charter: http://www.ietf.org/mail-archive/web/dispatch/current/msg03649.html - BFCP for UDP: *BFCPBIS WG* chartered. - Global Service Provider Identification Number: Agreed to be progressed (likely as AD sponsored). Ongoing discussion should be on RAI area list (as opposed to DRINKS or DISPATCH). - Related document: http://www.ietf.org/id/draft-pfautz-service-provider-identifier-urn-00.txt - SIP Action Referral: See Remote Device, Call Control @ IETF-82. IETF-80 topics - Q4S (on agenda): No interest in chartering this work. Being published via *ISE*. - Related document: http://datatracker.ietf.org/doc/draft-aranda-dispatch-q4s/ - Reason header in responses: *AD sponsored*. Published as *RFC 6432 * - RTCWEB: *RTCWEB WG* chartered. - VIPR: *VIPR WG* chartered. - SIP Action Referral: See IETF-81. - SIP Interconnect guidelines: No interest in chartering this work. IETF-79 topics - DTMF Info: No WG interest in this work. - Telepresence: *CLUE WG* chartered. - BFCP for UDP: See IETF-81 IETF-78 topics - Session-ID: See IETF-81 - Telepresence: See IETF-79 - VIPR: See IETF-80 - TEL URI WG proposal: No interest in adopting this work as is. The recommendation is to go back to the general problem and describe the use cases such that an optimal solution can be developed. IETF-77 topics - E.164 to Metadata (E2M). *BoF*. - BoF meeting minutes: http://www.ietf.org/proceedings/10mar/minutes/e2md.txt IETF-76 topics - Session Recording: *SIPREC WG* chartered. - Domain Registration: *MARTINI WG* chartered (completed deliverables, closed March 9th, 2011) - Disaggregated Media: *SPLICES WG* chartered. - Alert-URNs: *SALUD WG* chartered. - Reason in Response: see IETF-80. - SIP-XMPP: XMPP WG consensus not to charter this work (at IETF-80) - Proposed SIXPAC charter: http://www.ietf.org/mail-archive/web/dispatch/current/msg02699.html - SIP Overload: *SOC WG* chartered. IETF-75 topics - Sound level indicator (for conferences): Work item added to *AVT WG* charter. - Codec: *CODEC WG* chartered. - Common Log Format: *SIPCLF WG* chartered. - Call Control User-to-User Information: *CUSS WG* chartered. - Profile datasets (related to SIP configuration - from SIPPING WG): Work item removed from DISPATCH WG charter due to lack of interest. --00000000000043f30505849d2aea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here is a snapshot of what is on the DISP= ATCH WG wiki since a point was raised about the need to archive such.=C2=A0= https://trac.ietf.org/trac= /dispatch=C2=A0

By the= way, I went through recently and updated the information to include publis= hed RFC #s, etc.=C2=A0 There are handful of individual drafts for which the= meeting conclusion was that more discussion was needed.=C2=A0 If one of th= ose is yours and there has been subsequent discussion and the way forward a= greed with an AD, for example, OR you are not planning to pursue the topic,= I can update the wiki to reflect such.

Regards,
Mary
DIS= PATCH WG co-chair

Welcome to the IETF DISPATCH WG Wiki

The DISPATCH WG in the AR= T area is chartered to review new work in the ART area. Based on mailing li= st discussion, if there is sufficient interest, willingness to contribute a= nd WG consensus, new work items are dispatched in various ways depending up= on the scope and applicability of the work. Mailing list discussions should= focus on the problem statement, objectives and deliverables in the form of= a proposed charter. Note, that not all new work items are required to be d= iscussed in the DISPATCH WG - exceptions are items that clearly fit within = the chart of an existing WG (in this case those WG chairs should be contact= ed) and in the case of topics that would clearly require an official Bof (i= n which case the ADs should be contacted).

The following summarizes the current dispatchment optio= ns:

  • New work item = in DISPATCH WG for registrations only
  • New work item in currently chartered WG
=
  • New WG
  • IETF official BoF - typica= lly for work items that are of broad interest and potential impact within t= he ART area and across areas.
  • Individual/AD sponsored - for items limited in scope and = applicability

IETF-104 Deadlines

  • February 8, 2019. Cutoff = date for IETF BoF submissions.
  • February 15, 2019. Cutoff date to notify the chairs/DISP= ATCH WG of plans to submit a proposal/topic.
  • February 22, 2019. Cutoff for proposals (i= .e., problem statement and proposed deliverables) for topics posted to the = DISPATCH WG mailing list.
  • March 1, 2019. Announcement of topics that have been dispatch= ed for IETF-104.
  • March 11, 2019. Draft submission deadline.

A complete list of deadlines for IETF-104 is= available here:=C2=A0https://datatracker.ietf.org/meeting/important-da= tes/

Working with Deadlines

  • If you make the deadlines= , you go to the front of the list for agenda time.
  • If you miss the deadlines, you go be= hind "Any Other Business" in terms of priority.
  • Please=C2=A0= start draft names with: draft-<your-name-here>-dispatch-
DISPATCHed Topics

The following summarizes the work = items that have been dispatched or are in the process of being dispatched. = Please note that this is *not* a complete summary of the topics discussed i= n DISPATCH, but rather the items that have been put forth for discussion at= the meetings and/or agreed to be progressed. The status of the work items = still underway is periodically posted to the DISPATCH WG mailing list. Plea= se note that up-to-date charters are available on the DISPATCH or topic spe= cific mailing list (s).

IETF-104 topics

IETF-103 topics

  • HTTP Header Registry: Agreement with p= roposal to split.
    https://datatracker.ietf.org/doc/draft-nottingham-how-did-that-get-into-t= he-repo/

IETF-102 topics

IETF-10= 1 topics

IETF-100 topics<= /h3>
  • Zstandard compression:=C2=A0AD spons= ored. Published as=C2=A0RFC 8478.

IETF-99 topics

  • ECMAscript Media type updates: Dispatched to=C2= =A0DISPATCH WG

  • DN= S Over HTTPS:=C2=A0DOH WG=C2=A0chartered.
  • Web Packaging: See IETF-104.=

IETF-98 topics

--00000000000043f30505849d2aea-- From nobody Sat Mar 23 04:10:46 2019 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 45425130E46 for ; Sat, 23 Mar 2019 04:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 63MTgW97w2kR for ; Sat, 23 Mar 2019 04:10:43 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3369D126C01 for ; Sat, 23 Mar 2019 04:10:43 -0700 (PDT) Received: from dhcp-9259.meeting.ietf.org (dhcp-9259.meeting.ietf.org [31.133.146.89]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x2NBAcBh009222 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 23 Mar 2019 06:10:40 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1553339441; bh=3+10EuVhggNuRqlsIaYWhSSEqLsxWLqlRq7IaIBt18k=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=NGP2bnwR4Zz7PdOnK1dHt2hI+RA4JDvLdOiWo/FXnY59lvEdC3KHKHelffKJoebRK ENQgdN4O7/nrZ6MOGZxWygBs+6Iza4ACjuEEo+BDcsuIAe425FYBOeQrjzxGOL07cM +il/1zon5jTKKQ3Aedy/jzd5vuFvhUkNkiHR8tUs= From: Ben Campbell Message-Id: <6A0A9AD5-F76B-4F78-B59E-C1CFE93529E1@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_DE39F2A3-B955-431C-8777-FEEA55EA3474"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Sat, 23 Mar 2019 12:10:37 +0100 In-Reply-To: To: DISPATCH References: <3c9085a4-3348-489b-8a42-545f686c017a@www.fastmail.com> <892FDB9A-DC09-44BB-A540-61727F581C71@iii.ca> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [dispatch] DISPATCH processes (was Re: DISPATCH agenda @ IETF-104) 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, 23 Mar 2019 11:10:45 -0000 --Apple-Mail=_DE39F2A3-B955-431C-8777-FEEA55EA3474 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Speaking as out-going AD and incoming-co-chair who was on vacation when = all the agenda stuff needed to happen: (First, I am not picking on Martin=E2=80=99s comments; it just seemed = like a good point to jump into the conversation.) Mary had to deal with the agenda by herself (as in no co-chair and very = little AD support) for this meeting. That left very little time for = making changes or optimizations to the way we have historically = presented these things. I am probably more to blame for that than = anyone, for the reasons in my opening line to this email. DISPATCH holds a special place as the working group that most new ART = participants will experience first. I fully agree that we need to work = on making things easier for new participants, without making it tedious = for old-hands. There are some obvious things we can do based on the = discussion so far, and there may be room for other innovations and = experiments moving forward. I propose that for now we focus on getting through the agenda we have = for Monday and the related discussion topics, then afterwards continue a = discussion to get input on what would work best for people going = forward. That way we can have that discussion without the pressure of a = meeting only 2 days away. Thanks! Ben. > On Mar 21, 2019, at 4:44 PM, Martin Thomson wrote: >=20 > Cullen's points are valid here, but I was making a simple request for = courtesy and respect. >=20 > If the critical information is in an email, it is more readily = available. That's a tiny bit more work to provide, but a great help to = people looking to prepare for the meeting. The TLS agenda, for example, = was very helpful. >=20 > For instance, I had real trouble finding Bron's post until I went to = the wiki. I started to look for a draft, draft-gondwana-*, = draft-*-jmap-*, draft-jenkins-*, no luck. I searched my mail for emails, = I got none because the email had a misspelled title, and the journey to = find the wiki on a phone is distressingly long and the site agonizingly = slow. The direct link, once I had it, was fine, of course. >=20 > None of this is terribly hard to deal with, but it's a bit of burden. = It's possible that it is harder for me because I have inbuilt = expectations about how people present their ideas. >=20 > I wonder if there is a tools enhancement we might have: the ability to = build an agenda based on drafts (and uploaded slides). Manually = building all that stuff only takes 10 minutes, but I'll bet that it = could be cut down to 2 minutes for most groups, and produce a more = usable product. >=20 > --Martin >=20 > p.s., I don't think anyone was asking you not to use the wiki. Though = Cullen is right that all the stuff that happens out of sight without a = good record is not good. >=20 > On Fri, Mar 22, 2019, at 02:18, Mary Barnes wrote: >> So, where do you propose we store all this information for archival? >>=20 >> This really comes down to an earlier discussion on one of the other >> general lists that a lot of history is lost. That wiki is the history >> of what happened to all the work items since we started DISPATCH. = Yes, >> we have minutes, etc. but that doesn't give you the complete picture = as >> a lot of things happen actually NOT on public lists - e.g., the AD >> sponsored documents go off and discussions are between AD and = authors, >> when WGs are chartered, there's a lot of out of band discussion, etc. >> Do you propose that all those discussions happen on the mailing list >> for archival? >>=20 >> Can we add a page to the datatracker for each WG so that we can store >> information like this? The only other thing I can think of is that we >> just post it periodically on the mailing list if you want guaranteed >> archival. >>=20 >> Regards, >> Mary. >>=20 >> On Thu, Mar 21, 2019 at 10:00 AM Cullen Jennings = wrote: >>>=20 >>> I=E2=80=99m reading this on a plane and don=E2=80=99t have access to = the WIKI, and 10 years from now when I am trying to find prior are for a = patent trial, all the content of the Wiki will not be archived. >>>=20 >>>=20 >>>> On Mar 19, 2019, at 4:35 PM, Martin Thomson = wrote: >>>>=20 >>>> I agree with Martin. I don't know how to find these documents. = Where is the wiki? >>>>=20 >>>> The URL is the answer. >>>>=20 >>>> On Thu, Mar 14, 2019, at 16:16, Martin J. D=C3=BCrst wrote: >>>>> Hello everybody, >>>>>=20 >>>>> On 2019/03/14 02:13, Mary Barnes wrote: >>>>>> Hi all, >>>>>>=20 >>>>>> We have uploaded a preliminary agenda for DISPATCH: >>>>>=20 >>>>> Thanks for putting this together. >>>>>=20 >>>>>> https://datatracker.ietf.org/meeting/materials/ >>>>>=20 >>>>> This may be just an oversight, but in general, I very much prefer = to >>>>> have the agenda (and other, similarly short stuff) inline in my = inbox. >>>>> That saves me (and everybody else) a click (or two, plus some = on-page >>>>> search time, this time). Of course it can change later, but we all = know >>>>> that. >>>>>=20 >>>>> The actual agenda is at >>>>> = https://datatracker.ietf.org/meeting/104/materials/agenda-104-dispatch-00.= >>>>> In the future, precise links would be appreciated. >>>>>=20 >>>>> The agenda currently reads as follows: >>>>>=20 >>>>> # Draft Agenda Dispatch @IETF-104 - v1 >>>>>=20 >>>>> DISPATCH Meeting >>>>> ------------------- >>>>>=20 >>>>> # Status and agenda bash - Chairs (10 min) >>>>>=20 >>>>> # Relay User Machine (RUM) - Brian Rosen (20 min) >>>>>=20 >>>>> # JSON Contact - Bron Gondwana (20 min) >>>>>=20 >>>>> # Web Packaging - Jeffrey Yasskin (20 min) >>>>>=20 >>>>> Note: see DISPATCH wiki for additional links to materials >>>>>=20 >>>>>=20 >>>>> ART AREA Meeting >>>>> ------------------- >>>>>=20 >>>>> # Bofs and meetings of interest - ADs (5 min) >>>>>=20 >>>>> # JSON Canonicalization Scheme (JCS) - Anders Rundgren (20) >>>>> Document: draft-rundgren-json-canonicalization-scheme >>>>>=20 >>>>> # AOB >>>>>=20 >>>>>=20 >>>>>> Regards, >>>>>> Mary. >>>>>> DISPATCH WG co-chair >>>>>>=20 >>>>>> ---------- Forwarded message --------- >>>>>> From: Mary Barnes >>>>>> Date: Thu, Mar 7, 2019 at 9:59 AM >>>>>> Subject: Topics for DISPATCH @ IETF-104 >>>>>> To: DISPATCH >>>>>> Cc: ART ADs , dispatch chairs = >>>>>>=20 >>>>>>=20 >>>>>> Hi all, >>>>>>=20 >>>>>> The wiki has been updated with the topics that have been agreed = to be >>>>>> discussed at IETF-104: = https://trac.ietf.org/trac/dispatch/wiki/WikiStart >>>>>>=20 >>>>>> The proposal for moving forward draft-dold-payto is still being = discussed >>>>>> amongst ADS/chairs as is the JSON Canonicalization that had been = proposed >>>>>> as a BoF in the SEC Area, but was not approved. >>>>>>=20 >>>>>> We will post any updates to the wiki and will post an agenda = shortly. >>>>>>=20 >>>>>> As a reminder, if you are submitting drafts for discussion in the = dispatch >>>>>> working group following the standard convention of including the = WG name in >>>>>> the draft name (i.e., draft--dispatch-blah-blah) makes it = *much* >>>>>> easier for me as chair to make sure I have the right documents = identified >>>>>> on the wiki and on the agenda. The tool will allow you to = indicate that >>>>>> the document with the new name replaces the document with the old = name if >>>>>> that's a concern. >>>>>>=20 >>>>>> Regards, >>>>>> Mary >>>>>> DISPATCH WG co-chair >>>>>>=20 >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_DE39F2A3-B955-431C-8777-FEEA55EA3474 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlyWFC0ACgkQgFZKbJXz 1A3CYw//aj3IxAdyOvKUh2o6p3AILl1B72uK+RIyFbQ7pSDm5OWnVMya+sacPKkD /vOcyZFfRgJAz8anL+yiOcm1nVcBoXzvRsKVn8aWHQBA/ygeWTz8VEoVXSJ/plUo mhjNfuVuR1UPz7MaxQ6rUxgizi3jn+QiU54okVu3z1pxMJAqFN7yWHiQcolqeyn+ HYnbhXI1RapASrMuuoOowaC15Twv6V7nj1wnM5aYElplKcTrNDpIlkqhdou4FI0u YktWJd87lBtZ1iGHphbLe5DwW6/biayukFRVXwRTPGF3I0jg2xEzE8VHniYOqas3 pXPbg8qY15Rsw46reIFWHzYUjaTN0wSfysdYaUsyYUaTvkfoKb/vj/yoDqxFGRrC 4phllieVwCdDP4acZp5i93eOCZUBq8u1kMHuBzvCgMNOzH2tYffRihUCEhgq7ysc uE4bWSR3YLsRKpAaIVhB9VQ6qDHVSICdMMkOBqaLa1YTm4kO3VKjItVVYHoib1Em sqZA97ZIcWDM0Gsgpow3BtJFp4f8mnU/jPEWCpSKx3P6UZKkw/nLIsxDDmPBpfJd v3O7VDQW+AJgZMM2ZsAD8cOvWE5xZRUCaShjl4WkvGxgwyJB8gv8BAIfPNVqekjQ xfsbUjtfusxkidrOpRWZVIp7AjAdAP5NvSjpEPIwRJLr3obShUI= =2jxe -----END PGP SIGNATURE----- --Apple-Mail=_DE39F2A3-B955-431C-8777-FEEA55EA3474-- From nobody Sat Mar 23 04:17:34 2019 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 33EDE130E8E for ; Sat, 23 Mar 2019 04:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=BYR1p9qg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dAnZVY9l 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 5YVyU_ZZfkzk for ; Sat, 23 Mar 2019 04:17:30 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F700130E6D for ; Sat, 23 Mar 2019 04:17:30 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id DF08B352A for ; Sat, 23 Mar 2019 07:17:29 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Sat, 23 Mar 2019 07:17:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=25NazNF l1bjCPeM3cavQ0H1UBktG8XXC5twriSvu8+I=; b=BYR1p9qgAvX7Zeopjqi8oEO j1qTq0wfe5dMmQZDYTH01plQT9cpmcQVNe/F6KZRYdtrtop52RZ3mxqL9VtnZ6h8 YudkntfpLYY4voo+5BGKYNUXjQEHYN9H910EeZgshwSLfsZiMYFrbXh59lixRaiG IwLg4ZmaVbB8remu6eWX36C4hwurywQ/8KTia3xx99KnA9wyTYQsOtHwq5hHpgHM LaG6bGHtGXo4bM9NW0oG7oMEVMUXM+bgz/did+uK+DtARnA6WmCv766Lfepin+7c 06WrTiStVlB4hkYneDj7XmzAlmFpQAu+B1/p5rKRhI0dO0Rqry4wL9+0JUDR69A= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=25NazN Fl1bjCPeM3cavQ0H1UBktG8XXC5twriSvu8+I=; b=dAnZVY9lD3ihxb6JZzoCC6 6Se/8a9Zxs/xXGy9LpltoT8LXcJ7sxtIwxM7ZamiqVN0QC2PUj/SA+RL7PsyWFeN LnjOsStbM6hSsfpat0Sf+2yeYf9X1ln6BkI5J1K6EGdEWeBSyG/enF+/FbAOWhqu Bn1d89lXOJdF001XsCldUp91m/IuJggemdqaeoJK2xUWHVLtylRdSRKGh4rTcMKz 52HqsA4chUKa3HdHB+c6fYc2biMHK7it2ZMPjRFGANdof7PTUWZCFqC49foBPMNx fLurr2l8NvzjdF6/yA9UvGLIGHQAIFoMTNthjzfd47lNY5pZJ34kqib6ZqQUjq/A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrjeefgddvkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghenuc frrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgt ohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D435120617; Sat, 23 Mar 2019 07:17:28 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-976-g376b1f3-fmstable-20190314v3 Mime-Version: 1.0 X-Me-Personality: 56629417 Message-Id: In-Reply-To: References: <3c9085a4-3348-489b-8a42-545f686c017a@www.fastmail.com> <892FDB9A-DC09-44BB-A540-61727F581C71@iii.ca> Date: Sat, 23 Mar 2019 07:17:21 -0400 From: "Bron Gondwana" To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=aebf970502814055a5ce1282e5f0d894 Archived-At: Subject: Re: [dispatch] DISPATCH agenda @ IETF-104 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, 23 Mar 2019 11:17:33 -0000 --aebf970502814055a5ce1282e5f0d894 Content-Type: text/plain On Fri, Mar 22, 2019, at 02:44, Martin Thomson wrote: > For instance, I had real trouble finding Bron's post until I went to the wiki. I started to look for a draft, draft-gondwana-*, draft-*-jmap-*, draft-jenkins-*, no luck. I searched my mail for emails, I got none because the email had a misspelled title, and the journey to find the wiki on a phone is distressingly long and the site agonizingly slow. The direct link, once I had it, was fine, of course. Apologies for this! Obviously any time wasted by people trying to find information is disappointing. Of course it was Robert's name on the draft even though he's not going to be able to be here in person. For those still looking, it's here: https://datatracker.ietf.org/doc/draft-stepanek-jscontact/ Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --aebf970502814055a5ce1282e5f0d894 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Fri, Mar 22, 2019, at 02:44, Martin Thomson wrote:
<= /div>
For instance, I had real trouble finding Bron's post unt= il I went to the wiki.  I started to look for a draft, draft-gondwa= na-*, draft-*-jmap-*, draft-jenkins-*, no luck. I searched my mail for e= mails, I got none because the email had a misspelled title, and the jour= ney to find the wiki on a phone is distressingly long and the site agoni= zingly slow.  The direct link, once I had it, was fine, of course.<= br>

Apologies for this!  Obviously any time= wasted by people trying to find information is disappointing.  Of = course it was Robert's name on the draft even though he's not going to b= e able to be here in person.
=
For those still looking, it's here:


Cheers,
<= /div>

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--aebf970502814055a5ce1282e5f0d894-- From nobody Fri Mar 29 03:31:01 2019 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 C0809120408; Fri, 29 Mar 2019 03:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRkvVutoSx3B; Fri, 29 Mar 2019 03:30:47 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6148F12025E; Fri, 29 Mar 2019 03:30:45 -0700 (PDT) Received: from dhcp-9259.meeting.ietf.org (dhcp-9259.meeting.ietf.org [31.133.146.89]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x2TAUMGb032008 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 29 Mar 2019 05:30:32 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1553855442; bh=7V8aetPBeuOFXobMdoURj6vbLeHvQGebIc2OsveMESE=; h=From:Subject:Date:Cc:To; b=qMvM7TLiJ4Q5z7l+4KcIstHslE8WdhJXjcykLJcEn5DiG6t6aO3Iua09/5LFMg+26 7dMM/z+88GzSWbrqDx2vr6mFcLFMDrjbXYov28dKUDpPkp/oyvofAYOimnOVUFHlgw NRfY2tKNcS5kEFlJasC3S6X6yeekdP6Uq+dXcYY8= From: Ben Campbell Content-Type: multipart/signed; boundary="Apple-Mail=_9FF0126F-D5AA-4FC4-B56D-9085AA253A8A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: Date: Fri, 29 Mar 2019 11:30:14 +0100 Cc: Mary Barnes , ART ADs To: DISPATCH X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [dispatch] DISPATCH Minutes 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, 29 Mar 2019 10:31:00 -0000 --Apple-Mail=_9FF0126F-D5AA-4FC4-B56D-9085AA253A8A Content-Type: multipart/alternative; boundary="Apple-Mail=_6FF87BD3-D56D-43F5-8BCF-8AE52BDFC561" --Apple-Mail=_6FF87BD3-D56D-43F5-8BCF-8AE52BDFC561 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Everyone: The preliminary minutes for DISPATCH at IETF 104 are available at the = following link, and also copied below for your convenience. Please send = comments and corrections to the dispatch list and copy the chairs = directly. Many thanks to Jean and Pete for taking notes! = https://datatracker.ietf.org/meeting/104/materials/minutes-104-dispatch-00= = Thanks! Ben. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 # DISPATCH Minutes - IETF 104: Monday, 25 March, 2019 Prague Chairs: Mary Barnes, Ben Campbell. The chairs would like to thank our note takers for their excellent notes: Jean Mahoney, Pete Resnick See DISPATCH wiki for additional links to materials: https://trac.ietf.org/trac/dispatch/wiki # Summary: DISPATCH Meeting ------------------ ### Status and agenda bash - Chairs (10 min) The chairs thanked the outgoing chairs (Cullen and Murray) and welcomed the incoming chair (Ben). Mary presented a token of appreciation to the outgoing ART AD (Ben) The order of discussions was changed to accomodate a travel delay by one of the presenters. ### Relay User Machine (RUM) - Brian Rosen (Presented last due to Brian's travel delay) Brian provided an overview of the proposed RUM charter and draft-rosen-rue-00. RUM was not dispatched, since a working group charter is already in external review and expected to be approved soon. A side meeting was also planned for later in the week. ### JSON Contact - Bron Gondwana and Robert Stepanek(remote) Robert presented a summary of draft-stepanek-jscontact. There was discussion about whether this work should go into a new, focused WG vs CALEXT. 4 or 5 people indicated that they were likely to implement it. The work needs some refinement and more discussion prior to making a dispatch recommendation. DISPATCH may look at this again in the future. List discussion was encouraged. The chairs noted that this need not wait for IETF 105 for further discussion. ### Web Packaging - Jeffrey Yasskin (20 min) Jeffery presented draft-yasskin-dispatch-web-packaging and discussed changes since previous discussion of the concept. The work needs feedback from deployments. The IAB is organizing the ESCAPE workshop to get feedback from publishers. There will be a side meeting on Wednesday. It is likely that part of the work should be in the W3C. The room agreed that it would be appropriate to plan a BoF. We need to focus first on selecting the right use cases. Direct engagement from implementers will be important for success. ### Other Business Aaron Falk mentioned the proposal for BRAID at HotRFC as a potentially dispatchable proposal. ART AREA Meeting ------------------- # JSON Canonicalization Scheme (JCS) - Anders Rundgren (20) Anders presented draft-rundgren-json-canonicalization-scheme and received feedback. The draft was also expected to be discussed in SECDISPATCH. We need to better understand the use cases. There are both security and application aspects. # Raw Notes from Jean Mahoney Dispatch - IETF 104 Monday morning session I Congress Hall 3 Chairs: Ben Campbell, Mary Barnes Note takers: Pete Resnick, Jean Mahoney Jabber scribe: Matt Miller DISPATCH wiki: https://trac.ietf.org/trac/dispatch/wiki ---------------------------------------------------------- Status and agenda bash Presenters: Mary, Ben slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-dispatch- chairs-agenda-and-status-02 The schedule of presentations changed due to travel delays experienced by a presenter. Mary Barnes thanked Cullen Jennings and Murray Kucherawy for their work as DISPATCH co-chairs, and welcomed Ben Campbell as the new co-chair. Mary presented Ben with a token of appreciation for his work as ART AD (a bottle of Czech rum), and let him know that another gift would be shipped to his home address. ---------------------------------------------------------- Web Packaging Presenter: Jeffrey Yasskin Discussion: https://mailarchive.ietf.org/arch/msg/dispatch/ e6ZSh7ocW6n2afnbwGzBlX1WT8Y slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-dispatch- web-packaging-01 Jeffrey said that he needed feedback from deployments. Mark Nottingham and the IAB are organizing the ESCAPE workshop to get feedback from publishers. There will be a side meeting on Wednesday. He thought that part of the work should be in the W3C, and part in HTTPWG. Eric Rescorla suggested a bof be held and that the bof should discuss use cases. Eric pointed out that the answer to the given use cases may not be the solution that Jeffery is proposing, and didn't think that all use cases given were equally important. Wendy Seltzer said that the W3C is interested in the use cases and want to be part of the discussion. There were distances between use cases and solutions. Mark Nottingham thought that a bof was needed. He wondered if Jeffery would be willing to accept consensus if the IETF community determined that the solution to the use cases wasn't the one that Jeffrey was proposing. Jeffrey thought that he could. Cullen asked what Jeffrey expected from the IETF. Jeffery said he needed the security expertise in HTTPS, TLS and that the IETF would define the format while the W3C would define the algorithms for loading. Ted Hardy agreed that a bof was the next step, but wondered if it was a task for the bof to determine the split of work, or would that be decided before the bof, and suggested that the Wednesday side meeting be used to discuss that. Ted was interested in the anti-censorship use case. Martin Thomson wanted to know who would implement it, and said that the implementers needed to show up at the IETF. Dan York agreed that a bof was needed, but said that we needed to know that the solution would be used. Eric Rescorla emphasized that if the implementors don't participate, there's no point in pursuing it. Cullen Jennings said that if a group of people want to change the architecture fundamentally but don't show up, they won't be taken seriously. Jeffrey thought he could get the implementers to participate remotely. Ben Campbell, as chair stated for the minutes: A bof is a good idea, need to focus on right use cases first, the people who are going to implement it need to be engaged in the process. ---------------------------------------------------------- JSON Contact Presenter: Robert Stepanek (remote), Bron Gondwana Discussion: https://mailarchive.ietf.org/arch/msg/dispatch/ IEwBrtBUZfAsD_usDt40HDBBTB0 Draft: draft-stepanek-jscontact slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-dispatch- json-contact-00 Daniel Migault, as CALEXT co-chair, was in favor of bringing the working into the CALEXT working group. Cullen argued for a new, focused working group since CALEXT didn't do messaging. Barry Leiba sided with Cullen on a new, focused WG. He pointed out that vCard versions get ossified, with new implementations using new version of vCards, while older implementations stay with older versions. He suggested keep as much mapping as possible so it can be ported. Robert Stepanek said that they would reuse as much as possible but couldn't guarantee 100% compatibility. Jim Fenton asked if Robert had a feel for how well this would be adopted. Robert said they were early in the process and that it was experimental. Chris Newman felt that it created an opportunity to get address books integrated more effectively with other protocols. Alexey Melnikov, as AD, said that he heard some interest, but it was not clear whether it will go CALEXT, JMAP or a new working group. Ben Campbell asked for a show of hands if anyone was interested in implementing it. Four or five people raised their hands. Jon Peterson said there was already a draft on how to do vCard with JSON. He might implement this if it were better, but the draft was at too early a stage to tell. Mary Barnes, as chair, said that more work needed to go into this for people to discuss. Alexey, as AD, said that an updated draft and more discussion was needed, then it could be re-dispatched. Ben Campbell, as chair, pointed out it could be discussed on list and the WG didn't have to wait until Montreal to dispatch. ---------------------------------------------------------- JSONCanonicalization Scheme (JCS) Presenter: Anders Rundgren Document: draft-rundgren-json-canonicalization-scheme Richard Barnes pointed out that this topic was on the agenda of secdispatch, and the actual dispatch would be done there. Carsten Bormann wanted to know what the use case was and commented that it was a deterministic mapping ..., and that JSON has refused to define the data model. This would define _a_ data model, but not _the_ JSON data model. Carsten had issues with mapping specifics that he didn't need to cover at the mic. He didn't like the idea of embedded signatures. He thought a mapping to JSON ... was a good thing to have. Anders said that comparing output data was out of scope ... Matt Miller thought it was probably ok for what it was defining, but needed a better understanding of use cases. Eric Rescorla said that when JOSE was designed, canonicalization had been eschewed because previous attempts had been debacles and that wrapping was better, with sharp containment between wrapper and what was being signed... and wondered what was wrong with what we have? Anders said that it works, but is not readable. Eric said that it's readable, just not legible. Jeffrey said ... and agreed with Carsten. Carsten pointed out that the ...64 problem comes up in other environments, and that CBOR covers this. Deterministic serialization ... Martin Thomson ... and that a warning should be added. Cullen said that the point of JSON is to be human readable, and mistakes were made with STIR token signatures. Pete Resnick pointed out that encode the whole thing is inconvenient, because you can't manipulate the internal bits. There were advantages to ..., but that a security person would say not to do that. Mary cut the discussion due to lack of remaining time and that it would also be discussed in secdispatch. ---------------------------------------------------------- Relay User Machine (RUM) Presenter: Brian Rosen Charter proposal: https://mailarchive.ietf.org/arch/msg/dispatch/DulYa- smNK96RXGos_x_lEjeUw8 slides: = https://datatracker.ietf.org/meeting/104/materials/slides-104-dispatch- relay-user-machine-rum-00 Ben pointed out that the working group would be formed within the next few weeks, and that the charter is in external review. Paul Kyzivat, participating remotely, wondered if Meetecho would be available for the Wednesday meeting. Brian Rosen said that side meetings don't have Meetecho support and he didn't like it. Paul pointed out that it was more than just a SIP profile. Brian agreed and how much to include would be up to the WG. Aaron Falk wondered if it could cover any language translator use case? Brian thought it could work, and the charter could be modified if people were interested. Martin Thomson asked what thinking had gone into the security issues surrounding the man-in-the-middle use cases. Brian agreed that it needed more scrutiny. Jonathan Lennox said ... Brian said that they would fix it, and also would talk to Chris Wendt and Jon Peterson. Brian said that they'll ask the working group to adopt draft-rosen-rue-00, but the WG does't have to do that. # Raw Notes from Pete Resnick DISPATCH WG / ART Area Meeting. IETF 104 Mary Barnes and Ben Campbell chairing Pete Resnick taking minutes. https://datatracker.ietf.org/group/dispatch/meetings/ https://datatracker.ietf.org/meeting/104/session/dispatch Chairs rewiew Note Well, Agenda. Deadlines reviewed. A review of distinction of ART and DISPATCH lists, BOFs and other meetings this week, and new WGs. Thanks to previous co-chairs, and intro of new co-chair. Web Packaging: https://datatracker.ietf.org/meeting/104/materials/slides-104-dispatch- web-packaging-01.pdf WPACK is having a meeting on Wed (unfortunately against DOH). Comments: Eric Rescorla: This is a pretty big architectural change. A BOF should probably review use cases, not just jump into the protocol discussion of this proposal. Wendy Seltzer: W3C also has concerns about connection between use cases and solutions. Mark Nottingham: We need a BOF to actually have a discussion. Heard from several folks that use cases might not lead to web packaging. Are you still on board if the solution doesn't look like WPACK? Jeffrey: Yes, so long as we can get AMP to switch over to whatever we produce. Cullen Jennings: What's the interaction between IETF, W3C, and WHATWG? What's IETF's rule. Jeffrey: Security issues are the most important bit that IETF brings to table. IETF defines format; W3C defines algorithms to load it. W3C vs. WHATWG will be dealt with by them. Ted Hardie: BOF as next step makes sense. Should we figure out split before or after BOF? Side meeting should think about that. Anti-censorship use case is most interesting. Some folks would want this if it's available in common applications; don't want to identify folks who want anti-censorship, as that flags people who don't want flagging. Martin Thomson: BOF should definitely involve people who are going to implement this, and make sure they participate. That includes the AMP team, though other folks too (e.g., Apple News, etc.). Should reach out to them and get them to at least join the list. Dan York: Need BOF so that we can get use cases resolved. As web publisher, I have particular things in mind. Eric Rescorla: Getting AMP committed to this work is essential. If AMP isn't going to participate, no need to bother. Cullen Jennings: If a group who is going to change a fundemental architecture won't show up, that's not going to go over well. They really should show up in person. Eric Burger: Do we really want in-person to be a requirement? Cullen: Yes. Chair summary: We think a BOF is a good idea. Focus on right use cases. Implementers and users must be engaged in process. JSContact: https://datatracker.ietf.org/meeting/104/materials/slides-104-dispatch- json-contact-00 Comments: Daniel Migault: Merging the assorted WGs who deal with this sort of thing would be good. Perhaps calext is the right place. Cullen Jennings: Given that this also interacts in the collaboration/messaging folks, a small focused WG might be better. Barry Leiba: Lean toward Cullen's proposal. If we use existing, JMAP seems better. Also: VCARD versions tend to get occified, so try to keep as much mapping as possible so that you can port to older versions. Jim Fenton: VCARD isn't loved, but it would be hard to get people to change to this. Do you have some sense that this would be adopted? Robert Stepanek: It is an experiment at this stage. Barry Leiba: New implementations tend to implement new versions of VCARD. We may get new implementations will use this, but older implementations will not. Chris Newman: This has potential to deploy because the change in network API model has changed to the JSON model, meaning this might stick. Support this work. Alexey Melnikov summary: Some interest, not clear whether this goes to CALEXT, JMAP, or new WG. Still not clear how much implementation interest there is. Should discover that on the list. Chair query: Are there implementers in here? 4-5 people raise hands. Jon Peterson: We're shopping for a way to do VCARD in JSON. If this is better than the current standard, then we'd probably use it. Chair summary: Worth putting in more work for this and discussing on the list, and perhaps re-dispatch if needed. Aaron Falk: Proposal at HotRFC for BRAID. Might be worth discussing as a dispatchable proposal. JSON Canonicalization Scheme: https://datatracker.ietf.org/meeting/104/materials/slides-104-dispatch- json-canonicalization-scheme-jcs-00 Comments: Richard Barnes: Also on the agenda for SECDISPATCH, and will likely be dispatched there. Carsten Borman: One problem is that the JSON creator won't define the data model. We did that part way with I-JSON. We need to define the data model (and that would be a good thing). Some particular things that I don't like in the proposal, but that can be discussed later. Finally: What is the use case? This could be used for comparing output data. Even though the embedded data model for strings is out of scope, applications could take that on with specific standards for them. Overall, this is a good thing to have, and I have at least one use case. I don't like embedded signatures, but we can discuss that in SECDISPATCH. We should discuss this in a wider context than just signatures. Matthew Miller: It would be nice to figure out the cases. The simple JSON data types only get you so far. This might be a starting point, but we must be careful. Eric Rescorla: When we defined JOSE, we explicitly eschewed canonicalization. This (for better or worse) backtracks on that decision. Legibility seems to be the issue. Why is wrapping a bad thing? Readability. Jeffrey Raskin: Agree with Carsten that a deterministic serialization is useful. Carsten Borman: The BASE64 problem comes up in other environments (cf: CBOR). Eric Rescorla: Let's be clear on whether this is for security purposes or some other purposes. Carsten Borman: Not only a JSON issue, but an application issue. Somebody has to take care of deterministic encoding. This is a superset of the current proposal. Martin Thomson: If we define a canonicalization without being designed for security, it's still going to be used for security. Cullen Jennings: The point of JSON is to put it in human readable form, and this does that. We have made this mistake before. Eric Rescorla: We don't want applications to avoid the security stuff, so having a bucket of bits can be a good thing. Pete Resnick: But that is a tradeoff, because applications also want to examine certain parts before handed to security protocols. Chair summary: This will be dispatched by SECDISPATCH, but there may be application interactions that need to be acconted for. Relay User Machine: https://datatracker.ietf.org/meeting/104/materials/slides-104-dispatch- relay-user-machine-rum-00 Chair comment: This is already in the WG-forming process There is a Wednesday side meeting, but no Meetecho support. Comments: Paul Kyzivat: This seems beyond a SIP profile, given the provisioning stuff. The SIP SDP media piece is really the imporant stuff. Aaron Falk: Is this specific to sign-language translation, or could you put (e.g.) a language translation mecahism in the same slot? How specific is this? Brian: It should just work. We could put this in the charter. Martin Thomson: Suggest that "M" stands for man-in-the-middle. Perhaps that issue should be considered. Need to have mechanism to assure you're talking to the right endpoint, and someone gets to choose the MITM. (Current default is the originator who chooses.) Perhaps this should be in the charter. Jonathan Lennox: Want to also assure that the translation service is authenticated. Cullen Jennings: Need to limit security mechanisms to what will reasonably deploy. Eric Burger: 90% of the "am I talking with who I think I am talking with" is already in SIP. Brian: Still might need to authenticate original caller. --Apple-Mail=_6FF87BD3-D56D-43F5-8BCF-8AE52BDFC561 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello= Everyone:

The = preliminary minutes for DISPATCH at IETF 104 are available at the = following link, and also copied below for your convenience. Please send = comments and corrections to the dispatch list and copy the chairs = directly.

Many = thanks to Jean and Pete for taking notes!

https://datatracker.ietf.org/meeting/104/materials/minutes-104-= dispatch-00


Thanks!

Ben.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

# DISPATCH Minutes - IETF =
104: Monday, 25 March, 2019 Prague

Chairs: Mary Barnes, Ben Campbell.

The chairs would like to thank our note takers for
their excellent notes: Jean Mahoney, Pete Resnick

See DISPATCH wiki for additional links to materials:
https://trac.ietf.org/trac/dispatch/wiki

# Summary:

DISPATCH Meeting=20
------------------

### Status and agenda bash - Chairs (10 min)
=20
The chairs thanked the outgoing chairs (Cullen and Murray) and welcomed
the incoming chair (Ben). Mary presented a token of appreciation to the
outgoing ART AD (Ben) The order of discussions was changed to accomodate
a travel delay by one of the presenters.


### Relay User Machine (RUM) - Brian Rosen
=20
(Presented last due to Brian's travel delay)

Brian provided an overview of the proposed RUM charter and
draft-rosen-rue-00.

RUM was not dispatched, since a working group charter is already in
external review and expected to be approved soon. A side meeting was
also planned for later in the week.

### JSON Contact - Bron Gondwana and Robert Stepanek(remote)

Robert presented a summary of draft-stepanek-jscontact.

There was discussion about whether this work should go into a new,
focused WG vs CALEXT. 4 or 5 people indicated that they were likely to
implement it.

The work needs some refinement and more discussion prior to making a
dispatch recommendation. DISPATCH may look at this again in the future.
List discussion was encouraged. The chairs noted that this need not wait
for IETF 105 for further discussion.

### Web Packaging - Jeffrey Yasskin (20 min)=20

Jeffery presented draft-yasskin-dispatch-web-packaging and discussed
changes since previous discussion of the concept.

The work needs feedback from deployments. The IAB is organizing the
ESCAPE workshop to get feedback from publishers. There will be a side
meeting on Wednesday. It is likely that part of the work should be in
the W3C.

The room agreed that it would be appropriate to plan a BoF. We need to
focus first on selecting the right use cases. Direct engagement from
implementers will be important for success.

### Other Business

Aaron Falk mentioned the proposal for BRAID at HotRFC as a potentially
dispatchable proposal.


ART AREA Meeting
 -------------------

# JSON Canonicalization Scheme (JCS) - Anders Rundgren (20)

Anders presented draft-rundgren-json-canonicalization-scheme and=20
received feedback. The draft was also expected to be discussed in
SECDISPATCH.

We need to better understand the use cases. There are both security and
application aspects.

# Raw Notes from Jean Mahoney

Dispatch - IETF 104

Monday morning session I Congress Hall 3

Chairs: Ben Campbell, Mary Barnes

Note takers: Pete Resnick, Jean Mahoney Jabber scribe: Matt Miller

DISPATCH wiki: https://trac.ietf.org/trac/dispatch/wiki

----------------------------------------------------------=20
Status and agenda bash Presenters: Mary, Ben=20
slides:
https://datatracker.ietf.org/meeting/104/materials/slides-104-d=
ispatch-
chairs-agenda-and-status-02

The schedule of presentations changed due to travel delays experienced
by a presenter.

Mary Barnes thanked Cullen Jennings and Murray Kucherawy for their work
as DISPATCH co-chairs, and welcomed Ben Campbell as the new co-chair.
Mary presented Ben with a token of appreciation for his work as ART AD
(a bottle of Czech rum), and let him know that another gift would be
shipped to his home address.

----------------------------------------------------------=20
Web Packaging
Presenter: Jeffrey Yasskin Discussion:
https://mailarchive.ietf.org/arch/msg/dispatch/
e6ZSh7ocW6n2afnbwGzBlX1WT8Y slides:
https://datatracker.ietf.org/meeting/104/materials/slides-104-d=
ispatch-
web-packaging-01

Jeffrey said that he needed feedback from deployments. Mark Nottingham
and the IAB are organizing the ESCAPE workshop to get feedback from
publishers. There will be a side meeting on Wednesday. He thought that
part of the work should be in the W3C, and part in HTTPWG.

Eric Rescorla suggested a bof be held and that the bof should discuss
use cases. Eric pointed out that the answer to the given use cases may
not be the solution that Jeffery is proposing, and didn't think that all
use cases given were equally important.

Wendy Seltzer said that the W3C is interested in the use cases and want
to be part of the discussion. There were distances between use cases and
solutions.

Mark Nottingham thought that a bof was needed. He wondered if Jeffery
would be willing to accept consensus if the IETF community determined
that the solution to the use cases wasn't the one that Jeffrey was
proposing.

Jeffrey thought that he could.

Cullen asked what Jeffrey expected from the IETF.

Jeffery said he needed the security expertise in HTTPS, TLS and that the
IETF would define the format while the W3C would define the algorithms
for loading.

Ted Hardy agreed that a bof was the next step, but wondered if it was a
task for the bof to determine the split of work, or would that be
decided before the bof, and suggested that the Wednesday side meeting be
used to discuss that. Ted was interested in the anti-censorship use
case.

Martin Thomson wanted to know who would implement it, and said that the
implementers needed to show up at the IETF.

Dan York agreed that a bof was needed, but said that we needed to know
that the solution would be used.

Eric Rescorla emphasized that if the implementors don't participate,
there's no point in pursuing it.

Cullen Jennings said that if a group of people want to change the
architecture fundamentally but don't show up, they won't be taken
seriously.

Jeffrey thought he could get the implementers to participate remotely.

Ben Campbell, as chair stated for the minutes: A bof is a good idea,
need to focus on right use cases first, the people who are going to
implement it need to be engaged in the process.


----------------------------------------------------------=20
JSON Contact

Presenter: Robert Stepanek (remote), Bron Gondwana Discussion:
https://mailarchive.ietf.org/arch/msg/dispatch/
IEwBrtBUZfAsD_usDt40HDBBTB0 Draft: draft-stepanek-jscontact slides:
https://datatracker.ietf.org/meeting/104/materials/slides-104-d=
ispatch-
json-contact-00

Daniel Migault, as CALEXT co-chair, was in favor of bringing the working
into the CALEXT working group.

Cullen argued for a new, focused working group since CALEXT didn't do
messaging.

Barry Leiba sided with Cullen on a new, focused WG. He pointed out that
vCard versions get ossified, with new implementations using new version
of vCards, while older implementations stay with older versions. He
suggested keep as much mapping as possible so it can be ported.

Robert Stepanek said that they would reuse as much as possible but
couldn't guarantee 100% compatibility.

Jim Fenton asked if Robert had a feel for how well this would be
adopted.

Robert said they were early in the process and that it was experimental.

Chris Newman felt that it created an opportunity to get address books
integrated more effectively with other protocols.

Alexey Melnikov, as AD, said that he heard some interest, but it was not
clear whether it will go CALEXT, JMAP or a new working group.

Ben Campbell asked for a show of hands if anyone was interested in
implementing it. Four or five people raised their hands.

Jon Peterson said there was already a draft on how to do vCard with
JSON. He might implement this if it were better, but the draft was at
too early a stage to tell.

Mary Barnes, as chair, said that more work needed to go into this for
people to discuss.

Alexey, as AD, said that an updated draft and more discussion was
needed, then it could be re-dispatched.

Ben Campbell, as chair, pointed out it could be discussed on list and
the WG didn't have to wait until Montreal to dispatch.


----------------------------------------------------------=20
JSONCanonicalization Scheme (JCS) Presenter: Anders Rundgren=20
Document: draft-rundgren-json-canonicalization-scheme

Richard Barnes pointed out that this topic was on the agenda of
secdispatch, and the actual dispatch would be done there.

Carsten Bormann wanted to know what the use case was and commented that
it was a deterministic mapping ..., and that JSON has refused to define
the data model. This would define _a_ data model, but not _the_ JSON
data model. Carsten had issues with mapping specifics that he didn't
need to cover at the mic. He didn't like the idea of embedded
signatures. He thought a mapping to JSON ... was a good thing to have.

Anders said that comparing output data was out of scope ...

Matt Miller thought it was probably ok for what it was defining, but
needed a better understanding of use cases.

Eric Rescorla said that when JOSE was designed, canonicalization had
been eschewed because previous attempts had been debacles and that
wrapping was better, with sharp containment between wrapper and what was
being signed... and wondered what was wrong with what we have?

Anders said that it works, but is not readable.

Eric said that it's  readable, just not legible.

Jeffrey said ... and agreed with Carsten.

Carsten pointed out that the ...64 problem comes up in other
environments, and that CBOR covers this. Deterministic serialization ...

Martin Thomson ... and that a warning should be added.

Cullen said that the point of JSON is to be human readable, and mistakes
were made with STIR token signatures.

Pete Resnick pointed out that encode the whole thing is inconvenient,
because you can't manipulate the internal bits. There were advantages to
..., but that a security person would say not to do that.

Mary cut the discussion due to lack of remaining time and that it would
also be discussed in secdispatch.

----------------------------------------------------------=20
Relay User Machine (RUM)=20
Presenter: Brian Rosen Charter=20
proposal: https://mailarchive.ietf.org/arch/msg/dispatch/DulYa-
smNK96RXGos_x_lEjeUw8=20
slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-d=
ispatch-
relay-user-machine-rum-00

Ben pointed out that the working group would be formed within the next
few weeks, and that the charter is in external review.

Paul Kyzivat, participating remotely, wondered if Meetecho would be
available for the Wednesday meeting.

Brian Rosen said that side meetings don't have Meetecho support and he
didn't like it.

Paul pointed out that it was more than just a SIP profile.

Brian agreed and how much to include would be up to the WG.

Aaron Falk wondered if it could cover any language translator use case?

Brian thought it could work, and the charter could be modified if people
were interested.

Martin Thomson asked what thinking had gone into the security issues
surrounding the man-in-the-middle use cases.

Brian agreed that it needed more scrutiny.

Jonathan Lennox said ...

Brian said that they would fix it, and also would talk to Chris Wendt
and Jon Peterson.

Brian said that they'll ask the working group to adopt
draft-rosen-rue-00, but the WG does't have to do that.

# Raw Notes from Pete Resnick
=20
DISPATCH WG / ART Area Meeting. IETF 104 Mary Barnes and Ben Campbell
chairing Pete Resnick taking minutes.

https://datatracker.ietf.org/group/dispatch/meetings/
https://datatracker.ietf.org/meeting/104/session/dispatch

Chairs rewiew Note Well, Agenda.

Deadlines reviewed.

A review of distinction of ART and DISPATCH lists, BOFs and other
meetings this week, and new WGs.

Thanks to previous co-chairs, and intro of new co-chair.

Web Packaging:

https://datatracker.ietf.org/meeting/104/materials/slides-104-d=
ispatch-
web-packaging-01.pdf

WPACK is having a meeting on Wed (unfortunately against DOH).

Comments: Eric Rescorla: This is a pretty big architectural change. A
BOF should probably review use cases, not just jump into the protocol
discussion of this proposal. Wendy Seltzer: W3C also has concerns about
connection between use cases and solutions. Mark Nottingham: We need a
BOF to actually have a discussion. Heard from several folks that use
cases might not lead to web packaging. Are you still on board if the
solution doesn't look like WPACK? Jeffrey: Yes, so long as we can get
AMP to switch over to whatever we produce. Cullen Jennings: What's the
interaction between IETF, W3C, and WHATWG? What's IETF's rule. Jeffrey:
Security issues are the most important bit that IETF brings to table.
IETF defines format; W3C defines algorithms to load it. W3C vs. WHATWG
will be dealt with by them. Ted Hardie: BOF as next step makes sense.
Should we figure out split before or after BOF? Side meeting should
think about that. Anti-censorship use case is most interesting. Some
folks would want this if it's available in common applications; don't
want to identify folks who want anti-censorship, as that flags people
who don't want flagging. Martin Thomson: BOF should definitely involve
people who are going to implement this, and make sure they participate.
That includes the AMP team, though other folks too (e.g., Apple News,
etc.). Should reach out to them and get them to at least join the list.
Dan York: Need BOF so that we can get use cases resolved. As web
publisher, I have particular things in mind. Eric Rescorla: Getting AMP
committed to this work is essential. If AMP isn't going to participate,
no need to bother. Cullen Jennings: If a group who is going to change a
fundemental architecture won't show up, that's not going to go over
well. They really should show up in person. Eric Burger: Do we really
want in-person to be a requirement? Cullen: Yes. Chair summary: We think
a BOF is a good idea. Focus on right use cases. Implementers and users
must be engaged in process.

JSContact:

https://datatracker.ietf.org/meeting/104/materials/slides-104-d=
ispatch-
json-contact-00

Comments: Daniel Migault: Merging the assorted WGs who deal with this
sort of thing would be good. Perhaps calext is the right place. Cullen
Jennings: Given that this also interacts in the collaboration/messaging
folks, a small focused WG might be better. Barry Leiba: Lean toward
Cullen's proposal. If we use existing, JMAP seems better. Also: VCARD
versions tend to get occified, so try to keep as much mapping as
possible so that you can port to older versions. Jim Fenton: VCARD isn't
loved, but it would be hard to get people to change to this. Do you have
some sense that this would be adopted? Robert Stepanek: It is an
experiment at this stage. Barry Leiba: New implementations tend to
implement new versions of VCARD. We may get new implementations will use
this, but older implementations will not. Chris Newman: This has
potential to deploy because the change in network API model has changed
to the JSON model, meaning this might stick. Support this work. Alexey
Melnikov summary: Some interest, not clear whether this goes to CALEXT,
JMAP, or new WG. Still not clear how much implementation interest there
is. Should discover that on the list. Chair query: Are there
implementers in here? 4-5 people raise hands. Jon Peterson: We're
shopping for a way to do VCARD in JSON. If this is better than the
current standard, then we'd probably use it. Chair summary: Worth
putting in more work for this and discussing on the list, and perhaps
re-dispatch if needed.

Aaron Falk: Proposal at HotRFC for BRAID. Might be worth discussing as a
dispatchable proposal.

JSON Canonicalization Scheme:

https://datatracker.ietf.org/meeting/104/materials/slides-104-d=
ispatch-
json-canonicalization-scheme-jcs-00

Comments: Richard Barnes: Also on the agenda for SECDISPATCH, and will
likely be dispatched there. Carsten Borman: One problem is that the JSON
creator won't define the data model. We did that part way with I-JSON.
We need to define the data model (and that would be a good thing). Some
particular things that I don't like in the proposal, but that can be
discussed later. Finally: What is the use case? This could be used for
comparing output data. Even though the embedded data model for strings
is out of scope, applications could take that on with specific standards
for them. Overall, this is a good thing to have, and I have at least one
use case. I don't like embedded signatures, but we can discuss that in
SECDISPATCH. We should discuss this in a wider context than just
signatures. Matthew Miller: It would be nice to figure out the cases.
The simple JSON data types only get you so far. This might be a starting
point, but we must be careful. Eric Rescorla: When we defined JOSE, we
explicitly eschewed canonicalization. This (for better or worse)
backtracks on that decision. Legibility seems to be the issue. Why is
wrapping a bad thing? Readability. Jeffrey Raskin: Agree with Carsten
that a deterministic serialization is useful. Carsten Borman: The BASE64
problem comes up in other environments (cf: CBOR). Eric Rescorla: Let's
be clear on whether this is for security purposes or some other
purposes. Carsten Borman: Not only a JSON issue, but an application
issue. Somebody has to take care of deterministic encoding. This is a
superset of the current proposal. Martin Thomson: If we define a
canonicalization without being designed for security, it's still going
to be used for security. Cullen Jennings: The point of JSON is to put it
in human readable form, and this does that. We have made this mistake
before. Eric Rescorla: We don't want applications to avoid the security
stuff, so having a bucket of bits can be a good thing. Pete Resnick: But
that is a tradeoff, because applications also want to examine certain
parts before handed to security protocols. Chair summary: This will be
dispatched by SECDISPATCH, but there may be application interactions
that need to be acconted for.

Relay User Machine:

https://datatracker.ietf.org/meeting/104/materials/slides-104-d=
ispatch-
relay-user-machine-rum-00

Chair comment: This is already in the WG-forming process

There is a Wednesday side meeting, but no Meetecho support.

Comments: Paul Kyzivat: This seems beyond a SIP profile, given the
provisioning stuff. The SIP SDP media piece is really the imporant
stuff. Aaron Falk: Is this specific to sign-language translation, or
could you put (e.g.) a language translation mecahism in the same slot?
How specific is this? Brian: It should just work. We could put this in
the charter. Martin Thomson: Suggest that "M" stands for
man-in-the-middle. Perhaps that issue should be considered. Need to have
mechanism to assure you're talking to the right endpoint, and someone
gets to choose the MITM. (Current default is the originator who
chooses.) Perhaps this should be in the charter. Jonathan Lennox: Want
to also assure that the translation service is authenticated. Cullen
Jennings: Need to limit security mechanisms to what will reasonably
deploy. Eric Burger: 90% of the "am I talking with who I think I am
talking with" is already in SIP. Brian: Still might need to authenticate
original caller.






= --Apple-Mail=_6FF87BD3-D56D-43F5-8BCF-8AE52BDFC561-- --Apple-Mail=_9FF0126F-D5AA-4FC4-B56D-9085AA253A8A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlyd87YACgkQgFZKbJXz 1A0/JxAAiNp7lijhbNsHyniaalZkcGpLgJrcryf+BuAMixLFtSU5ee4gyMXkLAGa ziAFuyrv4rvVNaCegHG6KDDpcYgq7OpSHw+XfFigv2pulxE9Lgoiu/HS5uv+PblN 7kH5thXO92++3BXb8iM6fmTKqkwPnNSujIp4QlMAHGaAfGelU37XFnRBln2KT04k BhjYez3BUStodTNiVO8zNC31HNSDGE1bNphLNcZ92IWAPGpfd24zJVkedpA6YJs7 BJoL844MaviibuAkUf+0KqisA4aBGHSqP+4rTTVQsu+YWBENwti5xolyk6ICjcMp pvSBwnqm6mK8pULhyWw3DXjb9KVAm2900rmiWj4DP1YCqXwOLarRXpg0dnxdootW QWbp9buRyqvfpDpqXaRGMNlW0hbn1RPTiDu8pp2SEHcv9ecQ388jRc7UFKkVeixD SR/wIZgp2NOrfAntxG22sqoBVneMzXCOCwRmLZpPIt6IkDaT/cc90LeIkBIOz6b1 fqaKUJiJ928zEdntbP0x5gG2AqZ86vetrdDkt5eVxOEvSRXrCJuFQ9rFEqq95bjD J/snMU8YV4oqOzBp65aHrjA/SZh1b/GBxBLK2+GBFBaNLrYKp1pBMAPT5yqbdd+i 9ZiCP+aGCuePYEwmA79OlfcEi6ChOLiSz+mOIHRfaLZU7cau3Mo= =Hbms -----END PGP SIGNATURE----- --Apple-Mail=_9FF0126F-D5AA-4FC4-B56D-9085AA253A8A--