Internet Engineering Task Force 111, 29 Jul 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF111-DNSOP-20210729-2330

Description

DNSOP meeting session at IETF111
2021/07/29 2330

https://datatracker.ietf.org/meeting/111/proceedings/

A

All right, it looks like it's 30 minutes after the hour, so I this is tim and I figure we can get started.

A

Because we're all looking forward to this part of it um welcome to the second session of dinasopp.

A

Tim benno and suzanne you both heard them on the audio for a few minutes ago. um Paul's taking minutes again, the jab room is tied into meat, echo, which is actually very nice in many ways, um the notewell for you, folks that haven't seen it. Yet by this time of the week, please read it or if you have any questions, just ask one of the chairs or ads.

A

So yeah they're gonna shift the order around a little bit um and we can discuss this if people have any objections to it or anything like that or do a little new business. First um schumann wants a few minutes to talk about this. uh His new draft- um and I know that sort of raised some questions this afternoon.

A

So if folks have any sort of bashing to do on that, please speak up speak up now, um then, what we're going to do is um we've got a liaison reply to the iso statement on private use, tlds suzanne's going to present that, and some proposed next steps.

A

um They'll do those sort of in a combined fashion and then we'll break down and talk about some of the prioritization of the working group activities, including a discussion um as to what's going on, as that so um so saying that we can, um with with nothing to say um we'll just jump in this um schumann.

A

B

Schumann, you can just unmute yourself and stick yourself on video. You have to wait.

C

Okay was that to me uh paul thanks? Okay, so um uh I know there's some concern about taking time away from the work prioritization discussion, so I'm gonna be very quick. uh I'm discussing a new draft that describes an enhancement to the so-called black lies authenticated denial of existence mechanism, I'm using the term. That's widely known to describe this method, but I want to focus today on the technical content of the draft. Folks can propose other names afterwards.

C

So please, let's not do that right now, please and next slide. Please, let me start by quickly describing the mechanism for those who aren't aware of it. It's documented in an expired internet draft from 2016 and as far as I'm aware, has never been proposed to be published as an rfc in any category.

C

However, it is becoming widely deployed amongst the online signers. There are now three major commercial dns vendors that use it use it cloudflare, of course, the originator ns1 and more recently amazon route 53 and what it does is effectively eliminate. The concept of nx domain, which, as it turns out, has some implications next slide. Please.

C

So, for a name that doesn't exist which would normally elicit an nx domain response, it pretends that it does exist but doesn't have any data associated with the type you queried. For that's to say, it returns a no data response, so status code, no error with an empty answer section and the rationale is twofold: you have more compact answers.

C

A signed, no data requires just one, an nsec record and its corresponding rrsig and better performance. You just have to do one online signing operation for the nsx signature and, by contrast, a typical annex domain response requires up to two nsec records and if you use nsac3 up to three nsec3 records and they're associated signatures, so that's larger responses and more computation to produce those responses.

C

Next slide, please!

C

uh So what operational implications does this scheme have for normal end, user applications? Probably nothing. The effect of a no data response is treated identically to an nx domain. In almost all cases, however, there are a variety of diagnostic tools, traffic, characterization tools, etc. That may need changes to effectively deal with this rather strange protocol. Obviously the first example that comes to mind is things that plot our code: distribution of dns traffic.

C

Many people do that so they'll see almost everything is no error from these signers, since our code, 3 just doesn't exist here and to give another example, from my day job, we have dns record provisioning tools that need to precisely determine nx domain. They have critical safety features that prevent you from say, creating a zone cut or installing a d name at a name that does exist to prevent accidentally occluding everything at or below that name and lack of this safety features actually cause production, dns outages for us, and we need this stuff to work.

C

So arguably, the r code should not be used for these types of checks because, as we all know, it's unauthenticated and could be spoofed, but then what we need to do is to infer non-existence by looking deeper into the payload of the dns response, specifically at the signed, insect records and figure out whether this is sufficient or not to detect non-existence. So next slide. Please.

C

And the answer is almost here's. What an nx domain response looks like from this protocol, so I'm querying a name that I know not to exist, nxd.blah, etc, and you can see the response code is no error, not nx domain. So how might we infer that this name actually doesn't exist?

C

Well, the obvious way is to look at the type bitmap in the nsec record and see if it has any data record types associated with it, and we can see here here that it only has the nsx metadata rrsig and nsec, but is that good enough next slide? Please.

C

Not really because if we query an empty non-terminal name which positively does exist, as in this example, we get an identical response. The we get exactly the same type bitmap as you can see the bottom right next slide, please so, there's no way to distinguish nx domain from mt non-terminals in the spec as originally written.

C

Our proposal, then, is that these implementations, and only these implementations, add a new synthetic rr type to the nsec type bitmap to signal the presence of an ent and that will immediately allow you to you know precisely differentiate nx domain from this case of non-annex domain, so this is deployed in the field already by one commercial, dns vendor and I'd like to acknowledge yamchalak, who I work with to make that happen, and I'm also speaking with a second vendor about implementing this next slide. Please and to make it more concrete.

