Subject: Re: [Netconf] Mail regarding draft-ietf-netconf-restconf

From: Robert Wilton <[email-masked]>
Date: Mon, 19 Jan 2015 09:40:27 +0000

[Adding netconf working group at Andy Bierman's request]

Hi Kent,

I've read though the attached draft (up to the point that the yang 
modules were defined), and I've attached a draft with some inline 
comments (marked with "RW:", 20 locations) where the intent of the text 
wasn't completely clear to me.  In some places I found that it was 
clarified later in the doc, so may just need some forward references.

Anyway, hopefully these are helpful and self explanatory, but let me 
know if you need me to clarify any of my comments.

Cheers,
Rob

On 16/01/2015 17:40, Kent Watsen wrote:
> No problem.
>
> Also, in case you are unaware, we're trying to put the final touches on
> the draft now in preparation for last-call.   As it seems you are looking
> at it pretty carefully now, please report any other issues found.
>
> BTW, -03 is a bit outdated.  The current, but not yet released, draft is
> attached.
>
> Cheers,
> Kent
>
>
>
> On 1/16/15, 12:35 PM, "Robert Wilton" <[email-masked]> wrote:
>
>> Thanks for the quick confirmation.
>>
>> Rob
>>
>> On 16/01/2015 16:47, Kent Watsen wrote:
>>> Yes, this appears to be a typo - the "genre" line should've been
>>> omitted.
>>>
>>> Thanks for reporting it!
>>>
>>> Kent
>>>
>>>
>>>
>>> On 1/16/15, 8:51 AM, "Robert Wilton" <[email-masked]> wrote:
>>>
>>>> Hi,
>>>>
>>>> I was just skimming over draft-ietf-netconf-restconf-03, for the
>>>> description of "3.6. PATCH" on page 29, and the example was slightly
>>>> confusing in that the description talks about just replacing the "year"
>>>> field but the JSON patch includes both "genre" and "year".
>>>>
>>>> Is this just a typo?
>>>>
>>>> Thanks,
>>>> Rob
>>>>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 21 Jan 2015 01:17:46 +0000

First off, for those wondering, I had sent Robert a pre-release version
-04.

Below I extracted just the "RW" comments from the file Robert attached:

Thanks,
Kent

1. RW: Check whether there are options to modify multiple resources.

I don't understand this comment

2. RW: Is there a capability of bulking updates together?

Yes, one could do a PUT or a PATCH on the top-level configuration node.

3. RW: "plain patch" is one patch type that is identified, what other ones
are there, if any?  The description of patch above (and where the PATCH
operation is described implies that there will be more than one patch
type.)

See draft-ietf-netconf-yang-patch

4. RW: It might add clarity if "media type" was also defined.

We could copy/paste the first paragraph from RFC7231, section 3.1.1.1:

   HTTP uses Internet media types [RFC2046] in the Content-Type
   and Accept header fields in order to provide open and extensible
   data typing and type negotiation.

5. RW: Is it worth clarifying that child resources included in an HTTP
response could be a different datatype to media type identifier?

Maybe.  I believe the entire tree is application/yang.data, but the
"collection" media-type (no longer in this draft) would've provided a
secondary type (application/yang.collection) that would make you statement
true...

6. RW: Unclear what the "play" operation is here.

This is the server telling the client that it has an operation (i.e. RPC
statement) called "play".  That said, the client could've gotten it from
the YANG module(s), so this whole section might be redundant...

RW: The description of "3.3 API Resource" (below) implies that "data" is
mandatory here, so I was wondering if it should have also been included in
the response?

Yes, the server MUST implement the {+restconf}/data resource, but in this
example, the client is GET-ing {+restconf}/operations

7. RW: Perhaps clarify in some way here that the {+restconf}/data is the
datastore resource.  (But, it is explicitly described below, so it may be
unnecessary.)

Yes, something is off in this section.  The previous sentence says "The
datastore resource type is defined in Section 3.4," and it is, but I agree
that all this could be made easier to read.

8. RW: The description below was slightly confusing as to whether it was
refering to both datastore and data resources or just datastore.  In
particular, here it states that a server MUST maintain a last-modified
timestamp for this resource, whereas this appears to be optional for data
resources.

The "this resource" regards the parent section, which is for
{+restconf}/data (the top-level tree node), but there is no corresponding
text for decedent nodes.  I think a "SHOULD be supported for decedent
resources" would fix it - yes?

