Skip to main content

Narrative Minutes interim-2022-iesg-07 2022-03-10 15:00

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

Narrative minutes for the 2022-03-10 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) / incoming Routing Area
Jenny Bui (AMS) / IETF Secretariat
Ben Campbell (Independent Consultant) / IAB Liaison
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
Benjamin Kaduk (Akamai Technologies) / Security Area
Erik Kline  / 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
Alvaro Retana (Futurewei Technologies) / Routing Area
Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area
John Scudder (Juniper) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
Amy Vezza (AMS) / IETF Secretariat
Martin Vigoureux (Nokia) / Routing Area
Eric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area
Paul Wouters (Aiven) / incoming Security Area

Jay Daley / IETF Executive Director

Lee-Berkeley Shaw
Greg Wood

1.2 Bash the agenda

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

Francesca: I have something to bring up later; it's about IESG evaluation
review comments. I can say more about it later if we can add it at the end.

Amy: I'll also add that I added a management item for the monthly activity
report that's been updated and we can take a look at the graphs.

Lars: I have two things. One is that we should take a last look at the joint
call for RSCE nominations together with the IAB. I think Cindy has been
preparing that under some wording changes. We'd like to send it out reasonably
soon after the documents are approved. The other one is the IESG and Chair
pre-meeting report which also needs to be published. Finally, there's a
presentation that's mostly me, but if somebody has something they think we
should mention during the plenary, let me know. Otherwise it will just be the
normal stuff.

Martin D: I don't know if we need to add an agenda item but I'd like to bring
up the newcomers' agenda again. There are a lot of missing descriptions, etc,
so please look at it if you haven't had a chance. I should get it to Greg
pretty soon. I don't think there's a reason to go over it with the group.

Éric V: Two of our WGs have yet to produce an agenda. I sent them an email this

1.3 Approval of the minutes of past telechats

Amy: Normally we give you two weeks to review the minutes. These are just from
last week so I think we can hold them until the next teleconference.

1.4 List of remaining action items from last telechat


     o Roman Danyliw to find designated experts for RFC 9180 [IANA

Roman: This is still in progress.


     o Alvaro Retana and Martin Vigoureux to draft a note to wgchairs
       asking them to always confirm author/contributor status.

Alvaro: I said we had a draft already but I guess I didn't send it anywhere.
Did we already publish the new shepherd writeup?

Amy: That's a good question; I know they've been talking about where to put it
but I don't know if it's been actually put anywhere.

Alvaro: Because we'll want to point to where the writeup is. As soon as that's
put somewhere I guess we can send the note out. I'll get on that and send it
after the meeting.

     o Robert Wilton, Alvaro Retana, and Warren Kumari to report back to
       the IESG on the impact of COVID-19 to the IETF in March 2022.

Amy: This is on today's agenda as a management item.

     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: In progress.

     o Francesca Palombini to follow up on the public archive of AUTH48

Francesca: The deadline we gave for that was 22 March. Lars, thank you for
answering some of these comments. I've been trying to read them but I don't
think I have a clear vision yet. So far what we said on slack was that there's
not really anybody against the proposal. John's last email was very clearly
written where he said he's not against the proposal and hasn't seen anyone
against the proposal but this might have brought up more issues [audio cut out]

Lars: I think we lost her. I will agree with her that I haven't seen anything
that suggests we should not do it or do something significantly different. So
my proposal would be we go ahead with the outlined way of the single mailing
list but since the comment period is still open we'll wait to formalize that in
case something else comes in. If there are other things the community would
like to see more transparency on we can do that, but it will be a separate
effort. We should wait with this one.

Amy: So it sounds like this one will stay in progress since the comment period
is open until March 22.

Lars: I think we should just check back in after the comment period ends.
Francesca is back.

Francesca: Basically what I was saying is that John [Klensin] summarized that
no one really said people were against this proposal, but this might have
brought up issues unrelated to the proposal that we might want to discuss at
some point. I thought that was a very clear summary of this very long
discussion. The four weeks haven't passed so we can keep it for the next
telechat after 113 and the four weeks will have finished by then.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-ace-mqtt-tls-profile-15  - IETF stream
   Message Queuing Telemetry Transport (MQTT)-TLS profile of
   Authentication and Authorization for Constrained Environments (ACE)
   Framework (Proposed Standard)
   Token: Benjamin Kaduk

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

Ben: Real quick, can we check with Murray? I think there were a couple of
replies, and I wasn't sure if you still thought there was more needed there.

Murray: I saw your reply, but I didn't see any others. Let me look.

Ben: And I think for Francesca's, we've been going back and forth. I didn't
read all the messages, but I don't think we need to discuss it on the call

Francesca: I would just like to have another pair of eyes, either yours, Ben,
or Carsten, to approve of the change. But I'm happy with the resolution.

Ben: Excellent, I will attempt to make sure that happens.

Murray: Cigdem says in the draft we use MUST/MUST NOT for behavior that affects
security and SHOULD for desired behavior. Is that legitimate use of BCP 14?

Ben: It seems okay.

Warren: I'll note that was said by a security AD. Anything for security is a
MUST and anything else is a SHOULD.

Francesca: I insist quite a lot on SHOULD needing to contain more context, in
every document where SHOULD doesn't have more context on why this is just
recommended. I think we should have a common vision.

Murray: What she said in this reply is in conflict with my understanding of how
BCP 14 is supposed to be used, but either way the text says you have no option
other than sending a disconnect, therefore you should send a disconnect. I
don't understand that. I'm trying to read what Ben said in reply.

Ben: Oh, okay. There's no way to inform them of the error other than saying a
disconnect. But you could just disconnect the connection and not inform them of
the error at all.

Murray: Okay, I will reply and say that if that's what you meant, I would like
you to say it. As it reads right now, I don't understand what else could I do
besides the one thing you're saying?

Ben: I see where you're coming from now; let's get that clarified on the
thread. Amy, this will go in Revised ID Needed then.

Amy: Staying in IESG Evaluation, Revised ID Needed.

 o draft-ietf-ace-aif-06  - IETF stream
   An Authorization Information Format (AIF) for ACE (Proposed
   Token: Benjamin Kaduk

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

Ben: Thanks everyone for your review. This is definitely Revised ID Needed; we
have a key fix that is only in the editor's copy so far that needs to get
published before we send it over.

Amy: And I believe we're in the blackout time, so you're going to have to send
us a ticket to approve that when you're ready to do it.

Ben: Yeah, I was planning to do that. Thank you.

 o draft-ietf-rats-yang-tpm-charra-16  - IETF stream
   A YANG Data Model for Challenge-Response-based Remote Attestation
   Procedures using TPMs (Proposed Standard)
   Token: Roman Danyliw

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

Roman: First of all, I'd like to thank everyone for the detailed review. The
one I had a question about was related to references. Given that we're talking
about a specific Linux feature, is there a recommendation on how we best
reference a Linux capability?

Lars: I would suggest they find something that's versioned to cite to. Maybe to
the Linux source tree or something. The readme url is changing to whatever the
most current one is.

Roman: That's right. So we would be comfortable with a pointer to a versioned…

Lars: I would be comfortable with this, given that it's a little bit of a gray
area, but at least you can uniquely identify which version of the Linux kernel
readme they refer to.

Ben: And if that is not possible we could consider an snapshot of
the page, which I think I've seen in some other places.

John: Wikipedia does that sometimes.

Roman: Okay, that's great. Again, I appreciate all the feedback. Definitely a
Revised ID Needed for this one.

Amy: Thanks, so this stays in IESG Evaluation, Revised ID Needed.

 o draft-ietf-dprive-dnsoquic-10  - IETF stream
   DNS over Dedicated QUIC Connections (Proposed Standard)
   Token: Éric Vyncke

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

Éric V: It's approved. Thank you for all your detailed review, and thank you
Ben for changing your Discuss to a yes. I think this must be a record document
to move so fast. Joke aside, mark this as Revised ID Needed because we need to
revise the document and a couple of pull requests that need to be incorporated.
Thank you again.

Amy: Okay, this will go into Approved, Announcement to be Sent, Revised ID
Needed and you can let us know when that's ready to go. I also have a downref;
do we need to add RFC 8467 as an experimental document to the downref registry
for this?

Éric V: I don't think it's important because it's the only document that will
use that downref and I don't think it's required.

Amy: Okay; we will not add that to the downref registry, thank you.

Éric V: Except if a transport area AD thinks otherwise, but for me I don't
think it's required.

Zahed: I think this is fine, I don't have a strong opinion on it.

Francesca: I do have a comment I was hoping would get addressed. It's a bit
more than a nit but not enough to block it, obviously. And I think Alvaro had
one of the same comments. We don't need to discuss it now but I wanted to flag
it so you're aware.

Éric V: Okay, I will remember that I need to double check with you and Alvaro
when they upload the revised ID. Thank you.

2.1.2 Returning items


2.2 Individual submissions
2.2.1 New items

 o draft-carpenter-rfced-iab-charter-06  - IETF stream
   IAB Charter Update for RFC Editor Model (Best Current Practice)
   Token: Lars Eggert

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

Lars: The next three documents I think we should all discuss. I have a Discuss
here as a reminder to myself that I missed the downref to the RFC ED model, so
we need to agree that we don't need to Last Call this document again. The same
is true for another document. But I think Ben's Discuss is the more substantial
one. I think I saw some discussion on this that makes me believe this is on the
path to being resolved, am I correct?

Ben: Probably. I don't remember having done this before so I don't know what's
supposed to happen. This is for discussion. I don't remember if Brian or anyone
had replied back to my question about should we put an RFC Editor note on the
document to say we have to have this other step that happens before we publish
this, please wait until told?

Lars: He did reply, and I think he suggested something along those lines. I'm
trying to figure out where his email is.  He basically said he can't speak for
recent cases, but in the past after process BCPs were approved by the IESG they
were noted automatically by the ISOC board. But I didn't actually know there
was a process for the ISOC board to be involved here, frankly, so I wonder if
Amy or Cindy know how that noting by the ISOC board happens; if this is an
automatic thing or whether it needs to be triggered by us in some way.

Cindy: I have never done anything related to this so if something happens on
the ISOC side, it does it without our input.

Mirja: Usually I give reports to the ISOC board during the meeting and I point
out things that are happening in the IAB. But it's not very formal, it's just
telling them what we're doing, right?

Lars: I'm going to take an action item to figure out what needs to be done
here. I can't recall ever seeing an RFC formally taken to the ISOC board,
whether it's process oriented or not.

Mirja: Ben, what's your actual concern? Is it because this is a document that
considers the Internet Society or do you think the actual change of this
document is something that is important for the Internet Society?

Ben: Well, I don't know that i consider it especially important, but just in
terms of a process perspective, if the original IAB charter is something that
was jointly approved by the IETF and ISOC board, then in a certain sense it
seems like if you're going to change the IAB charter you should still get the
same level of approval. Because otherwise it's like you're only making the
change to one half of what the group is and not the other half of it. You would
want to avoid the skew that would be inherent in that.

Lars: Was the original IAB charter approved by the ISOC board?

Ben: I don't know. There is a note in 2850, let me see if I can find it. In
section 2 of 2850 it starts off with "The IAB is chartered both as a committee
of the IETF and as an advisory body of the Internet Society." I read that and
assumed that ISOC had to do something to designate the IAB as such an advisory
body. But that's the only evidence I know of for that point.

Mirja: I don't think there was a process in place that this was actually
approved by ISOC. From a process point of view this is an IETF stream document
which should be approved by the IESG. I think that's the important part.

Lars: I'll take an action item to email Andrew and ask him about this sentence.
I don't know if there's anyone left on the ISOC side that remembers this
either. I do know that the community was very strongly of the opinion that the
IETF needed to revamp the IAB charter and not the IAB itself, which is why this
is on the IETF stream. This particular wrinkle, I don't know. I'll email Andrew.

Mirja: I think you should check with Brian Carpenter, who's the author of the
new draft and the old draft and is probably a person who would know. He should
know what happened when this draft was published.

Lars: I'm happy to include Brian as well but I'd rather have an acknowledgment
of someone who is active in ISOC right now to say whether they are willing to
be okay with this, I guess. We'll leave the Discuss on, Ben, until we know
what's happened here and hopefully this will clarify quickly.

Warren: I must admit that I didn't fully understand what this is trying to
accomplish. It sounds like it used to be that the IAB approves the appointment,
and now it sounds like the IAB owns the entire function. I don't quite know if
that is what…I didn't have enough background knowledge to evaluate this.

Lars: It basically tries to reflect that the RFC Editor model changes the
authority of the IAB on the RFC Editor. It used to be a very direct one and now
basically it says the authority remains with the IAB but the way things are
handled now is done by the new model, which is the RSWG and the RSAB and so on.
The dotted line from the IAB to the RFC Editor has become thinner.

Mirja: The IAB is not responsible for any of the processes here anymore, so
it's actually taking away responsibilities from the IAB. The reason it still
talks about authority is because if we figure out that the new model is
entirely wrong, somebody has to do something, and that would be the IAB.

Warren: Okay. It seems like the introduction or background presumably is wildly
clear to people who have been following it all, but without more of the
background, just looking at this, it sounds like the IAB believes that it's in
charge of this all now instead of  just appointing someone.  More background
framing was confusing to some. But I don't really care.

Lars: I think this tries to basically do the minimal change to this other RFC
and it points to the RFCED model which has all the things. There was a desire
to not replicate text, especially early on when the text was still in flux. We
can argue whether we should copy some text now from the model to here. I would
rather just leave it like that.

Warren: The fact that it's giving up responsibility is important and useful and
the text didn't make that clear; but I'm fine if [the answer is] people should
go and read the other document.

Lars: The RFC model document makes that abundantly clear. I guess we are okay
with me lifting my Discuss, i.e. we do not think we need to do another Last
Call because I missed that downref to the model document?

Ben: I think we were pretty prominent about the simultaneous Last Calls going
on here and there's a reasonable expectation of awareness of the status of
these docs.

Lars: Good, thank you. So I will send that email and cc the IESG so you all see
what's being discussed there. Oh hang on, there needs to be one more yes or no
objection to pass?

Amy: Once you clear your Discuss, that will get you the ten.

Lars: Oh okay, sorry. Thank you.

Amy: I'm assuming this will be A Follow Up?

Lars: Yeah, let's do that.

 o draft-rosen-rfcefdp-update-2026-01  - IETF stream
   RFC Series Responsibility Change (Best Current Practice)
   Token: Lars Eggert

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

Lars: Yes, similarly. Zahed, do you really think this is Discuss worthy?
There's a long discussion here whether this should be a normative or
informative reference. I know the other two docs have a normative reference,
but the author here really feels like it's not necessary.

Zahed: I was not clear looking at Bernard's reply. There was no strong opening
other than I don't care. When I read this one, I completely agree with Bernard
Aboba; this is not an informative reference. Can I understand what's going on
without reading the reference document? No. So to me, it's a normative
reference. If the author doesn't really care whether it's normative or
informative, they should go for normative. That's my point. If you give me a

Lars: My reason would be that this document actually summarizes what the model
says. It basically says in this new model, which is informatively cited,
responsibility for the series moves to these new groups. So I think that's the
argument why he says it doesn't need to be normative. If you want all the
details of why it moves and how it moves and what the new structure looks like,
you need to read another document, but because it summarizes the relevant parts
of the other document, the author believes it can be informative.

Zahed: So that's really interesting because I didn't get that feeling. I
thought I needed to read that document to understand what's going on here and
that's exactly what I did. To me it was not an informative reference and I
agree with Bernard about that. If you have some text somewhere..

Lars: I think the text is there, it's really that one paragraph where it says
in this other document, the responsibility changes like this, and therefore….

Alvaro: I agree with Zahed and I think that's a very dangerous thing if we now
in the future can say look at that other document that defines blah and can get
away without making it a normative reference to something. We can summarize
what another document says and get away without it being normative for other
things. For this one, I made the same comment and I didn't make it a Discuss,
but I fully agree that this should be a normative reference.

Lars: Okay, fair point. I'll ask him to change that and that will make it a
downref; I guess we are okay with that. Okay, great. That leaves Ben's Discuss
which I think is a good find, thank you for that, and I believe it's being

Ben: I believe there was a reply to that effect, yeah.

Lars: Leave it there and I'll let you know when you should re-check; there will
be a revision coming for these two changes. So we'll put this in Revised ID

Zahed: If you put in a new revision with the normative reference obviously [my
ballot] will move to Yes.

Lars: Okay, thank you.

 o draft-rsalz-2028bis-05  - IETF stream
   Entities Involved in the IETF Standards Process (Best Current
   Token: Lars Eggert

Amy: This also has a Discuss.

Lars: It's mine, and it's again the downref, which I guess we are still okay

Alvaro: This one actually doesn't have a downref anymore. In my comments I
suggested a bunch of the normative ones be moved to informational. In this
case, all they say is go look over there for more information. According to
Rich, he said he made all those changes in his copy somewhere. In any case,
same thing as before.

Lars: Okay, so that's good. And I do realize that this one has gotten quite a
bit of editorial comments that were all good and I think Rich is working
through them. This will also go into Revised ID Needed because of that and if
you want to quickly check whether your stuff has been reflected when the new
version is up, I would appreciate that. Otherwise we are good in terms of the
number of ballots.

Amy: You just have to change to a Yes.

Zahed: One comment; I still don't really get this way of reading things. I'm a
bit bothered by this after so many years, we're updating this but we're not
changing anything. I don't know if it's laziness or like you said too much of a
process issue. I don't know but it doesn't feel good to me.

Lars: We're changing it because it talked about the RFC Editor originally, so
it was therefore identified as something that needed to be changed and Rich
took it on and nobody in the RFC Editor program really cared very deeply about
the other descriptions in that document. So they didn't quite get enough review
until the directorates and the IESG read the whole thing, and I think that's
why we are finding this now. Do you think anything is still wrong or outdated
that needs to be fixed?

Zahed: I think the way this is a singular way of describing the authorship and
editorship and chairmanship of a WG still bothers me. I have new chairs coming
in and they read a lot of documents and come up with questions, like this
doesn't make sense and this doesn't make sense, and why do you have this
process? I have two or three new younger chairs that are not familiar with all
this aesthetic part of it and they get confused. We don't have a document with
a single author, we don't really differentiate. We have a number of docs that
have multiple authors, and now this document says we have one author and one
editor. It doesn't make me happy but I saw that nobody complained about this.

Martin D: There's that thing in section 1.2 that says for brevity, they're
always using the singular. So for the most part…

Zahed: But I don't need that brevity now; what's the reason I'm having this
brevity when we can change it to best practices now? It's not 1996.

Lars: I believe that Rich thought it was clearer his way and it would be
shorter this way. We can argue whether that's a right decision, but you're not
Discussing it, right? It's a comment.

Zahed: I contested that myself whether I should Discuss it. It's not wrong, but
it's not right either.

Warren: Now that Zahed has called it out, it does seem entirely reasonable and
like it would be really helpful to say the document editor(s) or author(s). It
would be a trivial change and would make stuff a lot clearer. To me it seems
editorial only, but I don't see how it would hurt, and it would only make it

Zahed: I got this specific question.

Warren: It says each working group is headed by a chair. If I just came along
and read that I would be like, hang on, that means there's a singular chair for
a WG. I understand it was done in this way for a reason but I think it makes it
way harder to understand and read.

Martin D: I think there are two separate things here. One is the general
singular/plural thing which is purely editorial. If it were me I would just do
(s), and I don't know how much we want to micromanage Rich there. There's a
separate issue Zahed brought up, which is orthogonal to that editorial
convention, and that is that for a document, if there's one person it's an
author and if there are multiple people, they're editors.

Zahed: There's one editor there.

Martin D: In 2.1 it says "When a document is composed and edited mainly by an
individual, they may be referred to as the Document Author.  The distinction is
not significant." So you cannot have two authors on a document, is how I read
that. And that is definitely not what we do today. It does not seem to be

Roman: I'd say with the magic of Github we even have multiple editors now.

Lars: I will ask Rich if he feels strongly about keeping it this way or if he
would do a pass and change it to the plural. I will point out that the
community so far has not brought this up.

Warren: I suspect the community didn't really read much of it. I skimmed
through it.

Lars: We did get all the directorates to read these, so they have gotten at
least some reviews.

Ben: I sort of agree. It's not really clear that the community cares very much
about this, which is a little disappointing for a single-digit BCP, but we also
can't force people to do things.

Zahed: I saw some of the directorates pointed out the singularity.

Lars: I will talk to Rich and suggest that he takes this into consideration but
I won't require him to make the change unless someone puts a Discuss on it,
which I think is over the top, frankly. If you feel strongly enough go ahead
and we'll see what happens.

Warren: I think it would be bad form because I didn't ballot earlier, but if
I'd seen this point earlier, I would have said that I thought it was a really
big issue for newcomers. Existing people are going to be like yeah, whatever,
author, who cares? We understand what's meant. But someone who's trying to
figure out how the IETF works and how to write a document reads this and thinks
there's only one author and they can't ask to co-author. I think it's not a
helpful thing that Rich has worded it this way. I don't think there's a ruseful
reason. How bad form is it for me to Discuss at this point? It is bad form,

Ben: It's been done before.

Lars: I'm happy for you to put a Discuss on it if you feel strongly about it.

John: To me it seems like worse form to not put a Discuss on it if you feel
that strongly about it.

Martin D: Honestly, if you Discussed it right now you'd be 47 minutes late,
which probably is not that bad form in the scheme of things.

Ben: I didn't think the deadline was the beginning of the telechat, I thought
it was when we're discussing it on the telechat. Because it's not approved
until we get to it in the agenda, so you still have a chance.

Lars: Please file it, and then please actively discuss it with Rich so we can
get this resolved; don't file it and then go on your weekend. That would be
helpful. Thank you.

Martin D: I don't want to lose the other point. Do we agree there can be more
than one author on a document?

Warren: Yes.

Zahed: In my comment I also put one more thing; what about contributors? In
some cases we push some authors to the contributor list.

Lars: There's a proposal for text for that, I think. I saw something fly by
that says something to the effect that not all WG participants participate
equally in the creation of the document  and therefore can be called out as
contributors, or something like that.

Martin D: Warren, while you're filing your Discuss, can you bring up this issue
in 2.1? Quite aside from the (s) business, it seems like it defines an author
as when there is a single person on the header, and everyone else is an editor,
which is not at all how we do things. That to me is an actual qualitative
problem, as opposed to just being unclear.

Warren: Yep.

Murray: On the point of contributors, didn't Robert make a comment about why
we're not also including directorates? Directorates and contributors feel like
they're both to me in the same category of being a little bit of scope creep.
They're roles that are sometimes there and sometimes not and it's a little bit
peripheral to the actual process.

Lars: One thing I want to point out, and this is not a response specifically to
Murray, this is not the Tao. This is not supposed to be a long description of
the details. This is supposed to be a high-level description of the bodies that
are involved in internet standardization and you've got to draw the line
somewhere. Otherwise we're rewriting the Tao.

Roman: On the directorates though, they are a little bit different than
contributors because I thought current practice is that every single document
that goes for review gets at least GenART and SEC [reviews]. So basically any
document you make in the IETF is going to get one of these.

Lars: Not necessarily; it's going to get assigned but you don't know if you're
going to get a review or not.

Martin D: Aren't directorates sort of a sub-organ of Last Call to make sure the
Last Call is a no objection?

Murray: By that definition, so is a document shepherd.

Warren: By that, authors are just participants with a slightly different hat.
You can stretch this continuum as far as you like. I think they are a separate
thing that is worth noting but I don't think that's worth Discussing,

Rob: For me, the reason I raised it was that while I was reading this document
I thought what are the most likely bodies that if somebody was going through
the process that they want to know about? Some of the ones that are listed I
didn't think were particularly interesting, like the LLC and ISOC. I doubt
they'd necessarily get involved with. Whereas some of the other ones that they
would be more involved with then I think could be useful. Maybe you'll just say
that's the Tao, but that's why I flagged those things up as being potentially
worth having something about.

Roman: That's why I flagged directorates too. I didn't have a calibration of
the level of abstraction which we seem to be talking about. I didn't get that
level of abstraction so it seemed like, not an incorrect list, but I didn't
understand the motivation of why some things were in scope versus not. And why
there was this finesse of one author.

Lars: We would never have touched this document if it wasn't for the RFC Editor
model. The Tao is the actually better description that we point newcomers at
and it has a lot more stuff in it.

Warren: Apologies if this has also been mentioned, but the document starts off
with a bunch of question marks?

Lars: That's been mentioned. It's because it's AD-sponsored and he didn't know
what to put there.

Warren: Fair enough, no worries.

Lars: This will definitely go into Revised ID needed. I'd really argue for
minimal changes here so we can progress this together with the other four
documents. This is holding up the RFC Editor model like the other three are. If
someone really feels strongly this needs to be revised again, you all have pens
and can do another bis so it's not blocking anything. I'm happy to AD sponsor
any revision to this document as many times as we need to. Thank you.

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-bar-cfrg-spake2plus-00
   IETF conflict review for draft-bar-cfrg-spake2plus
     SPAKE2+, an Augmented PAKE (ISE: Informational)
   Token: Roman Danyliw

Amy: Roman did our RFC 5742 review for this document and it looks like there
are no Discusses, so unless there's an objection now, the no-problem message
can go back with the note that's in the tracker. Okay, hearing no objection, so
we will get that sent on Monday as we normally would.

3.4.2 Returning items

 o conflict-review-richardson-mud-qrcode-00
   IETF conflict review for draft-richardson-mud-qrcode
     On loading MUD URLs from QR codes (ISE: Informational)
   Token: Robert Wilton

Amy: Rob did the review for this document. I have no Discusses in the tracker,
so unless there's an objection now it looks like this can go back to the ISE.
I'm hearing no objection, so this can be sent on Monday.

3.4.3 For action

 o conflict-review-irtf-nwcrg-nwc-ccn-reqs-00
   IETF conflict review for draft-irtf-nwcrg-nwc-ccn-reqs
     Network Coding for Content-Centric Networking / Named Data
   Networking: Considerations and Challenges (IRTF: Informational)
   Token: Lars Eggert

Amy: We are here to assign this conflict review to someone.

Lars: This doesn't necessarily have an overlap within a chartered IETF area, so
anyone who feels like they haven't done one of these in a long time should step
forward and take it. It's network coding for ICN. Two topics which are not in
the IETF anymore.

Éric V: How long is it? 20 pages. Not too bad. Okay, put my name on it.

Amy: Thank you Éric.

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


4.2.2 Proposed for approval


5. IAB news we can use

Mirja: We discussed all the news already. Yesterday we approved the RFC Editor
model, of course pending your comments.

Martin V: That's what I was going to say. No other news.

6. Management issues

6.1 Approval of draft-iab-rfcefdp-rfced-model (Lars Eggert)

Lars: I added this. It looks like there has been a significant number of
comments. Since we don't have this nice ballot view, does anybody feel like
they have raised something that would be equivalent to a Discuss that would
make us not want to approve a revision of this document that fixes the
editorial things that have been proposed?

Rob: I'm not sure about mine. I guess it probably is editorial, but my question
was to do with how it's unclear to me who appoints the liaison to the IAB in
this role. Before it was clear whereas now it's ambiguous, so I think it's just
that's an editorial fix but I haven't seen a response back to that.

Lars: I can't remember. It was discussed in the program; if Mirja remembers
what the outcome was, let me know. I think there's definitely going to be a
liaison from the RPC like they have now but it's not clear whether the RSCE
will also be the liaison like the RFC editor is now, or whether they'll be an
ex officio member of the IAB. I don't actually know if it's up to the model to
decide this or whether it's an IAB decision.

Rob: I raised this as one of the comments on the previous docs we'd balloted
on, so that's the connection that it was saying is defined by this document.
This document is so broad, which is part of the RFC editor function, and to me
that means it's actually who is organizing this assignment?

Mirja: As Lars said, there was a lot of discussion about having the liaison
from the production center to the IAB, that's what we will have. I don't think
there was any discussion about another liaison and I'm not sure if another
liaison is needed. I think that's the answer, we need to clarify that.

Rob: Thanks.

John: I had one point I raised that I might have made a Discuss that I haven't
seen an answer to yet. It was about balloting. The way the text is written
right now it looks to me as though a document that doesn't have any votes
against it at all by default moves forward, which I thought was strange, and I
wonder if it's just an editorial error or if it was a deliberate decision. So
that's probably a simple answer, either we thought about it and that's what we
meant to write, or it's an editorial mistake, but I would just like to see some
response to it.

Lars: The voting rules were discussed but I can't remember if that particular
wrinkle was discussed. It was mostly about what kind of majority we want and
what happens if one seat isn't filled. I'm hoping that Peter will respond and
clarify what this is. I don't remember.

Ben: I'm not sure whether or not I would have Discussed about this one; I might
have. Just that we give guidance to what should happen when new streams are
created and then we create a new stream without following that guidance in
terms of specifying that the editorial stream will not have a representative on
the RSAB. It's maybe borderline Discuss versus not.

Lars: That was discussed and I think it was actually a decision that the
editorial stream wouldn't have a representative.

Ben: Elliott had replied and the document should say that it was decided what
the outcome was.

Lars: Okay. So I propose that since quite a few things were brought up that
people would want to see changed, or at least see a proposal for a change, that
we wait until we have a revision posted and then we do an e-vote next week if
that's possible for everybody. Or, we basically do Point Raised or something
and I'll have the action item to make sure these three things are in the
result, but you're all going to be in the conversation. I think we should do an
e-vote when we have a new version. Mirja, do you think that would work for the
IAB, or is it causing too much delay?

Mirja: I think that's totally fine, but I'm not sure if the IESG understands
what an e-vote is supposed to be. But we'll figure it out. We need to wait for
the updates.

Lars: Basically we can use iesg-only to approve the document without waiting
for another telechat, assuming we get a new version out. For the minutes we'll
say something like the IESG discussed the approval but wants to see a new
revision posted that clarifies some of the issues raised in the reviews by the
area directors, and the intention is that we would approve it in an email

Warren: I just wanted to make sure that this isn't likely to do things like
generate an appeal or anything? If it's nothing that anyone cares about, that's
cool, but John Klensin rightfully raised some concerns about the process.

Lars: John's concern was that the IAB appeared to have pre-approved the
document because they had an agenda item for IABOPEN that sounded like that was
the case. I would be surprised if he would also feel that not approving this
now would be appeal worthy, since that's the opposite behavior, but we won't
know until we find out.

Warren: I was thinking more, could it be appealed that it looks as though we're
giving this document special handling and doing it outside of our normal

Mirja: The normal process would be that this document needs to be approved by
the IAB and that's it.

Lars: This is not contingent on us approving it; the IAB could take this
forward unilaterally. It's nice that they let us have opinions about it and
that they're instructing their program editor to reflect our desired text
changes, but technically they could take it forward.

Warren: Okay, cool. My questions were clearly uneducated.

Lars: No, it's a fair point. These sorts of process things are always an appeal
minefield so it's good to think about this. So the proposal is basically to
wait for a revision, have everyone check if their concerns have been addressed,
and approve it by email and then minute it as part of the next telechat
minutes. Does that sound good?

Amy: So you want us to keep this management item for the first telechat after
113 to minute?

Lars: Yes, to minute the approval. I guess we would announce the approval
earlier already by email because that's when the cluster of documents is

Mirja: We can also minute the approval in the Sunday meeting, right?

Lars: Correct, we could do that also; let's do an action item then just in case
we need it.

Amy: The minutes of the Sunday meeting aren't public, so if you want to
publicly minute this, you could take the action any time but it would have to
be minuted at a formal telechat in April.

Lars: Okay, so then let's do what I said earlier and keep the management item
to minute it and the community will be informed when the IAB sends out its

Amy: Okay, we will edit this to say minuting the decision and we'll keep that
for next time.

Cindy: Can I jump in with one question that might clarify things? This goes to
Warren's process question. If we use the word "endorsement" rather than
"approval" would that make things less confusing, since this is actually an IAB
stream document to approve and this is just the IESG agreeing with that

Lars: That would be helpful; we should make that change. It doesn't change the
ADs having sent comments to the editor, but we can see if we can endorse the
document based on the revision that's forthcoming. But it makes it clear that
the approval lies with the IAB. Thanks.

Warren: If the approval lies with the IAB, maybe it's simply that we note that
we don't object and that's less confusing than approving or endorsing.

Ben: We got asked to review, and we provided some feedback, and maybe we don't
need to say anything else.

Warren: We don't really endorse. Does the IESG endorse an RFC when it says no
objection or this can be published? Maybe we do, I don't know. I guess I don't

Lars: I think it would be good to have a minuted statement that says this new
RFC Editor model is something the IESG supported.

Mirja: I'm just trying to make this simpler, but if people don't want this
that's fine as well. Isn't that something we can already minute in this
conversation? Because as we already said, it's the responsibility of the IAB to
approve this document and the IAB will take all the comments you provided and
try to address them before we finally approve it. So in that sense, if there
are no real concerns about the overall model, we could minute right now that
the IESG is in support of this.

Warren: Does anybody feel strongly enough to Discuss? If not, it's No Objection
or something similar. I don't think we feel strongly enough to have a Discuss,
you know, you will bring it back and we will make triply sure it's great.

Lars: I asked that exact question and three people said they had things they
felt like were at that level.

John: Speaking for myself, there are two different reasons you put in a
Discuss. One is what you pointed out earlier in this call, Lars, that you put
it in as reminders to make sure something doesn't get missed. That's why I
would have put my thing in a Discuss. I wouldn't have put it in a Discuss
because it needs to be rethought. As long as the IAB accepts it and makes sure
my thing gets considered and addressed one way or another, I'm good.

Rob: And I'm exactly the same as John.

Lars: Okay, so I guess the question is do we trust the IAB to make sure the
individual comments that were sent by area directors get reflected in the

Ben: We kind of have to. There was one thing Mirja said I wanted to respond to,
which was the phrasing about if anyone has concerns about the document? I have
concerns about the document, which I put in email, but I don't think they're
the sort of concern I could actually Discuss or block the document for. It's
causing more work for us and I don't see the need for it, but apparently the
community does, and we have to accept that consensus.

Lars: So we can minute that the IESG approves the endorsement of the document
and we trust that the IAB and the editor of the document take the comments they
got from us into account. Does that sound good?

Amy: So wordsmithing that just a bit, I have "the IESG supports the publication
of the document on the IAB stream."

Lars: That sounds perfect.

Mirja: Thanks everyone for your comments and careful review.

6.3 Adding the reopening of the I-D Submission Tool to the Important Dates

Amy: There has been a request for the date and time of I-D Submissions
reopening to be added to the Important Dates. However, the reopening of I-D
submissions has been hinged on meeting local time instead of UTC time; to make
that change is not insignificant for the tools team. We would like to have the
reopening time be hung on UTC time instead if we want to add it to the
Important Dates. That's the first question, do we want to add this to the
Important Dates, and for ease of tooling, can we make it a UTC time instead of
meeting local time?

Lars: That seems fine to me.

Ben: I wouldn't worry about it. We could say the Sunday before the meeting so
it's open by the time the meeting starts.

Amy: Sunday noon UTC?

Éric V: Midnight UTC?

Warren: Midnight is always tricky, because is it 23:59 or 00:01?

John: Let's just make it noon, because everyone knows when that is.

Amy: Okay, so we'll make it Sunday noon UTC for reopening I-D submissions.
Thank you.

6.4 IETF Monthly Activity Report

Graphs indicating low numbers of submissions and participation were shown
including through February 2022.

Rob: I think this will pick up once we have a significant number of people in
person attending meetings but there may be a lag.

6.5 IESG Evaluation Review Comments (Francesca Palombini)

Francesca: This has been brought up and I will ask the IESG to keep an open
mind. The idea here is to make it easier for authors to process IESG review
comments. I've gotten several times the feedback that it's quite overwhelming,
a lot of comments, and authors are not well prepared. We've seen sometimes that
they think they're supposed to answer immediately and they get comments from
10-15 people in the days before a telechat, they think they might even need to
answer before the telechat, so there is clearly something we can do there about
better communicating with the authors, especially authors who don't have
experience. The usual suspects who publish a lot of RFCs are very well versed
and know what to expect. For new authors this can be a traumatic experience for
them and I've heard that some authors have even expressed that they are not
willing to go through the process again. For me this is a big problem; I don't
want to hear that authors are discouraged from coming to the IETF because of
the process. There was this proposal to try to make things a bit easier for
authors that requires a little bit of effort on our part, but I don't think
it's unreasonable. I wanted to ask if the IESG was willing to try it for one of
my documents that is coming. It doesn't solve the problem but it's one
practical thing. The proposal is basically to format our review comments in a
way that a tool can then transform them into GitHub issues. This should make it
easier for the authors to see them and reply, assign and organize how to reply.
The shepherd chair should help the authors through the experience but it
happens so quickly, with ballots coming in in a few days, and shepherds don't
tell authors that's going to happen. I haven't told my authors it's going to

Roman: Why do the authors believe things need to be resolved during telechat
week? This seems to have come up recently. Why do we have that perception?

Warren: I did speak to the people who had had that concern, and in other SDOs,
a document gets an approval to be published or not and the approval is the
document as it stands at that point. They seem to think that comments come in
and they have to be resolved before the telechat and you either get a thumbs up
and it's published as is, or you get a no.

Francesca: We think the telechat is our deadline to review the documents, but
the authors can see the telechat as a deadline to resolve the comments that
come out of IESG Evaluation. There is some misunderstanding and
miscommunication and I'm thinking about how to make it better. I've started to
draft a very detailed thing of what my expectations are and timelines are for
after a document leaves the WG because I think this is not very clear and
authors only get to learn with experience. The first time they experience it
it's quite bad and it's totally fine and normal for people who have experienced
it before. I'm worried we are losing participants to this so I'm willing to try
anything to make this work.

Martin D: I'm happy to use this format on all my comments just to make it
easier for Github people. That's trivial and will make peoples' lives easier.
But I'm skeptical that newcomers are utilizing this GitHub tooling. It's not a
bad idea, I just don't think it really helps the problem you're describing.

Francesca: There are new authors in big groups like HTTP or HTTPAPI. These big
groups attract new people and they are the ones who get discouraged. The format
might actually help us because sometimes I start to write my ballot and
realize, oh, Ben has already pointed that out, and Alvaro has already pointed
that out. I still include those comments because i had them, so why not, but if
we can check to see if someone else already made the same comment.

Roman: Clarifying question; how does that solve that problem? Because all the
proposal was saying is put your stuff in a format that's machine parse-able. It
does not speak anything about how it will be machine parsed. Do you envision
you have a personal parser now that's reading everyone's ballots to make sure
there's this deconfliction? There's all this back end machinery of how issues
are created and adjudication of those issues and tying what's now in GitHub
state to things in the datatracker, there's a link I'm missing. Can you clarify?

Francesca: What I want to try, at least for one document, is we write the
comments in this specific format, there's a tool that will transform it into
GitHub issues, and then the ADs can follow all the issues. This will be easier
for authors because they can assign and tag the issues. It allows them to use a
tool they already have, and for the WG to participate more actively rather than
receiving this bunch of text they have to go through manually and parse it.
Which is basically what they've been doing, going through the ballots and
transforming them into issues; we can automate that part at least.

Warren: This seems like it's going to make stuff a lot more complex. There are
a lot of things which are like, this text seems weird, here's a proposal on how
to fix it. There can easily be 25 or 30 of those. To have people first review
the document, then figure out what you want to say, then go along and have a
look at the GitHub issue tracker for the document,, see if anybody else has
said similar things, then go back and write up your thing in this format, and
then have it sent to Github, and then you have 30 or 40 GitHub repositories to
track and see whether people are updating, it seems to me that the tooling is
going to get really complex. Are people then discussing it in the GitHub issue,
or are they just sending you mail? It seems unmanageable. I'm really
sympathetic when authors get freaked out about getting a lot of comments and
not knowing how to synthesize them. It seems to me that the way to make that
better is that when there's a ballot, there's a thing that says do not panic,
here's some info on what's expected of you, basically the IESG statement we did
for Discusses. Or here's a short video from somebody explaining what you should
do with these comments.

Francesca: That practically doesn't help them. That's what I'm telling you.
This is the WG coming to me and asking me to try this different way of doing
it. That's why I'm asking the IESG to please keep an open mind and try it. I
can see that you're saying this is not easier on us, because we are very used
to going into the ballot page. What I'm telling you is that it would be easier
for the authors to process the ballots, and I think that's what's important to
me. I just want to try this with one of my docs just to see how it goes.

Éric V: GitHub is the basis for all your WGs, right? In other WGs people do not
use GitHub. So let's not focus too much on this. My major thing with your
proposal is for us to detect the duplicates, because it's not only a burden for
us, but if I have to read the other ones before doing my own review, I have a
bias. And I don't want to get biased.

Francesca: What I usually do is I write my own review and then after I'm done I
read the ballot and see if anyone else has already addressed any of it. At that
point I either remove my comment because someone has already covered it, or
like I did today, I realized that I had an additional comment to that so I kept
it and explained my point of view. About not all the WGs using Github, that's
totally fine. I'm just saying let's try it for this one document for this one
WG and see how it goes.

Éric V: We can try it, of course. And my last point; using markdown as a format
is okay and that's what I try to do anyway in my own ballot. What would be
better is to have a common template, because each of us reports in different
ways. I typically use the section blah blah and then the text, others put the
text and then the comment.

Francesca: A comment template, if you want to call it that. Next in the queue
was Alvaro.

Alvaro:  I have some concerns; sure, we can try it for one, but we have 125
WGs, and if we try doing different things for them, then we have 125 different
ways of doing things. Even if you want to make it easier for the authors, that
creates a big inconsistency problem for us. And for them, because you
participate in different WGs and different WGs process things in different
ways. So to me it's a big problem. I think the first part, Roman said this in
the chat, the first part of having a common template seems reasonable. The way
of submitting comments in different ways and having to track them in different
ways, that doesn't really work for me.

Francesca: We wouldn't have to be submitting differently, it's only having the
template, because then there is a tool that will change this into issues.

Alvaro: But the way to track them, looking at the ballot.

Francesca: Yeah, tracking them is a valid thing. I haven't really thought about
it too much. I'm just bringing this up as a quick idea I was asked to consider.
We can see if we can do emails instead but at least we can try to do the first
part, which is formatting them.

Ben: If push comes to shove, it's Wednesday afternoon and I still have 150
pages to read. I'm flat-out not going to look through the existing issues
before I ballot. That's just how I need to prioritize my time to get through
the page count. I agree it would be nice to do that, but it is not the highest

Francesca: It's best effort. I think if we format the comments in the way they
can make issues, they can also link issues together and they can be the one
telling us this was already brought up. I guess it's the way that the authors
prefer to work is related to Github issues rather than long parallel mail
threads that we have with the Datatracker.

Ben: I'm certainly willing to use the markdown format. They've mentioned that
there's a validation tool, and it would be great if that was also available as
a web service because I'd prefer to not run tools locally that haven't gone
through a code review software development life cycle.

Francesca: That's the goal.

Ben: I think I was present for some of the initial conversations around this
topic in terms of having a common standard format that ADs and other people use
for their feedback, and it seems useful to have that available even if it's not
full out required by policy.

Zahed: I think this is good that we're discussing it. I don't believe there
will be one silver bullet to actually solve this problem for the newcomers and
I don't actually support this as coming from newcomers. Mark Nottingham is a
very passionate guy who's giving an idea. Maybe it doesn't help the newcomer
perspective to put it in Github but I'm a bit concerned. I'm doing a volunteer
job here on the IESG. If you ask too much from me, like I have to customize my
writing style to a format, it's very hard for me to actually judge all the WG's
ways of working and comply with all of them. I prefer to write comments the way
I prefer to write comments. Can I do a markdown? Yes, I can do markdown.
Sometimes I think why doesn't the datatracker have a markdown so I don't have
to do it myself? But I can do that no problem. The rest of the things, this
doesn't solve the problem you brought in. And it puts a lot of pressure on me
to think about how I should write my comment and that's not very efficient for
me to do my job.

Francesca: I'm not sure I agree.

Zahed: But that's my feeling. Let me give an example. If you want me to
comment, I can comment and do the section. On the sublevel, wrong reference,
does it work that way, all these categories -- I'm not willing to do that. I'll
write my comments the way I think and I will not categorize them. I have no
time to look and see what the other ADs are putting in as issues.

Francesca: It's not categorizing it, it's just giving it a title and then
writing your comment underneath.

Zahed: That's what I'm saying. I'll write my comments 1, 2, 3, 4, 5. My title
will be different from yours. If we don't agree on one title. Then we will need
an RFC to write all the titles. If you ask me to write it down in markdown, I
would love to do that. The rest of it is a bit too much for me and it doesn't
help the newcomers.

Francesca: I'm not sure what the problem is with the format I suggested.

Zahed: Why do they need to be titled?

Francesca: You can write "1" as your title if you'd like.

Zahed: That's my comment. The subtitles are my problem.

Francesca: I think I got it.

Zahed: If 13 of us come up with 13 different titles, that will be more cost for
the machines reading those titles and categorizing them.

Francesca: It will just parse it and put it into issues. I believe there will
be some work by the chairs and shepherd to do some categorization afterward and
connecting issues. Again, this is just a small thing in the big problem of the
IESG evaluation not being well understood.

Zahed: The problem you're describing, I agree with that. The perceptions of how
the authors should react to our comments are completely wrong. Even the first
time I got comments on mine I thought I needed to do all these things.

Francesca: I agree with you, and I will be working with my authors to make sure
what is expected is understood. But this is something small that can be done.

Zahed: Coming back to your question, can I do it for one of your documents? I
can. But only for one.

Francesca: Okay, thank you. That's a start.

Lars: Can we close the queue? There are four people left.

Martin D: I have numerous practical questions about this and if we don't have
time to address them, I would suggest that this proposal is not baked enough to
execute right now. Let me start with number 1. There's this markdown format,
that's fine. I'm happy to do all my comments in markdown whether or not there's
GitHub, why not? But in the Datatracker there's a Discuss box and a Comments
box. This seems to think that there's a single box. How do we adjudicate that?
Do you want me to repeat the Discuss in the comments box so it would be parsed

Francesca: I will get back to you on that. We're not doing this tomorrow, I
expect to do this with one specific draft and when I bring that draft I hope to
have all the answers to this.

Martin D: Thank you. My second issue, on this issues list, do we have a
commitment from the WG that all pre-IESG issues will be closed? Or will we be
sifting through a bunch of stuff that has been floating around? Like, are they
going to be relics in GitHub that are sitting open to sift through?

Francesca: No, only the IESG. When I push this document forward, all other
issues will be closed. Otherwise it's not ready to go to the IESG.

Martin D: Okay. And then three seems straightforward; I guess I'm not 100% sure
I can always propose a resolution, but that is my best effort. Number four, it
says that the editorial suggestions should be PRs. But there's a nits section
in the proposed format. I'm confused; do I put it in the nits section or am I
supposed to do PRs?

Francesca: If you do have easy typos or nits and you're willing to open a PR
and do it in a PR, that's very much appreciated. Otherwise, put it in the nits
and they will answer it with a PR. Having a PR with editorials and nits is
easier to merge, but if you don't have time or don't want to make the effort,
then put it into nits.

Martin D: Okay, so it's either/or.

Francesca: This is all best effort. I'm not trying to make anybody's life
harder, I'm trying to make everybody's life a little simpler.

Martin D: Okay. To me the only part of this that seems laborious is checking
the issues list potentially, but if it's just AD issues that's not so much
different than reading other peoples' reviews. I think this is probably
workable modulo clarification.

Francesca: If there are ten issues, it might be easy. If there are 100 issues
already it might not be possible, which is fine. But they prefer to have issues
they can link to each other instead of mail threads, where point 3 of my mail
relates to point 15 of Ben's, that might be harder for them to track.

Martin D: I hate the email threads. Especially if we could get more groups
working on this this would be better. I would love a world where there are a
lot of groups on github and we use the markdown format, and 2, 3, and 4 were
our best effort, I think that would be strictly better and not any more work
for us.

Francesca: Thank you, you put it how I was hoping to present it.

Martin D: I think the actual proposal Mark wrote down is a little bit like,
would you please do a bunch of additional work to make our lives easier? Which
to the extent it's best effort is sort of the case. But I think there's a
little bit of a tone problem in this that puts people off, but having discussed
it with you, I think this is probably manageable.

Lars: We still have people in the queue and we're running out of time. So I
think we should put this on the agenda for either the IETF meeting week or the
retreat and give people that are interested in this a little more time to work
on it.

Francesca: We can re-discuss this closer to the time when I would like to bring
a document to test this format.

6.6 RSWG Chair Appointment (Lars Eggert)

Lars: There is text here; give it a read and at the moment the intent is that
we basically ask for nominations or self-nominations soon, after these model
documents are approved. There's a deadline here sometime in April and the
people that have been nominated if they haven't included all the information
we've asked for, they'll get an email from the Secretariat asking them to do
so, and after that we the IESG and IAB have a pool of candidates. The intent is
that each body would make their own choice for RSWG co-chair out of that pool.
The IAB appoints for two years, the IESG appoints for one year, and then each
other year we renew or replace our "co-chair." Because there is a possibility
we both pick the same person, I would suggest that the IESG as the body who
picks the shorter-serving chair also picks an alternate so in the case that the
IAB fulfills our wish and picks the same person we want to pick, we can go with
the other person. Thus we will populate the chairing for the RSWG. Does that
sound reasonable?

Éric V: This WG would be in your area, Lars?

Lars: No. This is called a working group, but it's not actually an IETF working
group. It's a thing that hangs under the RFC Editor. I lost the argument to
call it something different.

Éric V: Okay, that was my second question; it's not a WG.

Lars: It looks like a WG and it smells like a WG but it's not.

Éric V: And it's too late to change it?

Lars: It's been discussed several times in the program and the consensus is to
call it a working group.

Éric V: Group consensus, not IETF consensus, though.

Lars: The IAB program had consensus to call it "RFC Series Working Group." IT's
in the model document that we just said it's okay to endorse. That discussion
has been had.

Mirja: The concern was exactly what you say, it's confusing because it's not an
IETF working group, but the reason for keeping it was because people understand
the term working group, and as it operates in a similar manner, it's easier for
outside people to understand what the operation mode of this group is.

Lars: It's basically a new type of group that is going to be doing the policies
for the RFC Series. But this is about how we're going to find chairs for them.
The model document says the IAB picks a person and the IESG picks a person and
we found it silly to do two calls for volunteers so we'll do a joint call but
separate selections. Going forward, we wouldn't do joint calls because we'll be
in opposite years. Give it a read, I put the link in the slack, and hopefully
sometime next week when the documents are approved this can go out. Thank you.

6.7 IESG and IETF Chair Report for IETF 113 (Lars Eggert)

Amy: This has gone out to the group to add things and suggest changes.

Lars: By when do you want to finalize this? Soon?

Amy: It's up to you. We generally try to make sure it's in the plenary
documents before the IETF week starts.

Lars: So in the next few days.

Amy: Within a week-ish. I can upload it anytime.

6.8 Newcomers Agenda (Martin Duke)

Martin D: I don't think we need to run through the document right now, but Greg
would like the newcomers; agenda by Tuesday. So by Tuesday morning Pacific time
I'll ship it as it is. This is a list of things that are accessible to
newcomers because they're not deep in the weeds on minor issues; generally
research groups, BoFs, newly chartered WGs, that kind of thing. My selection of
groups is probably wrong, so add and delete as appropriate, and we try to have
a couple of sentences about what's going to be there. It can be generic or tied
to the specific agenda. If you don't have an agenda you can just put in some
generic text. It's not that important to be precise about it, this is just a
way to help new people find a way to be tourists constructively. So please have
a look at that and make your edits by Tuesday morning Pacific time and then
we'll ship it.

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

6.2 Executive Session: ISOC Board of Trustees Appointment Confirmation