Re: [Isis-wg] Ben Campbell's No Objection on draft-ietf-isis-remaining-lifetime-03: (with COMMENT)

["Ben Campbell" <[e-mail]>]

Yes, it does.

Thanks!

Ben.

On 17 Aug 2016, at 22:35, Les Ginsberg (ginsberg) wrote:

> Ben -
>
> I believe all of your comments have been addressed in the recently 
> published V4 of the draft.
> Please take a look and let me know.
>
>    Les
>
>
>> -----Original Message-----
>> From: Ben Campbell [mailto:[e-mail]]
>> Sent: Wednesday, August 17, 2016 7:28 PM
>> To: Les Ginsberg (ginsberg)
>> Cc: The IESG; [e-mail]; Christian 
>> Hopps; isis-
>> [e-mail]; [e-mail]
>> Subject: Re: Ben Campbell's No Objection on 
>> draft-ietf-isis-remaining-
>> lifetime-03: (with COMMENT)
>>
>> On 16 Aug 2016, at 15:43, Les Ginsberg (ginsberg) wrote:
>>
>>> Ben -
>>>
>>
>> [...]
>>
>>>>
>>>> I have just a few minor comments:
>>>>
>>>> - 1, 2nd paragraph: "... the checksum
>>>>    field MUST NOT be altered..."
>>>>
>>>> That sounds more like a statement of fact than a normative
>>>> requirement.
>>>>
>>> [Les:] It is a normative requirement stated in the base protocol
>>> specification ISO 10589. It is repeated here in order to make the
>>> point that the reason RemainingLifetime is NOT included in the
>>> checksum is that doing so would require each router flooding the LSP
>>> to modify the checksum - which MUST NOT be done.
>>
>> I don't dispute that it is effectively normative in ISO 10589. But 
>> it's not
>> normative _here_. Normally 2119 keywords should be used to create
>> materially new normative requirements, not to talk about existing 
>> ones.
>> In my opinion, it's best to use descriptive language when talking 
>> about
>> requirements established in other documents, with the exception of 
>> making
>> direct quotes from the authoritative document.
>>
>> But in any case, this is not a blocking comment; do with it what you 
>> will.
>>
>>
>>>
>>>> -1, paragraph 4:
>>>>
>>>> I’m no expert here, but are where the originator might want to 
>>>> let
>>>> the LSP
>>>> expire before it becomes unreachable? (e.g. during a graceful
>>>> shutdown?)
>>>>
>>>
>>> [Les:] I am not quite sure what you are suggesting.
>>> If a router shuts down (gracefully or not) the adjacencies to it 
>>> will
>>> quickly go down on its neighbors. This will make the router
>>> unreachable and any LSPs from that router will not be used by any
>>> other routers in the system.
>>> If I wanted to be more proactive in case of a planned shutdown I 
>>> could
>>> purge LSP #0 before bringing adjacencies. Base specification 
>>> requires
>>> that LSP #0 from a given router be present in order to use any of 
>>> the
>>> LSPs from that router.
>>>
>>> But I don’t see the relevance of discussing any of this in the
>>> context of this draft.
>>
>> Okay.
>>
>>>
>>>> -2, 4th paragraph from end: "An additional
>>>>    action is added:
>>>> "
>>>> This document adds the additional action, or ISO10589 adds it?
>>>>
>>>
>>> [Les:] This document adds the additional action. I am fine with
>>> changing the text to say:
>>>
>>> "This document introduces one additional  action:"
>>>
>>> if you find that helpful.
>>
>> I think it's helpful.
>>
>> Thanks!
>>
>> Ben.