Subject: [Netconf] Netconf Charter update for approval

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Sat, 4 Jan 2014 12:36:49 +0000

Dear Benoit,

hope you had restful holidays.

Below is the charter proposal we prepared following the consensus calls and review of the draft charter text, basically adding to the WG item list point 3. for the joint server configuration data model and point 4. for RESTCONF.

We would like to ask you to initiate the re-chartering and the approval by the IESG. Thank you.

Bert & Mehmet

---------------

Network Configuration (netconf)
-------------------------------

 Charter

 Current Status: Active

 Chairs:
     Bert Wijnen <[email-masked]>
     Mehmet Ersue <[email-masked]>

 Operations and Management Area Directors:
     Benoit Claise <[email-masked]>
     Joel Jaeggli <[email-masked]>

 Operations and Management Area Advisor:
     Benoit Claise <[email-masked]>

 Mailing Lists:
     General Discussion: [email-masked]
     To Subscribe:       https://www.ietf.org/mailman/listinfo/netconf
     Archive:            http://www.ietf.org/mail-archive/web/netconf/

Description of Working Group:

  Configuration of networks of devices has become a critical requirement
  for operators in today's highly interconnected networks. Large and small
  operators alike have developed their own mechanisms or have used vendor
  specific mechanisms to transfer configuration data to and from a device
  and to examine device state information which may impact the
  configuration. Each of these mechanisms may be different in various
  aspects, such as session establishment, user authentication,
  configuration data exchange, and error responses.

  The NETCONF protocol has the following characteristics:

    - Provides retrieval mechanisms which can differentiate between
    configuration data and non-configuration data
    - Is extensible enough so that vendors can provide access to all
    configuration data on the device using a single protocol
    - Has a programmatic interface (avoids screen scraping and formatting-
    related changes between releases)
    - Uses an XML-based data representation, that can be easily manipulated
    using non-specialized XML manipulation tools.
    - Supports integration with existing user authentication methods
    - Supports integration with existing configuration database systems
    - Supports multiple (e.g. candidate and running) data-stores to optimize
    configuration preparation and activation
    - Supports network wide configuration transactions (with features such
    as locking and rollback capability)
   - Runs over a secure transport; SSH is mandatory to implement while TLS is an optional transport.
    - Provides support for asynchronous notifications.
    - Supports an Access Control Model and a YANG module for configuring the
    Access Control parameters.
    - Supports a YANG module for System Notifications

  The NETCONF protocol is data modeling language independent, but YANG is
  the recommended NETCONF modeling language, which introduces advanced
  language features for configuration management.

  Based on the implementation, deployment experience and interoperability
  testing, the WG aims to produce a NETCONF status report in a later stage.
  The result may be clarifications for RFC6241 and RFC6242 and addressing
  any reported errata.

  In the current phase of NETCONF's incremental development the workgroup
  will focus on following items:

  1. Develop the call home mechanism for the mandatory SSH binding (Reverse
  SSH) providing a server-initiated session establishment.

  2. Advance NETCONF over TLS to be in-line with NETCONF 1.1 (i.e., update
  RFC 5539) and add the call home mechanism to provide a server-initiated
  session establishment.

  3. Combine the server configuration data models from Reverse SSH and
  RFC5539bis drafts in a separate YANG module.

  4. Develop a RESTful interface (RESTCONF) for accessing YANG data using
  the datastores defined in NETCONF. The YANG patch operation will be prepared
  in a separate draft.

Goals and Milestones:
  Jan 2014 - Submit initial WG drafts for RESTCONF as WG item
  Apr 2014 - WGLC for RFC5539bis
  Apr 2014 - WGLC for Reverse SSH
  Apr 2014 - WGLC for NETCONF server configuration data model
  May 2014 - Submit Reverse SSH to AD/IESG for consideration as Proposed Standard
  May 2014 - Submit RFC5539bis to AD/IESG for consideration as Proposed Standard
  Jun 2014 - WGLC for RESTCONF drafts
  Aug 2014 - Submit RESTCONF to AD/IESG for consideration as Proposed Standard

---

From: Benoit Claise <[email-masked]>
Date: Mon, 13 Jan 2014 14:12:39 +0100

Dear all,

Sorry for the delay in getting back to you.

Today Bert, Mehmet, and I had a quick conf. call regarding the charter, 
and we made a few modifications.
You can follow up the temp charter text at 
http://datatracker.ietf.org/doc/charter-ietf-netconf/
Under the history tab, there is a very useful diff tool.
     The version 15, dated May 31st is the current official charter
     The version 15-06, dated Jan 10th, is the charter as proposed below 
in this email
     The version 15-11, dated today, is the charter after our discussion 
today.

As you can see from the diffs:
- we added the zero touch configuration document
- we tried to justify why the YANG patch document is needed
- we updated the milestones
- we added an important sentence regarding the RESTCONF/NETCONF alignment:
     RESTCONF should not deviate from NETCONF unless proper 
justifications is provided
     and documented.
- minor edits

Feedback?

I have two more points:

1. A question to which I've been receiving different answers from 
different persons: I understand that RESTCONF is an additional 
simplified interface that follows RESTful principles and is compatible 
with a resource-oriented device abstraction, but will RESTCONF be in 
line with the RFC 3535 section 3 requirements.
I understand that those requirements are for the communication between 
the NMS and the managed device. Hence my question during the last 
meeting opendaylight presentation: will RESTCONF be used as north bound 
interface only protocol, or also as a south bound interface. The answer 
was both: So we might have different (competing) solutions to managed 
devices.

2. HTTP2.0 is developed in the HTTPbis WG.
I see that draft-bierman-netconf-restconf is based on HTTP 1.1. Will it 
still work with HTTP2.0? Or is this completely orthogonal?
I've not been been following the HTTP2.0 developments, so I don't even 
know if this is a valid question, but I'm wondering if we should say 
something about the HTTP 2.0 compatibility in the charter?

Regards, Benoit
> Below is the charter proposal we prepared following the consensus 
> calls and review of the draft charter text, basically adding to the WG 
> item list point 3. for the joint server configuration data model and 
> point 4. for RESTCONF.

---

From: Kent Watsen <[email-masked]>
Date: Mon, 13 Jan 2014 17:30:25 +0000

Hi Benoit,

One comment regarding the charter, current phase item #2 says:  "Develop a zero touch configuration document, specific the NETCONF reverse SSH use case.".   I thought we were doing it both for NETCONF reverse-SSH and NETCONF reverse-TLS.  Is it ok to amend this statement to include reverse-TLS too?

Regarding RFC3535 section 3, the parts RESTCONF doesn't address (yet) are:

    #5.  Support for configuration transactions across a number of devices
           would significantly simplify network configuration management.

    #13. It is important to distinguish between the distribution of
             configurations and the activation of a certain configuration.
             Devices should be able to hold multiple configurations.

Is this an issue that needs to be addressed?

Regarding northbound vs southbound protocols and different/competing solutions to managed devices – I don't fully understand your concern.   How is an application (e.g. an NMS) presenting a RESTCONF interface causing a different or competing solution?   Are you thinking that the requirements might differ and, in our attempt to appease the app-folks, we somehow harm the solution for devices?   I personally don't see this as the case; having just re-read the RESTCONF –03 draft, it is very much aligned with NETCONF and therefore device-management.

Regarding HTTP1.1 vs 2.0, I believe that RESTCONF is completely orthogonal to HTTP and that which versions of HTTP it's compatible with doesn't need to be called out in the charter.  That said, you raise a good point that the RESTONF draft should be scrubbed so that it's clear that it's not specific to HTTP 1.1.

Thanks,
Kent

From: Benoit Claise <[email-masked]<mailto:[email-masked]>>
Date: Monday, January 13, 2014 8:12 AM
To: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]<mailto:[email-masked]>>
Cc: Pete Resnick <[email-masked]<mailto:[email-masked]>>, 'Barry Leiba' <[email-masked]<mailto:[email-masked]>>, NetConf <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] Netconf Charter update for approval

Dear all,

Today Bert, Mehmet, and I had a quick conf. call regarding the charter, and we made a few modifications.
You can follow up the temp charter text at http://datatracker.ietf.org/doc/charter-ietf-netconf/
Under the history tab, there is a very useful diff tool.
    The version 15, dated May 31st is the current official charter
    The version 15-06, dated Jan 10th, is the charter as proposed below in this email
    The version 15-11, dated today, is the charter after our discussion today.

    RESTCONF should not deviate from NETCONF unless proper justifications is provided
    and documented.
- minor edits

Feedback?

I have two more points:

1. A question to which I've been receiving different answers from different persons: I understand that RESTCONF is an additional simplified interface that follows RESTful principles and is compatible with a resource-oriented device abstraction, but will RESTCONF be in line with the RFC 3535 section 3 requirements.
I understand that those requirements are for the communication between the NMS and the managed device. Hence my question during the last meeting opendaylight presentation: will RESTCONF be used as north bound interface only protocol, or also as a south bound interface. The answer was both: So we might have different (competing) solutions to managed devices.

2. HTTP2.0 is developed in the HTTPbis WG.
I see that draft-bierman-netconf-restconf is based on HTTP 1.1. Will it still work with HTTP2.0? Or is this completely orthogonal?
I've not been been following the HTTP2.0 developments, so I don't even know if this is a valid question, but I'm wondering if we should say something about the HTTP 2.0 compatibility in the charter?

Regards, Benoit
Dear Benoit,

Bert & Mehmet

---------------

Charter

Current Status: Active

Chairs:
     Bert Wijnen <[email-masked]><mailto:[email-masked]>
     Mehmet Ersue <[email-masked]><mailto:[email-masked]>

Operations and Management Area Directors:
     Benoit Claise <[email-masked]><mailto:[email-masked]>
     Joel Jaeggli <[email-masked]><mailto:[email-masked]>

Operations and Management Area Advisor:
     Benoit Claise <[email-masked]><mailto:[email-masked]>

Mailing Lists:
     General Discussion: [email-masked]<mailto:[email-masked]>
     To Subscribe:       https://www.ietf.org/mailman/listinfo/netconf
     Archive:            http://www.ietf.org/mail-archive/web/netconf/

Goals and Milestones:

---

From: Barry Leiba <[email-masked]>
Date: Tue, 14 Jan 2014 10:31:00 -0500

Hi, all.
Just hitting the one App-related part:

> I've not been been following the HTTP2.0 developments, so I don't even know
> if this is a valid question, but I'm wondering if we should say something
> about the HTTP 2.0 compatibility in the charter?

I think there's no issue here.  First, http 2.0 won't be suitable for
all situations, and http 1.1 will be around and considered current for
a very long time yet.  Second, http 2.0 is being designed to be
protocol compatible with http 1.1.  Implementations will have to
change to use http 2.0, but those changes should involve code around
the edges, not at the core.  At the core, other protocols should not
have to change to become http-2.0-aware.

> hope you had restful holidays.

RESTful?  Hahahahaha......

Barry, Applications AD

---

From: Benoit Claise <[email-masked]>
Date: Tue, 14 Jan 2014 17:44:26 +0100

