On 2/21/18 16:36, Les Ginsberg (ginsberg) wrote: > 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> > > ?? I would not have raised this point if that's how it had read. That is much clearer that this is logging (or reporting or notifying) for out-of-band operational purposes. Joe
