[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: access control on the <eventStreams> data model
- To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
- Subject: Re: access control on the <eventStreams> data model
- From: "Randy Presuhn" <randy_presuhn@mindspring.com>
- Date: Thu, 12 Jul 2007 13:50:23 -0700
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=t27mHOAqrmYJqW9rl2clBRxdce+LrIh/EkW3fzj9QzdTVF/ZdhyMKjNHeypDu1tx; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
- References: <46968A5F.2000601@andybierman.com>
Hi -
> From: "Andy Bierman" <ietf@andybierman.com>
> To: "Netconf (E-mail)" <netconf@ops.ietf.org>
> Sent: Thursday, July 12, 2007 1:09 PM
> Subject: access control on the <eventStreams> data model
...
> It is not even clear that access control "by stream" even
> makes any sense. Access control by namespace and element name
> within the data stream makes sense. What if the same data
> can appear in multiple streams? It is also more robust
> to simply exclude restricted data from the particular subscription,
> rather than reject the entire subscription, because the manager
> has access to most (but not all) of the possible data that
> could be generated in a stream. This is how access control
> works in SNMP. If you to a getnext or getbulk, it skips restricted data,
> rather than rejecting the PDU with an error.
....
But, FWIW, that's not how access control for notifications works in SNMP.
RFC 3413 3.3 (2)
Randy
--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>