Julien: Thank you for the routing directorate review. I'm sure the authors will respond to you regarding these questions. I am responding on the standard track versus informational.
We placed these drafts on the standard track because I2RS charter includes the goal of not creating new protocols, but utilizing a combination of other protocols. Based on your questions and other reviewers questions about the status, the chairs are in discussion with the AD as to whether "standards" or "informational" is the right status. Thank you for bringing up these issues. Susan Hares -----Original Message----- From: rtg-dir [mailto:[email protected]] On Behalf Of Julien Meuric Sent: Monday, January 25, 2016 1:15 PM To: [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: [RTG-DIR] RtgDir Review: draft-ietf-i2rs-pub-sub-requirements 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. 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-04 Reviewer: Julien Meuric Review Date: 25 January 2016 IETF LC End Date: TBD Intended Status: ST (see below) *Summary:* I have some minor concerns about this document that I think should be resolved before publication. *Comments:* The I-D is well written and easy to understand. The first concern was about any cross-review with the Netconf WG; a quick check reveals that Netconf was in the loop. The comments below should be easy to address and are expected to help focusing IESG's reviews. *Minor Issues:* - The intended status is "Standard Track", whereas I would have expected "Informational", as it is usually the case for requirement documents, which are not protocol specification. - In the last paragraph of section 4.2.2, the used examples require more than the specified behavior, creating an implicit requirement. If it is the intend, this behavior should be explicitly stated before moving to examples. E.g, one may add: "The returned value, taken from the acceptable range, SHOULD minimize the difference with the requested one." - On page 11, given the following set of constraints, the support of Subscription bundling reads to me more as a "MAY" rather than as "SHOULD". *Nits:* - "pub/sub" is extensively used in sections 1 and 2, expansion ("Publication/Subscription"?) should happen early in the document. - page 3: * s/local Network Element based applications/local Network Element-based applications/ * s/NETCONF Event Notifications [RFC5277] provides/NETCONF Event Notifications [RFC5277] provide/ * s/but doesn't provide/but does not provide/ * s/this requirements document/this requirement document/ * s/create new solution./create new solutions./ * s/from operations interfaces/from operation interfaces/ - p.4: s/[i2rs-usecase]has/[i2rs-usecase] has/ - p.5: * s/a subscribe to/a subscribe[r] to/ (I know it is a quote...) * s/be able instruct/be able to instruct/ (ditto) - p.6: * s/supports connection oriented/supports connection-oriented/ * s/Unicast communication/unicast communication/ - p.7: s/pushes updates./pushes updates to./ - p.8: * Section 4 begins by giving credits to "OMG" and "XMPP.org": the references used earlier (2.3) should be reused. * s/Service such that if/Service; if/ * s/re-lease/release/ - p.9: * s/Request, Therefore/Request, therefore/ * Is subscribing to "on-demand" really just a "SHOULD"? * s/i.e. whenever/i.e., whenever/ * s/e.g. what data/e.g., what data/ * s/e.g. active or/e.g., active or/ - p.10 * s/indication at what/indication telling at what/ * After "for on-change update policy", "(if supported)" should be added, since the feature is only a "SHOULD". * s/subscriber will not know/subscriber may not know/ * s/a state of indicating/a state indicating/ - p.12: s/if it would deplete/if it was likely to deplete/ - p.14: * s/character based/character-based/ * At the very end of section 4.2.7, I would drop the brackets and the "Note:" string, to leave the corresponding text as regular text in the document. --- Best regards, Julien _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
