Narrative Minutes interim-2018-iesg-18 2018-09-13 14:00
narrative-minutes-interim-2018-iesg-18-201809131400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2018-09-13 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
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
Mirja Kuehlewind (ETH Zurich) / Transport Area
Warren Kumari (Google) / Operations and Management Area
Terry Manderson (ICANN) / Internet 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 (Nuage Networks) / IAB Liaison
Amy Vezza (AMS) / IETF Secretariat
Martin Vigoureux (Nokia) / Routing Area

REGRETS
---------------------------------
Spencer Dawkins (Wonder Hamster Internetworking) / Transport Area
Heather Flanagan / RFC Series Editor
Alexey Melnikov / Applications and Real-Time Area
Portia Wenze-Danley (ISOC) / Interim IAD

OBSERVERS
---------------------------------
Aaron Falk
Megan Rodrigo
Greg Wood

Amy: We did see regrets from Alexey and the only person I don't yet see in
Webex is Spencer. Hopefully he will join. Also welcome back Sandy!

1.2 Bash the agenda

Amy: Does anyone want to add anything new? Any other changes? Hearing nothing,
we'll move on.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes from the August 30
teleconference being approved? Hearing no objection, those will be posted. I
saw narrative minutes from the 30th, any objection to approving them? Hearing
none, we will get those posted as well.

