Subject: Re: [NGO] NETCONF protocol extensions

From: Balazs Lengyel <[email-masked]>
Date: Fri, 06 Apr 2007 09:22:44 +0200

Hello,
1) We support this. Ericsson actually has implemented something like "test-only". It would also 
clarify an important point in the original RFC: whether to use inline-configuration data in the 
<validate> operation which is explicitly supported by the XSD but not according to the text part.
2) A useful idea. If we do it, I strongly support the explicit indication whether defaults are 
requested to be returned or not.
3) Would be good.
Balazs

Andy Bierman wrote:
> 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

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

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