There are notes from two notetakers.

Notes by Tommy

Intro

Note (Really) Well presentation

Agenda: coauthors walk through the main sections of the document

• the -00 version of
  https://datatracker.ietf.org/doc/draft-fainchtein-diem-use-cases/

Section 3: requirements

Michael Richardson: Happy to adopt now. For the doc itself: I don't
think domain names are sufficient, we will need IP addresses for
actionable protocol work.

• Coauthors: we started with domain name based on the charter, no
  objection to IP addresses though. We did also talk about URLs but
  consensus was to stay with domain names per charter.

Orie Steele (no hats): have we gotten feedback on this document from
cyber operators?

• Coauthors: no feedback for or against yet on the specific text, but
  at least one stakeholder confirming value in domain names

Bill Woodcock: use of in-addr.arpa and ip6.arpa names will allow us to
avoid a recharter

• Michael: disagree, as these are hard to update and often not updated
• Jim: these could be potentially come into scope, and IP addresses
  can be used directly in .arpa names, but we don't want to get
  distracted by implementation details (let's get use caes and
  requirements adopted)
• Michael: still disagree, will take to email

Orie, AD hat on: base use cases on conversations with real experts
(on the use cases)

Jim Reid: let's focus on adoption and circulation with interested
parties rather than implementation details

Casey Deccio: I agree we should involve experts, but they may not have
the right technical knowledge to do so

Rohan Mahy, no hat: this text doesn't specify that domain names are the
only way a bearer can be identified, so it seems sufficiently flexible
for now

• Coauthors: we can specify this in the text?
• Chairs: yes, good idea (but be sensitive to not invite
  overchartering right now)

Section 4: extensibility

(no discussion)

Section 5: use cases

Chairs: is there anything missing here to make this reasonably
representative?

• (no feedback)

Questions to WG

Unofficial question: Should this be adopted?

• Jim: yes
• Casey: yes

Official show of hands: Does anyone have objections sufficient for them
to block adoption of this document as an initial WG requirements
document?

• Yes: 0
• No: 12
• No opinion: 0

With 12 people on the call, we have 100% answer

Official show of hands: Are the Use cases in the document sufficiently
representative?

• Yes: 11
• No: 0
• No opinion: 0

Orie: can issue a CFA, but be mindful of IETF 124 important dates

• Good news: I-D cutoff date is Oct 20

Wrap up discussion

Allison: we will get more participation with an adopted document than
with an I-D, let's go to CFA

Bill: agreed this is best worked on in the WG, let's adopt

Chairs: CFA issued, go team

Notes from Bill Woodcock

DIEM interim meeting
Wednesday, October 1, 2025
18:00 UTC
Rohan Mahy and Tommy Jensen chairing

18:05 - Rohan read the note well.

18:06 - Agenda bashing, nothing added, no objections.

18:10 - Rahel introduces the current use-cases document.
Purpose: give a structure to the discussion
Non-comprehensive list of some of the use-cases from the previous two drafts or the presentation.
Broad requirements for what each use-case would need to adhere to.

Felix discusses the contention around exclusion of use-cases and the attempt to find a more constructive approach.
Intention of requirements section is to list the requirements which a solution would address.
Section 5 is not quite finished, but it should explain how use cases fit the requirements.
Felix thinks that having the list of requirements allows us to know when the initial scope has been met.
Having the use cases allows stakeholders to show what they need to do, whether the requirements actually meet the needs of the use-cases or not.
It's clear that not all use-cases require all requirements, and the requirements are not sufficient to meet all of the use-cases.
Requirements are extensible and it's understood that more requirements will need to be added in the future to meet the use cases.

18:18: Rohan: let's walk through the individual requirements briefly.
Rahel: We envision a key/value structure to denote the components of a digital emblem.
Need to identify the bearer and what type of emblem they are.
They may include other types.
Still a bit general.

18:20: Michael Richardson: My understanding is that this is about willing parties not attacking each other. Thinks IP addresses are more useful than FQDNs.

18:22: Rahel points out that IP addresses also work, pick what you like.

18:24: Orie Steele, speaking as an individual. Asking the same question, is this focused too much on domain names? An FQDN can help you identify IP addresses. Have we gotten feedback on this use case from cyber operators? Do we see a problem?

18:29: Bill Woodcock: This is a solved problem, ip6.arpa and in-addr.arpa completely solve this issue. We don't need to do anything new to cover IP addresses.

18:32: Jim Reid: Michael is diving too far into operational detail. We should get back on the use cases, get the document circulated. Needs to go beyond the working group. Find out if we've missed use-cases and requirements, whether things need to be prioritized. Also, lots of useful things live under .ARPA, like RFID tags, so all kinds of useful things can be done within FQDNs.

