Narrative Minutes interim-2018-iesg-22 2018-10-25 14:00
narrative-minutes-interim-2018-iesg-22-201810251400-00

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

REGRETS
---------------------------------
Heather Flanagan / RFC Series Editor
Terry Manderson (ICANN) / Internet Area
Portia Wenze-Danley (ISOC) / Interim LLC Executive Director

OBSERVERS
---------------------------------
Stuart Brandt
Greg Wood

1.2 Bash the agenda
1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to approving the minutes from October 11?
Hearing no objection. Does anyone have an objection to approving the revised
narrative minutes? Hearing no objection.

1.4 List of remaining action items from last telechat

Amy: I have a list of action items are for Ekr to find experts. Are these still
in progress?

Ekr: Yes.

Michelle: I'm curious; can we get a review of those by an AD? We do have a
bunch of requests that have been waiting since August.

Ekr: I'm nailing that down to do it. Sorry.

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

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

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

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

     o 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-rtgwg-multihomed-prefix-lfa-08  - IETF stream
   LFA selection for Multi-Homed Prefixes (Proposed Standard)
   Token: Martin Vigoureux

Amy: I have no discusses in the tracker so unless there's an objection it looks
like this one is approved. Hearing no objection. I have no notes, are any
needed?

Martin: Could you put it in Point Raised or AD Followup? There are a number of
comments that need to be addressed.

Amy: It can go into Approved; Announcement to be Sent; Point Raised; Writeup
Needed and you can let us know when it's ready.

 o draft-ietf-bess-mvpn-expl-track-12  - IETF stream
   Explicit Tracking with Wild Card Routes in Multicast VPN (Proposed
   Standard)
   Token: Martin Vigoureux

Amy: I do have some discusses in the tracker. Do we need to discuss those today?

Martin: I think we can briefly discuss those but I think it can also be
resolved by email. Benjamin, I'll start with you. At first sight the discuss
you raised made a lot of sense to me, but I started to think about it and
especially on the proposal you had to update the registration procedure. But I
don't see how we can effectively do that. I further looked and saw there were
notes in the registry so maybe we could have a note there to refer to the point
you raised. Thinking more, it looks to me that these two paragraphs are
basically saying if you define a new tunnel type and plan on using the PTA in
that context, you need to specify how to handle that PTA. That seems a very
logical thing to do and I couldn't imagine any specification that would be
using an object without specifying how to handle it. I'm not sure these two
paragraphs put any requirement beyond anything logical on any future
specification. I'm wondering if it's really needed to have that visible
anywhere more than it is today.

Benjamin: I probably did not have the best understanding of this when I
reviewed it because to me it sounded like someone might be defining a new
tunnel type and it might be useful for this, it might not, so they might not
think to consider this when they're defining the new tunnel type. If it's the
inherent reason you'd be defining a new tunnel type then my concern goes away.

Martin: What I propose is we wait for the authors to react on this so we have
their views and you can decide based on that.

Benjamin: That works for me. Thank you for thinking about it more.

Martin: Suresh, I've seen your reply, which makes sense to me. I'll work with
the authors to make sure that something along the lines of what you propose is
inserted into the document. In any case, it doesn't hurt to have that so I
don't think the authors will oppose.

Suresh: I'll update my ballot to put my suggestion in there so they can decide
what to do. I was just worried because there as no reference at all to --

Martin: Yeah, I had overlooked that. The information exists but it's not
referenced. I had problems finding it myself in fact so your point is very
valid.

Suresh: Thanks.

Martin: And Mirja, which I think is supported by Ben and Spencer, and I liked a
lot Spencer the way you wrote it. Here let's see what the authors say. I think
at best we could have examples but I think it will be difficult to specify a
behavior that any implementation should support to handle that situation.

Mirja: That's not necessary but it's too easy to just say it's out of scope.
Would be rather nice to further discuss the problem and propose some example
measures.

Martin: I can see why it is out of scope. Typically the flag which is defined
might be user configured. Leaving out of scope an error originated by users is
a logical thing to do. I don't think we want any document to start envisaging
all the user could do. That would be a countermeasure at the root but I think
trying to list countermeasures is really out of the scope of the document.
Countermeasures for the control plane overload that could then result in that
error--I'll work with the authors. Typically on the proposal you were making,
filtering and so on, the route will be sent to the end points that are
effectively target. I don't think we could use filtering based on the subset of
those because otherwise we would be limiting the capability effectively
specified by the document. What I mean is that's the way it works. The risk is
inherent to that specification. If you specify it incorrectly you might get an
overload.

