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

Ben Campbell <ben@nostrum.com> Mon, 25 March 2019 13:35 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 B5C6812038C; Mon, 25 Mar 2019 06:35:11 -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, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 16Md2QkwaKcr; Mon, 25 Mar 2019 06:35:09 -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 C71DC1203EF; Mon, 25 Mar 2019 06:35:09 -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 x2PDYxb4013288 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 25 Mar 2019 08:35:02 -0500 (CDT) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1553520907; bh=1/J26zYmT+Y46mmu7lbfm8hr7/MJfilY0t7e5fOwln4=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=fnS4I9FEeZsrh1O7uRRO23Om90gr9AOMb41zyTVHocWBdVSb0202vdu9Ts2hJdxcs 6pXcC6tvTTbysYpDoD58bO8Kw/7tnvQtyL0E4hqkbihNry0GLa2k1ql2eGC3/UJLzr aZByrZF4ZW02u/fN27jAtmaPInYgBqRyXOI99ZaE=
From: Ben Campbell <ben@nostrum.com>
Message-Id: <E923A088-4AD7-46B6-806C-27123B8839B7@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_E28ADD11-1840-4B7A-A339-D63D3C0AB4F6"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Mon, 25 Mar 2019 14:34:57 +0100
In-Reply-To: <6e2d2076-198d-7085-0cec-5c0ae5e852d3@mozilla.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>
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> <6e2d2076-198d-7085-0cec-5c0ae5e852d3@mozilla.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/5V4nUJlRAiy8nw-Quc31uQ3ToWI>
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:35:12 -0000

Hi Peter,

That works for me. I will clear under the assumption this and the comments about the consequences of not having e2e security will make it into the final text.

Thanks!

Ben.

> On Mar 25, 2019, at 2:32 PM, Peter Saint-Andre <stpeter@mozilla.com>; wrote:
> 
> 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