Narrative Minutes interim-2023-iesg-04 2023-02-02 15:00
narrative-minutes-interim-2023-iesg-04-202302021500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2023-02-02 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
Jay Daley / IETF Executive Director
Roman Danyliw (CERT/SEI) / Security Area
Martin Duke (Google) / Transport Area
Lars Eggert (NetApp) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Jim Guichard (Futurewei Technologies) / Incoming Routing Area
Erik Kline (Aalyria Technologies) / Internet Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Stephanie McCammon (AMS) / IETF Secretariat
Cindy Morgan (AMS) / IETF Secretariat
Paige Mustafa (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Applications and Real-Time Area
Alvaro Retana (Futurewei Technologies) / Routing Area
Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area
John Scudder (Juniper) / Routing 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
---------------------------------

OBSERVERS
---------------------------------
Richard Barnes
Alissa Cooper
Suresh Krishnan
Lee-Berkeley Shaw
Rene Struik

1.2 Bash the agenda

Amy: Does anyone have anything to add to the agenda? Any other changes?

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes from January 19 being
approved? I'm hearing no objection. Does anyone have an objection to the
narrative minutes from January 19 being approved? I'm hearing no objection
there either.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

     o Francesca Palombini to find designated experts for RFC 8141 (Formal
       URN Namespaces, Informal URN Namespaces) [IANA #1263515]

Francesa: We had a proposed name and I've emailed them to ask and they haven't
responded yet, so I'm not sure what that means.

Lars: I think that means you might have to find a new expert.

Francesca: This is in progress, I guess.

   * 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

     o Lars Eggert, Warren Kumari, Éric Vyncke, and Rob Wilton to discuss
       whether to reconstruct the document approval announcements to be
       more meaningful.

Lars: I have a question whether we should put this on an informal agenda. I
have a feeling that no matter what the four of us discuss, the rest of you
would have opinions immediately. I'm going to stick this into the appropriate
category on the informal agenda for next time.

Warren: We should still meet the four of us as a start. But I'll be at NANOG
next week.

     o Murray Kucherawy and Warren Kumari to coordinate with Barry Leiba
       and IANA about possibly updating text regarding IANA registries and
       expert review process detailed in RFC 8216.

Warren: We actually did that. Barry is going to be making some updates to the
BCP and he's got a document partially written. In a couple of weeks he hopes to
have a new version posted.

Murray: That's right. I think we can say this is done. I'll see Barry in
February and this has started, so if the action item was to kick it off, that's
done.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-elegy-rfc8989bis-04  - IETF stream
   Nominating Committee Eligibility (Best Current Practice)
   Token: Lars Eggert

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

Lars: Very quickly. Barry pushed back pretty hard, I don't know if you saw it.
Does that change your mind?

Andrew: My problem here is that as I said in my discuss, you've got something
in there that says we're committing to free remote participation, and that's
what that reference is. Without the shmoo document there is no commitment.

Lars: That's not actually true. The commitment comes from publishing the shmoo
document and it doesn't matter what the reference is. In my mind, the
difference between normative and informative is you've got to read the
normative stuff to make sense of the document those references are in. The
informative ones are basically for further reading. This is a 'for further
reading' reference in my mind because you can understand the document without
having read the details of the…

Andrew: So what happens in the event that we don't end up publishing the shmoo
document? This explicitly says we're committing to something and it's being
done by way of this document. If this document never happens, we have a problem.

Lars: Fair point. I'm hopeful it will happen, but I see what you mean. One
solution would be to lump them together into a cluster because of the normative
reference. The other option would be to say we're in the process of giving
guidance to free participation and make it an informative reference.

Martin: I'm happy to remove the reference and just say that currently we offer
a free participation option, because that's the part that's germane to this.

Andrew: If you've got a way to make sure we're not saying by way of this
document we're doing this, then it becomes informative. At the moment the way
it's written we have a problem if it depends on the other document.

Martin: All right. It might be that there's no part of this document that
depends on there being a mandate for a free option. It doesn't affect
eligibility. It tightens eligibility if it's not free, but it's still wider
than status quo and it in fact makes the security conditions easier to meet
because it increases the barriers to joining the Nomcom. But I think it
certainly doesn't matter that there's a free option now and forever, what
matters is that right now there is one and there will probably be one in the
future.

Andrew: Do you see my point about the way the text is written?

Martin: Happy to rewrite the text. We don't even necessarily need a reference
to the other document at all.

Alvaro: So what you're saying is that if there's no free option, the pool
wouldn't be reduced significantly?

Martin: It might be reduced. But we don't need that guarantee to implement this
specification as it were.

Alvaro: I understand what you mean. I'm just wondering if the updated
eligibility criteria is lowering the barriers of entry by counting remote
attendance, and we're counting on that, is the impact significant? I don't have
a problem with that, I'm just  wondering if you were assuming that was going to
happen and the pool would be bigger. Without that do you have a guess?

Lars: There are 2 aspects here. One is that free remote participation increases
the potential pool because more people are eligible. The second thing is the
security implications, because some attacks get easier. You can just register a
bunch of dummy people. So there is a consideration here.

Alvaro: so are you saying it's better not to have free participation because
then there's no--

Lars. No. Well, from a security perspective, of course, and I also want to see
all your passports. But, no. Martin, if you look at the text there are two
places where we cite the shmoo document. One is in section 2 where it says as
the IETF is committed to having the no fee option, we could make that "striving
for" a no fee option.

Martin: I'd even just make the factual statement that historically we have had
a free option.

Lars: That's fine too; whatever works for Andrew. The second one is in the
security considerations where we're talking about how something should be done
in accordance with some section of that document. There we might even just
strike that out and say we have to watch for a sudden increase in online
registration with fee waivers.

Martin: Okay, that's fair enough.

Lars: Okay, I think we have a way forward and hopefully Andrew will be able to
lift. Warren?

Warren:  A question. Did somebody read all of John Klensin's response? I
skimmed it and ran out of time. From what I remember he had some useful points
and it might be worth skimming over them.

Martin: Thanks for the pointer.

Andrew: I've cleared that Discuss on the basis you're going to change it,
Martin.

Martin: Thanks. The other thing is, I don't know if a response came in
overnight, but there were people who wanted to see a more defined enforcement
mechanism if there are shenanigans going on with volunteers. My response was
that that was out of scope, and we weren't supposed to design the investigation
mechanism. There were some pointers to it and things we ought to do, but it's
pretty loose in saying who's going to do it and what's going to happen. I just
wanted to make sure people were okay with that.

Rob: I think we should change this. I proposed some text, idk if you've had a
chance to read it. The one that I raised is just to change "leadership" to
"IESG" in one or two places and just give a bit more strength that they're
responsible for resolving any issues with the Nomcom. I don't think it's really
setting any policy here. A minor change.

Martin: All the enforcement stuff is non-normative. If we just want to make
that all the IESG that's fine.

Lars: The other related addition you might want to make is to say that anybody
who has concerns with the integrity of the process can raise those with the
IESG. leave it open who does an investigation, but it puts somebody in charge
of doing an action.

Warren: That's a nice idea.

Lars: You could do both Rob's suggestion and this one.

Rob: I think mine said "IESG-led" or something like that. It wasn't that the
IESG was supposed to do the investigation, but just to make sure it happened.
The other one I was concerned about was in the case that somebody is trying to
break the process, I'm not sure we could get a consensus document through the
IETF process in time to mitigate that. At least the IESG could always put out
an IESG statement to mitigate it if we had to. I'm not suggesting writing that
down.

Lars: We discussed this in the WG and there are other options that are
basically you can appeal it at any stage, and there are more creative options
like the ISOC CEO doesn't appoint Nomcom chair or the Nomcom never formally
sits or something like that. There are a number of steps where we can do checks
and balances. Okay, so this goes to Revised I-D Needed and we'll wait for a new
version. Thanks for doing this, Martin, it's needed and we're very close to
getting it done.

Amy: Okay, this stays in IESG Evaluation with REvised ID Needed and we'll move
on.

Lars: Actually, can we put it in Approved, Revised I-D Needed since it doesn't
have any Discusses anymore?

Amy: Oh, I missed that. I didn't refresh. Yes, that's going into Approved,
Revised I-D Needed.

 o draft-ietf-mls-protocol-17  - IETF stream
   The Messaging Layer Security (MLS) Protocol (Proposed Standard)
   Token: Paul Wouters

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

Paul: I think briefly. Lars, obviously your Discuss is fine and that change
seems very reasonable. I wanted to talk about Rob's. The delivery service can
actually block things and it could be shut off to prevent further
communications between everyone. The document isn't always very clear that
there's very much power in the delivery agent to stop delivering and do things.
I think that's where things could be handled that you're concerned about.

Rob: Brilliant. When I was writing my Abstain, I wondered whether I knew
exactly what the technology was doing well enough to understand that layer. One
thing I was thinking is if this is meant to effectively enable more
interoperation between messaging services, does it mean you always know who the
other participants were in the encrypted communications? Hence, you'd never be
able to have another actor you wouldn't know about? That was a question in my
head but I just didn't really know the technology well enough to know if it
applies.

Paul: Okay. This will go into Revised I-D Needed and after that I guess Lars
will clear his Discuss.

Lars: I'm just waiting for the new revision, but it's a no-brainer. Thanks.

Amy: So this will stay in IESG Evaluation with Revised I-D Needed.

 o draft-ietf-shmoo-remote-fee-05  - IETF stream
   Open Participation Principle regarding Remote Registration Fee
   (Best Current Practice)
   Token: Lars Eggert

Amy: I have a few Discusses here; do we need to discuss those?

Lars: Yeah, we'd better.

Andrew: I certainly would like to.

Lars: Thank you all for your robust feedback. I talked to the chair and the
author, who's on the call. I want to see if there's some way forward. I think
we do need to have a document like this. Warren has a point that from our
principle of openness you can derive almost anything but it's still nice if
it's explicitly communicated. I think a document that says basically the IETF
community really wants the IETF LLC to try hard to have a free remote
participation option available is something that's good to write down and it's
helpful to the LLC to know the community wants this. Not that we don't already,
but it's good to know in 20  years. The document started out basically saying
that; it was a lot shorter. During the WG process a lot of text got added and
it's that text that's now causing problems, so I'm wondering if there's a way.
I do want the document here, but I'm not quite married to the content other
than it better say what I just outlined.Andrew had his hand up first.

Andrew: I'm not terribly married to the content but I am married to the
message. One of the things I found doing a lot of presentations about the IETF
trying to encourage remote participation is that people say, okay, there's a
fee waiver, but is that going to continue long term? Can you commit to us
coming back if we commit this time? It's something that's come up four
presentations in a row. To have something that commits on that is very
important. That's the way I see it.

Warren: If the document largely said what you said it originally said, the IESG
thinks that openness is important and the LLC should please keep in mind we
want that, I'd be more okay with that. At the moment the content is more like
we think it's really important, by the way here's some financial stuff, we know
what we're doing and the LLC does not. The tone is somewhat offensive toward
the LLC. It's not that I don't think there should be free ability for people to
participate, but some of this felt like 'we are engineers, we can figure out
everything including finance,' etc.

Mirja: I think the intention was exactly the opposite, that we trust the LLC to
do the right thing. I'm not sure how you got the opposite impression.

Warren: Well, if the document said the IETF is an open organization as we've
already said in blahblah, we think it's useful for people to participate,
blahblah, we have an LLC who figures this stuff out, yay. But that isn't really
the tone.

Mirja: That message wouldn't be strong enough for what Andrew is trying to
achieve, to have a commitment.

Warren: true. I think there is also the concern of if we make a commitment and
cannot abide by it, then are we kind of screwed?

Mirja: if we can't hold this commitment because we have financial problems
we're screwed anyway.

Andrew: That was my take. If we can't do this, we're probably in way deeper
water than what needs to be worried about in this document. I don't know if
this would work but have we discussed this document with the LLC and seen if
they have any issues with it? If they think it's fine, some concerns can be
alleviated.

Mirja: Jason, Jay and others were involved in the wg process so they are very
much aware and participated. Based on Warren's feedback I sent a private email
to Jason to ask if he thought it was good to have this document and he
basically said it's always good to have guidance from the community.

Roman: To return to what you said, Lars, the document does not say what you
said. I heard you say that we really should try very very hard to make sure
this is possible. I thought we have a word for that, SHOULD. The principle just
says MUST.

Rob: My objection is that I have no issue with saying we should have a free
option. My issue is  I don't think we need to say that the free option MUST be
the same as a paid participant. It feels like that's constraining the LLC too
much. Saying they SHOULD be the same feels fine. it feels like we're tying the
hands of the LLC unnecessarily and we should let them implement this guidance
the best way they can.

Lars: I disagree on that. The community can define that their expectation is
there is no difference between a paid registration and a free one in terms of
the experience you have as a participant. I think that's a fine expectation to
have. The LLC might need to do something but I'd be surprised if they had to. I
think it would send a terrible message to the outside if participants using a
fee waiver got second class service. I think we really really really want to
avoid that. That's something the community can tell us, to make the fee waiver
identical to the paid one and then we manage the fee waivers as we need to if
it becomes a financial issue.

Rob: When you say manage the fee waivers, what is that management going to be?

Lars: For all intents and purposes, we'll never have a future where the free
fee waivers cause an issue. But someone said if it turns out that a lot of
people that are currently paying for remote start using fee waivers, there
might be an erosion of payment for remote participation. If everyone assumes
everyone else is getting it for free, why would you pay? So the danger there is
that all remote participation reverts to free. That might still be okay
financially, it just means that the people who show up in person have to pay.
Then it becomes a judgment call; do we get rid of the fee waiver program or are
we still okay with the in person people paying more to subsidize the remote
participants?

Mirja: if that situation occurs we have to do something, but it was really
unclear in the WG what that thing is, so it's really speculative to give any
guidance for that situation.

Rob: I can move to Abstain, but I quite strongly don't agree with that point.

Lars: Let's get some new hands, Eric?

Mirja: Very quickly to reply to Roman. I believe the MUST has consensus. If we
changed it I wouldn't want to change it here in IESG review, we'd have to bring
it back to the WG and have a discussion there because that's fundamental.

Warren: I'm still slightly unclear what problem exactly this is supposed to be
solving. If it is that we think there should always be an infinite number of
fee waivers the chair can hand out, I'm fine with that. If it's that we should
just do away with remote participation fees completely, it's unclear.

Lars: It was supposed to be clear. There's not supposed to be a review for fee
waivers, and there's not supposed to be criteria. The WG was very strong on
that. It's not like this is only available for unemployed people or retired
people.

Warren: Yeah. But it's unclear for me if you click on the registration page
"I'd like to pay" or "I'd like to not pay" or if you email the chair and ask.
Is there a problem currently? If it's what Andrew wanted, which is that we
commit that anyone who wants a fee waiver always gets it, that's fine with me.

Mirja: This level of detail of how to implement it, we left out of the document
on purpose because that's something we can change. Currently you just ask for a
voucher and the Secretariat sends you one, but it doesn't have to be this
process specifically. With this document we tried to codify the consensus that
was reached before this document was written when the LLC first proposed to
have the remote fee and the community came back very strongly and said no, you
cannot have the fee, because you can't make a good decision about who gets one
and who doesn't, so we shouldn't have a limit.

Warren: I don't understand the problem. We've already solved that.

Mirja: It just writes it down and makes sure it's documented for the future. We
did have a lot of discussion in the group to figure out if there's a different
solution that would involve defining criteria of who should get one and who
should not get one, and that wasn't solvable.

Warren: I'm perfectly fine with everyone who asks for it being given a waiver,
I just know in some companies if there is a free option your employer will tell
you to take that.

Mirja: That was discussed as an implementation detail and that's why it's not
currently in the registration form, it's a separate step.

Lars: Let's keep going though the hands.

Éric V: I agree, Mirja, you may need to go back to the WG or at least do an
IETF Last Call after the changes, because they are heavy. I wanted to say I
want to keep the fee waiver, I think it's important but we cannot say at the
same time to the LLC, please keep the budget afloat, and tell them it's up to
the chair. It's putting a lot of responsibility on the chair to say yes or no.
Enough fee waivers to not be afloat regarding the budget. I think it's
impossible to do both at the same time.

Mirja: But we're not asking to keep the model as it is forever. If there's a
problem we can change the model.

Andrew: we're saying we should trust the LLC, right? But what I'm hearing from
Mirja is that the LLC has said this document is a good thing, they want this
document. So are we trusting the LLC in that sense or are we not trusting them?
Because if they are saying this document is good, we should trust the LLC.

Mirja: You've seen Jay made a comment about a few financial sentences in the
document.

Lars: Jay is on the call and we can ask him to speak, but John has had his hand
up for a long time.

John: It seems to me that what we've got is a problem with the document that
starts out with wanting to say a really strong statement, we should always have
a free option period. That's fine if that's the ietf consensus, great. But then
we have gone into this microanalysis bikeshedding thing where we follow the
decision tree all the way down and we're going to document all that in
additional sections. To me that makes the document confusing as hell and I
don't know what it's trying to say. If we want to make the statement that there
should always be a free option period, the document should say that. We have
the ability to publish new documents if the old document is no longer
sufficient as our best current practice anymore. Instead of trying to predict
the future, take out a lot of that stuff that's future-anticipating and put in
something that says if the LLC reports to us that this is not practical
anymore, we'll take it up again.

Éric V: Does the current document say the LLC can object? I don't remember.

John: Right, but the point is there's all this conditional text that talks
about different conditions and under which something might need to be done,
etc. to my reading, it makes it really hard to construe the document in a clear
way.

Mirja: The document was very short in its initial version, just stating the
principle and having two sentences about financial impact. Everything else was
added during the WG process in order to achieve WG consensus. I don't think
anything we added changes the principle, just provides additional detail.

John: So we just completely disagree on that point. We've iterated enough to
understand each other's points and we disagree. I'm not sure how we proceed
from there, which is why I moved to Abstain.

Jay: The first question that was asked is what's the LLC's overall position on
the document, and I think it's great to have the document. There was a wobble
earlier on which required the community to step in and redirect the LLC about
these things, and upholding that in a policy to stop it happening again is
fine. I think it's useful to have something that adds to the tone and the
culture of the organization through a document like this, so I quite like it.
My concerns are more about the implications of it. Rob's point about exactly
the same service is one I hadn't thought about and is quite important. You
can't absolutely guarantee that you wouldn't allow some people to pay for
something extra and then not be able to give that to someone else who's getting
a fee waiver. It just gets complicated, so I thought Rob's point was quite
useful. My biggest concern is about the financial stuff. I don't think the
financial stuff is in any way necessary for the document. I think it's
perfectly possible to say there SHOULD be one of these, I don't even
particularly mind if it's a MUST, because as John points out we can always come
back and say we can't make the MUST anymore, and we need to rethink this. To
state that if we do this wrong it can impact the credibility of the IETF if we
end up with 5,000 people using waivers and one person paying, we can clearly
say there's a problem there. But the bit about costs and stuff concerns me. To
me it sets a precedent about how we think about the cost of meetings, and what
goes into meetings. To me that's quite problematic, so that's why I've been
trying to excise that specific element. So I'm a bit like Lars; I think it's
great to have the document, I just think some elements of it are excessive to
achieve that. But with a few minor changes I'd be happy with it, and ultimately
this is yours / the community's, and if the community wants it I'll put up with
it. I don't think I have any kind of veto or ability to throw a grenade in it.

Mirja: Jay, let's work on the two sentences you have pointed out. It's not
important to say what exactly the financial model we apply here is. The initial
intention was to say that it's not the amount of free remote participants
that's the problem here, it's that you have to maintain a certain number of
paid remote participants to keep the IETF sustainable.

Jay: I think that whole way of looking at it is wrong. I think you have to look
at it from a fairness and credibility point of view. This is intended for
people who can't afford to participate, and provided that's not abused, the
actual number doesn't matter.

Mirja: If you have your usual participants and that stays stable, and we see a
huge increase in remote participation over time, that increase can be because
we have attracted other people to the IETF who wouldn't be able to afford it.
The point is that the number of free registrations is not the point here.

Jay: The number of paid ones is irrelevant. We're trying to get into a cost
model when we start talking about the number of paid people.

Mirja: But the number of paid people is important for the sustainability of the
IETF.

Lars: Would it be sufficient if the document says that the community trusts the
LLC to manage the costs of these fee waivers like it manages all the other
costs?

Jay: Yes.

Mirja: The point I was trying to make is that it's not just that you have to
pay money to the number of free registrations, you have to detect a shift from
paid registrations to free registrations.

Lars: That's something the LLC will look into when it needs to look into it.
The community can't, because that information is not public. We're running out
of time.

Andrew: Very quickly, like I said, for me we trust the LLC and if the document
says the LLC is going to manage those costs, let the LLC manage those costs.
That's what they're there for. At the same time, if we tell someone to come and
participate and they know they're not going to be able to pay, we need to be
able to say we're not suddenly going to remove the waiver from you. That would
impact credibility as well.

Lars: Fair point. I have a question. It's very clear that this will be Revised
I-D Needed. Do we think this needs to go back to the WG or do we think it can
be handled in IESG Evaluation?

Warren: I think it can be handled in IESG eval. If we make it clear we trust
the LLC, just think this is an important principle, I can remove my Abstain.

Éric V: I'd really prefer if you go at least to an IETF Last Call, to involve
the community on such a sensitive topic.

Lars: Let's put it in Revised I-D Needed and have the editors try and provide a
new version based on the feedback here. Then we can look at it on an informal
and see if we think it should go to the WG, or Last Call, or whatever. If this
goes back to the WG I want you all to be in the WG. Thank you everyone for the
feedback.

Amy: This is staying in IESG Evaluation, Revised I-D Needed.

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-lwig-curve-representations-23  - IETF stream
   Alternative Elliptic Curve Representations (Informational)
   Token: Erik Kline

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

Erik K: I think we probably should. The author is on the call but I haven't
seen them have the chance to respond to all the latest comments. I think the
comments about the designated expert stuff not being addressed yet obviously
make sense. I wanted to talk about the scope stuff. I think it's like the third
time we've had this discussion. First with Magnus and the decision at the time
with Alissa was to acknowledge there was a ton of work put in and try to carry
it forward. I have another recollection of a conversation with Lars from June
2021 that the way to go forward was to acknowledge that this was out of scope
and update the approval text, which I did. You can see the text I proposed
adding. I don't know if that addresses anyone's concerns. My reading of the
ballot positions is that if Roman's concerns can be addressed, it would have
enough to advance. Does anyone else have anything to add?

Zahed: The concern is still that this is not part of LWIG's charter. I'm not
Discussing it because of the announcement text, but I don't think this should
set a precedent for future work and we should be reminding ourselves to get
into the process of documents and WG decisions. It's great that Magnus caught
that and we can say it's fine, let's get it out into the RFC Editor, but this
is perhaps not the right thing to do. But we gave you some things to do, the
charter of LWIG could have been changed, and if the WG really wants to push
something as PS but then it goes to Informational, this doesn't all make sense.
But I said what I wanted to say, this is a complete exception.

Andrew: I kind of second that. There are process issues here. But at the same
time, they weren't process issues that formed the hill I was going to die on. I
do agree we must be careful this doesn't become a precedent, because it gets
very dangerous if we do start accepting documents that are clearly out of
charter.

Erik K: Is there something I should make note of somewhere for posterity?

Lars: I don't think this is on you. This is on all the ADs to take a look at
what WGs are working on and make sure the documents are in charter, especially
charters that haven't changed in a while, because WGs sometimes conveniently
forget what's in their charter.

Francesca: Erik, there are comments that might need addressing. I have two
questions, they're not Discuss level, but they were quite late so I understand
they haven't been seen yet.

Erik K: I definitely want to give the author a chance to respond to those
specific points. I just wanted to talk about the meta issue if anyone wanted to.

Francesca: I think we've talked about it a lot.

Erik K: Fair enough. In that case I'll wait to hear from the author on the
mailing lists.

Roman: I wanted to ask a process question; I know that IANA sometimes asks us
to hold a Discuss on a registration issue. Do they want that done?

Sabrina: Yes please, that would be helpful for us.

Roman: I will move my comment into the Discuss and I'll also mention the IANA
expert review.

Erik K: I think this is Revised I-D Needed.

Warren: Is the author clear on what needs to be done?

Paul: Is there no objection to changing the recommended value from yes to no? I
haven't heard any feedback from the author or AD.

Erik K: If we change it from yes to no then we can't publish it on the IETF
stream. You're talking about the IETF consensus? Oh no, you're talking about
the IANA registration value column being recommended.

Paul: Yeah, whether new algorithms are recommended. It doesn't need to change
the stream.

Erik K: I'd defer to the IANA experts; I have no idea what should be
recommended from a security context.

Paul: Normally, especially with new algorithms, the WG would recommend these in
PS documents. This is informational, right? That would suggest that recommended
is No is better, because there's not a broad PS action to make this mandatory
to implement.

Erik K: I see. I have no personal objection to that. That could be changed in
the future in a new document, right?

Paul: Yes.

Erik K: Okay. I'll let the author weigh in with his thoughts on that.

Amy: Okay, I hear this is a Revised I-D Needed. Let's move on.

 o draft-ietf-mls-architecture-10  - IETF stream
   The Messaging Layer Security (MLS) Architecture (Informational)
   Token: Paul Wouters

Amy: I have a number of Discusses; do we need to discuss any of those today?

Paul: I don't think so; most of these are things that will be picked up in a
Revised I-D but if any of the Discuss holders want to, we can [discuss].

Éric V: In the security section, in an IETF document we say that TOR and
WireGuard are secure channels. That's one part of my Discuss and I'll remove it
immediately after the discussion. Can we classify another protocol as being a
secure channel?

Paul: This was discussed on the MLS mailing list as well in the last two days.
Initially it only said WireGuard without IPSEC and then I objected to listing a
non-IETF protocol for a technology for which we have an IETF protocol, so then
they added that there. Then Eric Rescorla pointed out that you'll be mostly
looking at application level security and not really looking at IP security for
the transport, so it's better to stick to mentioning Quic and TLS and not
mentioning the others at all. I think that's how it's moving forward now. So
your issue is addressed; it doesn't really answer your question but it prevents
your question.

Éric V: Which is implicitly answering the question. And the other point, it
says scalable into the abstract. Honestly when I see the complexities of the
MLS…

Paul: I believe scalable mostly refers to the fact that you can have small
groups and large groups.  A lot of the cryptographic properties for large
groups traditionally would have been that everybody can see everything and even
if the group changes, suddenly you get to see all the old messages if you're a
new group member. It makes the security properties much more constrained to the
continuously updated members of the group. I think that's where the word scale
comes from.

Éric V: It was not explained in the text, that would be nice. My other point is
that what's the value of this document when we have the protocol document which
is really nicely written?

Paul: I think the MLS group was trying to make sure that the MLS protocol was
not the only driving point here, that people can do other things based on the
architecture. I agree there is definitely some overlap and you can tell it's
backwritten after the MLS protocol was already far along and then wrote an
architecture document around it. I think it's still useful to have both
documents go out. I did have similar issues as you and I avoided reading the
protocol document on purpose to do the architectural one first and make sure it
could stand on its own, and I also had some comments. But I think these things
can be fixed in a Revised I-D.

Éric V: Okay, fair enough. I'll clear my Discuss on the Revised I-D.

Zahed: My one other point was the use of transport was more general purpose
than the transport protocol was. It's confusing. So you have 24 transport [?]
but they don't all refer to the same level.

Paul: That was also raised that it's recommended to use some sort of transport
security for the public messages. That's already been agreed in a PR to make a
requirement. In general there should not be any non encrypted traffic over the
internet so transport security should be a requirement. That's been changed and
it will also be in the revised ID.

Amy: This will stay in IESG Evaluation, Revised I-D Needed.

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

 o Time-Variant Routing (tvr)

Amy: A block was just cleared for this, so now unless there's an objection this
can go through to external review.

Alvaro: Thanks everyone. I have one more little change I want to make in the
next half hour or so.

Warren: Do you want to give us a preview of it?

Alvaro: Take a look at my email thread with John from right before the
telechat. There are a couple changes there and Deborah sent some comments last
night saying we should coordinate with other WGs also looking at nontraditional
networks, so I'm going to add that as well.

Warren: Cool, thank you.

Amy: It sounds like external review is approved and we'll send that
announcement. We won't send it until tomorrow so you can do your edits today,
Alvaro.

4.1.2 Proposed for approval

 o More Instant Messaging Interoperability (mimi)

Amy: I have no blocks in the tracker, so unless there's an objection now this
is clear to be chartered.

Murray: The question was about the second chair; I've been talking with people
and will be naming somebody today or tomorrow. As far as I'm concerned this is
ready to go.

Amy: Do you want to wait on the announcement until you have that second chair?
You can let us know when you're ready.

Murray: Sure, thanks.

 o Domain Keys Identified Mail (dkim)

Amy: I do have a block; do we need to discuss that now?

Murray: I'd like to take a couple minutes. The first point is about the problem
statement and the WG was waffling about whether they wanted to do this on the
basis that we don't have to publish everything. There's also a possible branch
we won't be able to converge in a problem statement, in which case I think the
WG will close. That's why the language was a bit waffly. I don't think it's
going to be a problem to say no, you have to publish your problem statement,
and if you can't, you'll close. I don't mind tightening that up. The second
question about who's the chair, our plan generally is to identify a chair
that's experienced to help bring up a chair that's less experienced. I've
secured the less experienced person but I'm having all kinds of trouble finding
a more experienced person. Largely because there is so much bickering in the
email space everyone is tired of each other and I haven't found an experienced
person willing to work with everyone. I don't want to say nobody wants to work
with this person, therefore there are no chairs, therefore this WG isn't
chartering. So I'm kind of stuck until I find someone who wants to put up with
the nonsense.

Lars: Is there a proposed co-chair? Nobody wants to work with some big egos,
right?

Murray: Everyone likes the idea of the less experienced co chair I've selected.

Lars: There's no co chair at all in the charter. If you want to do it with just
the one you have, that's fine, but we can't charter with zero chairs. Do you
want me to block this until you have one chair named? Is there a state we can
use to keep this from going forward?

Murray: I'm not going to move it along until we have chairs.

Lars: But if we approve it today, what happens if there are no chairs?

Amy: It would just be pending chairs. We can't send the announcement with no
chairs.

Murray: If we're just verbally fine with this can we just agree to wait until
there are chairs?

Lars: We have to wait for a rev anyway about the publication issue, so
hopefully by then you have at least one chair in the datatracker. Ping me when
you want me to lift, I guess.

Amy: We'll wait for instructions from you, Murray, about when this can go
forward.

Murray: That's fine, thanks.

 o Secure Asset Transfer Protocol (satp)

Amy: I have no blocks here, so unless there's an objection now this is approved
as a WG.

Paul: We did add the second chair, so there are two.

Amy: Paul, are you going to continue to be on this? I see both you and Murray
as area directors.

Paul: Because of the load, I agreed to take this on and help. If it gets
rechartered in the future I'd like it to be in the correct area, not SEC.

Lars: Who's the second chair? It just says "Claire."

Paul: She's part of the external group that came to IETF to make this happen.
Her Datatracker entry only had a first name. Wes pinged her already to fix that.

Lars: Okay, thanks.

Amy: We have all the pieces to approve this, so we'll get that done.

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

Mirja: I don't think there was anything important. We talked about the retreat
a little bit but since we still don't have the new IAB members yet we can't
make a decision. Hopefully we'll hear next week.

6. Management issues

6.1 [IANA #1262464] renewing early allocation for
draft-ietf-bess-mvpn-evpn-aggregation-label (IANA)

Amy: It looks like this needs an extension of the early allocation. Andrew, do
you want to talk about where it is in your queue?

Andrew: Yes. Unfortunately the reason it expired is my fault, because I missed
it. Otherwise it would have been approved. This document is moving so I have no
issue with extending it.

Amy: Any objections to approving this extension? I'm hearing no objections, so
that's approved and we'll send mail to IANA.

6.2 IETF 116 Hours of Operation (Secretariat)

Paige: The standard hours for the convention center in Yokohama are 8 am to 9
pm and anything outside of that is a hefty charge, so we're trying to be very
tight with our scheduling.

Martin: Does that mean literally people can't get in the building?

Paige: Correct. It can't be unlocked and we can't be inside until 8 am.

Martin: That mainly affects TDD, right?

Warren: There's no TDD this time.

Lars: This might affect side meetings as well. I've advised the secretariat to
advertise an 8pm closure so we have an extra hour of slack. In Japan, closing
time means the doors are locked and you are gone, not a polite ask that you
should leave now. We should have a buffer at the end.

Amy: It may also affect the breakfast meetings for leadership. Depending on the
agenda schedule, are we starting at 9:30 or 10:00, which we won't' know until
all the session requests are in, we don't know what time we're starting and how
that will affect your breakfast meetings.

Lars: Financially we'll lose money on this meeting so I want to be firm on
this. Can we be flexible day by day?

Paige: We can be flexible day by day but we need to let the hotel know in
advance, at least two weeks ahead of the meeting.

Lars: That should be doable. We should operate under the assumption that we're
okay with these hours and if we have to make some changes we will, but I'd like
to not have to.

Warren: How expensive is it to stay open?

Lars: Expensive enough that the Secretariat is bringing it up to us. We could
also just eat breakfast individually at our hotels and just have the meeting.

Roman: I don't think breakfast is the concern. Let's just get our work done in
the box we have available to us.

Rob: That means realistically we're starting at 8:15, right, if the doors open
at 8?

Lars: I guess for you Paige, we're going to be okay with these hours and when
we know what the agenda is and when we need to start sessions, we'll figure out
the breakfast. And when you communicate it out, say 8 pm to end side meetings
and everything.

6.3 IETF 116 Mics in 40-U and 20-U (Secretariat)

Paige: We do have to change the mics in the 40-U because we can't use
push-to-talks. We'll do everything we can to reduce the impact.

Stephanie: The maximum they'll allow us to have is six; four wired and two
wireless. Otherwise we will need a full time tech in the room.

Lars: For the IESG and IAB only that should be fine. For the joint one it'll be
a little tight, but we'll make do.

6.4 Host Speaker Series (Secretariat)

Stephanie: WIDE would like to also have a host speaker series. They've already
sent what they would like to talk about, which is quantum internet from a
couple of WIDE members participating in QIRG. That would be Thursday as it
normally is. They would be providing lunch. I wanted to talk about this because
I think we've decided it will be either/or for a demonstration or the host
speaker series. But this is a special circumstance finally going back to Japan
so I wanted to come to you to see if anyone has any issues with this.

Éric V: Sure, I don't have any issues with it. The host needs recognition.

Lars: I don't have an issue either but we're setting a precedent. In the future
if a host wants to do this we'll need to be okay with it.

Warren: I think some of the precedent can be explained by this being a
consortium. Also if they're providing food, that's great.

Éric V: The two activities are completely optional.

Warren: If the community hates it, we can not do it again.

Stephanie: Okay, we'll proceed with that. Thanks everyone.

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

Lars: Lee-Berkeley wanted to talk about the document she sent.

Lee-Berkeley: Thanks Lars. You may remember at 115 we had a pilot event which
brought together various sectors to introduce the IETF and how to work with the
IETF in the hopes of building new relationships and educating people. That
event had about 35 people. We also had a great conversation with you all at the
end of 115 to talk about fundraising events. What we're proposing for 116 is an
event that mirrors that partially but with more of an eye to fundraising.
Tuesday from 5:30 to 7:30, we'd have an invite only event for people new to the
IETF and in the document we outline those audiences. In essence, folks that may
be either able to secure funding for IETF themselves or folks who may be able
to open doors to funding. The idea is to get them in, educate about who we are,
talk about why we need support, and use the remainder of time to mix and mingle
with leadership, people who can help talk about the right fit. More of a
cocktail party than a formal presentation. It's intended to be a lighter lift
than what we do at 115 because it's easier to build relationships if you're
talking to each other. It would be hosted by the LLC but we'd love to have your
participation.

Éric V: My only concern is to start this in Japan. Does Japanese culture work
like Western culture in things like this?

Lee-Berkeley: That's a good question. We floated this idea to WIDE and they
seemed interested. Is it probably the easiest place to start? No. But there's
still merit to it.

Mirja: Can you explain who you want to invite this? It wouldn't be people
already in the IETF?

Lee-Berkeley: It would not be IETF people except for some of you to come and
talk with people. We're looking at industry,

Mirja: So they would have to be local, right? Nobody is going to fly just for
this.

Lee-Berkeley: Right, but a lot of these companies are big and have people.

Mirja: Do you already have a list of concrete names?

Lee-Berkeley: We have a list of people who have agreed to help us outreach and
a small list of specific companies/other partners to target. The other audience
is building a rapport with other SDOs that may have partners in Japan, their
engineering partners, policy has flexible funding policies.

Andrew: The policy section of an organization has really different budgets, but
we look at policy at the same time as looking at stuff like the technical work
because some of what we do relates to policy, particularly when you look at the
security area etc. that does open opportunities for policy folks even in the
technical area.

Lars: How many people would you want as a minimum?

Lee-Berkeley: I've outlined this as 30-50.

Lars: I think even 30 is a reach in Japan. I think we need to be prepared for
it to be like, ten; are we going to go forward? The other thing is even if
companies have local offices in Japan, it doesn't mean the budget is there. And
talking to other SDOs I think is out, because they're definitely not going to
fund us. If the point is fundraising we need to think about fundraising.

Lee-Berkeley: We don't advertise it as fundraising, it starts with building
relationships. I'd argue it helps the entire SDO community if more people are
familiar with the process.

Lars: There is no SDO community. We're all competing. We must not invite people
from other SDOs except the ones we have really strong relationships with.

Warren: Have you met us all and are you comfortable putting us in front of
people?

Lee-Berkeley: One thing that's lovely is you all have a lot of passion and a
lot of knowledge. If we've organized the audience correctly there will be
people there with a divergence of interest areas and it will be useful to have
some of you there to talk to their specific interests.

Andrew: What are we looking at in terms of dress code? The IETF is very casual;
I need to know if I should pack special clothes.

Lee-Berkeley: We are who we are, and I don't think we need to pretend to be
what we aren't. Maybe no shorts that day. A step above normal, mostly.

Roman: How far in advance will we know the guest list and will there be a
dossier of information on them?

Lee-Berkeley: The idea was to do a little lookbook with a photo of the person,
their company, and thoughts on things they might care about or why they were
invited.

Lars: When do you think you can circulate a guest list? Then we on the IAB and
IESG can look at it and see who might be interesting to go.

Lee-Berkeley: I wanted to let you know about this so you have it on your radar.
We'll get invitations out in the next week or so and start getting responses
and we can build that lookbook.

Lars: The easiest way is if you have a spreadsheet you can share with who you
already have and we can give ideas for who to add.

Lars: We are a few minutes over time, but does anyone have anything else?

Éric V: Just a quick update on the homenet stuff; everything is going along and
it will probably close in two weeks.