Re: [mile] Ben Campbell's Discuss on draft-ietf-mile-xmpp-grid-09: (with DISCUSS and COMMENT)

Peter Saint-Andre <stpeter@mozilla.com> Mon, 25 March 2019 13:32 UTC

Return-Path: <stpeter@mozilla.com>
X-Original-To: mile@ietfa.amsl.com
Delivered-To: mile@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9D81203F0 for <mile@ietfa.amsl.com>; Mon, 25 Mar 2019 06:32:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 VgW_0h-xcOdA for <mile@ietfa.amsl.com>; Mon, 25 Mar 2019 06:32:50 -0700 (PDT)
Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 E9C091204B4 for <mile@ietf.org>; Mon, 25 Mar 2019 06:32:46 -0700 (PDT)
Received: by mail-pf1-x42d.google.com with SMTP id 10so6448263pfo.5 for <mile@ietf.org>; Mon, 25 Mar 2019 06:32:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:from:to:cc:references:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=TNNxksWKDVrUUrcBqO3R30c7+9rLWJLRqv9/BUhuuNg=; b=c5lEL6lZPoiFGX5WnAvzfqE+vUCoYNDgpz4SZdGK64LTQ8iVOY7LdTBOI5XZ8w5hKk QArhH1cbqeAKNMSWuw1RalcXZGFBahHaIm1Nc8NkvuSOiPPuUZublmtwWPqODEpEcWih bUvwYCLbhi0PFLpy8E+CbzHoTGUIpAwiq9wEs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=TNNxksWKDVrUUrcBqO3R30c7+9rLWJLRqv9/BUhuuNg=; b=b90qdEXIqfqx9nNfvObZmRvrx6FEX4CoLaYY9DnzVl/3dDm0MPgDV7rUkb7xItWZho aCCfWkPIi9Ycdh6F3aEKYhMXUPZSS3EHK4KyzKpLR6gqTf49ACRRDz1Im9rT2uY63aeT 42z9iaywWP+wlj6OIB8/clBef4RHRXtyvLaagsD/X3Eo+FuXkZw5hi9lYj7ASua75q29 iQVX+4B4JyWBRxX8Z2fQFDhiDkPk0eiclgEivAQbe0BmCQroCO+GPRQBwFauc5QJKj50 NXJgltKJb5abLmTq4WV4A18hM0kxS0mxvsrpJftAnhNG613NY98I/Qnb5jkhhBg3fgYE ptYQ==
X-Gm-Message-State: APjAAAUlZxE7o9eZH4xu2fDlNI2MVzVlg5FQFXpHLnnon8d5V9Lv3wZC Lbj/o9u4Yapki4Ry4xcBLh5ZtQ==
X-Google-Smtp-Source: APXvYqxRkFbHv9zWKv3JEdlKpz/RSKefFvHC0UaYVKL3kB9FNxGaO66aFwiyt2Rg6UXkiFZgsneQCA==
X-Received: by 2002:a17:902:42:: with SMTP id 60mr25085838pla.132.1553520766140; Mon, 25 Mar 2019 06:32:46 -0700 (PDT)
Received: from dragon.local ([74.85.93.170]) by smtp.gmail.com with ESMTPSA id m69sm28904621pfi.151.2019.03.25.06.32.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Mar 2019 06:32:45 -0700 (PDT)
From: Peter Saint-Andre <stpeter@mozilla.com>
To: Ben Campbell <ben@nostrum.com>
Cc: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>, "draft-ietf-mile-xmpp-grid@ietf.org" <draft-ietf-mile-xmpp-grid@ietf.org>, "mile-chairs@tools.ietf.org" <mile-chairs@tools.ietf.org>, Takeshi Takahashi <takeshi_takahashi@nict.go.jp>, The IESG <iesg@ietf.org>, "mile-chairs@ietf.org" <mile-chairs@ietf.org>, "mile@ietf.org" <mile@ietf.org>
References: <154821326562.13271.17282561556237229622.idtracker@ietfa.amsl.com> <4BD85B49-9F10-4724-B5C7-B4257D8A83CD@cisco.com> <8125411B-783D-4469-B60B-422FA4E447FF@cisco.com> <50DCB5B2-8045-4878-ACA2-A9BE1246DFF1@cisco.com> <C92CD6AF-CC03-4734-8CB4-2FACD071EBFC@cisco.com> <840D870A-36F9-4B32-918B-8F4A3D04EBDF@cisco.com> <7F9B5B96-D304-44B4-88D3-A598450477FF@nostrum.com> <2cee29b8-99ce-2053-6044-2c2e4c501557@mozilla.com> <67A5EFDB-F42F-4FE3-8DB0-9280B06C9289@nostrum.com> <0c972a62-9086-769e-5474-c40557be3e2f@mozilla.com>
Openpgp: preference=signencrypt
Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= mQINBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABtCdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT6JAlQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekLkCDQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAYkCPAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V
Message-ID: <6e2d2076-198d-7085-0cec-5c0ae5e852d3@mozilla.com>
Date: Mon, 25 Mar 2019 07:32:43 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.3
MIME-Version: 1.0
In-Reply-To: <0c972a62-9086-769e-5474-c40557be3e2f@mozilla.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="C4kV0v4NNcN4S9VTcj94cXiJDtX4AFMs9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/taQFRMLMv9ZEgDiBDw7mzLa1O_g>
Subject: Re: [mile] Ben Campbell's Discuss on draft-ietf-mile-xmpp-grid-09: (with DISCUSS and COMMENT)
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mile/>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Mar 2019 13:32:59 -0000

