Narrative Minutes interim-2019-iesg-06 2019-03-07 15:00
narrative-minutes-interim-2019-iesg-06-201903071500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2019-03-07 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Ignas Bagdonas (Equinix) /  Operations and Management Area
Deborah Brungard (AT&T) / Routing Area
Ben Campbell (Oracle) / Applications and Real-Time Area
Alissa Cooper (Cisco) / IETF Chair, General Area
Michelle Cotton (ICANN) / IANA Liaison
Spencer Dawkins (Wonder Hamster Internetworking) / Transport Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Ted Hardie (Google) / IAB Chair
Benjamin Kaduk (Akamai Technologies) / Security Area
Suresh Krishnan (Kaloom) / Internet Area
Mirja Kuehlewind (ETH Zurich) / Transport Area
Cindy Morgan (AMS) / IETF Secretariat
Eric Rescorla (Mozilla) / Security Area
Alvaro Retana (Huawei) / Routing Area
Adam Roach (Mozilla) / Applications and Real-Time Area
Jeff Tantsura (Apstra) / IAB Liaison
Martin Vigoureux (Nokia) / Routing Area
Amy Vezza (AMS) / IETF Secretariat
Eric Vyncke (Cisco) / Incoming Internet Area
Magnus Westerlund (Ericsson) / Incoming Transport Area

REGRETS
---------------------------------
Roman Danyliw (CERT/SEI) / Incoming Security Area
Heather Flanagan / RFC Series Editor
Warren Kumari (Google) / Operations and Management Area
Barry Leiba (Huawei) / Incoming Applications and Real-Time Area
Terry Manderson (ICANN) / Internet Area
Alexey Melnikov / Applications and Real-Time Area
Portia Wenze-Danley (ISOC) / Interim LLC Executive Director

OBSERVERS
---------------------------------
Henk Birkholz
Greg Wood

1.2 Bash the agenda

Amy: Any changes to today's agenda? I did see a document was deferred, so we'll
pick that up next week.

1.3 Approval of the minutes of past telechats

Amy: Anyone have an objection to the minutes of the February 21 teleconference
being approved? Hearing no objection, so we will get those posted in the public
archive. Anyone have an objection to approving the narrative minutes from
February 21? Hearing no objection and we'll get those posted as well. The other
set of minutes we have outstanding are from the BoF coordination call. I didn't
get any notes on those so there are no revisions. Any objection to getting
those posted as well? Hearing no objection.

1.4 List of remaining action items from last telechat

     o Alvaro Retana to send email to the IESG with proposed re-labeling of
       scheduling conflicts.

Alvaro: It is still in progress. I'm hoping by the time we get to Prague we can
discuss something on this.

     o Suresh Krishnan to discuss naming experts for the registries created
       by draft-irtf-icnrg-ccnxsemantics with Allison Mankin.

Suresh: I'm still waiting to hear back from her and it will potentially spill
over to Colin, and I'll brief him. Keep it in progress please.

     o Ben Campbell to write up text on the IESG's expectations regarding
       conflicts of interest and the disclosure of funding sources.

Ben: Still in progress.

     o Warren Kumari and Spencer Dawkins to develop the spherical routing
       topic.

Amy: I know that's in development and is going to be presented. Is this done or
should we keep this on the list?

Spencer: I think you can mark it as done. We have a poster.

     o Suresh Krishnan to draft a new proposed IESG Statement on the
       procedure to reference material behind a paywall, that includes the
       existing text and adds comments from the discussion, Eric Rescorla,
       and Barry Leiba.

Suresh: I haven't gotten to this yet. Keep it in progress please.

     o Roman Danyliw and Barry Leiba to identify and catalogue common
       problematic and inappropriate behaviors from individuals in the IETF
       community both at in-person meetings and on email lists.

Amy: Roman and Barry are not here so we'll keep it in progress.

     o Barry Leiba talk with the EDU team on the Working Group Chairs Forum
       agenda, possibly adding an item to discuss agenda conflicts and
       unstructured time.

