Narrative Minutes interim-2020-iesg-03 2020-02-06 15:00
narrative-minutes-interim-2020-iesg-03-202002061500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2020-02-06 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Deborah Brungard (AT&T) / Routing Area
Jenny Bui (AMS) / IETF Secretariat
Alissa Cooper (Cisco) / IETF Chair, General Area
Michelle Cotton (ICANN) / IANA Liaison
Roman Danyliw (CERT/SEI) / Security Area
Martin Duke / F5 Networks Inc / incoming Transport 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
Erik Kline / Loon LLC / incoming Internet Area
Suresh Krishnan (Kaloom) / Internet Area
Murray Kucherawy / Facebook / incoming Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / Transport Area
Warren Kumari (Google) / Operations and Management Area
Barry Leiba (Futurewei Technologies) / Applications and Real-Time Area
Alexey Melnikov / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
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
Robert Wilton / Cisco Systems / incoming Operations and Management Area

REGRETS
---------------------------------
Ignas Bagdonas (Equinix) /  Operations and Management Area
Jay Daley / IETF Executive Director

OBSERVERS
---------------------------------
Chris Box
Brenda Lyons
Benjamin Schwartz
Greg Wood

1.2 Bash the agenda

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

Alissa: I want to say welcome to our incoming IESG members. I have one agenda
item to add; a discussion of the appeal of 7230bis in executive session. It
should be brief.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to approving the minutes of the January 23
teleconference? Hearing none, we will get those posted. I saw final narrative
minutes from January 23; any objection to approving those? Hearing none, 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 ietf.org about reporting
       protocol vulnerabilities via an email alias and possible procedures
       on how to assign triage resources.

Roman: Please mark that in progress. Thanks.

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

Alexey: All of my items are in progress please.

     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: This hasn't progressed; I need to re-activate it.

     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, area directors, authors, or chairs.

Alvaro: This one, as well as all my other ones, are in progress.

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

In progress as noted above.

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

In progress as noted above.

     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
       ADs.

In progress as noted above.

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

Suresh has volunteered to take this over.

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

