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

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2024-06-20 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Amanda Baber (ICANN) / IANA Liaison
Jenny Bui (AMS) / IETF Secretariat
Deb Cooley / Security Area
Jay Daley / IETF Executive Director
Liz Flynn (AMS) / IETF Secretariat
Sandy Ginoza (AMS) / RFC Editor Liaison
Jim Guichard (Futurewei Technologies) / Routing Area
Mahesh Jethanandani (Arrcus) / Operations and Management Area
Erik Kline (Aalyria Technologies) / Internet Area
Murray Kucherawy (Meta) / Applications and Real-Time Area
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Web and Internet Transport Area
Tommy Pauly (Apple) / IAB Chair
Colin Perkins (University of Glasgow) / IRTF Chair
John Scudder (Juniper) / Routing Area
Orie Steele (Transmute) / Applications and Real-Time Area
Éric Vyncke (Cisco) / Internet Area
Paul Wouters (Aiven) /  Security Area

REGRETS
---------------------------------
Roman Danyliw (CERT/SEI) / IETF Chair, General Area
Gunter Van de Velde (Nokia) / Routing Area
Zaheduzzaman (Zahed) Sarker (Nokia) / Web and Internet Transport Area
David Schinazi (Google) / IAB Liaison
Sabrina Tanamal (ICANN) / IANA Liaison

OBSERVERS
---------------------------------
Behcet Sarikaya
Ben Schwartz
Greg Wood

1.2 Bash the agenda

Liz: Mahesh suggested we do the agenda first because he can only stay on for
the first hour, but I know we have some documents to get through and the agenda
can take up a lot of time. What do you guys think? Any objections to doing the
agenda first or should we try to get through some documents  first?

Eric: I see one author, Ben, for the ADD document so if maybe we can put it at
the beginning. Just a small request.

Liz: We can do the ADD document then move to the agenda deconfliction. Anyone
else have any other suggestions? Issues?

1.3 Approval of the minutes of past telechats

