Subject: [NGO] NETCONF protocol extensions

From: Andy Bierman <[email-masked]>
Date: Tue, 13 Mar 2007 10:02:28 -0700

Hi Martin,

Since we're both working on different NC extensions, as are many
others I suspect, I wonder if it would be too early to discuss
some basic extensions that make the protocol work as intended,
rather than as specified.

I'm not going to list everything here, but 3 obvious extensions
that have been discussed already:

 1) test-only

    Extension to <test-option> parameter in <edit-config> operation,
    which causes the agent to validate the <source> configuration fragment
    against the <target> configuration. Processing is done in the normal 
manner,
    except the agent will exit the operation without actually performing 
the
    requested edit.

 2) with-defaults attribute

    <xs:attribute name="with-defaults" type="boolean" default="true" />

    The standard NETCONF operations are defined such that all values,
    including default values must be returned in <get>, <get-config>,
    and <copy-config> operations.  However, it is standard NM practice
    to omit generation of configuration parameters which are present
    in the agent but contain a default value selected by the agent.

    If the 'with-defaults' attribute is present in the <rpc> element,
    with a value of 'false', and the RPC method is <get>, <get-config>,
    or <copy-config>, then the agent will suppress output of any 
configuration
    parameters which contain an agent-selected default value.

    In this mode, only configuration parameters which have been
    explicitly set to a value other than the default value will
    be included in the <rpc-reply> output.  This special filter
    is applied in addition to any filter that might have been
    supplied in the request.

 3) Conventions for data model module <capability> format:
    - need to convey the fact that the capability represents a module
    - need to convey module meta-data (owner, name, version, namespace URI)

I wonder if we could have a bar-BOF to see if there is some consensus
on a small number of these inter-operability details.

thanks,
Andy

_______________________________________________
NGO mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ngo

---

From: Phil Shafer <[email-masked]>
Date: Tue, 13 Mar 2007 13:53:22 -0500

Andy Bierman writes:
>    and <copy-config> operations.

I don't believe this is true.  It's certainly not what anyone
wanted.  The presence of explicit default values is dictated
by the data model, and there are enough distinct approaches
from different data models that we would be crazy to expect
<get-config> to return all defaults.

I'm a bit confused on how this affects <get> and <copy-config>
so maybe I'm completely misunderstanding you here.

>    - need to convey module meta-data (owner, name, version, namespace URI)

Are you looking for stylistic conformace or are you looking
to parse the URI?

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 13 Mar 2007 20:44:14 +0100 (CET)

> rather than as specified.

[...]

> on a small number of these inter-operability details.

Sounds like a good idea.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 13 Mar 2007 20:48:55 +0100 (CET)

> <get-config> to return all defaults.

If they don't return the defaults, how would you get the defaults?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 13 Mar 2007 12:56:07 -0700

> <get-config> to return all defaults.

I guess it depends whether you consider a parameter with
a default value to exist or not.  NETCONF does not recognize
this nuance.  If a value exists, and it is not explicitly filtered
out in the request, then it is returned in the response.

IMO, if the agent is using some value for the parameter,

then it should be returned in a retrieval operation.
If it the type of optional parameter that does not
exist because no conceptual instances of the parameter exist,
and the parameter is ignored by the agent, then it is not returned.

> so maybe I'm completely misunderstanding you here.

The <get> operation returns the <running> config.
The config format is affected by <copy-config> from running to startup.

> Are you looking for stylistic conformace or are you looking

I know there is a CLR against parsing URIs.
They are for exact-match comparison only.

I want the minimum amount of info for inter-operable NETCONF peers
to check module version mismatch problems, based on the <capabilities>
contents.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 13 Mar 2007 13:03:27 -0700

> If they don't return the defaults, how would you get the defaults?

Presumably, like the CLI, you look up the documentation
out-of-band, hope it's right, and hope that's what the
agent is really using.  Of course, assumption is the mother
of all 20 hour debugging sessions, you one might want
a better solution.

Or you could have an explicit CLI knob to show the defaults.
That's why I proposed an explicit XML attribute knob
in the only place we are allowed to add them.

Maybe Phil would like it better if the 'default' was left
to the agent, or changed to 'false'?

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 13 Mar 2007 15:59:50 -0500

>If they don't return the defaults, how would you get the defaults?

We put 'em in our schemas.

Thanks,
 Phil