9. RW: It is unclear to me what this Entity tag is meant to be?  I had
assumed that it would identify who last updated the resource so it was
possible to determine if a resource had been updated between reading it
and patching it, but then the comment that it has to be a new previously
unused value, implies that each value has to be unique in somewhat and
hence perhaps it is just a counter, or a session id?

Entity tags are defined here:
https://tools.ietf.org/html/rfc7232#section-2.3.  Would adding "entity
tag" to the Terminology section fix it?

10. RW: Perhaps indent list2 to make it clear that it is a child of list1?

Yes, and add the missing closing bracket as well (fixed in my local copy)

11. RW: Will the client be able to know whether default values have been
returned for the children nodes?  Would it be better to force all defaults
to be returned, otherwise the client may have to query for each and every
node?

No, the server's response MUST be in accordance with its reported default
handling mode.  That said, I think the text could say this a bit better...

12. RW: Is "204 No Content" only sent back on success?  Presumably it
could also return an error instead (e.g. not authorized, or perhaps some
other error to indicate that the system cannot comply)?

HTTP errors are indicated with 4xx and 5xx status codes
(https://tools.ietf.org/html/rfc7231#section-6.5 and
https://tools.ietf.org/html/rfc7231#section-6.6)

13. RW: What it mean by all media types here?  Does this mean both JSON
and XML or something else?

It is trying to say that if GET, PUT, POST, or PATCH are supported, then
they SHOULD be supported for both the +xml and +json variants of
resource's media-type, per whatever the server supports (which apparently
is undefined, except for restconf-state/streams)

12. RW: Presumably you are allowed to create a resource with child
resources as well (e.g. to POST a full configuration)?  Is that worth
clarifying here? 

Yes, it can be the full subtree.  I suppose it could be stated more
explicitly, though I'm not clear what other interpretation there can be...

13. RW: Perhaps indent the last line of the table by 2 spaces to make it
more clear?

...or have a smaller URI - e.g., s/restconf-with-defaults/with-defaults/
???

14. RW: I wonder if implementations would rather choose to implement an
easier syntax than full XPath, perhaps in future these is scope for a
simple-filter.

We plan more XPath 1.0 expressions for collections.   It's suppose to be a
simplified XPath 1.0 expression.

15: RW: I can understand how this works if XML data is being returned, but
what is the equivalent on a XML attribute in JSON to tag a particular
field as being default?

Please see draft-lhotka-netmod-yang-metadata for how to encode attributes
in JSON

16. RW: Where is it documented how multiple updates are possible with a
single PATCH method?  I've found it later - perhaps cross reference
section 5.4

Please see draft-ietf-netconf-yang-patch

17. RW: Why is support for XML encoding mandatory?  I thought that XML was
quickly going out of fashion - shouldn't this be left to the
implementation.

This was an issue discussed by the WG (see
https://github.com/netconf-wg/restconf/issues/7).  Though the issue
tracker didn't capture it, the very-narrow WG consensus was to have XML be
mandatory to implement.

Thanks,
Kent

---

From: Robert Wilton <[email-masked]>
Date: Wed, 21 Jan 2015 15:49:04 +0000

Hi Kent,

Please see some more comments inline ...

> I don't understand this comment
Please ignore this comment, it was a reminder to me to check.

> See draft-ietf-netconf-yang-patch
Would it be worth adding a cross reference to 
draft-ietf-netconf-yang-patch either in the description of the term 
patch, or in the description of the PATCH operation?
>     data typing and type negotiation.
Yes, that makes sense.
> secondary type (application/yang.collection) that would make you statement
I thought that {+restconf}/data was of datatype yang.datastore and then 
all the children nodes were of yang.data.

Hence I thinking that if you did a GET on {+restconf}/data then the 
media type returned would be yang.datastore even though all the nodes 
below would be yang.data.

I'm sort of wondering whether it is actually necessary to have both 
yang.datastore and yang.data and whether you couldn't just use yang.data 
for both?

> the YANG module(s), so this whole section might be redundant...
I was thinking that perhaps the text above the example could be 
clarified slightly.  E.g. maybe something like:
For instance, using the "/restconf/operations" path discovered above, 
the client can now determine
the operations supported by the the server; e.g. in this example a 

> example, the client is GET-ing {+restconf}/operations
Ah, yes.  That makes sense.  I had missed that the query was just for 
operations.

> resources" would fix it - yes?
Yes.

I wonder whether it wouldn't be more clear to have a separate "Edit 
Collision Detection"/Timestamp/Entity tag section under 3.5. Data 
Resource?  Perhaps just saying that it is the as for the Datastore node, 
but optional (SHOULD) rather than MUST.

> tag" to the Terminology section fix it?
Yes, I think so.  It also made more sense by the time that I had got to 
the end of the spec and seen some of the examples.

> https://tools.ietf.org/html/rfc7231#section-6.6)
I was questioning the wording of:
"Otherwise the server MUST NOT include a message-body
    in the response message, and MUST send a "204 No Content" Status-Line
    instead."

I was wondering if it should clarified to indicate that it only returns 
"204 No Content" if the request was otherwise successful. I.e. of course 
it could return an error (rather than 204) if the RPC request failed.

> is undefined, except for restconf-state/streams)
OK.  Would it help if the text was?
    The OPTIONS method is sent by the client to discover which methods
    are supported by the server for a specific resource.  If a method is 
