Re: Some question about get-all&kill-session

[Andy Bierman <abierman@cisco.com>]

At 06:57 AM 4/26/2004, =?gb2312?B?y+++sg==?= wrote:

>I am working on a trivial implementation  based on NETCONF v1, but during
>programming,I am confused by the description, so I want to ask a few
>questions.

This is somewhat risky because NETCONF v1 isn't done yet.
But I'm glad you are implementing it!


>1. Can <get-all>  get only config  without state information?

no.

The WG decided that operators asked for a special filter to
retrieve only config data.  They did not ask for the inverse filter.
The <get> operation (was <get-all>) will retrieve all the requested
nodes specified in the 'state' parameter (this param needs to be renamed).


>The draft-ietf-netconf-prot-02 takes the following example to illustrate how
><get-all> operation works:
>      <rpc message-id="109" xmlns="http://ietf.org/netconf/base/1.0";>
>         <get-all>
>           <state xmlns="http://example.com/schema/1.2/int-stats";>
>             <interface name="ethernet0/1">
>                <intstats></intstats>
>             </interface>
>           </state>
>           <format>xml</format>
>         </get-all>
>        </rpc>
>
>
>If <get-all> can get both config and state, does it mean we can use the
>following to get config without state?
>
>       <rpc message-id="109" xmlns="http://ietf.org/netconf/base/1.0";>
>         <get-all>
>           <config xmlns="http://example.com/schema/1.2/config";>
>             <interface name="ethernet0/1">
>             </interface>
>           </config>
>           <format>xml</format>
>         </get-all>
>        </rpc>

no - use the get-config operation instead



>If we can use <get-all> to obtain the individual config information,does it
>mean <get-config> is redundant?
>
>
>2. Another question about <get-all> is how to specify the datastore(running,
>startup) in the <get-all> operation. Should we add parameter "target" to
><get-all>? Or do we mean the default target is "running", but I cannot find
>such kind of explaination in the draft.

This is a bug.
The hardwired target is the <running> configuration, but
this is architecturally broken, because the current state
data and exec commands are not part of any configuration.
(Proposal to fix this will be sent to the WG soon.)



>3. As to kill-session, I have two questions. The first one is how the
>netconf assign session-id? Is there an algorithm or just use sequencial
>number;

This is not well-defined in the draft yet.
There needs to be an elements of procedure section
for session startup and teardown, which includes
the <kill-session> procedures.

The NETCONF peer in the agent role is responsible
for managing session IDs.  (There is an open issue
wrt/ session-id returned to the peer in the manager
role during the capabilities exchange).  

Note that this schema is not stable at all, and will
probably be moved from the protocol document and deferred
until the "netconf data model" WG starts.


>The second one is how to get the session-id of current session.

The manager should not forget its session ID, but just 
in case, it is available in the netconf state schema in the spec.
See /netconf-state/sessions/my-session-id.

>Since we have no specific operation to get the session-id, I wonder how this
>operation can be implemented. Can someone can give us an example about
><kill-session>?
>
>
>Thank you

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