Mirja: It also doesn't mean countermeasures are out of scope of the document.
You just said no countermeasures exist, which is different.

Martin: Okay, I will talk with them.

Amy: We'll put that in Revised ID Needed.

 o draft-ietf-ospf-lls-interface-id-08  - IETF stream
   OSPF LLS Extensions for Local Interface ID Advertisement (Proposed
   Standard)
   Token: Alvaro Retana

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

Alvaro: We're going to go with Revised ID for this one.

 o draft-ietf-regext-org-11  - IETF stream
   Extensible Provisioning Protocol (EPP) Organization Mapping
   (Proposed Standard)
   Token: Adam Roach

Amy: I have a Discuss in the tracker. Do we need to discuss that today?

Adam: I don't think so; the authors are being responsive.

Amy: Is this going to require a Revised ID?

Adam: Probably, yes.

 o draft-ietf-regext-org-ext-09  - IETF stream
   Organization Extension for the Extensible Provisioning Protocol
   (EPP) (Proposed Standard)
   Token: Adam Roach

Amy: I have a Discuss in the tracker. Do we need to discuss that today?

Adam: No, same thing. The authors are being responsive. Also a Revised ID,
thank you.

 o draft-ietf-teas-assoc-corouted-bidir-frr-06  - IETF stream
   Updates to the Fast Reroute Procedures for Co-routed Associated
   Bidirectional Label Switched Paths (LSPs) (Proposed Standard)
   Token: Deborah Brungard

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

Deborah: It should go as Point Raised, because there are a couple of comments
to address.

 o draft-ietf-core-too-many-reqs-05  - IETF stream
   Too Many Requests Response Code for the Constrained Application
   Protocol (Proposed Standard)
   Token: Alexey Melnikov

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

Alexey: Can I have this in AD followup, please? I want to make sure all
comments are [addressed].

Amy: This will go into Approved, Point Raised, Writeup Needed.

 o draft-ietf-bfcpbis-rfc4583bis-26  - IETF stream
   Session Description Protocol (SDP) Format for Binary Floor Control
   Protocol (BFCP) Streams (Proposed Standard)
   Token: Adam Roach

Amy: I have a couple of Discusses in the tracker. Do we need to discuss those
today?

Adam: I think Ben's is probably going to wait for the conversation in MMUSIC to
play out. I do want to see if I can clear up Eric's thing in a few sentences
here on the call. The root of this appears to be that BFCP is the first
protocol that I know of that uses SDP for negotiation that has canonically TCP
and UDP as native transports. The notion behind the way the 'm' lines are set
up is that if you remove all of the ICE information, the section is supposed to
be valid and interpretable by a client that does not implement ICE. As a
consequence we need to have an indication of which protocol is used by non ICE
clients in this line. So it needs to be variant. Does that clear up the
confusion?

Ekr: I understand that claim but as far as I can tell it has never worked,
because you don't update the lines. The lines are going to be wrong. The whole
premise of ICE is that the defaults aren't particularly likely to succeed.

Adam: That's a statement about what the nature of the network you're going to
be in is. If this whole thing is operating within, for example, an enterprise,
then trying to set things up without ICE is generally going to work. Inside
controlled environments, use of things without ICE does work.

Ekr: I appreciate that. My point is, if you read the ICE specification, look at
how it tells you to set the default. The default in the 'm' line is almost
always wrong. It gives you the one that's most likely to work. The actual
consequence is going to be a lot of 'm' lines that are incorrect, which is the
whole reason we deprecated this in JSEP. I don't think the fact they're
supposed to be both ICE and non ICE solves the problem here.

Adam: I'm a little perplexed because in the ICE case, these values are ignored,
as you point out. There's not a problem from an ICE mechanics perspective. The
issue is in order to work with non-ICE clients, clients that are unaware of
that convention, we need to have a value that they will comprehend.

Ekr: The implicit claim seems to be that I am going to be an ICE capable
client. It appears in a non ICE capable answer. That's not going to work and
violates all the rules about ICE consent checks. If You were to allow it you'd
have security problems.

Adam: There are a lot of SIP clients that don't implement ICE. Consent is not a
prerequisite for the way SIP clients in general work. There are consent
requirements for WEBRTC because they run inside browsers and are treated as
much less trusted environments.

Ekr: Perhaps your experience is more extensive than mine but I'm skeptical
there are in fact environments where there are ICE aware clients trying to do
ICE and they talk to other clients which they don't know if they do ICE and
that actually works well.

Adam: That is the intention of the design of the protocol.

Ekr: Yes, that is the intention but I don't think it will work. Do you have any
cases where it actually works?

