Subject: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Tue, 04 May 2010 18:06:42 +0200

We have one day left before thsi WG Last Call ends.
If you do have any comments, pls make sure we get it no later than 
tomorrow May 5th (any timezone)

Bert and Mehmet

Bert Wijnen (IETF) wrote:
> This email starts a formal WG Last Call for the
> draft-ietf-netconf-with-defaults-07.txt document
>
> The document is intended to be published as Proposed Standard.
>
> WGLC ends on May 5th 2010 (any timezone).
>
> Pls do review and send us your comments and feedback.
> Also, if you see no problems with the document pls let us know.
> A comment like:
>      I read the document and am happy with it.
> isusefull too.  It helps us determine how many people actually did 
> review.
>
> Thanks,
> Bert and Mehmet (WG chairs)
>
>
> ----- Original Message ----- From: [email-masked]
> To: [email-masked]
> Cc: [email-masked]
> Sent: Monday, April 19, 2010 2:45 PM
> Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-07.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Network Configuration Working Group 
> of the IETF.
>
>
> Title           : With-defaults capability for NETCONF
> Author(s)       : A. Bierman, B. Lengyel
> Filename        : draft-ietf-netconf-with-defaults-07.txt
> Pages           : 21
> Date            : 2010-04-19
>
> The NETCONF protocol defines ways to read configuration data from a
> NETCONF server.  Part of this data is not set by the NETCONF client,
> but rather a default value is used.  In many situations the NETCONF
> client has a priori knowledge about default data, so the NETCONF
> server does not need to send it to the client.  In other situations
> the NETCONF client will need this data as part of the NETCONF <rpc-
> reply> messages.  This document defines a capability-based extension
> to the NETCONF protocol that allows the NETCONF client to control
> whether default values are part of NETCONF <rpc-reply> messages or
> <copy-config> output to the target URL.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-netconf-with-defaults-07.txt 
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 5 May 2010 15:12:12 +0200

> tomorrow May 5th (any timezone)

Given that RFC 4741bis is defining NETCONF 1.1, it might have been
better to integrate with-defaults straight into 4741bis instead of
using a separate document with YANG augmentations and a recommendation
that every server SHOULD implement with-defaults, thus leaving the
behaviour of the base protocol itself unspecified when it comes to
defaults.

I do understand the procedural counter argument. Still I thought I air
this observation one more last time.

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 05 May 2010 15:22:53 +0200

> behaviour of the base protocol itself unspecified when it comes to

+1

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Wed, 5 May 2010 09:22:45 -0400

Juergen Schoenwaelder writes:
>better to integrate with-defaults straight into 4741bis ...

I would object to including it directly in 4741bis.  I'm uncomfortable
with this idea "that RFC 4741bis is defining NETCONF 1.1" and hope
that we can limit "bis" to clarification and mild improvments without
inventing new material.  If the true goal is to invent new material,
we should stop calling it "bis" and start calling it "NETCONF 2".

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 05 May 2010 16:11:40 +0200

> we should stop calling it "bis" and start calling it "NETCONF 2".

Actually, YANG is the new material here, and YANG uses a few important
assumptions related to the concept of default values, so IMO the ability
of the server to tell (at the very least) its way of handling defaults
is a critical prerequisite for YANG.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Wed, 05 May 2010 07:42:11 -0700

>> we should stop calling it "bis" and start calling it "NETCONF 2".

According to wikipedia, 'bis' does essentially mean NETCONF '2'.
So what?

We have no requirement to maintain backward compatibility
with RFC 4741.  We are cycling at Proposed Standard.
You can expect that servers compliant to 4741 will need
to do some work to be compliant to 4741bis.

There are specific detailed changes that the WG is
debating, 1 at a time, such as the 'capability-changed' error.
It does not help to debate abstractions such as whether
this is version 1.1, 1.5, or 2.0.

> is a critical prerequisite for YANG.

YANG does specify default behavior.
It says the server MAY leave them out.
What's the problem?  We don't care
about non-YANG content anymore in NETCONF, right?
>From a standards POV, it's simply not our problem anymore.
So how NETCONF handles defaults outside of YANG is
an issue outside the scope of the standard.

>>  Phil

Andy

---

From: Kent Watsen <[email-masked]>
Date: Wed, 5 May 2010 15:38:19 -0700

Lada writes:
> IMO the ability of the server to tell (at the very least) its way
> of handling defaults is a critical prerequisite for YANG.

I agree that this part of the I-D is good; it's important servers define their basic-mode so clients know how to interoperate with them

It's the other part of this I-D, forcing trim/explicit servers to support report-all without tagging, that I continue to have issues with; the questions asked in last the email I sent on April 5th remain open

As I was explaining to Phil, if supporting report-all was optional, surely Juniper would not, since the downside risks far exceed any value it brings (our schema-defined defaults are always correct).  But since supporting report-all is currently not optional, Juniper instead needs to decide if it's going to support this capability at all

Personally, I think this I-D has a great opportunity to introduce the use of attributes to let explicit/trim-servers tag the default values as such.  Not only does this remove the downside risks for explicit servers, but it also enables thin-clients to act on that extra bit on information.  Note: thin-client could be the on-box web interface.  Now that it's been established that the WG has never defined a concern for using attributes for metadata, and there are many good reasons for wanting to do so, it seems like its time has come

Please either remove the "MUST support report-all" requirement or introduce support for tagging defaults

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Wed, 05 May 2010 16:10:59 -0700

> Please either remove the "MUST support report-all" requirement or introduce support for tagging defaults

I don't see how you could possibly get the XML attribute tag
for a leaf that wasn't there (in the reply).  You have to return
all the nodes in order to return their tags (that means report-all).

The WG already decided to have different modes to retrieve only
the nodes that matched that mode.  This is viewed as a service,
rather than requiring the client to go through a
'report-all-with-xml-attributes' for everything and derive
the current functionality.

A client can lock the config and diff the various <rpc-reply>
contents if they want to construct a tagged reply within
the application.

The point of the with-defaults capability
is to let the client retrieve data with the defaults,
instead of allowing the server to omit any leafs.
If you don't want to support that functionality
in your server, then don't implement this draft.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 5 May 2010 19:13:11 -0400

>all the nodes in order to return their tags (that means report-all).

Kent's suggestion is to flag default leafs with an attribute
that makes it obvious that these are defaults, like:

    <system>
        <services>
             <netconf>
                 <port wd:default="true">830</port>
             </netconf>
         </services>
    </system>

This is meant to allow thin clients to know that a value
is the default, not "real", and to allow servers to ignore
incoming leafs that have this attribute, removing the risk
that some app will try to load default-laden config.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 05 May 2010 17:29:44 -0700

> that some app will try to load default-laden config.

I don't think anyone wanted to add this to the draft.
The client can get-config(report-all) and check the
YANG file to see which values happen
to equal the YANG default value.

The client can also retrieve report-all and then trim,
and compare them.  The nodes missing in the
2nd reply are the ones set to the YANG default.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Wed, 5 May 2010 19:43:04 -0700

> I don't think anyone wanted to add this to the draft

But this is what *I've* been asking for all along.  Good grief, my very first "with-defaults" email on 9/24/2009 was:

	"My primary comment is that, when using "report-all", the client
	 has no way of knowing which values were explicitly set without
	 also getting the "explicit" config, which would be a waste of
	 bandwidth...

	 A simple fix to this is to have "report-all" mark the default
	 nodes with an attribute indicating just that.  For instance:

	    <mtu is-default="true">1500<mtu>

	 This approach not only resolves the issue mentioned above, but it
	 also allows the output to be fed directly back into an <edit-config>
 	 operation without worries of the device creating a bunch of user-
	 defined nodes in the config tree"

> to equal the YANG default value.

If the client is schema-aware, it won't ask for report-all in the first place.  Again, see my April 5 email.

> 2nd reply are the ones set to the YANG default.

A waste of bandwidth and still doesn't resolve the round-tripping concern

Why not support tagging default values?  Now that we've concluded that the WG has never defined a concern for using attributes for metadata, what technical issue is holding us back now?

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 06 May 2010 07:49:25 +0200

Kent Watsen píše v St 05. 05. 2010 v 15:38 -0700:
> I agree that this part of the I-D is good; it's important servers
> define their basic-mode so clients know how to interoperate with them
> 

So how about moving the "basic-mode" announcement to RFC 4741bis and
dealing with "also-supported" and the modifications to the existing
operations in a separate document?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 06 May 2010 09:09:22 +0200 (CEST)

Hi,

Kent Watsen <[email-masked]> wrote:
> But this is what *I've* been asking for all along.  Good grief, my
> very first "with-defaults" email on 9/24/2009 was: 
> 

I agree that this seems useful.  I.e., if the client asks for
"report-all", the server MAY add a wd:is-default attribute.  The
reason for the MAY is that a server that has report-all as basic-mode
typically can't do this, so it is useful for explicit and trim servers
only.

> 	 defined nodes in the config tree"

But this part has bigger impact on existing code, and probably needs
more thought, esp. how it interacts with edit-config default-operation
and operation attribute.  Take Phil's example:

    <system>
        <services>
             <netconf>

What's really in the db might be just <system/>.

If you send this back in an edit-config, you might use
default-operation replace.  But this will (may) create the services
and netconf nodes even though they were not there in the original db.

One argument against sending data-model info in the reply was that it
is a slippery slope; why not also send the type of each leaf?  why not
indicate which leafs are keys? etc.  But in this case the operation
(report-all) explicitly asks the server to add nodes based on whether
they are defaults or not, so it makes sense to let the server mark
those nodes so the client knows which they are.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 06 May 2010 00:49:11 -0700

> typically can't do this, so it is useful for explicit and trim servers

So the client cannot rely on it being available in all servers.
Sounds useless to me.

>> 	 defined nodes in the config tree"

Nonsense.

This meta-data tagging breaks a fundamental property
of NETCONF -- the ability to use <get-config> output
as the input to an <edit-config> or <copy-config> operation.

The client must strip out all the XML attributes first,
because they will be rejected as 'unknown attributes'
during validation.

> those nodes so the client knows which they are.

I do not understand this 'thin client' argument.
It seems pointless to me to tag the NETCONF return data
with YANG meta-data, just because some application is
too lazy to use YANG -- they want to use the meta version
of YANG instead, encoded inline.  Why not tag all the
other meta-data? Why stop at the default-stmt value?
What is so special about knowing the value equals the
schema default?

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 06 May 2010 09:57:47 +0200 (CEST)

> So the client cannot rely on it being available in all servers.

It's not useless, since it always allows a client to take the output
of a report-all get-config and feed it back into an edit-config.

> because they will be rejected as 'unknown attributes'

Well, if we did this, this draft would modify edit-config /
copy-config to allow the wd:is-default attribute in the data.  So a
server that conforms to this spec must understand this new attribute.

> What is so special about knowing the value equals the

The thin client argument is the reason for having report-all in the
first place.  If that argument is invalid, I agree with Kent that
report-all should not be mandatory.  If so, this draft should just
define the basic-mode advertisment, and not add the with-defaults
parameter.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 06 May 2010 01:45:34 -0700

> define the basic-mode advertisment, and not add the with-defaults

There are lots of ways that the <hello> can be
ambiguous, even for an application that understands YANG.
That is the reason report-all is needed.  It has nothing
to do with thin clients vs. smart clients.

I do not understand this use-case at all.
We have had dumb MIB walker programs for 25 years.
Nobody ever asked for a dumb MIB walker that indicated
which varbinds were equal to the schema default.

What operational problem is solved by hacking the NETCONF
protocol to support an XML attribute indicating that a node
equals its schema-default-value?  What operator problem is solved
by knowing this information?

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 6 May 2010 09:36:46 -0400

>So the client cannot rely on it being available in all servers.

Your definition of "useless" as "available in all servers" stands
in conflict with our extensible, capabilitity-based, feature-friendly
architecture.   We allow higher-level clients to take advantage of
higher-level servers to provide a world that rich enough to complex
app and simple enough for trivial ones.  We've abandoned the "one
size fits all" world view for a more adjustable, real-world one.

So if the server doesn't send you this new attribute, then your
client is stuck not knowing if the settings are intentional or
default values, which it the same way it would work without this
new attribute.  You aren't losing anything but by allowing smarter
clients to deal more intelligently with servers that support this
attribute, you allow them to get better insight into what's real
and what are defaults.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Thu, 6 May 2010 09:41:26 -0400

>and netconf nodes even though they were not there in the original db.

