Skip to main content

Narrative Minutes interim-2024-iesg-11: Thu 14:00
narrative-minutes-interim-2024-iesg-11-202405161400-00

Meeting Narrative Minutes Internet Engineering Steering Group (iesg) IETF
Date and time 2024-05-16 14:00
Title Narrative Minutes interim-2024-iesg-11: Thu 14:00
State Active
Other versions plain text
Last updated 2024-05-30

narrative-minutes-interim-2024-iesg-11-202405161400-00
 INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2024-05-16 IESG Teleconference

These are not an official record of the meeting.
Narrative Scribe: Jenny Bui, Secretariat

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Jenny Bui (AMS) / IETF Secretariat
Deb Cooley / Security Area
Liz Flynn (AMS) / IETF Secretariat
Jim Guichard (Futurewei Technologies) / Routing Area
Mahesh Jethanandani (Arrcus) / Operations and Management Area
Erik Kline (Aalyria Technologies) / Internet Area
Warren Kumari (Google) / Operations and Management Area
Murray Kucherawy (Meta) / Applications and Real-Time Area
Jean Mahoney (AMS) / RFC Editor Liaison
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Web and Internet Transport Area
Zaheduzzaman (Zahed) Sarker (Nokia) / Web and Internet Transport Area
David Schinazi (Google) / IAB Liaison
John Scudder (Juniper) / Routing Area
Orie Steele (Transmute) / Applications and Real-Time Area
Sabrina Tanamal (ICANN) / IANA Liaison
Gunter Van de Velde (Nokia) / Routing Area
Éric Vyncke (Cisco) / Internet Area
Paul Wouters (Aiven) /  Security Area

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
Roman Danyliw (CERT/SEI) / IETF Chair, General Area
Sandy Ginoza (AMS) / RFC Editor Liaison
Tommy Pauly (Apple) / IAB Chair

OBSERVERS
---------------------------------
Karen O'Donoghue
Peter Thomassen
Greg Wood

1.2 Bash the agenda

Liz: Does anyone want to add anything new to today's agenda? Any changes?

1.3 Approval of the minutes of past telechats

Liz: Does anyone have an objection to the minutes of the May 02 IESG
teleconference being approved? Ok, hearing no objections so we'll get those
posted in the Datatracker. Does anyone have any objections of the narrative
minutes of May 02 being approved? Ok, those are approved as well and we'll get
both posted in the Datatracker.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

        o Murray Kucherawy to find designated experts for RFC 9530 (Digest
       Fields) [IANA #1359278].

Murray: I think I got those but forgot to email the names. I'll put it in Slack.

Liz: Ok great. I don't think i've seen one for those, so we do need those names.

     o Francesca Palombini to find designated experts for RFC 9557
       (Timestamp Suffix Tag Keys registry)[IANA #1363801]

     o Orie Steele to find designated experts for RFC 9560
       (Registration Data Access Protocol (RDAP) Query Purpose Values)

Liz: For Francesca and Orie, we do have both of these to approve at the end, so
we'll mark both of these as provisionally done.

     o Orie Steele to find designated experts for RFC 9562
       ((Universally Unique IDentifiers (UUIDs))

Orie: In progress, let me check if I don't already have those and i'll follow up
behind the scenes.

   * OPEN ACTION ITEMS

     o Roman Danyliw and Warren Kumari to 1) draft a revision of RFC 4858,
       2) draft a revised IESG Statement on Document Shepherds (original
       statement October 2010), and 3) update the WG Chairs wiki to point
       to the new IESG Statement.

Liz: Neither of them are here so we'll mark this as in progress.

     o Francesca Palombini to come up with a v2 proposal for trying
       ALLDISPATCH again at IETF 120.

Liz: Should we mark this as complete or do you still have more that you want to
do, Francesca?

Francesca: Let's mark it as complete and reminder for everyone who were not at
the last informal, we discussed it. GENDISPATCH stays in, pending, if we get
proposals. We are trying to reduce the time to 2 hours, again, depending how
many topics we get. There is a timeline that has been established and the
chairs have started this timeline now. The chairs has sent out a call for
topics and the idea is to have the first idea before the first BoF call. Which
I think has not been scheduled yet, right Liz?

Liz: It will be the last week of May.

Eric: I was unable to join the alldispatch discussion.  If we do it 2 hours,
are there working groups meeting after that meeting?

Francesca: Yes, but not in that room for room reset. It might be less tracks.
My proposal was to reduce to 2 hours, but we decided that we don't make that
decision until we know how many proposals there are. We might have 3 hours or 2
hours depending on how many proposals there are. If anyone has more comments
then please send it to the mailing list. I'm monitoring that thread to see if
there's anything else we want to add. This is done and we will discuss the
proposals once we get closer to the meeting.

     o Paul Wouters to open up an issue with the Tools Team asking for
       IANA to be notified about document state changes.

Paul: In progress.

     o Paul Wouters to write a proposal for handling IANA review
       mailing lists.

Paul: In progress.

     o All IESG to review Non-WG List Review spreadsheet and note
       which lists may be ready for closure and any needed AD Actions.

Paul: I do have one question about that. I notice for instances the PERPASS
list has seen one message with no replies in 5 years excluding spam, so they're
not on this list but I think they could use closure. I'm wondering if people
are looking for lists that have seen a few messages or whether they're really
strict about if there's one message from one person that's real then we'll keep
the list open, even if that's the only one we've seen in 5 years.

Eric: It's not only a single criteria, do you think it could become more emails
in this list?

Orie: I have some folks reach out when I sent request to close the list, and
unless there's objections in two weeks. A few folks has reached out for one
list but had no activity but they said, we want to keep it open because we
expect to use it in the future.

Paul: If you look at PERPASS mailing list which all about pervasive monitoring
which you can argue is even more important now than it was when the list
started, but the thing that list has a smaller subscription base. People who
joined the IETF in the last 5 years don't even know that the list exists so
you're actually better off mailing the generic IETF list and to pick one of
these topics lists that people have forgotten about. So i'm not sure if that
argument really holds to sort of keep it in reserve.

Orie: I definitely agree with the comment about if you send mail to list and
there's very few people subscribed to it. It would be better to send that to a
wider area lists, if you're seeking feedback.

Paul: Related to this, I'm going to bring this up on the Wish document. There
for instances, ask that main working group mailing list is also used as the
registry review list which I also think is not a good idea because then you
have to keep this working group list open, even if the working group closes and
there's no activity because it happens to also be the registry review list so I
think those should be definitely clearly separated.

Francesca: My opinion about lists, is when in doubt, keep it open and sort of
do this screening, and close those that are clearly useless at the moment.

Paul: That's how we got here, right.

John: I guess maybe you're point is kind of like, once you start overthinking
it, the fruit is no longer low hanging.

Deb: Most of the lists that I've emailed notices too, people have come backed
and was like: 'Oh, that's still open? Close it please.' It's been more than:
'Oh, wait, we really wanna use this list.'

Francesca: I agree, I think this is the exception, and not the rule.

Paul: I sent a message to list and if nobody responds to my message, then I
will conclude and close it.

Francesca: I have sent a message about this list is going to close in 2-4
weeks. Should I change the status to close? What's the process?

Cindy: You can send an email to support@ietf.org with the list you want close,
and then we will close them, and then I will go into that spreadsheet and mark
them as closed.

Deb: We go back in after 30 days or whatever, and check if there's any activity
on the list, and if there isn't, we close it?

Francesca: We send email to Secretariat asking to close it.

Deb: Then there's a tombstone that goes on the list, right? That says closed.

Cindy: In most cases, the last email that will show up in the archive is the
one saying, this list is going to be closed which effectively serves as the
tombstone. But the archives will remain.

Mahesh: With Mailman3, do you have to first subscribe to the mailing list to
send that tombstone email. Or now, you can as owner send that email without
subscribing to it.

Cindy: For with every lists global-whitelist should be applied so you should be
able to send to these lists. There's only a few cases where, if it was like a
design team list or something where it was deliberately closed, where that
Whitelist might not be applied. If any of you do get a message back, saying
your message has been stuck in moderation. Just ping me, and I can use my
special magical powers to let you out. If the people who are actually on the
list don't see it in a timely manner. And for some of these old lists the
people that are listed as owners may not be active addresses for them. But in
in most cases you should be able to send without an issue.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-tictoc-ptp-enterprise-profile-26  - IETF stream
   Enterprise Profile for the Precision Time Protocol With Mixed
   Multicast and Unicast messages (Proposed Standard)
   Token: Erik Kline

Liz: We have a discuss from Roman who's not here, does anyone want to discuss
this now?

Erik: I do see that Doug has been pretty good about responding to folks. He had
responded to Roman already as well. I think he hasn't responded to everyone's
feedback just yet, but the authors seems to be engaged. I know he already had
some rounds to close on some other issues as well.

Mahesh: One question I have with ptp-profile, is there anyone one place that
folks can go to see? What are the profiles they have? Because you have the
enterprise then you have the provider profile and that comes via IEEE, I think?

Erik: I suspect most of that stuff is over with IEEE, I don't actually know.
Maybe I can call upon Karen.

Karen O'Donoghue: The idea behind 1588 profiles was that the standards body
that was doing and work in that space with develop profile. So any organization
and even independent organizations are able to develop profiles. There's some
in ITU, some in IEEE, and some in other standards groups within IEEE. This one
is more for networks that looks like IETF networks.

Mahesh: Is there only one location where people can go to see what are the
profiles that have been defined?

Karen O'Donoghue: I don't believe there's a single registry. This structure of
how you identify a profile identifies the standards organization from which it
came from. so that the the definition of how you find this for the standards
organization that defines the profile is identified in the profile. But I don't
believe there's a single list. I can clarify that with Doug, but I don't recall
one.

Liz: So this document will stay where is it in IESG Evaluation, will it need a
revised ID?

Eik: Most definitely.

Liz: This will be in IESG evaluation; revised ID.

 o draft-ietf-ntp-update-registries-14  - IETF stream
   Updating the NTP Registries (Proposed Standard)
   Token: Erik Kline

Liz: We have a discuss, do you want to discuss this now?

Erik: If people would like to, I know Rich has been taking some feedback and
produced a revision during the telechat review period.

Paul: His responses have not been really been in target for the issue with a
hand-waving dismissal, which I wasn't too happy with it. I think the core
problem is that there is a registry for extension fields, and apparently
something has been using the wrong values there. And so what's in the IANA
registry is not actually what's being used. But now this document, basically,
byte swaps these registry entries, and there's absolutely no discussion or
mention anywhere. If anyone has done any sort of investigation, whether or not
clients are using only the byte swaps, versions that are not in the registry,
or that people have actually implemented it, based on the published registry,
which is like over a decade old, and so swapping these values that are like,
you know, really old, with no kind of analysis, what the impact will be seems
very worrying to me. Maybe that has been, and not written down but I think that
should be written down in a document, for prosperity.

Erik: My understanding is that broadly, you could maybe divide NTP
implementation into 2 camps; 1 is NTP, ntp.org, and the other camp is
everything else. Maybe I can call upon Karen again to comment on the
implementation status or implementation concerns.

Karen: As I understand it, there has been a lot of discussion about the
implementation issues associated with this. The bigger problem is not the
current NTP implementation. It's the things going forward like network time
security and auto key. I saw somebody's comment on auto-key in the ballot. That
was a downref question. The issue here is auto-queue is defined and made an
informational standard, because the IESG at that time was never going to buy
off on it, because it didn't follow the security at the time. But it was what
was being implemented by NTPD. Virtually nobody actually uses it. The way those
fields were done, and auto-key has become an issues. There's been disagreement
with developing NTS, and there's one person who's never going to agree with
this, and it doesn't have to do with the actual values, it has to do with the
way the field is structured. There's been a lot of discussion on implementation
fields, I saw your discussion, Paul, and do a better job at clarifying what the
current issue might be.

