Ballot for charter-ietf-multi
Block
No Objection
No Record
Summary: Needs a YES. Has 3 BLOCKs.
Ballot question: "Is this charter ready for external review?"
This specific term in the charter looks like a showstopper to me: -- BEGIN -- Items that are out of scope for the group include: [...] * Changing current multiformat header assignments in a way that breaks backward compatibility with production deployments. -- END -- Are we being asked to rubber-stamp something here? Who has change control? If this is supposed to be Standards Track work, I believe this is going to be a problem.
Feedback from Mike Jones and the thread that resulted raised some questions that need to be answered before this can go forward. I don't think the ensuing discussion resolved much.
There was quite some negative feedback on this that I feel should be addressed or explained first.
** After all of the introduction, a single sentence seems to describe the actual scope: “specifically, the group is currently focused on the standardization of the two most generally-useful multiformats: multibase and multihash.” Can the narrative text please define what multibase and multhash are; and the scope of what problem is to be solved in specifying them. ** The charter text states that “The outputs from this Working Group are currently being used by various groups, including the W3C Verifiable Credentials Working Group, W3C Decentralized Identifiers Working Group …”. Trivially, the tense here is doesn’t seem right as there is neither a WG nor output from it. More practically, I would like to get clarity on the exact cross-SDO dependencies are in place here. At the IETF-W3C liaison meeting last week, W3C mentioned that there was no dependency on this proposed work. Combing from the list archive, linkages were described as follows: https://mailarchive.ietf.org/arch/msg/multiformats/fH3BDoFkr5sirxiI_1qP4QavTLg/ (Orie Steele/Fri, 08 September 2023). Can we get ground truth and capture it in the text? https://mailarchive.ietf.org/arch/msg/multiformats/KqdFPgjbUcYhc4dHoWqQrUFGi08/ (Mike Jones/Wed, 06 September 2023), and the resulting thread, highlight foundational questions about whether such flexible building blocks are needed and the impact of this flexibility . Clarifying actual/anticipated dependencies will help. ** Realizing that draft-multiformats-multihash is only a starting point, it does suggest a new, generic hash registry is needed, as does the output of “an RFC defining a multihash registry”. What is the anticipated relationship with the existing IANA “Named Information Hash Algorithm Registry”, (https://www.iana.org/assignments/named-information/named-information.xhtml#hash-alg). (originally mentioned in: https://mailarchive.ietf.org/arch/msg/multiformats/KqdFPgjbUcYhc4dHoWqQrUFGi08/) ** Per “An RFC defining a registry-group for all the multicodecs, empty at inception, with registration process and group-wide constraints on registration values”, what is the thinking behind creating an empty registry that the WG explicitly declared doing work for as out of scope (i.e., out of scope is “Creating or standardizing new data formats identified by a multicodec byte header.”)
** Is the intent of this proposed work to: (a) “bring the projects in https://github.com/multiformats/multiformats into the IETF” (aka, standardized an inflight body of work); or (b) to address the generic problem of a “self-describing data formats that consist of an inline data header and a data value” within some constraints. If (a), why are these links not more explicit? If (b), my initial reaction was that CBOR is a “self-describing data formats.” COSE and JOSE’s work also provides flexible representations for hashes. There must be other design requirements/constraints that rule these out. Can they be explained? ** Per “[t]he scope of this Working Group is to discuss these formats as they relate to standardization at the IETF for wider and safer usage”: -- What does “wider and safer usage” mean”? What are the design constraints that language is intended to impose? -- Does this language imply change control of the formats is not possible? I ask because it surprised me that text would seemingly constrain what discussion would occur. I also had the same change control question around the prohibition of “changing current multiformat header assignments in a way that breaks backward compatibility with production deployments.” Are the header assignments the prefixes before the value? My concern is that if backwards compatibility is needed with the drafts that are the starting points, what new work is needed? ** Per the outputs of the group, I recommend specifying the intended status of these specifications (e.g., s/RFC/Proposed Standard RFC/) ** Per “An RFC specifying multibase usage”, is that the same as specifying “multibase”? I don’t follow what “usage” adds, unless the intent is to describe how implementations use multi-base. ** Per “An RFC defining an independent multibase registry and populating it with today's already-implemented stable and final values”, what does “independent” mean? Are the code points in the registry not coming from the RFC which specifies multibase? Why two documents? ** Same questions for the two “multihash” outputs. ** Declaring “[d]etermining whether one data format is better than another data format” out of scope if likely there for a good reason. However, it isn’t obvious to me what this prohibition is intended to cover. If the WG was designing a data format solution, compare candidate options seems like an obvious thing to do. Could this text please be clarified?
There should be some initial milestones, no?
It would great to have some examples where the multi formats can be used . It now just says - "The scope of this Working Group is to discuss these formats as they relate to standardization at the IETF for wider and safer usage". Without any more specifics the scope seems to be very wide.
I'm supporting Murray's block for further clarity here: - From a process perspective, if the format is brought to IETF for standardization then I think that the IETF needs to be able to improve/change it. It would be fine to state that backwards compatibility with existing versions and deployment is strongly desirable. - At a technology level, I'm not convinced that this is really a great approach, particularly in that it seems to be a set of somewhat ad-hoc point solutions (not all of which have been suggested for standardization at the IETF). Prior to this charter, I had no awareness that these multi-formats existed at all, and it isn't entirely clear to me what the benefits are of bringing them to the IETF. Hence, I would ask the sponsoring AD to consider whether it may be a good idea to hold a BOF on this topic to check that there is IETF consensus for doing this work and to get agreement on the scope. Regards, Rob