18:34: Rahel agrees with Jim.

18:34: Casey Deccio: A couple of thoughts. The focus of the group was to work together with what we had to get consensus on a document. I thank both chairs for their guidance. Orie asked if other options than FQDN were considered. We did talk about URLs, of which an FQDN is a subset. The consensus was to not do that, just do FQDN, so we went with that. That's what we decided for now, and I'm ok with that. The second thing: I don't mind including more experts, but it may be hard for them to weigh in on the mechanisms. There may not be the necessary knowledge to weigh in if they don't intimately know the technologies we're dealing with, so we need to take those with a grain of salt.

18:37: Rohan, as an individual. The document says the FQDN must have an FQDN, but it need not be the only way the bearer is identified. This is sufficiently flexible and open that it can cover what we need.

Rahel: I can also see us putting in a statement to that effect, if it would clear up misconception.

Rohan: We're concerned that if it's not in the charter, people will ask about that. But yeah, we could easily make that comment. We've exhausted the mic queue, so we can move on to the next requirement.

18:39: Rahel: Summarizing discovery requirements, section 3.2.

18:44: Felix: We had discussion about the difference between removed emblems and invalidated emblems. Some emblems may need "covert inspection". Authorization may be required to view some emblems. DE architecture must be extensible in order to accommodate known use cases.

18:48: Rohan: Our goal for this call is to find out whether the people on this call think this document is a good starting point? Should we call for adoption on the list?

18:48: Felix: Not going to summarize use-cases. We need to group use-cases, discuss how they fit into the architecture, so that the feedback can be meaningful. I don't know if this needs to happen before or after call for adoption.
Rahel: Grouping had to do with discussion of whether we view this as a top-down view of the use-cases, where we say this group have similar requirements. Or bottom-up, where we view each use-case and see what requirements it has, and then group them that way.

Rohan: Maybe Tommy can scroll the table of contents so we can see the list of use-cases, there are thirteen of them. That's a reasonable number of them. Does anyone feel that this isn't a representative list, or that something is crucially missing from the use-cases? The feedback we got in the last meeting was that we wanted any use-case that seemed plausible, even if it had requirements that weren't in the charter, should be included, so it would motivate architectural decisions anticipating future requirements.

18:55: Rohan and Tommy: Show of hands, are there requirements that would block adoption at this point?
12 people on the call, 12 say no objection.

18:58: Casey: Excited that we've gotten this across the finish line, and exhausted.

Tommy: Orie, can we do a call for adoption ahead of the next meeting?

Orie: Yes, I think we have enough time before the black-out window before the next meeting, but you should check my math on the calendar. I think you should run the call for adoption on the mailing list.

Rohan: The cut-off is October 20.

19:00 Orie: Excellent.

19:01: Felix: Wants to know whether use-cases could be added to before or after the call for adoption.

Orie: You should leave it alone during the call for adoption. But if the working group owns it, the working group will do plenty of additions prior to the working group last call, which is when we think the text is done. In other words, if no one on this call thinks there are big changes, go straight for adoption.

19:02: Allison, support call for adoption. Working group can work more effectively.

19:03: Bill Woodcock also support call for adoption immediately.

Casey: I support a CFA to the mailing list.

Rohan: We've heard plenty of support for immediate call for adoption.

Second show of hands: Are the use-cases in the document sufficiently representative? 11 say yes, no say no or no opionion.

Rahel: There is maybe one merge request that hasn't been merged.

Rohan: If it's just a PR, it doesn't show up in the editor's copy. I can do a compare, but my impression is that it's the same as what's been submitted.

Felix: Yes, there's one pull request which intends to add some charter definitions, and we should do the call for adoption first.

Tommy: We're going to put up for adoption what we reviewed on this call.

Rohan: There are no substantive changed relative to what we reviewed today.

Tommy: Cool, I'm going to go push the button then.

19:07: Rohan: Excellent. We have a bunch of time left. If folks have things they think would benefit the document and want to bring them up here on the call, or create an issue, I don't think there's any harm in doing this while we're in this adoption call. On the contrary, I feel like if we have more than the authors write up the issues or small PRs, shows interest and engagement in the document, which is quite useful.

Tommy: I have pushed the button, the CFA ends October 15th. I say we're good.

19:10: Rohan: Thanks everybody, I look forward to seeing everyone on the list, or at the next meeting.

Alex Rosenberg: Do we have any indication when in the week of IETF-124 we meet?

Rohan: No, not until the tentative schedule comes out.

Take care everybody.