Hi Kent,
> Hi Benoit,
>
> One comment regarding the charter, current phase item #2 says: 
>  "Develop a zero touch configuration document, specific the NETCONF 
> reverse SSH use case.".   I thought we were doing it both for NETCONF 
> reverse-SSH and NETCONF reverse-TLS.  Is it ok to amend this statement 
> to include reverse-TLS too?
Updated. See http://datatracker.ietf.org/doc/charter-ietf-netconf/
> Is this an issue that needs to be addressed?
 From the charter "RESTCONF should not deviate from NETCONF unless 
proper justifications is provided and documented."
>
> Regarding northbound vs southbound protocols and different/competing 
> solutions to managed devices – I don't fully understand your concern. 
>   How is an application (e.g. an NMS) presenting a RESTCONF interface 
> causing a different or competing solution?   Are you thinking that the 
> requirements might differ and, in our attempt to appease the 
> app-folks, we somehow harm the solution for devices?   I personally 
> don't see this as the case; having just re-read the RESTCONF –03 
> draft, it is very much aligned with NETCONF and therefore 
> device-management.
I simply meant that, if RESTCONF would be used as a northbound protocol, 
and NETCONF as southbound protocol, the messaging would have been easier 
as RESTCONF and NETCONF would not be competent protocols.
>
> Regarding HTTP1.1 vs 2.0, I believe that RESTCONF is completely 
> orthogonal to HTTP and that which versions of HTTP it's compatible 
> with doesn't need to be called out in the charter.  That said, you 
> raise a good point that the RESTONF draft should be scrubbed so that 
> it's clear that it's not specific to HTTP 1.1.
Barry answered that. We're good.

Regards, Benoit
>
> Thanks,
> Kent
>
>
> From: Benoit Claise <[email-masked] <mailto:[email-masked]>>
> Cc: Pete Resnick <[email-masked] 
> <mailto:[email-masked]>>, 'Barry Leiba' 
> <[email-masked] <mailto:[email-masked]>>, NetConf 
> <[email-masked] <mailto:[email-masked]>>
> Today Bert, Mehmet, and I had a quick conf. call regarding the 
> charter, and we made a few modifications.
> meeting opendaylight presentation: will RESTCONF be used as north 
> bound interface only protocol, or also as a south bound interface. The 
> answer was both: So we might have different (competing) solutions to 
> managed devices.
>
> I see that draft-bierman-netconf-restconf is based on HTTP 1.1. Will 
> it still work with HTTP2.0? Or is this completely orthogonal?
>> calls and review of the draft charter text, basically adding to the 
>> WG item list point 3. for the joint server configuration data model 
>> and point 4. for RESTCONF.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 14 Jan 2014 09:20:18 -0800

Hi,

On Tue, Jan 14, 2014 at 8:44 AM, Benoit Claise <[email-masked]> wrote:

>  Hi Kent,
>
> Hi Benoit,
>
>  One comment regarding the charter, current phase item #2 says:  "Develop
> a zero touch configuration document, specific the NETCONF reverse SSH use
> case.".   I thought we were doing it both for NETCONF reverse-SSH and
> NETCONF reverse-TLS.  Is it ok to amend this statement to include
> reverse-TLS too?
>
> From the charter "RESTCONF should not deviate from NETCONF unless proper
> justifications is provided and documented."
>
>
>
I this this text is problematic.
The WG is not addressing #5 above at this time.

#13 requires interpretation. It could mean support for
named configurations and the ability to boot (or switch
at runtime) between them. NETCONF does not support that either.

IMO this "should not deviate" sentence needs to be replaced.
NETCONF has sessions and operations tuned for session-based management.
It takes up to 8 request/response pairs to accomplish 1 edit in NETCONF.
RESTCONF is going to deviate from that. RESTCONF imposes a resource
model on the content and NETCONF does not.

I think the intent is that the impact on a NETCONF server implementation
should be kept at a minimum.  No new features can be added that would
break a NETCONF client managing a dual NETCONF/RESTCONF server.

> solutions to managed devices – I don't fully understand your concern.   How
> is an application (e.g. an NMS) presenting a RESTCONF interface causing a
> different or competing solution?   Are you thinking that the requirements
> might differ and, in our attempt to appease the app-folks, we somehow harm
> the solution for devices?   I personally don't see this as the case; having
> just re-read the RESTCONF –03 draft, it is very much aligned with NETCONF
> and therefore device-management.
>
> and NETCONF as southbound protocol, the messaging would have been easier as
> RESTCONF and NETCONF would not be competent protocols.
>

Northbound vs. southbound is a very subjective distinction.
RESTCONF vs. NETCONF is a project-specific engineering
decision about tools, training, and how much device-specific
control the application really needs from the server(s).
IMO, YANG is the real difference maker. RESTCONF is
about getting HTTP app developers to use YANG, rather
than getting NETCONF app developers to use RESTCONF.

> orthogonal to HTTP and that which versions of HTTP it's compatible with
> doesn't need to be called out in the charter.  That said, you raise a good
> point that the RESTONF draft should be scrubbed so that it's clear that
> it's not specific to HTTP 1.1.
>
Thanks,
> Kent
Andy

---

From: Benoit Claise <[email-masked]>
Date: Tue, 21 Jan 2014 01:00:43 +0100

Andy,
> Hi,
>
>
> On Tue, Jan 14, 2014 at 8:44 AM, Benoit Claise <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Kent,
>>     Hi Benoit,
>>
>>      "Develop a zero touch configuration document, specific the
>>     NETCONF reverse SSH use case.".   I thought we were doing it both
>>     for NETCONF reverse-SSH and NETCONF reverse-TLS.  Is it ok to
>>     amend this statement to include reverse-TLS too?
I see at http://www.ietf.org/proceedings/88/minutes/minutes-88-netconf, 
under "**** RESTCONF (Andy)" some discussion about alignment
For example: "Mehmet: History: a new WG and a BOF was proposed. It is 
different from Netconf, but based on Netconf. Keep them aligned. "