Liz: Since this is our second telechat in a row, we haven't had enough time for
the minutes from last time to be approved so we wil do those at the next formal
telechat which is the last one before IETF 120.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

     o Paul Wouters to find designated experts for RFC 9577 (The Privacy
       Pass HTTP Authentication Scheme) [IANA #1366921].

Liz: This came in within the last day or two so Paul, you got a new action item
here.

Paul: That one is actually in progress.

   * 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: I think you two are going to find time to talk about next week?

Warren: Yeah.

Liz: We'll leave that in progress.

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

Paul: This is done.

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

Paul: That will be done before the ISC meeting, it will be done in a few days.

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

Liz: Anyone have any updates they want to share on this?

Paul: I think I still need to convey that the PERPASS list can close, I did not
hear any feedback there, but I still have to go through some of my own entries.

Liz: Just send us a note @support, letting us know which ones are ready to be
closed when that's ready.

Francesca: When you are done, you can put your name in the list of people who
are done with it.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-dtn-ipn-update-11  - IETF stream
   Update to the ipn URI scheme (Proposed Standard)
   Token: Erik Kline

Liz: We have a couple of discusses, do we want to discuss it now?

Erik: I think we can discuss some of them. I know Roman's not here.

Eric: I think Mahesh left as well.

Erik: Maybe we can talk about the process since Colin is on.

Francesca: I think I can take on Mahesh's point to start with. He mentioned
Russ GEN ART review and Russ was basically saying that this IRTF informational
document being updated by this document which is in the standards track. Well,
there are two things about this; first is it's a standards track updating
informational which a lot of ADs have already said they don't have a problem
with it, the other part is that this is an IRTF document, or this is an IETF
updating IRTF document. I did see this stream protocol link that you just
posted, Colin. I thought it was useful, but when I read that it sounded like
this is more for when an IETF document wants to obsolete or we want to make an
IRTF document historic or something like that.

Colin: This is just an update to it, right?

Francesca: This is just an update, and because we don't really define what
update means, we always have different opinions.

Warren: As long as the stream manager is OK with it.

Colin: If you send something to the IRTF then we can ask the IRSG to have a
look at it and since there isn't any work in the space, I think it will be fine.

Warren: In the next couple of months there's going to be a document from DNSOP
which updates an independent stream document and we spoke to the ISE and we
were like 'hey are you cool with this?' and he was like 'yeah, perfectly fine.'

Francesca: Warren, make sure that gets into the shepherd write up so that the
IESG is aware you have done that.

Warren: It's already in there.

Erik: Zahed, did some initial communication but I wasn't aware of this and I
wasn't tracking this so I can follow-up on sending something to the IRTF.

Colin: If you get it to Jenny to put it on the IRSG agenda for next time, we'll
talk about it and approve it.

Erik: How do I do that?

Colin: Send an email to myself and Jenny.

Liz: Jenny is also on the call.

Jenny: I can add this to the agenda.

Erik: So if we do this, and the IRTF folks come back with a general approval,
do we think that addresses people's discuss points?

Francesca: I think it addresses mine, I think it addresses Mahesh's as well but
i'm not speaking for him. The other thing, I didn't understand why even there
was an update of that document and I saw that other ADs had the same question
as me. I don't understand why there is that link there, and if you don't need
that link, you might not need to do this whole thing.

Erik: Because 7116, defines an IANA registry for these CBHE numbers, and what
this document is doing is relaying out this registry which is rearchitecting
that registry by introducing this applicator.

Francesca: Is it just changing the name or doing additional things? Because the
name change, I have seen it but I wasn't sure you needed that link there for
that.

Erik: It's actually taking a 64 bit number space and splitting it into 232 bit
number spaces. Unfortunately, I think neither of the authors are on the call.
It's a bit more invasive surgery than cosmetic.

Eric: I agree it's an updating the document but it is completely unclear in the
comments. When you're reading this draft, you don't know what has been updated.

Erik: There's supposed to be a clear update section or at least in the abstract
or intro. That should be clarified.

Warren: Actually, as a quick note i've been pushing my authors and working
groups really hard to make sure that their abstract has a thing like 'this
updates, RFC number by changing the definition of something,' because I find
that they've been missing that and the purpose of the abstract is for people to
know if they need to read the rest of the document.

Liz: This sounds like it will be staying in IESG Evaluation for now, revised ID
needed or AD followup?

Erik: Why not both? Revised ID needed, and AD follow-up i'll send email to the
IRTF.

 o draft-ietf-add-split-horizon-authority-14  - IETF stream
   Establishing Local DNS Authority in Validated Split-Horizon
   Environments (Proposed Standard)
   Token: Éric Vyncke

Liz: Eric, do you want to discuss these discusses?

Eric: I think we need to discuss this one, for sure. Thank you to Ben for
joining the call to talk about this document. So i've seen that this morning,
my time, Tiru, who lives in India has submitted a new revised ID addressing
John's points and by the way, John, I should've spotted this one. Basically,
the revised ID goes in your direction, it must, if you don't get there don't
retry. It is pretty much clear. Murray, the same thing about the missing
reference base64 URL encoding, the new revised ID request is there. So I think
it was two simple and valid discuss, I should've spotted them before. I would
assume that those two discusses will be clear, and we will just get enough
ballots to pass. Now the abstaining is concerning, of course. I don't know what
to do, obviously, there's been some discussion back and forth between Paul and
the authors on this one. For me, I obviously respect the abstain position. I'm
not sure now, Paul and Warren if you want to leverage Ben's presence here to
discuss your abstain position.

Warren: To be clear, my abstain is not a grumpy abstain. It's more just sort of
following a little bit of Paul's position. But also, I think this is
significant enough change to the resolution behavior and it involves a fair
amount of not particularly simple DNSSEC considerations that I think that is
really should have had much closer consideration with the DNSOP working group
and review from DNSOP. I mean, there was a DNSOP stir review, but that's not
the same as the having the entire working group look at it. I think that is
sort of fundamental enough set changes that it should have had more discussion
and review across areas.

Eric: Thank you for restating that, I don't know whether you read my email sent
during your night. My apologies for not checking that DNSOP was in WGLC as
well, anyways, it was IETF Last Call so that should have been done at that
point of time. Normally, I would double check that but I didn't this time.
Sorry about that.

Paul: My problem is, part of it is the generic problem of the ADD working group
which has left the client policy out of charter because there's never going to
be an agreement on client policy because half the people want the network to
trump, and half the people want the client to trump about security decisions
and so the whole client security is out of scope. Instead of having in this
document a section on what is the client supposed to do and what is the proper
implementation for prime policy? It only puts in some security considerations
because it can't really give a full set of, this is what the client should do
because they would go against the charter. This is not something the authors
can fix it, it's just an artifact of how the ADD working group formed. My
second important point is, I think the split DNS is a concept and this document
kind of like weasel worth itself into changing that concept. I think the
concept of a split DNS is, you have a public zone worldwide, you have a couple
hundred branches that have all their own internal zones that are either split
off or copies of that zone. They are completely run independently so these
people don't talk to each other at all and they have to talk to each other to
make it work. On top of it needing DNSSEC, on top of it the client does DNSSEC,
and the public zone does DNSSEC so all in all, this becomes, to me,
un-deployable. It has a lot of complexities. I did chat a bit with John about
this, and I do agree that my objection, at this point, really comes down to I
don't think this is ever going to work and if it's not a standards track
document then I think it's not going to be useful but harmless because people
aren't first implemented whereas if it's a standards track then implementers
might think they must implement this. I think that's too much. I think if this
is changed to experimental then I will change my abstain to no objection.

Eric: Ben has raised his hands, Ben, do you want to reply to this? I want to
note, Paul, that there are so many standards track RFCs that are not
implemented or not even deployed, but it's not the reason. I do agree, it's not
the reason. Warren, do you mind if Ben speaks first?

Warren: No, go ahead.

Ben: I just wanted to clarify a DNSSEC is not a prerequisite for implementation
of this draft. We did a lot of work to make it fully compatible with DNSSEC,
but there is no requirement it's going to be signed. There's no requirement for
the client to be validating.

Paul: It is because you are equally transport security with data origin
security. You're saying if you've got a TLS connection to a trustworthy point
and a network then you can consume untrusted DNS and treat as trusted. That's
just a fundamentally wrong concept. I'm not going to say that DNS for TLS is
equivalent to DNSSEC.

Ben: It sounds in that case, you have a technical objection to part of the
draft because we do have some reliance on transport security. The draft does
not claim that transport security is equivalent to DNSSEC, it does not set the
DO bit, it does not use that in some general way as a substitute.

Paul: No, you just said you trust the DNSSEC part or you trust the transport
part of the data.

Ben: The draft makes, in my view, a compelling clear case that in this specific
case, based on the way that this data is being used, based on the security
relevant decisions that are being made in this case, that transport security is
entirely sufficient and appropriate as the foundation for the client to make a
particular choice for a certain set of clients which are described in more
detail in the draft. It also says for other clients with a different set of
starting points of assumptions that DNS could be required for different clients.

Paul: That's just a fundamentally disagreement, and i'm sorry I pushed back to
everyone who's trying to equate DNSSEC with DOT because they're not the same
thing.

Warren: I mean, this document does do an interesting thing where it lets the
zone operator assign the ability for a dot server to own a part of it. I agree
with Paul here, it feels like a very different trust model or different
security model, but again, I abstained not blocked.

Eric: For a sake of time, Ben do you want to say your last point?

Ben: I think this is an interesting case, my view of this document is that a
lot of people have said split-horizon DNS is impossible to do without resolving
the question of who is in control. We have to figure out if the client is
always in control? And just bypass the network for DNS. Is the network always
in control? And the client must do whatever the network tells it to do. The
point of this draft, in my view, is to say look, it is possible to do
split-horizon DNS without having to resolve this enormous fight. We can
essentially find a middle ground position here where networks can create
split-horizon zones, where clients can access them without handing over DNS
total control of the network. The network can prove precisely what they should
own and client can safely respect only that. I think it's a powerful
demonstration that this is possible, that there is a middle position here, a
technical solution to what looks like a political problem.

Paul: Let's assume that the network allows a client to send DNS packets over an
encrypted transport out of the network that it cannot inspect while offering
this network service. If you look at an enterprise solution, whereas split DNS
is the most common one, the two common ones are enterprise and university
deployment. The university might go 'whatever you want to do. We just also have
this 100 private zones that we don't put in the public DNS, and we'd like them
to work.' so in that case, I think you're right. This might work, but for the
enterprise case, I don't think the enterprise one shoot to have an unfiltered
extraction channel that they cannot monitor, but you can just send any data to
you right, other servers. In that sense, this mechanism is not going to work
because they're going to block your DNS and you're going to be forced to use
the odd path network.

Ben: I can't speak to what enterprises would want to do for that. But what I
would say is certainly any enterprise in that position shouldn't be allowing
clients on the network that aren't fully controlled by the enterprise.

Eric: Ben, Paul, thank you so much for the discussion. Should they be involved
in the ADD working group? Murray, you still have your discuss holding. John was
kind enough to clear it. Murray, are you ok enough with the new draft?

Murray: I saw that a draft has come through, my request wasn't complicated so I
imagine i'll be able to get out of your way shortly.

Paul: I can confirm that the new draft does fix Murray's concern.

Warren: I do agree with Ben that this does do a clever and cool solution to the
can you do split DNS in some way where you have authority. I just fundamentally
don't know if that's a useful thing for people to be doing. I kind of think
split DNS is somewhat of an abomination not to nag. Well done on managing a
solution to the split problem.

Erik: Even in the enterprise case, if they are permitting some security DNS
transport, that was discussed in the document, right? Being transmitted by DNS
stuff.

Warren: I still don't think split DNS is a good solution. What happens if
people have the webpage open or something and then they take their laptop home
and then their laptop connects to coffee shop home network and suddenly things
don't resolve or you leak the internal query, because various things leak DNS
information out including taking a laptop home.

Erik: And for Paul's concern, is this worse? Doesn't make it worse than the
state of things today.

Warren: I think it actually is, but then again I'm only abstaining.

Murray: Now i'm genuinely curious, you use the abomination, are we solidifying
an abomination by letting this go ahead? I thought split DNS is more common
than that.

Warren: It is common, but less over time I think when people realize it doesn't
really do what people want. Also, things like certificate transparency, they
used to be this view that you could keep a whole chunk of your name space
private, but with certificate transparency, if you get a certificate for any
sort of internal name it shows up in the CT logs and so the security or private
or whatever you think you get from split DNS doesn't apply anymore.

Eric: Until Murray clears his discuss, it will stay in IESG evaluation, AD
follow-up. I'll approve it once it clears.

Murray: I heard experimental get bandy around, did we decide we're not going to
do that?

Warren: I don't really understand how if it was experimental, what the
experiment would be. If we publish the document that people implement, you
can't really take it back.  I don't think this is really experimental.

Eric: Agree.

Murray: When Ben was describing it, the language you use described it as a very
particular way to do a very particular thing like a very limited client set and
that sounds an awful lot like the way we define applicability statements, which
forces it to be a proposed standard. But that's a collection of things that
already exist, arranged in a particular way to accomplish a particular thing.
Maybe that's not's not a good example.

Warren: I think the status and everything is fine. Would like to hold my nose.

Murray: The reason why i'm waffling a bit because if you manage to convince me
to hold my nose too, that might be enough balance to hold this entirely. That's
why I'm trying to be careful there.

Warren: I don't think you need to hold your nose.

Murray: I'll comment something when I resolve my discuss.

Liz: This document is staying in IESG Evaluation; AD follow-up.

 o draft-ietf-cbor-update-8610-grammar-05  - IETF stream
   Updates to the CDDL grammar of RFC 8610 (Proposed Standard)
   Token: Orie Steele

Liz: There are no discusses, unless there's an objection it looks like this one
is approved. Ok, this one is approved. Orie, is this ready to go as is?

Orie: It will be revised ID needed. I would like to see some parts of Paul's
comment addressed in the revision to the security consideration. I don't know
if Paul would like to say anything else.

Paul: No, I just sent Carsten an email saying pick one of the two things you
proposed is fine.

Orie: Perfect. Thanks.

Liz: This document will be approved announcement to be sent; revised ID needed.

 o draft-ietf-rats-eat-27  - IETF stream
   The Entity Attestation Token (EAT) (Proposed Standard)
   Token: Roman Danyliw

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

Eric: I guess AD follow-up to give Roman a chance to do something, right?

Liz: Yes. Ok, not hearing any objections so this document is approved
announcement to be sent; AD follow-up.

 o draft-ietf-dnsop-qdcount-is-one-03  - IETF stream
   In the DNS, QDCOUNT is (usually) One (Proposed Standard)
   Token: Warren Kumari

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

Warren: Five yeses, feels like a record.

Murray: I think eight was the record.

Liz: Warren, is this ready to go?

Warren: I believe it's ready.

Liz: Are you sure? Do you want to mark it as AD follow up?

Warren: Ok, 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-dnsop-zoneversion-08  - IETF stream
   The DNS Zone Version (ZONEVERSION) Option (Informational)
   Token: Warren Kumari

Liz: We have some discusses, do we want discuss it now?

Warren: I would like to discuss these because it feels like very much no matter
which thing we choose for documents like this a subset of people are gonna
discuss and be like 'I don't understand why this is PS when it should've been
informational' or 'I don't understand why it's informational when it should've
been PS.' We had a very similar document where it came in as PS and got
downgraded to informational so I don't understand which way I should be doing
these in the future, and I guess i'm just gonna make them primarily PS because
it's easy to downgrade from PS to info versus another last call. I've had
people complain it's not protocol enough to be PS in the past, that's why we
chose informational. I guess it requires another IETF Last Call and hopefully
it will clear.

John: I'm happy to clear my discuss after this discussion.

Warren: It's a judgment call, but I thought PS originally but i've been bitten
in the past so many times so if folks would like it to be PS and you think it's
PS, I believe the authors are okay with us doing it as another.

John: It just smelled exactly like a PS to me, but seemed like other people
thought so too but weren't willing to go all the way to a discuss. So I did it.
Do you want me to just drop the discuss and you do whatever you think is the
right thing? Or do you want me to hold it for form sake?

Warren: Please hold it for form's sake, I don't remember what I actually need
to do to make it. I guess just ask the authors to resubmit as PS and do another
last call?

Eric: Yes, I think it's cleaner.

Paul: Just for a record, my discuss has been answered and Duane is dealing with
it so we're good there.

Liz: So for this one it will stay on IESG evaluation, do you want a revised ID
on that?

Warren: Yes, revised ID. I need to ask them to submit a new one with PS.

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

 o DNS Delegation (deleg)

Warren: I think we've dealt with Roman's block. I added some milestones.

Liz: Apart from Roman's block, does anyone have anything else to discuss? I'm
not hearing anything so we'll just wait for Roman to clear his block and leave
it where it is for now.

Warren: So I do need to let you know as well, it doesn't automatically happen?
I should still send this is now approved message?

Liz: Yes, please.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 NONE

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Liz: They had an executive session this week, so I don't think they have
anything.

6. Management issues

6.3 IETF 120 Agenda Conflict Resolution (Liz)

The management item was discussed.

6.1 [IANA #1364810] renewing early allocations for
draft-ietf-netmod-syslog-model (IANA)

Liz: This is for one of Mahesh's groups, but Mahesh has already left. Did
anyone happened to look at this or talk to Mahesh about since last week?

Warren: Quick process question: assuming that we don't approve it now, can we
approve it during the meeting in London or can we not do real things?

Eric: What we talked about last time, this should be public discussion and the
retreat is not.

Warren: Us saying yes, this is cool should be public? Ok.

Eric: I think so.

Warren: Does anyone object to this even though Mahesh isn't here?

Liz: This is the third renewal presumably someone had said yes before.

Warren: I'm fine with it.

Cindy: Just a note, if you guys wait to approve it at the next telechat, the
next telechat day is the day it's going to expire.

John: Let's not have it expire just because we can't get around to putting it
on the right agenda at the right time. I don't have an objection to renewing it.

Warren: Going once, going twice.

Liz: Ok, this has been approved and we'll send that official note to IANA.

6.4 [IANA #1366749] renewing early allocation for
draft-ietf-lsr-dynamic-flooding (IANA)

Liz: This is one of Gunter's groups.

John: This is one of my documents though, that document is in the RFC editor
queue now so we should renew.

Liz: We'll renew this one as well and send that note to IANA.

6.5 [IANA #1366921] Designated experts for RFC 9577 (The Privacy Pass HTTP
Authentication Scheme) (IANA)

Liz: This was the item we assigned to Paul at the top of the call.

6.6 Executive Session: IANA problematic submitter (All)

This management item was discussed in executive session.

6.2 Executive Session: IETF 125 Planning (Roman)

This management item was discussed in executive session.

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