Narrative Minutes interim-2021-iesg-18 2021-08-26 14:00
narrative-minutes-interim-2021-iesg-18-202108261400-00

\INTERNET ENGINEERING STEERING GROUP (IESG)

Narrative minutes for the 2021-08-26 IESG Teleconference

These are not an official record of the meeting.

Narrative Scribe: Liz Flynn, Secretariat

1. Administrivia

1.1 Roll call

ATTENDEES

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

Jenny Bui (AMS) / IETF Secretariat

Ben Campbell (Independent Consultant) / IAB Liaison

Michelle Cotton (ICANN) / IANA Liaison

Roman Danyliw (CERT/SEI) / Security Area

Martin Duke (F5 Networks Inc) / Transport Area

Lars Eggert (NetApp) / IETF Chair, General Area

Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe

Benjamin Kaduk (Akamai Technologies) / Security Area

Erik Kline (Google) / Internet Area

Murray Kucherawy (Facebook) / Applications and Real-Time Area

Mirja Kuehlewind (Ericsson) / IAB Chair

Warren Kumari (Google) / Operations and Management Area

Karen Moore (AMS) / RFC Editor Liaison

Cindy Morgan (AMS) / IETF Secretariat

Alexa Morris (AMS) / IETF Secretariat

Laura Nugent (AMS) / IETF Secretariat

Francesca Palombini (Ericsson) / Applications and Real-Time Area

Alvaro Retana (Futurewei Technologies) / Routing Area

Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area

Amy Vezza (AMS) / IETF Secretariat

Martin Vigoureux (Nokia) / Routing Area

Éric Vyncke (Cisco) / Internet Area

Robert Wilton (Cisco Systems) / Operations and Management Area

REGRETS

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

Jay Daley / IETF Executive Director

Sandy Ginoza (AMS) / RFC Editor Liaison

John Scudder (Juniper) / Routing Area

OBSERVERS

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

Prachi Jain

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 any objection to the minutes from the August 12
teleconference being approved? I'm hearing no objection. Any objection to
approving the final narrative minutes? I'm hearing no objection there either;
we will get both of those posted.

1.4 List of remaining action items from last telechat

     o John Scudder, Martin Duke, and Robert Wilton to review the document

       shepherd templates and propose changes to include updated questions,

       cross-area checks, and an expanded section on the use of YANG

       models.

Rob: I've not done anything yet.

Martin D: I wrote something a while ago; I think that's in John's court.

Amy: John couldn't be with us today so we'll just keep this in progress.

     o Alvaro Retana and Martin Vigoureux to draft a note to wgchairs

       asking them to always confirm author/contributor status.

     o Alvaro Retana and Martin Vigoureux to draft text to include in the

       I-D submission tool warning about too many authors.

Amy: These two both depend on the previous item so we're waiting for that one.

     o Éric Vyncke and Francesca Palombini to draft text for guidelines/

       best practices for directorate reviewers.

Francesca: In progress.

Éric V: We have a meeting next week on this.

     o The IESG to report on the RFC 8989 experiment after the 2021 NomCom

       is seated.

Lars: There's a Google document we're editing. If people haven't taken a look
yet, please do. There is a recommendation in there for discussion which is
basically to extend the experiment for another year. One reason is that all
meetings have been fully online so participants can only become Nomcom eligible
if that counts. Also these other two paths were defined, we don't have data;
one of them qualifies a lot of people but very few end up volunteering, and we
don't know whether that's a fluke or something structural. So give it a read
and leave comments. We're supposed to ship this to the community by September 1
so we don't have a terribly long time.

Francesca: I added some comments after your last email; I don't know if you've
seen them and want to discuss them.

Lars: I've seen them and I think I've addressed most of them and Barbara left
some comments as well. There are some left. They were good, thanks.

Francesca: Okay, we'll take it offline.

     o Murray Kucherawy to update BCP 97 to provide guidance about handling

       normative references to non-SDO documents.

Murray: I've started this by retrieving the text that makes up BCP 79 currently
from the editor and I'll put together a new updated draft that combines them
all. It has started.

     o Robert Wilton, Alvaro Retana, and Warren Kumari to report back to

       the IESG on the impact of COVID-19 to the IETF in October 2021.

Amy: This is for October so we'll mark it in progress.

     o Lars Eggert to update BCP 45.

Lars: I'm waiting for Rob to start the AD sponsoring process.

Rob: I'll be on PTO for a week and I'll pick this up in September.

     o Lars Eggert, John Scudder, Ben Kaduk, Mirja Kuehlewind, Murray

       Kucherawy and Warren Kumari to work on short-term improvements to

       "IETF Culture, Toxicity, Inclusion."

Lars: We haven't managed to get a meeting together. Let's say it's in progress
but at some point we should have a conversation about if we're going to do
anything. It seems to have gotten slightly better anyway since April, but
that's only my impression.

Mirja: You wanted to schedule a meeting for it.

Lars: I tried a while ago and we couldn't find a date. It's on me to find a
date.

Mirja: At least having some initial discussion makes sense before sending it
away.

     o Éric Vyncke, Lars Eggert, and Rob Wilton to work on improvements to

       authoring and reviewing tools.

Éric V: I'm back from vacation now and I should have more time to publish a
draft and initiate discussion. Work is in progress.

Lars: There's a broader activity here that may or may not subsume this. Jay has
been working on this authors.ietf.org site. One thing that plays in there is
this may potentially become the future home of the I-D Guidelines, which at the
moment we just moved to the IETF Github. Other author focused content like this
one might also move there. Jay would like to get a small standing team together
to work with him and Greg on this authors thing so the three of us plus anyone
else who wants to join might form that small team. Jay would like some subset
of the IESG to help them maintain that particular site.

Warren: I'm happy to help.

Lars: Let me follow up with an email to the list and we can figure out who
wants to be involved.

Mirja: Without trying to have the whole discussion, why is this a separate page
and separate effort rather than integrating more information into the
Datatracker, which I thought was the landing page for all author things.

Lars: The datatracker is not very pretty and it's not a wiki or a page where
you can read something easily. It's a database. The idea that Jay has is that
authors.ietf.org would be consolidating all the information we have in various
places like the wiki and elsewhere into one thing that Greg would maintain
going forward and we'd eliminate duplicate stuff. For example the I-D
guidelines we're in the process of revising have a whole bunch of text about
tools that you may or may not use as an author. There's another page on
tools.ietf.org that also talks about tools for authoring. I think Jay is
thinking that things should just be in one place.

Mirja: That's a good goal, but anyway let's not have the discussion here.

Lars: The goal is to move the other stuff, I think that's where he's going.

Murray: Put it all in one place.

Michelle: Lars, would it be helpful to have an IANA person or RFC Editor person
help contribute to making sure we have the correct information for authors in
our areas as well?

Lars: I think IANA possibly, given that there's already IANA stuff in the I-D
Guidelines. For RFC Editor that's a question mark. This is for I-D authors, so
in my mind the RFC Editor might have a small addition to whatever gets put on
authors.ietf.org, as your stuff gets published here's some other things the RFC
Editor will look out for.

Warren: The RFC Editor wrote the Style Guide, which is basically the first
place we go. Maybe not the tooling, but the RFC editor basically defines how
everything should end up. There's the IANA Considerations section as well so we
would need to make sure we have some input from that. I have some kind of
similar concerns to Mirja, not as to where the data goes, but we seem to have a
 number of things where new projects get started but aren't necessarily hugely
well organized with existing things. Like EMODIR and this spring to mind as
examples.

Lars: I'll let Jay defend his idea. This does not originate with me, I'm just
bringing it up because he asked me what I think. I think it looks all right but
there's a whole bunch of other stuff that needs to move there. Also, since
we're not having an in person retreat in that week of October because nobody
can travel, the idea was maybe to schedule some topical workshops or something
in that week. Like two hour slots to avoid bad time zones and one topic could
certainly be this. There might be some other topics to discuss between the
IESG, IAB, and LLC, and this is one of them.

     o Francesca Palombini to find designated experts for RFC 9039 [IANA

       #1201198].

Amy: This is a management item for later in the call.

     o Murray Kucherawy to send the proposed updates to the I-D checklist

       out for community review.

Murray: That went to the WG chairs list a week or more ago. I guess sending it
out for review is done. That spawned a conversation about what we do with the
feedback, which I think is what Lars was referring to, that Jay and Greg are
talking about folding that whole process into the new tools thing. I think we
can call this done and Lars, you added a management item to discuss that.

     o Francesca Palombini to find designated experts for RFC 8984 [IANA

       #1205430].

     o Francesca Palombini to find designated experts for RFC 9073 [IANA

       #1206462]

     o Francesca Palombini to find designated experts for RFC 9074 [IANA

       #1206466]

     o Francesca Palombini to find designated experts for RFC 9100 [IANA

       #1207182]

Amy: Francesca has suggested designated experts for all of these items and
we'll cover them in the management items section.

2. Protocol actions

2.1 WG submissions

2.1.1 New items

 o draft-ietf-bier-te-arch-10  - IETF stream

   Tree Engineering for Bit Index Explicit Replication (BIER-TE)

   (Proposed Standard)

   Token: Alvaro Retana

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

Alvaro: No, I don't think we need to discuss this today. This shouldn't be too
hard for them to address so I'm going to let the authors respond to the
Discuss. Other than that, we will need a Revised ID for this one.

Éric V: Out of curiosity, is there any other protocol related to this? Like
Yang modules? It looks like it's a standalone architectural document, not
backed by any followup.

Alvaro: There is some general Yang module for BIER that's being worked on, and
they're adding on the TE parts to the module.

Murray: I have a quick question about the tools. Since this came up. Rob
originally discussed it and then cleared it after Alvaro sorted it out, and
then I almost tripped on the exact same thing. I wonder if there's something we
should do with how the RFCs are presented so we don't trip on this again. For
those who weren't following, the issue is that it looked like we were doing a
proposed standard that extended an experimental, which should raise red flags,
but the base document had its status changed and that wasn't obvious to either
Rob or me when we were doing our reviews. Rob raised a Discuss and I was about
to raise a Discuss but this actually has been done right, it's just that the
tooling was ambiguous. So I wonder if there's something to fix here.

Ben: The HTMLized version has the color coded bar at the top, so bluish purple
is proposed standard and yellow is experimental.

Murray: Apparently bluish purple is not as attention getting as black and
white. Maybe that's the problem. Should it be bold blinking red? I don't know.
But I missed it as well as Rob, that's all.

Lars: Also the Gen-ART review from Robert Sparks has a lot of nits that they
should get to and they haven't replied to.

Rob: Do we know of any plans to  implement this?

Alvaro: As far as I've heard, yes, there are some plans to implement it. I
don't think there's anything in a shipping product yet.

Rob: Thanks.

Roman: So you think it's then reasonable, since there's no shipped product,
that we should be able to strengthen the security requirements? I'll let the
authors answer.

Alvaro: I'll let the authors answer as well.

Amy: Okay, so this will stay in IESG Evaluation, Revised ID Needed and we'll
move on.

 o draft-ietf-httpbis-bcp56bis-14  - IETF stream

   Building Protocols with HTTP (Best Current Practice)

   Token: Francesca Palombini

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

Francesca: Thank you, everyone, for the reviews. It will require a Revised ID
before it goes out to address the comments. I believe that Mark has answered
everybody and he has been implementing changes in Github, so if you want to
follow up you can do that on Github or answer him directly.

Amy: Okay, so this goes into Approved, Announcement to be Sent, Revised ID
Needed and you can let us know when that's ready.

 o draft-ietf-dnsop-rfc7816bis-10  - IETF stream

   DNS Query Name Minimisation to Improve Privacy (Proposed Standard)

   Token: Warren Kumari

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

Warren: Yes please, Paul Hoffman, one of the authors, has sent some text which
he hopes will address Eric and Erik's concerns, which is basically that we need
to ask for some sort of record and they're suggesting we just say instead an
address record "A" or "AAAA." Honestly, the main thing is, one needs a record
that's likely to exist. At the moment, A is much more likely to exist than
AAAA. but if we say an address record "A" or "AAAA," over time implementers can
choose the one that makes sense.

Éric V: Paul's suggestion for the text completely agrees with me, so as soon as
they publish I'm clearing my Discuss.

Warren: Excellent, thank you very much. So I guess, Revised ID Needed.

 o draft-ietf-mmusic-rfc8843bis-04  - IETF stream

   Negotiating Media Multiplexing Using the Session Description

   Protocol (SDP) (Proposed Standard)

   Token: Murray Kucherawy

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

Murray: Revised ID needed, at least for the thing Lars found that's a missing
reference. Otherwise this is good to go.

Ben: Are you going to verify errata 6437?

Murray: Yes, but that's not on them, that's on me.

Amy: Okay, so this is Approved, Announcement to be Sent, Revised ID Needed.

 o draft-ietf-httpbis-proxy-status-06  - IETF stream

   The Proxy-Status HTTP Response Header Field (Proposed Standard)

   Token: Francesca Palombini

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

Francescsa: I believe there's a discussion going on with the authors, is that
right Ben?

Ben: Yes, that's correct.

Francesca: So maybe we don't need to discuss it. It will require a Revised ID
but staying in evaluation for now.

Amy: Okay, IESG Evaluation, Revised ID 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

 NONE

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD

3.2.1 New items

 o draft-housley-ers-asn1-modules-02  - IETF stream

   New ASN.1 Modules for the Evidence Record Syntax (ERS)

   (Informational)

   Token: Roman Danyliw

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

Michelle: This is a case where IANA asked Roman to hold a Discuss for us,
because we're waiting to hear back from the expert.

Roman: I will push that in the Datatracker to Discuss that document.

Michelle: Thank you. There was a conversation on the IESG mailing list between
Lars and myself about when a version changes for a document in the datatracker,
if we have a state in there for the IANA review field, and it says IANA OK, if
the version changes that will change and it will say Version Changed, Review
Needed. We don't actually get the version changes for every single document or
we'd be buried in email. So just so you all know, before a telechat we do the
review and make sure all of those states are up to date. If we have a problem
where we don't think the document should be approved because we're waiting for
expert review, or there's still text in the document that's confusing, or
something needs to be done, usually we'll reach out and ask you to hold a
Discuss. If there are any questions let me know, or if we want to do it
differently we can have discussions. Just wanted to make sure everybody knew
that.

Lars: Just to put it succinctly, Michelle, IANA will ask for a Discuss to be
held when they want to, right? So we shouldn't proactively do it?

Michelle: We usually will ask. Looking back in history we'll mostly speak up on
the telechats and ask you to hold a Discuss for us. If there's something big
going on and it's really clear that the document isn't going to progress
because of an IANA issue, sometimes ADs have just gone ahead and put a Discuss
in there. In most cases, we've asked for it.

Roman: And for other ADs, I strongly encourage you to follow his process. As
someone who previously had a document which had an issue with IANA in addition
to other Discusses, I worked really hard to clear the Discusses and then forgot
we still had an IANA issue and released the document. We had to rewind. So it's
just self preservation for you, for state management.

Michelle: Roman, we'll follow up and let you know if we're having trouble
reaching the expert. We've pinged him but we might reach out to you to help us
out.

Roman: Absolutely. I'll reach out to the expert as well.

Michelle: Thank you.

Amy: With Roman going to Discuss position on behalf of IANA, it sounds like
this will probably require a Revised ID.

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

 o conflict-review-irtf-icnrg-icnlowpan-00

   IETF conflict review for draft-irtf-icnrg-icnlowpan

     draft-irtf-icnrg-icnlowpan-10

     ICN Adaptation to LoWPAN Networks (ICN LoWPAN) (IRTF:

   Experimental)

   Token: Erik Kline

Amy: I have no Discusses for this IRTF document, so unless there's an objection
we can send the conflict review message back to the IRSG. I'm hearing no
objection, so we'll send that.

 o conflict-review-irtf-icnrg-nrs-requirements-00

   IETF conflict review for draft-irtf-icnrg-nrs-requirements

     draft-irtf-icnrg-nrs-requirements-06

     Design Considerations for Name Resolution Service in ICN (IRTF:

   Informational)

   Token: Warren Kumari

Amy: I have no Discusses for this IRTF document, so unless there's an objection
we can send the conflict review message back to the IRSG. I'm hearing no
objection, so we'll send that. Warren, the note in the tracker has an editorial
comment to the IRSG; do you want us to remove that before we send it?

Warren: Yes please.

Éric V: Is there a chance to add DNSSD as well in the list of potential overlap?

Warren: Sure, I can do that now. Does anyone object to me adding DNSOP/DNSSD? I
don't think we need to do anything from a process standpoint, do we?

Amy: No; if someone has a problem with it they can speak up now. With that edit
to the conflict review message note, we'll get that sent back to the IRSG.

3.4.2 Returning items

 NONE

4. Working Group actions

4.1 WG creation

4.1.1 Proposed for IETF review

 o Oblivious HTTP (ohttp)

Amy: I have no blocking comments, so unless there's an objection now this can
go to IETF external review.

Francesca: I do have questions. This is pending some edits, and proponents have
answered not all but most of the comments received. There was one comment that
was about the name of the WG, and this also came up yesterday during the IAB.
Also during the BOF meeting there was a rough sense in the room that the name
does not help; it's not super clear. Many people had brought up changing the
name. [audio cut out for a minute] I wanted to know process wise, if we agree
on a new name and everyone is more or less happy with it, and I submit the same
charter under the new name and then I would restart the rechartering process?
Since this charter is approved, if possible I'd rather avoid two weeks of delay
for IESG evaluation before it's ready for external review. So I don't know if
there's a way to do this easily.

Amy: You can change the long name with no trouble, you can change that at any
time. It's the acronym that's [difficult]. If you want to keep the acronym
OHTTP and call it something else, you can change it at any point in the process.

Francesca: It would be strange to have another name with OHTTP as an acronym.

Éric V: I remember we had the same discussion for DRIP; the mailing list is
still the old name. We changed the name and acronym during the BOF and
chartering process.

Francesca: Did you change the name and the acronym?

Éric V: Yes, exactly. I don't know what the secretariat did. The mailing list
is still TM-RID but the WG shortname and long name is now DRIP.

Francesca: I think we can keep the mailing list OHTTP; I have a WG, CALEXT,
which has a different list name. I don't think that's a problem.

Warren: I formed the DPRIVE WG and the email list was called dns-privacy I
think. We had a lot of problems where people would send mail to dprive@ietf and
complain.

Éric V: That's easy to fix with an alias, right? That's been fixed for DPRIVE
and now that's an alias for dns-privacy.

Warren: There was some issue with the alias; it made DMARC sad or something.

Francesca: Just to be clear, I don't think it's a problem for the mailing list
not matching the name of the WG, because we have experience with that and it
makes sense to keep the mailing list. We have a number of choices, the first
one is to not change the name or acronym and keep it as is, which from what
I've heard is not what people prefer. The second one is to just change the name
and keep the acronym and mailing list, so this would be something like Relaying
HTTP for Application Privacy and the acronym will be OHTTP, which may be a bit
confusing but it's a possibility and wouldn't require for me to submit a new
charter and restart the whole process. The third option is to change the name
and the acronym. I think those are the options. The fourth would be to change
the name, acronym, and mailing list but I'm not sure we need to go that far.
Cindy wanted to say something before?

Cindy: I think you were starting to allude to a concern about the timing if you
changed the acronym and having to go through the entire process again and wait
for reviews. We can fudge our way around that; it's just that the new
Datatracker record with the new acronym will have to move through all of the
states, so review messages would still go out. The external review one, it
would be very good if we have the correct acronym before that goes out so we
don't have to send a second external review message with a new acronym that has
a weird timing on it.

Francesca: That's why I'm bringing this up now, so we don't send this out for
external review yet.

Zahed: What is the problem with the fourth option? I think that's the best one.
If you do change this, change everything, before you go out for public review.

Francesca: I don't think changing the mailing list is absolutely necessary,
because we have WGs that have different ones.

Zahed: To me, nothing is necessary here. If some people have a problem with the
name. If you still call it OHTTP it won't really matter what the big name talks
about, it's just in the charter.

Francesca: If the name doesn't really matter, I'm also very good with keeping
the same name because that simplifies things for me and the Secretariat. I was
just answering some comments I've gotten from the IESG and IAB.

Zahed: If we care about those comments and you really reflect on it, the fourth
option is what I would go for, before you go for public review. That's my
opinion.

Francesca: Okay. Any more opinions on that, or changing the mailing list as
well? I personally don't think that's absolutely necessary.

Warren: I think changing mailing lists could result in people saying we're
trying to censor their old views or something like that.

Mirja: Having a mailing list that's named differently than the WG has been
confusing, like manycouches and shmoo and so on. I keep sending mails to lists
that don't exist. But you could fix that by creating an alias.

Warren: Or, keeping the acronym the same.

Lars: You can create a new mailing list and have the secretariat transfer over
the subscribers. So basically nobody is unsubscribed.

Francesca: Is that possible?

Amy: Yes.

Zahed: You can write all these things in your external review, right?

Francesca: Yes. Or even when the start chartering process mail goes out, I can
explain all of this absolutely. That's good. Okay, so then I guess we keep this
as it is right now. Thank you for the comments and I will follow up on the
edits, and I'll also try to find a better name with the proponents and with
those of you who had comments about it. I didn't want to find the name in the
mailing list if that's okay. I'll just try to come up with a better name and
make sure that those who commented on it are happy with it and then send it out.

Mirja: I think that's a very good plan. I think that's also what we've done for
other groups that we renamed last minute.

Lars: I agree. You're still going to get the name discussion anyways but you're
trying your best to avoid it.

Francesca: Yes. I don't want to get stuck there. I'll ask some or all of you to
reballot when the time comes so it can go to the next step, even if we don't
have a telechat in between.

Amy: Okay, so it sounds like external review for whatever OHTTP will become is
approved pending edits and the name change. If you have questions, let us know
and we will help you through the process. Most of the work will be from us, we
just need confirmation on what to do.

4.1.2 Proposed for approval

 NONE

4.2 WG rechartering

4.2.1 Under evaluation for IETF review

 NONE

4.2.2 Proposed for approval

 o Application-Layer Traffic Optimization (alto)

Amy: This has a block. Martin?

Martin D: Yeah, from a name argument to an extensional one.

Lars: Let me start off by saying this is clearly not a Block I can hold. This
is so we have a discussion. I will abstain on this. But I wanted to make the
point that I made privately before this, that for me this is under the bar
where we need a WG. It's your call. On technical grounds, there's nothing to
block it on.

Mirja: I have to agree a little bit with Lars, especially because I read this
email from the people from the WG and they clearly don't understand what the
purpose of a WG is. The purpose of a WG is writing RFCs and defining standards,
not just having people meet and talk.

Martin D: For those of you who haven't followed along, when I took over ALTO I
asked does anyone use this thing? People said yes, there's this and that and
another thing, so I said great. We brought in a new chair. Over time it became
obvious that all those deployments were proof of concept. There were a bunch of
extension proposals that I didn't think there was a point in doing. What this
charter is trying to do is trying to clean up what's there, to have an
operations document. There's a very hacky HTTP1 based server notification tool
that can be replaced by push, and so the idea here is to do that sort of basic
cleanup while supposedly there are some big trials going on, to allow them to
assemble a case that this is actually going to go somewhere. If that doesn't
happen in a year or so then we close it. I think there's a reasonable argument
that we could either close it right now or put it on ice, like we've done with
RMCAT, and just wait for this stuff to come up rather than generate more
documents. I'm somewhat sympathetic to that and Lars and Mirja made their
points, which is actually quite meaningful to me, but I don't know if other
people have thoughts on how to proceed.

Zahed: I wrote my comments on the ballot. I think I kind of agree with Lars and
Mirja. We don't need a charter to focus on the future use case discussions; you
can do it in a separate thing. You don't need a charter to do that. Another
comment I have is that RMCAT is on ice not by us, but by the WG, at least
that's what I understand; they don't have the energy to take on new work or
they just want to finish what they have. I don't see ALTO in the same category,
because people who have been in ALTO want to do a lot of things and they don't
like to go in a different direction than where ALTO was aiming for. That's my
concern, they don't know where they're going right now but if in the future
they might discuss this and find out ALTO is not the right option for them. I'd
like to have those discussions in separate fora where the same people with the
same kind of goal and mindset can see if ALTO is the answer for them rather
than dragging out the feature. That would be my comment.

Mirja: I really don't want to influence your opinion here; it's your decision
and you do what you think is right.

Martin D: No please, influence.

Mirja: I want to give you one thing for thought. One of the main reasons for me
to try to close ALTO was because it was a pain in the ass to get the documents
out. There were a small set of people who were all authors and there was no one
left to review and it was really hard to make progress. That was my main
motivation to get things done and close it.

Martin D: I'm of two minds. From a purely objective, unfeeling perspective, I
really agree with Lars and Mirja. From a human perspective, because I did not
understand the status of things, I've led the group down this road pretty far,
and now to say forget it feels a little jerkish. Maybe it's the right thing to
do, I don't know, rather than create more documents people don't really need.

Lars: If you want to give them a small charter, with a little runway, you're
going to have to have that conversation with them anyway. This feels like a
small community that's living almost in an alternate universe where ALTO
matters. You're going to get the same problems down the road with them so
anytime you can restart this discussion, if you want to give them a small
charter extension. Nothing will change in the deployment of ALTO on the
internet as far as I can see, so six months from now it will be the same thing.
Twelve months from now it will be the same thing.

Martin D: You mean under the current charter, just extend it and see what
emerges, rather than work on these new documents.

Lars: I think you're going to see a bunch of discussion about stuff that
doesn't matter. There was an email just now saying to talk to the SIGCOMM
workshop and extend ALTO in that direction. That sounds very much like a
research group, not an IETF WG. They're not helping their case by the way
they're arguing. But it's your call, so I'm going to abstain on this one.

Mirja: My advice would be to even scope the charter down. Just focus on one or
two documents, be clear it's just that one or two, and see how that goes and
have another rechartering discussion in a year or so.

Roman: My other tangential advice is related to the problem Mirja was
highlighting, that I've also found in several of my WGs. When they ask for a
recharter, I set a slightly higher bar where I said you can cover more ground
and do more work, but I need to hear there's more push and proponents than any
of the people previously authoring the last set of documents or saying they
were going to participate in these documents, to show there's sufficient energy
to bring them to closure.

Martin D: Lars asked a good question in email, that they do want to do this
operations document but is anyone asking for that and do we think it will
actually improve deployment? That's a good question. Lars, just leave your
block there for now.

Lars: Too late, I abstained.

Roman: I'm really sympathetic to the position you're in, because this is a
foundational question of rechartering WGs: is anyone running code? Is anyone
going to do something with it? It's a very slippery question and I don't think
you alone are struggling. This is not just an ALTO problem. We have a number of
things and we treat them inconsistently for all kinds of reasons, and that
confusion creates pockets in areas. I want to be clear I'm as guilty of this as
anyone else. That creates some of this confusion around what is really the bar
to continue work?

Martin D: I think I have to have another real talk conversation with the
chairs. Why don't we just put this in AD Review or the equivalent of followup.

Murray: Since everyone has their own versions of advice, I'll offer mine.
Recently I found dealing with a dead WG that doesn't want to die almost as
frustrating as dealing with contentious WGs. It's such a pain when people say
no no, I really want to do the work, this is really important, and then nothing
for months. I'm at the point where in March I may or may not be reappointed and
I don't want to hand those to the next person. I'm trying to clean all this up
and only leave WGs who are actually going to produce something meaningful. I
don't know if that sways you either way.

Martin D: This has all been really helpful. I'm not going to rubber stamp this
at this point, I'm going to have another conversation with the chairs. Everyone
brought up some good points. You'll see something occur in a few months,
probably, one way or the other. Thanks, everyone, I have what I need.

Amy: Okay, so we'll wait for you to tell us what to do next.

5. IAB news we can use

Martin V: Nothing specific to report, unless Mirja wants to raise something.

Mirja: I don't think there's anything that needs to be flagged.

6. Management issues

6.1 [IANA #1201198] Designated experts for RFC 9039 (Francesca Palombini)

Amy: Is there any objection to approving Jari Arkko and Jaime Jimenez as
experts for this registry? I'm hearing no objection, so we will send an
official note to IANA.

6.2 [IANA #1206884] Renewal for early allocations for
draft-ietf-idr-te-lsp-distribution (IANA)

Alvaro: I think we should approve it. Like many other IDR and BGP documents we
require two implementations; as far as I know there are two implementations of
this and they are getting ready for WG Last Call to progress this soon.

Amy: I'm hearing no objection to renewing this early allocation so that's
approved and we'll send a note to IANA.

6.3 [IANA #1205430] Designated experts for RFC 8984 (Francesca Palombini)

Amy: Francesca has identified three people. Does anyone have an objection to
approving Robert Stepanek, Neil Jenkins, and Michael Douglass as designated
experts? I'm hearing no objection, so we will send a note to IANA.

6.4 [IANA #1206462] Designated experts for RFC 9073 (Francesca Palombini)

Amy: Francesca has identified Ken Murchison and Michael Douglass. Any objection
to approving them as designated experts? I'm hearing no objection, so we will
send a note to IANA.

6.5 [IANA #1206466] Designated experts for RFC 9074 (Francesca Palombini)

Amy: Francesca has identified the same two experts for this one; any objection
to approving Ken and Michael for this as well? I'm hearing no objection, so we
will send a note to IANA.

6.6 [IANA #1207182] Designated experts for RFC 9100 (Francesca Palombini)

Amy: Francesca has identified Ari Keranen and Carsten Bormann as designated
experts for this registry. Any objection to approving them? ​​I'm hearing no
objection, so we will send a note to IANA.

Francesca: I just wanted to say that I used what Michelle and Zahed have been
working on for mails to experts. Thank you for that. I just wanted to report
that I have been using it and it's been very helpful. I haven't used it with
everybody because some experts already knew, but I made good use of it and
thank you.

Éric V: On every formal, we go through all these as RFC XX, but I don't know
them by number. Can we put the name of the RFC, and the name of the registry,
there?

Francesca: For some of them, the registry name is right here, SenML Features.
It was in my email. If you put that in your email it will make it to the agenda.

Éric V: It would be nice if all of us were doing this. Thanks in advance.

6.8 HotRFC for IETF 112 (Lars Eggert)

Lars: You probably saw the email from Spencer Dawkins wondering whether the
IESG would restart HotRFC in some form. Nevermind that there's some unclarity
whether Aaron Falk started it or the IESG at the time. It was useful when it
was in person, that was feedback we got often, and the question is whether we
want to restart it in some fully online form or not? If we did restart it, my
initial thinking is that I wouldn't want to make it a session, I would
basically task someone with collecting pre recorded video clips of a certain
length and make them available on some webpage before the IETF meeting. HotRFC
never allowed for questions anyway so there's no point having an interactive
session for it. That would be a format I could see working. I don't know if
this needs to be owned by the IESG but I guess Spencer at least feels we should
delegate it somebody. We could call for community members or ask Aaron if he
would like to do it again in this format and have a HotRFC for 112.

Mirja: My memory of this is a little different than Spencer's. This was very
much driven by Aaron and the IESG only approved giving him room for it and
adding it to the agenda.

Lars: That's what I remember too but Spencer remembers differently. I guess we
could put an email out asking if anyone wanted to organize a HotRFC style event
and if they need IESG approval for something we're happy to listen, and let
somebody from the community pick it up.

Mirja: Or reach out to Aaron and see if he wants to keep doing it.

Alvaro: At some point we had a discussion about who gets time on the agenda and
who gets put on the agenda. That's one of the reasons why HotRFC was sponsored
by an AD, so it would be sort of an official thing on the agenda people would
know about, vs just having it in a room. For now, I agree that there's no
better way to have some videos and publish them the week before so people can
look at them. In the future whenever we meet in person we should think about if
we want to sponsor this again or how we do that, so we can put it on the agenda
and not just open the door for anyone to say they need a room to do something.
Then we go down this hill of the side meetings and everything else.

Warren: I've never managed to actually make it to a HotRFC session because it
always conflicted with another meeting I had. Are there generally questions on
any of them? [No.] If there were, we could have the videos and maybe a really
short meeting where people could show up and ask things.

Lars: It was three or four minute for advertisements for anything you want to
talk about. Some people advertised their side meetings, or a BOF, or some other
work in the IRTF, or software, or what have you.

Rob: I've been to at least one of these and I thought it was really useful.
Certainly pointed me to one or two drafts I decided to look at and go to the WG
meetings for. I'm keen for something to happen if we can. I agree it's just a
matter of trying to get someone in the community to drive this but I'm not sure
the IESG needs to pick up more work here.

Ben: I have Aaron up on internal chat here if there are questions people want
me to ask him.

Martin D: Does he want to do it? I think he should have the right of first
refusal, and if he doesn't want to do it we can open it up to the rest of the
community. If we need an AD to rubber stamp it I'd be willing to do it, I'm
sure others would as well. Assuming that it's fine for staff to support that
and get the video up and all the things that happen there.

Lars: Can you ask Aaron what we can offer him so he does it again? He did a
great job. I think he should return to doing it when we're in person but I
would also like him to do it if we're not.

Mirja: Amy just reminded us that we had this format at 108.

Lars: Did we have it as a session?

Amy: People submitted <4 minute videos and it was put in a youtube playlist and
advertised. They were run whenever you wanted to go and look at the videos. It
wasn't a session.

Mirja: Do we know how many we had?

Lars: There were seven, I'm looking at it now.

Amy: I think there were three from one person, but all on different topics.

Rob: If we just put the videos together, will people bother to look at this if
there's no forcing function to get people to discuss it?

Mirja: I think one issue is we don't often have videos in the IETF so it's kind
of an additional barrier to submit a video rather than just a short abstract.
The other thing is you're not actually sure who will be watching it, you don't
get any direct feedback.

Éric V:  On the other hand, rather than spending an hour or two in the hot,
packed HotRFC meeting room, you can sit in whatever room you want and be done
in 15 minutes.

Warren: Isn't part of the purpose to share info on all the different things?
Having one "I'm interested in this particular document" doesn't seem that
helpful. It feels like having all the videos joined together so all the drafts
are covered in one thing, so you are exposed to all of them [would be better].

Mirja: I don't like watching videos, I'd rather read something so I can do it
at my own speed. I'm not sure we need the videos, we can just ask them to
publish an abstract and some slides and put it on a webpage.

Éric V: That's fine for me as well; I don't like video either.

Rob: There's an IETF 109 HotRFC here [on the IETF youtube channel] that has ten
views.

Lars: What's the suggestion for replying to Spencer? Do we want to say that
based on what we saw from 108 and 109, it doesn't seem that useful to put
videos together? Do we want to tell him that people should send email to where,
ietf@ietf? Attendees?

Mirja: Announce their hot topic, you mean?

Ben: Is hotrfc@ietf.org an open membership list? That's where previous calls
said to send topics.

Mirja: I'm not sure about what Aaron did for the latest ones but initially
there was a review team, so there was an additional step where you could reject
something. I'm not sure we ever did reject anything. But Aaron did review and
left it open to say something is out of scope, which might be a good function.

Rob: One other idea, at the last informal we discussed trying to move stuff to
the week before or after. Is HotRFC something we could experiment putting the
week before, to see if people turn up and it's useful? So we could do it as a
regular session and maybe have some time to talk about them?

Alvaro: I like that; that seems to be similar to Sunday night right before the
IETF.  I went to many HotRFC sessions and they were always full. There were 100
or 200 people in the room, which is a lot different than the 10 youtube views.
I didn't look at the ones on youtube so i would have missed those.

Warren: If there's a session, I'll show up for it. It sounds interesting and
I'd like to be able to see it. If it's 47 different emails of people telling me
how wonderful their drafts are, I'll never read them. If it's a bunch of videos
I'll also not get around to them. But if it's something I can put on my
calendar and people will stand up for three minutes and tell me about their
awesome new idea, I'd happily sit through that.

Mirja: The other option I had was to put everything on one webpage. Like you
check the side meetings and see what's going on there, you can also check this
page and see what you want to go to during the week.

Warren: The quality of the writing is going to vary so much, and there's going
to be so much [jargon].

Mirja: As long as it's not a huge wall of text.

Zahed: Sorry, but maybe I wasn't listening. What's wrong with having a session
and having people present for 3-5 minutes?

Lars: There's no problem with it, and it was just suggested as something we
could try the week before. My initial thinking was that because there's
traditionally no Q&A, there's no real need to have an interactively scheduled
session. But as Warren said, maybe people will show up if it's an hour and they
can get something out of it.

Warren: We could also do it as a video and post the link to youtube after for
people who don't want to go to the live thing. There's also nothing stopping us
from making a wiki page where people can list their wonderfulness for those who
prefer to read.

Mirja: I have no concerns about that but the real HotRFC we have on Sunday
evening also because everyone is there for the welcome reception and some
people are bored and go over to the room. I don't know if the same effect would
happen if we had this online. But we could give it a try.

Ben: The other thing that comes up as a virtual session is that the overhead of
switching presenters, changing media, and all that, could be a lot if your
presentation slot is only four minutes. You might still want pre recorded
videos even if it's going to be a live event you want people to show up to.

Zahed: If you have it as a session it will be recorded too though. We can
actually have every slide in one slideset. I think Aaron has done that
previously. That could be one thing to be done.

Lars: Did Aaron organize 108 and 109, the HotRFC sessions? Because if so in the
interest of saving time, I can ask him if he'd be willing to restart that for
112 and if he doesn't want to do it, I can ask him if he has a volunteer in
mind to take over.

Ben: I believe it was Aaron for 108 and 109, but I'm not sure.

Lars: Liz says in the chat he was. I will send him an email and cc the IESG and
ask him if he thinks it makes sense to restart.

Mirja: We can do all of these things, we can do a wiki and videos and put it in
Gather and as a session and we can leave it to Aaron how much effort he wants
to put in.

6.9 PR approval process for the I-D guidelines (Lars Eggert

Lars: As you'll see, the I-D guidelines are now on Github. People have been
sending pull requests and now the question is what to do with them. Robert
Sparks and Murray used to hold the pen; do we want to leave it with them and
let them use their best judgment for merging these PRs? Do we want to institute
some other approval committee or something?

Mirja: If those edits are straightforward we don't need an approval committee.
Someone needs to hold the pen and if there are any concerns you can always
bring it back to the IESG to have a look.

Murray: It seems to me that it should be with the tools team because this needs
longevity past any individual AD's term. Or there's got to be one person on the
IESG checking pull requests, approving them, and figuring out which ones need
consensus. You can leave it with me, for example, but what happens if I don't
get reappointed in March? That has to be managed, is all I'm getting at.

Warren: Isn't this a thing where Jay is going to be doing the authoring thing?
Doesn't this fall within that?

Murray: If we're going to go that way, for things that Jay feels like he should
check with someone, we should provide guidance about where he should go for the
nontrivial cases. Should it be IESG, should it be WG chairs, should it be at
his discretion who he asks for advice? That's about as far as I've gotten in my
thinking.

Lars: Technically this lies with us because the IESG decides what goes in an
I-D. It's not for the LLC. Going back to this authors.ietf.org thing, the plan
is that they would have a github repository where content would live and some
sort of web front end would be driven off that. But that still requires
somebody to have ownership of the different pieces. If the I-D guidelines in
some form moved there, the IESG would still need to be the body that controls
that or delegates it to somewhere else. I don't think it should be the tools
team either; this isn't really a tools thing. It's really what does an I-D look
like? There's a tools aspect but that's not the central part of it.

Alvaro: I think you mentioned before that Jay and Robert or whoever wanted to
do a team to manage the authors thing, including people from the IESG. Whoever
is on that team should be an IESG person.

Lars: Yes, if we go that direction, and create that team, we'd probably look
for two ADs for it.

Alvaro: So it wouldn't necessarily be the tools liaison, it could be whoever.

Lars: It would be somebody who cared about this. Should we instate that sort of
team already and the initial task would be to maintain the I-D guidelines as
they are in github? And if Jay wants to have a group to discuss
authors.ietf.org those would also be the stuckees for htat? Would anybody be
interested in being in that group? If nobody raises their hand we need a
different approach.

Mirja: I'm happy to help but we don't need a full group to maintain it, I think.

Lars: If we do the github model, we could agree that a PR needs two approvals
from somebody on that team. If so, if you're the second approver you can merge
it. That would be a pretty lightweight process.

Warren: Could you put a link to the github thing so we can understand what sort
of changes they are? 'It would be better if there were a comma here' is very
different to 'we should replace I-Ds with Word documents.'

Lars: There's the link. There are nine issues and seven pull requests open at
the moment. I've looked through them at the moment and approved them because
they made sense. There are some issues that are a bit more open but they didn't
create PRs.

Warren: I think I'm happy to help with this.

Mirja: My feeling is that a bunch of these PRs are just describing how it
works, so there's nothing to discuss. If they describe correctly how it works,
you can just accept them. That's my point of view.

Warren: We still need someone to do the clicking of the approval thing, whether
you need one person or fourteen, I think that's much less important than people
willing to do reviews and remove [small ones].

Lars: I reviewed them and I was okay with them, but I felt that someone else
reviewing them and also being okay with them would be helpful. So that's why I
didn't merge anything yet. If we have two okays, I think that would be better
than just one. Some of them are moving text around and those might make sense
to one individual but maybe not to another one and discussion can be good.

Warren: I think it should be done by an agreement that we'll look at ones that
are exciting and figure it out between whoever the reviewers are. Having a
formal review process for ones like pull 23 which is about an extra whitespace,
I don't think we should set up tooling that requires two okays for something
like that.

Lars: I don't want to set up the tooling like that, I think an agreement would
be fine.

Warren: But you're saying we set up Github actions so it requires two approvals.

Lars: No. I actually don't think there will be very many pull requests after
this first batch is done. I think it will be pretty stable anyway. So i suggest
that if you're willing to help with that Github review of the I-D guidelines at
the moment, and potentially also going through to talk to Jay about
authors.ietf.org, send an email to the IESG and in the short run I'll make you
admin on this repository, and then we can get started at your leisure.

6.10 Bulk retroactive revision to the Media Types "Content-Disposition"
registry (Murray Kucherawy)

Murray: The tl;dr is that this content disposition registry was created in the
90s, maybe earlier. Curiously, the registry was created by RFC 2183 that
specified a bunch of columns, or fields in the registry. Since then, not a
single registration has actually followed the template. The first one got it
wrong, and then all the others since then were based on the first one. We have
this column that's not properly populated for any registration. Until recently,
a document by Dave Crocker actually did the right thing and then IANA blocked
it because it didn't look like the rest, how do we fix this? My proposal has
been, and I think I sent this to the IESG list a while ago, I went back and
read all the documents and took my best guess at how to retroactively populate
the registry. I sent this to the media types list and nobody seems to care. I
suggest we do this, and rather than just directing IANA to do it, does anyone
have a reason why we shouldn't do it this way? The other option is to produce a
BCP that removes the column because nobody seems to care about it, which is
more work than putting the values in and being diligent about making sure that
it's done properly going forward.

Mirja: What's the value we're talking about; is it useful for anybody?

Murray: If you think about media types, it's like parameters for media types.
The documents do list which ones they want to allow, but they just never put
them in the registry for some reason. The right answer is in all the documents,
just the connection to the registry wasn't there.

Ben: I remember I had some thoughts when we talked about this last time but I
don't remember what they were.

Murray: I can go back and make sure they weren't anything that wouldn't be
addressed by this process.

Ben: It's likely that I was saying something about the right thing to do
depending on how obvious the answer is. It sounds like you did go through them
and it's pretty obvious.

Murray: I took my best guess because some of them I'm not familiar with the
source material, but it didn't seem like it was buried in the documents; there
were examples of what they expected to have happen.

Ben: Sure. That sounds reasonable.

Murray: Okay, hearing nothing, I'll proceed with this. Amy, do you have to do
something?

Amy: This is just weird enough that I don't think we have a process. We can do
a call to approve your way forward, if you'd like.

Murray: Originally I was thinking let's just do this, and then I was talking
with Ben about getting the IESG's approval of it.

Amy: Okay, does anyone have an objection to making the bulk retroactive
revision to the media types content-disposition registry?

Alvaro: I don't know if I object but basically what you're going to do is
change the registry based on this discussion and some email you sent before.
There's no draft RFC?

Murray: Right. We could do that sort of process if we really wanted to make
sure everything has been done on the level. As Warren just remarked, virtually
no one seems to care about this, so why go through all that process?

Michelle: Technically there are RFCs, they're just really old.

Murray: And they just failed to take a specific action towards IANA. All the
source material is already there.

Warren: I'm fine with that. If you wanted some cover you could send email to
ietf@ just saying we're doing this. I don't care, I'm fine with this as it is.

Murray: I think I didn't do that because I fully expected the IETF to ask why
are you wasting your time with this?

Alvaro: What I think worries me, maybe not enough, is that we're opening the
door to changing registries without having RFCs. Right now, most of the
registry changes are with RFCs. so I don't know if in the future it's going to
be something that sounds relatively obvious to me but no one else, and now
we're going to argue for this process and not something different, and if it's
something we need the IESG to approve, is it okay for WGs to say we agree this
column is not needed, just delete it. How do we get there? Without the proper
sort of paperwork, it sort of opens the door that I don't know we want opened
or that we can close correctly later.

Murray: Michelle, how have we handled corrections like this in the past?

Michelle: If they're pretty plain and simple, like a document said to do
something and we've discovered many years later that was never done, often we
just work with the AD and the expert to figure it out. In a way I look at this
just as a correction to a registry, because we're not necessarily creating or
defining anything new. Everything is defined in the old RFCs. In the case where
there's an actual change to the registries that are new or modified in some way
that isn't documented somewhere, Alvaro's approach of needing a document that
describes what's going on is the preferred path.

Murray: This isn't the first time we've made a retroactive registry correction,
where the action simply wasn't taken in the past properly.

Michelle: For this particular instance the way we're doing it now seems right
and it also seems like it's not going to be problematic. If there's anything
more than what we're doing in this case then a document probably would be
needed. This just appears to be correcting something that was never done in the
past.

Alvaro: So like I said, I'm not terribly opposed, I mostly just wanted to say
this for the minutes so five years from now some future IESG can pick this up
and see what we were doing.

Mirja: I'm fine because it seems like just fixing something that went wrong in
the first place. Talking about minutes, maybe we should put in the minutes what
the actual change is rather than only talking about it on a high level so it's
documented somewhere.

Murray: I sent it to the IESG list.

Mirja: I mean put it in the minutes or put it somewhere where also people can
publicly see it and find it later on as well.

Michelle: Documenting what we're doing is a good thing.

Amy: I think that was approved, to just make that change.

Murray: I'll work with you to get the list put in the minutes.

The IESG approved making a bulk

retroactive update to the "Content-Disposition" registry to populate the

"Allowed values" column that was specified in RFC 2183 with the

following:

inline: (none)

attachment: filename, creation-date, modification-date, read-date, size,

 handling

form-data: name, filename

signal: handling

alert: handling

icon: handling

render: handling

recipient-list-history: handling

session: handling

aib: handling

early-session: (none)

recipient-list: (none)

notification: (none)

by-reference: handling

info-package: (none)

recording-session: (none)

6.11 IETF 112 Plenary experiment (Martin Duke)

Martin D: The idea is to take the plenary out of the IETF week to free up eight
slots. A few questions have emerged. Number one is do we do this experiment or
not? Second is do we do it the week before or the week after? Third is what
time do we do it? The first question, do we do it or not do it, is anyone's
opinion going to be affected by the day and the time? Or should we focus on the
most important questions first?

Éric V: I guess the day and time will be critical for many people. You would
never wake up at 3 am to attend the plenary the week before.

Martin D: Is there a situation where your decision to approve or disapprove of
the experiment would depend on the time and date discussion? We're not going to
do something obviously stupid, right?

Éric V: We can go for it, i'm always for pushing for experiments, but I have a
big question mark in my head.

Martin D: Are there significant objections to having the experiment at this
point? I wrote out a google document a while ago about sketching exactly what
we're measuring and what we're trying to do, so there's something concrete to
poke at. Is the idea of continuing and having this experiment at 112 still
feeling doable, or do we want to pull back before we argue about the details?

Mirja: My hardest concern is not the experiment itself, it's rather about the
flamewar that could happen on the IETF mail list while discussing it. But I
think that should not be a reason to not do it.

Francesca: To also voice my opinion, I think we should do the experiment. I'm
not sure it would be very positive but as the IESG we should be more flexible
and open to new things, otherwise we're going to always be stuck in the same
way it's been done. So I'm all for an experiment.

Martin D: Going once, going twice….So this is worth discussing the details. I
think there was basically violent agreement on what was in the draft, except
for two things. Number one is whether we do this the week before or after IETF.
I think Lars made the point that after, people would be able to discuss things
that happened during the IETF week, which is certainly true. And Mirja made the
point that if we did it the week before, it would probably be higher
attendance, because people want to stop after IETF week is over. I have no
strong opinion about this but i want to open the floor for discussion.

Lars: I think attendance trumps my concern. If people believe we can get more
in the week before IETF, that's overriding giving people the opportunity to
complain, which they can do anyway by email or other forms. People don't have a
problem raising complaints when they need to. Maybe the week before is the way
we should do it.

Martin D: I don't want to get the cart too far before the horse here, but if we
decide to continue the experiment at 113, if 113 is remote, that's going to
affect when the dots move. That's a hidden implication of this whole process.

Zahed: I think we need to try it out and see how it works. We're working on a
lot of assumptions here. People are bogged down before IETF week; I don't want
to do anything else apart from my documents and my responsibilities, so people
might think the week before is overkill. The week after, people can comment
about what has happened, but also Mirja is right; people kind of stop after the
IETF week. We need to try it out and see what works.

Alvaro: About the dots, last time there was a March plenary I thought we gave
all the ADs access to new tools in the beginning of the week and then took
everything away at the end of the week so there's a massive overlap of ADs in
the week. The ceremony is nice but i think we can do the same thing.

Éric V: Regarding the dots, I agree. We can put everyone on stage. The week
before is nicer because if we want to do the HotRFC, that's the right time for
this. The interest in the technical plenary has been diminished a lot; there's
no technical anymore. So HotRFC and why not Dispatch at the same time?

Lars: I would argue for starting slow. The HotRFC discussion is separate and
Dispatch only frees up three slots or something while the plenary frees up
eight. I would start with the plenary and see how that goes. For 113, if it's a
problem with the handover, maybe we move it back into the week until we have a
better plan.

Martin D: I think I heard consensus for doing it the week before. Let's move on
to the other topic, which is start time. I spent way too long analyzing the
time zones here and ultimately it's an hour and a half meeting. There are two
big gaps of time zones in the world, the one between Australia/New Zealand and
California, and the one between CET and China, with apologies to Israel and
India. My best way to think about this is in a complete vacuum of what the
official meeting time was, in northern winter since Australia moves forward a
few hours, so the Eurasian gap is the one you want to have fall in the middle
of the night. Whereas in the northern summer, you want to have the overnight
over the Pacific Ocean. Unfortunately, what that implies is that this is a
"Madrid" meeting and the optimal time is something like 2300 European time.
It's pretty late. So I don't have a super strong opinion; do people want to
pick the globally optimal time or tie the plenary to the nominal location of
the meeting?

Alvaro: I think we should tie whatever activities we do for the meeting to the
meeting time. If this is supposed to be aligned with Madrid somehow, the
plenary should be somehow aligned with that. Whether we do it at the beginning
or end of the day is probably okay, as long as it's sort of aligned with that.

Lars: Can we continue this at the informal next week? We have 15 minutes left
and I still want to go to executive session for a little bit.

Martin D: Just to wrap it up, the alternate proposal is to do it at 2230 CET,
but the main text of the document is 1430 Madrid time, which is 05:30 in
California, and the meeting would wrap up at 02:00 in Sydney. This is where the
thing is compressed a little bit because it's not optimal at that time of year.
So just quickly, does anyone else have thoughts about whether to pick the
globally optimal time or the European optimal time? [pause] Okay, I think I've
gotten what I needed out of this. Do we still need to do another discussion
about it?

Lars: Since we don't know the time yet, I'd suggest we discuss and finalize it
on next week's informal call. You can give Jay a heads up this is coming but
let's finalize next week.

Mirja: We also need to give a heads up to the LLC and IAB since they're all
involved in the plenary, right?

Lars: I've given heads up to several people already, including ISOC and Greg
because the November meeting is when the Postel award is given out. Let's
quickly do the next one and go to executive session.

6.12 [IANA #1206885] Renewal for early allocations for
draft-ietf-bess-evpn-igmp-mld-proxy (IANA)

Michelle: Not being able to hear Martin, I know he said the document is
progressing and it's getting close but we're looking at a potential time period
that the document wouldn't be approved for publication and expiration of the
code points, so we talked about renewing just to be on the safe side.

Martin V: Do you hear me? It's in IETF Last Call, so it should make it, but as
a matter of security we decided to renew with Michelle.

Amy: Sounds like it is well on its way to the IESG. Is there any objection to
renewing this early allocation? I'm hearing no objection, so this is approved
and we'll send an official note to IANA.

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

Éric V: The HIP WG has been closed on Monday. I expect as well HOMENET will
close soon. If you're wondering about MADINAS, I was on vacation and unable to
update the charter, but the proponents and chairs are working on it so expect a
brand new charter tomorrow or next week.

6.7 Executive Session (Lars Eggert)