IETF 105 BoF Coordination Call
11 June 2019

Reported by: Amy Vezza, IETF Secretariat 
Revised with notes from: Martin Vigoureux

Additional reference materials available at the BoF Wiki 
(https://trac.tools.ietf.org/bof/trac/).

ATTENDEES
---------------------
Alexey Melnikov (ART)
Alissa Cooper (GEN)
Alvaro Retana (RTG)
Amy Vezza (Secretariat)
Barry Leiba (ART)
Benjamin Kaduk (SEC)
Cindy Morgan (Secretariat)
Colin Perkins  (IRTF)
ƒric Vyncke (INT)
Erik Nordmark (IAB)
Ignas Bagdonas (OPS)
Magnus Westerlund (TSV)
Martin Vigoureux (RTG)
Melinda Shore (IAB)
Roman Danyliw (SEC)
Stephen Farrell (IAB)
Suresh Krishnan (INT)
Ted Hardie (IAB)
Warren Kumari (OPS)


REGRETS
Adam Roach (ART)
Brian Trammell (IAB)
Christian Huitema (IAB)
Deborah Brungard (RTG)
Jari Arkko (IAB)
Jeff Tantsura (IAB)
Liz Flynn (Secretariat)
Mark Nottingham (IAB)
Martin Thomson (IAB)
Mirja KŸhlewind (TSV)

APPLICATIONS AND REAL-TIME AREA

o Applications Using DoH (ADD)
  Responsible AD: Barry Leiba

Barry Leiba introduced the prospective ADD BoF and indicated he 
thought the proposal was solid for a BoF, but the charter was not 
ready to make this a working group.

Ted Hardie noted that his comments were late, but indicated he wasn't 
sure the BoF was the right way to handle the underlying issues. He 
added that the discussion seemed to be set to be based on operational 
questions about managing the mapping between names and addresses. The 
presumption that the network operator has a privileged position is not 
the correct impression. He added that having a BoF on session 
ticketing key management is not the right BoF, and it will set the 
proposed group up for future issues with the community.

Barry Leiba disagreed that the BoF description that network operators 
have a privileged position, rather he reads it as they have up to this 
point. He mentioned that someone from the IAB could help refine the 
BoF with the proponents to something more appropriate.

Warren Kumari agreed that he was also as conflicted as Ted, and that 
it seemed like the BoF was being driven by one vendor's deployment 
model. He also noted that the discussions around this topic will take 
place somewhere, if not the IETF.

Barry agreed it would be better to have the discussion somewhere it 
can be addressed, like the IETF.

Alissa Cooper interjected that the discussion will likely continue in 
multiple venues and there should be no effort to control it by the 
IETF. She also noted she did not think the IETF would be able to 
resolve the questions raised, but if some operational improvements can 
be made, focusing on that would be worthwhile. And not to tackle the 
policy question at all.

Ted replied that he would be happy if the BoF acknowledged that many 
parts of the network would be able to influence the mapping it would 
be a better BoF proposal, but that isn't how he read the proposed 
charter text.

There was a short discussion on whether the text of the proposed ADD 
charter supported the discussion on the mailing list, or if the 
mailing list discussion was straying too far from the topic.

Warren asked if Ted thought there was some text that could fix the 
proposed BoF to get it back on track.

Ted said he would contextualize the issues differently. That there are 
multiple ways to access the DNS, even multiple parts that access the 
DNS now. From the end users' device to applications, and different 
forms and trust relationships and sets of resolvers. When there are 
more than one offering a resolution, what best practices are available 
for choosing them? By what Ted is reading on the mailing list he does 
not want them presuming that the old ways of doing things were right, 
and the new reality needs to be addressed.

Stephen Farrell noted in the jabber room that the BoF description 
and/or charter proposal may be inflammatory as is, and he did not want 
the session to be set up as a fight from the start.

Warren agreed that it would be useful to note that there are multiple 
deployment models being discussed.

Barry asked the group if anyone was willing to help the proponents on 
refining the description.

Alissa and Stephen both volunteered.

Ted noted that while he thought waiting one more IETF cycle and aiming 
to have the BoF at IETF 106 would be a good move, he was also okay 
with holding it at IETF 105.

Barry agreed that tentatively approving the BoF was the right thing to 
do, but that the asked for time was perhaps too much. Limiting the BoF 
to 1.5 hour would likely be useful. 

There was a short discussion on whether the BoF should be focused as a 
WG-forming BoF or not, and ultimately decided non-WG-forming would 
assist the discussion of the topic, instead of focusing on the 
proposed charter text.

The ADD BoF was approved as a non-WG-forming BoF for IETF 105. 

GENERAL AREA

 o IETF Meeting Network Requirements (NETRQMTS)
   Responsible AD: Alissa Cooper

Alissa Cooper introduced the BoF topic, and noted that the discussion 
began in the NOC about what services are provided for the meeting 
networks and what services may be desired. She mentioned some of the 
mailing list discussion thought this would be more appropriate for the 
MTGVENUE WG, she said that while it relates, it is not a perfect fit, 
and having the NOC folks involved in leading the discussion would be 
beneficial.

Warren Kumari mentioned that as part of the NOC team he agreed that 
they want the feedback from the community that the team builds the 
network that the participants want. He further noted that if the 
session was held in MTGVENUE it might not get the focus needed.

Barry Leiba agreed that holding the BoF is a good idea.

Suresh Krishnan added that documenting what the community says on this 
topic is a good idea.

The proposed NETRQMTS BoF was approved for IETF 105.

INTERNET AREA

NONE

OPERATIONS AND MANAGEMENT AREA

o Media OPerationS (MOPS)
  Responsible AD: Warren Kumari

Warren Kumari began the discussion mentioning that while the BoF is an 
OPS BoF proposal, that Eric Vyncke has been the most active 
participant with the BoF proponents. 

Eric Vyncke introduced the BoF and said that it is a V6OPS type of 
group. That it is trying to attract new people from the IETF on video 
and media. He expressed concern if the BoF would attract people to it.

Warren added that the proponents have had discussions and side 
meetings at other IETF meetings and want a BoF to determine wider 
interest. He asked if anyone thought holding the BoF was a bad idea.

Colin Perkins added in the jabber chat that it would be a good idea to 
clarify the relationship to other working group technologies like AVT, 
SIP, and RTCWEB.

Alissa Cooper said she confirmed with one of the proponents this is 
only relating to one-way video, not two-way, and making that clear 
should be easy. She also noted that clarifying the work items should 
be a priority.

Warren agreed that removing the text about TLS will help clarify that 
as well.

The proposed MOPS BoF was approved for IETF 105.

ROUTING AREA

NONE

SECURITY AREA

o Collaborative Automated Course of Action Operations (CACAO) 
  for Cyber Security
  Responsible AD: Roman Danyliw 

Roman Danyliw introduced the CACAO BoF and noted that this would be 
the second BoF for the group. He said the last time the proposed 
charter text was too broad, and that much of the discussion circled 
around the text. The intent for this BoF is to pare down the charter. 
He also recommended the IESG and IAB approve the BoF.

There were no concerns to approving the BoF, but Eric Vyncke noted 
that there was no proposed agenda yet, and that the conflict list was 
extremely broad.

Barry Leiba disagreed that the conflict list was too broad, and that 
it is appropriate for a Security Area BoF to list the rest of the 
Security Area as conflicts.

Benjamin Kaduk agreed with Barry, and that the agenda was mostly TBD 
because the charter was being actively worked on in the mailing list 
and it was still in flux. He noted it should be available soon.

The proposed CACAO BoF was approved for IETF 105.

o Security and End to End Privacy in Identifier Locator Separation 
  Systems (PIDLOC)
  Responsible AD: Ben Kaduk 

Benjamin Kaduk noted that the proponents reached out early, but 
unfortunately due to extrnal issues he did not have the time to ask 
for more details at the time. He also noted that the summary for the 
BoF seems light, and there was not a lot of interest or support 
expressed on the mailing list. He is also not sure if anyone would 
deploy anything based on this potential work.

Erik Nordmark mentioned he hoped they would have made more progress. 
He noted it might make a good HotRFC topic to drum up support and 
attention.

Roman Danyliw mentioned they have not presented anything in either 
SAAG or SECDISPATCH and that might be a good starting point for them 
to get some renewed efforts here.

Warren Kumari stated that he liked the HotRFC suggestion, and with 
some additional support they might be in a better position for a BoF 
for IETF 106.

Roman noted that they had a HotRFC at IETF 102, but no followup in the 
Security WGs that are open to that.

[Jari Arkko posted in the jabber room that a presentation from them in 
SAAG would be useful, but he cautioned that they should get more in 
depth before that discussion, specifically how privacy differs in 
different id/loc systems today, what privacy issues there might be in 
the solutions, etc.] 

Benjamin summed up the discussion to not approve the BoF for this 
meeting, but to give some feedback to the proponents for better 
visibility.

The proposed PIDLOCK BoF was not approved for IETF 105.

o Lightweight Authenticated Key Exchange (LAKE)
  Responsible AD: Roman Danyliw

Roman Danyliw introduced the proposed LAKE BoF. He mentioned the 
session the subject had in SECDISPATCH, and some issues that were 
brought up at the time. He said they think with a tight charter of 
narrow work it would help solve some of the issues.

Benjamin Kaduk spoke about some of the emailed feedback from the IAB, 
that Jari Arkko stated that this should be focused on what can be 
done, and not a deep discussion on how to modify TLS. And that he 
supported adding LWIG, CFRG, T2TRG, and ROLL to the conflict list 
[this includes some suggestions from the Jabber chatroom].

The proposed LAKE BoF was approved for IETF 105.

TRANSPORT AREA

o Local Optimizations on Path Segments (LOOPS)
  Responsible AD: Magnus Westerlund

Suresh Krishnan stated that he planned to attend this BoF so that any 
Internet Area issues can be addressed.

Alissa Cooper noted that Mirja Kuehlewind had advised the BoF go 
forward as a non-WG forming BoF, so they can get more input from the 
community. Alissa also mentioned she thought it would be a challenge 
to get it right.

Suresh agreed, but thought it was worth seeing the BoF happen.

Eric Vyncke agreed it should go forward.

Alissa warned that some of the room requirements for the BoF seem off, 
that the estimated numbers for this BoF seemed high, while the 
estimated numbers for MOPS seemed low. She suggested that the 
responsible ADs should check on the room requirements after the call 
so Liz has the best possible information when scheduling. 

The proposed LOOPS BoF was approved as a non-Working Group forming BoF 
for IETF 105.

IAB SESSIONS

NONE