Re: [Netconf] Fwd: I-D Action: draft-bierman-netconf-restconf-03.txt

[Martin Bjorklund <[e-mail]>]

Wojciech Dec <[e-mail]> wrote:
> On 6 January 2014 12:49, Andy Bierman <[e-mail]> wrote:
> >
> >
> >
> > On Mon, Jan 6, 2014 at 3:33 AM, Wojciech Dec <[e-mail]> wrote:
> >>
> >> Hi Andy, all,
> >>
> >> are the issues leading to this draft  documented somewhere? The IETF
> >> 88 minutes only talk about the yang patch aspect.
> >>
> >> Anyway, I took a read through the latest document and the change to
> >> have all Yang data-nodes be resources. Am I correct in interpreting it
> >> that now  every leaf node  effectively becomes a resource with a
> >> separate URI? Could the authors provide some more insight regarding
> >> this change?
> >>
> >
> >
> >
> > Since YANG Patch is now optional, there is no way to delete an optional leaf
> > or leaf-list otherwise, except to copy the entire resource, and then replace
> > the entire resource (minus the optional leaf).
> 
> 
> I am still not able to get the full rationale for the change.  Can the
> authors or chairs provide that?
> 
> Anyway, it now appears that every single data leaf is a resource,
> instead of an attribute

Yes, every leaf is a subresource to its parent list or container.
This just means that you can GET/POST/DELETE the leaf directly, w/o
having to PATCH the parent.

> and the spec doesn't specify a distinction
> between handling parent resources and its sub-resources, e.g. At the
> very least POST/PUT operations to sub resources need to be constrained
> by their parent resource, and leaving that up to the implementation is
> kind of a step backwards for the spec as a whole besides being IMO a
> major complication for client or server, and likely both e.g how
> should a change to a sub-resource that doesn't meet some condition of
> the parent be handled? For a single parent resource, how should
> multiple sub-resource changes be coordinated (the parent resource
> needs to be consistent)? Etc.

I am afraid I do not understand your concern.  Could you provide an
example (data model and requests) that you feel is problematic or
unclear?

> If this current development was driven by questions/problems in the
> support of HTTP Patch operation (incl. JSON patch), the solution
> appears to be possibly worse than the supposed problem. That's why it
> would be good to understand the rationale some more.

If the "yang patch" media type is opitonal, there is no other way to
delete optional leafs.  If the optional leaf is a resource it can be
removed with DELETE.


/martin