Skip to main content

Narrative Minutes interim-2022-iesg-10 2022-05-05 14:00

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

Narrative minutes for the 2022-05-05 IESG Teleconference

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

1. Administrivia
1.1 Roll call

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
Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area
John Scudder (Juniper) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
Amy Vezza (AMS) / IETF Secretariat
Éric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area
Paul Wouters (Aiven) /  Security Area
Qin Wu (Huawei) / IAB Liaison

Jay Daley / IETF Executive Director
Alvaro Retana (Futurewei Technologies) / Routing Area

Lee-Berkeley Shaw
Greg Wood

1.2 Bash the agenda

Amy: Does anyone have anything to add to today's agenda? Any other changes?
1.3 Approval of the minutes of past telechats

Amy: Is there any objection to approving the minutes from the April 21
teleconference? I'm hearing no objection. I also saw final narrative minutes
from April 21; any objection to those being approved? I'm hearing no objection
to that either.

1.4 List of remaining action items from last telechat


     o Murray Kucherawy to find designated experts for RFC 9208, "IMAP
       QUOTA Extension" [IANA #1229081].

Murray: I have that; do we want this at the end or do you want to do it now?

Amy: At the end; if you can put the names of who you found in the Slack channel
we can pick them up from there. We'll mark this as provisionally done and we'll
add a management item to approve.

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

