RE: Opsdir telechat review of draft-ietf-bier-isis-extensions-07

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Joe -

> -----Original Message-----
> From: Joe Clarke (jclarke)
> Sent: Wednesday, February 21, 2018 1:27 PM
> To: Les Ginsberg (ginsberg) <ginsberg@xxxxxxxxx>; ops-dir@xxxxxxxx
> Cc: bier@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-bier-isis-extensions.all@xxxxxxxx
> Subject: Re: Opsdir telechat review of draft-ietf-bier-isis-extensions-07
> 
> On 2/21/18 13:24, Les Ginsberg (ginsberg) wrote:
> >> The only substantive comment I have is in section 5.6 regarding
> >> reporting misconfigurations.  What is not stated is _how_ this is to
> >> be done.  There is no reference to a standard BIER or IS-IS mechanism
> >> with how this reporting should be carried out.  For operational
> >> consistency, I feel some guidance should be offered.
> >>
> > [Les:] Implementations have many possible vehicles for logging
> > errors/significant events. There are proprietary logging mechanisms,
> > standardized network management events, etc. I don’t think it is
> > within scope of this document to discuss (for example) the YANG model
> > - nor is it in general within the scope of the IETF to specify how
> > proprietary logging mechanisms should work. So I really have no clue
> > as to what you expect here.
> >
> > We are simply specifying that  implementations treat this as a
> > loggable event. How they do it is out of scope.
> 
> In my read of this, it was the use of "report" vs. logging that threw me.  Not
> being the BIER guy, I wasn't sure if you were referring to some protocol-
> specific inband signaling to indicate the misconfiguration to other routers.
> 
> I agree that the implementation of how operational notifications should be
> done is outside this scope.  But given that you use "logging" in here, it might
> be sufficient just to say "(e.g., through its logging channels)".  That said, I
> might be alone in this interpretation.
> 
[Les:] OK - how about:

<begin>
Section: Logging Misconfiguration
Whenever an advertisement is received which violates any of the constraints defined in this document the receiving router MUST support logging this occurrence. Logging SHOULD be dampened to avoid excessive output."
<end>

??

   Les

> Joe




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux