Narrative Minutes interim-2023-iesg-01 2023-01-05 15:00
narrative-minutes-interim-2023-iesg-01-202301051500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2023-01-05 IESG Teleconference

These are not an official record of the meeting.
Narrative Scribe: Liz Flynn, Secretariat

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Andrew Alston (Liquid Intelligent Technologies) /  Routing Area
Jenny Bui (AMS) / IETF Secretariat
Roman Danyliw (CERT/SEI) / Security Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Erik Kline (Aalyria Technologies) / Internet Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area
Warren Kumari (Google) / Operations and Management Area
Francesca Palombini (Ericsson) / Applications and Real-Time Area
Alvaro Retana (Futurewei Technologies) / Routing Area
Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area
Sabrina Tanamal (ICANN) / IANA Liaison
Amy Vezza (AMS) / IETF Secretariat
Éric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area
Paul Wouters (Aiven) /  Security Area
Qin Wu (Huawei) / IAB Liaison

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
Martin Duke (Google) / Transport Area
Lars Eggert (NetApp) / IETF Chair, General Area
Sandy Ginoza (AMS) / RFC Editor Liaison
Cindy Morgan (AMS) / IETF Secretariat
Mirja Kuehlewind (Éricsson) / IAB Chair
John Scudder (Juniper) / Routing Area

OBSERVERS
---------------------------------
Lee-Berkeley Shaw
Greg Wood
Oooonduke

1.2 Bash the agenda

Amy: Does anyone want to add anything new to today's agenda? Alvaro, I did see
that management item for your designated expert approvals. Any other changes?

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes of the December 15
teleconference being approved? I'm hearing no objection, so we'll get those
posted. Does anyone have an objection to the narrative minutes from December 15
being approved? I'm hearing no objection there either, so we'll get those
posted as well.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

     o Alvaro Retana to find designated experts for RFC 9303 "Locator/ID
       Separation Protocol Security (LISP-SEC)" [IANA #1241556].
     o Alvaro Retana to find designated experts for RFC 9305 "Locator/ID
       Separation Protocol (LISP) GenÉric Protocol Extension" [IANA
       #1241559].

Amy: These are both on the agenda for approval as management items.

   * OPEN ACTION ITEMS

     o Robert Wilton, Alvaro Retana, and Warren Kumari to report back to
       the IESG on the impact of COVID-19 to the IETF in March 2023.
       - On hold

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-ohai-ohttp-06  - IETF stream
   Oblivious HTTP (Proposed Standard)
   Token: Francesca Palombini

Amy: I have a Discuss in the tracker; do we need to discuss that today?

Francesca: I don't think so. Thanks, Murray, for catching that; I missed it.
Actually, we do need to discuss it since there is a downref that wasn't sent in
Last Call, I want to ask the IESG to approve it.

Paul: That downref also comes in with MLS as the HPKE downref so it should be
added to the downref registry. I'll also put in a Discuss on this. I'm still in
the process of doing this document. I'll file at least one Discuss on the data
type registrations.

Francesca: Okay, sounds good. Thank you for the reviews.

Roman: I concur that we should put it in the downref registry; we're going to
see usage of that document.

Murray: [crosstalk] … used as a standard, basically?

Roman: I feel it is. This is standard CFRG, as in they only put out
informational documents.

Murray: Okay cool, I'll get out of the way.

Francesca: Thank you. As Paul mentioned he's finishing his review and it still
needs a couple more.

Éric V: I promise to try to do it next week.

Francesca: Thank you. I can add it to next time's telechat to make sure we get
enough reviews, if that's easier for people. If I don't get enough before the
agenda is set for the next one I might put it back on.

Paul: One issue I had while reviewing this document, there seem to be a lot of
links to the exact same thing. For example if you look at section 3, that's key
configuration, and I think I already counted 30 links to key exchange in
section 3.1 in section 3, including a recursive link in section 3.1 itself. I
noticed every other word is a link. It would be nice if they could change that,
it's rather excessive.

Francesca: I did not notice that, or I guess it didn't bother me when I read
it. Feel free to add a comment about that. If it stops you from reading
properly then it's worth noting for the others. I usually think the more links
the better, but now that I see it there are many. I think this one stays in
IESG Evaluation for now.

Amy: Do you want it to be AD Followup?

Francesca: Yes, please. Thank you for the reviews.

 o draft-ietf-dnsop-dns-catalog-zones-08  - IETF stream
   DNS Catalog Zones (Proposed Standard)
   Token: Warren Kumari

Amy: I have a couple of Discusses in the tracker; do we need to discuss those
today?

Warren: I think if we can for a short bit. I think the authors have addressed
most, if not all of the comments. They sent around a link to a PR which I think
addresses both things. If Murray and Paul could have a quick look at the email
thread and the PRs and make sure they address their issues, that would be great.

Murray: I saw email from them yesterday and they were still noodling on what to
do about the IANA question, so once I see that I'll respond.

Warren: Oh, you mean the IANA registry thing?

Murray: The bulk of my Discuss was about that. There was one thing about zone
takeovers and I haven't seen anything about that yet but I know they are
thinking about the IANA problem.

Warren: I'd asked them about the zone takeovers and what they'd said offlist
was, we think people should be bright enough to not allow that but maybe we
should put some words in.

Paul: Yeah, I'm just looking for some words. Most of these configurations will
be between primaries and secondaries that trust each other, so that's not a
real issue there. If you're talking about big hosting firms then it does become
an issue.

Warren: Yep; I think there should definitely be some words in there. Whether or
not they'll make any difference, who knows, but it's worth putting in words.
Thank you. Thanks for the review, everyone.

Amy: So that sounds like it's going to require a Revised I-D?

Warren: Yes, thank you.

 o draft-ietf-extra-sieve-action-registry-05  - IETF stream
   IANA registry for Sieve actions (Proposed Standard)
   Token: Murray Kucherawy

Amy: I have a couple of Discusses in the tracker; do we need to discuss those
today?

Murray: Paul's was the newest one and I haven't really thought about it yet.
I'm going to go back to the WG and see what they say. I think we resolve Éric's
by saying it should be PS and we just need to make all the documents line up.
No, I don't need to talk about it unless Paul wants to.

Paul: I'm not set to one or the other, it just seems that since all the entries
are RFCs, why not make the registry RFC required?

Murray. Right. But I think the intent, and this is the part I want to verify,
the intent might be that they want it to be expert review but as it happens all
the nes they're putting in at first have RFCs. I'll figure it out.

Paul: It seems if they want to interop properly, which is what this document is
about, you'd want to have more than expert review.

Murray: I'll find out. I see the point you're trying to make and I'll make them
answer that. So AD Followup, please.

Amy: Great, thanks.

 o draft-ietf-cdni-additional-footprint-types-09  - IETF stream
   Content Delivery Network Interconnection (CDNI) Footprint Types:
   Subdivision Code and Footprint Union (Proposed Standard)
   Token: Francesca Palombini

Amy: I have a Discuss from Lars, who isn't with us today; Francesca, do you
want this to remain in AD Followup until Lars gets a chance to look at the
revision?

Francesca: It should be AD Followup. I don't think the authors have changed
anything. Lars's Discuss was whether this document should also update 9241, and
I don't think so because it's normatively referenced. But I can check with the
authors and WG to make sure this was considered and a conscious decision of the
WG not to update 9241. We'll continue that offline with Lars. Thank you for the
reviews.

Zahed: My read of this one is that it's extending 9241, it doesn't need to
update. I took a look at it because I have some background on the CDNI and this
stuff. My confusion there was that it's extending 9241. It's your call. Or, the
WG's call. This is a [fine] line between extension and update.

Francesca: That was also my view, but I will make sure that the WG has
considered it. Thank you.

 o draft-ietf-lpwan-schc-over-sigfox-20  - IETF stream
   SCHC over Sigfox LPWAN (Proposed Standard)
   Token: Éric Vyncke

Amy: I have a couple of Discusses in the tracker; do we need to discuss those
today?

Éric V: Sure. Lars is not here but his Discuss should be lifted and cleared; it
was that this should be split in two and it's been done. Roman, your Discuss is
being addressed by Sergio, which is quite active. I understand it's not
completely fixed so I assume a revised I-D will be needed. Others have
commented on there being too many authors; that was already explained in the
shepherd writeup because it's a PhD student, his professor, an associate PhD
and a couple of people from Sigfox. That's why we are at six.

Zahed: That's fine; I just missed that line you put in the ballot.

Éric V: Lesson learned for me; I never read the ballot text. I will read it now.

Warren: That raises an interesting point. We often spend a fair amount of time
writing up the ballot text and it seems that nobody reads them. Maybe we should
figure out some better solution or have a way the ballot text shows up more
prominently in the Datatracker or something. It feels like a bunch of wasted
work to spend 15 minutes writing a ballot and it just disappears into the void.

Alvaro: It's interesting that it's called ballot text but it doesn't show in
the ballot.

Zahed: Exactly. I think I had the same part and I think we can do something
better in the Datatracker so at least people are aware of the ballot text since
you don't see it unless you are explicitly looking for it. There should be some
way to expand something and see the ballot text.

Éric V: Maybe on the IESG evaluation page we can put it there.

Warren: There is also a bunch of stuff that's useful to communicate but it's
really useful in the ballot. Stuff where you don't need to write it quite as
formally. Maybe we should revisit or maybe it should be shorter or more of a
checklist? Anyway.

Zahed: Something for a retreat, perhaps.

Éric V: A couple of comments were about the Sigfox technology itself, what
about the security etc? A valid point but the charter of lpwan clearly says we
need to deliver SCHC for Sigfox. I don't think it's really up to the IETF to do
some consideration over the Sigfox technology itself. So roman, do you agree
that your Discuss is not yet addressed? Sergio will address it and then we can
move forward.

Roman: There's a missing reference somewhere that all the reference documents
and this text says exists and I just can't find it. We should reference it
because it's the basis of the algorithms that are being used.

Éric V: Fair enough. This will obviously stay in IESG Evaluation, Revised I-D
Needed. Thanks for all your reviews.

 o draft-ietf-avtcore-rtp-scip-04  - IETF stream
   RTP Payload Format for the Secure Communication Interoperability
   Protocol (SCIP) Codec (Proposed Standard)
   Token: Murray Kucherawy

Amy: I have a couple of Discusses in the tracker; do we need to discuss those
today?

Murray: No, I don't think so. I haven't seen Zahed's yet but I'm scanning it
quickly. I think I'll just give the WG a chance to answer this before I say
anything, so you can just do AD Followup. Unless Zahed wants to talk about it.

Zahed: My Discusses are more like things we look at like congestion control and
the specification. The intention is that someone would read this and understand
the format and be able to implement that and there are some confusions.
Sometimes it says it's variable and sometimes it's a fixed rate. These need to
be cleared up. I'm kind of really worried about one thing, AVTCORE has a lot of
transport background people and they usually do this kind of format. A couple
of things like the congestion control was completely not  there and nobody
cared about it in the WG? That made me think, okay, are we doing the right
thing here. I just wanted to recheck. I also saw some tsv-art review that was
not incorporated so I want to make sure we don't miss that.

Murray: That's all good. We could have a chat at some point. Should we have
someone, it doesn't have to be you but a transport person, be an advisor to
this WG to be more directly involved in reviews? If this is a WG that should
more formally straddle my area and yours, we should make that clear to the WG
and in the Datatracker.

Zahed: Let's talk about it.

Roman: Murray, one thing I can appreciate when I'm going to interact with the
authors is I'm trying to understand  what it takes to write up a payload
format. I know there's this desire with 7202 to draw this line between giving
you the format vs. like, not the application description of the security
parameters. And there's' this line drawn that in certain cases is clear when
you know what the codec is. I feel like what's different with SCIP here is that
they're saying the security properties are baked into this opaque blob that is
the payload and I'm not sure where the line gets drawn between the payload
format and getting into the business of the codec or the application. I feel
like this one is different from h264 or any of the other examples I could find.
How does that work in the WG?

Murray: I've seen them in their answers to you pushing back. There's a border,
an interface line, it's like TCP takes care of retransmission and we don't want
to talk about that. They're really trying to hold that line. I think the
question is valid, so we can go back to them and say we're not clear on this.
We should push them to be more solid in answering.

Roman: I just want us to be consistent in however we're going to be specifying
these payload formats. All I had was the history of going back to the old ones.

Zahed: Roman, I agree with you. This is not the typical video codec format
we're talking about. That's my problem with this document, it's not clear to me
if it's different or the same. It says I'm using h264 and also this other thing
and also this other thing. It's hard to see how this becomes a codec. Some
discussion around that would be helpful.

Murray: So, AD Follow Up please.

Amy: Okay, this stays in IESG Evaluation with AD Follow Up.

2.1.2 Returning items

 o draft-ietf-6lo-nfc-19  - IETF stream
   Transmission of IPv6 Packets over Near Field Communication
   (Proposed Standard)
   Token: Erik Kline

Amy: This was last Last Called in 2018 so it's been around a while, and I have
a number of Discusses.

Erik K: I think the author has been responding to most folks. Most of the
Discuss comments seemed to be addressable. I guess I'll start by asking Roman
if he thinks the access to this NFC authentication protocol was satisfactory?

Roman: Maybe I missed something. I thought the authors told me I can't have it.

Erik K: I thought he sent it to you. Let me see if I can find it.

Roman: Because I think there were two documents. There's the NFC spec itself
which you got to all of us, which is super, but that spec references another
one with additional details and that's the piece I was interested in reading
because some of the security properties in the base spec relied on the
dependency document.

Erik K: He said it was difficult to get access to but I thought at one point he
attached it. He did actually, on January 1.

Roman: Okay, I missed it.

Erik K: Understandable, it was on New Year's Day. It's a candidate protocol
from December 2020.It's not terribly long. Maybe if you have a chance to have a
look at that and let me know if it's satisfactory? I think the rest of the
comments are actually things the author can address. They had been replying bit
by bit.

Murray: I have a wider question, of which document is one of 2 on this topic.
This is the thing that we're doing this status because 3GPP asked us to. Paul,
I think you made the same comment about a different document.

Erik K: You're thinking of the DMM document. This is NFC.

Murray: Sorry, I lost my place.

Erik K: I don't know if anyone else has anything to go over at this time.

Éric V: My Discuss points have been addressed by the authors and I'm just
waiting for the revised I-D to clear my Discuss. Very responsive authors.

Zahed: My Discuss was about a good point made in the TSV-ART review and no
discussion I could find. I reviewed and looked at the TSV-ART review and
thought they were valid questions. So that's just a placeholder for those
concerns raised there and if they decided not to do that, I'd like to know how
they decided not to address those things.

Erik K: You were right to catch it and I think it's just that it's such an old
document.

Zahed: I wasn't sure if it was an oversight or a disagreement but they were
good points.

Erik K: Absolutely. Revised I-D Needed, obviously.

 o draft-ietf-homenet-front-end-naming-delegation-25  - IETF stream
   Simple Provisioning of Public Names for Residential Networks
   (Proposed Standard)
   Token: Éric Vyncke

Amy: I have a couple of Discusses; do we need to discuss those?

Éric V: I think so, quickly. Thank you for rereading this; as you see I opened
another ballot because I believe readability and clarity has been improved a
lot. Some points I want to make. Maybe Paul refers to the dynamic DNS dot org
and other dynamic DNS providers, but those are only for the forward zone. As
far as I know none of them are forwarding doing the reverse zone. Right? And
many may say, what's the point, it's the usual hidden primary DNS server.
Except the hidden primary server in this case is handled by your home, and not
by another entity, then the DNS or sourcing infrastructure. And HNA quite often
is a dynamic IP address and sometimes it's not. So it makes things a little bit
more complex. Basically, Paul, your Discuss and again, thank you for rereading.
It. There are many valid points. I think they will be addressed and because
they are easy to address as, you know, but basically the core of the discussion
is whether it should be experimental or proposed standard. I mean, Experimental
is easier. Proposed Standard, why not? Some Proposed Standard documents also
took more than 10 years to be specified and I'm not sure all the Proposed
Standards are implemented widely over the Internet, but I have no data either
way. Is it the exception or is it the rule? Because most other standards are
implemented, I guess, but this could be an exception.

Rob: My only comment on this was really about whether we have an expectation
that people should and can deploy this. As in, does it make sense for people to
migrate to this or is it more documenting an idea that was thought about but is
not expecting the world to move forward and implement? That was where I was
coming from as to whether it should be Standards track or Experimental. You
probably don't know that either; none of us have crystal balls. I'm not sure it
really matters.

Warren: I still don't really think it's implementable from the document. I
Think it's more of a high level architecture/… [cut off]

Éric V: Even with the -25?

Warren: I've had a bunch of discussions with Michael and I'm trying to remember
who else. There's a lot of hand wavy you can make this do stuff if you have a
bunch of guesses as to how things might fit together.

Éric V: Still in the -25? I really thought they were dotting the i's and
crossing the t's.

Paul: It's more clear what is outside the scope of the document but it's not
clear how you would attach those out of scope things to the document. How do
you configure the name service of a public DNS zone somehow with the HNA and
how do you connect with the CPE? There are still some unknown parts in there.

Éric V: I can understand. This is coming from homenet so they see the CPE and
not so much the other DNS infrastructure. I think that's a fair comment.

Paul: The v6 one I think is the only one where it's fairly clear, but it's
either the CPE is pre-configured by the ISP and it's all under their control.
That one I can see being fully implementable. But that's the only one I can see
where there are no questions on how you convey the domain name you're going to
use.

Warren: It also seems like if it's ISP provided CPE, the ISP could use a bunch
of much simpler solutions instead of delegating this down. They could do stuff
like NS update type updates instead. If I was an ISP this is not the sort of
thing I would want to deploy in my CPE because it seems wildly complex. If it's
not an ISP operated CPE then what Paul said doesn't apply.

Éric V: I got the point. I really wanted to say that it's not a replacement for
the Din-DNS part. Whether it's complex is a different story.

Paul: The question becomes, there's a claim that 3GPP might use this and for
that it needs to be Standards track. Do we care enough about this being
experimental or not? On the one hand I don't really like making it standards
track just for 3GPP, but I also don't think we should put a spoke in the wheel
just because of the words on the top of an RFC.

Éric V: My major concern is to please the Homenet WG and after [this], close it.

Zahed: On the 3GPP side, if I may comment on that. If there is some sort of
thing like Ellis coming to us and saying this is needed in a certain way, I
think we should do that. If some of us from the IETF say we need to do
something in a PS to make an impact on 3GPP, that's a different story.

Éric V: Yes, that's different.

Zahed: If there's something on the 3GPP level where we can refer to that, we
should do it, but I don't know if there is.

Warren: Following on from what Éric said about keeping the WG happy, as much as
I dislike this and don't really think it's likely to be used, the authors have
been incredibly responsive and helpful and polite in addressing some fairly
grumpy comments. It feels like maybe PS is reasonable. If people put in a huge
chunk of work, and the WG thinks it's PS style work, it is just words on the
header of a document and it doesn't really change the world if we say
Experimental or PS. Even though I still think it's not particularly useful, I
think PS is fine.

Murray: One thing I was talking about in my Discuss is that this feels a lot
like what we call an applicability statement, which is basically here's a
profile of how to use DNS to achieve a certain thing, or if you use it a
certain way you get these capabilities. If they're willing to call it an
applicability statement, 2026 says those are proposed standards. If they're
willing to take that path they can justify PS that way. It's unfortunate that
the shepherd writeup just says PS and not why. It's a bad habit people have for
smashing through that and this is one of those cases where recording that
discussion would be really valuable. My Discuss brings this up but like I also
said, I'm not insisting that there be implementations to justify the PS, I just
wanted to ask the question here what was the thinking behind this. Having had
this discussion I'm happy to get out of the way. There is a path for them to
get PS and justify it if they want to do that.

Éric V: That's a good idea, Murray.

Paul: Same for me. I just wanted to have it discussed, I'm not blocking it from
PS.

Éric V: Very valid Discuss points that need to be addressed anyway. So it's
both AD Followup and Revised I-D Needed, I'm not sure which is the winner
though. I'll come back to you if we downgrade to Experimental or use Murray's
idea.

Amy: If it requires a Revised I-D I think that one wins out, so we'll put it
there.

2.2 Individual submissions
2.2.1 New items

 o draft-moskowitz-ipsecme-ipseckey-eddsa-09  - IETF stream
   EdDSA value for IPSECKEY (Proposed Standard)
   Token: Roman Danyliw

