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

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 7 Mar 2022 21:31:56 -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-00 <https://www.ietf.org/archive/id/draft-wang-netconf-adaptive-subscrip>

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: Andy Bierman <[email-masked]>
Date: Thu, 10 Mar 2022 15:56:23 -0800

Hi,

This is a response for all 3 pagination drafts: support adoption

I support adoption of a NETCONF WG item to enable the advanced selection of
YANG list instance data.
The structure of the proposed solution (base + NC + RC) is good. It
addresses the RC-only concerns
that doomed the RESTCONF Collections draft.

There are various selection features which provide a good starting point
for WG discussion.

Andy

On Mon, Mar 7, 2022 at 9:32 PM Mahesh Jethanandani <[email-masked]>
wrote:

> 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-00
> <https://www.ietf.org/archive/id/draft-wang-netconf-adaptive-subscrip>
>
> 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: "Wei Wang" <[email-masked]>
Date: Wed, 30 Mar 2022 17:11:30 +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

Hi WG,

&nbsp;https://datatracker.ietf.org/doc/html/draft-wwlh-netconf-list-pagination-00

Thanks.

---

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

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

Hi WG,

 https://datatracker.ietf.org/doc/html/draft-wwlh-netconf-list-pagination-00<https://www.ietf.org/archive/id/draft-wang-netconf-adaptive-subscrip>

Thanks.

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 30 Mar 2022 09:44:04 +0000

I also think finishing the client/server/security modules should take precedence.
Balazs

-----Original Message-----
From: netconf <[email-masked]> On Behalf Of tom petch
Sent: Wednesday, 30 March, 2022 11:33
To: Mahesh Jethanandani <[email-masked]>; Netconf <[email-masked]>
Subject: Re: [netconf] WG adoption poll for draft-wwlh-netconf-list-pagination

I oppose adoption.

Tom Petch

Hi,

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

Hi WG,

Thanks.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 31 Mar 2022 10:42:15 -0700

> We should finish some of the existing work first.
There is a direct correlation between "committed resources" and "RFC
publication".
An adoption call now means:

   "This work is useful to me. The WG (not me though)
     should spend time writing, reviewing and implementing this work."

A WG draft needs contributors and reviewers throughout the entire process.
Your suggestion of "finishing what is on your plate" used to be built into
the
process, because you needed a charter extension to add a work item.

Now it seems we have a more multi-threaded process, where many drafts are in
progress at once. This seems to work for the CORE WG.  There are few (if
any)
drafts that the entire WG contributes to, but enough stakeholders for most
drafts to get
each one done.

Tom Petch
Andy

---

From: Kent Watsen <[email-masked]>
Date: Thu, 31 Mar 2022 18:58:27 +0000

As author of the "client-server" work, I support blocking all adoptions until it's done, with the hope that others will take an active role in getting the "client-server" work over the finish line.  

Here is a concrete call for help:
draft-boucadair-netmod-iana-registries <https://datatracker.ietf.org/doc/html/draft-boucadair-netmod-iana-registries> discusses a need for IANA-maintain modules to be defined a certain way.
The "ssh" and "tls" client-server drafts both define IANA-maintained modules, but not exactly this way, and hence need to be updated.  For instance, there is no discussion as to why "identities" were chosen over "enumerations", and there is no XSLT script in the Appendix that can be used to generate the modules.
I'm happy to work with anyone willing to submit Pull Requests on the GitHub repos for these drafts.

Thanks,
Kent

> On Mar 31, 2022, at 1:42 PM, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> On Wed, Mar 30, 2022 at 2:33 AM tom petch <[email-masked] <mailto:[email-masked]>> wrote:
> From: netconf <[email-masked] <mailto:[email-masked]>> on behalf of Wei Wang <[email-masked] <mailto:[email-masked]>>
> There is a direct correlation between "committed resources" and "RFC publication".
> Your suggestion of "finishing what is on your plate" used to be built into the
> progress at once. This seems to work for the CORE WG.  There are few (if any)
> drafts that the entire WG contributes to, but enough stakeholders for most drafts to get 
> each one done.
> 
> 
> Tom Petch
> 
> 
> Andy
>  
> Hi,
> From: "Mahesh Jethanandani" <[email-masked] <mailto:[email-masked]>>;
> To: "Netconf"<[email-masked] <mailto:[email-masked]>>;
>  https://datatracker.ietf.org/doc/html/draft-wwlh-netconf-list-pagination-00 <https://datatracker.ietf.org/doc/html/draft-wwlh-netconf-list-pagination-00><https://www.ietf.org/archive/id/draft-wang-netconf-adaptive-subscrip <https://www.ietf.org/archive/id/draft-wang-netconf-adaptive-subscrip>>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 31 Mar 2022 12:20:23 -0700

