Skip to main content

Narrative Minutes interim-2020-iesg-09 2020-04-09 14:00

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

Narrative minutes for the 2020-04-09 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
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Wes Hardaker (USC/ISI) / IAB Liaison
Benjamin Kaduk (Akamai Technologies) / Security Area
Erik Kline / Loon LLC / Internet Area
Murray Kucherawy / Facebook / Applications and Real-Time Area
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
Alvaro Retana (Futurewei Technologies) / Routing Area
Alice Russo (AMS) / RFC Editor Liaison
Amy Vezza (AMS) / IETF Secretariat
Martin Vigoureux (Nokia) / Routing Area
Eric Vyncke (Cisco) / Internet Area
Magnus Westerlund (Ericsson) / Transport Area
Robert Wilton / Cisco Systems / Operations and Management Area

Jay Daley / IETF Executive Director

Len Hause
Greg Wood

1.2 Bash the agenda

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

Ben: I sent in a late management item; I'm not sure if you got it.

Amy: We got that; there's an item about the CWT confirmation methods designated

Ben: That was it, thank you.

1.3 Approval of the minutes of past telechats

Amy: We have two sets of both narrative and regular minutes. Does anyone have
an objection to either the March 12 or March 19 minutes being approved? Hearing
none. Does anyone have an objection to the narrative minutes from March 12 or
March 19 being approved? Hearing none. Those will all be posted.

1.4 List of remaining action items from last telechat

     o Roman Danyliw to draft text to be posted on about reporting
       protocol vulnerabilities via an email alias and possible procedures
       on how to assign triage resources.

Roman: This is still in progress.

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

Wes: This got swallowed by recent events but we should keep it. We started
making progress and then stopped.

     o Alvaro Retana and Barry Leiba, with Warren Kumari, Alexey Melnikov,
       Martin Vigoureux, and Roman Danyliw to work on more transparency in
       the Datatracker about how long each phase of doc process takes / New
       datatracker flag to indicate who has the ball: area directors,
       authors, or chairs.

Barry: We should keep that in progress.

Amy: Is Alexey still going to work on this with you?

Barry: We can loop him in if we want to get his opinion but you can take him
off the action item.

     o Alexey Melnikov and Warren Kumari to add keyword tags to WG charters
       to identify specs that pertain to some general concept.

Amy: Warren, this morphed into some action items for you from 107. Is this done?

Warren: Kind of. Let's keep it listed as this because it's easier to remember.
We are making progress and getting stuff done. We're going to be testing a
webpage for proof of concept. Let's keep Alexey on this as well.

     o Alvaro Retana to work on a framework for analyzing new proposals.

Alvaro: In progress.

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

Warren: In progress.

     o Alexey Melnikov to organize IoT overview discussion with interested ADs.

Amy: Was this done? Did someone want to pick this up from Alexey? Should we
drop it?

Alissa: We talked about this during the meeting week. You can mark it as done.

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

Eric: In progress.

     o Magnus Westerlund to draft an IESG Statement regarding the IETF as the
     default change controller for IANA Registration requests.

Magnus: In progress.

     o Suresh Krishnan to draft a "best errata practices" document and post it
     on the IESG Wiki.

Amy: Did this get done? Should we drop it?

