[mile] some comments on the xmpp-grid draft
"Takeshi Takahashi" <takeshi_takahashi@nict.go.jp> Thu, 04 October 2018 05:06 UTC
Return-Path: <takeshi_takahashi@nict.go.jp>
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 A36D8130DDF for <mile@ietfa.amsl.com>; Wed, 3 Oct 2018 22:06:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 fHMk_zoT27u2 for <mile@ietfa.amsl.com>; Wed, 3 Oct 2018 22:06:24 -0700 (PDT)
Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id 002F4130DD5 for <mile@ietf.org>; Wed, 3 Oct 2018 22:06:23 -0700 (PDT)
Received: from gw2.nict.go.jp (gw2.nict.go.jp [133.243.18.251]) by ns2.nict.go.jp with ESMTP id w9456NXk045575 for <mile@ietf.org>; Thu, 4 Oct 2018 14:06:23 +0900 (JST)
Received: from mail2.nict.go.jp (mail2.nict.go.jp [133.243.18.15]) by gw2.nict.go.jp with ESMTP id w9456NPr045509 for <mile@ietf.org>; Thu, 4 Oct 2018 14:06:23 +0900 (JST)
Received: from LAPTOP9DLCDU5S (unknown [133.243.29.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail2.nict.go.jp (NICT Mail Spool Server2) with ESMTPS id 24C9113220 for <mile@ietf.org>; Thu, 4 Oct 2018 14:06:23 +0900 (JST)
From: Takeshi Takahashi <takeshi_takahashi@nict.go.jp>
To: 'MILE IETF' <mile@ietf.org>
Date: Thu, 04 Oct 2018 14:06:24 +0900
Message-ID: <018e01d45b9f$ffaa8540$feff8fc0$@nict.go.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdRbnvSKdjaCGbHfSbOSC+SVBeuJ2A==
Content-Language: ja
X-Virus-Scanned: clamav-milter 0.100.1 at zenith2
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/tmR-i7TGdzmPh94eTCYArvTv8Ng>
Subject: [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, 04 Oct 2018 05:06:27 -0000
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? 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. 3. The terminology definition sentences begin with "In SACM", but I think we can omit that part of the sentences. 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 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" ? 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) 7. In section 3 "Architecture", "thru"->"through" 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. 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 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" ??? 12, in section 4, "(Topics) to bepublished or consumes" -> "(Topics) to bepublished or consumed" 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? 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. Kind regards, Take
- [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)