Subject: [Netconf] with-defaults draft submitted

From: Balazs Lengyel <[email-masked]>
Date: Wed, 27 Aug 2008 10:04:10 +0200

Hello,
I submitted the 00 version of the WITH-DEFAULTS draft.
http://tools.ietf.org/id/draft-bierman-netconf-with-defaults-00.txt

I would like to have it accepted as a NETCONF WG item. If you agree that it is important to 
define this capability please support it, even if you are unhappy with the exact solution, 
which can be debated/changed/agreed in the WG. During this work we also intend to take into 
account whatever the NETMOD group says about the topic.

Balazs

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Aug 2008 11:33:44 +0200

On Wed, Aug 27, 2008 at 10:04:10AM +0200, Balazs Lengyel wrote:

> I would like to have it accepted as a NETCONF WG item. If you agree
> that it is important to define this capability please support it,
> even if you are unhappy with the exact solution, which can be
> debated/changed/agreed in the WG. During this work we also intend to
> take into account whatever the NETMOD group says about the topic.

I support this document becoming a WG work item.

Two comments from a quick read:

- I suggest to add text to the motivation that says that suppressing /
  enabling defaults enables humans to better understand what is part
  of the explicit config of a device and what is just defaults. Right
  now, the motivation talks more about technical resources (bandwidth
  and CPU consumption aspects) but I am much more concerned about
  human resources (lots of defaults can hide the real config).

- Considering section 7.2, what I really like to have is "all" and
  "explicit" - I do not really care that much about "trim".

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Aug 2008 11:33:44 +0200

/js

---

From: Phil Shafer <[email-masked]>
Date: Wed, 27 Aug 2008 10:14:23 -0400

>http://tools.ietf.org/id/draft-bierman-netconf-with-defaults-00.txt

I support this work becoming a WG item.

Comments:

>   The NETCONF protocol defines ways to read configuration data from a
>   NETCONF agent.  Part of this data is not set by the NETCONF manager,
>   but rather set to a default value by the NETCONF agent.

Remember that default values may never be "set".  It's an
implementation issue when and how the default mechanism
works.

>   Is is often not useful for network operators to view all

s/Is/It/

>   these default values.  It is usually more interesting to view just
>   the parameters which have been explicitly set by the network
>   operator.

Make clear you are talking about human operators.

>   However there are perfectly valid use-cases when a NETCONFrom [email-masked]  Wed Aug 27 07:28:37 2008
To: Balazs Lengyel <[email-masked]>
Date: Wed, 27 Aug 2008 10:14:23 -0400
From: Phil Shafer <[email-masked]>
Cc: netconf mailing list <[email-masked]>
Subject: Re: [Netconf] with-defaults draft submitted
Sender: [email-masked]

>http://tools.ietf.org/id/draft-bierman-netconf-with-defaults-00.txt

I support this work becoming a WG item.

Comments:

>   The NETCONF protocol defines ways to read configuration data from a
>   NETCONF agent.  Part of this data is not set by the NETCONF manager,
>   but rather set to a default value by the NETCONF agent.

Remember that default values may never be "set".  It's an
implementation issue when and how the default mechanism
works.

>   Is is often not useful for network operators to view all

s/Is/It/

>   these default values.  It is usually more interesting to view just
>   the parameters which have been explicitly set by the network
>   operator.

Make clear you are talking about human operators.

>   However there are perfectly valid use-cases when a F manager
>   will need the default data from the node.  Documentation about
>   default values is often unreliable or unavailable.

Hopefully YANG will help eliminate this problem, allowing apps to
know the fixed values for defaults.  with-defaults will not solve
the problem of making something with an unknown value because you
don't know the default.  Waiting until after you made it to know
what you made isn't a workable solution.

>   Some management
>   applications might not have the capabilities to correctly parse and
>   interpret formal data models.  Human users might want to understand
>   the received data without extensive consultation of the
>   documentation.  In all theses cases the NETCONF manager will need

s/theses/these/

>   default data as part of the NETCONF rpc reply messages.
>...
>   o  Default data: Data that is set by the NETCONF agent whenever the
>      NETCONF manager does not provide a specific value for the relevant
>      data item.  In the context of this document only configuration
>      data is considered, state data is excluded.

See previous comment re: "data that is set"