Paul: The problem I have now is I have no way of evaluating if this is going to
break the internet. There's no discussion, if it's true that this is like a
specific feature by one specific implementation that nobody uses, then putting
a few lines in there saying. Nobody's implemented this, so it's safe to change
the registry would be enough for me.

Karen: I agree that Rich's responses to this, Rich agreed to do this because he
is a neutral party and he is kind of closing patience with it. I'll go back and
get the clarifying language that you need. But I understand what you're asking
for. I don't believe it's an issue. I can't provide language on the call.

Erik: We can close on that though.

Murray: The thing about x registrations. I didn't raise that to a discuss, but
there is a BCP saying we don't do this anymore. I'm a bit wary that his quick
answer was, we have to do this for back issue reasons. We discussed it, and in
mind, that seems like a weak reason to ignore BCP. Erik, were you part of that
discussion? Did you see what it was about?

Erik: We were changing the format of the existing experimental fields.  Not
actually defining a new thing. It was already there, there was some discuss
with what letter it starts with. I think it used to be a dot, They're trying to
standardize on X, it's not new.

Murray: I know it's not new, i'm just worried if we should enable this
behavior? But maybe if it doesn't happen often, I guess we don't really care.
But anyway, I thought maybe this is more like Rich's answers are a little bit
too flip for me to feel like there's closure there, so I'll drop it.

Erik: Should we reference BCP 178?

Murray: I think I would feel a little better if it said something like we
acknowledge the presence of that, however, and then something that explains why
we're continuing to do it, anyway.

Orie: +1 to that, Just saying, we don't usually do this anymore but we're
making an exception in this case would be better.

Murray: I was just a little off put kind of attitude.

Karen: That makes sense to me.

Erik: I think we can find some language there.

Murray: It doesn't need to be a discuss, i'm happy with you following up.

Liz: Sounds like this one might need a revised ID?

Erik: Just a little bit.

Liz: Ok. This will stay in IESG evaluation; revised ID needed. Erik, are you
ready for your special down ref question? We got 2 downrefs here 5906 and 7821.
Do you want to add these to the downref registry for when we get there?

Erik: My understanding is that the downref registry is if they're going to be
cited often and given that this is an informational RFC. I think it's not
implemented and an experimental RFC, and their existence, and their downref
status here is because of the IANA registry. I don't expect these to be cited
often, so I would suggest that it's not necessary but I may be misinterpreting
or misunderstanding the nature of the downref registry.

Liz: No, I think you pretty much got it so we won't add this.

 o draft-ietf-wish-whip-14  - IETF stream
   WebRTC-HTTP ingestion protocol (WHIP) (Proposed Standard)
   Token: Murray Kucherawy

Liz: We got a few discuss here, do we want to discuss it now?

Murray: I don't think so . I think that there's enough material here for them
to deal with, and they haven't answered yet. But I have been talking to Roman
about them. So unless you guys wanna talk about them now, we can just let the
authors do the thing.

Francesca: I just want to mention that I highlighted the parts that I found
that did not comply with HTP usage, and I highlighted the parts that I found
that did not comply with the BCP about how it should be used in protocols. But
that might be more because it's all over the documents, so there might be more
places and that might need revision.  I know that this document got the HTP DIR
review, if I had noted before, I would have asked one for the telechat as well
not only for the last call, so I sort of hope I did. That was my miss.

Murray: No problem, i'm going to let the authors deal with it. There's nothing
that I think needs to be resolved in the moment.

Liz: So this document will stay in IESG evaluation; revised ID?

Murray: Let's do an AD follow-up, I'd like to start there and then when they
see revised ID needed, they know i'm waiting on something from them.

 o draft-ietf-mpls-mldp-multi-topology-05  - IETF stream
   mLDP Extensions for Multi-Topology Routing (Proposed Standard)
   Token: Jim Guichard

Liz: We have a discuss, we want to discuss this now?

Jim: I don't think unless John wants to say something. It looks like John's
discuss is reasonable straightforward but there are a bunch of comments that
need to be addressed. So I guess unless John has anything we can put this in
revised ID needed.

John: I'm good.

Jim: Revised ID needed.

 o draft-ietf-oauth-security-topics-27  - IETF stream
   OAuth 2.0 Security Best Current Practice (Best Current Practice)
   Token: Roman Danyliw

Liz: There's no discusses, so unless there's an objection now, it looks like
this is approved. Ok, this is approved and since Roman isn't here, we'll put
this in approved announcement to be sent; AD follow-up.

Mahesh:   The question is, I think occurrence of the word 'not' in lowercase,
followed by 'recommended' in uppercase, what is the recommendation? I did point
it that they have used 'not recommended' with 'not’ being lowercase, should
that be in all caps?

John: It's either all caps or no caps.

Mahesh:I don't know what the expectation is, are the authors expected to fixed
it or is it okay to let it go?

John: You didn't make it a discuss so that means you thought that it was okay
for the authors to go ahead.

Mahesh: My mistake, that's why i'm asking myself now, maybe I should have.

Francesca: I think it should be fixed, but it's also fine not to put into a
discuss and trust the responsible AD that they will follow up and make sure
that the comments are there.

Murray: I think most of the time the RFC Editor will catch this, but we should
catch it first because this is sort of a domain that we claim as something we
should be filtering. But I agree that it should be all caps, and it should be
caught and fixed.

Deb: Is recommended a word in RFC 2119?

Murray: Yes.

Erik: Negated forms are also in there.

Deb: I assumed, if recommend was in there not recommended would be there as
well. But I didn't realize recommended was there.

John: It's one of those lesser use synonyms like, shall.

Liz: Mahesh, do you want to follow-up with Roman about this or do you want to
put in a discuss now?

Mahesh: I'll just follow-up with Roman.

 o draft-ietf-httpbis-sfbis-06  - IETF stream
   Structured Field Values for HTTP (Proposed Standard)
   Token: Francesca Palombini

