Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-i2rs-pub-sub-requirements-06 Reviewer: Dan Frost Review Date: 2016-04-25 IETF LC End Date: 2016-04-29 Intended Status: Informational (?) Summary: I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors. Comments: Overall this is a clear and consistent requirements document that addresses an important real-world problem domain, and is nearly ready for publication. However, because this work may lead to significant changes in the mechanics of network management and control, some extra care in the review stage is warranted. I've marked some issues as major to indicate that they may deserve extra consideration by the ADs and/or the wider Internet community. Major Issues: 1. There seems to be some confusion as to the intended status of the document. The draft itself lists its intended status as Informational, which is usually appropriate for a requirements document. On the other hand, the draft was submitted to the IESG with an Intended Status of Proposed Standard. Furthermore, a quick check of other I2RS WG requirements docs shows them split between Informational and Proposed Standard, so the confusion may extend beyond this draft. I'd suggest the ADs and chairs agree on a consistent policy. 2. The document concerns requirements for a publish/subscribe interface to, among other things, real-time operational data. The text in Section 2.3 indicates an awareness of the need to support potentially large numbers of subscribers and high volumes of data. However, the document doesn't seem to discuss the global network impact of continuously pushing a lot of data to many subscribers. As the introduction of such a push system could lead to a qualitative shift in the total volume of management/control traffic, it seems important to begin addressing this issue at the requirements stage. A possible resolution would be to add a brief section on network impact under large-scale conditions, and/or a set of requirements for minimizing this impact. Some of the listed requirements are germane to this, e.g. subscription filters. bundling, and dampening. Issues that are not addressed include support for encoding formats that are efficient for high-volume transport and processing (XML and JSON are usually considered not to be); appropriate selection of transport protocols and features according to scale/use-case; and support for mechanisms to determine or restrict the bandwidth cost of a proposed or ongoing subscription. 3. This work is being carried out in the I2RS WG, but the first sentence of Section 2.2 states that this document is intended to cover requirements beyond I2RS. A general question for the editors/chairs/ADs is whether it has received any review by interested/affected parties outside I2RS? 4. The Security Requirements make no mention of data integrity or confidentiality. This is a potentially serious omission in today's network environment. I would expect at the least that subscribers have the ability to request a secure (authenticated, integrity-verified, confidential) session, that publishers likewise have the ability to refuse non-secure sessions, and that the security status of a session is explicitly signaled and checked by both parties during negotiation. Minor Issues: 1. The requirements in this document ought to be numbered for ease of reference. 2. Section 3: As this is a requirements doc, the RFC 2119 language paragraph could use a clarification sentence along the lines of the one in Section 1.1 of RFC 5654. 3. Section 3: It's not obvious to me from the text in this section what the distinction and intended relationship is between Receivers and Subscribers. Perhaps this can be clarified with an example? Also the statement "In general, the Receiver and Subscriber will be the same entity" doesn't sound right -- maybe you meant that in general they can be different, but usually they will be the same? 4. Section 3, last sentence: What is the difference between the terms "previous Push" and "last Update" used in this sentence? 5. Section 4.2.3, last paragraph: This paragraph would be more useful if it explained what a persistence/replay capability was and how it might work. 6. Can a definition or reference be provided for the term "object property" as used in Sections 3 and 4.2.7? This terminology seems slightly different from that used in RFC 6020. 7. Section 4.2.4: What is the purpose of stating that a subscription service should support "different" transports and encodings? This sounds too vague to be useful. Choice of transport and encoding are of great practical importance, but the document has almost nothing to say on these topics. Can the authors not provide a summary of options and some definite guidance here? 8. Section 4.2.5, third paragraph: Can you spell out in the document exactly what "Versioning" means here? 9. When the underlying transport provides some form of security, should there not be a requirement for alignment between transport security and pub/sub protocol security? Can, for example, TLS certificate validation fulfil the pub/sub authentication requirement? 10. An important use-case for such a pub/sub update service is a subscriber that wants to maintain an up-to-date local copy of a datastore residing on the publisher. This requires the ability to correlate the version of the datastore obtained via an out-of-band full download with the version reflected by each published update. Do the authors intend to allow for this case, and have they considered the associated requirements? Nits: Section 2.2, first paragraph: - s/Switches and Routers/switches and routers/ - s/past subscriptions includes/past subscription mechanisms includes/ Section 2.2, last paragraph: - s/NETCONF should the/NETCONF should be the/ - s/support Multicast and Broadcast/support for multicast and broadcast/ Section 3, 8th paragraph: - s/referred in/referred to in/ Section 3, 9th paragraph: - s/which have been made/that have been made/ Section 3, last paragraph: - s/propert(ies)/properties/ - s/different that/different than that/ Section 4, first paragraph: - s/morphed/adapted/ Section 4.1, last paragraph: - s/lease a Subscription/lease of a Subscription/ Section 4.2.1, second and third paragraphs: These two requirements seem to make more sense if "one or more" is replaced by "multiple". Section 4.2.8, third paragraph: - s/us a failure/is a failure/ Cheers, -d