Subject: Re: [Netconf] base:1.1 capabilities

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

Juergen Schoenwaelder <[email-masked]> wrote:
> On Wed, Mar 31, 2010 at 11:11:58PM +0200, Martin Bjorklund wrote:
> > Juergen Schoenwaelder <[email-masked]> wrote:
> > > On Wed, Mar 31, 2010 at 10:45:59PM +0200, Martin Bjorklund wrote:
> > >  
> > > > 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...)
> > > 
> > > 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)
> 
> So why is the YANG namespace URI then 1.0 and not 1.1?

Because the YANG namespace statement specifies the XML namespace for
all operations.  So if we change this from the current urn:...:1.0,
a new client would have to send e.g. 

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

This was proposed by Lada, in another thread.

> > Also, why do we need the capability uris for candidate etc if we have
> > them as features?
> 
> 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".

If we were to do a completely new version, without any concerns for
backwards compatibility, we surely would use the normal YANG
features.  The namespace would not have the version number at all,
instead we'd use the revision value; we'd have no capabilities, just
features etc.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 01 Apr 2010 09:59:56 +0200

> This was proposed by Lada, in another thread.

I actually proposed to change the namespace to 1.1 for rpc layer
elements as well, which seems more straightforward. Only the hello
elements have to keep the old namespace for compatibility.

Whether or not namespace URI is the right place for encoding the
protocol version is a controversial question that has been discussed in
XML circles before. The main argument against ever changing the
namespace is that old implementations won't recognize the new URI. I
think it doesn't really apply for NETCONF because of the hello messages
- each party can only get the namespace(s) it asked for.

Given that hello was not designed with an option for sending version
info - and version number *is* already present in the namespace URI - I
think it's better to eat our own dog food. It will work the same way for
any future versions as well, even if the vocabulary really changes.

Lada

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

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Thu, 01 Apr 2010 03:01:40 -0700

> possible", not "as old style NETCONFish as possible".

My concern is that the YANG module capability MUST be predictable.
It MUST mean the same thing every time it is used.  If I have to
find the YANG module and parse it to make sure I am using the
correct module, then it is not predictable at all.

The current formula, approved by the WG and sent to the IESG,
is predictable.

IMO, the YANG formula is fine and not confusing at all.
So what if the XML namespace URI has a '1.0' in it.  That is just
legacy cruft.

The YANG features for NETCONF capabilities does not work.
The features with parameters can never be replaced.
Replacing some of the '1.0' capabilities with features
but not all of them is pointless.  Advertising ietf-netconf.yang
is pointless.  The 'base:1.1' capability already covers it.

> /js

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 7 Apr 2010 12:32:24 +0200

On Thu, Apr 01, 2010 at 12:01:40PM +0200, Andy Bierman wrote:
 
> Advertising ietf-netconf.yang is pointless.  The 'base:1.1'
> capability already covers it.

But isn't this an exception to how you normally advertise YANG
modules? If yes, I do not like it.

/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, 07 Apr 2010 12:36:03 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> modules?

It is an exception.  A normal YANG module is advertised as a
capability with <namespace>?module=<module>&revision=<revision>...

But in this case, for backwards compatibility reasons, the idea is
that it is advertised as base:1.1 instead.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 7 Apr 2010 12:52:15 +0200

> that it is advertised as base:1.1 instead.

I do not like the 'instead' - I would not mind if it is advertised
differently in addition to the normal YANG advertisement for backwards
compatibility.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 07 Apr 2010 07:52:46 -0700

> differently in addition to the normal YANG advertisement for backwards

I may agree with you.
I implement with-defaults, but do not advertise ietf-netconf.yang (yet).
However, that file must be present in the module path because
with-defaults imports ietf-netconf. If ietf-netconf
is not advertised by the server, then it seems broken to advertise
modules that augment it.

No matter what we do, a 4741bis implementor is going to
have to special-case ietf-netconf.yang because of the capability URIs.