Liz: We don't have any discusses here so unless there's an objection now, it
looks like it's approved.

Francesca: Thank you everyone, for the first time I think we don't need a
substate for this one.

Liz: Alright. Approved announcement to be sent.

 o draft-ietf-emailcore-rfc5322bis-11  - IETF stream
   Internet Message Format (Internet Standard)
   Token: Murray Kucherawy

Liz: We have a discuss, we want to discuss this today?

Murray: Nope. I'm sitting back and waiting for Paul to get beat up pretty good
over this one.

Paul: During the days of the open PGP key specifications. What we needed to do
was provide a hash of the email address. And of course, then we got into the
interpretation of the local part on the left side of the ad symbol where you
run into this issue of capitalizing words so like like you can see on the
screen paul@nohats. Let's see over the capital P being Paul@nohats and
paul@nohats lowercase. Technically, these are, according to the spec different
email boxes, and you're not allowed to interpret them. But of course, with
virtual keyboards on phones these days, there's absolutely no one who could
have these things different at the time, this was like 1015 years ago. They
said, if you want to change that interpretation, you'll have to change the
specification of 822. 15 years later, here we are. It's getting updated. But
they're not actually updating this part now. So I'm basically throwing salt in
the wounds and see what happens. I think it should be updated and i'm sure a
lot of people think it should not.

Murray: Is that a normative, should not?

Paul: we'll see what happens, I don't think we need to further discuss it here.

Murray: AD follow up, it probably will not require a revision but we'll see how
the conversations play out.

Paul: Thanks for the vote of confidence.

Liz: This will stay in IESG evaluation; AD follow-up.

Francesca: I closed all the erratas that were still open for 5322. But I
understand correctly that when we do this, we try to like go over this because
the working groups had taken care of them all. I'll just go ahead and double
check that there is none left.

Murray: Right. It's less important for a bis, but it is most important when
things go up the standards track like to Internet standards which is what's
happening here. So thanks for that.

 o draft-ietf-sidrops-signed-tal-15  - IETF stream
   RPKI Signed Object for Trust Anchor Key (Proposed Standard)
   Token: Warren Kumari

Liz: There are no discusses so unless there's an objection now, it looks like
this approved.

Eric: AD follow up, right?

Liz: Yes, we'll put this in AD follow up since he's not here

 o draft-ietf-lamps-ocsp-nonce-update-08  - IETF stream
   Online Certificate Status Protocol (OCSP) Nonce Extension (Proposed
   Standard)
   Token: Roman Danyliw

Liz: We have a few discuss, does anyone want to discuss this now without Roman
or leave it for later?

Deb: We'll leave it for later. The authors have come back to me quickly so
hopefully it'll be resolved quickly.

Liz: We'll just leave this in IESG evaluation; AD follow-up.

 o draft-ietf-dnsop-dnssec-bootstrapping-09  - IETF stream
   Automatic DNSSEC Bootstrapping using Authenticated Signals from the
   Zone's Operator (Proposed Standard)
   Token: Warren Kumari

Liz: There's a discuss, anyone want to discuss this? Anyone want to discuss
this while Warren is still not here?

Paul: The one item is about the signal of putting in a DNS record that has the
underscore signal as a prefix for a protocol and my comments, I was asked as
the designated expert for the underscore registry to comment on this. And so
with that hat on, I commented that underscore signals are very generic and
might get used by other people as well. It's better to pick up a little more
specific name, for instance, like Underscore DNSSEC or something so there was
some discussion, and then some of the participants are fairly new, so they
don't know the entire process. They were kind of waiting for the IESG to make a
decision. I have to come back to them and say, that's not really how it works.
We just put our fingers in the wound, and then you're supposed to to fix the
wound so we'll talk to them on that part and some other issues, but I'm still
in email conversations with the author, so that will just go back and forth.
But I don't see any fundamental problems. They seem to misunderstand the
process a little bit.

Erik: I thought the underscore name was on purpose and it was the underscore DS
boot. Prefix in front of the underscore signal that actually sort of identified
a sub application use of the signal, signal signaling mechanism as I mentioned,
it's also still too early in the morning.

Paul: You're right but for instances there  are suggestions that the underscore
signal would be its own separate DNS zone with zone cut so that you put all the
DNS things in there specifically. And so there's sort of this implication that
it's still all related to DNS or DNS SEC. I'm more concerned about like, you
know, signal messenger doing something with underscore signal.

Erik: Things that have a zone cut operational comment, right?

Paul: In some places that seems to be suggested in other places it's not.  I
want to propose to them to change it but their term that they defined was a
signaling domain, and I think signaling domain, in the word kind, of implies a
domain like a zone cut. So I think maybe they should use signaling names
instead. And then, whether it's a zone cut or not is left in the middle. So
I'll have a few back and forth with them on those topics. If they want to keep
using underscore signals, I'm not going to put my foot further down. I've
thrown enough for discussion, there seems to be some disagreement in the
working group so it's not just me. There's some others that also think this is
not the right term to use but there's also a few people that want to keep it
so.  My My understanding from Warren that because the authors aren't too
familiar with the process, they're kind of waiting for others to fix this issue
and the working group chairs have said this is not our problem anymore. There's
some grumbling around who makes the final call, or who makes a consensus call
on what to do in this case. I'll walk to Warren about it. These are all minor
things, they're not fundamentals problems like the emailcore one so this should
be much of a problem.

Peter: I only came to observe,  my understanding is that it's not my role here
to participate, although, if you want me to comment on stuff then I certainly
can.

Paul: We can talk about this over email. I still need to answer on some of your
responses, I didn't have time before this meeting to respond. As for the
underscore signal thing, I need to talk Warren because apparently the chairs
are also not sure, they don't want to do a consensus call on this. It's a bit
in limbo now, whether it should change or not because there are some people for
and some people against. Normally not the IESG that makes that decision.

Peter: The chairs are also not of one opinion so I don't know who's official
role it would be at this point to resolve this.