Alissa: Nobody picked it up. I think we should just drop this.

     o Roman Danyliw to find designated experts for RFC 7636 [IANA #1160634].

Roman: In progress.

     o Suresh Krishnan to find designated experts for the IPv6 Low Power
       Personal Area Network Parameters registries [IANA #1163481].

Amy: I think this was done, did someone pick this up from Suresh?

Alissa: Who's responsible AD for lpwan now?

Erik K: That's me. I can take this up.

     o Ben Kaduk, Alvaro Retana, and Suresh Krishnan to divide community
       suggestions in the "AD Workload" thread into workload-specific
       topics and workflow-related topics.

Amy: I think this was done, right?

Ben: Yes, we did. There were some other things that came out of it that I don't
quite remember.

Amy: They were a bit amorphous. I can send you an email with what I thought
they were and we can go from there.

Ben: Thank you.

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

Alvaro: In progress.

     o Benjamin Kaduk to find designated experts for RFC 8747 [IANA

Ben: We have a management item for that [today].

     o Eric Vyncke (with Suresh Krishnan) to write a draft of an IoT
       Systems charter.

Eric V: We start on this tomorrow.

     o Murray Kucherawy to send out a Last Call on marking TCP and UDP
       Ports 109 as "Reserved" in the "Service Name and Transport Protocol
       Port Number" Registry.

Murray: Have not done it but I can do it today.

     o Warren Kumari to draft and send email to the WG Chairs list to begin
       assembling a list of high-level keywords related to WG Charters.

Warren: I did that!

     o Warren Kumari to email the Tools Team to inquire about the possibilities
       of tagging WG Charters and the level of effort required.

Warren: I did that too.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-stir-passport-divert-08  - IETF stream
   PASSporT Extension for Diverted Calls (Proposed Standard)
   Token: Murray Kucherawy

Amy: I have a couple of Discusses in the tracker. Do we need to discuss those

Murray: The authors haven't been as proactive about getting back to the ADs on
this, but I don't have any questions about the Discusses. I'll follow up with
the WG and the authors.

Amy: Will these require a Revised ID?

Murray: I believe so, yes.

Amy: We'll keep this in IESG Evaluation, Revised ID Needed.

 o draft-ietf-dnsop-no-response-issue-20  - IETF stream
   A Common Operational Problem in DNS Servers - Failure To
   Communicate (Best Current Practice)
   Token: Warren Kumari

Amy: There are no Discusses in the tracker so if there's no objection, it looks
like this document is approved.

Warren: Approved, Announcement to be Sent. It's ready to go.

Amy: I do have a number of downrefs called out, should we add these four to the
downref registry?

Cindy: They don't need that.

Amy: Got it. Let's move on.

 o draft-ietf-mmusic-t140-usage-data-channel-12  - IETF stream
   T.140 Real-time Text Conversation over WebRTC Data Channels
   (Proposed Standard)
   Token: Murray Kucherawy

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

Murray: I don't think so. Martin and the authors have been very active chatting
about it and it looks like he's pretty close to clearing, so I guess Revised ID
Needed and I expect that to come presently.

 o draft-ietf-regext-data-escrow-07  - IETF stream
   Registry Data Escrow Specification (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: No, I don't think so.

Magnus: Yes.

Barry: We have the issue that Magnus raised of the change controller for the
registry. Let me see if I understand you, Magnus. You think that because we
have not issued the IESG statement stating the change we want, we shouldn't be
doing it.

Magnus: No, that's not what I'm saying. I'm saying the IESG statement is a
recommendation to others what they should write and what should be going into
this. But where we have existing recommendations, the IESG statement is not
going to drop them.

Barry: I think that's wrong. I think we should do the right thing, and if we've
decided that the right thing is to say that the change controller is the IETF
rather than the change controller is the IESG, we should be doing that.

Magnus: Then we have to write an RFC and publish that to change those existing
recommendations. It's basically updating the RFC that makes that...

Barry: I'm happy to draft that, if you will AD Sponsor it. For this document I
think we should do the right thing rather than be slavish about saying IESG,
because we've decided the IESG is not the right answer here. The IESG is just
the agent of the IETF. I don't think this is a hill we should die on, but I
think we should do the right thing and not quibble about that. What do others
think? The issue is that in the IANA considerations this document specifies the
change controller as IETF, and the relevant document that specifies the
template for this says it should be IESG.

Alissa: I'm not seeing how that actually maps to the draft though.

Barry: The draft says the change controller is IETF, and Magnus is correctly
pointing out that the relevant document that backs this says if it's an IETF
document, the change controller should be IESG.

Alissa: Are you talking about the registrant contact?

Magnus: Assignee, basically.

Alissa: Just wanted to confirm, because it says it's the WG.

Barry: Well, it gives the WG email address, which is also what we said we
wanted to happen. When the RFC is published, the email address won't be in the
RFC, it will just be recorded by IANA. That part is not such a problem, just
whether it says IETF or IESG.

Ben: I think we should be internally consistent across our documents, but it's
not entirely clear to me if the point in time to make that check is at IESG
approval or RFC publication.

Magnus: We have several registries that are not consistently what we think
might be right. Until we put something in place officially...writing a draft
and changing some of the registration rules is going to have to be a process.
Not everywhere does it make sense to make it into IETF. There are cases where
the policy needs to be slightly different.

Warren: We have Michelle on the call who deals with this stuff a lot. Maybe
she's got some views that would help influence us?

Michelle: Barry and I have been talking about this. I was going to help Magnus
with the IESG statement, but I like the idea of having a document create this.
I thought from previous discussions for all registrations that were done
through documents, we agreed that we wanted it to be the IETF as the assignee.
There are quite a few documents that do have specific instructions that say the
change controller or assignee is the IESG or sometimes something different. But
we wanted to go to the direction of having it be the IETF. Whether we let this
one squeak by with IESG as currently written in the RFC, or we go ahead and
proactively put IETF because that's the direction we're going, I guess I don't
have real strong feelings about. If we do put IETF I think we should get the
document out as soon as possible to clarify that documents that do specify IESG
would be changed to IETF going forward.

Barry: I'm happy to have a draft out this afternoon. That part we'll deal with.
The question is what to do with this document, where Magnus thinks we should
stick with the existing documentation and I think we should go with what we've
decided is the right way. It sounds like nobody else cares that strongly.

Murray: I was looking through the media types to see if we could find a
meaningful precedent and it looks like we don't have one there either. There's
a vague hand wavy thing that says the change control is IETF if it's an IETF
document, unless it was approved through the IESG, in which case the IESG is
the change controller. It's not very clear.

Barry: I think we were just generally inconsistent, which is why we need to
make some sort of stake in the ground for consistency.

Mirja: It's really the same, right? If we say the change controller is IETF and
somebody needs to make a decision, it would be the IESG.

Barry: Yes, the IESG is the agent of the IETF for doing approvals. It doesn't
make any substantive difference.

Mirja: In the port registry we have both, we have the assignee which is IETF
and the contact person ...

Magnus: No, it's IESG.


Mirja: And the contact is the IETF Chair.

Magnus: And the assignee is IESG. That's in 6335.

Michelle: I do like the idea of picking one and moving forward.

Magnus: I totally agree with that. The only question here is can we do this?
From a formality perspective I'd say no because we should follow the currently
in force RFC regarding this registry and not override that.

Michelle: It is true, IETF is essentially the IESG, in the way that if we had
any questions, if it said IETF we would go to the IESG.

Barry: Or you might go to a relevant WG or something like that. But you, IANA,
would go to the IESG, that's true.

Magnus: In practice it might have zero difference.

Barry: There's no substantive difference here, it's just which letters go into
the RFC. In the interest of unclogging this, I'll support Magnus and we'll make
it say IESG for now. I'll get a document out today.

Magnus: Are you ok sending in a response to the authors or should I do that?

Barry: I'll respond, since I was the one who responded saying no, don't do what
Magnus said, so I'll respond and say yes, do what Magnus said.

Magnus: Probably an RFC Editor note about removing it later.

Barry: IANA is supposed to work that out with the RFC Editor, and I don't think
we need to have a note. But I can stick one in anyway.

Michelle: With Barry, you writing that document, does that mean we don't need
an IESG statement because we'll have a future RFC?

Barry I think that's correct. I'll write a draft today and we'll get that
through the process.

Michelle: I'm happy to help on that.

Barry: So for Amy, this goes in Revised ID Needed and we don't need to discuss
the rest of the Discusses.

 o draft-ietf-tsvwg-datagram-plpmtud-19  - IETF stream
   Packetization Layer Path MTU Discovery for Datagram Transports
   (Proposed Standard)
   Token: Magnus Westerlund

Amy: There are no Discusses in the tracker so if there's no objection, it looks
like this document is approved.

Magnus: I would like to put it in Point Raised because I'd like to publish an
updated draft with all the editorial stuff before we progress.

Amy: Okay, thanks. You can let us know when it's ready.

 o draft-ietf-sidrops-ov-egress-04  - IETF stream
   BGP RPKI-Based Origin Validation on Export (Proposed Standard)
   Token: Warren Kumari

Amy: There are no Discusses in the tracker so if there's no objection, it looks
like this document is approved. I'm hearing no objection. The document does
have an IESG note; do we need to remove that before we send the announcement?

Warren: I meant to start off with that. Yes please, remove it. Then it's ready
to go.

2.1.2 Returning items


2.2 Individual submissions
2.2.1 New items


2.2.2 Returning items


2.3 Status changes
2.3.1 New items


2.3.2 Returning items


3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-taps-transport-security-11  - IETF stream
   A Survey of the Interaction Between Security Protocols and
   Transport Services (Informational)
   Token: Magnus Westerlund

Amy: There's a Discuss in the tracker; do we need to discuss that today?

Eric: I think so. Let's solve the issue. I'm a little bit surprised to see a
non-IETF protocol analyzed in this document. In the protocol description for
this non-IETF protocol, it doesn't say anything about the lack of support for
IPv6 but as you and Barry strongly object on my point here, I think it's better
to remove my Discuss after this call. So assume there's no Discuss anymore.

Magnus: I was just wondering why it mattered in this particular case, that's

Eric: Simply because it's not documented. The way it says "protocol
description," not "protocol security properties description" or whatever. It
says "protocol description," and I think in an IETF document it's very
important to say that the IPv4-only support is indicated.

Magnus: Okay. Maybe it's more about that it says "description" and not
"overview" or something like that?

Eric: Correct. And honestly adding a simple line like "no IPv6 support" doesn't

Magnus: Let me look into this and see if I can send some suggestion for one or
two changes here.

Eric: Thank you. And I will remove my Discuss at the end of the call.

Amy: Is this going to require a Revised ID?

Magnus: AD Followup for now.

 o draft-ietf-emu-rfc5448bis-07  - IETF stream
   Improved Extensible Authentication Protocol Method for 3GPP Mobile
   Network Authentication and Key Agreement (EAP-AKA') (Informational)
   Token: Roman Danyliw

Amy: I have the Consensus Unknown, is that a Yes?

Roman: I'm staring at it and I see a Yes. I must have done something wrong?

Amy: We'll make sure it's set to Yes if it's not already.

Roman: Thanks. I just have one question for Alissa: The WG went back and forth
on what track to put this on, and for consistency it wasn't made PS.

Alissa: If you know why the other ones weren't...I'm just assuming it needed to
get out the door and it was easier to do as informational or something.

Roman: I asked that exact story, because it looked like there was normative
language in there. That's what I got, that basically the first one was
informational and every one after that cascaded it forward, so that's where
we're at now with the consistency to be the last one.

Alissa: Okay. I'm not blocking it,  just wanted to ask in case it hadn't come

Roman: Can you mark this Point Raised?

Amy: Absolutely; Approved, Announcement to be Sent, Point Raised, Writeup
Needed, and let us know when it's ready.

 o draft-ietf-dnsop-multi-provider-dnssec-04  - IETF stream
   Multi Signer DNSSEC models (Informational)
   Token: Warren Kumari

Amy: There are no Discusses in the tracker so if there's no objection, it looks
like this document is approved.

Warren: I admit I haven't read any of the comments. Does anyone think this
needs Revised ID or anything that needs addressing?

Ben: I'd prefer to see it in Point Raised.

Amy: Okay, we'll do Point Raised, and Warren you can let us know when all the
comments are addressed.

 o draft-ietf-sidrops-rp-06  - IETF stream
   Requirements for Resource Public Key Infrastructure (RPKI) Relying
   Parties (Informational)
   Token: Warren Kumari

Amy: I have Consensus Unknown, is that a yes?

Warren: Yes. I think this one is all ready to go. Does anyone have an objection
to it just going? Okay, I guess it's approved.

3.1.2 Returning items


3.2 Individual submissions via AD
3.2.1 New items

 o draft-nottingham-how-did-that-get-into-the-repo-01  - IETF stream
   The secret-token URI Scheme (Informational)
   Token: Murray Kucherawy

Amy: There are no Discusses in the tracker so if there's no objection, it looks
like this document is approved. Hearing no objection. Are there any notes
needed before this goes?

Murray: I don't think so.

Barry: I think Mark had an update queued for some comments.

Murray: Oh, you're right. Then Revised ID Needed, if there's not already a
version 2. Thank you, Barry.

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

 o conflict-review-msahli-ise-ieee1609-00
   IETF conflict review for draft-msahli-ise-ieee1609
     TLS Authentication using ITS certificate (ISE: Experimental)
   Token: Benjamin Kaduk

Amy: I have no Discusses, so unless there's an objection now this conflict
review message is approved and ready to go.

Erik K: I was wondering whether or not anybody actually had access to the IEEE
document that specifies this format?

Ben: I did not get access, although the one author that had responded to me
suggested that maybe the other author could get me access.

Erik: I'm obviously not a security expert. Is that important, do you think?

Ben: I don't think it's important to getting the correct conflict review
response. It may well be that they've made some horrendous security-relevant
mistake and their protocol is insecure, but that doesn't really mean that we
should be refusing them the ability to get a code point.

Erik: Understood.

Roman: I'm with Ben. It's not a matter that they did the right thing by
security, just that it's not a conflict.

Ben: If we were doing a conflict review of the IEEE document itself there was
one topic I was a little concerned about, but that's not what we're doing.

Erik: Okay, thanks.

Alissa: I can get this if you need it.

Amy: So I'm not hearing any objection to the conflict review, so it sounds like
this is approved and we'll get that sent on Monday.

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 Deterministic Networking (detnet)

Amy: It looks like we're going for just making the changes to the charter and
not sending this out for external review. Is that correct?

Deborah: Yes. It's just a simple adding the control plane requirements, which
was already part of the charter in the control aspects, but it's just that the
first priority of the first version was to do data plane only. So it was always
there in the first blurb and it's affiliated with TEAS. So I don't think this
needs external review.

Amy: Okay, so I'm not hearing any objections to just making the changes to the
charter. It looks like we haven't carried over the milestones; is it just the
two millstones we can carry over before we announce it?

Deborah: There are a couple of tweaks in the charter text and we'll update that
and double check those milestones.

Amy: Okay, so we'll wait for you to let us know that's ready.

4.2.2 Proposed for approval

 o Transport Layer Security (tls)

Amy: There are no blocks, so unless there's an objection now it looks like the
new charter is approved.

Ben: If you could hold off on sending the announcement for a couple of days,
I'll check on the milestones and the other comment that was made.

Amy: Great, this will be approved pending edits and we'll wait for you to let
us know.

5. IAB news we can use

Alvaro: The only thing I wanted to mention is the cancellation of the retreat,
but we're going to talk about that later.

6. Management issues

6.1 [IANA #1165827] Management Item: Acceptance of media type registration from
standards organization FIX Trading Community (IANA)

Amy: Is there any objection to adding this to the standards related
organizations that have registered media types in the standards tree list?

Ben: I tried to load their website yesterday and it timed out. The GitHub site
worked, though.

Alissa: I looked at it today. I think it's fine. I love how far standards
reach; these people do standards for financial trading. But it definitely looks
like a legit organization.

Amy: Okay, so they're approved and we'll get that note to IANA.

6.2 Response to [IANA #1161777] Protocol Number for Transparent Inter Process
Communication (TIPC) (Response to IANA)

Amy: Has this already gone to IANA or is this the official approval of sending
this to IANA?

Eric: It's really what Suresh said last time, right?

Alissa: We're approving it to be sent to IANA.

Amy: So we're minuting that this is the approval note and we're sending it to

Alissa: I believe so. Michelle can confirm whether she has officially received
this or not.

Michelle: Even if you sent it twice, we wouldn't be upset. Thank you.

6.3 [IANA #1167290] Designated experts for RFC 7489 (IANA)

Amy: We need to find someone to find experts for this.

Murray: I can take that. I've already talked to the dmarc WG chairs and we have
someone in mind; I'm just waiting to hear back.

Amy: Great. We will add that action item for you, Murray.

6.4 [IANA #1167382] Management Item: Acceptance of media type registration from
standards organization Linux Foundation (IANA)

Amy: Is there any objection to this?

Ben: I have sort of mixed feelings, but not really an objection per se. The
spdx stuff is pretty widely used and the Linux Foundation happens to become the
home for it a little bit by chance, as far as I can tell, but I don't think
they're going to be irresponsible about managing it.

Barry: The main question here is if they come to us with other registrations in
the future, do we want those to come back to the IESG or do we want to just say
they can make registrations?

Ben: I think the experts for the media types should be able to do the right
thing, so we can add them.

Barry: That's what I think too. So it sounds like we're a go on this.

Amy: We will say this is approved and we'll send note to IANA.

6.5 Retreat Cancellation (Alissa Cooper)

Alissa: The question is whether, since we had the time blocked out, if we want
to use some of it for conference calls to have some discussions we would have
had at the retreat or to socialize somehow, or something. There's been a little
discussion on the list but I wanted to hear from people what your thoughts are
on using the time that week, or not.

Barry: I think we should prioritize the agenda and take things we really need
to talk about and talk about them on calls. It's not a retreat but if there's
stuff we need to discuss we should discuss it.

Roman: I have the time blocked off so I see no reason why we wouldn't use that
time if it helps us press through issues.

Eric: What would be the difference compared to the informal call?

Barry: We often have stuff accumulated to talk about that would overflow the
informals. If in the end we think we have little enough to talk about that we
can do it on informals, we can make that decision.

Mirja: For some creative thinking, I had the idea for the IAB retreat to also
do some small group work where people can self-organize. Because of the time
zone challenges we will have, which is even worse for the IAB. So instead of
just having calls and going through one topic and then another maybe there's a
more dynamic way of working through these things.

Alissa: Maybe what we can do is ask people to continue to hold the dates for a
little bit longer at least, and set up the wiki page to start generating ideas
for the agenda. People can start entering agenda items or suggestions and we
can see what we get in a few weeks and circle back. I will say that on my side,
we had four days blocked out. I definitely don't have those four days available
anymore because I have my kids at home, and I'm assuming other people have
restrictions as well so we can factor those in when we try to find times for
calls. I think we can move on.

6.6 Designated experts for "CWT Confirmation Methods" (Ben Kaduk)

Amy: Is there any objection to approving Ludwig Seitz and Mike Jones as the
designated experts for this registry?

Ben: I'm also happy to push this off for a couple weeks if people want more
time to think about it. Both of them are already experts for some other

[Erik?]: I'm good with it.

Warren: Me too. I largely think if an AD suggests people, unless we all know
the person is completely crazy, we should just nod and move on.

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

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

Barry: We keep tripping over the consensus bit and it occurs to me that since
we have the consensus informational document approved and in the RFC Editor
queue, this doesn't matter anymore. Should we be getting the tooling changed
now that we've agreed that everything that comes through the IESG has to have
IETF Consensus?

Warren: And until we get the tooling changed, assuming we decide to do that,
can the Secretariat just automatically set the bit?

Barry: Does anyone think that's not the right approach?

Warren: Feature requests for the Secretariat seem to be much easier than the

Barry: So Amy, whenever that bit's not set, the answer is Yes. Roman, as tools
liaison, can you make a request to burn the consensus bit?

Roman: Ack.

Amy: Great, we will not ask that question anymore. I just want to remind
everyone that the next two telechats will be on Friday in this time slot to
avoid hitting any interim meetings.