architecture and security

[Andy Bierman <ietf@andybierman.com>]

Hi,

I think the architecture for netconf notifications needs more attention.
The current draft tries to fit notifications into the existing model
for remote procedure calls.  The <rpc-one-way> is supposedly just
like a regular <rpc>, except it goes from the agent to the manager,
and there is no return value.  Also, the WG decided (based on
Junoscript experience) that returning <ok> was better than
no return value -- we explicitly don't want a 1-way-rpc --
in either direction.


There are 2 major problems with this architecture:

1) Headers are different becase the messages are different;
  Notifications have different general characteristics
  than RPC requests, so the headers will be different
  (e.g., no timestamp in an RPC request like a notification)

2) Access control is backwards;
  It doesn't make sense to apply access control to the '1 way RPC'
  in the same sense as a regular RPC.  It is the manager who is
  supposed to have access granted to view specific agent data -- not
  the agent that is supposed to have access granted to
  send the manager specific agent data.


Even though the term <rpc-one-way> is being removed, and the
message will be called <notification> instead (as it is on
page 17), we still need a secure architecture which scales well,
and will support a user-based access control model.
We need to think of how notifications fit into the base
netconf protocol, as well as existing security and NM protocols.
Operational issues and common use cases (e.g., building power-cycle)
need to be addressed.

Once the requirements and architecture are understood,
we will be able to simplify and focus the API.  It isn't
acceptable to come to the conclusion that a feature is
a 95% lose-lose scenario, but we should do it anyway.


Andy



--
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/>