Which alignment do we speak about here?

>>     Regarding northbound vs southbound protocols
>>     and different/competing solutions to managed devices – I don't
>>     fully understand your concern.   How is an application (e.g. an
>>     NMS) presenting a RESTCONF interface causing a different or
>>     competing solution?   Are you thinking that the requirements
>>     might differ and, in our attempt to appease the app-folks, we
>>     somehow harm the solution for devices?   I personally don't see
>>     this as the case; having just re-read the RESTCONF –03 draft, it
>>     is very much aligned with NETCONF and therefore device-management.
>     I simply meant that, if RESTCONF would be used as a northbound
>     protocol, and NETCONF as southbound protocol, the messaging would
>     have been easier as RESTCONF and NETCONF would not be competent
>     protocols.
>
>
>
What is actually the justification for RESTCONF?
Do we need RESTCONF for the HTTP tools or for the REST concepts?
I could not find any justification/problem statement in 
draft-bierman-netconf-restconf-03 
<https://datatracker.ietf.org/doc/draft-bierman-netconf-restconf/>

Regards, Benoit
>>     orthogonal to HTTP and that which versions of HTTP it's
>>     compatible with doesn't need to be called out in the charter.
>>      That said, you raise a good point that the RESTONF draft should
>>     be scrubbed so that it's clear that it's not specific to HTTP 1.1.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 20 Jan 2014 16:56:17 -0800

On Mon, Jan 20, 2014 at 4:00 PM, Benoit Claise <[email-masked]> wrote:

>> reverse-SSH and NETCONF reverse-TLS.  Is it ok to amend this statement to
>> include reverse-TLS too?
>>

The term "alignment" was used only generically in meetings so far.
My comment was on the phrase in the charter
"RESTCONF should not deviate from NETCONF".
What does that mean?  What would constitute a deviation from NETCONF
that should be avoided?

> draft-bierman-netconf-restconf-03<https://datatracker.ietf.org/doc/draft-bierman-netconf-restconf/>
>

There is text in sec. 1.
If you want to suggest a rewrite, that's fine.
HTTP tools that use REST concepts are needed.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 21 Jan 2014 08:27:37 +0100 (CET)

> > What is actually the justification for RESTCONF?

[...]

> HTTP tools that use REST concepts are needed.

I am not sure what this means.  IMO, RESTCONF in its current shape
really is about HTTP, not REST concepts.

/martin

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 21 Jan 2014 13:21:15 +0100

> really is about HTTP, not REST concepts.

+1

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 Jan 2014 13:25:52 +0100

> really is about HTTP, not REST concepts.

So, is this a bug or a feature? Where do you think does RESTCONF
depart from REST concepts?

/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: Martin Bjorklund <[email-masked]>
Date: Tue, 21 Jan 2014 13:33:15 +0100 (CET)

> depart from REST concepts?

Feature!  See section 1.2 of the draft.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 Jan 2014 13:53:10 +0100

> Feature!  See section 1.2 of the draft.

You may want to provide a pointer to what exactly you mean with
HATEOAS. I think it is useful to distinguish between having schema
controlled 'resources' you manipulate and schema controlled URI
namespaces.

It seems <draft-ietf-appsawg-uri-get-off-my-lawn-00> is arguing to be
cautious with the later. Will RESTCONF follow the recommendations
given in this ID or not?

I understand that you do not want excessive URI discovery overhead.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 21 Jan 2014 14:20:38 +0100 (CET)

> I understand that you do not want excessive URI discovery overhead.

It seems to me that draft-ietf-appsawg-uri-get-off-my-lawn-00 requires
us to use URI discovery.  If this is a firm requirement on a protocol
developed in the IETF, I think we should not do RESTCONF at all.  The
whole point of RESTCONF is to have a "quick" and "simple" interface.
URI discovery puts an enormous burden on the client.

Maybe it would be a good idea to get this design "approved" before we
spend more time on this protocol.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 Jan 2014 14:31:59 +0100

> spend more time on this protocol.

I believe what is indeed called for here is an early review of this
work by apps area experts. It is not about 'approving' this work, it
is about making sure that we get good technical advice on the design
of the protocol (and of course to avoid late surprises). In other
words, I think we should try to find ways to work in a positive and
constructive spirit with apps area experts here.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 21 Jan 2014 14:41:30 +0100 (CET)

> constructive spirit with apps area experts here.

Absolutely.  How do we get this review?  Do we do that *before*
charter update?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 Jan 2014 15:00:06 +0100

> Absolutely.  How do we get this review?  Do we do that *before*

This is something for the chairs to figure out. There is also the
formal role of a 'technical advisor'. But what we need is a serious
technical review, establishing a 'technical advisor' may be a means
for this but there might be other ways of getting the input.

/js

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 21 Jan 2014 15:51:57 +0100

I am sure we can ask for an early technical review from the APSS
area. Let us do that as soon as we have the charter approved and
our forst WG document oin this space.

Bert (my opinion, I have not checked with my co-chair yet)

---

From: Andy Bierman <[email-masked]>
Date: Tue, 21 Jan 2014 07:10:27 -0800

> I understand that you do not want excessive URI discovery overhead.
It depends on the interpretation of this text in sec 2.3:

   Scheme definitions define the presence, format, and semantics of a
   path component in URIs; all other specifications MUST NOT constrain,
   define structure or semantics for any path component.

IMO RESTCONF does not really impose structure -- it maps arbitrary URI
paths to
YANG statements.  For any possible URI value, a YANG module could be
defined which would map to the arbitrary URI.  The RESTCONF server
implementation
only supports a subset of all possible URIs, just like a regular WEB server.

Ad-hoc APIs (e.g. OpenStack) put constraints on the structure of a
particular URI
when attempting to accomplish a specific task.  RESTCONF is just documenting
data model constraints with YANG instead of ad-hoc examples.

HATEOAS and URI discovery does not scale to the level of complexity that
our customers need to model and manage networking devices.  It is impossible
for the applications to do useful work with these complex models by
discovering
them on the fly.  Instead, the API contract is carefully documented in YANG,
and applications are designed and coded in advance to work with specific
YANG modules.

/js

Andy

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Tue, 21 Jan 2014 16:39:38 +0000

I agree that a review is a good idea.  However, a question is also about the goal, and the earlier question whether the incorporation of additional features and is a bug or a feature.  Basically, is the goal is to have the same Netconf operations/ functionality over HTTP , or an interface based on ReST concepts that is geared towards Web developers.  Personally, I find the value proposition of the latter more compelling than the former.  

I liked the original charter wording to that regards better (before the addition of "RESTCONF should not deviate from NETCONF unless proper justifications is provided and documented"), but either way it will be good to be clear on the goals and who the intended target audience is. 

--- Alex 

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Tuesday, January 21, 2014 6:00 AM
To: Martin Bjorklund
Cc: [email-masked]
Subject: Re: [Netconf] Netconf Charter update for approval

On Tue, Jan 21, 2014 at 02:41:30PM +0100, Martin Bjorklund wrote:
> > > > It seems <draft-ietf-appsawg-uri-get-off-my-lawn-00> is arguing 
> > > > to be cautious with the later. Will RESTCONF follow the 
> > > > recommendations given in this ID or not?
> > > > 
> > > It seems to me that draft-ietf-appsawg-uri-get-off-my-lawn-00 
> > > requires us to use URI discovery.  If this is a firm requirement 
> > > on a protocol developed in the IETF, I think we should not do 
> > > RESTCONF at all.  The whole point of RESTCONF is to have a "quick" and "simple" interface.
> > > Maybe it would be a good idea to get this design "approved" before 
> > > we spend more time on this protocol.
> > > 
> > 

This is something for the chairs to figure out. There is also the formal role of a 'technical advisor'. But what we need is a serious technical review, establishing a 'technical advisor' may be a means for this but there might be other ways of getting the input.

/js

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 22 Jan 2014 10:49:27 +0100

On 21 January 2014 16:10, Andy Bierman <[email-masked]> wrote:
>
>
>
> On Tue, Jan 21, 2014 at 4:53 AM, Juergen Schoenwaelder
> <[email-masked]> wrote:
>>
> IMO RESTCONF does not really impose structure -- it maps arbitrary URI paths
> to

Can we have some insight as to how that conclusion has been arrived
at? The REST (HATEOAS) pattern is found to work rather well in many
large scale web environments, often with much bigger scale than in
network device config CRUD...
In any case, based on the above, this work perhaps should refrain from
using the REST term as intended (and voiced) by the author of REST?

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

HTTPConf may be better...

/Wojciech.

---

From: Andy Bierman <[email-masked]>
Date: Wed, 22 Jan 2014 02:44:56 -0800

On Wed, Jan 22, 2014 at 1:49 AM, Wojciech Dec <[email-masked]> wrote:

> >> > > > > On Mon, Jan 20, 2014 at 4:00 PM, Benoit Claise <
> [email-masked]>
> >> > > > > wrote:
> paths
Simplistic data models may work OK with this approach.
It has been pointed out that YANG constraints do not
align with trivial classifications (such as all leafs are mandatory
and all lists are optional sub-resources).  There is no value
in pretending that an application that ignores YANG
is something worth supporting with this protocol.

> HTTPConf may be better...

I don't care what it is called.

Andy

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Wed, 22 Jan 2014 13:44:49 +0100

Inline

> model on the content and NETCONF does not.

Andy, the example you give here is easy to defend. I see it as
an improvement and not so much as a deviation.

But even if we (anyone) see(s) it as a deviation, then I think it is easy
enough to point it out and justify it.

So I see no issue with the text as in the latest charter proposal.

The chairs and AD agree that this is not an issue if put into the charter.
It avoids controversial discussion in the future but simplifies further decisions

I believe we have WG consensus to move forward and get the charter approved by IESG.

Bert

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 22 Jan 2014 13:22:58 +0000

One of the solutions we discussed in Vancouver was to invite an APPS person as co-author for the RESTCONF draft, which would be indeed very useful for the development.

Cheers, 
Mehmet 

> From: Netconf [mailto:[email-masked]] On Behalf Of ext Bert
> Wijnen (IETF)
> Sent: Tuesday, January 21, 2014 3:52 PM
> To: Martin Bjorklund; [email-masked]; [email-masked]
> to be
> requires

---

From: Benoit Claise <[email-masked]>
Date: Wed, 22 Jan 2014 14:40:08 +0100

Dear all,

I believe I finally see a source of confusion.
The proposal was: "RESTCONF should not deviate from NETCONF unless 
proper justifications is provided and documented"
What was meant: "RESTCONF should not deviate from the _NETCONF 
capabilities_unless proper justification is
provided and documented"