Paul: I guess the unofficial official way is for those people involved to get
into a meeting or into a room and come out as happy people in the end. We'll
let Warren and chairs arrange that.

Liz: This document will stay in IESG evaluation; AD follow up.

(Warren joins the telechat)

Warren: Paul and I have a discussion afterwards on some portions of it but we
can do that now, or we could not in which case everyone can get on with the
rest of their lives.

Paul: There was, but mostly that's it's unclear how we're going to get a
decision and that I was going to punt that back to you and the chairs.

Warren: A decision on which particular part? The signal thing?

Paul: Yeah, the signal name.

Warren: I reread the thread a couple of times, I guess we just need to have
more discussion. Initially, I was leaning fairly strong in that we should do
something other than underscore signal, but the more I think about it, the more
it seems like, one can mint other uses within that. I think it just needs to be
more discussion.

Paul: Ok, that sounds good. Let's do that.

Warren: I wasn't there for that part, was there anything more than that?

Paul The only thing that is that it intersects a little bit with the phrasing
of signaling domain and advice in the document to make that a separate zone. If
you make it a separate zone, you're kind of binding it to the DNS/DNS
signaling, and you wouldn't really use it for anything else. Message store,
signaling if the signal Messenger wants to do something there. That's why i'm
still leading more towards a different name. So don't want to stall on that for
too long, either. We should just decide to move on.

Warren: Some of it comes down to implementations, and what I don't know is how
many individual organizations are using the signal, if there's Cloudflare has
millions of zones but presumably there's one place in the code where they can
change it versus if you have 50,000 different people who've all done it as one
offs. It's much harder to do. People should understand that if something moves
from a draft to an RFC, and if it's a draft, things might change. If signal
messenger were to want o use it, we shouldn't change name based on the fact
that somebody might use it for something, right? DS could be used by someone
else.

Paul: That's why as the underscore registry designated expert, i'm always
warning people if they use very generic names that aren't really tying them to
one specific purpose.

Warren: Do we want to take offline the discussion but which I also care fairly
strong about, I think it's useful to have advance that operators shouldn't use
this to lock people to something without their consent.

Paul: That's true. That's a good issue to discuss, let me just reiterate the
issue bit better so that people here from the IESG have a better idea of what
we're talking about. At some point, the document recommends that you don't
enable the DNSSEC thing has an a DNS operator without permission from the
participant because it can be used to make it harder to move a domain from one
DNS hosted to another. On the hand, I kind of feel that the whole point of this
document is to make this all more automated and happening, and so asking the
participant or the domain owner who doesn't really know anything about it, and
they've just assigned the DNS host to do stuff for them. They would expect that
stuff includes the security part, and they should just do the stuff that's
best. And so, by seeing whether they should or should not enable the
specification of this document. I feel it's more wading into ICANN territory
about what our contractual terms and how you should have as a register. My
preference is to leave this out of the document as possible.

Warren: I understand what you're saying, my concern is until this document, the
domain owner is the person who has been responsible for the zone content. It is
a fairly fundamental shift. The DNS operator, all they do is take the zone and
serve it. Load balancing, but you're told by the Zone operator, please provide
the best answer that you can. This changes the fundamental model where the fact
that somebody is a domain hoster for you. Domain operator is now in a position
where they make fairly fundamental decisions about your zone, whether or not
you want to sign as a fairly fundamental decision. Saying because i've asked
you to serve my zone file, you're now in a position where you can make changes
to the site.

Paul: I don't fully agree with you on that because the same thing could be said
about hosting a website. I ask someone to host a website and they make all
these decisions about how much Let's Encrypt can be trusted to put a
certificate on there for a certain amount of time and maybe, I don't trust that
Let's Encrypt at all. The web hoster doesn't ask the main owner if I can use
Let's Encrypt to put an SSL certificate on your website. It'll be considered
part of the process, so part of hosting a domain is hosting it securely.

Warren: Yes, but something that's different is if you ask somebody to host your
website and they  change the content of the website, you would presumably be
annoyed. Here you're asking some to host a zone file and they're changing the
contents of the zone file, my concern is, that's a bit of a weird thing.  I
think it would be reasonable when you ask someone to host the zone as part of
their sign-up, they say we're going to enable DNSSEC for you. Maybe it's more
that you not necessarily ask have to ask their requirement, but maybe the
person should be informed that the hoster will change stuff.

Paul: The problem you're still causing is Cloudflare is hosting the millions of
domains cannot just enable this feature, because now they have to ask each
individual registrant to do this, ti be OK with it. And, again, I feel this is
all about automating the basic security of DNS zone for the customers, and it
should just be able to do that without getting explicit customer confirmation,
because otherwise all of this automations will actually fail.

Warren: That's what i'm saying, let's just not get confirmation they could be
part of your sign-up going forward.

Paul: But they already have 100 million zones and what if they want to enable
it for that too? I feel all of this is outside IETF things, we just specify how
it works, whether or not you think you should be able to do this with or
without confirmation of the user should again be other people's problem, like
people with lawyers and money.

Warren: We do have a lot of stuff in the IETF, where we say 'from an
operational standpoint, you should not announce someone else's address space',
right? BCP38, you should not send addresses from things that are not yours. I
would be more than fine if we put in some weasel words. I think there's some
actual risks here with vendor locking. I ask Amazon to host my zone file, I
transfer it to them and they DNSSEC sign it, I decide that route 53 is doing a
crappy job, and I want to move it to DSEC. I didn't decide for it to be signed,
they did. I don't know that when I move it, it breaks. I don't know why I have
to keep it there from now.

Paul: The providers that are involved in the moving should know what they're
doing, the new providers should realize it's the DNSx site and know to drop the
DS record or we're going to have to add our own DS record to be in and do a
multi-sign or rollover, or whatever is needed.

Warren: Suddenly way harder than when users used to be like move from here to
there.

Paul: Users can just be told by the new DNS host, please ask your old host to
remove the DS record because without this we cannot move your domain safely.

