Thanks a lot, Amanda. I hope i did resolve all IANA issues in rev 08/09:
https://www.ietf.org/archive/id/draft-ietf-anima-brski-discovery-09.html#name-iana-considerations Would be great if you could do another round of review until IETF124, so i can then hopefully declare to have passed iANA review (and get to WGLC ;-) - The RFC6690 registration procedure related text is hopefully now correct and the draft is also an update to rfc6690 to be allowed to update the registration procedures. - Had a major rework of the BRSKI Discovery Parameters tables. Draft is now targeting the format of one registry with multiple sub-registries, given how i did like that representation in IANA CORE registry the best. - no more multi-line registration stuff, empty cells, all tables should still be sane if resorted by arbitrary columns. - split into more tables so each table only has one core registration column. - more precise regustration requirements for expert review for each tabe. - Hopefully tables will fit into 72 characters once all drafts are RFC, which they should be in RFC editor queue (but that's not an IANA concern). Thanks! Toerless On Thu, Oct 16, 2025 at 10:12:25PM +0000, Amanda Baber via RT wrote: > Hi Toerless, > > I'm sorry, I dropped this one. > > > 1. Regarding > > > > https://www.iana.org/assignments/core-parameters/core- > > parameters.xhtml#rt-link-target-att-value > > > > Wrt to the first short table: > > > > Range Registration Procedures > > value starts with "core" IETF Review > > all other values Specification Required > > > > Q: This is actually not a registry table when i read the text of > > RFC6990, section 7.4 correctly. Right ? > > No. As far as we're concerned, this is just a list of procedures that apply > to different types of registration requests, presented in a tabular format. > You'll more often see them attached to registrations of numeric values, where > the "Range" label is a better fit, than registrations of strings. Typically a > registration procedure table will look more like this: > > Range | Registration Procedures > 0-127 | Expert Review > 128-251 | First Come First Serve > 252-255 | Experimental Use > > > Q: if as i assume this table is not a registry (and this applies to > > many similar tables in other registries): Would it not be a lot > > cleaner > > to move such a table then into the "Note" section as opposed to > > the place where it currently is - after the "Available Formats" ? > > Whereit currently sits, it looks more like part of the registry as > > opposed to the rules for the registry. And one may try to find (in > > vain) > > the tables entries in the CSV that follows... > > I agree. When the registration procedure is presented in a line of text > rather than in a table, it appears immediately beneath the registry name. I > just sent a note to our development team. > > > Note1: I am also asking because i was thinking i could refine the > > brski-discovery > > ask from section 4.1.1 to extend that table to say: > > > > Range Registration Procedures > > value starts with "core" IETF Review > > >> value starts with "brski" Expert Review with Specification > > >> Required > > all other values Specification Required > > > > But if you confirm that that table is not a registry, than such a > > change through brski-discovery would be an update to rfc6990 and > > accordingly require work with core-wg / core-parameters. So then maybe > > we even discuss with them how to convert the table to a registry > > through a core-wg draft > > instead of a one-off as brski-discovery 4.1.1. now asks for. > > If this is a registry, the registry as it exists now would need to be split > into two (or three, pending "brski") subregistries of that registry. > > A question: if you were to create a separate registry for strings beginning > with "brski-", while leaving this registry as it is, would you then need to > reserve values beginning with "brski-" in this registry and state that they > can't be registered here? We would still need to add "value starts with > 'brski*' | Reserved" to the registration procedure table. > > > More inline: > > > > On Thu, Jul 24, 2025 at 08:09:02AM +0000, Amanda Baber via RT wrote: > > > Hi Toerless, > > > > > > Two separate issues I want to talk about. > > > > > > 1) It looks like what's being requested in Section 4.2.2 is what we'd > > > call a registry with subregistries, except that the registry would > > > only consist of a title ("BRSKI Variations Discovery Parameters") and > > > procedures with no table, which is problematic for us. There are a > > > couple of registries from ca. 2000-2005 that we've converted to XML > > > in this way, but the development team that's looking at a new > > > presentation format is strongly discouraging this. (The beta website > > > is being used to demonstrate something other than this format at the > > > moment, so I can't send screenshots, but could pass on your > > > information to the team if you would be interested in a demo at some > > > point.) > > > > Q: I hope you are referring to 4.2 and it's sub-sections and not only > > 4.2.2. > > Yes, it looks like I meant 4.2. > > > Q: How is section 4.2 of brski-discovery different from rfc7252 and > > it's > > resulting set of sub-registries. And that's a 2014 RFC, not 2000-2005: > > > > https://www.iana.org/assignments/core-parameters/core- > > parameters.xhtml#codes > > > > The initial table in the "CoAP Codes" registry is not a registry table > > itself, > > right ? It is just shared allocation rules for the two sub-registries > > "CoAP Method Codes" and "CoAP Response Codes". > > So we won't create a walled-off section within a registry group, within a > file, unless we're creating subregistries for a parent registry. > > This is a a structural issue for us, and one we have to be fairly rigid about > as our development team looks at registry presentation design and conversion > from XML to database storage. > > A table of registration procedures, for IANA, is the list of the RFC 8126 or > 8126-derived procedures we need to apply in order to process a registration > request, depending on criteria provided in a "range" field or similar. > https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#codes > doesn't do this. It lists ranges and associates them with a category. The > subregistries for the categories have the "registration procedure" field. > > An alternative presentation for the CoAP Method Codes and Response Codes > registries would have been to present a single Method and Response Codes > registry, and supply a registration procedure table at the top that combined > the "Method" or "Response" information in an additional "Note" field. > > > Are you telling me that you would need brski-discovery section 4.2 > > specify > > some non-registry rule-table so that 4.2.1, 4.2.2 and 4.2.3 could each > > create > > sub-registries in the same way as "CoAP Method Codes" and "CoAP > > Response Codes" > > do ??? > > The problem is simply that we have been asked, on account of current and > especially future structural considerations, not to do this in a registry > group: > > Registry > > Section > > - Registry in section > > - Registry in section > > Whereas we can present > > Registry > > Registry > > - Subregistry > > - Subregistry > > thanks, > Amanda > > > > Also, a quick note: we'll also need to list the registration > > > procedure individually for each table/registry, no matter what the > > > approach. > > > > Sure. > > > > > So a couple of suggestions: > > > > > > a) What if we were to create a new registry group at a new web page > > > dedicated to this, and place individual links to all these in > > > https://www.iana.org/assignments/brski-parameters? I can show you > > > what those links look like in an existing page. > > > > Understood. I'll look into that option if the above "sub-registry" > > option like done for CoAP Codes falls through. > > > > > Look for "Measurement Timestamp Type" under "Registries Included > > > Below" at https://www.iana.org/assignments/mpls-lsp-ping-parameters, > > > and you'll see a registry title and reference accompanied by a note > > > that points to another location. We could do this at brski-parameters > > > for each table/registry and use whatever you want for the note. Maybe > > > something like "Included in the 'BRSKI Variations Discovery' registry > > > group at [URL]." > > > > > > b) A little hackier, perhaps: what if, instead of creating a section, > > > we incorporated the type of registry into the name? e.g., "'BRSKI > > > Variations Discovery: Context," "'BRSKI Variations Discovery: > > > Variation Type and Choices," and "BRSKI Variations Discovery: > > > Variations and Variation Strings"? > > > > See above. > > > > > 2) Two separate questions about table contents: > > > > > > a) I'm assuming that in Table 2, for example, "BRSKI" and "mode > > > vformat enroll" are meant to apply to the second and third rows as > > > well as the first row. If so, would there be any issues with us > > > populating those empty fields? Here's an example of a registry that > > > does that: https://www.iana.org/assignments/email-auth. At the > > > moment, I don't know whether we might need to come back later and say > > > "we really need to fill in these blank spaces." I see the current > > > approach being more readable in the draft, so I don't think the draft > > > and registry would necessarily need to match in that way. (Another > > > point I just remembered here: the registries are sortable, as you'll > > > see if you click on the box to the right of the column header name in > > > any of those email-auth registries. This suggests to me that it would > > > be better not to leave fields blank.) > > > > Right. I will add note to next-rev that the registry can/will have the > > fields filled and that not-filling them is just for nicer editorial > > visibility. > > > > > b) The above would make more sense for the CSV file associated with > > > each registry and the JSON file we're going to associate (this is > > > what you can see in registries linked from > > > https://beta.iana.org/protocols right now). But for that reason, > > > separating "mode," "vformat," and "enroll" with commas would also > > > likely make more sense than line breaks. > > > > Right. Next rev. > > > > Thanks a lot! > > Toerless > > Many apologies, > Amanda -- --- [email protected] _______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
