Hi -
From: "Andy Bierman" <ietf@andybierman.com>
To: "Randy Presuhn" <randy_presuhn@mindspring.com>
Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Sent: Thursday, July 12, 2007 2:28 PM
Subject: Re: access control on the <eventStreams> data model
...
But, FWIW, that's not how access control for notifications works in SNMP.
RFC 3413 3.3 (2)
...
I think you mean para 4, point 2:
yes
...
The difference seems to be that (on a PER-NOTIFICATION basis)
the entire PDU is dropped if any data within it is restricted.
This is fine -- easier on the agent than pruning the restricted data
and sending the rest.
yes, particularly in the case of SNMP where the NOTIFICATION-TYPE
may specify mandatory variable bindings, but other stuff may be
included by an implementation.
But this is much different than refusing to let the manager see
the name of the stream or rejecting the <create-subscription>
because individual notifications may not be delivered.
Since it's reasonable for permissions to change over time,
I think it makes no sense to block creation of a subscription
based on whether the notifications that could be generated
in the future might be blocked at the moment. Particularly in
the case of creating a subscription with respect to things
that might not exist at the moment. But that having that kind
of flexibility might be an SNMP-centric view of the world.