Skip to main content

Narrative Minutes interim-2019-iesg-15 2019-07-11 14:00

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

Narrative minutes for the 2019-07-11 IESG Teleconference

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

1. Administrivia
1.1 Roll call

Ignas Bagdonas (Equinix) /  Operations and Management Area
Michelle Cotton (ICANN) / IANA Liaison
Alissa Cooper (Cisco) / IETF Chair, General Area
Roman Danyliw (CERT/SEI) / Security Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Wes Hardaker (USC/ISI) / IAB Liaison
Ted Hardie (Google) / IAB Chair
Benjamin Kaduk (Akamai Technologies) / Security Area
Suresh Krishnan (Kaloom) / Internet Area
Mirja Kuehlewind (Ericsson) / Transport Area
Warren Kumari (Google) / Operations and Management Area
Barry Leiba (Futurewei Technologies) / Applications and Real-Time Area
Alexey Melnikov / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
Adam Roach (Mozilla) / Applications and Real-Time Area
Amy Vezza (AMS) / IETF Secretariat
Martin Vigoureux (Nokia) / Routing Area
Eric Vyncke (Cisco) / Internet Area
Magnus Westerlund (Ericsson) / Transport Area

Deborah Brungard (AT&T) / Routing Area
Heather Flanagan / RFC Series Editor
Alvaro Retana (Futurewei Technologies) / Routing Area
Martin Vigoureux (Nokia) / Routing Area
Portia Wenze-Danley (ISOC) / Interim LLC Executive Director

Bob Hinden
Greg Wood

1.2 Bash the agenda

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

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes of the June 27 teleconference
being approved? Hearing no objection, so we will call those approved. Any
objection to approving the narrative minutes from June 27? Hearing no
objection. We also have outstanding the BoF call minutes, for which there are
no substantial edits. Any objection to approving those for posting? Hearing no

1.4 List of remaining action items from last telechat

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

Ignas: This is an ongoing discussion with the Yang doctors. Please keep this in

     o Roman Danyliw to talk to the tools team to reset the counters on
       substate change for documents in AD Evaluation.

Roman: I think we're at the point where we either need to take no action or
folks need to choose a different option. This morning I sent the tally between
option 1 and 5, we have roughly equal support for each one. They're somewhat
mutually exclusive. I proposed if we can't move off of either of those options
we take no action and the counters stay the same. Do folks have any opinions on

Barry: I had been a #5 person and I can deal with #1. It's better than doing
nothing and covers most of the cases I want. I'm moving over to 1 to try to
break the logjam.

Adam: I was about to say the exact same thing, so that's two moves I guess.

Eric: Just to be sure, the most important stuff is to document exactly what the
counter means, whatever choice we do.

Ben: Option 1 would work for me as well, if we seem to be coalescing on that.

Roman: I will reach out to Alvaro to see if he can live with option 1, and most
importantly we'll document as brightly as we can the details of that. I just
want to bring this to closure.

     o Roman Danyliw to draft text to be posted on about reporting
       protocol vulnerabilities via an email alias and possible procedures
       on how to assign triage resources.

Roman: This is still in progress.

     o Suresh Krishnan to write a document on replacing the "updates" with
       new terminology (amends/amended by; extends/extended by; see also).

Suresh: I started writing something and I'll put it on GitHub early next week,
and circulate within the IESG to get a draft out. I was hoping to get this done
by the draft deadline but it was tight. It's in progress.

Alissa: Will we need time for this in the IESG agenda in Montreal?

Suresh: I think so; I'll add it.

     o Roman Danyliw and Barry Leiba to draft a starting point for the
       discussion on setting expectations with the WG Chairs in reference
       to responses to inappropriate or unacceptable behaviors.

Barry: That is done. We posted that to the IESG list; there's been no
discussion yet but it's been posted.

Alissa: Should we also talk about this in Montreal?

Barry: Yes, that's a good thing to have on the agenda.

     o Martin Vigoureux to work with the IESG to create a list of possible
       IESG Tutorials and will prioritize them for scheduling on a series
       of Informal Telechats.

Amy: Martin could not be with us today so we'll skip this one.

     o INT ADs to send a list of specific "hot topic" items that should be
       checked. The list to be provided for document authors.

Eric: Can you remind us to whom we send it?

Amy: I believe you send it to the IESG and Adam will collate them.

Suresh: We put it in the IESG wiki.

Adam: Great thanks. Just send a link to that.

     o SEC ADs to send a list of specific "hot topic" items that should be
       checked. The list to be provided for document authors.

Ben: That should be done as well.

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