C

Here's a real example of this enhancement in action. I query the mt non-terminal that I have here cleverly named ent1.sftcsd.net and, as you can see, we have this additional synthetic r type in the type bitmap currently we're using a number from the private use or our type range.

C

We could and probably should ask for an official allocation from ayanna next slide. Please, and if you're interested, I have some simple sample code here to infer nx domain from the bl type bitmap and next and lastly, what should we do next, so whether the itf dns up crowd likes it or not? The bl mechanism is deployed in the field today and potentially will be widely used because, as I mentioned, there are three big dns vendors doing it.

C

So it seems to me that it deserves to have a stable, published reference, not just an expired id. We did inquire with the originator, maybe a year or two about their draft and didn't hear back. The ent enhancement that I just described is also deployed in the field and should have a published reference for that same reason.

C

Now, due to the fact that this protocol contorts the semantics of annex domain egregiously, one might say, I suspect that the dns crowd will not bless this approach, but maybe I'm going to be surprised.

C

So I was thinking informational rfcs via the independent stream, could be the most fruitful course of action to pursue, and we could even combine the original protocol description into my new draft and then we just have one document to publish. So what else we could let this draft expire as well and call it a day, and with that I will stop.

A

Go ahead, victor support.

D

Either informational or standards track. This looks like a good idea.

C

Okay, okay, these are those are two radically different things, though right, but okay thanks.

A

Victor yeah peter.

E

Hello, I know I argued against bullet point 2 earlier today on the list, but then I found myself arguing 4 bullet points 1 on the chat just now. So I guess I stand behind bullets point for a document that describes, although all of these things that are happening, because it is important for any developer to know that these are happening, and I I'm as a resolver vendor that it is important to understand what is happening in the black lives area. So we don't pollute our insect aggressive catch with those.

E

So I like four. I have no uh no opinion on point three, because process is unclear to me.

C

Okay, great yeah thanks peter, so I think I agree. Generally I mean one of the problems I've had is uh when I talked to savvy dns engineers in my company. They're uh often surprised by this behavior of uh you know the vendors that do these tricks and then I have to explain what it is and then uh I have no like stable documentation for uh to point them to right to even describe what's going on.

E

Yeah there's a cloudflare blog post from years ago that isn't quite good but doesn't describe exactly what everybody else is doing and there's the additional confusion that when you query without the dns okay bits that cloudflare does actually return an x domain. So many things about it are confusing. So I do agree that some stable reference would be very good to have.

C

Okay, great, thank you peter joe.

C

uh We I can't hear.

F

G

Here you go, oh no, oh! No! I can oh now. I can oh good, okay, good, no idea why that is anyway. um I don't think it's actually very important whether we think this is a good idea. I think it's far more important that it's being used and it's confusing and I think a document is good.

G

I think the working group should take this on, although I hesitate to say that, because I know the working group's already got a lot of documents, they're struggling to make progress on, but um I do agree that it should be published just because it's being used, it's deployed in the wild and it's nice to have a reference when people are confused.

C

Okay, thank you.

C

C

I don't know if paul is talking, because I can't hear him.

H

C

H

Sorry about that, um I agree with the previous two speakers that we should do this. We should do this in a working group, um since it's mostly documenting existing practice. It shouldn't be too slow to go through the working group because we're really just writing what's already there. um I would request that we not call it black lies and come up with a different name.

C

Sure so we are going to do that and I think uh joe you're going to come up with an alternative name for me, but we'll work on that.

C

Okay, so I'm gonna relay something that was just uh sent to me um and it looks like cloudflare is on board with uh renaming and helping to publish. So that's that's good.

F

uh We're closing the queue.

A

I

Just wanted to say that, as the author of the indiana considerations rfc, that, since this needs special handling, uh it requires the standards action to assign an rr type for this purpose.

I

It cannot be handled as an unknown rr. I don't think maybe my opinion.

C

Okay, uh thank you donald we'll have to figure that out. I guess joe.

J

C

J

In the queue again or.

C

K

Brian, uh sorry, I'm I guess when I was reading the uh the draft, it wasn't clear to me and then going back and looking at some of the related items, uh whether this is also being done by these providers for insect 3 or if it's only insect, because I think insect 3 has a slightly different uh behavior in terms of how it treats ents. And that was what originally caused me to post the list.

C

Right yeah, so uh so my understanding is that this mechanism only use enzyme uh insect, epsilon functions and sector is more complicated. It requires more records, so they chose not to do that.

C

F

L

That's all I have yeah. I can just address that last point very quickly. There's no benefit for using nsec3. uh This already hides. This already prevents his own enumeration. um So there's no real there'd be no reason to apply anzac uh three. um I just wanted to push back against the idea that we're just going to document an existing protocol or some part of dns.

