Hi Eric,
It looks like we have entered a fast convergence process. Please, see
[JM] below.
Julien
Jan. 26, 2016 - [email protected]:
Hi Julien,
Thanks for the review. Responses in-line...
From: Susan Hares [mailto:[email protected]]
Sent: Monday, January 25, 2016 1:25 PM
[...]
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.
[JM] OK, I am looking forward to the conclusion.
Thank you for bringing up these issues.
Susan Hares
-----Original Message-----
From: rtg-dir [mailto:[email protected]] On Behalf Of Julien Meuric
Sent: Monday, January 25, 2016 1:15 PM
[...]
- 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).
[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".
[...]
- page 3:
* s/local Network Element based applications/local Network Element-based
applications/
Not sure what the "-" adds here?
* s/NETCONF Event Notifications [RFC5277] provides/NETCONF Event
Notifications [RFC5277] provide/
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".
[...]
* s/from operations interfaces/from operation interfaces/
"Operations" is the traditional term I have seen for this function.
[JM] OK
[...]
- p.7: s/pushes updates./pushes updates to./
Equivalent change made. " to which a Publisher pushes updates."
[JM] Even better.
[...]
* s/re-lease/release/
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.
Eric
---
Best regards,
Julien
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
