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

Kent Watsen <kent+ietf@watsen.net> Thu, 31 March 2022 21:40 UTC

Return-Path: <0100017fe1ec96d1-884245af-2b1d-4215-b262-bceea7955417-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472AE3A1399 for <netconf@ietfa.amsl.com>; Thu, 31 Mar 2022 14:40:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27ALdFvmxW4N for <netconf@ietfa.amsl.com>; Thu, 31 Mar 2022 14:40:54 -0700 (PDT)
Received: from a48-93.smtp-out.amazonses.com (a48-93.smtp-out.amazonses.com [54.240.48.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A3D53A1365 for <netconf@ietf.org>; Thu, 31 Mar 2022 14:40:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1648762853; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=BCw8FNrv9U3XUd51EzZt+7mGuUz7NhwuPSZyLTHVEGw=; b=jE8daI7AVoPqo7N7ihHJigJrqVItDK6OPofmZkIR0xNjWwpLivE95vc+HEWyUQ2/ UgPLqkbsavQPhmlp0AFvxwBSqiWbcRWYE4UG0z4X1NW5GCoXUDVcAnvvo6PRGbjgKe+ /BpB2kB+TzxWu5kwuGtdrJ2nchveGnYfVv4W3rv0=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100017fe1ec96d1-884245af-2b1d-4215-b262-bceea7955417-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_22C6BA09-B7E8-456E-9FE2-C3E7B474D506"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
Date: Thu, 31 Mar 2022 21:40:53 +0000
In-Reply-To: <CABCOCHTkgt9MsZ+GcmPkUXzgTjtGBY-UELBW4_WeH99FfY-SFQ@mail.gmail.com>
Cc: tom petch <ietfc@btconnect.com>, "netconf@ietf.org" <netconf@ietf.org>
To: Andy Bierman <andy@yumaworks.com>
References: <F0DD43C9-ED92-4CEB-B2FF-3B62170B6EEE@gmail.com> <tencent_8AE86C089985513D6D2AEDAE7A4B7338F308@qq.com> <AM7PR07MB62483608303747857CD1E9AAA01F9@AM7PR07MB6248.eurprd07.prod.outlook.com> <CABCOCHSziMOZFFpHzXVwYtEQtd1DkW0XURSc=Q_+q_FMUjVgzg@mail.gmail.com> <0100017fe157e336-8a013b15-6bb0-48bd-965d-c68858e59b8f-000000@email.amazonses.com> <CABCOCHSNof7ZTORk7R59zsVy_+EKHOBC7F7GUBgtZp9r1ESb1w@mail.gmail.com> <0100017fe1996ed6-ada36fd9-7392-45ee-8040-a6ecd76be10c-000000@email.amazonses.com> <CABCOCHTkgt9MsZ+GcmPkUXzgTjtGBY-UELBW4_WeH99FfY-SFQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2022.03.31-54.240.48.93
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Yj5MEt3txeiw4fVssnC_baqb4VI>
Subject: Re: [netconf] WG adoption poll for draft-wwlh-netconf-list-pagination
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Mar 2022 21:40:57 -0000

Hi Andy,

First, thank you for this more helpful message.


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

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

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.


> Andy

K.