add collection resource

[mbj4668]

Add the 'collection' resource. To be returned (currently) when doing a GET on a URL that points to the list, w/o any keys. Should support offset / limit query parameters.

[kwatsen]

In addition to pagination, it should support sorting as well.
Also, my team is very much hoping for a "where" clause.

As an example:

GET /restconf/data/devices?select=id;system/;lsysInfo/;redundancy/status;configInfo(schemaVersion;configStatus)
where=system/family=junos&&configInfo/configStatus=IN_SYNC
orderBy=system/hostname
paging=100;2

[abierman]

Issue B.5 from draft-01 is part of this issue

o New query parameters (e.g., offset, limit) are needed to retrieve
a limited number of list instances.

Status: solution proposal pending

Resolution: This bulk retrieval mechanism will be added.

[abierman]

Issue B.8 from restconf-01 is part of this issue

target resource list keys required for GET

o Should the client be able to GET all or a subset of all list
instances by issuing a GET without any list keys for the target
resource list?

 GET /restconf/data/interfaces/interface

o Should a "collection" resource be required in order for such a
request to be considered valid by the server.

Proposal: yes -- collection resource required to omit list keys from
the target resource in the request URI

[mbj4668]

This is a reply to Kent's comment above. I can't figure out how to comment a comment.

I agree that this is needed, but I think the solution needs to be more flexible. For example, it should be possible to do "joins" etc. I.e., a more general query mechanism. In fact, this is something our customers have asked for, and we have implemented; both in our REST and NETCONF. However, I think this should be done as an extension, not in the base spec (we need to finish).

[kwatsen]

that reminds me, we need an issue to make just about everything in RESTCONF optional - it's "light" by default...

[abierman]

Hi,

Can you make all this email go to the NETCONF WG mailing list?
Nobody knows about the issue tracker yet.

Andy

On Wed, Aug 6, 2014 at 1:08 PM, Kent Watsen notifications@github.com
wrote:

that reminds me, we need an issue to make just about everything in
RESTCONF optional - it's "light" by default...

Reply to this email directly or view it on GitHub
#3 (comment).

[bwijnen]

So Andy asked if we can get "all this emai" go to NETCONF WG list.

Is there anyone who knows how o do this?
Because I think it would indeed be good if the WG participants can see what is being said here on the issues list.

[mbj4668]

I guess create a user called ietf-netconf-wg, and register this user with the proper mail address.

But I am not convinced yet that this particular tool is better or produces results faster than what we have used before... The root cause of the problem is not which tool we use.

[bwijnen]

I agree that we must find a way to activate the NETCONF WG participants to speak up and express their opinion. That is the biggest challenge. But I think I agree with Any that many (most) of them have no idea even that this issues list exists here.

The other thing I can do is to post a ptr to the issues list to the WG and ask them to participate here.

[kwatsen]

I view GitHub as mostly an aid for authors to prepare drafts, which would then be posted and commented on using ietf conventions.

That said, it would be too cool if more members were active participants, posting issues, and even generating pull-requests.

I think we can code in a hook to email activity to the WG mailing list, but it will require an account or a code, so the ietf-mailer doesn't think it's relaying spam.

BTW, I still haven't heard back from Tom Petch regarding the new call-home draft, which I find supremely annoying given his previous comments.

Kent

On Sep 2, 2014, at 8:32 AM, Bert Wijnen notifications@github.com wrote:

I agree that we must find a way to activate the NETCONF WG participants to speak up and express their opinion. That is the biggest challenge. But I think I agree with Any that many (most) of them have no idea even that this issues list exists here.

The other thing I can do is to post a ptr to the issues list to the WG and ask them to participate here.

—
Reply to this email directly or view it on GitHub.

[abierman]

Hi,

I agree with Kent.
The issue tracker should be to keep the status and as an archive people can
check
when we are concerned about going over the same issues. The debates should
be
on the mailing list. But notifications of new issues, etc. should go to
the WG.

Andy

On Tue, Sep 2, 2014 at 6:03 AM, Kent Watsen notifications@github.com
wrote:

I view GitHub as mostly an aid for authors to prepare drafts, which would
then be posted and commented on using ietf conventions.

That said, it would be too cool if more members were active participants,
posting issues, and even generating pull-requests.

I think we can code in a hook to email activity to the WG mailing list,
but it will require an account or a code, so the ietf-mailer doesn't think
it's relaying spam.

BTW, I still haven't heard back from Tom Petch regarding the new call-home
draft, which I find supremely annoying given his previous comments.

Kent

On Sep 2, 2014, at 8:32 AM, Bert Wijnen notifications@github.com
wrote:

I agree that we must find a way to activate the NETCONF WG participants
to speak up and express their opinion. That is the biggest challenge. But I
think I agree with Any that many (most) of them have no idea even that this
issues list exists here.

The other thing I can do is to post a ptr to the issues list to the WG
and ask them to participate here.

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub
#3 (comment).

[abierman]

Seems to be consensus to put collections resource in another document.

Need to deal with GET on a list with no keys given:
GET /restconf/data/interfaces/interface
--> Maybe this will be an error unless collection resource requested

Need text proposals on mailing list.

[abierman]

Update -02:

Should the basic collection resource be defined to provide the container?

Complex retrieval modes for collections can be defined in a new RFC after RESTCONF is done

[abierman]

Update VI meeting 2014-10-20:

The original plan to add a basic collection resource will be done in the next release (if possible).
Only basic pagination (offset + limit) will be supported. Future work may extend the basic
features.

AI: Martin will attempt to add a basic collection resource in time for IETF #91

[mbj4668]

collection resource with offset and limit added in -03

[abierman]

Proposed change: collection resource with offset and limit will be removed
in -04 and moved to a different draft.

[abierman]

Issues moved to their own issue tracker since now a new draft