Narrative Minutes interim-2018-iesg-16 2018-08-16 14:00
narrative-minutes-interim-2018-iesg-16-201808161400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2018-08-16 IESG Teleconference

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

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
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
Alexey Melnikov / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
Alvaro Retana (Huawei) / Routing Area
Adam Roach (Mozilla) / Applications and Real-Time Area
Alice Russo (AMS) / RFC Editor Liaison
Jeff Tantsura (Nuage Networks) / IAB Liaison
Amy Vezza (AMS) / IETF Secretariat
Martin Vigoureux (Nokia) / Routing Area

OBSERVERS
---------------------------------
Arun Arunachalam
Peter Dawes
Ben Schwartz
Greg Wood

1. Administrivia
1.1 Roll call

Amy: We have regrets from Spencer, Sandy, Ekr, and Ted is still out.

1.2 Bash the agenda

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

1.3 Approval of the minutes of past telechats

Amy: Does anyone have any objection to the minutes of the August 2
teleconference being approved? Hearing none, those are approved. I did see
revised narrative minutes sent earlier this week; is there any objection to
approving those? Hearing none, so those are approved as well.

1.4 List of remaining action items from last telechat

     o Benjamin Kaduk to find an additional designated expert for the AEAD
       Parameters registry.

Amy: I saw that as a management item so we will hopefully approve that, and
this will be marked as provisionally done.

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

