Narrative Minutes interim-2018-iesg-23 2018-11-21 15:00
narrative-minutes-interim-2018-iesg-23-201811211500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2018-11-21 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
Warren Kumari (Google) / Operations and Management Area
Alexey Melnikov / Applications and Real-Time 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
Amy Vezza (AMS) / IETF Secretariat

REGRETS
---------------------------------
Heather Flanagan / RFC Series Editor
Mirja Kuehlewind (ETH Zurich) / Transport Area
Terry Manderson (ICANN) / Internet Area
Martin Vigoureux (Nokia) / Routing Area
Portia Wenze-Danley (ISOC) / Interim LLC Executive Director

OBSERVERS
---------------------------------
Jim Hague

1.2 Bash the agenda

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

Adam: I don't know, I can't get to the datatracker either.

Alvaro: The datatracker is down from here as well.

[discussion of website/datatracker technical difficulties]

Amy: Technical difficulties abound, but let's try to move on. I have a paper
copy of the agenda.

1.3 Approval of the minutes of past telechats

Amy: Anyone have an objection to the minutes of the October 25 telechat being
approved? Hearing no objection; we will get those posted. I did see the revised
narrative minutes from October 25; does anyone have an objection to approving
those? Hearing no objection so we will get those posted.

1.4 List of remaining action items from last telechat

     o Eric Rescorla to find designated experts for RFC 8411 [IANA
       #1120853].

     o Eric Rescorla to find designated experts for RFC 6509
       (mikey-payloads) [IANA #1121057].

     o Eric Rescorla to find designated experts for RFC 6043
       (mikey-payloads) [IANA #1121239].

     o Eric Rescorla to find designated experts for RFC 6267
       (mikey-payloads) [IANA #1121240].

     o Eric Rescorla to find designated experts for RFC 6309
       (mikey-payloads) [IANA #1121241].

Amy: I have a whole list of them here for Ekr for designated experts. Any
forward movement on any of those?

Ekr: Barely managed to read the drafts.

Amy: Okay. I also have some possible additional action items that came out of
the Wednesday meeting in Bangkok; two or Alvaro. One to follow up on putting
major discussion points of decisions on the wiki. Would you like me to add that
as an action item?

Alvaro: Yes, I do.

Amy: The second one was about following up on documenting the bigger discussion
decisions from face to face conversations for you as well

Alvaro: Yes.

Amy: We'll add those moving forward and we'll try to remember ask for future
action items for the IESG whether you want those put on the action item list as
well.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-clue-protocol-17  - IETF stream
   Protocol for Controlling Multiple Streams for Telepresence (CLUE)
   (Proposed Standard)
   Token: Adam Roach

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

Adam: I think on those, if I'm remembering correctly, we're mostly waiting for
responses from the authors. I suspect we're going to need revisions. If anyone
who has a Discuss on this thinks they  rise to the point they talk about, I'm
happy to entertain that, but I can't remember what they are right now.

[datatracker reloads]

Michelle: I dropped you an email this morning about some IANA issues for both
clue-protocol and clue-signaling so that should be in your mailbox.

Adam: I thought Martin had cleared the registration of these but I'll go back
and find that mail to make sure you were copied on it. These just need to have
responses from the authors before we can move forward.

Amy: Sound like its going to be IESG evaluation, Revised ID needed for this
document.

Adam: Yes, that's almost certainly correct.

 o draft-ietf-clue-signaling-14  - IETF stream
   Session Signaling for Controlling Multiple Streams for Telepresence
   (CLUE) (Proposed Standard)
   Token: Adam Roach

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

Adam: I just want to ask Benjamin: What action do you expect to be taken here
to clear the discuss? Do you want to see a new version of the document that
says .8.4.x and has IANA assign it manually or do you want some clearance from
IANA that this code point is cleared for use, or what?

Benjamin: Either of those would be fine.

Adam: Okay. Given that the other comments are probably going to require a new
revised ID, we can probably go for the first one. If not, I'll ask for
confirmation from Michelle the code point is available.

Benjamin: Sure. I don't want us to be in the position of granting IESG approval
of a document that is doing something that we don't want people to do.

Adam: That makes sense. Thank you.

Amy: Sounds like this one is also going in substate of Revised ID Needed.

Adam: That's right.

 o draft-ietf-oauth-token-exchange-16  - IETF stream
   OAuth 2.0 Token Exchange (Proposed Standard)
   Token: Eric Rescorla

Amy: I have a consensus as Unknown. I thought these automatically went to Yes.

Ekr: I didn't intentionally make it not Yes. Feel free to flip it to Yes.

Amy: It could be that it's just been around long enough it didn't catch at that
point. We will put that as a yes for you. I have a few discusses in the
tracker; do we need to discuss?

Ekr: I was just reviewing them and I don't think so. Two of them are
straightforward and one may be more complicated, Benjamin's, but I don't see a
response to Benjamin's. Let's give them a chance to respond.

Benjamin: I just put it in the Datatracker recently.

Adam: I'll point out the main author on this is on holiday all week so it may
be a little bit of time.

Ekr: We can move on.

Amy: Sounds like these need a Revised ID. Thank you.

 o draft-ietf-ipsecme-split-dns-14  - IETF stream
   Split DNS Configuration for IKEv2 (Proposed Standard)
   Token: Eric Rescorla

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

Ekr: I think it would be good to discuss Warren's. He might be on to something
important here. This may actually be something we wish to push. The essential
property of this technology is as you say that your VPN gets to more or less
dictate which DNS it wants you to query it for. That means at minimum it lets
you override DNS responses and maximally you'll notice it lets you override
TLSA responses. This text here was intended as a compromise, in a sense. I was
informed by the WG that it was super important to be able to do this and DNSSEC
wouldn't work otherwise. This was an attempt to compromise on that. I never
felt that awesome about it but I felt it was a WG decision and not mine to
override. You may feel differently and I'm certainly happy to continue the
discussion.

Warren: What terrifies me is that this could easily be used by the --  There
are a lot of very cheap VPN providers designed for things like torrents, and
having them have the ability to override DNSSEC responses seems scary. The
authors claim that users should be able to figure this out. And it should make
a pop up thing saying 'Do you want to allow this to override your DNSSEC trust
anchor?' I don't know if users will understand that. What do other people
think? Are other people freaked out by this?

EKR: I'm still kind of freaked out about it but concluded people probably
weren't going to do it. I concluded browsers weren't going to do it. This is a
real philosophical issue. I'm never sure how to deal with these.

Warren: I'm happy to continue the discussion with Paul, and hopefully the rest
of the WG chimes in. If it sounds like they've thought it through and there's a
WG discussion and decision, I guess I'll double check with DNSOP to see if
people there are freaked out there.

Ekr: Can you do that please, definitely? I want to hear from people in the IESG
too, if people are bothered.

Ted: I think Warren's discussion of whether or not you could present a 'this
changes your DNS trust anchor, proceed yes/no' and get anything useful out of
the average user. My suspicion is that would not end well for anyone. I think
the real question is, are you willing to do this knowing that informed user
consent is likely not obtainable? That does raise all of the issues both of you
have been concerned about.

Benjamin: I think in some of the side discussions we've had, the case of
individual end user, explicit consent was not as important as for a corporate
managed device where you already have a configuration management set up and you
can push this whitelist through the normal corporate device configuration.

Ted: The problem with that turns out to be that a very large number of what
people consider to be corporate devices are actually bring-your-own devices
that are subscribed to a corporate service as part of it. So you have an
android device which has enterprise management turned on so you can reach
enterprise resources. That turns out to mean that it can be turned on by the
enterprise at times you are not connecting to enterprise resources. Reversing
this so the only thing they can affect is the trust anchors for the explicitly
configured enterprise resources would be a better design but it's very
difficult to get right because of the way the trust anchor chains up. You'd
have to go back to the look-aside trust anchor at the enterprise level.

Warren: One thing that makes me slightly less worried is most of the "pay $2.99
and get your cheap VPN here" install stuff in the OS anyway and requires admin
privileges to do that. If it were done by somebody malicious, they have other
ways to do similar sorts of things. They could just add stuff to the trust
store themselves through the installer. Bad folks potentially already have a
way to do this badness and they might not want to implement this extra
complexity to get the badness.

Ted: But the problem is people are using the DNS as as second source of truth.
If you're taking away their second source of truth through this, their ability
to detect the other one goes way down.

Alissa: One note on the text about human interaction: I didn't read that to be
implying a choice. This doesn't help the situation. But I thought the idea of
this was not that you're going to be able to distinguish which domains should
or should not be on the whitelist, but there's going to be some notification
that this is happening, which is different from expecting people to make a
choice. I read that and thought about that a little bit. I don't think it
actually implies a choice.

Ekr: It sounds like there are a number of people concerned here and maybe we
can continue this discussion at the next informal. And Warren, can you talk to
DNSOP? I appreciate you raising this and there will be no hard feelings if the
IESG says we made a mistake and we should not do this.

Warren: I don't think it would be a mistake, just a difference of opinion. I'll
chat with DNSOP.

Amy: It sounds like this is going to require a Revised ID?

Ekr: At least. Is there a state that's like 'major discussion needed?'

Amy: Revised ID Needed and we'll move on.

 o draft-ietf-ntp-mac-05  - IETF stream
   Message Authentication Code for the Network Time Protocol (Proposed
   Standard)
   Token: Suresh Krishnan

Amy: There are no open positions or active discusses so unless there's an
objection, it looks like this is approved.

Suresh: Can you please put it in Point Raised? There are some text changes
required but I want the authors to respond first. I pinged them to make sure
IESG comments get addressed. Put it in Point Raised.

 o draft-ietf-isis-reverse-metric-16  - IETF stream
   IS-IS Routing with Reverse Metric (Proposed Standard)
   Token: Alvaro Retana

Amy: I have an open position for Ace. Ace, did you want to state a position?

Warren: Nope, sorry.

Amy: Okay. There are no discusses so unless there's an objection, it looks like
this is approved.

Alvaro: We're going to need a Revised ID for this one. Thank you.

 o draft-ietf-cbor-cddl-06  - IETF stream
   Concise data definition language (CDDL): a notational convention to
   express CBOR and JSON data structures (Proposed Standard)
   Token: Alexey Melnikov

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

Alexey: I don't think so. Ekr, do you think we need to discuss it? I think the
discussion is happening on the list.

Ekr: I think the discussion is happening on the list. I do want to note that I
found this document extremely hard to read. There does not seem to be a Discuss
position for 'this document needs a rewrite.' I think we'll get there. I'm
really attempting to make sure I understand everything.

Alexey: I think that's fair. This is definitely Revised ID Needed.

 o draft-ietf-dnsop-dns-capture-format-08  - IETF stream
   C-DNS: A DNS Packet Capture Format (Proposed Standard)
   Token: Warren Kumari

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

Warren: I think so, if possible. Benjamin's right; when I saw his Discuss I
thought that's a really good point. Thanks for noting that. I think he authors
will do a good job of addressing it; I believe the authors take privacy
seriously. I don't know if we want to put it in Approved for now and make sure
they address the privacy issues promptly. I think it's mainly Benjamin's now
and it's a good one.

Benjamin: They sent mail this morning that seemed very good but I haven't read
it in detail yet, but I think it's on the right track.

Warren: I also thought it looked good but haven't digested. What's the right
thing?

Benjamin: I think we just have to wait.

Amy: You can't go to Approved until all the Discusses are cleared, so we'll
stay in IESG evaluation.

Alexey: Can we quickly talk about the normative reference to the PCAP document?
Are we okay with that?

Warren: It's not actually a normative reference to a PCAP document, it's
currently a normative reference to a website. But PCAP is used in a lot of
places and is a relatively well understood format. There was an attempt to
publish it through DNSOP. I don't know what we do with that.

Alexey: This specific thing is about filter. Filtering information can be
extracted and put in the document, which would be my preference. If people
think referencing a website is fine normatively I can let go of this.

Warren: In general normatively referencing a website makes me twitch, but
because this is well known and it's such a common thing at this point I don't
know if I'm that twitchy about it.

Alexey: Is the webpage going to be stable enough?

Ekr: Supposing a new keyword were added to the PCAP filter language, then you
might have a situation where it wouldn't be clear which version of these
documents you referenced. There's no way to snapshot this, is there?

Warren: I guess they could say, tcpdump as of 2018, but that seems fraught with
danger. Anybody have any suggestions?

Alexey: Cut and pasting the filter definition would be the simplest way.

Warren: Doesn't that cover...[crosstalk]

Adam: It's very complex.

Warren: I would think that would require all the BPF type stuff to be
referenced, wouldn't it? Which is massive and huge.

Alexey: So it doesn't look like it's necessarily stable. It's not going to go
down but it might change over time.

Warren: Seeing as this is an optional thing, I wonder if it could be
informative instead.

Alexey: No, it can't.

Warren: I figured you were going to say that.

Alexey: It's optional to include by some, but somebody needs to watch that
[crosstalk]

Warren: Yeah, you're right.

Alissa: What about the snapshot idea? We could snapshot this and stick it
someplace as a stable URL.

Benjamin: License - Are we allowed to do that?

Ekr: It's probably a Berkeley license. We could shove it on the IETF website
somewhere.

Adam: The documentation also?

Ekr: I don't know. You know, we run into this problem reasonably often. I
wonder if it would be useful to have an IETF archival thing, which is here are
some things you might depend on we've snapshotted so you can reference.

Adam: Or would it be okay to rely on archive.org?

Ekr: It would be okay with me. We have this problem with websites in Github and
stuff like that too. I know people worry  about even referencing GitHub.

Warren: I guess we can check with Heather if she has any brilliant ideas.
Sticking a copy on the IETF website feels janky but less janky than the current
solution. Let me take a note to try and talk to Heather and hold the Discuss
for now, we'll see if we can figure something out. Thank you.

 o draft-ietf-stir-passport-shaken-05  - IETF stream
   PASSporT SHAKEN Extension (SHAKEN) (Proposed Standard)
   Token: Adam Roach

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

Adam: I have a couple of comments. Benjamin, I'm going to work with Chris and
the other people who have been working with ATIS to see if we can get written
permission, because the alternative is making this document into something
that's relatively unreadable or possibly out of sync. Does that sound like a
reasonable path to you as well?

Benjamin: That sounds wonderful to me. I'm not super happy about being
copyright cop.

Adam: This is a good catch. Thanks for noticing that.  To Ekr's point, I'd like
to hear back from the WG on this. Oddly enough, there have been responses on
things that weren't the Discuss, but not on the discuss itself yet. I do want
to ask -- you said something about potentially needing something longer than a
UUID?

Ekr: The typical property you want to have here is you have a token issued by 
the originator and map back to some data structure. One way you do that is to
generate a random identifier and use it as a lookup table. The other is to have
a static symmetric key which you then use to encrypt a data structure to
yourself which doesn't require a lookup table. Generally those data structures
are larger than 128 bits. So you wouldn't be able to format.

Adam: That makes sense, thanks. So in terms of procedurally, we're almost
certainly going to need a Revised ID. I will wait to hear back from the WG
about what they want to do regarding the identifiers. We're kind of limited as
to what we can do here because the ATIS document is already published, but I
think it does allow for doing things. In a way that would preserve privacy, so
we might be able to restrict it further here.

Benjamin: I'm not super familiar with their versions of normative language and
what is mandatory and what is suggestion. It sounded like you weren't required
to use the UUID; you could use a different structure.

Ekr: There is a version of this which is compatible with UUID.

Adam: I suspect that's what they have in mind.

Amy: It sounds like that is going to require a Revised ID. We will move on.

 o draft-ietf-dmarc-rfc7601bis-04  - IETF stream
   Message Header Field for Indicating Message Authentication Status
   (Proposed Standard)
   Token: Alexey Melnikov

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

Alexey: Possibly. Ben and Benjamin, you are effectively talking about the same
thing, just different aspects of it. Is that accurate?

Benjamin: I think so.

Ben: I think so.

Alexey: So I think the document basically needs to be updated for registration
of various items hat were deleted and say it obsoletes the original. I think
that's the simplest way. If the WG decides another way there are other changes
that need to be done. I think this is Revised ID Needed.

2.1.2 Returning items

 NONE

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-dmarc-arc-protocol-21  - IETF stream
   Authenticated Received Chain (ARC) Protocol (Experimental)
   Token: Alexey Melnikov

Amy: I have no discusses in the tracker; Unless there's an objection this is
approved.

Alexey: Can I have this in Point raised? I think there are some very good
comments, including from Ekr, I want the authors to respond.

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

3.4.3 For action

 NONE

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

 NONE

4.1.2 Proposed for approval

 NONE

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o Domain-based Message Authentication, Reporting & Conformance (dmarc)

Amy: I have no blocking comments and it looks like it does need to go for
external review.

Alexey: Let's do that just to be safe, considering the language about EAI I
want to make sure it's announced.

Amy: Unless there's an objection it looks like the WG review recharter
announcement can go out and we will put this back on the agenda for approval
for the next telechat which is December 6.

 o Hypertext Transfer Protocol (httpbis)

Amy: This looks like it also has to go for external review.

Alexey: Yes please. There's one minor point about what is included in the core
list of documents and I'm just double checking with the chairs about which
range of RFCs it is. What I have in the current text is the most conservative
version so I think it's fine for external review. I believe I addressed Ben's
and other comments about what exactly is in the core set.

Amy: Okay, so unless there's an objection it looks like the review recharter
announcement can go out.

4.2.2 Proposed for approval

 o Managed Incident Lightweight Exchange (mile)

Amy: I have no blocking comments so unless there's an objection now it looks
like the recharter is approved.

Benjamin: I think it needs to be in the 'wait for Alexey to tell you to approve
it' state.

Amy: You think it needs edits?

Alexey: I think I addressed Spencer and Benjamin's comments.

Benjamin: Oh, there's an -05 now. I missed that; my apologies. I retract my
comment about needing your approval.

Amy: Okay, it sounds like MILE is approved, and we will get that recharter
announcement sent.

5. IAB news we can use

Amy: I don't think the IAB has met since we've all seen each other in Bangkok.
Deborah, any news maybe from the mailing list?

Deborah: None from their mailing list. As you all know, on the IETF list
there's quite a discussion going on you can all see. They meet later today.

6. Management issues

6.1 Designated Experts for the draft-ietf-isis-reverse-metric (Alvaro Retana)

Alvaro: Yes, that was the document we just approved earlier today. Unless
anyone objects I'd like to add those three guys to the registry.

Amy: So unless there's an objection we will name Christian Hopps, Les Ginsberg,
and Hannes Gredler as the designated experts for this registry?

Amy: Sounds like they are approved and we will send the official note to IANA.

6.2 Extending Last Calls around/during IETF Meetings (Secretariat)

Amy: We had a small discussion with a couple of you in Bangkok. Our proposal is
that we would automatically extend any Last Call that would normally end during
the IETF meeting to a week after the meeting ends. I don't know if you want to
extend that so any Last Call that would end the week before the meeting would
also end a week after the meeting.

Ben: One case this might miss is when we have a non-WG draft with a 4 week last
call that crosses the IETF meeting week but still goes beyond the following
week. What I've typically done for anything that crosses the IETF week I don't
count that week and make it go five weeks. I don't know if other people do it
but the way I do it, there are a few cases that wouldn't be caught by this.

Alissa: I'm not sure this lends itself to a uniform solution. I think it's our
responsibility to pay attention to this and we should tell you case by case
what the end date we want is. Sometimes the November meeting is going to be the
week before a large holiday in some countries. This isn't going to catch every
case no matter what we set it to. It seems better for us to be paying attention.

Spencer: I just saw Benjamin said what I usually do which is assume people are
no more coherent the week after IETF than they are during IETF and add 2 weeks.
I think having us do the right thing, whatever that turns out to be, makes more
sense than trying to automate it.

Benjamin: Is Alissa's proposal that when we go into the datatracker to the
request publication button we can't use a shortcut button we have to add a
comment  saying 'please actually end this last call at whatever date'.

Amy: That may not actually send email to the secretariat.

Alissa: I've edited the Last Call announcement before.

Amy: We look at the Last Call announcement and if that date has been edited in
any way we go with the edit. Then you save the text and push the request Last
Call button and we'll get a ticket.

Warren: That sounds reasonable but I know I will manage to forget that. Perhaps
the Secretariat notices the Last Call is going to hit during a meeting and they
also send us email?

Ben: I notice the last paragraph of the management item points out they'd
rather not have to do that.

Adam: I read that they don't want to ask and wait for an answer, but a reminder
to ask them --- would that be the same objection?

Warren: But by then the IETF last call has started, right?

Adam: You have a good point.

Warren: What about as an option, the default is that it ends after, and if we
want to change it then we change the last call date? Or are we over-engineering
this?

Amy: When possible, we'd prefer to have a standard rule to follow a procedure.
If the last call ends during the meeting, we automatically make it a week or
two weeks after the meeting. A standard rule is always going to better.

Benjamin: the proposal by the Secretariat is an improvement over what we have
now and still gives ADs the option to change things if we want.

Spencer: I think what we're saying is the suggestion from the Secretariat is
more likely to be right than we are.

Warren: Does anybody object to that?

Amy: Okay, we will still pay attention to whatever you put in the Last Call
announcement, but we will automatically extend last calls in a meeting week for
at least one week.

6.3 Secondary expert for the Personal Assertion Token (PASSporT) Extensions
registry (Adam Roach)

Amy: Any objection to confirming Russ Housley as secondary expert?  Hearing no
objection, we will send official note to IANA.

6.4 IESG appointment to the IETF Trust (Alissa Cooper)

Alissa: We need to do one appointment to the IETF Trust. I put the proposed
announcement on the wiki. It has dates and a timeline there as well. Wondering
if people have any feedback on this. I proposed to send this next week but if
everyone's cool with it we can send it this week and get an extra week. Do
people need more time to look at this? Should I bring it back next week or are
people comfortable sending it today?

Warren Sounds ok.

Adam: Skimmed it and it looks good to me. December 21 seems like a good day to
end this? That gives us about a month from today.

Alissa: Yes, I think starting it today would be best.

Ekr: Are we going to have a race condition like we had with the IAOC?

Alissa: That's what the last line is about. We can do our deliberations and end
up with a rank ordered list if we have enough candidates, and then wait until
the NomCom announces so they don't have to wait for us.

Ekr: That seems like a reasonable outcome.

Adam: I think the conversation we had in the Nomcom was that the IESG appoint
first. Can I have you hold off for a couple of hours so I can square this with
Scott?

Alissa: I don't think it matters. They are very busy and I though it might
complicate things for them to have to wait for us. It doesn't really matter who
goes first as long as no one's waiting for each other.

Adam: I'll double check this and run it by Scott.

Alissa: Sure. I'll wait for an email from you.

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

Amy: Any other business? Hearing none, we will end.