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

Hi Joel,

Thanks for your response!

In my mind, I thought a informative reference is enough, which could help readers to understand more about traceability but will not block the publication of this document. How do you think?

Best regards,
Mach

> -----Original Message-----
> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> Sent: Thursday, December 04, 2014 11:04 PM
> To: Mach Chen; draft-ietf-i2rs-architecture@tools.ietf.org
> Cc: i2rs@ietf.org
> Subject: 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
> >