In order to achieve a complete framework in which client applications
can rely on the <hello> meta-data to drive the session, then I think we
have to advertise ietf-netconf.yang.

The YANG features are secondary.  Being able to augment the protocol
operations is the primary reason to include ietf-netconf in the
advertised modules.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 08 Apr 2010 08:34:34 +0200 (CEST)

> is not advertised by the server, then it seems broken to advertise

So if we advertise both, how do we treat inconsistencies?  Any MUSTs?

> have to special-case ietf-netconf.yang because of the capability URIs.

No, there is an option which does not make any special cases for the
implementor, and that is to not have any special capabilities at all
in 4741bis, just do them as features.  A pure 1.1 server would
advertise the YANG capability including features.  A 1.0 + 1.1 server
would advertise the YANG capability + all the 1.0 capabilities.

So here are the alternatives:

  1.  capability-based
      advertise base:1.1 capability + other capabilities as in 4741
      do not advertise the YANG-defined capability.

      Pro: requires less changes to code and doc
      Con: not yangy

  2.  pure YANG
      just follow YANG rules, and advertise the namespace + features.
      there is no base:1.1 capability to advertise.
  
  3.  mix
      advertise both base:1.1 + other capabilities,
      and advertise the namespace + features

      Con: Confusing that redundant info is advertised, and how do we
           handle mismatches?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 08 Apr 2010 00:52:27 -0700

>       Con: Confusing that redundant info is advertised, and how do we

I see your point on (2).
Before I said ietf-netconf was redundant because we had base:1.1.
In reality, base:1.1 is redundant because we have ietf-netconf.

We need ietf-netconf because other modules (like with-defaults)
will augment it.  We don't really need base:1.1, since a new client
can look for ietf-netconf just as easily as it could look for base:1.1.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 08 Apr 2010 01:10:06 -0700

> can look for ietf-netconf just as easily as it could look for base:1.1.

oops -- this is not entirely correct.
We need a new client to somehow advertise in its <hello>
that it is a new client, and wants a 4741bis session,
not a 4741 session.  The base:1.1 capability serves that
purpose.  The alternative is to have the client advertise
ietf-netconf but that seems more broken than the rest of the options.

The easiest solution for this aspect of the problem is
to extend the exact-match for a base capability
instead of creating a partial-match for namespace-part. (option c.)

Client sends     Server sends       Protocol version in use:
 1.0, 1.1          1.0, 1.1         1.1
 1.0, 1.1          1.0              1.0
 1.0, 1.1          1.1              1.1
 1.0               1.0, 1.1         1.0
 1.0               1.0              1.0
 1.0               1.1              none -- drop session
 1.1               1.0, 1.1         1.1
 1.1               1.1              1.1
 1.1               1.0              none -- drop session

ietf-netconf SHOULD be advertised because it can be augmented.
A server MUST make its protocol capabilities and ietf-netconf features match.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 08 Apr 2010 11:07:24 +0200

>       there is no base:1.1 capability to advertise.

Strictly speaking, this option is not "pure YANG" but rather "misused
YANG". The spec positions YANG quite clearly as "a language used to
model data for the NETCONF protocol". In this case, YANG is used for
(re)defining the NETCONF protocol itself, which is IMO clearly outside
the scope of YANG and therefore incorrect. In fact, by doing so, YANG is
made into yet another XML schema language.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 08 Apr 2010 11:12:56 +0200 (CEST)

> made into yet another XML schema language.

I disagree.  The YANG spec says:

  YANG is used to model the operations and content layers of NETCONF

What we're doing in ietf-netconf.yang is modelling the core NETCONF
operations.

We're not doing anything with the Messages layer (*that* would be
misusing YANG).

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 08 Apr 2010 13:01:37 +0200

> What we're doing in ietf-netconf.yang is modelling the core NETCONF

Beside the technical issue of XML attributes in core NETCONF operations
that cannot be represented in YANG (by design), YANG spec also defines
XML mapping rules in terms of the core NETCONF operations. So I'd assume
these core operations are given to YANG from outside.

IMO the core NETCONF operations as defined in RFC 4741 or 4741bis should
be fully determined by the base capability URI, independently of any
YANG idiosyncrasies.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Apr 2010 13:17:01 +0200

On Thu, Apr 08, 2010 at 11:12:56AM +0200, Martin Bjorklund wrote:
> > Martin Bjorklund p????e v ??t 08. 04. 2010 v 08:34 +0200:
> > 

+1

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Apr 2010 13:20:32 +0200

> Client sends     Server sends       Protocol version in use:

If this is a problem, we need to solve if for _all_ YANG modules and
not just for this one. If I have two versions of foo.yang defining
bar(), how is the server going to know whether the client likes to
invoke bar() of the first or second version?

Things really should fall out naturally if we got YANG right and if
things don't fall out naturally, I am concerned we did not do our
homework well enough.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 08 Apr 2010 14:33:10 +0200 (CEST)

> invoke bar() of the first or second version?

The problem is not which version of the operation to invoke - the
problem is which version of the protocol (on the message layer) the
client wants.

> things don't fall out naturally, I am concerned we did not do our

As we agreed, YANG does not try to do anything with the message layer,
so in order to do any negotiation for the message layer, it needs to
be done outside YANG.

Hmm.  So maybe this is the solution.  The base:1.1 capability is used
by the server and client to indicate support for 4741bis message
layer.  Then the normal YANG capability is used by a 4741bis server to
indicate support for 4741bis operations, and the old capabilities are
used to indicate support for the 4741 operations to old clients.

4741bis-only server advertises:
   base:1.1
   YANG capability (namespace + features)

4741bis + 4741 server advertises:
   base:1.1
   YANG capability (namespace + features)
   base:1.0
   4741-capabilites (:startup etc)

4741bis-only client advertises:
   base:1.1

4741bis + 4741 client advertises:
   base:1.0
   base:1.1

If the effective protocol is base:1.1, then the client checks the
features to see what the server can do.

If the effective protocol is base:1.0, then the client checks the
capabilities to see what the server can do.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Apr 2010 14:40:58 +0200

On Thu, Apr 08, 2010 at 02:33:10PM +0200, Martin Bjorklund wrote:

[...]

> capabilities to see what the server can do.

This looks reasonable to me.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 08 Apr 2010 06:00:51 -0700

> This looks reasonable to me.

Except YANG features have no way of passing parameters, so
they will never work for :url or :with-defaults.

A solution which does not even work for our 1.0 legacy
stuff is not very good.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Apr 2010 15:05:35 +0200

> they will never work for :url or :with-defaults.

See my other message - :with-defaults is not cast into stone yet.
 
> A solution which does not even work for our 1.0 legacy

Or perhaps shows that there is a real-world demand for parameterized
features?

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 08 Apr 2010 08:22:22 -0700

> See my other message - :with-defaults is not cast into stone yet.

We went through your proposal months ago and the WG
decided to keep using parameter=value instead
of feature=permutation-name.

This conversion plan does not work at all for
the :url 'scheme' parameter (scheme=file,sftp')
because the parameter values are not fixed enums like for :with-defaults.

> Or perhaps shows that there is a real-world demand for parameterized

The :url and :with-defaults capabilities work fine the way
they are now.  They need to remain in place, even if a YANG
feature (a boolean) is also used.

I do not think we need CLRs about what parts of the <hello> a client
is allowed to use.  The whole message MUST be correct, even if it
may have redundant information.  The client can ignore :url and :with-defaults
if it does not care about those capabilities.  The client can ignore
YANG features for ietf-netconf if it implements the protocol based
on the capabilities instead.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 08 Apr 2010 18:23:51 +0200 (CEST)

> >> they will never work for :url or :with-defaults.

I agree that features should not be (mis)used to carry information
about e.g. url schemes.  The YANG spec says about feature:

  feature: A mechanism for marking a portion of the model as optional

Two alternatives have been suggested to cope with this:

1.  This can be solved with Andy's proposal to allow other
    parameters in the capability string in YANG.  Something like:

  capability-string   = namespace-uri [ parameter-list ]
  parameter-list      = "?" parameter *( "&" parameter )
  parameter           = revision-parameter /
                        module-parameter /
                        feature-parameter /
                        deviation-parameter /
                        other-parameter

  Where "other-parameter" is a "<key>=<value>" parameter.

2.  Do not change YANG, and instead use a normal capability to pass
    "protocol information".  In the url case, url would be advertised
    as a feature, and its schemes would be advertised as a capability.

In both cases, there are no formal YANG constructs to define this
extra information; it would have to be defined in text.

I did not like alt. 2 when Andy suggested it for with-defaults, but I
have changed my mind.  I think both these alternatives work.

> is allowed to use.

My point was that a pure 4741bis server would not send all the old
capabilities, so a 4741bis client needs to look at the features to
figure out what the server supports.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 08 Apr 2010 10:10:41 -0700

>     as a feature, and its schemes would be advertised as a capability.

I prefer this solution, rather than re-opening the YANG spec.

> figure out what the server supports.

The :url and :with-defaults capabilities will need to be advertised,
even in a 1.1-only server.

In addition, the url feature in ietf-netconf.yang needs to be set
to enable/disable the <url> parameter in protocol operations.

I prefer to keep the YANG module capability set complete,
which means if module A imports B, then a capability URI
for B MUST be present in the <hello>.  (Even if B is ietf-netconf.yang)
This is what the YANG spec says now, and we should not change it now.

The YANG capability URIs give a complete picture of the operations and content
supported in a particular session.

For a complete picture of the protocol behavior (not covered by YANG),
the base:1.0 and/or base:1.1 capabilities are used, plus the parameter
values for :url and/or :with-defaults.

(and what about capability-change -- how does the client opt-in or opt-out
of capability-changed errors? An RPC? A capability in the client <hello>?)

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 08 Apr 2010 20:45:25 +0200 (CEST)

> I prefer this solution, rather than re-opening the YANG spec.

Ok.

> even in a 1.1-only server.

Yes.

> to enable/disable the <url> parameter in protocol operations.

Yes.

> values for :url and/or :with-defaults.

Yes.

> of capability-changed errors? An RPC? A capability in the client <hello>?)

As proposed earlier, by sending a parameter in its base:1.1 capability
advertisement.

It seems we have an acceptable solution.  So what do other people
think?

If we do this, it will require quite some work in 4741bis.  We need to
talk about features instead of capabilities.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 08 Apr 2010 12:36:15 -0700

>> We're not doing anything with the Messages layer (*that* would be

I do not think we can put the genie back in the bottle now. ;-)
People are discovering other applications for YANG
besides the approved NETCONF operations, notification events,
and data nodes.

For example, a data-driven implementation may choose to create or validate
<rpc-error> contents with YANG derived data structures.
Perhaps the entire NM stack is data-driven from YANG files,
including the CLI and .conf parameters, the WEBui, the CLI,
and maybe even the SNMP agent.

I understand the YANG spec needs to keep the scope limited to NETCONF,
but it also allows language extensions,
and those do not have to be limited to NETCONF.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 09 Apr 2010 10:26:07 +0200

> It seems we have an acceptable solution.  So what do other people

Martin, could you please summarize this solution? I must admit I am a
bit lost.

Thanks, Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 10 Apr 2010 10:27:55 +0200

On Thu, Apr 08, 2010 at 08:45:25PM +0200, Martin Bjorklund wrote:

[...]
 
> It seems we have an acceptable solution.  So what do other people

I disagree that we have an acceptable solution. I think there is quite
some evidence that something is wrong if we are faced with two YANG
modules where the YANG feature advertisement mechanism is not good
enough to do the job. I rather like to get this fixed instead of
special casing this for these two modules by resorting to hand crafted
capabilities because I am sure we will hit this again with other data
models.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 10 Apr 2010 02:32:25 -0700

> capabilities because I am sure we will hit this again with other data

I disagree that YANG features were designed to do the same job
as :url?scheme=ftp,file,sftp or :with-defaults?basic-mode=explicit.

As Martin pointed out, YANG features are designed to be used
with the if-feature statement to partition module contents.

I do not see any reason to change existing protocol capabilities
or not to use new ones in the future, if needed.

There are parts of the NETCONF protocol that YANG does not cover.
This is part of the charter,

YANG feature advertisement is a boolean.
That is unacceptable for some protocol capability parameters.

Using YANG features as a choice is broken:

   feature basic-is-explicit;
   feature basic-is-report-all;
   feature basic-is-trim;
   feature also-supported-is-none;
   feature also-supported-is-trim;
   feature also-supported-is-explicit;
   feature also-supported-is-report-all;
   feature also-supported-is-trim-and-explicit;
   feature also-supported-is-trim-and-report-all;
   feature also-supported-is-explicit-and-report-all;

 1)  There is nothing in YANG that tells the client that only
     2 of these features can possibly be present on a particular server.
 2) There is no meaning or error to generate if other combinations
    of these features are advertised.
 3) this is a cumbersome solution, even for 3 independent variables
 4) the :url scheme has an unbounded list of permutations, so this solution
    is impossible for :url, not just unwieldy
 5) there are no YANG module contents associated with any of these features
    so they represent a misuse of the feature-stmt

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 10 Apr 2010 12:24:14 +0200

>     so they represent a misuse of the feature-stmt

My point remains - if YANG is not good enough to handle the core of
the NETCONF operations, we likely are not done with YANG. If YANG
features are not used to handle this, then YANG obviously lacks a
mechansims to handle such situations properly.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 10 Apr 2010 10:36:28 -0700

> mechansims to handle such situations properly.

We had some solution proposals to deal with capabilities
but the WG decided not to support any modeling of NETCONF capabilities.
It is missing from YANG by choice.

At some point we need to finish this
work and publish it.  Rearranging the deliverables and
re-opening the YANG spec to add more stuff to it
will only delay the 1.0 by another year or more.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 12 Apr 2010 14:40:53 +0200 (CEST)

> Martin, could you please summarize this solution? I must admit I am a

1.  The base:1.1 capability is used by the server and client to
    indicate support for 4741bis message layer.

    Then the normal YANG capability (with features= etc) is used by a
    4741bis server to indicate support for 4741bis operations, and the
    old capabilities are used to indicate support for the 4741
    operations to old clients.

    (see
    http://www.ietf.org/mail-archive/web/netconf/current/msg05602.html
    for more details)

2.  A client that wants the strict capability change behavior
    advertises:

     :base:1.1?strict-capabilities

    (or something like that)

    If the client doesn't advertise that, the server will allow
    capabilities to dynamically change w/o giving any
    'capabilities-changed' errors.

