Skip to main content

Narrative Minutes interim-2019-iesg-25 2019-12-19 15:00

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

Narrative minutes for the 2019-12-19 IESG Teleconference

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

1. Administrivia
1.1 Roll call

Deborah Brungard (AT&T) / Routing Area
Jenny Bui (AMS) / IETF Secretariat
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
Warren Kumari (Google) / Operations and Management Area
Barry Leiba (Futurewei Technologies) / Applications and Real-Time Area
Alvaro Retana (Futurewei Technologies) / Routing Area
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

Ignas Bagdonas (Equinix) /  Operations and Management Area
Michelle Cotton (ICANN) / IANA Liaison
Jay Daley / IETF Executive Director
Heather Flanagan / RFC Series Editor
Mirja Kuehlewind (Ericsson) / Transport Area
Alexey Melnikov / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat

Chris Box
Jacob Holland
Greg Wood

1.2 Bash the agenda

Suresh: I sent a mail requesting expedited processing; is that usually a
management item?

Amy: Yes, I believe it is usually a management item.

Suresh: I sent an email; can you add it?

Amy: Is this for the lpwan document?

Suresh: Yes.

Amy: I'll get that in the Datatracker as a management item.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes of the December 5 telechat
being approved? Hearing no objection so we'll get those posted. Does anyone
have an objection to the final narrative minutes of the December 5 telechat
being approved? Hearing no objection so we'll get those posted as well.

1.4 List of remaining action items from last telechat

     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: That's still in progress, thank you.

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

Eric: The text is written but I still need to make it published, so keep it in

     o Alexey Melnikov to think about how to analyze how successful WGs and
       protocols are and why they failed or not.

Amy: Alexey could not be here today so we'll mark that in progress for him.

     o Martin Vigoureux with Wes, and Alvaro to work on some
       mechanism to obtain wider or private feedback from people who are
       disenfranchised; anonymous flagging of offensive emails to inform
       leadership; more opportunities for private feedback.

Martin: In progress.

     o Alvaro Retana with Warren, Alexey, Martin, Barry, and Roman
       to work on more transparency in the Datatracker about how long each
       phase of doc process takes / New datatracker flag to indicate who
       has the ball, authors or chairs.

Alvaro: This is still in progress, just like any other one that I'm up for.

Eric: On this action item, the AD can have the ball as well, not just authors
or chairs. Right?

Amy: So you want to add ADs in this?

Eric: It seems sensible.

Amy: We'll make a note, thank you.

     o Alexey Melnikov and Warren Kumari to add keyword tags to WG charters
       to identify specs that pertain to some general concept.

Warren: Still in progress.

     o Alvaro Retana to work on a framework for analyzing new proposals.

