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

Ben Campbell <ben@nostrum.com> Sun, 24 March 2019 22:15 UTC

Return-Path: <ben@nostrum.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 4321A12016E; Sun, 24 Mar 2019 15:15:37 -0700 (PDT)
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 yjUFfj_9EV4h; Sun, 24 Mar 2019 15:15:35 -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 8CC5C12018C; Sun, 24 Mar 2019 15:15:35 -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 x2OMFS51062385 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 24 Mar 2019 17:15:30 -0500 (CDT) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1553465733; bh=/MtVoJWy7FJrwqTK7BaGFJlKLE0/tB3N2a30YCfD0m8=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=FI/QOdDDsKdtzAvXvpMu/CGuRMkKeJs1wWRojrrpze+Yxa4T7dJtj1W1hIpw6aGYT U5EAlhijWusQw4uqAI5dwNjtrotAWIRTVCc9MdFiLxFOr6iIC4yn4hAkRtXjRLhvBi 0IJvR7EWbjTK+6HZ2V6wvZEg/xN6OsbXkQziM+Xg=
From: Ben Campbell <ben@nostrum.com>
Message-Id: <22FDF515-3D2B-444B-9985-009D7DC93191@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_04158E75-9B39-4616-85EB-62E1856CBE9A"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Sun, 24 Mar 2019 23:15:27 +0100
In-Reply-To: <0c972a62-9086-769e-5474-c40557be3e2f@mozilla.com>
Cc: "draft-ietf-mile-xmpp-grid@ietf.org" <draft-ietf-mile-xmpp-grid@ietf.org>, "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>, "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>
To: Peter Saint-Andre <stpeter@mozilla.com>
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>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/y8xUoS2aDWNPI4Qw-wTpa_u5AFk>
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: Sun, 24 Mar 2019 22:15:41 -0000


> On Mar 24, 2019, at 11:06 PM, Peter Saint-Andre <stpeter@mozilla.com>; wrote:
> 
> Hi Ben, thanks for continuing to engage on these topics. Replies inline.

For better or worse, you’ve got me until the plenary :-) (After which my discuss will be moot unless someone else wants to take it on.)

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

Ah, okay.

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

If I read 6121 §8.5.2.2.1. correctly, it says SHOULD either store offline _or_ return an error.  That is, rejecting the message with an error is given equal billing.


> 
> Peter