L

If we're going to adopt this as a working group item, then it needs to be a proper working group item and we should be allowed to change it or improve it. I don't expect many changes because it is in production. It does seem to work. We use it at ns1 as you as you pointed out, um but I don't want to end up with something like um edna's client subnet, where it was sort of like uh well just adopt what it is and we'll fix it up later in another version which will never happen.

L

So that's uh that's my feeling about that.

C

Okay, thanks shane.

C

Right. Thank you folks,.

J

Yeah. Thank you, shimon.

J

ah Let me move the window around and I guess I'm next great everybody's favorite um just to set the stage um this is the this is going to be a very process, oriented update on the situation that we have around this draft.

J

The chairs have because it's a process, heavy kind of kind of activity. The chairs do have a specific role and we've been working with our area directors and with wes as a member of the iab, to keep the process on track, but the working group will have to decide what we'll do with the situation we have. So I'm going to go through the the process pieces first and lists where we are with with various options for how to proceed, because no decisions have been made and no decision can be made without the working group.

J

um As far as what to do with the information we have. um The editors of the private use, tld document have some comments to make on how we might proceed and we wanted the chairs wanted to see how people feel about where we are. But this is largely a process and sort of informational update and we will proceed. We will continue to discuss the implications next slide. Please very brief history. um The private ucld draft introduced late in 20 2019 adopted middle of last year in the midst of a in the timeless covid time.

J

um The basic idea we had discussed before, I believe in dnsap to acknowledge the use of quote private tlds, which is a terrible term.

J

As you know, most of us most of us are familiar um outside of the public dns and the idea was to minimize damage of these uses of the public dns outside of the public dns by indicating strings that seem safe to use for this kind of purpose.

J

The draft proposes to add around 40 of user assigned alpha 2 codes to the special use names registry and that's where the process comes in, because iso 3166 is maintained by another standards. Development organization, beside iso tc46 and dennis out sought guidance on whether the user assigned list was stable and otherwise suitable for this use.

J

The iab administers liaison relationships on behalf of the ietf, including to isotc46, and the iab composed an appropriate question in a liaison request, and the liaison manager was asked to follow up and there's a reference here for the. Where that that's online, the liaison manager has offered written advice to the working group, including an assessment of why we should not expect a formal response and why we shouldn't use the proposed strings as private tlds. Now this is a communication to the chairs. We get to decide what we make of it. Next, please.

J

Again, no decision has been made on how to proceed, but- and we do have to consider where we are at the moment, unknown what alternatives we might have to accepting the advice. John clenson was liaison manager that handled the communication.

J

We forwarded his letter to the mailing list, in particular the reason given in his analysis, for why there isn't more of an answer from iso tcp 46 sounds structural, not circumstantial or procedural.

J

I want to emphasize at this point that this kind of communication is well within the prerogatives of any standards development organization regarding a standard they maintain, including, as john described, the itf itself, just for example, the iutf has no way to answer such a question. Besides publishing a new rfc and also realistically, it's very difficult to assure anyone that anything in the digital world is guaranteed to be stable for 50 or 100 years.

J

Next, please so the implications of the advice we've gotten. If we take it at face value as unlikely as it might be to change, we can't depend on these strings to remain user assigned forever.

J

The lack of a clear answer itself promotes uncertainty, particularly if we're talking about a standard track, rfc and iana actions.

J

Reserving the strings in the special use names registry may be unproductive for the iso ietf relationship, which does affect more than danisop at face value. This implies. We should look elsewhere for strings to reserve for the private tld purpose. Next, please.

J

So we have options possible ways forward for the draft we can proceed with it is currently written. We can rewrite it in a couple of different ways: to reserve different strings formally in the special use names registry, or to provide procedural advice to people with this engineering problem of strings, to use in a private dns context, but not recommending specific strings.

J

We can abandon the draft and figure will revive it if and when acceptable strings can be agreed on, or the question can be safely avoided. There's a lot of ways to to approach that um the working group could ask the chairs to come up with a way to get further advice, which would almost certainly which would necessarily involve our area directors or the iab, or both um your option here.

J

We're looking for, if other, if people see additional options that they feel strongly about, we would like to hear that, but we also wanted to make sure that the current editors of the document had a few minutes to make their suggestion on how we might want to move forward.

J

So I think joe ably is next as one of the editors of the document so I'll, let joe take it away. Take it away.

G

Thanks susan, can you hear me just checking yep yep, all right, good, all right, so um we threw these slides together very quickly earlier today, without having the benefit of looking at your slides suzanne that you just repeated, has just presented. So I'm going to suggest in the interest of not repeating anything. The original slides are all there and the materials people can see them. But can we just skip to the very last slide which has moving on in the top that'll save some time?

G

I don't want to repeat all the stuff that suzanne just said. So this is what we came up with the the authors, the editors of this draft. This is the working group's draft. It's not our draft.

G

