Skip to main content

Narrative Minutes interim-2019-iesg-20 2019-10-03 14:00

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

Narrative minutes for the 2019-10-03 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
Michelle Cotton (ICANN) / IANA Liaison
Alissa Cooper (Cisco) / IETF Chair, General Area
Roman Danyliw (CERT/SEI) / Security Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Wes Hardaker (USC/ISI) / IAB Liaison
Ted Hardie (Google) / IAB Chair
Benjamin Kaduk (Akamai Technologies) / Security Area
Warren Kumari (Google) / Operations and Management Area
Barry Leiba (Futurewei Technologies) / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
Alvaro Retana (Futurewei Technologies) / Routing Area
Adam Roach (Mozilla) / Applications and Real-Time Area
Martin Vigoureux (Nokia) / Routing Area
Amy Vezza (AMS) / IETF Secretariat
Eric Vyncke (Cisco) / Internet Area
Magnus Westerlund (Ericsson) / Transport Area

Ignas Bagdonas (Equinix) /  Operations and Management Area
Heather Flanagan / RFC Series Editor
Suresh Krishnan (Kaloom) / Internet Area
Mirja Kuehlewind (Ericsson) / Transport Area
Alexey Melnikov / Applications and Real-Time Area
Portia Wenze-Danley (ISOC) / Interim LLC Executive Director

Chris Box
Darren Dukes
Francesca Palombini
Greg Wood

1.2 Bash the agenda

Amy: Any changes to today's agenda? [None.]

1.3 Approval of the minutes of past telechats

Amy: Does anyone object to the minutes from September 19 teleconference being
approved? Hearing no objection. Does anyone have an objection to the narrative
minutes being approved? Hearing no objection.

1.4 List of remaining action items from last telechat

     o Ignas Bagdonas to propose an additional question on YANG Model
       format validation for each of the styles of document write-ups.

Amy: Since Ignas is not here, we will keep this in progress.

     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: That's still in progress.

     o Eric Vyncke to write up draft text for the NomCom to help them
       understand the rules for the NomCom.

Eric: That's still in progress.

     o Roman Danyliw to shepherd the analytics discussion
       with the community.

Roman: I think we can mark that closed. A proposal was sent to the community
and now there's an implementation discussion happening.

     o Ignas Bagdonas to find designated experts for RFC 7317 [IANA

Amy: We will leave this in progress for Ignas.

     o Adam Roach to collate the list of specific "hot topic" items from
       each Area that will be provided to document authors and post it on
       the wiki.

Adam: That's been on the wiki and out for review. My next step is to get it out
to the WG chairs mailing list, which I intend to do today. You can mark it as

     o Adam Roach to send a message to the tools team cc Roman as
       liaison about removing the required date associated with milestones
       on WG Charters.

Adam: There is now a ticket open for that. It's in progress now. You can close
this one too.

     o Magnus Westerlund and Suresh Krishnan to draft an "AD Evaluation"
       checklist, and add it to the IESG wiki.

Magnus: It's been started but it's not finished.

     o Alissa Cooper to work with Liz Flynn and Alexa Morris to determine
       the optimum time for open agenda time for IETF 106 (before 10am as
       in Montreal, or longer lunch break, or something else).

Alissa: No progress on this. I think I sent everything to the list from my
conversation with Liz and Stephanie.

Amy: It's just waiting for session requests to close, right?

Alissa: That's what we did last time. Sounds good.

     o All IESG to discuss on the IESG mailing list which SWOT/PEST
       topics are the priority, and which three or four should be
       discussed in Amsterdam at the retreat.
       (Deadline to socialize the topics: October 3 IESG Telechat)

Amy: I think this particular item is done, since I've seen conversation about

     o Ignas Bagdonas to send the YANG Model format variation for each
       Style of shepherd document write-up text to Alissa Cooper.

Amy: We will mark this in progress for Ignas.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-acme-ip-08  - IETF stream
   ACME IP Identifier Validation Extension (Proposed Standard)
   Token: Roman Danyliw

Amy: There are no Discusses for this document, so unless there's an objection
it looks like this one is approved. I'm hearing no objection to approving this
document. It has no notes; Roman, are there notes required here?

Roman: Please mark it Revised ID Needed. There are a couple of helpful comments
that still need to be folded into an update as promised by the authors.

 o draft-ietf-acme-tls-alpn-07  - IETF stream
   ACME TLS ALPN Challenge Extension (Proposed Standard)
   Token: Roman Danyliw

Amy: There are no Discusses for this document, so unless there's an objection
it looks like this one is approved.

Michelle: We are waiting for the acme reviewer to get back to us.

Roman: That makes sense. I would have requested AD Followup on this one because
there were several important comments not in there, especially the ARTAREA

Amy: Okay. We'll put into Point Raised, Writeup Needed and you can let us know
when it's ready to go.

 o draft-ietf-sipcore-callinfo-spam-04  - IETF stream
   SIP Call-Info Parameters for Labeling Calls (Proposed Standard)
   Token: Adam Roach

Amy: I have a couple of Discusses. Do we need to discuss those today?

Adam: I think for the most part we want to wait to hear back from the authors,
but I have a quick question for Alissa about her second point. I'm a little
curious about the nature of where she thinks these things might come from. Are
you anticipating there's an ITU document or an industry consortium that's
characterized these?

Alissa: That's what I was wondering. I saw a reference to the robocall strike
force. Maybe they didn't write it down. It just seems odd to me that IETF would
become the source of call types for telephone calls. It's just a little weird
that such a thing wouldn't exist in some telephony oriented forum.

Adam: I did a quick sweep through any of the usual suspects I would except to
have something like this and I couldn't find anything immediately, so it might
be that it's not out there in any consolidated form.

Alissa: Okay. I just wanted to ask.

Adam: Thanks. Aside from that, I think we're just waiting to hear back from the
authors. Thanks. We're going to need a Revised ID.

 o draft-ietf-acme-star-09  - IETF stream
   Support for Short-Term, Automatically-Renewed (STAR) Certificates
   in Automated Certificate Management Environment (ACME) (Proposed
   Token: Roman Danyliw

Amy: I have a couple of Discusses. Do we need to discuss those today?

Roman: We do not. Some of the issues are understood and the authors are going
to continue having that conversation, if you could just flag that as Revised ID

Ben: One of my points may not actually be needed. I was confused about what the
configurable field in the IANA registry means. Because if we go back to look at
8555, IANA considerations say that 'configurable' just means it can be included
in the newOrder request. I don't think that's technically a formal problem
we're posting to the order URL with a new value for that field. I need to reply
back to the authors. It may be too late for them to do their revised ID if
they've already made the change, but I don't think they need to make the change

Michelle: This is another one where since it changed to version 9, we had the
expert review the request again so they still have it. We're also waiting for
the TLS experts for some requests in this document. We've heard from one and
they indicated it might just be a couple days until we hear from the others.

Roman: Understood. Thank you. We still have Alexey's issue about tightening up
the registration language and that's going to require new text, so I still
think a new ID is required.

 o draft-ietf-isis-yang-isis-cfg-40  - IETF stream
   YANG Data Model for IS-IS Protocol (Proposed Standard)
   Token: Alvaro Retana

Amy: I have a couple of Discusses. Do we need to discuss those today?

Alvaro: No, I don't think we need to discuss these. We will require a new ID
for this one.

 o draft-ietf-payload-tsvcis-03  - IETF stream
   RTP Payload Format for TSVCIS Codec (Proposed Standard)
   Token: Barry Leiba

Amy: I have a couple of Discusses. Do we need to discuss those today?

Barry: No, we just have to wait for the authors to respond. Just put it in AD

 o draft-ietf-pce-lsp-control-request-09  - IETF stream
   Ability for a Stateful Path Computation Element (PCE) to request
   and obtain control of a Label Switched Path (LSP) (Proposed
   Token: Deborah Brungard

Amy: I have a Discusses. Do we need to discuss that today?

Deborah: I'll let the others decide. I know that Dhruv did respond to Ben on
Tuesday. It's up to others if they want to discuss it or not.

Ben: I think we can do that on email.

Deborah: Okay. So it's definitely Revised ID Needed.

 o draft-ietf-cbor-array-tags-07  - IETF stream
   Concise Binary Object Representation (CBOR) Tags for Typed Arrays
   (Proposed Standard)
   Token: Alexey Melnikov

Amy: Alexey could not be here today. I have no Discusses in the tracker and
only one of the people who have no position is here. Ace, did you have a
position on this document or no?

Warren: No, I don't have a useful position.

Amy: I have no Discusses and there are enough positions to pass, so we will put
it into Point Raised for Alexey.

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-teas-native-ip-scenarios-09  - IETF stream
   Scenarios and Simulation Results of PCE in Native IP Network
   Token: Deborah Brungard

Amy: I have a couple of Discusses. Do we need to discuss those today?

Deborah: I'll ask the rest of them; should we start the discussion today?

Magnus: I think we should. This is to a large degree a question for the IESG. I
don't want to put myself in Abstain so I put myself in Discuss regarding if
this should be published or not. I don't really feel that strongly but I didn't
want to Abstain because I don't think that's the right way to deal with this
kind of document. Is this reasonable to get published? I understand if the WG
still wants to produce it, but the fact that it looks more like we investigated
this thing, blah ... that's the feel I get from the document and it doesn't
really have this support document feel either.

Alissa: Just curious, Deborah, do you know if anyone in the WG supported the
advancement of this document aside from the authors?

Deborah: They did. They weren't sure on the need for this, but there were
people that understood that they needed this. As we said there's another
document coming along now from spring that has the same requirements for
traffic engineering for native IP. Most people put their mpls solution hats on
and they were a bit wary of this. There was nobody saying they were against
this document being published.

Alissa: Right. I was asking if there were people who said they were for it
being published, that were not the authors.

Deborah: You could say that people felt it was appropriate to be published in
teas, and then pce could begin work on it. I really didn't follow exactly if
other operators came forth and said they need this. We always have a couple
operators come in with something and it takes a while until they have the
bandwagon that more operators think they need it. Like I said, nobody went
against this.

Alissa: It was just hard to tell from the shepherd writeup if there was support
for it outside of the author group.

Deborah: The shepherd writeups are being a bit conservative now, because before
the IESG has gone to the list and said nobody spoke up for this, is this really
something you want to do? They just want cover their tracks and say that while
interest level was low, there was nobody against it.

Alissa: Okay. Thanks.

Deborah: To clarify, I don't know that we need this for native IP. I'm not
going to go against another operator. Now we have this other document in spring
and we want to try to get the general requirements nailed down so we have
similar attributes being supported across pce and protocol specific if we need.
Yesterday we saw that ITU is going to start work on this. It's authored by
Chinese operators, and China Mobile and China Unicom are pretty big and I'm
very happy they came to us and put this document here instead of working at
ITU. We talked about that when we talked about informational documents with
Heather at the BoF. You saw the operators come to the mic and say 'we like
informational documents' and again at the plenary. People do savor
informational documents. We want to attract operators but we say we're not
interested in your requirements, we just want to do solutions. We have some new
people and if we're going to tell people we're no longer doing informational
documents I don't think the community would go for it.

Ben: To try and clarify, I'm not opposed to publishing informational documents
about native IP sort of stuff. It's just not clear to me what this specific
document is bringing to the table. If it was discussing something that's
actually deployed or a more fleshed out architecture such that someone else
could try to run the deployment, or the same sort of simulations, I think that
would be quite useful to me. The sense I get from just what's here is that this
shows a lot of promise and would be interesting to hear more about, but I don't
know that there's quite enough here to make me happy publishing just what's
here. I was trying to give concrete feedback about ways we could tweak the
document and make it a better fit for publication.

Warren: I didn't ballot on this, I oscillated between No Objection, Abstain,
and No Record. Eventually I couldn't decide which so I left it alone. I like
the idea of the document, but I just think it isn't very complete and I wasn't
sure how to write that down. I think this would be useful if it had a bunch
more text in it. I don't know if that's helpful input or not.

Roman: I'm less concerned about section 3, and I'll let the experts in the wg
drive demand for having section 3. Ben has his comments on how to polish that.
My concern was with the science of section 4. I just don't exactly understand
what was being described in the simulation, and given that there's a whole
other document that's open access to read and written by the same subset of
authors and in a better, more detailed way, I'm not sure why we're replicating
that here down to the charts and figures.

Eric: Exactly my point as well. If we take a scientific paper that's open and
free and available and duplicate it in RFCs, what's the point? I don't mind
doing it but I see no value. Operators explaining their experience are
perfectly welcome.

Deborah: Concerning this document and others I've received, this one I just
don't see. I think it's appropriate content, and they give traffic demands. To
me it's okay. If you want to continue having your Discusses you can ask the
authors to add more content to be specific, and we'll see where it goes. If it
doesn't get resolved I'll send it back to the wg. But please try to be specific
about what you're looking for to the author. He's been very responsive. The
other question was on the charter, and I don't know if you want to discuss that
or not.

Eric: On the charter, it's a wg document, so it's too late to discuss about it.
It's a useful work anyway, so whether it's coming from this wg or another, I
don't mind too much.

Alissa: Sometimes wgs do things that are out of charter, and it's okay for us
to discuss them, because the whole point of chartering is that we said there
was a set of things people were going to work on. I'll say I did this analysis
and it seemed like it was in charter to me.

Magnus: I cleared my point on this. But it was bringing up a thing which is on
topic related, but it doesn't say. This type of use, not classical support
documents, etc, was a potential angle. But I cleared [my Discuss].

Deborah: So like I say, let the authors know what your concerns are and we'll
see what can be done with it. I feel strongly now that I think it looks great
we can reply to the ITU liaison and say we are doing this work. This work is
exactly what ITU says they want to do and we're doing it too.

Roman: Can you talk me through the structuring of all of the material? We have
one draft that describes scenarios and motivations for the work, plus the
simulation that validates a solution; that's one draft. Then there's another
draft that talks about a solution that implements the problems plus the
manifestation of this simulation -- is there a reason why it was broken up that
way? Because I would have expected you'd have something that says here's the
problem draft, then you'd have a draft that talks about the solution, then
another draft that's like an implementation report that validates why that
solution is happening.

Deborah: We often see that authors from the operator community are trying to
get visibility, so they have lots of drafts; use cases, a framework, etc. Then
we choose as it goes through the wg how many documents we're going to publish
on something. On this one first they're just getting the use cases out, then we
can decide how many informational documents we want to pull through after. You
can look at any of the groups like detnet too; they have use cases, scenarios,
all kinds of stuff. There's no exact formula, but we do like to see use cases,
requirements, and then solution work. But as we all say, don't hold up solution
work while you're figuring out these informational documents. Which is exactly
what they're doing.

Roman: I completely agree; I just had the opposite reaction in terms of what I
would have expected in individual drafts. It caught me as an odd consolidation
I wouldn't have thought of, and I was wondering if there was motivation for
that particular version of consolidation to give less informational documents.
Thanks for the explanation.

Deborah: It's a question also that these documents might move over to pce in
the end.

Ben: I guess I'm on the hook to talk to the authors and try to get some
specific feedback for potential changes. Probably if that happens, many of the
people who have abstained will be able to change to No Objection as well. So
that means we leave the document in Revised ID Needed?

Deborah: Yes, Revised ID Needed.

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

 o status-change-dlv-to-historic-01  - IETF stream
   Moving DNSSEC Lookaside Validation (DLV) to Historic Status (None)
   Token: Warren Kumari

Amy: I have a single Discuss for this; do we need to discuss this today?

Warren: Yes. Alvaro put in the Discuss and I completely misread it. [audio
garbled] I think what needs to happen is that we probably do need to in fact
publish the draft-ietf-dnsop-obsolete-dlv document itself. As far as I can see,
that will have to be resubmitted with an updated header. I think it would have
to be standards track, because it's going to be making changes to standards
track documents. The big question I have is are people okay with the text in
section which basically just describes how it updates the two documents
that it does, and doesn't contain old text / new text. I think it's better the
way it is, but I just wanted to check that's okay.

Adam: That's generally my preferred way of doing things anyway because it's
easier to understand. I also agree with everything else you said.

Alvaro: That works for me as well.

Warren: The preferred way is the way it is in the document, or the preferred
way is the other way?

Adam: The preferred way is the way it's in this document. It's a matter of
taste, but that's the one I prefer.

Warren. Cool. I'll ask the authors to update that and resubmit it, and
unfortunately it's going to have to go through another IETF last call. I will
have to apologize profusely to the dnsop wg and the authors, and then this will
come back. I don't know what the status should be on this document.

Amy: I think we can do an AD Followup on this.

Ben: Before we move on, on the topic Adam was mentioning with preferred format
for how to say that things update, generally I agree about the preferred
format. I was just going to note that for this particular text, had it been in
a document in front of us I would have looked more closely to verify that it's
actually clear about what's being done. I did not do that this time because we
were looking gat the status change and not the document, but probably Adam did
so and I don't expect any problems here.

Adam: This will be coming back to us, obviously.

Warren: To me it seems clear enough. Thank you.

3.3.2 Returning items


3.4 IRTF and Independent Submission stream documents
3.4.1 New items


3.4.2 Returning items


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

 o Lightweight Authenticated Key Exchange (lake)

Amy: We have a blocking comment here. Do we need to discuss that today?

Ben: We talked about that a little bit for the first part. It's on me to make
some tweaks to the text. For the second point, I think we do need to discuss
that probably today. Alissa, do you agree?

Alisa: It would be useful. The question that remains for me is it clear to
everybody else what is expected to happen here? If something gets produced in
one group, what the effect is on the other group. I appreciate that it's
controversial but I think it's important for everyone to have the same
understanding of, if TLS recharters and does a thing that's blocking on lake,
and vice versa, I think something needs to be said about that.

Ben: Thinking on the spot, one way to do that might be to change the language
about zero or one to apply instead to the number of solutions that meet the
requirements, which is to say that if there is a "preexisting" solution that
meets the requirements, then it's not appropriate for this wg to produce
another one. It's not 100% clear to me that would fly with the expected
participants but I think it would certainly resolve the clarity issue.

Alissa: That sounds fine, if that's what it is. I don't care if it's 2, or 7,
or 1, or 0. I just think it needs to be clear.

Ben: I guess I will ponder if that's actually what I want to do, vs. it being
okay for us to end up with two different solutions. So maybe I'll huddle with
Roman and get some updated text together. In terms of the timing, does the
charter go out for a 2 week last call or 1 week?

Cindy: The default is 10 days, but we can go as low as 7.

Ben: So I have a little bit of time to get something together and get the last
call out and get it onto another telechat before the IETF meeting. I think
that's all we need to talk about for the charter and we'll get some updated
text out real soon.

Amy: I didn't see this on the BoF wiki as a placeholder; if you expect lake to
meet in Singapore you need to get it on the BoF wiki so it gets a slot.
Tomorrow's our deadline for that.

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

Ted: Probably important for you to know that RSOC sent the SOW to the IAB and
the IAB has transmitted it to the LLC. The actual RSE RFP will come out
relatively soon. RSOC should be sending out messages to the community with the
SOW text. Hopefully it will produce no great firestorm of heat, but FYI in case
your mailboxes get overflowed.

6. Management issues

6.1 SWOT/PEST Topics for the Retreat (Alvaro, Alissa)

The retreat agenda was discussed and several changes were made, now reflected
on the wiki. Four topics from the SWOT/PEST will be discussed in breakouts:
Technology, Operations - Externally Facing, Culture, Process - Internally
Facing. There is a space on the wiki for retreat attendees to sign up for the
topics they are interested in.

6.2 [IANA #1151831] Acceptance of media type registration from standards
organizations DLMS UA and IEC (IANA)

Barry: IEC is very clearly appropriate. I did some looking into DLMS and it's
an industry standardization organization that does seem appropriate. I think we
should approve both of these.

Amy: Is there any objection to approving both of these and adding them as media
types? Hearing none; these are approved and we will send official note to IANA.

6.3 Important Dates 2020 (Liz Flynn, Secretariat)

Alissa: I just wanted to ask the question of whether people think we need to
establish where in the agenda the open time is sooner than we have been doing.
It came up in this round and we just decided earlier to not do it sooner, but
people thought there needed to be a date certain that isn't just the day the
preliminary agenda is published. I don't think we need to do it earlier.

Ben: Would the goal be to have that on public-facing lists, so other people can
rely on it, or just as an internal forcing function for us?

Alissa: It would be public. I don't think it's really useful for us. I'm not
even clear it would be useful for others.

Barry: I thought part of our issue was that we needed to see what requests come
in and how they lay out on the grid before we can decide that. I think really
it's difficult for us to do it significantly before the preliminary agenda
comes out.

Alissa: Okay. I just wanted to ask. The dates themselves look fine.

Eric: The preliminary agenda also depends upon the length of the sessions,
which is also impacted by the open time. If we start late, we have less time in
the morning.

Barry: Yes, but the point was to do it all in one thing. It didn't make sense
to decide one before the other, we needed to do them in concert.

Eric: They influence each other. Right.

Alissa: It's sounding like we can continue as is, with the priority that we see
how many requests we get first.

Amy: Is there any objection to approving the important dates as laid out
currently? Hearing no objection, so we will mark those approved and they will
go live in the datatracker.

6.4 Possible Telechat Dates After IETF 106 (Secretariat)

Amy: There seems to be a preference for proposal 1 over proposal 2, which is an
informal call or no meeting on January 2, and then back to back formal
telechats the weeks before IETF 107. Is there any objection to proposal 1?
Hearing no objection, so we will do so.

6.5 Proposed Application Behaviour Considering DNS (ABCD) Charter Text
Discussion (Alissa, Barry)

Barry: As I read through Alissa's proposal I mostly think it's okay. I think we
had some comments on the list for tweaking it. The one Eric and Ace and I put
forth and that one are both pretty vague. Some people have a little angst about
that, understandably so. Does anybody want to make any specific comments?

Eric: I agree with you Barry. If we take Alissa's draft with the comments from
the list, I think we're good to go.

Barry: I will have a look at that and tweak it to address whatever comments we
had, and post it back to the list before I put it to the ADD list. I'll try to
get that done by tomorrow. Does anybody object to that plan?

Adam: It sounds like a good way forward to me.

Alissa: One more thing. The IAB was quite curious about what's going on with
this; would anyone object to me (or someone) forwarding this to the IAB once it
hits the IESG list?

Barry: When I post to the IESG list I'll send it to the IAB as well.

6.6 [IANA #1151876] renewing early allocations for
draft-ietf-idr-bgp-ls-segment-routing-msd (IANA)

Alvaro: This document already went through WG last call, so I'm hoping we will
see the document soon.

Amy: Any objection to renewing the early allocation for this? Hearing none, so
we will send official note to IANA.

6.7 Last-call mailing list (Barry Leiba)

Barry: My sense of the comments that we got were "do it," with a few "well, uh"
but mostly do it. I just wanted to make sure we were all set with my going
ahead. I hear no objections. Amy, should I send a request to action to create
the mailing list, or can you take it as an action from this?

Amy: I think we can just take it as an action from this. You want it to be

Barry: And initial subscription list will be the same as those to Before you do it, I'll have a message out to to
let people know to expect it, and then I'll talk to the tools team.

Amy: We'll create the list today and the tooling will follow once that is in

Barry: Cindy brought up the issue of special handling for ietf-announce? What
is the reason we're doing it that way rather than just bit bucketing a post to
ietf-announce and using Reply-To to handle that?

Cindy: Honestly this predates AMS as Secretariat so if there's a reason, we
don't know what it is. I would be super happy if it changed.

Barry: So I will talk to the tools team and make sure there are no concerns
about it from them and we'll set that in motion.

Alissa: Jared and Bron have agreed to be the moderators. I don't know if that
implies they need any particular privileges.

Cindy: For ietf-announce and ietf@ietf, its which feeds
into a Secretariat queue so we can release things from moderation. We can add
additional addresses with privileges to do that too.

Barry: So we'll follow up with email with about who we
want to moderate it.

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

Barry: Quick item for Alissa; please have a look at
draft-klensin-unicode-review and see if it addresses your Discuss acceptably?

Alissa: Probably next week.

Barry: If you could manage it this week, it would be good. We do want to get
that one out quickly. The other one, 5891bis, we've decided to hold back to try
to see if there's some significant improvement we can make. The unicode update
one we want to get out quickly. Thanks.