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. Joe
