Session Date/Time: 28 Apr 2026 15:00
Sarah Jennings: All right, that number is it's crawling up, but we have what do you think Rohan, should we make a start?
Rohan Mahy: Hello, sorry, I'm back.
Sarah Jennings: All right, good to have you back. Should we get going?
Rohan Mahy: Yep.
Sarah Jennings: All right, so welcome to the DM interim for today. We've got two hours. So Rohan and I are your co-chairs. For today, we as is customary for IETF meetings, this is the Note Well. So by participating in the IETF, you've agreed already to follow the processes and policies. And this is a friendly reminder of those policies. You can use the QR code to kind of see the linked version of the text. But just as an overview, you're expected to behave in a professional manner and extend respect and courtesy to your colleagues at all times. If you're aware of any contribution that's covered by patents or patent applications, you must disclose that fact. There is more detailed process information in RFC 2026 and 2418. And the IETF makes public written, audio, video and photographic records, including this meeting, so that is set out in the IETF privacy statement. If you have any questions, you can come to Rohan and I or Charles as our responsible AD. I'll give you a chance to take a little moment on that.
So for today's agenda, our intention was to go through any sort of outstanding issues and pull requests that we had in the GitHub for the draft-ietf-diem-requirements. We've sort of pulled out six sort of thematic groupings as it stands. So the first is protective emblems under IHL versus broader IHL use cases and that's covered in PR 31 and 35. Clarifying the independence of different emblem types and a kind of effort at future-proofing the working group's work, that's in PR 34. Forensic tracing requirements in issue 26. Proof of presence in PR 25. Response requirements in PR 33. And then other discovery mechanisms beyond DNS, which is issue 36. Do we have any bashing of the agenda? Anything that anyone wants to raise?
That sounds like a no to me. So that's what we'll kind of allocate our time to. Our intention is to spend about 20 minutes on each of these, but we can be flexible if something needs a little bit more conversation or if we blissfully get through something very quickly.
So the kind of goal for this meeting is to find a path to resolving those outstanding PRs and issues for the use case and requirements draft so that we can be in a in a kind of position where we reached consensus and we can take it to a working group last call to demonstrate that. Our current plan as chairs is not to go to IETF last call and publish the document as an RFC and that instead the use cases and requirements document would stay serve as a kind of stable point of reference for future work to guide the architecture and ultimately the individual emblem design work. We are things that we kind of want the working group to keep in mind for this meeting. So the first is that the requirements are derived from any of the exemplary use cases that are set out in the document. So we want them to be grounded in genuine stakeholder need, but we don't need to have an exhaustive set of all possible use cases provided that we have covered all of the kind of core requirements that we think are necessary at this stage of the working group's work. We want our requirements to be kind of relatively flexible and future-proof. We need to work within the scope of our charter, but we also need to be careful about unnecessarily limiting future work by what we do at this stage. And then finally, we want to reach rough consensus. Our any objections that folks have in today's meeting or on the mailing list need to be argued and not just asserted and we encourage folks to work on consensus text and come to some agreement.
So with that in mind, we're going to start off with PR 31 and 35. Ah, Felix, go ahead.
Felix Linker: Yeah, hi Sarah, just a question on current plan is not to go to IETF last call and publish as an RFC. Is there a distinction between working group and IETF last call and did you want to make that explicit? Okay.
Rohan Mahy: Sure. So working group last call is we issue a last call on the on the mailing list on the DM mailing list and you would expect that you know the people who subscribe to that mailing list are the people who are going to respond and read the message. A few people will also probably get, you know, have been maybe lurking who attended the BoF and haven't been actively participating, they might send in some reviews. Some other people might sort of there's a working group last call mailing list that people might be see and then go and make some comments. But it's basically the participants who you already know. And so it is about consensus of the working group and the comments that the working group itself makes. When we go to IETF last call for say the architecture document or certainly for any protocol, that's going to go to a much wider group of people within the IETF who have experience in whole bunch of different areas. You know people who mainly work on routing or people who mainly work on on email or people who work on some security technology that that isn't represented here, right? And so they're going to have these different perspectives and they're also going to have sort of a feel of how things are done over a wide range of of different working groups and different parts of the IETF.
Sarah Jennings: And and just to add, we we think that going to working group last call on the use cases and requirements document means that we can be assured that we have consensus within the working group and that we're happy with that as a kind of foundational document for the work that the rest of the working group is going to take on. But it also balances that with you know IETF last call can take a lot longer and it can it can raise more issues that kind of need to be responded to. So it helps us to balance getting on with the work and and moving on with the architecture document. Does that answer your question, Felix?
Felix Linker: Yes, thank you.
Sarah Jennings: Cool. Jim?
Jim Reid: Thanks. Just to expand a little bit on what Rohan has just said is the IETF last call is done by the IESG which is the collective of all the area directors. And that's so we get a multidisciplinary review in the IETF of any document that's going to become an RFC. And of course that can take time because the IESG are very very busy. And amongst other things the IESG can do is they can send a document back to the working group if they think it needs more work or this lacks clarity or they can pass it on to one of the directorates if need be because they think it could do with some scrutiny by one of the directorates although I don't think that would be the case for this particular document. So just because we have a document reaching consensus in the working group doesn't mean to say it's a done deal at that point. It should be, but there might be further work needed.
Rohan Mahy: Yep. Thanks, Jim.
Sarah Jennings: Absolutely. All right, in the interest of time, we're going to move on to talking about our first kind of set of PRs. So this is IHL use cases PR 31 and 35. We have these slides where we have a bit of an explanation but folks should should feel free to to look at the GitHub and if if we need to we can always screen share so we can see things in a bit more detail. But currently as the draft is written it just talks about IHL use cases generally and it talks about protective emblems for the Red Cross, Red Crescent, Blue Shield and dangerous forces emblems. And quite a lot of the discussion that's been had on the list today is about the distinction between the kind of protective emblems that describes that kind of set of four emblems and then protection that might be conferred to an asset because it is a civilian asset but not necessarily because it displays the that particular distinctive emblem. So it's a sort of second order effect. You say I am an ambulance and therefore I derive protection from international humanitarian law without necessarily displaying the protective emblem. And we think that this was kind of leading to a little bit of confusion and conflict between those two different use cases between kind of stakeholder groups. So we've suggested splitting them out and having protective emblems under IHL so that list the Red Cross, Red Crescent, Blue Shield and dangerous forces emblems and then other IHL use cases that use recognizable insignia and logos. Did you want to come in on this?
Rahel Fainchtein: It's just a small point I think it's an oversight but you didn't mention and it's not written on the slide but there's also the civil defense right so there's four in total but I I see that in the text so just to clarify.
Sarah Jennings: Yeah, this is almost certainly my fault for doing the slides a little bit at a last moment. Um, so yeah we want to get thoughts from the working group about this as an approach to split out these two different use cases in particular that because from as chairs from where we're standing we think that they they come with slightly different requirements because there's that kind of second second order protection. Bill?
Bill Woodcock: I think it's valuable to name specific users and specific use cases as we're documenting use cases, but I think it would be going in the wrong direction to try to name specific users or specific business processes that those users might be employing in the protocol documents themselves.
Sarah Jennings: Can you expand on that a little bit but what you mean by kind of specific business practices?
Bill Woodcock: Well, so this idea of protection, right, is a business process between the issuer and the validator, right? And so protection might be like we feed the animal, you know, every four hours or it might be we don't bomb the church or it might be, you know, this needs lead shielding, okay. There are a lot of different kinds of things that protection means for different parties and different contexts and that's exactly the right thing for documenting the requirements in specific use cases, but I want to be really careful that we don't start moving these specific business process things into the protocol. Protocol should be general, we need, you know, something that documents how we move data around, not who does what with the data.
Sarah Jennings: Yeah, I mean I think as it's currently drafted I don't think the text sort of strays into I guess I'm seeing that as almost kind of handling instructions as to as to what happens after the receipt of the data but that's something certainly we can take a look at and make sure that that's uber clear.
Rohan Mahy: Yeah. I agree and and I'd I'd invite you to have a look at the text from PR 35 to see if there's anything in there that that stands out as inappropriate. I think the the other place that I'll mention is that eventually people are going to need to define specific emblems and when they do that obviously they're going to want to put specific things that that are appropriate for a particular emblem type and do not apply to other emblem types.
Bill Woodcock: Yeah, but that's like saying people define their specific, you know, content on web page right has nothing to do with the protocol.
Rohan Mahy: Exactly. It's defined when you, you know, I'm defining my emblem, here it is, I reference the protocol document for I'm going to use this piece of the protocol and that piece of the protocol and these are the pieces of the protocol that everybody has to do and here's my additional my additional stuff that might include things about validators and all all sorts of things like that and boom you have your emblem.
Bill Woodcock: Okay, but fundamentally that's an agreement between issuer and validator as to what they're expecting to exchange over the protocol. It's not something to do with the protocol itself.
Rohan Mahy: Right. Like a schema would be, for example.
Bill Woodcock: Yeah. Okay.
Rohan Mahy: Okay. Do we have any other any other comments on some any specific language in PR 31 or 35? Rahel.
Rahel Fainchtein: Um, yeah, so my thing was that I'm having a bit of trouble from the text itself understanding what the concrete differences are here like because um, yes mentioned um Sarah the distinction between uh something that is like a specific emblem that's mentioned under IHL uh versus something that is uh humanitarian infrastructure uh but doesn't necessarily have that specific emblem. Uh I just yeah in in practice in terms of what they would be doing to notify the emblem like I I the language to me seems very vague and I'm confused as to how there's really a distinction here. Like we we're leaving that to later so there may or may not be a distinction.
Rohan Mahy: Um, for I mean I can I can give you one concrete example which is if we if somebody went to go and register two emblems one for you know one for one of the protective emblems that's that's defined in the Geneva Conventions and another one that is for some other use that's covered under under the other section that we would not prevent them from doing that.
Rahel Fainchtein: Okay. But in terms of how they would actually show the emblem or what they would need to do for the emblem per se, um we can't we're not really making a distinction here. Like we're leaving that to later so there may or may not be a distinction.
Rohan Mahy: I would agree with that.
Sarah Jennings: I think some of where this kind of specific splitting comes from is the discussion that's been had about the kind of specific ICRC use case versus there being a sort of more generic set of use cases that might exist and wanting to to make a distinction between those. Like as it stands we think that they're probably very similar ultimate emblem types but they're coming from kind of different underlying agreements and treaties and slightly different stakeholder bases. So just making sure that we're being very clear that there's a kind of delineation of where they're coming from. One's linked to just the the statement of protection and one is linked to the asset itself.
Rahel Fainchtein: Okay. Thank you.
Rohan Mahy: Sarah do you think we should move on or should we wait for more comments on this?
Sarah Jennings: I think we're good to move on. Giving people their last five seconds. Cool. All right.
So Allison.
Allison Mankin: Yeah, sorry I'm having a little trouble finding the queue, not enough coffee. Um, can can you go over what's currently in pull request 31 because there was a lot of debate about it are we going to or tell us how you're going to like move along on these pull requests now because PR 31 has a lot of back and forth in the discussion um and are are the chairs satisfied that that has kind of settled down or do you want to air any of that in the meeting?
Rohan Mahy: We've had comments within let's see. The most recent comment that we had was was yesterday. I think um you know it might be worth waiting another day or two but I I think that there it seems that there there appear to be no unresolved comments at this point. Um and the main thing would be for other people to have a chance to look at it as you know the PR is still relatively young. Anyway, the I think the important thing here is this this group has been forewarned that there is a PR. Um we can post a summary of what it says on the on the mailing list people can have a look, they can discuss it on the mailing list, they can discuss it in GitHub um but uh it seems like the things have been have been ironed out a bit on on that PR. And 35 just was posted today so I don't expect that we would immediately merge that one.
Allison Mankin: Thank you. Actually I've caught up now with reading the state of the document under PR 31 and it does look like it's been ironed out. So thank you.
Sarah Jennings: Great. All right, let's move on to PR 34. So this is some text that I've suggested um being very clear in in my capacity as chair which is about kind of emblem independence and future-proofing of the the working group's work. So on independence it's kind of alluded to in how we talk about you know requirements possibly being contradictory between individual emblem types but just making very explicit that each emblem type is independent and that the requirements for an individual emblem type don't constrain, override or or otherwise affect the requirements design or use of any other digital emblem. So for the purposes of clarity if if somebody sees um you know an emblem that requires undetectable validation and one that requires you know proof of presence or forensic tracing that those two being in conflict and and existing in two separate emblem types is is perfectly valid and and there's no crossover between the two. The second is um about kind of making a clarification that where there's some limitations in the use case and requirements about how an emblem is deployed whether that's stating that it's only applicable to digital or physical assets that it has you know a really very narrow scope of valid issuers or it's only available through a very specific discovery mechanism that that's only reflective of the current set of use cases and that those limitations could change in the future if the working group decided to kind of revisit the topic and open up the discussion about a kind of additional use case or an adaptation to a current use case. We're conscious that the the working group in in sort of narrowing things down at this stage if there is a change of intention behind any of the groups for a specific emblem type needs to be able to adapt to that and be responsive to that. Welcome any thoughts.
Rohan Mahy: Um I think we forgot to ask about a notetaker.
Sarah Jennings: Yeah. Okay.
Rohan Mahy: Um do is anybody here willing to take notes?
Felix Linker: Um just action items and decisions?
Rohan Mahy: Sure.
Felix Linker: Yeah, um sure. I I can, yeah I can take notes.
Rohan Mahy: Great. Okay. Thank you.
Right. Um do we have anybody who um objects to this to this in concept? And do we have any any concerns about specific language in 34 that um that you don't want to put in the on the list or in the GitHub that you'd like to mention right now? Bill.
Bill Woodcock: Just what I said in the chat, I think the phrase valid issuer or valid validator is anathema. I don't think we want to say that there are specific parties who are or are not allowed to use IETF protocols.
Rohan Mahy: Um I think it's referring to given a specific emblem type. So um I could have an emblem type that requires no validation and I could have another emblem type that that um just says that it needs to be rooted in that the issuer needs to be rooted in in the DNS and DNSSEC. You could have another one that says you know we the law says that these people are allowed to um you know ICAO or you know some organization is allowed to to make um
Bill Woodcock: The law is external to the protocol. The law is different in different jurisdictions. We don't deal in laws.
Rohan Mahy: Yes. And why is that a problem for an emblem to say that since an emblem specifically refers to a law is this a problem?
Bill Woodcock: No, the protocol should not refer to laws and protocols.
Rohan Mahy: The protocol doesn't refer to the protocol doing it. It refers to to the the designers of specific emblem types.
Bill Woodcock: Okay, but what is an emblem type?
Rohan Mahy: Um so an emblem type would be a um let's say you define an emblem type for um hazardous materials markings. So each instance of a hazardous material would be an emblem and emblem type would be this is a hazardous material emblem type.
Bill Woodcock: Right, so anybody could mark something as hazardous and depending who the issuer was a validator might or might not consider that meaningful information. Doesn't mean that an issuer is a valid issuer or not a valid issuer.
Rohan Mahy: So that emblem type could choose to say that every issuer is a valid issuer. Or it could choose to say that any issuer rooted in the DNS is a valid issuer.
Bill Woodcock: But but again this is bringing us back to the question of what is an emblem type? Like I'm really not clear that we have a shared consensus on what that phrase means. To me what if somebody asked me to define what emblem type meant, I would say that an emblem type is a specific combination of RR types in the emblem bundle. Right? Like if it consisted of a LOC and a time and an A record or something like that would be a type. But that doesn't seem to be what you're talking about.
Rohan Mahy: Yeah, I I think that there has been the idea that it is in the charter that there is a law, convention, treaty or you know words like this that is associated with a particular a particular emblem. And so I think that you would probably say that it would be one of those. Um so what about press?
Bill Woodcock: Yeah.
Rohan Mahy: So um somebody might try to define a you know some some group might try to define a generic press emblem type and somebody else might try to define a a more specific press emblem type that is for you know a say press in um in Europe or press in North America.
Bill Woodcock: Or Reuters versus BBC, right? But those aren't different types. Those are just different emblem issuers.
Rohan Mahy: If somebody wants to define an emblem type that says that they are um that this is a generic press press emblem type, they can say you know in order to be a valid issuer um then you need to be able the validator needs to verify that you are actually a member of the press according to some particular particular organization or some particular definition or they could say they don't require that at all.
Bill Woodcock: But I mean we already had the interesting characteristic of that use case was that there is no authority that says who is and who is not press. Press are civilians who are engaging in journalism. Full stop, right? I mean that that is the definition both our understanding of it and in law.
Sarah Jennings: I'm just following some of the discussion that people are having in the chat about perhaps Felix with the suggestion of of using use case over emblem types. But but both Alex and Tommy making the point and I think this is this is where I agree that types are whatever we define at the third stage of this, the the kind of additional the profiles, right? Each individual RFC that takes each of the requirements according to the architecture document and implements them and they're kind of subset of according to whatever the the use cases are. There might be multiple emblem types for each use case, right? That that's perfectly within the rights of individuals to define. But we do have as it stands within the use cases and requirements document within the protective IHL use case a reference to there only being a certain set of of valid valid issuers under IHL those who are authorized to bear an emblem or other distinctive signs so we do have a kind of limitation there about who the valid issuers are. But as you say Bill there there may be other cases where somebody can just make any claim that they see fit. It's up for validators to to make a distinction as to whether they accept that claim.
Rohan Mahy: Um I will add um Alex mentioned specifically using the word profile um and we had we had talked about you know I had mentioned like something like a schema. Um so those are sort of two alternate alternate names that have been come up with independently for this type of thing.
Bill Woodcock: Maybe we could talk through the phytosanitary use case because that's a fairly specific one where there is a clearly defined set of pieces of information that need to be conveyed and if the person if the validator encounters unexpected information either more or less than expected or something not formatted correctly or whatever the they're not going to be able to proceed under their legal requirements. Right? Um so that seems to me to define I mean like in my conception of what a type would be that's a specific type of emblem because there is a business case between a set of issuers and a set of validators where there is a specific set of expectations that need to be met in order for the protocol to be useful to that pair. Does that resonate with anybody else's understanding of what a type would be?
Sarah Jennings: What might be helpful would be this specific conversation about who is a valid issuer um and the the kind of sense that that the idea of there being valid issuers and that being something that's defined external to the protocol seems to come primarily from the protective IHL use case and I wonder if uh some of the people who are particularly involved in that might want to
Bill Woodcock: We keep rat-holing on this one use case to the exclusion of hundreds of others. Well what about the Ramsar use case for example? Right, well that's that's a pretty simple one because there is a specific treaty organization that is the registry, right? So I'm not particularly interested in that one because it's a simple one that doesn't actually exercise the problem here, right?
Rohan Mahy: Does it have a set of valid issuers?
Bill Woodcock: It has one valid issuer.
Rohan Mahy: Great, it has a set of valid issuers.
Bill Woodcock: Right. Okay, but with the phytosanitary one, right? Is the set of valid issuers anybody who's in possession of a piece of wood? What?
Rohan Mahy: What does the treaty say? Who can assert that that that a pallet has been has been handled in a particular way?
Bill Woodcock: Anybody who has a piece of wood can make assertions about the handling of that piece of wood.
Rohan Mahy: That that's what that emblem type says is the valid set of valid issuers.
Sarah Jennings: What I think we might be coming round in circles on here is as it's currently worded it says a narrow scope of valid issuers, which is suggesting that there is a set of valid issuers for every emblem type. I think probably more so what it should say is a defined set of valid issuers. Because in some cases there will be no set of valid issuers and in some cases there will be.
Bill Woodcock: Or or an undefined set. I mean what's the where would the where would the definition rest? Isn't that from the perspective of the validator? I mean the validator is the one who decides whether the issuer is relevant to them or not. Right? That's that's the job of the validator to look at the issuer and the binding and the signature and decide whether it's relevant to their business case. There's nobody else who can make that decision.
Rohan Mahy: Sure, but I think we're missing this I think many of us had an implied idea that there would be sort of a name for what what am I what am I trying to get so if that's phytosanitary or that's that's Ramsar or that's hazardous materials or a diplomatic pouch that there would be some sort of a name for the thing you would be saying and based on that somebody could say ah yes I I know this thing and I could go look it up and even if they didn't know that thing they could still go and say they could still display these are the the parts of this that I know about. I don't know what the rules of this are, but I can still present it.
Bill Woodcock: Yeah, but like the IETF doesn't care about that with respect to email or web traffic or you know anything else, right? We don't say well there are specific valid issuers of websites and we have to define who they are and you know what they're allowed to
Rohan Mahy: Well actually we have RFC 5280 and it says a tremendous amount about that. It just doesn't say that a specific person can do this and it doesn't say that right? So this is a little different but I guess the question is if it's just a few words that are problematic here then let's propose some text on the mailing list or in the GitHub and let's see what we can come up with. Um okay and maybe we can have a little bit of a a poll in the in the mailing list about um what do you think constitutes a you know oh I want this I'm talking about a set of emblems that all have similar characteristics what do I call this what are my expectations about what this is going to be like and how does that affect the protocol? That would be that would be a healthy conversation to to have on the list I think.
Sarah Jennings: All right, any other comments on this? I'm taking that as a no. So just to clarify, take it to the list, let's have a conversation about any specific changes to the text on this. About I think we're focusing on the the kind of scope of valid issuers question. Um
Issue 26 and then also I guess we've also got Rahel's slides on proof of presence and I missing something? Yeah, proof of presence. Rahel do you want to speak to to this issue and then we can also share your slides.
Rahel Fainchtein: Uh sure. So um kind of the the general idea which um I can go into a little bit more in the slides, um is that um in some cases when if there's a requirement that um you know that an emblem be checked or it's providing some sort of protection, um since it doesn't actually directly prevent harm from happening, um there needs to be a form of holding people accountable um who disregard uh whatever protection it's holding accountable. Um and so this was the the sort of overall idea was um providing tools to do that, um providing a paper trail so that um someone could say you that you know the only way you could have not seen uh an emblem was if you didn't query for it. Um and if there's a requirement for actually checking it then um that would be enough to um prevent someone from claiming a plausible deniability which um as I understand it has been an issue for um some types of emblems in the past. Um so um and then um beyond that there's um some discussion about uh when you need to have uh something more when that sort of forensic tracing needs to be more along the lines of a um chain of custody. Um and that's um that's a case where um um it's a little bit more difficult to kind of pin down because at least um in discussions that I've had on this, um in some cases you can't always rely on the infrastructure for a chain of custody to be there. So um I think that um there's like some some additional thought probably needs to go into that, um but I kind of just wanted to put out what those what's covered in in these uh in this PR roughly speaking and in the related ones.
Sarah Jennings: Rahel, would you like to to bundle this conversation in with the other PRs then, um and open up the conversation more generally or just focus very specifically on this forensic tracing requirement?
Rahel Fainchtein: Um I I kind of think that um so I think that they kind of need to be bundled um because some of the what came from the other PRs was a realization in working on this one. So uh I think it would be better to kind of talk about them in conjunction with each other.
Sarah Jennings: All right, I will share the slides. I think what would be helpful for the for the working group to kind of start thinking about and start us off on this conversation is whether pointers to a chain of custody or to a forensic to some sort of forensic tracing mechanism would satisfy this requirement rather than having to to kind of implement a forensic tracing mechanism directly within the emblem.
Rahel Fainchtein: Right. Yeah.
Sarah Jennings: So if you can speak in that I'll get the slides sorted.
Rahel Fainchtein: Oh yeah. Um I mean I will say that having that pointer was a largely an intention um of introducing this, um but say like and saying that in some cases you know that the that this use case would should support or might require um depending on some specifics a pointer to a forensic tracing mechanism and some of its actions should be connected to changes um updates in the forensic tracing mechanism as well. All right, you should now have slide control so if you want to run through these. Okay. Uh great so um I guess kind of going into this with um some slides and a little bit of uh drawings. Um so kind of explaining the nuances and what was intended by uh the uh these uh the two PRs um which was expanding on proof of presence and the general response requirements. Um so like I mentioned before some digital emblems indicate the protection of the asset that they're associated with but they don't directly protect them. Um and so kind of glazing over this quickly um again having like a some sort of teeth um is necessary because if I can get away with excuse me if I can get away with doing something that's supposed to be disallowed by in this case a protective emblem then there's in practice no actual protection being offered. Um but actually having being able to enforce um requires a means of actually showing if something was violated that it was. Um so that's the kind of motivation for proof of what I mentioned as proof of presence. Um so um in cases where checking before engaging either in conflicts or otherwise um is required then I demonstrating that undeniably this was like undeniably present at roughly the time someone should have been checking or roughly the time that it was targeted um would preempt any potential claims of plausible deniability that about knowledge of its protected status.
So basically the the kind of gist of it is that um to to be able to do that there are two things that concretely need to be shown. Um specifically that it was present at the time and that it was reachable that um there wasn't any way that it could have been missed. Um so any check for the digital emblem roughly at that time would have returned the emblem or whatever we're considering its core contents to be.
So um in this case um giving a concrete example would be potentially like a UNESCO heritage site. Um this is uh one such site which is uh Xochimilco which is in Mexico City. Um and uh currently um it's pretty easy to have a forensic record that shows um presence. Uh namely that it's there that there's uh an emblem associated with it and that um it is in fact of this status. But what's more difficult especially given the um just broadly speaking the architecture that we're using with DNS is that there doesn't seem to be a straightforward way to demonstrate that any and all checks at that time uh showed that emblem specifically. Um so for these kinds of use cases requiring that um there be consistency in the response given um could address this.
So going back to this drawing here um if any query regardless of for example geographic vantage point um for the emblem uh would receive a constant response with that core information then we could then assume the accessibility because um any valid response would show that. Um but again this is uh not a one size fits all so this is not something that's applicable for all use cases. Um so um the intent behind um the I believe it was PR 25, let me just double check. Um yeah, so yes, so the intent behind PR 25 was that um for each specific use case or emblem type regardless of what we're calling it here, um that what is required in terms of consistency be specifically identified and defined and explained. Um so here we introduce some terminology which is assured response meaning that any query for um a digital emblem would receive a response um versus selective meaning that not every check for an emblem that was being shown might return a response. Um and then the consistency of content meaning that the core content of what was being in the response would be the same. Versus selective where the provide or the the emblem could respond with different responses depending on some attribute of the request that it received. Um and like I said before this requires that each use case explain why it's making that decision of is it saying that it's required all the time, is it saying that it's the support for it is required etc. Um so beyond that um in terms of what I want to ask is whether the PRs actually match uh what I communicated here. Um I know that there was a bit more to talk about as well so
Rohan Mahy: We have we have Jim in the queue here.
Rahel Fainchtein: Yeah of course.
Jim Reid: Thanks Rohan. Thanks Rahel. Um my head's beginning to hurt sorry to say. And I think it would help this discussion um if there were some actual examples better better examples of the sort of scenarios that you're trying to address here. You're talking about things like um an emblem if we can use that term for now that has a validity period and so on. Um well how would we want to express that how could that be encoded say for example in resource record types or could it be done by the validity intervals or unsigned DNS resource records. Um so I think a little bit more clarity around that kind of thing would help certainly would help my thinking about what we're trying to achieve here. At the moment I still don't have enough information to try to even think about that. Sorry.
Rahel Fainchtein: Um sorry I am not entirely understanding your question I know you were asking for clarity but are you asking for clarity about how it would be implemented um or like examples of that or are you asking about clarity of why how a use case would require or did I miss it entirely?
Jim Reid: Sorry Rahel I wasn't wanting to get into um the specifics of the implementation detail at this stage. I think we're still some way away from that. But it would help me a lot at least maybe for others as well if there was a little bit more information in some examples, almost like worked examples so we can figure out what kind of technical solutions might be the most appropriate way to deal with them. At the moment I still don't have enough information to try to even even think about that. Sorry.
Rahel Fainchtein: Okay. That's fine. Um what I was kind of trying to not go into too much was that um the fact that we're using uh DNS does mean that we have um there's some flexibility where we may have been making underlying assumptions about um how um what it means that an emblem is present or querying for an emblem that it will always return potentially the same thing. Um and this is largely trying to say okay if we're making that assumption that needs to be stated, um and that needs to be um explicitly um defined when we're putting down underlying requirements for that use case. Um so um when it comes to like a concrete example I guess the one that comes to mind for example is like an IHL emblem where uh when it's present it's something that should be um that anyone who queries for it should see that the emblem itself. Does that help answer your question Jim?
Jim Reid: No, not not really Rahel. Um I'm still struggling to get get my head around this. So if we've got as I said earlier before, if we could have a little bit more information about the sort of examples you have in mind that would certainly help clarify things from my point of view. And maybe for others I don't know.
Rahel Fainchtein: Okay.
Bill Woodcock: Um a lot of this area of the specification uh came out of the CITES use case, uh the transportation of endangered species. Um and so like that was where the handling requirements and the requested uh like requested status update from validator came from right the idea that you know when somebody validates they should you know check to see whether the handling conditions have been met right is the package still right side up has the animal been fed you know was the thing transported in the pressurized part of the aircraft you know whatever right? And like please respond back to us and let us know whether the thing is still alive or whatever right has it fallen out of its package? Um and so I think a lot of a lot of this use case is covered there. I think that there's this idea that we have IHL users who are in battlefield conditions and trust one of the combatants and don't trust the other of the combatants and are going to be using selective disclosure and you know somebody's going to get hauled up in the Hague and is going to have to prove something right? And I think the the set the combination of different permutations there gets out of hand pretty quickly. Um so I don't know I I it feels like we could create an infinitely branching rat hole here if we tried.
Allison Mankin: Um can I mention we've talked we've had multiple postings by Timo from Whiteflag so there's a case where they actually have implemented a means of knowing when the protections were advertised and when they weren't because they have a ledger. Um actually well they have a ledger and um um they want to be in the position to to say um this was marked as a um a protected site. There were children, it was a school or something like that. Um and I don't think we're we're if there's anything about this that gets you in the whole rat hole of how people use it it's just a capability that adds to the value of the digital emblem to be able to say and I know when it was I know it was posted at this time it was proven to be posted at this time and therefore if I need to use that for some some purpose which is not defined by the architecture or by the by the requirements you know the requirements aren't even normative at all. Um well they are but it doesn't I mean we don't say everybody we say specifically that only some use cases will use particular requirements. Um so I I think that that one is you know go back and look at what Timo wrote or um uh but but it's not the infinitely branching rat hole it's just that if we don't have something mentioning this in the requirements um the implementations may not make it easy for people to do this. Um so we want to guide the architecture to make it possible for people to do this.
Rahel Fainchtein: Yes. Yeah, I think that thank you Allison, that was kind of the missing piece that I was getting at which was at a certain point in time of checking is a really important piece of information here. So like if I if some validator was going to check at a specific moment in time because the emblem might not always be there especially if it can be removed at different times, being able to show that it was in fact there which might not be a given is important.
Allison Mankin: I think the missing point is that digital emblems will come and go. For example if the school moved or if the school was bombed it's um it's no longer an active school. So the so things and I mean that's the war case which I hate to do but but the point is that digital emblems are not always going to be around like a DNS because DNS allows you to remove and you know add and remove very easily. So the goal is just to have a a proof that it was there at a certain time and how and um and then there's some more discussion about proof that some content was there too but that's dependent on what you put in the ledger.
Rohan Mahy: So um I don't see any hands up. Um Rahel you were you know we're kind of out of time for this for this segment we could push it a little bit longer but um I wanted to ask do you feel like in terms of being able to have just we already have we already have statements that say um that you can add additional information um and so presumably for a use case like CITES that having a pointer to the service that you have to use to check back in with with the sender that the animal is still alive and has been fed or whatever um what um you know are we missing anything there? And in terms of um doing a query and showing that okay there was an answer to this query or having a pointer to a ledger or having a um some someone be able to keep a copy of a of an answer that they received and like in the DNS case a validator that wants to show that they did check could look at could show okay I this is what I received it didn't contain this emblem or this is what I received it didn't contain this information or this is what I received and it contained an emblem or this is what I received and it says there were no records and it was signed. Are we missing something here is there something about these the sort of examples that I just gave that needs to be needs to be stated in the requirements that hasn't hasn't been articulated correctly?
Rahel Fainchtein: So um ah um so how something is consistent which is not a given necessarily in DNS um is again something that like is a prerequisite for being able to show proof of presence like I mentioned before. I didn't feel like that was um really discussed in the in the requirements kind of a lot of where this came from was the um discussions in previous meetings where um where that sort of came to light um and so do I think the requirements cover that? I think there's room to discuss them but I don't think that they specifically say you have to.
Tommy Jensen: Yes, just to repeat what I said on the chat. Um and I little confused because I think I'm in agreement with Bill also. Um I'm not sure if there's an objection there. But this document's entire purpose is to use use cases to illustrate why the architecture and final standards need to account for things. It doesn't need to specify how those things are implemented. Um and so the text in 25 and 33 both specify things that an architecture needs to enable. It doesn't specify that standards must do these things a certain way. Therefore I think the text is great, um should be merged. And I want to ask the working group what further discussion on this is going to enable changes in this document? Obviously it affects changes in the final standards, but we should have that discussion there, not here.
Bill Woodcock: Um we're saying often you know we don't need to do anything special because the DNS already takes care of this for us right digital signatures you know querying you know blah blah blah right. Um it it feels to me like possibly we could do the same thing here and say that yes these are real requirements and we believe that the combination of what we're doing in DM plus the DNS plus Whiteflag addresses this set of requirements. And that DM doesn't need to replicate what's in Whiteflag just as it doesn't need to replicate what's in the DNS because those pieces already exist. Admitting that Whiteflag is not an IETF protocol.
Sarah Jennings: Just to clarify Bill, so your position is that it's fine to to put this in as a requirement and then perhaps within the architecture document make reference to actually the fulfillment of that requirement being an external protocol being something else that that DM itself doesn't need to address.
Bill Woodcock: Yeah I mean I don't know that we actually need to explicitly say that if we're all understanding it the same way right I mean we don't need to canonically list everything that we're not doing right as long as we understand that every requirement doesn't need to be met within DM if it's already met using the combination of DM and other existing protocols. Okay. Thank you.
Sarah Jennings: I see the chat is pretty busy. Um it would be helpful if anyone who's posting in the chat at the moment thinks that it there's something that they would like to to say in the group. Allison.
Allison Mankin: Um well what I think I want to say is that um it's not that we're saying that um we want to do the work that someone else has already done like Whiteflag. But right now Whiteflag uses just to give a and continue with them as an example uses something that look that that um is similar to digital emblems but when we standardize digital emblems we want to make sure that it's usable by a um by a uh a use case who has Whiteflag-like requirements. So we're not going to define everything in fact I assume the architecture will will be um you know able to say there's an interface that allows some access to existing protocols we're not we're not actually supposed to define any new protocols really at all we're supposed to put it together from existing protocols. But if the requirements don't call for it the architecture may not accommodate it and that is what um that's what we're trying to provide. And Whiteflag might I'm just answering back to Bill Whiteflag's architecture may say that I don't um I don't need to I don't need to use the standard digital emblems but we'd like them to be able to if they can. Um we'd like any of the use cases to be able to use this standard in an access insensi- extensible fashion if they can and that's why the requirements have been made to be you know very broad in order to allow a lot of use cases. Um and we just happened to be using you know we I I think Sites gave you some examples of ways this is valuable too. So
Sarah Jennings: All right, my interpretation of the discussion is people see this as a an important requirement to have in, there's a couple of use cases that it's grounded in. Rahel's proposed some text, uh if folks can review that and see that they're kind of content with it as it currently stands. But um yeah, some comments sorry just reading the chat. But it seems like it is something that is that is necessary to to guide the architecture document, but we don't need to be overly prescriptive at the moment about how that's put into practice. Just need to be clear that it's something that some emblems may need to consider.
Allison is that an old standard hand up? Cool. All right. Thank you Rahel.
Rohan do you want to try and summarize a little bit more explicitly for for Felix for the for the notes on this one?
Rohan Mahy: So we've had a discussion about forensic tracing and proof of presence. Um we've got two specific use cases mentioned that that may require Sites and um the kind of protective emblems under International Humanitarian Law. Uh agreement that at the current moment the text in the use cases and requirements document doesn't need to specify uh the mechanism by which any of that is provided and sort of agreement within the working group that that pointers are probably appropriate for for certain use cases. Uh but a request for folks to review the the specific text. Okay and Felix just made an entry in the in the in the chat here so. Great. Thanks Felix. Let me share slides again.
And then the last thing that we had was uh issue 36 other discovery mechanisms. This is something that Mallory mentioned at IETF 125 and uh we've had some mailing list traffic about it that um do we need to account within the use cases and requirements document or perhaps within the architecture document uh that kind of other discovery mechanisms are not currently in scope for the working group but suppose may be in scope in future uh and that we should sort of consider that bear that in mind. Is that a fair summarization Rohan where we're at?
Rohan Mahy: I think so. And it's unfortunate that Mallory is not is not here but uh because she did submit some concrete text and
Bill Woodcock: Um in reading that text I think my my response to it was that some of it um is rooted in um a
Rohan Mahy: Narrow view of the DNS?
Bill Woodcock: Yes exactly. Like I as a user of the DNS for a long time know exactly how to address each of many of those things in there. The ones that are not identifiable using DNS identifiers are the ephemeral session identifiers. And um I mean I can see how I would do it but it would need new RR type and I'd like to avoid new RR types if they're not of general use outside of DM right? Um so the question that leaves me with is ephemeral uh ephemeral session identifiers is not exactly a thing I mean originally what we said was people places things uh digital data at rest or in flight and um I can't remember the last one. Anyway so that would be the digital data in flight I guess. But I hadn't really I mean has anybody else put any thought into that specific requirement and is that still on the table? Digital data in flight.
Rohan Mahy: Felix maybe have you been aware of any of this?
Felix Linker: Um I'm making up my mind right now. To me it was always services that are protected in the digital space. Uh and that includes their data I think binding something to data in flight is really impossible. Yeah. Well but I haven't thought this through deeply.
Bill Woodcock: We could certainly do a new RR type but like it's so hard for me to imagine how that could get glued together in a temporally useful way right? Like ephemeral really is ephemeral we're talking about a few milliseconds right whereas any data that is making its way through a provisioning system and out through publication and then somebody queries it and then they get a response you know we're talking about minimally seconds and probably tens of seconds at which point the ephemeral thing it's pretty far gone you know? So I'm just having a really hard time imagining what this means or what it would look like in DNS.
Rohan Mahy: In DNS or in general?
Bill Woodcock: No in in in general like I mean I can imagine how you would try to accommodate this in the DNS but I can't imagine who the user is or what the use case is or like what the mechanic would be. Like I guess we said digital data in transit right? But I think what was being imagined at the time was that like we'd be talking about DANE keys right the keys that protect the data not the the TLS the you know session ID. And so that's that's really the one thing that stands out to me here as the not already addressed requirement in Mallory's text and so that's like the one thing in there that I would say needs to be there if it's a valid requirement but I haven't really heard anybody flesh that out as a valid requirement with a use case and a constituency.
Sarah Jennings: Any other comments on this? Looks like no. My sense was from Mallory's proposed text a little difficult in that she's not here but it it seemed targeted at the architecture document specifically. From from what Bill's just spoken about it seems unlikely that we have a new requirement that that particular text in the architecture document kind of gives rise to or at least if there is a requirement it's perhaps infeasible. Um with that in mind and with one eye on kind of the purpose of this meeting and and trying to get to the working group towards consensus on the use cases and requirements document my suggestion would be that we we don't need to include any of the specific text from Mallory's suggestion in the document as it currently stands. Um is that something that kind of so chimes with the working group? So to be clear no edits to the use cases and requirements document from Mallory's suggestion as it currently stands. Allison.
Allison Mankin: I'm happy with with this getting discussed in the architecture department document instead because it really will have to see about whether it's it falls out from the choices of the architecture or not and we don't have a use case. I mean I think it's I think what Felix said is he doesn't really see a use case at the moment.
Rohan Mahy: Um I'm going to yeah I'm going to raise my hand. Um I think we have had specific so as an individual um I think we have seen use cases for being able to discover things not using DNS um but they don't have any so for example discovering something via a QR code or an NFC they may then go and check query something in DNS or not they may just get some they may have some records lying around but I don't see a new requirement for any of those cases that we discussed previously. Um and Tommy it's out of the initial scope of the charter and those words were very carefully chosen because that might not be the that might not be the final scope of the charter of DM after rechartering.
Allison Mankin: I'll be quick because Tommy has more better things to say I'm sure but um the um I think Mallory's text doesn't talk about discovery as much as it talks about bearing not bearing with DNS. Um and I think that we've kind of elided the fact that there were some other discovery mechanisms that's certainly true with Ramsar but but when we get to the architecture we have to describe what a possible interface that might be but DNS does more than just discovery so that's why I think saying DNS is not central here in implying that in some way is not called for and architecture can consider the ways that you might interface to something that goes and finds the initial data so that you can get an ID for the DE or something like that.
Tommy Jensen: Okay, so just to bring up the point I made in chat. In since the working group formation there was a show of hands one of the only calls of consensus that the working group has done and in that the group was actually quite explicit that we should limit ourselves to use cases that are fully in charter or optionally to include things that are partially in charter so that we're future proofed so long as they're not controversial. So I know that back when I was chair um that we had had a dream about making this deliverable one future proof and I think we've clearly discovered that that's a fool's errand and we should admit to ourselves that when we recharter we can also redraft requirements if that's necessary and not run in circles trying to account for things that aren't in our charter today.
Sarah Jennings: Tommy I think we we are very much trying to to do that and some of the the kind of text in in PR 34 and the fact of going to working group last call but but not kind of publishing as an RFC is to give us that flexibility of of admitting that um we might have some human fallibility here in not being able to think of every single possible scenario and and draft the perfect text. Um I want this kind of conversation to be less so do we think that there might be something that you know the working group could possibly do in the future that might be helpful that relates to a non-DNS based discovery mechanism and more so is there anything in in Mallory's suggested text that needs to be accounted for at the current use cases and requirements stage? Uh my current read from the conversation is no.
Tommy Jensen: Understood. Uh understood. Yes and I other working groups take this approach with the don't publish the all of that makes perfect sense. I was just reacting to the live discussion not the text switching to talking about things that are currently out of charter. I'm fine with the text. Um I think everyone on planet earth and within its general vicinity knows that I think we should merge these and move on to the architecture.
Rohan Mahy: Yeah well yeah my point was that even if we have this idea of non-DNS based discovery or other things which are out of scope uh we haven't identified new requirements that are directly applicable to this document they may be applicable to the architecture document or they may be applicable to a future protocol but no change here I think.
All right. That is provided we've no other hands everything we had from the GitHub in terms of PRs and issues that we wanted to discuss with the working group today. Do we have any anything else that people think we need to discuss as a working group at this stage?
Allison Mankin: Oops. I didn't get in the queue sorry. Um I'd like to um side with Tommy and say could we issue a revised ID um so people can then um can then you know sort of voice their objections against a unit or considerations or concerns for working group last call against an 02? Can you ask the can you ask this group and the mailing list if they feel we're ready to do that? Because we're really been really conservative in keeping to uh not having a new version all this time.
Sarah Jennings: I think for for a lot of what we've discussed today we have we have consensus to to either kind of merge the requests or uh there's a couple of things that we need some specific text. My suggestion would be we we get those um where they're kind of uncontroversial we were able to merge them and publish a new version um and then if there's any outstanding consensus calls we need to do on a couple of small items we can do that uh before going to working group last call that would be my suggestion. Rohan what do you think?
Rohan Mahy: Um yeah I think we there are some PRs that have been around for only a few you know today only over the weekend only a few days so yeah we should let those settle but it looks like we're making progress. If we keep the energy that we have had over the last you know five or six days uh for a few more days I think we can probably close and merge a lot of things. Um we still don't have a full security requirements um section which is probably also something we would need for working group last call. Um if we've got that I think I think we're good to go.
Sarah Jennings: And then on schedule for the architecture document work and next steps we would like to have another interim meeting um to before Vienna to uh to kind of start making progress on that. Um that's a that's an ambitious timeline but we think that we're able to we should be able to meet it. Um and in the meantime we'd ask folks who were interested in working on the architecture document to kind of take that off the list and start producing something that the the group will be able to present to so we can be in touch uh as to as and when that's the best time to to put that forward.
Rohan anything to add?
Rohan Mahy: No, I think the fact that we finished before the end of time and still had vigorous discussion I think is excellent.
Sarah Jennings: Good work. Good work everyone. Celebrate with I mean if it's the morning a nice coffee if it's the evening a beverage of your choice however you wish. Well done. It's been great to meet. Uh please take a look at the um the traffic on the GitHub uh and please if you want need to want to contribute text please do so uh and in the meantime we'll see you on the list.
Tommy Jensen: Tommy I wouldn't dare.
Sarah Jennings: Take care everyone. Thank you. Take care. Bye.
Jim Reid: Yeah, thanks everyone.