Subject: [Netconf] additional netconf (4741bis) issues

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 8 Nov 2009 21:56:24 +0100

Hi,

I have a file where I collected some additional 4741bis issues. Its
getting time to get it on the table (and I am happy to do the edits if
people agree on the issues).

* clarify:

  copy-config('running', 'candidate') == commit()
  copy-config('candidate', 'running') == discard-changes()

* clarify

  any changes to 'running' must fail (check which error applies) while
  a commit is in progress

* clarify

  The handling of default data is implementation specific. Some
  implementations may choose to suppress default data while others may
  choose to always report default data while yet some other
  implementations may suppress default data as long as it was not
  explicitely set. A NETCONF extension allows to work with these
  implementation differences.

* clarify examples

  Make sure the message-id is in a proper namespace in all the
  examples. Note that attributes are not in the default namespace, so
  one has to be explicit:

    <rpc message-id="101"
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    </rpc>

  vs.

    <nc:rpc nc:message-id="101"
       xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
    </nc:rpc>

* incorporate capabilities text from the netconf-monitoring draft

   The
   capabilities of a NETCONF server may change over time.  However, once
   a NETCONF server has announced its capabilities in the <hello>
   message, the capabilities for that session MUST NOT change.  A server
   MUST reply with a 'capabilities-changed' error if the client sends a
   request which is affected by a modified capability.  A server MAY
   choose to send 'capabilities-changed' as the response to any request
   other than <close-session> if its capabilities has changed.

/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: Martin Bjorklund <[email-masked]>
Date: Mon, 09 Nov 2009 09:47:45 +0100 (CET)

>   copy-config('running', 'candidate') == commit()

This is not quite correct.  A copy-config() does not count as a
confirming commit.

>   copy-config('candidate', 'running') == discard-changes()

Ok.

>   any changes to 'running' must fail (check which error applies) while

No, since you are allowed to do more changes through a new confirming
commit:

   Note that any commit operation, including a commit which
   introduces additional changes to the configuration, will serve as a
   confirming commit.

Unless we want to change that of course...

>   implementation differences.

Ok.  We just agreed that 4741bis should say that with-defaults SHOULD
be implemented.

>        xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">

No this is not correct.

The default namespace doesn't even apply to attributes.

And in the XSD, attributeFormDefault is "unqualified", which means
that local attributes do not have prefixes.

Confusing?  A simple concept like "namespace" surely must be easy to
explain - see http://www.rpbourret.com/xml/NamespacesFAQ.htm :)

>    other than <close-session> if its capabilities has changed.

Ok.  It is still not clear if 'capabilities-changed' should be a new
error-tag (makes the protocol incompatible), or an error-app-tag
(works, but the protocol is not an "app"), or maybe error-info (also
works, but seems a bit convoluted).

/martin

---

From: Phil Shafer <[email-masked]>
Date: Mon, 9 Nov 2009 08:37:31 -0500

>Ok.  We just agreed that 4741bis should say that with-defaults SHOULD

I strongly object to with-defaults being SHOULD.  2119 says:

   3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
      may exist valid reasons in particular circumstances to ignore a
      particular item, but the full implications must be understood and
      carefully weighed before choosing a different course.

I don't see the implementation of use of W-D as being sufficiently
important to hit this bar.  It's a "nice to have" feature, but not
a SHOULD.  In particular, there are multiple implementations of
NETCONF working in the real world at this moment that do not have
this feature and are not significantly harmed.  For data model that
contain the sufficient default values, an implementation may never
need to use W-D.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 09 Nov 2009 08:13:17 -0800

> contain the sufficient default values, an implementation may never

The same could be said for YANG.
There are NETCONF implementations that don't use YANG.
So what?

The issue for the IETF to decide SHOULD/MUST is whether
a client SHOULD/MUST be able to retrieve all server values.
IMO, this is a SHOULD requirement.  We have already established
that the server knows all the default leafs, even when the
meta-data is incomplete so the client cannot deduce the values.

If you only ship data models that never
have any YANG defaults, then you can explain
to your customers that the SHOULD doesn't
apply to you.

