Subject: [Netconf] way forward

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 13 Aug 2012 20:16:25 +0200

Hi,

my position regarding the alternatives for future NETCONF work is:

- The issues of operational state representation and modelling need to be worked on. This will most likely require changes in both base NETCONF and YANG.
- If 6241bis is started as a result of previous item, it would be very useful to make NETCONF more modular, and also address other things (errata, conformance, better integration with YANG).
- I therefore prefer to advance the base NETCONF spec, i.e. NETCONF 1.2.

Lada

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 13 Aug 2012 21:50:16 +0200

> - I therefore prefer to advance the base NETCONF spec, i.e. NETCONF 1.2.

My position is as follows:

a) We should finish the NETCONF over TLS update.

b) The WG needs to define how to retrieve and perhaps edit operational
   state. This is crucial, without a solution for this, NETCONF
   remains incomplete. Since I find retrieval of operational state
   crucial, I would rather have the solution part of NETCONF 1.2
   instead of a separate extension.

   My recommendation is that people (or groups of people) draft
   proposals (individual IDs) and the WG selects one by the next IETF
   to be incorporated into NETCONF 1.2.

c) Implementors need to do interoperability testing. It is crucial to
   understand to what extend the specifications we have lead to
   interoperable implementations. I know that interoperability testing
   is not really a WG work item for a WG charter but it is crucial to
   undertake this activity since usually such tests also identify bugs
   in the specifications.

d) Any errata and any interoperability test results identifying
   unclear aspects of the specification should be incorporated into
   NETCONF 1.2. Ideally, NETCONF 1.2. would prove to be bug free
   enough that it later can even advance without re-publication.

e) I have no clear opinion concerning modularization. In my view, we
   should not do anything at this point in time to support NETCONF on
   very constrained devices. If we do some modularization, then we
   should look at interoperability issues with boxes that do not
   support NETCONF fully because they proxy for boxes that say can't
   do locking or they do not support structured data models. Some of
   the solutions such as lying about locks or pretending that the data
   model of the box is just a single element likely are worse than
   adding a few well selected features. Truth in advertising I believe
   is desirable and helpful for interoperability.

   My recommendation here would as well be that people (or groups of
   people) draft concrete modularization proposals (individual IDs)
   and the WG selects by the next IETF. And the selection might very
   well be an empty set.

/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, 13 Aug 2012 13:13:54 -0700

Hi,

I don't agree that protocol modularity is an important problem to solve.
The protocol is already very modular, in that there MUST implement
list for a server is already quite small, considering "read-only running"
is the minimum requirement.

I do not agree operational-state is critical to solve.
I have not seen a clear problem statement yet.
We can go looking for corner-cases to solve, with ever diminishing returns
on WG effort and time.

There are work-arounds to the operational state problems
(define 2 leafs ala admin/operStatus for duplex=auto;
 define custom write-state RPC operation).
I don't agree the operational state problem requires that
the protocol version be updated and base:1.1 be made obsolete.

I agree with Phil that we should not even send the signal that base:1.1 is
going to be obsolete, and replaced by a base:1.2.  We can continue to
add nice-to-have operations and capabilities, without continuously
spinning the base protocol.

Andy

On Mon, Aug 13, 2012 at 12:50 PM, Juergen Schoenwaelder
<[email-masked]> wrote:
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Phil Shafer <[email-masked]>
Date: Mon, 13 Aug 2012 17:42:52 -0400

My position is:

- NETCONF and YANG do not need further churn
  - Churn discourages adoption
  - The "1.2" effort should be avoided
  - The needs of NETCONF are already very low
    - Lowering them is pointless
    - I've no sympathy for the argument that implementing
      a single global lock is too expensive
- Operational state is an unsolved problem
  - There is no single, simple way to represent this data
- SDN, IRS, and other related projects are looking at data
  that is neither config, nor operational data and we need
  to investigate their needs and find suitable means of modeling
  this data
- The above two items can be solved using extensions (no churn)

Thanks,
 Phil

---

From: Kent Watsen <[email-masked]>
Date: Mon, 13 Aug 2012 15:28:17 -0700

>      a single global lock is too expensive

Again, it's not an issue of it being difficult for the device team to
implement locking.  Since we're developing an off-box device-adapter, the
device-team doesn't even know there is a need.  I don't know why they
don't have a global lock, perhaps they think that only having
writable-running makes it safe enough, but it doesn't matter, our
device-adapter is *lying* about the device fully supporting NETCONF and
blindly returns <ok/> for lock/unlock.

Kent

---

From: Andy Bierman <[email-masked]>
Date: Mon, 13 Aug 2012 16:28:19 -0700

> blindly returns <ok/> for lock/unlock.

Implementation costs will vary greatly for individual features.
We really have to look at a feature and decide if the standard
really needs it to be robust and interoperable.

IMO, global locking meets this test.  It cannot be removed.
There are many known deadlock scenarios and other 'bad outcome'
operation sequences that cannot occur if locking is properly used.

Subtree filtering and edit-config may not meet this test,
but the alternate solutions are extremely inefficient.
These are the most popular features of NETCONF,
not some obscure unused operations.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 15 Aug 2012 22:33:22 +0200 (CEST)

Hi,

I agree that work needs to be done on the operational state problem
(and I plan to work on this and submit an individual I-D).

However, I think it might be too early to say if the solution to this
problem requires an update to NETCONF and/or YANG, or can be done
using only extensions.

I do not think the WG should do further modularization of the base
protocol.

/martin