Re: [netmod] The Restconf root

[Kent Watsen]

Yes, please re-post to the netconf ML.

Also, though not your primary point, you misquoted the example.  The 2nd 
example in Section 3.1 returns “/top/restconf” (not “/restconf”), which is 
consistent with it subsequent use-example quoted below.

Kent


On 6/13/16, 2:34 AM, "netmod on behalf of Juergen Schoenwaelder" 
 
wrote:

>Hi,
>
>this comment seems to be long to NETCONF and not NETMOD.
>
>/js
>
>On Sun, Jun 12, 2016 at 10:14:17PM -0400, Dale R. Worley wrote:
>> 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 like appending path components to 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 like the new, improved method is for a URL template to
>> be advertised, and the Restconf client should use the template and the
>> Restconf specification to construct the URL to be used.
>> 
>> E.g., now, the 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
>> 
>>   
>>   
>>   
>> 
>> 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
>> 
>>   
>>   
>>   
>> 
>> The value of this being that a different server might return the
>> template 'http://example.com{?resource}', causing the second request to
>> use the URL 'http://example.com?resource=operations'.
>> 
>> Although this probably requires a redefinition of the href attribute of
>> the Link element.
>> 
>> Dale
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>-- 
>Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>Fax:   +49 421 200 3103 
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] The Restconf root

[Dale R. Worley]

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 like appending path components to 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 like the new, improved method is for a URL template to
be advertised, and the Restconf client should use the template and the
Restconf specification to construct the URL to be used.

E.g., now, the 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

  
  
  

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

  
  
  

The value of this being that a different server might return the
template 'http://example.com{?resource}', causing the second request to
use the URL 'http://example.com?resource=operations'.

Although this probably requires a redefinition of the href attribute of
the Link element.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod