raqmon mib comments
Juergen Schoenwaelder <[email protected]>
| Newsgroups | gmane.ietf.rmonmib |
|---|---|
| Message-ID | <20050118112633.GA2526@james> |
Hi! I am new to this list and I was lazy to not read the archives (sorry). There was a discussion on the MIB reviewers mailing list triggered by the RAQMON MIB and this lead me to scan the documents. Since some of my concerns are really RAQMON specific, Bert asked me to post them here which I do now. - I find MIB tables which consist of 4 index object and 28 accessible-for-notify objects a strange construction. If you do this, you should at least spell out which combinations of objects can be reasonably expected for which notification. If all 28 objects are shipped, it is not unlikely that the notifications well exceed the 484 byte message boundary (my smidump tool can't compute the precise numbers since all the 28 objects are optional ;-). - I generally question the two transports solution. Interoperability comes from choosing one way of doing things not two. The solution that you require the RAQMON receivers to support both does not really convince me. - There is text such as "SNMP informs give you congestion safety" which I simply do not understand without further qualification/discussion. - There is text implying that TLS is good enough to make security folks happy which I believe won't make them happy. You should at least spell out how TLS is used, whether you expect certificates on both the client and the server side and so on. Note that key management is a critical issue to worry about because it impacts ease of deployment (and thus success of the whole effort). I did not read the documents in detail - so I might be totally off with my comments. Anyway, since I raised them on another list, I think it is just fair to discuss these things here and to take the blame for my misunderstandings. /js -- Juergen Schoenwaelder International University Bremen <http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany