Subject: [Netconf] Summary of the NETCONF WG Session at IETF 72 and Action Points

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Sun, 10 Aug 2008 12:50:40 +0200

Dear NETCONF WG, 

after having sent out the preliminary minutes we need 
to confirm the results of the NETCONF session.  

=> [Topic owners] please start the necessary discussion 
     or bring the action points "[A-D]n)" to the maillist
     as soon as possible.

Below is the summary of the NETCONF WG session on 
TUESDAY, July 29, 2008 1850-1950.

- We had 35 persons in the 1 hour NETCONF session.
- We reviewed the status of the WG

- NETCONF Notification draft has been published as 
  RFC 5277.
- We went through the chartered WG items andFrom [email-masked]  Sun Aug 10 03:50:46 2008
Content-class: urn:content-classes:message
Date: Sun, 10 Aug 2008 12:50:40 +0200
From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
To: <[email-masked]>
Subject: [Netconf] Summary of the NETCONF WG Session at IETF 72 and Action
	Points
Sender: [email-masked]

This is a multi-part message in MIME format.

Dear NETCONF WG, 

after having sent out the preliminary minutes we need 
to confirm the results of the NETCONF session.  

=> [Topic owners] please start the necessary discussion 
     or bring the action points "[A-D]n)" to the maillist
     as soon as possible.

Below is the summary of the NETCONF WG session on 
TUESDAY, July 29, 2008 1850-1950.

- We had 35 persons in the 1 hour NETCONF session.
- We reviewed the status of the WG

- NETCONF Notification draft has been published as 
  RFC 5277.
- We went through the chartered WG items and had=2 had 
  a discussion and review of the documents.

NETCONF Monitoring Schema (Mark Scott )

The NETCONF Monitoring needs some work before WGLC. 
Issue #1: Which terminology should be used? schema or 
model or data model ...?

A1) The issue will be discussed on the maillist to try to 
converge to consensus [Mark].

Issue #2: lack of agreed XSD definitions for data types 
to use.
The work on SMIv2-to-XSD translation in OPSAWG has 
a different focus and does not solve the problem of 
additional data types needed in NETCONF. 

PS: There was additional disscussion on this issue in the 
OPSAWG. The SMIv2-to-XSD document will be finalized 
asap to see how it impacts YANG data type usage. 
It has been proposed to define short-term data type 
usage for NETCONF based on XSD.

A2) The issue will be discussed first by the base 
players Mark, Dave H, Bob Natale, Jürgen Schönwälder 
and co-chairs [Mark]
A3) and will be brought to the maillist to reach a 
consensus for the usage of data types in NETCONF [Mark].

Partial Lock RPC for NETCONF (Balazs Lengyel)

Issue #1: Remove empty locks?
Keep as it is.
Issue #2: Does the granular locking put requirements on 
other protocols that night lock the database?
Keep the text in document.
The document is ready for WG last call? 8 in favor, 
no objections.

B1) Update the document for clarifications [Balazs, done]
B2) Bring the document to WGLC [Chairs]

NETCONF over TLS (Mohamad Badra)

Security AD Tim Polk does not see the additional value 
in the document since the password-based SSH transport 
is already mandatory. Tim Polk does not have any technical 
objections to the use of TLS out of the box if the WG 
decided so. The focus in the document should be on 
certificate-based TLS.

C1) Summarize the WG discussion and take the comments 
of the security ADs Pasi Eronen and Tim Polk [Badra, mail sent].
C2) Bring AD comments to the maillist and ask for consensus 
[Badra].

NETCONF Notification Content (Sharon Chisholm)

The WG has interest of doing some work on notification 
content (6 in room + 1 jabber in favour, no objections).
The current charter does not cover this work and needs 
to be extended.

D1) Chairs will prepare charter text proposal and ask 
the WG for comments and whether they are interested 
doing work on network content. [Chairs]

Cheers,
Bert & Mehmet
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Mon, 18 Aug 2008 23:47:40 +0200

In the IETF72 WG meeting summary (attached below),
we have pointed out several action points.

We'd like to remind everyone to please execute on those
action points, so that we make progress to a converged
resolution and to completed documents. We have seen
some initial action, but we need to see more!

The action points were/are:

A)  Monitoring Draft [Mark]

A1)  Monitoring daft [Mark Scott]
        Which terminology should be used?
        schema or model or data model ...?

        The issue will be discussed on the maillist to try to
        converge to consensus.

A2) Monitoring Draft [Mark Scott]
       No agreed XSD definitions for data types to use.
       The work on SMIv2-to-XSD translation in OPSAWG
       has a different focus and does not solve the problem
       of additional data types needed in NETCONF.

       The issue will be discussed first by the base players
        Mark, Dave H, Bob Natale, Jürgen Schönwälder
        and co-chairs.

A3) Monitoring Draft [Mark Scott]

       Issue A2 will then be brought to the maillist to reach a
       consensus for the usage of data types in NETCONF.

B  Partial Locking Draft [Balazs]

B1)  Remove empty locks?
        Keep as it is.

        Update the document for clarifications [Balazs, done]

B2)  The document is ready for WG last call?
        8 in favor,  no objectionsFrom [email-masked]  Mon Aug 18 14:48:44 2008
From: "Bert Wijnen \(IETF\)" <[email-masked]>
To: <[email-masked]>
Date: Mon, 18 Aug 2008 23:47:40 +0200
Organization: Consultant
Subject: [Netconf] Reminder,
	Action Points [was: Summary of the NETCONF WG Session at IETF 72
	and Action Points]
Sender: [email-masked]

In the IETF72 WG meeting summary (attached below),
we have pointed out several action points.

We'd like to remind everyone to please execute on those
action points, so that we make progress to a converged
resolution and to completed documents. We have seen
some initial action, but we need to see more!

The action points were/are:

A)  Monitoring Draft [Mark]

A1)  Monitoring daft [Mark Scott]
        Which terminology should be used?
        schema or model or data model ...?

        The issue will be discussed on the maillist to try to
        converge to consensus.

A2) Monitoring Draft [Mark Scott]
       No agreed XSD definitions for data types to use.
       The work on SMIv2-to-XSD translation in OPSAWG
       has a different focus and does not solve the problem
       of additional data types needed in NETCONF.

       The issue will be discussed first by the base players
        Mark, Dave H, Bob Natale, Jürgen Schönwälder
        and co-chairs.

A3) Monitoring Draft [Mark Scott]

       Issue A2 will then be brought to the maillist to reach a
       consensus for the usage of data types in NETCONF.

B  Partial Locking Draft [Balazs]

B1)  Remove empty locks?
        Keep as it is.

        Update the document for clarifications [Balazs, done]

B2)  The document is ready for WG last call?
        8 in favor,  no objections.

        Bring the document to WGLC [Chairs, done]

        WG Last Call is running from Aug 10 till Aug24  [All WG members]

        PLEASE, all WG members should review and post their
        comments (also a "I have read it and am happy with it" is
        useful information).

C) NETCONF over TLS (Mohamad Badra)

C1)  Need to focus on out-of-box usafge of TLS.
        Summarize the WG discussion and take the comments
        of the security ADs Pasi Eronen and Tim Polk
        [Badra, mail sent, follow still needs to happen.]

C2)  Bring (security) AD comments to the maillist and drive
        for consensus  [Badra].

D)   NETCONF Notification Content (Sharon Chisholm)

Bert and Mehmet

----- Original Message ----- 
From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
To: <[email-masked]>
Cc: "ext Bert Wijnen (IETF)" <[email-masked]>
Sent: Sunday, August 10, 2008 12:50 PM
Subject: Summary of the NETCONF WG Session at IETF 72 and Action Points

Dear NETCONF WG,

- NETCONF Notification draft has been published as
  RFC 5277.
- We went through the chartered WG items and had
  a discussion and review of the documents.

Cheers,
Bert & Mehmet

.

        Bring the document to WGLC [Chairs, done]

        WG Last Call is running from Aug 10 till Aug24  [All WG members]

        PLEASE, all WG members should review and post their
        comments (also a "I have read it and am happy with it" is
        useful information).

C) NETCONF over TLS (Mohamad Badra)

C1)  Need to focus on out-of-box usafge of TLS.
        Summarize the WG discussion and take the comments
        of the security ADs Pasi Eronen and Tim Polk
        [Badra, mail sent, follow still needs to happen.]

C2)  Bring (security) AD comments to the maillist and drive
        for consensus  [Badra].

D)   NETCONF Notification Content (Sharon Chisholm)

Bert and Mehmet

----- Original Message ----- 
From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
To: <[email-masked]>
Cc: "ext Bert Wijnen (IETF)" <[email-masked]>
Sent: Sunday, August 10, 2008 12:50 PM
Subject: Summary of the NETCONF WG Session at IETF 72 and Action Points

Dear NETCONF WG,

- NETCONF Notification draft has been published as
  RFC 5277.
- We went through the chartered WG items and had
  a discussion and review of the documents.

Cheers,
Bert & Mehmet

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 21 Aug 2008 14:54:45 +0200

Hello Bert, Mehmet,
In the Netmod WG (mostly the same people I assume) I raised the issue of getting the 
"with-defaults" feature documented/standardized/RFC-d. The feature will be useful even without 
YANG, but even more so once YANG is adopted. IMHO there is a consensus about the need for the 
feature.

Andy Bierman already wrote a draft (http://tools.ietf.org/html/draft-bierman-ncx-ext-00) that 
could be used as a a starting point; I am only referring to chapter "2.2.  with-defaults 
Attribute", not the rest of the draft. I assume Andy is willing to work on the topic, but I am 
definitely available for this.

I would like to have this added to the WG charter, proposed text:

"5. With-defaults feature: The NETCONF working group will define a mechanism whereby the 
Netconf manager can control, wFrom [email-masked]  Thu Aug 21 06:02:32 2008
Date: Thu, 21 Aug 2008 14:54:45 +0200
From: Balazs Lengyel <[email-masked]>
To: "Bert Wijnen (IETF)" <[email-masked]>
Cc: netconf mailing list <[email-masked]>
Subject: [Netconf] New work: with-defaults
Sender: [email-masked]

Hello Bert, Mehmet,
In the Netmod WG (mostly the same people I assume) I raised the issue of getting the 
"with-defaults" feature documented/standardized/RFC-d. The feature will be useful even without 
YANG, but even more so once YANG is adopted. IMHO there is a consensus about the need for the 
feature.

Andy Bierman already wrote a draft (http://tools.ietf.org/html/draft-bierman-ncx-ext-00) that 
could be used as a a starting point; I am only referring to chapter "2.2.  with-defaults 
Attribute", not the rest of the draft. I assume Andy is willing to work on the topic, but I am 
definitely available for this.

I would like to have this added to the WG charter, proposed text:

"5. With-defaults feature: The NETCONF working group will define a mechanism whereby the 
Netconf manager can conthether the Netconf server shall include default values in the 
reply to the get, get-config and copy-config operations."

Comments?
Balazs

rol, whether the Netconf server shall include default values in the 
reply to the get, get-config and copy-config operations."

Comments?
Balazs

---

From: Phil Shafer <[email-masked]>
Date: Thu, 21 Aug 2008 10:21:44 -0400

>I would like to have this added to the WG charter, proposed text:

Would writing a new draft be the place to start?

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Thu, 21 Aug 2008 10:21:44 -0400

Thanks,
 Phil

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Thu, 21 Aug 2008 15:10:47 +0200

Balazs,

Thanks for your input.

WG, pls express your opinion on this possible new work-item.

Bert

----- Original Message ----- 
From: "Balazs Lengyel" <[email-masked]>
To: "Bert Wijnen (IETF)" <[email-masked]>
Cc: "Ersue, Mehmet (NSN - DE/Muenich)" <[email-masked]>; "netconf 
mailing list" <[email-masked]>
Sent: Thursday, August 21, 2008 2:54 PM
Subject: New work: with-defaults

> Hello Bert, Mehmet,
> In the Netmod WG (mostly the same people I assume) I raised the issue of 
> getting the "with-defaults" feature documented/standardized/RFC-d. The 
> feature will be useful even without YANG, but even more so once YANG is 
> adopted. IMHO there is a consensus about the need for the feature.
>
> Andy Bierman already wrote a draft 
> (http://tools.ietf.org/html/draft-bierman-ncx-ext-00) that could be used 
> as a a starting point; I am only referring to chapter "2.2.  with-defaults 
> Attribute", not the rest of the draft. I assume Andy is willing to work on 
> the topic, but I am definitely available for this.
>
> "5. With-defaults feature: The NETCONF working group will define a 
> mechanism whereby the Netconf manager can control, whether the Netconf 
> server shall include default values in the reply to the get, get-config 
> and copy-config operations."
>
> Comments?
> Balazs
>
>

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Thu, 21 Aug 2008 15:10:47 +0200

Balazs,

Thanks for your input.

Bert

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 21 Aug 2008 16:42:22 +0200

Hello,
Definitely, but i would like to know two things first:
1) Is there some support for this, can we get it chartered? Pleaser raise your voice if you 
support it?
2) As Andy has a draft on the topic, does he want to do this?
Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 21 Aug 2008 16:42:22 +0200

Hello,

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 Aug 2008 16:59:45 +0200 (CEST)

> WG, pls express your opinion on this possible new work-item.

I support this.  (And have it implemented the way Andy describes it).

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 Aug 2008 16:59:45 +0200 (CEST)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Aug 2008 08:02:21 -0700

Balazs Lengyel wrote:
> 1) Is there some support for this, can we get it chartered? Pleaser 
> raise your voice if you support it?

yes -- I think the major issues are:
   1) add a capability URI for 'with-defaults' support
   2) use augment to add new optional leafs to copy-config, get-config,
      and get (type empty), instead of an XML attribute in the <rpc>
      element
   3) with-defaults-default leaf in netconf-state DM (or separate DM?)
      - is this read-only or just min-access read-only?
      - should this be required (read-only) even if with-defaults
        capability not supported?

Balazs and I have agreed to work on a draft, so hopefully
in a few weeks, a new draft addressing defaults will be out.

>> Would writing a new draft be the place to start?

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Aug 2008 08:02:21 -0700

Andy

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Thu, 21 Aug 2008 16:38:39 +0200

That would certainly help. But since some of the dieas are already
documented in a draft from Andy (to which Balazs pointed), people
may be able to state their opinion already.

Bert
----- Original Message ----- 
From: "Phil Shafer" <[email-masked]>
To: "Balazs Lengyel" <[email-masked]>
Cc: "Bert Wijnen (IETF)" <[email-masked]>; "netconf mailing list" 
<[email-masked]>
Sent: Thursday, August 21, 2008 4:21 PM
Subject: Re: [Netconf] New work: with-defaults

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Thu, 21 Aug 2008 16:38:39 +0200

Bert
----- Original Message ----- 
From: "Phil Shafer" <[email-masked]>
To: "Balazs Lengyel" <[email-masked]>
Cc: "Bert Wijnen (IETF)" <[email-masked]>; "netconf mailing list" 
<[email-masked]>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Aug 2008 19:41:06 +0200

>        capability not supported?

Why is this needed?

/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: Thu, 21 Aug 2008 19:41:06 +0200

Why is this needed?

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Aug 2008 10:51:47 -0700

>>        capability not supported?

So the manager will know what to expect when it issues
a 'plain' request without the flag.  Since RFC 4741 is
silent on the issue, it seems like it should be a
vendor-configured property.

Perhaps not every application of NETCONF will be 90% defaults.
Perhaps returning defaults will not be perceived as a total
waste of time by the application developer.

Another NETCONF Axiom:

Axiom 3:  A NETCONF manager should always be able to determine
           if an agent feature is supported, without relying on
           'try it and see what happens'.  SNMP experience has
           proven this method to be unreliable.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Aug 2008 10:51:47 -0700

Another NETCONF Axiom:

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Aug 2008 22:42:20 +0200

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Aug 2008 22:42:20 +0200

On Thu, Aug 21, 2008 at 10:51:47AM -0700, Andy Bierman wrote:
> vend> vendor-configured property.

Can we not clarify RFC 4741 and by announcing the with-defaults
capability we are done? I do not really like to read various leafs
before I know what a get-config really does...

/js

or-configured property.

Can we not clarify RFC 4741 and by announcing the with-defaults
capability we are done? I do not really like to read various leafs
before I know what a get-config really does...

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Aug 2008 13:51:34 -0700

> before I know what a get-config really does...

Excellent idea.

Something like:

   urn:ietf:params:netconf:capability:with-defaults?default=false

[This agent will not return defaults unless asked for them.]

Another detail:  this capability does not differentiate
between a value set by the manager or the agent.  If
the default is '3' and the value is '3', it is considered
to contain the default, regardless of how it was created.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Aug 2008 13:51:34 -0700

Excellent idea.

Something like:

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 22 Aug 2008 08:53:14 -0400

>to contain the default, regardless of how it was created.

This is another can o' worms.  I preserve user specified values
even when the value matches the default.  This allows users complete
control over what appears in their config.  Values to not disappear
simply because the match the default.

If you want this behavior, I'd suggest making your "with-defaults"
a tri-state value:

"all"       -- report all default values
"trim"      -- do not report values if they match the default
"explicit"  -- report any values explicitly set

Thanks,
 Phil
_______________________________________________
NetconfFrom [email-masked]  Fri Aug 22 06:07:40 2008
To: Andy Bierman <[email-masked]>
Date: Fri, 22 Aug 2008 08:53:14 -0400
From: Phil Shafer <[email-masked]>
Cc: netconf mailing list <[email-masked]>
Subject: Re: [Netconf] New work: with-defaults
Sender: [email-masked]

>to contain the default, regardless of how it was created.

This is another can o' worms.  I preserve user specified values
even when the value matches the default.  This allows users complete
control over what appears in their config.  Values to not disappear
simply because the match the default.

If you want this behavior, I'd suggest making your "with-defaults"
a tri-state value:

"all"       -- report all default values
"trim"      -- do not report values if they match the default
"explicit"  -- report any values explicitly set

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

ng list
[email-masked]

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 22 Aug 2008 12:06:08 -0700

Hi -

> To: "Andy Bierman" <[email-masked]>
> Cc: "netconf mailing list" <[email-masked]>
> Sent: Friday, August 22, 2008 5:53 AM

This seems surprising if the point of having defaults was to avoid the
need to shovel those values back and forth.  If default values are part
of the interface contract between client and server, then how something
came to have a value equal to the default shouldn't be a factor.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 22 Aug 2008 12:06:08 -0700

Hi -

Randy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 22 Aug 2008 15:25:45 -0400

>came to have a value equal to the default shouldn't be a factor.

Many of my customers like to say "set mtu 1500" even though they
know it's the default.  They like to explicitly set it and see it.

I personally find it odd when I explicitly set something, come back
later and find it gone.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Fri, 22 Aug 2008 15:25:45 -0400

Thanks,
 Phil

---

From: Simon Leinen <[email-masked]>
Date: Sat, 23 Aug 2008 00:39:28 +0200

Phil Shafer writes:
> "Randy Presuhn" writes:
>> This seems surprising if the point of having defaults was to avoid
>> the need to shovel those values back and forth.  If default values
>> are part of the interface contract between client and server, then
>> how something came to have a value equal to the default shouldn't
>> be a factor.

> know it's the default.  They like to explicitly set it and see it.

Thanks for bringing up the MTU example.  This reminds me of why I
strongly agree with Phil here: It is important to distinguish between
an unset parameter and a parameter that has been explicitly configured
to a value that happens to match the default.

Here's a true story from an operator:

There's a brand of router we and many other people use.  When
configuring a tunnel interface, the configuration default for the MTU
is derived from the MTU of the interface towards the remote endpoint.

Operationally, it is usually required to have equal MTU sizes on both
ends of the tunnel (different routers, possibly under different
administration), so we have to agree on one value.

Now let's say that, on my router, and at the time the configuration is
entered, the agreed-upon value happens to be the same as the default
MTU - depending on which interface the route to the other endpoint
points to at that time.  Because the router works according to what
Randy finds natural, as opposed to what Phil and I prefer, it will
simply ignore my configuration because it matches the default.

This will work just fine... until my router is rebooted for some
reason.  The configuration (with the MTU set to "default") is
re-interpreted in a different context, where the route to the other
endpoint may point to a different interface with a different MTU.  The
result will be that the tunnel MTU is now set to some other value,
which leads to the tunnel blackholing large packets in one direction.
I have seen this happen to me, and I have heard others had the same
issue.  Believe me that debugging these kinds of problems is NOT FUN.

You may say that this wouldn't be a problem if the default MTU in this
case wasn't derived from operational state, and I sort-of agree.  But
the people who wrote the software probably have good (probably
usability) arguments for doing it that way.

> I personally find it odd when I explicitly set something, come back

Precisely.
-- 
Simon.

---

From: Simon Leinen <[email-masked]>
Date: Sat, 23 Aug 2008 00:39:28 +0200

Precisely.

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 22 Aug 2008 15:53:59 -0700

Hi -

> From: "Simon Leinen" <[email-masked]>
> To: "Phil Shafer" <[email-masked]>
> Cc: "Randy Presuhn" <[email-masked]>; "netconf mailing list" <[email-masked]>
> Sent: Friday, August 22, 2008 3:39 PM
> an unset parameter and a parameter that has bFrom [email-masked]  Fri Aug 22 15:52:45 2008
From: "Randy Presuhn" <[email-masked]>
To: "netconf mailing list" <[email-masked]>
Date: Fri, 22 Aug 2008 15:53:59 -0700
Subject: Re: [Netconf] New work: with-defaults
Sender: [email-masked]

Hi -

> From: "Simon Leinen" <[email-masked]>
> To: "Phil Shafer" <[email-masked]>
> Cc: "Randy Presuhn" <[email-masked]>; "netconf mailing list" <[email-masked]>
> Sent: Friday, August 22, 2008 3:39 PM

This example is very similar to some of the cases we worked through
while looking at the netmod requirements.  It actually makes a strong case
for only using defaults as part of an interface contract, and explains why
(1) "defaults" derived from operational state are a bad thing from a configuration
management perspective. even though they may be nice when designing a
human (not machine-to-machine) interface and (2) "disappearing" defaults
are problematic from a machine-to-machine configuration management
perspective, even though they might be desirable for some human
interface use cases.

Randy

een explicitly configured
> > I personally find it odd when I explicitly set something, come back

This example is very similar to some of the cases we worked through
while looking at the netmod requirements.  It actually makes a strong case
for only using defaults as part of an interface contract, and explains why
(1) "defaults" derived from operational state are a bad thing from a configuration
management perspective. even though they may be nice when designing a
human (not machine-to-machine) interface and (2) "disappearing" defaults
are problematic from a machine-to-machine configuration management
perspective, even though they might be desirable for some human
interface use cases.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 22 Aug 2008 16:27:04 -0700

> perspective, even though they might be desirable for some human

Even though, I still think it makes better sense all around
to only filter agent-supplied values, because that is
what the CLI world is used to having.

It's easier to understand too.
If the manager did not supply the value, it
is part of the filter. It doesn't matter
if the leaf value was derived from a YANG module, an XSD,
a CLI command, or the operational state, or even random
data.

If you think about the real feature here, it is
the manager saying "I know what config I supplied. Show
me what you added."  The two subsets should not overlap
(filter true, then false).

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 22 Aug 2008 16:27:04 -0700

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 23 Aug 2008 11:40:45 +0200 (CEST)

Phil Shafer <[email-masked]> wrote:
> This is another can o' worms.

Yes.

> I preserve user specified values
> even when the value matches the default. 

So do I, and I think doing otherwise violates the Principle of Least
Anstonishment.  If I set a value I expect it to be there.

We don't have upgrade rules yet, so we don't know if it will be ok to
change default values in new revisions.  But in reality default values
are changed over time.  If a client explicitly sets 'foo' to a value
which happens to be the default, and 'foo' gets a new default in a new
revision, the explicitly set value has been silently changed by the
box.  (A valid use case is for the client to explicitly reset a knob
to its default value, but that is covered already).

So I wonder why this capability has to talk about this at all?  Just
as the rest of the default semantics are left to the data model, I
think this should be as well.  This is a NETCONF (data-model agnostic)
capability.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 23 Aug 2008 11:40:45 +0200 (CEST)

Yes.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 23 Aug 2008 12:02:52 +0200 (CEST)

"Randy Presuhn" <[email-masked]> wrote:
> (1) "defaults" derived from operational state are a bad thing from a
> configuration management perspective.

I agree.  IMO these objects should be explicitly created by the
server, and thus not marked as defaults, and reported regardless of
the value of with-defaults.  (In YANG terms, such an object would me
marked with "created-by system;")

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 23 Aug 2008 12:02:52 +0200 (CEST)

/martin

---

From: Phil Shafer <[email-masked]>
Date: Sun, 24 Aug 2008 22:44:41 -0400

>Anstonishment.  If I set a value I expect it to be there.

Amen.

>think this should be as well.  This is a NETCONF (data-model agnostic)

I think this is a matter for us to dictate for all YANG-based models.
It's not something that can (or should) be dictated for all
NETCONF-based data models, since NETCONF has no rules about what
one can do here.  I'd rather explicitly specify a fixed behavior
in YANG than retrofit it in NETCONF.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Sun, 24 Aug 2008 22:44:41 -0400

Amen.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Sun, 24 Aug 2008 22:47:18 -0400

"Randy Presuhn" writes:
>human (not machine-to-machine) interface and

State-derived defaults may not be nice, but they are definitely
real world.

> (2) "disappearing" defaults

IMHO disappearing defaults are problematic for humans also.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Sun, 24 Aug 2008 22:47:18 -0400

Thanks,
 Phil

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 25 Aug 2008 18:12:32 +0200

Hello,
While I agree with the principle, some devices might not store the difference between a leaf 
set to 5 explicitly and a leaf that only has a 5 as a default value. (We have such devices :-(
So mandating this might be a tall order for some nodes.
Balazs

Martin Bjorklund wrote:
> server, and thus not marked as defaults, and reported regardleFrom [email-masked]  Mon Aug 25 09:14:21 2008
Date: Mon, 25 Aug 2008 18:12:32 +0200
From: Balazs Lengyel <[email-masked]>
To: Martin Bjorklund <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] New work: with-defaults
Sender: [email-masked]

Hello,
While I agree with the principle, some devices might not store the difference between a leaf 
set to 5 explicitly and a leaf that only has a 5 as a default value. (We have such devices :-(
So mandating this might be a tall order for some nodes.
Balazs

> server, and thus not marked as defaults, and reported regardless of
ss of

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Phil Shafer <[email-masked]>
Date: Mon, 25 Aug 2008 12:37:00 -0400

>set to 5 explicitly and a leaf that only has a 5 as a default value. (We have 

Many devices have mimiced IOS behavior in this regard, which is
part of the yang draft says:

    A NETCONF server that replies to a <get> or <get-config> request
    MAY choose not to send the leaf element if its value is the
    default value.

I prefer (vastly) the "keep values explicitly set" behavior, so we
allow device to choose their own path.  The client needs to be able
to handle devices that work both ways:

    Thus, a client that receives an <rpc-reply> for a <get> or
    <get-config> request, must be prepared to handle the case that
    a leaf node with a default value is not present in the XML. In
    this case, the value used by the server is known to be the
    default value.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Mon, 25 Aug 2008 12:37:00 -0400

Thanks,
 Phil

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 26 Aug 2008 15:39:33 -0400

Hi,

Be conservative in what you send and liberal in what you receive.

I do not think we should leave it up to each server to decide for
itself what to return; we need to specify what is the correct behavior
for compliance to the standard, so we have something that is
interoperable. 

Will legacy devices already support this feature of a brand new
standard? of course not. We should design the standard for
interoperability, not to make all existing devices able to claim
compliance based on their current CLI behavior. If an existing device
has a CLI that already keeps track of whether values are explicitly
set or defaults, then those devices have a leg up on meeting the
netconf standard; those that do not do this in their CLI will need to
add the capability in the netconf implementation.

The client should be able to handle responses of any approach, because
the client should be able to handle non-compliant responses without
crashing. 

Are we trying to standardize things to work more interoperably in the
future, or to mimic all of the non-interoperable choices made by
vendors in the past?

dbh

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Phil Shafer
> Sent: Monday, August 25, 2008 12:37 PM
> To: Balazs Lengyel
> Cc: [email-masked]
> >While I agree with the principle, some devices might not 
> store the difference 
> >between a leaf 
> >set to 5 explicitly and a leaf that only has a 5 as a 
> default value. (We have 
> >such devices :-(
>

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 26 Aug 2008 15:39:33 -0400

Hi,

dbh

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 26 Aug 2008 21:45:17 +0200

Hello David,
Interoperability is certainly a goal.

However NETCONF will usually be fitted on nodes that already exist. So if we require them to 
change their existing datastore design (adding a bit for each leaf  setBymanager { boolean} ), 
then we certainly raise the cost of NETCONF implementation.

Balazs

David B Harrington wrote:
> interoperability, not to make all existing devicFrom [email-masked]  Tue Aug 26 12:46:13 2008
Date: Tue, 26 Aug 2008 21:45:17 +0200
From: Balazs Lengyel <[email-masked]>
To: David B Harrington <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] New work: with-defaults
Sender: [email-masked]

Hello David,
Interoperability is certainly a goal.

However NETCONF will usually be fitted on nodes that already exist. So if we require them to 
change their existing datastore design (adding a bit for each leaf  setBymanager { boolean} ), 
then we certainly raise the cost of NETCONF implementation.

Balazs

es able to claim

---

From: Phil Shafer <[email-masked]>
Date: Tue, 26 Aug 2008 16:19:24 -0400

>future, or to mimic all of the non-interoperable choices made by

I think we're trying to maximize market acceptance, allowing the
large set of devices to use YANG (and YANG modules) as easily as
possible in order to encourage people to use what we're making and
avoid having an incredible standard that no one implements.

The alternate theory is we're making a spec that minimizes the
opportunity for vendors to decide that they will be forced (for
economic reasons, meaning the cost of doing it the right way) to
violate the spec in order to ship something they can call YANG/NETCONF.
If a vendor can't implement a feature correctly without rototiling
their entire code base, it's not going to happen.

Yes, I'd love it to work the way my code works (save user-specified
values even if they are the default), but we need to be flexible
enough to embrace vendors that don't work that way.

So the short answer is: If we don't deal with the present/past, we
won't get to become the future.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Tue, 26 Aug 2008 16:19:24 -0400

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 26 Aug 2008 15:59:40 -0700

> future, or to mimic all of the non-interoperable choices made by

It has always been the 'NETCONF philosophy' to standardize
what we can, and use capabilities to identify the things
we cannot standardize.  The 'with-defaults' feature itself
does not seem to be the problem.  If you support the
capability, you will return everything is asked by the
manager.

This may be like <candidate> vs. <running> as the config
target.  We had no success forcing one camp to give in
and say "we'll toss our code out and do it your way".

And just like the <candidate> vs. <running> debate,
if the manager knows which of the finite set of variants
is supported, it can deal with the agent easily.

I would prefer a standard solution, like you would.
But I will settle for a standard way to figure out
what the agent will do.

IMO, the arguments against returning the defaults when
asked by the agent are based on the outdated notion
that bandwidth is expensive and memory is insanely expensive.
I can buy a 1G stick of memory on eBay for $12, a gigE switch
for $50.  The idea that it is too much burden for a
router to store these values seems absurd to me.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 26 Aug 2008 15:59:40 -0700

Andy