Alvaro: In progress.

     o Adam Roach to work on a virtual social room for remote attendees
       (promoting #hallway)

Adam: In progress, as well as my other one.

Warren: If you want to write something up we can put it on the affiliates page.
It kind of fits within that sort of social hangout type thing. So a paragraph
or some sentences we can point to.

Adam: Are you thinking like for creating a mailing list, or it goes on the same
page because it has the same general feel to it?

Warren: I was just thinking to stick it on the same page because it has the
same general feel. We'll put in a little blurb explaining one of these things
is not like the other.

Adam: That's a good idea, thank you. I appreciate it.

     o Warren Kumari to work on acknowledging shepherds, directorate
       reviewers in a more standardized/formal way.

Warren: In progress.

     o Alexey Melnikov to organize IoT overview discussion with interested

Amy: Alexey could not be here today so we'll mark that in progress for him.

     o Ignas Bagdonas to write a draft of an IoT Systems charter.

Amy: Ignas could not be here today so we'll mark that in progress for him.

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

Amy: Alexey could not be here today so we'll mark that in progress for him.

     o Alvaro Retana and Adam Roach to look at updating the I-D Checklist.

Alvaro: In progress.

     o Roman Danilyw to find designated experts for RFC-ietf-lamps-cms-mix-
       with-psk [IANA #1156116].

     o Roman Danilyw to find designated experts for RFC 8471 [IANA

Roman: These two are still in progress.

     o Eric Vyncke to write up draft text on Special Interest
       Groups and send to the IESG for comment.

Eric: Still in progress.

     o Warren Kumari to write up draft text on Affiliate Groups
       and send to the IESG for comment.

Warren: I did something! You can mark this done.

     o All IESG to submit their metrics data priorities to Roman (deadline
     o Roman Danyliw to collect feedback from the IESG on the metrics
       data priorities for the IESG to discuss at a future meeting.

Amy: I saw email for this and you have a deadline of January 16.

Roman: The next action is that I'll synthesize whatever has come in by then. If
people think that's not a long enough deadline, let me know.

     o Ben Kaduk, Alvaro Retana, and Suresh Krishnan to skim the ietf@ietf
       list and collect a list of topics that seem to be the major concerns
       for the community from recent discussion threads.

Ben: Let's keep that as in progress.

     o Martin Vigoureux to put together a proposal on disambiguating side
       meetings from IETF meetings.

Martin: I can't call that in progress because I haven't started but please keep
it there.

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

Amy: This is a management item for later in the call.

     o Magnus Westerlund to draft an IESG Statement regarding the IETF
       as the default change controller for IANA Registration requests.

Magnus: In progress.

     o Suresh Krishnan to draft a "best errata practices" document and
       post it on the IESG Wiki.

Suresh: I'll do that. We had a conversation about this at the last informal.
Keep it in progress and I'll write something up to summarize.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-cellar-ebml-15  - IETF stream
   Extensible Binary Meta Language (Proposed Standard)
   Token: Alexey Melnikov

Amy: Alexey said this would need a revised ID.

 o draft-ietf-bfd-vxlan-09  - IETF stream
   BFD for VXLAN (Proposed Standard)
   Token: Martin Vigoureux

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

Martin: Maybe we could, but as I said in jabber I'm not in an excellent
position to do so. Let's try. I think Ben, you had a specific point you wanted
to discuss on the configurability of the management VNI. Correct?

Ben: Right. I think I had two numbered Discuss points.

Martin: I remember reading you wanted to discuss this one specifically on the
telechat but if you want to discuss more, I'm fine with that.

Ben: Sure. I think for both of them, I don't actually know what the right thing
to do is, so I rely on the rest of the IESG to give us some hints as to what
the right thing to do is. For the particular management VNI configuration, I
don't know that it was as much about needing to configure the specific number
of the VNI that is the management VNI so much as whether the concept of the
management VNI was already something that was specified.

Martin: The thing is that it doesn't exist. Part of the issue here is that
VXLAN is not an IETF technology. The specification on which we rely is an
informal one; it was kind of a de facto standard that was described during an
IETF. At that time, there was absolutely no registry defined for VNIs and so
on. And I'm not aware of any outside of IETF. So we are a bit in a tricky
situation, where some implementations rely on VNI zero, some don't. So I'm not
sure I have an easy answer to the problem.

Ben: I don't think I have an easy answer either, although I do perhaps have a
potential answer; which would be to attempt to adopt the VXLAN specification
itself into the IETF stream and publish a new revision of it, which perhaps
could include some additions or modifications regarding the management VNI. But
then this document would have to wait until that document was complete for us
to go forward, and that's obviously not a great situation to be in. I was
hoping someone else on the IESG might have some thoughts to share.  [long

Martin: Apparently not! Do you think we really need to move the VXLAN into the
IETF as a standard track document? Maybe we could define a registry,
considering it has been used the first time, and start using it from now on? We
don't necessarily need to make it standards track.

Ben: I don't think we necessarily need to; that's a heavy hammer and I don't
have a clear sense that it's needed here. Perhaps it's worth asking Adrian how
he would feel about us making a registry for the ISE stream protocol, just so
we're not stepping on anyone's toes.

Martin: We can check that.

Ben: Part of why I don't know what to do is that we don't have a clear single
definition for what it means to update another document, so using some of the
definitions people have this doc would need to update the other doc, but not
using all of the definitions of update. There's not really a clear answer.
Given the apathy on the call right now, maybe we're just going to ignore the
question and let this document go forward, possibly with a registry but
possibly without.

Martin: So you hold the Discuss; it's up to you to decide what's the preferred
way. I don't have a strong opinion.

Ben: For the particular point I mostly just wanted to try to get broader
feedback on the topic, but I don't think it's a blocking point. I think we can
say we discussed it and we don't have a better proposal than what we're
currently doing. If we can move on to the other point, I think Adam had pointed
out something interesting I didn't get to look into. Apparently as IETF we have
the ability to reserve a special-use IP address, and I didn't have a great
sense on what the inherent restrictions on how those can be used and the
guarantee that other nodes would not be attempting to route or process packets
using those addresses. From some sense that seems like the most appealing route
to make progress on this, in terms of being able to keep the broader monitoring
properties that some of the WG members wanted, but still having a fairly robust
guarantee that the identifiers in question will not collide with the tenant

Martin: I myself wasn't fully aware of that capability. It looks quite
appealing, thanks Adam. I can try to bring the author to this idea.

Ben: Adam, was there anything else you wanted to tell us about that approach?

Adam: No, I have a question pending for the authors about what they're trying
to achieve here. If they want to make certain it's not ever leaving this router
if a tunnel is broken, or if it just doesn't have a valid destination. What
they're trying to do doesn't really do either of those very well. If we're just
trying to find something not routable, I'd think that if we were to put in a
null address, like all zeros, which I believe in both v4 and v6 is a "this is
not an address" address, then that probably gets to what they want as well
without burning a code point. But like I said, I'm still a little unsure what
they're trying to achieve here. I think we need to hear back from them before
we suggest a concrete route.

Eric: They were talking about adding entropy as well. Entropy into the overlay
is quite useless.

Warren: In v4 there's 0/8 which shouldn't leave the local network, but might.
169254 in v4 space seems like it would do a bunch of what they want and that
needs to be confirmed. But I'm also not quite sure what they're trying to
accomplish. I tried following their discussion and got lost midway through.

Martin: I have to admit it is not always easy to develop a good understanding
of what some authors have in mind and I have struggled myself. Let's explore
that before effectively taking a decision. What you were proposing, Adam, was
interesting. So I don't want to jeopardize the whole call with that document;
there are other very important Discusses but I've seen the authors have engaged
with you. It's not clear right now where we're going but I want to let the
discussion go a bit before stepping in. Thank you very much.

Wes: From a routeability point of view, with my operator hat on, I get an
amazing amount of addresses reaching me that are not supposed to be routable.
Looking through some requests in my archive, I see some arriving from 0000.

Warren: The question is was that intentional. It would be useful to figure that

Wes: My point was that if you want packets not to leave a box, good luck.

Warren: It's also possible those were hand-rolled packets, not done through a
normal API form.

Adam: When you say "from" are you referring to the destination or the source

Wes: Source.

Adam: This is the destination address they're discussing. I can't imagine how a
packet addressed to 0000 would route to anyone's network.

Wes: Well, it depends on how you have anyone's network configured. But it might
leak if someone has their network set up in strange ways.

Adam: Thanks.

Martin: In any case, it will be Revised ID needed for that document.

Amy: Thank you everyone.

 o draft-ietf-ace-coap-est-17  - IETF stream
   EST over secure CoAP (EST-coaps) (Proposed Standard)
   Token: Benjamin Kaduk

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

Ben: No, I don't think so. I think we should wait for the authors to respond.
The primary author had a recent change of affiliation so may be a little slower
than usual.

Amy: Is this going to require a Revised ID?

Ben: Yes.

 o draft-ietf-tls-certificate-compression-08  - IETF stream
   TLS Certificate Compression (Proposed Standard)
   Token: Benjamin Kaduk

Amy: There are no Discusses in the tracker. Eric, did you want to state a

Eric: No, I haven't read it yet.

Amy: Okay. So unless there's an objection now, this one is approved.

Ben: Let's put it in Point Raised, please.

Amy: I also have downrefs for this document; we'll be adding RFC7932 and
RFC1950 to the downref registry when this is approved?

Ben: Yes, I think that's the right thing to do.

Amy: This will go into Approved, Announcement to be Sent, Point Raised.

 o draft-ietf-bess-nsh-bgp-control-plane-13  - IETF stream
   BGP Control Plane for NSH SFC (Proposed Standard)
   Token: Martin Vigoureux

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

Martin: The author has been pretty responsive. I didn't see anything
unresolvable, so I'll let him continue to do the talking and if needed I'll
jump in. But if any of you want to discuss now, I'm fine.

Ben: I had this thing about the strategic direction of the SFC architecture,
which is kind of wishy washy and not my area of expertise. Has this already
been talked about a lot and explicitly taken, or if this is just something
we're picking up as a consequence of this document?

Martin: I don't think the document breaks anything in the SFC architecture.
However, I agree there are some things we could call differences. The authors
have argued that we should consider our document as a superset on the
functional point of view. I have mixed feelings about that but we don't break
anything. Maybe it could be clearer that the document departs a bit from the
architecture, in the sense of being a superset from what the architecture
specifies, but beyond that I'm not sure what else is needed.

Ben: So it sounds like you think we should wait to see what the authors come
back and reply with.

Martin: Yes. They'll likely say that, because they're already saying that to me
when I made the same comments. We'll see.

Ben: Thanks.

Martin: This will require a revised ID, I believe.

 o draft-ietf-mboned-driad-amt-discovery-11  - IETF stream
   DNS Reverse IP AMT (Automatic Multicast Tunneling) Discovery
   (Proposed Standard)
   Token: Warren Kumari

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

Warren: I guess if we have a minute. The authors replied some time last night.

Suresh: I looked at the new version. I'll clear.

Warren: I think the author is going to incorporate some other comments so once
that's done it should be okay to progress.

Adam: Warren, there's a conversation I'm still having with the authors about
Figure 2. They might be coming up with a revision to that. I'd at least double
check with them on that point first.

Warren: Okay, let's leave it in Point Raised and then once Adam's happy we can
clear it.

 o draft-ietf-6man-ra-pref64-08  - IETF stream
   Discovering PREF64 in Router Advertisements (Proposed Standard)
   Token: Suresh Krishnan

Amy: There are no Discusses in the tracker, so unless someone has an objection
now it looks like this is approved.

Suresh: Just put it in Point Raised please. I just want to make sure everything
is good.

 o draft-ietf-nfsv4-rfc5661sesqui-msns-03  - IETF stream
   Network File System (NFS) Version 4 Minor Version 1 Protocol
   (Proposed Standard)
   Token: Magnus Westerlund

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

Magnus: No, put it in Revised ID Needed.

2.1.2 Returning items


2.2 Individual submissions
2.2.1 New items

 o draft-thaler-iftype-reg-06  - IETF stream
   Guidelines and Registration Procedures for Interface Types and
   Tunnel Types (Proposed Standard)
   Token: Suresh Krishnan

Amy: There are no Discusses in the tracker, so unless there's an objection now
it looks like this is approved.

Suresh: Please put this in Point Raised as well; I'd like to discuss with

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-tls-tls13-cert-with-extern-psk-03  - IETF stream
   TLS 1.3 Extension for Certificate-based Authentication with an
   External Pre-Shared Key (Experimental)
   Token: Benjamin Kaduk

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

Ben: Let's keep this one in Point Raised for a bit; we had some ongoing
discussion I need to read through.

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

 o conflict-review-vesely-authmethod-dnswl-00
   IETF conflict review for draft-vesely-authmethod-dnswl
     DNSWL Email Authentication Method Extension (ISE: Informational)
   Token: Alexey Melnikov

Amy: I have no Discuss points in the tracker, so unless there's an objection
this conflict review can go back to the ISE with the notes that are currently
in the tracker. Hearing no objection, so this can go back to the ISE.

 o conflict-review-rundgren-json-canonicalization-scheme-00
   IETF conflict review for draft-rundgren-json-canonicalization-scheme
     JSON Canonicalization Scheme (JCS) (ISE: Informational)
   Token: Barry Leiba

Amy: I have no Discuss points in the tracker, so unless there's an objection
this conflict review can go back to the ISE with the notes that are currently
in the tracker. Hearing no objection, so this can go back to the ISE.

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

 o IP Security Maintenance and Extensions (ipsecme)

Amy: I have no blocking comments. Does it need to go for external review?

Ben: Yes, it will need to go for external review. But first, what state...

Amy: Pending Edits, if you need to edit.

Ben: Yes, I want to apply the wordsmithing from Barry and update the dates for
the milestones that are currently in the past.

Amy: So the external review is approved, pending edits, and you can let us know
when you're ready.

4.2.2 Proposed for approval

 o JSON Mail Access Protocol (jmap)

Amy: I have no blocking comments, so unless there's an objection the
rechartering is approved. I'm hearing no objection, so we will get that
approval sent.

5. IAB news we can use

Wes: We are currently pushing forward on creating the conflict of interest
draft you guys are waiting for, and you should expect to see a draft of it in
the not too distant future.

6. Management issues

6.2 Designated Experts for CMS Encapsulating Content Types and CMS Inner
Content Types (RFC 7193)

Amy: Alexey has identified Russ Housley and Sean Turner as the designated
experts for these two registries, with the possibility of adding a third in the
future. Is there any objection to naming Russ and Sean as experts? Okay, we
will get official note sent to IANA.

6.3 Requesting expedited processing for

Amy: Suresh is asking for approval to request expedited processing from the RFC

Ben: Suresh, did you see there was some discussion on the lake WG about how
this document is not very clear that the header compression portion is somewhat
separable from the ipv6 translation layer. I don't know if you saw that. [Note:
This discussion was actually on the TLS list.]

Suresh: I haven't seen it; I'm not on the lake list. I'll find it. There's
another document which is also in process so I'm not sure if it's related to
this one or that one. If you can send me the link, otherwise I'll check the
lake list.

Eric: Out of curiosity, is it to reuse the mechanism from this document to
another purpose?

Ben: Someone had proposed that the header compression mechanism might be useful
for a cTLS type scheme to minimize the size of the messages. But of course if
you just need the compression part you don't need the fragmentation and

Eric: Thank you. It could also be applicable to the compression part of ipsecme.

Ben: Yes, I think I saw your note on the charter.

Suresh: The draft name doesn't show me any hits on lake mailing list, but if
you send me something I'll take a look for sure. Was that a concern about the
content of this draft?

Ben: I think there was a suggestion that there might be an editorial tweak to
reflect that the header compression is usable outside of the immediate context
that it's being defined for.

Suresh: Okay, excellent. Do you want to hold off on this until that's done, or
do you want to do this in parallel?

Ben: We should be able to do it in parallel.

Suresh: Okay, so I'll make myself a note to check in with you by tomorrow.

Ben: I'll try and do it right away.

Amy: Okay, I'm hearing no objection to approving the expedited processing, so
we'll move on. Thank you.

6.1 Executive session: Invitations for leadership training

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

Amy: I wanted to remind you all that the Secretariat will be on winter holidays
from December 24 through the new year. We'll check email sporadically but if
you request last calls within that window it might be delayed, so keep that in
mind. You have an informal telechat scheduled for January 2 but it's up to you
to fill an agenda if you want to have it.