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 _______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