The editors of this of this draft already had different possible futures in mind, and I think we mentioned on the main list that, like we didn't all agree with each other about the best way we were kind of listening to guidance um and what we discovered on the path to that is that this is a tangled mess of policy and standards, bodies and governments.

G

It's just a bit of a nightmare and, it's probably fair to say it's more of a nightmare than we anticipated when we started doing what we thought was a very sensible thing. So what we suggest is that there's some good work in this document there's some useful stuff to write down. We know that there are some people using these particular two character code points in private networks. So what we suggest is that we recognize that the existing recognize the current state of the advice.

G

We don't recommend anything. We don't put anything in any iowa registry. We don't reserve any of these names. We don't promote any kind of best, current practice or even worse, current practice. What we do instead is we describe why people have decided. Some people have decided to do this document. The potential future pitfalls. The fact we cannot predict the future. These things are not guaranteed to be stable and we just empower people to make their own decisions.

G

So we think this is a reasonable way to avoid bogging ourselves down impossibly. You know an intractable, never-ending policy mess, but still give some advice. That represents some of the thinking around this and make sure that you know the the conversations we've had, which you know and are not all thrown away and pointless. We actually write some of it down, but I mean just repeat: the idea is not to recommend anything not to specify what these code points should be used to.

G

It's simply to document how some people have interpreted the current standards and and and acknowledged that things may change in the future, so that that's all I got for this happy to take questions.

D

Victor is the goal only to capture the things that are already in use or to potentially find things that are safe to use, because I have thoughts on the finding things that are safe to use. But if we're not looking to recommend new code points, but only capture existing dubious practices, then I don't have anything to add so, which are we trying to do.

G

I think we're trying to capture existing practices. I think we're going to avoid casting aspersions as to whether they're dubious or not we're just going to try and relay the thinking that led to people just making those decisions and, whilst.

I

D

The same time, highlighting.

G

That these decisions are not perfect and people should be right.

D

G

D

Right because in the world.

G

D

A

J

D

We could introduce.

J

Some new prefix prefixes.

D

That are completely.

M

D

H

D

G

I'm not sure what who said what oh many of my microphones stopped working again. No.

J

G

You're, fine, you're, fine, okay, but there's an.

J

Outcome: okay, well I'll mute when I'm not talking but yeah. The idea is.

G

To document what we have, there are lots of ideas possible ideas about this. The xn-type analog is one of them. S-Sac produced a document which, which recommended the I can board, do a thing. The ccns may have opinions about things, there's all kinds of people who could have opinions around this. I think we're not trying to close any doors, we're just trying to document one set of decisions that some people have made without recommending anything.

A

Go ahead, wes yeah.

J

Sorry, I muted myself again go ahead. Wes.

N

uh So bear with me for a minute, um so this is a really really cool hack and I I loved the ingenuity of it. You know from the beginning.

I

um It was, it was a clever.

N

Way to get out of the problem that we've been in for a while, but when I really stepped back and talked to a lot of people in the past couple of months as my role in iab and not and my role as liaison coordinator for the iab and not, um I realize that it's important to consider a couple of vantage points right. So we have the advantage point from dns. Op we've always had this issue of you know.

N

We want private organizations with a label or a set of labels that they can use for internal communications, or you know whatever else, and this has been desired for a long time and we've you know, failed to provide it, and so there's.

F

Even disagreement about.

N

Whether there's a need in the first place, if we consider iso's advantage point right, they've they've created this space. They they were assigned uh the the uh the responsibility of administering the two-letter tlds. You know for user space, um what is a user in this context right in iso's vantage point: what is a user and and after reading, documentation and stuff, the user is supposed to be countries that don't have an assignment yet for themselves, and this is sort of important. If you know countries split or you know, new countries get created.

N

That does still happen occasionally and eventually they're not yet recognized, and it takes that process takes a while, so they can take one of these user-defined spaces. If we turned around and changed the notion of what a user is from our perspective, we're adding potential conflicts to that intended use. If organizations inside a country had been using it, for example, then there amounts to similar conflicts, as we already have with corporate mail, and we know how much of a pain that the whole situation is from.

N

You know the iso vantage point, you know it's functionally their code space given to them a long time ago in history that I actually don't know, which is between the ietf and icann and iso- that I can't summarize here, because I actually don't have it in my head, but consider what it looks like if we functionally publish a document that takes it back or even publishes a document that says you know, we don't know whether this is good or not to use, and that's really what I'm going to come down to, because I, I don't think it's actually okay to even to you know this ends up to me being I should not or must not, uh because it's not necessarily appropriate.

N

It's politically inappropriate to consider this. That's not where I started. I started with this is a really cool hack. Let's take one more step forward, which is the ietf vantage point right. What happens if we set this precedence to reuse other organizations private spaces?

N

Would it be okay for iso to define how private asn spaces should be used for routing and what impact would that have on existing operations? What about another sdo that redefines the purpose of the evil bit, because clearly we're never going to use it for reals?