supported,
    it SHOULD be implemented for all media types.

> explicitly, though I'm not clear what other interpretation there can be...
:-)

OK, you say that, but on my initial reading, I had thought that you 
could POST a full configuration, but only PATCH a single resource. ;-)

This was based on reading the definition of "3. Resources (Page 13)" to 
mean that a resource refer to a single container or leaf, where a 
container may contain separate child resources, and also the definition 
of "4.6 PATCH (page 30) that says that it is used to create or update a 
child resource.  Hence my thinking that you could only "patch" one level 
in the tree, and not recursively patch sub elements as well.

So, I think that clarifying this in some way may be beneficial.

Perhaps the description of PATCH/POST/PUT could be strengthened to 
indicate that it applies to a resource and any child resources?

> ...or have a smaller URI - e.g., s/restconf-with-defaults/with-defaults/
Yes.

> simplified XPath 1.0 expression.
OK.

> tracker didn't capture it, the very-narrow WG consensus was to have XML be
Hum, OK.

I could very easily be wrong, but my hunch is that this could problems 
for someone wanting to implement a greenfield yang based SDN 
controller.  It would seem likely to me that at a minimum that would 
want to support JSON and possibly a more efficient binary 
representation, e.g. perhaps GPB and/or MsgPack.  But, XML, I doubt that 
they would be so keen.

Thanks,
Rob

> .

---

From: Kent Watsen <[email-masked]>
Date: Fri, 23 Jan 2015 20:57:00 +0000

>patch, or in the description of the PATCH operation?

Yes, good suggestion  [added]

>>     data typing and type negotiation.

Added.

>yang.datastore and yang.data and whether you couldn't just use yang.data

Makes sense to me - Andy or Martin?

>custom play operation is supported :

Added - thanks for the text!

>> that all this could be made easier to read.

This is connected to the other issue above - Andy/Martin?

>> resources" would fix it - yes?

I changed the text somewhat significantly.  Is this clear?

   The server MUST maintain a last-modified timestamp for the
   top-level {+restconf}/data resource and SHOULD maintain
   last-modified timestamps for decendent resources.  For all
   resources, the server MUST return the "Last-Modified" header
   when the resource is retrieved with the GET or HEAD methods.
   If the server does not maintain a timestamp for a resource,
   it MUST return the timestamp of the resource's ancestor, a
   process that may recurse up to the top-level {+restconf}/data
   resource. Only changes to configuration data resources within
   the datastore affect the timestamp.

What do you think?

Of course, parallel text was added in the ETag section below this
Timestamp section.

>but optional (SHOULD) rather than MUST.

Please see the above text - do you still think a separate section is
needed?

>the end of the spec and seen some of the examples.

Instead of adding to Terminology section, I put inline reference to
RFC7232, section 2.3.  I put a similar reference in the Timestamp section
above, but to RFC7232, section 2.2

>> handling mode.  That said, I think the text could say this a bit

OK, I fixed the flow on this paragraph.

>it could return an error (rather than 204) if the RPC request failed.

I'm OK with the current text.  I believe that it is generally understood
that 204 is a successful response.

>    it SHOULD be implemented for all media types.

The last sentence is confusing - both the original and yours above.  The
issue is mostly that the sentence in unneeded at all.  Which encodings
(xml/json) are supported by a server is orthogonal to which HTTP methods a
server supports for a resource.   I removed the last sentence.

>> explicitly, though I'm not clear what other interpretation there can

