Julien, All changes made from both your emails. I did tweak wording on the hyphen topic as described below...
> From: Julien Meuric, January 26, 2016 4:55 AM > > Hi again, > > Just a quick patch to my previous e-mail, to resume the hyphen issue I have > overlooked below. > > On page 3, I would see: > s/both controller and local Network Element based applications/both > controller- and local Network Element-based applications/ > Reason: I believe hyphens are required to create compound adjectives that > qualify the noun "applications" here (but don't ask me what some grammar rules > actually add! ;-) ). The rule made for an awkward feeling sentence for me. So I just rewrote the sentence to: "With such mechanisms, applications on either a controller or Network Element have access to a set of consistent network information driven via push from peer Network Elements which host authoritative information." > By the way, on the same page, I had caught another one: > s/polling based solution/polling-based solution/ Fixed. Eric > Regards, > > Julien > > > Jan. 26, 2016 - [email protected]: > > Hi Eric, > > > > It looks like we have entered a fast convergence process. Please, see > > [JM] below. > > > > Julien > > > > > > Jan. 26, 2016 - [email protected]: > >> Hi Julien, > >> > >> Thanks for the review. Responses in-line... > >> > >>> From: Susan Hares [mailto:[email protected]] > >>> Sent: Monday, January 25, 2016 1:25 PM > > > > [...] > > > >>> 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. > >> > > [JM] OK, I am looking forward to the conclusion. > > > > > >>> 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 > > > > [...] > > > >>> - 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). > > > > [JM] My proposed sentence was trying to reflect my reading of the > > examples. I agree with the downside you point out and am perfectly > > fine with the proposed text. Just beware of the typo: "the an acceptable". > > > > [...] > > > >>> - 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. > > > > [JM] I parsed the sentence considering the reference in brackets as an > > optional parenthesis, thus the plural. I can live with "provides". > > > > [...] > > > >>> * s/from operations interfaces/from operation interfaces/ > >> > >> "Operations" is the traditional term I have seen for this function. > > > > [JM] OK > > > > [...] > > > >>> - p.7: s/pushes updates./pushes updates to./ > >> > >> Equivalent change made. " to which a Publisher pushes updates." > > > > [JM] Even better. > > > > [...] > > > >>> * s/re-lease/release/ > >> > >> Release has a different meaning. The intent more like renew. Text > >> changed to "extend the lease". > > > > [JM] Much clearer. > > > > [...] > > > >> > >> And thanks for the excellent scrub of the document. > > > > [JM] You are welcome. Thank you for the quick response. > > > >> > >> Eric > >> > >>> --- > >>> > >>> Best regards, > >>> > >>> Julien > >>> > >> _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