Amy: Barry is not here so we'll keep this in progress.

     o Ben Campbell to find designated experts for RFC 8506 [IANA #1137331].

Amy: This is a brand new action item and I see Ben has updated that management
item with possible experts so this is provisionally done.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-rtcweb-security-arch-18  - IETF stream
   WebRTC Security Architecture (Proposed Standard)
   Token: Adam Roach

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

Adam: I think Alexey's is straightforward. I'm not sure if anyone's had enough
time to process Benjamin's and respond to it. Ekr, is there anything you want
to say to it or should we treat this via email?

Ekr: It would be helpful to have more explanation of what Benjamin's concern is.

Benjamin: I can try. The main thing that jumped out at me when I was reading
this was that the body text reads like we're going to allow any web server to
claim to be an IdP and certify some identity binding. In order for the browser
to use that information the IdP has to be trustworthy to certify whatever
identity..[cut off]

Ekr: No, that is not correct. The general assumption is it's supposed to be
scoped to the origin of the IdP. So The idea is supposed to be: example.com
says this is a user. Example.com can always say that, but you don't have to
trust it. It's not a trust relationship.

Benjamin: Late in the document you do make clear the intent about any domain
can have its own authoritative server but only for identities scoped to that
domain. We also have this third party certification thing but that should be a
small list of vetted IdPs. It's clear to me the intended stance is sane, but in
reading through the main text of the document it feels fishy until you get to
the end.

Ekr: If it's an effectively editorial comment, I can fix that. I'll go through
these.

Benjamin: Most of them have a little more detail in the comments.

Ekr: Okay, I'll go through them. I just wanted to make sure I understand your
objections.

Adam: I think that's it for this document. Obviously we're going to need a new
version.

 o draft-ietf-rtcweb-security-11  - IETF stream
   Security Considerations for WebRTC (Proposed Standard)
   Token: Adam Roach

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

Adam: We're going to need a revised ID on this also; there were a lot of
editorial comments.

Amy: Okay, this will go into Approved, Announcement to be Sent, Revised ID
Needed and you can let us know when it's ready to go.

 o draft-ietf-rtcweb-ip-handling-11  - IETF stream
   WebRTC IP Address Handling Requirements (Proposed Standard)
   Token: Adam Roach

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

Adam: This one will at least need followup, if not a revised ID; the comment
about the STUN and TURN normativity is correct. We might be able to do that
with an RFC Editor note if there are no other changes necessary.

Amy: Sounds like it's going to Approved, Announcement to be Sent, Point Raised,
Writeup Needed. Let us know when it's ready.

 o draft-ietf-kitten-pkinit-alg-agility-06  - IETF stream
   PKINIT Algorithm Agility (Proposed Standard)
   Token: Benjamin Kaduk

Amy: This document has been deferred so we'll pick this up next week.

 o draft-ietf-sipcore-reason-q850-loc-06  - IETF stream
   ISUP Cause Location Parameter for the SIP Reason Header Field
   (Proposed Standard)
   Token: Ben Campbell

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

Ben: I think they can be handled in email; we just need to give the authors a
chance to respond.

Amy: Is this an AD Followup, or Revised ID?

Ben: It's almost certainly going to need a Revised ID.

Amy: Great, then we'll move on.

 o draft-ietf-sipbrandy-rtpsec-07  - IETF stream
   Best Practices for Securing RTP Media Signaled with SIP (Best Current
   Practice) Token: Ben Campbell

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

Ben: I think again we need to let the authors have a chance to respond to it.
Benjamin and I had one email response earlier and he clarified, and it was
discussed to my satisfaction. We'll let the authors respond. Benjamin, is that
okay with you?

Benjamin: Yes, I think it's basically editorial. It's just the interaction of
the formatting and small details of it made me want to ensure it gets fixed.

Ben: I hope you're right and I think it's likely editorial. I hope it doesn't
turn out to be otherwise. We'll see when the response happens. This is almost
certainly going to need a new version.

 o draft-ietf-mpls-sfc-05  - IETF stream
   An MPLS-Based Forwarding Plane for Service Function Chaining
   (Proposed Standard)
   Token: Deborah Brungard

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

Deborah: I don't think so, unless someone wants to. The authors are engaged and
responding.

Amy: Okay, then this will require a Revised ID to clear those?

Deborah: Yes.

Amy: We'll put that in the substate Revised ID Needed and move on, thank you.

 o draft-ietf-nfsv4-mv1-msns-update-04  - IETF stream
   NFS Version 4.1 Update for Multi-Server Namespace (Proposed
   Standard)
   Token: Spencer Dawkins

Amy: I have a Discuss in the tracker and a whole lot of Abstains.

Spencer: Thanks Benjamin for the Discuss, and I think that's a solvable
problem. The bigger problem I've got with this document right now is that with
seven abstains, this can't be approved. Something needs to happen to it. If I'm
understanding the will of the IESG on this, it's going back to the WG to be a
bis. The complicated part for me is that several ADs have asserted they can do
a bis that won't trip over security concerns, but I have an email from a
Security AD that says they will. If anyone has any thoughts about guidance I
can give the WG, that would be great.

Adam: One of the things that's been rumbling in my head is the prospect of
putting a new process document in that I think would be relatively short. And
effectively has something along the lines of making progress instead of
perfection on documents we've published in the past. We have a process by which
bis documents have an indication of specifically what has changed, and when we
put them out for IETF review we point to those sections. When it comes to the
IESG, only the new portions are subject to discuss. This is happening because
of the fact that people are concerned we'll have discusses on portions of
existing text, right?

Ekr: Do you think it would have been reasonable for TLS 1.3 to only have the
security considerations of 1.2? That was a bis.

Adam: It's not all bises. It would be a process that would be requested by a WG.

Ben: That would be a request, not a demand, right? If an AD looks at something
and says this really needs a change, and I know you didn't want to take that on
but this is critical, they would be able to do that. Right?

Ekr: My point is that the import of Proposed Standard is we think this document
is good. If there are now portions we think don't meet modern standards, those
need to be called out.

Alissa: I don't understand the need for a process. Why couldn't they write
narrative text into the bis that explains the situation? Then it gets evaluated
on its merits.

Ben: This WG didn't seem to think that was an option for them.

Adam: The notion is to have an accord with the community that everyone is
bought into about how these things can be handled.

Spencer: I think one of the important parts about the conversation is that it
is possible to have later surprises than the WG is getting on this doc, but
it's not easy. This is a really late surprise. No individual AD balloting
abstain is blocking this document, but the IESG is.

Benjamin: The proposal to have these bis documents that are scoped to a limited
set of changes is something that makes me uncomfortable. I'd be less
uncomfortable if there was also a provision for including some section about,
these are some additional issues that have been raised and maybe aren't so
great with the current text but we're still considering them out of scope for
the current incarnation. That might help in some cases, as Ekr was saying, but
there may be some cases where it's not going to fly with the mantle of Proposed
Standard. But I don't want to shoot down that proposal entirely right now.

Ben: This is an abstract proposal that doesn't help these guys. It might help
them later in the process of doing a bis draft if that's the result of this
discussion. I don't have a problem with updates in general and I think there
are perfectly good times to do updates. I'm quite sympathetic to the idea we
didn't want to do a bis draft because we wanted to limit the worms we were
letting out of the worm container. In this particular one, I had the same
problem as the Gen Art reviewer. Some other people commented it was very hard
to review this in this form. If it's very hard to review it, it's also very
hard for an implementer to understand the current state of the standard. I
don't think it's that updates are bad in general, just that this particular one
did too much.

Spencer: The concern that came back from the WG was basically that the
implementers this is a target for are familiar with 4.1 now, and the first
thing they'll do with a bis is do a diff and they'll end up with exactly the
same view of the world that this document is providing now.

Ekr: No they will not. As someone who tried to read the diffs, they will not.

Benjamin: To read diffs I was saving subsections from this document and from
5661 and diffing those individually, and that was kind of tedious.

Ben: I don't think that's an expectation we should require for readers. One of
the things we fall down on sometimes is we optimize drafts for our process and
not our readers. I think that's usually backwards. When you talk about existing
implementers, I hope we write things so that a new implementer can come in. I
realize with things like this that may never happen, but it would be nice.

Alissa: I think that's pretty important. This notion that it doesn't have to be
understood by anyone besides our little small club... then why are we writing
public RFCs?

Benjamin: The NFSv4 community is pretty insular within the IETF, and it's been
that way for a long time.

Alissa: But they're using our process, so you have to admit the possibility
there's a new person out there who one day becomes interested in this. We're
supposed to be catering for the broad audience, not the narrow.

Spencer: I don't think that's inconceivable. The other thing I mentioned a
couple times in email is that this is in many ways similar, except on scale, to
what we were doing with the errata draft for SCTP. The errata draft for SCTP
was an informational errata, so it was processed as an informational draft that
only needed one yes. This is being processed as a Proposed Standard so it needs
ten Yes or No Objections. It's not anywhere close to that. I'm stepping down at
the end of the month, so what would the IESG that's going to be talking to
these people like for me to tell the WG?

Magnus: I've been in a situation where I had a document abstained to hell. I
wonder if you shouldn't ballot Discuss on this. If you think it's a clarity
issue, it fulfills the Discuss criteria and you should ballot Discuss. It's a
hard discuss but I think it would be fairer than abstaining.

Spencer: The thing with abstain is that nobody is blocking it, but everyone is.

Ekr: I'm not seeing a problem here. This is a balloting procedure and people
are balloting effectively no. I'm not seeing a process problem.

Spencer: Your understanding is that abstain is No?

Ekr: Documents need a certain minimum level of support, and if you don't have
that minimum level of support the document can't advance.

Magnus: The problem is the actionable part.

Ekr: The answer is clear, rewrite it!

Benjamin: If it were possible, and I'm not entirely sure it is, to reframe this
content into a bunch of updates about how when 5661 talks about replicas it
really means both trunking and migration and replicas and this is the new
thinking about that, but this new document was phrased in terms of an update
and not a full bis. Do you think it's possible for that to be something that is
acceptably readable?

Ekr: I don't know. I'd like to understand how much this objection to doing a
bis is objection to doing the work vs. a procedural concern about being unable
to clear the IESG for reasons of things not being updated that would not be to
modern standards. Were I continuing, I'd want to see a document with a
disclaimer that says this is a consolidation of updates but does not meet
modern standards in the following respects. Which would be more readable than
the current form. Is there some other concern besides that?

Spencer: I think you've captured both the concerns of the WG, one of which is
that putting this together as a bis and reviewing it was work, and the other
was a security AD telling the WG this is a problem. If that's not going to be a
problem, telling the WG that would be great. The email that went back said it
was likely this was going to get held up. They'd be thrilled if that didn't
happen.

Ben: I'd argue that this is a big enough and intrusive enough update that it
ought to be held to the same standards we'd hold a bis draft to. For that
perspective about fixing egregiously broken things. Whatever that standard is,
the same standard should hold.

Benjamin: Interestingly, the secdir reviewer was essentially taking the same
stance. Proposing some changes to the mandatory security mechanisms that are
not really covered by the actual sections this document claims to touch.

Ekr: It is also a problem that we have documents which are longstanding that
have unacceptable security properties that nobody ever fixes because they just
revise parts of the document and continue to enjoy endorsement by the IETF. I
feel like I've discussed many documents over my term which, had they been new
documents, we would never have approved, but we approve because they're simply
a continuation of a line of documents which already had other properties.

Ben: When we talk about it being a lot of work to do a bis draft, I have to
wonder how they got this done. In spite of my objections, this is an amazing
piece of work and the amount of effort it took is astounding to me. The only
way I can imagine doing this myself is to write a bis draft, take the diff, and
build this from the diff. If they did that, they may have a bis draft sitting
around.

Spencer: The issues I've seen have mostly been about saying NSFV4.1 had at the
time acceptable security mechanisms we would not accept today, so we're really
talking about bumping this to 4.2 to bring this up to speed.

Benjamin: That's only sort of true. It contains security mechanisms that are
still perfectly fine today. The RPCSEC_GSS is still fine, and the reason we're
really stuck here is that people haven't been deploying it because they claim
it's hard to use. There's some truth to that, but there's also a fair bit of
the implementations of NFS and their integration with Kerberos is really
terrible, and people get confused trying to figure out what configurations they
need to set, what keys they need to generate, because the implementations have
put in too many choices and used conflicting names for different things, so
people have incorrect senses of what they nee to do to deploy the RPCSEC_GSS
and it doesn't get deployed very much. Then we're stuck in this deployed
reality where the security mechanism that's actually good isn't being used and
the security mechanism that's crap and is still permitted by the spec is what's
being used in the majority of cases.

Suresh: Since it's hard to read, it's not clear if it's expected to be
interoperable or backwards compatible with existing implementations of 5661. I
think that should certainly be here. I have no idea if it's going to
interoperate with something there. That's something we need to do at the IETF,
that we can be sure we do interoperability. Another thing is if the changes are
big enough to warrant a new version number or not? I don't see it discussed
anywhere, why is this an update rather than a new version number? If it adds
stuff like that I'd probably be willing to switch to a No Objection, even with
these readability issues. And I see there are some quote segments getting
updated with no apparent diff, so I'm not sure why the update is there. There
are specific things they can do to improve the document and I'm potentially
willing to switch over at some point. There's a lot of work to do in this
document.

Spencer: Thank you. That's very helpful. So anything else on this one?

Amy: Okay, that doesn't sound like it's anything else. Did you want AD Followup
on this?

Spencer: At least AD Followup. I'll talk with Magnus about what we're really
going to tell the WG on this.

2.1.2 Returning items

 o draft-ietf-jmap-core-15  - IETF stream
   JSON Meta Application Protocol (Proposed Standard)
   Token: Alexey Melnikov

Amy: Alexey's not here and I have a couple of Discusses in the tracker; do we
need to discuss those today?

Benjamin: For mine, email with the authors is fine. We got a lot of
improvements between versions 14 and 15, and there are just a couple more
things to tweak. I don't know about Mirja's.

Amy: So they're still revising, is that your feeling Benjamin?

Mirja: I think this is resolved, I just didn't have time to look into it. I can
do that right after the call.

Amy: Benjamin, do you think we're still working on a Revised ID?

Benjamin: I'd put it in Revised ID.

 o draft-ietf-jmap-mail-15  - IETF stream
   JMAP for Mail (Proposed Standard)
   Token: Alexey Melnikov

Amy: Alexey is not here. I have a Discuss in the tracker; do we need to discuss
that today?

Benjamin: It's pretty straightforward but it should just be an email
conversation with the authors. Revised ID is fine.

2.2 Individual submissions
2.2.1 New items

 NONE

2.2.2 Returning items

 NONE

2.3 Status changes
2.3.1 New items

 NONE

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-rmcat-eval-test-09  - IETF stream
   Test Cases for Evaluating RMCAT Proposals (Informational)
   Token: Mirja Kuehlewind

Amy: There are no discusses so unless there are any objections it looks like
this is approved. There are no notes, are any needed?

Mirja: Please put it in Point Raised; I'll double check.

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 NONE

3.2.2 Returning items

 NONE

3.3 Status changes
3.3.1 New items

 NONE

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 NONE

3.4.2 Returning items

 NONE

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

 o Relay User Machine (rum)

Amy: There are no blocking comments so unless there's an objection this can go
out for external review.

Adam: I think I want to hold on to it; Ekr made a comment about RUM possibly
being a terminology collision and I want to look into that a little more. I'd
hate to put this out there and then have the name change.

Amy: Are we talking about a name change or an acronym change?

Adam: It would probably be both.

Ekr: Please don't tell me we can't change the acronym.

Amy: You can't change the acronym. Once that's set everything hinges on it.

Alissa: You can just abandon this one and create a new one.

Adam: That's what I would expect to do if it's a bad collision. I'll note it
went through Dispatch without anyone noticing.

Ekr: You'll notice it's not a block; I'm making this comment for your awareness
and you can do whatever you want.

Adam: I want to look into it and see how bad a collision it is before we make a
decision to change the name.

Ben: So if abandoning this one and re-charter a new name happens, that doesn't
mean we have to go through the whole process again, would it?

Amy: It wouldn't change anything for you; this is for external review. You're
so early in the process that it's not going to mess up anything too much, we
may just have to shove a little bit on the tool to make it show up in the right
state.

Adam: Hold on to this for a little while and then I'll get back to you about
whether we're going to change the name or release it as-is.

4.1.2 Proposed for approval

 o Remote ATtestation ProcedureS (rats)

Amy: I have no blocks on this charter, so unless there's an objection now it
looks like this is approved to be a new WG.

Benjamin: We did get one comment about the formatting of the bulleted lists,
which does not show up in the view I'm looking at. I'm happy to hold on to this
and get that fixed, if there's something that needs to be done there. Adam, do
you remember what you were looking at?

Adam: If you look at the charter itself up near the top...it's not there now.
Apparently something changed in the way the tool is handling this, so you can
leave it as is. Ignore my comment.

Benjamin: Okay, so it sounds like the Secretariat can do the normal approval
messages.

Amy: We will send that out.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 NONE

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Deborah: If you recall, we had that appeal from someone questioning the
independent submissions stream and the fairness of those procedures. The IAB
did a response and it's posted on the IAB appeals page. They're sorting out BoF
coverage; it's not finished yet but I imagine once they get it done they'll
send us mails to say who's covering what. They're working on a couple of
documents and we'll see it soon on the list: a draft by Mark and it's a
statement that the internet is for end users. They're going to send it out on
the IETF list soon. And for whoever wants to be the IAB liaison, they've
settled on their retreat dates: May 16 and 17.

Ted: The retreat looks likely to be in Reykjavik right before RIPE.

6. Management issues

6.1 Response to Liaison Statement on "Request to update the IoT and SC&C
Standards Roadmap and the list of contact points" (Suresh Krishnan)

Alissa: This is due in a couple of weeks so this is the check-in point.

Suresh: I'm discussing this with the IoT directorate. I've only gotten one
volunteer. I'll give you an update on the next telechat. The IoT DIR meeting is
right now, so I'll catch up with them and let you know next week.

6.2 IESG agendas at IETF 104 (Alissa Cooper)

Alissa: There were just a couple of candidate topics people put on the wiki.
I've tried to allocate them onto our agenda time. We have a couple of slots in
here where we usually meet; we have Sunday morning, and what we decided last
year is that at at the March meeting we'll do the longer Sunday morning. We
have new ADs coming on so we'll get more fulsome updates. We have our various
liaison roles to sort out, and a couple of other topics that came in on the
queue.

We have two breakfasts, Monday and Wednesday. Thus far we have only really one
other topic, about these invited speakers Barry is interested in for IETF 105.
I put that on Wednesday, as well as overflow from Sunday and plenary prep; that
was quite useful last time, when we previewed some questions we thought we
would get at the plenary and gamed that out in advance. The question is at this
point whether anyone has other topics they plan to add. If not, or if there are
only one or two more, I think we can go ahead and cancel the Monday breakfast
and give you that time back. We need to tell Stephanie by tomorrow or at the
latest Monday so she can cancel the catering.

Alvaro: I have a topic of the relabeling of agenda conflicts. That shouldn't
take a lot of time.

Adam: I'm thinking of putting together a draft that has a strawman proposal
taking into account the Security AD's concerns about a streamlined bis process
that I might want to have some time for.

Alissa: Okay. I think if it's just those two we can put one on Sunday and one
on Wednesday and we're probably still fine to cancel Monday.

Amy: We'll take that back to Stephanie and let her know the Monday breakfast
has been cancelled.

6.3 [IANA #1137331] Designated experts for RFC 8506 (IANA)

Amy: Ben has identified Jouni Korhonen and Lionel Morand as designated experts
for these registries. Any objection? Hearing none, we'll send an official note
to IANA.

6.4 Change to handling for iesg-only mailing list (Secretariat)

Amy: Adam had sent email to us talking about a change you wanted to have happen
for the iesg-only mailing list and we went back to our IT and now we have a
couple of questions. Is the IESG completely certain they want iesg-only-104 as
the naming convention?

Adam: That was a strawman; it's completely up to you.

Amy: We were thinking if it was iesg-only-2019 that might be better?

Ekr: That wouldn't work because of vacancies. If someone quits halfway though.

Adam: You could create A or B. This should be largely opaque to everyone.

Amy: We currently add incoming members to iesg-only as soon as they are named.
Do you want to change that procedure so the iesg-only list springs into being
during the meeting?

Alissa: I think we want this to match the old behavior. This is about the
archives; I don't think we intended to change the behavior of when people get
added.

Spencer: The awesome idea someone is going to get the first email to iesg-only
while sitting on the stage after getting their dot....

Amy: It's fairly opaque to us how busy this list is since we aren't on it.

Cindy: About the overlap between outgoing and incoming, if that's a separate
list also?

Adam: If we're going to implement it that way, that's what we have to do; have
a transitional list that's only around for a few months. This scheme was chosen
because I thought it seemed easiest to implement; if this is making things
complicated, any other scheme that accomplishes the same result (Limiting
archive access to those people who were on the list when the message was sent)
is fine.

Benjamin: Should we delegate Adam to talk to the IT folk with any questions
that come up?

Adam: I'm happy to do that. Do you want to keep Ekr looped in as tools liaison?

Ekr: I'm fine with that if it's done soon.

Amy: I think we have enough now to get the ball rolling, thank you.

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