Good point; these are not CBOR map keys because it's not a map but an array. But still, for an array, the indices could be managed in an IANA registry for the JPY protocol. This allows future documents to add new map indices to the registry. An alternative is not to create a registry at all but just allow an RFC to update the array with 1 or more indices. I don't have a preference for one of these solutions.
In case we go for the registry solution still, the name 'Map index' needs to be changed to 'Array index' in the text that I proposed. For extendibility it would be good to add a sentence in the stateful JPY protocol description that any additional array elements (i.e., not specified by current document) MUST be ignored by a receiver if it doesn't know these elements. This allows evolution of the protocol while maintaining backwards-compatibility. And a version number isn't needed; that number is defined by the length of the array ;-) Best regards Esko -----Original Message----- From: Michael Richardson <[email protected]> Sent: Wednesday, November 24, 2021 19:00 To: Esko Dijk <[email protected]>; [email protected]; Peter van der Stok <[email protected]> Subject: Re: [Anima] I-D Action: draft-ietf-anima-constrained-join-proxy-05.txt / Section 9 proposed text Esko Dijk <[email protected]> wrote: > Based on my earlier review comments: see below Section 9 proposed text. > It adds these elements that I think are missing in the current -05 > text. I hope that clarifies it. Also it refers to an existing IANA > policy from RFC 8126. At first, I was all... "how did we miss this". But, back in section 5.3, JPY_Message was defined as an *array* not a map, so there are no indexes to manage in an IANA registry. (Or rather, the indexes are implicit, maybe) Maybe we can text making this more explicit? -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =- _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