I added "The data-model for the child tree is the subtree is
defined by YANG for the child resource."

>So, I think that clarifying this in some way may be beneficial.

Yup, see previously mentioned addition.

>indicate that it applies to a resource and any child resources?

I don't want to add text to each of those sections.  Actually, the text in
"3. Resources (Page 13)" looks complete to me.  Can you check this again?

>> ...or have a smaller URI - e.g., s/restconf-with-defaults/with-defaults/

So I applied to replacement above, but it did not fix the formatted issue.
 I'm leaving it for now.

>representation, e.g. perhaps GPB and/or MsgPack.  But, XML, I doubt that

I agree with you and made similar statements to the affect before.  This
may yet come up again.

PS: changes made in this patch:
https://github.com/netconf-wg/restconf/commit/2b9821ee1d3cbc773e9b9b720de62
a5f947defed

Thanks again,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Jan 2015 13:04:35 -0800

> Yes, good suggestion  [added]

Do not add a normative reference to YANG Patch in RESTCONF.
The reverse already exists.

> Makes sense to me - Andy or Martin?

The application/yang.datastore resource is just a conceptual parent
for the YANG data nodes.  There is no YANG data-def-stmt that
can be associated with the datastore itself.

I agree it is odd to do a GET and Accept: application/yang.datastore,
just because the target resource references the document root instead
of a data node.

Why is it better to request data and get back datastore instead?

> This is connected to the other issue above - Andy/Martin?

I think the text says restconf/data is the datastore resource.

> https://github.com/netconf-wg/restconf/commit/2b9821ee1d3cbc773e9b9b720de62

Andy

>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Kent Watsen <[email-masked]>
Date: Fri, 23 Jan 2015 21:40:27 +0000

Hi Andy,

>The reverse already exists.

Correct.  I added it only as an Informative reference.  We can remove it
if you don't like it.

Thanks,
Kent

---

From: Robert Wilton <[email-masked]>
Date: Mon, 26 Jan 2015 12:06:25 +0000

Hi Kent,

Please see inline

>     the datastore affect the timestamp.
Yes, this is much clearer.

As your text indicates, I think that it is quite useful to allow 
implementations to potentially optimize how many timestamps/etags they 
use.  E.g. I could easily imagine implementations where they would 
choose to hold a reference to the timestamp/etag at the container level, 
but not separately for every individual leaf node.

BTW, do you think that a client will need to know whether the timestamp 
applies to the whole datastore, particular subtrees, or individual leaf 
nodes?  And if so, does there need to be a mechanism to query this via 
RESTCONF?

I was also wondering about what the timestamp behaviour would be if a 
node was deleted.  Presumably if that node is deleted, then all parent 
containers up to the top of the tree would have their timestamp modified 
accordingly.

But what about if a GET "with defaults" is performed on a leaf (that has 
a default value) that previously existed but had been deleted. In this 
case, would you expect the server to return a timestamp of when the 
explicitly configured value was deleted or just return the timestamp of 
the parent container instead?

> Please see the above text - do you still think a separate section is
No, I think that your text above is now sufficient/clear.

> that 204 is a successful response.
That wasn't quite the point that I was attempting to make (or I didn't 
make it very well ;-).

According to my reading of the existing text, if the rpc does not 
include an "output" section then it isn't allowed to return an error 
because it "MUST" send a "204 No Content" Status-line.  Hence, I was 
wondering if it wouldn't help to add a "unless the operation failed" 
qualifier to the final sentence.  E.g. something along the lines of:

    If the "rpc" statement has an "input" section, then a message-body
    MAY be sent by the client in the request, otherwise the request
    message MUST NOT include a message-body.  If the "rpc" statement has
    an "output" section, then a message-body MAY be sent by the server in
    the response.  Otherwise the server MUST NOT include a message-body
    in the response message, and unless the operation failed, MUST send 
a "204 No Content" Status-Line
    instead.

But you may deem that returning an error is obvious beyond the point of 
needing to be explicitly clarified.

> "3. Resources (Page 13)" looks complete to me.  Can you check this again?
It still feels slightly ambiguous to me.  In particular, from the text 
I'm not sure whether it is obvious that a container resource includes 
any child containers as well.  Nor does the definition of "data node" in 
the Yang spec really clarify.

Perhaps this could be made more clear in the description of a resource, 
although I'm not sure that my description below is a good way to word 
this, perhaps:

3.5.  Data Resource

    A data resource represents a YANG data node that is a descendant node
    of a datastore resource.  Containers, leafs, list entries and anyxml
    nodes are data resources.  A data resource also includes all 
descendent child nodes.

Thanks,
Rob

---

From: Kent Watsen <[email-masked]>
Date: Mon, 26 Jan 2015 21:14:37 +0000

>nodes?  And if so, does there need to be a mechanism to query this via

Yes! - and this is supported by getting the value for the top-level
{+restconf}/data resource, right?

>containers up to the top of the tree would have their timestamp modified

Correct, is node's timestamp is updated anytime there is a change in its
subtree, the top-level {+restconf}/data timestamp is updated for every
change.

>the parent container instead?

Good question.  I think that the server would maintain metadata for nodes
dependent on its default-handling mode as follows:

* report-all: maintain timestamp for leaf having a default always, even if
deleted

* trim: maintain timestamp for leaf having a default only when value
differs from default

* explicit: maintain timestamp for a leaf having a default only when its
value has been explicitly configured, regardless if the value is the same
as the default or not.

For those wondering, the reason why 404 Not Found isn't returned is
because the draft says this:

    If the target of a GET method is a data node
    that represents a leaf that has a default value,
    and the leaf has not been given a value yet, the
    server MUST return the default value that is in
    use by the server.

><snip/>

That is the case here, yes.  I do really think that text is ostensibly
about successful responses, and that the "Invoke Operation Mode" section
covers what you're looking for.

>    nodes are data resources.  A data resource also includes all

How about this?

  A data resource represents a YANG data node that is a descendant
  node of a datastore resource.  Each YANG-defined data node can
  be uniquely targeted by the request-line of an HTTP operation.
  Containers, leafs, list entries and anyxml nodes are data resources.
 
  The representation maintained for each data resource is the YANG
  defined subtree for that node.  Hence HTTP operations on a data
  resource simultaneously affect the targeted data node and all
  its decendents, if any.

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Mon, 26 Jan 2015 13:38:42 -0800

> * report-all: maintain timestamp for leaf having a default always, even if

I don't think the server will maintain state for deleted nodes.
The timestamp of the parent node will probably be used.

Andy

---

From: Robert Wilton <[email-masked]>
Date: Tue, 27 Jan 2015 18:13:48 +0000

Hi Kent,

> {+restconf}/data resource, right?
Considering a container with 2 leaves (e.g. an interface with a MTU leaf 
and admin state leaf).  The server is only tracking timestamps at the 
container and top-level resource, but the client doesn't know this.

When a client queries the MTU leaf node, the server would return a 
timestamp along with the data, but the client wouldn't know whether that 
timestamp is (i) when that leaf was last changed, or (ii) when any child 
configuration of the containing interface node had changed, or (iii) 
when any configuration has changed.  I.e. because in this case the 
timestamp that would be returned with the MTU leaf node would be changed 
even when only the admin state leaf was changed.

Is this an issue - I'm not sure?  Unless a client knows what the 
behaviour of the server is concerning timestamps, then the only 
information they know for sure is (i) the top-level timestamp associated 
with the datastore must be correct, (ii) that the timestamp associated 
with a particular node reports the last possible time that node was 
updated.

OK.

>    resource simultaneously affect the targeted data node and all
Yes, that looks good.

Thanks,
Rob

---

From: Kent Watsen <[email-masked]>
Date: Wed, 28 Jan 2015 02:09:55 +0000

>even when only the admin state leaf was changed.

No, the draft says that only config changes affect the timestamp.  The
admin state leaf (config false) wouldn't affect the timestamp.

>with a particular node reports the last possible time that node was

I'm not sure I see an issue.  Can you provide a concrete example? The
expectation is that the client will use the timestamps thusly:

  Request:
    GET /restconf/data/example:foo/bar
    Host: example.com
    Content-Type: application/yang.data+json

  Response:
      HTTP/1.1 200 OK
      Date: Mon, 23 Apr 2012 17:49:30 GMT
      Server: example-server
      Content-Type: application/yang.data+json

      Last-Modified: Mon, 23 Apr 2012 17:49:30 GMT
      {
        // some document here
      }

And then to:

  Request:
      PATCH /restconf/data/example:foo/bar
      Host: example.com
      If-Unmodified-Since Mon, 23 Apr 2012 17:49:30 GMT   <---- SAME
TIMESTAMP
      Content-Type: application/yang.data+json

      {
        // some new document here
      }

