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
inhttps://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"
athttps://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 fromhttps://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
