Skip to main content

Narrative Minutes interim-2020-iesg-21 2020-09-24 14:00

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

Narrative minutes for the 2020-09-24 IESG Teleconference

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

1. Administrivia
1.1 Roll call

Deborah Brungard (AT&T) / Routing Area
Jenny Bui (AMS) / IETF Secretariat
Alissa Cooper (Cisco) / IETF Chair, General Area
Roman Danyliw (CERT/SEI) / Security Area
Martin Duke (F5 Networks Inc) / Transport Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Wes Hardaker (USC/ISI) / IAB Liaison
Benjamin Kaduk (Akamai Technologies) / Security Area
Erik Kline (Loon LLC) / Internet Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area
Warren Kumari (Google) / Operations and Management Area
Barry Leiba (Futurewei Technologies) / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
Alvaro Retana (Futurewei Technologies) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
Amy Vezza (AMS) / IETF Secretariat
Martin Vigoureux (Nokia) / Routing Area
Eric Vyncke (Cisco) / Internet Area
Magnus Westerlund (Ericsson) / Transport Area
Robert Wilton (Cisco Systems) / Operations and Management Area

Michelle Cotton (ICANN) / IANA Liaison
Jay Daley / IETF Executive Director
Mirja Kuehlewind (Ericsson) / IAB Chair

Pablo Camarillo
John Leddy
David Millman
Dan Older
Dan Voyer
Greg Wood

1.2 Bash the agenda

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

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes from September 10 being
approved? Hearing no objection. Any objection to approving the narrative
minutes for September 10? Hearing no objection to that either, so we will get
those posted.

1.4 List of remaining action items from last telechat

     o Martin Vigoureux with Wes, and Alvaro to work on some
       mechanism to obtain wider or private feedback from people who are
       disenfranchised; anonymous flagging of offensive emails to inform
       leadership; more opportunities for private feedback.

Alvaro: Still in progress. We have a slot at the retreat to talk about this.

     o Warren Kumari to work on acknowledging shepherds, directorate
       reviewers in a more standardized/formal way.

Warren: In progress.

     o Eric Vyncke to write up draft text on Special Interest
       Groups and send to the IESG for comment.

Eric V: I still need to write a page with similar content, modified with
Alvaro's comments, and then send it back to the IESG. Keep it in progress.

     o Alvaro Retana, Benjamin Kaduk, and Murray Kucherawy to look at
       updating the I-D Checklist.

Murray: Michelle just sent me some feedback for the IANA section so my next
step is to merge Ben's changes and see where we go from there. Expect more on
this in two weeks.

     o Alvaro Retana and Martin Vigoureux to draft text on guidance
       regarding the number of document authors on documents.

Alvaro: We're going to call this in progress.

     o Alvaro Retana, Rob Wilton, Alissa Cooper, and Martin Vigoureux to
       draft text on the framework for a long-term future plan for the

Amy: I noticed this is on the retreat agenda, so let's keep this in progress.

     o Roman Danyliw to draft text for a request to the Tools Team to move
       BoF requests from the BoF Wiki to the Datatracker.

Roman: We're in progress.

     o Alvaro Retana, Warren Kumari, and Barry Leiba to draft clarifying
       text on Errata Best Practices.

