Subject: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying a consensus on the way forwardwithNetconf-Light]

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Wed, 6 Jun 2012 23:39:19 +0200

Dear WG participants,

it seem very difficult to converge on the topic of NetConf
Light. We have evaluated the mailing lists discussions and
have had conversations with several key participants. We
also discussed this with our AD. From all that, we believe
that an acceptable approach will be that we try to get
approval (i.e. a chartered work item) for:

     Develop standards track NETCONF 2.0 with a new
     modular base version, which has a reduced set of
     mandatory features.
     The present functionality can be used as optional
     capabilities or YANG features.

The "reduced set of mandatory features" is of course to be
developed by the WG once we are chartered for this work.
 
 Please express your support or objections w.r.t. to this
proposal. Pls do so asap, but in any event, no later than
June 20th 2012 (any timezone)

Bert and Mehmet
WG chairs for NETCONF

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Jun 2012 23:50:25 +0200

> developed by the WG once we are chartered for this work.

Is NC 2.0 limited to this or can NC 2.0 also address other issues such
as how we deal with operational state data?

/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: Andy Bierman <[email-masked]>
Date: Wed, 06 Jun 2012 14:50:57 -0700

> developed by the WG once we are chartered for this work.

I don't want to spend WG time to figure out how to make
the standard do less than it does now.  Jumping from 1.1 to 2.0 implies
some new features.  Increased modularity is just 1 of the features
I would expect to be on the table.

I hope we would not make the same mistake as SMIng and EOS
many years ago and isolate protocol and data modeling language
updates unless both WGs decide they cannot rely on the other WG to do X,
so that's why we can't do Y.  If a real NETCONF 2.0 with new features
needs new YANG functionality, then that should be already in the charter.

Andy

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

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Thu, 07 Jun 2012 09:22:51 +0200

Inline

> as how we deal with operational state data?

Sofar, the "netconf-lite" type work (i.e. netconf for constrained devices)
had been agreed by the WG as something that we want to look at and address.

I had not heard that we have agreed on other topics.
But if we have agreement on what things we want tio do additionally, then
fine.

What I don't think we want to do is to define a work item that is
open-ended in terms of what can be added over the course of some years.

Bert (personal opinion)

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 Jun 2012 09:26:42 +0200 (CEST)

> developed by the WG once we are chartered for this work.

With the new coma initiative, isn't it a bit premature to do develop
this now?  Shouldn't we wait for some conclusions from coma first?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 Jun 2012 09:28:09 +0200

> open-ended in terms of what can be added over the course of some years.

Sure. But if we start a project such as NC 2.0, we may want to think a
bit more about what to include/exclude.

/js

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Thu, 07 Jun 2012 09:56:10 +0200

On 6/7/12 9:26 AM, Martin Bjorklund wrote:
> "Bert Wijnen \(IETF\)"<[email-masked]>  wrote:

... snip..

> this now?  Shouldn't we wait for some conclusions from coma first?

Sure we can wait. We can ALWAYS WAIT.

The WG decides.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 7 Jun 2012 12:19:04 +0200

By 'present functionality' we mean Netconf 1.0 and 1.1?  

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Bert Wijnen (IETF)
> Sent: Thursday, June 07, 2012 12:39 AM
> To: Netconf
> Subject: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying a
> consensuson the way forwardwithNetconf-Light]
> 
> Dear WG participants,
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 7 Jun 2012 12:22:05 +0200

> Behalf Of Martin Bjorklund
> Sent: Thursday, June 07, 2012 10:27 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Netconf] WG Consensus call: Netconf 2.0?
> 

My understanding is that coma (if it will succeed) will write a set of
requirements for management of constrained devices and networks. These
may be relevant or relevant in part to Netconf, but the outcome is not
meant to be tailored on Netconf (or Netconf-light or such). 

Which does not mean that contributions to coma from the Netconf folks
are not welcome and needed. Actually the time for these is right now. 

Dan

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 Jun 2012 12:27:52 +0200 (CEST)

> meant to be tailored on Netconf (or Netconf-light or such). 

Right.  For example, if the coma works results in a new protocol for
configuration of constrained devices, should we still be doing this
work with NETCONF?  Or, if coma thinks they can use NETCONF, but only
if we do X, and we just published 2.0 without X, that would be
unfortunate.  So I guess I am saying we should sync with coma.

/martin

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 7 Jun 2012 12:41:42 +0200

> From: Martin Bjorklund [mailto:[email-masked]]
> Sent: Thursday, June 07, 2012 1:28 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; [email-masked]

I like 'sync' better than 'wait for' :-) For example it would be useful
if you can provide (as input to coma) use cases of applications and
configurations that could be addressed by using NETCONF. They may not
solve all coma needs but would help understanding the gaps. 

Dan

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Thu, 07 Jun 2012 13:23:15 +0200

Yes, I would think that those are the current set of fucntions
to choose from.

Bert

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Thu, 07 Jun 2012 13:24:17 +0200

I have nor problem to add a sentence to our possibly
charter work item that says that we need to interface
and sync with coma.

Bert

On 6/7/12 12:41 PM, Romascanu, Dan (Dan) wrote:
> I like 'sync' better than 'wait for':-)  For example it would be useful

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 7 Jun 2012 15:59:32 +0200

> I would expect to be on the table.

Sure, but the new features can be developed as optional, separately from the core spec. I think that making the *current* functionality available in a modular way would be a good start that shouldn't require much discussion (I hope). The benefit of doing so is that it would still be possible to use the old stuff while, at the same time, somebody may develop new approaches as alternatives to the old stuff.
 
> needs new YANG functionality, then that should be already in the charter.

Yes, YANG should be more tightly integrated into NETCONF. IMO there are two areas that should be addressed and improved in NETCONF 2.0:

1. signalling of conformance and revisions
2. configuration versus operational state data versus statistics.

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Thu, 07 Jun 2012 07:06:03 -0700

> charter work item that says that we need to interface

Why would we presume to know more about their charter than they do?

So far, nobody has produced a YANG file which they claim they want
to run on their constrained device.  Is it 10 lists? Is is 50 leafs? Is it 2 leafs?
Is session-based <copy-config> to retrieve or write the entire config at once really
the correct approach, whether it's 2 or 50?

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 07 Jun 2012 07:59:58 -0700

...
> Sure, but the new features can be developed as optional, separately from the core spec. I think that making the *current* functionality available in a modular way would be a good start that shouldn…

Agreed.  That's why I called the feature "increased modularity".
I would also add to the feature list (in no particular order):

   - conformance model
   - transaction model
   - operational state
   - HTTP/RESTful API
   - optimized bulk retrieval
   - YANG XPath updates

> 2. configuration versus operational state data versus statistics.

Yes -- my wish list makes no attempt to partition items between the 2 WGs at this time.
There are a summary from Juergen about the ad-hoc meeting feature list at IETF 83.
That's the list we should start with I guess.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 07 Jun 2012 08:23:00 -0700

...
> solve all coma needs but would help understanding the gaps.

IMO, NETCONF may be too heavyweight for a tiny device, even if
it is stripped down to just <copy-config>:
    * Sessions and XML parsing just get in the way in this use-case.
    * Keeping a session open to avoid the startup overhead is just different overhead.
    * A generic NETCONF client has to wait to receive the server <hello> before sending
       the first <rpc>

I would think a minimal subset of YANG-API would be better suited to a tiny device:
    * No sessions (or session startup overhead, or need for extra round-trip)
    * JSON encoding smaller and easier to parse than XML
    * less state kept in the server

Example Request to replace 2 leaf module:

       PUT /yang-api/datastore/fooconf HTTP/1.1
       Host: example.com
       Content-Type: application/vnd.yang.data+json

       {"fooconf":{"mtu":1500, "hostname":"tiny.example.com"}}

OK Reply:

       HTTP/1.1 204 No Content
       Date: Mon, 23 Apr 2012 17:04:00 GMT
       Server: example-server

Andy

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 8 Jun 2012 12:33:24 +0200

> > > My understanding is that coma (if it will succeed) will write a
set
> > of

Both activities could run in parallel and could be synced, however we
might not be interested to integrate everything coming up in Coma into a
Netconf 2.0.
Current proposal for Netconf 2.0 aims to address the flexibility for the
implementation of capabilities by avoiding competing standards. 

If Coma results suggest the development of a new protocol (e.g. a
Netconf-Constrained) this can be for sure done by using the basics of
the Netconf standard. As I understand our AD supports such a protocol
addressing Coma requirements. Those who are interested in such a
protocol please join Coma and contribute your requirements.

Cheers, 
Mehmet

---

From: Phil Shafer <[email-masked]>
Date: Mon, 11 Jun 2012 08:48:12 -0400

>June 20th 2012 (any timezone)

I object to any "2.0" efforts.  We have a new set of technologies
that need some development, field testing, and experience.  Revisiting
them for a "2.0" effort before the paint is dry on the "1.0" will
be detrimental efforts to gain mindshare.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 11 Jun 2012 15:28:59 +0200

> be detrimental efforts to gain mindshare.

I don't know whether the paint is dry on IPv6 but RFC 6434 recently introduced relatively significant changes in terms of what is required from an IPv6 node. For instance, IPSec used to be a MUST, now it is a SHOULD - simply because almost nobody bothered to implement it but still claimed to have a standard IPv6 implementation.

Apparently, NETCONF also has a few features that are too heavy-weight, clumsy or broken. There is already a decent amount of operational experience and I believe it is time - after about ten years - to adjust NETCONF to the current reality, which actually also includes YANG.

Lada

---

From: Carl Moberg <[email-masked]>
Date: Mon, 11 Jun 2012 15:45:23 +0200

> Apparently, NETCONF also has a few features that are too heavy-weight, clumsy or broken. There is already a decent amount of operational experience and I believe it is time - after about ten years…

 For the record; I don't actually see any strong suggestions that there are any features that are "too heavy-weight, clumsy or broken" in NETCONF or YANG. At least I have never heard that type of feedback from the implementations that we've been working with. Sure, there are issues and challenges with implementing server-side NETCONF (and YANG) particularly around retrofitting it on top of existing software infrastructure, but I have no experience that there are show stopping aspects to it that must be fixed.

 I agree with Phil, let's get (lots) more development, testing and experience before we move. Only now do we see signs of network management software that leverages the features of NETCONF (instead of retrofitting it onto SNMP-centric architecture) and I would like to see how that pans out before drawing any conclusions.

 As was mentioned in our side-meeting in Paris; even better if we could get hold of a handful of those fabled "EMS developers" (that everyone is referring to but noone seems to be able to produce) and see what they think. The discussions we have had this far is based solely on strawmen.

Regards,
--
Carl Moberg, Tail-f Systems
mailto:[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Mon, 11 Jun 2012 07:27:22 -0700

On Mon, Jun 11, 2012 at 6:45 AM, Carl Moberg <[email-masked]> wrote:

> > I don't know whether the paint is dry on IPv6 but RFC 6434 recently
> introduced relatively significant changes in terms of what is required from
> an IPv6 node. For instance, IPSec used to be a MUST, now it is a SHOULD -
> simply because almost nobody bothered to implement it but still claimed to
> have a standard IPv6 implementation.
> >
> > Apparently, NETCONF also has a few features that are too heavy-weight,
> clumsy or broken. There is already a decent amount of operational
> experience and I believe it is time - after about ten years - to adjust
> NETCONF to the current reality, which actually also includes YANG.
>
>
>  For the record; I don't actually see any strong suggestions that there
> are any features that are "too heavy-weight, clumsy or broken" in NETCONF
> or YANG. At least I have never heard that type of feedback from the
> implementations that we've been working with. Sure, there are issues and
> challenges with implementing server-side NETCONF (and YANG) particularly
> around retrofitting it on top of existing software infrastructure, but I
> have no experience that there are show stopping aspects to it that must be
> fixed.
>
>  I agree with Phil, let's get (lots) more development, testing and
> experience before we move. Only now do we see signs of network management
> software that leverages the features of NETCONF (instead of retrofitting it
> onto SNMP-centric architecture) and I would like to see how that pans out
> before drawing any conclusions.
>
>  As was mentioned in our side-meeting in Paris; even better if we could
> get hold of a handful of those fabled "EMS developers" (that everyone is
> referring to but noone seems to be able to produce) and see what they
> think. The discussions we have had this far is based solely on strawmen.
>
>

The feature list identified in Paris is not a strawman.
Transactions, conformance, and some other areas could be improved
in NETCONF.  RFC 6241 was a small incremental update to RFC 4271.

IMO, a NETCONF version of (HTTP or FTP) put and get does not advance
interoperability or operator utility.  A version of NETCONF with nothiing
mandatory to implement except a <hello> (netconf-zero) is even less useful
to end users.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 11 Jun 2012 16:33:30 +0200

> For the record; I don't actually see any strong suggestions that there are any features that are "too heavy-weight, clumsy or broken" in NETCONF or YANG. At least I have never heard that type of fe…

Apparently there are implementations that tend to avoid, for various reasons, certain features that are mandatory in NETCONF, hence NETCONF Light.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 11 Jun 2012 07:52:06 -0700

On Mon, Jun 11, 2012 at 7:33 AM, Ladislav Lhotka <[email-masked]> wrote:

> Apparently there are implementations that tend to avoid, for various
> reasons, certain features that are mandatory in NETCONF, hence NETCONF
> Light.
>
>
I think we should focus on the utility that is delivered to network
operators.
The art of engineering NETCONF-Light is removing features that have the
biggest impact
on memory and CPU footprint, while still providing utility to network
operators.

BTW, there are 2 independent implementations for all of RFC 6241,
so instead from being too heavyweight to implement, it is ready to advance
on the standards track (after some interop testing).

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 11 Jun 2012 17:20:07 +0200

On Jun 11, 2012, at 4:52 PM, Andy Bierman wrote:

> 
> I think we should focus on the utility that is delivered to network operators.
> The art of engineering NETCONF-Light is removing features that have the biggest impact
> on memory and CPU footprint, while still providing utility to network operators.

… or development manpower, …

My original point was that instead of standardizing NETCONF Light it would be better to have NETCONF 2.0 whose barebone version is a common denominator for everybody. And those who have/need more functionality would just advertise it as additional capabilities.

> on the standards track (after some interop testing).

Sure, but this is not in conflict with any 2.0-related efforts.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 11 Jun 2012 08:48:44 -0700

> … or development manpower, …

IMO impact on the Internet and interoperability should be the highest
priorities.
The charter is for network configuration, and multiple independent
implementations
should be able to perform network configuration using the standard protocol.

> My original point was that instead of standardizing NETCONF Light it would
> be better to have NETCONF 2.0 whose barebone version is a common
> denominator for everybody. And those who have/need more functionality would
> just advertise it as additional capabilities.
>
>
I strongly oppose this approach, as well as calling it NETCONF 2.0.
The <hello> message is not a common denominator the configuration
management.

> Sure, but this is not in conflict with any 2.0-related efforts.

I don't think there is consensus to work on a "2.0" at this time.
Nothing mainstream is broken - not even conformance.  We might find in the
future
that module imports prevents us from ever changing an exportable
typedef or grouping.  The simple workaround is to use a different name.
Some think this is a better approach anyway.

It's OK with me if we don't work on any new versions of NETCONF now.

Lada
Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 11 Jun 2012 18:11:47 +0200

On Jun 11, 2012, at 5:48 PM, Andy Bierman wrote:

> IMO impact on the Internet and interoperability should be the highest priorities.
> The charter is for network configuration, and multiple independent implementations

I don't get it. A server can now say in <hello>, e. g. "I implement NACM", or "I implement defaults in this way". What is then the difference if it also says "I implement global locks"? Another server might instead say "I implement transactions" and avoid the overhead of implementing locks.

Lada

> Nothing mainstream is broken - not even conformance.  We might find in the future

---

From: Andy Bierman <[email-masked]>
Date: Mon, 11 Jun 2012 09:26:53 -0700

> I don't get it. A server can now say in <hello>, e. g. "I implement NACM",
> or "I implement defaults in this way". What is then the difference if it
> also says "I implement global locks"? Another server might instead say "I
> implement transactions" and avoid the overhead of implementing locks.
>
>
The issue is not the stuff already optional to implement,
but rather the mandatory-to-implement parts of NETCONF base:1.1.
The issue is how much can a client do with netconf-light -- i.e.,
how much is still mandatory-to-implement?

Lada

Andy

---

From: Carl Moberg <[email-masked]>
Date: Mon, 11 Jun 2012 18:38:19 +0200

> in NETCONF.  RFC 6241 was a small incremental update to RFC 4271.

 Agree that they can be improved, but my impression is still that the there is no factual feedback from real-world users that point us in that direction. It's just that *we* know that there are some irregularities that could be improved.

> mandatory to implement except a <hello> (netconf-zero) is even less useful to end users.

 Agreed.

twitter: @cmoberg
http://www.tail-f.com/

---

From: Carl Moberg <[email-masked]>
Date: Mon, 11 Jun 2012 18:39:36 +0200

> Apparently there are implementations that tend to avoid, for various reasons, certain features that are mandatory in NETCONF, hence NETCONF Light.

 Yes, but the reasons seems to have little to do with protocol design, but with aspects of software development that protocols are poor at addressing.

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 11 Jun 2012 18:57:30 +0200

> how much is still mandatory-to-implement?

Well, NACM is IMO quite critical, too, but still it is not mandatory. 

Lada

---

From: Carl Moberg <[email-masked]>
Date: Mon, 11 Jun 2012 19:17:15 +0200

> Well, NACM is IMO quite critical, too, but still it is not mandatory. 

 Perhaps this is more a game of words, but I certainly don't see the current lack of NACM implementations in the market as "critical". Yes, we would certainly be better off with a universally accepted access control design and implementation(s) but I've yet to hear any implementor (client or server) classify this as blocking their development. In which case it would truly be critical, no?

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Mon, 11 Jun 2012 14:24:36 -0700

I am kind of new to the working group, but for what it's worth, here are
my thoughts on this:

-	To Bert's question: I echo the sentiment that it is not clear
that definition of greater modularity alone such as proposed in Netconf
Light is enough to define Netconf 2.0.  I agree with Juergen that with
the start of a project like this, we may want to consider if there are
other items are to be pursued.  There were a couple of items that were
mentioned e.g. by Andy on the list earlier, from alternative
encodings/JSON via improved ways to handle capabilities to supporting
e.g. REST and connectionless models.  Those are all sensible ideas, and
those particular examples are things which I would like to see pursued.
Changing to 2.0 seems like a major revision change, so it would be good
to be clear which of those goals would be covered (also to avoid
scope/feature creep etc)
-	On the current Netconf Light proposal:  While I agree in
sentiment with allowing for a lighter version and making things modular
and like it from a conceptual perspective, I am skeptical of making
everything optional from a practical standpoint.  My concerns would be
that this impedes interoperability and hence hurts rather than helps the
Netconf value proposition. Lighter version, yes, but not with a
potentially empty set of functionality 
-	That said, modularity _is_ of course important, and a 2.0
hopefully will not make things heavier but "better".  
-	On the coma stuff, it would seem that if the goal of Netconf
light is particularly to address the needs of constrained devices, it
will be important to be in sync with that community, as pointed out by
Martin.  However, I don't think a Netconf 2.0 has to depend on that
community, as long as the goals are clearly articulated (and go beyond
support of constrained devices).  

Regards
--- Alex

-----Original Message-----
Sent: Wednesday, June 06, 2012 2:39 PM

Dear WG participants,

 

Bert and Mehmet
WG chairs for NETCONF

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 12 Jun 2012 10:27:49 +0200

Hi,

The coma work is still very much in scope debating phase, but the
declared goals it started from are 'management of constrained networks
and devices' - so not only 'constrained devices'. 

Regards,

Dan

> Behalf Of Alexander Clemm (alex)

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 12 Jun 2012 11:58:43 +0200

>  For the record; I don't actually see any strong suggestions that there are any features that are "too heavy-weight, clumsy or broken" in NETCONF or YANG. At least I have never heard that type of f…

OK, let me mention one thing: the design of <edit-config> is wrong. A standard approach would be to have one expression for locating the node to be updated and another one for specifying the changes. This is how it is done e.g. in XQuery Update or in databases. <edit-config> attempts to do both steps in one shot which doesn't really work all that great. While this may not be a showstopper, it certainly causes problems - cf. the parallel discussion in the NETMOD list regarding keys for route lists. With a separate locator expression, the NETCONF client wouldn't have to care about list keys all that much and just use any appropriate attributes for selecting a list entry.

Lada

---

From: Carl Moberg <[email-masked]>
Date: Tue, 12 Jun 2012 15:51:52 +0200

> OK, let me mention one thing: the design of <edit-config> is wrong. A standard approach would be to have one expression for locating the node to be updated and another one for specifying the change…

 I agree that it's not perfect. It's about as good/bad as some other protocols (e.g. SNMP). But the point that I come back to is that it's certainly good enough (even with that imperfection and others) that it has the potential to radically improve the way we do configuration management in networks. Making it a moving target instead of widely applying what we have would be a case of over optimization IMHO.

 Now, this looks like one dead horse :-)

---

From: Phil Shafer <[email-masked]>
Date: Tue, 12 Jun 2012 10:11:03 -0400

Ladislav Lhotka writes:
>OK, let me mention one thing: the design of <edit-config> is wrong.

Where "wrong" means "I don't care for it"?  Certainly there's nothing
provably wrong here.  The current functionality has worked well for
us for > 10 yrs.

It uses a consistent approach for both finding targets, changing
targets, and rendering targets.  One can fetch an policy, add the
"replace" attribute value, and load that data as a "patch" on
multiple boxes.

It puts larger responsibilities on the client than the server, with
the assumption that the client has more resources and more current
software, where the device is dumber and will be upgraded as rarely
as possible.

It's not XQuery, but one of the goals was making it accessable to
non-programmers, and I think the declarative nature allows this.

I would not want to see NETCONF turn into XQuery.

Yeah, I know.  You were just checking to see if I was still here ;^)

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 12 Jun 2012 16:36:03 +0200

> I agree that it's not perfect. It's about as good/bad as some other protocols (e.g. SNMP). But the point that I come back to is that it's certainly good enough (even with that imperfection and othe…

If NETCONF (ever) gets widely deployed, it will become next to impossible to make any incompatible changes.

Similar arguments were raised against fixing the SSH end-of-message marker and yet everyone now seems happy with it. Things that are known to be broken should be fixed.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 12 Jun 2012 07:41:21 -0700

> I would not want to see NETCONF turn into XQuery.
Agreed. But I think the approach Lada describes has its use-cases,
such as constrained devices or open systems.

There is plenty of complexity on the server to implement <edit-config>.
It is harder to make N arbitrary edits work together than 1 edit at a time.
There is some presumption that <copy-config> for writing is somehow way
easier than <edit-config> to implement.  It is still N arbitrary edits,
except
the operation is always "replace".

NETCONF servers should go out of their way to prevent glitches to the device
for config that is not really changing in a <copy-config>.  Is a
constrained device going to
do this or just reset everything?  If not, then an approach where the
client picks a single subtree as the target resource (e.g., YANG-API)
may be better.

Specifying the path to the target resource is simpler and smaller as a path
expression, than as an XML subtree.  Encoding the path
from root to the target resource in the <config> subtree is inefficient
for both client and server.

The current approach is better if the client needs to do multiple edits at
once.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 12 Jun 2012 17:23:56 +0200

> provably wrong here.  The current functionality has worked well for

It was fixed in YANG by introducing mandatory list keys and additional rules for <edit-config>, but they also make some things harder than necessary.

> "replace" attribute value, and load that data as a "patch" on

But you can only use keys for selecting list entries, and the key of an entry cannot be changed.

> non-programmers, and I think the declarative nature allows this.

IMO with separate locator and update spec it would be even more accessible and flexible.

> I would not want to see NETCONF turn into XQuery.

Neither would I, it was just an example. Actually, HTTP methods work the same way.

> Yeah, I know.  You were just checking to see if I was still here ;^)

Why, you started this thread, didn't you? :-)

Lada

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Tue, 12 Jun 2012 10:58:08 -0700

Just my 2 cents, one aspect that seems a bit clumsy in YANG concerns the
specification of conditions and constraints.  While it is certainly
possible to argue that it does the job, it is fairly hard to use.  If it
is hard to use, things might be left up to implementations while they
really should be captured in the spec.  It might be worthwhile to
consider possible alternatives to the current scheme, such as being able
to refer to a more "procedural" way to refer to constraints, rather than
the declarative way it is now. 
--- Alex

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Carl Moberg
Sent: Tuesday, June 12, 2012 6:52 AM
To: Ladislav Lhotka
Cc: Netconf
Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying
aconsensus on the way forwardwithNetconf-Light]

On Jun 12, 2012, at 11:58 AM, Ladislav Lhotka wrote:

>> For the record; I don't actually see any strong suggestions that
there are any features that are "too heavy-weight, clumsy or broken" in
NETCONF or YANG. At least I have never heard that type of feedback from
the implementations that we've been working with. Sure, there are issues
and challenges with implementing server-side NETCONF (and YANG)
particularly around retrofitting it on top of existing software
infrastructure, but I have no experience that there are show stopping
aspects to it that must be fixed.
> 
> OK, let me mention one thing: the design of <edit-config> is wrong. A
standard approach would be to have one expression for locating the node
to be updated and another one for specifying the changes. This is how it
is done e.g. in XQuery Update or in databases. <edit-config> attempts to
do both steps in one shot which doesn't really work all that great.
While this may not be a showstopper, it certainly causes problems - cf.
the parallel discussion in the NETMOD list regarding keys for route
lists. With a separate locator expression, the NETCONF client wouldn't
have to care about list keys all that much and just use any appropriate
attributes for selecting a list entry.

 I agree that it's not perfect. It's about as good/bad as some other
protocols (e.g. SNMP). But the point that I come back to is that it's
certainly good enough (even with that imperfection and others) that it
has the potential to radically improve the way we do configuration
management in networks. Making it a moving target instead of widely
applying what we have would be a case of over optimization IMHO.

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 12 Jun 2012 11:08:10 -0700

Hi -

> From: "Ladislav Lhotka" <[email-masked]>
> To: "Phil Shafer" <[email-masked]>
> Cc: "Netconf" <[email-masked]>
> Sent: Tuesday, June 12, 2012 8:23 AM
> Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying aconsensus on the way forwardwithNetconf-Light]
...
> IMO with separate locator and update spec it would be even more accessible and flexible.

...or at least clearly distinguishing them in the operator syntax.
Other benefits of separation:
   - it makes implementing access control a bit more efficient (allows earlier
     detection of "deny" cases)
   - it makes support for "subagents" and other forms of dynamically added /
     removed instrumentation much easier to deal with
   - it allows straightforward implementation of operators that do "the same thing"
     to a whole set of objects (e.g. disable all interfaces currently in alarm states)
   - it potentially allows one to talk about locks and granularity in more reasonable
     terms

This separation was one of the things CMIP got right, and SNMP got perhaps
half right, though I fear mentioning that might endanger it here.

What might seem like a downside (but really isn't) is that it forces the protocol
design to acknowledge at least the gestalt of the naming architecture.
Imposing those constraints is actually a good thing, because it makes it
possible, even necessary to forbid the really pathological architectures a priori.

Randy

---

From: Carl Moberg <[email-masked]>
Date: Tue, 12 Jun 2012 21:23:28 +0200

> Similar arguments were raised against fixing the SSH end-of-message marker and yet everyone now seems happy with it. Things that are known to be broken should be fixed.

 I think the difference is significant. The concerns around the end-of-message marker was related to potential (or actual) security issues that could seriously undermine the willingness to adopt the NETCONF protocol. I'd argue that the edit-config concern you're raising is not "broken", it could potentially be improved for some unspecified application context.

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 13 Jun 2012 11:12:35 +0200

> possible to argue that it does the job, it is fairly hard to use.  If it

Could you be more specific? What is exactly hard? Is it that, for example, one needs to carefully count the number of double dots in order to get to a remote node? Or missing semantics?

> the declarative way it is now.

We have been discussing the addition of several new XPath functions, but mainly for supporting special YANG data types, so nothing really procedural. Can you give some examples?

Thanks, Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 13 Jun 2012 11:27:25 +0200

> The current approach is better if the client needs to do multiple edits at

This is only an issue if you need to perform a larger atomic edit on "running", but this is quite problematic anyway. With "candidate" (or transactions) it can be done chunk-by-chunk. And, as Randy writes, such simple edits would be much easier to validate in terms of access control.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 13 Jun 2012 10:03:17 -0700

>   - it potentially allows one to talk about locks and granularity in more
Nice list.  The 3rd bullet is one of the things in HTTP that I like the
most.
The separation of headers and message body (meta-data and data)
is much cleaner than anything we have in NM protocols.

Not only does it allow for reusable headers that do "the same thing"
across many media types, it makes it easy to extend the set of operators
independently of the base protocol or the data model.

> design to acknowledge at least the gestalt of the naming architecture.

The thing we need the most is a unified naming architecture.
The protocols and APIs can be tuned for different use-cases,
but the data needs to be "glued together" somehow by the apps,
(e.g. CLI, WEBui, REST-API, SNMP. NETCONF., syslog)

Andy

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Wed, 13 Jun 2012 18:37:52 -0700

Hi,

here is one example:

The definition of identity allows to specify a base identity, allowing
to build an "identity hierarchy".  However, if I subsequently want to
specify a condition or a constraint that pertains to all identities that
were derived from the same base identity, I need to enumerate every
single one of the identities.  This makes the definition of the
condition/constraint unnecessarily complex.  Even worse, every time I
introduce a new identity that is derived from the same base identity, I
need to update the conditions/constraints which may have been defined in
an entirely different place.  This basically also defeats the purpose of
using identities, instead of enums, to allow for extending a set of
enumerated values without having to revise the original definition.  

For example, think of the following identity hierarchy:
flow
+-- audioflow
    +-- pandora
    +-- rhapsody
    +-- spotify
    +-- ...
 
If I have a constraint that pertains to audioflows, I need to enumerate
a long list of subidentities instead of the single base identity, and
need to update that constraint whenever a new identity that identifies a
new audioflow is introduced.  

(Maybe this part of the thread actually belongs on the netmod mailer,
not netconf)
--- Alex

-----Original Message-----
From: Ladislav Lhotka [mailto:[email-masked]] 
Sent: Wednesday, June 13, 2012 2:13 AM
To: Alexander Clemm (alex); Carl Moberg
Cc: Netconf
Subject: RE: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying

> possible to argue that it does the job, it is fairly hard to use.  If
it

Could you be more specific? What is exactly hard? Is it that, for
example, one needs to carefully count the number of double dots in order
to get to a remote node? Or missing semantics?

> the declarative way it is now.

We have been discussing the addition of several new XPath functions, but
mainly for supporting special YANG data types, so nothing really
procedural. Can you give some examples?

Thanks, Lada

---

From: t.petch <[email-masked]>
Date: Thu, 14 Jun 2012 10:12:49 +0100

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "Phil Shafer" <[email-masked]>
Cc: "Netconf" <[email-masked]>
Sent: Monday, June 11, 2012 2:28 PM
> I don't know whether the paint is dry on IPv6 but RFC 6434 recently
introduced relatively significant changes in terms of what is required
from an IPv6 node. For instance, IPSec used to be a MUST, now it is a
SHOULD - simply because almost nobody bothered to implement it but still
claimed to have a standard IPv6 implementation.

I think that IPv6 is the poster child on how not to introduce a new
flavour of a protocol.  It is too complex and it is always being meddled
with for what seems like no other reason that the instigators have
little better else to do while waiting to see if anyone adopts it.

In answer to Bert's other thread,
Yes.
There should be a lighter weight version of Netconf that makes chunks
optional but changes nothing - 'improving' the edit capabilities is the
sort of death by meddling that afflicts IPv6.
As pointed out elsewhere, calling it 2.0 will put people off - new major
versions imply large, incompatible changes.
Whether it is possible to come up with an agreed lighter weight version
I am unsure about, the only way to find out is to try.   (Using my
older workstation, I struggle with some websites and believe that it is
the insane complexity of the scripts that render them unusable, but
doubt if I will ever see an HTML option to cut down on script
processing:-(

Tom Petch

---

From: Kent Watsen <[email-masked]>
Date: Mon, 18 Jun 2012 10:53:24 -0700

[just back from PTO, hence the delayed response]

I support a "netconf:base:1.2" that requires the following reduced set of base features:

   - copy-config
   - close-session
   - get-config (no filtering)

And defines distinct capabilities to enable all the base:1.1 operations.

Notes:

  1. I've read all the postings to date

  2. I'm OK calling this an "upgrade".  It doesn't seem too much of a stretch to
     consider "modularization" as the feature being added.  

  3. I'm OK with the "backwards compatibility" of the solution, as existing servers
     would continue to advertise their currently supported 1.0 and/or 1.1 bases and,
     as section 8.1 says: "If more than one protocol version URI in common is present, 
     then the highest numbered (most recent) protocol version MUST be used by both
     peers."  

  4. The reduced set of operations listed above are the same that Andy listed here
     (http://www.ietf.org/mail-archive/web/netconf/current/msg07501.html).  Even in
     the most extreme case, I rather have a device provide this NETCONF base than 
     have to resort to another protocol (ftp).   That said, none of Juniper's devices
     are this constrained: one would only not advertise "locking" and another would
     only not advertize "subtree filtering" (assuming "base:1.2" is advertized) 

Thanks,
Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bert Wijnen (IETF)
Sent: Wednesday, June 06, 2012 5:39 PM
To: Netconf
Subject: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying a consensus on the way forwardwithNetconf-Light]

Dear WG participants,

 

Bert and Mehmet
WG chairs for NETCONF

---

From: Andy Bierman <[email-masked]>
Date: Mon, 18 Jun 2012 11:35:31 -0700

> And defines distinct capabilities to enable all the base:1.1 operations.
I prefer the current name and capability "netconf-light".
That is more clear to users.

Using copy-config to write to the device is optional-to-implement,
but a capability flag 'writes-allowed' could fix that.

Copy-config requires the entire config be present every time anything is
edited.
This seems inefficient, even for small devices.  Copy-config allows an
arbitrary
mix of all-or-nothing changes just like "big NETCONF".  This seems much
more expensive
to implement than 1-resource-at-a-time (like CLI or REST).

I do not strongly object to NETCONF-Light, but I think it will have a
negative impact
on NETCONF usability and interoperability. There is some assumption that
vendors will
start here and raise the bar by adding missing standard components.

It would be perfectly valid for a vendor to "raise the bar" by replacing the
missing standard components with proprietary components.
That reduces the standard to a read-only get-config w/o any standard
filtering.
The read-only copy-config is redundant.  It is only relevant here for
writing, which is optional.

Andy

> consensus on the way forwardwithNetconf-Light]
>
> Dear WG participants,
>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 26 Jun 2012 10:06:19 -0700

> And defines distinct capabilities to enable all the base:1.1 operations.

Why does NETCONF-Light have to be a pure subset of NETCONF?
IMO, copy-config is a horrible solution for CM editing for constrained
devices.
A new edit function could be created instead, creating a new minimum list:

    - edit-resource
    - close-session

rpc edit-resource {
   description "Edit a managed resource in the target configuration.";
   input {
     leaf target-resource {
        type instance-identifier;
        mandatory true;
        description "Resource to edit";
     }
     choice config-target {
           // if not set the server will pick the target config
           // same as config-target in edit-config (candidate or running
leafs)

      leaf candidate {
          if-feature candidate;
          type empty;
          description
             "The candidate configuration is the config target.";
      }
      leaf running {
         if-feature writable-running;
         type empty;
         description
           "The running configuration is the config source.";
     }

     }
     leaf operation {
        type nc:edit-operation-type;
        description "edit operation to perform";
        default "merge";
     }
     anyxml data {
        description "New target resource data (if needed)."
     }
  }
}

Also, the entire mandatory set can be encoded in JSON.
IMO, the real issues impacting server complexity are related
to client flexibility.  In reality, too much of this is a recipe
for non-interoperability. <copy-config> is the worst operation
in NETCONF wrt/ server consistency.  Instead of allowing
an arbitrary mix of eedits, the server is more likely to have
hidden restrictions on the order and concurrency of config changes.

IMO, we should be having the discussion "What do constrained
devices need to be managed effectively and efficiently?"
Instead we are working backwards from a solution and asking
"How much NETCONF can we agree on removing from the
the mandatory subset?"

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Jun 2012 05:08:50 +0200

> IMO, copy-config is a horrible solution for CM editing for constrained

The devices we were implementing on had no CM at all other than
loading a new firmware image. Compared to that, copy-config was a step
forward.

>         description "New target resource data (if needed)."

Sure, something like this could be considered, but we were starting
from a device that really only had "load-firmware", hence copy-config
was already a step forward.

> Also, the entire mandatory set can be encoded in JSON.

We were lucky that there was a minimal XML parser. JSON tends to be a
bit smaller and less chatty but on our device, we had to pass NETCONF
messages through flash since RAM was not sufficient to hold them...

> hidden restrictions on the order and concurrency of config changes.

That was not our problem for the things we made configurable. But I
can see that such devices might want to do a warm start after config
changes, which of course breaks TCP transports. As I said, the REST
API looks indeed interesting and it might map to CoAP, which does not
even maintain a TCP session.

> "How much NETCONF can we agree on removing from the

I think that is the purpose of the coma list.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 27 Jun 2012 06:33:04 -0700

> was already a step forward.
So get-config and copy-config are completely irrelevant to your
implementation?  Maybe you have an binary leaf called 'firmware-image'
as the only object in the config?  IMO this is not CM if the device
has no config.  NETCONF does not even have a standard load-firmware
operation, so the only part of the standard you use is the <hello>.

> even maintain a TCP session.

That's not the point.  The problem is that <copy-config> allows
arbitrary changes, but some implementations I have seen are not good
enough to do that.  They reject the request or handle it wrong instead.
Requiring a reboot is yet another area that NETCONF does not address.

> I think that is the purpose of the coma list.

Which really makes me wonder why the NETCONF WG is solving
this problem as well.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Jun 2012 15:55:40 +0200

> operation, so the only part of the standard you use is the <hello>.

Sorry for expressing myself not well. We did add get-config and
copy-config and we considered that an improvement over the "plug a
cable and do magic to load a new firmware" there was before.

> enough to do that.  They reject the request or handle it wrong instead.

Obviously, devices and implementations differ.

> Requiring a reboot is yet another area that NETCONF does not address.

Yes. But that was not the point either. ;-) NETCONF also does not
provide support to load new firmware (but we would likely not have
used it on the devices we dealt with for other technical reasons).
 
> Which really makes me wonder why the NETCONF WG is solving

As far as I recall, the problem showed up first on this list (because
there was an I-D) and then things got carried forward. And if you go
back the start of this thread, you will see why the discussion is
here.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 27 Jun 2012 07:26:45 -0700

> used it on the devices we dealt with for other technical reasons).

It would be nice if your insights from implementation made it into the
draft.
The technical issues which lead to 1 solution or another are import.
There are issues that are more likely to affect small boxes:

   * cannot change arbitrary mix of config objects at once
   * cannot apply config without requiring a warmstart
   * special requirements for firmware-update

I don't think the same exact operations that were designed for
backbone routers have to be used to manage a tiny SOHO router,
or an alarm clock or a light bub.  In particular, copy-config
has many issues which make it unsuitable.  Requiring the server
to process the entire config in order to change anything seems
contrary to the goals one would associate with "tiny server".

> back the start of this thread, you will see why the discussion is
OK -- we can have the discussion "what does standards-based CM look like,
if these 3 operations are all that is available?".  IMO, not so good.
There seems to be some assumption that the difficult part of implementing
edit-config is related to the nc:operation attribute, so the copy-config
operation will be much easier to support.  This is incorrect.  95% of
the complexity is the same with both operations.

But forget about implementation.  Let's talk about usability.
Providing the entire config for replacement in a copy-config
is something only an admin user can do.  Unless the client
has 100% access to all objects (i.e., no access control allowed),
then copy-config will fail.  (The client will provide a replacement
config that attempts to delete nodes it is unauthorized to access).

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 27 Jun 2012 08:47:47 -0700

> cable and do magic to load a new firmware" there was before.
I should be clear that I like netconf-light-00 and think the WG should
solve the problems presented in that version of the draft.
I just don't want to assume the best solution
is going to be some pure subset of base:1.1.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Jun 2012 17:59:56 +0200

>    * special requirements for firmware-update

I agree.

> contrary to the goals one would associate with "tiny server".

Copy-config is not really bad if you for example can do a warmstart
after getting the new config. ;-) Otherwise, it indeed depends on what
has been modified and whether you can actually change the subsystems
easily (often only true for some of them). Since a warmstart usually
kills your NETCONF session, having something RESTful over CoAP might
be really interesting, but we have not implemented this yet so the
surprises might still be out there in the details.
 
> config that attempts to delete nodes it is unauthorized to access).

On really small devices, there is only an admin user. My good old home
router (and I mean several years old) has a web frontend and for
advanced users it can give you its config for backup purposed and you
can restore it (and it is going to reinitialize itself if you do it).
I assume this config download and config upload model followed by a
warmstart is a rather common model for many small devices (and my home
router is big compared to the devices we tried to implement NETCONF
light on).

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 27 Jun 2012 09:32:48 -0700

> router is big compared to the devices we tried to implement NETCONF

You are right -- for boxes small enough, there is no access control needed.
My home office boxes have 1 user and therefore no need for access control.
They are not all "load-and-reboot" though.  That's part of the problem.
Only some WEBui changes require a reboot, not all.  That's where a
YANG extension might help.

BTW, my little router and APs only have a WEBui - no CLI, no NETCONF, no
SNMP.
I would like to leverage a programmatic API out of the WEBui as efficiently
as possible. That's part of the motivation behind YANG-API.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 27 Jun 2012 20:10:35 +0200

> surprises might still be out there in the details.

FWIW, BIRD routing daemon, upon receiving the HUP signal, performs an internal diff of the old and new configuration and restarts only the subsystems whose configuration changed.

So copy-config really needn't be that bad.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 27 Jun 2012 11:56:27 -0700

On Wed, Jun 27, 2012 at 11:10 AM, Ladislav Lhotka <[email-masked]> wrote:

> FWIW, BIRD routing daemon, upon receiving the HUP signal, performs an
> internal diff of the old and new configuration and restarts only the
> subsystems whose configuration changed.
>
What do you think edit-config does?  Same thing.  That's my point.

Lada
Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Jun 2012 23:20:17 +0200

> FWIW, BIRD routing daemon, upon receiving the HUP signal, performs an internal diff of the old and new configuration and restarts only the subsystems whose configuration changed.

I doubt BIRD runs on the devices I have been talking about here.

/js