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

Re: [netmod] Tokenizing and strings (was: Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12 (part 2))

[Dale R. Worley]

Juergen Schoenwaelder  writes:
> I think we should consider this for a future version of YANG but not
> now. I am not aware what implementors had problems to implement YANG
> strings in YANG 1 or YANG 1.1 and we are at a point in the process
> where I like to not run the risk to make bigger changes to the
> specification that may turn out to introduce incompabilities.

I've written an issue about it
(https://github.com/netmod-wg/yang-next/issues/6), so it can be
considered for the next revision.

Dale

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

Re: [netmod] YANG 1.1: must-stmt evaluation in input, output, notification

[Ladislav Lhotka]

Andy Bierman  writes:

> Hi,
>
> I am trying to implement YANG 1.1 must-stmt extensions.
> They appear to be under-specified.
>
> In sec. 7.5.3
>
>The XPath expression is conceptually evaluated in the following
>context, in addition to the definition in Section 6.4.1
> :
>
>o  The context node is the node in the accessible tree for which the
>   "must" statement is defined.
>
>
> The problem for input/output is that these nodes are not encoded
> in any NETCONF RPC or action invocation. Sec. 6.4.1 clearly defines the
> XPath context for input and output, so 7.5.3 is incorrect.
>
> 7.5.3 should say the context node for input/output is the node representing
> the RPC operation. This would be the same for NETCONF encoding of action.
> The RESTCONF encoding for RPC and action is completely different
> but the definition in 7.5.3 is actually correct for RESTCONF.

This should not depend on any encoding, an XPath expression is evaluated
on a conceptual data tree, and this tree is defined for operations, too.  

>
>
> The problem for notification is not that  is not in the
> instance document, but rather that it is not part of the XPath context:
>
>o  If the XPath expression is defined in a substatement to a
>   "notification" statement, the accessible tree is the notification
>   instance, all state data in the server, and the running
>   configuration datastore. * If the notification is defined on the
>   top-level in a module, then the root node has the node
>   representing the notification being defined* and all top-level data
>   nodes in all modules as children.  Otherwise, the root node has
>   all top-level data nodes in all modules as children.
>

This is indeed quite incomprehensible. What's the idea here?

Lada

>
> The context node for  should be the node representing the
> notification.
>
>
>
> Andy
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

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