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