>   The NETCONF
>   agent MUST also indicate it's default behavior, whether it sends
>   default data in the absence of any specific request from the NETCONF
>   manager.

Do we need this feature?  Can it simply default to "off"?  Isn't
it a pain to check the state before knowing you can turn it off?

>   The identifier MAY have a second parameter indicating how it treats
>   explicitly set default data.  If the explicit-default parameter is
>   set to "unrecognized" the agent MUST treat explicitly set default
>   data as normal default data.  If the parameter is set to recognized
>   this means that such data is not treated as default data.  All other
>   values for the parameter or a missing parameter is handled as the
>   value unrecognized.
>
>   urn:ietf:params:netconf:capability:with-defaults?default=false&
>   explicit-default=recognized

Is there a more suitable term than "recognized"?  Even "true"
seems more clear.

>   A new 'with-defaults' XML attribute is used to control the generation
>   of default data.  If the 'with-defaults' attribute is present in the
>   <rpc> element, of the affected operations, the agent will use it's
>   value to control whether default data is returned in the NETCONF rpc
>   reply messages.

I strongly dislike putting this as an attribute on <rpc>:

1) It's a horrible precedent.  Imagine every capability defining
an attribute instead of modifying the proper operations.  <rpc>
will become a dumping ground.

2) with-defaults isn't a generic attribute, but applies to
a specific set of operations.  Better to have it ties directly
to those operations via a new element within their <input>
arguments (in YANG-speak).  The list of affected operations is
short enough that this is a simple solution:

>   Affected operations:
>   o  <get>
>   o  <get-config>
>   o  <copy-config>

Putting in on the <rpc> is like making it an argument to every RPC
but ignoring it for all but these three.

3) In YANG, this capability would be an augmentation of the input
arguments to those three operations.  There's no mechanism in YANG
to address adding an attribute to <rpc>.

>   Index clause components are not subject to default suppression.

"index clause"?  Is that snmp-speak?

>   If
>   an element within the configuration database is considered to be part
>   of a key, and represents one of the naming components for a
>   conceptual data structure which allows multiple named instances of an
>   ancestor node, then this element is never suppressed, regardless of
>   the value of the 'with-defaults' attribute.

Keys don't have default values, so this isn't really an issue.

>      <rpc message-id="102" with-defaults="false"
>           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>        <get>
>          <filter type="subtree">
>            <interfaces xmlns="http://example.com/interfaces/1.2"/>
>          </filter>
>        </get>
>      </rpc>

Should be:

      <rpc message-id="102"
          NETCONF manager
>   will need the default data from the node.  Documentation about
>   default values is often unreliable or unavailable.

Hopefully YANG will help eliminate this problem, allowing apps to
know the fixed values for defaults.  with-defaults will not solve
the problem of making something with an unknown value because you
don't know the default.  Waiting until after you made it to know
what you made isn't a workable solution.

>   Some management
>   applications might not have the capabilities to correctly parse and
>   interpret formal data models.  Human users might want to understand
>   the received data without extensive consultation of the
>   documentation.  In all theses cases the NETCONF manager will need

s/theses/these/

>   default data as part of the NETCONF rpc reply messages.
>...
>   o  Default data: Data that is set by the NETCONF agent whenever the
>      NETCONF manager does not provide a specific value for the relevant
>      data item.  In the context of this document only configuration
>      data is considered, state data is excluded.

See previous comment re: "data that is set"

>   The NETCONF
>   agent MUST also indicate it's default behavior, whether it sends
>   default data in the absence of any specific request from the NETCONF
>   manager.

Do we need this feature?  Can it simply default to "off"?  Isn't
it a pain to check the state before knowing you can turn it off?

>   The identifier MAY have a second parameter indicating how it treats
>   explicitly set default data.  If the explicit-default parameter is
>   set to "unrecognized" the agent MUST treat explicitly set default
>   data as normal default data.  If the parameter is set to recognized
>   this means that such data is not treated as default data.  All other
>   values for the parameter or a missing parameter is handled as the
>   value unrecognized.
>
>   urn:ietf:params:netconf:capability:with-defaults?default=false&
>   explicit-default=recognized

Is there a more suitable term than "recognized"?  Even "true"
seems more clear.

