Session Date/Time: 23 Jul 2026 12:00
[00:00:27] Rowan: Testing. Testing. Testing. Both mics can be heard by remote participants.
[00:01:23] Sarah: Alright. Welcome to DIEM at IETF one hundred twenty six. This is your friendly reminder this session is being recorded. So you'll have seen this plenty throughout the week, but just a reminder, this is the note well. By participating in the ITF, you've agreed to various processes and policies. This is a little reminder of those. You can use the QR code to see the full version of the text, but you're expected to behave in a professional manner under the guidelines for code of conduct. If you're aware of any contribution that's covered by patents or patent applications, you must disclose that fact in line with the IPR. Right? There is a detailed process information, in RFC twenty twenty six and twenty four eighteen, and we make public written audio video records of, IGF activities, and that's set out in the privacy statement how that's covered. You have any questions, you can ask us or Charles for the period that he's here. A couple of logistical points before we really kick into it. For in person participants, please make sure that you're signed into the session via data tracker or the QR code around the room. Use the light client to join the queue and share hands. Please keep your audio and video off if you're using the full client. For remote participants, please keep your audio and video off unless you're chairing or presenting. None of you should be chairing. Use a headset, please, if you can. And when you come to the mic line, please make sure to state your name and affiliation, especially helps for folks who are remote. So a couple of other resources that you've probably seen throughout the week, the full agenda, all the info on Meet Echo, and if you have any issues and you need any help, you can report it to the reporting issues page. So the agenda for today's session. We have the preliminaries, mostly gone through by us. We've got a little update on the liaison from study group seventeen, the ITU, that we'll be delivering. We've then got an update on the use cases and requirements document on the working group last call that Felix is gonna present to us. We've got a little bit of a prompt from the chairs to talk about architecture, then we've got plenty of time for an open discussion, then we'll try and summarise what we've heard, maybe do some questions, and then we should be done and dusted. Before I go any further, is anybody willing to take notes? Thank you, Laura. Fantastic. It's much easier than it often is. Brilliant. So a little bit on the on the kind of goal for this meeting. We are going to give an update on the feedback that we've received on the use cases and requirements document from the working group last call so far. Just a reminder for for anyone who hasn't been following along in lots of detail, the plan is not to publish that document as an RFC, but rather to use it as kind of stable reference for the rest of the work. So we're doing working group last call within the group, but not planning to go to kind of IETF wide call. Jim, is that a question on the agenda?
[00:04:33] Jim Reed: Excellent.
[00:04:35] Sarah: And then we are gonna move the discussion on the architecture as our charter allows us to do to work sequentially. Just to say, I will we will try and keep an eye on the chat, but sharing, presenting, listening to you all, and doing the chat is not always the easiest thing to do simultaneously. So if you have a particularly interesting point that you'd like to make, can I suggest that you pop your hand up and join the mic line? Any agenda bashing? No. Perfect. So I'm gonna give a quick update on the liaison between DIEM and ITU-T Study Group 17. So as background, we received a liaison statement on two new work items that had begun in ITU in December 2025. Those were xstr.dm-assets and xstr. D m. That liaison statement can be found on the IAB's liaison statement management tool, it can also be found in the working group mailing list, and that contains full text versions of those documents as of the time that we received the liaison statement. We sent a response from the working group to Study Group 17 in April, sort of thanking them for their liaison statement, giving a little bit of a background on what the working group was doing and what it was dealing with and what its remit was, and inviting engagement in the IETF process, highlighting that we had this meeting and that contributions were welcome at any time on mailing list. We'll continue to engage with any liaison statements that are received as needed and try and encourage contributions and make sure that the work doesn't sort of there isn't any conflict between the kind of two sets of work in progress and that we're able to to work together as productively as we can. Alright. In which case, Felix? Jim. Sorry,
[00:06:38] Jim Reed: I was just a bit too slow to put my hand up there. Jim Reed speaking as myself. Just to let you know, there's a the next study group seventeen meeting is early September. So we may see some activity coming from the study group shortly after that, and then that can feed into what we did discuss at ICF-one hundred twenty seven. Just to bear in mind that decisions at ITU are done in the physical meetings and that's the timelines that they want to.
[00:07:08] Sarah: Thanks, Jim. Thanks for the heads up.
[00:07:10] Rowan: And just to make sure, did the folks in the back hear that? Please just wave if you heard it. You did not you did not hear it or you did hear it? Okay. Yeah. How dare you say that about a a Scotsman? And then and then remote, if somebody remote could just say something or text in the chat if they were able to hear the Jim at the mic there. DKG, maybe? Alright. If if people are on remote yes. Great. Loud and clear. Okay. Moving right along.
[00:07:59] Sarah: Alright. Felix, you ready to come up?
[00:08:21] Felix Linke: Okay. Hi, everyone. I will give a quick update on the use case and requirements document, which since last IETF evolved by two version numbers, one for the interim, one for the ITF meeting. The chairs issued a working group last call, which runs until July 30, I think. I checked earlier. K. I get a nod. So everyone's feedback on this version would be greatly appreciated on the list. I already posted some minor comments. I personally think it's good to go. Let's look at the changes.
[00:08:57] Sarah: I yeah.
[00:09:01] Felix Linke: One change well, there's a group of changes on the question of how use cases interact, and there are I think the the takeaway of this text is that use cases may or may not develop distinct solutions. The use case and requirements document doesn't say much about that. But in particular, it now it now says more clearly that they should not restrict one another so that just because use case a has limitation x, this doesn't necessarily apply to use case b and vice versa. Concretely, there was text added to the document that more verbosely describes what I just told you as a preface to the requirements. We also adjusted the text on two requirements, namely the digital emblem format and digital validate emblem digital emblem validation requirements. So these are more flexible to express the same thought. Then on the requirements, we have new text on the current response requirements. And there's there are passages sketching the landscape of requirements like assured or selective response and consistent and selective content. I encourage you to read the document if you're curious about the details. The requirement for removability has new, less awkward text that was oversight on my end. I didn't like the previous phrasing. It was a bit, yeah, weird. Now it's less weird. And some normative language was removed to, again, make the document more flexible and easier to work with. We have some changes on use cases themselves. The diplomatic pouches now have many more details, and they are related to individual requirements. The emblems under international humanitarian law section is now more precise and specifically mentions which emblems under international humanitarian law we mean. And there is a section on use cases that also relate to an international humanitarian law but are not the red cross, red crystal, red crescent, emblem of dangerous forces, blue shield, and I think the civil protection sign. Yeah. So now this is clearly separated. And there's some text on security considerations. We now list which requirement is a security requirement, which is almost every of them, or almost every requirement has security implications. And we note that use cases must consider their specific risks, which, of course, depend on the use case. Yeah. That was my quick rundown of the changes from version one to version three of the document. Are there any questions?
[00:11:52] Rowan: Okay. Are there any comments on the requirements and use cases document? So I'd like to remind everyone, we are currently in working group last call. Working group last call we're half finished with that. It ends next week, Thursday, July 30, midnight in UTC. We have received only three responses. There are more authors than have than there are people who have responded to this working group last call. So even if all you want to say is, it looks fine to me, please say that, That we we will not be able to justify our continued existence as a working group if we don't have some meaningful consensus of the working group that says they think the requirements and the use cases document is sufficient for us to progress.
[00:13:19] Sarah: Alright. So we are required by our charter to deliver an extensible architecture containing a taxonomy information model and overall information flows, brackets, informational. We have to work on the architecture document before working as a group, I think important caveat, on the protocol, and we couldn't start work in earnest on this until we were finished with the work with the use cases and requirements document. We've had a couple of suggestions, contributions that that touch on architecture so far, some kind of going into slightly more detail on the technical elements, some sort of sketching out what the architecture should generically cover and do. Before we we think that the way to kind of start it hasn't updated on my screen. The way to kind of start kicking off this conversation is for us to get a shape, a sense from the working group what shape that document should take. So we have two questions that we'd like to discuss. The first is what does the working group think the architecture needs to cover, and what can and should be left up to the upcoming protocol work? And then are there any major architectural design choices that are common across all requirements that need to be made now and need to be in the architecture document. I think one thing that's worth bearing in mind when we have this discussion, it's probably most helpful to think about this in terms of requirements rather than use cases. There are requirements that are common across all use cases or many use cases, there are requirements that are going be very specific to individual use cases, so if we can try and stick to that as a framing, that should help us also to see where there's any commonality that we can find. These are obviously very generic high level questions. That is not to preclude you guys from coming up with very specific technical solutions and answers, but we just wanna have a a couple of things to start us off from now. Any chat? Yep. Alright. I'm gonna queue's open if anyone has any thoughts on these two questions.
[00:15:49] Jim Reed: Jim Reed speaking for myself. I'm not sure if this is perhaps an issue for the architecture document, but I think it's something that needs to be addressed, and that's identifying roles and responsibility. When we talk about things like authenticating and validating responses, she's not clear who's going to be doing that.
[00:16:10] Rowan: Jim, could you get a tiny bit closer to the mic, please?
[00:16:13] Jim Reed: Sorry. Is that better? I'm getting a bit more worse. I'll cope with a lot of feedback. So Yeah. To repeat what I just said, I think we need to look at issues around roles and responsibilities. And, for example, when we're talking about validating data, who's going to be doing the validation, and what responsibility do they have? Now that doesn't fit comfortably with the architecture, but I think it's an important component that needs to be addressed somehow, says me waving my hands metaphorically.
[00:17:09] Sarah: I will say comments relating to the architecture more generically or the drafts that have been submitted are also very welcome from from those draft authors. You do not have to have a very straight formal answer to these two questions.
[00:17:24] Felix Linke: Yeah. Hi, Felix Linke. I think we shouldn't what I would love is that the working group, henceforth, considers working on the architecture and the protocol documents together. I like to view architecture documents or the ones that I've seen. They tend to describe the protocol document on a higher level. It provides some context on how they expect the protocol document to be used, by whom and for what, and how the information flow will go. And so I I don't think we necessarily need to agree on what goes into the architecture and what goes into the protocol document ahead of writing both. But if we can have something concrete to back up the abstract, I think that will be helpful. That and both documents can inform the writing of each other. So, yeah, that's that's what I plan to do, to work on these in parallel in a writing process and bring them in parallel to the working group. And I would encourage everyone to do the same. Are there yeah. I'll I'll take more time to think about the second question and not do it on the mic. Thanks.
[00:18:40] Sarah: So I will I will look to Charles to correct me if I'm wrong, but our charter requires us to work in sequence on documents. So whilst we people can work on things, I think we're a little constrained in what we can adopt, in what order. But that is not a bar on doing the work.
[00:19:01] Rowan: Nor is it a bar on us discussing an individual draft in working group time if it doesn't negatively impact the working group items or the the next thing that we're supposed to be working on.
[00:19:21] Allison Mankin: I I think this said this is sort of a segue from protocol work in parallel somewhat with architecture work. But the way that the requirements document ended up evolving is almost every every requirement says some use cases may need this or that. Right? And you could not use this if you don't want to. But there's also many expressions where it says, the protocol must make it possible for those who need it to do this. And I think that's not just don't block it, but also provide some mechanisms. So we've been having some discussions, for example, about, oh, what about the use cases who really don't care about data integrity or anything about the verifiability about stuff? And I think the answer is if the protocol said, oh, we're not blocking you from adding new mechanisms like that. That would not if the architecture didn't provide some some built in capabilities that would make that possible that we knew worked, that would not be good. They need to be able to be turned off, but it doesn't mean that we shouldn't put them in the architecture. And that we should think of protocols that are not as minimalist as everybody doesn't need any of these things, really. So, you know, because we could end up with with very little in a common architecture or a common protocol. So I'm encouraging us to use the requirements document inclusively while we think about the architecture and think about the architecture in a way that is enabling, simply not blocking. Hope that makes sense. Oh, and I'm Allison Mankin from Packet Clear.
[00:21:19] Orest Steele: Hi. Orest Steele, Trade Verified, just a regular guy nowadays. The charter text says the DM working group will work on the following deliverables for the defined scope strictly in this order. It doesn't say that this is the order they have to be necessarily delivered to the ISG. I think it's gonna be extremely helpful to work on the architecture and some of these technical building blocks in parallel. And, also, you know, for anything that's not yet adopted, that that's to the authors to sort of, you know, think about how they wanna organize themselves. And so when I worked on this, now that I have time to work on things, I looked at, you know, hey. I I wanna think about this architecture, but I also wanna think about this technical solution, and I wanna kinda bounce back and forth between the two of them. So I found that very helpful for my, you know, individual draft, which I don't think I ever sent to the data tracker. But I would encourage folks who are working on the protocol or who are thinking about the architecture to start looking tech at the technical building blocks, like, right away. Thanks.
[00:22:28] Charles Eckle: Charles Eckle. I think I interpret the charter much in the same way. Although, I think also in line to perhaps with what Rowan was saying, You know, I don't want discussion on the protocols to slow down work on the architecture. I also think I want to see the architecture in a certain state to where it's pretty clear when I see a protocol document, like, I understand why it's a part of the architecture. Right? So if we don't even have the the basics in the architecture that kinda motivate what the protocol specifications, you know, should be, then then that's a problem. Right? But if we can get that beginning architecture down and then we have protocol documents and they involve in parallel, I think that's all good.
[00:23:22] Sarah: Thanks, Charles.
[00:23:45] Rowan: Allison, go ahead.
[00:23:48] Allison Mankin: Actually, I find I'm willing to answer the questions a little more specifically. I think we need to include methods of authentication and include methods of verification in the architecture and work on those now not say there will be some kind of thing that is in a blob that will do this, and we don't need it to be showing up anywhere in the architecture now. So I would like to encourage us to do that, and that brings us back to our I know there's some discussion that'll come after this, but it brings us back to our what is an you know, what's the DNS role? But having a discussion of how that plays in as part of the architecture seems mandatory and valuable to me, you know, committing to that.
[00:25:06] Rowan: Okay. So it we didn't hear any objections to working in parallel with the caveat that Charles said that with the two caveats that he provided. So we're just gonna take a poll, but we're basically assuming that you're gonna be able to work on work on protocol ideas to the extent that they do not they do not negatively impact forward progress on the architecture. Yep. So we put a poll up, and we'll give a few minutes for everybody to weigh in on this. We got 28 participants, of which eight are Zulip only. So don't expect many of them to any of them to participate in the poll.
[00:26:48] Sarah: Alright. I'm gonna terminate that. That is 11 yeses and two no opinions and no noes. Perfect. In which case, I think that is pretty strong consensus to head on with that approach. We had initially thought about do you want introduce this? Had initially thought about kind of spedding out in a little bit more detail some of the questions that we think need to be answered by the architecture document, But thought we get some answers on these first. We have a pretty clear answer. So Rowan is going to present on some things that have been thrown up by the kind of architecture discussion so far. These are not chair opinions on what the architecture should or shouldn't do. It's not exhaustive. It's just meant as a conversation starter for some of the things that we think we're going to need to talk about. Let's start having those discussions now. So
[00:27:52] Rowan: Okay. Hi, everybody. So, again, even though I'm presenting these as I'm a co chair, the goal here was to go and take from the half dozen plus drafts that have been produced that talk about architecture in general and to talk about some potential places where we may need to make a decision or we may need to say, you can pick a or b or where these decisions may result in impact on other decisions on other aspects or dimensions. And if you wanna if you wanna ask a question at any time, please jump right in. If you wanna wait till the end, that's fine too. But the point here is to encourage some discussion. We've had very little discussion today. So so the first thought is there are several fields that were mentioned in some of the documents and they were sort of mixed together fields that might be talking about the issuer of an emblem, some that were talking about the asset or identification of the asset, some that were talking about asset handling. When I say asset handling, this may not be something that every that every emblem type needs to say explicitly. But for example, in the use case of, CITES, which is, it's for endangered species protection, There may be a bunch of additional information that you wanted to sort of tag along that talks about how to take care of a live animal. There may be any number of other things. Right? In the case of hazardous materials, this might be the place where you would go and put something like that. That's how I would categorize this. You have information about an emblem type. So, like, let's say that we were talking about an emblem for a wetland, then this is where you would put things that are specific to all Ramsar wetlands and not this specific wetland. And then information about an emblem instance. And so in this case, you might have validity times. You might have unique identifiers. This doesn't necessarily mean that the the asset, but things about the the emblem itself that I might have an emblem today for an asset and then I have a different emblem tomorrow for the same asset.
[00:30:38] Sarah: Just
[00:30:41] Rowan: throwing that out there, it's just some some ideas about possible ways that may be useful to categorize information. It doesn't need to go in an architecture document. It doesn't need to go in a protocol document. If it's useful for you for your mental model, great. But if it's not, then you can just you you don't have to think about it.
[00:31:08] Jim Reed: Jim. Jim Reed for Jim Reed. I think this is a good idea, Rohan. But I cannot think about, do we have any unknown unknowns? What is it we don't know about emblem types other than the ones you had mentioned before? I have a horrible feeling there may be other categories out there, but the problem then is how do we find out where these emblems are being used or being discussed and how are they relevant to how would they or would they not be relevant to the work we've done here? I suppose if nothing shows up here, no one makes any requirements, we just have to just bypass them altogether. I just have a feel we might be missing something important. I could be wrong about this, but I just think that needs to be explored a little bit further if we can. Yep.
[00:31:56] Rowan: Okay. Now we have we have also talked our initial scope is is supposed to have us use emblems that can be represented using a fully qualified domain name. That doesn't mean we won't have other emblems later that may or may not use fully qualified domain names. But for things that do have a fully qualified domain name. Alex, what was the the wording you said? Not stored in the DNS, but but delivered by the DNS. So if you have a fully qualified domain name, this implies some some kind of DNS lookup. And the delivery of information as a result of looking up something with that f FQDN could, for example, be an emblem that's expressed in a TXT record. Now we have lots of people in the DNS area that say, please do not do that. I I don't know if there's actually an RFC that says TXT records considered harmful, but I would not in the slightest be surprised if there is. There could, for example, be a an emblem that is represented using a single emblem represented using a new RR type that contains an entire emblem. There might be bits of data of an emblem that are spread across several RR types or there may be something more like a pointer approach where you have a record, for example, an SVC B record that points to an emblem using a URI, like a HTTP or HTTPS URI. Jim Mosley.
[00:34:01] Jim Mosley: Jim Mosley speaking for myself. Can you hear me? Faintly. Jim Mosley speaking for myself. Yes, can hear me now. Great. I can't remember what the word was you mentioned earlier, but maybe referenced by the DNS was one way, one word to say it. Doing some work elsewhere, let's say, in another group. Yeah. I had the same comment from people about TXT records. On the other hand, the bottom option with SVC B records may not be implemented everywhere. So the thing we're thinking about in that context is promote SBCB record first because it's structured, better for connectivity, better for referencing other things, but maybe fall back to the TXT record. So that's one thing there. Just technically, having TXT records at the apex of a domain is potentially problematic. So I think that's generally the DNS community's reaction to that. If it's not at the apex, then it's probably okay. I'd suggest creating a a new record type is a long process, potentially. I know people have said not, but it's it's not only the creation of a new record type, it's the actual support in software that's that's problematic. So, yeah, just some just some things around that that we've discovered elsewhere. So if there's somebody that wants to talk about that, then then happy to. Thank you.
[00:35:36] Jim Reed: Speaking Jim as someone who wants to talk to many things that Jim has just mentioned. Of all is that using a text record I think is going to be a really bad idea It's established with them in the DNS community. You just don't do that anymore. I certainly note to some people earlier, but I'm happy to post it to the list about some of the reasoning for that. As an example, mit.edu has got a tech has got something like 20 text records in their zone epics already for all sorts of weird and wonderful reasons. So if you're going to get those number of bush records being returned in a lookup for a text record for something, the end client is going to have to plow through all of them and figure out which is the one that's of interest to them because it represents some kind of DM attribute. Now maybe we have that problem finessed a little bit by using _dm. Domain name and having a text record there. I still think that's maybe not the way forward. The next question that Jim mentioned was that the difficulty of getting URR types. The answer to that is there is no problem. It's a lightweight process. It can be done in less than a day. And in terms of implementation, there's really nothing to be done because there already is an established mechanism for DNS inflammations to handle unknown RR types. They just treat it as a byte count and a blob of data. So there won't be any issues there with existing implementations. I kinda think the idea of an emblem spread across a few other types might be a good idea, but it needs a little bit more detail to finesse that and work on it. And my I'm heading right now towards the idea of using a single RR type as a form of indirection, probably an SVCD record, so that we then just indirect all this stuff into the web and let the web deal with all the issues around anonymity and all the other kind of concerns we have about tiered access to information in the DNS. So in in outline, what you would do is a lookup of some domain name for this VCP record. It gives you the details of the endpoint of a web server. We can go and pick out all the information that you need, and the web server can deal with issue around tiered access and all the other anonymity concerns. So that's kind of where I'm heading for at the moment, but it could be persuaded otherwise of people can compelling cases for these other other ideas. Thanks. Tommy.
[00:38:01] Tommy Jensen: Tommy Jensen, no hats other than the one on my head. So I agree with no text records for a plethora of reasons. I hope that I I think creating a new RR type seems like a pretty reasonable straightforward or or a reasonable path forward. Most cases, we'll probably end up needing it. I would like to see that we do one and have extensibility in the the structure of that type. Like, for example, the way service binding is structured essentially makes it a key value store. We could be creative such that we're not creating a ton of new RR types just so that if there are future extensions needed, those extensions just need to do something within an existing RR type rather than continuously add more. But that's a preference. We'll see how discussion goes. I think for many use cases, the service binding idea is a brilliant one. What we will have to figure out is whether the service binding folks think it's within scope because I will note that from prior documents attempting to use service binding keys that it has a somewhat strict academic definition for enabling you to access services at a given place. Is a emblem a service? I'll I'm saying there's a debate to be had there beyond our working group that, you know, maybe a sleeping dragon.
[00:39:27] Rowan: Tommy, before you go, would you would you be able to hook up a couple of people that are relevant that could come talk to, say, either Sarah and I or the sort of larger architecture y volunteers, please?
[00:39:47] Tommy Jensen: You're talking about for the service binding Dragon? Yeah. Absolutely.
[00:39:50] Jim Mosley: Thank you.
[00:39:55] Rowan: Okay. Alright. So there is a requirement that some emblem types be validated. I'm gonna go out on a limb here and guess that maybe most emblems even will need to be cryptographically verified using some kind of signature. And so there are a few a few ways that we could do this. Some of them use DNSSEC. So DNSSEC allows you to see if a record is signed and whether it is if it is, you know, all the you can verify its its chain of trust all the way back to the root. So a record, an RR type, which is directly in the DNS, which is DNSSEC protected, you can verify it in a pretty straightforward way. Earlier today, I went and looked at at some statistics about DNSSEC deployment. I don't have time to summarize those here, but I will be happy to send out that to the list so people can see that and just have that information. So it's not a 100% and it's not a tiny amount either. Somewhere in between. Another option would be you could have an you can have a Dane certificate. So this is a certificate which is anchored in the DNS. This certificate can be used elsewhere and and it can be used to sign things. It could be used to sign things that are inside a inside the data represent that is returned from a DNS query that has maybe some attributes that are covered by the signature and some that are not. So for example, Alex in his document, he gave an example of perhaps something that is gonna be dynamically dynamically updated that could be in a part of the data that is not covered by this by a signature and not covered intentionally for that reason. In the example before we gave of SVCB pointer to an HTTP resource, you could have, for example, a web token, like a JSON web token or a CBOR web token. And those have a protected header that has a key identifier. The key ID can be for example, it could be a URI. Often, it's an HTTPS URI that's pointing at a key somewhere. It could also be a Dane search. Finally, we could have we could just use the web style, public key infrastructure certificates. So all of these have different trade offs. Allison.
[00:43:09] Allison Mankin: So I I just wanted to add the assurance of source source source authentication and also the assurance of non of nonexistence, which DNSSEC provides. We probably should have had a little bit more of that in there, but in the requirements. But it's it's it's not just a a a data protection. It's also that you have the ability to put yourself in a part of the hierarchy that is associated with you and that has a trust chain that comes down to your organization. And then also that if the if somebody tries to suppress send you something that that is shouldn't be there, like a a fake one, you can prove that it's not it's not actually it really isn't there. So there are some facilit capabilities that come from a DNSSEC piece that would be handy to have in general, whether people all elect to use them or not. And we should make sure that we're kind of knowledgeable enough about DNSSEC to be good application users of it.
[00:44:29] Rowan: Rahul?
[00:44:39] Rahul: Okay. I I realized that as I was set I joined the queue, unfortunately, a lot of my comments were a bit more focused on a specific, protocol sort of focus. I guess my general thought would be towards favoring using DNSSEC. I am concerned that using, like, Web Style certs with PKI could cause issues when it comes to someone's ability to recognize different certs simply because of their policy choices as opposed to when you when using DNSSEC where there's the universal ability to trace back to root. Thanks.
[00:45:44] Sarah: Thanks, Rahul. Just to say, I think given we're considering architecture and protocol in in parallel in in some capacity, If you wanna talk very specifically about protocol design, if it helps you to contextualize this, then then please do. So
[00:46:02] Tommy Jensen: do we all.
[00:46:04] Rowan: Thank you, whoever's AI agent that was, Tommy.
[00:46:07] Sarah: For for those online.
[00:46:08] Tommy Jensen: Yeah. Relaying something Peter said on chat, which I happen to strongly agree with, and I'm glad was mentioned. Versioned RR types are not a great idea because it makes complying with RFC three five nine seven close to impossible, which is about guidance for implementers to parse data when they see an RR type they do not recognize. So food for thought.
[00:46:38] Felix Linke: Hi. Felix Linger again. On the DNSSEC discussion, Alison, great point on the proof of nonexistence. I have never considered that. That could indeed become handy. However, I have some concerns with well, I don't think DNSSEC does it all. I think no use case would be hurt if records were signed by DNSSEC. It doesn't make anything worse. But, for example, if if you want to deploy a digital Red Cross, you must have authorization from the competent authority, which is a state, which you just cannot express straightforward in the chain of authorization that you get from DNSSEC. If things were signed in DNSSEC, you would know that it was indeed the domain owner who put the emblem there, but you don't care about that. Right? You you want to know whether the domain owner had authorization. Yeah. So it's definitely not everything for every use case, but it could be part of the bigger picture.
[00:47:46] Rowan: Jim, I think we had Raelle on line. Did you put yourself in queue?
[00:47:50] Jim Reed: No. Sorry. Go ahead, Raelle. I'll stick myself in the
[00:47:52] Allison Mankin: queue.
[00:47:53] Rahul: Not a problem. I was going to respond to Felix's point where when it comes to authorization, I think this might be more implementation oriented, but DNSSEC is actually not as difficult to use for authorization as you might think. Because once you have authorizing entities authenticated via DNSSEC and you have nonrepudiation of whatever they say, they can easily put out a record saying, I authorize Emblem x. So that could be put out in a formally structured query that someone would need to then subsequently issue if encountering an Emblem in DNSSEC. And so I think that saying that that's not applicable might be premature. Thanks.
[00:48:56] Jim Reed: Jim Reed. The question of authorization or using DNSSEC as the mechanism for indicating that tokens are authorized is fairly clearly understood because we have a chain of trust in the DNS in DNSSEC where you have a cryptographic signature which is signed by the parent, which is set on that parent signature assigned by its parent until we go all the way up to the very top of the tree, the trust anchor, which is the one true route for the DNS. And this would also apply for the scenarios that Peter was Felix was talking about there is that if you've got, say, a country that's issuing codes, say, for example, on behalf of the Red Cross, well, the country would have the ability to insert a record into the appropriate country codes zone and take things from there. So I don't see a particular difficulty with that particular point. I do see lots of problems in trying to get DNS site deployed in all sorts of use cases for digital emblems. DNSSEC is hard. The tools are difficult to use, and, broadly speaking, only DNS geeks use them because nobody else knows how to make them work. And I think it'll be difficult to put them into scenarios, say, for example, in a refugee camp or a hospital, and asking people to go and insert records in the DNS, get them signed, and make sure that that stuff continues to be signed. This is not a one time operation, is going to be very, very hard to achieve in practice. Now there's other benefits of DNSSEC because you can get proof of nonexistence in some cases, and that can also be a valuable thing and it shouldn't be ignored. So the last thing I want to see on is really on the question of DNS related stuff. If we can capture this together stuff together and write it down in an ID, I'm going to make a shameless plug for the DNS direct to it. So if we can get all the stuff amassed into a single document, our beloved co chairs can throw this over the wall to the DNS directorate and get one of the DNS experts there to review the document and assess it. And so it's not just something that said this it's me speaking as a DNS person, but you get another point of view in that, which I think could be very, very helpful. Please don't go away. So in regards to your last point, I wonder if there might be someone in the
[00:51:20] Rowan: room who might be able to find someone in the DNS directorate that they could assign to this to this working group for that purpose.
[00:51:33] Jim Reed: There might be. I'll okay. I'll include an interest here. I'm one the co chairs of the DNS directorate. So whenever request comes in, it's a round robin list. So we're gonna assign it to the next member of the directorate whenever a document comes in, And I could perhaps adjust that to actually choose someone in the director that might be best placed to give a proper review of the document.
[00:51:56] Rowan: Thank you. Then in regards to your first comment, I just wanna make sure that it's clear for everybody here. It sounds like when you said authorization that you were talking about that the that the by the existence of the record being signed, that it was authorized to be in that position in the in the DNS tree. Correct. Yes. Yep. I think we've had three use at least three uses of authorization, including one in the requirements document which talks about so so that's a very important obvious, very important one. One is the when we some emblem types may want to do selective disclosure or differential disclosure based on who is asking. And so there there would be some kind of authorization. And I think there may be at least one other authorization. Felix specifically referred to, you know, say and an organization which is defines an emblem type, like Ramsar or ICRC, might say, we authorize these subtrees in the DNS to be able to deliver emblems. So those are three different uses of authorization that we're using. We just need everybody to know that there are more than one.
[00:53:29] Jim Reed: Okay. Can I sit down, Ali?
[00:53:35] Rowan: If you really must.
[00:53:42] Gianpaolo Scalone: Hi. Gianpaolo Scalone speaking for myself. I think that in addition to yeah. So I think that in addition to the DNS that is acting on the control plane, there should be some mechanism in the hands of the authority, the member state that has the authority to issue the emblem. That could be, for example, a special number numbering such as ECIM, MSCSDN that could be used at the on the traffic plane. There's also the advantage of the being able to control also the life cycle of the element. So the issue could be dropped in case the emblem is no more active and could give us some additional flexibility. So link it in somehow to the records. I don't know if this sounds
[00:54:39] Rowan: you. DKG, you're up.
[00:54:46] DKG: Hi there. I'm still trying to understand this idea that Rahul put forward. And I think maybe, Ruhan, you just described some of it, but I'm still a little bit fuzzy. The emblems are not gonna be just issued from the one party that controls them except in, like, the ICRC use case where the ICRC says, yes. This is mine. And, yeah, you can see it by looking up its ICRC, you know, its its record in the ICRC subzone. But in the case where an emblem is offer you know, issued by an authority that is not the entity operating the thing that has the emblem on I don't see how the DNS SEC on its own is gonna solve that problem. What what am I yeah. Ron, you meant something about So somebody delegates It was a little zone. I don't see how that works. So sorry about
[00:55:42] Jim Reed: So
[00:55:42] Rowan: it was a little bit hard to hear you, but what I heard was the DNSSEC can't vouch for some other subzone other than the one that the that it's signing for. And, yes, I agree.
[00:55:57] DKG: Right. So that that causes problems if we're talking about an emblem that is issued by a party that's not operating the thing the emblem is attached to.
[00:56:05] Rowan: Yep. So for example, if you have an emblem that's issued by the, I don't know, the Ministry of Health of Bangladesh and or it it's in the root of that that country. So
[00:56:23] Tommy Jensen: you it
[00:56:25] Rowan: there is a there is a, quote, unquote, authorization. Sorry. I'm looking at I'm looking at a picture that's not even a picture of your face. There you could you could auth auth authenticate a DNSSEC signature from, say, an emblem that is stored in a subtree under the Ministry of Health of Bangladesh and, like, verify DNS signatures all the way down to the root. And then you could see that the emblem type is, you know, dangerous forces or something. And then the emblem type could define an application layer authorization step that says that you need to check that the subtree that is is authorized to use this emblem. And there's some additional special, you know, application layer sauce that you need to do that. But it's not DNSSEC, particularly. Does that make sense?
[00:57:38] DKG: I think so. But I also saw your hand waving a lot, both literally and metaphorically.
[00:57:45] Rowan: I really am having a hard time hearing you both. Yes. There was both literal and metaphorical hand waving. Is there something else that that is I mean, this is a this is sort of how the how the physical emblems work today in some emblem types. And I think Ramsar is also in this category. I think, you know, even even sites I don't think sites is gonna be issuing emblems for every shipment of a, you know, involving some kind of endangered animal or plant or product thereof. So there is in real life, there is sort of some kind of a secondary delegation or authorization which is provided. And we need to come up with some way to express that. Again, it just because there's a record in the DNS and then that there is DNS signing doesn't mean that that requirement ceases to exist or that the way to solve that requirement is to solve it by using DNSSEC.
[00:59:03] Alex Rosenberg: Alex Rosenberg representing myself. Just a couple thoughts here. One, in my view, DNSSEC gives us a chain of trust that goes back to a domain name holder. That's a very specific thing. I like that a lot compared to general PKI. Right? It it anchors your chain of trust on something very specific, you know, a a company's reputation or an organization's reputation. And it is extremely meaningful in that regard. Dane is DNSSEC as far as I'm concerned because one's a prerequisite for the other. So that just is how you transition to another service beyond DNS. The other one is that Jim spoke about, you know, difficulties implementing these things in the real world. I think it's instructive to think about the fact that the entire software stack we're discussing here is all brand new and doesn't exist. We happen to be delivering data via existing protocols and, you know, DNS and whatnot, But we're talking about all new applications for this, and it it won't be the current agreeably very difficult tools. Right? I mean, not everybody's in the work, you know, master. But I imagine, you know, easy applications from large software vendors that are, you know, around logistics or whatever offering this feature, and it just works with whatever DNS provider you have. As well, plug ins to, you know, popular DNS implementations that talk to whatever other database. Because I think in most of these cases, the data here is not static and the data is, you know, highly variable. It's, you know, tracking lots of things, not, you know, this domain this website has an emblem on it, which would be pretty static. I I think it's all gonna come from some other kind of database than an actual DNS database, which is why I said delivery as opposed to store in DNS earlier.
[01:01:15] Jim Mosley: Jim Mosley. Hi. Jim Mosley speaking for myself. Acknowledging the fact that DNSSEC is difficult, notoriously, or historically, I think most organizations will be using service providers that provide those Geek tools wrapped up. So I think using the difficulty as a as a reason maybe not to progress or use that as probably not there for most organizations. And there are certainly developments in that area within DNS working groups to actually make that process even easier. But I think for most people, it's the the line that GHG uses, probably they're not gonna spin up their own website, and they're an Apache server and everything else to do the content of of it. They're gonna go to a service provider and do it. And I think that's gonna be the same with something like DNSSEC. They need a button to sign it. They might need instructions to put their DS key in the in in the zone above. If it's not if the appropriate RFCs are not supported to do that. But I just think, in general, we shouldn't use that as a a reason not to move forward with using something like that. Thank you.
[01:02:31] Speaker 13: Hello. Speaking for myself. I just wanted to bring some points. I read the the drafts relating to the DM working group, and I saw that they talked very little about discover names and the government authority relating to those. Because if we have a trust chain that goes back to one government, some people could use that to directly hurt a specific government or something. So I think the working group could also expand on those subjects also relating discover names because when I was looking at the drafts, it was barely talked about. And in the only drafts that specifically about in Jim Reed's draft, there was only one paragraph about it. So I think we should also expand on that.
[01:03:19] Rowan: Okay. Yeah. And this isn't specific to your comments, but to everybody. If you see something that you think is is missing in an architectural discussion and you think this is this is a problem I can solve by writing a few paragraphs, then ITF mantra of send text is the fastest way to get what you want. Dan?
[01:03:46] Dan York: I I have that weird thing. So Dan York, employed by Internet society, no longer doing much at all with DNSSEC, but spending spent many long years working with it. I it seems like I had that weird thing that when somebody like my dear friend Jim says DNSSEC is hard, my brain explodes and I have to come and and respond. So but I want as I said in the chat, there's a couple things here. First, I I will disagree with my friend Jim over here because the way that DNSSEC tools have evolved, it's like you uncomment something and you go and check this and the automated signing is all there. So that's not an argument. It's all really simple. There's a bigger problem, though. So, I mean, deploying it, putting the records in, doing all that. The challenge is that DNSSEC, the signing is only half of it. The real issue is getting it checked and validated. So and and right now, again, that's actually not a difficult thing to do. Usually, in most of the DNS resolvers, it is literally uncommenting a line in the config file, and now we'll start to check for for DNS validation. But as far as the Internet Society has a platform called Pulse where we track many different things and measure the Internet. Right now, our stats are showing only about 39% of global DNS valid global DNS queries are being validated. So only about 40% of the of the you know, from what we're seeing around there are actually checking the validations. So you could get that you could sign all you want, but only 40% of the people may actually check. And and it varies widely. Some countries, it's like 99% of all queries. Some countries, it's 5%. So the the thing would be that you're not gonna get the the full global validation of that.
[01:05:33] Rowan: Dan, do you happen to know whether that number includes reverses or it's just forwards?
[01:05:41] Dan York: I don't know. Why would you do why would you be doing reversing?
[01:05:49] Rowan: I mean, if you if you have a CIDR block, then you can sign your reverses. A lot of DNS queries are reverses. So Oh, okay. If 40% are signed and that includes reverses, that's pretty good. But if it doesn't, then
[01:06:06] Dan York: Sorry. That's not as 40% is the is the queries of validation. So it's not the the percentage signed. It's the it's the it's the numbers that are actually checked of it. And that's a kind of wider thing. It relies on some of Jeff Houston's APNIC measurement stats that go out and do different things and other different sources. So, you know, like, the big public resolvers, the eight dot eight, one dot one dot one, all those the quad nine, everybody else, they all do typically support DNSSEC. So people in countries that, for instance, have outsourced most of their DNS resolution to those big solvers, they're all checking DNSSEC. They're checking the validations. But that's the challenge of DNSSEC. It's the signing part and there's the validation part. Both are easy these days, but they have to actually be turned on. And the and the and the resolution part is the part that just is not fully happening out there.
[01:06:59] Jim Mosley: Uh-huh. Tommy.
[01:07:06] Tommy Jensen: I'm getting out of queue because I don't remember what I was gonna say.
[01:07:09] Rowan: Jim?
[01:07:13] Jim Reed: Thanks. I was just going to respond to what Dan had said that Jeff Houston's surveys on DNS utilization would be good if you wanted to track the exact details of uptake both of validation and of signing. That will give you some indications of how widespread it is. But remember, of course, that's not necessarily giving you the full picture, but it's close enough.
[01:07:41] Rowan: Okay. We have cleared the queue on this slide.
[01:07:44] Alex Rosenberg: Oh, no. Alright, Alex. I I was just gonna quickly say that I'm I'm not sure that stats on general DNSSEC usage matter to us because we're talking about validation of an emblem, which is a new thing, and a specific use case that happens to be layered on DNSSEC. So the fact that some folks don't care about the quality of their queries is not relevant. If we need validation of an emblem, then we'll we can use the infrastructure. Right? It's using an existing piece of infrastructure instead of inventing.
[01:08:17] Rowan: I I suspect I suspect it's more subtle than that. I think that it's something in between what you said and what everybody else what Dan said. Yeah.
[01:08:26] Dan York: Yeah. Just to be clear on that. So when you put something in DNS, whether it's an emblem, whether it's whatever, any kind of record, and then you sign it, you get the RR SIGs that indicate that that's been signed. So that part we could do for any kind of new record. We could do it for, you know, however it's gonna be be done in that. But but without the validation side I mean, so anybody out in the world, if they wanna go and check that that emblem is in DNS, they can check it, but only about 40% globally would know for certain that it was assigned. And and and, I mean, everybody would get the record, but only those that are actually checking it would be there. The other part I wanted to say was to be clear that Dane, which is an awesome solution in so many ways, it does rely on DNSSEC. So you are working with that part to ensure that the validation of the TLS cert that's that's inside of Dane or the record, the, you know, zone of that, whatever, that would also need DNSSEC as far to make that fully work on that. So I would be I'd be delighted if it went that way. But I also heard the comment here that you you're looking you would be looking for somebody else to authorize the use of that.
[01:09:36] Rowan: At the application level, there are some emblem types that may require that or that may require some kind of delegation, a delegation which may or may not be a DNS delegation.
[01:09:50] Dan York: Right. Yeah. Because the DNS side, whoever owns the domain, you know, can put whatever records in and sign them. Yeah.
[01:09:58] Rowan: Okay. So we we're we're very far away from being able to look at those Okay. Specific requirements yet, but I think we will this is laying the groundwork for us having a common understanding where, you know, we can start to discuss those kind of issues maybe next meeting.
[01:10:15] Dan York: Alright. And I will go fully read all the documents.
[01:10:27] Rowan: Okay. Here's another one. If you want some more fireworks. Where are DM related DNS records rooted? So oh, yeah. I had newer version of these these slides, but this has in a dedicated route, dedicated domain, d m .arpa, something rooted there. It could be something that is rooted in the issuer's domain. It could be rooted in a domain associated with the asset. The asset may or may not have a separate domain of its own. It could be in a reverse. It could be in in adder.arpa. It could be in something else. Felix?
[01:11:19] Felix Linke: Yeah. I would say definitely in the assets domain, maybe in the issuers domain. But at this level of abstraction, it's actually hard for me to distinguish issuer and asset. So if you say you just we assume the domain name to be given, then the boundaries become blurry. I would be I have I don't see any benefit of dedicating a specific subzone to emblems. I would be so I wouldn't do it. I would be curious if there is someone who thinks the contrary.
[01:12:01] Tommy Jensen: Okay. So I remember what I was gonna say last time, and it's related to this one.
[01:12:05] Rowan: Tommy, what's your name?
[01:12:07] Tommy Jensen: I don't remember. Jim, apparently, statistically. For the notetaker, Tommy Jensen. Sorry about that. I'm not being inclusive.
[01:12:16] Rahul: So
[01:12:19] Tommy Jensen: I think this is pretty this gets specifically into different emblem uses that I don't think the architecture needs to specify or answer this question. I think the architecture should say there are possibilities and the emblem needs to declare where it's stored.
[01:12:38] Rowan: Tommy, FYI, I agree with you that the architecture probably does not need to say anything about this, but I think that the authors of the architecture need to understand this issue in order to be able to communicate with each other.
[01:12:53] Tommy Jensen: Meaning, like, understanding that, like, the trade offs or understanding which maybe that nobody cares about at all for their emblem cases?
[01:13:03] Rowan: Or or even just which one they're doing when they make a proposal, that they're doing that they are, in fact, making a choice in doing one of these.
[01:13:11] Tommy Jensen: Oh, sorry. Let me clarify. I don't think the architecture authors need to make this choice because I think that's something that different emblems may choose to put. Like, for example, if it goes into different zones, like, what does the architecture care? Like, emblems are in names. Names are in the DNS. And I might be wrong. I'm just that's my current take on this is I don't I feel like that might be overbearing for an architecture since emblems will probably wanna do different things.
[01:13:43] Jim Reed: Jim Reed. Just what the other Jim just said, I think it doesn't really matter so much about where it goes in the issues from that assets domain. A domain name is a domain name is a domain name. Doesn't matter. I would have thought from the point of view of trying to do the rendezvous discovery for these assets, we probably want to agree in a common, say, sub string, say, example, _dm. Domain name as being the place to find token that you want to look up. The problem I think we have though is how will some application or device out there on the Internet know which domain name to use to look up something. And I'm not sure we have a handle on how to deal with that. Excuse the pun. As far as dm.arpa is concerned, I think that's a bad idea, and we shouldn't really try to take that any further. One of the issues we'd have to deal with with that, but there's several actually. But one of the big concerns is some is going to have stand stand up a robust, 100% reliable DNS architecture service for that just as we have for nro.arpa, ip6.arpa, and all the other stuff that goes on. I think that's a non starter because, first of all, who's going to pay for it? And then the next question then is who's going to be in charge of populating it? Would this be an Ayanna thing just as Ayanna deals with some certain other kind of issues to do with numbering resources and so on like that? And we've got other things into ARPA as well that have got discrete entities responsible for managing them. And if we go down the dm.arpa route, we would need to find somebody that would take charge of managing that namespace. And I think that's also going to be a problem. It's probably not worth trying to trying to do that.
[01:15:38] Rowan: Allison?
[01:15:45] Allison Mankin: But I think that the question of is there a dot ARPA domain of some kind playing here or an IANA registry of some kind, the OU registry or a number of the registries that we have is different from I'm I have a bunch of of assets with digital emblems, and I'm putting a bunch of names for them somewhere. I'm gonna make sure you know where they are. Right? But we could use something like dime.arpa or an IANA registry with suitable expert review to help people figure out where to start if they're looking for somebody's domain. You know, like if the if it's it's UNESCO has agreed that the Ramsar wet wetlands should be there. What's the name of the domain the the the zone where they wanna start those? Right? And that might be something that you would put in a more centralized place where you might do something else with it. But as Jim says, we do have a lot of examples where we've created discovery registries of different types. And one of those is dot ARPA, which we, IETF, administer. And one of them is IANA, which we give IANA instructions about how the IANA wants to administer it. So we I think the architecture that people can think about that as a tool and think about what the offerings might be there. And maybe there is a central thing which would be available for everybody which the architecture would design.
[01:17:25] Rowan: Jim?
[01:17:28] Jim Mosley: Hi, Jim. Speaking for myself. I would say that don't put things on the dm.arpa unless it's to do with a sort of trust issue or verification thing. I think the records are better put under either the issuers or the assets domain. Yeah. And and unless it does that trust or verification thing, yes to putting stuff under a specific location that the other Jim mentioned, like underscore d m as a DNS SD label because then there's a specific place in the hierarchy to to look for it, and we're not sticking things in the apex. So that I think might avoid the registrar type registry type problems that people have got to go to an organization and shove stuff in. Obviously, having it under one place then leads to potentially concerns about the resilience of of that and maybe even DDoS. So that that that kind of thing. So I I think it's better split up under the issue as all the assets. Thanks.
[01:18:33] Rowan: Tommy, you're actually in the queue next.
[01:18:37] Tommy Jensen: So I just wanted to ask a clarifying question because, Alison, your comment actually confused me a little. Well, not confused me. Surprised me. Are we talking about in scope including in scope the discovery of asset identifiers? Meaning, like, I don't have the domain name yet, and I'm trying to find the domain name where versus emblem discovery, which is I already have the asset identifier, and I want to see if it has an emblem. Because when you're talking about, you know, as a human being abstract, I know that Ramzar has some things, but I don't know what name it is. That to me, I didn't think was anywhere in our scope. And I'm not saying that's like a charter statement. That sounded harsh. I I didn't realize we were attempting to solve that. And so I just wanna clarify, like, am I the odd one out? Are we attempting to solve this? Were we taking for granted that we start with a with a asset identifier already?
[01:19:35] Allison Mankin: I mean, from a practical standpoint, we want the use cases to be able to do that. And that will be different for different use cases. So when we did when we did our our Ramsar prototype, what we we thought we would do is have some way of of having a a location and say, is there a Ramsar wetland in this location because I'm just about to do something to it? And that is not something that we would design. In fact, we would look to design we would look to use existing capabilities. But the DNS name that's that's in there could either be identified in an abstract way or it could be identified in a way that has been, you know, that the identifier could be derived from what you what you what Ramzar was able to provide you. And then look in you look at Ramzar, figure out there is one. Now go look at the authorizations and everything else about it that you can find that's associated with the with the with the digital emblem.
[01:20:47] Tommy Jensen: But it doesn't need to be addressed in
[01:20:48] Allison Mankin: the art Mike? So so the ability to to do that discovery should be addressed in the art sorry. The the ability to do to do that sort of go have a use case specific discovery should be called out, and then the ability and then any given any the architecture should allow you to create a record that helps with that while not necessarily doing that. Is that is that clear enough, Tommy? Yes. So I think that in order to be a full offering of digital emblem, we have to address some ability to do that. But the emblem itself won't necessarily be self contained for that kind of discovery.
[01:21:34] Jim Reed: Jim. Jim Reeds. Back on the issue of DM. ARPA, I now want to put another nail in the coffin and spit on its grave. I'm being diplomatic here. It was suggested or thought might be that Ayanna could oversee dm. Arpa and perhaps then have dealings with, for example, UNESCO about entries to do with wetlands or whatever. And presumably, that would then extend into other international organizations such as ECAO, the International Civil Use Aviation Authority, and so on. Now if we go down that path, we're also going to be a huge world of heart because we then have to engage with all these organizations and work with them at their speed in order to come up with procedures to handle delegation requests and authentication of delegation requests and figure out how Ayanna and these other organizations each talk to each other.
[01:22:37] Rowan: Could I repeat one thing you just said? Yeah. At their speed. Yes.
[01:22:45] Jim Reed: And I I I oh, wait. Wait. Wait. No. I can speak from personal experience about this because we had a technology called Drip, which is do with mapping drones into nonroutable IPv6 addresses, and we had some discussions with ICAO, the Civil Aviation Authority, about having them acting as some kind of authenticator of requests. Someone came along saying, I represent these bunch of numbers to do with some particular country. ICAO would go and talk to the national the relevant Civil Aviation Authority and come back and give a yes or a no answer. That was how we thought we'd approach this. And then we spoke to people from ICAO, and I said, this will take us a very, very long time because it's a very, very conservative organization. And sometimes decisions might have to wait until three or four plenty potentially meetings time. Each is about five years apart. So it may take it would have taken perhaps ten, fifteen years before ICAO could give a signal to see whether they could or could not take part in that kind of exercise. We may well find the same problem with other kinds of international organizations. So I think we just don't go down that path.
[01:24:00] Rowan: Okay. I'm gonna skip this one. Alright. So among the possible types of digital assets that may need an emblem, There are several different types, and we've been primarily talking about, I think, the easy one or the easy ones, which are I have a service or a server which is represented by a fully qualified domain name by in that that is the front door to that service. But that's how I normally use it. That's what I normally use. I normally resolve a query for, know, some random web server or whatever what what it whatever it is by fully qualified domain. However, there are a number of other types of digital assets that do not already have a fully qualified domain name associated with them. They might have a public IP address as their main identifier. And you may say, well, yeah. But you can use the reverse to find the fully qualified domain name. Maybe, maybe not. I don't know. But if I have a private IP address inside of a system, that's a little harder. You know, it might be a private IP address that is connected in some way to the Internet through a network address translator, but it might not be. It might be inside of a network, inside of a a vehicle. You know, inside of some piece of some larger piece of equipment. On the Internet, it might be an entire autonomous system. That's for those of you who are not aware, that's how we describe a basically, service providers that have a bunch of of subnets associated with them. It might be data at rest. It might be data in flight. And so being able to figure out what an FQDN is that that is relevant to some of these other digital assets that might be a little hard. And so I would encourage people not just to think about the simple, but to give a little bit of thought to the rest of these use cases. I must be doing something wrong. There's nobody in the queue. Something provocative. Not being provocative enough. Tommy, was that in regards to
[01:26:59] Tommy Jensen: this slide? No. No. No. No. No. I was I was derailed by Ori's excellent commentary in the chat. Tommy Jensen, I wanna be really careful here because I sure we can, but I don't wanna bog down the architecture document with what the charter essentially tells us we can take for granted as there's an FQDN in place. And just so that everyone doesn't have to go off, you know, command tabbing to it, the part I'm talking about is saying the working group will develop an initial DNS base, blah blah blah blah blah, that explicitly identify their bearer by a fully qualified domain name. So, like, that's in place already. I I do agree in the long run that that's a thing, but I just don't wanna over overengineer the architecture document for something we're not required to solve yet.
[01:28:03] Rowan: Yep. As as a co chair, I want to make sure that it will be possible for us to extend this architecture for things that don't naturally already have an obvious fully qualified domain name. That is not the you know, we don't need to we don't need to come up with a fully fledged architecture describing how all of those discovery mechanisms work. But I think we would be remiss if we did not at least have some hint of an existence proof. Does that make sense, Tommy?
[01:28:56] Tommy Jensen: It does not because I don't know where the that line seems really fuzzy. Like, either we're accounting for it or we're not. I don't know what an architecture with a hint looks like. And I'm not trying to be coy. Like, I I don't I don't know how to envision that.
[01:29:09] Rowan: I would I would suggest that if somebody suggests an architecture one two architectures and one of them solves all of our current requirements or both of them solve all of our current requirements, and one of them has a straightforward way to handle non non sort of obviously full of qualified domain name assets that it would make sense for us to prefer the latter.
[01:29:44] Tommy Jensen: I agree that would make a good tiebreaker. I am doubtful that those two things will require equal effort, And so I'm concerned about what that effort delta is and spending the working group's effort on that right now. Alright.
[01:29:57] Orest Steele: Orest, deal. My advice would be do only enough in the architecture that you need to get some interoperability on FQDNs working. Don't do anything else until you can get to that point in the architecture, like, seriously. Like, I think it's super dangerous. I'm I'm joking in the chat about, you know, agents being in scope. Like, it's a bad idea. Like, figure out how to get some kind of interoperability on FQDNs. Whatever that thing is that's connected to FQDNs, you know, maybe you've got metadata. Maybe you can point to other things. Maybe you can talk about it. Like, let's get interoperability around that piece. That would be my recommendation. So I think it's I think it's good to to talk about discovering, you know, pointers. I like the indirection a lot, but I think I think as soon as you start saying, like, I wanna imagine a way for this to work for things that aren't in FQDNs, you're just taking the working group into a dangerous trap.
[01:31:10] Rowan: Okay. Last slide of my provocative slides. But this certainly did accomplish my and, you know, our intended goal of getting some discussion going. So there are a bunch of requirements which are mentioned, which are not necessarily requirements for every emblem type. So just a handful of them here is offline supported for this emblem type. If so, how? Undetectable validation. Is that required for a particular emblem type? Okay. How would you deal with that? Validation verification. That's kind of an important one. I think that probably gonna apply to most emblems. Traceability. Is traceability important or logging about, you know, when a when an asset was when an emblem was created or when even when an asset was was queried or even, you know, even maybe for for further than that, whether differential or selective disclosure is required for a particular emblem type. And then, finally, how do we deal with the request for privacy if that's an issue for some m one types? So lots of little things here. If anybody wants to talk about any of those, feel free. And, I mean, this is the last slide, so I'm gonna sit down. Please feel free to have some discussion. And if there's other things that are not on any of these slides,
[01:32:56] Tommy Jensen: go for it. Tommy Jensen, I was just getting up to say I think this was comprehensive when I was writing out a scratch draft of my own. I I don't think I even got all of these. I think this is great, and exactly what I was hoping that a architecture would have is basically the reminder to imp implementers, writers of emblem drafts of these are the various things that can be accounted for. So, yeah, I like this slide. It's a good one.
[01:33:28] Felix Linke: Tommy said it all.
[01:33:38] Allison Mankin: Without putting my hand up, sorry. I think you need you might wanna add removability. You know, easy add, easy remove.
[01:33:49] Rowan: Thank you. You know, it's funny. I thought of that one as so important that I didn't it didn't even occur to me that we might not include that. So, you know, while I put this together, this is these are not my slides. These are slides for the working group and for the team that's working on architecture. So please, like, get together, go forth, make some more make some architect some more architecture documents, like, discuss. And, you know, I I'm really hoping that we're gonna have a lot more concrete examples of, you know, hey. Here is an architecture that shows how we meet such and such requirements, or here is a way that we, you know, we have some representative vignettes for several different use cases, and we can show how we meet you know, plausibly meet the requirements of of all of those vignettes, that would be a great outcome.
[01:35:16] Nick Williams: Nick Williams speaking for myself, but aspirationally also a gym internally. One of the things that I don't see up here that I think might be interesting to consider is also the, I'll call it, disaster recovery scenario in the event that you no longer if we are kind of talking about DNS, the concept of you would like to make updates to your emblem or add emblem, etcetera, but you don't necessarily still have access to that infrastructure and how that delegation might look. So I don't know if you'd call that federation or delegation, etcetera, but that concept might differ based on the type of emblem or the use case intended for that emblem, that there are some that are more secure or held versus others.
[01:36:09] Rowan: And you would think of that as distinct from offline?
[01:36:14] Nick Williams: Doctor, I suppose, could be offline in the sense that you no longer have access to it, but it could also be a federated, model where something like an emergency situation means that you're minting potentially a new organization that they're gonna have their own capability to be a subset of your emblem. I'm thinking of something theme alike where you have somebody that is in a field that is responding to something where you have the apex that says, yes. Hey. I am a part of FEMA, but guess what? We are the ones that are responsible for responding to either this particular thing or something else. So I don't necessarily know that offline is the prerequisite. To me, it's more about the use case in which either you can't act on your own or you are empowering somebody to act for you as a part of that emblem. And that could potentially be offline, but it could also be intentionally online.
[01:37:46] Sarah: Alright. We've joined the queue. I think we've had a really substantive and good discussion about architecture, so thank you all. A reminder that the working group last call for the use cases and requirements document is open. We didn't do a sort of round of applause to say we got there. So I think let's take a moment. Continuing the round of applause, massive thank you to Laura for taking notes. I assume people wanna take a a quick look over them just to make sure that anything that was said was covered accurately or if anything that you think was missed needs to be added in. And call that if you have any further thoughts on the architecture to take them to the list. It is the best place to get kind of immediate feedback from the working group as a whole, and we'd like to see as much kind of list traffic as we possibly can so we can kinda continue in the spirit of having a bit of a back and forth that we've had today. Yes? No. In which case, Jim.
[01:38:51] Jim Reed: Thanks, Sarah. Thanks also to our beloved co chairs for all the hard work today and in the run up to this particular meeting. My question though is, what are the next steps? We've had a very productive discussion today, I think, but I think it'd be very helpful. We try to identify what happens next and timelines for that and perhaps even put people on the spot to actually produce deliverables by those timelines. And I I would utterly delegate that to our co chairs because they run the working group and perhaps even an AD if necessary.
[01:39:43] Sarah: We're gonna try and and set some meetings for folks who have specifically requested that they they want to kind of work on the architecture directly and get them to get to work on this. We will have, hopefully, an interim before 01/27 so we can kind of present some early thoughts on that.
[01:40:02] Dan York: Think it's
[01:40:02] Sarah: probably the plan. Yeah.
[01:40:08] Rowan: And, you know, for an interim, you know, I don't think we're gonna be doing it in August. You know, a lot of people won't will be on vacation and stuff, but we also don't wanna delay very long either. So thanks.
[01:40:28] Sarah: Alright. Thanks all. See you on the list. That's fine.
[01:40:57] Allison Mankin: That's true. Hey, Jeff.
[01:41:00] Tommy Jensen: Yes. We