Warren: As long as there's an easy way to be like, please turn off this magic
feature you turned on that I didn't know you were going to do, but apparently
you did even though I didn't ask you.

Paul: From a practical point of view, when this person would have signed up
without 53, and it would have been a disclaimer, saying, we're doing to enable
this for you unless you say no, they would have been in the exact same position
right now, nothing have changed except there has been some legal lease, and
there's some lawyers that will tell you whether or not this is enforceable.

Warren: I do agree that many people don't read AEP's, that just feels wrong to
me that we're making a fairly fundamental change to the DNS.

Zahed: I think Peter wants to talk.

Peter: If you want me to comment. I would just like to observe that in most
cases, the DNS is operator by the registrar, who, even without any kind of CDS
or something can turn on DNSSEC and put DS records in the parent and lock in
the customer, which I recognized that may be a problem but it's certainly not
introduced or exacerbated by this draft. Second, RFC 8078 already has CDS based
bootstrapping, it's just not authenticated. My point is that this draft doesn't
change or introduce this problem.

Warren: With CDS bootstrapping, I, as the registrant, decided to enable DNSSEC
and publish a CDS record.

Peter: Not necessarily, nothing kept the DNS operator from signing a zone and
putting a CDS. Why is it different from now that it's also called publishing
under some other name.

Warren: The difference is, before a DNS operator change a user's zone file
without a user expecting that, the DNS operator's done something real bad. What
we doing here, we're saying if I put a a zone file on Route 53, and they
randomly added 4 records and deleted some and pointed
www.kumari.net@amazon.com. I'd ask what are you doing?

Paul: So Warren, they actually need to have a copy of the CDS records in the
actual zone file too. It's not that they're just editing their own domain host
or signaling domain. They also have to have matching records in the actual
customer zone, so they would still be acting against the customers interest. If
that's the case you're concerned about. They have to basically put in the old
CDS and SD style records, plus they need to add the signaling zone. So in that
sense they still have to modify customer data for which they can hold liable.
If that was against the wishes of the customer.

Warren: That's my point, before it was clear who was responsible for the zone
content. We are here now saying the DNS operator has some responsibility, as
they're expected to be able to change a user's zone which wasn't really true.

Peter: No, RFC 8078 defines that you can put in CDS records in the child zone
if that is desired. This draft says that if you put CDS records in the child
zone, if there are, doesn't say that there should, or you can arbitrarily do
that but if there are any, then you should also co-publish them under the name
service subdomain. It doesn't change the conditions under which you can put
stuff in the child zone.

Warren: I still disagree, to me this feels like you're changing the
responsibility model of who's allowed to make changes to a zone.

Paul: It's already been done without a disclaimer.

Peter: But I do feel the uneasiness of it, and I think that's fine. Which is
why we put in those 2 sentences about you can't do it without permission which
I think is kind of common sense anyway. I wonder how much those 2 sentences
really hurt. So let's just say we kept them. I understand, the kind of policy
thing, but does anyone really object that you can't put stuff in the zone
without.

Paul: The issue is by putting it explicitly in there, someone who implements
this document will then have to wonder, how do I implement this? Must I create
a button or questionnaire, or an email that will find the right user for this.
Do I need to write code for this? And I think the answer is no, you don't need
to write code for this. That's my problem with adding these sentences.

Peter: Maybe we should make some commentary on, the conditions under which you
edit the child zone that is the zone of responsibility to decide the content.
Maybe we shouldn't use normative language for it.

Warren: If it were me, if I had a zone that I did not want DNSSEC signed, let's
say I have no dnssec.com, and I put it on a DNS hoster, and they sign it for
me. I would be annoyed.

Paul: Well in the fine print of the DNSSEC no, said that they will, for your
security sign this. I don't think the RFC should make any text on this, this
outside of IETF land. This is contracts and agreements between parties working
together to do stuff, that's ICANN, not IETF.

Warren: There's a lot of things throughout most of our documents where we set
expectations on how the protocol will be used. Maybe the exact wording needs to
be changed. You must get explicit permission from the registrar. If people are
ready doing this, they're really doing this but i'm sure we can probably come
with some wording.

Paul: Do other IESG members have any, have any input on this? Warren, Peter,
and I have already given our opinions. I would like to hear from others on what
they think.

John: I'll repeat what I put in Slack, generally RFC 2119 keywords, you said do
I need to write code for this? If the answer to that question is yes, I need to
write code for this then go ahead and use the all caps keywords. If the answer
is no, I don't need to write code for this, then you shouldn't be using 2119
keywords.

Warren: I think that there's a huge number of documents, probably ones you've
written as well. Where there is you "MUST" not do this, which is done through
norms and expectations. What you're saying then, is, no operational document
should contain 2119 language.

John: I'm not going to ballot discuss based on that, I think it's adorable and
optimistic. I think it's not especially useful because operators do what
operators, and in my experience, are going to say it says ‘MUST' in here so now
I need to change my business process.

Murray: I tend to agree. There are 2 exceptions that have come to be known to
me since in my terms, I became an area director, and 2 of them are security
related where you must use the most recent shaw to ensure the best security,
even though if you use shall 128, it's going to work fine.  It's just going to
suck in terms of protecting your data. In terms of operability, it doesn't
matter which shaw you use, they're all probably fine. The other one is
operational stuff where we have come to say things like you really SHOULD log
this thing someplace, well, it has nothing to do with interoperability, right?
The protocol , the main protocol, like DNS, will continue to work doesn't
matter what you log but this becomes something that has an interoperability
thing but it became an accepted practice to use 14 words. As a black and white
kind of thing, I tend to agree with John. We should only use it when it comes
to interoperability of the protocol rather than describing practices. But there
are a few things where it seems like it's become sort of normal to use it. I'd
like us to be conservative about it.

Warren: I think we work this together and work it offline. We can come to some
discussion that I think will make us happy enough.

Paul: Yeah, we'll find some text.

Murray: I'm happy to help.

Warren: Peter was asking if we want discuss the deprecate obsolete question
where, Murray, if he's still around had different views.

Murray: What was it again?

Warren: Would you like to discuss the deprecate obsolete question?

Peter: I can do a quick summary. The unauthenticated CDS bootstrapping method,
the current draft says that section is getting deprecated. It was suggested
that instead RFC 8078, which contains that old method should be obsoleted as a
whole because otherwise, Murray said there would be two methods of operations.
Paul suggested that it should not be obsoleted and just be recommended to use
the new method.

Warren: To me, it seems like recommend to use the new old feels more reasonable
which I think was Paul's text.

Paul: Yeah, that was my proposal because I felt weird that sort of the core of
the other RFC is obsolete, but then all the text around that core is still
relevant. It felt a bit weird to me.

Murray: I guess I thought it was strange you're only should-ing the use of the
new thing. It seems mushy because it should, can be ignored and then you can
still claim that you're compliant because you've chosen to ignore the advice of
the should. So is this enough? Is there a new algorithm or isn't there? That's
kind of where i'm heading with it. I didn't discuss this anyway, i'm probably
going to be fine with whatever you decide.

Warren: I think I don't entirely your understand/concern. We're introducing a
new thing, and you're saying it's recommended you use this.

Murray: Is this new thing to utterly replace the old thing? Or is there a
transition period allowed for a while or something like that?

Warren: In my view, this is an additional way of doing something. It involves
different set of players. Like if, my DNS operator doesn't want to support
this, and I personally would not want my DNS operator to support this. But if
my DNS operator doesn't support this, then the other solution can still be used.

Murray: Ok. The way it read, at the time I read it, it seemed like the point
was to say, the old way is dead. Don't use the old way period, in which case
this should not be a 'should' because a 'should', allows me to say I am
compliant with the spec, even though I don't do what that should've told me to
do, and I claim I have intelligent reasons for that deviation. The context you
just gave me, i'm fine with it. Maybe this about is there any clarifying
language it needs to be put in to make that clear to weird people, like me, who
read things in funny ways.

Paul: You're probably responding to my suggested text then, right? Where I say
'don't obsolete it, but just recommend a new method.'

Murray: That's fine. It seemed like the 'should' is doing what you said, but
the original text was saying something much stronger, and that disconnect is
where I got caught.

Paul: Ok. I think it's clear then.

 o draft-ietf-dhc-addr-notification-12  - IETF stream
   Registering Self-generated IPv6 Addresses using DHCPv6 (Proposed
   Standard)
   Token: Éric Vyncke

Liz: We a discuss, we want to discuss this now?

Eric: Thank you everyone for reviewing it. Warren is an author so it'll be nice
to have him on board, but Jen, the other author was quite responsive to all the
points and I think all the raised points are mostly implemented already in -13.

Murray: We've been exchanging emails during this call out, i'll clear within
the next few minutes.

Eric: Let's put it in AD follow-up, i'm sure it will be approved next week. Do
you agree, Murray?

Murray: Yes, it's all yours.

Liz: We'll put in IESG evaluation; AD follow up.

 o draft-ietf-lamps-rfc5990bis-06  - IETF stream
   Use of the RSA-KEM Algorithm in the Cryptographic Message Syntax
   (CMS) (Proposed Standard)
   Token: Deb Cooley

Liz: We have a discuss, do we want to discuss this now?

Paul: Not really, I talked to Russ  a bit already, he answered most of my
questions, there is still one or two things to figure out but this will be
resolved soon with a revised ID.

Deb: That's the answer to your next question.

Liz: Revised ID needed?

Deb: Yes, please.

Liz: It's staying in IESG evaluation; revised ID needed.

 o draft-ietf-lamps-cms-sha3-hash-03  - IETF stream
   Use of the SHA3 One-way Hash Functions in the Cryptographic Message
   Syntax (CMS) (Proposed Standard)
   Token: Deb Cooley

Liz: Unless there's an objection now, this one is approved.

I'm hearing no objection so this one is approved. Deb, is this ready to go or
do you want give it a final look?

Deb: I would like to give it a final look, please.

Liz: This will go into approved announcement to be sent; AD follow up.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 NONE

2.2.2 Returning items

 NONE

2.3 Status changes
2.3.1 New items

 NONE

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-tls-keylogfile-02  - IETF stream
   The SSLKEYLOGFILE Format for TLS (Informational)
   Token: Paul Wouters

Liz: We don't have any discusses so unless there's an objection, it looks like
this one is approved. Paul, is this ready to go?

Paul: Put it in AD follow up just to be sure.

Liz: This will go into approved announcement to be sent; AD follow up.

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 NONE

3.2.2 Returning items

 NONE

3.3 Status changes
3.3.1 New items

 NONE

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 NONE

3.4.2 Returning items

 NONE

4. Working Group actions
4.1 WG creation
4.1.1 Proposed for IETF review

 NONE

4.1.2 Proposed for approval

 NONE

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o EAP Method Update (emu)

Liz: Is this ready for external review?

Paul: I think so, just reading your comments right now. I'm not sure the
process for this is for me to do some revisions based on the bullet point
mentioned of the milestones, or whether the milestones get filled in later on.

Liz: We can just send this out for external review right now or you can take
another chance at a revision and then you let us know when you want to send the
announcement.

Paul: Send this out first and i'll review, then we'll take this comment along
with the others that come in.

Liz: We'll go ahead and send this out  for external review without waiting.

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

John: Sorry I had to miss the meeting yesterday and so did Roman, unless David
would like to tell us something.

Liz: David, do you want to give a little update on what the IAB has been
talking about?

Cindy: The thing that the IESG wants to be aware about, is that the IAB has
been talking to Elliot Lear about running a session at IETF 120 to get
community feedback on how the independent stream runs because it's the easiest
way to get something on the main agenda.

6. Management issues

6.1 [IANA #1364742] Designated experts for RFC 9562 (Universally Unique
IDentifiers (UUIDs)) (IANA)

