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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.