Skip to main content

Narrative Minutes interim-2018-iesg-17 2018-08-30 14:00
narrative-minutes-interim-2018-iesg-17-201808301400-00

Meeting Narrative Minutes Internet Engineering Steering Group (iesg) IETF
Date and time 2018-08-30 14:00
Title Narrative Minutes interim-2018-iesg-17 2018-08-30 14:00
State (None)
Other versions plain text
Last updated 2024-02-23

narrative-minutes-interim-2018-iesg-17-201808301400-00
INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2018-08-30 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
Michelle Cotton (ICANN) / IANA Liaison
Spencer Dawkins (Wonder Hamster Internetworking) / Transport Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Ted Hardie (Google) / IAB Chair
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
Alice Russo (AMS) / RFC Editor Liaison
Amy Vezza (AMS) / IETF Secretariat
Martin Vigoureux (Nokia) / Routing Area

REGRETS
---------------------------------
Alissa Cooper (Cisco) / IETF Chair, General Area
Heather Flanagan / RFC Series Editor
Sandy Ginoza (AMS) / RFC Editor Liaison
Benjamin Kaduk (Akamai Technologies) / Security Area
Terry Manderson (ICANN) / Internet Area
Jeff Tantsura (Nuage Networks) / IAB Liaison
Portia Wenze-Danley (ISOC) / Interim IAD

GUESTS
---------------------------------
Richard Barnes (author of draft-ietf-acme-acme)
Daniel McCarney (author of draft-ietf-acme-acme)

OBSERVERS
---------------------------------
Greg Wood

