Subject: [Netconf] Fwd: I-D Action: draft-bierman-netconf-restconf-04.txt

From: Andy Bierman <[email-masked]>
Date: Thu, 13 Feb 2014 14:12:37 -0800

FYI,

A new version of the RESTCONF draft has been posted.
There were only minor clarifications and bug-fixes done.
See Appendix A.1 for details on the changes.

Andy

---------- Forwarded message ----------
From: <[email-masked]>
Date: Thu, Feb 13, 2014 at 2:10 PM
Subject: I-D Action: draft-bierman-netconf-restconf-04.txt
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : RESTCONF Protocol
        Authors         : Andy Bierman
                          Martin Bjorklund
                          Kent Watsen
                          Rex Fernando
        Filename        : draft-bierman-netconf-restconf-04.txt
        Pages           : 96
        Date            : 2014-02-13

Abstract:
   This document describes a REST-like protocol that provides a
   programmatic interface over HTTP for accessing data defined in YANG,
   using the datastores defined in NETCONF.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bierman-netconf-restconf/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bierman-netconf-restconf-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-bierman-netconf-restconf-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Yi Yang (yiya)" <[email-masked]>
Date: Tue, 25 Feb 2014 19:41:18 +0000

Per RFC3986, slash ("/") is used to separate path segment. In other words, it indicates a hierarchy.

In current draft, if there are multiple keys for a list, the key values are separated by slash ("/"), for example, /top/list/key1/key2/key3.. . Even though these keys are on the same level. I understand that we need to separate these keys, but it doesn't have to be "/", as there are plenty of sub-delims available. For example, something like /top/list/key1&key2&key3 or /top/list/key1+key2+key3?

Yi

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 13, 2014 5:12 PM
To: Netconf <[email-masked]<mailto:[email-masked]>>
Subject: [Netconf] Fwd: I-D Action: draft-bierman-netconf-restconf-04.txt

FYI,

Andy

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Thu, Feb 13, 2014 at 2:10 PM
Subject: I-D Action: draft-bierman-netconf-restconf-04.txt
To: [email-masked]<mailto:[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

[email-masked]<mailto:[email-masked]>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 25 Feb 2014 12:28:02 -0800

On Tue, Feb 25, 2014 at 11:41 AM, Yi Yang (yiya) <[email-masked]> wrote:

>  In current draft, if there are multiple keys for a list, the key values
> are separated by slash ("/"), for example, /top/list/key1/key2/key3.. .
> Even though these keys are on the same level. I understand that we need to
> separate these keys, but it doesn't have to be "/", as there are plenty of
> sub-delims available. For example, something like /top/list/key1&key2&key3
> or /top/list/key1+key2+key3?
>
>

I have seen REST-like APIs that pass parameters in the URL, which is what
we are doing
by putting the key values in the URL.

IMO '/' is more generally accepted.  Not sure this would be legal URI syntax
if nested lists were specified.  The query string parameters are after the
path-expr.

 Yi

Andy

>
>
>
>   From: Andy Bierman <[email-masked]>
> To: Netconf <[email-masked]>
> Internet-Draft<https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft>directories:
> http://www.ietf.org/shadow.html

---

From: "Yi Yang (yiya)" <[email-masked]>
Date: Tue, 25 Feb 2014 20:35:45 +0000

Hi Andy,

I support to pass parameters in URL — what I meant is,  using a sub-delim, instead of slash ("/"), to separate key values in the URL.

Yi

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, February 25, 2014 3:28 PM
To: Yi Yang <[email-masked]<mailto:[email-masked]>>
Cc: Netconf <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] Fwd: I-D Action: draft-bierman-netconf-restconf-04.txt

On Tue, Feb 25, 2014 at 11:41 AM, Yi Yang (yiya) <[email-masked]<mailto:[email-masked]>> wrote:
Per RFC3986, slash ("/") is used to separate path segment. In other words, it indicates a hierarchy.

