RE: architecture and security

["Hector Trevino \(htrevino\)" <htrevino@cisco.com>]

> -----Original Message-----
> From: owner-netconf@ops.ietf.org 
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Thursday, April 06, 2006 9:21 AM
> To: Netconf (E-mail)
> Subject: architecture and security
> 
> 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)

HT: I'd expect the messages, let's say event and edit-config to be
different, because as you point out they are different. The draft
separates the event contents into Header and Data to identify event type
independent/dependent fields. Maybe I'm wrong but I don't see the
NETCONF operations identifying a header. 

Then we have the remote invocation (e.g. the RPC layer) where I agree,
all messages should be delivered in the same manner and hence have the
same headers. This is why the draft proposed the one-way-message -
preserves the architecture. I don't see an architecture problem but
rather a design choice preference. The issues that we have discussed
before and keep coming up:

1) RPC without a reply (The WG doesn't want RPCs w/o reply) 
2) Notification w/and w/o acks -- I think this one there was agreement
to go w/o acks
3) Introduction of a endless RPC 
 
 
> 
> 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/>
> 

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