Narrative Minutes interim-2024-iesg-02 2024-01-18 15:00
narrative-minutes-interim-2024-iesg-02-202401181500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2024-01-18 IESG Teleconference

These are not an official record of the meeting.
Narrative Scribe: Jenny Bui, 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
Dhruv Dhody (Huawei) / IAB Liaison
Martin Duke (Google) / Transport Area
Lars Eggert (Mozilla) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat
Sandy Ginoza (AMS) / RFC Editor Liaison
Jim Guichard (Futurewei Technologies) / Routing Area
Mahesh Jethanandani (Arrcus) / Incoming Operations and Management Area
Murray Kucherawy (Meta) / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Applications and Real-Time Area
Zaheduzzaman (Zahed) Sarker (Nokia) / Transport Area
John Scudder (Juniper) / Routing Area
Orie Steele (Transmute) / Incoming Applications and Real-Time Area
Sabrina Tanamal (ICANN) / IANA Liaison
Gunter Van de Velde (Nokia) / Incoming Routing Area
Éric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area
Paul Wouters (Aiven) /  Security Area

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
Erik Kline (Aalyria Technologies) / Internet Area

OBSERVERS
---------------------------------
Deb Cooley
Greg Wood

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

(crosstalk)

Liz: Ok. Got that AOB from Warren. Eric?

Eric: And my only thing is we should congratulate ourselves on the number of
erratas that we fixed in the last week. Thank you.

Liz: Yes, round of applause for everybody.

Sandy: Just on that one, I failed to send it yesterday, but just sent the
numbers for erratas. The reported erratas that are technical and to me, what I
see is that the larger parter of the backlog is really the editorial erratas so
we'll be working through more of those each week

Eric: Thank you, Sandy.

Warren: And thank you everyone, who raised this as an issue and started stuff.
I think that we're all a lot happier, or at least I'm a lot less stressed and
happier now.

John: I think it was Lloyd who poked us to begin with, so maybe i'll reply back
to him.

Paul: So now we've done ten percent, I guess we can wait again until next year.

Eric: Specifically on the eighteen of January, we can for another year, right?

Paul: We all declare victory and go home.

Warren: Just wondering who all here are going to be like "Well, i'm not running
again", so it's not my problem.

Lars: Although for those not running again, there's something else to do which
is to clear their discusses and empty their queues.

Paul: This is also a good thing to do if you are running again.

Lars: Sure. You can clear your own queue for yourself which is always a good
idea, but specifically, I think for somebody else, it's very nice if you do.

Rob: My aim is to try and get my queue down and before handing it over to
Mahesh.

Warren: And thank you. You're making a huge, you shamed me to doing a bunch
because I keep seeing "Rob closed an errata".

(crosstalk)

Andrew: My sincere thanks to John and Jim for helping me out with the erratas
stuff during my medical issue, so my thanks to them because they have stepped
in and helped out.

Warren: This meeting is a love feast, a little odd.

Lars: Quick, Liz, jump in here's your chance.

1.3 Approval of the minutes of past telechat

Liz: Does anyone have any objections to the minutes of the January 4th
teleconference being approved? I'm hearing no objections so those are approved,
and we'll post them in the public archive. Does anyone have any objectives to
the narrative minutes of the January 4th being approved? I'm hearing no
objections on these either, so we'll get those posted.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

     o Roman Danyliw to find designated experts for RFC 9447, ACME
       Authority Token Challenge Types" [IANA #1281679].
     o Roman Danyliw to find designated experts for RFC 9493 (Subject
       Identifiers for Security Event Tokens).

