Re: [i2rs] Shepherd review on draft-ietf-i2rs-architecture-06

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
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>