Skip to main content

Early Review of draft-ietf-i2rs-pub-sub-requirements-03

Request Review of draft-ietf-i2rs-pub-sub-requirements
Requested revision No specific revision (document currently at 09)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2016-02-19
Requested 2016-01-15
Authors Eric Voit , Alexander Clemm , Alberto Gonzalez Prieto
I-D last updated 2016-02-19
Completed reviews Genart Last Call review of -06 by Francis Dupont (diff)
Secdir Telechat review of -05 by Scott G. Kelly (diff)
Opsdir Last Call review of -06 by Sheng Jiang (diff)
Rtgdir Early review of -03 by Julien Meuric (diff)
Rtgdir Early review of -03 by Dan Frost (diff)
Assignment Reviewer Julien Meuric
State Completed
Request Early review on draft-ietf-i2rs-pub-sub-requirements by Routing Area Directorate Assigned
Reviewed revision 03 (document currently at 09)
Result Has nits
Completed 2016-02-19

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 ‚Äč

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
Intended Status: ST (see below)


I have some minor concerns about this document that I think should be 

resolved before publication.


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".


- "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 "": 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,