Hi Dan, Thanks for the excellent comments. In-line below are what has been done for each of these...
> From: Dan Frost, April 25, 2016 12:04 PM > > 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. Fixed > 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. Good point. We do have some relevant requirements as there are mechanisms to: - Allow/deny/negotiate subscriptions so as not to overwhelm resources. This could include negotiation of the encoding and filters. See Section 4.2.2 - Notify subscribers that push updates are being suspended/resumed But there could be more. For example, there should be the ability of prioritize some subscriptions over others for de-queuing towards recipients Therefore the new draft version '07' adds a Relative Prioritization section 4.2.6.8 and requirements to ensure limited bandwidth environments are addressed. > 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. With subscriptions signaled in-band, any pushed updates will rely on the underlying transport layer protocols to ensure integrity and confidentiality. This provides the same level of security as a traditional "GET". > > Minor Issues: > > 1. The requirements in this document ought to be numbered for ease of > reference. Hoping to avoid this :-) > 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. Added > 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? That is what is meant. > 4. Section 3, last sentence: > What is the difference between the terms "previous Push" and "last Update" > used in this sentence? Agree this was confusing. In fact it included a requirement in the definition. Extracted this text in the -07 version, and added a reworded requirement to section 4.2.7. > 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. Updated text > 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. I can see where people might get confused. I tweaked the text to better match what can be seen with RFC6241 filtering. > 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? This is tough. There are proposals for transports of NETCONF, RESTCONF, HTTP, and HTTP2 in technology drafts. Other people have suggested COAP and IPFIX. Some people want non-IETF transports like gRPC. We really don't want to take a position. > 8. Section 4.2.5, third paragraph: > Can you spell out in the document exactly what "Versioning" means here? Updated > 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? These requirements explore the security requirements for control plane messaging, anticipating that the data plane will be locked down as would a traditional "GET" for the same information. This is why in the Security requirements talk about filtering based on whatever mechanisms would in place for a "GET" using that specific transport. I.e., we are attempting equivalence for "GET" rather than new incremental mechanisms with perhaps different behavior. > 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? Yes. In summary, you can get deltas via on-change. And when you want to ensure you haven't lost something, you can do a GET against any objects where the remote datastore houses the primary copy. > > Nits: > > Section 2.2, first paragraph: > - s/Switches and Routers/switches and routers/ > - s/past subscriptions includes/past subscription mechanisms includes/ Fixed > Section 2.2, last paragraph: > - s/NETCONF should the/NETCONF should be the/ > - s/support Multicast and Broadcast/support for multicast and broadcast/ Fixed > 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/ Fixed > - s/different that/different than that/ Couldn't find that one > Section 4, first paragraph: > - s/morphed/adapted/ fixed > Section 4.1, last paragraph: > - s/lease a Subscription/lease of a Subscription/ Fixed > Section 4.2.1, second and third paragraphs: > These two requirements seem to make more sense if "one or more" is replaced > by "multiple". Fixed > Section 4.2.8, third paragraph: > - s/us a failure/is a failure/ Fixed Eric > > Cheers, > -d _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