Eric: Just waiting for Victor's feedback. Mostly done but still work in

     o Suresh Krishnan to write up a NomCom Chair BCP (work with past

Suresh: I've put together a skeleton but haven't made much progress on this.
I'll probably try to catch a few people in Montreal. Still in progress.

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

Roman: I think it'd be worth flashing up the summary in Montreal given the
discussion. So leave this in progress, I'd just like to go over where we stand
in person.

     o Alexey Melnikov to find designated experts for RFC-ietf-core-object-
       security [IANA #1141664].

Alexey: In progress.

     o Alvaro Retana to finalize the proposal for relabeling the IETF
       Meeting Agenda Conflicts, and discuss the proposal with the WG

Alvaro could not be on the call today so we'll skip this.

     o Alexey Melnikov to find designated experts for RFC 8554 [IANA

Alexey: In progress as well.

     o Adam Roach to facilitate the discussion on WG Meeting Structure,
       related to alternate room layouts and the facilitation of

Adam: I would consider this done. I was going to gather some of the feedback
from the chairs for the Secretariat but Stephanie is already on top of that.
She sent a nice long message with useful information. My read is that this is
pretty played out and I don't see a lot of stomach in the WG chairs to try an
experiment like this again.  I'm likely to conclude by saying to the wgchairs
list that based on your feedback we're not likely to try this again.

Magnus: My reading was that there was some interest but only for very small

Mirja: There was some interest for doing it in a small room.

Adam: I did see a few echoes of that. I'll try to work that into the summary.

     o Alexey Melnikov to find designated experts for RFC 8610 [IANA

Alexey: In progress.

     o Warren Kumari to draft text for an example
   operational use case for target interoperability set, utilizing
   "stable" in the filename string, and will circulate the text
   with the IESG and IAB.

Warren: This is done. There's going to be a side meeting in Montreal on
Thursday and I'm expecting much feedback.

Alissa: Did the previous portions Ted had written on interoperability get

Warren: I don't think so. I think that's kind of on hold.

Ted: I think that's true. I also thought we decided floating two things at once
was likely to cause some confusion, and focusing on one of them first was the
right introduction. Particularly for this, since we know the different groups
do different things, we have the httpbis and quic versions of these that look
like the state of play, and then what Mirja described in transport using wikis
is a bit different. There are a bunch of different ways to do this and the real
question is, is anybody thirsting for a common way to do this. Let's see what
happens on the Thursday side meeting, if this is a use case people would like
to address. If it is, we can pull this out.

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

Ignas: This is in progress.

     o Magnus Westerlund to find designated experts for RFC-ietf-tram-
       stunbis [IANA #1146028].

Amy: We have this as a management item so we'll mark this as provisionally done.

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

Adam: This is in progress and if I have difficulty finding one I'll ping the
chairs directly. I should have access to all the data I need to finish this
task now.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-anima-bootstrapping-keyinfra-22  - IETF stream
   Bootstrapping Remote Secure Key Infrastructures (BRSKI) (Proposed
   Token: Ignas Bagdonas

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

Ignas: Seven discusses, thank you everyone for that. I'd like to raise one
question on whether the discuss holders believe that this document can be
resolved in a meaningful way without returning it back to the WG and redoing it
from the ground up. This is mostly for the topic of MASA. The rest, I
understand from the authors and seeing the discussion on the list that the rest
of the discuss points could be resolved. But the reliance on MASA is kind of
the fundamental functionality of this document. The community has concerns
about that, and I think the use cases which are being targeted for this
document. For that it is probably reasonably acceptable. However, if we're
talking about a much broader scope, which eventually may happen, I probably
will concur with the questions hat the reliance on MASA is too heavy as it is
specified now. So the question I have is, do you believe that the current
mechanism as it is specified can be accepted, or does this need to be reworked
from ground up?

Eric: My three or four Discuss points are resolvable by a revised ID, but they
need to be done. I agree with the objective of the system and Ii think on the
MASA stuff, that's of course a big question mark in real life. It depends on
the vendor and the market and it's also out of IETF scope.

Alissa: Same for me. I think the main issue there is just the lack of clarity
in the document, not what it's specifying. I think there's been a little bit of
this from this WG before, being reluctant to cabin it off and say 'this is what
the scope is.' It says deployments targeting different environments would need
their own applicability statements, but then as you read the text it seems to
intermingle use cases that are out of scope with the ones that it is targeting.
I think if it was just clearer about that, the document as it is could be
published in a revised version.

Ignas: Okay. Anyone else with an opinion?

Warren: I'm recused; I'm not holding a Discuss. My concerns are more
fundamental, but I'm recused so mine don't need to be addressed.

Ignas: The proposal that you have, it works in some practical cases but I would
say different in the deployment scenarios. Yours is asking about configuration
and that's a fine problem to solve. This one is different in scope. I'm not
asking you to revert your recuse position but I would personally see those are
very different topics.

Warren: I fundamentally have concerns about the use of this, which I hopefully
explained okay.  It makes it so that it's hard to transfer equipment in the
future and makes it so vendors can block equipment after it's purchased. If I
was not recused I would probably abstain.

Ben: I'm not entirely sure, Warren, if local serial console access to do this
sort of configuration would alleviate your concerns about lack of resale. It
seems related to Alissa's point about lack of clarity about whether BRSKI is
going to be the only way to configure things, or if local touchful access is
still going to be supported.

Warren: Even if local touchful is supported, if I now buy a new shiny Juniper
router, which is in the millions of dollars, I also need to buy a bunch of
licenses to make it work. For some routers I have to buy a specific license to
make it accept more than 256,000 routes. This is something which already
happens and it's fully within the vendor's right, but to me it feels like this
functionality is used to make that sort of thing more common. I personally
don't think that should be what happens, but vendors are commercial groups and
I fully understand they're allowed to. Even if there was a way to always do
serial config, I think this functionality is a slippery path to making the use
of licenses and entitlements more common. But again, their commercial choice. I
don't have to like it.

Ben: That helps me understand a lot. Thank you.

Roman: My read of the applicability statement is we're not just talking about
big honking routes, we're just talking class 2 devices and up. A class 2 device
is actually quite a small thing. That would be my first contribution. I'm quite
excited we have text that talks about those new operational modes. My concern
is odd know how to implement those operational modes that are supposed to be in

Adam: I'll answer the same question you asked Warren. Having a serial console
would address the issue I have, that is likely to push me to abstain if it's
not otherwise addressed. Some normative requirement around that would put me
into a no objection category.

Ignas: So from what I hear, there probably needs to be much more clarity about
where this mechanism is targeted; this is bootstrap, this is not necessarily
operation. If I have a device in some form already booted up, I can still use
that router from the manufacturer. This is only important for the cases where I
am bootstrapping, so it's a new device.

Warren: Related to that, yes requiring a console for a big shiny router seems
reasonable, but if this gets used to deploy a wireless doorbell, I think even
if we say there needs to be a serial console, that would be implemented and
that's fully reasonable to not have it implemented. I think the applicability
statement and use case stuff does need to change. I still have a fundamental
thought that once I own a thing I can do whatever I want, including giving it
to someone else who will have to re-boostrap it. If the vendor has gone out of
business that has issues, but currently that's also kind of true with similar
IoT things where if the vendor goes away you're stuck.

Adam: I will point out that I would object to us putting anything out there
that would have these disposable devices also. The fact there out there doesn't
mean it's a good thing and something we need to be endorsing. A local access
method for bootstrapping would address my concerns.

Ignas: Which is an implementation detail, I would say, and probably out of
scope for this. I think I heard the answers for this question of whether the
document should be completely redone; probably no. So this definitely will be a
Revised ID Needed and we'll focus on resolving the discuss comments.

 o draft-ietf-mpls-egress-protection-framework-06  - IETF stream
   MPLS Egress Protection Framework (Proposed Standard)
   Token: Deborah Brungard

Amy: Deborah could not be with us today. I do have a Discuss in the tracker for
this document. Do you think this is going to require a Revised ID or AD

Roman: I think it's going to need a Revised ID.

Amy: Then we'll put this in Revised ID Needed for Deborah to address when she
gets back.

 o draft-ietf-ipwave-ipv6-over-80211ocb-49  - IETF stream
   Basic Support for IPv6 over IEEE Std 802.11 Networks Operating
   Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)
   (Proposed Standard)
   Token: Suresh Krishnan

Amy: I have a number of Discusses here; do we need to discuss any of those

Suresh: I have a clear understanding of what needs to change and I'm in
conversation with the authors so let's do this over email. Revised ID Needed

 o draft-ietf-tram-turnbis-27  - IETF stream
   Traversal Using Relays around NAT (TURN): Relay Extensions to
   Session Traversal Utilities for NAT (STUN) (Proposed Standard)
   Token: Magnus Westerlund

Amy: I have a number of Discusses here; do we need to discuss any of those

Magnus: I don't think so. Revised ID Needed.

 o draft-ietf-pce-association-group-09  - IETF stream
   PCEP Extensions for Establishing Relationships Between Sets of LSPs
   (Proposed Standard)
   Token: Deborah Brungard

Amy: No Discusses here but I do have an open position for Alexey, if you'd like
to state a position now you may do so.

Alexey: No, I didn't get around to it.

Amy: Okay. We have no Discusses so it looks like this is approved, but since
Deborah isn't here, we'll put this in Point Raised so she can do final checks.

 o draft-ietf-grow-bmp-adj-rib-out-06  - IETF stream
   Support for Adj-RIB-Out in BGP Monitoring Protocol (BMP) (Proposed
   Token: Warren Kumari

Amy: I have a couple of Discusses here; do we need to discuss any of those

Warren: I'm not sure. Would folks like to discuss them? Barry's is really easy
for the authors to address. Ben, do you want to discuss yours?

Ben: We got a reply from the authors within the past hour I haven't had a
chance to look at. Let's do it over email.

Warren: Okay. Let's do Revised ID Needed.

 o draft-ietf-iasa2-rfc7437bis-08  - IETF stream
   IAB, IESG, IETF Trust and IETF LLC Selection, Confirmation, and
   Recall Process: Operation of the IETF Nominating and Recall
   Committees (Best Current Practice)
   Token: Alissa Cooper

Amy: I have no Discusses. I have an open position for Ben; do you want to state
a position?

Ben: No, I ran out of time this week.

Amy: This one is approved. I have no notes in the tracker; any needed?

Alissa: No. There will be a Revised ID.

2.1.2 Returning items


2.2 Individual submissions
2.2.1 New items


2.2.2 Returning items


2.3 Status changes
2.3.1 New items


2.3.2 Returning items


3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-v6ops-nat64-deployment-07  - IETF stream
   Additional NAT64/464XLAT Deployment Guidelines in Operator and
   Enterprise Networks (Informational)
   Token: Warren Kumari

Amy: I have no Discusses in the tracker so unless someone has an objection it
looks like this one is approved. Is this ready to go as-is or does it need

Warren: There are a little fixups that could be done. I don't think we need

Eric: It looks like the author wants to get another rev of this, addressing

Warren: Okay, then let's do Revised ID Needed. Thank you.

3.1.2 Returning items


3.2 Individual submissions via AD
3.2.1 New items


3.2.2 Returning items


3.3 Status changes
3.3.1 New items


3.3.2 Returning items


3.4 IRTF and Independent Submission stream documents
3.4.1 New items


3.4.2 Returning items


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


4.1.2 Proposed for approval


4.2 WG rechartering
4.2.1 Under evaluation for IETF review


4.2.2 Proposed for approval


5. IAB news we can use

Mirja: I don't think there's news.

6. Management issues

6.1 IESG Job Description that is provided to NomCom (Eric Vyncke)

Amy: Eric, you added this as a reminder to everyone to review the job
description. How's that going?

Eric: I got good feedback from most areas. I think I'm only missing security.

Ben: I think both Roman and I edited the wiki page directly.

Eric: I didn't see. Thanks.

Mirja: Transport, we are editing it right now. We'll be done soon.

6.2 [IANA #1146028] Designated experts for RFC-ietf-tram-stunbis (Magnus

Amy: Is there any objection to approving Dan Wing as the expert for this
registry? Hearing no objection. We will send official note to IANA.

6.3 IESG agenda at IETF 105 (Alissa Cooper)

Alissa: The slots that we normally have for IESG only time are Sunday morning,
Monday morning, and Wednesday morning, and then joint with IAB Sunday midday
and Friday afternoon. If we look at the candidate topics, I just added the few
that we'd talked about earlier today, and we have one from Eric as well. We
basically have four IESG only topics. The other thing we normally do is ask
IANA, LLC ED, Secretariat, and RFC Editor and RPC if they have any
updates/topics. What I've heard from them so far is that the RFC Editor and
possibly IANA may have topics. I think based on that, unless anyone has other
topics they want to add, I'd like to suggest that we cancel our Monday morning.
I don't think we need it. We have an hour and a half on Wednesday morning and
currently we have 2.5 hours on Sunday morning. Even that is maybe too much
time. Does anyone object?

Ben: I'm not objecting but want to point out every time we've canceled Monday
we feel crunched for time on Wednesday.

Alissa Have we done it that many times?

Ben: I remember twice.

Eric: Would you prefer to cancel Wednesday?

Ben: Wednesday lets us do more localized preparation for the plenary,
especially if there are topics that have come up during the week.

Alissa: The IAB is meeting with RSOC on Monday morning and I'd like to attend
that if possible. I take your point, Ben, but we have a lighter agenda this
time than previously. I'll try to stick the various items in different places,
split them between Sunday and Wednesday, and we'll update the wiki. I think
that's all.

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

Ben This is probably better done in email but in SEC area we have a document
kicking around forever through IESG changes and it doesn't have enough
positions to pass. We need a couple more people to enter a position.

Barry: How many new ballots do you need?

Ben: I think 2 or 3.

Adam: I think it's 2 more.

Barry: I'll volunteer.

Mirja: I'd rather put it on the next telechat as a returning item.

Ben: I'll talk to Roman about it.