I have seen REST-like APIs that pass parameters in the URL, which is what we are doing
by putting the key values in the URL.

IMO '/' is more generally accepted.  Not sure this would be legal URI syntax
if nested lists were specified.  The query string parameters are after the path-expr.

Yi

Andy

FYI,

Andy

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Thu, Feb 13, 2014 at 2:10 PM
Subject: I-D Action: draft-bierman-netconf-restconf-04.txt
To: [email-masked]<mailto:[email-masked]>

Abstract:

Internet-Draft<https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft> directories: http://www.ietf.org/shadow.html

---

From: Andy Bierman <[email-masked]>
Date: Tue, 25 Feb 2014 12:51:10 -0800

On Tue, Feb 25, 2014 at 12:35 PM, Yi Yang (yiya) <[email-masked]> wrote:

>  Hi Andy,
>
>  I support to pass parameters in URL -- what I meant is,  using a
> sub-delim, instead of slash ("/"), to separate key values in the URL.
>
>
I understand what you mean.  I just don't agree that using another character
to separate key values would be better.

Andy

> To: Yi Yang <[email-masked]>
> Cc: Netconf <[email-masked]>

---

From: "Alberto Gonzalez Prieto (albertgo)" <[email-masked]>
Date: Tue, 25 Feb 2014 21:28:50 +0000

Hi,

An advantage of having keys encoded using a different character is that a module parsing the URI + body could be semantic free wrt the yang modules.
This would add flexibility in the agent design.

Another consideration is that using [] for enclosing keys,  would also make URIs more similar to xpaths, which may make them more intuitive to some communities.

Andy, can you comment on the cons of encoding keys using another character?

Thanks,

Alberto

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, February 25, 2014 12:51 PM
To: "Yi Yang (yiya)" <[email-masked]<mailto:[email-masked]>>
Cc: Netconf <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] Fwd: I-D Action: draft-bierman-netconf-restconf-04.txt

On Tue, Feb 25, 2014 at 12:35 PM, Yi Yang (yiya) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Andy,

Yi

Andy

Yi

Andy

FYI,

Andy

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Thu, Feb 13, 2014 at 2:10 PM
Subject: I-D Action: draft-bierman-netconf-restconf-04.txt
To: [email-masked]<mailto:[email-masked]>

Abstract:

---

From: Andy Bierman <[email-masked]>
Date: Tue, 25 Feb 2014 13:40:50 -0800

Hi,

This URI syntax maps to the path component, defined in RFC 3986, sec. 3.3.
Paragraph 5 suggest the semi-colon or comma reserved characters to delimit
parameters.  Either of those would be OK, if the WG wants to create a
special
syntax for list keys.

Andy

On Tue, Feb 25, 2014 at 1:28 PM, Alberto Gonzalez Prieto (albertgo) <
[email-masked]> wrote:

>  Hi,
>
>  An advantage of having keys encoded using a different character is that
> a module parsing the URI + body could be semantic free wrt the yang modules.
>  Another consideration is that using [] for enclosing keys,  would also
> make URIs more similar to xpaths, which may make them more intuitive to
> some communities.
>
> To: "Yi Yang (yiya)" <[email-masked]>
>>>  In current draft, if there are multiple keys for a list, the key
>>> values are separated by slash ("/"), for example,
>>> /top/list/key1/key2/key3.. . Even though these keys are on the same level.
>>> I understand that we need to separate these keys, but it doesn't have to be
>>> "/", as there are plenty of sub-delims available. For example, something
>>> like /top/list/key1&key2&key3 or /top/list/key1+key2+key3?
>>>
>>>
>>

---

From: "Alberto Gonzalez Prieto (albertgo)" <[email-masked]>
Date: Tue, 25 Feb 2014 23:00:49 +0000

Thanks Andy,

That sounds good to me.
Taking the example below, the URI would look something like this, I guess:

/top/list;key1=value1,key2=value2,key3=value3/…

Thanks,