Liz: That is just assigning that first action item for Orie, and we already
have names to approve at the end of this agenda here.

6.2 [IANA #1363801] Designated experts for RFC 9557 (Timestamp Suffix Tag Keys
registry) (Francesca Palombini)

Liz: Francesca has identified Ujjwal Sharma and Bron Gondwana as the designated
experts for this registry, any objections to approving these folks?

I'm hearing no objections so it looks like they are approved, and we'll send
that official note to IANA.

6.3 Designated Experts for RFC 9560: Registration Data Access Protocol (RDAP)
Query Purpose Values (Orie Steele)

Liz: Orie has identified 4 names; Scott Hollenbeck, Andrew Newton, Mario
Loffredo, and Pawel Kowalik as the designated experts. Any objections to naming
these folks?

I'm hearing no objections so we'll get that official note to IANA as well.

6.4 [IANA #1359278] Designated experts for RFC 9530 (Digest Fields) (Murray
Kucherawy)

Liz: Murray has identified Roberto Polli and Lucas Pardue, any objections to
approving these two?

I'm hearing no objections so they're approved, and we'll get that official note
to IANA.

6.5 [IANA #1364742] Designated experts for RFC 9562 (Universally Unique
IDentifiers (UUIDs)) (Orie Steele)

Liz: Orie has finished a brand new item already, and has identified  Kyzer
Davis and Brad Peabody as designated experts for RFC 9562.

I'm hearing no objections so they are approved. I think for the first time ever
we don't have any designated expert items, we're all done. I'm sure we'll get
another one soon.

7. Any Other Business (WG News, New Proposals, etc.)

Deb: Can I ask a question about IAB news you can use, you mentioned Elliot and
a BoF. Can you remind what the topic of that?

Cindy: Elliot is the independent submissions. Editor. This would be a
discussion with the community on the independent stream.

Deb: So that's interesting, so not special algorithms, vanity algorithms.

Cindy: The national crypto stuff, that is part of that,

Deb: So we've been talking to him about this, because the security area is
interested in this and we thought there was a different plan so that's very
useful information, but definitely news we can use.

Cindy: I know that it's kind of a little bit amorphous at the moment, and i'm
probably not explaining it as well as I could.

Francesca: There's minutes for the IAB?

Cindy: I was actually taking the transcription for that but the nuances of that
conversation completely left my head. I would have to go back and look.

Deb: That would be awesome. There had been some discussion points for sometime,
predating March.

Cindy: I'm suddenly remembering the other part of this that there was going to
be a discussion in SAAG specifically about the national crypto stuff. Maybe
that's what you're thinking of, and then separate conversation with the
community about what are the expectations for the independent stream as a whole
and how how it operates, and what the community is actually wanting from this.

Deb: Ok, we knew about the SAAG part of it and that was part of our plan, but
we didn't know what the IAB was going to make Elliot do. It is very useful to
know and it would be nice to see the transcript for that for whatever he's
doing as a BoF. I would assume, because this only happened yesterday, right?
That he would come back to us and tell us what the plan was.

Cindy: And that plan has not yet been formalized at all because it sort of
brainstorming about what that session would be, and who actually would own that
session because the independent steak is independent but IAB has oversight of
the independent stream. The IAB is still trying to work that out with Elliot so
there might not been a concrete answer to your question on that.

Deb: That's fine, we have time between now and July.

Cindy: This is mostly when you see something show up as a BoF request, don't be
surprised by that.

Paul: I guess i'm still surprised by Elliot sorting mentioning or taking
actions that relate to his, even though the Security Area Directors haven't
decided  on final plans yet, but we'll take it up with Roman and Elliot.

Francesca: The item I want to bring up, is that there was two documents on the
telechat that have had after the working group was done with it, only had 1
review. Like one is your NTP document, Erik and the other was Warren's sidrops.
It's a little worrying because we usually have 2 or 3 review of directorates or
review teams. I guess it's less worrying if the working group is quite big and
active, and there is more people in it. I don't know at all how these working
groups are. For some of my working groups, I wouldn't been worried about fewer
reviews. For others, they're smaller, only 10 participants like active
participants, I would be more worried if they only for 1 directorate or review
team review. Then it's up to the responsible area director to evaluate
consensus, and I know that we usually just assume consensus by silence. But for
these ones, I was just wondering i'm the only one worried that or feel free to
say yes, you shouldn't be worried about this.

Eric: That's a valid point, because how can you give consensus with just one
person?

John: For the sidrops one, i'm not worried about that because I know that
community is a pretty tight community and I rely on the working group and the
authors to actually have reviewed it. If anything sidrops is going to get too
much review inside the working group, not too little. I don't know about the
other one, but formally, the directorates have no formal standing at all, they
just exist. I think in the end, we count on the AD to have enough review.

Francesca: Ok. That's reassuring, because like I noted when I was looking at
the document which I did not have time to review myself. I know that it was
just 1 review and the previous versions had issues that have been dealt with,
but it sort of caught my eye. Other documents have a number of reviews, like 6
or 7 because there is the last call and telechat review and then you are sort
of more reassured that more people outside the community have also taken a look.

Erik: I think you're observations are fair, I think for the NTP case you're
look at a group with fewer than 10 active participants, but all of them
essentially represent one NTP implementation, each individually. This
particular document case it was about IANA registries, and it wasn't a protocol.

Francesca: I guess this is just a reminder to not slack on that because we are
supposed to be evaluating consensus. I know that I have some working groups
that are quite small, so when that consensus call will come, i'll have to pay
more attention to those.

Francesca: I have started a rechartering, and I got some comments, and the
charter following one of the blocks and now the charter is significantly
different from what the IESG had internally reviewed the first time. What's the
process? Am I supposed to bring it back as an internal review again? Or send an
email to the IESG?

Murray: I think by process it's through your conscience, right? If you think
it's changed enough that our prior ballot really doesn't apply to the text that
is there. Now, I would run the process again just to make sure it's
bulletproof. If you try to squeeze it though, the likelihood of an appeal goes
up.