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 protected]>
> 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:[email protected]]
>> Sent: Friday, December 05, 2014 2:33 AM
>> To: Joel Halpern; Joel M. Halpern;
>> [email protected]
>> Cc: [email protected]
>> 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:[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