Warren: In progress.

     o Murray Kucherawy to find designated experts for content SDP
       Parameters, QoS Mechanism Tokens [IANA #1175036].

Amy: This is a management item at the end of the call so we'll mark this
provisionally done.

     o Eric Vyncke to follow up on the suggestion at IETF 108 to share a
       list of grammar checking tools with the community.

Eric V: Still need to compile it, so work in progress.

     o Barry Leiba to discuss possible datatracker feature request
       regarding flagging who is responsible for the next step for a
       document; the document authors, the WG Chairs, the AD Discuss
       Holder, or the Responsible AD, with Robert Sparks. The feature
       request should include a "length of time in state" flag.

Barry: Technically that's done because I've sent a message to Robert, but let's
leave it on until I have something to report back.

     o Robert Wilton and Warren Kumari to draft a charter for a proposed
       IOTOPS Working Group.

Rob: In progress, we should be able to share it with the IESG fairly soon.

     o Martin Vigoureux to find designated experts for RFC-ietf-babel-
       rfc6126bis [IANA #1178016]

Amy: This is just to alert you that you have an action item.

Martin V: This is in progress.

     o Barry Leiba to find designated experts for RFC 8908 [IANA #1178597].

Amy: This is also just to alert you that you have this action item.

Barry: Mark that complete, because when we get to the management item I'll tell
you who the experts are and we can approve them.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-extra-imap-fetch-preview-09  - IETF stream
   IMAP4 Extension: Message Preview Generation (Proposed Standard)
   Token: Barry Leiba

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

Barry: I don't think so. We've been discussing it by email and I think we're
fine with that. Robert, quickly, if we remove that one phrase, would that be
enough to clear this?

Rob: Absolutely.

Barry: Okay. As I said, I believe Michael has already said he's going to remove
that, so I think we'll be good. Thanks. Leave this in Revised ID Needed, please.

 o draft-ietf-bess-evpn-na-flags-06  - IETF stream
   Propagation of ARP/ND Flags in EVPN (Proposed Standard)
   Token: Martin Vigoureux

Amy: I have a few Discusses in the tracker; do we need to discuss any of those

Martin V: Let me check. Maybe I'd like to discuss Erik K's. Thank you all for
your reviews and comments and Discusses. Erik, do I understand correctly that
you are asking or suggesting that there is a linkage between that document and
any future NA flag or ND extension? I wasn't sure.

Erik K: My concern is that it's really just dealing with the ARP function of
ND. The whole ND infrastructure in v6 can do more than just link layer
resolution. People propose at various times that we should include a new
message for this, and a new message for that, and so IPv6 ND proxying is
notoriously tricky to get right. We don't even really have a document about how
to do it. We have an experimental proxy ND protocol, I think it's still
technically experimental, and some other text in other places, but it's never
been really codified anywhere. This is partly why. It's not just this link
layer address resolution feature. I'm worried that it's an embrittlement of the
protocol, the idea that you couldn't deploy a new on link neighbor discovery
feature because BGP didn't allow it seemed kind of humorous to me.

Martin V: This I understand but I don't view things that way. I think whatever
future work would be done in the context of ND is not blocked, and I don't see
how it could be blocked by that document. I believe whatever is defined in the
future, in the context of ND, is not necessarily needed for the BGP EVPN.

Erik K: It might be, or it might not be. It depends on the deployment context;
it's not blocked by the document per se, it creates a deployment where it
wouldn't work in that deployment.

Warren: And the fix is relatively easy, isn't it? It's not that this requires a
significant change to the document, it just shoves all this stuff here instead
of shoving it there.

Erik K: I have two proposals, and the one that you've described there is
untested. I basically tried to list off the cuff all the things I could think
of, in part to show there are some considerations here. The other thing I think
is reasonable is just don't do ND proxy, and instead just relay the messages.
If you see features you don't support.

Warren: I'll happily admit I think adding new stuff to NA is a bad idea,
because at some point we're going to run out of NA packet size. But with that
said, we don't yet know what might be added that might end up in basically all
NA packets in the future. In which case, if you don't do this for ones you
don't understand, there's limited utility in this.

Eric V: Unless you update it later.

Warren: Unless you update it later. Lets say we keep adding new flags, we're
just going to have to keep updating this document, which seems annoying.

Erik K: But at least the new flags could be used on this network deployment,
right? It would bypass the ND proxy and be less efficient, and it would be up
to the implementation to let some operator know that ND proxy was not being

Warren: It seems like having a more extensible design would be a really good
outcome. I thought it would just copy the flags as they were.

Erik K: That might generally be the case, however in truth probably 6MAN should
do the work to say if that's true or not. You never know what's involved,
right? The Nonce value, it probably should change on every NS/NA, right? You
probably shouldn't cache those things if you see them. There might be other
things you don't want to cache but an implementation wouldn't understand them. 
It's tricky for this reason. It's not just an ARP function.  You could include
node identifiers and things like that. I don't know if that makes any sense.

Martin V: I think it makes sense. What I'd like is to hear back from the
authors and have them engage in discussion with you. I primarily wanted to
better understand what you had in mind. Now I think it is clear. I understand
the rationale; let's see where the discussion goes. Okay?

Erik K: I think the simplest thing is just to advise that if you see any flags
you don't expect, as listed in this document, can you see anything other than a
TLLAO [crosstalk] Notice that this document is already fixing a problem with
proxying because the flags are gone. This has been seen in corporate IPv6
wireless deployments. For example, wireless APs tend to have a proxying and
deproxying function. We had several devices attached to an IPv6 capable SSID
and then immediately hop off because compliant implementations saw the ARP flag
disappear from the device that was the RA. Not immediately, it works for a
couple of seconds, then compliant implementations hop off. This document
attempts to address that but that already shows that there's complexity.

Martin V: Let's take things the other way round and say the BESS WG thinks a
new flag would be useful. Does it mean that this should be done elsewhere?

Erik K: A new flag in ND?

Martin V: Yeah. In the extended community.

Erik K: The immutable flag makes sense to me. It made sense in the document
that there are two flags involved, one is the set of ND flags, or logically
mappable to the set of ND flags, and the other is a set of flags specific to
the ND proxy operation.

Ben: There's quite a bit of space in the extended community, so you could
easily have a separate location for flags specific to EVPN or BESS and flags
that are inherited.

Martin V: So the field would be split between things which are specific to VPNs
and those that are inherited from NDP. They don't use the S flag, do they?
Anyway. Let's wait for Jorge to reply and see where it goes. Thanks. The other
two Discusses, thank you too; I think they are pretty straightforward to
address and shouldn't pose any issue. I believe we can mark this document
Revised ID Needed.

 o draft-ietf-i2nsf-capability-data-model-12  - IETF stream
   I2NSF Capability YANG Data Model (Proposed Standard)
   Token: Roman Danyliw

Amy: It looks like this document was supposed to be deferred but didn't quite
make it?

Roman: I clearly hit the wrong button; I thought I hit 'defer'.

Amy: You did hit defer, which is why I'm asking. I think we got caught up in
some Datatracker weirdness. We'll put this on the agenda manually for next
time; is that what you wanted to have happen?

Roman: For everyone's benefit, let's do that. I may pull it back after I have a
real chance to talk to all of the authors and the WG. I apologize if folks
didn't see it sooner.

Ben: What you did was from the document status page, just changing the State? I
think normal usage is from the IESG Evaluation Record page, the ballot page.
There's a "defer ballot" button there which has effects besides changing the

Barry: You can also manually change the telechat date.

Ben: Yes, which I'd argue for in this particular case.

Roman: Okay. Thanks for guidance on how to do that right and sorry again.

 o draft-ietf-mpls-sfl-framework-10  - IETF stream
   Synonymous Flow Label Framework (Proposed Standard)
   Token: Deborah Brungard

Amy: I have a couple of open positions here; Alissa and Warren, did you want to
state a position here? [No for both.] Okay. There are no Discusses in the
Datatracker so unless there's an objection now, this is approved.

Deborah: Let's do it as Revised ID Needed to incorporate some comments.

 o draft-ietf-calext-jscalendar-30  - IETF stream
   JSCalendar: A JSON representation of calendar data (Proposed
   Token: Barry Leiba

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

Barry: No, the authors need to respond to it. Just put it in Revised ID Needed

Ben: Quickly before we move on, does anyone have anything to add to my comment
about the slash character in time zone identifiers? I'm pretty confused and I
don't know if it's just me.

Warren: I seem to remember reading that, thinking someone else understands it,
and stopping reading.

Ben: It's number 6 in the Discuss section.

Barry: I'll have to go check.

Ben: We don't need to talk about it today.

Barry: Slash characters are normally used in time zone identifiers but I'll
have to go check the references. Also the authors need to respond anyway and
they'll probably have something to say about it.

 o draft-ietf-spring-srv6-network-programming-20  - IETF stream
   SRv6 Network Programming (Proposed Standard)
   Token: Martin Vigoureux

Amy: We have some Discusses here; do we need to discuss any of those today?

Martin V: It really depends on the ADs who raised the Discusses. I'm happy to.
My understanding is that [the author] is really on top of that and has already
addressed some of the comments and is planning on replying to each and every
Discuss. I didn't see anything critical; I did see some very good points, thank
you. There is one aspect I would like to discuss, Alvaro, your point 5. This
point is for the IESG to discuss. I'd like to better understand what you are
looking for, because I have a possible concern with that suggestion. This
document has IETF consensus, or it will ultimately have it when I approve it,

Alvaro: Yes, correct.

Martin V: So that means everything which is written has IETF consensus. I think
it would be very confusing to find in that RFC a note which reduces or scopes
the level of consensus for a particular part of that document.

Alvaro: This is what I think. Maybe I'll just throw the ball over to Eric. Yes
you're right, this is going to be an IETF consensus document. What it says
about 8200 in that section is what the WG reached consensus on. Or that
interpretation of 8200. Of course, 6MAN has discussed how to interpret that
part of 8200 at least 3200 times. I don't think they have reached a consensus
other than 'you can interpret this in different ways.' By leaving it the way it
is now, it seems to imply that the IETF agreed this is the implementation of
8200. I don't think 6MAN has reached that consensus. In other words, there
could be documents in the future that interpret 8200 this way, and that's
perfectly fine. There could be documents in the future that interpret 8200 in a
different way and define a different behavior. That's probably fine, but this
document shouldn't be the one that calls the consensus on how 8200 is

Warren: I agree with that. I think it's awful we might have to have this whole
set of discussions again about what 8200 means. I really wish that 6MAN could
come to a consensus agreement on what it actually means. I would go further and
say that for this particular use 8200 is interpreted in this particular way.
It's not that the consensus of SPRING is that, but for this document we're
interpreting 8200 in this particular way.

Eric V: I don't agree when you say 6MAN agrees that it's 8200 or not. 8200 is
an IETF consensus document, so it's not under 6MAN ownership anymore.

Warren: Sure, but it's unclear what 8200 means. Different people have different
interpretations, and in 6MAN when the document came out and people asked what
exactly did you mean, some said they meant Y and some said they meant Z. The
fact that 6MAN can't explain what the actual consensus was shows that where the
document came from is unclear and having other WGs interpret it for the entire
IETF seems interesting.

Martin V: I understand the point, but still the whole IETF had the opportunity
to comment on that specific sentence.

Eric V: IETF Last Call, indeed.

Martin V: So I'm concerned by the fact that we would be now saying that
specific sentence is only SPRING.

Warren: I think when people read this and commented on it, some people assumed
it meant one thing and others assumed it meant something else. That's a
discussion we've had. To me this feels like while trying to use one of our
documents we've discovered an ambiguity, almost like an errata. I don't think
we should actually do an errata, because this is much too large a problem to
solve with an errata.

Erik K: Two errata were already filed. And a draft was written as well to
clarify this point, and that draft failed to get consensus. We're in the state
where the document has shipped and the current feeling in the WG, which might
not always be the case, can't come to agreement yet about how to revise or
clarify interpretation of this.

Warren: Which is exactly my point. Having SPRING decide for them feels ....

Martin V: SPRING didn't decide anything for anyone. SPRING produced a document
and submitted it to the whole IETF.

Alissa: The precedent that this kind of thing sets is pretty atrocious. We have
documents which are supposed to be consensus of the whole IETF but we start
picking off sections and sentences saying this part isn't the consensus of the
whole IETF, just this one WG. That will degrade very quickly if it happens
repeatedly. I don't see how we can claim the whole text has consensus of the
IETF except this one part that doesn't.

Alvaro: For what it's worth I'm fine with Warren's warning, which was that for
this application, this is how we interpret it. The opposite of what you just
said is also true. If a WG can't agree on what they wrote, and some other WG
interprets it for them, that's also a slippery slope.

Ben: My sense here is that 8200 is a flawed document and when I was reviewing
the SPRING document in front of us I was forced to read the words on the page
of 8200 and take what they say, for lack of a better option. Not wanting to
reopen 8200 as a dependency of this document. On the other hand, it does seem
like 8200 is the crux of the issue here. It occurred to me that in light of
some points raised about 8200, the text in 8200 is seen as adding a feature
that was not in 2460, we could do something crazy like make a status change
document to take 8200 back to Proposed Standard, which is what it should have

Eric V: I don't think we need to reread again 2460 to be sure that this
behavior was most probably already there.

Ben: I didn't read 2460 either. The question about deleting may have been
differently specified. The prohibition about inserting has been there for a
long time but the text about deleting may have changed.

Warren: As far as I understand, when 8200 was published, the group admitted
that this part was intentionally left open to interpretation or vague. That now
it's being interpreted in a specific way and written down as what they must
have meant, feels incorrect.

Martin V: I don't think the text in that draft says this is the only possible

Warren: It doesn't say that it chose to interpret ambiguous text in a specific
way, so anyone reading it in the future is going to think SPRING interpreted it
this way, there's IETF consensus, therefore it must mean X. For the purpose of
this document we have interpreted it in this way.

Martin V: The point here is that the text is not ambiguous. The text is very

Warren: If that is true, how come 6MAN can't say it's very clear and that's
what they meant?

Erik K: It's hard to re-litigate the past but it's more along the lines that
people thought they got the edits they wanted because they were each holding to
their own interpretations of the text. It was never really tested against other
possible interpretations until now.

Rob: One question is, does this sentence need to be in the document at all? Is
one solution just to remove it?

Eric V: Or change it. Have you seen Alissa's suggestion in the chat?

Alissa: It's there for a reason, right? It came at a crucial point in this
document. I'm assuming it's better to keep some version of it.

Ben: I do wonder if having it in this section in the body of the document makes
more sense or if it would make sense to have this topic covered by an IESG note?

Eric V: The topic being what specifically?

Ben: The interaction of PSP with 8200.

Alvaro: I don't think we need an IESG note. This is one flavor in one
sub-sub-subn section clarifying that sentence is enough.

Warren: Alissa's text seems reasonable. I do still really think that it would
be really useful if 6MAN could document what exactly this is supposed to mean.
I don't really care which way they do it but I don't want to have this fight
again next month, or ever.

Erik K: There was a document that attempted to clarify this in the direction of
the most vocal opinion at this time, and that has not gone anywhere. Secondly,
this particular ambiguity we're talking about applies to routing headers only.
The only time this ambiguity can come up is in contemplating the context of the
action association with future routing headers.

Warren: I fully get that. I'm just concerned. Maybe not tomorrow or next week
but at some point someone is going to want to touch this again and having
people point at this as precedent or something seems ...

Erik K: They can point at the text of both errata and the text that was written
in the appeal, as well, not just this text.

Ben: If we're talking about fixing 8200 I'd rather not focus quite so narrowly
and I'd prefer to have some guidelines or sense for how routing headers are
supposed to work and what constraints there are on what behavior can be changed
by the routing header. Right now it's an open slate so SPRING is free to
consider many things that may be surprising to people.

Warren: At the root of much of my disquiet is that a WG came up with a
document, there are ambiguities, and a different WG is choosing to interpret
the ambiguities in a specific way. The very fact that the original WG can't
simply clarify feels bad. I'm abstaining on the document because I think there
are a lot of other things not good with it, so maybe I should stop talking.

Erik K: I don't disagree with your assessment of the state of 6MAN consensus on
this point; it's certainly far from ideal.

Eric V: I have a hard time seeing 6MAN agreeing on a consensus of
interpretation of this section. So this is wishful thinking, removing the
ambiguity, but it would be nice.

Martin V: I think we are in a situation where it will likely be impossible to
have one and only one reading, because we have one document in front of us who
reads the words exactly as they are written and if we end up concluding in 6MAN
that you shouldn't read them that way, we are impacting a deployed technology
and existing standards and that would be strange.

Warren: We do that with errata; that would not be uncommon for us to say.

Erik K: The text Alissa proposed seemed reasonable to me.

Alvaro: It works for me too. Alissa suggested we just add at the beginning of
that paragraph: "In the context of this specification, the End, End.X and End.T
behaviors with PSP do not contravene Section 4 of [RFC8200] because the
destination address of the incoming packet is the address of the node executing
the behavior."

Martin V: Seems reasonable. If the Discuss holders are happy with that, and
they can find agreement with the authors, I think I can live with that too. I
won't go through all of the Discuss points. Thank you very much again for your
reviews and this is obviously a Revised ID Needed.

 o draft-ietf-regext-rdap-sorting-and-paging-17  - IETF stream
   Registration Data Access Protocol (RDAP) Query Parameters for
   Result Sorting and Paging (Proposed Standard)
   Token: Barry Leiba

Amy: I have a couple of Discusses in the tracker for this document; do we need
to discuss those today?

Barry: We don't. We have to sort out what to do with the JSON path references
and that's going on over email. Ben had an interesting Discuss about the
sorting order and we'll sort that out by email as well. This will be Revised ID

 o draft-ietf-avtcore-cc-feedback-message-08  - IETF stream
   RTP Control Protocol (RTCP) Feedback for Congestion Control
   (Proposed Standard)
   Token: Barry Leiba

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

Barry: No. Colin responded to Magnus's Discuss and suggested that he will put
some text in. We'll see what he comes up with. Revised ID Needed. Thanks.

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


3.4.2 Returning items


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


4.1.2 Proposed for approval

 o Revision of core Email specifications (emailcore)

Amy: I have no blocking comments, so unless there's an objection now it looks
like emailcore has been approved.

Barry: Sorry everyone that we don't have milestones in there. I'm continuing to
push on the chairs to get milestones as soon as possible so we should see those
any day now. Warren, in response to your comment, the first sentence of the
charter says what the base email specifications we're talking about are.

Warren: I did see that. That's where I copied and pasted from. I just wasn't
sure if it was worth adding the part about these being the ones that will
update. Either way.

Barry: I think it's clear enough. Ben, I rephrased the bit I put in for you
about the security stuff. Take a look and see if you think it reads better now.
Barring Ben coming back and saying it still reads awkwardly, I think we're

Amy: I'm hearing no objection to approving emailcore so we'll send the WG
action announcement tomorrow.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review


4.2.2 Proposed for approval


5. IAB news we can use

Alvaro: No news this week.

6. Management issues

6.1 [IANA #1177950] Designated experts for RFC 8894 (IANA)

Amy: This document was an individual document shepherded by Alexey. Is this
something one of the ART ADs wanted to tackle?

Roman: If not the ART folks, I'm happy to try to shop for it.

Murray: This is a bunch of acronyms I don't recognize so if you know what this
is, by all means. I don't want to step on Barry if he wants to.

Barry: It's on your side. Somewhere between you and Roman you should be able to
figure it out.

Murray: Okay. I'll go brush up on this RFC and sync up with Roman.

Amy: Okay, I'll assign this to both of you.

6.2 [IANA #1178016] Designated experts for RFC-ietf-babel-rfc6126bis (IANA)

Amy: We assigned this to Martin V at the top of the call so he's working on
experts there.

6.3 Approval of an additional Designated Expert for the "OAuth Authorization
Server Metadata" registry (Roman Danyliw)

Amy: Roman, you want to add Dick Hardt as an additional expert?

Roman: That's right. Overall I'm trying to overhaul some OAUTH registries to
make sure there's sufficient backup to get timely approval. That's why I want
to add Dick here.

Amy: Any objections? Hearing none, so we'll send official note to IANA.

6.4 [IANA #1175036] Designated experts for content SDP Parameters, QoS
Mechanism Tokens (Murray Kucherawy)

Amy: It looks like we have someone who wants to be replaced and has suggested
his own replacement.

Murray: I just got an email back from Christer moments ago confirming that he's
up for the job, so that's the proposed assignment.

Amy: Any objection to naming Christer as Gonzalo's replacement?

Barry: An excellent choice.

Amy: I'm hearing no objection, so we'll send note to IANA.

6.5 [IANA #1178597] Designated experts for RFC 8908 (IANA)

Barry has already found Tommy Pauly, Darshak Thakore, and Martin Thomson. Any
objections? Hearing no objection, so we'll send official note to IANA.

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

Reminders: The IESG retreat is next week and there's a Doodle out for BoF
coordination call times.