Sure there are constraints related to REST and HTTP, but this sentence 
is not really meant to discuss "8 request/response pairs to accomplish 1 
edit in NETCONF versus a different number in RESTCONF". However, this 
sentence is valid for a feature such as locking, if not provided by 
RESTCONF.

Regards, Benoit
> .

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 22 Jan 2014 15:14:06 +0100

On 22 January 2014 14:40, Benoit Claise <[email-masked]> wrote:
> The proposal was: "RESTCONF should not deviate from NETCONF unless proper
> justifications is provided and documented"
> What was meant: "RESTCONF should not deviate from the NETCONF capabilities
> unless proper justification is
> provided and documented"
>
> Sure there are constraints related to REST and HTTP, but this sentence is
> not really meant to discuss "8 request/response pairs to accomplish 1 edit
> in NETCONF versus a different number in RESTCONF".  However, this sentence
> is valid for a feature such as locking, if not provided by RESTCONF.

That is one item.
The other is "REST" or "RESTful". As noted on this thread, the
motivation is really HTTP rather than REST design (at least as
intended by those that coined the REST term). Accordingly, and to
perhaps further lengthy discussions of hoe "RESTful" is the document
or not, the charter should actually reflect that it is development of
an "HTTP based interface".

-Wojciech.

---

From: Andy Bierman <[email-masked]>
Date: Wed, 22 Jan 2014 07:20:20 -0800

> an "HTTP based interface".

We certainly need to reach consensus on the protocol mechanics and design
assumptions.
The content semantics and syntax are fully described by YANG. I agree with
Kent that
we are trying to allow YANG-aware applications to manage a device with HTTP.
Maybe we had it right calling this YANG-API instead of RESTCONF.

The authors discussed "RESTful features" such as returning a full URL _self
link in
every node that is retrieved.  This increases payload sizes by about 10X,
so we did not add that. We could also give every single data node its own
resource type (and maybe not bother with YANG?).  Then an app can look
up the hard-wired code to handle the "interfaces.interface.if-type"
resource type, etc.

Can you point me to any REST-ful CM solutions that use models at least as
complicated as the ietf-routing-cfg.yang module? Vendors are actually
designing
YANG modules for RESTCONF even more complicated than this module,
We want to make sure we do not design a solution that works well with
"Hello world"
but cannot be used to manage a real router.

-Wojciech.
Andy

> > I believe we have WG consensus to move forward and get the charter
> approved
> > by IESG.
> >
> > Bert
> > .
> >
> >
> >

---

From: Kent Watsen <[email-masked]>
Date: Thu, 23 Jan 2014 17:59:18 +0000

> assumptions.  The content semantics and syntax are fully described by YANG.
> I agree with Kent that we are trying to allow YANG-aware applications to
> manage a device with HTTP.  Maybe we had it right calling this YANG-API
> instead of RESTCONF.

I'm ok to renaming RESTCONF if the apps-people agree that it's best.  HTTPConf or whatever is fine by me.  I wouldn't want to call it YANG-API, though, because it's not descriptive enough; for instance, one could easily say that YANG-API == NETCONF (not RESTCONF)...

Kent

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 23 Jan 2014 18:05:33 +0000

I as a technical contributor would suggest to let it as is, namely RESTConf.

A lot of folks in and outside of IETF know it already under this title.
And obviously we are the only ones who are questioning it.

Cheers,
Mehmet

From: Netconf [mailto:[email-masked]] On Behalf Of ext Kent Watsen
Sent: Thursday, January 23, 2014 6:59 PM
To: Andy Bierman; Wojciech Dec
Cc: Netconf
Subject: Re: [Netconf] Netconf Charter update for approval

Kent

---

From: Andy Bierman <[email-masked]>
Date: Thu, 23 Jan 2014 10:38:26 -0800

> And obviously we are the only ones who are questioning it.

There is a fundamental design difference with RESTCONF that seems
to be perceived as not REST-ful.  With data-model driven solutions
like RESTCONF, NETCONF, or SNMP, there is no point is sending
redundant schema information over the wire in the protocol. All the
semantics and validation rules are in the schema, and both client
and server are expected to have access to the same schema definitions.
This is done because the data model API contract is far too complex to
discover or express on the fly.  Applications need to be designed and coded
to the API contract in advance.

 Cheers,

Andy

>
>
> *From:* Netconf [mailto:[email-masked]] *On Behalf Of *ext Kent
> Watsen
> *Sent:* Thursday, January 23, 2014 6:59 PM
> *To:* Andy Bierman; Wojciech Dec
> *Cc:* Netconf
> *Subject:* Re: [Netconf] Netconf Charter update for approval
>
>
>
>
>
>
>
> I'm ok to renaming RESTCONF if the apps-people agree that it's best.
>  HTTPConf or whatever is fine by me.  I wouldn't want to call it YANG-API,
> though, because it's not descriptive enough; for instance, one could easily
> say that YANG-API == NETCONF (not RESTCONF)...
>
>
>
> Kent
>
>
>

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 24 Jan 2014 10:13:29 +0100

> A lot of folks in and outside of IETF know it already under this title.

There is of course plenty of precedent for renaming and rescoping of
individual drafts and protocols...
Having been in a fair bit of "what's REST and what's not" discussions
that sap time, I would suggest that going easy on describing the
protocol scope with the term REST and RESTful is advisable. Of course
none of this means that some of REST style cannot apply.
An analogy from the IETF networking world: a few years ago some other
body took to defining MPLS-TP, which then had little to do with MPLS
as known at the IETF... Generally that was a hassle to deal with for
all concerned...

> And obviously we are the only ones who are questioning it.

Yes, and I suppose that is so because we are having a WG discussion.

Cheers,

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 24 Jan 2014 10:37:43 +0100