It <netconf> is a presence container (which it is, since it turns
on the netconf protocol), its appearance is supposed to create
the netconf node.  If <services> is a non-presence container
(which it is, since it just holds the set of supported services),
its appearance carried no information, so the server can create
that node or not, as allowed by the normal YANG operations.

>those nodes so the client knows which they are.

I agree on the slippery slope, but I think that mixing default
values into "real" config values is a much more slippery one.
This new attribute would help folks that want to venture onto
that slope have better footing.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 06 May 2010 08:44:33 -0700

> attribute, you allow them to get better insight into what's real

What operator problem is solved by this solution proposal?

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 6 May 2010 13:41:32 -0400

>What operator problem is solved by this solution proposal?

Here are some of the ones previously mentioned:

-an app loads a config fetched with report-all and ends up with a
horribly bloated config
- an archived config is found but there's no indication what is "real" config and
what is report-all'd defaults
- a thin client wants to should the configured values, including defaults, but wants
to flag default values to make it plain to the user they are not
part of the config.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 06 May 2010 11:29:04 -0700

> -an app loads a config fetched with report-all and ends up with a

So how does adding more text to the payload solve this problem?

> what is report-all'd defaults

This is an operator usage detail.
The operator can select which with-defaults mode to use.

The protocol does not need to add this specific meta-data.
SNMP never added any SMIv2 contents to the payload.
I don't see why NETCONF needs to do this.

> to flag default values to make it plain to the user they are not

The current draft allows the client to do this
by selecting different modes and comparing the results.

IMO it is unacceptable to force all clients to deal with
meta-data in the reply because there is no compelling need
to know which leafs happen to equal the default value,
but the client does not want to use any sort of schema file.
That is what will happen if servers MAY add XML attributes
to the payload.  This breaks existing clients, which (IMO)
is unacceptable.

BTW, description-stmts are not just for implementors.
An operator needs to know the purpose of the config data.
This is always part of the description-stmt.

If we were ranking meta-data:
   1) is leaf a list key/naming nodes
   2) description/purpose
   3) mandatory vs. optional
   4) min/max constraints
   5) needs to be unique
   6) must/when constraints
   7) value is the schema default

But of course I think the client should somehow learn
this information off-line (or w/ <get-schema>).
Use YANG or DSDL or Acme Miracle DML or whatever.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 6 May 2010 14:37:23 -0400

>So how does adding more text to the payload solve this problem?

If the report-all config flags default values with a new attribute,
then when that config is loaded, the server will see that they are
defaults and can process them as such (typically by discarding
those leafs and letting the normal default logic engage).

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 06 May 2010 12:01:29 -0700

> those leafs and letting the normal default logic engage).

The server needs to be able to support 'trim' mode
in order to create the wd:default="true" attribute.
So the client can just use with-defaults=trim for
the get-config operation.  The server will to this discarding
work for the client.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 6 May 2010 14:52:49 -0400

>the get-config operation.  The server will to this discarding

I think we're talking past each other, but I'm not sure why.

If a client app requests get-config(report-all) from a server, that
server may intermix default values with real values.  The fetched
config will have no indication which values are real and which are
defaults that are only reported because of the "report-all".  If
the app archives this data and next week wants to restore it, then
the server will see a ton of defaults and (if the server is explicit)
they will add these defaults to the real config.  This will cause
evil config bloating.

The attribute addresses this as mentioned above (allowing the server
to detect defaults).

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 06 May 2010 12:24:15 -0700