Amy: Ekr could not join us today so we will keep that in progress.

     o Adam Roach to find designated experts for RFC-ietf-stir-rhp
       [IANA #1116309].

Amy: It looks like that is also a management item so it will also be marked as
provisionally done.

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

Martin: Still working on it. I have one name; do I need two names?

Michelle: We can start off with one name and get another if needed. Having one
is better than none.

Martin: Okay. I'll look a bit for a second one and I'll submit the one name I
have.

Amy: When you want to get one or both approved, just put it as a management
item on a future teleconference.

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

Alissa: That's done.

     o Alvaro Retana to find designated experts for RFC-ietf-idr-bgp-
       prefix-sid [IANA #1118995].

Amy: This is also a management item so it will be marked as provisionally done.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-insipid-logme-marking-12  - IETF stream
   Marking SIP Messages to be Logged (Proposed Standard)
   Token: Ben Campbell

Amy: I have one Discuss in the tracker and unfortunately it's someone who is
not with us today. Ben, is this going to be a Revised ID Needed or AD Followup?

Ben: It's going to need a Revised ID, and the conversation is moving to email,
so no need to discuss here.

Benjamin: I agree the conversation is moving in email, and I know I did not
ballot a Discuss. I just wanted to ask, are we staring down a slippery slope
here or am I just being a paranoid security guy?

Ben: Can you elaborate on the specifics?

Benjamin: We're specifying a thing that could be used to log the session
headers, and maybe it could evolve into logging content as well and letting
them do it without user consent.

Ben: I understand that and the idea that a proxy can do this on behalf of a
user is something I expected more controversy over, honestly. You probably
missed that we had this controversy once before because there was a
requirements document that covered this and we argued about that one for some
time in the IESG and made them move a lot of things out of it. In this
particular case there are some things in there that instinctively make me
concerned but at the same time, what this is really intended to do is reduce.
The status quo is often log everything.

Benjamin: I don't think they made that clear.

Ben: The real value in this is having marking done by either the end user or a
network administrator; someone who has the authority to make these decisions.
You can cut down on logging for the messages and it's not necessary for
troubleshooting purposes. And if you think they should strengthen that argument
then I would wholeheartedly agree with you. There's more in it than there
originally was but if you think it needs more I would not object.

Benjamin: I don't think it needs more. The particular content of this document
is not really objectionable, so I didn't ballot Discuss. Thank you for the
discussion, it is reassuring. I think we should move on.

Amy: Thank you; this will go into Revised ID Needed and we will move on.

 o draft-ietf-radext-coa-proxy-06  - IETF stream
   Dynamic Authorization Proxying in Remote Authorization Dial-In User
   Service Protocol (RADIUS) (Proposed Standard)
   Token: Benjamin Kaduk

Amy: I have a couple of open positions here for Terry and Alexey. Do either of
you want to state a position?

Alexey: No, I didn't have time to finish reviewing it.

Terry: Same. No thank you.

Amy: Do we need to discuss any of the Discusses?

Benjamin: I believe we do; just the procedural one. There are 2 conflicting
schools of thought here. We have this one base spec that's an informational
document. There's not an explicit applicability statement as to why it as
informational and not standards track. Then we've got this new thing coming
along that's an extension to it and the question is, can we make the extension
a proposed standard while the base document is informational? On one side we
can say this is completely new, it's green fields, nobody has it deployed, so
we can say that anyone who does implement it implements it this way, and the
extension will be interoperable. The other school of thought is that you can't
do anything with this extension without also doing the base spec.

The base spec is inherently not interoperable because the implementations at
the time didn't want to have the IETF say they were not compliant, and they
didn't want to change. If you require doing this base thing and the base thing
is inherently in this wishy washy state, by trying to say that the extension is
proposed standard, you're implying there are some proposed standard worthy bits
in the base spec that you're incorporating by reference. Am I summarizing your
point accurately, Ben?

Ben: That's pretty close. I'll add that our normal policy is that you don't
downref, but we have exceptions for that and we regularly approve exceptions.
My argument there is that in this particular case, this is not a small
dependency. A lot of times the exceptions are referring to a security algorithm
draft that are all informational or we're referring to a terminology or an
architecture draft or we're referring to a little piece of something that's
informational. When I say a little piece, I mean compared to the overall
document doing the referral. In this case what you have is a small extension on
top of a greater work and that greater work is informational. What I don't see
is if it's not possible to inter-operably implement the base spec, I don't see
how I  could inter-operably implement that plus a little more. Even if the
little more is well defined.

Benjamin: Caveat that I'm not a radius expert per se but my understanding is
there are plenty of deployments who use different vendors and manage to talk to
each other just fine and do their federation scenarios. The different vendors
specify in their documentation, we use this one of the two possible
interpretations, so you should send us this info and not the other info. People
manage to make it work.

Ben: The right way to handle that argument would be to promote the base spec to
standards track. As he said, I don't think there's probably energy in the
radius community to do that. If I understand correctly, most of the
specifications in the radius area are informational. Or at least a large number
of them.

Benjamin: That was the impression I got from Alan's mail but I did not
specifically check.

Ben: In any case, I'm wiling to make that argument and then step away from it.
If other people think it's okay to do the standards track, I'm fine with that.
I just wanted to make sure we'd thought about that.

Benjamin: I had to raise the downref issue before I started the last call,
because they had originally been citing 5176 as an informative reference, which
is hilarious. I think if we did need to drop down to informational that would
be okay, but they did explicitly make the decision they wanted this to be
standards track. Hoping to get some more opinions on the call today.

Adam: I'm having a hard time reasoning about it. It doesn't seem terribly
important, I guess?

Ben: I see a mild agreement but don't feel strongly, and indifference, in
jabber. At this point I'm willing to clear, and Benjamin you can handle this
however you think.

Benjamin: I'm somewhat leaning towards switching to informational, partially
for consistency with the other documents and partially because that seems to be
the slight sense of IESG.  It is odd to have this be an exception that is
proposed standard.

Ben: I'll add one other comment, which is the fact that nobody cares about this
surprised me a little bit, and I'm okay with that. But it makes me wonder if we
should look at how we handle downrefs. This is the core of the original reason
not to allow downrefs. If we feel like our class of exceptions to downrefs
rules incorporates this, we might want to consider whether we want the rule in
the first place.

Benjamin: That's a good point.

Ben: Okay, I'll clear and leave it to you.

Amy: It sounds like this is going to require a revised ID?

Benjamin: Yes.

 o draft-ietf-regext-allocation-token-09  - IETF stream
   Allocation Token Extension for the Extensible Provisioning Protocol
   (EPP) (Proposed Standard)
   Token: Adam Roach

Amy: I have a couple of Discusses. Do we need to discuss either today?

Adam: Benjamin, do you think things are moving along for your concern?

Benjamin: Probably. Im not sure that I'm communicating terribly effectively
with the authors but hopefully my latest response from last night will help. I
think Ben also had a question about, What is this actually for? What is the
token itself? Getting that clarified would help quite a bit.

Adam: I think a lot of the responses in Ekr's thread end up addressing that.
I'm happy to see how the email plays out. We're going to need a revised ID here
with at least some clarifying text so move it to whatever's appropriate for
that.

Amy: Okay, we'll put it in Revised ID Needed.

 o draft-ietf-doh-dns-over-https-13  - IETF stream
   DNS Queries over HTTPS (DoH) (Proposed Standard)
   Token: Adam Roach

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

Adam: It's also going to need to go into Revised ID needed, the authors have
one ready to go but I asked them to wait until after the telechat.

Amy: It's going into Approved, Announcement to be Sent, Revised ID Needed.

 o draft-ietf-sidrops-ov-clarify-04  - IETF stream
   BGP RPKI-Based Origin Validation Clarifications (Proposed Standard)
   Token: Warren Kumari

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

Warren: Sounds good to me. There are a couple of nitty things that I think the
authors have already fixed.

Amy: Ready to go as is so it looks like this will go into Approved,
Announcement to be Sent.

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

 NONE

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

 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: I don't have any.

6. Management issues

6.1 [IANA #1116309] Designated experts for RFC-ietf-stir-rph (Adam Roach)

Amy: Any objection to assigning these tasks to those Martin Dolly and Subir
Das? Hearing none, this is approved and we will send a note to IANA.

6.2 [IANA #1118524] Upcoming Parameter Expiration: Early IANA Allocation for
draft-ietf-idr-bgp-extended-messages (Alvaro Retana)

Amy: We got this from the IANA and Alvaro has an update.

Alvaro: This parameter is expiring and we're renewing it for the 3rd time,
which means we need IESG approval. The draft is already in WG last call and I
expect to see it before the end of the year.

Michelle: So the question is, does the IESG object to extending this parameter
registration for another year, since the document is on its way?

Amy: Hearing no objection to that, so it sounds like the IESG is approving the
extension of the early allocation. Do you need an official note for that?

Michelle: Yes we do. Something saying the IESG has approved the extension would
be perfect.

6.3 TLS registry updates (Benjamin Kaduk)

Benjamin: We have the column in most of the registries for 'is this recommended
by the IETF or not?' and we have a few things that are yes that should probably
be no, because they have authentication tags that are only 64 bits or 80 bits,
respectively, which are appropriate in some cases but not really appropriate
for general use. We need an IESG action to make the change from yes to no. Does
anyone object?

Amy: Hearing no objection, so it looks like this has been approved. Benjamin,
did you want to send a note on behalf of the IESG to IANA or would you like us
to do that?

Benjamin: I don't actually know how this is expected to work.

Michelle: Is this for the recently published RFC?

Benjamin: Yes.

Michelle: Is this something we needed an errata for?

Benjamin: That's debatable. I had a conversation with the chairs and other
AD/author and none of us had a particularly strong preference, but it seemed
reasonable to us to do the IESG action and not worry about having an erratum.

Michelle: The question for me would be if the RFC actually has the yeses and
nos in it, and now we're going to be changing them, those two pieces of
information aren't going to match up.

Benjamin: The whole point is that we want people to look at IANA, and what's
actually in the text in the document isn't expected to be current. The text of
the document doesn't explicitly say yes or no for each one, it just says the
list of ciphers from section B dot whatever all get yes. That was sloppy
editing on my part, but we have an easy way to fix it.

Michelle: Okay, just making sure. So since we haven't really done this bit
before I don't know who should send the message to us; we just need a message
explaining what should be done in the registry, which nos should turn yes and
which yeses should turn no.

Benjamin: I would be happy if the Secretariat sent that, since they seem to be
the main contact point for IESG approvals.

Michelle: That's fine with us. Amy, do you have the exact information to send
to us?

Amy: Benjamin, if you could confirm exactly what we should send to IANA, we
would appreciate that.

Benjamin: Probably what I put in the text of the management item is sufficient
but I will check.

6.4 Designated experts for AEAD Parameters registry (Benjamin Kaduk)

Amy: Does anyone object to approving Bjoern Tackmann and Stanislav Smyshlyaev
as designated experts for this registry?

Alexey: I don't have any objection; they probably just need a bit of a hand
from the ADs when the first registration comes in because they're relatively
new to the IETF.

Benjamin: David is staying on, so he will be able to help if he's available at
that time.

Amy: Hearing no objection to approving these folks as experts for this
registry, we will mark that as approved.

6.5 [IANA #1118995] Designated experts for RFC-ietf-idr-bgp-prefix-sid (IANA)

Amy: We are looking to approve designated experts for these registries. Does
anyone have an objection to naming Acee Lindem and Hannes Gredler? Hearing no
objection, so these are approved and we will get official note sent to IANA.

6.6 Approval of appeal response (Alissa Cooper)

Alissa: This was just meant to minute our approval of the latest version of our
appeal response. Anyone object to minuting our approval of that?

Amy: Hearing no objection, so we can minute that approval.

Alissa: I will send it in response to the appeal message on the IETF list. Then
the Secretariat just posts the content of that to the appeals page?

Amy: Yes I believe so. If it's publicly posted you don't have to send us a
ticket; we'll take it from the publicly posted.

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

No other business.