1.4 List of remaining action items from last telechat

     o Eric Rescorla to find designated experts for RFC-ietf-oauth-discovery
     [IANA #1113497].

Ekr: I've done that. Now I need to find it in my email.

Amy: If you want to get them approved today, if you put their names in the
jabber room we'll take it as a management item.

     o Alissa Cooper to follow up with the editors of the Tao regarding
     proposed revisions.

Amy: I know this is kind of done.

Alissa: Niels has the action now so he's working through the edits. There's no
action for the IESG.

Amy: This action item for you is done?

Alissa: Correct.

Amy: You don't want to keep it as an action item?

Alissa: No, he'll come back to us when he's ready for us to review the whole
thing.

     o Suresh Krishnan to find designated experts for
     RFC-ietf-6tisch-6top-protocol [IANA #1119883].

Suresh: I've asked somebody, still waiting for him to get back to me.

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

Ekr: Remind me what RFC 8411 is?

Amy: I'd have to look it up.

Ekr: I feel slightly less uninformed. I have some vague memory but I didn't
realize I had agreed to do this. I've done nothing but I'm happy to continue to
have the action item.

     o Alvaro Retana to find designated experts for sub-sub-TLVs for BIER Info
     sub-TLV registry created by RFC 8401 [IANA #1120855].

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

Amy: The next four are for Benjamin and/or Ekr to deal with mikey-payloads.
These are brand new and just came in from IANA.

Michelle: In the note that we send to the IESG we'll tell you if there are
pending requests. I'd have to look them up individually to tell you if one has
priority. I think they kind of all go together.

Benjamin: There's one pending request from 3GPP for the payload name spaces
registry. I assume Ekr and I should just flip a coin and stick one of us with
this.

Ekr: I can take it with the same level of confidence that I took the last one.

Amy: These four action items: Ekr, did I hear you say you were going to find
experts for these?

Ekr: Yes.

Amy: Thank you for that.

Michelle: To clarify, for the first two there are pending requests, for the
third there is no pending request, and the last has two pending requests, all
from 3GPP.

Ekr: Okay, I will get on it at some point.

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

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

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

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

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-dnsop-refuse-any-07  - IETF stream
   Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY
   (Proposed Standard) Token: Warren Kumari

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

Warren: People have sent some comments, the authors are integrating them, I
think it's all good.

Michelle: We have an IANA Not-Okay here, and I'm trying to look up what the
issue was. I'll pop that in Jabber.

Warren: Thank you. I missed that, sorry.

Amy: Does this require a hold for Point Raised, Writeup Needed, or Revised ID?
Or is it good to go on Monday?

Warren: I guess it depends on the IANA thing. Point Raised.

Amy: Okay, you can send us a ticket when that's ready.

 o draft-ietf-bess-l2l3-vpn-mcast-mib-16  - IETF stream
   L2L3 VPN Multicast MIB (Proposed Standard)
   Token: Martin Vigoureux

Amy: I currently have no discusses in the tracker so unless there's an
objection it looks like this one is approved. There are no notes in the
tracker, Martin, is this good to go or does it need notes?

Martin: No, it's good to go.

Amy: Great, then we will get that announcement sent on Monday.

 o draft-ietf-bess-mvpn-mib-11  - IETF stream
   BGP/MPLS Layer 3 VPN Multicast Management Information Base (Proposed
   Standard) Token: Martin Vigoureux

Amy: I currently have no discusses in the tracker so unless there's an
objection it looks like this one is good to go.

Martin: Yes it is but I want to make sure that Benjamin's comment is addressed,
as well as the security directorate one. I haven't looked at the latest version
to check if the security directorate comment was addressed.

Benjamin: [The security directorate comment] was addressed.

Martin: Okay. You raise a good point so I'll check with the author and see what
needs to be addressed here. I don't know what state, AD Followup or something
like that?

Amy: It can be either Point Raised Writeup Needed or Revised ID Needed.

Martin: Point Raised, please.

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-tcpm-alternativebackoff-ecn-11  - IETF stream
   TCP Alternative Backoff with ECN (ABE) (Experimental)
   Token: Mirja Kuhlewind

Amy: I currently have no discusses in the tracker so unless there's an
objection it looks like this one is approved. Hearing no objection, it looks
like this one is approved. I have no notes in the tracker. Is it ready to go as
is?

Mirja: The authors are working on a new version right now and I was hoping they
would submit it before this which didn't happen. What's the right state? The
update will come in the next thirty minutes.

Amy: If it's version 12 that we're waiting on, because it's now version 11, we
can put it right now into Approved, Announcement to be Sent, Revised ID needed,
and we'll check if it's version 11 or 12 before it goes into that state. If
it's version 12 do you still need to do a final check, or have you seen that
version and it's ready?

Mirja: I saw the edits but I didn't see the final version. I think it should be
ready to go.

Amy: We will just make sure that it's version 12 before we send the
announcement.

 o draft-ietf-httpbis-expect-ct-07  - IETF stream
   Expect-CT Extension for HTTP (Experimental)
   Token: Alexey Melnikov

Amy: I have a number of Discusses in the tracker for this document.
Unfortunately Alexey couldn't be with us today to discuss these. Do the
Discuss-holders have a feeling if this is going to require a Revised ID?

Ekr: Yeah. There's another point I wanted to raise, I just realized, because I
hadn't looked at the status carefully. I don't understand why this is going for
Experimental. This is a stopgap mechanism to be used until CT is universally
deployed, which is a fine thing. Why is that experimental? What's the
experiment?

Ted: Whether or not it actually gets deployed?

Ekr: It doesn't seem like a very interesting experiment. And I don't see that
anywhere in the document.

Benjamin: I thought I remembered something in the document that mentions the
experimental status.

Ekr: I may have also missed it. I don't usually care about the status.

Alissa:  I thought it was the part about being conservative in how you react to
this, because the whole support for the reporting URI thing.

Ekr: For context, Chrome has already moved to require CT at all times, so it
seems odd to think that asking other people to act like Chrome is an experiment.

Warren: I agree with you, I looked at the status and thought it seemed weird.
From a process standpoint, if we made it informational that could just happen,
but if we wanted to make it something else, to me it seems Proposed Standard
makes more sense; it would require another Last Call, wouldn't it?

Ekr: I'm happy to leave this to Alexey; if he was here I would have raised it
with him. I'm happy to email the list and if Alexey says, no, I meant
experimental, be quiet, I'll be quiet. Is that okay with people or do people
feel more strongly about it than I do? Hearing no objection, I will do so.

Warren: One quick note. Adam mentioned that RFC 3864 doesn't allow experimental
RFCs to register HTTP codes.  Adam, can you clarify?

Adam: Basically, it should say 'experimental' instead of 'standard' on this
line. The value here corresponds as far as I can tell to the level of the RFC
itself.

Amy: It sounds like this is going to need a Revised ID and Alexey can follow up
with anyone who has questions.

 o draft-ietf-taps-minset-08  - IETF stream
   A Minimal Set of Transport Services for End Systems (Informational)
   Token: Spencer Dawkins

Amy: There are a couple of Discusses. The consensus was set as Unknown instead
of Yes. Does anyone have a feeling if this was a Yes or should I keep it
unknown until Spencer can answer the question?

Mirja: Spencer sent some late regrets and Aaron Falk, the chair, is on the
call. I'm pretty sure that should be Yes.

Amy: We'll set the consensus as Yes. There are a couple of Discusses. Does
anyone want to discuss the discusses with Aaron, since he's here?

Suresh: I think Spencer's note said the Discuss is actionable and he'll talk to
Aaron after.

Ekr: Reading the shepherd report, I'm actually not sure the consensus is
probably supposed to be yes. It's worth checking with Spencer. It opens with
'there's not a lot of interest in this agenda item'. IT looks like it was
reviewed by a lot of people but we should double check.

Amy: Okay; we'll double check with Spencer.

Ekr: I'm not questioning the consensus, if the consensus was yes, but it's
possible it was not pilot error.

Amy: We'll let him answer that question.

Mirja: From the shepherd report I can say there was consensus in the WG. I
think that yes also includes the consensus of the IETF last call, and as far as
I can see there was no comments on the IETF Last Call so I would think the
consensus yes as well.

Ekr: As long as someone responsible thinks its yes and not pilot error, I've
got no problem.

Mirja: As Spencer said, the question of what the status of this draft should
be, is definitely a question for the WG. My personal opinion is that it should
be informational because it's something that informs the API which then will be
a proposed standard, and it's really information you need to design the API.
You also said there's a normative reference and I'm not sure it needs to be
normative but I think that's all good questions to ask the WG.

Alissa: That's fine, thank you.

Mirja: The point about QUIC; I don't think there's a plan to redo this work
when QUIC is out there because it's a minset. Many of the features are also
available in SCTP, just not in this combination, so it shouldn't change. For
the API itself we're looking at QUIC and what's going on and want to
incorporate those things. That also kind of addresses Benjamin's discuss
because it really just is a minset, it doesn't constrain the API we're
developing. But it really says this is the features you must have, but we will
have more features in the API.

Benjamin: I'm sorry my Discuss was not more actionable. It's been hard for me
to coalesce my thoughts into a solid point.

Mirja: There might be some editorial work that can be done to clarify these
points.

Benjamin: And you're saying there's going to be another document that actually
does have the API?

Mirja: Yes, the more important documents are the 3 documents that are currently
in progress, which are the taps architecture, the API document, which is more
extensive than this, and an implementation guide that goes together with the
API document.

Benjamin: I did not notice the existence of an API document. That renders moot
a lot of my comment.

Mirja: Those docs are still in progress so they will get a pointer to the
minset but not the other way around.

Alissa: The QUIC thing was just a comment; we can follow up by email. Where it
really struck me was the security considerations; I think there's a factual
statement there which is going to be untrue fairly soon. It might be a matter
of future proofing that a bit.

Mirja: Originally the group was chartered explicitly to exclude security
protocols. We rechartered to include them now because it doesn't make sense to
exclude them, especially with QUIC. The API will capture that. That will change
the minset probably, but Im not sure if it makes sense to re-do the work.

Amy: It sounds like we can change the consensus tab to Yes, and Spencer can
follow up on the Discusses if necessary. We'll put this into AD Followup; or is
that wrong?

Mirja: Pretty sure there will be [Revised ID Needed].

Amy: Okay, we'll put it in Revised ID Needed and Spencer can take it from there.

Benjamin: Apparently they just published a new version of taps-minuet.

Amy: It went from 8 to 9! Why don't we put it in AD Followup and Spencer can
take it.

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

 o conflict-review-melnikov-email-over-pmul-00
   IETF conflict review for draft-melnikov-email-over-pmul
     draft-melnikov-email-over-pmul-08
     Multicast Email (MULE) over Allied Communications Publication
   (ACP) 142 (ISE: Informational)
   Token: Ben Campbell

Amy: I currently have no discusses in the tracker so unless there's an
objection it looks like this conflict review is approved. Hearing no objection,
this will go back to the ISE. We will send the standard message with the
included note.

Michelle: We sent a bunch of comments to Alexey. They'll probably be fine, I
don't think it's anything that would impede the conflict review. Just keeping
folks informed.

Amy: Thank you Michelle. I'm sure if Alexey has questions he will follow up
with you directly.

3.4.2 Returning items

 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

 NONE

4.2.2 Proposed for approval

 o IP Security Maintenance and Extensions (ipsecme)

Benjamin: I think we have to cut this short. There was some discussion in the
jabber that the IETF Last Call may not have actually gone out.

Ekr: Apparently if I push the right buttons I can do that? I don't know how to
fix that.  to

Amy: So it was supposed to get an external review and the external review
didn't get sent?

Ekr: My understanding is it was supposed to do internal review, which it did,
then go to IETF, then back to the IESG. The second one of those seems not to
have happened. I certainly agree it should have gone to the IETF and I
absolutely believe that if it didn't, it was my fault, but here we are.

Cindy: Ekr, this actually did go for external review back on August 27.

Ekr: Oh, okay, so we misread the history perhaps?

Cindy: I'm looking at the message that went out right now.

Ekr: Okay, then I guess maybe we just misread the history.

Benjamin: I was just looking at the Datatracker history and apparently I forgot
to check the ietf-announce list archives for the traffic.

Ekr: I guess this should have appeared in the Datatracker history.

Cindy: It should and it looks like something went wrong there.

Ekr: Okay, then sorry. Belay the belay!

Amy: It sounds like we have a Datatracker issue, not a process issue.

Ekr: Not my fault!

Amy: It sounds like the process happened correctly but the Datatracker may not
have followed the process correctly. If it did get an external review, which
Cindy says it did and I believe her, is there any objection to approving the
recharter? I have no blocking comments.

Ekr: I don't see any blocking comments. I can fix the editorial things. I think
Spencer's comment is just an FYI. I'll just edit this and upload. Do I mark it
approved?

Amy: No, you let us know when your upload is complete. Once we approve it and
get it sent, any changes to the text will then require another recharter.

5. IAB news we can use

Deborah: In case folks missed it, they did two posts recently; the RSOC
appointments and a good letter to the Australian Assistance and Access bill,
which you may want to take a browse through. They're discussing the logistics
for opening their meetings. A couple workshops, and what to do for the
technical plenaries.

6. Management issues

6.1 [IANA #1121057] Designated experts for RFC 6509 (mikey-payloads) (IANA)

Amy: Ekr, you're aware these are assigned to you.

6.2 [IANA #1120855] Designated experts for RFC 8401 (sub-sub-TLVs for BIER Info
sub-TLV) (Alvaro Retana)

Amy: Alvaro has identified two experts for this registry. Any objection to
approving Chris Hopps and Les Ginsberg? Hearing no objection, we will call this
approved and send an official note to IANA.

6.3 [IANA #1121239] Designated experts for RFC 6043 (mikey-payloads) (IANA)

Amy: Reiterating that we assigned this to Ekr at the top of the call. Ditto the
next two.

6.4 [IANA #1121240] Designated experts for RFC 6267 (mikey-payloads) (IANA)

6.5 [IANA #1121241] Designated experts for RFC 6309 (mikey-payloads) (IANA)

6.7 [IANA $1113497] Designated experts for RFC-ietf-oauthdiscovery (Eric
Rescorla)

Amy: Ekr has identified Mike Jones, Nat Sakimura, and John Bradley as
designated experts. Any objection for those three folks? Hearing no objection,
we'll call that approved.

6.6 Topics for IEEE 802 / IETF leadership gathering in Bangkok (Alissa Cooper)

Alissa: We have this IEEE and IETF leadership gathering set for Saturday
morning after IETF 103. Russ, the liaison manager, was asking if there are
particular topics that the IESG would like to see on the agenda here. There are
two topics the IAB has suggested, one relates to 5G work and the other is an
update on the status of privacy addressing. The question is whether folks have
other topics they'd like to discuss at this leadership meeting. I didn't get
any responses on email either, so I wanted to double check. Can I hear from who
plans to attend this meeting?

Warren: Warren will be there
Suresh: I might be there. I'm trying to change my tickets so I can stay the
extra day.

Alissa: We had the same sort of turnout from the IAB. Part of the point of
these is to maintain a good relationship and make sure the people in the
leadership know each other, even when things are going swimmingly and it seems
like we don't need it; but then if things start to go askew we have
relationships there and we're up to date on our items of mutual interest. It
might just be that we don't have a lot of items of mutual interest right now,
which is probably okay, but the next time one of these gets scheduled if most
of the IETF leadership is not going to be able to attend then we probably want
to reschedule or reconsider whether this is a good use of peoples' time. I'll
note that to Russ as well.

Mirja: I could potentially attend but I didn't have the feeling the topics on
the agenda are very useful for me to attend.

Alissa: That's how I felt when I was the ART AD as well.

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

Ekr: I do not but I updated the charter so I think we're ready now.

Amy: Great, so we'll make a note ipsecme is ready.

Amy: Has anyone asked whether the IAB/IESG conclusion meeting in Bangkok is
going to be a breakfast meeting? Have you discussed that at all?

Alissa: We discussed it when we were in the midst of discussing the Friday
experiment and I think that was my expectation, that it would be a Friday
morning breakfast meeting.

Amy: So like a 9 am breakfast?

Ted: The IAB would respectfully like us to consider brunch.

Alissa: Do people have strong opinions on this? We could do a 10 am meeting?
Noon?

Ted: I don't mean the San Francisco brunch that starts at 2 pm, I mean between
breakfast and lunch.

Terry: 10, 10:30 sounds perfect to me.

Amy: I will adjust the wiki time to a 10 am brunch .

Amy: Quick note that the BOF Coordination Call is Wednesday September 26 at
1400 UTC. That's it.