>   A new 'with-defaults' XML attribute is used to control the generation
>   of default data.  If the 'with-defaults' attribute is present in the
>   <rpc> element, of the affected operations, the agent will use it's
>   value to control whether default data is returned in the NETCONF rpc
>   reply messages.

I strongly dislike putting this as an attribute on <rpc>:

1) It's a horrible precedent.  Imagine every capability defining
an attribute instead of modifying the proper operations.  <rpc>
will become a dumping ground.

2) with-defaults isn't a generic attribute, but applies to
a specific set of operations.  Better to have it ties directly
to those operations via a new element within their <input>
arguments (in YANG-speak).  The list of affected operations is
short enough that this is a simple solution:

>   Affected operations:
>   o  <get>
>   o  <get-config>
>   o  <copy-config>

Putting in on the <rpc> is like making it an argument to every RPC
but ignoring it for all but these three.

3) In YANG, this capability would be an augmentation of the input
arguments to those three operations.  There's no mechanism in YANG
to address adding an attribute to <rpc>.

>   Index clause components are not subject to default suppression.

"index clause"?  Is that snmp-speak?

>   If
>   an element within the configuration database is considered to be part
>   of a key, and represents one of the naming components for a
>   conceptual data structure which allows multiple named instances of an
>   ancestor node, then this element is never suppressed, regardless of
>   the value of the 'with-defaults' attribute.

Keys don't have default values, so this isn't really an issue.

>      <rpc message-id="102" with-defaults="false"
>           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>        <get>
>          <filter type="subtree">
>            <interfaces xmlns="http://example.com/interfaces/1.2"/>
>          </filter>
>        </get>
>      </rpc>

Should be:

      <rpc message-id="102"
     xmlns:wdef="urn:whatever:netconf:with-defaults"
           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <get>
          <wdef:with-default>false</wdef:with-defaults>
          <filter type="subtree">
            <interfaces xmlns="http://example.com/interfaces/1.2"/>
          </filter>
        </get>
      </rpc>

>7.1.  Augmenting the base RPCs
>
>   Instead of using an attribute on the RPC element we could "augment"
>   the relevant NETCONF operations with an extra XML element with a
>   similar meaning.

Coooool.......

>   Pro: parameters on RPC are for vendor extensions.  We should not put
>   standard stuff there.

See other Pros above.

>   Contra: Some people might consider this a violation of [RFC4741] as
>   the XSD does not allow adding new elements.  As there is no NETCONF
>   YAM (at least not yet), what do we actually augment?  Also there are
>   multiple ways of defining RFC4741 in YANG.  The description will be
>   perfectly clear, but it can never be fed into YANG tools.

If you see this as a violation, you are condemning all future changes
to base operations to the same fate.  I'd say declare this lack of
flexibility in 4741's XSD a bug and fix it there.

Thanks,
 Phil

       xmlns:wdef="urn:whatever:netconf:with-defaults"
           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <get>
          <wdef:with-default>false</wdef:with-defaults>
          <filter type="subtree">
            <interfaces xmlns="http://example.com/interfaces/1.2"/>
          </filter>
        </get>
      </rpc>

>7.1.  Augmenting the base RPCs
>
>   Instead of using an attribute on the RPC element we could "augment"
>   the relevant NETCONF operations with an extra XML element with a
>   similar meaning.

Coooool.......

>   Pro: parameters on RPC are for vendor extensions.  We should not put
>   standard stuff there.

See other Pros above.

>   Contra: Some people might consider this a violation of [RFC4741] as
>   the XSD does not allow adding new elements.  As there is no NETCONF
>   YAM (at least not yet), what do we actually augment?  Also there are
>   multiple ways of defining RFC4741 in YANG.  The description will be
>   perfectly clear, but it can never be fed into YANG tools.

If you see this as a violation, you are condemning all future changes
to base operations to the same fate.  I'd say declare this lack of
flexibility in 4741's XSD a bug and fix it there.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 28 Aug 2008 09:08:05 +0200 (CEST)

Balazs Lengyel <[email-masked]> wrote:
> that it is important to define this capability please support it

I support this work.