> The attribute addresses this as mentioned above (allowing the server

No we are not talking past each other.

If the client wants to keep the real values, it should use 'trim',
not 'report-all'.  We don't need to add XML attributes to NETCONF
so a client can use the wrong mode.

Martin also made an important point, which is the meaning
of basic-mode:
   report-all:  the server does not have to keep track of any sort
                     of default so it cannot be forced to return
wd:default=true
   trim: the server prunes schema default values
   explicit: the server trims server schema default values but
                  keeps client schema default values.  (An explicit server
                  can always do trim because of this
server-created-default rule.

So Kent's premise that every server that supports :with-defaults
can support report-all and can also tag all the schema-defaults,
is not correct.  Any server that can tag the defaults can also support
the 'trim' mode, so the client can compare 2 XML trees and get this
information, without changing the NETCONF protocol.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Thu, 6 May 2010 15:05:02 -0700

>    7) value is the schema default

Tagging defaults isn't about duplicating everything that can be described in a data model; it's about data-sourcing, which is typically desired when a server is asked to flatten/expand some aspect of its configuration.

Here are a couple more data-sourcing examples:

1. a device supporting the notion templates (i.e. config-groups) is asked to return configuration with all templates flattened.  Client wants the complete config, but would like to know which parts came from a template and, if so, which one.  Server again wants to insure that it doesn't create a bunch of local config objects when the config is sent back to it

2. a device supporting a cluster may have some cluster-global config (values shared by all members of the cluster) and cluster-local config (member-specific values).  Client wants the complete config from one cluster-member, annotated with which parts are inherited from the cluster-global definition.

I'm not suggesting that NETCONF support either of these things;  I'm only using these examples to illustrate why tagging default values is different than any other tag mentioned in the list above.

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 7 May 2010 00:35:51 +0200

> I'm not suggesting that NETCONF support either of these things;  I'm only using these examples to illustrate why tagging default values is different than any other tag mentioned in the list above.

Tagging might be a workable solution for the representation of
operational state, something we like to skip over because we do not
have a good and agreed upon solution. Perhaps another way of looking
at YANG defaults is that they represent well-known hard-wired static
operational state. By answering the more general dynamic operational
state representation question, YANG defaults might just fall out
naturally...

/js

---

From: Kent Watsen <[email-masked]>
Date: Thu, 6 May 2010 15:42:18 -0700

> in order to create the wd:default="true" attribute.

Explicit servers do not need to support trim and yet can still tag their defaults.  Also, I doubt an explicit server, which has gone thru the trouble to support explicit, would even support trim, as that would dilute its core value proposition.

Consider this:

Basic-Mode                           report-all     trim     explicit
------------------------             ----------     ----     --------
Can Support Report-All?                  yes         yes        yes 
Can Support Trim?                        no          yes        yes
Can support Explicit?                    no          no         yes
Can Tag Defaults?                        no          yes        yes 
Problem if untagged config returned?     n/a         no         yes          

BTW, the example in the I-D:

  "with-defaults?basic-mode=report-all&also-supported=trim,explicit"

doesn't make sense to me.  A server capable of supporting 'explicit' will have basic-mode=explicit, else if it supports trim, it will have basic-mode=trim, else it can only have basic-mode=report-all.

> the get-config operation.  The server will to this discarding

This is a red herring; the goal, for explicit servers, is to either make report-all safe or remove it as a requirement

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Thu, 06 May 2010 15:54:56 -0700

> I'm not suggesting that NETCONF support either of these things;  I'm only using these examples to illustrate why tagging default values is different than any other tag mentioned in the list above.
The application developer can do whatever it wants
with the data it retrieves.  Just refer to the data model
or hardwire the code to do what the data model says.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 07 May 2010 13:18:07 -0700

> Basic-Mode                           report-all     trim     explicit

I don't really understand this chart, or why it is a
problem if untagged nodes are returned in explicit mode.
In explicit mode, if the server returns a value it is because
the client set it.  In explicit mode, if the client sets the node
to any value at all, it is part of the config.  The fact that
the client-set value equals the schema-default is irrelevant in
explicit mode.

My strong objections to this work remain:
  1) no need to encode YANG properties into the protocol.
       There is no standards need for this extra complexity
       and verbosity.
  2) not client-initiated
      The client must somehow select (in the <rpc>)
      "I want wd:default attributes in the reply".
      It cannot be an arbitrary decision up to the server.
 3) there is nothing special about default-stmt.
     I prefer to see a coherent I-D that proposes how the
     client can request any meta-data in the reply,
     and wd:default is just 1 data node within that framework.
     The current proposal is short-sighted, especially when
     we already know about other meta-data that would be useful.

> doesn't make sense to me.  A server capable of supporting 'explicit' will have basic-mode=explicit, else if it supports trim, it will have basic-mode=trim, else it can only have basic-mode=report-a…

probably true, although that is a server vendor decision.
It may even be an operator-configurable setting.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Fri, 7 May 2010 14:06:09 -0700

> the client-set value equals the schema-default is irrelevant in

