Hi Toerless, My colleague David Dong and I reviewed this, and Section 5.4 looks fine. A few other notes:
Section 5.2, Service Names: We'll also need a description, assignees, and contacts for the new UDP service names. For brski-proxy and brski-registrar, you could tell us to replicate those fields from the TCP registration, but brski-registrar-rjp doesn't have a corresponding TCP registration to draw from. In fact, this section also says that the "defined TXT keys column for brski-proxy, brski-registrar and brski-registrar-rjp for "tcp" and "udp" protocols are to state the following text," but it doesn't tell us to register a TCP service name for brski-registrar-rjp. We have registered a TCP "brski-reg-cmp" service name that isn't being mentioned in this section. Finally, as David noted, service names can't be more than 15 characters long (RFC 6335, Section 5.1), but "brski-registrar-rjp" is 19 characters. Could "reg" be used in place of "registrar" instead, as in "brski-reg-cmp"? You can see registrations that contain the string "brski" here: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=brski Minor terminology issues (no rush): 5.3: '"GeneRic Autonomic Signaling Protocol (GRASP) Parameters Registry" page' should be '"GeneRic Autonomic Signaling Protocol (GRASP) Parameters" registry group' 5.4: "registry webpage" -> "registry group" Section references in the new registries might also be useful, but of course aren't required. Thanks again, Amanda On Mon Oct 20 19:24:30 2025, [email protected] wrote: > 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 _______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
