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

At this point I will leave it to my co-authors and the WG.  I do not think the reference adds much, but I am not going to fuss over adding an informational reference.

Yours,
Joel 

> -----Original Message-----
> From: Mach Chen [mailto:mach.chen@huawei.com] 
> Sent: Friday, December 05, 2014 2:33 AM
> To: Joel Halpern; Joel M. Halpern; 
> draft-ietf-i2rs-architecture@tools.ietf.org
> Cc: i2rs@ietf.org
> Subject: RE: [i2rs] Shepherd review on draft-ietf-i2rs-architecture-06
> 
> Hi Joel,
> 
> In my understanding, an informational reference can be either 
> WG or now-WG draft. But anyway, I believe that the 
> traceability draft will be a WG draft before the publication 
> of this document. 
> 
> BTW, so far, all the references of this document are 
> informational, I do not think draft-traceability is different 
> from other references. So let's make it as an informational 
> reference. 
> 
> Best regards,
> Mach
> 
> > -----Original Message-----
> > From: Joel Halpern [mailto:joel.halpern@ericsson.com]
> > Sent: Friday, December 05, 2014 9:26 AM
> > To: Mach Chen; Joel M. Halpern; 
> > draft-ietf-i2rs-architecture@tools.ietf.org
> > Cc: i2rs@ietf.org
> > Subject: RE: [i2rs] Shepherd review on 
> draft-ietf-i2rs-architecture-06
> > 
> > I have trouble constructing the sentence such that an informational 
> > reference is useful, but it does not become normative.
> > I would note that even for an informational reference I 
> would want to 
> > have a WG adopted draft.  I believe that hurdle will be 
> cleared in sufficient time.
> > 
> > Yours,
> > Joel
> > 
> > > -----Original Message-----
> > > From: Mach Chen [mailto:mach.chen@huawei.com]
> > > Sent: Thursday, December 04, 2014 8:24 PM
> > > To: Joel M. Halpern; draft-ietf-i2rs-architecture@tools.ietf.org
> > > Cc: i2rs@ietf.org
> > > Subject: 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
> > > > >
> > >
> 