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

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 7 Mar 2022 21:31:59 -0800

Hi WG,

The authors presented the following draft in IETF 112, and there was interest in adopting the draft as a WG item.

https://datatracker.ietf.org/doc/html/draft-wwlh-netconf-list-pagination-rc-02

Since this call is coming close to IETF 113, the chairs decided to extend the adoption poll to 4 weeks. This poll will end on April 4, and will decide whether this document should be made a WG document or not. Please reply to this email whether or not you support adoption of this draft by the WG. Indications that the draft has been read will be also be appreciated. The Intended Status of the draft is Standards Track.

A separate IPR call will be issued on the draft.

Thanks.

Mahesh and Kent (as co-chairs)

---

From: "maqiufang (A)" <[email-masked]>
Date: Wed, 23 Mar 2022 11:18:05 +0000

Hi, Mahesh, all

As a response to all three list-pagination drafts, I've read these three drafts and support their adoption.

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);

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?

Then why do we want to remove this restriction now?

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).

Best Regards,

Qiufang
From: netconf [mailto:[email-masked]] On Behalf Of Mahesh Jethanandani
Sent: Tuesday, March 8, 2022 1:32 PM
To: Netconf <[email-masked]>
Subject: [netconf] WG adoption poll for draft-wwlh-netconf-list-pagination-rc

Hi WG,

Thanks.

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Mar 2022 10:53:04 -0700

On Wed, Mar 23, 2022 at 4:18 AM maqiufang (A) <maqiufang1=
[email-masked]> 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).

> 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.

> 2)   RFC8040 says “If the target resource represents a configuration leaf-list or list
>
>    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?
>
>
yes -- how does the server know the difference between a client bug (forgot
to include the keys)
and an intentional "delete-all"?

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.

We don't.
Not a priority and not in scope for this work.

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).
>
>
>
> Best Regards,
>
> Qiufang
>
>
Andy

> *From:* netconf [mailto:[email-masked]] *On Behalf Of *Mahesh
> Jethanandani
> *Sent:* Tuesday, March 8, 2022 1:32 PM
> *To:* Netconf <[email-masked]>
> *Subject:* [netconf] WG adoption poll for
> draft-wwlh-netconf-list-pagination-rc
>
>
>
> Hi WG,
>
>
>
> The authors presented the following draft in IETF 112, and there was
> interest in adopting the draft as a WG item.
>
>
>
>
> Since this call is coming close to IETF 113, the chairs decided to extend
> the adoption poll to 4 weeks. This poll will end on April 4, and will
> decide whether this document should be made a WG document or not. Please
> reply to this email whether or not you support adoption of this draft by
> the WG. Indications that the draft has been read will be also be
> appreciated. The Intended Status of the draft is Standards Track.
>
>
>
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 23 Mar 2022 20:32:40 +0000

Hi Andy and Qiufang,

> On Mar 23, 2022, at 1:53 PM, Andy Bierman <[email-masked]> wrote:
> 
> On Wed, Mar 23, 2022 at 4:18 AM maqiufang (A) <maqiufang1=[email-masked] <mailto:[email-masked]>> wrote:
> Hi, Mahesh, all
> 
> As a response to all three list-pagination drafts, I’ve read these three drafts and support their adoption.
> 
> 
> 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

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.

> 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.
> 
> 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".

>    than one such instance.”(https://datatracker.ietf.org/doc/html/rfc8040#section-4.7 <https://datatracker.ietf.org/doc/html/rfc8040#section-4.7>) 
Because the authors of RFC 8040 were being silly...and I say that being one of them!  ;)

> yes -- how does the server know the difference between a client bug (forgot to include the keys)

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.

> and then the client can explicitly specify the operation in a list or leaf-list target.

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?

Separately, here we're just talking about RESTCONF, is it not possible to delete a whole list or leaf-list in NETCONF?

> 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.  

> 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 dele…
Good catch!  Fixed in my local copy.

> Andy

Kent  // contributor

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Mar 2022 18:55:50 -0700

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

> 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.

>> 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
> 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

>> Because the authors of RFC 8040 were being silly...and I say that being

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)

> 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.

> 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?
>
>
> 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

---

From: "Wei Wang" <[email-masked]>
Date: Wed, 30 Mar 2022 17:14:45 +0800

Hi,

&nbsp; &nbsp; I support the adoption of this draft.

Wei Wang
China Telecom

------------------&nbsp;Original&nbsp;------------------
From:                                                                                                                        "Mahesh Jethanandani"                                                                                    <[email-masked]&gt;;
Date:&nbsp;Tue, Mar 8, 2022 01:31 PM
To:&nbsp;"Netconf"<[email-masked]&gt;;

Subject:&nbsp;[netconf] WG adoption poll for draft-wwlh-netconf-list-pagination-rc

Hi WG,

Thanks.

---

From: tom petch <[email-masked]>
Date: Wed, 30 Mar 2022 09:34:16 +0000

From: netconf <[email-masked]> on behalf of Wei Wang <[email-masked]>
Sent: 30 March 2022 10:14

From: netconf <[email-masked]> on behalf of Wei Wang <[email-masked]>
Sent: 30 March 2022 10:11

I oppose adoption.

The WG has too many I-D outstanding for too many years, which other WG are awaiting,

We should finish some of the existing work first.

Tom Petch

Hi,

Hi,

    I support the adoption of this draft.

Wei Wang
China Telecom
------------------ Original ------------------
From: "Mahesh Jethanandani" <[email-masked]>;
Date: Tue, Mar 8, 2022 01:31 PM
To: "Netconf"<[email-masked]>;
Subject: [netconf] WG adoption poll for draft-wwlh-netconf-list-pagination-rc

Hi WG,

Thanks.