Hi Alia, The document has been updated in the ways requested below. The new version is -06. Let us know if you need anything else. Eric
From: Alia Atlas, April 15, 2016 11:00 AM First, I would like to thank Eric, Alex, and Alberto for their work on this document. As is customary, i have done my AD review of draft-ietf-i2rs-pub-sub-requirements-05. I am advancing it to IETF Last Call but would very much appreciate it if an updated version which substantially improves the language in Sec 1-3 is done as soon as possible. Please think about how useful and coherent those sections are for living as a useful RFC in several years. The expected schedule is that this draft will on the May 5 IESG telechat. It is very important for the shepherd and authors to be highly responsive around this period. It is quite welcome to submit updated versions of the draft that address my comments, comments received during IETF Last Call, comments from the various Directorates and from the IESG. I do see the documenting of the desired requirements as useful, even as the associated technical solution is being handled in netconf. Minor comments: 1) Sec 1: The Introduction is written to persuade rather than as a factual description that might be read and be useful in 5 years. For instance " I2RS WG documents have expressed a need for more robust YANG object subscriptions. Similar discussions are underway in NETMOD and NETCONF. With the support of standards bodies such as OMG (DDS), XMPP.org standard, generic Publication/Subscription (Pub/Sub) mechanisms to communicate data updates have been defined and proven themselves in a wide variety of deployments." really needs some rewriting. Similarly, the last paragraph discusses the authors rather than the WG as seeing this need and specifying the associated requirements. 2) Sec 2.2: How each of the mentioned mechanisms is really a pub/sub is not described. This section needs a rewrite and tightening up. Nits: a) Sec 2: SDN is not a well-known acronym for the RFC Editor. Please expand it or preferably have a different way to describe it - is it the drive for centralized orchestration? Is it the need for Programmatic Interfaces? etc. b)Sec 2: "YANG's ascent as a dominant programmatic interface to network elements" isn't quite accurate. Perhaps "YANG's ascent as the dominant data modeling language for use in programmatic interfaces to network elements" or the like? c) Sec 4.2.2: should be "or" not "of" "The policy: i.e. whether updates are on-change of periodic" Thanks, Alia
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