Amy: I have no Discusses in the tracker, so unless there's an objection now,
this one is good to go.

Roman: Big thank you to everyone for the reviews. I've checked the comments and
I think this is ready to go.

Amy: Not waiting for notes or a final check or anything?

Paul: The comment I left has been addressed in -09.

Amy: Terrific. We'll put this in Approved, Announcement to be Sent.

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-dmm-srv6-mobile-uplane-23  - IETF stream
   Segment Routing IPv6 for Mobile User Plane (Informational)
   Token: Erik Kline

Amy: I have a Discuss in the tracker; do we need to discuss that today?

Erik K: I think probably the Discuss and some other meta comments if we have
the time. Éric, your Discuss is about the shepherd writeup?

Éric V: Yes, I would love the writeup to be consistent with the metadata.

Erik K: I think the shepherd just put a new block at the top rather than
rewrite everything within the writeup.

Éric V: Okay, maybe my bad. The other point is basically more textual, but very
easy to fix. It talks about a gNB, and I know what that is, but it should be
clear in the document.

Erik K: Thank you; I think everything else is pretty clear. I have not seen any
of the authors replying yet; maybe just holidays. Except maybe we should talk
about Alvaro's comment? I guess the surfeit of No Objections means maybe it's
okay to proceed, but at a meta level, is this a big concern?

Alvaro: It's a concern to me, but that's why I'm abstaining. My point is that
SRV6 to replace GTP-U was taken to 3GPP years ago and they said no, we don't
want to do that, and here we're telling them this is how you can do it,
regardless of whether it's PS or informational, it's an IETF document and it
just doesn't feel right to me because they have said they don't want to do
this. That's why I'm abstaining. It seems clear that the WG and maybe a bunch
of you guys think it's okay. I get it.

Zahed: Can I say something about that? The thing is, I think Alvaro, your
concern is valid. This is the same document that wanted to have a PS before,
right? And then it came to Experimental. There we had a talk. PS is a step in
saying here's how you do the thing, and then when you talk with other chairs
they think this boat has already sailed. Whatever you do here isn't going to
impact anything. That's why I'm not Discussing it, but I still feel like this
document lacks motivation. It talks about scalability and all these things but
it doesn't say what the problem of the current system is. Then you have to
really dig down into the architecture and say what the hell is wrong with those
things. I think, fine, if you want to do this document, but it doesn't really
help. I'm not Discussing or blocking it but I think it's fine if it's
informational.

Roman: I'm with you, Alavor. I'm a little concerned we're giving something to
another standards organization that they don't want. I just didn't know what
the blocking Discuss criteria was for that. It does have consensus, we say we
want to give it to them….

Alvaro: Regardless of this document, you asked a question on email, Roman, if
there's precedent to make a decision on stuff like this. I Don't think we the
IESG have agreed on anything but there is a precedent that we've turned work
down because another SDO said they didn't want it. We could have already done
it. Also, I think it goes both ways and it's bigger than this document. Publish
this, I don't care, but we complain when other people say they want to do
something to our protocols. IP, there's that MC TLS thing that came up a few
years ago; we complain when they try to do stuff to our stuff. Here we are
doing stuff for them. Doing them the great favor of what they can do with their
architecture. It just doesn't feel right to me.

Roman: I agree, that's compelling. I hadn't even considered that. I thought
what you were saying was compelling before but the way you just framed it when
people do it to us. I agree we should have some consistent way to reason about
this.

Erik K: That was the core of Joel's objection and the reason he opposed PS
status. He said as soon as it was downgraded to informational he still opposed
it but didn't think there was a procedural argument to stand on at that point.

Alvaro: Except that no one knows the difference between informational and PS
except us, and all informational documents are consensus documents. Even if
they're informational it's the IETF saying this is what we believe. We agree
that this is a right thing to inform you about. It is better than telling you
we standardized this for you, but we agree that this is a nice thing to do for
you.