In progress as noted above.

     o Roman Danilyw to find designated experts for RFC 8471 [IANA
       #1156118].

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

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

Eric: In progress.

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

Roman: I didn't get input from everyone but I think I got as much as I'm going
to get, so thank you to the IESG for providing all that feedback. I sent out a
data call saying 'this is what I believe is the subset of metrics that's our
consensus position.' Unless there's an objection I'll go with that as the list
we agree to. Thanks everyone; I'll assume the shorter list we made is consensus
and I'll think about resources and followup now.

     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: Technically that's done, but please keep this in progress so we can
remember what the next steps are.

Amy: Okay, we'll keep this in progress. Let us know if you want to update the
text.

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

Martin: The slide is ready; I still need to share it with you all for comments.
Let's keep it in progress until I share it.

     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: Please keep this in progress.

     o Adam Roach to draft a message to the WG Chairs email list
       regarding the ability to dispense with milestone dates in the
       datatracker.

Adam: This is done.

     o Roman Danyliw to find designated experts for RFC 7636 [IANA
       #1160634].

Roman: Still in progress.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-6lo-ap-nd-19  - IETF stream
   Address Protected Neighbor Discovery for Low-power and Lossy
   Networks (Proposed Standard)
   Token: Suresh Krishnan

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

Ben: I should be clearing shortly. I believe all the changes are in; I just
need to double check one of the dependencies.

Suresh: I think the authors have responded to pretty much everything, so I
don't think we need to discuss anything. Pascal just replied this morning at 7
am and I don't expect you to clear yet; take your time and get back if there's
an issue. There's also an IANA change that's going to happen here so no matter
what it's going to get updated. Keep it in IESG eval and most likely Revised ID
Needed.

 o draft-ietf-dtn-bpbis-22  - IETF stream
   Bundle Protocol Version 7 (Proposed Standard)
   Token: Magnus Westerlund

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

Magnus: I don't know; I haven't read them. Is there anything the Discuss
holders want to discuss? Or we'll just go to Revised ID.

Alexey: I have a request about my discuss, because I didn't have enough time to
put it in more details. Can I have until tomorrow evening to update my discuss
and expand it a little bit?

Magnus: I think that's fine, yes.

Alexey: I initially suggested I might defer the document, but it might be
better if I can just do all of it by tomorrow.

Magnus: Could you send email to the authors and chairs saying that and cc me?

Alexey: I put a Discuss placeholder but I will update it. That's fine. Thank
you.

Warren: I didn't ballot on this document; there were a couple of other
documents I didn't ballot on this round because I was traveling. Just figured
I'd mention; no need to check with me on each of them.

Magnus: Does it have enough positions currently if the discusses clear?

Warren: Yes, I think so.

Amy: If all the Discusses move to Yes or No Objection, yes you have enough
positions.

Magnus: So Revised ID Needed, then.

 o draft-ietf-dtn-bpsec-18  - IETF stream
   Bundle Protocol Security Specification (Proposed Standard)
   Token: Magnus Westerlund

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

Magnus: Same question here. Does anyone have anything they want to discuss?
Otherwise email is fine. [pause] Sounds like nothing. Revised ID Needed, please.

 o draft-ietf-sipcore-locparam-05  - IETF stream
   Location Source Parameter for the SIP Geolocation Header Field
   (Proposed Standard)
   Token: Adam Roach

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

Adam: I think there are enough editorial comments on this we're probably going
to need a new version of it.

Amy: So Approved, Announcement to be sent, revised ID needed?

Adam: Yes, thank you.

Amy: There also looks to be a downref in it. Should we be adding RFC 3325 to
the downref registry on approval of this document?

Adam: I think that's correct.

Amy: We'll make sure that happens once that approval notice goes out.

 o draft-ietf-dprive-bcp-op-08  - IETF stream
   Recommendations for DNS Privacy Service Operators (Best Current
   Practice)
   Token: Eric Vyncke

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

Eric: I don't think so. Alissa and Ben have very clear Discusses that are
easily addressed. Thank you for those comments. The main author is not
available right now so put it as Revised ID Needed please.

Alexey: Can I ask Alissa to explain her last point? Basically it's text about a
document in legal jurisdictions and what kind of corporation might apply. From
the user point of view, this is information I would like to have. I understand
it's a minefield and all the legal implications can be difficult, but can you
maybe elaborate what your concern is?

Alissa: I think this is not really a technical or operational concern. It just
seems a little odd to me that we would say we have IETF consensus on this, that
you want these policies to go into detail about all the privacy laws that apply
when you're using this DNS service and that you expect these policies to be
specific about which law enforcement agencies the operator is sharing data
with. These practices are not in line with what anybody publishes today as far
as I know, so it seems a little bit strange for us as a technical organization
to set out a marker that assumes these things which don't happen today, might
be a good idea, or might not be, depending on how you think people consume
these policies, whether anyone reads them or if you'd rather have a short
focused operational policy and then the longer compliance notice that has all
this other stuff in it. The whole area related to the publication of these
policies is pretty complicated and involves the entity that's publishing the
policy having some position around what they think this policy is doing, and I
think most commercial entities think this is a legal document and not a means
of providing users with actionable information. The whole section makes me a
little queasy but that part in particular seemed like outside the scope of
something where we have the expertise to say this is the best current practice.

Alexey: Thank you. Your expanded explanation is much better. I understand the
concern.

Alissa: I probably should have put more of that in the ballot.

Alexey: If you could expand the background, that would be helpful.

Eric: It will help the authors to fix the text.

Alissa: I'll make a note of it.

Ben: I also had a point I wanted to talk about briefly that was kind of buried
in my comment section. There was a part of the document where they essentially
make the statement that it is a legitimate reason for DNS operators to inspect
DNS traffic in order to monitor for network security threats. The word
'legitimate' stuck out to me as a subjective statement that this is a value
judgment, and I wasn't sure if that was really something that had been reviewed
by the IETF, given that it's not the main focus of the document and kind of
buried in there. I'd proposed some alternate wording that had less of a value
judgment associated with it. If people think I'm being overly sensitive I'd
like to know.

Warren: As noted earlier I didn't read and ballot on some of this because I was
busy last week. I'm beginning to think maybe that was a mistake, since there's
much in this discussion that's making me twitch.

Ben: I believe the 'defer' button is still active, just saying.

Warren: I think you and Alissa have things in hand, but let me think about
that. It's probably still not too late for me to ballot.

Roman: Ben, I'd agree with not using subjective language like 'legitimate'. One
man's legitimate is another woman's illegitimate. I think what you have removes
some of the subjectivity so I think that makes sense.

Alissa: This is the section that's the subject of the first point of my
Discuss, so I'm hoping that it will get edited anyway. The text there doesn't
really make sense to me. I don't understand the point that is being made.

Ben: I did miss that was the same section that you'd been covering. Thanks for
pointing that out.

Alissa: I don't know, Eric, if you want to talk about this or wait until Sara
is back, but it's a little odd to me. The whole document is focused on the
operators of the DNS resolution service, but this says there are other people
who will have trouble, so it just seems a little mixed.

Eric: It may also be relating to the fact that the authors use the word
'operator' but this word is ambiguous in this context. It could be read
multiple ways, which isn't good. I will let the authors fix it.

Roman: There's certainly some subjectivity in the language which Ben had
alluded to. The text to me read like it's acknowledging the  continuing reality
that there is going to be some inspection that is going to happen relating to
security operations.

Adam: The section is aimed at the wrong people. This is a different set of
operators than the operators the document is ostensibly directed to.

Eric: That is exactly what I'm saying. It's ambiguous what is meant by operator
here. So you put your own meaning on it, I put my own, and it's unclear. It
needs to be fixed.

Adam: The title of the document is "Recommendations for DNS Privacy Service
Operators" so I think it's pretty clear which operators are the subject of this
document. This section does not apply to them, it applies to other operators.

Eric: It's unclear.

Alissa: We can keep an eye out for this 'legitimate' language when we get a
response on the bigger point.

Eric: I fully agree with the comments; 'legitimate' is the wrong word to be
used here.

Adam: I also have a couple of comments on this section that if it stays in, I
want to get those taken care of. But I assume this is going to be removed
because it really does feel like it doesn't belong in here.

Eric: I can only agree.

Amy: So this will stay in IESG Evaluation with a substate of Revised ID Needed.

2.1.2 Returning items

 o draft-ietf-perc-srtp-ekt-diet-11  - IETF stream
   Encrypted Key Transport for DTLS and Secure RTP (Proposed Standard)
   Token: Alexey Melnikov

Amy: I have a Discuss in the tracker; do we need to discuss it today?

Alexey: I don't think so; it seemed quite straightforward. There are also
several comments that need to be addressed. This needs a revised ID please.

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-dots-architecture-16  - IETF stream
   Distributed-Denial-of-Service Open Threat Signaling (DOTS)
   Architecture (Informational)
   Token: Roman Danyliw

Amy: I have Consensus Unknown for this. Should it be a yes?

Roman: Yes, thank you.

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

Roman: Thank you everyone for the review. Can you please mark it Revised ID
Needed? There are some good comments in there the authors are going to fold
into the text.

Amy: Great. You can let us know when it's ready.

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

 NONE

3.4.2 Returning items

 NONE

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

 o Web Packaging (wpack)

Amy: I have a Block on this charter.

Ben: It's a fairly soft block but I want to hear from the proponents. Alexey, I
don't know if you saw but I sent a slightly updated version as the call was
starting.

Alexey: No I haven't. I'd like, if we can, to come up with some suggested
changes today or tomorrow to get this unblocked. I have lots of very good
comments from others about items that should be dropped or reworded. I'd like
to send this for external review sooner rather than later and make sure all of
them are addressed by the time it comes back for final approval.

Ben: I think we can probably do that.

Ted: Ben, I posted a pointer in the jabber to some additional information about
the unsigned bundle case. The confusion there can be probably cleared up with
additional language clarifying that those are user created, and because they're
user created they don't share the same name space or URI scheme as the web
itself. It also ties into your question about efficiency, because some of this
is for efficient management of resources which you got from the web and might
be storing right now in mhtml or something. So there's probably more language
there needed but you might want to review that particular exchange and the
things linked off it.

Ben: I will try to do so. I was also pondering if even for a single user's own
internal use there would be value in some sort of integrity protection that
only they could verify, like they could use a self-sign certificate to sign the
thing. If you remember that certificate was you, you have evidence of tampering
or protection from tampering, depending on where you're sending the stuff.

Ted: That's a useful question. A lot of the systems we're talking bout here
don't necessarily have the mechanisms to do that right now but may be something
to include as an option so when we are talking about systems which could
generate a self sign certificate and do object security it would work. Again,
it's not clear to me personally what the connection here would be to the
certificates that are already used for things like mime.

Ben: I don't intend to hold this up for a long time.

Alissa: I have a question. This thread from last night about the parallel work
in the HTTP working group; can you summarize what the status is there? We
expect two different efforts that won't end up using the same crypto? What is
the status there? I want to make sure the IESG has an understanding of what's
going on here.

Alexey: I think I agree that it's not clear whether making the two efforts the
same is ... it might cause a delay. It's not clear whether this is necessary.
The way I wanted to address this is by saying the WG will cooperate with
httpbis on messages and make sure much of it can be reused.

Alissa: So you'll add some words to the charter about this?

Alexey: Yeah.

Alissa: Okay. Sounds good.

Amy: With that I think we can move on.

 o WebTransport (webtrans)

Amy: We have a couple of blocks. Do we need to discuss those today?

Barry: We do not. The proponents are discussing it. They unfortunately dropped
the IESG off the copy list for it and I asked them to put them back on when
there's something substantive. I'm in conversation with the proponents and
we'll get that sorted out.

Amy: So similar to the last one, this is in a holding pattern awaiting
instructions from you, Barry.

 o Applications Doing DNS (add)

Amy: I have no Blocks, so is this ready for external review? Unless there's an
objection, it is.

Barry: I want to make sure the change I made to the informational document
ballot is okay with the people who commented on that. The change was proposed
by Ekr. Ben and Adam in particular, are there other things you want me to do to
the charter before we send it out? Ben, you have a couple of editorial things.
Ben and Adam in particular, are you okay with having this go out for external
review modulo a few editorial things?

Ben: Yes.

Adam: Assuming this is the change Ekr proposed, this is the minimal set of
changes that I'm all right with. I had a couple of other comments that I think
could be incorporated but I'm not going to die on that hill.

Barry: Send me an off list email for the main points you think we should tweak.

Adam: They're in my ballot, butI'll reiterate in shorter form.

Barry: I just want to make sure I get the main points.

Murray: The charter variably calls itself "adaptive DNS discovery" and
"applications doing DNS"

Barry: The charter calls itself "adaptive DNS discovery". The "applications
doing DNS" name might show up because that's the name of the BoF that this is
spun off from. That will all get sorted out when it's chartered.

Mirja: Do you think this needs something further before it goes for external
review, or can it start external review?

Adam: I'd prefer to go ahead and tweak it before external review.

Barry: That's my approach as well.

Ben: Those things you said are editorial from me, I'm only mostly sure they're
editorial. There may be a subtle technical distinction involved. Please don't
blindly take it.

Barry: I'll have a look at it and get back to you if I need to.

 o Trustworthy Multipurpose Remote ID (tmrid)

Amy: I have some blocks for this charter. Do we need to discuss those?

Eric: I don't know. I have just sent, one or two hours before this telechat, a
revised charter that I believe fixes Ben and Magnus's issues, as well as a
couple of others. Alissa was kind enough to improve the draft charter. If Ben
and Magnus could have a look and see whether they are okay with the revision,
we can go for external review.

Ben: My calendar claims that they are having a virtual meeting in about three
hours, so I will try to look at things before then. It would be a shame for
them to have to spend their time discussing the charter and not technology.

Magnus: I will have trouble reviewing in that short timeline; I think by Monday
is the earliest I can really review it.

Eric: The only thing is that on Monday I will be on the beach, so external
review will be a low priority for me. Is there any chance you can do it before
Friday?

Magnus: Probably not. I can try but I don't think so.

Eric: I understand. I will try not to forget to contact the Secretariat on
Monday and ask for external review, if you clear your block.

4.1.2 Proposed for approval

 o Reliable and Available Wireless (raw)

Amy: There are no blocks, so unless there's an objection now it looks like this
charter is approved and the WG will be created.

Deborah: I had a last minute comment from Ben to clarify and I think I'll make
some tweaks as he suggested. I'll let you know when it's ready to go.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o QUIC (quic)

Amy: There are no blocks, so unless there's an objection now it looks like this
is ready. Does it need to go for external review?

Magnus: I don't really know what level it is. I'm fine with putting it for
review because it's changed back and forth and everyone should see. I'd think
send it out.

Amy: Okay. This is ready to go out for external review.

Mirja: Sorry I'm super late. The intention of this charter was only to fix some
obvious small things so I don't think we need external review. I just wanted to
state my opinion in case others have the same feeling.

Warren: Nobody is likely to get wildly annoyed if it doesn't go out for
external review. If not I don't think we need to.

Magnus: My state is more, why not?

Warren: As long as the WG can continue getting work done, there's no harm in it
I guess. Okay.

Mirja: I'm fine with 'why not,' but my only concern is we'll see the same thing
that happened on the QUIC list; people will start discussing everything that
should be rechartered. This was intended to only have an interim change to only
fix the things that need fixing, with intention to have a real recharter in the
summer.

Alissa: You can put some words in the announcement that goes out to frame it. I
just think given the level of interest of people outside the IETF who are
paying attention and want to understand what is the next set of steps that's
going to happen here, I do think it's good to send it for external review.

Mirja: But I think that's the confusing part. It doesn't change much, only
small things, and people will ask why things aren't in there.

Alissa: Maybe you can write some sentences to explain.

Mirja: I think that would be useful.

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Mirja: No news.

6. Management issues

6.1 Designated Experts for RFC 8471 [IANA #1156118] (Roman Danyliw)

Amy: Roman has identified Andrei Popov and Dirk Balfanz. Any objection to
approving these two as designated experts for this registry? Hearing none, so
we will send official note to IANA.

6.2 [IANA 1159844] renewing early allocations for
draft-ietf-bess-evpn-bum-procedure-updates (IANA)

Amy: The IESG needs to approve to extend the early allocations.

Michelle: The authors indicated the document is moving along but we just need
to keep the registrations in there until it gets to the finish line.

Amy: Any objection to renewing? Hearing none, so we'll send note to IANA.

6.4 Retreat timing (Alissa Cooper)

The IESG discussed Doodle results for possible retreat dates in April and June,
and whose conflicts might be moveable. Alissa hopes to have dates finalized
within ten days; looking at the June dates with the IESG first and potentially
IAB second.

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

Suresh: Amy, I tried to send a conflict review response but the message hasn't
gone out. Is there something I need to do? I cycled it to Approved,
announcement to be sent and I don't know if it triggered something for you.

Amy: It's supposed to but it may not have. Can you email?

Suresh: I'll send a note. Thanks.

6.3 Executive Session: ISOC BoT confirmation (Alissa Cooper)

6.5 Appeal Discussion