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:[email protected]] > Sent: Friday, December 05, 2014 9:26 AM > To: Mach Chen; Joel M. Halpern; [email protected] > Cc: [email protected] > 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:[email protected]] > > Sent: Thursday, December 04, 2014 8:24 PM > > To: Joel M. Halpern; [email protected] > > Cc: [email protected] > > 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:[email protected]] > > > Sent: Thursday, December 04, 2014 11:04 PM > > > To: Mach Chen; [email protected] > > > Cc: [email protected] > > > 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 > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
