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

[Andy Bierman <[e-mail]>]

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

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

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.




>
> 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:
>
>    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.
>
> Would this satisfy IANA?  Can someone volunteer to submit Pull Requests
> for the needed updates?
>
>

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.



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