>  Phil

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 9 Nov 2009 13:06:09 -0500

>There are NETCONF implementations that don't use YANG.

There's no requirement in NETCONF that mandates the use of YANG.

>meta-data is incomplete so the client cannot deduce the values.

We have also established (by existence proof) that NETCONF servers
don't need W-D.  It's a "nice to have", not something that is
a requirement, SHOULD or otherwise.

Thanks,
 Phil

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 12 Nov 2009 10:50:07 +0100

Phil,

IIRC you have been on the NETCONF/NETMOD call where we decided 
together on the use of with-defaults and David summarized the 
discussion results as below:

David Partain wrote on Friday, October 02, 2009 10:36 AM
> Subject: [netmod] Information from chair phone call on 24 September
>
......
> 
> 3. The NETCONF WG to check consensus on whether 'with-defaults:'
> should be a SHOULD to implement.
> 
> 4. In conjunction with the 'with-defaults:' work, the NETCONF WG
> can consider adding an XML attribute in a report-all response
> that tags default data as such to help NETCONF applications.
> (This discussion is already underway.)

Can you elaborate why you think now differently?

Mehmet

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Phil Shafer
> Sent: Monday, November 09, 2009 7:06 PM
> To: Andy Bierman
> Cc: [email-masked]
> Subject: Re: [Netconf] additional netconf (4741bis) issues
> 
> Andy Bierman writes:
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Phil Shafer <[email-masked]>
Date: Thu, 12 Nov 2009 09:38:08 -0500

>> should be a SHOULD to implement.

The bullet is "check concensus".  This does not imply that the
concensus of folks on the call was that this is a good idea.
I have never thought it was reasonable and continue in that
opinion.  There is nothing in NETCONF (or YANG) that requires
W-DEF and there's no reason it MUST be a SHOULD.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 12 Nov 2009 07:13:23 -0800

> W-DEF and there's no reason it MUST be a SHOULD.

There are many ways that the meta-data that is needed
to derive the default (or determine that a missing leaf
instance indicates no default is being used) can be incomplete.

Your claim that the client can simply figure out the
default that is is effect doesn't work reliably.
The only reliable mechanism is to retrieve the
default value that is in use on the server.

The importance of using correct data instead of
guessing, and perhaps using wrong data, is
critical to the application developer.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 12 Nov 2009 10:15:44 -0500

>default that is is effect doesn't work reliably.

There are existence proofs that W-D is not needed for NETCONF apps
to work reliably.  In many cases, the translation between high-level
config (I want to join VPN foo) and the config to perform that job
(add that customer's interface to that VPN) will be completely
unrelated to default values.

But I'm not debating that it's useful, only that it doesn't rise
to the level of a SHOULD.  It's something clients and servers can
live a long and happy life without needing.

>default value that is in use on the server.

"in use"?  Have we shifted to talking about dynamic defaults (for
operational data) again?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 12 Nov 2009 07:58:46 -0800

> unrelated to default values.

The IETF members have every right to focus on
the interoperability needs of the IETF.

Unless the import/include by revision is used
in every case, and every module has a revision, and every module
is advertised, then the client cannot deduce the defaults correctly.

There does not seem to be any consensus to require
YANG writers to follow these strict rules.  Since the
revision-date has not been used in any YANG data model so far,
it seems unlikely these rules would be followed anyway.

> live a long and happy life without needing.

Some people think the client MUST be able to retrieve
all values that affect the device.  There seem to be
even more who think all values SHOULD be retrievable.

> "in use"?  Have we shifted to talking about dynamic defaults (for

No -- the server 'knows' exactly what it implements.
The client may have to guess what the server knows, unless
the 'report-all' option is available for retrieval.

If the server uses only modules with revision dates,
and every import/include has a revision date, and every
module is advertised in the <hello>, then W-D is just
a nice-to-have.  Otherwise, it is a SHOULD have.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 12 Nov 2009 14:20:48 -0500

>the interoperability needs of the IETF.

Is this an issue for your guidelines document then?  It's certainly
not needed in the base NETCONF spec.

Thanks,
 Phil