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

[Mach Chen <[e-mail]>]

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

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[e-mail]]
> Sent: Friday, December 05, 2014 8:57 PM
> To: Joel Halpern
> Cc: Mach Chen; Joel M. Halpern; [e-mail];
> [e-mail]
> Subject: Re: [i2rs] Shepherd review on draft-ietf-i2rs-architecture-06
> 
> 
> 	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 <[e-mail]>
> wrote:
> >
> > 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:[e-mail]]
> >> Sent: Friday, December 05, 2014 2:33 AM
> >> To: Joel Halpern; Joel M. Halpern;
> >> [e-mail]
> >> Cc: [e-mail]
> >> 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:[e-mail]]
> >>> Sent: Friday, December 05, 2014 9:26 AM
> >>> To: Mach Chen; Joel M. Halpern;
> >>> [e-mail]
> >>> Cc: [e-mail]
> >>> 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:[e-mail]]
> >>>> Sent: Thursday, December 04, 2014 8:24 PM
> >>>> To: Joel M. Halpern; [e-mail]
> >>>> Cc: [e-mail]
> >>>> 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:[e-mail]]
> >>>>> Sent: Thursday, December 04, 2014 11:04 PM
> >>>>> To: Mach Chen; [e-mail]
> >>>>> Cc: [e-mail]
> >>>>> 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
> >>>>>> [e-mail]
> >>>>>> https://www.ietf.org/mailman/listinfo/i2rs
> >>>>>>
> >>>>
> >>