Subject: [Netconf] Trying a consensus on the way forward with Netconf-Light

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 16 Apr 2012 15:29:06 +0200

Dear NETCONF WG,

after the discussion on the Netconf-Light, we would like to get the
sense of the WG. The WG at the end needs a consensus to prepare a
reasonably well scoped new charter.

Current Netconf-Light specification describes a profile of the NETCONF
protocol and allows devices to announce that they only support a subset
of the NETCONF protocol operations.
However, Netconf-Light differs from the Netconf standard and proposes to
use a new namespace and a reduced set of configuration features with a
new capability. The specification also discusses TLS as the potential
mandatory to implement secure transport protocol. 	

With that, there are a few questions to answer to get a clarity on what
the WG thinks ( questions b) and c) might be possible to combine,
however please state your opinion separately):

a) Assuming that we need a Netconf-Light document to define diverse
details, should the Netconf-Light document be a Standard track document
or an Experimental? 

b) Should the minimal set of configuration features used in
Netconf-Light be defined in the Netconf-Light document or in an
applicability statement.
E.g. the Netconf-Light document would define a "minimal CM feature set".
An applicability statement can define a few "minimal CM feature sets"
for different purposes. 

c) Should the minimal set of configuration features be defined with a
new capability or based on deviations?

d) Which minimal CM feature set is appropriate for a Netconf-Light for
constrained devices?

Please send your response to the questions above to the Netconf ML, by
April 26, 2011 EDT EOB.

PS: If anybody wants to start additional discussion on a particular
topic, please do so with a "new subject".

Thank you.

Mehmet & Bert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 16 Apr 2012 15:57:01 +0200

> d) Which minimal CM feature set is appropriate for a Netconf-Light for

For a charter discussion, we need to agree on the scope of the
problem(s) to be solved, not necessarily on all details of the
solution. If we break things into abstract pieces, I see two things:

a) an applicability statement document that details how to put NETCONF
   on constrained devices

b) an implementation guidelines document that details how one can best
   transition from a legacy configuration frontend to a standards-based
   NETCONF implementation

(Trying to be constructive without restarting the discussion about
 the details - the answers to a)-d) are interdependent.)

/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: Mon, 16 Apr 2012 10:13:51 -0700

> however please state your opinion separately):

I don't think you are asking the most important questions.
I don't like to reverse-engineer the charter text from a solution I-D.
We should agree on the problems that need to be solved, agree on the
charter text (when it exists), and then agree on the starting point draft.
We can even wait to get the charter approved before making decisions about
the solution.

The WG was asked in Paris for consensus on working on the problem
of NETCONF for constrained devices.  There seemed to be consensus to do that.
The WG was not asked if they wanted to work on NETCONF Light, or
even to use this draft for the starting point.

IMO, there is consensus to work on the problem of NETCONF for
run-time resource constrained devices.  The charter text needs
to be very clear about the definition of a constrained device.

So until there is charter text to discuss, I don't see the point in
discussing solution mechanisms, or standards vs. experimental track,
or other procedural issues.

Andy

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 17 Apr 2012 12:26:43 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Juergen Schoenwaelder
> Sent: Monday, April 16, 2012 4:57 PM
> To: Ersue, Mehmet (NSN - DE/Munich)
> Cc: [email-masked]
> Subject: Re: [Netconf] Trying a consensus on the way forward with
> Netconf-Light
> 
> > However, Netconf-Light differs from the Netconf standard and
proposes
> to

I think that Juergen defined well the goals and deliverables of a
possible work. I support this work. 

Regards,

Dan

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 17 Apr 2012 12:31:44 +0200

> a) an applicability statement document that details how to put NETCONF

I think it's a shame that (base) NETCONF doesn't work on constrained devices because my cell phone now probably has more memory, battery capacity and processing power than what my laptop had when the NETCONF WG was started.

Andy has argued few times that NETCONF is not a good fit for the modern distributed computing and communication environments. Does it mean somebody will start "NETCONF-cloudy" before long?

Lada

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

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 17 Apr 2012 12:57:13 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> On Mon, 16 Apr 2012 15:57:01 +0200, Juergen Schoenwaelder
> <[email-masked]> wrote:
> > 
> I think it's a shame that (base) NETCONF doesn't work on constrained devices

AFAIK, we don't know how small a complete, minimal (base) NETCONF
implementation (for a particular data model) would be.

It is also not clear to me that NETCONF (light) is the right tool for
the job.  Maybe a deployment of these constrained devices have some
kind of controller that can be a NETCONF server, and then the
controller use some other protocol to control the constrainded
devices.

> Andy has argued few times that NETCONF is not a good fit for the modern
> distributed computing and communication environments.

?

/martin

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 17 Apr 2012 13:03:06 +0200

> Behalf Of Martin Bjorklund
> Sent: Tuesday, April 17, 2012 1:57 PM
> To: [email-masked]
> Cc: [email-masked]

[[DR]] Some of them may follow this model but not all, and for sure the
architecture of these devices cannot be constrained or changed because
of the need to accommodate a management protocol, it should be the other
way. 

Regards,

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 17 Apr 2012 13:06:20 +0200

> I think it's a shame that (base) NETCONF doesn't work on constrained devices because my cell phone now probably has more memory, battery capacity and processing power than what my laptop had when t…

Your cell phone is most likely not a constrained device and hence not
the target of a).

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 17 Apr 2012 14:00:55 +0200

> Your cell phone is most likely not a constrained device and hence not

Perhaps in a year or two your constrained devices won't be constrained any more.

But my point is different: I think it would be much better to have a clean, lean and mean baseline spec that works everywhere - i.e., NETCONF-revisited instead of NETCONF + NETCONF-light, and maybe other variants in the future.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 17 Apr 2012 06:27:26 -0700

On 04/17/2012 03:31 AM, Ladislav Lhotka wrote:
> On Mon, 16 Apr 2012 15:57:01 +0200, Juergen Schoenwaelder<[email-masked]>  wrote:
>>

My objection to this work is the inclusion of server-developer-resources-constrained
devices.  I don't think that is a problem the WG should be solving.  We all struggle
with not enough time to get everything done.  So what -- deal with it outside the IETF.

I do not know for sure, but I suspect it would be easier to add something
to CoAP to handle the tiny amount of CM needed on a constrained device,
than it would be cram a usable subset of NETCONF into said device.

What YANG data models are going to run on this tiny device?
So far, none of the modules created in the IETF.
It would be nice to have a concrete example.

Andy

>> Fax:   +49 421 200 3103<http://www.jacobs-university.de/>

---

From: <[email-masked]>
Date: Tue, 17 Apr 2012 14:40:13 +0100

> From: Andy Bierman [mailto:[email-masked]]
> Sent: 17 April 2012 14:27
> To: Ladislav Lhotka
> Cc: [email-masked]
> Subject: Re: [Netconf] Trying a consensus on the way forward
withNetconf-
> Light
> > On Mon, 16 Apr 2012 15:57:01 +0200, Juergen
> Schoenwaelder<[email-masked]>  wrote:
> >>
> > I think it's a shame that (base) NETCONF doesn't work on constrained
> devices because my cell phone now probably has more memory, battery
> capacity and processing power than what my laptop had when the NETCONF
WG
> was started.
> distributed computing and communication environments. Does it mean
> somebody will start "NETCONF-cloudy" before long?
> >
> 
> 
> My objection to this work is the inclusion of
server-developer-resources-
> constrained
> devices.  I don't think that is a problem the WG should be solving.
We
> all struggle

Does it follow that because a device is constrained its CM will be tiny?
Clearly devices with memory, CPU, power or bandwidth constraints would
all prefer as efficient a solution as possible, but that doesn't
necessarily mean the CM will be tiny.

> It would be nice to have a concrete example.

Jonathan

> >>   the details - the answers to a)-d) are interdependent.)

This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 17 Apr 2012 07:02:59 -0700

..
> necessarily mean the CM will be tiny.

This is the only type of constrained devices I think the IETF should address.
What definition of resource-constrained device are you using?
The definition that includes 'not enough engineering hours to
get everything done in time to ship' could make every single
electronics product I've ever purchased a constrained device.

I find it odd that nobody has anything close to a concrete
example of a constrained device and a YANG data model that would
run on that device.

If this is a problem ready for standardization, then somebody
should already be solving it for a real product.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 17 Apr 2012 11:01:41 -0700

> should already be solving it for a real product.

We do, as mentioned before, we don't always implement the whole spec.  Of course, we don't let those devices advertize they support NETCONF, but at least our NMS can support them...

BTW, we have all cases:

  - device resource constrained (cpu, mem, disk)
  - dev/time resource constrained (fact of life, in our experience, we're dealing with it)
  - adapted devices (impossible for a façade to support <lock> when the real device doesn't)

I'm not sure how a NETCONF-light limits the YANG modules that can be supported - "what" and "how" seem orthogonal to me.

K.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 17 Apr 2012 11:14:03 -0700

>    - dev/time resource constrained (fact of life, in our experience, we're dealing with it)

The issue is whether the WG picks a meaningful subset of functionality
or whether the vendor picks an arbitrary subset of functionality.
I don't think the latter is appropriate for a standard.

It wouldn't make sense to ship a router that does some arbitrary subset
of BGP4.  The subset has to be well-known and agreed upon by the WG.

>    - adapted devices (impossible for a façade to support<lock>  when the real device doesn't)
>

If the WG thinks a "no-locking" subset is a good idea,
then that should be in the solution, but it should not be up to the vendor.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 17 Apr 2012 11:31:29 -0700

> Dear NETCONF WG,

a) standards-track

b) NETCONF-Light document; but I prefer the name 'NETCONF for Constrained Devices'

c) new capability; since deviations are not widely implemented (except in yuma and confd)
    they do not really solve the problem; incompatible at layer 8 - political layer

d) the original suggested subset in the -00 draft.
      http://tools.ietf.org/html/draft-schoenw-netconf-light-00
    The -00 draft was almost done. The -01 draft was not a step forward.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 17 Apr 2012 11:49:41 -0700

> But my point is different: I think it would be much better to have a clean,
> lean and mean baseline spec that works everywhere - i.e., NETCONF-revisited
> instead of NETCONF + NETCONF-light, and maybe other variants in the future.

FWIW, this gets my vote.

---

From: Kent Watsen <[email-masked]>
Date: Tue, 17 Apr 2012 12:22:40 -0700

> I don't think the latter is appropriate for a standard.

You mentioned this before, but didn't explain why it matters.  Recall from http://www.ietf.org/mail-archive/web/netconf/current/msg07436.html:

     But the question to ask might be, what difference does it make if
     "light" starts with netconf-zero?  Surely it's better for the devices,
     and it's not like the NMSs are going to implement any less NETCONF,
     as they're going to need it all to interoperate with other devices.
     So, again, what difference does it really make?

NETCONF already defines the concept of extending "base" through advertising capabilities, NCL only lowers the bar for what "base" is.  This change doesn't seem to alter anything fundamental, which is why I don't understand your concern.

BTW, I'm equally OK with using deviations.  The WG just needs to define a deviation for each feature in the NCL draft - a 1-1 mapping.  Either way gets us to the same point.

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Tue, 17 Apr 2012 13:10:47 -0700

> NETCONF already defines the concept of extending "base" through advertising capabilities, NCL only lowers the bar for what "base" is.  This change doesn't seem to alter anything fundamental, which…

The functionality in the NETCONF 'base' was not picked in arbitrary fashion.
The issue is whether the bar is lowered by the WG to a specific point,
or whether the WG standardizes a bar-lowering mechanism so vendors can
set the bar wherever they want, and change it whenever they want.

I don't think multi-vendor interoperability is achievable unless
there is a well-known and meaningful subset of NETCONF that does CM.
Just implementing a few NETCONF commands of your choosing does not
mean a 3rd party application can actually use your server to do
configuration management.

> BTW, I'm equally OK with using deviations.  The WG just needs to define a deviation for each feature in the NCL draft - a 1-1 mapping.  Either way gets us to the same point.

yes -- except RFC 6020 already says how to do this.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 17 Apr 2012 17:01:48 -0700

> The functionality in the NETCONF 'base' was not picked in arbitrary fashion.

I didn't say that.  But now we have several years of implementation experience behind us, maybe it's worth revisiting if that definition of 'base' was best?

> set the bar wherever they want, and change it whenever they want.

Regardless what the WG decides, it won't impact vendors, they will just implement what they can.  The only difference is if they will use an IETF-approved mechanism to advertize that or make up their own.

> configuration management.

It's a business-decision for the vendor to decide how much NETCONF they want to implement and when.  They would make the decision taking into account market ramifications, such as not being managed by particular NMSs - so be it.  On the flip-side, NMS developers might wise up and support NCL because their market demands it.  

> yes -- except RFC 6020 already says how to do this.

Three problems with that:
  1) YANG is not required for NETCONF (see 6241, appendix D)
  2) 6020 says that "deviations MUST never be part of a published standard"
  3) we would need said deviations to be standardized to support interoperability

Thanks,
Kent

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 18 Apr 2012 08:08:39 +0200

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 18 Apr 2012 08:17:55 +0200

Hi,

sorry for the previous empty reply, my fingers don't work well early in the morning. :-(

> I didn't say that.  But now we have several years of implementation experience behind us, maybe it's worth revisiting if that definition of 'base' was best?

Pragmatically, what are the features that are strictly necessary on the server side?

- Subtree filters? No.

- edit-config with all its complexity? No.

- Locks? No. A device implementing per-user candidate does not need them.

Turning these (and other) features into optional capabilities would mean additional flexibility in distributing the functions between the server and client.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 18 Apr 2012 10:01:12 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> - Locks? No. A device implementing per-user candidate does not need
> - them.

So all you have left is file transfer with complete configs.  As Andy
said, why don't you use ftp or http - and call it REST; it's a
super-trivial REST protcol with just one resource, the config, and you
can GET and PUT it.  Done.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 18 Apr 2012 10:25:17 +0200

> can GET and PUT it.  Done.

Yes, this may be perfectly fine in some deployments, or I may just want to use alternative (perhaps more robust) means instead of those that incidentally ended up in 4741.

I may be biased but IMO it is the data layer that is most important and interesting. A system using YANG-based data over HTTPS with PUT, GET, POST etc. can still be a decent CM solution.

And I actually don't want to call it REST because (i) it is a dodgy buzzword and (ii) REST is designed for a human user clicking links in a browser rather than automated machine-machine communication.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 18 Apr 2012 11:31:13 +0200

> - Locks? No. A device implementing per-user candidate does not need them.

Yes, with the minor detail that there is no per-user candidate in the
standards either (and on some systems, a lock is actually much less
costly to implement than a per-user candidate).

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 18 Apr 2012 11:51:01 +0200

> Yes, with the minor detail that there is no per-user candidate in the

This is really a minor detail because it can be standardized as an optional capability. The global candidate is broken.

> costly to implement than a per-user candidate).

Could be. My idea is to represent per-user candidate as a sequence of edits performed by a given user, which shouldn't be too demanding - and also helps with avoiding some of the race conditions.

And I am not saying there is anything wrong with locks, they could become just another optional capability.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 18 Apr 2012 03:01:28 -0700

> This is really a minor detail because it can be standardized as an optional capability. The global candidate is broken.

Actually, designing private candidates is non-trivial.
Not ready for standardization.

> Could be. My idea is to represent per-user candidate as a sequence of edits performed by a given user, which shouldn't be too demanding - and also helps with avoiding some of the race conditions.

It may solve some race race conditions, but it introduces very complex
conflict resolution.  First one wins, and every other concurrent commit fails
is too simplistic and fragile.  Serializing transactions via locking
avoids conflict resolution, but it creates a bottleneck.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 18 Apr 2012 12:31:14 +0200

> Not ready for standardization.

This is OK. I used per-user candidate just as an illustration of the fact that the locking capability is not a sine qua non condition for a CM system.

> is too simplistic and fragile.  Serializing transactions via locking

No, a concurrent commit would fail only if different users happen to have edited the same data nodes. And even then the conflict can be taken back to the private candidate and the user may be given a chance to resolve it. I am not saying this is going to be easy but distributed VC systems like darcs or git demonstrate that it can be done in a reliable way and without locks.

Lada

---

From: <[email-masked]>
Date: Thu, 19 Apr 2012 09:56:28 +0100

> From: Martin Bjorklund [mailto:[email-masked]]
> Sent: 18 April 2012 09:01
> To: [email-masked]
> Cc: [email-masked]
withNetconf-
> can GET and PUT it.  Done.

You have a route for someone to introduce NETCONF in two stages.

You also have an implementation that can be subsequently upgraded to
full NETCONF should you be looking to replace your device with something
less constrained in the future.

Jonathan

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 Apr 2012 02:49:29 -0700

On 04/19/2012 01:56 AM, [email-masked] wrote:
>> Ladislav Lhotka<[email-masked]>  wrote:

It takes about 10 minutes to write some code to use curl to push or pull
a file with HTTP.  I don't know why people would bother to invent a new
version of NETCONF, and then re-engineer a NETCONF-based CM system,
just to move a config file back and forth.

But I keep looking at this problem in terms of what the application
developer gets out of the deal, not what the server vendor gets.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 Apr 2012 11:52:34 +0200

> can GET and PUT it.  Done.

Yes, I am sure something like that can be made to work. However, I
think we have two options (and I think I stated that before):

a) Take a decision to provide a way for devices to support a reduced
   subset of base NETCONF so that they can more easily integrate /
   participate in NETCONF configuration management systems.

b) Or, take a decision that we leave the configuration management of
   certain devices to other protocols, likely developed by other
   people / working groups, likely also ending up with a rather
   different view of the data models.

Orthogonal to all this is the desire to have REST interfaces by some
parts of the larger community talking about managing complex service
driven networks or clouds rather than devices and by other parts of
the community that talk about large numbers of small embedded systems
with serious resource constraints.

I think we have to answer some strategic questions here about where
the NETCONF / YANG community wants to go, whether we are fine with
what we have accomplished or whether we want to react to address
requirements that go beyond what was driving NETCONF initially.

/js

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Thu, 19 Apr 2012 11:59:10 +0200

Inline

> developer gets out of the deal, not what the server vendor gets.

Speaking as an individual contributor.

I would think that specifically at the "application developer" side,
it would be handy/useful/desirable to be able to "manage/configure"
ALL devices (also the constrained ones) with the same NM infrastructure
i.e. YANG and NETCONF. Is that naive thinking?

Bert

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 19 Apr 2012 12:06:00 +0200

> Behalf Of Bert Wijnen (IETF)
> Sent: Thursday, April 19, 2012 12:59 PM
> To: Andy Bierman
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Netconf] Trying a consensus on the way
> forwardwithNetconf-Light
> 
> Inline
> 
> >>>> Pragmatically, what are the features that are strictly necessary
> on
> >>>> the server side?
> >>>>
> >>>> - Subtree filters? No.
> >>>>

[[DR]] Yes, and also from the operators perspective this opens the
chance to share data models, which I do not know how would be done if we
continue to rely on (proprietary) file transfers. 

In the terms of Juergen's mail, if we do not do a) (provide a way for
devices to support a reduced subset of base NETCONF) the world will
default to b) ending up with a rather different view of the data models.

Regards,

Dan

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 19 Apr 2012 12:22:15 +0200

>   different view of the data models.

This is probably already happening in many places. It might be useful though to promote YANG for data modelling outside NETCONF.

And I would also add

c) Take a decision to develop NETCONF 2.0 as a barebone version that would work for all devices and make other features currently included in base NETCONF 1.1 into optional (some of them perhaps RECOMMENDED) capabilities.

For existing implementations this would only mean advertising a few additional capabilities.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 Apr 2012 12:28:42 +0200

> c) Take a decision to develop NETCONF 2.0 as a barebone version that would work for all devices and make other features currently included in base NETCONF 1.1 into optional (some of them perhaps RE…

I tried to stay away from _how_ to do this instead focusing on the
question whether there is something to do or not. So I think your c)
is not really a c). ;-)

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 19 Apr 2012 13:32:06 +0200

> question whether there is something to do or not. So I think your c)

OK.

On a side note, I am now attending RIPE 64 and just saw a demonstration of a switch which can be configured via Jabber.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 Apr 2012 08:16:26 -0700

> i.e. YANG and NETCONF. Is that naive thinking?

Having YANG data models everywhere would help.
Having the instance naming from SNMP traps and SYSLOG messages
match up with the instance naming in the NETCONF datastore
and the CLI would help a lot.

Being able to reuse your code that starts up a NETCONF session is not
very interesting.  Code like curl already does all that for you.
It's the operations that really matter.

   "Get the entire config"
   "Replace the entire config"

Assuming this is the minimum functionality set, there are lots of protocols
that could perform these tasks.  This is separate from the schema language
used to define the contents of the config.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Mon, 23 Apr 2012 09:10:34 -0700

> used to define the contents of the config.

True, but for a vendor who has many devices, some constrained and some not, it would be very nice to have some continuity between them, even if it's just the transport (i.e. netconf-zero).  For instance, our BUs prioritize implementing our proprietary NETCONF capabilities over NETCONF's CM operations.  For constrained devices, our primary market demands would be satisfied even if they could only do entire-config operations plus a few of the extra RPCs we defined.

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Mon, 23 Apr 2012 09:43:21 -0700

> True, but for a vendor who has many devices, some constrained and some not, it would be very nice to have some continuity between them, even if it's just the transport (i.e. netconf-zero).  For ins…

Well netconf-zero would certainly fix your feature development priority issues.
You could just implement the <hello> and maybe get around to some operations some day.
IMO, netconf-zero is a non-starter.

Locking is an important component of NETCONF.
If only 1 session at a time is allowed it is trivial.
If more than 1 concurrent session is allowed it is important to have.

Subtree filtering and <edit-config> are not really must-have features.
Not sure if my minimum must-implement list now exactly matches draft-00:

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

This allows multiple sessions to safely inspect, edit offline, and replace the config.
I can't see lowering the bar any lower than this, and still call the
device "NETCONF manageable".

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 23 Apr 2012 20:48:28 +0200

>  - get-config (no filtering)

Without edit-config, I don't see any need for locking the repository because it can only be modified via copy-config which is presumably atomic. Am I missing something?

Lada

---

From: Kent Watsen <[email-masked]>
Date: Mon, 23 Apr 2012 11:49:16 -0700

> You could just implement the <hello> and maybe get around to some operations some day.

Yes, this is exactly what some of our devices currently do.  Of course, we also made up a strategy for expressing the device doesn't support CM, since NETCONF hasn't provided one yet ;)

> IMO, netconf-zero is a non-starter.

I wonder if anyone else on the list feels this way, so far, IIRC, yours is the only dissenting opinion

> If more than 1 concurrent session is allowed it is important to have.

Devices that only support writable-running sometimes don't implement a lock, as the developers assume the CLI is instantaneously always up to date (I've seen this more than once).  Naturally, these devices wouldn't implement NETCONF, due to their CLI-centric worldview, and so NMS systems are incentivized to implement a NETCONF-adapter for them.   We have that very case, and our off-box NETCONF adapter *lies* about the <lock> RPC succeeding.

BTW, we also have a device that implemented user-specific candidate configs as default.  I pointed out to the dev-team that the RFC called for a global candidate datastore, but they didn't care, citing that user-specific was even more useful.  I bring this up because, in this case, it seems that locking is also somewhat unnecessary.  I know that NETCONF doesn't support user-specific candidate datastores yet, but given that vendors are already doing it, it seems the writing is on the wall...

> device "NETCONF manageable".

I don't know if "NETCONF manageable" is a defined term, but at least half our devices have a different notion of what it means to be managed than yours.  For some of them, the configuration can be dynamically learned from the network, what needs to centralized is software-distribution and licensing (some of what our proprietary capabilities enable)

K.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 23 Apr 2012 12:20:12 -0700

On 04/23/2012 11:48 AM, Ladislav Lhotka wrote:
>> You could just implement the<hello>  and maybe get around to some operations some day.
>> Subtree filtering and<edit-config>  are not really must-have features.

I don't think NETCONF provides any atomicity across sessions.
Messages within a session are serialized but not across multiple sessions.
Sometimes locking is used just to retrieve a clean response that
has not been partially altered during the retrieval.
But I agree locking is not critical if the server does 1 operation at a time,
and the entire config is retrieved or replaced in 1 operation.
I don't think this counts as network configuration, which is
the charter of the NETCONF working group.

So we are back to a file transfer protocol for 1 hardwired file:
   - copy-config
   - close-session
   - get-config (no filtering)

Andy

---

From: Kent Watsen <[email-masked]>
Date: Fri, 27 Apr 2012 07:33:54 -0700

>   - get-config (no filtering)

This set of operations for a new "base" looks good to me, but I'd like it to be the case that the new "base" capability doesn't have to be advertized.  For instance, assuming we define a "base:2.0":

   <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <capabilities>
       <capability>
         urn:ietf:params:netconf:base:2.0
       </capability>
       <capability>
         http://acme.com/foobar/1.0
       </capability>
     </capabilities>
     <session-id>4</session-id>
   </hello>

Means it supports the three operations listed above plus whatever foobar/1.0 defines, whereas:

   <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <capabilities>
       <capability>
         http://acme.com/foobar/1.0
       </capability>
     </capabilities>
     <session-id>4</session-id>
   </hello>

Means it only supports whatever foobar/1.0 defines - is this OK?

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Fri, 27 Apr 2012 08:18:51 -0700

> Means it only supports whatever foobar/1.0 defines - is this OK?

Not to me. I agree with Martin that other protocols such as FTP or HTTP
can be used to transfer the entire config back and forth.  But netconf-zero
doesn't even do that. It is even less useful than a simple HTTP GET.

Even worse than providing zero mandatory-to-implement features,
the use-cases in section 2.2 "Gradually Adding NETCONF Support"
are meant to codify and standardize instability, without any predictability.
Random incremental protocol changes are really not the BCPs that we should be standardizing.

The only issue that matters right now is the one Bob Cole raised:
Is the WG specifying the minimum functionality for netconf-light or not?

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 27 Apr 2012 17:22:37 +0200

> Means it only supports whatever foobar/1.0 defines - is this OK?

So it means really netconf-zero where essentially only <hello> remains and everything else is optional. This looks good to me but I would change the namespace URI for <hello> to urn:ietf:params:xml:ns:netconf:base:2.0
and use something else for the capability defining the three "base" operations (this could actually be a YANG capability).

Lada

---

From: Andy Bierman <[email-masked]>
Date: Fri, 27 Apr 2012 09:07:41 -0700

On 04/27/2012 08:22 AM, Ladislav Lhotka wrote:
> So it means really netconf-zero where essentially only<hello>  remains and everything else is optional. This looks good to me but I would change the namespace URI for<hello>  to urn:ietf:params:xml:ns:netconf:base:2.0

This <hello> message advertises a single proprietary URI.
No standard operations.  No YANG modules.  All the standard
operations have been replaced by proprietary operations,
implied by the "foobar" URI.

You really think it is a good idea to standardize this?

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 27 Apr 2012 18:12:08 +0200

> doesn't even do that. It is even less useful than a simple HTTP GET.

Yes, netconf-zero would be just a communication protocol with the ability to advertise the server's capabilities and data models (both can be defined using YANG). Of course, each device has to implement some set of operations that enable the client to do what's necessary but these sets may widely differ between different classes of devices.

> Random incremental protocol changes are really not the BCPs that we should be standardizing.

We can hardly expect any client to be able to deal with all capabilities that can potentially be thrown on it, so each deployment will have to make sure the capabilities on the servers' side match those that the client(s) can handle.

> Is the WG specifying the minimum functionality for netconf-light or not?

I think what's needed is not neconf-light but rather netconf-2.0 that works everywhere, and this new baseline could be netconf-zero or something more capable. Zero is an absolute minimum functionality.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Fri, 27 Apr 2012 09:23:17 -0700

>> On 04/27/2012 07:33 AM, Kent Watsen wrote:
...
> I think what's needed is not neconf-light but rather netconf-2.0 that works everywhere, and this new baseline could be netconf-zero or something more capable. Zero is an absolute minimum functional…

It works everywhere because all it does is advertise a random or proprietary
version of the protocol.

It will be up to the IESG to decide if netconf-zero advances multi-vendor
interoperability or not.  They have to approve the charter.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 27 Apr 2012 18:33:02 +0200

> It works everywhere because all it does is advertise a random or proprietary

The version of the protocol would be always the same, and the set of capabilities would be adjusted to the problem at hand and properly advertised.

> interoperability or not.  They have to approve the charter.

If there is any tendency to undercut the baseline, via deviations or otherwise, it's IMO even worse for interoperability.

Lada