**Session Date/Time:** 17 Mar 2026 08:00

# IANABIS Working Group - IETF 125 Transcript

**Date:** March 2025
**Working Group Documents:**
- [draft-ietf-ianabis-rfc8126bis](https://datatracker.ietf.org/doc/draft-ietf-ianabis-rfc8126bis/): Guidelines for Writing an IANA Considerations Section in RFCs
- [draft-ietf-ianabis-rfc7120bis](https://datatracker.ietf.org/doc/draft-ietf-ianabis-rfc7120bis/): Early IANA Code Point Allocation

**Session Slides:**
1. [Chair slides](https://datatracker.ietf.org/meeting/125/materials/slides-125-ianabis-chair-slides-00)
2. [Early action I-Ds and 8126bis](https://datatracker.ietf.org/meeting/125/materials/slides-125-ianabis-early-action-i-ds-and-8126bis-02)

---

**Ted Hardie:** Okay, everyone. Uh, we are now at time. Uh, so thank you all for being here. A couple of reminders: Uh, first of all, uh, this session will be recorded and it will be posted on YouTube, so please be aware of that as you consider your comments. Uh, we're- we're joined today by the avatar of the Shenzhen Leopards, the local basketball team. Uh, they're having an exciting season, currently six. Yesterday's uh game, they were 97 to 64 victors over the Long Lions. Uh, they're playing again tomorrow, they're playing the- the Gold Lions and then the following day they are playing the- the Flying Tigers. So I have the feeling that there's sort of a theme here because originally the name of the team was the Aviators, but I think the entire uh league is now cats of some type or another. So, interesting to note if you're a basketball person, uh tomorrow 11:30 or Friday at noon. 

Uh, we have uh the Note Well to look at. Uh, I think many of you have been here before, but if you- if this is your first IETF, this Note Well both notes that we have a guide for professional conduct and an anti-harassment policy. If you have issues, you can bring them up to me as chair, to one of the area directors, or to the ombuds team. Uh, we also want you to be aware that any contributions you make, made that are covered by patents or patent applications, will be extraordinarily surprising uh for this particular group. Uh, but if- if it should be for this or any other group, please make sure you're aware of what your uh rights you are providing uh and your duties according to the intellectual property rights and IETF technologies. 

Uh, as a reminder, uh most of the decisions that we will discuss today will be confirmed on the list. Uh, if people decide to get up a group to go see the- the Shenzhen Leopards tomorrow, it- that doesn't have to be confirmed on the list, but most kinds of decisions today will be confirmed on the list. Uh, that's particularly the case because we- we have quite a few people who are not able to join us uh for a variety of reasons, including my co-chair, uh Murray. It's midnight where he is and he doesn't get back from the disco for at least two hours. So unfortunately, we'll be missing him.

**Ted Hardie:** Uh, sure, thank you. Uh, so I said, uh it's midnight where Murray is and he doesn't get back from the disco for at least two hours. That- that- that's what you missed, sorry. Uh, so here are some meeting tips. I think many of you have already seen those. If you have not already signed in uh to- to the meeting via the Data Tracker or via the QR code uh that's attached to the microphones, please do so. Uh, that has a couple of functions: One, it makes sure we get the right size room; it also makes sure that when you're ready to uh have an intervention, that you can enter the queue because the queue management will be done entirely through that tool. Uh, if you're- have audio and video in your client, please keep them off. Uh, if you're remote and you are ready uh-uh to join the queue, uh you can certainly turn them on uh once your turn comes. It's helpful if you have headphones that you use them or a- a microphone that you use as a separate microphone as well.

We have a pretty simple uh agenda today, the adminstrivia, most of it has uh occurred already. I will note I'm not asking for uh a scribe this time. We're going to attempt to use the AI uh tool and then we'll go back and confirm using the uh- the uh- the posted video of it to make sure that the AI has captured everything correctly. If you happen to be an old-school person who is taking notes and you'd like to take the notes in the uh- uh the Meetecho note taker, you're welcome to do so. We'll certainly uh-uh consult them if somebody does choose to take notes there, but we're not asking for it this time. Uh, are there any questions about the adminstrivia uh for the working group before we start? 

Uh, hearing none, you'll notice a single person's name associated with all of these. So we've given Amanda a chair and her own- her own microphone. Uh, we have not provided her uh a guitar, but if you happen to have a guitar in your room, uh we're willing to have her play later. Uh, it looks like there is a person in queue. Martin- uh good to hear from you. What's up?

**Martin Nottingham:** Yes, uh Ted, can you ple- please be careful that you speak into the microphone and you are not too far away from the microphone, because otherwise it's very difficult to hear you. Thank you.

**Ted Hardie:** Okay Martin, uh I've moved it right onto my laptop now, which uh should adjust it. Sorry, I'm getting a fair amount of uh-uh feedback from the- the monitor here that indicated I was speaking quite loudly, so it's a little bit difficult with these monitors. Sometimes they're very soft, sometimes they're quite loud. Uh, but uh hopefully this will resolve the problem and in any case the person speaking pretty much from now on will be Amanda, so I'm going to turn it over to her uh as I change uh what uh slide deck we're using.

**Amanda Baber:** Let me know if I'm getting away from the microphone. Uh, I'm sure I will want to. Uh, whenever you're ready. Oh, uh ready. Next. Uh, okay. Uh, this time we wanted to look at the [Early Registry Creation document](https://datatracker.ietf.org/doc/draft-ietf-ianabis-rfc7120bis/) first, uh because it's our understanding that there is actually a pressing need for this one. And uh we haven't seen any objections to it so far, but we don't know if it's just been sort of overlooked. Uh, if you haven't seen it, essentially this lets working groups that need to coordinate registrations across documents use an IANA registry instead of something like an internal wiki uh that has to be destroyed, or it could be used for uh coordination with another organization like- like DRIP. 

Uh, so creating and renewing the registry will use the same approach you see with early allocations, uh chair and AD approval. Uh, however the registries have to have registration procedures and a lot of the normal 8126 procedures uh don't make sense in this context. Like you can't require an RFC, we don't want to ask the IESG to designate experts, uh and uh first-come-first-served probably isn't appropriate. So the plan is to have two procedures. Uh, if the finalized registry would require an RFC, uh registration will take the usual early allocation procedure. If it's going to be a first-come-first-served or expert review registry, then registration is going to require chair approval, uh or sponsoring AD approval in the unlikely event that it's created by uh an AD-sponsored draft. Uh, if they plan to use specification required in the future, uh the procedure would depend on who's applying and uh whether- whether the authors want to declare as TLS did at one point that- that IDs are eligible for permanent registration.

Uh, there's a couple small questions we want to check with you on. Uh, the chair and AD have to approve creating and renewing a registry, but if the registry structure needs to be updated in some way, like new fields or uh different allowed values, is it okay to just get chair approval? Uh, if- if nobody cares, we will say yes to that. Uh, let's see. Uh, the other procedural question, uh very bureaucratic, is uh if working group A creates the registry and working group B wants an early allocation code point from it that requires approval from uh the AD and the requesting chair, does the group A chair who's responsible for the registry also have to approve? Uh, if nobody objects, we'll just say both chairs need to approve the initial registration, but the chair for the registry doesn't have to approve renewals. Uh, yeah, that's- uh, a more substantial question, uh we can't answer, uh we just don't know whether there needs to be more of the security considerations here. Uh, we took what we could from RFC 7120, which but that's essentially don't DDoS IANA, uh but- but most of the text didn't seem to apply. So if people think something more here is needed, we- we really need the group to provide some text. 

Uh, let's see. And uh one last point is that uh we're currently noting this in the document and aren't sure whether it's appropriate or necessary to do so. Uh, if an ID for a registration is approved for- for a registration is approved before the ID that- that creates the registry is approved, I think it is correct, uh is it not that this would temporarily block publication for the ID with the registration in it, because it would be stating that it's- it's registered a code point in a registry that could be allowed to expire? Uh, we don't plan to offer the option to delete expired registries, we'll just, you know, keep the expiration date there as we say in the document. I'm just not sure whether this note about potential publication delays needs to be included or if so where it belongs. Uh, for that matter, if we mention that here, there could be a similar consideration for early allocations that would need to be mentioned in uh 7120bis. Uh, the issue wouldn't be for the document requesting the allocation there, but for any approved document that happens to mention somebody else's early allocation, uh which could expire and be removed uh if the chairs wanted to remove it. So, I might have needed like a flow chart or something for that, but uh- uh that's it for that slide.

**Ted Hardie:** Any comments from uh those present, either uh remotely or in person? Hi Michael, would you mind saying your name for the thing.

**Mike Jones:** Mike Jones. Seems okay to me.

**Ted Hardie:** Yay. Martin.

**Sue Hares:** Sounds more than okay, it sounds like a lifesaver.

**Ted Hardie:** Slightly out of order, but fine. Thank you, Sue. Martin.

**Martin Nottingham:** Thank you. Can't hear you yet. Yeah, the- the setup in here is completely bizarre. Um, so on this last point, uh it would be much easier if you didn't have to deal with the fact that drafts expire. Um, I don't think this is- this is actually relevant in this case. I think if a draft expires, carry on, just ignore the fact that it's expired. Uh, it's only a problem if someone- if someone retracts a draft and that- that becomes the problem then for you. Uh, I- I don't think you want to over- over-index on- on draft expiration. Drafts expire all the time, particularly when they're in the RFC editor's queue. Um, that's- yeah.

**Amanda Baber:** Well, it's the- the early allocation made by the draft. They- they might decide to keep going with the draft but decide they don't- they don't need the early registry or the early allocation anymore. And uh with early allocations, uh there's- there's currently an option in there for chairs, uh not for registries but for early allocations, they can deprecate it, they can leave it in there with uh an expiration date, they can choose to just remove it from the registry if they want to.

**Martin Nottingham:** Yeah, this all seems kind of overly complicated, but um I would simply say in in these cases, um there's an obligation on the part of the folks who have created the- the registry or the registry entries to inform you when they no longer want one. And other than that, um you're- you're waiting for the- the document to either, you know, someone to either tell you that they no longer want it or for the document to transition to- to RFC, at which point the- the things can become more permanent.

**Amanda Baber:** Right, we check on uh- we- uh we ask about renewing them every- at the end of every term, which is currently annual and will be every two years if 7120bis goes through.

**Martin Nottingham:** Yeah, a regular check would be helpful, but I think that's- that's all you need. Uh, I wouldn't worry about the other things I've done. Yeah. All right. 

**Ted Hardie:** Uh, thank you Martin. Sue, you're- still in the queue. 

**Sue Hares:** Yeah, I was- just as it's uh- so I know what you're doing with the last question, would you like feedback on that one based on a real case? So, if we have, say I have that document I'm talking about uh-uh with the flow spec V2 and I have that new registration document, I imagine you might get an ID for registration before we get that registration document approved. That's the case. So my suggestion is you hold them if you can, or we just have them resubmit because they need the- they need the registry there to hold it. Now I don't know if you can have an early education allocation for a registry and then add an ID on top of it. Uh...

**Amanda Baber:** So, uh- my understanding is that the RFC editor would hold that. I'm kind of wondering if we need to put some advisory text in there warning people, "Hey, that might happen."

**Sue Hares:** Okay. I'm just thinking how we- what- what'll come up against us is I know we'll have that registry draft that I'm writing and then we'll have IDs coming in after it. Uh, so they're both drafts, you know, and they're sort- so does the registry draft need to be there and approved before I get the other little ones in or do we live both in approved state? Uh... I- it's a real question for next month, so that's- so I got the registry draft for the flow spec V2 and then I get IDs coming in after you that want uh-uh early allocation for something there. I really have to get that registry draft out and in to the IESG/IANA. 

**Amanda Baber:** Okay, yeah, as far as I- as far as I understand it would just be sort of stuck in an RFC editor state, I think. 

**Sue Hares:** Okay. I- I would just work harder and get the little draft out there.

**Ted Hardie:** Uh, Brent.

**Brent Zundel:** Uh, Brent Zundel. Um, so in Media Man, we have a similar mechanism as the early allocation for provisional registration of media types. The- the primary difference between the two mechanisms is that um provisional registration can be done by groups outside of the IETF, where early allocation requires that there be an internet draft on the IETF stream. Is that something that uh if that requirement were not in place, then the Media Man bis that's currently being drafted would be able to just point to IANA bis instead of making its own provisional registration thing?

**Amanda Baber:** Um, I think uh- and and this is a question I think comes up later is- is that maybe we want some more text in 8126bis uh explaining, you know, when you might want to use uh- set up a provisional registry or provisional registration option and when you might want to fall back on- on early allocation. I know a thing with uh media- media type templates are kind of unusual in that there's quite a lot of text you need to have prepared in order to register, and with provisional you're just- you're just registering your name and that's, you know, that's a non-consideration for most registries. Uh, a- thing that we are doing in the next um in 7120bis is- is proposing uh- uh an early allocation option for SDOs uh where we would be using that- uh that- that standardistry registry. So, um...

**Brent Zundel:** Yeah, that's what I was asking about. Thank you. Mm-hmm.

**Ted Hardie:** Uh, so I put myself in the queue when Sue was talking. It sounded like we got to a conclusion, though, so I'm just going to repeat the conclusion and see if folks agree. I think what we concluded was that the registry document had to be sub- complete, sent to the IESG, or some later state before the registrations' internet drafts could show up and be acted on. Is that what we agreed?

**Sue Hares:** Yes, at least we have to just hold them in the working group or something else. Yeah, and that's okay, I've- we- this is an unusual case in that we're revving a protocol but we need totally new registries, so... okay, I accept the responsibility for writing that draft.

**Ted Hardie:** I just wanted to make sure that uh I had gotten the conclusion correct. Um, thanks. Harald.

**Harald Alvestrand:** Harald Alvestrand. Just uh as far as I understand, Brent's worry is irrelevant in this context because if any other organization than the IETF wish- wishes to set up a registry with IANA, that would be a relationship between IANA and that- that organization and not involve the IETF at all. So this- so the concern is real in the- and we'll come to discuss that later today, but it's a 7120 worry, not this document worry.

**Amanda Baber:** Okay, yeah, for registry creation that is a separate- a separate issue that's not- not being covered here. So...

**Ted Hardie:** Uh, I'm just going to check something. I got a message from one of the uh remote folks that they could not hear the presenter. Can I ask somebody else who's remote to check um and give us a- comment in- in the- in the chat?

**Meetecho:** It's very clear where we are, Ted.

**Ted Hardie:** Okay, so at least some are getting it. I'll comment back to that person that it may be on their end and suggest they re- reconnect. Uh, thanks. Is there anything more on this uh-uh slide before we move on? I think we're good. Okay.

**Amanda Baber:** Let's see. Locating notes. Um, so about the early allocation procedure for SDOs and we do think it should probably be limited to SDOs just because we want to be relatively sure that the organization will- will publish this spec and we won't end up with some- some expired values. Um, the bureaucratic uh question I think first, uh we'd like to repurpose a registry created by [RFC 6838](https://datatracker.ietf.org/doc/rfc6838/), which has the IESG approve SDOs for the registration of standards tree media types. Uh, this currently has about 45 entries, we usually add like three a year. Um, and uh we checked with the IESG, they- they have no problem with this. Uh, but the problem is uh-uh that if we're going to uh take over this registry, where might my notes be... um, we need to- we need to do one of two things. 

Uh, option one, we can add a column that tells people what kind of registrations the SDO's approved for. Uh, so we could label these existing ones with media types, uh or maybe multiple registries, or all registries. Uh, ideally this would be groups of registries and not individual ones because that could become unwieldy. Uh... option two, uh we don't add a registry field, it's just a blanket approval for any registry. That's certainly easiest for us, but it does mean all the media type organizations are getting- getting grandfathered and that's- I mean it's W3C and OpenID, but it's also like uh the American Society of Heating, Refrigerating and Air-Conditioning Engineers, and I don't know if that's an issue for anyone. Uh, but we need to let Media Man know what the plan is there. I understand 6838bis is in working group last call. 

Um, so a- sort of more philosophical question. Uh, I was under a possibly totally incorrect impression that people wanted to limit early allocations for SDOs. Uh, hence the proposal that they not be uh- renewable and they should be, and I'm not sure how this would even be enforced, uh-uh made only when the document's nearing approval rather than early in the development stage. Uh, Mike Jones, who's an expert for a lot of relevant registries, uh suggested on the list that trying to- to limit uh-uh their early allocation in this way is- is not the way to go, and we're happy to remove those limitations or implied limitations. Just- just let us know what to do there. 

Uh, John Klensin, uh you're first in queue.

**John Klensin:** Uh, hi. I- I first of all want to say that this- this whole business makes me nervous because uh-uh my understanding of the role of IANA from- from what I first became involved with a long time ago, um makes notions of- of temporary or provisional or- or early registrations a little bit dubious, and I need to think much more about that and will try to write something when I have it. But as to this specific point, um the right SDOs for the purposes of IANA and running registries and keeping things may be different for IANA than for the IETF. Uh, and even for the IETF, it gets involved in fundamental ways with- uh- with the liaison process and IETF's connection with other bodies rather than simply whether the IESG thinks they're an okay body for some specific standards purpose. If you were doing this on the basis of one particular registry and the decision to allow one particular SDO went through the relevant working group and was approved there and went through the IETF process, that would be a different thing. But with regard to random standards development organizations, uh as I say, I'm not certain that the right answers for the IETF are the same as the right answers for IANA, and uh- and if they're even more or less the same, I'm not certain that going off and bothering the IESG is the right answer. And generalizing to media types, it's and- and- and to generalize from that to media types or from media types to that is just probably the wrong thing because again the right definitions for an SDO may be different depending on different standards, different context.

**Ted Hardie:** Uh, thank you John. Uh, Harald is next and then Mike.

**Harald Alvestrand:** Harald Alvestrand again. And the reason I suggested that we reuse the registry was because that seemed- reuse the media type SDO registry was because that was simplest. We only want one. And the reason I suggested that we should limit- limit to specific registries was just because I didn't want to have a sudden change in- uh the rights of other organizations. Uh, there's a long list of organizations that I have no idea whether either the IETF or the organization is interested in any other registration than media types. So um putting in a limit field uh seemed- seemed like the least disruptive change we could make. 

**Ted Hardie:** Thank you. Mike.

**Mike Jones:** Mike Jones. As a frequent user of registries and as a designated expert for a bunch of them, um first I would just reuse the list of SDOs for the reasons that Harald said. It's simplest for us, we don't want to have to um... and it's working well enough, to John Klensin's point, that uh- the IESG is a body that can decide if, you know, the Society of Refrigeration qualifies or not, which is fine by me. 

Um, also thinking about we- you know, we have professional staff that are doing all these things for us. If we can keep their jobs simpler by, for instance, not making them check whether an SDO is eligible to create a well-known suffix uh-uh despite the fact that it can create a media type, that's probably simpler. I know that I write a lot of drafts here but also in the OpenID Foundation and the W3C that register things in a multiplicity of registries and I don't want to create administrative overhead for the staff to have to keep track of that. That's just make-work as far as I can tell.

**Ted Hardie:** Mark.

**Martin Nottingham:** Martin Nottingham. Um, I- I do think that reusing the existing uh- uh list is the right approach. Um, but I- I pause at just making it open slather, I think. Uh, what's surprising maybe here is that the early allocation procedure as I understand it is not opt-in, it's applied universally across all registries created by the IETF. Uh, so my specification doesn't have to opt into, you know, early allocation. And I think that with the- the trust boundary of the IETF, that makes a lot of sense. But when you expand it to other SDOs, that could have some surprising effects. Um, and so I'm wondering about, you know, I don't know about keeping state in the registry or- or- or uh- you know, like maybe this is something that needs to be specified uh- uh in the what establishes the registry and it's opt-in rather than by default, where- where- a registration for other SDOs is only something that- that a registry definition document opts into. Uh, just- just a thought.

**Ted Hardie:** Paul.

**Paul Hoffman:** Paul Hoffman. Um, the purpose of registries is to help make interoperability, we don't want people stepping on code points and such like that. An exceptionally small number of registries have very limited code space for certain things. The vast, vast majority, if we get a couple of weird registrations that weren't really needed and such like that, absolutely nobody other than maybe the people in this room will care. I believe that permissibility is the right way here. Just go ahead and let everyone do it. If we discover after the fifth bad registration from the refrigeration people that this was a mistake, we can look at it again, but I would say the default really should be let- let people register, you know, early allocation the same way they would have if they had sent things later and such like that. And again, if that's a mistake, we'll know it soon enough and we can change it. But let's be nice.

**Amanda Baber:** Uh, I'd like to add here that we expect very little use here. Uh, we haven't seen this problem come up often. I mean it's a real problem, but it's- it's fairly rare. And uh unless- unless we start suggesting it to organizations, um then I- wouldn't- I wouldn't expect to get more. I mean if people want to suggest it to organizations, that's- again fine with us. Um, but I- I think even um the- the knowledge that the early allocation process exists uh for- for uh IETF stream IDs is maybe not like as widespread as we'd like it to be, and this- this procedure has existed since 2004. 

**Ted Hardie:** Uh, so I put myself in the queue to- to call out something else on this uh-uh because I think there's an- an interaction that maybe we haven't discussed. And that's the bottom statement: retract the claim that ID process is made for specs at any stage of development, but SDO docs should be nearing completion. Um, and I- I think one of the issues that people are talking about and how broadly should the permissions be for SDOs outside of the IETF actually relates to the completion of those docs, right? So if a- if a group from outside the IETF has something near completion in terms of its own process, um that uses a code point that they want early allocation for, there's- there's presumably then enough text to tell you why the code point is there, right? They- they're not going to be, "Hi, we're the refrigeration people and we'd like an IP-uh version number," right? There- there will be some text that actually um is in their document that- that describes it. So I think as long as we have this idea that SDO specs uh need to be near completion before these allocations are made, then the- the idea that the permissions seem broad may not be as concerning. But that's definitely only my personal opinion, and I wanted to make sure if anybody else had a contrary opinion uh before we take it to the list, that we gave them an opportunity to chat about it today.

Mike.

**Mike Jones:** Me again. I've certainly written more than a dozen IANA considerations sections in RFCs that contain text of the form: "As long as the designated expert is convinced that the specification will be published in a timely fashion, they have the option to make assignments." Um, and that's standard text that's borrowed from somewhere. Um, that works perfectly well for the designated expert to, you know, ask the W3C or the OpenID Foundation or the Refrigeration Association um if they're not familiar with this process: "What does it mean for something to be a candidate recommendation? Or what does it mean for it to be an implementer's draft?" or what have you. Um, I haven't seen any problems with that uh- uh role for the designated experts. Um, I will say, um and repeat something I said on list recently that's pertinent to this. I view the early review as stuff is being near final as serving a purpose other than just code point allocation. There's a broader good, which is if you get designated experts looking at your draft, whether it's an IETF draft or a W3C draft, right, they will find stuff because they're generally smart, well-informed people. And it's more often the case in my experience than not, when the draft that's near final is exposed to the designated expert, they will improve the text if we give them the opportunity to do so. Um, I gave an example of a draft where about half the registry entries were improved, and I think that's good for all. So um this goes to the purpose of the early review by the designated experts that it's um going to improve both the specs and the quality of the registrations that occur, which I think is a good- whether it's an IETF spec or whether it's using IANA in not an IETF spec.

**Amanda Baber:** Would- would it be useful to uh add a sentence that- that says something like, "However, um- um, you know, SDOs can request an early review at any time, a preliminary review at any time"? Or...

**Mike Jones:** Perhaps. The- I- I only pause because "at any time," um I might qualify it with "at any time in that they believe their specification is sufficiently mature."

**Ted Hardie:** Okay, from the point of view of uh- uh action items, I think I didn't hear anybody object to some form of reusing the existing registry, and the discussion was around uh what guardrails uh were needed and what the shape of those guardrails be. So I think for the discussion in the uh- uh in the list, which will follow this, I'm probably going to take the- the position that I heard more people say, that we didn't need specific guardrails and registry entries at this time, and that we will look for the need for those in the future as the starting position, but not as a declaration of consensus, and see with that whether we can make progress toward consensus on the list. Uh, does anybody want to immediately leap up and say, "I'm going to fall on my sword if you do that"? 

Seeing none, I- I think that- that's our- our theory there. 

**Amanda Baber:** Okay, thanks. Um, and I apologize for the text falling off the page, it looked right on my computer. Um, there's- um another small item where uh- uh it was pointed out that uh- we're putting it on the expert to tell us when the spec's been published. Uh, I think I was taking it for granted, so didn't mention that the requester would and should probably tell us first, but there's a very good chance that they won't. Uh, our big concern is again we just don't want unnecessary expiration, so this will be rephrased uh in some way uh- uh to basically say uh- uh that I've lost my note... um, that the requester should uh- tell us, the expert if- if they find out, should tell us uh- uh but we will be the backstop uh- uh at the- at the uh- renewal/expiration point. And uh that's it for that slide.

**Ted Hardie:** Okay.

**Amanda Baber:** So this is a- this is a new thing. Um, this slide's a late addition as well, so uh you might not have seen them uh- if you downloaded yesterday. Um, so there is a message on the list uh questioning the fact that authors of working group documents can request permanent first-come-first-served, expert review, and in some cases specification required uh registrations uh without bringing it to the group first. Uh, this has- this has always uh- uh been the case, and we've uh- in fact pointed it out to authors who uh- uh seem to be sort of squatting on code points uh in their IANA consideration sections. Uh, but the question is, is this- is this something people are concerned about? Do you want us to add a step for working group documents, uh just for working group documents, where- where we ask the chairs to confirm that it's okay for that request to be submitted to us before we process it? Not to review the request, but just to confirm that they could make it. Uh, this is probably something we'd rather do across the board or not do across the board. Uh, and I'm not sure where this would be inserted, maybe inserted into 8126bis and- and pointed out in 7120bis. Um, so this- uh- this is used uh- a lot in BGP registries, I'd say, and uh- and not so much elsewhere if you haven't seen it. And uh- I- I think we'll be- uh- taken care of a lot by uh- maybe early- well, no, that's it. 

**Ted Hardie:** Uh, so I put myself in the queue as an individual. I think it would belong in 8126bis because the first-come-first-served registries are impacted by this. Any other thoughts from the- folks? Does anyone want to argue that uh working group chairs should confirm? Uh, looks like not. So it looks like the current process, that would be working group drafts but no necessary uh-uh second step to get confirmation from the working group chairs. 

**Amanda Baber:** Okay, "no, don't do it." 

**Ted Hardie:** No, no need to- from- we'll confirm it on the list, but at least in the room and... oh, John's on the thing. John. 

**John Klensin:** Sorry, I- it took a while to pick up on your question. Um, I'd like to see some confirmation from the- from the working group that this is uh- is consistent with our intentions. Uh, we see an awful lot of working group documents, a lot of documents which are adopted by working groups which are in very, very preliminary or- or vague phases, and which may change very significantly uh- uh along the way. And- and- and having some author acquire this authority simply because they are authors of a document which has been adopted by a working group for further discussion seems a little dubious to me. So some sort of provision for going back to the working group chair and saying, "Does this look stable enough to you uh- uh to do this?" or to the- or to the relevant AD seems to me to be relatively lightweight compared to standard things working group chairs and particularly ADs are expected to do. 

**Ted Hardie:** Uh, Martin.

**Martin Nottingham:** Yeah, I agree with John. I couldn't imagine that if I were an author for a working group ID and would uh- uh ask for such a registration that I wouldn't uh- copy the working group or at least the working group chairs, so I think it's kind of a no-brainer to me. Thank you.

**Ted Hardie:** Uh, so from the chat I'll point out that uh the other Martin uh- uh actually said, "So that an early allocation from an individual draft would be permitted, uh and for first-come-first-served that's obviously going to be the case, but it wouldn't be permitted if the same request came from a work group draft." That- that's the consequence of this, and I just want to make sure that people are aware that he's called it out. 

**Amanda Baber:** It's uh- it's not that the request would be- well, I suppose, if the- if the working group chair said no, that is- it would effectively be making it not first-come-first-served anymore. And it would only affect working groups because otherwise there's no one to ask.

**Ted Hardie:** Any other thoughts on this? John.

**John Klensin:** Yeah, I- I- I- I think I'm going to be the uh- uh the- the- the radical conservative here. Uh, I'm nervous about individual drafts as well because it uh- uh because anybody can publish anything as an individual draft. Um, it opens us up to uh- to all kinds of denial-of-service attacks on IANA should anybody decide they want to do that. And I don't quite know what to do about it because I understand why the- what the intent is there, but uh- uh but it does make me anxious. 

**Ted Hardie:** I- I'm sorry it makes you anxious, but it appears to be a very fundamental part of first-come-first-served. And so unless you wish to argue we should remove that, um I don't see how this changes it, right? In this- in this case in first-come-first-served, there's by default in that registry anyone who asks is given a value. And in expert review, by default the expert decides and presumably if it's working group draft they would be a member of the working group or would confirm with the working group. So that- 

**John Klensin:** Yeah, that- that- that's- that's fair. And of course it- uh- it brings us into the argument of- of whether or not internet drafts are stable documents, all- all sorts of other things like that. But uh- but you're quite right about FC/FS. 

**Ted Hardie:** That- that would only be true if we were talking about the specification required of it, but for the first two I think it's clear that the- FC- sorry, FC/FS is affected. Anyway, I've been talking, in there are other people in queue. John... Jonathan.

**Jonathan Lennox:** Oh yeah, Jonathan Lennox. I mean, I think as somebody in the- in the chat mentioned that you should rather than confirming with the working group chair just notify the working group chair and, like, CC them on the- your response and then if that's wrong if something is wrong the working group chair can say, "Oh my god, what is- what is this draft author doing, you know, I'm- I'm- I'm revoking- I'm- getting a new editor" and they can fix it. But I think that's, you know, keep the- everybody has good intentions and it's not insane uh- case smooth, but with a- way to correct if something goes wacky. 

**Ted Hardie:** Uh, Sue.

**Sue Hares:** People make mistakes. You know, working- we all live in a flawed world. Uh, I like you at least informing the working chair so as the previous person said, you can fix that, "Oh my goodness, we really should not have done this," or "You sure that person really wanted that?" and even that case behooves you to get a con- you know, a notification of the chair so that if it's in the same space you can- you can- at least try to fix errors. 

**Ted Hardie:** Thank you. I saw quite a few people uh giving thumbs up to uh- Jonathan's proposal uh- uh here in the room and a couple on the chat as well. So I'm- I'm going to suggest for the uh confirmation on the working group mailing list that we take that as the baseline and we say that what IANA should do on receiving one of these from a working group is to CC uh- the working group chair on responses. To the- or working group chairs on responses. Uh- that's not a pre-notification and a- and a raising of first-come-first-served to another bar, but it is uh keeping the working group uh leadership in the loop as this happens. Um, so we'll- we'll try and confirm that on the list. 

**Amanda Baber:** Okay, uh- for first-come-first-served, that first email would probably be uh a notice of registration within, you know, a day or two. Yeah. Uh- ready for the next slide? Oh, yeah. Thanks. 

Uh, so this is just a- summary of what we've done with specification required in- in 8126bis. Uh, so ID and purchase-only spec issues are now addressed in a- in a specification required subsection called "Common Specification Issues." Uh, for IDs, uh- the decision here as I understood it was the default from now on uh- isn't that it's up to the expert, but that IDs will not qualify unless the working group says they do or the AD if- if the group has concluded and I believe the- the idea was that they would also notify the last call list. Um, it's important to note that this um- doesn't shut out IETF stream IDs, they can still get uh- RFC 7120 early allocations. Uh, however it does shut out IDs from uh- other streams, which I understand from the last meeting is- is considered okay. 

Uh, but we still have uh logistical questions. Uh, primarily for us, if- if the registry has already been created, does the working group decision have to be recorded in an RFC? Uh, and if- if IDs are eligible for permanent registration, it- it might be a good idea for us to record this in some kind of registry note. Um, the other question is uh- if an expert has been accepting IDs for permanent registration, and there- there are registries where this is done, would they then have to go to the- the working group to get approval for further ID-based registrations or would there be a kind of grandfathering? So... thoughts on those questions. Uh, Sue it looks like you're first. Oh, Paul.

**Paul Hoffman:** Paul Hoffman. I brought this up briefly the last time and I still have the very same concern: working groups versus the IETF. Once most of these registries are done, IETF is the change controller. And um so we've got- working- some working groups have closed or- or- are closing or whatever. Um... I don't think having working groups doing this is- is- at all correct. I think it should always go to the IESG. It'll go to an area director. That's like one extra step, and if the area director wants to punt it to the working group, great. But as the chair of a working group, not that has any registries, but that is closing and isn't closing fast enough to make my area director happy and stuff like that, I don't want all- any of those decisions to get in the way of the IESG saying, "This is what we want, we've been running- you know, we've been responsible for this registry for a while." But now the working group gets to change the rules or things like that. And that comes back to some of your questions like, "Well, what happens if the expert has already been approving things?" Every time an expert approves a thing, they're doing it under the auspices of the IESG, not of the working group. So I just would take working group out of all of this. 

**Ted Hardie:** I am surprised the line did not grow after that statement. I am too. Are there any other comments? Klensin agrees with me, gone through them. Are there any area directors in the room that wish to state they were willing to take this on? Okay, so this is definitely one we need to take it to the list because I think this is a pretty major change. Um, we can take the proposal that- that Paul has made uh to the list. And Paul, if you would uh- uh write up in text what it would mean for 8126bis to make that change and- and share it with Amanda, I'd appreciate that. And we'll then take that to the list. Um, I- I do feel like this is a major shift in responsibility. Um, we can certainly make this proposal and- and see what the- the mailing list says, but uh I am- am- somewhat surprised on the lack of opposition. 

**Amanda Baber:** So uh- can I confirm that uh- that when the registry is being uh- created that- that that RFC can choose, but it's- it's just registries that uh- that already exist and- and we don't know what to do?

**Ted Hardie:** Yeah. That from that point on from what I understood Paul to be proposing, it was only the area directors who decide, not- not a working group even if the working group was extant. 

**Amanda Baber:** Okay. Uh- for the other question, if an expert has already accepted IDs for permanent registration, will they need to get a working group decision before doing it again? Do folks have comments? Mike.

**Mike Jones:** I hope not, just because um... you- I'm- I'm going to bias most of my answers in terms of let's have as little process as we can get away with and you're describing what seems like an extra confirmation step that doesn't exist now. 

**Amanda Baber:** There is- there is one thing for IANA though is- that we should be- recording at least for ourselves, if not for others, which registries this applies to. So are we going to have a registry note for these grandfathered ones stating it's okay? 

**Paul Hoffman:** Paul Hoffman. Mirroring exactly what Amanda said, that should be noted, and it should be noted in the registry. I as somebody who has been put into a registry with an internet draft um a couple years ago and I- I might want to try to do it again later would be shocked to be like, "Oh no, we've changed the rules and, you know, you can't do that" or whatever when it was simply because time had elapsed, not that anyone had made a decision. 

**Ted Hardie:** Okay, so what I'm hearing is that once uh- uh IDs have been accepted they continue to be accepted unless some- something more major than um- a- a decision of the specific expert occurs, that a registry note is added and that's going forward unless some policy decision is documented somewhere. Is that approximately what people want? Martin.

**Martin Nottingham:** So I think this is- this is the policy decision. This is not just time elapsing. This group is making a decision that says that by default, unless the creation of the- the registry, which gets IETF approval, um recognizes IDs as valid references for the- for the code points that are being assigned, then um you just can't have any more of them. And that's- that seems to be the decision here. I- I think this whole grandfathering thing is kind of- um- I mean you could make the decision to allow that if- if a registry has previously accepted IDs as references then- then it could continue to do so, but that's the decision we can make here. And if a registry hasn't taken any IDs in the past, then uh maybe it's- maybe it's moot and- yeah. I- I think this needs to be a lot clearer. Because the- um- to Paul's point earlier, the IETF makes a decision about the creation of the registry. It is IETF consensus that drives the creation of the registries and ultimately the IETF community as a whole is responsible for these policies. Now, it is my opinion that this is not the right decision, but if that's the decision of this working group then that's the decision it needs to be and it- it would be best to be consistent throughout. Um, and yeah, there may be some registry entries out there that reference IDs and then- you know, too bad. 

**Ted Hardie:** Uh- putting myself up uh as an individual. I think the difficulty here is that nobody in the group has announced that they have a time machine and so we can't go back and inform anybody who would have had the decision to enter specific text to allow IDs into documents which have already now RFCed. And the way this was done before did not have the clear guidance that we intend to have in 8126, and so your question is what do you do in the cases um when there is no clear guidance. And there are three states that- that are possible. One is you say if it was previously allowed, um it remains allowed. One you can say if it was previously allowed from the moment of this policy um being implemented it is no longer allowed. Um, and the third is you can say every time it comes up it must be escalated to somebody to make a decision. Uh, and then you have to decide who that someone is. 

Uh, I think taking Mike's point we want this to be something where it is as low overhead a process as possible. I think the escalation view of this is somewhat higher overhead than the other two, and I think if the working group wants to choose one of the two lower overhead, it has to make a decision about whether it's going to be once we put this policy in it is- it is firm. Um, but I think there will be cases where then people come back and say, "I'm going to escalate because there is no working group for me to fix this with." And maybe that escalation takes the form of an AD-sponsored draft which updates the registration procedures to permit them. Um, but I think we have to acknowledge that we need something here that's clear one way or the other, and I personally um am unsure what the consensus of the group is. I'm being asked by Martin if I want to run a poll. I'll take off my individual hat now and run a quick poll and see if we can get that done. Is there anything else you want to get on the um- on this slide while...

**Amanda Baber:** Uh- on the slide there's just a little bit about purchase-only specs. Um, and uh I think we're all agreed that uh it's okay if they provide a free copy for- for the expert. Uh, what we said but are not at all attached to uh- is- is that we suggested giving the expert some leeway if they thought that a purchase-only spec was not appropriate for some scenario, some registration, some registry. Um, do you want to keep that for the expert and if so do the experts need guidance and if so could somebody else write that guidance? 

**Ted Hardie:** Oh wow, I did this completely badly. Sorry, I'm showing terminating it. I've forgotten that I can't do three- three choices in this. Uh- so I- I will take this to the list instead. Uh, Chris.

**Chris:** Yeah, so uh I- don't have an answer for that purchase-only question. Um, I can only make it more difficult. Um, there are scenarios where a code point may be registered under a specification that is not purchase-only, and then at some later time that uh specification could become purchase-only. Uh, not talking hypothetically, um there are code points that have been uh- requested and registered by the CTA that uh- were very nearly had this exact issue occur. And so some sort of guidance on what the correct process is for that because obviously it- it makes a mess. 

**Amanda Baber:** I mean I'm not- I'm not sure if uh- I'm- is this- is this um- speaking to whether the expert decides that a purchase-only spec...

**Chris:** Yeah. Let- let's suppose- suppose there's a- there's a registry, uh- the expert says, "Uh, this is cool, um- you gave me a free copy, um- a- not you gave me a free copy, but, you know, this is cool because this is open, right? That's fine. Um, and if it were not open, I would not approve it." And then later, after that point in time, the specification could become closed, because they still retain the right to close it. Um, and- and what would happen then to that registration point in the registry? 

**Amanda Baber:** So in that case it would not have been registered...

**Chris:** No, so in this particular case it would have been registered because it was open, and then it became closed later, thus making...

**Amanda Baber:** Right, well I mean... I- I haven't seen- so I haven't seen that happen that I recall in, you know, 10 or 15 years, an expert saying- I mean it- might have happened that- that he would approve this but he doesn't like the fact that the- the spec is closed. It's poss- it- could have happened and I'm not remembering it or- or Sabrina covered it. Um, so I- I think this is one of the sort of cover-the-basis things. Um, but it seems simpler to just leave that out and uh if the expert has reasons to- to not approve they can produce whatever those reasons may be and it can be appealed if they disagree. I think... 

**Ted Hardie:** Jonathan... Jonathan Klensin is in front of you. John.

**John Klensin:** Yeah, the- the only uh- problem I see with the comment you just made uh and and what's on the slide uh is- is if the free copy is provided the expert, with many SDOs and at many stages development process, that free copy comes with restrictions about not- about lack of further distribution or forbidding further distribution. And- and- and if you get into that stage and the expert looks at the free copy and says this is okay, and then there is some sort of protest or complaint about the registration being accepted, um we could be in a problem because the- the permission for free copy of the expert to the- to the expert might not allow the expert to share that copy with whoever was doing- reviewing the protest or appeal. Um, this- this is an obscure case, it may not be worth worrying about, but at least at this stage in our discussions we should be aware that various organizational rules could- could cause that to happen. I tried to explain parts of this on the list, I think. 

**Jonathan Lennox:** Yeah, Jonathan Lennox. This is coming out of a chat I was having in the- or whatever I was having in the chat um where Robert Sparks mentioned a weird case which is not- but is sort of analogous to a case where a spec is classified and can only be viewed inside a SKIF or something like that. So- um- or, you know, he mentioned something where you can only see the spec in person at the spot where it is archived. So, um- I think there's other cases other than purchase-only where something is not freely available and perhaps we should just generalize this. 

**Amanda Baber:** I- I think they would be obligated to provide uh airfare and accommodations. Um, yeah this seems hard to legislate for. Maybe we should just note that they're okay generally. I- I think I remember the one you're talking about where we were asked to deal with something where the- the spec itself was at a classification level that we had to find somebody who could read, but um I think it's very much a corner case. I can only remember one in 30 years, so hopefully we won't get a second while any of us have to worry about it. Uh... Next slide is again if we're... 

**Ted Hardie:** Okay. I just want to go back for a second, say I'm going to take the question uh to the list about uh the set of choices around what do we do um if the expert has already accepted IDs for- for uh later um internet drafts because I feel like we didn't come to a consensus on that, so that's going to go to the list. 

Uh, Brian, you're already here. Is it for this- this or did you want to go back one? 

**Brian:** I wanted to go back one. Apologies, I stumbled over it a little bit, but I wanted to ask for a bit of clarification and guidance on that last bullet point because I'm- only a DE on one particular registry. I have a strong disdain for purchase-only specifications and I would love to have some sort of authority to say that I won't accept a registration thereof. And in previous cases where I've tried to make that argument, not very strongly but I've tried to, I've largely got pushback that, "Oh no, you should do this, you can't assault their business model" or whatever, like and um- so I- I would be very much in favor of some kind of text giving explicitly giving the experts leeway to make that call. Because I- I don't think it's there right now and I feel like there's some unsaid pressures to- um act otherwise. 

**Amanda Baber:** Okay, so I think the proposal is that that text will be in there along with a note that this is an appealable decision of the expert. That's- that's what I heard. Okay. 

**Ted Hardie:** Uh, Barry.

**Barry Leiba:** This is Barry Leiba. I don't mean to throw an extra wrench in, but it just occurred to me: have we ever had a case where the document, the- the um spec was not in English, and do we want to say anything about that? So for instance we register a bunch of uh Russian cipher text- or cipher algorithms, whatever. Um, maybe those specs would be written only in Russian in some cases or something like that. 

**Amanda Baber:** There's certainly no reason it couldn't happen. I can't remember one. It mostly comes up, you know, with media types and ISO documents, but... 

**Barry Leiba:** Um, so the question I guess is just do we want to say anything about that or just leave it for- uh it being an edge case uh that we deal with at the time? 

**Ted Hardie:** Uh- so from- from my perspective it falls into the case that if the expert can't review the spec for whatever reason, then uh they may request some accommodation just like they might have to- to apply to the SKIF and be... 

**Barry Leiba:** Suppose the expert is- does speak Russian and can read it, but the other people can't, you know, the other people who might want to implement it can't. I don't know, maybe I'm just- let's just forget about what I just said. Okay, that's fine. 

**Ted Hardie:** Uh, I think I understand the objection, but as long as the expert can review it, if it's an expert review registry I think we're- 

**Amanda Baber:** Okay. It- occurs to me to add also that for um- we run the .int registry for intergovernmental organizations and if they have if their only treaty is not in English we say, "Please give us a certified translation." So, okay. 

**Ted Hardie:** Uh, Roman, good to- good to hear from you. How- how's it going, man?

**Roman Danyliw:** Uh, great. It's a very favorable time zone. Uh, I'm sorry I can't join in person. Uh, so I'm speaking as an individual. I'm reacting largely to the- the text there up top about IDs won't qualify for permanent registration but the working group can say it does. Uh, this seems to me like this is going to be prone to error if we do that. Working groups may forget to consider it. Uh, you know, as a- as a kind of a suggestion, um maybe one way if- if the- if the consensus is that we want to head in that direction might be actually to- to eliminate specification required for new- for new registrations and instead we split it and we have specification required flexible, specification required- kind of- strict. And so we explicitly bake in the registration policy that a working group can choose uh that- that- that includes kind of these characteristics rather than having this idea of like, "Let's choose specification required and then the working group needs to remember to put all additional qualifiers." I think it's going to create confusion. I know that's- that's challenging for what it means kind of historically uh- but this should be a more kind of explicit, you know, dropdown choice. 

**Ted Hardie:** Uh- speaking as chair, I would love to see actual text on that because I think what you've stated is an interesting idea but unactionable, um because what flexible and- and inflexible mean are- aren't well-specified. So if you could send actual text for the working group to consider, that would be great. Paul.

**Paul Hoffman:** Paul Hoffman. Um, got up to say something different, I'll say it in a second. In response to Roman, I think if since IANA for every document that has IANA considerations including creating new registries is already sending out a message, I think if IANA just, you know, in this- if this goes through in this future simply says, "By the way, did you notice that?" and, you know, talk- talk about the two things. That could be extremely boilerplate and if the working group skips over their- the IANA letter, which they often do, then that's on them. But I think many working groups, many people in many working groups actually do read the IANA letters and might go, "Oh, we forgot that." Um, the reason I raised my hand is I really feel like we're getting away from what IANA registries are for. I have a big concern that people are saying like, "As long as the expert understands something, then it gets a registration." That's not what the registry's for. The registry is for the thousand or ten thousand people over the next 30 years who look in the registry. I don't believe there's any way we can say the- that what is pointed to in a registry will be understandable to everyone and such like that. We make a best effort, and that's why in the past some people said, "Oh, it's got to be an RFC," and other people said, "No, it doesn't, an internet draft is just fine, it's just as readable as an RFC." So it would be nice if we got away from- and again, I'll- I'll do a pass on the draft and see- if we got away from this concept of "it's about the expert." It's not about the expert. It's about everyone else and getting interoperability.

**Martin Nottingham:** Yeah, I agree with Paul, but- as an expert on a number of registries and one who works with a lot of experts, they- they- really need guidance. And often I think the guidance that we give them is- is pretty poor despite the- the things we have in place. I got up to respond to Roman. I think that's great. Um, I would love to help contribute to something like that because to me one of the most successful things we've done is these pre-packaged little nuggets of, "You're doing it this way, therefore follow this procedure," and I think we need more of that. Um, I think whether or not an internet draft is one good aspect of- of distinguishing there, but we have as- as we discussed in dispatch, people submitting GitHub repos as their specification references and random things on personal websites and some guidance about that because not all registries are the same. For some registries that might be great, in others it might be disastrous, but we need to get people to think about this when they're creating the registries and give them easy policies to choose from. So Roman, if you're interested I'd- I'd love to collaborate on that. 

**Ted Hardie:** Uh, it's great that the two of you will continue to talk about it. It seems like um- there- there are others who might have uh- comments that looked like Martin for- for example had comments on the name and I had as well, so um- when you guys are ready to send something to list that would be great. 

**Amanda Baber:** Yeah, we were certainly interested in the idea of- a tiered specification required but had no idea how to- codify that. 

**Ted Hardie:** Okay, um- so it sounds like it's not something that would- ruffle IANA's feathers if it were specified, it just- it would need- you know, is it binary, just IDs are now permitted, or is flexible in fact including other things that are considered reasonably- reasonably easy to find but not necessarily archival. Um, is there anything else on this slide? Okay. 

So uh- so this is a question for you that hasn't come up uh- on the list. Uh, this was the suggestion from Katen who recently had an issue with authors uh squatting on a value. Um, a lot of drafts will request, you know, a specific value or even sort of state that they will be using a specific value as if it had already been assigned. Uh, we ask them to please at least call it a suggested value for the time being and we point them to the early allocation procedure uh- you know as an alternative. Uh, however we're under the impression that the suggested label may not always register for readers, especially if the value just sort of appears in the middle of a sentence somewhere and not- not in a table. Um, when we do our pre-meeting reviews for- for documents on working group agendas and this year we looked at about 475 IANA consideration sections, I think... yeah. Um- so it's- it's fair to say that- that every- every meeting there's at least one draft that requests a specific value that has already been assigned to another document. It must have been available at some point but, you know, the registries are not static. So Katen recommended that 8126bis tell authors that they uh cannot uh- request or suggest or mention specific values until they have the assignment. This is something we would like to do, honestly, but never thought we'd get to ask for, um in part because we don't really understand whether there are good reasons for people to do it and we don't want to take away something genuinely useful or- or- or necessary. Uh, and I should note of course this does not apply to new registries, those are supposed to assign values. 

Um, so how we would I guess propose going about this would be to tell people that they can instead request early allocation, um or add a note to us, like a note to the RFC editor that tells us to please contact them about- uh- value selection considerations before we assign a value. Uh, they could maybe suggest a preferred range of values, I don't know if that would be problematic or- or how large the range would have to be, uh- or uh- they could use a- like a bespoke approach to suggesting values that's already been codified for their registry. Um, the only example of this I- know of uh- for sure is from a document of- of Carsten's that I think says for some core registries it's possible to- to preface a preferred value with something like TBC and- uh- you know please correct me on that Carsten if you're here. Uh, I believe there's some form of coordination involved and that's- that's- that's great if a group has committed to an approach like that that's under control. That's- uh that's great. Um, but uh- I can also add here that- that many values are being suggested because the ID needs an assignment for a registry that is being created by another ID and early registry creation would take care of a lot of these. 

**Martin Nottingham:** This arrangement's terrible. Uh- so don't worry about it, we'll- we'll sort it out later. Uh- so Quick has a solution to this one that I think you haven't considered here, which is kind of interesting. One of the things we observed in TLS in particular was we- I think we had a three-way collision between drafts and those- were- were squatting on code points and deploying code on the same code point, which was kind of disastrous. Um, but it was all because people were taking code points sequentially. And so one of the things we did in Quick was said, "If- you can suggest, and we suggest that you draw one at random." And then the odds of a collision basically go to zero, and um- it- becomes much more possible then for people to- to start using the code points uh without going through the coordination steps. It turns out that the early allocation process is- uh- cumbersome and annoying enough that a lot of people don't take that option even though they probably should, uh- and so encouraging people to take a random number was- was- pretty good. Uh, I don't think that solves some of the problems that Mark's having with for instance the well-known document where you have text labels, but I do think it works in the numeric case pretty well. 

**Amanda Baber:** Well, Quick- Quick is a large set of values and a lot of registries are maybe 16 or- or 255 or something. 

**Martin Nottingham:** Right. We've got- we've got two to the 62 code points to allocate from, so drawing a random number from that space is highly unlikely to collide. That's also true of smaller spaces like- uh- a lot of the TLS registries are 16-bit code points. And so um- random draws from that space would be perfectly acceptable as well in terms of collision risk, given the number of...

**Amanda Baber:** I didn't say 16 bits, I mean- I- I mean 16-15 code points, like values one through 15.

**Martin Nottingham:** Or whatever it is, yeah. Yeah, but uh- that's a suggestion that you consider adding to this document as well, um because I think in a lot of cases suggesting a code point uh that's been selected in that fashion is harmless. Selecting the next sequential code point from a list is almost guaranteed to collide with someone else, and um- that's- our experience from- from use of this. 

**Mark:** Mark Nottingham. Uh- yeah. Um- this- this topic makes me despair because I- I was just in a research group uh- uh meeting where somebody presented an experimental draft and they used the first value that was available and as you've said, even though there's an explicit experimental range for HTTP settings right next to it, so... and- and you know, we feel this really, really keenly with HTTP status codes. You know, people go off and they just choose a number even though it's a pretty constrained space. Um, one day we're going to run out of them. Uh, so the- the social forces here are- are- are going to be really hard to overcome. Maybe uh- we need to figure out some uh language we can use in drafts to- to vividly paint the- the dangers of just picking a value here. I don't know. But um- it's- it's going to be a hard push. And Martin uh also covered a little bit of what I was going to say as well that- that for- for numeric ranges this makes a lot of sense, but with a textual label, it often embodies the semantics and people get very precious about the name they choose, which I really wish they wouldn't get so precious about the name they choose, but they do. 

**Brent Zundel:** Brent Zundel. Um, the question was asked uh- about whether IANA can say no about the code points that are requested. I think allowing authors to suggest code points is a kindness and IANA should be able to assign whatever numbers work best and we should just get over it. 

**Amanda Baber:** Well, I think IANA has to say no if it's already registered, that's happened, right? 

**Brent Zundel:** Yeah, I think so, but I think making that the norm should be fine. Right, and just to make it very clear, any values that are listed in an internet draft are automatically always suggestions, they're never real. 

**Amanda Baber:** They're not always taken that way. 

**Brent Zundel:** I- I agree, but I'm just saying I'm in support of that. 

**Michael:** Hi. So one- suggestion, one question I got query about preferred range, I was un... I'm getting echo, I'll just keep talking. Um, was un... I didn't know how to answer it. So we had a bunch of- uh, I don't remember what it was now, but there was- um- they were CBOR things and they could be positive or negative and they were essentially equivalent, the same size, the same rules. And it was like, "Okay, am I supposed to pick a positive number or negative number?" And then I asked the designated expert, and I think that was Mike Jones, and he didn't know either. And so it was like, "I don't know what I'm supposed to answer to this," and that part IANA's asking me. And so I don't know if that means that we have actually a missing piece of information about whether there's any difference or- or what. So I'm happy to tell you what my preferred range is, but I- I didn't know in this case if there was a reason to- to pick one or the other. 

**Amanda Baber:** I mean if it's- if it's a clearly sequentially assigned registry, we'll just give you the next number, but if there are gaps, if it's- if it's a mystery then...

**Michael:** Well, I mean like so you can have one-byte numbers are negative one to negative 24 and- plus 24 and one to 24. They're the same size, the same rules, same consideration, and I was asked, "Do I want a positive or negative number?" And I went, "Uh, I don't know, give me whatever you want," right? So and that- that seemed to be a big- big deal to- to not have said so. And so um- I- I didn't know whether- whether registries actually should be saying, "Use all the positive ones first and then the negative ones," or- or- or do I- should I even know or care, I just say I don't know I don't care, and I didn't seem to be able to answer that way. 

**Ted Hardie:** I have locked the queue uh- just because we're beginning to run out of time and there are a couple more slides. I- I think this discussion uh- has taken us in some interesting directions, but I think the- one of the primary ones is that we should be encouraging people to use the uh early allocation and we should work on lowering the friction to early allocation so that the number of people who do use it goes up. And the rest of the uh- of the discussion is about what do we do if that didn't work. Um, and there have been a variety of discussions there from using random choice to lower the collision to let the devil take the hindmost, and we'll need to do that on the list. In the meantime, we have Michael and Barry. Michael. 

**Michael Jones:** All I was going to say is random doesn't work when uh- the space is differentiated, like CBOR values where uh- some are more shorter than others, as they say. And- and the positive-negative thing was uh- a Jim Schaad thing that I think is lost in history. 

**Barry Leiba:** This is Barry Leiba. Actually, random does work in the differentiated spaces, you just pick a random one within the range that you want. But that's not what I got up to say. Um, most of the registries I deal with um use strings. And clearly you're going to pick a string that you want, it's not just a suggestion, it's what we want to use. But by the time it gets published, that still can conflict with something that's been uh- done since. So we should make sure that when this text is finalized, we have something that says how you deal with it in that situation as well. 

**Amanda Baber:** Yeah, I have to say when I- when I wrote this slide this morning I was not thinking about strings. 

**Barry Leiba:** Right. Um, yeah. Thanks. 

**Ted Hardie:** Okay, so we'll definitely take further conversation to the list. Thanks everybody for contributions on this. 

**Amanda Baber:** It looks like a lot of text but there's not really uh- much substantive here. Um, the- the first bit is just under in this uh- um "Registry Creation and Design Practices" section we have that is basically tips. Uh, we- we now have a subsection uh- pointing out that uh- these URN sub-namespace registries uh- people ask for, uh- they'll- they'll often forget to make the accompanying registration uh- in uh- you know under `urn:ietf` or `urn:ietf:params`, especially leaving out the params part. Uh, so we need someone to check this for accuracy or for clumsy or inaccurate phrasing. Uh, and uh- maybe we also need to add a reminder that um- the URN formal namespace registry exists as well. Uh, I think we can skip the change controller bit, it's just rewarding. Um, we've- discussed specs. Uh, question um- an action for us is to go back and change, add the change controller field for- for uh first-come-first-served, uh expert review, spec required and uh RFC required registries since RFCs could- could be produced by different parties. Uh, those will initially just be blank. Uh, but we're wondering should the IETF be listed as the change controller for IETF stream RFCs by default, or should we leave those blank too, just in case? 

**Ted Hardie:** Uh, for the first one I'll take an action item to send uh the document and request a review to the `urn-nid` review list which has uh folks like Saint Peter and Dale Worley on it who would be the right people to make sure that we're getting this right. Um, for the next bit... Barry. 

**Barry Leiba:** This is Barry Leiba. I- I guess my opinion on the last item is that the best thing to do is to leave them blank and to say somewhere that blank defaults to IETF change control, but the fact that you're leaving them blank is a key that uh- we have not made an explicit decision. 

**Ted Hardie:** Jonathan.

**Jonathan Lennox:** Jonathan Lennox. Yeah, I was- I'm not sure I still agree with this after what Barry said, but I was going to suggest that maybe standards track RFCs be- put- marked as IETF change controller because informational might be like, "This is something one," you know, we decided to publish what one vendor did, you know, for V1 of the spec and then V2 is the, you know, standards track, which is a not uncommon pattern, in which case presumably the V1 would want to be the- the vendor, not the IETF. So uh- which might imply standards track is what this should be. But I don't know how that checks out in practice. Or we could just do what Barry said. 

**Barry Leiba:** Well, just- just responding to that, I think if- what would happen in that case is that if a change needed to be made, it- the first change would go through the IESG and the IESG would then assign the appropriate change controller at that point, and any future changes would go that way. 

**Amanda Baber:** We could ask, "By the way, are you the change controller?" So... 

**Ted Hardie:** Okay, I think uh- that's- that's good for that slide. And the rest is just um listing some more items I know we have and that we wanted to assign uh- on the next. Ready for the next slide? Oh, yeah. Thanks. Uh, so- so we knew as of- as of the beginning of the session, um we need- we need to write up uh what is happening with what the SDO uh procedure since that- that is new. Uh, 8126bis, um we're not thinking that this needs much more work, or- or we won't. I'd like to- very interested to see what happens with the specification required bit. Um, otherwise we're just thinking about editorial changes, really, splitting sections into subsections and such for- to make it, you know, easier to find things. Uh, and uh there- there- there requests from the group as mentioned, early registries, security considerations if anybody... I- I don't- I don't think- I- I don't know. Um, 8126bis. Uh, I think- I think we've covered uh- the next one. Um, provisional registrations. This came up on the list and uh- I think there was a suggestion from Mark uh- that- that we talk about how provisional registrations and early allocations differ, and uh- when to make it available. The thing is we- we don't know, so if anybody wants to take a shot. And uh- status field issues, I- I forgot to um- chase this down. There's- there's a- a little subsection that- that says, "Hey, by the way you could- you could add a status field." Uh, the last meeting I think- the- we were told um- you know, terms are used so inconsistently that- please do not suggest any terms, and that in fact it might be useful to present examples of- of terms that are used in different clashing ways perhaps uh across different registries. So... I guess I'll send email about that. 

**Ted Hardie:** Okay, you- you finished with one minute to spare, which gives me the one minute to say we're going to be looking for some uh opportunities to do working group last call on some of these drafts pretty soon now, especially uh- 7120bis and depending on what the outcome is of the- the decisions related to 8126bis, maybe that as well. So uh please, uh thank you to Harald for doing his high-level review. If you are interested in doing your own high-level review, do it uh- as soon as possible and we'll probably start thinking about doing that after we've made the resolutions to the questions that are going to be confirmed on the list after today's meeting. Jonathan. 

**Jonathan Lennox:** Uh, yeah, Jonathan Lennox. There was one other thing that was I think a mailing list issue I raised based on a thing by Harald, based on a thing by Murray. It's- uh but about whether the text about um the appeals process for experts is sufficient, and that didn't seem like it necessarily converged. 

**Amanda Baber:** Uh, yeah, no I didn't pick that up. Um, if you could uh resend that to the list, I'd appreciate that as it looks like I dropped it. 

**Jonathan Lennox:** Yeah, I'll- I'll just uh reply to the- to the thread and say this is the- you know, this is the- this is the thread I was talking about. 

**Ted Hardie:** Yeah. Sorry for dropping it. Is there anything else for the good of the order? If not, uh- the rest of you have a wonderful evening. Thanks. Enjoy the social event if you're going. 

*(Meeting ends at 90:52)*