Adam: This is the first protocol where it's canonically TCP and UDP as native
representations. Until this gets deployment I'm not sure that's answerable in
terms of an operational perspective. The complaint you're leveling would be
more appropriate to put on ICE than this document.

Ekr: I guess? But this is the document in front of us and it has this problem.

Adam: Okay, I think we need to take this to email. I don't agree that this is a
problem. I think you'd have to point out how the system fails when the explicit
intention was to make this work. Let's go ahead and resolve this over email.

Ben: One point on mine before we move on. You did catch that I also added that
the mux categories don't match what's specified in this doc and what's
specified in the mux draft?

Adam: Yeah. I see that as an issue. I think the name of 'the stuff that cannot
be mux-ed' is probably a pretty low order bit. Thanks.

Adam: So for Amy, this is definitely going to be a Revised ID Needed.

 o draft-ietf-ccamp-mw-yang-10  - IETF stream
   A YANG Data Model for Microwave Radio Link (Proposed Standard)
   Token: Deborah Brungard

Amy: I have one discuss in the tracker; do we need to discuss that today?

Deborah: No, I think it's more for the authors to respond. Let's do this as
IESG Evaluation.

Benjamin: I think they did respond, but I only got to skim their message. It
looked reasonable at first glance.

Amy: Is this going to require a Revised ID Needed, or AD Followup?

Deborah: It doesn't matter. Do whichever one you want.

 o draft-ietf-extra-imap-replace-02  - IETF stream
   IMAP REPLACE Extension (Proposed Standard)
   Token: Alexey Melnikov

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

Alexey: Can I have this in Approved, Point Raised as well? I know the editors
have some comments to address from ADs.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 o draft-campbell-sip-messaging-smime-04  - IETF stream
   Securing Session Initiation Protocol (SIP) based Messaging with
   S/MIME (Proposed Standard)
   Token: Alexey Melnikov

Amy: I have a Discuss in the tracker. Do we need to discuss that today?

Alexey: I don't think so. We are waiting for Russ to respond and Ben already
replied to various comments. Ben, are you happy with this being Revised ID
Needed?

Ben: Yes. There were also some comments that came in from Benjamin since I had
a chance to look so I'll be looking at those today.

 o draft-murchison-tzdist-tzif-15  - IETF stream
   The Time Zone Information Format (TZif) (Proposed Standard)
   Token: Alexey Melnikov

Alexey: Can I also have this in Approved, Point Raised?

Amy: You sure can. There are notes in the tracker, so you'll make sure they're
appropriate before you approve it?

Alexey: Yes, they are to address an early Discuss from Benjamin. I'll double
check.

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-anima-reference-model-08  - IETF stream
   A Reference Model for Autonomic Networking (Informational)
   Token: Ignas Bagdonas

Amy: Ignas, I have a Consensus Unknown. Should that be changed to Yes?

Ignas: Yes, please. That should be yes.

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

Benjamin: It landed like 20 minutes ago, during this call.

Ignas: In general, this reads as fine, Benjamin, unless you'd like to go
through those comments again but I don't feel it's really necessary. What
you're raising makes sense and the intention of what is raised in the document
is exactly what you are putting into the comments. That's mostly the wording
aspect.

Benjamin: I agree; I think it's just a wording aspect here. We can discuss that
with the authors.

Amy: Okay, is that going to be a Revised ID?

Ignas: Probably.

 o draft-ietf-detnet-use-cases-19  - IETF stream
   Deterministic Networking Use Cases (Informational)
   Token: Deborah Brungard

Amy: I have no Discusses in the tracker, so unless there's an objection this is
approved. Hearing no objection, so this one is approved. I have no notes; are
there any needed?

Deborah: We'll do it as Point Raised.

Suresh: I put in some comments yesterday that were not blocking, but it would
be good to take a look.

Deborah: Yes, thanks. We'll have them clarify that.

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-filsfils-spring-large-scale-interconnect-00
   IETF conflict review for
   draft-filsfils-spring-large-scale-interconnect
     draft-filsfils-spring-large-scale-interconnect-12
     Interconnecting Millions Of Endpoints With Segment Routing (ISE:
   Informational)
   Token: Martin Vigoureux

Amy: I have no discusses in the tracker, so unless there's an objection the
current conflict review message can go back to the ISE. Hearing no objection,
so we will get that sent.

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 CBOR Object Signing and Encryption (cose)

Amy: I have a couple of blocks on this charter. Do we need to discuss those?

Ekr: I don't think so. We clearly can't approve this until the comment period
is over. Sorry for not changing the text; I do recognize you have comments so
I'll get on that before I ask for approval.