Alberto

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, February 25, 2014 1:40 PM
To: Alberto Gonzalez Prieto <[email-masked]<mailto:[email-masked]>>
Cc: "Yi Yang (yiya)" <[email-masked]<mailto:[email-masked]>>, Netconf <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] Fwd: I-D Action: draft-bierman-netconf-restconf-04.txt

Hi,

This URI syntax maps to the path component, defined in RFC 3986, sec. 3.3.
Paragraph 5 suggest the semi-colon or comma reserved characters to delimit
parameters.  Either of those would be OK, if the WG wants to create a special
syntax for list keys.

Andy

On Tue, Feb 25, 2014 at 1:28 PM, Alberto Gonzalez Prieto (albertgo) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Thanks,

Alberto

Yi

Andy

Yi

Andy

FYI,

Andy

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Thu, Feb 13, 2014 at 2:10 PM
Subject: I-D Action: draft-bierman-netconf-restconf-04.txt
To: [email-masked]<mailto:[email-masked]>

Abstract:

---

From: Andy Bierman <[email-masked]>
Date: Tue, 25 Feb 2014 15:15:27 -0800

On Tue, Feb 25, 2014 at 3:00 PM, Alberto Gonzalez Prieto (albertgo) <
[email-masked]> wrote:

>  /top/list;key1=value1,key2=value2,key3=value3/...
>
>
Actually I meant:

  container top {
     list list1 {
       key "key1 key2 key3";
       ...
       list list2 {
          key "key4 key5";
          ...
          leaf X { type string; }
       }
     }
  }

 /top/list1=key1val,key2val,key3val3/list2=key4val,key5val/X

The key names are redundant because they are in the YANG module.
This syntax has 1 conceptual YANG level per segment.

Andy

> To: Alberto Gonzalez Prieto <[email-masked]>
> Cc: "Yi Yang (yiya)" <[email-masked]>, Netconf <[email-masked]>

---

From: "Alberto Gonzalez Prieto (albertgo)" <[email-masked]>
Date: Tue, 25 Feb 2014 23:26:22 +0000

Thanks Andy,

I was proposing a way to provide more flexibility to agent designs, allowing the parsing of the URI + body to be semantic free wrt the yang modules
Excluding the names of key leaves in the URI prevents that flexibility.

Thanks,

Alberto

Date: Tuesday, February 25, 2014 3:15 PM

On Tue, Feb 25, 2014 at 3:00 PM, Alberto Gonzalez Prieto (albertgo) <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Andy,

That sounds good to me.

Actually I meant:

  container top {
     list list1 {
       key "key1 key2 key3";
       ...
       list list2 {
          key "key4 key5";
          ...
          leaf X { type string; }
       }
     }
  }

Andy

Thanks,

Alberto

Hi,

Andy

Thanks,

Alberto

Yi

Andy

Yi

Andy

FYI,

Andy

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Thu, Feb 13, 2014 at 2:10 PM
Subject: I-D Action: draft-bierman-netconf-restconf-04.txt
To: [email-masked]<mailto:[email-masked]>

Abstract:

---

From: Andy Bierman <[email-masked]>
Date: Tue, 25 Feb 2014 15:57:36 -0800

Hi,

What I proposed can be generically mapped to JSON arrays
or generic YANG.  The keys have to be in order and the mapping
to key names is not really needed for a generic parser.

Andy

On Tue, Feb 25, 2014 at 3:26 PM, Alberto Gonzalez Prieto (albertgo) <
[email-masked]> wrote:

>  Thanks Andy,
>
>  I was proposing a way to provide more flexibility to agent designs,
> allowing the parsing of the URI + body to be semantic free wrt the yang
> modules
>>>  An advantage of having keys encoded using a different character is
>>> that a module parsing the URI + body could be semantic free wrt the yang
>>> modules.
>>>> On Tue, Feb 25, 2014 at 11:41 AM, Yi Yang (yiya) <[email-masked]>wrote:
>>>>