Roman: In progress.

     o Francesca Palombini to find designated experts for RFC 9176
       (Constrained RESTful Environments (CoRE) Resource) [IANA #1229995]

Amy: This is a new item for Francesca.

Francesca: Thank you; noted.

     o Security ADs to find designated experts for RFC 9116 (A File Format
       to Aid in Security Vulnerability Disclosure) [IANA #1230049].

Amy: Is there a specific security AD who wants to pick this up?

Roman: Paul and I will talk collectively, so action caught. Unless Paul, you
have an idea right now.

Paul: I do not.

Amy: Great, then we'll mark this in progress and you can let us know.

     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 Murray Kucherawy to look into updating the guidance in BCP 13 on
       when to add organizations to the "Standards-related organizations
       that have registered Media Types in the Standards Tree" list.

Murray: Where that seems like it's going to go is a note on the IESG wiki
rather than a new draft. Changing a BCP seems like a heavy handed answer to
what we were talking about. Expect a proposal from me shortly; it's still open,
but that's where it's going.

     o Lars Eggert and Francesca Palombini to draft an announcement about
       the public archive of AUTH48 conversations.

Amy: I think this is on as a management item to discuss today, is that right?

Lars: That's right. I'd mark this done since it's drafted.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-idr-bgp-ls-sbfd-extensions-10  - IETF stream
   BGP Link-State Extensions for Seamless BFD (Proposed Standard)
   Token: Alvaro Retana

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

Éric V: I may suggest to put this as Revised ID Needed just in case, because
Alvaro is not here.

Amy: Since it was just revised, I think AD Followup would be a better choice,
unless you think version 10 that was just released is not sufficient.

Éric V: That's fine for me, go for it.

Amy: Great, then we will put this as AD Followup and Alvaro can release it
whenever he wants.

2.1.2 Returning items


2.2 Individual submissions
2.2.1 New items


2.2.2 Returning items


2.3 Status changes
2.3.1 New items


2.3.2 Returning items


3. Document actions
3.1 WG submissions
3.1.1 New items


3.1.2 Returning items


3.2 Individual submissions via AD
3.2.1 New items


3.2.2 Returning items


3.3 Status changes
3.3.1 New items


3.3.2 Returning items


3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 o conflict-review-liu-lsr-p2poverlan-00
   IETF conflict review for draft-liu-lsr-p2poverlan
     Interface Stack Table Definition and Example for Point-to-Point
   (P2P) Interface over LAN (ISE: Informational)
   Token: Warren Kumari

Amy: Warren did the review for this document and I have a Discuss; Rob, it
seemed like you just wanted to discuss this, is that right?

Rob: Yes. I've sent more detailed comments to the authors; I just wanted more
discussion here with the IESG about whether they think it's okay to publish
this. My specific concerns are the way they are modeling this is not how I
would recommend modeling this in Yang and I'm not sure it's how I would expect
an IETF consensus to model this. The attribute they are modeling is one that's
standardized so I think it's probably okay, potentially with a disclaimer, but
I wanted to flag that and see if anyone had any concerns. I've discussed it
with Eliot and will discuss it with the authors as well. I've sent them further
comments about the approach they're taking.

John: That makes sense to me. What's the outcome you're hoping to achieve?
Getting them to revise their document in a way that's more suitable, or getting
us to put a disclaimer on the top of it?

Rob: I send comments anyway suggesting some technical issues they will probably
want to comment to address. I don't know if some of those will potentially then
stop them using this approach at all. It may be that the ISE then says we
shouldn't publish because there are technical problems. Assuming that it's
technically viable, then I think just a disclaimer saying effectively this is
one way this can be configured, but it's not the recommended way, or an
expectation that other operators or other vendors would necessarily follow this
approach. So that's my concern, is that it's like a back door way of adding
some extra manageability API and i'm just not sure that's helpful. Does that
answer your question, John?

John: Yes. I've always been unclear about whether we just have to pick from
that menu of boilerplate disclaimers or whether we can actually provide other

Warren: We had somewhat of a discussion on that with a previous ISE. What we'd
largely come to consensus on is that we're supposed to choose from those
answers with maybe very tiny changes. If you have other thoughts, you can put
them in as additional thoughts that are not part of the conflict review. Like
dear rFC editor, please remove this before publishing type things. What I don't
know is what the process is if there's a Discuss on a conflict review. The
Discuss isn't really about the conflict review, it's more about the document.

Lars: A Discuss on a conflict review is with the proposed answer. You basically
say I don't agree this is good to go forward, I think this should be do not
publish. You could have a Discuss that says I don't agree and I think we Do Not
Publish this because of the content of the document. But if it's not at that
level, I think it needs to go to the ISE and say I have some serious concerns
but I don't want to argue for Do not Publish, but maybe the authors want to
look at this. Do you think this is a DNP?

Rob: I don't, I think that's too strong. I wanted to flag that I had concerns;
if the IETF was doing work in this area I don't think they'd come up with this
solution. I think they'd do a different mapping of the manageability model to
describe the same thing. And I have questions about how their solution will
work from other aspects, which I've raised with them. So that has been sent to
them and the IESG has been CCed. I'm not sure if this is a Do Not Publish. When
I chatted with him today, Eliot was of the opinion that because the IETF is not
actively standardizing this attribute, it's like potential future work. He
would say he thinks it should be published anyway assuming that it's
technically sound. That was my opinion. I don't know if that will change but
that seems reasonable to me. I think it's just a matter of having a disclaimer
that makes it very clear this isn't part of the IETF's Yang manageability
interface and how these things are managed. It's one way it could be done and
some vendors are using it.

Zahed: My understanding from when Adrian was here before he left, he said that
this Discuss is about the conflict review and if you have comments about the
content you can put it in the comment section. So this would be No Objection
with lots of comments and I think you've already done that.

Rob: Yes, effectively, assuming nobody else says Do Not Publish, we should
change the outcome that this is related to IETF work in LSR, so that's a minor
change. I'm not saying we should Do Not Publish, I just wanted to have the

Warren: Two quick questions. One, Alvaro had said this does feel like it might
be related to X. He's probably right. What I don't know is, does that mean that
we have to propose new conflict review text saying this is related but the IESG
is okay with it? Or do we just go with what we've got? I don't think there's
much in the way of important archival stuff in the conflict reviews, whether
there's no conflict or it's kind of related but you can publish anyway. If the
IESG does want an IESG note attached, instead of DNP, what's the process for
that? And a third point, we should probably change the button that says send
notice to Adrian to Eliot.

Amy: It does go to Eliot, there's just a Datatracker thing that has Adrians'
name attached and there's already a bug report for that.

Warren: Can we stick with the current text or do we think we need to change it,
and if so do we need to do another ballot?

John: Or should we make the text be right? What's the point of having text if
we don't try to get it right? I don't think we have to spend a lot of time
losing hair over it, but if we agree this one isn't quite right, let's make it

Warren: Sure, but do we have to re-ballot?

Amy: No, you just change the text of the conflict review.

Éric V: To which text? I'm a bit confused now.

John: I assume it would be changed to, is related to LSR but no objection.

Warren: Yes.

Éric V: But I think Rob's goes further than this, right?

Warren: That's a separate issue.

Rob: The fix for mine is that hopefully Eliot and the authors will agree to
have some text in the document that makes it clear about the scope. I would
have thought they'd be willing to put that in so that's my assumption. I don't
know if we need a formal IESG note attached to it; that feels heavy-handed.

Éric V: But it's important, right?

Rob: I think so. On the flip side, this is just an IF type and anyone is sort
of allowed to allocate these by the INF process; there are guidelines for how
to do that and there are no guidelines that say you can't do this if IETF
disagrees. It feels like it would be wrong to block this and say you can't do
it, because there's no good grounding other than if the IETF was to try and do
this I think they would come up with a better answer. It may also be that I
misunderstand exactly what they're trying to model in their document and it's
just clear enough that from a configuration side nothing's changing. That's
fine, they just need to clarify that in the document.

John: It sounds to me like you should just do exactly what you said, take it to
the authors and Eliot and they'll do the right thing, and then we're done. If
they don't we can probably have another conversation about it.

Rob: Eliot is happy with that.

Warren: I just updated the text to reflect Alvaro's concern.

Rob: So I'll clear my Discuss on this and we'll just take it to the authors
from there.

Warren: Awesome, thank you.

Amy: So the text has been updated and Rob will clear, so this conflict review
is now cleared to go back to the ISE with the note that's in the tracker.

 o conflict-review-irtf-nwcrg-coding-and-congestion-00
   IETF conflict review for draft-irtf-nwcrg-coding-and-congestion
     Coding and congestion control in transport (IRTF: Informational)
   Token: Zaheduzzaman Sarker

Amy: There are no Discusses in the tracker so unless there's an objection, this
conflict review is ready to go back to the IRSG.

Éric V: I don't recall having reviewed this one; when was it submitted? I guess
I didn't. My bad, sorry.

Lars: It came a bit late, but it was on the agenda for a while.

Zahed: That was my mistake, not to change the area review to IESG review which
is why it didn't create a ballot. I did the review a while ago but I didn't
change the state.

Éric V: That's fine, I just wanted to check if I'm the outlier.

3.4.2 Returning items


3.4.3 For action

 o conflict-review-rprice-ups-management-protocol-00
   IETF conflict review for draft-rprice-ups-management-protocol
     Uninterruptible Power Supply (UPS) Management Protocol --
   Commands and Responses (ISE: Informational)
   Token: Lars Eggert

Amy: Is there any idea of who might be the appropriate person for this review?

Lars: This looks like an ART thing to me.

Warren: It has the word Management in it…

Lars: If you want to fight over it I'm all for it.

Rob: I don't mind either way. I had a quick look and I don't think there are
any issues.

Francesca: I'm currently doing another conflict review so I'd rather not take
on another.

Rob: Send it my way then.

Amy: Thank you, Rob. We'll put you in for that.

Lars: Before we move on, there's another one that I think came in yesterday,
that I was wondering if it's INT or OPS and Erik said he thinks it's OPS, so I
think it's Warren's if you want it? It's draft-dashevskyi-dnsrr-antipatterns-00.

Warren: I don't see it anywhere, can you drop a link to the document?

Lars: It went to the IESG list, I can forward it to you.

Warren: I will take a look and see why it's not in DNSOP.

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


4.1.2 Proposed for approval


4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o Common Control and Measurement Plane (ccamp)

Amy: I have no blocking comments on this recharter; does this need to go for
external review?

John: Other opinions? Unless other people think we should skip it, my
inclination would be to go ahead and do it. It's a small textual change that we
went back and forth on. They didn't seem to be very proprietary about it so we
took it on, but the fact that the consensus was not that this obviously belongs
in CCAMP makes me wonder if other people want to have their opinions heard.

Amy: That sounds like a good reason for external review to me.

Roman: If there's nothing pressing it's always better to go to the community
just to give visibility for it.

John: I don't see anybody saying we shouldn't do an external review, so let's
just go ahead and send it. Can you hold off on the announcement until we have a
chance to produce an 08-02? There were a bunch of non-blocking comments we can
take on.

Amy: Okay, this will be Approved, Pending edits, and you can let us know when
it's ready.

 o Remote ATtestation ProcedureS (rats)

Amy: I have no blocking comments to sending this for external review and I
believe Roman did say he wanted this to go for external review, so unless
there's an objection it looks like that external review is approved.

Roman: I appreciate everyone's feedback. To respond to the things that came in:
Francesca, we can add a couple more WGs. It never hurts to talk about who we're
going to coordinate with. John, I think you've been talking with the chair, and
I think I commented previously we can tune that language and clear it up. On
the carriage return line feed, I continue to think that this is that markdown
rendering issue. I seem to have it every time I do a charter. If someone knows
what I should be doing differently to make it render better, I'm all ears.

Éric V: Put an empty line between those items.

Roman: That does not render correctly for me either.

Warren: Put two empty lines between those? I know I made it work by randomly
adding a bunch of extra blank lines. Or, just don't bother to make it render

John: All the other lines have a comma, or an asterisk, and that one has
something else on the tail of the preceding line. It's so arbitrary.

Roman: I'll spin a -01, -02, -03 to figure it out. Eric, I think we got your
comment already. I'll make a few minor tweaks and I appreciate the feedback.

Lars: There's also the sandbox that you can use to play around with this so you
don't need to send email out for a gazillion reviews because of markdown.

Roman: That's a good idea, I forgot we can do that.

Warren: Somewhere I actually wrote an email or a note to myself or something
from when Rob and I found this last time. We did figure out what the issue was.
But I think it's easier just not trying to format them.

Amy: Okay, so this is Approved -- Roman, do you want it to be Pending Edits so
you can get it to look the way you want before we send it out?

Roman: Yes please. It's not just the formatting, there are a few word changes I
wanted to make too. I'll do that this afternoon.

Lars: Before we move on, I wanted to ask the ADs whether any of these
recharterings are also a good opportunity to also cycle some chairs. I think at
least one of those groups has had those chairs for a long time. I'm just going
to put it in your heads, we don't have to discuss it now, but think about it.
Thank you.

4.2.2 Proposed for approval


5. IAB news we can use

Warren: I wanted to point at the email that the IAB and IESG seek feedback on
candidates for the RSE Series WG chairs. That was sent to the announcement list
so I just wanted to remind people to have a look at that. The proposed IAB
workshop on in network support for troubleshooting and security which is ISTS,
which Lars forwarded to the IESG yesterday or the day before with a Google
document in it. That was something being discussed and worth having an extra
set of eyes on it. Those are the main things, not specifically news but
reminders for feedback.

Mirja: If I can add one more thing, we also looked at the BOF proposals and
there were IAB members who were interested in supporting the proponents, so
they will reach out and CC the ADs accordingly and see if any help is needed.

Warren: Thank you, yes.

6. Management issues

6.1 Approval of Designated Experts for rfc6833bis (Alvaro Retana)

Amy: Alvaro has identified Albert Cabellos and Dino Farinacci as experts for
this document and all six registries it talks about; is there any objection to
approving these two as the experts? Okay, hearing no objection so they are
approved and we will send the official note to IANA.

6.2 [IANA #1229995] Designated experts for RFC 9176 (Constrained RESTful
Environments (CoRE) Resource) (IANA)

Amy: This is to assign the action item we assigned to Francesca at the top of
the call.

6.3 Appoint an IETF RFC stream representative to the RSAB (Lars Eggert)

Lars: The IAB did this in Vienna and we sort of missed it when we did our
appointees. We talked about it but we didn't actually decide. I think it should
be the IESG chair, especially in the beginning, and I haven't seen anyone
disagree with that. It's also Mirja from the IAB and all the other heads of the
approval bodies so I would like us to appoint myself, if that's possible, and
then we have the RSAG complete and we can start the new model.

Warren: If it helps, I nominate Lars, so you don't do it yourself.

Éric V: I agree.

Amy: Is there anything we need to do process-wise?

Lars: We probably want to send out a message to the community with the names
and I think they're all in the Trello ticket. The one name we don't have yet is
the RCSE which is being hired; but the RSAG can already start without that
position being filled.

Mirja: Do you think this is super urgent? My plan was to get a meeting during
the next IETF meeting so some of us can meet in person.

Lars: I was just going to send a message to the community saying here are the
people who were picked for the RSAG.

Mirja: That's probably also not super urgent. Cindy is targeting to set up the
mailing list and a Datatracker group and then plan for our first meeting; in
between there we can announce it.

Lars: The mailing list is ready as I understand it.

Mirja: Yes but we need to subscribe people.

Lars: Then let's send an announcement at some point when you think we're ready.

Mirja: Let's add this to the to-do list, Cindy.

6.4 [IANA #1230049] Designated experts for RFC 9116 (A File Format to Aid in
Security Vulnerability Disclosure)

Amy: Roman and Paul took this on at the top of the call.

Éric V: May I suggest getting some ART people involved there as well, because
it's not just about security? Just a suggestion.

Paul: Thanks, that's noted. We'll talk to them about it.

6.5 RSWG Chair Appointment Process (Mirja Kuehlewind)

Amy: I know the IAB discussed this yesterday and they have their people for the
interview team.

Mirja: We discussed this yesterday and there are two questions. One is if we
want to form a common interview team, and I think there was strong support for
that because otherwise that means we have to ask all the candidates to do the
interview twice and we need double the Secretariat support for notetaking and
such. So there was strong support for that. We picked 3 IAB members to join
that team, so having another potential three people from the IESG would
complete the team. The second question we may want to discuss is how we
actually select the people, because I made the point yesterday that I don't
think we should make an independent selection. It's not like we are appointing
two people independently who work on their own; this team has to work together,
so there might be dependencies and we should pick them as a couple. That was my
proposal. I think there were less strong opinions about this in the IAB but
there was no objection to taking this approach. Any comments or thoughts?

Lars: I changed my mind yesterday a little bit. I initially thought we should
do two separate selections because that's what the RFC says. However it doesn't
say that we can't coordinate between the bodies and share information when we
independently make a selection. It does make sense to me that we are picking a
team here and not individuals. I think we should jointly decide who we pick.
The IAB picks for a two year term and the IESG picks for a one year term and
then in alternating years we renew or replace, but in the beginning here I
think we are picking a team.

Mirja: In the end of course we have to decide which person will be the IAB
person and which person will be the IESG person because of the terms, but that
should be easy.

Rob: I agree with what you're suggesting, Mirja, based on the feedback I've
received anonymously that you need to consider this as two people not one.
Having some sort of coordination at least on who we are appointing between the
two bodies makes sense.

Zahed: I didn't read the background about why we have these two processes and
why the rFC wants us to do it separately. Any background information on that?
We can definitely pick up the team jointly but what is the reason?

Mirja: It's not that the RFC wants us to do it separately, it just doesn't say
anything about it. The IAB picks one candidate and the IESG picks another
candidate and there was some discussion that we don't want to put any kind of
process for how to pick it into the RFC and leave it to the bodies. The idea
was to have shared responsibilities among both groups

Zahed: Okay. If it's about having shared responsibilities across both groups, I
think we're doing exactly that. What you said makes sense to me, Lars.

Lars: It was Mirja's idea first, I just agreed with it.

Roman: I want to make sure I understand the bottom line. What we're saying is
that we are going to form a joint search committee, or joint review committee,
that is the IESG + IAB and collectively two choices are going to be made out of

Lars: I think the proposal is that first we're going to pick an interview team,
there are 3 IAB members already and I guess we're looking for 3 more. Ideally
all six of those will interview all the candidates but because of time zones it
might be a subset. We'll get written notes out of those interviews that are
sent to the entire IESG and entire IAB. Based on the interview results and
community feedback that's already coming in, the IESG and IAB together are
picking two. The one that's slated as the IESG person serves a one year term
initially and the IAB person serves a two year term.

Mirja: Ideally we'd get a recommendation for one pair out of the interview
team, but we also probably need a venue for discussion where we can all discuss
together. Then at the end we would do some kind of vote on accepting these two

Roman: So there's a joint review committee between the three IESG and three IAB
and together they'll choose 2 candidates to bring back to the IESG and IAB to
support collectively, rather than the IESG having its own review committee to
see if we want this particular individual. We're basically collapsing the
search by pooling the IESG's thinking with the IAB. Correct?

Lars: There's no IAB lead, it's level ground between the IESG and IAB. There
would be a joint interview team and they would make a selection for a pair.
Then we can all decide whether we want to go with that or if we need to have
everybody review everything from scratch. But I hope we can delegate it to the

Mirja: how we design the voting at the end is something we can still discuss. I
hope we can reach a good consensus. If we get to a situation where everybody on
the IAB agrees with the two people suggested and everybody on the IESG says no,
we will have to have more discussion; we shouldn't just take a majority of
votes. But I hope the process will be smooth and we can all just agree at the
end. IF that's not the case we can figure out how to design the voting in a
useful way.

Roman: I'm fine if the takeaway position here is that we have two subteams that
are working together and are going to provide a joint set of recommendations
but there is an opportunity for either body to eject form whatever is that
recommendation if that is the choice those bodies independently want to make.
To be clear, I think that's what was said but I just wanted to confirm. I don't
know whether we're talking past each other or if we agree.

Mirja: I think you're right. We don't have to finalize the process yet and if
someone feels uncomfortable we can always change it. My hope is that we can all
find agreement on two candidates together at the end and if we can't find
agreement then we will have to find a different process.

Lars: So I guess we are looking for three names from the IESG to do the
interviews and make a pre-selection for us that we can confirm.

Mirja: We assumed we'd do what we usually do with interviews, which is that we
form a team and Cindy supports us to find meeting slots with the candidates
where most of the team members are available, so she will do a doodle for that.
If anybody can't make any of the calls that's usually not a problem because she
will take minutes and we'll have a summary at the end, and then we also usually
prepare a set of questions for the interview beforehand. Wes already agreed to
start a google document for that and everyone on the team can contribute
questions to that. Then at the interviews we usually go through those questions
in a round robin manner so everyone is involved, but the team itself can figure
out how they want to handle it. Then at the end you also need somebody from the
team to send a summary and channel the recommendations to the rest of the IAB
and IESG.

Éric V: And this is to be done in May or June?

Mirja: We probably won't be able to get any of the interviews done before the
retreat so the assumption is that the two weeks after the retreat will be the
period for the interviews, depending on the candidates' availability, and then
hopefully we can come to a conclusion soon after that.

Roman: I'm happy to be one of the three from IESg.

Éric V: Me too.

Zahed: I can also be interested.

Amy: Great, that's three, thank you. The Secretariat will be in touch and let
you know what's next.

6.6 Finalization of retreat agenda (Lars Eggert)

The IESG went through the retreat agenda to finalize some topics and timing,
which is now reflected on the IESG wiki.

6.7 AUTH48 archival announcement (Lars Eggert)

Lars: there is a google document that has seen a few edits and I would like to
send this out after running it past Robert one last time. I think we're doing
exactly what the tools team said was easy to do for them but I want to double

Francesca: I didn't put in any comments but thank you for drafting that. The
only thing I think we might want to hint at is to say that this is what the
tools team said is the easiest/most doable. Which is the conclusion we got to,
but it would answer a lot of the feedback that we got if we just say that we're
going to do this after talking to the tools team.

Lars: That makes sense. I'll try and stick a half sentence in somewhere unless
someone beats me to it before I look at it tomorrow. So basically we're going
forward with this and we'll send out an announcement based on the current
proposal module. That will probably happen early next week. Since I just
mentioned Robert, by the way, he's now an LLC employee as of May 2. Nothing
changes otherwise.

6.9 Designated experts for RFC 9208, "IMAP Quota Extension" [IANA #1229081]
(Murray Kucherawy)

Murray has identified Alexey Melnikov and Ken Murchison as designated experts
for this. Any objection to naming them? Hearing no objection, so they are
approved and we will send an official note to IANA.

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

Andrew: Briefly, I wanted thoughts on this -- I was thinking it would be useful
on the AD dashboard to show outstanding auth-48 things so things don't
disappear into mails. I wondered if anyone else had any thoughts? Otherwise I
can drop an email to tools-discuss and see what's possible.

Warren: I believe everybody else has views on this and everybody else has said
it would be awesome. I think it's already on the list. There's some sort of
issue with the fact that in order for it to be on the dashboard you need a way
to get it out of the RFC editor queue and something something that's complex.
But yes, that would be great and everybody wants it as far as I know.

Francesca: Also Robert and the RFC Editor have told us that the tools team is
working on a new website/tool for keeping track of auth-48 conversations. At
that point it might be easier to integrate that sort of information with the
Datatracker. We've discussed this and that was the result but you're welcome to
bring this feedback to Robert again. There is a work in progress about related
things, though.

Andrew: Thank you, that predates me.

Sandy: As an FYI, a while ago there was discussion that it would be useful to
note which documents are awaiting AD approval; like the RFC editor has asked
for something. On the RPC side there has been a little tooling work to put the
information in place for the datatracker to pick it up. We've talked to Robert
about it, it's just not the top priority right now. The way it would work as I
understand it is that it would be a flag like "Waiting for approval" or "AD
input needed" and you could then go look at the thread for whichever RFC is

Andrew: Like I said, as long as there's something beyond emails.

Roman: I think what you're describing is a great idea and I wholeheartedly
endorse it. If anything I would want something more ambitious, like taking all
the things that are at the RFC Editor and putting it on my dashboard, so the
other big bogey for me is errata and making sure they are verified.

Andrew: I 100% support that as well.

Sandy: I'll take a note of that for future tooling.

6.8 Executive Session: Discussion on DNSOPS message-fragments (Lars Eggert)