Subject: Re: [Netconf] FW: [netmod] The Restconf root

From: Kent Watsen <[email-masked]>
Date: Tue, 14 Jun 2016 16:51:01 +0000

Hi Dale,

We recently received a similar comment from Mark Nottingham, which is interesting since he was involved with the definition of the current mechanism a couple years back as well (https://www.ietf.org/mail-archive/web/netconf/current/msg09145.html).

The RESTCONF draft authors discussed this issue yesterday.  We believe that we understand the merits of URI templates, but don’t feel that they add any value to RESTCONF.  This is because RESTCONF expects clients to be aware of RESTCONF’s three top-level resources (data, operations, and yang-library-version), as described in Section 3.3 in the -08 draft, and from then on be able to generate URLs via YANG mappings (not templates).  In line with this, RESTCONF also does not support HATEOAS (see Section 1.3 in the -08 draft).   We understand that templates may be a best practice for other HTTP servers, but believe that what we have now is perfect for this use.   Do you still feel that we can do better?

Kent

>On 6/13/16, 1:57 PM, "netmod on behalf of Dale R. Worley" <[email-masked] on behalf of [email-masked]> wrote:
>
>>(I'm new to the Netconf mailing list, so it's possible that this issue
>>has already been disposed of.)
>>
>>Looking at draft-ietf-netconf-restconf-13, it looks like the RFC 7320
>>mechanism is used to find the root URL, from which all the Restconf URLs
>>are derived by appending path components as specified in the draft.
>>
>>But looking at RFC 6570, which is referenced by both 7320 and the draft,
>>it seems that specifying path components to be appended a configured
>>base URL is no longer best practice, because it requires the HTTP server
>>to be able to connect all those URLs to the Restconf server despite
>>their different paths.  It seems that the new, improved method is to
>>advertise a URL template, and the client should use the template and the
>>Restconf "additional path" to construct the URL to be used.
>>
>>E.g., now, the second example in section 3.1 shows how the Restconf root
>>is obtained:
>>
>>      Request
>>      -------
>>      GET /.well-known/host-meta HTTP/1.1
>>      Host: example.com
>>      Accept: application/xrd+xml
>>
>>      Response
>>      --------
>>      HTTP/1.1 200 OK
>>      Content-Type: application/xrd+xml
>>      Content-Length: nnn
>>
>>      <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
>>          <Link rel='restconf' href='/top/restconf'/>
>>      </XRD>
>>
>>and used, with the sub-URL "operations":
>>
>>      Request
>>      -------
>>      GET /top/restconf/operations  HTTP/1.1
>>      Host: example.com
>>      Accept: application/yang.api+json
>>
>>RFC 6570 seems to suggest that the first lookup should return a URL
>>template:
>>
>>      Request
>>      -------
>>      GET /.well-known/host-meta HTTP/1.1
>>      Host: example.com
>>      Accept: application/xrd+xml
>>
>>      Response
>>      --------
>>      HTTP/1.1 200 OK
>>      Content-Type: application/xrd+xml
>>      Content-Length: nnn
>>
>>      <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
>>          <Link rel='restconf' href='http://example.com/top/restconf/{resource}'/>
>>      </XRD>
>>
>>The value of this being that a different server might return the
>>template 'http://example.com/top/restconf{?resource}', causing the
>>second request to use the URL
>>'http://example.com/top/restconf?resource=operations'.
>>
>>Although this probably requires a revision of the href attribute of the
>>Link element, since it now carries a URL template rather than a URL.
>>
>>Dale
>>
>>_______________________________________________
>>netmod mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/netmod
>
>_______________________________________________
>Netconf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netconf

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 15 Jun 2016 11:41:20 -0400

Kent Watsen <[email-masked]> writes:
> We understand that templates may be a best practice for other HTTP
> servers, but believe that what we have now is perfect for this use.
> Do you still feel that we can do better?

Mostly, I wanted to know that the WG had considered the question.

This question may be coupled to another one:  The draft assumes that the
HTTP URL authority part (DNS name and port) is associated with exactly
one RESTCONF datastore, because the well-known service mechanism can
point to only one root URL.

I suppose this is the most common case.  Though RESTCONF could support
multiple datastores, each with its own root URL, as long as there was
some other mechanism for locating the roots.

Dale

---

From: Andy Bierman <[email-masked]>
Date: Thu, 16 Jun 2016 20:27:56 -0700

> some other mechanism for locating the roots.

You mean we cannot add /restconf/candidate or /restconf/my-datastore?
I think an SDO or vendor could define a RESTCONF capability URI to
indicate a new datastore was supported.

> Dale
Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 17 Jun 2016 08:26:30 +0200

> indicate a new datastore was supported.

Andy,

I think Dale used "datastore" in a wider sense, i.e., as 'RESTCONF
instance'. For a given (DNS name, port) tuple, there is a restriction
of at most one RESTCONF instance.

/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: Fri, 17 Jun 2016 04:51:26 -0700

> of at most one RESTCONF instance.
So why is this a problem?
Run the server on abnothe port if you want 2 of them.

Andy

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 20 Jun 2016 15:47:04 -0400

Andy Bierman <[email-masked]> writes:
> Run the server on [another] port if you want 2 of them.

True, but what if you want to run an arbitrary number of them?  That is,
if the Restconf instances don't correspond to "devices" that have
distinct network addresses.  Say the Restconf server is the front-end
for a large number of devices which are accessed using a non-IP
protocol.

Dale

---

From: Andy Bierman <[email-masked]>
Date: Mon, 20 Jun 2016 13:25:33 -0700

> for a large number of devices which are accessed using a non-IP

This is not supported.
I suppose you could write a draft proposing standard support for non-IP
protocols.

Andy