N

What about an sdo that redefines the use of the z bit in dns, because it's historic and we no longer clearly need it, because we, you know, aren't really using it. What about an sdo that defines how 1918 space could be used in some sort of novel way? What if iso actually revoked? You know portions of our oid tree, because they didn't think that we were using it right. I think that we'd be furious from the ietf perspective. If some organization did something similar and in the end to me, this is a we.

N

We should not do this, or we must not do this, because we have to agree between multiple standards organizations uh to have consensus and and just beyond consensus, unanimous consensus in order. You know for interoperability not to be broken between organizations.

N

G

Hopefully, it seems to be a delay. Sometimes am I working again yes, testing testing. Looking now.

J

Yep yeah brian, isn't it brian isn't it? I.

G

Don't know what the delay is. We just respond briefly to where's the history of the intersection between these two letter code points and how they're used as tlds is not quite as as wes pointed out.

G

I mean we don't need to go into the history here, but it, but it's it's not quite as as indicated, but I want to confirm that the suggested approach here is definitively not for the ietf to promote anything or to suggest that anybody do anything, merely document that some people have used their interpretation of the standard in a particular way in their private network where they have jurisdiction and how they organize their dns. So again, it's not the ietf exerting a particular use.

G

It's really just documenting what somebody did I I realized, whereas you may well think that that's a sort of a way of a weasley way of addressing the entire thing, but I I do think there's some benefit in actually documenting what people are doing here and I don't know where else to do it.

G

K

I think everybody's ever said. um Sorry, that's also kind of easy.

K

I think it would be helpful or useful if we could document it and then vaguely deprecate it if we have something that we can offer as an alternative, and I think if we do pick an alternative, something underneath iepf control, such as under dot arpa, might be a good place for something like that and then the question bad ideas suggested might be previously possibly is having something like a an unsigned delegation to md.as112.rpa just to make sure that, if it leaks, if any of these uses get leaked, uh they don't really go anywhere useful anyway.

K

Those are your thoughts.

G

Thanks brian, I I definitely appreciate the leap into engineering, but I mean I think, just just be be confident that there is no. There are no shortage of ideas about how to do this from the technical perspective. We're really, I think, at this point talking about whether we should do anything not exactly how we should do anything.

G

M

So warren and wearing no hats, um so I think that if we were to document the fact that people do things like this, we should be very careful that we do think mention things like you know. People do this for home and dot corp and dot mail and a whole bunch of other strings that we know about.

M

I'm concerned that if we specifically point at these iso 3166 codes, it's gonna come across as hey look. Some set of people do this, isn't that interesting, nudge, nudge, wink wink um and it would be very hard sort of not have that be heard. As you know, we found what could be viewed as a loophole in some set of specs. That's interesting, we're not going to say use it, we're not going to say not, but hey ain't that interesting, um obviously, name collisions and people.

M

Squatting on names is a massive issue and I think everybody agrees that um having more discussion that might be useful, I'm just not sure that mentioning the set of labels is going to end well for us.

J

Yeah we're going.

M

To give wes the last word and.

A

Then take it to the list.

G

J

All right go ahead.

G

Joe, you have something to say in the west.

J

G

I was just going to agree with warren. It would if we did publish something here and it's a perfectly reasonable option to say this doesn't have a home where we should drop it, and I think, if that's what the working group prefers. That's what we'll do- and uh I do think if we do publish something it's very going to be very important to make it very clear that there are problems with all these approaches. None of these things are sanctioned.

G

The ietf is not expressing any kind of authority. All we're doing is documenting some decisions, some people have made and it has trade-offs same as everything else. So I do agree. The wording will be very careful, important.

N

uh So you're right that that uh it is, you would be talking documenting something that already existed. However, by actually producing the document in the first place, I actually looked went back to uh four years worth of queries on just one sample day out of uh digital data, about the number of queries for dot. Zed that arrived at.

N

You see usc isis root service, it quadrupled and almost quintupled between the point that that draft was published and now so we already have had an effect. Unfortunately, but the guidance of this document that we might want to produce should define everything that we learned and then explain advice about why people shouldn't be doing what we've learned right. So you're right, you know people are doing it, but they shouldn't and that's what we should document stop it.

G

Well, I think publishing it as an idea considered harmful is certainly an idea too, so I guess we'll take it to the list and uh thanks suzanne and next next thing. I guess.

J

Yeah, yes, thank you, joe and yeah.

F

J

The the the next! The next item is the the last thing and it's um we had gone to the working group a couple weeks ago and we're we're our trying to get a handle on priorities among the working working groups. Workload and tim is going to lead that so go ahead. Tim thanks, okay,.

A

Thanks um yeah um and thanks for benno for putting some of these together. This is very good um going through the list of documents we have um when this first came up, I was sort of like I didn't think we had that many documents, and then I looked, I said: oh maybe we do and then I looked and I realized like oh http, biz has just as many as we do so we're not as horrible as like the next group of people.