Perhaps "returned" is ambiguous, but I was referring to <get-config>, whereby the server will create a bunch of local config values for defaults, because they weren't tagged.  That is the "problem" that we're trying to solve by tagging the defaults.  What's interesting is that it is NOT a problem for a trim server, because it'll just trim the default values again.  While both trim and explicit servers can tags defaults, only explicit servers have the "problem".

>        There is no standards need for this extra complexity

I sure there is a "need", as otherwise we wouldn't be discussing it.  Complex/verbose? - I don't think so, so long as it remains focused to just a wd:defaults attribute; expanding the scope to be for other YANG tags would be more involved...

>       It cannot be an arbitrary decision up to the server.

If we allow tagging defaults, I think we should let trim/explicit servers advertise if the tagging is:
  - not supported by the server
  - supported, but must be asked for
  - default, may be disabled
  - always on, no way to disable

>      we already know about other meta-data that would be useful.

I don't think they're comparable; my experience is that data-sourcing is important, even for a fully schema-aware server.  We've never been able to get around needing the device to tag where data came from after a config flattening/expanding <get-config> (via proprietary Juniper capabilities)

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Fri, 07 May 2010 15:16:25 -0700

> Perhaps "returned" is ambiguous, but I was referring to <get-config>, whereby the server will create a bunch of local config values for defaults, because they weren't tagged.  That is the "problem"…

Do you mean client instead of server?
The server implementation knows the data model
somehow, beyond the scope of the NETCONF standard.
The server has to generate the tags, so it sure can't use them.

By definition, a basic-mode=explicit server will only create
nodes that do not have the schema default value.

   1) basic-mode=report-all

       schema defaults may not be available

  2) basic-mode=trim

      schema defaults == get-config(report-all) - get-config(trim)

  3) basic-mode=explicit
      I was led to believe the schema default is not important in this mode.
    
     server schema defaults == get-config(report-all) - get-config(explicit)

    You cannot detect the client created nodes that happen to be the
    schema default value, but the explicit mode doesn't care about
    that.  A client set node cannot be a default in this mode.

> I don't think they're comparable; my experience is that data-sourcing is important, even for a fully schema-aware server.  We've never been able to get around needing the device to tag where data c…

IMO, there is not WG consensus to expand the scope of the
with-defaults document to support meta-data tagging.
I think if you want this to be a standard, you should write
a draft that addresses all the issues, and specifies
all the extensions you want to add to the NETCONF protocol.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Mon, 10 May 2010 10:50:00 -0700

> all the extensions you want to add to the NETCONF protocol.

I'm willing to write up some text, but would like to see it in the with-defaults I-D.  Would it be OK for me to send out an edit of v7? - just as a proposal to see how it would read?

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 May 2010 10:57:12 -0700

Kent Watsen wrote:
>
>> I think if you want this to be a standard, you should write a draft
>> that addresses all the issues, and specifies all the extensions you
>> want to add to the NETCONF protocol.
>
> I'm willing to write up some text, but would like to see it in the
> with-defaults I-D.  Would it be OK for me to send out an edit of v7?
> - just as a proposal to see how it would read?
>

A charter expansion of the with-defaults draft is not an option.
IMO -- you should publish an I-D and propose a new work item
for the WG to consider.  The WG can decide what they want to
do after we read the draft.

> Thanks, Kent

Andy

---

From: Kent Watsen <[email-masked]>
Date: Mon, 10 May 2010 14:20:38 -0700

> do after we read the draft.

Fair enough, but I'll pass, as I rather move the basic-mode definitions and announcement to 4741bis.  Once this happens, the remaining bit (essentially a "report-all" capability) isn't likely something Juniper would implement.

BTW, we might want to revisit this I-D's "SHOULD implement" status; I think folks were just wanting the basic-mode announcement...

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 May 2010 16:02:34 -0700

Kent Watsen wrote:
>> IMO -- you should publish an I-D and propose a new work item for
>> the WG to consider.  The WG can decide what they want to do after
>> we read the draft.
>
>
> Fair enough, but I'll pass, as I rather move the basic-mode
> definitions and announcement to 4741bis.  Once this happens, the
> remaining bit (essentially a "report-all" capability) isn't likely
> something Juniper would implement.
>

I don't see what the with-defaults draft has to do
with your desire to add meta-data to NETCONF replies.
This request was discussed at the last IETF and the WG
decided then not to do this.  I think the matter is closed
wrt/ the with-defaults draft.

