Subject: [RTG-DIR] RtgDir Review: draft-ietf-i2rs-pub-sub-requirements

From: Julien Meuric <[email-masked]>
Date: Mon, 25 Jan 2016 19:14:37 +0100

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

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 25 Jan 2016 13:24:41 -0500

Julien: 

Thank you for the routing directorate review.   I'm sure the authors will respond to you regarding these questions.  I am responding on the standard track versus informational.  

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. 

Thank you for bringing up these issues. 

Susan Hares 

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Julien Meuric
Sent: Monday, January 25, 2016 1:15 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [RTG-DIR] RtgDir Review: draft-ietf-i2rs-pub-sub-requirements

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.

*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:*
     * s/local Network Element based applications/local Network Element-based applications/
     * s/NETCONF Event Notifications [RFC5277] provides/NETCONF Event Notifications [RFC5277] provide/
     * Section 4 begins by giving credits to "OMG" and "XMPP.org": the references used earlier (2.3) should be reused.
     * After "for on-change update policy", "(if supported)" should be added, since the feature is only a "SHOULD".
     * 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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 26 Jan 2016 01:42:59 +0000

Hi Julien,

Thanks for the review.   Responses in-line...

> From: Susan Hares [mailto:[email-masked]]
> Sent: Monday, January 25, 2016 1:25 PM
> To: 'Julien Meuric'; [email-masked]
> Subject: RE: [RTG-DIR] RtgDir Review: draft-ietf-i2rs-pub-sub-requirements
> 
> Julien:
> 
> Thank you for the routing directorate review.   I'm sure the authors will respond
> to you regarding these questions.  I am responding on the standard track versus
> informational.
> 
> 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.

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

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

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

Agree.  Change made.
 
> ("Publication/Subscription"?) should happen early in the document.

Change made

>      * s/local Network Element based applications/local Network Element-based

Not sure what the "-" adds here?

> Notifications [RFC5277] provide/

 Here we refer to RFC 5277 which is singular, so "provides" seems to be the better choice.

>      * s/but doesn't provide/but does not provide/

Change made

>      * s/this requirements document/this requirement document/

Change made

>      * s/create new solution./create new solutions./

Change made

>      * s/from operations interfaces/from operation interfaces/

"Operations" is the traditional term I have seen for this function.

> - p.4: s/[i2rs-usecase]has/[i2rs-usecase] has/

Change made

>      * s/a subscribe to/a subscribe[r] to/  (I know it is a quote...)

Change made

>      * s/be able instruct/be able to instruct/  (ditto)

Change made

>      * s/supports connection oriented/supports connection-oriented/

Change made

>      * s/Unicast communication/unicast communication/

Change made

> - p.7: s/pushes updates./pushes updates to./

Equivalent change made. " to which a Publisher pushes updates."

> used earlier (2.3) should be reused.

Change made.

>      * s/Service such that if/Service; if/

Change made

>      * s/re-lease/release/

Release has a different meaning.  The intent more like renew.  Text changed to "extend the lease".

>      * s/Request, Therefore/Request, therefore/

Change made

>      * Is subscribing to "on-demand" really just a "SHOULD"?

Yes.   Some implementations are likely to only support periodic subscriptions.

>      * s/i.e. whenever/i.e., whenever/

Change made

>      * s/e.g. what data/e.g., what data/

Change made

>      * s/e.g. active or/e.g., active or/

Change made

>      * s/indication at what/indication telling at what/

Change made

> the feature is only a "SHOULD".

Change made

>      * s/subscriber will not know/subscriber may not know/

Changed to "might not"

>      * s/a state of indicating/a state indicating/

Change made

> - p.12: s/if it would deplete/if it was likely to deplete/

Change made: "if it is likely to deplete "

>      * s/character based/character-based/

Change made

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

Change made

And thanks for the excellent scrub of the document.

Eric

---

From: Julien Meuric <[email-masked]>
Date: Tue, 26 Jan 2016 10:30:21 +0100

Hi Eric,

It looks like we have entered a fast convergence process. Please, see 
[JM] below.

Julien

>> Sent: Monday, January 25, 2016 1:25 PM

[...]

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

>> Sent: Monday, January 25, 2016 1:15 PM

[...]

> "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-c…

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

[...]

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

[...]

> "Operations" is the traditional term I have seen for this function.

[JM] OK

[...]

> Equivalent change made. " to which a Publisher pushes updates."

[JM] Even better.

[...]

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

---

From: Julien Meuric <[email-masked]>
Date: Tue, 26 Jan 2016 10:55:22 +0100

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! ;-) ).

By the way, on the same page, I had caught another one:
s/polling based solution/polling-based solution/

Regards,

Julien

Jan. 26, 2016 - [email-masked]:
>> Below are responses on all comments provided *except* for the
>> standards or informational question which Susan is driving.
>>
>> 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).
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 26 Jan 2016 14:21:46 +0000

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

> s/polling based solution/polling-based solution/

Fixed.

Eric

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