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

From: Mach Chen <[email-masked]>
Date: Thu, 4 Dec 2014 03:22:43 +0000

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 04 Dec 2014 10:03:40 -0500

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:
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: Mach Chen <[email-masked]>
Date: Fri, 5 Dec 2014 01:23:50 +0000

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-masked]]
> Sent: Thursday, December 04, 2014 11:04 PM
> To: Mach Chen; [email-masked]
> Cc: [email-masked]
> Subject: Re: [i2rs] Shepherd review on draft-ietf-i2rs-architecture-06
> 
> 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
> 
> > 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.
> > 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.
> > "The I2RS Agent Agent must send a
> NOTIFICATION_I2RS_AGENT_TERMINATING to all
> > 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
> >

---

From: Joel Halpern <[email-masked]>
Date: Fri, 5 Dec 2014 01:26:23 +0000

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 

> From: Mach Chen [mailto:[email-masked]] 
> Sent: Thursday, December 04, 2014 8:24 PM
> To: Joel M. Halpern; [email-masked]
> Cc: [email-masked]
> Subject: RE: [i2rs] Shepherd review on draft-ietf-i2rs-architecture-06
> 
> Hi Joel,
> 
> 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
> 
> > 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
> > 
> > > 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.
> > 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.
> > > 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"
> > state is generally whatever was specified via the CLI, NETCONF, SN, 
> > MP, other I2RS Clients etc."
> > >
> > > 7.
> > > Section 6.4.1
> > >

---

From: Mach Chen <[email-masked]>
Date: Fri, 5 Dec 2014 07:33:17 +0000

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

> From: Joel Halpern [mailto:[email-masked]]
> Sent: Friday, December 05, 2014 9:26 AM
> To: Mach Chen; Joel M. Halpern; [email-masked]
> Cc: [email-masked]
> 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
> 
> > 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
> >

---

From: Joel Halpern <[email-masked]>
Date: Fri, 5 Dec 2014 11:13:08 +0000

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 

> Sent: Friday, December 05, 2014 2:33 AM
> To: Joel Halpern; Joel M. Halpern; 
> [email-masked]
> Cc: [email-masked]
> 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
> 
> > To: Mach Chen; Joel M. Halpern; 
> > [email-masked]
> > Cc: [email-masked]
> > 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
> > 
> 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
> > >
> > > > > The architecture document raises a lot of 
> requirements to I2RS 
> > > > > protocol,
> > > > 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.
> > > > > "...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
> > > > >

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 5 Dec 2014 07:57:17 -0500

I personally do not want to add the additional reference. I don't see how this adds anything that is critically missing from the draft as it currently stands.  Lets please move things forward and only make changes that are critically needed.

	--Tom

> On Dec 5, 2014:6:13 AM, at 6:13 AM, Joel Halpern <[email-masked]> wrote:
>

---

From: Mach Chen <[email-masked]>
Date: Mon, 8 Dec 2014 01:27:18 +0000

Hi Tom and Joel,

OK, that's just a suggestion, I'm OK with either way, I will leave the discretion to the authors. 

Best regards,
Mach

> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Friday, December 05, 2014 8:57 PM
> To: Joel Halpern
> Cc: Mach Chen; Joel M. Halpern; [email-masked];
> [email-masked]
> 	I personally do not want to add the additional reference. I don't see how
> this adds anything that is critically missing from the draft as it currently stands.
> Lets please move things forward and only make changes that are critically
> needed.
> 
> 	--Tom
> 
> 
> > 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
> >
> >> 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
> >>