> BTW, we might want to revisit this I-D's "SHOULD implement" status; I
> think folks were just wanting the basic-mode announcement...
>

We are revisiting it apparently. :-(
I do not see any need for MUST advertise.
The use of MUST is reserved for when then
protocol cannot possibly work without the MUST requirement.

I do not understand why advertising the with-defaults capability
needs to be coupled to the  server conformance to 4741bis.
If both RFCs are eventually published, what difference does
it make where the URI in the <hello> came from?
The <hello> is already full of URIs from different RFCs
and I-Ds.  I don't see any problem with that.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Mon, 10 May 2010 17:18:20 -0700

> with your desire to add meta-data to NETCONF replies.

I do desire it; I believe tagging-defaults is the right thing to do but, as long as Juniper isn't being compelled to implement report-all (because the announcement moves to 4741bis), I'm willing to defer adding tagging to some future revision of this I-D.

> and I-Ds.  I don't see any problem with that.

You're right that it doesn't matter which capability string defines a thing; a device MUST implement everything it advertises.  But that's not the issue, which is that one capability string is being used to define two MUST statements of unequal importance:

  "A NETCONF server implementing the :with-defaults capability MUST
   indicate its basic behavior, whether it sends default data in the
   absence of any specific request from the NETCONF client; and MUST
   support the 'report-all' handling mode and MAY support other modes."

The basic-mode announcement is really important; the report-all doesn't seem nearly so.  If we break up these two things, putting the announcement into 4741, then the remaining bit in w-d probably wouldn't still warrant a "SHOULD implement" conformance level.

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 May 2010 17:37:24 -0700

> The basic-mode announcement is really important; the report-all doesn't seem nearly so.  If we break up these two things, putting the announcement into 4741, then the remaining bit in w-d probably…

I agree it is OK to change MUST support report-all
to SHOULD support report-all, especially if it
means we can finally stop debating defaults.

If the server does not have any 'also-supported' values,
then the <with-defaults> leaf accepts only 1 value so it's pointless.
The conformance for the YANG module would be:

   - MUST implement ietf-netconf-with-defaults.yang
     if the 'also-supported' parameter is used in the
     :with-defaults capability advertisement.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 11 May 2010 16:02:08 -0700

> I agree it is OK to change MUST support report-all to SHOULD 
> support report-all, especially if it means we can finally 
> stop debating defaults.
> 
> If the server does not have any 'also-supported' values, then 
> the <with-defaults> leaf accepts only 1 value so it's pointless.

Can we make the following change to the I-D?

  "A NETCONF server implementing the :with-defaults capability MUST
   indicate its basic behavior, whether it sends default data in the
+  absence of any specific request from the NETCONF client; and SHOULD
-  absence of any specific request from the NETCONF client; and MUST
   support the 'report-all' handling mode and MAY support other modes."

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Tue, 11 May 2010 16:30:17 -0700

>    support the 'report-all' handling mode and MAY support other modes."

What is the point of having also-supported modes
in the standard, but no way to make sure there is
a standard way to access these other modes?

The YANG module is needed if also-supported in non-empty.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 12 May 2010 08:11:25 -0400

>a standard way to access these other modes?

You've already said that report-all is for "debug mode", which would
limit its usefulness as a "standard way".  If my server doesn't
need "debug mode", why is report-all a MUST?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 12 May 2010 05:47:34 -0700

> need "debug mode", why is report-all a MUST?

The standard provides 2 mandatory buts of functionality
  1) advertise the modes supported
  2) ability to retrieve all the nodes

We already established that every server CAN
return report-all.  You just don't want to do that,
even though that is a client decision, not a server decision.

The WG already agreed that report-all MUST be part
of this capability.  Since there is no implementation
burden, I do not see any reason to change that.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 12 May 2010 08:45:52 -0400

>even though that is a client decision, not a server decision.

My concern remains that intermixing default values with "real"
configuration data is a problem waiting to happen.  Kent's proposal
attempts to let the client (and the server to which the client feeds
a default-laden config) understand which are phantom defaults and
which are "real" config, allowing both sides to deal with these
defaults in an appropriate manner.  The w-d attribute gives a means
of keeping the pin in the grenade.