1.2 Bash the agenda

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

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes of August 16 being approved?
Hearing none, it looks like those are approved and we'll get those posted in
the public archive. I also saw revised narrative minutes a couple of days ago;
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 Eric Rescorla to find designated experts for RFC-ietf-oauth-
       discovery [IANA #1113497].

Ekr: No action; in progress.

     o Martin Vigoureux to find designated experts for RFC-ietf-trill-
       multi-topology [IANA #1117184].

Amy: I saw this was down as a management item today so we'll mark that
provisionally done.

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

Amy: Alissa could not be with us today, so we'll move on.

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

Amy: Suresh, this is just to alert you that you have an action item.

Suresh: That's in progress; I'll take care of it.

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

Amy: Ekr, just to let you know this came in not too long ago.

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

Alvaro: Working on that, thanks.

     o Ben Campbell to find designated experts for RFC-ietf-mmusic-rid
       [IANA #1120856].

Amy: I notice Ben has updated that management item naming an expert and we'll
mark that provisionally done.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-acme-acme-14  - IETF stream
   Automatic Certificate Management Environment (ACME) (Proposed
   Standard)
   Token: Eric Rescorla

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

Ekr: Benjamin's not here so we won't discuss his. I was hoping Adam would
clear, since he said he would clear.

Adam: I'll clear when the document comes out. There's still some conversation
going on; I have a back channel to Richard and he suggested Daniel might not be
too happy about the proposal Richard put in there.

Ekr: I think Daniel is here, so maybe we can see if we can resolve that now.

Adam: With the text Richard has in there, I think it's fine. If we're going to
roll it back to something that basically says, in this version of the document
these are still gettable resources without any authentication, then we need to
talk through the correlatability issue. I'm willing to concede I might be off
in the weeds here, but it does seem like the ability to correlate all the
orders associated with an account is a real privacy issue.

Ekr: I'm actually persuaded by that. Had I noticed that in my review, I would
have AD blocked that. So you've got to fix it, in my opinion.

Daniel: How do you build that correlation when you only get the orders list
from an account resource by an authenticated post to the account url?

Adam: It doesn't say that.

Daniel: I think it does.

Richard: The thing Adam noted is that, at least in the examples we've got, the
order list resources have a guessable structure.  if you got one account
resource, maybe your own, you could potentially guess other people's order list
URLs. So you write them that way.

Daniel: I'm not super familiar with the process here, I think this is the wrong
place to hash out the technical discussion. I think the actual URLs as given as
example in the doc, those are up to the server implementer to decide on. We
could just make a comment about not choosing predictable URLS, since that was a
concern of the server operator.

Adam: That's what my comment was, basically, these need to be not predictable.
And you probably need to put some parameters around what 'not predictable'
generally looks like.

Daniel: I'm fine with that, I'm just opposed to changing to requiring posts for
those resources.

Ekr: I didn't think that was what Richard's text said. Maybe I misread it.

Richard: That is in fact what my text said. I was trying to avoid relying on
unguessable URLs as an authentication method, to keep the authentication
concentrated on safe symmetric modality. My PR says that if you have something
you don't want to be gettable, require people to send a post with an empty
body, which was kind of a hack, but was at least generic. If we want to have a
more blended approach that uses posts for some authentication and uses
unguessable urls for some other authentication, we can also do that.  It's just
a little less uniform.

Ekr: It sounds like the authors don't agree, so perhaps the authors can go back
and sort it out. The way Daniel characterized it as, if the server cares, I
don't think is okay. This is clearly sensitive information and we should be
mandating it has extra controls.

Richard: I think we have the outlines of a discussion here, we just need to
have some iteration on the mailing list.

Adam: Thanks everyone.

Amy: Okay, that sounds like a Revised ID Needed. We will mark it as such.

 o draft-ietf-dnsop-terminology-bis-13  - IETF stream
   DNS Terminology (Best Current Practice)
   Token: Warren Kumari

Amy: I have no Discusses, so unless there any objections it looks like this is
approved.

Warren: I think it will be Approved, RID, because there were some useful
comments provided. the WG did feel relatively strongly that it should be BCP,
so I'm going to try and stick with that. Nobody has a Discuss, but does anybody
want to shout strongly against BCP? Approved, Revised ID Needed.

Amy: Approved, Announcement to be Sent, Revised ID Needed and you can let us
know when that is ready.

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-sidrops-rpki-tree-validation-02  - IETF stream
   RPKI Certificate Tree Validation by the RIPE NCC RPKI Validator
   (Informational)
   Token: Warren Kumari

Amy: I have no Discusses, so unless there any objections it looks like this is
approved. Hearing no objection, this is approved. Does it need any notes?

Warren: I think it's good to go. Actually let's do a Revised ID Needed because
some of them might need two or three back and forth to get text perfect. And
thanks Benjamin for the comments.

Amy: Approved, Announcement to be Sent, Revised ID Needed and you can let us
know when that is ready.

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 o draft-york-p-charge-info-08  - IETF stream
   P-Charge-Info - A Private Header Field (P-Header) Extension to the
   Session Initiation Protocol (SIP) (Informational)
   Token: Ben Campbell

Amy: I have no Discusses, so unless there any objections it looks like this is
approved.

Ben: Let's put this in Point Raised. I would like the authors to respond to
Spencer's comments; I don't know if it will require a new revision.

Amy: Okay, let us know when you are satisfied, Ben.

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

 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

 NONE

5. IAB news we can use

Deborah: Nothing I can think of.

6. Management issues

6.1 Designated Experts for TRILL Ethertypes registry (Martin Vigoureux)

Amy: Any objection to approving Donald Eastlake as the primary and Sue Hares as
the backup experts for the registry? Hearing none, we will send an official
note to IANA identifying them.

Martin: Thank you very much.

6.2 [IANA #1119883] Designated experts for RFC-ietf-6tisch-6top-protocol (IANA)

Amy: This was to assign an action item to Suresh, which we talked about during
action items.

6.3 [IANA #1119224] Designated Experts for draft-richer-vectors-of-trust and
ietf-mile-rolie (RFC 8322) (Benjamin Kaduk, IANA)

Amy: Benjamin added this for approval. There are two separate sets of
designated experts to approve here. For draft-richer-vectors-of-trust they are
Justin Richer and Leif Johansson. Any objection to approving those two people?
Hearing none, so it looks like they are approved and we will send an official
note to IANA. The next one is the draft ietf-mile-rolie. The experts are David
Waltermire and Stephen Bangheart. Any objection to approving those? Hearing no
objection, we will send that official note to IANA.

Alexey: I think there is also a more generic question here for Michelle about
when we actually happen to include IANA instructions in writeups. Do we need
separate management items for approval or not?

Michelle: The names of two experts were included in an approval announcement
but we didn't actually have a management item with the official approval. So my
question to the IESG was do we accept that as an approval if expert names are
listed in the writeup, or do we actually need a management item to approve the
expert?

Alexey: Do you have a preference?

Michelle: I don't think so. Either way works for us. If we do have experts
announced with the approval of the document, we can put it in the registry
right away. Often we're not that ahead of schedule and we usually are asking
for experts later on. Either would work for us, it's really a matter of what
you think is acceptable.

Alexey: I know that when you create a writeup, there's a field for IANA
instructions. I'm usually never organized enough to pick experts on the spot so
I usually delete the section but if others are organized I think that's fine.
Another interesting question is if people are always reading shepherding
writeups. Some people can miss this.

Ben: That can change after approval, too, the notes. Do we really need formal
management approval of these? If we do, it seems the notes doesn't necessarily
get us that. I'm not sure why we do, but there's probably history there I may
not know.

Alexey: Are you suggesting we should always do a management item?

Ben: I'm saying if we really need formal approval we probably need the
management item. I'm agnostic about it.

Alexey: Any other thoughts? Does anybody other than me and Ben care?

Ekr: All I care about is that someone somewhere write down what I have to do.

Ted: I put some history into the jabber chat but the basic point was that there
have been discussions/objections in the past. I suspect that if you took those
to the IESG list and did them as informal, anybody got any heartburn kind of
calls, you could get the same issues and resolve them informally.

Warren: To me it seems like we spend a long time on these calls doing these
expert discussions and I so far have only ever seen people say yeah, okay,
whatever. I wasn't aware of what Ted posted that there have been discussions in
the past.

Michelle: What about: If the experts' names are present when the document is
being discussed on the telechat, can it be brought up then? Amy usually says,
are the notes correct? We can say at that point there are notes to designate so
and so as experts, is that approved? Then we avoid additional management items
later on, but at least it was brought up and discussed as approving the experts
as well at that point in time. We can try that and see how it works out. Like
Alexey said, this is the first time this has happened in a really long time,
because usually the experts aren't named at the point the document is approved.
If that's something we can do more of that's great, but often we don't ask for
experts until the document is actually approved. Let's give that a try and
we'll see how it goes.

Warren: As an additional thought, what might be helpful is that when IANA does
their review, if you notice an expert is required, letting the AD know - just a
reminder, if you know who this person is going to be, please stick it in the
document.

Michelle: We can start doing that. We can give that a try and see if that helps
you out.

Spencer: I'd like to agree with that. Some of us go chasing experts a lot more
often than others. For the ones that don't go chasing experts often, it
probably is helpful to have someone who thinks about this more often than we do
ask the embarrassing questions.

Michelle: Okay, I know what to do going forward now and I'll discuss it with
the team. Let's see if that helps.

Amy: Do you want to record that in the minutes, or just that it was discussed?

Michelle: I'll put something in Jabber for the minutes.

6.4 [IANA #1120853] Designated experts for RFC 8411 (IANA)

Amy: We reminded Ekr of that action item at the top of the call.

6.5 [IANA #1120855] Designated experts for RFC 8401 (IANA)

Amy: We also let Alvaro know that's a new action item for him.

6.6 [IANA #1120856] Designated experts for RFC-ietf-mmusic-rid (IANA)

Amy: We got email not so long ago from Ben naming Adam Roach as the designated
expert for this registry. Any objection for Adam taking that on? Hearing none,
Adam is approved and we will send the official note to IANA.

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

Amy: Anything anyone wants to bring up today? Hearing nothing from anybody, so
it looks like we had a short call today.