Some comments:

  o  Section 1.

     Another reason for not sending defaults is that if you take a
     config backup and later restore it, you don't want all the
     defaults to be explicitly set.  [with your terminology; when
     explicit-defaults=unrecongnized]

  o  2.3 & 5

     The capability URIs do not match.

  o  Open issue 7.1

     I agree w/ Phil that the correct solution is to add a parameter
     to the existing rpcs.  Even though this is strictly not allowed
     by the XSD in RFC 4741, I think the idea is that capabilities are
     allowed to "augment" existing operations.

  o  Open issue 7.2

     I prefer your current solution with 'explicit-default' over
     making with-defaults have three values.  Your solution makes it
     clear what the box really does.

Nits:

--------------------

s/it's/its/g

--------------------

>   It is not defined in [RFC4741] whether default data is part of the
>   datastore/data model, or if it meta data that influences the behavior
                          ^^^^^^^^^^^^^
>   of the NETCONF server device but is not actually part of the
>   datastore. 

--------------------

>   explicitly set default data.

s/it/the NETCONF agent/

--------------------

s/effected/affected on several places

--------------------

1.1.2.  says that "agent" and "manager" are defined in RFC 4741.  They
are not really defined there, and RFC 4741 uses the terms "client"
(32) and "server" (59) more than "manager" (4) and "agent" (1).

--------------------

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 28 Aug 2008 09:08:05 +0200 (CEST)

I support this work.

Some comments:

  o  Section 1.

  o  2.3 & 5

  o  Open issue 7.1

  o  Open issue 7.2

Nits:

--------------------

s/it's/its/g

--------------------

                          ^^^^^^^^^^^^^

--------------------

s/it/the NETCONF agent/

--------------------

--------------------

--------------------

/martin

---

From: David Partain <[email-masked]>
Date: Thu, 28 Aug 2008 14:26:45 +0200

Hi,

I certainly support the NETCONF working group taking on this work and starting 
from draft-bierman-netconf-with-defaults-00.txt

Cheers,

David

---

From: David Partain <[email-masked]>
Date: Thu, 28 Aug 2008 14:26:45 +0200

Hi,

Cheers,

David

---

From: Andy Bierman <[email-masked]>
Date: Thu, 28 Aug 2008 13:23:28 -0700

> it a pain to check the state before knowing you can turn it off?

Some people have commented that the default MUST be 'on'
instead of 'off'.  If the application knows which is
the default, that is good enough.

Old managers do not know about the new with-defaults
capability no matter what the default.  Old managers
should keep getting whatever response they used to get,
before YANG came along and starting making all these CLRs.

So there cannot be a default because RFC 4741 never mentions
filtering out agent-supplied values at all.  This either means
that the agent MUST NOT filter out any values or it means
the agent can do whatever it wants.

Assuming we agree on the latter, then the agent should
be free to keep the same default behavior it already supports.

>>   data as normal default data.  If the parameter is set to rFrom [email-masked]  Thu Aug 28 13:23:39 2008
Date: Thu, 28 Aug 2008 13:23:28 -0700
From: Andy Bierman <[email-masked]>
To: Phil Shafer <[email-masked]>
Cc: netconf mailing list <[email-masked]>
Subject: Re: [Netconf] with-defaults draft submitted
Sender: [email-masked]

> it a pain to check the state before knowing you can turn it off?

Some people have commented that the default MUST be 'on'
instead of 'off'.  If the application knows which is
the default, that is good enough.

Old managers do not know about the new with-defaults
capability no matter what the default.  Old managers
should keep getting whatever response they used to get,
before YANG came along and starting making all these CLRs.

So there cannot be a default because RFC 4741 never mentions
filtering out agent-supplied values at all.  This either means
that the agent MUST NOT filter out any values or it means
the agent can do whatever it wants.

Assuming we agree on the latter, then the agent should
be free to keep the same default behavior it already supports.

>>   data as normal default data.  If the parameter is seecognized

I do not mind making them leafs instead.
It could be argued that the attrributes in
the <rpc> element are intended as a vendor sandbox,
but that doesn't mean standards should also use it.

> https://www.ietf.org/mailman/listinfo/netct to recognized

I do not mind making them leafs instead.
It could be argued that the attrributes in
the <rpc> element are intended as a vendor sandbox,
but that doesn't mean standards should also use it.

> https://www.ietf.org/mailman/listinfonf
> 
> 
> 

Andy

o/netconf

Andy