Narrative Minutes interim-2018-iesg-10 2018-05-24 14:00
narrative-minutes-interim-2018-iesg-10-201805241400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative Minutes of the 2018-05-24 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
Ben Campbell (Oracle) / Applications and Real-Time Area
Alissa Cooper (Cisco) / IETF Chair, General Area
Michelle Cotton (ICANN) / IANA Liaison
Spencer Dawkins (Wonder Hamster Internetworking) / Transport Area
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
Warren Kumari (Google) / Operations and Management Area
Terry Manderson (ICANN) / Internet Area
Alexey Melnikov / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
Eric Rescorla (Mozilla) / Security Area
Alvaro Retana (Huawei) / Routing Area
Adam Roach (Mozilla) / Applications and Real-Time Area
Amy Vezza (AMS) / IETF Secretariat
Martin Vigoureux (Nokia) / Routing Area

REGRETS
---------------------------------
Deborah Brungard (AT&T) / Routing Area
Heather Flanagan / RFC Series Editor
Mirja Kuehlewind (ETH Zurich) / Transport Area
Jeff Tantsura (Nuage Networks) / IAB Liaison
Portia Wenze-Danley (ISOC) / Interim IAD

OBSERVERS
---------------------------------
Charles Eckel
Karl Henderson
Greg Wood

NARRATIVE MINUTES
---------------------------------

1.2 Bash the agenda

Amy: Any changes to today's agenda?
No changes, terrific.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes of the May 10 teleconference
being approved? Hearing none, those will be posted.

I saw revised narrative minutes go out a few days ago, any objection to
approving those? Hearing none, those will also be posted.

1.4 List of remaining action items from last telechat

     o Benjamin Kaduk to ask the designated experts for the AEAD Parameters
       registry to update the registry noting that draft-nir-cfrg-
       rfc7539bis will obsolete RFC 7539.

Benjamin: I sent another email. I don’t know if Alissa has more current data
about his status.

Alissa: I don’t. I can check again.

Benjamin: This has been coming up for a month now so we can talk about how much
longer we want to wait before adding an additional expert. This was originally
added as a management item at the request of Alexey. Alexey, do you have
thoughts on how long we should wait?

Alexey: I think David was quite slow in the past, so I think maybe
investigating a second expert would be a good idea anyway.

Benjamin: Okay, let’s update that to reflect seeking an additional expert.

Amy: We will update that task, thank you.

     o Alexey Melnikov to find a designated expert for RFC 8323 [IANA
       #1108770]

Alexey: In progress.

Amy: Excellent, thank you.

     o Benjamin Kaduk to find designated experts for RFC 7924 and
       RFC-ietf-tls-rfc4492bis [IANA #1111082]

Benjamin: I think this is basically a boilerplate thing. We recently approved
three experts for TLS related registries and we wanted to make a clean sweep,
so IANA asked us to officially have the ISEG approve those experts for all the
registries.

Amy: When we get to that management item, those three experts are named; do you
want to change that to approving three experts for this?

Benjamin: Unless anyone objects from the IESG.

Amy: Okay, we can ask that question when we get there, so this will be
provisionally done.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-idr-bgp-gr-notification-15  - IETF stream
   Notification Message support for BGP Graceful Restart (Proposed
   Standard)
   Token: Alvaro Retana

Amy: I have no Discusses in the tracker for this document, so unless anyone has
an objection it looks like it’s approved.

Alvaro: This will need a Revised ID please.

Amy: Hearing no objection to approving the document, so it will go into
Approved, Revised ID Needed.

 o draft-ietf-softwire-map-mib-12  - IETF stream
   Definitions of Managed Objects for MAP-E (Proposed Standard)
   Token: Terry Manderson

Amy: I have no Discusses in the tracker for this document, so unless anyone has
an objection it looks like it’s approved.

Terry: This one will also need a Revised ID please.

Amy: Hearing no objection to approving the document, so it will go into
Approved, Revised ID Needed.

 o draft-ietf-dime-rfc4006bis-08  - IETF stream
   Diameter Credit-Control Application (Proposed Standard)
   Token: Ben Campbell

Amy: I have several Discusses in the tracker, do we need to discuss those today?

Ben: I’d like to discuss one just a little bit. Benjamin, I saw your proposed
text about the HTTP redirect concern. I just had a chance to scan it so I may
have failed to grok everything properly. I think the right answer here is to
document something along those lines but I have a little bit of a concern when
we're giving guidance on some out of band way of saying this is officially
redirected page should exist without some guidance on how to do that. As far as
I know I’m not aware of any approach to do that.

Benjamin: I'm not aware of how to do that, so perhaps we shouldn't bother to
mention that. I wrote it in a hurry as well.

Ben: I was going to propose what we do is to recommend that normal web best
practices are followed, like you should redirect to a HTTPS site that has a
properly certified certificate and that sort of thing. That gives us better
than nothing.

Benjamin: Those are fine things to do. I’m not sure this is limited to just
HTTP; I was using that as my example because I understand it better than SIP or
other spaces.

Ben: I understand that and we can make those words more generic. I think in the
real world we’re going to see it be primarily HTTP and occasionally SIP. I
think the other discuss items on there we have conversations happening so we
don’t need to talk about them right now, unless someone wants to. And we’re
definitely going to need a new revision.

Suresh: I think my comments can be resolved.

Ben: I’m not sure I heard you but I think I heard you say we can resolve over
email. Suresh: Yes.

Amy: This is going to stay in IESG evaluation and Revised ID Needed.

 o draft-ietf-softwire-dslite-yang-15  - IETF stream
   A YANG Data Module for Dual-Stack Lite (DS-Lite) (Proposed Standard)
   Token: Terry Manderson

Amy: I have no active discusses, so unless there’s an objection it looks like
this one is approved.

Terry: Approved, Revised ID Needed please.

Amy: This will go into Approved, Revised ID Needed and you can let us know when
that’s ready to go on.

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-xrblock-rtcweb-rtcp-xr-metrics-09  - IETF stream
   Considerations for Selecting RTCP Extended Report (XR) Metrics for
   the WebRTC Statistics API (Informational)
   Token: Ben Campbell

Amy: I have no Discusses in the tracker for this document, so unless anyone has
an objection it looks like it’s approved.

Ben: We're going to need a new revision; there are a fair number of comments.

Amy: This is going to go in Approved, Revised ID Needed. Thanks.

 o draft-ietf-ccamp-microwave-framework-06  - IETF stream
   A framework for Management and Control of microwave and millimeter
   wave interface parameters (Informational)
   Token: Deborah Brungard

Amy: Deborah could not be with us today. I have no Discusses in the tracker for
this document, so unless anyone has an objection it looks like it’s approved.
Since Deborah is not here to do final checks we’ll put this in Point Raised for
her to review.

 o draft-ietf-teas-actn-framework-14  - IETF stream
   Framework for Abstraction and Control of Traffic Engineered
   Networks (Informational)
   Token: Deborah Brungard

Amy: I have no Discusses in the tracker for this document, so unless anyone has
an objection it looks like it’s approved. As with the other one, we’ll put this
in Point Raised so Deborah can do final checks.

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 o draft-kucherawy-dispatch-zstd-01  - IETF stream
   Zstandard Compression and The application/zstd Media Type
   (Informational)
   Token: Alexey Melnikov

Amy: I have several Discusses in the tracker, do we need to discuss those today?
Alexey: [has Webex audio problems but says in chat this needs a Revised ID but
no need to discuss today.] Amy: That will go in Revised ID Needed.

 o draft-housley-suite-b-to-historic-05  - IETF stream
   Reclassification of Suite B Documents to Historic Status
   (Informational)
   Token: Eric Rescorla

 o status-change-suiteb-to-historic-00  - IETF stream
   Reclassification of Suite B Documents to Historic Status (None)
   Token: Eric Rescorla

Amy: I have a Consensus Unknown, is that supposed to be a yes, Ekr?

Ekr: Yes, I didn’t know I had to push that button. Do I?

Amy: For the documents yes, for the status changes no. We’ll mark that as a yes
for this document.

Ekr: Unless anyone objects. Have people been balloting on this thinking there’s
no consensus? I do notice some people have some minor points about clarity,
which I can work with Russ about.

Spencer: Just to mention one minor thing, it turns out that WG chairs can also
set that field, which is why you might not have had to set it before.
Unfortunately a lot of them do that when it has consensus in the WG to publish.

Ekr: I will say, this is perhaps the dumbest process piece I’ve ever seen. My
sympathy for other mechanisms of status change is increasing dramatically. We
could have a status change document and a document that references both
documents.

Amy: In any case, I have no discusses on either the draft Housley document or
the status change. As they go forward together, and they get announced
together, I think we can talk about them together. Unless there’s an objection,
both of these are approved and we can send the information to the RFC Editor.
Hearing no objection, unless anybody needs to put notes on them they’re good to
go as is. These are approved, announcement to be sent for both.

3.2.2 Returning items

 NONE

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 NONE

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

 o Messaging Layer Security (mls)

Amy: I have no blocking comments, so unless there’s an objection now MLS is
approved as a new WG.

Benjamin: As a process question, we did get some comments and I’d like to make
changes to the charter text. I assume there’s an equivalent to Point Raised,
Revised ID status?

Amy: Yes, it's Approved, pending edits to the charter. You will let us know
when it’s ready to go and we’ll get it sent. I believe we have all the parts
necessary given that you have 2 chairs; if those chairs are staying the same
all we’re waiting for is you to say you’ve made the edits and it’s good to go.

Benjamin: Okay, thanks.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o DNS PRIVate Exchange (dprive)

Amy: Terry is our AD for this group. I have no blocking comments, so if you
approve it we can make the changes to the charter and the WG action recharter
announcement will go forward. Any objection to just making the changes? Hearing
none, we will send a WG Action recharter announcement for it.

Terry: Thank you so much.

 o Limited Additional Mechanisms for PKIX and SMIME (lamps)

Amy: There are no blocking comments in the Datatracker; it looks like this is
ready for external review. Any objections?

Ekr: I have a process question. This is a pretty substantial charter change so
I'm happy to have external review. Do we always have external review?

Amy: No, if it’s a substantial change it gets an external review. Small changes
don’t need it. We could do a seven day external review so we can approve this
next time.

Ekr: I think that would be fine, unless anyone objects.

Amy: This will go for seven day external review and come back on the agenda for
June 7.

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Ted: There is one piece of work going on that we might want to talk to TSV area
about. There’s a group of documents coming out of stackevo about what a
critical wire image is and path signaling. Those will eventually go out for the
typical IAB review but it might also be useful to have some discussion in TSV
area. Brian is going to talk to Spencer about that, since Mirja is otherwise
implicated. Just as a heads up.

Spencer: Mirja and I have been talking about that. In general we think that’s a
fine thing to do and I think I may have been the person to ask if that would be
a good thing to do this time as well. This will not be a surprise to either me
or Mirja.

Ted: Okay.

Alissa: Ted, do you think we can talk about the stream identifier BoF proposal
now?

Ted: We put together a BoF proposal around the experiment we discussed a little
bit at the last meeting. The critical thing is we really need very strong, not
just BoF chairs but folks to manage the community discussion afterwards. Ideas
about who would be good at that would be very useful.

Alissa: The other thing that we hadn’t fully resolved is whether the IESG wants
the IETF stream to be included in the experiment.

[audio issues chatter]

Alissa: The way this BoF proposal is being framed right now proposes an
experiment whereby the IAB, IRTF, and independent streams begin to produce
documents with a different stream identifier. The RFC Editor reserves in the
background RFC numbers for those documents but doesn’t publish them. We run
this experiment where we see if the some of the confusion about what RFC
implies and what the different document streams imply gets cleared up in the
span of three years. Then we can reassess whether we want to go back to
everybody using RFC numbers like we do now or whether we want to keep separate
stream identifiers. We talked about better disambiguating experimental from
informational and standards track in the IETF stream. The question is whether
we want, in the BoF proposal itself, to say the IETF stream would be included
in this experiment and the IESG would propose some different set of identifiers
to use for documents on different tracks, or if we want to leave that out of
the BoF proposal itself and have people talk it through on the mailing list or
at the microphone at the BoF. That's what I wanted to get opinions about.

Ted: The idea here too, to remind people, is that we would create a mailing
list for this separate from RFC interest since that will have format related
stuff going on. The mailing list that people would be talking it through on
would presumably be the new mailing list. Presumably that would happen before
the BoF because I don't think it's very likely we'd get enough mic time at the
BoF to actually resolve anything.

Alissa: My personal take is that just the other 3 streams being included in the
BoF proposal itself is enough complexity and will incur plenty of discussion.
we don't quite have a specific proposal of what we want to experiment with yet.
It seems a little premature to throw that in there and have people criticize it
or ask a bunch of questions that we don't have answers ready for. I would
prefer to leave it out, but it's up to us what we do.

Ted: My honest opinion is that we should put it in. Even if we say
experimentals only, it makes it very clear that all of the stream managers
cooperating in the production of the BoF think this is a good idea. If the IESG
isn’t interested in doing this for experimentals, then I think it will be much
harder to push the other stream identifier view of the world.

Ekr: That’s one possibility. the other is that the bigger the change, the
harder it is for people to swallow. this might attract even more unhappiness. I
have no objections to making the changes proposed in this document but I'm
interested in what the IETF and RFC community will tolerate.

Suresh: We need to make sure we have a proposal worth talking about before we
put it on. I have no qualms about adding it in but let’s try to have something
ready to make sure we have something to talk about.

Ted: So I think the issue here is that the argument for doing this at all is to
better disambiguate standards from not-standards. If there’s going to remain a
set of docs that go through the RFC stream that are not standards during the
course of the experiment, I’m not sure this is worth doing directly from a BoF.
We could do a WG forming BOF to discuss how to do the experiment and
incorporate this if we want to delay and say the purpose of the BoF is to
design the experiment based on this idea, I think that'll work. But if we leave
the experimental stuff out of the process entirely it’s not worth holding the
BoF; I think we’ll get shot down too quickly.

Ted: The whole reason we’re arguing the ISE and IRTF should give the new stream
identifiers a chance is because this will help disambiguate the standards work
of the IETF from the other streams. If we’re still leaving nonstandards work in
the RFC stream, that disambiguation won't be as clean as if we say we’re trying
to make the RFC brand be standards, and all of the other streams are behind
that effort, independent stream will really have to come along. If we’re not
all behind the effort, the independent stream will be able to argue that we
won’t be able to disambiguate and it's not worth running the experiment or they
won't want to participate further.

Ekr: Isn’t this ultimately an IAB decision?

Ted: The way that works is actually a little complicated.

Suresh: If that's the basis then it's not sufficient to just do experimental,
so we'll probably have to do the informationals too.

Ted: Alissa, can you circulate the current proposal on iesg-only?

Alissa: Yes, I meant to do that before this call. I’ll send that and let’s see
if we can come up with something that people feel comfortable with as the
version of the experiment we would run in our stream. We can see next week on
the informal where we are.

Adam: I also want to clarify, Ted, I don’t disagree with anything you’re saying
but I don’t think it's clear to me that that needs to be in the charter as
opposed to in the discussion.

Ted: If what we're running is a WGFB and the WG is going to figure out what
experiment is going to successfully manage the disambiguation, then you're
right, we can certainly take time out for it. We were originally trying to do
this without forming a WG bc it’s not absolutely necessary if everybody agrees.
It’s really the stream managers who decide this sort of thing. If we shift this
to WG forming, and you’ll see the current text doesn’t talk about forming a WG,
we could adjust it so the form of the experiment is what gets produced by the
WG. The time that it will take goes up with that and the chance of needing a
very strong manager for the WG certainly goes up as well. To circle back to my
original request, if you have good ideas of people who would be able to run
this discussion in the community over a sustained period of time, we would love
to know them.

Adam: Thanks for your clarification, Ted.

Spencer: Couple of thoughts. Until I read through the text you’re talking about
sending to us I am broadly sympathetic to the POV that if we’re trying to
disambiguate standards from everything else, then everything else should be on
the table, no matter what stream produces it. I think there is that. I guess I
have two questions. Does it seem like the more likely failure path is having a
non WG forming BoF and figuring out that you need a WG halfway through, or
having a WG forming BoF and figuring out that you don't need a WG halfway
through?

Ted: I see what you’re asking but I suspect that if we have a WG forming BOF...
I don’t see a path for that turning into not needing one. There are people who
will want to extend this process enough that if they don't think they can kill
it entirely they will accept the idea of a WG in order to continue to influence
the outcome as much as possible. And that's fair; their viewpoint is that this
isn't necessary and if they persuade the rest of the community of that
viewpoint then we should stop. The upshot is that it's unlikely in my view that
we’ll have a situation where everyone says this is good to go.

Alissa: Why don’t people check out the proposal and we can talk about it over
email. We can get bak to the IAB after the informal next week.

6. Management issues

6.1 IESG Telechat Agenda Queue (Secretariat)

Amy: We have started receiving the ballot issue email, so we are adding
documents to the telechat agendas for the future. Related, we’re also keeping
an eye on the page counts because we had a deferral a couple of days ago that
will push a document from June 7 to 21, so you’ll see notices about things
moving to keep to the 400 page limit. Anybody have any questions?

Ben: When that gets pushed out, is there going to be explanation to the chairs
or do I need to follow up?

Amy: We would generally just move it on the telechat queue. I don’t know if
you’ve alerted your chairs that this might happen. I wouldn’t generally email
chairs and authors to let them know.

Ben: I alerted the chairs that we had a new process and I wouldn’t be putting
it on but I didn’t tell them it might be bumped. It would be good to get a
direct mail to the responsible AD rather than the generic; we get so many of
those we might miss that it’s our document.

Amy: The datatracker spits out its telechat agenda change for the document; we
wouldn't alert specific people.

Ben: I guess I’m asking for the responsible AD to be alerted a little more
aggressively. Just in the case of rebalancing the queue.

Alissa: You already receive the telechat update notice.

Ben: I get the telechat update notices for dozens of documents and might not
notice if one of them is mine.

Alissa: Maybe that's something we all need to pay attention to. What we're
trying to do is shift the responsibility to someone else, so now you have to
pay attention to things other people do.

Ekr: The underlying problem here is that the tooling is not very good at
letting you filter your notifications. Why don’t we see how it works and if it
turns out people are really getting lost, maybe the tooling can be adjusted.

Ben: I'm okay with waiting to see what happens.

Spencer: I'm trying to think why I would care. If we have some reason,
especially because of an external liaison relationship or something, that we
want something to be on a telechat before some date, I can imagine us wanting
to know. I can imagine us wanting to know if we're planning on not being
present for a particular telechat that we really want to be present for one of
our documents. I would want to know that's been moved from a telechat that I
would be present for to one I wouldn't be present for. What problem are we
actually solving here?

Ben: I was just thinking in terms of possibility of surprise.

Benjamin: It sounded like you had had WG chairs asking you what's going on and
wanted to be prepared.

Ben: On this one specifically. This was one of the first ones to be
automatically scheduled.

6.2 [IANA #1111082] Designated experts for RFC 7924 and
RFC-ietf-tls-rfc4492bis-17 (IANA)

Amy: The TLS chairs have asked that the three people who are currently serving
as TLS designated experts also serve as experts for this registry. Did I get
that right? Any objection to having Yoav Nir, Rich Salz, and Nick Sullivan be
the designated experts for these registries? Okay, they have been approved and
we will send an official note to IANA saying so.

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

Amy: Hearing no other business. we are finished. See you on June 7.