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

["Les Ginsberg (ginsberg)" <[e-mail]>]

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.