Hi Julien, Thanks for the review. Responses in-line...
> From: Susan Hares [mailto:[email protected]] > Sent: Monday, January 25, 2016 1:25 PM > To: 'Julien Meuric'; [email protected] > Cc: [email protected]; [email protected]; > [email protected] > Subject: RE: [RTG-DIR] RtgDir Review: draft-ietf-i2rs-pub-sub-requirements > > 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. Below are responses on all comments provided *except* for the standards or informational question which Susan is driving. > 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." Reading this again, I do see some downside to "SHOULD". Perhaps some variant of "may" is better. The reason for downgrading the requirement is that a Subscriber might always ask for extremely high QoS levels, knowing the best possible QoS will be returned by the Publisher. This could degrade capacity for the Publisher as a whole. What about the following text instead... "For example, if periodic updates were requested with too short update intervals for the specified data set, an alternative acceptable interval period might be returned from the Publisher. If on-change updates were requested with too-aggressive dampening period, the an acceptable dampening period may be returned, or alternatively an indication that only periodic updates are supported for the requested object(s). > - 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". Agree. Change made. > *Nits:* > - "pub/sub" is extensively used in sections 1 and 2, expansion > ("Publication/Subscription"?) should happen early in the document. Change made > - page 3: > * s/local Network Element based applications/local Network Element-based > applications/ Not sure what the "-" adds here? > * s/NETCONF Event Notifications [RFC5277] provides/NETCONF Event > Notifications [RFC5277] provide/ Here we refer to RFC 5277 which is singular, so "provides" seems to be the better choice. > * s/but doesn't provide/but does not provide/ Change made > * s/this requirements document/this requirement document/ Change made > * s/create new solution./create new solutions./ Change made > * s/from operations interfaces/from operation interfaces/ "Operations" is the traditional term I have seen for this function. > - p.4: s/[i2rs-usecase]has/[i2rs-usecase] has/ Change made > - p.5: > * s/a subscribe to/a subscribe[r] to/ (I know it is a quote...) Change made > * s/be able instruct/be able to instruct/ (ditto) Change made > - p.6: > * s/supports connection oriented/supports connection-oriented/ Change made > * s/Unicast communication/unicast communication/ Change made > - p.7: s/pushes updates./pushes updates to./ Equivalent change made. " to which a Publisher pushes updates." > - p.8: > * Section 4 begins by giving credits to "OMG" and "XMPP.org": the > references > used earlier (2.3) should be reused. Change made. > * s/Service such that if/Service; if/ Change made > * s/re-lease/release/ Release has a different meaning. The intent more like renew. Text changed to "extend the lease". > - p.9: > * s/Request, Therefore/Request, therefore/ Change made > * Is subscribing to "on-demand" really just a "SHOULD"? Yes. Some implementations are likely to only support periodic subscriptions. > * s/i.e. whenever/i.e., whenever/ Change made > * s/e.g. what data/e.g., what data/ Change made > * s/e.g. active or/e.g., active or/ Change made > - p.10 > * s/indication at what/indication telling at what/ Change made > * After "for on-change update policy", "(if supported)" should be added, > since > the feature is only a "SHOULD". Change made > * s/subscriber will not know/subscriber may not know/ Changed to "might not" > * s/a state of indicating/a state indicating/ Change made > - p.12: s/if it would deplete/if it was likely to deplete/ Change made: "if it is likely to deplete " > - p.14: > * s/character based/character-based/ Change made > * 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. Change made And thanks for the excellent scrub of the document. Eric > --- > > Best regards, > > Julien > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
