Re: [i2rs] Shepherd's review of draft-ietf-i2rs-pub-sub-requirements

["Susan Hares" <[e-mail]>]

Eric: 

 

Wonderful.   Our next steps toward publication are: 

 

1)      Revise the draft based on shepherds report, 

2)      Get a RTG-Directorate review, 

3)      Send to IESG for publication 

4)      AD Evaluation  (hopefully first week of January). 

 

I'm hoping we can get the RTG-Directorate review over the next few weeks so
your quick response (after my lengthy delay) is so helpful!

 

Sue 

 

From: Eric Voit (evoit) [mailto:[e-mail]] 
Sent: Thursday, December 17, 2015 3:34 PM
To: Susan Hares; [e-mail];
[e-mail]
Cc: 'Jeffrey Haas'; 'Alia Atlas'; Alexander Clemm (alex); Alberto Gonzalez
Prieto (albertgo)
Subject: RE: Shepherd's review of draft-ietf-i2rs-pub-sub-requirements

 

Thanks Susan,

 

We will make all needful changes next week.

 

Eric

 

From: Susan Hares [mailto:[e-mail]] 
Sent: Thursday, December 17, 2015 3:18 PM
To: [e-mail]; [e-mail]
Cc: 'Jeffrey Haas'; 'Alia Atlas'; Eric Voit (evoit); Alexander Clemm (alex);
Alberto Gonzalez Prieto (albertgo)
Subject: Shepherd's review of draft-ietf-i2rs-pub-sub-requirements

 

Eric, Alexander, Alberto: 

 

This is a shepherd's review of draft-i2rs-pub-sub-requirements.  

 

Status: 95% ready for Directorate reviews and IESG with 1 minor technical
comment, and a few minor editorial changes. 

 

Overall comment: This document is a joy to read with carefully written
English, excellent descriptions of the concepts, and a carefully thought out
set of requirements. 

 

Minor technical point: [i2rs-pubsub-security] is no longer an individual
draft.  If you feel this draft provides significant additions to the
I2rs-protocol-security and I2rs-protocol-security-environment by provide
specific concept on [I2rs-pubsub-security], please indicate this in your
response.  We will work on adopting and refining this draft. 

 

If you could work on these minor changes this week, we'll try to get the
Directorate reviews over the next 2 weeks. 

 

Thank you, 

 

Sue Hares

==============================

 

Editorial: 

#1 p. 2 section 1 

 

You should change period in first bullet to ", and" and the second bullet to
".". 


   o  a reliance on RPC-style interactions where data is configured or

      fetched on-demand by applications.

 

   o  change notifications which identify a node associated with the

      config change, without the actual data updates

 

#2) p. 3 paragraph 4  

   Predating YANG is an
   issue, as monitoring and filtering based on YANG subtrees becomes
   problematic . [RFC6470 <https://tools.ietf.org/html/rfc6470> ] defines

 

change /problematic  ./problematic./

 

#3) p. 4 section 2.1, bottom: 

 

Revise the references to I2RS architecture document to match 

https://tools.ietf.org/html/draft-ietf-i2rs-architecture-11

 

#4) p. 5 update the section 2.1 

 

[i2rs-pubsub-security] is no longer an individual draft.   Once you have
determined whether it is needed, update this section. 

 

#5) section 2.3, p. 6 first paragraph

 

s/We need a technology/We need a new pub-sub technology/

 

#6) section 4.1,1 paragraph, 2 sentence 

 

s/However, In/However, in/ 

 

#7) section 4.1.2, p. 9, 3 paragraph. 

 

This is a single sentence 

 

   s/A Subscription may include filters as defined within a Subscription

   Request,  the Subscription Service must publish only data nodes that

   meet the filter criteria./

   /A Subscription may include filters as defined within a Subscription

   Request. Therefore,  the Subscription Service must publish only data
nodes that

   meet the filter criteria within a subscription./ 

 

 

#8 section 4.2.3 , p. 10, paragraph 1

 

  Sentence:  The updates for each object needs to include an indication
whether it

   was removed, added, or changed.

 

s/needs/need/ - the updates is plural noun to my reading.  However, this
grammar can be argued another way. 

 

#9 - section 4.2.5, p. 12, 3rd paragraph 

 

   A loss of authenticated access to subtree or node SHOULD be

   communicated to the Subscriber

 

s/Subscriber/Subscriber./ 

 

#10 - section 4.2.6, p. 12 

  

   A Subscription Service should be able to negotiate the following

   Subscription QoS parameters with a Subscriber: Dampening,

   Reliability, Deadline, Bundling.

 

s/Bundling/ and Bundling./ 

 

#11 - section 4.2.8, p. 8 

 

Lists elements should be terminated with ";" .