On 23 January 2014 19:38, Andy Bierman <[email-masked]> wrote:
>
>
>
> On Thu, Jan 23, 2014 at 10:05 AM, Ersue, Mehmet (NSN - DE/Munich)

There is another REST derived constraint that, I'm not sure lines up
with what is being scoped here in terms of Netconf functional
equivalence: It is considered un RESTful for a server to  to retain
any client specific server context state. This would apply to resource
locking (aka transactions) and also client event subscriptions.

-W.

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 24 Jan 2014 10:41:28 +0100 (CET)

Wojciech Dec <[email-masked]> wrote:
> locking (aka transactions)

Can you be more specific?  AFAICT there are no such things in the
draft (anymore).

> and also client event subscriptions.

Ok.

/martin

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 24 Jan 2014 11:22:28 +0100

> Can you be more specific?  AFAICT there are no such things in the

I'm not saying that it is there, but as per previous posts on this
thread, maybe resource locking should be there. I.e. "RESTCONF should
not deviate from the NETCONF capabilities unless proper justification
is provided and documented" .
To me it appears that REST style is not a key requirement here, but rather HTTP.

-W.

---

From: Andy Bierman <[email-masked]>
Date: Fri, 24 Jan 2014 03:03:50 -0800

> To me it appears that REST style is not a key requirement here, but rather

I think the NETCONF WG is very likely to create NETCONF over HTTP,
and it will end up just as bloated and over-engineered as NETCONF over SSH.
I hope the temptation to expose all server complexity to the client
is resisted. IMO it would be better to keep the RESTCONF API unified,
rather than forcing the client to deal with all the server options in
NETCONF.
IMO these REST purity tests are a waste of time.

Andy

---

From: Benoit Claise <[email-masked]>
Date: Fri, 24 Jan 2014 15:40:31 +0100

Dear all,

[Taking the last email in the thread.]

The current proposed charter says:

    5. Develop a_RESTful interface_  (RESTCONF) for accessing YANG data using the
    datastores defined in NETCONF.

draft-bierman-netconf-restconf says:

       RESTCONF Protocol

    Abstract

        This document describes a_RESTful protocol_  that provides a
        programmatic interface over HTTP for accessing data defined in YANG,
        using the datastores defined in NETCONF.

Considering that ...
     1. The motivation is really HTTP rather than REST design
     2. Some REST principles are not respected
... this should be reflected in the charter (and as a consequence in the 
draft)

The way I now understand RESTCONF is:
RESTCONF =  a protocol almost similar to NETCONF in terms of 
capabilities, to access YANG modules over HTTP, with _some _REST 
characteristics.

If this is the case, both the proposed charter and the draft abstract 
are misleading.
This should be corrected.

Regards, Benoit
>
>
>
> On Fri, Jan 24, 2014 at 2:22 AM, Wojciech Dec <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On 24 January 2014 10:41, Martin Bjorklund <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > Wojciech Dec <[email-masked] <mailto:[email-masked]>>
>     wrote:

---

From: Andy Bierman <[email-masked]>
Date: Fri, 24 Jan 2014 07:40:55 -0800

On Fri, Jan 24, 2014 at 6:40 AM, Benoit Claise <[email-masked]> wrote:

> 5. Develop a *RESTful interface* (RESTCONF) for accessing YANG data using the
>    This document describes a *RESTful protocol* that provides a
> capabilities, to access YANG modules over HTTP, with *some *REST
> characteristics.
>
> If this is the case, both the proposed charter and the draft abstract are
> misleading.

IMO the term "RESTful" is used just as consistently here as in other
solutions.
(E.g., are there any HATEOAS mechanisms in OpenStack? Seems to me a
client needs to know all the ad-hoc docs to know the resource model. It is
not discovered inline at all).

We could downgrade the term to "REST-like"?  Would that make the purists
happy?
We could call the protocol RESTLESS. Would that help? ;-)

Andy

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

---

From: Benoit Claise <[email-masked]>
Date: Fri, 24 Jan 2014 16:53:53 +0100

Andy,

You have to understand one part of my job, as OPS AD: defending your 
work in front the IESG, whether this is at the charter time, or at the 
document approval time.
So I'm trying to see which questions will arise. I would hate it if 
somebody would say in a year from now: "hey, you're not actually 
defining a RESTful as specified in your charter. RESTful is specified 
according to principles XYZ, you're not compliant, you're out.

Personally, I'm not married to any marketing names.

Regards, Benoit

>
>
>
> On Fri, Jan 24, 2014 at 6:40 AM, Benoit Claise <[email-masked] 
>     ... this should be reflected in the charter (and as a consequence
>     in the draft)
>
>     If this is the case, both the proposed charter and the draft
>     abstract are misleading.
> We could downgrade the term to "REST-like"?  Would that make the 
> purists happy?
>>     On Fri, Jan 24, 2014 at 2:22 AM, Wojciech Dec
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         > Wojciech Dec <[email-masked]
>>     rather than forcing the client to deal with all the server
>>     options in NETCONF.
>>     [email-masked]  <mailto:[email-masked]>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 24 Jan 2014 08:08:43 -0800

Hi,

I understand.
However, when it was called YANG-API, many people commented
"Why isn't it called RESTCONF? You are doing REST"

IMO, all REST will use schema-based content eventually.
There seems to be a growing realization that hand-crafted code
based on ad-hoc API documentation is not as desirable as
auto-generated code based on an easy-to-use schema language.

So what is the new name if RESTCONF is out?

Andy

On Fri, Jan 24, 2014 at 7:53 AM, Benoit Claise <[email-masked]> wrote:

