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 protected]:
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
