RE: raqmon mib comments

Juergen,

Before I address your questions, I would like a clarification from you. RAQMON defines two MIB modules. There is a RAQMON-MIB defined in draft-ietf-rmonmib-raqmon-mib-07.txt, and there is a RAQMON-RDS-MIB defined in draft-ietf-rmonmib-raqmon-pdu-09.txt. I believe that you refer to the RAQMON-RDS-MIB in your mail, because this is the module that includes the infamous table with 4 index objects and 28 accessible-for-notify objects. However you refer to it as 'RAQMON MIB' in your mail. Please clarify, and if possible change the subject line as well, in order to avoid confusion. 

Thanks and Regards,

Dan



> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]]On Behalf Of Juergen Schoenwaelder
> Sent: 18 January, 2005 1:27 PM
> To: [email protected]
> Subject: [RMONMIB] raqmon mib comments
> 
> 
> 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
> 
> _______________________________________________
> RMONMIB mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rmonmib
>