Thanks for the review. The editorial items we clealry should apply.
If we put in a normative reference to draft-clarke-i2rs-traceability (or
even to the WG adopted version, which would be the minimum necessary) we
would create a block to publication. Given that we are not trying to
mandate the details here, I don't think we need a reference.
Yours,
Joel
On 12/3/14, 10:22 PM, Mach Chen wrote:
Hi Authors,
I just finished the shepherd review on draft-ietf-i2rs-architecture-06, it's
well written and easy for reading. I have the following comments for this
version, most of them are editorial comments.
1.
Some (not well-known) of the acronyms may need to be expanded in their first
use. For example, DCCP, etc.
2.
The architecture document raises a lot of requirements to I2RS protocol,
Information model, Data model. It somehow can be treated as a requirement
document. But I only found that there is only one place that uses the RFC2119
language and no reference to RFC2119 (idnits tool also pointed this). Do we
need to use the RFC2219 language for all requirements or just change only one
place to non-RFC2119 usage?
3.
Section 1.2 the last third paragraph
"..., these these error cases should be
resolved by the network applications and management systems."
There is a redundant "these".
4.
Section 6.1
"To facilitate operations, deployment and troubleshooting, it is
important that traceability of the I2RS Agent's requests and actions
be supported via a common data model."
Seems it's better to make a reference to draft-clarke-i2rs-traceability here.
5.
Section 6.2.1
"The I2RS Agent Agent must send a NOTIFICATION_I2RS_AGENT_TERMINATING to all
its cached I2RS Clients."
There is a redundant "Agent".
6.
Section 6.2.3
"An I2RS Agent may decide that some state should no longer be applied.
An I2RS Client may instruct an Agent to remove state it has applied.
In all such cases, the state will revert to what it would have been
without the I2RS; that state is generally whatever was specified via
the CLI, NETCONF, SNMP, etc."
An I2RS can only withdraws its own states that have been applied to the specific Routing
Element, there may be other I2RS clients are in effect. So the decription "the state
will revert to what it would have been without the I2RS" may not be accuracy. How
about changing it as:
"...the state will revert to what it would have been without the I2RS Client; that
state is generally whatever was specified via the CLI, NETCONF, SN, MP, other I2RS
Clients etc."
7.
Section 6.4.1
"...per-interface." This..."
There is a redundant " in between.
s/per-platform-/per-platform
8.
Section 6.4.5.4
Should the editors' note be removed before sending to IESG review?
9.
Section 7.8
s/it be possible/it is possible
Hope this useful!
Best regards,
Mach
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
