|
> > And e.g. draft-ietf-isms-secshell-15 defines the SSH transport model > > in the same Internet-Draft as the MIB for managing it. > > I agree that the MIB Module example is not the best illustration of the > concept. One would not expect the protocol being managed to be defined > within the MIB Module. It's OK to include a MIB Module in the document that > defines the protocols, but not the other way around. No? I'd agree with Pasi in the case where the service is defined (either within the same document or elsewhere). In such a situation, it should be sufficient for the RADIUS attribute document to either reference the service definition (if it is in another document) or to include it within the same document. This is an editorial decision outside the scope of the Design Guidelines document. The issue that this text was attempting to address was a situation in which there is no definition for the service, either within the document or elsewhere. In this situation the Design Guidelines document is pointing out that designing management attributes (or MIBs for that matter) for a service that is undefined is not a "best current practice". For example, while a "RADIUS Attributes for IPv8" document might meet all the RADIUS Design guidelines, the fact that the document includes no reference for IPv8 is a problem of a non-editorial nature. Believe it or not, this problem has actually come up in practice (more than once!). |