Thanks Amanda, Sorry, ran out of time during IETF123, so back now in email. Also adding anima so they can share in the discuss.
Let me start with a new question so that i can actually better address your concerns/suggestions later on: 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 ? 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... 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. 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. 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". 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 ??? > 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 > thanks, > Amanda > > On Sun Jul 20 10:15:55 2025, [email protected] wrote: > > On Sun, Jul 20, 2025 at 09:41:49AM +0000, Amanda Baber via RT wrote: > > > Hi Toerless, > > > > > > Sure, I'll take a look at this by Wednesday. Or would it be better to > > > do this before the meeting on Monday? > > > > Given the size of the IANA asks in the documents i really wouldn't > > want to put you folks under any time pressure, > > but if you're hree in person, it would of course be great to take the > > opportunity to resolve any possible > > issues in person this week. > > > > I will be happy to report monday that IANA will be looking at it. > > > > > We'd never thought of asking for a datatracker button for requesting > > > an IANA review. Sounds like something to look at. In general, you're > > > welcome to send a review request to this address or our main one, > > > [email protected], at any time. > > > > Great. > > > > > We do have an IETF meeting review system, but it isn't visible > > > enough, I think. Over the last few years, before every meeting, we've > > > been reviewing the IANA Considerations sections for documents that > > > appear in WG .tgz files attached to the meeting-wide agenda page, > > > provided they're posted by the Wednesday or Monday deadlines. We try > > > to catch late and updated agendas, but can't always manage it; by > > > Monday night we're looking at roughly 500 I-Ds (leaving out the ones > > > that haven't been updated since the last time we checked them them or > > > instances that appear on a second or third WG agenda). > > > > Yes, i think MichaelR was guessing at a process like this. Quite a big > > amount of work! > > > > > We only send a review if we see an issue, which usually the case for > > > about 20-25 percent of documents at this stage. (This doesn't count > > > documents that don't have a real IC section yet.) > > > > > > This being a new process, and because we were concerned about being > > > too noisy, at first we were only writing to authors. We recently > > > started adding the draft-string.all address, and only just started > > > copying WG chairs on reviews of documents that haven't been adopted > > > yet. I also just realized that if one of those documents is on more > > > than one WG agenda, we haven't built in a step that gets it sent to > > > the other WG chairs. So it's a work in progress, and it sounds like > > > we need to publicize it a little better. > > > > > > It looks like we didn't review anything for anima this time. The .tgz > > > file only has an empty manifest.txt file in it. > > > > Hah! I've never looked into when/how the tgz file gets built, and alas > > this time the agenda is built fairly late, but i'll take this process > > into account for the future meeting. Thanks for letting me know. > > > > Cheers > > Toerless > > > > > thanks, > > > Amanda > > > > > > On Sun Jul 20 08:49:10 2025, [email protected] wrote: > > > > Dear IANA > > > > > > > > I am a bit lost as to how to request an early IANA review for a WG > > > > draft > > > > given how there is no explicit request review button for chairs. My > > > > co-chair > > > > has asked through our AD, not sure if that request was passed on > > > > (Cc'ed). > > > > > > > > I was also told by colleagues that on might also ask directly as > > > > co-authors > > > > vi this above mail address for such a review, especially given how > > > > you do > > > > seem to scan/provide feedback for new WG drafts often by yourself. > > > > > > > > So, hereby, solely with co-author hat on, i'd like to request > > > > IANA review for the following draft: > > > > > > > > https://www.ietf.org/archive/id/draft-ietf-anima-brski-discovery- > > > > 07.html > > > > > > > > It intends to establish a pretty convoluted registry, but replaces > > > > what would be an even more convoluted mess of interdependent > > > > drafts/RFC > > > > trying to coordinate how to consistently get the job done. ;-) > > > > > > > > Thank you very much! > > > > on behalf of the authors, Toerless > > > > -- --- [email protected] _______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
