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
> > > >
> >