Hi Dan, Thank you very much for your review. This document is intended to be Informational; the data-tracker needed to be updated. I do have a few comments in-line.
Eric, Alex, Gonzalez & Sue, please address these comments ASAP as you feel is appropriate. I do think that some clarifications will help. I do think that version 06 is quite improved in sections 1 & 2. On Mon, Apr 25, 2016 at 12:04 PM, Dan Frost <[email protected]> wrote: > 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. > [Alia] Good catch. Agreement is that they are informational. > 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. > [Alia] There are a number of different potential transports and encodings; these tend to be dictated by the ecosystem in which the deployment is desired. These I2RS requirements are targeted initially for YANG with NetConf and RestConf. An expectation is that the mechanisms such as subscription filters, bundling, and dampening, can be reused for other transports and encodings. 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? > [Alia] A proposed solution is being discussed in NetConf. > 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. > [Alia] While the I2RS architecture and draft-ietf-i2rs-security-environment-reqs-01 <https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment-reqs/> and draft-ietf-i2rs-protocol-security-requirements-03 <https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/> all cover lots of details about this, it would be a good idea to touch on it this as well in the Security Requirements with a useful reference. > 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? > [Alia] These are the requirements on a pub/sub service. Of course, different transports and encodings may have slight nuances - but I2RS is specifically reusing NetConf and RestConf and YANG, so that gives the initial set for at least subscribing. Thanks, Alia > 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 >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
