RE: WG last call: Coex draft

"Wijnen, Bert (Bert)" <[email protected]>
Newsgroups gmane.ietf.snmpv3
Message-ID <7D5D48D2CAA3D84C813F5B154F43B15583D8C2@nl0006exch001u.nl.lucent.com>
> > Notice that this is in line with what would happen in a pure SNMPv3
> > environment:  a notification is not sent to a given target if any
> > of the mandatory varbinds would be out-of-view for that target.  There
> > is a good reason for doing this:  a notification definition (whether
> > specified by an SMIv2 NOTIFICATION-TYPE or an SMIv1 TRAP-TYPE
> > definition) lists mandatory varbinds that a notification receiver
> > can always expect to receive.  Selectively stripping away out-of-view
> > varbinds as specified in rfc 2089 would violate that contract.
> 
> If that's the basis for it, then shouldn't the behavior depend on whether
> or not that Counter64 object is one that is required by the notification
> definition, versus one that has been added by the implementation?  This
> would, I suppose, assume that the proxy has knowledge of the 
> notification definition.
> 
Theorethically... one could make things more complex and do as you suggest
and possibly pass notifications if the Counter64 objects were "extra"
(i.e. not part of the mandatory set).
But... we're doing all this to allow for a co-existence during a migration
from SNMPv1 to SNMPv3 (or so I would hope). So adding this additional
complexity seems not warranted to me.

Bert
> --
> Michael Kirkham
> www.muonics.com
>
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.