I have not received any reply to the following questions yet (or else email
errors...)
Thanks
Toerless
On Wed, Sep 03, 2025 at 04:05:27AM +0200, Toerless Eckert wrote:
> 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]
--
---
[email protected]
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
