Re: [mile] some comments on the xmpp-grid draft
"Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com> Thu, 18 October 2018 02:48 UTC
Return-Path: <ncamwing@cisco.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 289EF130E47 for <mile@ietfa.amsl.com>; Wed, 17 Oct 2018 19:48:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.565
X-Spam-Level:
X-Spam-Status: No, score=-14.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 oaxnk5XBsApW for <mile@ietfa.amsl.com>; Wed, 17 Oct 2018 19:48:07 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46B5B12777C for <mile@ietf.org>; Wed, 17 Oct 2018 19:48:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9984; q=dns/txt; s=iport; t=1539830887; x=1541040487; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=XpeqvOWbH4CgbPMhdHaIEW2N+zuQtE0TSFiOJ4njIk4=; b=RcfFisXTPPY/GLczI63JIrT6+vqoom3/bk1w4LFrzNgsZXaDgwgy4pkl 98QBRSvl4yNB5jWJFgc3eAuJgfqm4QGRU1G/UkH7OR6TiS8rT99A/mh1h d/DThJMTyA7jRSy3IwrDfEp9PvfKUweyDXQ1TN9LUP5rU8zuTjMQe0tq0 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AHAAA688db/5FdJa1kGgEBAQEBAgEBAQEHAgEBAQGBUgQBAQEBCwGBVS9mfygKg2uUMoFolzGBegsBARgLhEkCF4RlITUMDQEDAQECAQECbRwMhToCBAEBIQQNOgQXAgEIEggCCB4CAgIlCxUCDgEBBAESgyABggEPpl57M4U6hGMFgQuKQReCAIERJwwTgU5+gxsBAYFLFoMDMYImAp40CQKQYheBT4RxgxSGT4kcjHoCERSBJh8CNIFVcBU7KgGCQYImF4hbhT5viW6BHwEB
X-IronPort-AV: E=Sophos;i="5.54,393,1534809600"; d="scan'208";a="465998085"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Oct 2018 02:48:06 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id w9I2m5on015317 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 18 Oct 2018 02:48:05 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 17 Oct 2018 22:48:04 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1395.000; Wed, 17 Oct 2018 22:48:04 -0400
From: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>
To: Takeshi Takahashi <takeshi_takahashi@nict.go.jp>, 'MILE IETF' <mile@ietf.org>
Thread-Topic: [mile] some comments on the xmpp-grid draft
Thread-Index: AdRbnvSKdjaCGbHfSbOSC+SVBeuJ2AK1OP0A
Date: Thu, 18 Oct 2018 02:48:04 +0000
Message-ID: <140527B3-88F1-463D-9695-93A1B07E2475@cisco.com>
References: <018e01d45b9f$ffaa8540$feff8fc0$@nict.go.jp>
In-Reply-To: <018e01d45b9f$ffaa8540$feff8fc0$@nict.go.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.c.0.180410
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.68.5]
Content-Type: text/plain; charset="utf-8"
Content-ID: <04CDBC49F9AC2249A0DD09EAF15BA5D2@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.152, xch-rtp-012.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/OE6fCBAavcIzLk5XEhSd6CsCJh4>
Subject: Re: [mile] some comments on the xmpp-grid draft
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: Thu, 18 Oct 2018 02:48:10 -0000
Hi Takeshi, Many thanks for providing these comments! Please see further responses below: On 10/3/18, 22:06, "mile on behalf of Takeshi Takahashi" <mile-bounces@ietf.org on behalf of takeshi_takahashi@nict.go.jp> wrote: Hello authors of draft-appala-mile-xmpp-grid, Before working on the shepherd-writeup, there are several issues I (as an individual without any hat) would like to comment on. I know that the WG last call has already completed, but hopefully you could consider reflecting these comments. These comments are more-or-less editorial. 1. Current xmpp-draft talks about the delivery of only IODEF document, but the charter will be changed so that MILE transport protocols can deliver not only IODEF documents but also various security-related information (currently, the charter is under review by our AD). Moreover, by reading the draft, I could not find any IODEF-specific definitions. Therefore, wouldn't it be better to change the sentences so that xmpp-grid can deliver not only IODEF documents but also various security-related information, including STIX documents? [NCW] True, as our charter grows we can demonstrate how other namespaces can be used. I am not sure the draft is restricted to only IODEF, though it uses that as the (or one) example for how security information can be shared using XMPP. I think the only normative aspect to IODEF is its use and reference in namespace. I am amenable to making it wider, but I think the only suitable place could be in The introduction. I could add a sentence at the end to state "While many other Security information formats can be shared using XMPP, this document uses IODEF as one such exchange format that can be published And consumed using XMPP." Would that satisfy this comment? 2. The document is intended to be a Standard-track RFC. Readers of the current draft may think it is a draft designed to be an Informational RFC because it is not clear to the readers what is newly defined in this document. The document could be seen as a guidancde on how to use XMPP-related techniques. Therefore, these new definitions should be addressed in the introduction section. In my understanding, the three values, i.e., disco#items, disco#info, and pubsub#type, were newly defined in this document. [NCW] Ah yes, we had discussed this but never concluded as to whether it is Standards or informational. The reference to the use of the IODEF namespace May allow this to be standards track; but in general, it is more of a guidance document So we could make this an informational draft. 3. The terminology definition sentences begin with "In SACM", but I think we can omit that part of the sentences. [NCW] Will do. 4. We could delete the defitions of "Publisher", "Publish-Subscribe Service", and "Subscriber" from the Terminology definition section, because - these terms are not used in this document, and - you have already said that "Provider", "Broker", and "Consumer" are the terms that us used within this document for them [NCW] Will do. 5. in section 3 "Architecture", there is a sentence: "Platforms cannot ... and relationships (e.g., Provider or Consumer) at the Broker. Is it correct to read like this: "Platforms cannot ... and relationships among entities, (e.g., Provider or Consumer) at the Broker" ? [NCW] Actually they have to obtain the appropriate authorization to either or both Be a provider or consumer; the authorization is done thru the broker. I will clean that Sentence; somehow it got munged in version 4 of the draft. 6. in the same sentence discussed above, you have written "(e.g., Provider or Consumer)". However, are there indeed any other entities other that Provider and Consuer? If not, we could change it to "(i.e., Provider or Consumer) [NCW] Actually, a platform can be a provider for some formats (say IODEF) and A consumer of others (say STIX or some other namespaces). But in general, There are only providers and consumers. 7. In section 3 "Architecture", "thru"->"through" [NCW] Thanks, will update. 8. in Section 4 (workflow), "Controller (XMPP server)" -> "Controller" Because you have already defined the term (and because you have already clarified that these terms are equivalent), I am not sure whether we need both terms listed here or not. [NCW] Fair point. 9. you have a term "Topic". In section 2, Topic is defined to be a channel, but in other places, it seems to be treated as a data or information. - ex1: "A Provider unicasts its Topic updates to the Grid.... The Broker handles replication and distribution of the Topic to Consumers" - ex2: "discover thbe available information (Topics) to be published or Consumes [NCW] I will have to go through and ensure they are consistant. A Topic Is a type of information (effectively a namespace). 10. in item f of section 4, I am not sure whether "as" in "and as Consumers will then receive ... " is a typo or not. Would it be "the" or something else? 11. in item f of section 4, "from the Topics to which it is subscribed" could be "from the Topics to which they subscribe" ??? [NCW] How about: Any Platform on the Grid may subscribe to any Topics published to the Grid (as permitted by authorization policy), and (as Consumers) will then receive a continuous, real-time stream of updates from the Topics to which they are subscribed. 12, in section 4, "(Topics) to bepublished or consumes" -> "(Topics) to bepublished or consumed" [NCW] Thanks for catching this....will update 13. in section 5: I believe this section is the basis for making this draft a standard track RFC. The draft seems to be defining these three values---disco#items, disco#info, and pubsub#type. If it is newly defined in this draft, I hope the authors could say so somewhere in this draft. Or, is it defined elsewhere? [NCW] No, these are extended XMPP constructs in XEP-0030, but I think for the "Grid" To allow for service discovery, XEP-0030 SHOULD be implemented And for asynchronous sharing XEP-0060 MUST be implemented. So these I also thought is what made it standard or stronger than a guidance. 14. Sectuion 8 "Security Considerations" have lots of information. I am wondering which of these are issues brought by the original xmpp and which of these are newly added issues brought by xmpp-grid. If there are already existing texts on the security considerations of xmpp, referencing these text would be helpful. [NCW] These are all new considerations we believed are needed beyond what is Defined in the XMPP RFC's as they go to the establishment of the "Grid" and the communications between the consumers and producers. Kind regards, Take _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile
- [mile] some comments on the xmpp-grid draft Takeshi Takahashi
- Re: [mile] some comments on the xmpp-grid draft Nancy Cam-Winget (ncamwing)
- Re: [mile] some comments on the xmpp-grid draft Takeshi Takahashi
- Re: [mile] some comments on the xmpp-grid draft Nancy Cam-Winget (ncamwing)