Should I turn this around and ask where in Kent's proposal?  What
problems are created by flagging defaults as defaults?  Is there
any harm in giving this information to clients and servers?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 12 May 2010 06:30:08 -0700

> any harm in giving this information to clients and servers?

A client cannot use the retrieved get-config as
input to an edit-config or copy-config without
altering the get-config reply.

IMO, tagging would be acceptable if (and only if)
the client asks for tagged output.  The client MUST
be the one that decides to receive XML attributes,
not the server.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 12 May 2010 09:15:52 -0400

>altering the get-config reply.

You made this claim before and Martin's response was that part of
defining this attribute would be requiring that servers parse is
and discard/ignore leafs so tagged.  I think this is a great addition.

>be the one that decides to receive XML attributes,

So you are agreeable to adding another w-d parameter that
turns on this attribute-tagged-of-defaults behavior?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 12 May 2010 06:38:05 -0700

> turns on this attribute-tagged-of-defaults behavior?

repetition is the key to learning....

I do not want the server to decide what to send.
I want the client to always decide. I also want
the server to be able to not implement this XML attribute.

basic-mode = [trim | explicit | report-all]

also-supported = 0 or more of
[trim | explicit | report-all | report-all-tagged]

<with-defaults>[full-list-of-enums]</with-defaults>

This fixes the problem.
If the server wants to support this XML attribute,
it will list it in its also-supported parameter.
If the client wants report-all-tagged, it will ask for it.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 12 May 2010 06:52:27 -0700

Andy Bierman wrote:
>> ...

Note the phrase '0 or more'.
This is not a typo.  In my proposal, some form of
report-all would be SHOULD, not MUST.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 12 May 2010 16:32:30 +0200

> If the client wants report-all-tagged, it will ask for it.

If we do tagging, we should have a plan how in general we want to deal
with operational state. For explicit server, leafs with defaults are
simply operational state, not config.

I guess I lacking the meta model here to say it in Randy's terms.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 12 May 2010 07:57:58 -0700

> I guess I lacking the meta model here to say it in Randy's terms.

The tagging proposal is not detailed enough, so we may be
debating different versions of the proposal.

Does wd:default='true' mean:

  1) "This is a default node by my definition of a default"

OR

  2)  "The value is equal to the schema-default for the node"

Martin pointed out that not all servers know (2),
they only can be forced to know (1).

If (1), then get-config(report-all) - get-config(basic-mode)
describes the set of nodes that will be tagged.

If (2), not sure what problem this solves.

If (1), the report-all mode can be thought of as the
'include all your operational data' mode, since that
is what the non-basic-mode nodes represent in every case.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 12 May 2010 17:27:55 +0200

> is what the non-basic-mode nodes represent in every case.

A route inserted into my router via BGP is not default data but still
operational state. So I see it the other way round: If we would have a
mechanism to retrieve data tagged config / operational state / ..., a
solution for defaults likely falls out naturally. (This might be done
by introducing a new <get-tagged> operation instead of adding more
parameters to existing operations - but that is just one option and
there can be debates about what the best approach is.)

There are lots of examples where operational state if coming both from
explicit config and control protocols and I have yet to see how we
like to model this with YANG and the semantics of the NETCONF
operations we have. It would be nice if we do not have to duplicate
definitions in order to separate the operational state view from the
config view - this is I think what is currently required (and this
approach makes comparison of operational state and config state a non
automated process the relationship is not machine readable).

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 12 May 2010 08:52:33 -0700

> automated process the relationship is not machine readable).

So we agree the tag means (1) not (2).  Good.

A new operation to retrieve just the operational data
is one option.  This would be fine with me.
This would be client-initiated, which is important.

I still like the current report-all because it supports some
use-cases the WG has agreed are important, such as
off-line schema validation, and simplified diff-tracking.

I agree that much more work is needed for NETCONF/YANG
to properly model real-world micro-details of configuration
behavior, such as server containers vs. client-created containers,
or disabled config subtrees, or pre-provisioned config sub-trees.

I never really agreed in the first place that config-stmt was a boolean.
I argued for a 3rd state to represent operational-config
(I called it transient config or 'tconfig').

Gee, guess what the wd:default=true is? -- that 3rd state.
But it is just in NETCONF, not YANG.  YANG must/when/unique
constraints are still fuzzy because config-stmt is a boolean.

Andy