[Multiformats] More explicit registry governance incoming!

[Bumblefudge <[e-mail]>]

On 7/14/2023 2:55 PM, Orie Steele wrote [off-list]:	I've got some concerns regarding scope and registries.https://datatracker.ietf.org/doc/draft-multiformats-multibase/07/^ this seems ok, but I would like to see more support for existing IETF standards, specifically, CBOR / COSE / LAMPs, etc ....https://datatracker.ietf.org/doc/html/draft-multiformats-multibase-07#name-the-multibase-algorithms-re^ this is yet another hash algorithm registry... but it's actually just the top part of this table:https://github.com/multiformats/multicodec/blob/master/table.csvWhich contains public and private key representations, for example:https://github.com/multiformats/multicodec/pull/190I can't yet read the charter, but I assume new key formats are out of scope... but from a practical perspective... if the top half of the registry is hashes, and that becomes a standard....changing the bottom part of the registry will cause a lot of software problems.... (even if it never makes it to RFC th
 is is the case).This makes me wonder about how to transfer the change controller from an open source project to IETF for only part of a binary prefix table.These issues can probably be sorted out by a working group, but I can see this having interesting interactions with other work at IETF that should be carefully considered.OS		Hey Orie:These are entirely fair questions, and hopefully the answers will be as reasonable. I am hoping that a "mini-Working Group" can firm up the process over time in the ways you are describing, as new users bring their use-cases (including younger and orthogonal IETF standards) in via registrations along familiar IANA lines after iterating the Multiformats spec (governing the whole Registry Group) and the Multibase spec (governing one registry within in).  Ideally, the mini-WG would decide on how to manage existing registries in the process of finalizing the specifications, which will specify how to implement all of (and only) the "final" entri
 es in the initial state of the corresponding registry. Note that the Registry Group today has very many entries marked as "draft" and many more that would, more honestly, have been marked "reserved". Many of these are unlikely to get to "final" status any time soon, and are not implemented in today's implementations across various languages. Note also that in today's mega-table, there is a column confusingly titled "tag"-- multibase corresponds to one such tag, multiaddr another, multihash another, etc.  Thus, the multicodec mega-table you linked to is an aggregate view of what is essentially a collision-avoiding Registry Group superset, with each tag corresponding to a separately-specified protocol and extension registry thereto, in IANA terms. The task of avoiding collisions across registries would get managed by the Registrars ("Stewards", in IPFS lingo) that manage the Group. If this moves into IETF, per-registry Experts would be more explicitly assigned and these could
  assist the Stewards in assessing and triaging registrations on the Registry level. This is only a slight change from what happens now, except more public, and ideally with more peer/horizontal review (in the spirit of RFC8720).I've started working on some PRs to the multiformats and multibase repositories today; next week I'll try to update the RFC internet draft for discussion at IETF117 and beyond.Thanks,__juan		bumblefudgejanitor @Chain Agnostic Standards Allianceconsulting services offered through learningProof UGmostly berlin-based, mostly		Secured by Skiff Mail.