Roman: I have two actions items related to finding designated experts. I'm
having some difficulty narrowing this one down. I am not getting responses. I
know Deb's on the line. We're gonna probably have to work on an alternate plan
because I'm not pulling from the right folks and then for the other one,
related to SEC events, we have that as a management item.

     o Robert Wilton to find designated experts for RFC 9487 (Export of
       Segment Routing over IPv6 Information in IP Flow Information Export
       (IPFIX))[IANA #1287238].
     o Robert Wilton to find designated experts for RFC 9456 (Updates to
       the TLS Transport Model for SNMP)[IANA #1287239].

Rob: These are both actually in progress.

   * OPEN ACTION ITEMS

     o Warren Kumari to follow up on a bis document for RFC 8126 regarding
       designated experts.

Warren: What's his name can chime in on here, if he's on the call. He spoke
with Barry last. Still in progress but it's not only me that's poking him.

Murray: I don't know at which point we should call and say we're gonna find
another author. That's kind of up to us right now. Still in progress, I agree.

Warren: I think we have agreed during the Prague IETF that if it wasn't done
within the thirty days of the end of the Prague IETF that you and I were just
gonna do it.

Murray: Maybe we should.

Warren: Maybe we should just do it.

Liz: Do you want us to update this action item at all or just leave it how it
is?

Warren: Can you update to say “Murray and Warren Kumari to update the bis
document”.

Liz: Sure. No problem.

Murray: Just put my name on everything.

     o Andrew Alston to email the RSWG regarding document authorship/
       editorship with regards to the number of authors listed.

Liz: Andrew said before this call that this is in progress.

Andrew: Yes.

     o Lars Eggert 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.

Lars: In progress.

     o Francesca Palombini to review and merge updates to the wiki page
       "Getting a Document on the Agenda."

Liz: She has proposed updates to that and we're going to be talking about that
in the management item at the end so this one will hopefully be done very
shortly.

Francesca: Right. Thank you.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-kitten-krb-spake-preauth-11  - IETF stream
   SPAKE Pre-Authentication (Proposed Standard)
   Token: Paul Wouters

Liz: We've got a discuss, do we want to discuss that today?

Paul: I think Murray wanted to lead the discuss part of it today.

Murray: Eric was the first to point out and I agree there's a bunch of stuff
that this is like a four year old shepherd write up. It doesn't use a proper
template. It seems to have sat there for a long time and then just resumed from
where it was. Maybe that is all OK because actually nothing important happened
all that time, but it did raise some eyebrows. Is this something something we
should fix or are we OK with it the way it is?

Paul: So I'll give a little bit of history. Actually Ben had raised issues in
his AD review during last call, I think even so he's sat on as an AD for a
while, and I inherited this document in this state like two years ago, and so
I've been pushing to get the two Kitten documents that were in hundreds of days
of weird state to get out of them. So one of them, I returned to the working
group after talking to the chairs and funny enough now Ben Kaduk is the chair
of Kitten. One of the two, so I gave that back. The other one basically then
came to the conclusion that indeed there was no changes needed anymore. So the
only thing that happened since the document sat on the queue was that the 
document went through our CFRG and did become an RFC; it already deviated
slightly from the implementation that CFRG wants. Even two years ago, they
already deemed that they deviated from the draft and it was just not referred
to that draft, but referred to the original paper and I added this note to the
ballot text, which probably nobody read.

Warren: Thank you. I converted from abstained to no objection.

Rob: The key question is, could the consensus of the IETF changed between that
point and now, realistically.

Paul: I don't think so. First of all, Kitten is extremely dormant as a working
group, but second of all I believe this also has been implemented, and so the
implementation is preventing for a while now, so you can't even really change
anything to it, even if you wanted to.

Murray: I'm looking at the diff between -06 and the current one is -11, -06 is
the one about which the shepherd write-up is done.  I don't have a good feeling
for whether there are a lot of changes, but I don't have a good feeling for
whether they were substantial or change would, if the shepherd, if he or she
were to take another look. So that's kind of where I decided that we should
probably chat about this. It sat like you said for several years and there are,
there's what looks to me like a significant amount of text change. So, and some
of it has normative stuff in it so that's why I wanted to chat. I'm happy to
get out of the way of this. If if you're fine with all these changes that have
happened, since the shepherd write up and that the shepherd write up refers to
the earlier of those versions, that's what I wanted to verify.

Paul: Those have gone through the chairs and the then ADs, right? And again,
like I said Ben is still the working group chair so we can ask Ben.

Murray: Ok. Thanks, i'll get out of the way.

Eric: By the way, may we suggest that everyone when we are doing this similar
situation, that we force a shepherd write-up refresh? Because for the shepherd
write-up, you can have the shepherd taking a vacation. It's like sheep, it's
not when they are getting out of the band and it is done, right? You need to
bring them to the fields.

Andrew: I agree with Eric. It's something that i've done with all the documents
in my queue. I try to get the shepherds to update them before I move them
forward.

Paul: That's fair. I can see if I can ask the shepherd. I'll double check with
the shepherds again, but they might have touched this in like the last 4 or 5
years, and just left the whole Kitten area, so i'm not sure how active they are.

Eric: That's an issue. I understand that it's not an easy task to do because
you become a shepherd as an AD.

John: I mean anybody with permissions can update that write-up. So like any of
the chairs can, or the ADs can. To me, it seems it doesn't matter so much about
updating it now because we've already had this conversation and in my mind, at
least the shepherd write up is the thing that I always look at. I don't always
look at ballot text. I almost always look at the, at the actual ballot, so like
the three places to expose these kind of things like you said, you mentioned
it, in the ballot text, to stick it into the yes ballot, and I probably would
have noticed it there or to stick it into the shepherd right up and I probably
would have noticed it there.

Paul:I'll next time I'll consider using my ballot text for my yes, but I
actually never thought about that, but I guess more visible than me putting
stuff in the ballot text.

Eric: Because you are too lazy, right? So let's be clear. it's not because you
did something wrong just because we are lazy or the other ADs, right? Not me.

Liz: Murray removed his discuss so now this document can move forward. Paul, do
you want to keep it in AD follow-up for a little while?

Paul: Based on the comments, it's going to need a revision so just put it in
there. Revision needed. I'll try to update the other parts.

 o draft-ietf-lamps-rfc8399bis-04  - IETF stream
   Internationalization Updates to RFC 5280 (Proposed Standard)
   Token: Roman Danyliw

Liz: There are no discusses in the tracker so if there's no objection now this
document is now approved.

Paul: I do want to note that Russ did comment back on the, on the boiler plate
and he did also propose to put back the original boiler plate. If we can do
that before publishing a document out, that would be great.

Roman: I appreciate everyone's feedback. Murray and Orie could you help me
understand what you're saying? I'm not quite smart on all of IDNA and all the
internationalization issues. What are you asking for in terms of clarifications?

Orie:  For my comment, we had a document go through UTA a little while ago and
that document had this question on how do you refer to IDNA and it raised this
issue that, what’s the WG spec for Urls? Uses UTS 46, which allows emojis and
if you look at what WG URL spec, they have this nice text block that just says
this domain name with an emoji, it doesn't produce an error because we use UTS
46. I don't have an opinion on what decision should be made in the given
document. I just like how simple and clear that sort of messages in what WG
spec because it just says there is no error for this interesting strain case
and I think if we were to leave the document exactly the way as I read it
instead, you would have an example like that, and it would say this produces an
error. I don't know. That's the comment, basically just because I saw this like
spend a bunch of cycles in UTA and it's related to internationalization and I
had to read all of that then I'm just surfacing it now because there seems to
be contention over, what the web platform considers an internationalized domain
name and what IETF sort of tends to consider, which is IDNA2008.

Warren: I'll happily note that I stopped reading the document and missed any
mentions of emojis.

Orie: There isn't any, so this is the first thing I searched for, and it was
our emojis and then I searched for UTS 64, and I think the other document in
the unit took a similar approach of just sort of not mentioning it and that's
fine. My comment was just to surface that seems to be the convention we're
following here.

Warren: I'll just add the reason is ICANN SAC (Security Advisory Committee)
published an advisory about the fact that emojis and domain names are bad mojo
and should not be allowed as TLDs or should not be allowed within TLDS. I can't
remember the exact wording, but if there was a mention, I figure it should cite
that as well, but seeing as there isn't, I'll rollback under my rock.

Roman: Why don't we do the following things because I can't adjudicate all of
this in real time. So why don't we put this document approved announcement to
be sent AD follow up and we'll take this to the document authors and the
working group to polish what would be the exact precise thing to potentially
say, and what would be the set of references we would want to make sure we have
and that I think covers what you are suggesting, kind of, Warren.

Warren: I think mine is not actionable.

Roman: Because there's not something published, is that right? Maybe I
misunderstood.

Warren: Sorry, apparently the document itself doesn't mention emojis. If it did
mention emojis, then I would say we should cite this thing seeing as it doesn't.

Orie: Just to be clear, like my comment was just to surface that I've seen this
discussion happen before, and as I read the document, there's a category of
what would be considered an acceptable domain name in the web platform that you
couldn't use this document with. That's fine, I would just prefer to see
something like a one sentence that says you can't use this document with these
things like that just is easier for me as a reader of a document, but, whatever
the typical way this is resolved, that's how it should be handled.

Roman: I'll put it into AD follow up and we can talk to the working group about
how to provide this clarity. Thanks for the review.

Liz: Thanks everyone. So this document will go into approved announcement to
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-emu-aka-pfs-11  - IETF stream
   Forward Secrecy for the Extensible Authentication Protocol Method
   for Authentication and Key Agreement (EAP-AKA' FS) (Informational)
   Token: Paul Wouters

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

Paul: Sure. I'm not sure, Murray, if you've seen Yari's reply but it was more
or less of like these are updates to original documents that were also not
proposed standards or we're just doing an update and so we're keeping the same
status.

Murray: He said the same thing in the shepherd write up and I don't think that
satisfies what I'm trying to get at. I understand that they were originally
informational. I don't think they should have been. I think that you have a
technical specification, you should put it in the right status. I don't know
why it was an informational to begin with, but is there any harm in upgrading
them now?

Francesca: I talked to Yari, so I've have a little bit more history about why
it was informational. I think the original document which was 5448 was AD
sponsored and it was as informational and it felt a bit more out of the
mainstream. They didn't think it needed to be proposed standard and then 9048
which is the other document that this draft updates, it sort of an update to
that one. They worked on things like security consideration and stuff that felt
like was missing 5448, but they still did it informational because that one was
informational but 9048 could be, according to Yari, could be a proposed
standard. So if we wanted, if we wanted to go to the proposed standard route,
we should probably do, like I said, status change to 9048 but if one of the
authors doesn't feel like 5448 could go the proposed standard route. If we want
to make this one proposed standard then we need to make 9048 proposed standard
as well, right?

Murray:  I have a bad feeling when I see this wasn't done right in the first
place, and then it just creates this cascade of let's do it wrong. Again, let's
do it wrong again. Let's do it wrong again. If this is the right status for
things is PS, let's change it. Now let's do the homework and get it to where
it's supposed to be, and it's dependent if that's what we have to do. I mean,
status changes are not expensive.

Francesca: Right. The only thing is that when I had this conversation with
Yari, he said that yes, 9048 can go to proposed standard. They didn't do it at
that time, probably should have been done, but probably 5448 might not be up to
the standard level. And that's why 9048 was published.

Murray: Well, if we really don't want to mess with that one then we accept it
as a down ref, one time.

Francesca: I think that would be good and if someone later wants to work on a
diff and bring it to proposed standard with text changes then they can do that
as well.

Murray: I'll get out of the way of this and leave it to you Paul, but I guess
now I wanted to have the conversation and just go on the record saying, that we
should whenever we can fix a situation like this, we really should rather than
leading things
 in not a state that it really should have been.

Paul: So just from a process point of view for me, if the, if you're changing
to proposed standard, does that require?

Francesca: Another Last Call.

Roman: IETF Last Call.

Warren: Which is why often if I'm not sure if a document's gonna be standard or
informational similar, I do the Last Call as the higher level downgrade without.

Eric: And it is only two weeks, right?

Murray: It's only two more weeks and you don't have to change anything in the
document that changes to fix its status this way.

Paul: I'll talk to the authors.

John: Do we all have to reballot then after that all happens? No, probably we
do.

Roman: Yes, we would have to reballot. If we re-IETF Last Call a document, it
comes back. We're pushing back in the process.

John: As long as it doesn't get rewritten much. I don't intend to re-review it.
I'm just going to say to "it's changed status". That's fine. No objection.

Murray: Yes, sorry. Roman's right. You will see it as a second ballot thought.
You will see I just agree with my first ballot, however you did it again.

Liz: I think we can just leave this where it is for now and put it in the
substate of AD follow up and then if you want to change the state, we can do
another last call.

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

 NONE

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Lars: They didn't have a meeting this week, but they had a BIAS workshop but I
wasn't there for that so somebody could say something about it.

Roman: Sorry, I did not unmute. No, I don't have anything. It's exactly what
Lars said.

Mirja: The BIAS workshop went pretty well. I think the slides and papers are
online, if you're interested. The recordings are also online.

6. Management issues

6.1 Designated Experts for Performance Metrics (Martin Duke)

Liz: So is there any objections to approving Greg Mirsky and Michael Scharf as
the designated experts for these registries?  I'm hearing no objections so
these two are approved, and we'll send that official note to IANA.

6.2 Deprecate Expect-CT from the HTTP Field Name Registry (Francesca Palombini)

Francesca: Mark Nottingham as the expert for this header HTP Field Name
Registry contacted us and said he wanted to deprecate one of the fields. There
is a pointer to the email there and he wondered how to do that and I said, this
is an IESG action that needs to be approved by the ISEG. He has also given a
heads up to HTTP mailing list to see if anyone has any objections, and if not
then we can deprecate this field.

Eric: Just to summarize because i'm not that they understand the relationship
with W3C and ourselves. They want to deprecate it, but the risk itself is
handled by IANA? Is that correct?

Francesca: The registry is an IANA registry.

Eric: And W3C wants to deprecate it?

Francesca: No, I think it's Mark cleaning up the registry basically saying that
this is not used and let me bring up his email.

Eric: This is an IETF working group, right? Hosted by W3C?

Francesca: Yeah.

Eric: Sorry for the confusion.

Francesca: The archive link is the W3C archive link, but it's the same in the
mail archive after, if you want to see it there. His email is quite short. Does
anybody have any objections?

Liz: I'm not hearing any objections, so this can be considered approved. We'll
send that official note to IANA. Is there any other action that you need from
the Secretariat?

Francesca: Not that's it. Thank you.

Orie: Sorry, just one comment. I thought there was a new regulation in the EU
that doesn't require CT at all. So that doesn't really matter. Never mind.

Francesca: I have a task with Mark, we can do that as well.

Orie: It seems like it has already been resolved.

Paul: I think they do, it's really clear. If there's no CT entry for the
certificate, you're already getting browser failure so you're basically defecto
down already. Saying that you expect it is, it doesn't seem to serve any
purpose anymore.

Orie: Yeah. Makes sense.

6.3 Update to wiki's Getting a document on the agenda page (Francesca Palombini)

Francesca: I realized I had a to-do on my action items and wanted to clear it,
so this is it. If you remember, I brought up the update to the IESG wiki
getting a document on the agenda page a while ago. We had a discussion about
that. For the new ADs, this had come up because there was text that was not
best current practice of the current IESG and I thought let's fix it. This is
that fix. It is obviously my opinion of what is the current practice and there
is a poll request. I hope everyone had time to check it. Liz, can you show the
poll request?

Lars: Do you want to run us quickly verbally through the highlights?

Francesca: Sorry?

Lars: Run us quickly verbally through the highlights.

Francesca: The first change is it is possible to do late additions. I added an
exceptional cases to highlight that that's really not the current practice.
Basically, I wrote that the secretariat is the one that puts the document on
the next available agenda.
 I think that was already the case and that, it's automatically moved into
 state IESG evaluation before one needed to do it manually. Common practice for
 the responsible AD not to issue ballot until the Last Call is over. I think
 this was what we agreed. I added the responsibility AD in special cases can
 make the judgment call to add the document before the last call is over, but
 this should be done, always considering the one week deadline. And I explain
 how to do that. So manually change the Telechat date. And then leave the state
 and change the state only when the last call is ended, and I added this
 sentence "documents are not commonly placed on the agenda before the last call
 is over and the ID has to remember to take the document off the agenda case.
The last call shows that the document needs to go back to the working group".

Eric: Francesca, go back to the working group, but it's kept in IESG evaluation
state. This could be when I say going back to the working group, I removed the
IESG state, so you may want to change this to get a revised ID or something
better.

Francesca:  Ok. I think this is how it was phrased before, so I didn't change
it.

Eric: I mean it's up to the working group to make the change, I mean it's the
authors that are doing it. What is Paul doing with five and seven?

Paul:  I was just following up on your googling the Webex thing because I have
already reviewed all these changes and I've already approved.

Francesca: So what kind of text would you like there, Eric?

Eric: That revised ID of the document is required or is needed or something
like that. Simply, so to not mention the working groups, basically, go back to
the working group has a specific meaning.

Francesca: Maybe I can rephrase this to say that it can't have major issues, or
needs to be resolved. Something like that. Then there was this when there is
external deadline pressure procedure that was very aggressive where it says
that a document is on the agenda a few days before the Last Call ends. I've
never seen this in my three years on the IESG.  I kept this paragraph here more
for history, but I added the, “in very exceptional cases, previous IESG have
used the following procedure. This is a procedure that hasn't been necessary in
several years so highly discouraged but documented for prosperity.”

Lars: I suggest taking this out because there's a history in the wiki that
people can look at, if they're interested in the history of stuff and we should
keep this on what we're currently doing. Otherwise, I like the changes and
thanks for doing the diff and I think it was good to go.

Francesca: Yeah, I left it there because we haven't needed it, at least This
IESG hasn't needed it, but I just wondering like, how we come up with and the
same question over and over, I thought maybe if the future IESG needs it, they
have like a procedure that has already been defined.

Rob: To be honest, you can always override anything and say they're gonna be an
acceptable case. I'll do some exceptional, but I think to write up some rules
of the exceptional case in advance doesn't seem that helpful to me.

Francesca: Ok. I'll remove that. Then there some update to IESG Secretary.
There's a little bit more text about late addition are to be avoided as much as
possible. Nothing major, and that's it. I'll do these two changes as discusses
and then I can just merge it.

Liz: You should be able to, if you run into any wiki problems just let us know.

6.4 ALLDISPATCH Update and Creation (Francesca Palombini)

Francesca: We started in the mailing list on how we schedule ALLDISPATCH. Is
Martin here?

Martin: I'm here.

Francesca: I thought like you that we could just schedule all three dispatch
together, but this seems to be difficult in terms of the tooling, right?

Martin: We've done that before. I mean, we have two working groups in the same
time slot all, but in the same slot.

Liz: It's always a bit hacked together to do a "joint session"". It basically
means we schedule one of the sessions and then we just add an extra line that
says also this other section is meeting, but all of the Meetecho and the links
and the documents and the materials are only connected with the one session
that's officially scheduled. It would be simpler to just create another group
for ALLDISPATCH so that there would remain sort of a record that this special
thing happened this one time, and if this experiment is a huge success and you
want to keep doing it for a long time, then there'll be like a group to work
off of.

Francesca: Another thing I was thinking about the conflict. If we make the
three dispatch, we're basically scheduling one dispatch and the other are
co-located then the working groups have to enter the correct dispatch for
conflict, and if we do the all dispatch and it's easier to say, just conflict
with alldisbatch.

Martin: we're not really, we're not doing it that way, right? We're not gonna
put anything in alldispatch.

Francesca: Right, I forgot about that.

Martin: As I said, in the email, like my main objective in saying joint
sessions to make Liz's life easier and if it isn't like, let's do it this way,
I think that's fine. I mean the idea conceptually, this is basically a BOF,
we're trying out a new working group concept and if it works, we're gonna keep
it so like I think that's a perfectly reasonable thing to do.

Francesca: Should we make it a BOF request so it gets into the system and get
it approved on Monday? We can just do non-working group forming BOF.

Lars: Do we need to do it through the Datatracker? That's a question for the
Secretariat or what is preferred?

Francesca: I thought for scheduling purposes?

Eric: And what about the deep dive? This is kind of the same thing, right?

Martin: Well, we need a repository for the documents. There's gonna be a bunch
of drafts and agendas and stuff and it probably should sit in the Datatracker.

Lars: It's clear that there needs to be a BOF in the Datatracker, what is not
clear whether we need to create a BOF request to get a BOF.

Cindy: You don't necessarily.

Lars: Would you prefer us to?

Cindy: I think what the easiest thing just so that this just doesn't get lost
in tracking is we can just create the BOF request and then it will just be
there and we can track it that way and we will create the Datatracker group
after the call on Monday.

Roman: Could I ask a related question. That's not related to alldispatch, but
is asked the question about BOF request versus BOF. I only want to ask after
we're done with all the dispatch conversations.

 I'm not hearing anyone.

We often defensively follow on BOFs for BOFs that we think are gonna get
chartered as a working group and we use that as a marker to hold a place on the
scheduling and we keep it as a BOF or sometimes we upgrade to a working group
if things are formed. We sometimes kind of cancel if we feel like we don't need
a BOF. We also have been historically operating under the premise that you only
get two face to face BOFs in a group. I may be in a situation where I have
already held two face-to-face BOFs, and we're working on the charter. I hope we
finished the charter, of course that depends on the community. There's some
discussion to be had about what I should do to make sure that it gets scheduled
in the case that I have a BOF in the case that we charter a working group.

Francesca: That's what we've done before, placeholder BOFs so Liz can schedule
it.

Roman:  I'm just making sure because when we've done placeholders, I don't know
whether we've ever introduced a placeholder after we held two face-to-faces.
That's why I'm asking.

Rob: The two rule, is that a hard rule or is that one where we had
discretionary over anyway?

Francesca: It's a hard rule.

John: I thought it was a guideline, but I'd be perfectly happy for it to be a
hard role.

Liz: From a scheduling point of view, as long as the group exists in the
Datatracker, it doesn't actually matter to me anyway whether it's like BOF or a
working group, as long as there is a thing in the data tracker that I can move
around that little agenda board.

Francesca: Back to alldispatch.  I definitely did not want to ask to create a
working group without chartering, even if it's just for scheduling purposes, I
think a BOF is much better so the thing I haven't understood is, do we need to
enter BOF requests or will the Secretariat do it for us?

Cindy: We will do that, I will enter a BOF request. Just so that we can track
this, it's going to end up with a BOF request and then the actual Datatracker
group is a separate thing. We'll deal with all of that. We just wanted to know
how you wanted it dealt with first.

Francesca: Sounds good then I think we have a way forward.

Cindy: I just want to unmuted take an opportunity to build on what Roman said
and for ADs who have working group charters in flight, it's kind of the time to
start thinking about whether you want to put in BOF requests for those of
placeholders in case they're chartered in time.

Paul: So Murray, do we need to talk to WIMPSY?

Francesca: They have already put in a BOF request.

Paul Oh, they did. Ok.

6.5 Update on WIT Area Creation (Secretariat)

Cindy: So this is in progress. You probably saw the message from Robert in
Slack yesterday explaining that he had originally wanted to do this through a
migration and in trying to do all of that ran into some snags and determined it
would be easier to have the secretary start moving stuff manually. so we have
done that. The witarea has been created. The groups have been moved with the
caveat that Francesca noticed this morning, this morning my time that WISH
wasn't there. So that's been fixed, but it looks like the email to the
community and the slide and the plenary didn't quite match. So I just want to
do another double check there to make sure that we have all the groups in the
right place. The mailing list will be created later today and once the mailing
list is created, we will migrate to the members over. I did check the TSVarea
list and saw that there's already been a message since that looks saying that,
that will happen. So that is good. Once that is done, sorry, I'm looking at the
message from Martin, we will then close TSVarea list and that group. Then the
last question, once all of this is done, should there be some sort of formal
announcement to the community about the closure of TSVarea? Just just sort of
put a bow on everything.

Martin: Just to be clear TSVarea, the area group, not the area.

Cindy: Right. Right.

Martin: I can send out a note, I guess to IETF announce. It's not, nobody
really cares about TSV area. It's just a bookkeeping thing for us, but yeah,
it's probably worth a brief word.

Francesca: It would be helpful to CC art@ietf.org so that people can go and
subscribe if they're interested. Because we're not moving anyone from ART,
right?

Martin: Yeah. Francesca, do you want to send a note to the ART list just saying
that this new list exists now?

Francesca: Yeah. I will do that.

Martin: There's like, separate operations here. There's the closing of TSV
area, the area group, which should be announced. There should be because we
usually announce group closures. I guess when WIT area stands up, I don't have
to tell TSV Area anything because people have already been migrated over, but
yes, whoever is in ART wants to go follow and subscribe to WIT has to be told
to do so.

Francesca: Exactly. Once people are moved from TSV  to WIT then I will also
tell ART to subscribe.

Cindy: We will do all that mailing list stuff, and will let you guys know when
to proceed.

Francesca: We, as in Zahed, Orie, and I are working on deciding who will be the
responsible AD for the different working groups, so we should have that ready
for you very soon, hopefully. That should be done before scheduling.

Martin: How do we schedule? Do we schedule with the future ADs? Because the
responsible AD does not change until 119.

Liz: The responsible ADs won't change in the Datatracker until during the
meeting, but it's helpful for me to just have a list and then I just sort of be
my own computer and try and work out the AD conflicts.

Francesca: For example, Murray can take the working groups that we will have
and Zahed will take the working groups he will have. Either Murray and I will
take some of the ones that Orie will have.

Cindy: If you're moving it to a current area from a current area director to
another current area director that can happen whenever it's just the new folks
can't be officially as AD until during the plenary.

Francesca: We will split Orie's working groups until Wednesday.

Cindy: And I will take, this is the opportunity to remind the other areas that
have to do folks coming in that you should be thinking about how you want your
splits to happen so that we have that list to make those changes in the plenary
too.

Sandy: For my own understanding between now and IETF, when the actual
transition takes place, what will the document action say, will they say
they're from TSV or from ART or from WIT?

Cindy: If they have been moved to, I'm gonna actually have to remind myself
what a document action actually says because I don't know that it says the
area. Yes, so the protocol actions and document action announcements only say
in them that it is the product of a working group. It doesn't mention the area.
The area directors for an area, but it doesn't completely call out the area.

Sandy: This may be more for the IESG than when we receive the documents, the
RFCs are associated with a working group and an area, and when we transition,
we keep the history, so it'll still say this working group from this area and
then eventually say now WIT or something like that, and then once WIT is
created, it'll just say, this area in WIT.

Martin: WIT has been created, the working groups already in place. It's the
area directors that aren't moving.

Sandy: The documents that are approved between now and IETF, should those be
associated with the original area or with WIT?

Francesca: But for which document are we talking about those approved?

Sandy: The documents that are already, for example, the documents that are
already in our queue that have been approved or anything that is approved
between now and IETF.

Francesca: I guess whatever the current area is. There is a moment in time
where this goes out, right?

Martin: So like the administrative we need things to be the current area, but I
think the practical answer may be to have it be the new area because ultimately
when a working closes you go in and figure out who owns the document and I
think the new area is a more useful guide. Does that make sense?

Sandy: The old groups will be associated with the new groups as soon as WIT is
created on our end. For me, it's about tracking history, right? Like it's what,
what is the correct?

Martin: If you have an answer here that just needs approval please say it
that's fine. Like, I don't have an opinion about it. If it's easier for you for
it to be in the current area, I think that's fine. I mean, at the risk of
speaking for everyone, I think that's probably fine for everybody.

Sandy: From my point of view, then I would keep it, because with the ADs
wouldn’t officially be in place until IETF, right? For me, historically, this
document was actually approved in this working group under TSV while it was
under TSV or it was approved in this working group while it was part of ART, so
we would keep that history and switch it over once WIT is more official.

Francesca: Just to understand, are you now talking about email announcements or
are you talking about, like, I don't know RFC editor like the RFC page itself,
or I'm, I'm not really sure I understand.

Sandy: So I think it's all of the above, but the long term history would be
tracked on the RFC editor, like search and stuff like that.

So let me find an example.

So if you look, I just threw a link into the IESG chat room. So for RFC 9110,
which was produced out of httpbis, ART. Stream and source, right? So right now
it says ART in the future, it'll say ART, but then it'll say move to WIT and
then all of like, erratas and stuff would be redirected to the right place, but
for the documents that, so this is what I think we would show for any of the
documents that are already in the queue have already been approved from the
various working groups under the existing areas, does that sound, right? And
then when WIT is created, then it would show as httpbis, WIT.

Francesca: That sounds good, yeah.

Lars: I think I may have misunderstood, but I think this should stay in
whatever area it is when it was published and not change after the fact.

Francesca: But httpbis will have moved, so it should be in WIT.

Lars: It wasn't in WIT when this document was published, right?

Sandy: So the documents that have already been published, it will still say
httpbis, ART then it'll have another note that says moved to WIT.

Lars: I don't care strongly, but I don't think there's any benefit to having
this move to thing, but I don't care.

Martin: Well, we have to send the erratas to the right place. The way should
handle httpbis.

Francesca: Erratas are a whole nother thing.

Martin: Yeah, that's bad. I think all erratas should go to an actual area that
exists, but i don't know.

Sandy: Erratas will be handled separately from this, but it will be redirected
to the right place. From our point of view, the reason for having the move was
to give people an idea of like, if I want to discuss this, where do I go.

Lars: So my point of I'm coming from the point that this shows actually more
internal information about the IETF structure and the Datatracker does for the
document. So this might be a discussion like with Robert and the tools team
about what the right thing to show here is.

Cindy: In the Datatracker, all of the working groups that moved now have a note
saying, Cindy Morgan moved this from ART to WIT or something to that effect.

Lars: In the history of the group, right?

Cindy: Yes.

Martin: I think the currently responsible area for a document is hugely
important; it should be attached to every place. We have the document because I
mean, httpbis is never going to close so it's kind of a bad example. But when
the working group is closed, like the only place to go is the area that kind of
owns that. I would love it if all our closed working groups had like a current
area that sort of owned them. I don't know if that's the case. I don't think it
is, but that's a problem that we should be fixing, not not one we should be
perpetuating.

Sandy: Ok Thanks.

Martin: For instance a document is done by the MPTCP working group in
Transport. Is that going to be? So, I mean, MPTCP is not migrating, will that
just remain Transport forever?

Lars: Yes, it would.

Cindy: Asking if a previously closed group is going to change area. No, it will
not.

Rob: I partly agree with Martin here. That would be nice if all the closed
working groups. There was an area that was given or AD responsibility for those.

Martin: Separate project that like an IESG needs to take on like, go make
assignments for all these things. I agree that would be good, but I can also
ask the secretariat or somebody to make that decision for us.

Rob: Martin, that sounds like a good retreat topic to me.

Martin: You guys are welcome to talk about it at the next retreat.

Rob: I won't be there.

Martin: I agree. The next IESG should absolutely do that.

Liz: Sandy, do you have what you need for now?

Sandy: Yes. We're good. Thanks.

6.6 [IANA #1291684] Designated experts for RFC 9493 (Subject Identifiers for
Security Event Tokens) (Roman Danyliw)

Liz: Roman has suggested Prachi Jain as the designated expert for this
registry. Are there any objections? Hearing no objections, so this is approved
and we will send that official note to IANA.

6.8 [IANA #1287239] Designated experts for RFC 9456 (Updates to the TLS
Transport Model for SNMP) (Rob Wilton)

Liz: Rob has suggested Russ Housely and Sean Turner as the designated experts.
Any objections? Ok. I'm hearing no objections there either so we will send that
official note to IANA.

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

Liz: Warren, you had something about IPV6 was it?

Warren: Yes, this is just more of a heads up. The RIPE meetings for a while now
have, for the last 2 or 3 meetings, been operating in a IPV6 mostly mechanism
for their meeting networks. What this means is their primary wireless network,
when you join it and if your device is an Android device or an Apple IOS device
or Apple Mac or a few other types of devices. When you join the network your
device signals to the network that can work in ah IPV6 only mode and the
network says "Great", you can work on an IPV6 only mode and you don't get an
IPV4 address at all. If you need to connect to an IPV4 site like GitHub or
TikTok or anything like that, the network will automatically perform NAT64 for
you. This is basically completely invisible to the user. Everything just works
fine what we would like to do is we, and this is when I say we, I mean the NOC
and i've discussed with with Jay is that we would like to purpose at the
Brisbane meeting that we convert IETFssid to IPV6 mostly then create a new
wireless SSID called something like ietf-legacy or ietf-ipv4 or something like
that. That way users are not able to use the NAT64, IPV6 mostly service will
still have a way to work but everybody else will be using an IPV6 mostly
service. As I said, Android and MAC OS all work perfectly with us and signal
that they can do an IPV6 only network, if you're using a device which doesn't
yet support this, your device should automatically fall back to just using IPV4
on the network, like normal. So we believe that everything should just work
fine, but we will still have a backup wireless ssid. When I say everything
should just work fine, there were a few people who had issues at the RIPE
meeting when this was first enabled. I was one of them, and this was caused by
the fact that I had Wireguard on my laptop and I was overriding DNS servers,
which means that I was not using a DNS64 capable name server, but anyway the
main purpose of this is just to sort of give people a heads up, get some
feedback. This is what we're hoping to do, and I'm hoping/planning on
presenting this proposal to the community during the plenary at the meeting in
Brisbane and I think I did a really, really bad job of explaining how IPV6
mostly works and so if anybody's wildly confused, please let me know and also
if anybody thinks this is the worst idea they've ever heard of please let me
know. If you think this is the best idea you've ever heard of then yeah, you're
right.

Rob: Sounds like a good idea, Warren.

(Crosstalk)

Mirja: Just to confirm, are you proposing to do it in Brisbane or just
informing the community in Brisbane and doing it later?

Warren: So some of this also depends on, it requires a very large change to the
network or to at least to the routing part of the network because we will now
have state stored in the devices and up until now we've never had that. So
hopefully I will have it ready for Brisbane, but I'm not planning on launching
it in Brisbane. The plan assuming everything goes well, is we would migrate the
current NAT64 network onto the new infrastructure and we would run the NAT64
network, the NAT64 wireless SSID. Assuming the community likes it, that way,
only people who want to will have opted in assuming this all goes, well the
plan would be to see if we could do this for reals in Vancouver.

Lars: Can I ask why we're doing this? If the answer is dogfooding that's fine.
Because it adds complexity and it makes the NOC job harder which is already
pretty hard. Everything works before, so I'm wondering what the reason is.

Warren: A couple of reasons, dogfooding is one of them. It also will actually,
after the initial teething troubles should actually make the NOC's life easier,
one of our ongoing problems is we are fairly unusual in that we have a very
subnet announced to the internet and so we keep having problems with the amount
of scanning and similar things by moving to a IPV6, mostly thing we'll be able
to decrease the size of our IPV4 address pool or announced address pools
substantially. Which should help with that, but yeah, a substantial amount of
the drive is dogfooding. We think that the users want it after their initial
teething troubles should make the NOC's life easier.

Lars: I'm all for it if it simplifies the network for you guys.

Warren: When I say it's the same. I mean users shouldn't have to change their
working style and users shouldn't have negative impacts, they will only have an
IPV6 address and they will be using 4x4 X-lab and C-lab on their devices. If
you just open your web browser, you shouldn't notice anything different. But if
you're an IPV6 seller, you will be able to see things that are cool and you can
make the case that everything works fine. I'll share slides once this is closer
and will have a whole communication plan.

Liz: Ok, thanks Warren does anyone else have any other business before we go
into executive session?

Lars:  What is the status of the doodle poll for the retreat?

Roman: We haven't launched one because I've done nothing despite the fact that
Mirja has been poking me to do that and we'll launch one soonish.

Lars: Include the LLC please, because yesterday they started talking about what
they wanted to do and suggested a joint one if possible.

Roman: So ISTAR, basically? IESG, IAB, and LLC.

Lars. Yeah, if that's possible. I think that would be useful. We haven't had
one in a number of years.

Mirja: How do you do this from an organizational point of view?

Lars: Frankly, I think the IAB and the LLC don't really need to overlap so
much. I would basically have the IESG and LLC overlap.

Mirja: Ok. But that still means that we probably need more like 6 or 7 days in
a row rather than 5.

Lars: Well that's up for your successor and Roman to figure out.

Mirja: What I'm asking is if the LLC is willing to meet on a weekend?

Lars: No, the LLC said: "Oh we should do a retreat" and that was it.

Roman: And I guess my question I have for the IESG is, can you commit to dates
without knowing the location beyond a continent? So can you not, I guess I
should say if there’s objections, so we're looking into Europe, obviously, we
have announced we've talked in different countries, so it's probably Europe.mIs
that enough information? if we gave you a list of dates?

John: Okay. For me, I mean, assuming that the location is not some place that's
stupidly hard to get to.

Warren: That's what I was gonna say. It's helpful to be able to start getting
things figured out and in terms of timing, et cetera, but if it turns up that,
when you say Europe, you're actually meaning the very far end of Russia.

John: More like Frankfurt or Slovenia.

Roman: I think we, I haven't decided anything or haven't even suggested
anything, Mirja and I haven't kind of talked. I think first pass is, can we get
a venue from someone and that's driving a little bit of a decision making, and
that is why I've seen multiple kind of offers, I have not read anything in
detail on the line. But that would kind of drive where we end up, which is, can
you decide on? Can you commit to Europe? Can you commit it to a date? only
knowing Europe? Because again, there's a couple of things on the plate, a
couple of you have offered, which is great.

Warren: I have a standing request or suggestion that we go to Liechtenstein,
but if people really don't want to do that. I can see if I can get us some
space and something like the Amsterdam Google Office, which, AMS is always easy
to get in and out of, I think.

Roman: Did you say Liechtenstein?

Warren: Liechtenstein is awesome. I want to go there.

Lars: It's a 3 hour drive from any major airport.

Jim: How about somewhere with direct international flights?

Warren: I’m assuming we wouldn't want to go to Liechtenstein. I think the plan
is to fly into Europe and the drive is less than 3 hours. We've done previous
retreat type things in Amsterdam and I think they've gotten easy for people to
get to.

Mirja: If you want major airports then that limits us to basically Paris,
London, Frankfurt, and Amsterdam.

Warren: We said Europe though, so not London.

Mirja: We have some other cities where it would one hop away.

Roman: We'll have something really soon for you to kind of noodle that, and if
you have an office in Europe and you can secure us the space and it seems like
it's an increasingly bigger space for longer for longer stuff, because now the
LLC is kind of in the mix, please let us know.

Zahed: I think like, whoever is proposing, there might be some good input just
saying like the dates. If we can fix on the dates first, that would be making,
I think, a bit easier. The particular timing might not be possible to get
access to those venues. So my opinion would be for us to fix the dates first,
and then we can pick the location based on the big cities.

Roman: Agreed, if we have the dates then we can see whether we can get those
dates.

Liz: Well, await some further information on that, and let me give a quick
reminder for the BOF coordination call, which is going to be Monday at just
about right now. So that's morning for me as of today, we've got a third BOF
request. So there are now three in the Datatracker. So please review those and
we will see you on Monday for the BOF  coordination call. Any other, any other
business before executive session.

Okay, then let's move into the executive session. So we'll ask liaisons and
visitors to please drop off. I don't know if the incoming ads should stay on or
if they should drop.

Lars: I think it's probably best if they drop as well.

6.7 Executive Session: IETF Trust Appointment

An executive session was held.

------------------------------------------------------------------------