On 3/24/19 4:06 PM, Peter Saint-Andre wrote:
> Hi Ben, thanks for continuing to engage on these topics. Replies inline.
> 
> On 3/24/19 3:55 PM, Ben Campbell wrote:
>>
>>
>>> On Mar 24, 2019, at 10:14 PM, Peter Saint-Andre <stpeter@mozilla.com>; wrote:
>>>
>>> On 3/24/19 1:32 PM, Ben Campbell wrote:
>>>> Hi, apologies for not getting back to this sooner. I’m trying to close
>>>> or clarify my DISCUSS points prior to stepping down from the IESG this
>>>> week. Please see inline:
>>>>
>>>> Thanks!
>>>>
>>>> Ben.
>>>>
>>>>> On Mar 4, 2019, at 6:49 PM, Nancy Cam-Winget (ncamwing)
>>>>> <ncamwing@cisco.com <mailto:ncamwing@cisco.com>> wrote:
>>>>>
>>>>> Hi Ben,
>>>>>     Thanks for the careful review and comments, please see answers below:
>>>>>
>>>>>     On 1/22/19, 19:14, "Ben Campbell" <ben@nostrum.com
>>>>> <mailto:ben@nostrum.com>> wrote:
>>>>>
>>>>>
>>>>>         ----------------------------------------------------------------------
>>>>>         DISCUSS:
>>>>>
>>>>> ----------------------------------------------------------------------
>>>>>
>>>>>         Hi, thanks for the readable approach to this. I like the plain
>>>>> English approach
>>>>>         to the security considerations, in particular. But I do have
>>>>> some comments,
>>>>>         including a couple that I think needs to be resolved before
>>>>> progressing the
>>>>>         draft:
>>>>>
>>>>>         1) I was surprised not to see a discussion of the "never-meet"
>>>>> problem. That
>>>>>         is, what happens if a provider and a consumer never connect
>>>>> with the controller
>>>>>         at the same time. Is the controller expected to
>>>>> store-and-forward items
>>>>>         submitted to a topic prior to when the consumer connects? IIRC
>>>>> (and I apologize
>>>>>         that I did not have time to refresh my memory on the
>>>>> referenced XEPs), that
>>>>>         sort of behavior is optional under XEP-0060. Is it required
>>>>> for this use case?
>>>>>         Is support for delayed delivery (xep-0203) or something
>>>>> similar required? Or
>>>>>         perhaps platforms are expected to keep long-lived connections?
>>>>>     [NCW] I think this is an implementation detail, but we've added a
>>>>> sentence in section 4
>>>>>     To describe that it is an option per XEP-0060.
>>>>
>>>> I’m not sure that’s enough to solve the isssue. I think this is more
>>>> than an implementation detail. I think there’s some implicit assumptions
>>>> about how and when providers and consumers connnect to the server that
>>>> are required for interoperation. These should be explicit. For example,
>>>> do you expect that consumers will maintain long-lived connections to the
>>>> server, or just connect occasionally to download any waiting data? If
>>>> there are several new pieces of data published while a consumer is not
>>>> connected, do they expect to download all the changes or just the
>>>> latest? (i,e does this require the server to be configured for
>>>> persistent items?)
>>>
>>> The "never-meet" problem isn't really a problem in XMPP - all servers
>>> implement support for so-called "offline messages" and the message
>>> delivery semantics defined in Section 8 of RFC 6121 take full account of
>>> eventual delivery by servers to clients that are not online at the time
>>> the message was created. A reference to RFC 6121 should be sufficient to
>>> correctly specify this behavior.
>>
>>
>> I agree referencing RFC 6121 would help.  I had missed the fact the examples use ‘message' stanzas (although if there is normative text that says to do that, I have still missed it.)
> 
> XEP-0060 uses message stanzas for content delivery.
> 
>> Am I mistaken to remember that offline-storage is still optional even for message stanzas?
>>
>> In any case, a mention of the use of offline-storage as described in 6121 would be sufficient to for me to clear on this point. It would be nice for it to suggest (normatively or otherwise) the use of offline-storage, or at least point out the consequences of not using it.
> 
> Specifying that servers MUST support offline storage for these use cases
> seems appropriate. I can't remember why we said it was only SHOULD-level
> in the updated XMPP RFCs (6120 & 6121) - that was silly of us.

I propose that we add the following paragraph at the end of Section 6
("Publish-Subscribe"):

   Note that [XEP-0060] uses the XMPP <message/> stanza for delivery of
   content.  To ensure that messages are delivered to the Consumer even
   if the Consumer is not online at the same time that the Publisher
   generates the message, an XMPP-Grid Controller MUST support "offline
   messaging" delivery semantics as specified in [RFC6121], best
   practices for which are further explained in [XEP-0160].

Peter


Peter