The remaining problem is how to deal with the :url scheme parameter
and the :with-defaults basic-mode and also-supported parameters:
(see http://www.ietf.org/mail-archive/web/netconf/current/msg05607.html)

3a. Change YANG to explicity allow extra parameters in the capability
    string.

or

3b. Use a normal capability to pass extra parameters.  This requires
    no changes to YANG.

In both 3a and 3b there would be no formal YANG statement to define
these extra parameters.

Andy prefers 3b, and I personally think both 3a and 3b works.

I think Juergen objects to both 3a and 3b, because he wants a formal
way to specify extra parameters in YANG.  Juergen is that correct?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 12 Apr 2010 15:29:38 +0200

>     indicate support for 4741bis message layer.

And the base:1.0 capability will have to be advertized in any case,
right? If so, I think it would make a very good sense to emphasize the
NETCONF layering and use a separate URI for operations, e.g.

urn:ietf:params:xml:ns:netconf:ops:1.1

In this case, a server/client supporting 4741bis would advertize
base:1.0 and ops:1.1, old server/client would advertize either base:1.0
and ops:1.0 or just base:1.0 (ops:1.0 will be considered default so that
old implementations continue to work). Finally, a server/client
supporting both versions would advertize base:1.0, ops:1.0 and ops:1.1.

The base:1.0 URI will only have to be changed if the hello protocol or
RPC layer changes (which may also never happen).

>     operations to old clients.

Is the YANG capability really needed, if the 4741bis support is already
indicated via the capability URI?

>      :base:1.1?strict-capabilities

Again, aren't capabilities sufficient to perform this task?

> Andy prefers 3b, and I personally think both 3a and 3b works.

I prefer 3b.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 12 Apr 2010 15:38:32 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> right?

No if you follow the link I included you will see that it is not.  The
idea is that :base:1.0 means that the 4741 message layer is supported,
and :base:1.1 means that the 4741bis message layer is supported.

A new server which does not have to be backwards compatible would
advertise :base:1.1 only.

> If so, I think it would make a very good sense to emphasize the

Yes, b/c the revision and all the features are specified there.

> Again, aren't capabilities sufficient to perform this task?

Yes, this could be indicated by the client either as a separate
capability or as a parameter to the base capability.  I prefer the
latter.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 12 Apr 2010 15:47:39 +0200

> Yes, b/c the revision and all the features are specified there.

The revision can be specified in (or as a parameter to) the base
capability URI and optional features can use special capability elements
as in 3b below for with-defaults. I really think this is out of YANG's
scope and not needed anyway.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 12 Apr 2010 16:01:45 +0200 (CEST)

> scope and not needed anyway.

The YANG module ietf-netconf defines the operations edit-config etc.
The standard YANG rules says that a server that implements this module
should advertise the capability:

   urn:ietf:params:xml:ns:netconf:base:1.0\
     ?module=ietf-netconf\
     &revision=2010-02-04\
     &features=startup,url,validate

How is this out of YANG's scope?  We would need special rules to NOT
advertise this capability.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 12 Apr 2010 07:05:43 -0700

> scope and not needed anyway.

This is incorrect.
The ietf-netconf.yang contents are clearly within the scope of YANG
or the module would be empty.

I have implemented an automated system based on the YANG module
capability URI.  It is critical that the set of modules being
advertised is complete.  Since with-defaults imports ietf-netconf,
it needs to be in the set of advertised modules.

Even without with-defaults, ietf-netconf.yang is the module
for the XML namespace of the 4741bis operations.  It does not
hurt anything to advertise the YANG capability for this namespace,
since it will not be identified in the <hello>
any other way.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 12 Apr 2010 16:33:32 +0200

> or the module would be empty.

YANG features were not designed for client-server negotiation - that's
why they don't have parameters.

>From what Martin wrote I understood that base:1.1 will be advertized as
a capability.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Mon, 12 Apr 2010 07:42:47 -0700

> why they don't have parameters.

No -- they were designed to partition a YANG module into sections.

I don't see what :url or :with-defaults has to
do with advertising the YANG modules.

>>From what Martin wrote I understood that base:1.1 will be advertized as

There needs to be a YANG capability
mapping for the XML namespace of the operations.
This allows an implementation to handle <edit-config>
the same way it handles <acme:restart>.

I do not see why an implementation should be forced to special-case
all the standard protocol operations.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 12 Apr 2010 08:46:09 -0700

> advertise this capability.

This point about special cases is important to me.
I want to avoid them in the standard and in everybody's code.

In order to implement a data-driven system in a modular fashion,
it is important to keep the algorithms rigid and self-contained.
It is desirable for a software module to process the entire
YANG module capability, without any coupling to arbitrary external
modules.

The current YANG spec works this way, and does a nice job of allowing
an on-the-fly compile of the advertised module (e.g. patch in the
deviations and disable the unannounced features).

For protocol capabilities like :url and :with-defaults, special code
is needed, and it is better if this is not coupled to other URI processing.

>From a standards perspective, it is cleaner to keep the YANG module
contents and the special protocol capabilities separate.
The server provides a translation from 1.0 capabilities
to 1.1 features so a client can use either one, and transition
to YANG features over time.

----------------------------------------------------------------------------------
*** WITH-DEFAULTS TEXT CHANGE ***

I think the with-defaults capability should be split into 2
modules and the XML namespace for the <with-defaults> leaf should
use the YANG format base-part, not the NETCONF capability base part:

OLD:

*** 1 combined capability:

   urn:ietf:params:netconf:capability:with-defaults?module=ietf-netconf-
   with-defaults&revision=2010-03-25&basic-mode=report-all&
   also-supported=trim,explicit

*** module namespace uses NETCONF protocol capability base part.

 module ietf-netconf-with-defaults {

    namespace "urn:ietf:params:netconf:capability:with-defaults";

NEW:

*** protocol capability for with-defaults parameters

   urn:ietf:params:netconf:capability:with-defaults?basic-mode=report-all&
   also-supported=trim,explicit

*** module capability using YANG base-part instead or protocol base-part

   urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults?module=ietf-netconf-with-defaults&
   revision=2010-03-25

*** module namespace follows usage guidelines and our naming conventions

 module ietf-netconf-with-defaults {

    namespace "urn:ietf:params:xml:ns:yang:with-defaults";

Unless there are any strong objections, I am going to make these changes to
the next revision of the with-defaults draft.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 12 Apr 2010 08:55:12 -0700

...
>     namespace "urn:ietf:params:xml:ns:yang:with-defaults";

oops -- the full module name needs to be in the new namespace:

  namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults";

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 16 Apr 2010 17:22:21 +0200

> is needed, and it is better if this is not coupled to other URI processing.

But :url is specific to the url feature of the ietf-netconf.yang
module. And the same goes for :with-defaults.
 
> to YANG features over time.

I consider the 4741 protocol operations just another data model
defined in YANG in 4741 and hence :url and :with-defaults are not
"special protocol capabilities" to keep separate from the data
model. This is where our views of the world differ.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 16 Apr 2010 09:07:46 -0700

> module. And the same goes for :with-defaults.

There is no with-defaults YANG feature.
The url YANG feature is new and poorly defined.
It's purpose is just to enable the <url> parameter.
The :url capability is still needed to find out what schemes
are supported by the server.

> model. This is where our views of the world differ.

The NETMOD WG decided not to support NETCONF capabilities
in YANG.  The YANG draft is done and sent to the IESG.
Sorry you don't agree with that decision, but it has already
been made.  The YANG spec does not support the addition
of arbitrary parameters to the module capability URI.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 16 Apr 2010 18:37:04 +0200

> are supported by the server.

Andy, I think I understand how it works. I think the reason we have
the capability is because we can't pass the schemas as a parameter of
the feature. (And there is backwards compatibility mess here.)

> of arbitrary parameters to the module capability URI.

We likely regret this timing later on. Its likely this is not the
last time we run into this.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 16 Apr 2010 12:14:36 -0700

> the feature. (And there is backwards compatibility mess here.)

It is more a conceptual mess than a real problem.
In reality, it is just different letters to parse in a URI string.
There is no impact on the protocol here.

> last time we run into this.

We already fell down that slippery slope.
There is no real criteria for what monitoring information
should be sent in the <hello> vs. polled by the client.
It is not clear that anybody really wants (or ever asked for)
parameters in YANG features.

We have some legacy cruft that does not fit the design,
but going forward, if we use YANG for all the operations,
data nodes, and notifications, then we will be OK.

Each new protocol capability has to be evaluated on
a case-by-case basis.  There may be a need for URI
parameters in the future.  We should not rule it out
for session properties which the client should know about
from the very start of the session.

Andy