Narrative Minutes interim-2022-iesg-22 2022-10-06 14:00
narrative-minutes-interim-2022-iesg-22-202210061400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2022-10-06 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Andrew Alston (Liquid Intelligent Technologies) /  Routing Area
Jenny Bui (AMS) / IETF Secretariat
Jay Daley / IETF Executive Director
Roman Danyliw (CERT/SEI) / Security Area
Martin Duke (Google) / Transport Area
Lars Eggert (NetApp) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Erik Kline (Aalyria Technologies) / Internet Area
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Colin Perkins (University of Glasgow) / IRTF Chair
Alvaro Retana (Futurewei Technologies) / Routing Area
Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area
John Scudder (Juniper) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
Amy Vezza (AMS) / IETF Secretariat
Éric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area
Paul Wouters (Aiven) /  Security Area
Qin Wu (Huawei) / IAB Liaison

REGRETS
---------------------------------
Murray Kucherawy (Facebook) / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Francesca Palombini (Ericsson) / Applications and Real-Time Area

OBSERVERS
---------------------------------
Lee-Berkeley Shaw
Ketan Talulikar

1.2 Bash the agenda

Amy: An executive session has been added to the end of the agenda. Also, the
independent stream document that was on the agenda for discussion has been
pushed to the next telechat to give more time to review. Any other changes?

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes from the September 22
telechat being approved? I'm hearing no objection, so it looks like those are
approved. I saw final narrative minutes; any objection to approving those?
Hearing no objection, so those are also approved. As a reminder, the BoF call
minutes have been out for about a week and we will take the approval of those
on the 20th.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

     o Roman Danyliw to find designated experts for RFC 8809 (WebAuthn)
       [IANA #1229681].

Roman: In progress.

     o Paul Wouters to find designated experts for RFC 9200 (ACE-OAuth)
       [IANA #1239251].
     o Paul Wouters to find designated experts for RFC 9203 (The (OSCORE)
       Profile of the (ACE) Framework) [IANA #1239258].
     o Paul Wouters to find designated experts for RFC 9237 (An
       Authorization Information Format (AIF) for Authentication and
       Authorization for Constrained Environments (ACE))[IANA #1239259]].

Paul: [These three are all] in progress.

   * OPEN ACTION ITEMS

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

Amy: On hold.

Éric V: As far as I know the Covid impact was measured on numbers of -00
[drafts], but it looks like we have less and less documents coming for IESG
evaluation after one or two years. Should this also be part of the statistics?

Warren: I think it is one of the charts we've shown.

Amy: The numbers are all based on mailing list activity. I'm not sure what we
could pull from the Datatracker to talk about [this].

Warren: I could have sworn we'd also seen pretty graphs with numbers about this.

Amy: Yes, that's from the mailing list activity. Anything that's a -00 draft
that gets announced, that's the number that's pulled. But coming in front of
the IESG, documents maturing to that point, is not part of that activity.

Warren: What about just documents showing up on the last-call list? It's not
quite in front of the IESG.

Éric V: You also have an approved one that is sent to ietf-announce. I don't
want to put on too much work but with three years on the IESG, I see way
[fewer] documents in the last few months than two years ago.

Warren: We also have the RFC Editor stats, I'm just finding them. Things
entering the RFC Editor state are the same as once we hit approved, which will
cover a fair bit of it.

Amy: You had a couple of big clusters sit and wait for a while before they're
all released at the same time. I don't know how useful --

Éric V: But it's entering the queue at the same time, right? The cluster
doesn't influence the entering of the queue.

Warren: Even if the data's not perfect, it still is a good rough thing. I know
this data does exist.

Amy: Okay, if you find it, please share it with the crowd.

Sandy: If there is specific information you want, just let us know and we can
provide it. We do have the dates that the documents enter the queue, even if
they're going into misref first, we have the date marked form when they are
approved. That's information we can easily provide to you.

Warren: Thank you. I know I've also seen a chart or graph somewhere on the RFC
Editor page. If you happen to come across those…

Sandy: I can send you the link.

Amy: Great. We'll see what we can use from that to see the trend for documents
entering the queue.

     o IANA to report back on CoAP Content-Format for application/tm+json.

Sabrina: We forwarded the response from the expert to you all on Tuesday. The
expert basically said that he thought it makes sense to allocate the next code
point since the media types are closely related. We just need to know if you
think the relationship between these two media types means we should assign 443
from the IESG approval space. If not, should we just assign one from the first
come first served range? The expert said that is okay as well. That's where we
are at right now.

Amy: Does anyone have an opinion?

Warren: That sounds great to me.

Amy: Is there any objection to assigning the one that's near the one they
wanted?

Warren: IANA usually knows what they are doing and I see no downsides, so why
should we fuss?

John: I want someone more informed than me to comment on this but I don't have
a problem with going with this recommendation.

Amy: So it sounds like the IESG is approving assigning a code point from the
IESG approval space, not the first come first served space? I'm seeing shrugs.

John: Is "shrug" a valid response?

Amy: Well, I'm hearing that assigning the code point is approved, and we'll
send an official note to IANA.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-lsr-flex-algo-24  - IETF stream
   IGP Flexible Algorithm (Proposed Standard)
   Token: John Scudder

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

John: We will need a new revision.

Amy: Okay, this will go into Approved, Announcement to be Sent, Revised ID
Needed. You can let us know when that is ready.

 o draft-ietf-lsr-pce-discovery-security-support-11  - IETF stream
   IGP extension for PCEP security capability support in PCE discovery
   (Proposed Standard)
   Token: John Scudder

Amy: I do have a couple of Discusses for this document; do we need to discuss
either of these today?

John: Yes please. I think we have Discusses from Lars and Rob, and the authors
updated their working copy to address your points. Last I looked it seemed like
their update was reasonable, so please have a look. I don't think they've
pushed -12 yet, so maybe we can ask them to push that and then you can clear if
you're okay with it.

Lars: That seems fine. I haven't had a chance to look at the text they proposed
but I followed the discussion that started yesterday and it seemed to go in the
right direction.

Rob: I'll check. I don't recall if my Discuss was a strong Discuss.

John: I can't remember what your point was but I do remember chatting with them
about it and I think they took it on board. Thanks to both of you.

Amy: All right, then it sounds like we're going to get a new revision.

 o draft-uberti-rtcweb-rfc8829bis-03  - IETF stream
   JavaScript Session Establishment Protocol (JSEP) (Proposed Standard)
   Token: Murray Kucherawy

Amy: I have no Discusses in the tracker, so unless there's an objection it
looks like this one is approved. Since Murray isn't with us today, we'll put
this in AD Followup for him.

 o draft-ietf-lsr-ospf-bfd-strict-mode-09  - IETF stream
   OSPF BFD Strict-Mode (Proposed Standard)
   Token: John Scudder

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

John: Can you put this in AD Followup so I can just make sure there are no
revisions needed?

Amy: Certainly, just let us know when you're satisfied.

 o draft-ietf-dots-robust-blocks-05  - IETF stream
   Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
   Channel Configuration Attributes for Robust Block Transmission
   (Proposed Standard)
   Token: Paul Wouters

Amy: I have no Discusses in the tracker, so unless there's an objection it
looks like this one is approved. I do see we have IANA experts here for the
registries in the document, so that's great. Are there any notes needed?

Paul: Please put it in AD Followup, I just want to make sure the comments are
addressed.

 o draft-ietf-lsr-ospf-reverse-metric-08  - IETF stream
   OSPF Reverse Metric (Proposed Standard)
   Token: John Scudder

Amy: I do have a number of Discusses for this document; do we need to discuss
any of these today?

John: I don't think so; it seems like this is taking place in email already. If
anyone who has a Discuss wants to talk about it, please go ahead. [silence]

Amy: It kind of seems like this might require a revision?

John: Yes.

Amy: Okay, then this will stay in IESG Evaluation, Revised ID Needed.

 o draft-ietf-lsr-ospf-l2bundles-07  - IETF stream
   Advertising Layer 2 Bundle Member Link Attributes in OSPF (Proposed
   Standard)
   Token: John Scudder

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

John: Please put it in AD Followup. Thanks for all the LSR-ing this week,
everybody.

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

 NONE

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
3.4.2 Returning items

 NONE

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

 o Application-aware Networking (apn)

Amy: Andrew is shepherding this chartering effort. I have a number of blocks to
this charter; do we need to discuss some of that?

Andrew: I've sent all of this back to the mailing list and said these are all
the current blocking positions, I need you to now come up with suggestions. Iw
ant to see that they're going to be doing the work before we go ahead and
charter this. I have certain misgivings. I'm waiting to see what comes back
from them and then I'll submit a revision.

Amy: Did you want to keep this on the agenda to talk about next time, or would
you like it to come off?

Andrew: Let's leave it on the agenda for next time, because if there isn't a
revision then we can figure out what to do with their meeting slot. If there
is, we can then talk about it. So let's leave it on the agenda.

Amy: Okay, we will update the date to come back next time on October 20.

Alvaro: Just a quick comment. Even if we move it to next time, for approval of
the external review, are we going to have time to approve it before IETF? I
think we don't, right?

Andrew: No we don't, but I think we said we'd have some kind of preliminary
meeting if they managed to actually get this to a point where we were properly
proceeding. Whereas if I see absolutely nothing on the list coming back, I'm
going to think about withdrawing.

Alvaro: I guess my point is, if we're not approving it, this will become sort
of a bof slot.

Andrew: Yes, then we could make it a BOF slot. It was originally scheduled as a
preliminary bof anyway.

Alvaro: I'm just making sure we're not asking Liz to deconflict this as a BOF
later because it already conflicts with other stuff.

Andrew: I have a fair number of conflicts there anyway.

Rob: Would it be fair to the proponents if this moved to a BOF? With the
two-BOF limit, will they have had time to prepare or is this just going to go
the same way as their last BOF? Maybe they want to do it anyway, but I just
want to make sure we give them a fair opportunity here.

Alvaro: It would be good for them to know that if they don't do anything before
the next call, meaning if this doesn't go into external review within the next
week, for example, they really don't have a chance to get to be a WG by the
IETF.

John: I think Erik's comment in slack is well taken. They can always schedule a
side meeting like everybody else.

Alvaro: Right. They just need to know this is going to happen, is what I mean.

Andrew: I'll send something to the list to that effect.

Éric V: I don't follow the mailing list, but was there any comment on the
blocks?

Andrew: I haven't seen anything on the routing area WG list. There has been
only one comment on the APN list and my reading of it is "why are we doing
this?" or "should we be doing this?"

Amy: We'll continue to keep this on the October 20 agenda. Let's move on.

4.1.2 Proposed for approval

 o Supply Chain Integrity, Transparency, and Trust (scitt)

Amy: Roman is shepherding this chartering effort. It looks like I have a block;
do we need to discuss that today?

Roman: Sure, I did want to talk a little bit about this and ask a couple of
clarifying questions on the non-blocking comments. First, I wanted to start
with the block from Paul. I roughly sent a note, because I think there was a
datatracker hiccup where mail wasn't sent so I started a new thread. Paul, can
you explain what it is that we'd need to clarify here at chartering time vs at
WG time? From my perspective these are good questions to discuss, like what
implementation choices the wg would want, and the operational incentives, makes
sense. But to charter, I didn't see personally that we would need to resolve
that right now. Can you talk me through it?

Paul: My view was that depending on the incentives of running this, if there's
no incentive to run it, then it doesn't really matter what the WG will produce
RFC wise because it will just get ignored. I wanted to make sure we're not
starting to do a lot of work and then in the end there's no way of getting it
deployed. That was my main concern; I wasn't sure if this is really
decentralized to different vendors, I can see how each of these vendors
shipping things have an incentive of publishing this data so they'll pay for
the hosting to do it. But at that point I also question whether it's still a
useful concept because you're trusting the vendor to publish something. If it's
not tied to the vendor and you're doing it really decentralized, there must be
some incentive for someone to publish this. If they don't, it doesn't really
matter that we standardize the formats and everything if no one will run this.

Roman: I think there are a number of open questions at what level in the
architecture and at what level of the supply chain you're talking about
decentralization. How many of them will it be, is it down to vendors, is it
groupings of vendors, is it a particular subvertical in software, is it going
to be driven and required by policy….I don't know. I think that's a further
conversation. The way I would answer is, is something going to run it? I answer
with the overwhelming enthusiasm that we had at the BOF with companies saying
they want this, they want this approach, and the sheer energy we've had since
the BOF continuing to refine our understanding of it. So what are the
incentives to run it? I don't know if i can be very specific just now, because
that's going to be the work of the wg and refining what's in the architecture,
so it's kind of TBD in some way. Unless you think there's some kind of
architectural element we want to have up front. There's an architecture
document and this is going to be the substance of my comments later on the
non-blocking, they roughly put this notional thing up but it's going to be
refined, no question.

Paul: We can take this offline. I guess I'm still a little bit confused about
what part is the actual work the WG is doing and which is are the starting
points there to actually do this work?

Roman: Let's back up. The only place where the charter talks about
decentralized structure is saying there's a gap. It's saying there is no global
decentralized thing. The rest of the charter doesn't even talk about that. I'm
wondering why we're picking at this particular thing when there is so much
still to be decided. If you want that problem of the ecosystem removed, if the
work continues to stand on its own by removing that, there's no talk about that
in the charter. There's also no talk about merkel trees, which also seems like
a very specific implementation choice.

Paul: I guess I just had a merkel tree instead of a blockchain. So, maybe let's
take this offline and talk after the meeting. I'm not trying to block the work,
I think the work is good. I'm just trying to make sure there are no unsolvable
problems before we start so we don't waste time.

Roman: The unsolvable problem is that the WG would come to some technical
agreement and then no one would want it? But they also came to the WG anyway to
specify it? This is a case where we have actual vendors who are in this supply
chain kind of business and want this. And they also said at the BOF, we had a
list of 10-15 companies saying they will implement it. I'm not sure what the
threshold is.

Paul: My idea was that it's so decentralized that even if these people are
happy to use the infrastructure and put their data there, who runs the
infrastructure? Normally in these decentralized ways there are miners who make
money by running this. What is the incentive for these decentralized structures
to run all of this to help people publish their integrity check?

Warren: It feels like this is outside the charter for this. Whether someone is
actually going to run it is the first thing. Secondly, there are a fair number
of non-bitcoin or non-mining based merkel trees, blockchains, whatever you want
to call them, that a lot of industries are publishing in already. One is the
coffee market, which is really large and distributed. There are also things
like certificate transparency, which is basically the same thing. It's a merkel
tree that a bunch of people run logs for. Running a chain is not expensive, so
if people want to use this thing it seems strange to me that we would say no
we're not going to form a wg because we're not sure if somebody is going to run
the needed infrastructure when there are a bunch of people who say they want to
use it and will build the infrastructure.

Paul: I think it's a little different from giving them the tools to do the job.
I guess my fundamental question remains: yes, I understand that a software
vendor is happy to do this. But then if they're the only ones who are using it,
then they will be the ones that end up running, like, a vendor starts running a
decentralized merkel tree for this, the question becomes what is the game for
it being a merkel tree instead of just a scientist of software updates from
that vendor. If it's an inter-vendor or a vendor-neutral thing then it should
be run by not a vendor, right?

Warren: I would like to know that the software I'm getting from Debian is
something that had been set by them and if I looked six months ago, I can see
it's the same software. Even if it's just run by one company, it's really
useful. Take The Juniper netscreen issue, for example, where the software had
been modified after being placed on one of the cases.

Paul: I agree that it's useful, but that can just be done by a key in the
signature from the vendor. That's not what this WG is attempting to do.

Warren: No, it can't. I don't know that they didn't go back and update the
signature four months ago. They could publish a version, they could publish a
new version, and then it turns out the first version had a massive bug. We'll
just sign another one. But that's way down in the details.

Paul: Okay. if people think this is too mad, then I'm happy to remove my block
on it. I thought maybe the charter could clarify a little bit what the
incentive is for people to do it this way and not have a list of signatures and
keys.

Roman: I personally think asking charter text to describe incentives for their
work beyond interest in adoption, that's a different bar than we use for other
work. That's not the universal bar.

Paul: Okay. Thanks for this discussion; I'll remove my block.

Roman: Thanks. The other piece I wanted to add, in no particular order, is
Éric, you were saying something that is focused on software is not clear
enough. It's in the third sentence now. The first sentence says "This is a
mechanism," the second sentence is an example of it being software, and then
the third sentence explicitly states "software only." It's got to happen sooner?

Éric V: I appreciate that you changed the last sentence. It's mostly a nit, but
I suggest you do it in the first sentence as well. Just a word.

Roman: I appreciate that clarity. Thank you. Then I think we'll still make a
little bit of an edit based on the other comments so pending Paul's
deliberation there will also be an -04 for this regardless.

Éric V: The most important comment in my mind is this: "SCITT will initially
focus" keeps the door open to other work.

Roman: I'll remove "initially."

Éric V: Super, thank you.

Amy: So this is approved pending edits and we're waiting for you, Roman.

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

Warren: Not a huge amount of news other than the fact that the IAB is working
on a workshop proposal for IDR to address problems in BGP and a workshop to
have discussion about addressing a bunch of problems listed in the problem
statement. Which includes BGP security, code complexity, stability, etc. I
think that's mostly of interest to the routing ADs. This is early days and the
IAB is noodling on it, primarily Russ White. There's discussion on not
necessarily replacing BGP, but not continuing to add incremental fixes to the
side.

John: I was not aware they were going to do a workshop on hats and I'd be
interested if there are any links you can point me to.

Alvaro: Just for the record, I'm officially aware because Russ told me. If this
is being done for IDR, it would be great if IDR knew. That doesn't mean just me.

Warren: Again, it's early days. It's called IDR Workshop. There's the problem
statement which I could have sworn Russ said he'd sent to John, but maybe it's
a different John, and a proposal. The Routing ADs should at least be aware of
it.

Alvaro: He sent it to me, and Tony P, and some other people. I'll forward it to
you, John.

Warren: I also dropped the link in slack.

John: Thank you. It's possible he sent it to me too and I just missed it.

Warren: there is also still a document underway to comment on the trade
regulations rule on commercial surveillance and data security. I think those
are the main things.

Amy: Thank you. While we're speaking about the IAB, I hope everyone saw the
email from Cindy about the IAB wanting the Sunday afternoon slot in London to
facilitate their folks who will be remote. If you have a strong opinion about
the IESG meeting in the morning or the afternoon please respond to that message.

Lars: I wanted to check if we have any ADs who are going to be remote? We
haven't really talked about it.

Amy: There are only two who have not yet registered, Francesca and Roman.

Roman: Sorry, I don't have my administrative processes in order. I'm going to
be in person; morning or afternoon don't really matter to me.

Warren: I always have the IEPG meeting in the morning, but I Don't really have
to be there and it doesn't really matter.

Lars: You're also IAB liaison so you'd lose the morning anyway. Then they can
have what they want and owe us a favor.

Amy: Okay. So Sunday morning will be the IESG only, then a combined lunch and
meeting, and the IAB will take over in the afternoon. The only other question
is do you want us to provide breakfast or go to the hotel breakfast that comes
with the room and we will provide drinks?

Warren: I would think just hotel breakfast. Breakfast in the room is not cheap
and I don't think it's usually better.

Amy: It's never better than the hotel breakfast.

Lars: Let's do the hotel breakfast and I heard Jay promise an upgraded lunch.

6. Management issues

6.2 Draft statement on restricting access (Jay Daley/Lars Eggert)

Lars: Basically, you were supposed to have all read this by now. Is this ready
to go out for community input? Does anybody think it's not ready or need more
time to read it?

John: Let's get this over with.

Lars: It's in a Google document at the moment so I'll probably make it an email
and send it out to ietf-announce, is that where it goes?

Jay: There are two comments in there. Alvaro has a suggestion of something to
fix and then it's ready to go.

Lars: Okay, when you have it ready, send me a message and I'll start it. We
normally ask for direct feedback to the IESG. I'll check what we normally do
for IESG statements and do the same.

6.3 [IANA #1239154] Designated experts for RFC 8609, Content-Centric Networking
(CCNx) Messages in TLV Format (IANA)

Amy: We are looking for a designated expert for this registry. This came out of
the IRTF and Suresh did the conflict review in January of 2019. They're now
looking for someone to find designated experts. Is anybody familiar enough to
find experts? Maybe ask the IRSG? This was a number of IESGs ago.

Colin: This is a designated expert for an IRTF stream protocol?

Amy: Correct. Allison was the IRTF chair at the time.

Colin: It seems like something where we should ask the ICNRG chairs.

Lars: There's also a broader discussion here where this looks an awful lot like
standardization.

Colin: Sure.

Lars: Maybe it's time to suggest that they BOF it. Irrespective of this
registration, if they keep doing this sort of stuff that basically makes them
act like a WG then maybe they should become a WG.

Colin: We had that discussion not long ago and they're not keen on it.

Lars: I can understand that but what they're doing now is also not the greatest
solution. I guess at some point the IESG can say no to one of these and force
it, but they really should understand that if they want to do WG things they
should become a WG. I Don't want to hijack this topic.

Colin: I can find an expert if it's useful.

Lars: Is there a registration that requires an expert? Or is this basically an
expert to fill the seat but there's no registration request yet?

Sabrina: Correct. There is no registration request at this time but there was a
recent document asking for registrations and some of the RFC required
registries within the CCNX registry group. We just noticed that we didn't have
an expert for the specification required registries. We thought we'd just
submit the request now.

Lars: Thanks. If you could ask the ICNRG chairs and combine it with this and
relay that the IESG would like to have a chat about their plans for becoming a
WG, that would be helpful.

Colin: I'll do that.

Amy: Can I get a second person for this task so that it's Lars and Colin and I
can put it on the [list of IESG action items??]

Lars: Sure.

6.4 Proposed Telechat Dates Between IETF 115 and IETF 116 (Secretariat)

Amy: With all of the holidays between 115 and 116, this is the only option I
found for the telechat dates. This gives us 8 formal telechats, and we try to
have at least 7.

Éric V: There's a formal on January 5, I'm not sure how many people will be
reviewing the documents.

Amy: We've had formals on the 6th before. I didn't know if you wanted to push
off the formal for an extra week, which would be a full month after the
previous one in December.

Éric V: I guess in the worst case we don't have enough ballots.

John: I guess the way to say it would be if you want to be on the January 6
telechat, get your draft in early.

Amy: I'm hearing we should keep the one on the 5th as a formal and continue on
with the pattern until March 16. Thank you for the discussion.

6.1 IETF 115 Agenda Conflict Resolution (Liz Flynn)

The IETF 115 agenda conflict resolution was discussed.

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

No other business.

6.5 Executive Session (Lars)