[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: action RPC I-D
Hello,
Andy Bierman wrote:
What exactly is an "action"?
It is not defined in this document.
[BALAZS]: An action could be basically any management operation. I propose 2 cases when
actions are really useful (from the draft):
1) "operations that do not change the configuration data (e.g. ping)"
2) "reading or writing a set of data that form a logical group but might be scattered in
different parts of the management data model."
For number 1) I interpret your comment as I should have written: "operations where the
main aim is an effect that does not change the configuration although the configuration
might be changed as a secondary effect."
Naturally if you want to misuse action, you could do a <balazs-get> action. However you
can misuse all other Netconf operations as well, so this is nothing new.
I believe it is impossible to give an exact, precise rule that can not be misinterpreted
about when to use actions.
I know "reboot" is an action.
What about "save and reboot" (which changes
config and then does an action)?
IMO, the agent and manager MUST know the security and
other requirements a priori anyway (via a schema), so
some generic 'container' for actions does not provide any
real value -- just extra XML.
In your 'restart' example, 'actionName' could just as well be
the actual RPC method name, and 'callingPoint' is really
just an RPC parameter, along with the entire 'parameters' sub-tree.
[BALAZS]: You are right, this is also possible. However, I try to say that doing it as a
generic action will spare us some problems, work specially with intermediate SW and vendor
specific actions.
How do you manage the allocation of action names?
You propose just xs:string as a data type, and all these
unbounded strings are in the NETCONF namespace.
This implies the WG is going to define the contents,
but that is not stated in the draft.
[BALAZS]: Good question, sorry for omitting it. Just some initial ideas:
- some other RFCs state that vendor specific extensions should be based on DNS types names
to avoid conflicts.
Do we really need a standard "action" RPC method container,
without defining any actual standard actions?
[BALAZS]: generic actions are aimed specifically for management commands that we do not
standardize. For standardized commands we still might chose between putting them into
generic actions or making them into separate operations. (But I do not want to open this
debate, I just say that the options remain open.)
thanks,
Andy
--
Balazs Lengyel Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320 Fax: +36 1 4377792
Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com
--
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/>