Session Date/Time: 20 Jul 2026 09:30
[00:00:08] Murray Kucherawy: It's not remote either. You wanna start it? You wanna give him a minute?
[00:00:27] Ted Hardie: We can at least start the the master view if we
[00:00:30] Amanda Baber: need to.
[00:00:30] Murray Kucherawy: Oh, here we go. There he is. You wanna go? I can't get in. There we go. Good morning. This is the IANABIS excuse me. The IANABIS working group at IETF-one twenty six. Welcome to Vienna. I'm Murray. This is Ted. We're your chairs. Please note the note well well. As Barry likes to say, there are expectations that you are familiar with your obligations around code of conduct and rights and contribute to contribute excuse me, rights and contributions to the IETF. Also, procedures for running working groups and the Internet standards process are listed here. Please be sure you are familiar with all these. We presume that you are before continuing. Some meeting tips. Please make sure you sign into the data tracker or use the QR code in the session. Join the mic queue. You need to use the Meet Echo client to join the mic queue. Participate in shows of hands and other activities that are specifically through the tool. Please keep your audio and video off if you are using the on-site version until you're or accept to be queue manage in the queue. Remote participants, make sure your audio and video are off until you are actually interacting with the working group and use a headset use of a headset is strongly recommended. Some key resources. These URLs, I realize you have to type pretty quickly, but they're in the chair slide deck if you want to reference them. I believe we this is the typical list of things that we're looking for. We have done the note well. Agenda bashing is on the next slide. Ted mentioned earlier, we're looking for note minute takers to compare it to the transcription. We'll do chat relay. That's right. This is our current agenda. Is there any bashing that
[00:02:46] Ted Hardie: we both like to do?
[00:02:51] Murray Kucherawy: If not, we can move straight to our next item, which is Mark.
[00:03:08] Amanda Baber: I'll say next slide.
[00:03:09] Murray Kucherawy: Very good.
[00:03:15] Mark Nottingham: Good morn good morning.
[00:03:18] Murray Kucherawy: It's there.
[00:03:19] Mark Nottingham: Okay. So there's been some discussion, about specification required ongoing. We had some experiences when we're doing 6838bis, the media type registration procedures, and that kind of fed into this discussion. So I put together draft not draft Nottingham, ianabis-spec-required to talk about that. So next slide. So, yeah, one of the requirements for for specification required is that specification be permanent and readily available. And a lot of the concern or confusion in this space is, well, what does that mean? What counts as permanent and readily available? And depending upon the registry, you might get different answers to this. Next slide. And so, again, depending on, you know, where you're talking to and and and what the expert is is feeling on that day, different things might qualify for this particular bingo card. Sometimes it needs to be an RFC, or it might be okay if it's published by another SDO, which we've talked about before in this group. Or and and there's, of course, the ongoing question of, is it in that draft acceptable for a reference? Many times, you'll have submissions of a specification on a vendor's website. Increasingly, in the registries that I am an expert on, we have submissions from open source projects or from even people's personal web pages or in a GitHub repository, whether that's in an active project of some sort or just somebody's personal GitHub repository. Sometimes it's just a website, and you have no idea what's really behind it. Sometimes it's a link. Actually, I haven't yet seen archive.org or Scribd, but I anticipate we one day will. You know, there there's lots of variability here. And from the expert standpoint, you know, getting back to that permanent and readily available language, it's not clear, you know, what the real intent is. Next slide. The other is a requirement for for specification required is is that it's insufficient detail, so the interoperability between independent implementations is possible. Next slide. And so, that kind of brings out the the aspect that sometimes, at least in my interpretation, the publication status is is a proxy for other things. It's not just, can I get the specification again? It's, is it a reasonable quality specification? Is it, of course, available? Is there a level of community interest where there's a need for interoperability? Do you have implementer buy in and implementation intent or actual implementation? And are all the people who were affected by, you know, some domain of of of activity bought into this? Do they have some level of consensus? And it's not really clear, that that publication is a good proxy, but, you know, it does tend to be used.
[00:06:23] Ted Hardie: Next slide.
[00:06:25] Mark Nottingham: Finally, the other thing that kind of led me down this path was, that for some registries, and of course, this is not for all registries, but for some registries, there's also a scarcity problem. If if you have a registry of human readable names, so for example, well known URIs, then, you know, you have these questions come up of, well, you know, somebody publishes a specification on their personal website. We're on a brand new website that didn't exist two weeks ago, and it's a somewhat reasonable looking specification that may or may not have been created by AI, which is a different discussion. Come to my talk later this week. And, they've asked for registration of an extremely common term like ai.json or, you know, whatever. Should that be permissible? You know, by the rules, they have a specification. It's in a location that is plausibly permanent. It is plausibly interoperable, and yet they are effectively squatting on a term that has no demonstrated buy in from other implementers, community interest, interoperability. Maybe the answer here is is you need a different registry policy, but maybe it's just you need some more fine grained detail on what the registration policy is. Next. So this all led me to this proposal in the draft of of three sub policies for, specification required that one might choose from. The first is kinda you know? So they're parenthetical specializations of specification required. So the first is standards where you basically require publication by a recognized SDO. And so, you know, we've in in the other draft of the working group, we've already had this discussion of of of formalizing what used to be used just, I think, for media types into something more general. And so this would be basically you need to be published by one of those. The second is a community policy, and this is very much shaped by, the discussion we've had in 6838bis, which is you you have a a list of kinda guidelines for the expert to say, well, you know, do you see evidence of community buy into this? Do you see, implementer interest? Is conflicting with other work and so forth and so on? And you can look at the draft for that full list. And and the intent here is to accommodate, you know, things with general genuine community activity around them, but that might not be informal standards organizations, so especially open source projects, for example. And then the third policy in the draft, subpolicy in the draft is called permissive. And this is basically the, you know, more open season. If you've got a spec and it looks relatively permanent, and and we we're pretty sure we can retrieve it again, you're in, which is how some registries operate today. Next slide. So there are still open questions here, you know, especially around how a a a registry adopts one of these sub policies. The draft currently punts on that, and there's already been a little discussion on the list about that, I believe. It could be plausibly a decision of the experts using their discretion. It could be that, you know, the IESG needs to weigh in. It could be that you need to revise the RFC that establishes the registry. That's a discussion to have if we decide to walk down this this pathway. The other thing that I I you know, makes me think is is that that the the first policy, the the standards policy is easy to apply. You know, the expert looks up, is it an organization on this list? Yes. They are. No. They aren't. Proceed. The third policy, the permissive one, is also fairly easy to apply. You know, you you you may need to decide, okay. Is this permanent enough? But you can come up with a policy for that. The middle one, the community policy, does require some discretion, of the expert. They need to decide, you know, and characterize what the level of community activity is around something and whether that's legitimate enough to, justify a registration. That gives me a little pause. You know, I'm living through this right now, on a couple of the registries that I'm an expert on. I think, you know, the fact that we do have an appeal process, that we do have these things in place, probably gives that the amount of legitimacy it needs, but it does create workload for the expert. So that's something I think we need to go into with eyes open. Is there another slide?
[00:10:44] Murray Kucherawy: I don't believe so.
[00:10:45] Amanda Baber: Okay. That's all. Who
[00:10:48] Mark Nottingham: who's read the draft?
[00:10:51] Ted Hardie: Cool. Who has an opinion they'd like to bring to, the queue by using the tool to press the little hand button and then getting in queue? Oh, you're first.
[00:11:06] Murray Kucherawy: Yeah. You're the first contestant.
[00:11:10] Paul Hoffman: Paul Hoffman. I waited to see if someone else wanted to jump up. Can you go back one slide? Because I agree with you that the middle is the hard one. These are for when you use these for early allocations, which I think they would be just as good for early as for regular, The question of community adoption is extremely difficult because at least in places where I'm working right now, there is no community adoption until there is a a code point. Like, the the the developers are so busy dealing with AI generated slop that they aren't gonna even start until there is a code point, such like that. I would love to see more in this document about not needing adoption, but that then, unfortunately, goes even harder to what you said of it makes it even harder for the expert reviewer to say when should it be in. And I I don't have specific words. I'd be willing to if if other people are interested in this idea, I'd be willing to work some up. But one of the things to me would help that would help an expert reviewer for an early adoption based on a draft is, has the draft been discussed? Is there a thread with the draft's name in a working group or an IETF sponsored list? And is that thread more than five messages long? Has there been some discussion before? And I Martin is sitting here shaking his head no, so that's great. But different work different registries will need different Jesus. Specs. And I don't want this to be too prescriptive, but I also don't want it to be so loosey goosey that there is any pressure on an expert to accept something that they believe without any strong evidence hasn't been reviewed enough. And I'll I'll be specific about something that we had twenty five ish years ago in the crypto in various crypto registries is someone would say, here's an academic paper that shows how to do this algorithm, and then it would be accepted. And it turns out that the paper described how to use it in a use case that is not really completely what the registry was about. And now the world is stuck with it, and all the implementers had to actually frob their code because it audit had had automatically gone in. I want expert reviewers to be able to look at a draft or whatever and say, yes, that's there, but no, it hasn't been reviewed enough. Please come back showing more review. Thank you. Sure.
[00:14:10] Ted Hardie: So before before we go on, I'll just say we already have quite a long queue and amount of discussion time we have. So people who are coming up, Jonathan, please be crisp. And everybody who follows Jonathan, be at least as crisp as Jonathan or more. Thank you.
[00:14:24] Mark Nottingham: I'll I'll I'll resist responding to every point then and just answer questions.
[00:14:28] Eliot Lear: Jonathan,
[00:14:30] Jonathan Lennox: your proposal here doesn't directly address the squatting problem. Do you have a separate proposal for that, or are you just saying if we make it at least community, then we won't get people random people squatting? But you still might have a, you know, a community decide they wanna be a at JSON. So I feel like that might need a separate solution, though I think this is possibly also a good thing.
[00:14:51] Mark Nottingham: There there's a hook in the draft for for that. It it allows the expert to establish policy for names, for example, in the in the in the registry when when that's called for. And that's what we've started to do in in web known URIs, for example.
[00:15:07] Ted Hardie: Harold?
[00:15:10] Harold Alvestrand: Thank you. Hello. This is John. I think you slightly understate the need for, like, reference permanence. I mean, one of the purposes of spec is that when two implementations have done incompatible things, there needs to be some way to figure out which one is actually adhering to the spec. So, of course, if you have first come first serve plus plus policy that is which allows just about anything, that's not going to not going to help. I have unfortunately had a lot of implementations of draft o three of a protocol, which is incompatible with the version that got into an RFC, and we need to identify those versions so that we can tell what we're incompatible with. So permanence of reference is also an important property here. And that's one reason why STO publication is less problematic than the others.
[00:16:35] Ted Hardie: Mike?
[00:16:37] Mike StJohns: I think these are useful. I'm gonna throw one word of caution actually on the standard sub policy. That existing list, I've been on some telechats where we added something to that list with reasonably light review. And I I would be cautious about relying too heavily on that being a thoroughly vetted list and repurposing it for something else. It might be worth at least a cleanup pass before we say, yeah, we're comfortable doing that.
[00:17:14] Mark Nottingham: I can see that it might be useful, for example, to specify that some entries in the list are good for a certain registries and not for others.
[00:17:21] Ted Hardie: Mhmm. Elliot?
[00:17:27] Eliot Lear: Mark, thanks for the draft, and I appreciate that you have scars on your back on on on some of these issues. I think I wanna make two points. The first is that I'm not sure that everything you raised in terms of your problem statements is is matched up by the solution. In particular, the squatting problem to me, I'm I'm not sure that that quite is but we may be we may be solving we we may need to solve that problem in a different way. And and I think we should explore that a little bit in terms of do do we just need for specific registries, do they just need to tighten up what the what the guidance is to expert reviewers? Because it hits more than just specification required. Which brings me to the next point, which is think the working group would do well, I think, to establish some criteria around how to evaluate your draft. What the questions that should be asked in terms of even before we say, yes, let's do this or no, let's not. What are the what are the criteria? What are the questions we should ask about? Is this a good idea or is this a bad idea? And I think it would be good for the working take some time on that. And I'm willing to work on a draft, you know, with some others if people are interested to just say, here
[00:18:40] Jonathan Lennox: are the questions.
[00:18:42] Ted Hardie: Okay. Sue So people at the mic, remember we kinda have to eat the mic a little bit to be well heard.
[00:18:50] Susan Hares: Okay. Community is something that the IDR working group is looking at to try to handle the community, category is one I wanna speak to. Okay? And also, in that community category, the problems we've had with a lack of, permanence on the draft, links. We've actually worked with that and, trying to resolve squatting, one of the problems we deal with. We did have problems where anything other than an Internet draft doesn't seem to keep permanence over the scale of BGP time, which is in decades. Therein being a problem, I would prefer to see Internet drafts. Second point, what we'd like to see in community, because we're dealing with two or three drafts in this particular category, we'd like to see. We need to be able to we have two things. We don't wanna squat, and we want to get some of the things like extended communities out and at least if there are algorithms to define it, much like I'm sure media or something has. Because of that, we would like to maybe have, right into the policy, some mechanism to check IDR with something afterwards to at least give the experts some feedback and help. Okay? So I'm interested in working on how that might happen because we have two or three examples. Hopefully, that's short enough.
[00:20:35] Ted Hardie: Thanks. Rich.
[00:20:38] Rich Salz: Yeah. Two quick questions. I wonder what your opinion is of bringing back x dash or vnddot.
[00:20:44] Mark Nottingham: Nice try.
[00:20:47] Murray Kucherawy: You said two
[00:20:47] Ted Hardie: Does that mean no? That means no.
[00:20:50] Murray Kucherawy: Did you say you had two questions?
[00:20:53] Jonathan Lennox: No. Oh,
[00:20:54] Murray Kucherawy: okay. I get it.
[00:20:56] Ted Hardie: Martin.
[00:21:02] Martin Thompson: Richard was too fast. Martin Thompson. So I think this is a real problem, but I don't know that this is the way that I would suggest solving it. I dropped it in chat. I think we may have some legacy registries that are just screwed as a result of this, and we're going to have to look at registration policies around them and empower experts and iAnna to to say no more. And I don't know that we need strict rules around this, and and I do think that that means, unfortunately, to the point that I heard earlier from Elliot, I think, was that, yes, that is gonna put more load on the experts, and they're not gonna be able to look at the at the rule book and simply say that it works or not. But part of the point of putting an expert in place on those registries is that there's some discernment and judgment involved in registration processes. And as long as we give them support, then I think that that's gonna be reasonable. But I think, in a lot of cases, we're gonna find that it's gonna be necessary to move away from human readable labels and into things like numbers and opaque strings and nothing up my sleeve type assignment policies so that we don't get people asking for AI as an as an example. So, you know, unfortunately, some of these things are just broken.
[00:22:27] Mark Nottingham: I I think that's a very good piece of advice. Maybe we should highlight more strongly that, you know, if you can make it neutral like that, that that's that's a huge advantage. And maybe we need to walk into that more thoughtfully. As an expert on the coalface, I would appreciate guidance like this or like something else, but something to help me justify the decisions I make. It's extremely uncomfortable to be out there and making these decisions, and having people from the community judging the IETF on how I respond without stuff to back me up in those decisions. And I've tried to create, you know, some some registry specific policies and infrastructure infrastructure to support that and to illustrate what I'm doing, but I still feel like I'm out on a limb. And it's especially difficult when, you know, sometimes the community comes to us as experts and yells at us for exercising that discretion.
[00:23:24] Ted Hardie: Okay. Thanks, everyone, for the conversation. I think the conversation demonstrated that there's interest enough in the working group, to work on this concept. And I think the point that was made at the very end here ties this enough to other pieces of the main document that one of the other questions we plan to ask, which is whether there should be a separate document or text incorporated into the main document, is pretty much obvious. So our next thing is we will go to the working group mailing list to reconfirm this since it's the sense of the room here. But my sense of the room is that we that this text is the basis for further discussion in the working group for text into the main document, and that we will adopt the work, so to speak, rather than adopting the document because it's gonna go into the main document. So that will be confirmed on the list as an action item coming out of this meeting. Thank you very much, Mark. Next speaker will be Amanda.
[00:24:37] Murray Kucherawy: I assume that it got your that it's converted your
[00:24:39] Martin Thompson: most version
[00:24:44] Eliot Lear: by now.
[00:24:44] Amanda Baber: So Okay.
[00:24:45] Murray Kucherawy: If it happens to be stale, it just means it didn't get there.
[00:24:47] Amanda Baber: Okay. Glasses are not what they should be, perhaps. Okay, is this good? Okay. So let's see. The main thing this is not the main thing. Just reading so I don't go into a fugue state. 7120bis, we think this document is basically okay. So I'll just go over the changes since the last meeting and review what's changed since RFC 7120 and see if there's anything that still needs to be addressed. There is one change we do need to make. If a specification required subtype also needs to use it, then the document that converts the media type standards organization registry to a general STO registry should probably be 8126bis instead of this. Just to review what it's doing real quick, it extends the term of early allocation from one year to two. Most early allocations need more than one year. It adds missing descriptions of IANA practices, main one being that we ask for expert approval when the registry requires it, for specification required for any procedure that that needs RFC and expert review. This is a practical issue for us. We don't wanna add something to the registry, not request the expert review until IETF last call, and then find out that the expert wouldn't approve of something that's that's been in the registry for a few years. The big change is the addition of the area allocation procedure for standards organizations, which is for specification required registries only. It's it's essentially just like early allocation for IETF stream graphs. They can be renewed every two years. The only difference really is that the only people who can approve the registration itself are the experts. The ADs approve the standards organization, not the request. And they only approve it once. Changes since -01 to -02. Again, we expect to move this. But about the registry, the decision, you know, as as noted was was that we're going to repurpose the 6838 registry and turn it into a kind of general purpose registry. Organizations in it can can register standards tree media types and get early allocations and get standard subtype specification required registrations and and whatever else a registry might want to use it for. Let's see. The other changes I'm I'm not sure quite worth mentioning. When we initially proposed the SDO early allocation process, we thought people wanted those allocations to sort of have limits, like make them not renewable or tell them that they shouldn't they shouldn't request them until the the document is is ready for publication. But that was that was that was not what the group wanted. We were also trying to present kind of permanent allocations for a for a first come, first serve registry or expert review registry as a kind of early allocation. One of it's like a a subset of three early allocation procedures, but this was confusing. We moved it out to its own section where we say that although it can be described as early, it's not what people mean by early allocation. We also pointed out that we're not going to ask for working group approval if you're getting a first come, first served registration for your draft, but you lowercase should make sure the working group's okay with it. And that's the 7120. Should we move on to 8126?
[00:28:24] Jonathan Lennox: Sure. Okay.
[00:28:31] Amanda Baber: So the the biggest change we made in 8126bis is telling authors or version three, I should say. The biggest change we made is telling authors not to suggest or recommend or really mention numeric values anymore until they've been allocated. We used to just tell people to be really clear that this is just a suggestion, but we can't be sure that that's effective, especially if it's sort of buried in a paragraph of text instead of being a clear label in a table. And when we're doing our pre meeting reviews, we usually see one or two documents per meeting that are suggesting values that have already been allocated. This time, there were four documents doing this. So we're asking people to use TBD one, two, and so on, or suggest a range of preferred values, or add a note to us that asks us to check-in before we assign numbers, or just if it's appropriate, use early allocation. Let's see. The next few are minor. There were places we needed to add text about requiring guidance for experts, such as for RFC with expert review registries. This is a reminder we sent out a lot last week during our pre meeting reviews. We incorporated Peter St. Andre's URN sub namespace fixes. Somehow the document didn't say that the INA consideration section is required, although I think authors.ietf.org does. So we added that this is required for drafts. We'd like it for all RFCs, even ones that that don't have actions. But, you know, we just so we know nothing was missed, but but don't don't wanna argue for it.
[00:30:01] Ted Hardie: Mhmm. We have a couple of people in queue now. Do you wanna take them now or Sure. Those people are in queue. We're gonna go ahead and take you now. So Sue and then Martin.
[00:30:22] Susan Hares: IDR was the one with the four ID drafts and 12 error values. We hit that due to a lack of the early registry issues. My fault. It's we've tried to make it very critical to the people be because IDR requires two implementations before you can go to standard. So there's a catch 22 unless they can get preallocation of values. So I really appreciate how Amanda has added to it and the kindness and grace she has given to us as we tried to fix our problem. But I if anyone wants to know how painful it is to back it out and why you need this language, contact me offline.
[00:31:32] Ted Hardie: Martin?
[00:31:40] Martin Thompson: Yeah, Martin Thompson. The first point on this slide, we talk about requesting authors not to suggest or request values. To the point from earlier, if we're going to move to registries where you might, for instance, like to deprive authors of the choice of something sort of structurally, that's sort of incompatible with that. And I think it's also incompatible with practice that we see out there, where people, well, who was it that said the internet runs on internet draughts? It becomes impossible to do experiments that then sort of leak off into actual practise. And we've had a lot of experience with protocols that see significant deployment before they reach the RFC editor queue for various reasons. Some of those reasons being that the IETF is fantastically slow. So I'm not sure that I like the reasoning behind this one and think this may be a little bit too absolute. So I'd like to sort of just flag that as something that I would contest.
[00:32:50] Ted Hardie: Can you send suggested text?
[00:32:53] Martin Thompson: I'm actually kind of asking for the opposite here, which is to say that requesting a code point is good, aside from in certain cases. And those certain cases are, I guess, the ones that you see as being most problematic, where we have the three way collisions in TLS on the same code point, and trying to avoid that. But if you have a structural system in place for doing that, then it's a good idea, in fact, to suggest a code point.
[00:33:23] Amanda Baber: Right. It sounds like we need to add some text that allows for, if you have a system in place, such as with QUIC. What we're mostly running into is the next value is 13 at the time that they wrote the first version of the draft, and now, you know, we've assigned up to 16 or something like
[00:33:39] Eliot Lear: that.
[00:33:40] Martin Thompson: Yeah. So the the collision problem is a real one, and particularly for small registries. I think I think the guidance remains strong for a registry that has, for instance, 256 code points. I think anyone building one of those today is nuts, but we we we have tons of them in existence. But once you go beyond that and have systems in place to deal with the collision problem, it is in many ways much better not to to rely on Diana to allocate the code point.
[00:34:10] Amanda Baber: Yeah. Happy to add something.
[00:34:13] Ted Hardie: Elliot.
[00:34:19] Eliot Lear: Hi, Amanda. Thank you for the for the work on these drafts. The the issue I have is sort of my perennial one as in in terms of 7120 bis in particular and allocating code points to Internet drafts where you call it early but it may not actually be a temporary registration. You have some text in section 3.1 on that. If we're gonna go down that route, and I'm I still have grave concerns about it, but if we're gonna go down that route, then the IANA require I think not so much the IANA up, but the implementer requires an understanding of whether the next version of the draft, whether the code point is still usable for the next version of the draft and the version after that and the version after that. Right? And because you get into ambiguities around what's changed and whether the behavior change requires a new code point or doesn't require a new code point. And I think we need some tooling around that if we're gonna go down this route to say, okay. You submitted a new draft. You have allocate you you have an early allocation. Is that early allocation still valid for the for the changes that you've made between versions? And somewhere we need to capture that.
[00:35:38] Amanda Baber: So you're referring specifically to the the first come, first served expert reviewings that are that are permanent?
[00:35:43] Eliot Lear: What if if something is an early allocation, quote unquote Mhmm. And then there's a new version of a draft, and it's and and then at some point, we we've lived with the idea that if it's an early allocation, you know, you get what you get because you're a developer and you should pay attention, and maybe you need to provide feedback that, oops, something's changed and you have to change your code. But if something looks more like a permanent allocation, right, and there's some text in 7120 that says this begins to smell more like a permanent allocation, and the maybe there actually won't even be an RFC out of this. Right? Same old problem as we've discussed. Right? Somewhere along lines, if there is a new out if there's a new draft out there that comes along later, right, if there there could be incompatibilities with the with the existing code point. The question is, do you need a new code point to to to allocate out? TLS is a perfect example. You're if you've made a change in a working draft, you you have to go back and look. Did did things break? So now people working on TLS, they're gonna notice. Right? But at least there, we know it's gonna end up as an RFC. Right? In some cases, things won't. The developer might still wanna use that work. At that point, they need to know, oops, you know, things change between version a and version b. And this goes back to the whole draft discussion. And I think 7120 sort of steps on that with with that comment that you have about, well, if it's permanent if something can be permanent, you add this note to the IANA. I I I think we the seven 7120 doesn't sit well with me on that on that particular point.
[00:37:24] Ted Hardie: Okay. So that sounds like this was this whole comment then was for the previous document.
[00:37:29] Eliot Lear: And Yes. Because we moved on rather quickly.
[00:37:31] Jonathan Lennox: Yep.
[00:37:32] Ted Hardie: Okay. Let's let's take it to the list then. And if there's specific additional comments you can make about what tooling you think is required, that might be something where a good list discussion on that might be helpful. Thank you.
[00:37:51] Amanda Baber: Slide. Current slide, actually. Okay. No. So squatting is the main issue here. The next few are minor. There's places where we needed to add text about requiring guidance for experts. Oh, sorry.
[00:38:06] Jonathan Lennox: Sorry. Yeah. I just I mentioned this in the chat, but I thought I'd say it out loud here. While I understand I mean, just going on the requesting values thing, I just give the example of, like, having the author not be able to suggest the name of a new HTTP header field would be really weird.
[00:38:22] Amanda Baber: We should specify numeric values. Yeah. Yeah. Yeah. Exactly.
[00:38:25] Ted Hardie: Yeah. So you notice it goes the other way for error codes. Right? People get an error code, and then the semantics eventually get attached to it, the point that if somebody says four zero four in chat. Yeah.
[00:38:37] Jonathan Lennox: Okay. Yeah. I think yeah. So it's yeah. I think, yeah, numeric and textual are very different categories here, I think.
[00:38:41] Murray Kucherawy: Yeah. And so
[00:38:42] Jonathan Lennox: I While textual has a little bit of the issue that I'm not mentioned with the squatting, that's I think not as nearly as likely as in these as in most I mean, I don't know. But I think, yeah, numeric is different than textual, definitely.
[00:39:03] Amanda Baber: Okay. Yes. We'll fix that. Other than that, let's see. We've got addition adding adding more text about requiring guidance for experts. This is this is something we had to tell people about quite a bit. Let's see. I think we did Okay. We've that editorial improvements moved. I'm sorry? If I must, let's see. There's just one big editorial change. We moved all of the registry creation stuff into one giant section two. And the registry update sections all kind of got piled into section three. This was in version two. That's it's going to make diff between this and RFC8126 kinda difficult to read. But that was that was a plan that Mark McFadden basically drew up for us, I'd say. Other than that, we're just trying to mostly focus on making this document easier to use, breaking stuff up visually with subsections and bullet points where we can. So next slide. Let's see. Specification. We are assuming that that marks draft is is is going to have the next version of of specification required in it. We just need to figure out what still needs to be in our document. We would very much prefer that this be a separate document, actually, so that if adjustments need to be made, it can be done easily. We're assuming we need to move oh, oh, right, right. Our big a question for us is how existing specification required registries can have a subtype assigned to them. Our preference would be that this not require an RFC. We've certainly made registrations where we've listed an IESG statement or a link to a Telechat minutes as the reference. For us, it would be ideal if something like that can be done or if it could be something simpler. I don't know. Other than that, we need to bring in the standards registry from 7120bis. Clean up examples. Registration procedures need some examples that come from RFCs that have INA consideration sections we're happier with. We should keep some. We'll ask for confirmation that any new registries we want to add are actually good examples of those procedures. And we need to clean up references, add links to registries.
[00:42:09] Ted Hardie: You have a question. Mark? Oh, okay.
[00:42:16] Amanda Baber: Let's see. Questions? This main question has kind of been addressed. So for first come, first served requests, we may not realize that we need to flag certain kinds of submission issues for the ISG, like some volume of inappropriately generic string requests. If somebody's submitting, like, irrationally formed requests or or requests for a large number of numeric values, we can we can ask the ISG for advice, but we're not necessarily gonna recognize a content problem. That's not easy for the IANA consideration section to describe to us. So we're wondering if we maybe need some text in first come, first serve that says, if you could imagine this problem x being an issue for your new registry, maybe first come, first serve is inappropriate. Also, experts may need to be given grounds to reject certain kinds of requests that that registry designers may not be anticipating. I mean, it's kind of a broad ask, but wonder if people could go through the procedures that don't require an RFC and see if there's something not covered there that you want authors to think about before they choose that procedure, whether it's guidance they need to give experts or restrictions to place on registration eligibility or whether something just isn't an appropriate procedure if x, y, or z is a concern because we're not equipped. The other two questions could really be brought up on the list. I believe that IESG prefers that RFC twenty one nineteen keywords not be used in the anti consideration section. We agree they don't make sense to us. So should we record this here? It's also a decision not to use them in 8126, if not an earlier version. And the last question is just moderately trivial. A closed registry section 3.3 says, can be marked as obsolete, an indication that the information is no longer in current use. And it specifies that obsolete registries are closed to new registrations. Do we want to say the registry can be deprecated? What would that mean? Would it continue to be open? That's it.
[00:44:28] Mark Nottingham: Mark Nottingham. Yeah. Regarding my draft, I do not have strong opinions about whether it should be in 8126bis or not. And I I think it's extremely reasonable to say that if if if we are going to take the approach of, you know, effectively sub policies, that that having that flexibility to revise them because this is a fairly new thing is entirely reasonable. That would give us some time to figure those out. So I I would I would support keeping it as a separate document. And regarding the the land grab squatting issue, that may be something that might be more effectively addressed in 8126bis, and maybe we should spend a little time thinking about that. My initial approach would be maybe to pair some advice to document authors when they're defining registries with some guidance to experts for or at least for the expert registries in terms of empowering them to establish policies in consultation with the area directors or or whatever we come up with there. Because because yeah. It's bad.
[00:45:42] Amanda Baber: Paul. Paul
[00:45:44] Paul Hoffman: Hoffman. This goes to the discussion of do we move Mark's draft into 8126bis or not? If we don't, if and we take the extra time and such like that, this working group needs to acknowledge that 8126 bis will have a bis to it. I know that some working groups generally don't like that. Oh, we just finished and such like that. I I'm fine either way, and I like taking a lot of time. I believe that we're we're gonna have more time. So I believe if we do Mark's documents separately and more slowly, just as long as the working group admits, yes, we're gonna be updating 8126bis, that's great.
[00:46:24] Ted Hardie: So it looks like you have a a clarifying question.
[00:46:27] Mark Nottingham: Yes. Why would it need a bis?
[00:46:30] Paul Hoffman: Because we have separate document. Parts of 8126bis just know? It would be a separate document. Yeah. That's what I'm saying. It's a separate document that is a bis to eighty one twenty six.
[00:46:40] Mark Nottingham: No. It
[00:46:41] Ted Hardie: just it just opt in.
[00:46:43] Paul Hoffman: You think you can do that cleanly, great. Let's talk about that offline. I don't think you can do it cleanly enough to just do a simple update. We'll see.
[00:46:51] Amanda Baber: Okay.
[00:46:54] Murray Kucherawy: This is Murray just from the floor. I'm partial to saying twenty one nineteen keywords like you're saying or should not be used in IC sections, and I'm happy to contribute text to support that.
[00:47:16] Jonathan Lennox: Jonathan. Yeah. Jonathan, next I'm not sure there needs to be an explicit policy about obsolete or deprecated registries. I think if a group bot says that this is for a deprecated protocol, they can have that be in the instructions to the expert or whatever saying, this only applies to the old protocol and don't register this for the new protocol. There doesn't need to be an IANA specific tag for that. I mean, maybe they could change the name of the registry to, you know, protocol you know, registry for deprecated protocol x, but I don't know if that needs to be, like, an explicit tag that I that needs to be in here. That looks confused. Do disagree with me?
[00:48:06] Ted Hardie: So if you don't mind my asking a clarifying question. So, like, I I was the designer of a registry for SWAFT template types, which have gone the way of the dinosaur. Mhmm. So is your proposal there that you would update the the registry to say
[00:48:23] Jonathan Lennox: I mean, if something is actually closed, like, you know, you don't use it don't use it no. Actually
[00:48:28] Ted Hardie: Yeah. We actually closed that one. It said
[00:48:30] Jonathan Lennox: Closed is closed is closed. That's why. And so you you're talking If something is you know, you still want registries to be possible. You know, like, you know, this is you know, if we actually succeed and, you know, the sunset four succeeds and people, you know, five p v four extensions, but people still won't wanna register those. That would be you know, this is only for you know, the expert's job is to say this is only something for for a deprecated protocol and figure that out, and you're doing new stuff you would overhear instead. But
[00:49:00] Ted Hardie: Okay. I'll talk talk to you offline Okay. Because I think I'm a little confused.
[00:49:04] Jonathan Lennox: Closed is closed. Yeah. If you're not read accepting new registrations and forward anymore, that's fine. But I think if you are accepting new registrations, that would be a registration policy.
[00:49:19] Susan Hares: So this is a question, not a comment. I'm now confused what the difference is between obsoleted and deprecated. I thought I know what we had an example to do. For example, there are cases, Amanda, where we've deprecated registries because we're no long, we're no longer doing it or reformatting it. If it's obsoleted, how is that different? If you would just repeat that because I'm I'm it's a very important difference Mhmm. To what we do.
[00:50:03] Amanda Baber: So 8126 said we brought it up and nobody really wanted to write, I think, longer definitions. Obsolete is described as no longer in use. Deprecated is described as use is not recommended. And there's a paragraph here that says, for a registry, if you're going to market obsolete, it's no further registrations. But it doesn't say anything about deprecating a register.
[00:50:35] Susan Hares: The difference is important for the the work we're doing. So if it's deprecated and we've changed the version on the feature, that wouldn't apply because the old feature still is deployed and the new feature is your flow spec v one to flow spec v two. Okay? Eventually, we won't add more to flow spec v one, but it'll still exist. So it's not deprecated. Flow spec v two, we're taking the values and put it. So I don't have it deprecated in either case. But if I we are changing, forty two seventy one bis, we are going to replace forty two seventy one with the bis, some things might be deprecated, but I can't see where I get a deprecated registry in that. So what's an example of a deprecated registry? I understand Ted's deprecated.
[00:51:41] Ted Hardie: So let me give you a quick example. Or, Mark, you have one? Go ahead. I'm Mike.
[00:51:47] Amanda Baber: I I just confused.
[00:51:48] Mark Nottingham: So I I came up to to test my understanding. So this this will be good. So we had an HTTP workshop last week, and one of the ideas that was floated in discussion was that maybe we're done with HTTP methods. We don't need anymore, and we'd like to close off the registry to new values. Would that be deprecated?
[00:52:10] Amanda Baber: I well, this states that if it's obsoleted, it's closed. If it's closed, it's closed. You can close something without marking it obsoleted.
[00:52:19] Eliot Lear: Okay.
[00:52:19] Amanda Baber: We wouldn't we absolutely wouldn't stop you from marking it deprecated. We just wouldn't know what that meant. Right. I've we have one here in SIP registry identity info algorithm parameter values. It's described as deprecated and closed.
[00:52:35] Ted Hardie: K. So let let me see if I can give an example. SSL obsoleted. Right? No no extension possible to that. Any registry associated with that is closed. TLS one dot two deprecated. Still exists. We know it's in the wild. We don't want people extending it because we want them to be working in one dot three. Right. But the registries aren't closed because there could be some situation in which they needed with the appropriate action to to add something to the registry. So, I think for the protocol side, we we kinda know the difference on what the registry side would be. Anytime you mark something deprecated, you assume at that point that the friction you're gonna get from the designated expert is very, very high indeed. There has to be a demonstration that this gets pried open quickly and this added back in, where in general, that that's not gonna be permitted. Where with obsoleted, there's no possibility of prying it open ever.
[00:53:37] Amanda Baber: Okay.
[00:53:38] Mark Nottingham: It it seems like there's a lot of conflation of the status of the protocol elements and and whether we want them to be used versus whether we want the registry to be used. And and while that's often coincident, it's not always.
[00:53:52] Ted Hardie: So
[00:53:52] Amanda Baber: So a registry you can simply close without declaring it obsoleted. We could probably be more clear about that.
[00:54:04] Ted Hardie: Any other comments on a one twenty six bips? Any other questions for the working group?
[00:54:19] Jonathan Lennox: Do you have any?
[00:54:20] Amanda Baber: I think so. Okay.
[00:54:23] Ted Hardie: We have five minutes to go. And from the chair's perspective, I think we know what we need to do to get to the next steps of the document. I do have a question for the working group. We have discussed a couple of times in the past possibly having a virtual interim to try and make progress between IETFs. The time between now and the next ITF is fairly long because it's in November. Is there any appetite in the working group for a virtual interim to try and make progress, or do we just think we can do what we can do on the list and act that? It's always morning somewhere, Mark.
[00:55:05] Rich Salz: I'd ask Amanda if she thinks there's gonna be discussion topics or if she thinks everything is clear and we can see what happens after the drafts come out.
[00:55:16] Ted Hardie: Do you wish we'd had an interim in the last couple of months?
[00:55:19] Amanda Baber: Well, I mean, we've got the specification required draft now. And I I think the the thing we'd like to see is if anybody has anything for experts I mean, not expert, registration procedure text.
[00:55:37] Ted Hardie: Okay. I'm not I'm not hearing hearing a groundswell of yes, absolutely. So we'll go to the mailing list with the action items from this working group meeting and see if things come up that seem like it would be better resolved with a virtual interim followed by confirmation on the list as of a as opposed to just list discussion. With that, I think we're done. Yep. Thanks everybody for your time today. Much appreciated, and see you around the rest of the ITF.
[00:56:31] Murray Kucherawy: Are you still the DE for well known?
[00:56:35] Ted Hardie: Remember you're on a house link.
[00:56:36] Jonathan Lennox: I'm on a
[00:56:36] Amanda Baber: house link.
[00:56:36] Murray Kucherawy: It's not a Google. There's a document that's trying