[mile] Ben Campbell's No Objection on draft-ietf-mile-xmpp-grid-10: (with COMMENT)
Ben Campbell via Datatracker <noreply@ietf.org> Mon, 25 March 2019 13:40 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: mile@ietf.org
Delivered-To: mile@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6B4120381; Mon, 25 Mar 2019 06:40:11 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Ben Campbell via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-mile-xmpp-grid@ietf.org, mile@ietf.org, Takeshi Takahashi <takeshi_takahashi@nict.go.jp>, mile-chairs@ietf.org, mile-chairs@ietf.org, takeshi_takahashi@nict.go.jp, mile@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.94.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Ben Campbell <ben@nostrum.com>
Message-ID: <155352121123.29020.8343636810594610942.idtracker@ietfa.amsl.com>
Date: Mon, 25 Mar 2019 06:40:11 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/8ylMIk6JerTDgkLzArfu6j7iPRg>
Subject: [mile] Ben Campbell's No Objection on draft-ietf-mile-xmpp-grid-10: (with COMMENT)
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.29
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:40:12 -0000
Ben Campbell has entered the following ballot position for draft-ietf-mile-xmpp-grid-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mile-xmpp-grid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS points in email. I am clearing now under the assumption the right things will happen in the draft text. My original non-blocking comments are listed below for reference. I leave it to the authors and AD to decide if any further actions are needed. *** Substantive Comments *** Figure 1: I fail to understand the meaning intended by extending "data plane" to the right under the peer-to-peer data flow. §3: It would be nice to somehow include authentication and authorization in Figure 1. §4: Figure 2 shows the consumer delaying the topic list request until after the provider has created the topic. I realize that's just for illustrative purposes, but I wonder what would have happened if the consumer requested the topic list sooner? Would it ever learn about the new topic? Do you have thoughts about how often new topics will be created in the field? §5: "a Platform would send an XMPP "disco#info" request to each Topic:" Have people thought about how this might work if there are a _lot_ of topics? §8.1.3: Is the controller trusted to see data and to be able to modify that data? Or more to the point: It _can_ do those things. Is it trusted to not improperly use, store, or share data, and to not improperly modify data? (See further comments below) §8.3.2: - Can you elaborate on the concept of honey tokens? - The requirement that the grid controllers SHOULD keep auditable logs of platform behavior has privacy implications that need to be discussed in the privacy considerations. In particular, could there be some guidance around not logging more information than is needed for the purpose? §8.3.3: "permanent read-only audit logs of security-relevant information (especially administrative actions) should be maintained." Really permanent, as in forever? (also, should that "should" be a "SHOULD"?) §8.3.5: I wonder if this guidance creates a new DoS opportunity. Could a malicious provider insert so much data into a topic to make it impossible to receive data from that topic due to these size limits? (That brings up a question: Can multiple providers insert data to the same topic?) §8.3.6: Can you cite something or otherwise elaborate on certificate pinning? *** Editorial Comments: §2: In most of the definitions, you treat the XMPP-specific terminology inside the definition of the abstract term. Was there a reason to treat "Node" differently? §3: "be a Provider or Consumer of interested Topics at the Broker" I'm not sure topics are capable of being interested. Perhaps "topics of interest"? §4: - list item "e": What does "in real time" mean in the context of a provider submitting data to the grid? - "XMPP-Grid implementations MUST adhere to the mandatory-to-implement and mandatory-to-negotiate features as defined in [RFC6120]." It's not generally necessary to say that an implementation MUST implement the mandatory bits of a spec. That's up to that spec to do itself. - "The Service Discovery per [XEP-0030] SHOULD be implemented" There appears to be a missing word after "Discovery". Or perhaps the use of "The" is incorrect. (i.e. "The Service Discovery Mechanism" vs "Service Discovery") §8.1.4: It's a bit confusing to find CA security considerations before any mention that there are CAs involved. §8.2.2: "... if the XMPP-Grid Platform assumes that old XMPP-Grid Platform data deserves to be ignored." "deserves" has connotations that I don't think apply here. I suspect you probably mean "... should be ignored", but were trying to avoid the non-normative use of "should". Such use is fine given the draft uses the RFC 8174 boilerplate for normative keywords. §8.3.X: There are a number of statements that systems need to be "well managed", "hardened against attack", and "reduce their attack surface". Some of them use normative language. These seem like glittering generalities, unless specific practices can be recommended or cited. §8.3.1: "(with the SCRAM-SHA-256-PLUS variant being preferred over the SCRAM-SHA-256 variant and SHA-256 variants [RFC7677] being preferred over SHA-1 varients [RFC5802]" Should that be stated normatively? §8.3.3: "Administrators SHOULD NOT use password-based authentication but should..." Should the second "should" be a "SHOULD"?
- [mile] Ben Campbell's No Objection on draft-ietf-… Ben Campbell via Datatracker