Re: [netconf] WG adoption poll for draft-wwlh-netconf-list-pagination-rc

[Andy Bierman <[e-mail]>]

On Wed, Mar 23, 2022 at 1:32 PM Kent Watsen <[e-mail]> wrote:

> Hi Andy and Qiufang,
>
>
> On Mar 23, 2022, at 1:53 PM, Andy Bierman <[e-mail]> wrote:
>
> On Wed, Mar 23, 2022 at 4:18 AM maqiufang (A) <maqiufang1=
> [e-mail]> wrote:
>
>> Hi, Mahesh, all
>>
>> As a response to all three list-pagination drafts, I’ve read these three
>> drafts and support their adoption.
>>
>
> I have not examined the solution details closely enough.
> Not all details look like they have 1000s of hours of customer deployment
> usage
> like the basics implemented in real servers).  IMO standards like this one
> need
> to be based on proven technology (i.e. running code).
>
>
> Both the CLIXON and SZTPD products ship with half of this draft
> implemented, using two completely different DB-backends, and one author
> (Per) is from the Tail-f side of the Cisco-house and is ensuring
> compatibility there (it may be that Taif-f has a proprietary paging
> mechanism).   We welcome a Yumapro prototype to further ensure correctness.
>
>
https://www.yumaworks.com/pub/latest/netconfd/yumapro-netconfd-manual.html#get-bulk

We have a lightweight, stateless, bufferless solution called
'get-bulk' that is simply for iterating
through a YANG list, N entries at a time (with lots of filtering parameters
of course).
It does not rely on count or position, so additions and deletions "behind"
the current instance location do not affect the walk.

The pagination drafts provide stateful, resource-intensive advanced
features.
I don't have time right now to work on an implementation, but plan to
implement the RFC.

I really liked the original RESTCONF Collections proposal from Martin,
which required the client to create, use, and free a 'collection' resource.
It is much more efficient for both client and server if there is explicit
state
managed for this purpose.



> I do have one comment regarding list-pagination-rc draft:
>>
>> It makes sense to me that the draft extends RESTCONF protocol to add
>> “list” and “leaf-list” nodes as data resources and define a new media type
>> to encode list/leaf-list in XML.
>>
>> But when I understand that the draft also tries to extends RC DELETE
>> method to allow the deletion of a whole leaf/leaf-list, I have the
>> following feelings:
>>
>
>
>> 1)       It’s not in the scope of this list pagination work which
>> focuses more on list/leaf-list pagination retrieval( but I can understand
>> that the authors do this for completing RC solution);
>>
>
> +1
> There is no way that EDIT operations should be included in a pagination
> draft.
>
>
> These are reasonable objections.  The authors struggled mightily over the
> DELETE operation, but left it in so it could be a WG-discuss.  This will be
> treated as a post-adoption "open issue".
>
>
Just submit a new draft


>
>
> 2)   RFC8040 says “If the target resource represents a configuration leaf-list or list
>>
>>    data node, then it MUST represent a single YANG leaf-list or list
>>
>>    instance.  The server MUST NOT use the DELETE method to delete more
>>
>>    than one such instance.”(https://datatracker.ietf.org/doc/html/rfc8040#section-4.7)
>>
>> I am curious what’s the consideration for this design, is it because it’s a dangerous behavior?
>>
>> Because the authors of RFC 8040 were being silly...and I say that being
> one of them!  ;)
>

There were objections, based on lack of "REST Purity" in our solution
proposal.
The DELETE method can only apply to 1 resource.
BTW, we do not implement any delete-all for RESTCONF. (due to multiple
MUSTs in the RFC)




>
>
> yes -- how does the server know the difference between a client bug
> (forgot to include the keys)
> and an intentional "delete-all"?
>
>
> The server wouldn't know if the client has a bug, of course.  But, if
> discussing existing RC-clients, they currently cannot target a
> list/leaf-leaf (as a whole, not a specific entry) without the RC-server
> throwing an error.  Said existing RC-clients would have to be modified to
> introduce support to target a whole list/leaf-list.
>
>
There is text that says a list MUST have all keys present in the target
resource URL.
All leaf-lists MUST be specified with their value for DELETE.


>
> netconfd-pro has supported "delete-all" and "remove-all" values for
> the nc:operation attribute for many years.  It has to be enabled in the
> CLI,
> and then the client can explicitly specify the operation in a list or
> leaf-list target.
> It is widely used for leaf-list, and not so much for list.
>
> IMO the NETCONF and RESTCONF RFCs would need updates to support
> such an operation. Something for netconf-next and restconf-next wishlists.
>
>
> Are *-next updates technically necessary?   Clearly the intention is that
> the DELETE operation is only supported *if* the module is implemented by
> the server...so where is the harm?  If a client fails to test the server,
> the worst that happens is that it gets an RPC-error, right?
>


You are right. A server could advertise a YANG module, feature, capability,
etc
that indicates it allows a special edit mode.



> Separately, here we're just talking about RESTCONF, is it not possible to
> delete a whole list or leaf-list in NETCONF?
>
>
> Then why do we want to remove this restriction now?
>>
>>
> We don't.
> Not a priority and not in scope for this work.
>
>
> It's fair to say that a DELETE list/leaf-list operation is not-required,
> as list-pagination is fundamentally a read-only activity and, obviously,
> DELETE is not.
>
> That said, as soon as the new targets are defined, immediately folks will
> want to use the DELETE operation on them, don't you think?  This is
> something that comes up often; so much that current practice is to wrap
> lists and leaf-lists with container solely to enable whole-list deletion.
>


IMO list pagination is mostly useful for operational data
and bulk list deletion is not needed at all.

If this is needed for a specific config list, then it can be placed in its
own NP-container parent, so deleting the parent is the same as delete-all.


Andy



>
> Maybe I’ve missed something, but just curious.
>>
>>
>>
>> BTW, the “decimal64-numbers” parameter is defined as leaf-list in the list-pagination draft, rather than a “list”. But it’s mentioned as “list” in Appendix C.2 of list-pagination-rc(example of deletion of a list).
>>
>> Good catch!  Fixed in my local copy.
>
>
>
>>
>> Best Regards,
>>
>> Qiufang
>>
>>
> Andy
>
>
> Kent  // contributor
>
>
>