Subject: [Netconf] base:1.1 capabilities

From: Andy Bierman <[email-masked]>
Date: Wed, 31 Mar 2010 11:44:56 -0700

Hi,

I would like to resolve the base:1.1 issues in 4741bis.

1) client and server advertise the base capabilities they support
   (base:1.0 and/or base:1.1)

     urn:ietf:params:netconf:base:1.0
     urn:ietf:params:netconf:base:1.1

  The namespace for all base:1.0 and base:1.1 elements are the same

     urn:ietf:params:xml:ns:netconf:base:1.0

  The client and server will determine which protocol version
  (RFC 4741 or 4741bis) is in use, by examining the base URI
  string during the <hello> exchange.  If there are no base URIs
  in common, then the session is dropped.

  The base:1.1 capability will be defined in normative text,
  not in the ietf-netconf.yang module (e.g., via extension-stmts).

  There seemed to be consensus in Anaheim to make this change to RFC 4741bis.
  This is needed to indicate to new clients that the server
  is following the more-constrained rules in RFC 4741bis,
  not the under-specified rules in RFC 4741.

2) Server advertising YANG module ietf-netconf

    urn:ietf:params:xml:ns:netconf:base:1.0?module=ietf-netconf&revision=2010-xx-xx

  There are problems with replacing NETCONF capabilities with YANG features:
  a) capabilities with parameters (e.g. url or with-defaults)
     are not translated completely.  All the parameters are lost.
  b) base:1.0 needs to be supported for awhile, so implementations
     still need to parse the capabilities

  Also, advertising module ietf-netconf.yang implies that the server
  supports YANG, when in fact the base:1.1 (+ other capabilities)
  is the real indication of protocol conformance.

  There did not seem to be any consensus on this part of the problem.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 31 Mar 2010 21:09:40 +0200 (CEST)

>   not the under-specified rules in RFC 4741.

I agree with this.

>   There did not seem to be any consensus on this part of the problem.

I think it is better to let the server advertise the base capability
as you describe in (1) above, instead of the normal YANG capability.
This can be controlled with an extension in ietf-netconf.yang:

  module ietf-netconf {
  
    namespace "urn:ietf:params:xml:ns:netconf:base:1.0";
    prefix nc;
    nc:capability "urn:ietf:params:netconf:base:1.1";
     
    ...
  
    extension capability {
    argument uri;
    description
      "If this extension is present within the 'module' statement,
       a NECTONF server will adveritise the 'uri' as specified as
       the argument to this statement instead of the URI as
       mandated by YANG.
  
       This extension is used only to support the versioning mechanism
       in the NETCONF protocol.";
  }

3) We should also decide if we want to make any of the base:1.1
  functions optionally controlled by the client.  Specifically I am
  thinking of the discussion on capability-change.  My proposal was to
  let the client decide if it wants the server to ignore capability
  changes in the session or not, by advertising this info in the
  capability URI.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 31 Mar 2010 12:51:41 -0700

>        in the NETCONF protocol.";

I don't like this because it means everyone will have to
special-case this sort of capability.  This does not follow
the rules in the YANG spec.  A client is supposed to be able
to parse the module XML namespace from the capability URI.

A client should not trust the module names, because they
may not be unique.  The XML namespace is much more likely
to be unique.  Clients should use the XML namespace in their
module lookup code, and not rely on the module name.

How is the client supposed to know when a module has decided
to suppress the module namespace and use a capability extension
instead?

This will confuse clients into thinking there is an XML namespace
"urn:ietf:params:netconf:base:1.1" for module ietf-netconf.

I prefer to only get the correct YANG encoding for every YANG module.

The 'base:1.1' capability is sufficient.
The module=ietf-netconf and the revision date are not needed.
The 'base:1.1' is more conceptually correct, because server
conformance in this case is the the entire protocol (as defined
in RFC 4741bis.)  YANG conformance is only for the operations
and content layers, not the other layers,  The 'base:1.1' capability
covers all the layers.

>   changes in the session or not, by advertising this info in the

This could be a separate URI, or a parameter added to base:1.1

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 31 Mar 2010 22:45:59 +0200 (CEST)

> The module=ietf-netconf and the revision date are not needed.

This was actually what I tried to propose above.  My suggestion was
that a 4741bis server must advertise

  <capability>urn:ietf:params:netconf:base:1.1</capability>

It seems we agree so far.

I also proposed that the server should not advertise

  <capability>urn:ietf:params:xml:ns:netconf:base:1.0?module=ietf-netconf&revision=2010-xx-xx&features=candidate,confirmed-commit,xpath,validate</capability>

(since it is not needed, and sort of confusing...)

> and content layers, not the other layers,  The 'base:1.1' capability

Agreed.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 31 Mar 2010 22:58:38 +0200

> (since it is not needed, and sort of confusing...)

Why is the later confusing? Isn't this how YANG works?

/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: Wed, 31 Mar 2010 23:11:58 +0200 (CEST)

> Why is the later confusing? Isn't this how YANG works?

One thing is that the uri "urn:ietf:params:xml:ns:netconf:base:1.0"
actually means that the server speaks base:1.1 (the uri says 1.0, but
it means 1.1)

Also, why do we need the capability uris for candidate etc if we have
them as features?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 31 Mar 2010 23:40:17 +0200

> actually means that the server speaks base:1.1 (the uri says 1.0, but

So why is the YANG namespace URI then 1.0 and not 1.1?
 
> Also, why do we need the capability uris for candidate etc if we have

We need them for backward compatibility to the 1.0 capabilities.

My point is that if YANG works, we should use it. If it does not work,
we should be concerned. My preference would be to be "as YANGish as
possible", not "as old style NETCONFish as possible".

/js