On Thu, Mar 31, 2022 at 11:58 AM Kent Watsen <[email-masked]> wrote:

>
> As author of the "client-server" work, I support blocking all adoptions
> until it's done, with the hope that others will take an active role in
> getting the "client-server" work over the finish line.
>
>    - draft-boucadair-netmod-iana-registries
>    <https://datatracker.ietf.org/doc/html/draft-boucadair-netmod-iana-registries> discusses
>    a need for IANA-maintain modules to be defined a certain way.
>    - The "ssh" and "tls" client-server drafts both define IANA-maintained
>    modules, but not exactly this way, and hence need to be updated.  For
>    instance, there is no discussion as to why "identities" were chosen over
>    "enumerations", and there is no XSLT script in the Appendix that can be
>    used to generate the modules.
>    - I'm happy to work with anyone willing to submit Pull Requests on the
>    GitHub repos for these drafts.
>
>
>
It sure seems like the goalposts keep moving further and further away.
Maybe if we delay another 6 months even more new requirements and MISREFs
can be added to the heap.

Thanks,

Andy

---

From: Jürgen Schönwälder <[email-masked]>
Date: Thu, 31 Mar 2022 21:53:20 +0200

> can be added to the heap.

+1

/js

-- 
Jürgen Schönwälder              Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Kent Watsen <[email-masked]>
Date: Thu, 31 Mar 2022 20:10:03 +0000

Andy,

> can be added to the heap.

How is your statement relevant to what I wrote?  Do you think there is a choice in this matter?  Have you reviewed the modules in question and concluded that there won't be an issue in the handoff to IANA?  Yes, IANA's rebuttal would occur outside the WG, but who's time do you think would be "volunteered" to fix it?  You know, I do not get compensated for this work, right?  What happened to this being a "WG effort"?

> Andy

K.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 31 Mar 2022 13:22:58 -0700

On Thu, Mar 31, 2022 at 1:10 PM Kent Watsen <[email-masked]> wrote:

>>    - The "ssh" and "tls" client-server drafts both define
>>    IANA-maintained modules, but not exactly this way, and hence need to be
>>    updated.  For instance, there is no discussion as to why "identities" were
>>    chosen over "enumerations", and there is no XSLT script in the Appendix
>>    that can be used to generate the modules.
>>    - I'm happy to work with anyone willing to submit Pull Requests on
>>    the GitHub repos for these drafts.
>>
>>
>>
> How is your statement relevant to what I wrote?  Do you think there is a
> choice in this matter?  Have you reviewed the modules in question and
> concluded that there won't be an issue in the handoff to IANA?  Yes, IANA's
> rebuttal would occur outside the WG, but who's time do you think would be "volunteered"
> to fix it?  You know, I do not get compensated for this work, right?
> What happened to this being a "WG effort"?
>
>

The first bullet mentions a work-in-progress that is not ready,
yet somehow the client-server drafts need to wait until it is done
and follow its recommendations.

In fact there may be nothing to add beyond the text in 4.11.1 of RFC 8407.
Holding the draft up for this item is not required.

Add text:

The WG selected identities based on extensibility requirements, as outlined
in RFC 8704, section 4.11.1.

The second bullet requires XSLT programming expertise and development time.
The IETF should provide any tools required, not document authors.
So the drafts will probably wait a long time because of this new
requirement.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Thu, 31 Mar 2022 21:40:53 +0000

Hi Andy,

First, thank you for this more helpful message.

> and follow its recommendations.

I did not mean to imply that this work should wait for that draft to be done, but rather immediately act on it, as there appears to be an agreement of sorts with IANA, complete with precedence.

> in RFC 8704, section 4.11.1.

Yes, adding a sentence like that is the easy part.   

That said, AFAICT, the WG never articulated *why* identities should used.  The "Create IANA-defined modules?" thread starting at this point <https://mailarchive.ietf.org/arch/msg/netconf/TTMwp3veeBixD5k3NwHL2gyoCGs/> touches on, but does not land, this decision.   IDK if there is a need, or even if it is possible, for SSH/TLS algorithm identifiers to be defined outside of the IANA-defined registries and, if not, then they SHOULD be enumerations (per 4.11.1).

> The second bullet requires XSLT programming expertise and development time.

