Skip to main content

Narrative Minutes interim-2021-iesg-06 2021-02-25 15:00

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

Narrative minutes for the 2021-02-25 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
Michelle Cotton (ICANN) / IANA Liaison
Roman Danyliw (CERT/SEI) / Security Area
Martin Duke (F5 Networks Inc) / Transport Area
Lars Eggert (NetApp) / incoming IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Wes Hardaker (USC/ISI) / IAB Liaison
Benjamin Kaduk (Akamai Technologies) / Security Area
Erik Kline (Google) / Internet Area
Magnus Westerlund (Ericsson) / Transport Area
Martin Vigoureux (Nokia) / Routing Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Barry Leiba (Futurewei Technologies) / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / incoming Applications and Real-Time Area
Alvaro Retana (Futurewei Technologies) / Routing Area
Alice Russo (AMS) / RFC Editor Liaison
Zaheduzzaman (Zahed) Sarker (Ericsson) / incoming Transport Area
John Scudder (Juniper) / incoming Routing Area
Amy Vezza (AMS) / IETF Secretariat
Eric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area

Jay Daley / IETF Executive Director
Sandy Ginoza (AMS) / RFC Editor Liaison

Al Morton
John Klensin
Lucas Pardue
Greg Wood

1.2 Bash the agenda

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

1.3 Approval of the minutes of past telechats

Amy: The last telechat was just last week and we generally give you two weeks
to review the minutes. Does anybody need more time for these minutes?

Eric V: I had no time, sorry.

Amy: Okay, we'll keep the February 18 minutes and approve them next time.

1.4 List of remaining action items from last telechat

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

Amy: This is on the agenda as a management item so we'll skip this for now.

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

Alvaro: I just added that to the list of possible topics for next week at the
pre-IETF meeting so we can close on it next week.

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

Amy: This is also on as a management item for discussion today.

     o Martin Vigoureux and Alvaro Retana to work with Jay Daley on the
       process for using EthicsPoint incident management software as
       the mechanism of private feedback and anonymous reporting.

Martin V: I think we can close this one. We've reached a point where we can now
try building a version of the EthicsPoint for the IESG. I need to reach out to
Jay or Greg whether we can do that in a sandbox. As for the descriptions, I
think Wes, Alvaro and I have reached consensus on what to write. So at some
point in the future I'll ask you to create a new action item.

     o Erik Kline to find designated Experts for RFC  8915 [IANA #1179647].

Amy: This is also on as a management item so we'll mark this as provisionally

     o Warren Kumari, Deborah Brungard, Stephen Farrell, and Jay Daley to
       investigate ways to recruit, recognize, and retain volunteers in the

Warren: That's in progress and we're making progress. We are talking about
adding stuff to the survey to better understand why people volunteer and how
they feel about it. It's turned into participation [overall], not just

     o Erik Kline to find designated experts for RFC 8928 [IANA #1183445].

Amy: This is also on as a management item so we'll mark this as provisionally

     o Ben Kaduk to find designated experts for RFC 8935 [IANA #1184035].

Ben: I've been trying to get in touch with one of the two people I was
proposing and haven't heard back, so I'm going to have to ponder whether I
should just go forward with the one, ask somebody else, or keep trying. Let's
leave that in progress for now.

     o Murray Kucherawy to find designated experts for RFC 8839 [IANA

Amy: Murray, you asked us to add this as a management item last week but I
don't think we have the names.

Murray: I forgot to send the name. Christer Holmberg has volunteered. You can
leave this as a management item. And last week we dispatched with [a designated
expert] for 8855. We appointed Brian Rosen and IANA has requested I look into
getting a second one. I don't know if you want to add that as a separate item
or if I should just bring it back when I have someone.

Amy: We'll re-add that as an action item for you.

     o Eric Vyncke to draft text for the WG Chairs about requesting early
       review of documents by existing Directorates.

Eric V: It's a work in progress in the sense of to be started. But it's in

     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: We'd dropped this for a few months and brought it back for February.

Alvaro: I think we should do something about this one. Probably not for next
week, but I guess Rob, Martin and I should take the ongoing action on talking
about this.

Alissa: I should get dropped from this.

Amy: Okay, we'll keep this on the action item list and go forward with Alvaro,
Rob, and Martin V.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-cdni-uri-signing-21  - IETF stream
   URI Signing for Content Delivery Network Interconnection (CDNI)
   (Proposed Standard)
   Token: Barry Leiba

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

Barry: We do not. We're getting responses from the authors about that and the
discussion continues online. We'll definitely need a Revised ID.

 o draft-ietf-6lo-blemesh-09  - IETF stream
   IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP (Proposed
   Token: Erik Kline

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

Erik K: I haven't seen the authors reply to any of the comments just yet. I
think the comments are all intelligible and actionable so I would say let's let
the authors have a chance to get around to them. Unless people want to discuss
stuff, I think maybe just Revised ID Needed.

 o draft-ietf-ippm-capacity-metric-method-06  - IETF stream
   Metrics and Methods for One-way IP Capacity (Proposed Standard)
   Token: Martin Duke

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

Martin D: No, I'm just now reading through them since it's early here. It seems
fine. Al has been very good about replying so I'd expect in a day or so we'll
have replies from the author and we'll see where we are from there.

Murray: Can I take two minutes here just to talk about the SHOULD stuff I
brought up earlier? Not specifically about this document, but generally.
Deborah corrected me last time I brought this up, about using that sort of
language to describe the way information should be presented. I think she
referred to it as operational documents, or operational advice. I guess that's
starting to become a typical way to describe the way you should present
operational advice to operators, or something like that. Is this something we
should write up in an IESG statement, or a revision to BCP 14 or something? I
keep tripping on this as something [that] by the letter we shouldn't allow, but
it seems like it's becoming more common and if it's a tolerated thing, we
should write that down somewhere.

Martin D: I've seen it a lot in security documents, where something should be
logged, or someone should be notified, when their privacy has been violated or

Murray: 2119 calls out security as a reason to use it, and obviously
interoperability is a reason to use it, but the way you show it something on a
screen is not typically what I think of as falling under either of those
things. Deborah just unmuted so maybe she can set me straight again.

Deborah: I forget what I was referencing, but we used it in a couple of
references. I think we should definitely look at it. We don't necessarily need
an IESG statement but maybe some guidance, or something. Since I'm now two
weeks or less out, Warren in OPS maybe has some good guidance there.

Warren: I'm happy to try and work on this. It is relatively common and I think
it's relatively common for a good reason, so we should clarify that.

Murray: I'll figure out how to introduce this as a work item and clear the
Discuss. Thanks.

Barry: Let me add something. We often refer to BCP 14 keywords as normative
language, as though if you don't use BCP 14 keywords what you say isn't
normative. And I really want to push on that not being the case. The point of
BCP 14 is to make specific definitions of specific terms that have specific
meanings, but if you just say, "you lowercase-must do this" it's still a
normative statement in the document. Maybe we need to try to steer the
community toward not using the BCP 14 keywords for this sort of thing but still
saying "you have to log this" [etc].

Warren: One of the issues with that is having it in uppercase makes it much
much much easier to find. When you've got a huge stack of documents and you're
trying to figure out which are the things I actually really need to do,
searching for uppercase MUST makes it easier.

Barry: That's true. Maybe the thing is to do an update to BCP 14.

Murray: If we agree that's what we want to do I'm happy to take that up, since
I'm the one who keeps tripping on this.

Warren: I'm happy to help.

Murray: That doesn't need to be a management item, when I get around to it I'll
make a draft.

Warren: Do you have an objection to making it a management item? Otherwise
we're likely to forget it.

Murray: My management items tend to drag on for a year so let's not do it that

Alvaro: This could go into GENDISPATCH or something, right?

Murray: It could start there, yeah. Okay, I'll take off my Discuss.

Martin D: Thanks Murray. Magnus, I haven't had a chance to process your Discuss
at all. Is it something we should talk about now?

Magnus: I think it has to do with how you apply the [unclear word]. I think the
metrics definition are fine, it's the measurement which is clearly
underspecified and I do not read them as requirements on how you would do a
measurement but not specify for a protocol, so I think it falls somewhere in
between and needs to be sorted out.

Martin D: Okay, let's see what Al says and you and I can talk offline. I think
this is still Revised ID Needed.

 o draft-ietf-calext-valarm-extensions-05  - IETF stream
   VALARM Extensions for iCalendar (Proposed Standard)
   Token: Barry Leiba

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

Barry: It has been discussed and resolved, so we're just waiting for a Revised
ID. Thank you.

 o draft-ietf-pce-pcep-extension-for-pce-controller-12  - IETF stream
   PCEP Procedures and Protocol Extensions for Using PCE as a Central
   Controller (PCECC) of LSPs (Proposed Standard)
   Token: Deborah Brungard

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

Eric V: I just quickly read the reply from the authors and it looks like Erik,
you had the same Discuss as me. I was unaware. If it was solved for Erik, maybe
it's solved for me as well.

Erik K: The author referred me to where this structure comes from in another
document. I agree it looks weird to me, two remote interface IDs, but it's a
pre-existing thing and he said they could be adding a reference to it. I don't
know if he intends to do that or not but I understand that within the context
of people who need to read this it may be a well known thing.

Eric V: But if someone made a mistake two years ago are we obliged to repeat
the same mistake again and again?

Deborah: Even if the Discusses are removed I will always say Revised ID Needed
so we can check through everything.

Erik K: To your point, Eric, if you want to have a larger discussion about
whether or not that pre-existing structure is actually a thing that needs to be
carried forward....

Eric V: At least the name should be changed, right? It's not

Erik K: It's a pair of link local addresses, he says.

Eric V: It's a global address. Something is wrong in the definition. It's
either linked locally or globally. It can't be both at the same time.

Erik K: I'll check his reply to you and maybe we can see where it goes.

Eric V: Okay. Revised ID Needed, I'm afraid, Deborah.

Deborah: Definitely.

 o draft-ietf-mpls-rfc6374-sfl-09  - IETF stream
   RFC6374 Synonymous Flow Labels (Proposed Standard)
   Token: Deborah Brungard

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

Deborah: That was kind of a late one, right? I think we'll wait for a
pen-holding author to respond, so this should just stay in IESG Evaluation,
Revised ID Needed.

 o draft-ietf-lamps-cms-aes-gmac-alg-03  - IETF stream
   Using the AES-GMAC Algorithm with the Cryptographic Message Syntax
   (CMS) (Proposed Standard)
   Token: Roman Danyliw

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

Roman: Minimally, I'm going to send some of the language we opened the meeting
with in chat, because I think that's great guidance.

Amy: It looks like this one is approved. Did you want this in AD Followup?

Roman: Can you mark it as Revised ID? I want to address Ben's comment too.

Amy: Okay, you can let us know when that's ready.

 o draft-ietf-stir-rph-emergency-services-06  - IETF stream
   Assertion Values for a Resource Priority Header Claim and a SIP
   Priority Header Claim in Support of Emergency Services Networks
   (Proposed Standard)
   Token: Murray Kucherawy

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

Murray: Ship it. I don't think it needs anything. Ben, is there anything you'd
like to wait on a reply to before I ship it?

Ben: I think adding more references in the security considerations is pretty
worthwhile, so I'd like to see that. I don't think the other stuff I need a
response to.

Murray: Okay. Can we do AD Followup and I'll ask them to do that and we'll go
forward from there.

Amy: Certainly. It does have a downref; does that downref for 7135 need to go
into the downref registry?

Murray, later: Yes, please update the downref registry.

2.1.2 Returning items

 o draft-ietf-v6ops-cpe-slaac-renum-07  - IETF stream
   Improving the Reaction of Customer Edge Routers to IPv6 Renumbering
   Events (Best Current Practice)
   Token: Warren Kumari

Amy: I have no Discusses in the tracker, so unless there's an objection now, it
looks like this is approved. Okay, hearing none. I see no notes in the tracker;
are there any needed?

Warren: I don't think so, no. It's all ready to go.

Erik K: I suggested one textual change to Fernando. He replied but I haven't
seen it yet.

Ben: I had a suggested change too.

Warren: Okay, Revised ID Needed.

2.2 Individual submissions
2.2.1 New items


2.2.2 Returning items


2.3 Status changes
2.3.1 New items

 o status-change-rdap-to-internet-standard-01  - IETF stream
   Advancing the Registration Data Access Protocol (RDAP) to Internet
   Standard (None)
   Token: Barry Leiba

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

Ben: I did not get to polish up my comments yet, and I don't intend to ballot
Discuss, but I did want to talk about one or two things. The first one was
about the stance on TLS usage. If you look through 7480 it seems to come across
as, "You can use HTTP, but oh, you can also use HTTPS if you want." But then if
you look at 7481 it seems to be a much stronger "you must use TLS unless you
have something that provides equivalent services," or something like that. I
don't remember [exactly]. If you had looked at that more carefully it would be
reassuring to know what the intended state is.

Barry: So 7480 is the HTTP usage and 7481 is the security service. Okay. Amy,
is there some equivalent to AD Followup you can put this in? Or if it's not a
formal state, just hold it until I tell you otherwise.

Ben: It's sort of an awkward position where if we were opening the documents
up, I would have some comments on them, but I don't think they're huge
problems. I also don't know there's something we could really put more text in
a status change document about. I might just have to swallow my concerns and
let this go forward.

Barry: I will say that in practice, RDAP is always used over HTTPS. I'll check
if that's in the documents.

Ben: Thanks.

Amy: So this will go into Point Raised and we'll wait for instructions from
you, Barry.

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

 o draft-crocker-inreply-react-08  - IETF stream
   React: Indicating Summary Reaction to a Message (Experimental)
   Token: Barry Leiba

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

Barry: No we don't. This will definitely be Revised ID Needed. There is still
some ongoing discussion about the use of emoji code points and how it's
referenced and specified in the document.

Ben: Could you maybe try to summarize the discussion about the stability, or
lack thereof, of the UTS#51 reference?

Barry: The main problem is that the document refers to that as a source of ABNF
for the emoji sequence, and there isn't actually ABNF in that document that
specifies emoji sequence. It would probably benefit from some rewording that
text to clarify how that document should be used by a reader of this one as a
reference. There's also some concern about using emoji sequences at all for
this. My view is that as an experiment, it should be part of the experiment.
Given that, there needs to be more text in there about how we determine whether
the experiment succeeded in that regard.

Ben: Thanks for doing that. I was a little confused with all the messages going
back and forth.

Barry: There have been a lot of long messages and multiple threads with
different people on them, so it's been hard to collect them all. But those are
the main points.

Amy: Okay, so we'll have that in Revised ID Needed.

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


4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o QUIC (quic)

Amy: I have no blocking comments for this. Is there any objection to sending
this text for external review?

Magnus: Sorry, I'm a bit unprepared. Have there been any comments?

Amy: I suppose I should ask, it says that the checkbox wasn't checked for just
making the changes. Is this a big change?

Magnus: Yes. I see Ben has some...

Ben: For the most part, my comments are editorial in nature. I don't think it
needs to hold anything up.

Magnus: Yeah, but at the same time the next telechat is on March 25 so we could
actually wordsmith it before it goes for external review. Let me look into this
and I will tell the Secretariat when it's ready to go out.

Amy: Sure, so external review is approved but this is on hold pending edits.
You can let us know when it's ready to go.

4.2.2 Proposed for approval


5. IAB news we can use

Alvaro: One piece of news this week; Mirja was selected to continue as IAB
Chair, so congratulations to Mirja.

Mirja: I don't think it's officially announced yet, but thanks. Not a big
surprise as I was the only candidate.

6. Management issues

6.1 I-D Checklist Updates (Alvaro Retana, Benjamin Kaduk, and Murray Kucherawy)

Murray: I was just about ready to say the final version is there but I've seen
edits in the last two days and the RFC Editor has said Greg Wood wants to take
a look at it. I'm going to close editing on it later today and send the last
version out for everyone to look at and give final blessing on. So I guess we
can approve it at the next telechat or one of the meetings during 110.

Amy: If you all think it's ready you can do it next Wednesday at your next

Murray: I'll make sure the final version is available for a few days before

6.2 [IANA #1187517] Designated experts for RFC 8839 (Murray Kucherawy)

Amy: Murray identified Christer Holmberg. Is there any objection to approving
Christer as the designated expert for RFC 8839? I'm hearing no objection, so we
will send that official note to IANA.

6.4 Designated experts for RFC 8915 (Erik Kline)

Amy: Erik has identified two people: Miroslav Lichvar and Daniel Franke. Any
objection to approving them as experts for RFC 8915? I'm hearing no objection,
so we will send that official note to IANA.

6.5 Errata Best Practices (Alvaro, Warren, and Barry)

Alvaro: If you don't mind I'm going to show the document. There are a couple of
comments I want to talk about today. Just as a reminder, we had put out a
statement in 2008 and this is the revised statement we want to put out soon.
The two big changes are that the RFC Editor has agreed to handle obvious
editorial errata, so instead of sending us reports and us having to deal with
them, they're going to deal with those. If they go beyond an obvious editorial
problem, they're going to get us involved. The other change is in the actual
guidelines. Before I go into that I want to also mention that Sandy is talking
to the other stream managers to see how closely they can follow these
guidelines as well. It would be ideal for the RFC Editor to have one process,
but also it would be ideal for others to handle errata in a similar way. So the
guidelines are grouped. The first three are around editorial changes, then we
go into more of the technical issues, and then we talk about registration
processes for example and how-- [crosstalk]

[Various people talking about how to zoom in to the document on the screen

Alvaro: Okay, so the comments were that for editorial reports we should verify
everything that is obvious. Martin was asking why don't we do the same thing
for technical errors? The technical errors are numbers 4 and 5. In 4 we're
saying that anything that could cause implementation or deployment problems or
significant confusions should be verified. Then we say things that don't should
be held as document updates, so Martin's question was why don't we just verify
everything? I think that's okay, assuming there is a description of changes,
that it's easy to display. One of the things around verified errata is it's
going to be displayed inline with RFCs.

Barry: When we were working on this, my thought was, and I think it was just
worded badly and we need to reword it, is that we often get reports where yes
it's clearly an error, but the resolution of that situation, whatever's in the
errata report is not necessarily the right way to solve the problem and more
discussion needs to happen in order to figure out how to resolve it. That's
what I'm trying to get at here in that bullet. It's that there's an error here,
but more discussion is needed to figure out how to fix the error, and those
should be held for document update.

Martin D: What is the cost of verifying an errata vs. holding for document

Barry: What I don't want to happen is for a resolution of an error that
somebody found to be displayed as part of the RFC when you say "I want to see
verified errata in here" without having the relevant subset of the community
agree that that's the right solution.

Martin D: I completely understand your point and I agree with it. I'm zooming
out to ask a broader question. I was under the impression this whole time that
we held the document updates as some kind of administrative overhead in
actually verifying errata and having the RFC Editor do something, so we were
kind of conservative about doing that. Is that accurate?

Barry: If it was accurate it's not anymore. I think the issue now is that if
we're talking about optionally displaying verified errata inline, we need to
think about that when we verify errata and say we definitely think this is the
right solution and should be displayed inline with the RFC. There was a time
when people were just reading every RFC and submitting errata reports on every
missing comma, and there was a thought at the time these guidelines were
originally written, that we didn't want to reward that and go verifying every
errata report. I think that time has passed and we should not worry about that
at this point.

Martin D: Okay, so the principle now is if the correct verbiage is clear and
uncontroversial, we should go ahead and verify the errata.

Barry: That's what I think, and I think that's what Alvaro thinks, right?

Alvaro: Yeah, that works for me.

Barry: If we need to reword this to make that clearer, that would be great. The
point is that if you would like both the error and the solution to the error to
be displayed when somebody reads the RFC because it's important for them to see
that, then it should be verified.

Martin D: I'm completely comfortable with that outcome. My only issue was with
what I thought was the inconsistency, but from what you said Barry, that seems
to be the best way forward.

Alvaro: So we'll work on updating that. That's number 5. The other comment from
Rob was around this text in number 6, talking about changes to modify a
protocol to something that might be different from what the WG had consensus
on, and then it says in unclear situations, small changes can be classified as
Hold for Document Update. Rob's comment was around the size of the change. Why
small changes? The way I was reading this is that if we know it modifies the WG
consensus we should reject it. If we don't think it modifies the WG consensus,
then we know it falls into the other categories. So what I'm thinking is we can
get rid of that sentence.

Mirja: I'm not sure I'm certain about that point. If there is something which
is clearly wrong but there's no consensus about how to resolve it, I would put
this on hold for document update. Right?

Alvaro: That's what I mean, it falls into 4 or 5.

Barry: I think, Mirja, if you think that doesn't fall into number 5 that needs
to be reworded to make it clear that it does.

Alvaro: Okay, and we can reword that. I'm going to get rid of this sentence
[too]. Then there's one last comment that I hadn't seen; here we said how to
handle obsolete errata. This says that it is considered only if the error
persists in the RFC that superseded the obsolete one. Ben's comment is that it
would be better to duplicate the report, or generate a new one, rather than
retargeting it. Is there any change we need to do here? You mean instead of
changing the reference, there should be a new report filed?

Ben: Yes, that's what I was going for.

Alvaro: Sure, we can reword that.

Rob: So then they need to say what to do with your one as well. When you make a
duplicate report against the new RFC, you need to say what to do with the
report on the old RFC.

Alvaro: Right, well, then it depends on whether it's editorial or anything else.

Rob: Even for one that's obsolete?

Alvaro: The obsolete one is only considered in the obsoleting RFC. The
obsoleting RFC is not obsolete, that's the superseding one.

Barry: But the question is if somebody does a report on an obsolete RFC, and we
find this has not been corrected in the new RFC, if we make the change Ben is
suggesting now we have two errata reports, one on the obsolete one and one on
the new one. Is there value in maintaining the errata report on the obsolete

Alvaro: So the question is do we delete it or reject it? I think we reject it
and point in the rejection to the new report.

Ben: I would be happy with rejecting it, but I think there should still be a
record that there was an issue in that fixed immortalized RFC.

Barry: That makes sense. So this report rejected, but a new report is made on
the new RFC and that is verified.

Alvaro: Okay, good. So we'll work on these changes we talked about. As I
mentioned, Sandy sent this to the other stream managers for them to look and
consider. If they have any other comments or anything we'll come back here so
we can review again. If not, we'll let you know when we're ready to publish
this as an update to the old statement from 2008.

Mirja: I saw Sandy's message but I wasn't really aware of this document before.
Is this an IESG statement and is this the right place to put it?

Alvaro: There was an IESG statement from 2008. When Sandy talked to me about
other stream managers I told her I think anyone is free to use whatever
criteria they think of to verify or not. The one change that we're making here
to the process is that now the RFC Editor handles editorial errata directly
instead of sending it to us. To me that's the only real thing that matters for
the other streams. If we all could agree, maybe it's not an IESG statement, but
for now I think it's the right place to put it.

Barry: I think this should be an IESG statement that replaces the old IESG
statement. And generally the other streams have agreed with our criteria,
although they don't have to. The interesting one is the independent stream,
which now handles the April 1 RFCs. We occasionally get errata reports on April
1 RFCs and with older ones they come to us, because it predates the independent
stream handling it, and it's always kind of funny to handle errata reports on
April 1 RFCs. That's just babble.

Mirja: I actually think this is okay as an IESG statement. Maybe we should put
a pointer to this statement somewhere on the RFC Editor page during the 
process, like when you log in.

Barry: That's a good idea.

Alvaro: Not when you log in, but there's a link there to instructions from the
RFC Editor and in there is a link. Maybe we can move it there to make it more
prominent, that's a good idea. Okay, that's all I have. Thank you.

6.6 Designated experts for RFC 8928 (Erik Kline)

Amy: Erik K has identified two experts. Any objection to approving Pascal and
Mohit as experts for RFC 8928? Hearing no objection, so we will send that
official note to IANA.

6.7 Additional Experts for iCalendar registries - RFC 5545 (Barry Leiba)

Amy: Barry, you added this to give us additional experts.

Barry: Yes, one of the things with the iCalendar stuff is there's a small group
of people that deal with it and the experts often wind up being authors on the
documents, so we need more experts to cover that. So the two I've proposed are
very active in the iCalendar community and the CALEXT WG.

Amy: Is there any objection to approving Ken and Mike? No objections, so we
will send a note to IANA.

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

Amy: I just have a couple of notes; we need some GitHub IDs for a few of you.

Warren: Do you have a list of who you still need them from?

Amy: I don't want to call people out, but Warren, you're not on the list. 
We're also still waiting on the WG assignments for some areas, particularly TSV.

Martin D: I think for now it's just going to be a straight swap from Magnus to

Amy: Does that include the directorates?

Martin D: Is that just TSVART or is there something else?

Magnus: Give him everything.

Amy: Okay, thanks. Also, will Erik or Eric take ADD? Have you decided?

Eric V: I will take it.

Amy: And one last changeover note, I understand the directorates that Barry
has, you were thinking of closing APPSDIR?

Barry: Correct; it's basically replaced by ARTART.

Amy: Were you going to close that, or ask us to close that?

Barry: I thought I had asked. There's certainly no controversy about it. In the
closing notice, note that it's been replaced by ARTART.

Amy: I don't think we got clarification on who was going to take the
directorates, Murray or Francesca.

Murray: You can assign them to me and we can sort that out later.

6.3 Executive Session: GENDISPATCH mailing list (Alissa Cooper)