Amy: Okay; we'll be waiting for you, Ekr, to move that forward.

Spencer: Is there a substate for charters that's something like Approved for
External review, AD Followup? I mean from the last telechat. What happened was
that we had comments but the thing was approved for external review. So Eric
didn't have a moment to make the updates after it was approved for external
review.

Amy: It's Approved, Pending Edits, would be the substate. Then he would let us
know.

Spencer: So we just missed putting that in the right substate then, thank you.

Amy: If it had just gone for external review, the external review period would
already be over. You're saying the external review period is not yet over.

Ekr: Normally when we approve a draft that has comments, prior to approval
there's a substate that says the IESG is happy but changes need to be made. In
this case it went directly to external review and there was no intermediate
stage where I was reminded to screw with the document before it went for
review. I'm totally willing to cop to my part in that but I think Spencer's
question is: is there a mechanical step which I screwed up somehow?

Spencer: We don't do a lot of charters and recharters, so it's good for us to
learn things.

Cindy: At the last telechat this was approved for external review. It was not
approved for external review pending edits. It did go out one day later than
normal because all of our meeting deadlines hit last week. There's not a
datatracker state for external review pending edits, but we have our internal
tracker so if something is pending edits at a meeting we note that. This one
was not.

Ekr: So I just need to say "pending edits" and then we'll be good.

Cindy: Yes.

Warren: I had a similar confusion recently. Sometime in our copious free time
we should discuss the names of the states in the datatracker for this. I've
sent stuff for external review that I didn't intend to, and I haven't sent
stuff I meant to. I have a cheat sheet that I think Cindy gave me, but also the
names of these things are just weird.

Amy: that might be a good thing to talk to the tools team about at the upcoming
code sprint. At this point for COSE we are waiting on you, Ekr, to tell us it's
ready to go or if you want more review.

Ekr: No action from you required; we're waiting for the comment period to
expire and when that's over, I'll edit with whatever comments and then ask for
approval.

Amy: Great, thank you.

Spencer: There's not a Yes yet, so I'll clear my block.

Ekr: I haven't gotten around to voting Yes. I'll do that at the same time.

Adam: I'll also clear, given that this will be overtaken by events in a few
hours.

Amy: Ekr, if you could also make sure the chairs are the chairs you want, that
would be great. I don't think the chairs have changed since before.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o Managed Incident Lightweight Exchange (mile)

Amy: Alexey is shepherding this recharter effort. I have one block on the
charter. Do we need to discuss it?

Alexey: I don't think so. I think at least one chair agreed the comments are
sensible, so I'll work with chairs on updated text. I think people also agreed
about use of transport protocol to be replaced with HTTP substrate, or
something like that. Other comments need to be addressed as well. I'll try to
get this done before we meet in Bangkok.

Amy: Will this require external review?

Alexey: I think probably yes, just because of the addition of STIX. Hopefully
it's not very controversial, but better safe.

Amy: Okay, we'll just wait for instructions from you then.

 o Registration Protocols Extensions (regext)

Amy: I have no blocking comments, so unless there's an objection this is either
ready for external review or ready without external review. Does anybody
believe this needs external review? Hearing crickets.

Adam: Last time around there was consensus we didn't need an external review on
this. I wanted to put it in front of people because there are a lot of comments
of an open ended nature, so I wanted to make usr people were happy with the
tightened language.

Amy: Okay; it looks like this is approved for recharter, so we'll send that
announcement.

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Deborah: Not really any news. They still haven't really finalized on the
workshop but they're getting close. I can't really say any more.

Ted: Two quick things to add to that. Alexey, I did mention on the call when we
were reviewing the unicode 11 state that you might need a shepherd; so if you
haven't found one yet, various IAB members are ready willing and able to help
you find stuckees, but know they are not going to be considered themselves. You
might reach out to either the IAB as a whole or Suzanne to help find folks.

The other thing is the IAB reviewed on the call and updated workshop report RFC
template, so the boilerplate thats associated with IAB workshops or documents
is going to change. If you have individual tooling that checks for that you
might want to look at the webpage. The IAB is also talking about shifting some
workshop reports from RFCs to webpages and we expect to issue a call for a
community commentary in the IAB chair's report to the community for Bangkok.

6. Management issues

6.1 IESG agenda at IETF 103 (Alissa Cooper)

The schedule for IESG meetings was discussed and the Monday morning breakfast
meeting will be canceled.

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

Amy: Any other business?

Benjamin: The TLS chairs are polling the WG about rechartering so we should see
that in a couple of months.

Amy: Okay, see you all in Thailand!