Erik K: It's complicated by the fact that this document is actually three
different behaviors, one of which is perfectly fine to standardize because it
doesn't touch the 3GPP stuff at all. It just magically rewrites stuff in the
wire in between and unrewrites it before it gets anywhere else. It's like
converting all of your data center traffic to Apple Talk and back without
anybody needing to know about it. But then these other 2 methods have more
consequences. Does anybody want to change their ballot position? This document
has been around for a long time. There are implementations.

Alvaro: A lot of people complain that us in the IESG throw a lot of stuff at
them at the very end. Again, this is why I'm abstaining, because also I
couldn't find a discuss criteria to say no. We can't just at the very last
second say we really care about this inter-SDO thing so we're going to say no.
but I think we should talk about this in the bigger context and either put out
a statement or in the wiki or something about what we should do going forward
and let chairs know so that if work comes in, we're not going to be discussing
this at the very end.

Zahed: I really would love to have this kind of consensus or something written.
This has been a case in different places. We talked about this with NFC and if
there was any LS with 3GPP. If we produce something, is it really useful to the
other SDO? We don't know how to use that. When it comes to inter-SDO it has to
be mutual benefit. They should be asking for something or needing something to
fulfill their protocol requirements. But there's not a Discuss criteria and I
felt like this document lacks serious motivation.

Erik K: At some level, IETF documents are for the IETF community. If it's
informational to the IETF community and how they could run their 3GPP network.

Zahed: One thing I didn't really understand during this whole process of
discussion of 3GPP. There's some part of the document that doesn't touch 3GPP;
why don't we take that one and make it a standard?

Erik K: I believe at many points they had opportunities to separate the
document. I believe it was pointed out to them that they could even pull out
one behavior and send that PS and put the other two behaviors on the ISE track,
since the whole numbers base for network programming code points is first come
first served. They seemed to try to keep the discussion and behaviors all
together in one. I guess what I'm wondering is should I go back and tell them
they need to split up their document into two or three? I think it used to be
two and they've squashed it into one.

Zahed: I don't think we should spend any more cycles on this one, so no for me.

Warren: as a meta observation, we do seem to spend a fair amount of time having
these situations like "Other SDO wants this sort of thing from us" and often
when we have these discussions we have heard rumors that another SDO wants
this, but we don't have a clear understanding of exactly what, how, and who. It
feels  like something's not working hugely well in the liaison relationship
between us and some of the other SDOs. We run around like chickens trying to do
something for other groups. It feels like there are odd interactions where
we're bending over to help other folks without clear understandings. Maybe
that's a retreat topic.

Erik K: Based on what Zahed was saying it does sound like this is a retreat
topic.

Roman: I strongly concur with this as a retreat topic.

Warren: It also seems like there's a fair bit of stuff in 3GPP that doesn't
really follow IETF ethos, or architectural design, but when we have a feeling
they might want something we try and solve it for them. It feels not quite one
sided but that more understanding and discussion and back and forth [is needed].

Zahed: There is something going on. I'm not super unhappy about it but there is
opportunity to improve. And now I need to leave.

Erik K: I guess this will be Revised I-D Needed.

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 o draft-davies-int-historic-05  - IETF stream
   Deprecating infrastructure "int" domains (Informational)
   Note: [ This IESG note to be removed before publication: The Status
   Change document
   (https://datatracker.ietf.org/doc/status-change-int-tlds-to-historic/)
   was approved, but the responsible AD (Warren Kumari) is holding it
   until *this* document is approved. This note is a (probably futile)
   attempt to remind him to release the status change when
   draft-davies-int-historic is approved. ]
   Token: Warren Kumari

Amy: I have no Discusses in the tracker, so unless there's an objection now,
this document is approved.

Warren: I'm glad this note reminded me and you about the status change. Thanks
everyone, I'm so happy this is done. To IANA, sorry this took so long.

Roman: Thanks for doing it, Warren.

Amy: So this is now waiting for nothing and it's ready to go, as is the status
change. No notes, everything is good?

Warren: Ship it.

Amy: Okay, this will be shipped on Monday and it's in Approved, Announcement to
be Sent.

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

 o Post-Quantum Use In Protocols (pquip)

Amy: It looks like we have a couple of blocks. Should we discuss today?

Roman: Yes, I'd like to discuss a little bit. As hard as PQUIP is to pronounce,
the alternatives were worse. I got a lot of feedback on two different threads,
which was a little bit of how did we get here, and how is this different than
CFRG? The first thing  I'd like to point out is that Warren hinted at this; the
intent of this WG is entirely like MOPS. If careful readers put the text side
by side they'll see the MOPS text was cribbed significantly on style and tone
and the way the WG will operate. The substance of a number of blocks was what
about CFRG? I put some additional changes in text, please review that. The
relationship with CFRG is going to be the same as all other WGs. There's no
cryptography experience in the IETF and we get it from outside; CFRG is one of
those places and we'll continue to rely on CFRG for their cryptographic
assessment, advice, and specification, along with other entities we work with.
Is that sufficient to resolve concerns?

Paul: We won't know from Lars, because he's not here.

Roman: Right. Maybe I'm staring at Zahed most. Oh, he left.

Warren: I cleared my block. We should come up with a name for things that are
similar to MOPS. I would have been fully on board [if I'd understood that]. I
changed to a Yes.

Roman: I'll confess I didn't understand so much when you were pitching MOPS,
Warren, and then I understood going through it myself. It is a different style
of WG than we're used to. Are there others that made the comment about CFRG
that don't get it, can I help talk you through it? [silence] Okay, we'll wait
for Lars to get back from vacation. One other change that's happened, I named
the other chair so it's going to be Sofia Celi and Paul Hoffman if this comes
to be. Thank you.

Amy: We'll wait for instructions from you, Roman.

Roman: I'm waiting for a response from Lars and then I'll let you know what to
do.

 o Domain Keys Identified Mail (dkim)

Amy: This is the reanimation of the DKIM WG that closed about ten years ago. I
have no blocking comments for this to go for external review, so unless there's
an objection, it looks like this is ready for external review.

Murray: With the exception that I need to add milestones. I managed never to do
that on a first pass anyway so it will have them. Do I need ten ballots to get
this through or is it just no blocks?

Amy: It's just no blocks.

Murray: Then this is ready to go to the next state. I have some tweaks and
milestones to add; should I just move it to the next state when it's ready?

Amy: Do you want us to wait until you have milestones for external review?

Murray: Yes.

Amy: Then just drop us an email and let us know [when you're ready]. This is
approved for external review pending addition of milestones.

4.1.2 Proposed for approval

 NONE

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

Amy: I believe the IAB has been off for three weeks, but is there any news?

Warren: No news.

6. Management issues

6.1 [IANA #1241556] Designated experts for RFC 9303 "Locator/ID Separation
Protocol Security (LISP-SEC)" (Alvaro Retana)

Amy: Alvaro has identified Damien Saucez and Luigi Iannone as designated
experts for this registry. Any objections to approving them? Okay, I'm hearing
no objections, so we'll get that official note sent to IANA.

6.2 New Designated Expert for IANA Media Types Registry (Murray Kucherawy)

Amy: Murray has identified Darrel Miller. I believe this is for the general
media types; are you including him with Alexey and yourself?

Murray: Ideally he'll shadow us for a little bit and then I'll stop, because an
AD shouldn't be doing them. I've just been doing them in a pinch because we're
down to one person. Alexey met with him and gave him the lay of the land and
the process and typical gotchas we find, etc. It looks like he's ready to go.

Amy: Great. Is there any objection to approving Darrel Miller as an additional
expert here? I'm hearing no objection, so we'll send an official note to IANA
adding him to the pool.

6.3 [IANA #1241559] Designated Experts for RFC 9305 "Locator/ID Separation
Protocol (LISP) GenÉric Protocol Extension" (Alvaro Retana)

Amy: Alvaro has identified Darrel Lewis and Luigi Iannone as the designated
experts for this registry. Is there any objection to approving them? I'm
hearing no objection, so we'll send the official note to IANA.

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

Warren: I have a question; is there any news on the NomCom stuff?

Amy: We need to do an e-vote to approve the IESG and I know Lars sent something
to the IESG-only list. Since I can't know the names, I think it needs to come
from one of you, and I can't send to the IESG-only list.

Francesca: I have some WG news to share. WPACK is most likely going to shut
down soon. The WG has been dormant and basically the only author is not
involved anymore, so I'm getting ready to close it.