Skip to main content

Narrative Minutes interim-2022-iesg-14 2022-06-16 14:00
narrative-minutes-interim-2022-iesg-14-202206161400-00

Meeting Narrative Minutes Internet Engineering Steering Group (iesg) IETF
Date and time 2022-06-16 14:00
Title Narrative Minutes interim-2022-iesg-14 2022-06-16 14:00
State (None)
Other versions plain text
Last updated 2024-02-23

narrative-minutes-interim-2022-iesg-14-202206161400-00
INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2022-06-16 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Andrew Alston (Liquid Intelligent Technologies) /  Routing Area
Jenny Bui (AMS) / IETF Secretariat
Roman Danyliw (CERT/SEI) / Security Area
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
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
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Applications and Real-Time Area
Colin Perkins (University of Glasgow) / IRTF Chair
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
Qin Wu (Huawei) / IAB Liaison

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
Paul Wouters (Aiven) /  Security Area

OBSERVERS
---------------------------------
Shuai Zhao
Greg Wood

1.2 Bash the agenda

Amy: Does anyone have anything new to add to today's agenda? Any other changes?

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes of the June 2 teleconference
being approved? I'm hearing no objection so it looks like those minutes are
approved. I saw final narrative minutes for June 2; is there any objection to
posting those as well? Hearing no objection, so we will get those posted as
well.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

     o Roman Danyliw to find designated experts for RFC 8809 (WebAuthn)
       [IANA #1229681].

Roman: That's in progress. I'm not even sure we need to do this at this point
but I'll get back to you.

     o Éric Vyncke to find designated experts for RFC 9250, "DNS over
       Dedicated QUIC Connections" [IANA #1230687].

Amy: Approving the experts Éric has identified is on the agenda for later in
the call.

     o Martin Duke to find designated experts for RFC 9260 (Stream Control
       Transmission Protocol) [IANA #1232030].

Murray: In progress; I found one so far.

     o Murray Kucherawy to find designated experts for RFC 9248
       (Interoperability Profile for Relay User Equipment) [IANA #1232225].

Murray: I've asked on the RUM list which has produced this RFC for volunteers
and I'm waiting to hear back.

     o Francesca Palombini to find designated experts for RFC 9209 (The
       Proxy-Status HTTP Response Header Field) [IANA #1232222].

Francesca: In progress.

     o Francesca Palombini to find designated experts for RFC 9211 (The
       Cache-Status HTTP Response Header Field) [IANA #1232214].

Francesca: We should have this as a management item today to approve experts.

   * 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 July 2022.

Amy: This is on hold.

     o Lars Eggert to facilitate an update of the document shepherd writeup
       form.

Lars: This is ongoing. I think I've rolled in everything that I saw in the PR
on Github. Rich Salz requested that we run the change to the IPR question by
Brad. I did that and I haven't heard back from Brad yet. I assume he'll say
it's fine, at which point I'll merge it. The other thing that's pending is that
Mark Nottingham was wondering why we have a separate question for Yang when we
don't have a separate question for other things like HTTP. I tried to explain
that it's not necessarily a feature that Yang has a separate question and he
argued that it shows IESG interest in the technology. I told him it's not that,
the purpose of the writeup is to get us the IESG information to make it easier
to review a document and if we feel that we need to ask the question about Yang
we should be able to do this, and if we feel we don't need to ask a question
about HTTP this should also be fine. I haven't seen a response based on that
but I'm hoping that resolved it. The short answer is that it's in progress
pending Brad getting back to me.

     o Lars Eggert to ask the Tools Team to push the global whitelist out
       to WG mailing lists again.

Lars: I think this on Cindy's to-do list if I remember correctly, but it's also
not prioritized super highly.

Cindy: The WG lists should already have it; that was done last week. There are
a number of non-WG lists that don't have it and I'm going through those to
figure out which ones should and which ones obviously don't. That's the part
that's still in progress. But the WG mailing lists should already have it.

Lars: Okay, great. I guess we should leave this open until you finish. But the
ADs mostly saw this with WG lists so we should not see bounces anymore. If you
still see bounces then let us know because something else is going on.

     o Murray Kucherawy to draft text for an IESG statement providing
       guidance about patch documents.

Murray: In progress. Should have it for you by the next telechat.

     o Lars Eggert to follow-up on the management of the IETF non-wg
       mailing lists.

Lars: I can't remember who I was supposed to follow up with . There was a
thread started on the main IETF list by John Klensin and I think I asked the
tools team whether the changes John suggested we make to make things better for
new participants are possible to do with mailman version 2 or whether they
would be easier with mailman 3. IE, I think he wanted the names of the
moderators shown on the mailing list webpage rather than just the owner's
alias. I think that needs to be done. Warren was going to send a script that
lets us figure out how many lists had recent activity, and for the ones that
didn't meet some sort of cutoff we didn't quite define yet, we were going to
suggest that they be closed and then focus our attention on the lists that were
still active to make sure they have good short and long descriptions. That will
take some more time. So I guess we'll leave that in progress.

     o Lars Eggert to send notification for last call for the Proposed
       Revision to the Tao of the IETF.

Lars: I sent that. There's a PR and the editors are working through it, so I
don't think we're quite ready to approve it yet. There's also an ongoing
discussion on gendispatch about what we should do in the future to maintain it,
and I think that's heavily leaning towards making it an RFC again and getting
rid of the special process we had. We're going to talk about this in
Philadelphia. We can mark this one done.

     o Lars Eggert to check with the Tools Team about whether improvements
       to mailing list descriptions should wait until after the upgrade to
       Mailman 3.

Lars: I don't think the descriptions need to wait, because that's a manual
action anyway. I think it was reflecting the list moderators by name, we were
wondering whether that's easier in mailman 3. This basically the same action
item as the one before this. I think we can mark this one as done.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-avtcore-cryptex-06  - IETF stream
   Completely Encrypting RTP Header Extensions and Contributing
   Sources (Proposed Standard)
   Token: Murray Kucherawy

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

Murray: I don't have to, unless the ADs who hold them want to. This should go
in AD Followup because I have to follow up on all four of them.

Lars: I just want to check briefly with Sabrina on the IANA not-okay thing.
Last time we discussed this was when Michelle Cotton was still there. There are
some cases where IANA would like an AD to hold a Discuss, and I don't quite
understand if this is one. I looked at the IANA review, Sabrina, and apparently
there were a bunch of questions from the expert and I can't tell if those have
been resolved or not.

Sabrina: Not yet, actually. We just sent it to the authors yesterday and we
haven't heard back.

Lars: Okay. So Murray, if you prefer, you can track that and I'll lift my
Discuss so there is one fewer. It was simply just to make sure that we know
what we're doing here.

Murray: I don't have a good mechanism to do that. It really deserves a Discuss
or something to block it. I guess I could pull my Yes but there's another Yes.

Lars: I'm fine with just leaving it on and you can tell me when [it's done].

Murray: Yeah, why don't you leave it and I'll follow up on all this stuff.

Roman: Murray, as a personal recommendation, I would say to keep it on just so
you don't forget; as someone that's approved a document because I forgot I had
an IANA issue on it and it needed to be reset.

Amy: Okay, so this will stay in IESG Evaluation and go to AD Followup.

 o draft-ietf-avtcore-rtp-vvc-16  - IETF stream
   RTP Payload Format for Versatile Video Coding (VVC) (Proposed
   Standard)
   Token: Murray Kucherawy

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

Murray: Paul's not here, so unless Francesca or Zahed want to talk about theirs
I don't think I need to. I just need to go back to the authors; this is another
AD Followup.

Zahed: For mine, I'm just a bit confused. We have been there, we've done this
for 64, and this is 66. It's the same kind of document having the same kind of
claims. I thought I'd just bring it to attention and see if we have a better
resolution. In 64, 65 we did this or something, or we can change it. I don't
think it's a big issue, I just wanted to see the author's response to that one.

Murray: Do you mean RFC 60something?

Zahed: It's the codec. All the codecs 264, 265, 266 have this format.

Murray: Oh, right. I think your questions are reasonable ones; I'll wait for
the authors to get back. They may have already; I'm behind on email.

Zahed: I kind of know what the answer will be but I still want to discuss it.

Murray: No problem. AD Followup is perfect.

Francesca: Just for your information, Murray, my Discuss was just to make sure
that the media type was sent to the media type mailing list. If you're okay
with it I'll let them do that and then wait to make sure there are no
objections and then remove the Discuss.

Murray: Sure; I don't recall ever demanding that that process be followed every
time. Do we require it for everyone or do we just strongly suggest that it
needs to be done?

Francesca: It is strongly encouraged, but I have kind of requested other docs
to do it as well. I don't stick with the two weeks recommendation, I think one
week is enough, but I would feel more comfortable if authors actually did that
since it's strongly encouraged.

Murray: Okay.

Amy: Okay, so this will stay in IESG Evaluation and go into AD Followup.

 o draft-ietf-sidrops-8210bis-09  - IETF stream
   The Resource Public Key Infrastructure (RPKI) to Router Protocol,
   Version 2 (Proposed Standard)
   Token: Warren Kumari

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

Warren: Yes please. I had a discussion with the authors and for [the question
of] why is this updating vs obsoleting, [they said] this is above their pay
grade and whatever you want to do, go do it. The initial reason for updating
was the WG does not want to signal that version 0 and version 1 are actually
not appropriate for use yet. Having it as obsoleted kind of implies that. This
is the problem that we've had before and we've generally just marked it as
obsoletes and hopefully people migrate over time. Idk if we want to discuss
that some more.

Martin: My main concern is that 8210, if I'm not mistaken, is completely
contained within this document so there's no new information in 8210. For that
reason I've convinced myself it should be obsolete. I appreciate the WG's
concerns, but I think that can be solved with a sentence in the abstract, or in
the introduction, that says 'v1 is great, please use it forever.' That would be
fine.

Alvaro: I was the AD for the other 2 versions. I think part of the problem is
the community that uses these specs. The RPI community is very sensitive to
what they specify and how it's being used and when it's being used. There was a
time when they wanted to put dates in an RFC, a "By September 2020 this must
happen" type thing. Of course I convinced them not to, but that's why they want
to keep all of them. The problem with obsoleting the other ones is that one of
the problems with this protocol is that the version numbers are carried in the
TLVs. If I'm running version 1 and you send me a TLV with version 2, even
though it's the same TLV, I won't understand it. In other words, even if 1 and
2 are very similar, it's just not backwards compatible.

Martin: It's been a week, so maybe I've forgotten; but if I'm not mistaken,
this document fully specifies both version 1 and version 2, right?

Rob: v2.

Martin: Just v2.

John: I think it specifies v2 in a way that's practically speaking compatible
with v1, but it does not strictly speaking specify v1 at all.

Warren: The authors have actually updated the document to say "This document
describes version 2 of the RPKI-Router protocol.  RFC 6810 describes version 0,
and RFC 8210 describes version 1.  This document updates and replaces 8210."

John: My own take on the obsoletes vs updates vs nothing is that I see the case
for obsoletes and to me that would be fine. I Didn't actually see anything in
the document that updated v1 at all, except as we've discussed before, updates
doesn't mean anything so it can mean everything. I guess in the author's mind
it somehow updated v1, but I don't see it.

Warren: I kind of think it's better to leave it as updates, personally. This is
also one of those things where the only people who are likely to care deeply
about it being obsoletes instead of updates are us. Whereas there might be a
bunch of people who would be annoyed if it obsoleted an earlier version. I
think we would be this much [fingers close together] annoyed if it doesn't
obsolete and some set of people will be this much [hands far apart] annoyed if
it does. It feels like instead of standing on our purity answer the authors and
WG think this is just process wonkery and we can do whatever we want to do.

Roman: My version of my confusion is that I was always under the impression
that updates is typically used when you want to make changes to an existing
protocol. Right? You published the other protocol and I want to make changes to
it. That's confusing to me because I've heard it both ways here that it's a
different protocol and it's not a different protocol. If v2 is in fact a
protocol that stands by itself, and can coexist with 1, I don't understand how
you can create this lattice of documents where the new protocol is not changing
the old protocol but it's updating the other protocol and there are no
dependencies between those two.

Warren: I think a fair bit of it is that when I use a word I intend it to mean
exactly what I intend it to mean, nothing more and nothing less. Updates can
either be if you read this document, you should also read that document. It can
be 'replace section 4 with section 5.' I think this is more that it simply ties
docs together.

Roman: Why would the docs have to be tied together at all? They're discrete
protocols.

Warren: If you read the version 1 document, it would be better to read this
version 2 document as well or instead. That's the only way we have to
realistically link docs.

Roman: I'm confused by that because I was under the impression that communities
can't just make the jump to v2, it's too hard, you can't update the stacks. So
why should I ever read that other document?

Warren: If you have a Greenfield deployment, go read this one instead.
Otherwise we should just be like, the IETF is done, it's hard to move from v4
to v6, let's declare success and close the whole thing down.

Rob: Warren, my question is, if you had a new Greenfield deployment, which
version should they deploy? Is it that they can just choose which they use, 1
or 2?

Warren: I think they should do the latest one.

Rob: Then it should replace the previous version and obsoletes is the right
choice. Because that is effectively an obsolete version, if the version you
should be deploying is v2.

Warren: I'll note that I think that but I'm not sure there is consensus.

Alvaro: This is not my document and you know, it doesn't matter, but I'm going
to go back to the community specific thing here. This is really adding a lot of
new functionality. But it's not completely implemented in the RPKI and
everything else. So if I get a  new cache to talk to my new router, I won't
necessarily use this new version. Because the new ASPA thing that is being
implemented is not supported in the RPKI. So I don't need that signaling yet
and I may still end up with version 1. Or even many of the caches still have
version 0 implemented.

John: Wait a minute though. Just because you're talking version 2 doesn't mean
that you have to send ASPA objects.

Warren: But you might. And you want the other side to understand that and not
explode if you do.

Alvaro: The carrot for the implementers to go implement something new is if
there's new functionality. If there's no functionality in the RPKI to go signal
anything new, why would the cache to router protocol have new signaling if the
old signaling is still fine? Part of the problem with this document is that
it's sort of running ahead. It's adding functionality that is not yet deployed
in the RPKI and all the routes so that we're ready for the future, but we're
not there yet. Unfortunately for whatever reason they made this protocol not
backwards compatible with all the versions in the TLVs. So I can't just add a
new TLV and everything is the same. At that point it would be a clear update if
I just added a new TLV. In this case they're redefining everything because all
the TLVs carry the version number.

John: I think Roman and others are right that if this ain't updates, and it
ain't obsoletes, then it's just nothing. But I do also agree that practically
speaking, it's useful to have a forward reference. Like Eric said in the chat,
people who enjoy this spec will also enjoy such and such; that's what we really
need. I guess my final comment is that even though I think the WG and authors
are wrong, it's your WG and if you think let the wookie win is the better way
to proceed, it's no skin off me. I'm not going to hold a Discuss on it but I
think the people holding the Discusses have the moral high ground if that's any
consolation to them.

Martin: Now that I understand this is not altering the v1 spec in any way, I'm
less passionate than I was. I naturally adhere to the TLS model which would
make me want this to be obsoletes. I think I'm in John's boat, let the wookie
win. That said, I'm holding a Discuss for a bunch of people so I could continue
to hold it if people feel more strongly than I do at this point.

Rob: I already had a communication with the authors earlier this week. I was
going to use Yang as an example, Yang 1.1 obsoleting Yang 1.0, but then I
looked up the RFCs and it doesn't do that. It's not applied consistently. I did
find a random IESG statement that sort of implies obsoleting is the right
choice here but at the same time, I'm happy not to die on this hill. The other
Discuss point I think I might be, but not this one. The other one was that I
don't like the fact that they are redefining a text field to be carrying binary
data. I just thought that was a bad choice for an error message. I think Randy
has potentially decided to do that a different way, I don't know.

Warren: I think he's posted an update; I can't remember if your text is in
that. From what I understand I think Martin is okay clearing his specific
Discuss, you're okay clearing half of yours, and I think Roman also had the MD5
thing again which is one of those ongoing sources of entertainment in BGP.

Martin: I would also like to clarify that Roman is okay with me lifting my
Discuss, because he did support it and I'm not sure where he's at on it.

Warren: I thought he had his own on that.

Roman: No I didn't, I was just supporting Martin. I guess part of this is a
little philosophical to pop it up. If we collectively think we want to let the
wookie win because the community of this document wants it that way, I guess I
would appreciate if everyone would clear their Abstains from the last telechat
where the IESG turned their nose up on a patch style that the CMP community
wanted on that PKIX document because we didn't think it should be written like
that and it was too hard to read. I pushed back that implementers actually are
reading it and that's what the WG wanted. I'm feeling a little inconsistent
here about when we're willing to bend it or not. It appears to be flexing on
whether we want to put in the time to review it in the way that the WG wants to
give it to us.

Zahed: Roman, I'm really seconding you on this point.

Warren: I will note that I did not abstain, I supported that document because I
thought that's what the WG wanted. But I think this is a very different
situation. This is not an editorial choice, this is the WG discussing this
particular topic and it is a different protocol, or a different use of the
protocol, not an editorial or readability thing. But also, are there enough
abstains that that document is actually stuck?

Roman: It is.

Warren: Wow.

Roman: People didn't ballot on it, and we have abstains. We have a plan, we
talked it through, and I'm going to bring it back to [June] 30 and there are a
couple of actions folks requested that the WG will make. Again, I'm not going
to die on this hill, Martin, you can clear. I'm also in favor that if the WG
really wants it that way for their community, that's fine. I would just ask us
to accept the argument to flex for the community consistently because we didn't
go that way last week.

Andrew: I will say, Roman,that from my perspective I abstained from that last
document because I found it to be completely unreadable. Versus this, I can
read it, and I support Martin's Discuss on the basis that it's not backwards
compatible and to me it's a new protocol. The reasons for htat abstain I put on
there, which I'm still holding to, are very different from my reasons for
supporting Martin's Discuss on this. Even after this discussion, if anything
I'm feeling more inclined to change my position to a Discuss. I do think they
are very different situations.

Roman: I'll stop here because we're not talking about that document, we're
talking about this document. When you have the two biggest CMP implementers who
are somehow able to produce code from the document, I find a lot of docs also
hard to read but the implementation community somehow figured it out. I don't
know. Thanks.

Martin: Should we have Andrew talk a little bit more about his concerns about
updates and obsoletes? Is that the state of things?

Andrew: I kind of look at things and go, if this thing is not backward
compatible and we're going tos ay it's simply an update, there are going to be
people who don't bother to notice that this is an update, go and read the new
one. Then you end up with potential implementations where people have
misunderstood updates vs obsoletes. This should work if it's just an update; it
may not be able to implement all of the functionality but it should still work.
Whereas, when it's going to stop working because it's not backwards compatible,
that to me isn't an update. Something has been obsoleted and no longer works if
you implement via the new one vs the old one.

Warren: Alvaro is right that there are only a small number of people doing
this. If we obsolete the old one, we are then signaling this thing is obsolete,
don't use it anymore, and if you use it you're doing something wrong. Seeing as
that's not the message that the WG wants to send, I don't know if that's what
it should do. Obsoletes means this is old, don't deploy it anymore.

Andrew: This is another interesting discussion. What does the term obsolete
mean to different people? To me, if I see obsoletes, I'm assuming that the new
protocol and if I want the old one I need to go by the obsoleted document. I
don't really get that same message from the word obsolete, but I understand
your point. It just makes me wonder whether or not there is something between
an obsolete and an update when you're making something that breaks backward
compatibility like that.

Warren: Clearly, it would be better if we had more useful labels, like
obsoletes and updates and something vaguely related.

Martin: I think there's a distinction between historic and obsolete. TLS 1.2 is
obsolete, it has been obsoleted by 1.3, but there's a lot of 1.2 out there. I
think the security community would prefer that people move to TLS 1.3, but
there are some people that won't for various reasons. Someone could do a
version of a protocol that's for IOT and is not in any way meant to replace the
previous version that's been for general use. So that's a different
relationship that is not obsoleting. If this is going to be read in a certain
way by the people who actually consume this document I think I'm ready to
relent. If I were king, as I understand it, v2 is an improvement on v1 and if
it wasn't for legacy deadweight people would use v2 because of the crypto
agility and over time as ciphers age out you'll have to run v2, because ciphers
won't have the crypto agility. Is that accurate?

Warren: Sorry, I was looking at Rob's comment. He put in a quote that 'The
"Obsoletes:" header indicates a replacement version of the same technology,
rather than a retirement of the technology itself.' This isn't really a
replacement version of the same technology, it's the same technology with some
other cooler features.

Rob: If it's not a replacement version of the same technology, shouldn't they
give the protocol a completely different name? That's a slightly extreme view.

Martin: Why would someone choose to use v1 other than deadweight legacy stuff?

Warren: Because they've got a lot of deployed things that are never going to
change, and v2 is providing features they don't need or in some cases don't
want.

Rob: But it's still okay to deploy TLS 1.2, I presume. I'm not sure you're not
allowed to use it because it's obsoleted.

Warren: No no no, I've had people tell me I'm not allowed to use that anymore.
Again, I also think the amount of pain and drama we've had discussing this far
exceeds the importance. I think a number of people will be irritable if we say
you have to use obsoletes instead, and there will be some fussing, but I think
they have more interesting things to do than fight this fight. I personally
think it should stay with updates because that's the forward reference we use,
as broken as it is.

Rob: Let me say it's up to the WG to decide, that's okay. But to go back to
Roman's comment, then I think we should apply that consistently and make an
IESG statement and say it's entirely up to the WG whether they want to obsolete
something or update something, and we're not setting any precedent. Otherwise I
wonder why this is an exception and yet in Roman's case it wasn't an exception.

Warren: Hang on, Roman's case was different. Roman's case was that we want our
document in this format that you all think is hard to read. This is obsolete vs
updates. I'd be fine with us saying the WG gets to decide stuff like that if we
could actually explain what any of these terms mean. But as Mirja and others
have shown, updates means whatever we want it to mean that day.

Andrew: I see these as completely different cases because my motivation on that
abstain was not about an update vs an obsolete, it was that I can't' read it.
To me that is a completely different issue. If this document was unreadable to
me I'd have abstained as well.

Rob: I think it's a slightly different point I tried to make, more about who's
meant to be enforcing these rules. Is it up to the IESG  to enforce them or is
it up to the wG to decide what they mean? That's the angle I was coming from.

WArren: We enforce all the rules, but the WG provides a strong signal on what
they think should happen. It's our job to try and follow that signal unless it
violates the rules. We're basically the auditors who go through and check. Not
that we represent what we think is right.

Roman: I don't want to take us to an extreme position here but between now and
March we're going to be the current IESG. If we're really flexing to let WGs do
what they want in terms of these tags, I'd appreciate less mail in my mailbox
so let's collectively agree we're not going to ballot between now and when we
switch the IESG about anything relating to updates tag or obsoletes and
whatever the WG wants, goes. That's what we're deciding here, effectively.

Warren: No it's not. That's extreme. This is an unusual document wanting to do
an unusual thing in a corner case. One of the features of the IETF is that we
try to do the right thing, not that we are a slave to the process. We aren't
IEEE. They have a different process that works for them, but they have a strong
process and follow it. Ours is that we try to do what we think is the right
thing and sanity over process. If you're trying to do something weird, you fall
into an odd spot between our poorly defined terms.

Martin: I don't think this is that unique of a case. This seems like an
incremental improvement and v2 is a strict improvement, but an incremental
improvement over v1. It's not like if we put obsolete on this, the protocol
police are going to come seize all the devices and throw them in the dumpster.

Warren: I have what I think might be a good compromise for everyone. I will go
back to the WG and say the IESG strongly thinks this should be obsoletes. Are
people okay with that? IF the WG says sure, we don't care, then it's obsoletes.
If the WG says no, we really think it should be updates, we'll let them do
updates. Does that work for everyone because we've been kind of on the fence?

Alvaro: If we do that, we would need to go obsolete the other version too.
Version 1, 6810. We had the same discussion years ago when I came with version
1. That's why I keep insisting that it's the community. In general, you're not
going to go burn a box because it runs an obsolete protocol, but these people
are. They are going to burn the box that has the obsolete protocol. That's why
for this specific community, whether we like it or not, and whether we know
what updates means or not, to them it means that they can still use the
protocol as soon as it's obsolete. There was this other draft on changing keys.
The specification told them how to change the keys, but they wanted to put
dates to make sure that everyone changed the key at the same time. I tried to
explain that no, the RFC tells you how to do it and you can go do it whenever
you want. They couldn't get that around them because the whole community that
does RPKI implementations and cache implementations is all sitting in the same
room at the same time. They're working on implementation and deployment and
specs all with one mind.

Martin: I guess the real tension here is that this community has a completely
different meaning of the word than the rest of the IETF and so there's a
tension between making this clear to this community vs an outsider coming in
reading this and not understanding. The words mean different things to
different potential audiences.

Alvaro: The word updates means whatever we want anyway.

Lars: Can we come to a conclusion on this?

Martin: Andrew, I guess I'm inclined to lift the Discuss after all this. How do
you feel about that since you were the most fervent supporter of that Discuss?

Andrew: I need to think about it. Honestly I'm almost of the opinion that I'm
about to change mine to a Discuss if you lift yours.

Martin: I'll just leave it for now.

Andrew: I'll discuss this with you on slack in the next day or two and let's
talk.

Francesca: For what it's worth, I don't think you should hold a Discuss for
others. You were saying before there are a lot of people who support your
Discuss and I don't think that's a reason. Other people can raise their concern
to Discuss.

Martin: The convention is that you put in a comment when you support a Discuss.
I guess this document isn't going anywhere for now anyway.

Francesca: But you can notify people you're lifting their Discuss and if
someone feels strongly they can raise their concern to a Discuss.

Martin: Okay. Andrew, why don't you raise yours to Discuss and I'll lower mine.

Andrew: I'll take your text and say I'm continuing Martin's Discuss.

Martin: If it were me, I'd call it obsolete and make it very clear in the
abstract the relationship to v1, but I don't want to micromanage this. I think
we've reached an interim resolution here in that this will remain in Discuss
until Adnrew is satisfied.

Warren: One clarifying question. If this one gets obsoleted, who's going to go
through and obsolete the earlier version, 6810? This obsoletes both?

John: Seems normal, I can't see why you wouldn't do that.

Warren: Because we discussed this when we reviewed 8210 and agreed then that it
was updates, not obsolete.

Martin: There's an inter-IESG consistency issue too which is another thing. I
think the resolution here is that I will clear mine, Andrew will raise one, and
we can continue discussing on the list.

Warren: Okay.

Amy: So this will stay in IESG Evaluation, with AD Followup.

 o draft-ietf-httpbis-binary-message-05  - IETF stream
   Binary Representation of HTTP Messages (Proposed Standard)
   Token: Francesca Palombini

Amy: I have no Discusses for this document, so unless there's an objection it
looks like this one is approved.

Francesca: Thank you, everybody, for trying the format. I hope it wasn't too
much of a hassle. I saw that Rob's comments are already addressed but I haven't
seen a response to Lars's or others, so I will check with the authors. This
will need a Revised ID. Does anybody have any feedback to give on the format?
By the way, Mark just sent an online validator for this type of format which in
my opinion makes it easier to just copy paste the comments and see if it can be
parsed.

Rob: I had some faff at getting it set up initially, but it was fine. In terms
of validating the markdown I submitted, the validator wouldn't check that. I'm
not sure why that was but I think I raised it on github. If we can get an
online validator and try to do this more generally, it would be great if we
could get this into the datatracker if we want to go ahead with it. I didn't
have any objections but it was such a light review it was hard to draw a
conclusion. It would be nice to do on a larger document.

Francesca: I've posted this online validator in slack which should make it
easier. I had the same problem in one of my AD reviews that I formatted wrong.
I think this will make it much easier. As for implementing this into the
Datatracker, I think that's a question for the tools team. I don't think all
WGs want to use this format so it shouldn't be the only format. I'm using kind
of a hybrid of some reviews that are a bit longer and formatted this way and
those that are shorter. I don't think it's really necessary to format it this
way either. It might be something to bring up with the tools team later.

Rob: My other comments on the process is that I submitted the first review. The
bit about going and checking what has already been raised to make sure you're
not raising duplicate issues, I'm not sure that should necessarily fall on the
ADs.  I don't mind saying please do this if you can, but we are more time
constrained than the WGs are.

Francesca: As I said this was best effort. It's kind of the same as checking if
anybody else has balloted the same thing after your review, which I try to do
after if I can.

Rob: Otherwise I'm supportive that if there are WGs that think this will make
their process significantly easier, it's not too much of a burden on ADs and us
trying to be a little bit flexible here is a good thing. Github is going to get
more and more traction so I think we should be trying to be nice.

Francesca: Thanks, Rob.

Amy: So I have that this document is going into Approved, Announcement to be
Sent, Revised ID Needed.

 o draft-ietf-masque-connect-udp-14  - IETF stream
   Proxying UDP in HTTP (Proposed Standard)
   Token: Martin Duke

Amy: I have no Discusses for this document, so unless there's an objection it
looks like this one is approved.

Martin: This will be revised ID needed. There are some good comments that have
already been addressed and Erik K's, I don't believe David has responded yet so
that's the main thing.

Andrew: I had a very similar kind of feeling on this, that I walk away with an
uneasy feeling but it's difficult to articulate it into a discuss. I'm prepared
to swallow it because I can't articulate it.

Martin:  I understand it gives you the willies and I appreciate you not
Discussing based on that. Erik made an interesting point that this is in many
ways modeled after http connect which maybe has some same issues.

Andrew: There is a big difference between TCP tunneling and when you're
tunneling UDP where somebody can authenticate to the proxy, spoof a stateless
packet and shove it back into your tunnel, but then again that's UDP.

Martin: I think Erik had some good suggested questions to answer about
targeting address and all that. We'll give him an opportunity to respond, but
put this into Revised ID Needed please.

Erik K: I debated whether or not to make that a Discuss, but you know, I went
through and the first thing I did was go through the connect text and there's
no consideration here for any of these kinds of concerns. Not that we need to
adhere to the past too much, but I ultimately decided that if we've lived this
long maybe people have figured some of this stuff out.

Martin: I think a little text in security considerations to address the
suggestion you made is a completely reasonable amount of work to do.

John: I just wanted to point out that someplace in the back scroll of chat,
Mirja made a suggestion that might be useful with some privacypass document she
thought was relevant. I don't have the background or competence to evaluate
whether it really is but she thought it might be a reasonable cite, so somebody
should probably take a quick look at that.

Martin: Thanks.

Zahed: I also raised my hand. I'm kind of one of the implementers of this
document and when I saw the Last Call review with an open question that's not
answered on the review, I reached out to our SEC ADs to get their view on
whether this is something to care about. My personal opinion is that when you
hear UDP you bring a lot of memories with you. Here we really mean UDP as a
substrate and basically we're using quic. That's at least what I'm
implementing. I'm not really concerned about if this is going to blow things up
but it's good to have the discussion anyway. We don't say you have to use quic,
just something to secure the connection. I think it's a valid point to distill
those things in the security considerations.

Martin: If anything that's a blind spot. I think we're thinking that when we
connect UDP we're actually moving quic. It could be RTP or a whole other thing.
It's a good observation that we've maybe not considered that very carefully.

Andrew: Had this said 'we're moving Quic,' my issue wouldn't have been there
because Quic has security on top of it. The fact that it said UDP made me think
it could be really nasty but I don't know how to articulate it.

Martin: THis is Revised ID Needed, I think we can move on.

Rob: One question though, wouldn't it be hard for the device to identify Quic
traffic? Isn't it quite tricky to know that it's Quic traffic and not UDP
traffic?

Martin: Yes.

Andrew: If you specify this should be Quic, at least you've got something in
there that says it as a clarifying note.

Martin: There would still be attack vectors though.

Andrew: There would be, yeah.

Erik K: There are still attack vectors with connect, right? You can still IP
scan all kinds of things from the proxy. Including the proxy itself, depending
on what implementations do. I did try to find a reference for something, I
think it was 6169, but there are probably others. Let me know if you want me to
change it to a Discuss if that helps.

Martin: When did you file this?

Erik K: A couple of days ago.

Martin: I wonder why he didn't reply; he's usually on it. It's fine, I'm not
going to let it pass until this gets addressed one way or another.

Amy: Okay, this will go into Approved, Announcement to be Sent, Revised ID
Needed.

 o draft-ietf-masque-h3-datagram-10  - IETF stream
   HTTP Datagrams and the Capsule Protocol (Proposed Standard)
   Token: Martin Duke

Amy: I have no Discusses for this document, so unless there's an objection it
looks like this one is approved.

Martin: This is really just Revised ID needed, there are just a few nits that I
think have already been addressed in the editor's copy so when they post a new
one, I don't think anyone has an unanswered email out there that is a problem.
This one is much more straightforward.

Amy: Okay, this will go into Approved, Announcement to be Sent, Revised ID
Needed.

 o draft-ietf-core-problem-details-05  - IETF stream
   Concise Problem Details For CoAP APIs (Proposed Standard)
   Token: Francesca Palombini

Murray: Francesca, do you want to talk about what I said or is that understood?

Francesca: I understood and I think the authors also replied to your mail. They
have just submitted an update answering the Discusses, so when you have time,
you can check that. Thank you. Anyway, this is the same comment to Paul as
well; I believe the authors have answered in the new update.

Amy: Paul was not able to be here today. Hopefully both Murray and Paul will
review version -06 when they have a moment.

Francesca: Okay.

Amy: Because version -06 was just uploaded, I'm going to put this in AD
Followup.

Francesca: That should be fine, thank you.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 o draft-koster-rep-09  - IETF stream
   Robots Exclusion Protocol (Proposed Standard)
   Token: Murray Kucherawy

Amy: I have no Discusses in the tracker, so unless there's an objection it
looks like this one is approved.

Murray: Please leave it in IESG Evaluation, Revised ID needed. There's a common
theme among all the comments I'm seeing about case matching and all that stuff;
I'll get that all sorted out before it goes forward.

Andrew: I just got an email from someone on the IESG list that noted they'd
fixed some of that stuff.

Murray: Yeah, Revised ID needed then.

Amy: I can put it in Approved, Announcement to be Sent, Revised ID Needed, but
I can't leave it in IESG Evaluation unless it has a Discuss.

Murray: That's fine.

Amy: I also have a downref for this document; do we need to add that to the
downref registry? RFC 1945, which is an informational doc.

Murray: Right. I'm surprised that one is not in the downref registry already. I
could go either way on this; it's so unlikely that anyone is going to refer to
such an old RFC again, given that there are other HTTP RFCs. We could add it,
but it's unlikely it's ever going to matter again.

Amy: Is there any harm to adding it?

Murray: Nope.

Amy: Okay, let's go ahead and add it.

Francesca: I did ask the authors to update that to the latest version and they
will be doing that.

Amy: This goes into Approved, Announcement to be Sent, Revised ID Needed.

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

 NONE

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

 o conflict-review-irtf-nmrg-ibn-concepts-definitions-00
   IETF conflict review for draft-irtf-nmrg-ibn-concepts-definitions
     draft-irtf-nmrg-ibn-concepts-definitions-09
     Intent-Based Networking - Concepts and Definitions (IRTF:
   Informational)
   Token: Robert Wilton

Amy: I have no Discusses in the tracker so unless there's an objection now, it
looks like this conflict review message can go back to the IRSG.

Rob: There is some related stuff to this in anima, but when I looked at what's
in this draft and in anima, I felt it was distinct enough there wasn't really a
connection. That's why I used that response.

Amy: Okay, I'm hearing no objection, so we will send that message to the IRSG
and this will go into Approved, Announcement to be Sent.

 o conflict-review-irtf-nmrg-ibn-intent-classification-00
   IETF conflict review for draft-irtf-nmrg-ibn-intent-classification
     draft-irtf-nmrg-ibn-intent-classification-08
     Intent Classification (IRTF: Informational)
   Token: Robert Wilton

Amy: I have no Discusses in the tracker so unless there's an objection now, it
looks like this conflict review message can go back to the IRSG. Okay, I'm
hearing no objection, so we will send that message to the IRSG and this will go
into Approved, Announcement to be Sent.

Lars: Before we move on, I think there's one other item that's looking for a
reviewer and for some reason it didn't get put under new items;
draft-santesson-svt.

Roman: I thought I took that and put it in AD Review.

Lars: I looked at it just now and it didn't look that way.

Roman: Did I push the wrong button? Maybe I didn't make myself the responsible
AD.

Lars: Exactly, you put it in AD review but you left it at me, so I want to fix
that for you.

Roman: Okay, just make me the responsible AD and I got it. Thanks.

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

 NONE

4.1.2 Proposed for approval

 o Source Address Validation in Intra-domain and Inter-domain Networks (savnet)

Amy: I have no blocking comments, so unless there's an objection, Savnet has
been approved as a new WG.

Alvaro: There are some comments Lars sent this morning that we're exchanging
email on. I think I'm going to end up pushing -04. If I understand correctly,
Amy, you would send out the message on Monday, is that true?

Amy: Usually WG actions get done a little bit earlier. We can absolutely extend
the time until Monday but it's usually Friday afternoon.

Alvaro: Okay, I'll work this out with Lars today.

Lars: I don't think it's a big issue. I just read the charter again and I'm
sorry I'm late with this. It's basically just a clarification on what future
processes are expected so we don't need to read a bunch of emails to figure out
what was meant in a year or two.

Alvaro: Right. There are a couple of sentences I want to update there. I'll get
that done and send you an email in a couple of hours when that's ready, Amy.

Amy: Great. Do you want us to move the milestones? Are those milestones still
good?

Alvaro: Yes please.

Amy: Then we'll have to update the text too so this will probably be version
-05 before it goes out. I think you have everything else that we need. With the
pending text changes and the movement of the milestones, this is approved.

Alvaro: Okay. Thank you.

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: Basically Eliot talked most of the time about how he intends to review
documents. Some of you picked up that he had some examples of documents that
are with the ISE that we recently discussed. I think Eliot is doing great.
There was a question he had about how do we prevent this cycle from IETF
telling somebody to take stuff to the ISE, and then Eliot thinks it would
benefit from being brought to the IETF for discussion, and there's a circle. I
told him I think the cycle needs to stop with him because it's not really a
prime motivation for the ISE to put stuff back to the IETF. Obviously if
someone has never talked to the IETF and he thinks it should go somewhere,
that's a good thing to do. But if it's coming from the IETF, telling someone to
take it back there doesn't seem awfully productive. That was the majority of
the call. Mirja and some of the liaison coordinators or managers want some
changes from the tool team about how liaison things are managed in the
datatracker. I asked her to include ADs that care, because we also interact
with that tool quite frequently.

Roman: If I could add one other thing from the IAB but not from the formal
meeting, it's that we have concluded doing interviews for the RSWG that were
joint IAB/IESG. We're going to convene next week to talk jointly and we'll
likely have some things to bring back the week after.

Lars: That would be great if we could make a decision on the RSWG soon. The
RSAG is basically in soft opening; the mail list is set up and everything but
we're waiting to pick a chair until the first meeting in Philadelphia.
Obviously we don't have an RCSE yet either but apparently there are some good
candidates the recruiting firm has identified and that's about as much as I
know about it.

Warren: My comment was about the earlier thing about docs going to Eliot. I'll
note that one of the standard ballot procedures that we can do on conflicts is
'the IESG has concluded this document extends an IETF protocol, blah blah blah,
and therefore should not be published without IESG review and approval.' We
have a bunch of other ones which have things that require IETF review and
approval. We need to be careful that whatever happens with that, it doesn't run
afoul; it's' not that it can never come back to the IETF for review. Just a
corner case.

Lars: That makes sense. Qin is on the call, who's IAB liaison to us. Qin, if
you remember anything the IESG should know, please let us know because I'm
blanking.

Qin: Nothing to add here, I think you covered everything.

6. Management issues

6.1 Final Approval for BoFs at 114

Amy: We have seven BoFs here. Does anybody think the BoF they are now
responsible for should not go forward for 114 and do we have a new acronym for
JSON Web Proofs?

Roman: Is there a new acronym? Sorry, no, not yet. I'll get that buttoned up
for you in the next day or two.

Amy: We need that before we can do any scheduling for it, so if it doesn't
happen in 24 hours, we're going to choose for you and it's going to be JSONWP.

Roman: I will work on it this afternoon, sorry.

Amy: Thank you, Roman. It sounds like these BoFs are all going forward and
we'll get them all into the datatracker.

Lars: One more suggestion; could we also find a different acronym for SAT,
since this is going to burn those three letters forever. SATP would be a little
bit better. Just in case.

Amy: Is SATP an okay thing for the AD who is shepherding it?

Roman: Sure. As you can see, SEC-overseen BoFs have a lot of things we're
juggling.

Amy: Okay, so we will work on getting all of those into the datatracker as
actual BoFs so that scheduling can begin.

6.2 [IANA #1232030] Designated experts for RFC 9260 (Stream Control
Transmission Protocol) (IANA)

Amy: This was assigned to Martin who is working on it.

6.3 [IANA #1230687] Designated experts for RFC 9250, "DNS over Dedicated QUIC
Connections" (Éric Vyncke)

Amy: Éric V has identified Sara Dickinson and Christian Huitema as the
designated experts for RFC 9250; is there any objection to approving them as
experts? I'm hearing no objection, so we will send the official note to IANA.

6.4 [IANA #1232225] Designated experts for RFC 9248 (Interoperability Profile
for Relay User Equipment) (IANA)

Amy: This item has been assigned to Murray.

6.5 [IANA #1232222] Designated experts for RFC 9209 (The Proxy-Status HTTP
Response Header Field) (IANA)

Amy: This item is assigned to Francesca.

6.6 [IANA #1232214] Designated experts for RFC 9211 (The Cache-Status HTTP
Response Header Field) (IANA)

Amy: Francesca has identified Mark Nottingham as the designated expert for this
registry. Is there any objection to approving Mark? I'm hearing no objection,
so he is approved.

6.7 [IANA #1232305] renewing early allocations for
draft-ietf-lsr-dynamic-flooding (IANA)

John: I've talked with the authors and WG chairs about it. This is a little
less cut and dried than most of my early allocation renewals. I'm still okay
with extending it; the WG is trying to figure out: do we publish this as
historic, do we publish it as experimental? Nobody has been willing to say they
want to let it die. Basedon that I think we need to extend these code points
and let them figure out what their plan is.

Amy: Is there any objection to extending the early allocation for this
document? I'm hearing no objection, so that is approved and we'll send that
note to IANA.

6.8 IETF 114 Agenda Schedule (Liz Flynn)

Lars: I think if we can limit everybody to two hours, we should be okay in
terms of being close to Vienna?

Liz: Mostly. If we limit everybody to only one session, one hour if they
requested one hour and two hours if they requested two or more hours, we could
almost stay at the same schedule we had in Vienna except we would need to add
one more 1-hour session block to one day.

Lars: Could we add that to Friday?

Liz: We could, but that would mean going until 5 pm on Friday.

Lars: Yeah, that's not great.

Liz: If Friday was a full day that would be exactly enough to have two 2-hour
blocks and one 1-hour block per day, which is mostly what Vienna had, but that
would be going until 5 pm Friday.

Éric V: If we start earlier on Friday with no side meetings, can we do it?

Liz: STart before 10 am on Friday only and then fit in six hours of sessions on
Friday? We could look at that.

Lars: Did we have a proper lunch on Friday or was that weird? I can't remember.

Liz: In Vienna there wasn't a proper lunch on Friday.

Lars: But if we went longer we would have to add lunch. Would that still work?

Liz: I would have to figure out exactly how the timing would work. Basically,
if we're adding back another half hour to lunch to make it 90 minutes, that
would be 6.5 total hours every day. We could make a 6.5 hour day on Friday but
shift everything earlier.

Lars: To me that seems like the least bad option, but I'd also be interested in
what others are thinking. Can you pull up the list of WGs that would get a
session cut? Or I can pull it up myself.

Roman: When you sent that note you asked if the ADs were okay. For SEC, if
cutting those oauth and rats sessions gets us all squeezed in, that's an
optimization for the entire IETF that's worth making. Thank you.

Martin: The schedule would be 10-5 every day, modulo the plenary. Then on
Friday we're talking about starting earlier so that we still wrap up at a
decent hour?

Liz: I'd have to check. If you remember, at meetings in North America there
isn't typically a continental breakfast included in the room rate so we provide
a snack break in the morning with breakfast food. We would have to make sure
that we leave time in the morning so that people can eat breakfast before
sessions since they won't be able to eat in the room. I'll have to check with
STephanie about the hotel side of that.

Lars: The one exception is also that the ANRW will need the two sessions
because that's a workshop and they have commitments for speakers and stuff.

Liz: Right. The number I sent includes keeping both those sessions for ANRW.

Lars: TO me, that sounds like the least bad option here. Maybe you can send
another email later today or tomorrow that has the details for that, that would
be great.

Rob: How late would the sessions be finishing on Friday and how late would the
IESG finish? I've already booked flights for Friday evening because I was
assuming we would wrap up sessions as before. I can miss the IESG meetings but
I'm just wondering if there will be other attendees who booked flights on
Friday.

Lars: We used to have the wrapup meeting on Friday breakfast, rather than
after. We did the after when we had short days on Fridays. It might be
worthwhile doing that so that people can get out. Obviously we can't cover the
Friday stuff but people wouldn't need to stay beyond the meeting.

Liz: Are you suggesting that you'd start really early Friday morning with a
wrapup breakfast, then a full day of sessions starting earlier?

Lars: Yeah, like in the good old days when we started at 7. Or you could just
come straight from the scotch BoF.

Liz: You might also want to talk to the IAB about that; don't they share your
wrapup as well?

Lars: I don't think the IAB has anything pressing to talk about on Friday so
they can also meet on Thursday if they want. I would prioritize the IESG wrapup
over the IAB. Can the IESG have breakfast at a breakfast meeting or do the IESG
also not eat in the room?

Liz: That's a good question. I'm not sure that's been decided either way about
group meals.  I'll talk with Stephanie and figure out the details for the
timing and send you all another email.

6.9 To Minute the Decision: NomCom Eligibility (Lars Eggert)

Lars: I think there's some confusion actually. I don't think we need to do
anything because we already sent this out for announcement. The question was,
for this Nomcom cycle, whether we count eligibility based on meeting attendance
by the meeting registration form data or by the new data that we get from
Meetecho about who actually attended sessions. I think I heard that we said we
would want to keep going based on meeting registration data, like we basically
did in the past, and that makes sense because that's what 8989 said and we're
going to continue that this year. I don't think we need to minute anything
because we already said we would do this and not change it. Does that make
sense, or am I confusing everybody?

Amy: It makes sense, but I found Path 1 in RFC 8989 and it is based on a
registered person being logged in for at least one session of an online IETF
meeting. I don't know if that throws a spanner in the works as to how you
understand what it was.

Lars: That is great because we actually didn't do this the last two years. The
second part, check that the record was based on who logged in. I don't think we
had the meetecho data until basically just now. We've always ignored this. But
this is a good find and now we probably need to send an announcement that this
was never done, blame the tools or whatever, and therefore we're also not going
to do it this time because we're going to repeat the experiment as it ran in
the last 2 years rather than something else. I'm mostly worried about changing
it this late into the cycle, as the Nomcom chair is already named.

Martin: I'm sorry, what are the criteria to say you attended a meeting?

Amy: It says in the RFC that attendance is determined by the record keeping of
the Secretariat for in person meetings and is based on being a registered
person who logged in for at least one session of an online IETF meeting.

Martin: But what is Lars proposing for the criteria?  It's not that, right?

Lars: I didn't know this was in the RFC. What was done is that they basically
went to registered for the meeting.

Martin: So what you propose is either you picked up a badge, or you registered
as a remote attendee, whether or not you signed a bluesheet.

Lars: Right. As far as I understand, that's what is usually done. For in person
people they remove the ones who didn't pick up their badge; but for remote
participants, both for fully online and hybrid meetings, what set the flag in
the datatracker was did they fill out the registration form.

Martin: So if someone registered in-person and then bailed to remote at the
last minute, would that fall through the cracks?

Lars: I don't know. That's a question for Robert.

Mirja: For me this finally changed my mind a little bit. I was with you on not
surprising the community by changing something late but apparently we always
did it wrong. That's a different situation.

Lars: It's very clear we need to tell the community that we always did this
wrong. That's an action item I can take on right now. The discussion is now,
what else do we want to say about what we are going to do for this year? Until
Amy brought this up I was of the impression that we can retreat to the line
that we'll keep doing it on meeting registrations because that's what we've
done in the past, but the RFC says we should have done something else.

Amy: I was very confused at that entire conversation last week, so that's why I
went looking for the RFC.

Lars: Thanks for doing that, since nobody else did, including me.

Amy: Well you've already sent a message to the community that you were going to
keep on keeping on.

Mirja: Maybe it's the right thing to say we're keeping things as they are for
this cycle so we don't introduce new mistakes by changing it, but we're also
working on changing it for the future cycles.

Lars: One reason we gave is that we want to have more data on how this
experiment works, and changing it now would introduce some bias into the data.
We do need to do something because 8989 doesn't let us do it again. I was going
to send email to gendispatch and basically ask for another agenda item to
discuss what we should be doing post-8989. The major thing that has me worried
is that if you combine the no questions asked fee waivers for remote
attendance, it's basically very easy to keep your nomcom eligibility up without
ever really participating. You could do the same thing if we checked meeting
registrations because then you would just have to log in to one session real
quick, but there is this loophole that it's actually pretty cheap to keep up
your nomcom eligibility without actually engaging in the community. THat's what
the nomcom eligibility is supposed to filter.

Martin: This requires a lot of re-thinking, I think. I'm going to put something
in the next retreat about this. We're not going to solve it here.

Mirja: It's a community discussion to have because there are also plenty of
people who are at a meeting but not really engaging in the actual work. Should
they be eligible? This is just how we defined it. If we want to change it it's
a community discussion to have.

Lars: There are two questions, one is how to deal with remote people, and do we
also want to change something for the in-person people? So far it was enough
that you just picked up your badge, you don't have to go to any sessions. Since
you need to use Meetecho to sign the bluesheet and get in the queue, we do have
that participation data for in person people too. I think that's a gendispatch
question. It's related to the 8989 discussion because we can't continue doing
it anyway.

Rob: I agree that running the experiment consistently makes sense. The one
comment I have is that as far as I remember, Path 2 and Path 3 hardly anyone
came through on those. Is that correct?

Lars: It was surprisingly few. One of them was a complete no and one of them
resulted in very few additional qualified people. I don't remember which was
which.

Rob: One question I would have is, given we know there are people registering
and not attending, whether that would change it. I Guess we don't need to
change the rules to find out that answer.

Lars: Robert could find out for us because he's done the comparison to see if
there are bugs in the tool that calculates eligibility. It might. Not based on
the few names I recognized that he mentioned to me, but there might be others.

Rob: Doing the same we've done before is fine but we might get pushback when we
announce that sto the community.

Lars: So I get an action item to send a message regarding 8989 Path 1 not
having been followed as it was described. I'm also going to send an email to
gendisaptch to point out that 8989 can't be renewed and the community should
think about what they want. Thank you.

6.10 Expedited Processing for the LISP Standard Documents (Alvaro Retana)

Alvaro: I know that we deferred the lisp document, which is okay, but I wanted
to bring this up now so that when those docs are ready we can just move with
them. Expedited processing usually means we ask the RFC Editor to put docs in
the front of their queue and get them out faster. In this case, what I want to
ask is not that full process, but for them to assign RFC numbers which usually
doesn't happen until the end closer to auth48. We received a liaison from ICAO
to publish the lisp base documents, they were approved over a year ago and
they've been sitting in the RFC Editor queue waiting for the lisp-sec document
which was on this week and the one that was a couple of weeks ago. WE still
need to resolve a couple of discusses there but we're close. They're going to
use lisp as a mobility solution and they want RFC numbers so they can refer to
it in their specification. It's going to come out sometime in Q3, meaning a
little bit after July, so they can refer to those two base documents. So what I
want to ask the IESG to approve is that when we can approve lisp-sec and
6834-bis, I will ask the RFC Editor for expedited processing which will mean
getting them to assign an RFC number, not to move all seven documents that
would be in the cluster to the front of the queue. It shouldn't delay anything
else but will expedite the process of getting an RFC number. Does anyone object
to this?

Warren: I don't object but I do have a question, and it seems likely I
misunderstood what they were trying to do. THis is simply that once we have
approved them, you would like the RFC Editor to give them a number and move it
faster? That's all?

Alvaro: That's all. And the documents they want to number, four are documents
that have already been approved by the IESG.

Warren: Okay. The concern with there being a number for the ones that have
already been approved is that those documents can't go forward until the
missing reference ones are done. Giving a number is then that people are going
to start referencing that number and there's no way we can claw it back. If
lisp-sec was not approved, people are still going to be referring to the thing
and using it. I thought this was more like please move the documents along and
approve them faster.

Alvaro: No, no. I got the WG and the authors lined up as fast as they can react
to anything that comes out of lisp-sec and close the pending discuss on 6834
bis. I believe Roman's and Paul's have already been resolved in the latest
version. We'll see what happens with lisp-sec in a couple weeks; if we can
address all the comments that great, and if not we'll do whatever needs to be
done and approve it later. Once those are approved all the documents should
start moving. That's when I would like to ask the RFC Editor to assign numbers
to the approved documents, yes.

Sandy: Just FYI, we would probably also expedite processing just so that when
people reference those numbers, they're not referencing documents that don't
exist yet.

Alvaro: Okay, great. I thought we had done the other thing before but that
works fine for me as well. So everyone knows, there are five documents in
cluster 381 that are waiting for these two documents I mentioned, so it's seven
documents total to move forward.

Amy: I'm hearing no objection to that way forward, Alvaro.

Sandy: Thanks for noting this, because if there is ac hacne that we can start
editing these while they're still in misref that's helpful to know which ones
to prioritize.

Alvaro: There's the 381 cluster and the next telechat is June 30. I was hoping
we can move the other two after that, so that's when we would request this.
I'll also send you a note about the ordering.

Sandy: Sounds good, thank you.

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

None.