Subject: [netmod] netconf/yang side meeting in paris on monday morning

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 19 Mar 2012 11:15:05 +0100

Hi,

a number of NETCONF / YANG contributors plan to meet on Monday morning
09:00-11:30 in order to informally discuss where we are with NETCONF
and YANG adoption and if there is any useful work that people find
valuable to spent their time on and which might be relevant from an
IETF perspective. Some topics that have popped up several times
include:

- REST interface to NETCONF/YANG
- Modeling operational state
- XPATH function library for YANG
- Issues with the candidate editing model

The goal of the meeting is to dive into a certain level of technical
depth to better understand the feasibility / complexity of potential
solutions. People who like to attend should thus be warned that this
meeting is not about high-level lets dream up something in the blue
sky discussions.

Note that this is an informal meeting. We plan to report in the AOB
part of the NETMOD or NETCONF meetings (likely the NETMOD meeting
since the NETCONF meeting is rather short).

We are trying to find a suitable room. I will post a pointer once we
have one. The fallback is to simply meet at the registration area.

/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: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 22 Mar 2012 18:38:50 +0100

> have one. The fallback is to simply meet at the registration area.

The room has been found: Room 237M is available on Monday, 26th
(0900-1130). Thanks to Dan for organizing the room.

/js

---

From: James Nguyen <[email-masked]>
Date: Thu, 22 Mar 2012 14:46:19 -0400

Hi Juergen,

Our team, US Army CERDEC, is currently working on improving NETCONF by
adding a common interface on top of it.  The current proposal is to use US
Naval Research Laboratory (NRL)'s NORM while REST over NETCONF is in
discussion.  Thus, I'm interested in listening the discussion of REST
interface to NETCONF/YANG.  Unfortunately, I won't be able to attend the
meeting in Paris.  Is there a conference bridge and time that I could dial
in?

Thanks,

James

On Mon, Mar 19, 2012 at 6:15 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

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

-- 
James Nguyen
Email: [email-masked]

---

From: Kent Watsen <[email-masked]>
Date: Mon, 26 Mar 2012 13:18:37 -0700

Having defined the standards and conventions for REST APIs at my company, I have a working understanding.  The fundamental question will be if the datastores are the "resources" on which PATCH is used or if the config hierarchy is mapped onto URL space.  The other key decisions will be how far we take HATEOAS and custom media-types...

Thanks,
Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Clemm (alex)
Sent: Monday, March 26, 2012 2:57 PM
To: Juergen Schoenwaelder; [email-masked]; [email-masked]
Subject: Re: [Netconf] netconf/yang side meeting in paris on monday morning

A significant topic from my perspective concerns the topic of REST.
Unfortunately I cannot be at IETF, but I just wanted to underscore /
express my support for this topic from remote.  This is also something I
would be willing to spend time and engage on.  

Kind regards
--- Alex

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Juergen Schoenwaelder
Sent: Thursday, March 22, 2012 10:39 AM
To: [email-masked]; [email-masked]
Subject: Re: [Netconf] netconf/yang side meeting in paris on monday
morning

/js

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Mar 2012 01:00:04 +0200

> Having defined the standards and conventions for REST APIs at my company, I have a working understanding.  The fundamental question will be if the datastores are the "resources" on which PATCH is u…

And your preferred answer to these questions is?

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Mar 2012 01:04:12 +0200

Hi, 

the meeting took place but we did not manage to cover all the topics
nor did we manage to explore all the details in the time we had
available. Anyway, I think it is good to have such discussions in
order to reflect where we are with NETCONF and where we might want to
go or where we might not want to go.

Attached are my meeting notes. They might be incomplete or even wrong.
Participants, feel free to send me updates and corrections.

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 26 Mar 2012 20:55:56 -0700

> Having defined the standards and conventions for REST APIs at my company, I have a working understanding.  The fundamental question will be if the datastores are the "resources" on which PATCH is u…

The top-level issue is "what problem are we trying to solve"?

IMO, NETCONF is so server-centric that application developers have too much
complexity punted their way.  Are we trying to pass all that complexity
to a WEB app?  Are we running NETCONF over HTTP or are we providing
consistent CRUD operations on a YANG-specified resource model?

The REST resource model has no concept of 'candidate config'
or 'copy-config from running to startup'.  Creation of a resource
is activated right away and no extra steps for persistence are expected.

There are many more issues than the mechanics of mapping CRUD operations
on a subset of the datastore.  IMO, fitting into the REST application
toolsets and 'world view' are just as important as the mechanics.

HTTP/REST is much better than NETCONF at separating meta-data and real data
(HEAD operation).  High level iterators (startPage=i, pageCount=N)
could be much more efficient than subtree or XPath filtering.

NETCONF <rpc-error> has much more info than HTTP error codes, which is a problem
that needs to be solved.

REST resource discovery is also interesting.  How does this interact
with NETCONF capability URIs?  Do we expect the WEB app to use :with-defaults,
or :partial-lock?  (IMO, just the YANG module capability URIs are mandatory.)

> Kent

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 27 Mar 2012 10:59:26 +0200

> consistent CRUD operations on a YANG-specified resource model?

I think a RESTful approach requires a different perspective, namely "model-view-controller". This could by the way also help resolve the issue of operational state versus configuration. Specifically:

- Model is a complete set of state parameters that determines the device behaviour, configured manually or 
  otherwise. This is the representational state in REST terms.

- View can be the contents of a get (or get-operational) reply, or an HTML rendering of the Model.

- The Controller part represents the procedures for changing the Model. For simple changes the HTTP methods 
  (PUT, POST, DELETE) can be used while complicated changes (e.g. adding a new OSPF adjacency) might require an 
  edit-config. 
> is activated right away and no extra steps for persistence are expected.

A (user-specific) candidate may be treated as a special View in which a sequence of edits performed by the user have been made. A commit then boils down to applying the same sequence of edits to the Model (atomically). With this approach, many of the issues concerning access control wouldn't exist - it would only be necessary to check whether the user has the permissions to perform all the edits.

> NETCONF <rpc-error> has much more info than HTTP error codes, which is a problem

IMO HTTP and NETCONF approaches are not mutually exclusive.

Lada

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

---

From: Kent Watsen <[email-masked]>
Date: Tue, 27 Mar 2012 09:34:32 -0700

> The top-level issue is "what problem are we trying to solve"?

Yes, this is the top-level question.

It seems to that there are 3 use-cases:

  1. off-box scripts
  2. off-box NMS apps
  3. on-box web interface

Did I miss any?

Considering these in turn:

  1. off-box scripts

        The API should be simple to use via a scripting language.
        HTTP is ubiquitous, every scripting language has built-in 
        support.  NETCONF API bindings can be provided, but they'll
        never be built into the language nor be as popular.

  2. off-box NMS apps

        The complexity of the API doesn't matter as much as the
        scalability and performance of the protocol.  NETCONF may
        have the edge here, though HTTP caching servers may make
        up for much of that.

  3. on-box web-interface

        Assuming the web-interface is AJAX/AJAJ, then a REST interface
        would be preferred - not only because the HTTP bindings are
        built into Javascript, but also because the client could use
        JSON and there would be no uncertainty for if the REST API is
        available, since it uses the same protocol as the web interface.

Thoughts?

Kent

---

From: Kent Watsen <[email-masked]>
Date: Tue, 27 Mar 2012 10:38:43 -0700

>And your preferred answer to these questions is?

Just thinking out loud.  We know that a YANG module can define config/state, RPCs, and notifications. From NETCONF, we know that the device can have config datastores and capabilities.  Lastly, from REST, we know that HTTP is the protocol (not NETCONF).

Given its simplicity, my preference would be to model each datastore as single resource (not a hierarchy of URLs).  For granular retrievals, I would use XPath with GET; for granular updates, I would use PATCH (RFC 5789) - this implies using ETags and If-Match.  For the PATCH document format, we could define one to be like the body of an <edit-confg> operation.  For RPCs, I would define "methods" (more on this later) and for notifications, I would define a long-poll (comet) interface.  Lastly, to support capabilities exchange, I would define RFC 6022's "netconf-state" as a top-level resource.

While I'm generally a proponent for custom media-types, I envision them as being more useful when defined by the vendor than IETF.  We might define a few like: datastore, netconf-state, and edit-config.  That said, "datastore" might be better identified as "application/json" and/or "application/xml", so the document can be defined in the vendor's namespace.

As for HATEOAS, I don't see the use-case for supporting clients that aren't explicitly programmed to know that they're connecting to a device.  Thus, I think that it's OK for us to assume the client knows about the /netconf-state and /<datastore> resources without having to discover them via the Host Metadata service (RFC 6415).  If we want something more elegant than returning 404 on /netconf-state, we could register a single <Link> element in the .well-known XDP for a "netconf" relation.

What do you think?

Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Mar 2012 20:11:08 +0200

> Given its simplicity, my preference would be to model each datastore as single resource (not a hierarchy of URLs).  For granular retrievals, I would use XPath with GET; for granular updates, I woul…

There is a JSON patch format
<http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-01> and it
would be nice to use that together with HTTP PATCH (RFC 5789) to do
modifications.
 
> As for HATEOAS, I don't see the use-case for supporting clients that aren't explicitly programmed to know that they're connecting to a device.  Thus, I think that it's OK for us to assume the clien…

I share the concern that exposing fine grained resources might be
cumbersome. But we would need to support filtered retrieval in some
way.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Mar 2012 20:21:53 +0200

>         available, since it uses the same protocol as the web interface.

But are all three use cases at the end not boiling down to the same
argument, namely the ubiquity of HTTP and JSON support?

For me, the question really is whether we are fine with NETCONF being
used as a well designed and optimized configuration protocol of bigger
networking gear or whether we want to reach out of that niche and seek
wider application on say constrained devices or as an interface to
network managers (that is software components that configure
collections of boxes to provide a certain service) etc. If we want to
reach out, then a REST interface is going to make a difference.

/js

---

From: Kent Watsen <[email-masked]>
Date: Tue, 27 Mar 2012 12:50:14 -0700

> There is a JSON patch format <http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-01> and it would be nice to use that together with HTTP PATCH (RFC 5789) to do modifications.

And the XML Patch format is defined in RFC 5261.  If we do this, we'd need to support both XML and JSON.

> we would need to support filtered retrieval in some way.

Following mimics the example given in RFC 6241 for the Xpath capability:

---Request--- (pretend I escaped the URL yuk)
GET /running?xmlns:t="http://example.com/schema/1.2/config"& select="/t:top/t:users/t:user[t:name='fred']" HTTP/1.1
Host: acme.company.com
Authorization: Basic xxxxxxxxxxxxxxxxxxx
Accept: application/xml; application/json

---Response---
HTTP/1.1 200 OK
Content-Type: application/xml
Content-Length: nnn
<?xml version="1.0">
<top xmlns="http://example.com/schema/1.2/config">
  <users>
    <user>
      <name>fred</name>
      <company-info>
        <id>2</id>
      </company-info>
    </user>
  </users>
</top>

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Mon, 26 Mar 2012 11:56:42 -0700

Kind regards
--- Alex

-----Original Message-----

/js