A

um I don't know if that means anything, but in the data tracker, as you can see, we've got 17 documents really 12 when you sort of toss out the ones that are basically in the process or being held, um I think the held one is the all tld document which we won't talk about right now. um So in an idea to sort of manage prioritize. What's going on, we were looking at some documents that are close or ready to work in group.

A

Last call you know basically the low hanging fruit and then what does the working group think about this? And we, when we were talking about this with warren, we sort of threw out this half-baked idea of like maybe we should do a poll and worms like that's a great idea. You should do a poll, and, um and so there we are um so look for all the other warren um working groups that have polls that got going out as well, um we'll see um so looking at some of this.

A

This is some of the, um where we sort of saw some of the you know feedback from folks where, where there was some, as we sort of said on monday, was that monday, when we had our first meet? Oh, yes, it was um some. You know a lot of positive stuff on the insect three guidance draft. The glue is not optional and it's revalidation um some interesting, you know push back on um a lot of indifference to stuff like 5933 biz and the in consideration. Catalog zones um comments like that.

A

um Not important um delegation only sort of got the the largest negative response. um Sorry paul um the other paul, not that paul that paul, um you know which paul it is um but yeah. That seems to be really where the group was sort of. It was sort of good to get sort of this feedback in a very anonymous way, so people didn't feel like they were going to be judged in any way shape or form. um Would you like to say something, mr.

H

Paul they also probably revealed that, on my um my submission too, um the questions are a little weird like, like the the delegation. Only draft, for instance, just takes 15 minutes for people to finally decide to kill this idea or accept this idea like it doesn't take much working group time exactly.

A

Exactly and exactly.

H

And so telling people, whether it's important to know that I'm putting it to the back of the list all the time, it's what has already been done to this document for like two years. So I don't think the the methods of trying to clear our queue is is a proper method, because there will always become more important things than the less important items we have, and so you will always get them on the android chain and they will just linger for years without getting resolvement either one way or the other, and that's the real problem.

A

That no actually that's a very good point and- and I think some of what we're going to take from some of this is not just things to move forward, but things to to basically say goodbye to right um and and you're absolutely correct um that that's a good way to say it, and um and yes, it won't take that long. Okay, warren! You may.

M

Thank you and yeah, I mean I think some of this is also people. Who've said that a specific document is important. I think we're hoping that that also means and they're willing to spend some time on reviewing it really soon and providing comments as well right. So some of this isn't just which is important, but it's also a implicit and I'm willing to actually spend the time to do a useful review as soon as it comes up for working group last call.

M

Another part was also to help get people thinking about the set of drafts for the conversation, but I don't really know why I'm talking now so I'll just stop. Okay, thank.

A

You um and much like we discussed on monday. We feel we have a few graphs that are pretty close to working group. Last call um I the ionic consideration. This is this is not interesting, but it's basically plumbing that we have to do that. I feel we have to do as a working group, and I think the chair is all sort of an agreement on that, and so we'll move that forward. I a lot of good discussion on the glue is unoptional.

A

Now that it's been revived and um as well as the avoid fragmentation, we really want to sort of move that, along though there was some good discussion on monday about some of that um I need to sort of. We need to follow up on same thing with insect. Three guidance are very you know it.

A

It looks like some straightforward measurements to get to settle on some maximization count, and um we feel that the draft is ready to go to move forward as well um as long as the authors sort of feel, similarly, um which we think they do so there's a few things that sort of came up um that we consider are pretty close as well. The error reporting um needs a little bit more discussion um and some sort of this you know some prototypes but ns revalidation.

A

We feel- um and I know I've sort of poked the authors on this a few times. um We really think it's pretty pretty close to working group last call: okay, schumann, as one of the authors.

C

uh Yeah, so I was gonna say um it's mostly done: there are a few uh small edits that were in the queue. So what happened with that was we kind of got derailed a bit and lost momentum when one of our co-authors ralph belmans left for a green pasture, by which I mean non-dns passions. He completely left the dns political engineering community.

C

So um we're going to pick that up. I just have to um ping uh paul that is paul, vixxie and uh finish up some of those edits and then hopefully we can get that review. Yes,.

A

I I did not poke you this time because you had been you guys have been working. You folks been working on the the glue is not optional draft and um I didn't want to sort of get you mixed up with that. So, but thank you. Okay, yeah thanks yeah, victor.

D

Timing on the n63 in terms of timing and insecurity recommendations, I'm waiting for a few shoes to drop trans ip has some bulk changes that they're implementing and a few others and we'll have a much clearer picture of what the deployment landscape looks like about a month or two out. So I don't know, if that's you know, within the kind of time frame, you're thinking ready for school or not, but I think that's.

O

D

Yep, okay, yeah yeah, but not today, but.

A

Before, but before the next ietf, we should be able to yes.

D

Yeah things should be clearer by then yes, yep.

A

Perfect, that's exactly how I sort of view close um really close would be. You know like I am in consideration. That'll probably go off this week um as soon as I sort of get moving on stuff, um some other interest. You know there's sort of mixed interest in some of these.

A

um We do want to move the 84.99 biz because there's some updates in that um some some new terminology, especially on the dot, dom h bits, um and maybe some more after the deprived discussion on some of the dennis over quick and some of the variations. I I will have to talk to the authors on that, um but some of the new work being suggested in the in sort of the free form field, the dns bootstrapping, um which we saw you know as well as the dnsec automation.

A

um We saw that you know we saw both drafts kind of come through the mailing list and they looked interesting um and we were sort of you know we're thinking that. Yes, these may you know these sort of fall into the sort of same bits um that we feel very good about sort of adopting, but we held off because of you know. We wanted to make sure we sort of got our handle on what we were doing um but, and I think the dynasty bootstrapping.

A

It got a fair bit of good comments about sort of being adopted. So I think that's something the authors. We should talk to the authors about um sort of bringing up discussion on the mailing list as well. um So thanks for that, as you know, we've held off tld and that's not going to go anywhere um and we've sort of held back on sort of you know we we had. We had folks present stuff that wasn't what we considered current business or even new business, because we like doing that in dynastop.

A

We, like giving folks sort of that place to sort of you know, throw out all their sort of ideas and sort of get the feedback. um It didn't mean we're gonna, adopt stuff or sort of put it in the queue. um But you know we want to get the cue a little bit more cleaned up or a little more organized, so uh paul.

B

Explain why all tld is going nowhere? It was held by the working group. There's you know in the last draft we saw a lot of interest. Why is it going nowhere.

A

I'm going to let suzanne talk about that, because I'm no expert on the alt tld bit sorry suzanne.

J

Yeah, not um there's not a lot to say we had parked it.

J

Pending man, I'd have to look at I would. I would actually have to go. Look at it here. Yeah warren probably remembers better than I do, but we had held it pending resolution of some some external condition and warren. If you, if you remember you should speak up, I believe.

M

That we held it based on the finishing the special use domain names, problem statement document and then an assumption that, after we finish special use, names problem statement, we would actually get around to fixing all the problems with special use domain names.

M

um It was always the plan that you know there would be the problem statement and then the resolution document- and I think we have never actually found people with enough stomach to take on the solution to special use names.

J

Yeah there was some hope that we would come up with a more general framework for moving at the time we had a large number of requests for special use names, and there was.

M

I mean I'll point out that I am an author and I still think it's a really great idea. We could always say you know it's unlikely that we will ever solve the problem of special use names. So let's possibly go ahead with this, but I'm biased. Obviously, and that's the chairs decision um I will mention it- did, have a working group last call to which we invited I can people who all came along and, I think were partly terrified by us, but they nodded sagely.

J

A

Go ahead, paul.

B

Don't say things like that, um I I know you were sort of joking, but that's not at all a good, a good representation of what happened. um Icann folks came and said you know what, if the ietf wants something we'll make it happen, that's really different.

M

You're right, I was overly flippant as as I want to do. Apologies.

A

Thanks well, um a good comment that came out of the the the chat was. Basically, we should go talk to a lot of the authors and figure out. What's going on with stuff um which, yes, we do, we tend to do that um you before an itf, we usually start contacting all the authors of documents and poking them about the status and where they are um and where we think you know where we think things should be, and a lot of that we do.

A

You know sort of in the background, and so maybe it's not as transparent, and one thing that I've been really thinking about a lot- and I think benno and suzanne have been, is trying to figure out how to be more transparent to the working group as to how we make our decisions and basically our sort of workflow, um because we do think about this stuff.

A

We have a bi-weekly chairs call um where we sort of go over a bunch of this and try to figure try to prioritize what we think is happening, um and we do it basically a little independently of the working group, which I think now that I realize is perhaps not the best way to do it, um and so um it'd be great to get some solid feedback. You know we're getting some solid feedback from the from the poll and from folks um and yes, we want to sort of put we don't.

A

You know we want to basically start moving more stuff along and or not moving stuff along in mr water's case and and he's absolutely correct in some of this, um I think sometimes we push stuff down thinking that eventually it'll go away, but really the answer is, we need to. You know, make those decisions in the working group and we're just the chairs. Are you know I'm just as guilty of of letting those slide and um thinking about the bigger issues I'm moving stuff forward? um So, oh brian, you want to say.

A

K

The I think there is interest, um could we do a show of hands? Is that something we can do in this format?.

A

A show of hands for.

A

I missed with the first part of the.

I

K

Okay, uh cheers: uh how do you feel about doing the show of hands and if so, let's do a show of hands.

A

I'm sorry a show of hands on what I guess that was the question.

K

Getting it back out of the health and making it move forward.

A

