Dan: Regarding your major comments:
Comment on #1 - The ADs agreed on informational after WG LC did standards. It is fixed to informational now. Comment on #2 - Has Eric's comment addressed your questions? Comment on #3 - NETCONF has adopted push mechanism. What other parties are you concerned about? Comment on #4 - Please see the security requirements for the I2RS protocol: https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requireme nts https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment-reqs/ These documents provide requirement for data integrity, confidentiality, protection against replay attacks, and DDoS. Do you feel you major comments have been addressed? Sue -----Original Message----- From: i2rs [mailto:[email protected]] On Behalf Of Eric Voit (evoit) Sent: Wednesday, May 04, 2016 7:25 PM To: Dan Frost Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-pub-sub-requirements-06 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 _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
