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

["Thomas D. Nadeau" <[e-mail]>]

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