Subject: [Netconf] Verifing session consensus on RESTCONF as WG item with the maillist

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Sun, 24 Nov 2013 14:16:36 +0000

Dear Netconf WG,

in the Netconf session during IETF #88 we discussed the RESTCONF protocol and whether it should be developed in the Netconf WG. There were around 60 participants in the room.
The authors of the RESTCONF draft do not want to create a protocol which competes with NETCONF and it is seen as beneficial if NETCONF and RESTCONF are developed in parallel and aligned with each other. There are obviously different projects outside of IETF (e.g. OpenDaylight and other MANET oriented projects) which use RESTCONF. The opinion poll showed that there is a huge support of the people in the room (and nobody against) to develop the RESTCONF protocol in the Netconf WG. As a result of the discussion with the AD, the WG chairs got the action to prepare a charter update and adopt RESTCONF as the new WG item.

Though before we do this, the chairs need to verify the consensus in the session with the maillist.

Following text is proposed to use for the charter update:
"  3. Develop a RESTful protocol (RESTCONF) that provides a programmatic interface for accessing data defined in YANG, using the datastores defined in NETCONF. The three parts concerning RESTCONF protocol, the transport binding over HTTP and the YANG patch operation will be prepared modular and in separate drafts. This enables to add a new transport binding at a later stage."

Please state your opinion on this step forward.
If you have strong objections against please state your substantial and convincing arguments.

This consensus call will close on December 4, 2013 EOB PT.

Mehmet & Bert

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Sun, 24 Nov 2013 19:04:20 +0000

I support RESTCONF as a new deliverable.  RESTCONF is an very important part of Opendaylight Northbound Interface.

From: <Ersue>, "Mehmet (NSN - DE/Munich)" <[email-masked]<mailto:[email-masked]>>
Date: Sunday, November 24, 2013 at 6:16 AM
To: Netconf <[email-masked]<mailto:[email-masked]>>
Subject: [Netconf] Verifing session consensus on RESTCONF as WG item with the maillist

Dear Netconf WG,

Following text is proposed to use for the charter update:
“  3. Develop a RESTful protocol (RESTCONF) that provides a programmatic interface for accessing data defined in YANG, using the datastores defined in NETCONF. The three parts concerning RESTCONF protocol, the transport binding over HTTP and the YANG patch operation will be prepared modular and in separate drafts. This enables to add a new transport binding at a later stage.”

Mehmet & Bert

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 24 Nov 2013 14:54:44 -0500

Is there somewhere I can read a description of what problems with using 
NetConf are addressed by using RestConf?  It would be helpful to 
understand the problem beyond "some folks are doing this" before 
supporting or opposing the work item.

Thank you,
Joel

On 11/24/13 2:04 PM, Reinaldo Penno (repenno) wrote:
> I support RESTCONF as a new deliverable.  RESTCONF is an very important
> part of Opendaylight Northbound Interface.
>
> To: Netconf <[email-masked] <mailto:[email-masked]>>
> in the Netconf session during IETF #88 we discussed the RESTCONF
> protocol and whether it should be developed in the Netconf WG. There
> were around 60 participants in the room.
> The authors of the RESTCONF draft do not want to create a protocol which
> competes with NETCONF and it is seen as beneficial if NETCONF and
> RESTCONF are developed in parallel and aligned with each other. There
> are obviously different projects outside of IETF (e.g. OpenDaylight and
> other MANET oriented projects) which use RESTCONF. The opinion poll
> showed that there is a huge support of the people in the room (and
> nobody against) to develop the RESTCONF protocol in the Netconf WG. As a
> result of the discussion with the AD, the WG chairs got the action to
> prepare a charter update and adopt RESTCONF as the new WG item.
> “  3. Develop a RESTful protocol (RESTCONF) that provides a programmatic
> interface for accessing data defined in YANG, using the datastores
> defined in NETCONF. The three parts concerning RESTCONF protocol, the
> transport binding over HTTP and the YANG patch operation will be
> prepared modular and in separate drafts. This enables to add a new
> transport binding at a later stage.”
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Andy Bierman <[email-masked]>
Date: Sun, 24 Nov 2013 12:39:40 -0800

Hi,

Sec. 1.1 of draft-bierman-netconf-restconf-02.txt has some text.

I will start a list to throw darts at:
  - NETCONF does not have a resource management model
  - NETCONF is session-based, and even some simple management tasks require
    several request/response pairs to complete
  - NETCONF allows a lot of server variance instead of a unified abstraction
    of the local configuration. This complicates management code.
  - Many more client tools are available for HTTP/REST than NETCONF/SSH
  - JSON is widely deployed and more efficient than XML

Andy

On Sun, Nov 24, 2013 at 11:54 AM, Joel M. Halpern <[email-masked]>wrote:

> NetConf are addressed by using RestConf?  It would be helpful to understand
> the problem beyond "some folks are doing this" before supporting or
> opposing the work item.
>
> Thank you,
> Joel
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 25 Nov 2013 10:15:10 +0100

> "  3. Develop a RESTful protocol (RESTCONF) that provides a programmatic interface for accessing data defined in YANG, using the datastores defined in NETCONF. The three parts concerning RESTCONF p…

Technical question:

I do wonder how you can separate the HTTP transport binding out of a
RESTful protocol without making the specification rather complicated
to read and understand. After all, you will make assumptions about
what HTTP provides in many places (e.g. what is carried in HTTP
message headers or HTTP mechanisms like etags are used). Is there an
example somewhere I can look at to understand what this separation is
going to look like? And which problem are we solving by separating
this out?

/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: Ladislav Lhotka <[email-masked]>
Date: Mon, 25 Nov 2013 10:33:26 +0100

> going to look like? And which problem are we solving by separating

Indeed, and also the use of HTTP methods is crucial.

IMO, what makes sense is to factor out YANG Patch because, in principle, other patch formats (media types) may be supported instead/in parallel.

Lada

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 25 Nov 2013 01:45:44 -0800

On Mon, Nov 25, 2013 at 1:33 AM, Ladislav Lhotka <[email-masked]> wrote:

>
> On 25 Nov 2013, at 10:15, Juergen Schoenwaelder <
> [email-masked]> wrote:
>
> >> "  3. Develop a RESTful protocol (RESTCONF) that provides a
> programmatic interface for accessing data defined in YANG, using the
> datastores defined in NETCONF. The three parts concerning RESTCONF
> protocol, the transport binding over HTTP and the YANG patch operation will
> be prepared modular and in separate drafts. This enables to add a new
> transport binding at a later stage."
> >>
> >
> > Technical question:
> >
I agree.
Just emailed Martin about this -- splitting out the HTTP bits may
not be practical or required.  More likely, the set of
mandatory-to-implement
features would be smaller for constrained devices.

> IMO, what makes sense is to factor out YANG Patch because, in principle,
> other patch formats (media types) may be supported instead/in parallel.
>
> Lada
>
> >
> > /js
>

Andy