RE: RAQMON PDU Notification Objects - Table or Scalar?

See in-line. 

Regards,

Dan



> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]]On Behalf Of Randy Presuhn
> Sent: 26 January, 2005 10:35 PM
> To: [email protected]
> Subject: Re: [RMONMIB] RAQMON PDU Notification Objects - 
> Table or Scalar?
> 
> 
> Hi -
> 
> > From: "Romascanu, Dan (Dan)" <[email protected]>
> > To: "Mark Ellison" <[email protected]>
> > Cc: <[email protected]>
> > Sent: Wednesday, January 26, 2005 10:25 AM
> > Subject: RE: [RMONMIB] RAQMON PDU Notification Objects - 
> Table or Scalar?
> ...
> > What I got until now:
> >
> > - SNMP is optional and not recommended.
> 
> I had understood it to be "SNMP is optional" and "use of 
> traps is NOT RECOMMENDED"

yes - better wording

> 
> > - if SNMP is supported, recommend doing INFORMs
> 
> > RDS-MIB structure. three options:
> >
> > - keep the table as is, define initital and continuous 
> reporting notifications
> > - keep table but change indexing as suggested by Mark, 
> initial notification points
> >   to subsession identifiers, then continuous notifications use this
> > - change to scalar
> ...
> 
> Can you confirm or deny whether it was a goal to, as Mark put it,
> "commingle statistics from different (sub)sessions in a 
> single report "?

It is not an explicit goal, but an implicit one. The other RAQMON transport (over TCP) has this capability, and it would be very nice to have it in the SNMP notifications transport. 

> This, and effectively dropping TRAPs as way of carrying this stuff,
> will affect which of the alternatives would make more sense.
> 
> Randy
> 
> 
> 
> 
> _______________________________________________
> RMONMIB mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rmonmib
>