The granularity of the timestamps will matter more the longer the delay
between the two interactions.  If they're back-to-back, it would matter
very little.  If separated by minutes or hours, there is a much higher
chance of a false-negative when using coarser timestamps, which will lead
to the client maybe needing to redo the action, but that's fairly
innocuous in the scheme of things.

Naturally, this is a tradeoff implementations can play with.  Too many
timestamps may be expensive, too few may cause unacceptable thrashing.
For some devices, a sweet spot may be data-model specific.

Thanks,
Kent

---

From: Robert Wilton <[email-masked]>
Date: Wed, 28 Jan 2015 16:12:12 +0000

Hi Kent,

> admin state leaf (config false) wouldn't affect the timestamp.
Sorry, I hadn't realized that admin state was an oper leaf.  If you read 
my comment substituting "admin state" leaf with 
interfaces/interface/enabled leaf" then that may clarify what I was 
trying to indicate.

> I'm not sure I see an issue.  Can you provide a concrete example? The

I think that for your example below, the timestamps make complete sense.

I guess that I was thinking of a timestamp outside the context of this 
particular use case, i.e. basically just some meta data associated with 
an item of configuration that could potentially be useful for other 
reasons such as system triage/monitoring.  Although given that you only 
get a timestamp for the top resource node that is returned it may not be 
so useful anyway.

Would it be worth explicitly stating that the timestamp associated with 
a non root response returns the timestamp of when that node *may* have 
been last modified, and not necessarily the time when it *was* last 
modified?   Otherwise clients may incorrectly infer that the timestamp 
returned is when it was last modified due to field name in the HTTP 
response.  I.e. to prevent clients from trying to use this timestamp for 
a purpose that it isn't necessarily appropriate for.

Thanks,
Rob

---

From: Kent Watsen <[email-masked]>
Date: Wed, 28 Jan 2015 21:44:41 +0000

Hi Robert,

>a purpose that it isn't necessarily appropriate for.

The current text essentially says this already, at least I don't think it
can be interpreted any other way.  For what it's worth, I prefer the draft
specify server-behavior more than perceived client behavior.  I also
reread RFC 7232 section 2.2 and am comfortable that we're not misusing the
Last-Modified field in any way.

It seems that what you're looking for might be better handled in the
server's API documentation, which could identify the specific nodes for
which it maintains timestamps.  Perhaps RESTCONF could define a special
header (e.g., X-Last-Modified-Degrees[-Of-Separation], 0==exact,
1==parent, 2=grandparent, etc.) but, as an API-consumer, I'd rather have a
doc tell me where the timestamps are maintained rather than have to
iterate over the API to map it out.

What do you think?

Thanks,
Kent

---

From: Robert Wilton <[email-masked]>
Date: Thu, 29 Jan 2015 15:53:59 +0000

Hi Kent,

> Last-Modified field in any way.
Yes, having read the text for RFC 7232 I agree.

> iterate over the API to map it out.
I think that in the cases where the client knows exactly which server 
implementations you are interacting with then you are right, this could 
easily be covered by server API documentation.

But in the case that you have a general client that doesn't have the 
foreknowledge of which server implementations it will be expected to 
interact with then it can only rely on what is in the specification.

However, I agree with you that defining an extra header would seem to be 
overkill at this stage, and that could easily be added as an extension 
to the specification in future if there was a specific requirement for it.

On that note, I think that concludes my comments/feedback!  Thanks for 
your patience on clarifying particular points.

Thanks,
Rob

---

From: Andy Bierman <[email-masked]>
Date: Thu, 29 Jan 2015 08:25:30 -0800

On Thu, Jan 29, 2015 at 7:53 AM, Robert Wilton <[email-masked]> wrote:
> overkill at this stage, and that could easily be added as an extension to
> the specification in future if there was a specific requirement for it.
>

I proposed a mechanism in NETCONF-EX called <get2> that supports
an identityref-based registry of metadata, and a way for the client to
ask for specific data to be returned.  The server would only add 'last-modified'
attributes to those nodes where they are actually kept, so the client could
discover exactly what the server supported.

RESTCONF can have query parameters defined at any time, so
a 'with-metadata=foo,bar,baz' type of parameter could be defined
for GET in the future.

> On that note, I think that concludes my comments/feedback!  Thanks for your
> patience on clarifying particular points.
>
> Thanks,
> Rob
>

Andy