>  Andy,
>
> You have to understand one part of my job, as OPS AD: defending your work
> in front the IESG, whether this is at the charter time, or at the document
> approval time.
> somebody would say in a year from now: "hey, you're not actually defining a
> RESTful as specified in your charter. RESTful is specified according to
> principles XYZ, you're not compliant, you're out.
>
>> On Fri, Jan 24, 2014 at 2:22 AM, Wojciech Dec <[email-masked]>wrote:
>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 24 Jan 2014 18:21:12 +0100

> We could downgrade the term to "REST-like"?  Would that make the

I would indeed find that more appropriate.

/js

---

From: Kent Watsen <[email-masked]>
Date: Fri, 24 Jan 2014 17:25:02 +0000

>I would indeed find that more appropriate.

+1 if only to help put this to rest   - get it, rest  ;)

K.

---

From: Andy Bierman <[email-masked]>
Date: Fri, 24 Jan 2014 10:03:27 -0800

> +1 if only to help put this to rest   - get it, rest  ;)
I updated the draft in the SVN repo -- s/RESTful/REST-like/

K.
Andy

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Fri, 24 Jan 2014 18:40:54 +0000

Rereading the charter again, I have one question re  the 5th bullet point, specifically "and also allow more precise client control of the transaction procedure than existing mechanisms"

What is meant by that? "Existing mechanisms" presumably refers to Netconf - why not call it out?  "More precise client control" - does this mean additional capabilities not provided by Netconf - i.e. not ReST, not Netconf Lite, but actually Netconf++ / Heavy?  I don't think this is what is meant, and it does mean in fact "lighter than Netconf, with more responsibilities to control transactions (if that is needed) shifted to clients".  However, it could be interpreted this way, and is ambiguous.  The goals of RESTconf, not very clear to begin with (address different community of (Web) developers?  Add another transport to Netconf operations?  Provide a subset of services for lighterweight agent implementations in more constrained environments?) gets obscured a little further.  I would suggest rephrasing to clarify and disambiguate.

--- Alex

From: Netconf [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Friday, January 24, 2014 10:03 AM
To: Kent Watsen
Cc: Netconf
Subject: Re: [Netconf] Netconf Charter update for approval

On Fri, Jan 24, 2014 at 9:25 AM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:

K.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 24 Jan 2014 11:45:46 -0800

Hi,

On Fri, Jan 24, 2014 at 10:40 AM, Alexander Clemm (alex) <[email-masked]>wrote:

>  Rereading the charter again, I have one question re  the 5th bullet point, specifically “and also allow more precise client control of the transaction procedure than existing mechanisms”
>
>
>
> What is meant by that? “Existing mechanisms” presumably refers to Netconf – why not call it out?  “More precise client control” – does this mean additional capabilities not provided by Netconf – i.e. not ReST, not Netconf Lite, but actually Netconf++ / Heavy?  I don’t think this is what is meant, and it does mean in fact “lighter than Netconf, with more responsibilities to control transactions (if that is needed) shifted to clients”.  However, it could be interpreted this way, and is ambiguous.  The goals of RESTconf, not very clear to begin with (address different community of (Web) developers?  Add another transport to Netconf operations?  Provide a subset of services for lighterweight agent implementations in more constrained environments?) gets obscured a little further.  I would suggest rephrasing to clarify and disambiguate.
>
>
>
>
This might refer to YANG Patch. It has:
   * an explicit operation for "move" that do not require
     a clone of the entire subtree being moved.
   * an ordered list of edits.  NETCONF <config> subtrees can
     be processed in any order by the server.

RESTCONF has:
   * if-match entity-matching to help prevent edit collision problems

I hope NETCONF-EX will be standardized so NETCONF will also
 have these features.

 --- Alex
Andy

---

From: Benoit Claise <[email-masked]>
Date: Mon, 27 Jan 2014 11:14:52 +0100

> So what is the new name if RESTCONF is out?
Personally, I have no problem with the RESTCONF name, as long as we make 
clear in charter and drafts, stressing "some"

Regards, Benoit

>
>
> Andy
>
>
>
>
>
> On Fri, Jan 24, 2014 at 7:53 AM, Benoit Claise <[email-masked] 
>     You have to understand one part of my job, as OPS AD: defending
>     your work in front the IESG, whether this is at the charter time,
>     or at the document approval time.
>     So I'm trying to see which questions will arise. I would hate it
>     if somebody would say in a year from now: "hey, you're not
>     actually defining a RESTful as specified in your charter. RESTful
>     is specified according to principles XYZ, you're not compliant,
>     you're out.
>
>>         ... this should be reflected in the charter (and as a
>>         consequence in the draft)
>>
>>         capabilities, to access YANG modules over HTTP, with _some
>>         _REST characteristics.
>>
>>     IMO the term "RESTful" is used just as consistently here as in
>>     other solutions.
>>>             On 24 January 2014 10:41, Martin Bjorklund
>>>             <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Andy Bierman <[email-masked]>
Date: Mon, 27 Jan 2014 08:45:05 -0800

On Mon, Jan 27, 2014 at 2:14 AM, Benoit Claise <[email-masked]> wrote:

> RESTCONF =  a protocol almost similar to NETCONF in terms of capabilities,
> to access YANG modules over HTTP, with *some *REST characteristics.
>
>

OK with me.

It occurred to me that we have already done some "NETCONF alignment",
such as removing the "optional-key" YANG extension.  It may be RESTful
to have the server control all the key values, but NETCONF does not support
it.
IMO, arbitrary keys are useful sometimes, but they are extremely
inefficient.
With YANG it is up to the designer whether list keys have any semantics.

Andy