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