So yeah, sorry, I'm I'm I'm missing part part of it that dropped that um benno suzanne any suggestion, I'm missing something there. I don't understand.

F

No, it's it's no.

J

Brian, not great so I'm not sure what he was requesting a show of hands on. um In any case, we are running a little bit short on time um and.

A

Oh, they requested.

F

A

The request is whether all tld should move forward now that.

J

Since it's been parked for a while, and it's not clear that people have had much of a chance to renew their memories on it, I think it would be better to take that to the list.

J

Tell people we're interested in assessing that and give them a chance to reread it.

F

Yeah yeah, so this session is really about making progress in general and not about specific uh uh drafts. uh So it's more approach: how to improve, well progress and and manage workload.

A

And transparency in our workflow yeah.

F

Yeah um and indeed all the individual drafts have to be discussed. uh Maybe, uh as schumann mentioned, some authors have have a new career and outside the dns. So maybe some of these documents need an additional new author, this kind of things and and the chairs will think about it and get in dialogue with the authors. If either there's another author needed on a document what's necessary and also for the old tld, we need to think about uh what to do.

F

Is that do we need to go to the mailing list or talk with the authors uh indeed? Well, we had just had this discussion, uh what's blocking the document and how we can get around that.

A

And one thing we sort of thought about was having a meeting every so often in between ietf's, where we, you know, authors come in or anybody can come in and sort of. You know we talk about sort of document status and, and mostly you know how to move things forward, not so much discussing the the innards of documents. But you know: where are we? How are we moving? You know? How are we doing that kind of thing? We're always looking for sort of feedback on how to improve our process?

A

Basically, because we do get a lot of folks kind of coming in with stuff, and we see a lot of documents and there's some like the bootstrapping document, which we think is very interesting but um sort of got missed in the shuffle um that I think you know really sort of fit into the the dinosaur world. uh So we're always looking for that and I I hope, we're we're responsive to any any issues or you know people people want to raise, and you know you just go talk to warren.

A

If you've got issues um he's very willing to listen and and bring things to us and and sort of yell at us about stuff, I think.

J

People should feel free to yell at us. First, yes,.

A

J

And in general I did want to say um I suggested in the chat just asking people if um it seemed useful to them for us to do like what the iab and I think the iasg have been doing the last couple of years. Where, instead of having an agenda item for a lengthy or detailed report, we publish a status report to the list before a meeting. And then we have time for questions or comments.

A

J

A

J

To go through it, let's have we just have time in the meeting for for people to uh bring up specific items, and that seemed to get some good reaction so guys we should think about that. I think it'd be a good idea.

A

Yes agreed: go ahead, paul.

H

So one suggestion I have is to maybe monthly or so just send an email with the list of items that we are working on items that we need feedback on, so that everybody is reminded very regularly about what items we are talking about, and then we have a much better situation where we can declare lack of interest and other things to to to to then kill those documents that have no interest or say this document seems to never be able to reach consensus, we're killing it. Therefore, then, then, we have something.

H

I think the the three times a year list of documents is just not good enough to get through this.

A

No, I agree and actually that's funny, because we keep a document status list in github and I've always thought about mailing it out regularly and it's kind of where we think documents are. You know it's like this is being you know, we're waiting for an author to get back to us on something and so you're you're right. We we actually keep something very similar to that already. We should push that to the mailing list on a regular basis that that's a very good point, and actually, I would agree totally with that.

A

A

Okay, so we should take that as a action item as well.

A

No thank you for that.

J

Yeah, we are almost out of time, but um this this has been tremendously useful thanks everybody um and we have time for one or two final comments. If anybody has anything additional today,.

J

Or we can give you back three three minutes of your afternoon evening: ryan: go ahead.

J

K

Cute, okay, sorry, I hate to be that guy uh at dprive um there was some stuff. I was suggesting that I wanted to bring over to dnsof um specifically to deal with uh the fact that um delegations are unsigned- um and I was wondering- is that- should I just write that up and post list and ask for feedback? Okay, yes, yeah! Okay, just want to make sure it was cool thanks.

A

All right, oh it looks like ben- is going to get the last word in okay.

O

So I would, I would appreciate, from the chairs um a little more guidance about where documents like that should go um between dns and op and deprive basically if the nsop is overloaded. You know tell us, so we can have that conversation with depressed yep.

A

We can do that.

M

And I'll talk really quickly kind of like an echo, um we had spoken about having a joint meeting between the pride and dns up and add and a bunch of others. Where, specifically, we could talk about that sort of stuff. We should probably try and organize that an intro.

J

A

Yep cool all right, then I'm going to let go because mr michaelson wants his minutes back, um but no.

J

Thank you all for showing up, especially those of you who are up in the middle of the night. It is vastly vastly appreciated.

A

Yes, we do appreciate that.

J

And we'll be.

A

J

A

Say good night a good day and.

J

See you on the list and thanks again for the input? Yes,.

D

Good night.

D