Indeed.  And this is what I'm hoping someone can help with now.  Note that the "initial" modules found in the draft Appendices are over a year old now.  Immediately IANA will say, "these modules are too old" followed by "we don't know how to update these module".  

FWIW, my script was/is a hard-coded Shell script.  Hardcoded in that I kept added special-cases to it until it made it through all the entries.  There is a separate hardcoded Shell script for the SSH registries.   Given the hacky nature of these scripts, I cannot recommend them for inclusion in the Appendix of the drafts.

In lieu of someone stepping up to develop more robust scripts (XSLT?), we might be able to get away with:
updating my scripts to convert the current registries
include human-instructions for how to manually update the YANG modules when new entries are added to the base registries.
Would this satisfy IANA?  Can someone volunteer to submit Pull Requests for the needed updates?

> The IETF should provide any tools required, not document authors.

I wish!  But something tells me we could be waiting a long time for that.   AFAICT, each registry requires a custom-script.  Note that Lada defined a custom XSLT for each registry he mapped.

> So the drafts will probably wait a long time because of this new requirement.

We have 3 SDOs and 2 outside WGs blocked on this effort.  Letting the drafts sit in the RFC Editor queue waiting for a IANA-maintenance solution would be stressful.

K.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 31 Mar 2022 14:58:03 -0700

On Thu, Mar 31, 2022 at 2:40 PM Kent Watsen <[email-masked]> wrote:

> I did not mean to imply that this work should wait for that draft to be
> done, but rather immediately act on it, as there appears to be an agreement
> of sorts with IANA, complete with precedence.
>
>

IMO these new guidelines are a waste of time and illustrate the problems
when
process is prioritized over results.

I would not want to see lots of pseudo-boilerplate created for stock answers
to less-than-relevant questions.  Enumerations cannot be extended in a
standard
(deviation replace(type) not allowed in a standard), without updating the
data type.
Identities can be extended without updating the data type.
This will always be the main selection criteria and not really worth
documenting.

> That said, AFAICT, the WG never articulated *why* identities should used.
> The "Create IANA-defined modules?" thread starting at this point
> <https://mailarchive.ietf.org/arch/msg/netconf/TTMwp3veeBixD5k3NwHL2gyoCGs/> touches
> on, but does not land, this decision.   IDK if there is a need, or even if
> it is possible, for SSH/TLS algorithm identifiers to be defined outside of
> the IANA-defined registries and, if not, then they SHOULD be enumerations
> (per 4.11.1).
>
>
> Indeed.  And this is what I'm hoping someone can help with now.  Note that
> the "initial" modules found in the draft Appendices are over a year old
> now.  Immediately IANA will say, "these modules are too old" followed by
> "we don't know how to update these module".
>
> FWIW, my script was/is a hard-coded Shell script.  Hardcoded in that I
> kept added special-cases to it until it made it through all the entries.
> There is a separate hardcoded Shell script for the SSH registries.   Given
> the hacky nature of these scripts, I cannot recommend them for inclusion in
> the Appendix of the drafts.
>
>    1. updating my scripts to convert the current registries
>    2. include human-instructions for how to manually update the YANG
>    modules when new entries are added to the base registries.
>

Not clear on this requirement.
A trivial YANG module with identities or enum typedefs needs to be manually
converted to an XML instance document representing the registry,
and then an XSLT script is needed to automatically regenerate the trivial
YANG module?
Is that the requirement? Supremely pointless.

> I wish!  But something tells me we could be waiting a long time for that.
>   AFAICT, each registry requires a custom-script.  Note that Lada defined a
> custom XSLT for each registry he mapped.
>
>
> We have 3 SDOs and 2 outside WGs blocked on this effort.  Letting the
> drafts sit in the RFC Editor queue waiting for a IANA-maintenance solution
> would be stressful.
>
>
> Andy
>
>
> K.
>
>
Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 31 Mar 2022 17:26:25 -0700

On Thu, Mar 31, 2022 at 2:40 PM Kent Watsen <[email-masked]> wrote:

> .....

I will try to rephrase the original message:

There will always be new requirements and new features that could be
added to a draft that takes 4+ years to finish. That is the nature of
our industry.

The challenge is to shelve the new stuff for the next version,
and release the current version on time. Make some progress
with the standard, even though more features are expected later.
That has not been the case very often.

If the publication procedures have changed, then the RFCs will be delayed
until all the process work is done. I guess organizations waiting for these
RFCs
will either help out or continue waiting.

K.
Andy

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 1 Apr 2022 00:15:16 -0400

I support WG adoption.

Thanks

Gyan

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*