Skip to main content

Narrative Minutes interim-2018-iesg-08 2018-04-19 14:00

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

Narrative Minutes of the April 19, 2018 IESG Teleconference

Narrative Minutes of the IESG Teleconference on 2018-04-19. These are not an
official record of the meeting. Narrative Scribe: Liz Flynn, IETF Secretariat

1. Administrivia
1.1 Roll call

Ignas Bagdonas (Equinix) /  Operations and Management Area
Deborah Brungard (AT&T) / Routing Area
Alissa Cooper (Cisco) / IETF Chair, General Area
Michelle Cotton (ICANN) / IANA Liaison
Spencer Dawkins (Wonder Hamster Internetworking) / Transport Area
Sandy Ginoza (AMS) / RFC Editor Liaison
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
Eric Rescorla (Mozilla) / Security 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

Ben Campbell (Oracle) / Applications and Real-Time Area
Heather Flanagan / RFC Series Editor
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Ted Hardie (Google) / IAB Chair
Alvaro Retana (Huawei) / Routing Area
Portia Wenze-Danley (ISOC) / Interim IAD

Alethia Brown
Eliot Lear
John Leslie
Xiaoyin Liu
Carl Mehner
Greg Wood


1.2 Bash the agenda

Amy: Does anyone want to add anything new to today’s agenda? Any changes?
Great, moving on.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes being approved? Hearing no
objections, we will get those published in the public archive. I did not see
revised narrative minutes from Liz but as she’s been at the IAOC retreat all
week, and I know she had a few edits to make, I didn’t see those go out. We
will keep those until next time. John Leslie: Did you say there’s no scribe
present? Amy: She is on a flight and she will work from the recording.

1.4 List of remaining action items from last telechat


     o Benjamin Kaduk to find a designated expert for RFC 5793 [IANA

Benjamin: That’s still in progress.

     o Adam Roach to find a designated expert for RFC 8225 [IANA #1055836].

Amy: I believe that is provisionally done. We have experts to approve at the
end of the call in the management items.

     o Alexey Melnikov to find a designated expert for RFC-irtf-cfrg-xmss-
       hash-based-signatures [IANA #1053888].

Alexey: Did I send a message about two editors volunteering?
Amy: I did not see one.
Alexey: I have candidates, I’ll pull up on this.

     o Alvaro Retana to find a designated expert for RFC-ietf-bier-isis-
       extensions [IANA #1056644].

Amy: That is also provisionally done, provided you all approve at the end of
the call in the management items.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-nfsv4-layout-types-10  - IETF stream
   Requirements for pNFS Layout Types (Proposed Standard)
   Token: Spencer Dawkins

Amy: This has a discuss, do we have to discuss today?
Spencer: I don’t think that we do. It looked to me like this was going to be a
really easy discuss to resolve. The authors had not started that discussion, so
I pinged them this morning. Amy: That sounded like it was going to be a
revised… Spencer: That would not surprise me in the least. Amy: I will make
that Revised ID needed.

 o draft-ietf-core-senml-14  - IETF stream
   Media Types for Sensor Measurement Lists (SenML) (Proposed Standard)
   Token: Alexey Melnikov

Amy: Has discusses, do we have to discuss them now?
Alexey: I think they are mostly fine, I just want to put Benjamin on the spot
and ask about part of his discuss, the point about base values. Benjamin: I
sent an email about two minutes ago. Alexey: Okay, I didn’t see that. Benjamin:
Do you want me to repeat it? Alexey: Yeah, just do a quick version. Benjamin:
Basically the concern is that in my understanding of the document, the minimum
viable unit that you can be sure you can use is the pack. I’m concerned people
are going to take a non-normalized pack and try to extract individual records
from it and use those and get wrong results, send incorrect commands, things
like that. Because the individual records are dependent on the context within
the pack to get base values from the preceding records. Probably this could be
resolved by just adding a bigger disclaimer, that the pack is the smallest unit
unless you normalize, so you need to be careful about how you use these values.
If a record is lost or potentially lost from a stream, then all subsequent
records are unreliable because they could have been off by base values. Alexey:
All right. I think this one I’ll need to pull up with editors and the working
group, but that’s much better. Thank you. So this will definitely need a new
revision. Amy: Okay, this will go into the substate of Revised ID Needed.

 o draft-ietf-curdle-pkix-07  - IETF stream
   Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for use
   in the Internet X.509 Public Key Infrastructure (Proposed Standard)
   Token: Eric Rescorla

Amy: No discusses, any objection to approving?   Hearing no objection, looks
like this one is approved. I see no notes in the tracker, are there any needed
for this version or is this good to go on Monday? Ekr: Give me a minute to look
over the status of the tracker and I’ll make a note in the chat. Amy: Great,
we’l take a look at the chat. It’ll go into Approved announcement to be sent,
whether it has a qualifier or not. Ekr: I’d like this to be into Approved,
Revised ID needed.

 o draft-ietf-opsawg-mud-20  - IETF stream
   Manufacturer Usage Description Specification (Proposed Standard)
   Token: Ignas Bagdonas

Amy: Has discusses, do we have to discuss them now?
Ignas: I think yes. There was an indication from Ekr that he’d like to discuss
them. Ekr: Ben and I talked about this privately, I’m not sure if he shares my
views. I am still trying to make any sense of what the security model this
document is supposed to implement is. There are two functions  … one of which
is what I’m calling restrict me, which is you say I’m never going to talk on
these channels, so don’t let me, and if you see me doing it I’m probably making
a mistake, and if you see someone trying to do it to me, don’t let them. That’s
totally fine. The second is what I’ve been calling additive, which is: let me
do things you wouldn’t let other people do. It’s the second one that’s
problematic. The reason is because the trust chain from that assertion to
attempting whether that should be accepted. There seems to be, I’m still trying
to make my way through the set of reasoning which allows a switch to make that
conclusion, that this is a valid assertion of enhanced privilege. I had back
and forth with Eliot and I have an email in my inbox from last night that
attempts to explain it. The areas of concern I have are, are you actually able
to validate that the person who’s asserting the L2 addressing question really
does chain all the way back to someone who you trust to ask for privileges.
There are a bunch of places in that that seem pretty shaky. I can keep working
with Eliot if people like. Ben and I talked about this privately and there was
some talk about how this part of it may not be well enough baked to
standardize. I can’t quite tell yet.

Ignas: In principle you see this as something that can get resolved eventually?
EKR: To be honest I’m not sure. There seems to be some unspecified notion that
they’re going to chain back to something which is rooted in some unspecified
PKI. You’d validate a certificate chain, it chains back to a trust anchor, then
I conclude that this manufacturer is entitled to say certain things. That only
worked out for the web PKI, never again. I don’t see how it can possibly work.
Maybe I’m missing something here but I have a hard time seeing how you’d build
an interoperable system. Ignas: I’m thinking how to proceed. If those comments
which were sent with Eliot, if those get in, does this at least have a remote
chance of you becoming more happy with your security considerations? Ekr: I
really don’t think this is a question of security. I think it’s a question of
architecture and design. I understand Eliot is on the call, maybe Eliot would
like to talk about it?

Eliot: Thank you, good morning and good afternoon. Thank you for taking so much
time with me, I know this has been a bit of a challenging draft. The comments
that I would add are twofold. First, it may be a longer conversation than it’s
fair to take on this call. Ekr, I’m happy to work with you offline as much time
as you’re willing to give me, but hopefully resolvable within half an hour. The
basis of the draft is that the devices are connected, there actually is meant
to be an approval process for those devices. There’s really some manual steps
here. It’s not like we in general automatically allow the device to be thrown
on the network just because there’s ... That’s number 1. We tried to make that
clear in the security considerations. Ekr: Sorry Eliot, I just lost 20 seconds
of your audio. Eliot: Can you hear me now? Ekr: Yes, thank you.

Eliot: There is supposed to be an approval process for devices. It’s not like
devices can easily be thrown on the network the first time and be trusted in
all circumstances, unless the administrator has explicitly said that. The
administrator is made the key actor throughout all of these. The second point
is that we actually have at least two parties that want to sign these mud piles
on behalf of devices, and these are not the main actors themselves. I don’t
want to mention names because they’re not going to announce until there’s a
proposed standard. I’m a little bit concerned about a chicken and an egg
problem that might develop. We can talk about that if you want. The third thing
that I’d like to point out is that we need to make a clear distinction in terms
of what it’s offering. It’s really meant to provide authorization for the
device and only as a recommendation to the administrator. It’s not intended to
provide device authentication. We have a ton of standards for that. I don’t
want to duplicate that, I want to leverage that. Those are the points I tried
to convey. With that, maybe I should stop.

Benjamin: I’m sad to say I have not gotten to follow the entire thread yet. It
sounds like Eliot has been trying to clarify that it really is more of Ekr’s
first restrictive case, and a sense of, yes your device may need to authorize
to get on the network at all, but any device that’s authorized to get on the
network would normally have some capabilities. Mud is trying to say I don’t
need all of those, so if you’re going to authorize me to the network at all,
just give me this smaller subset. Warren: I’ve been the chair of OPSAWG when
this came up. I viewed the restrictive use case as being the most likely, and
that it’s a lot better than the way people are often currently deploying stuff,
which is simply plug it in and leave it alone, or plug it in and watch it for
ten seconds, see what it needs, enable all that and walk away. With the
restrictive case of these are the things I want, protect me from other stuff,
that seems like a much better thing than the way people are currently doing it.
And if people choose to do something dangerous, you can’t stop them from
shooting themselves in the foot.

Eliot: If I could just add one last thing, and I apologize for taking this much
time. One of the resolutions that I would propose is that there are cases where
the device may be unauthenticated, and in those cases I propose the device
receive no greater access to the network than whatever the default network
policy is. It should receive no greater access than if the device didn’t have a
mud pile at all. Ekr: Stepping back, I think the restrictive use case is
valuable. I don’t object on principle to the added use case either. What I’m
trying to understand is how the logic behind it works. In the simplest case,
imagine everything else worked perfectly, I received a signed mud file that
says this device is made by manufacturer X, and it should be able to talk to
other devices made by manufacturer X, which seems like a pretty common thing
you might want to think about saying. It changes some trust anchor, how am I
expected to evaluate that? Where do the trust anchors come from? Surely each
independent user doesn’t decide their own trust anchors? The only case I’ve
ever seen this work is web PKI, which largely works because they cabal people
who have defined their own trust anchors and they’re all basically great. 
Absent some story for that, I just don’t understand how this system works.
Eliot: Would you like me to comment? Ekr: Please, or I’m happy to take this
offline if that would be more useful to people. This week was terrible, but I
can talk next week when I’m in Europe.

Eliot: Let me just add one comment about that. The flow there for those
examples would be…I don’t think you want to hear the mechanics of how Json and
Yang get translated into IP addresses, I think you probably get that. The
general idea is that the mud manager, and thank you for suggesting a change of
that term by the way, is going to have either a known set of trust anchors that
the administrator trusts, or has given agency to the provider of the mud
manager itself. So as a case in point, when Cisco develops this, what we would
do is glean some information with the permission of our deployments as to who
has trusted what. When we see a sufficient number of those things we might say,
this signer is trusted. In addition, we expect there will be a couple of
entities, and I’m really not authorized to name them yet, but they actually
want to be that cabal for this purpose. My suggestion is that the worst that
can happen for a proposed standard in this context is that the cabal doesn’t
properly form, and we have to come up with a new idea and we revise it in the
next round. I want to be careful about ending up in a chicken and egg
situation. In the industry we’re in, with manufacturers in particular, people
just don’t move until we’re at least at the level of proposed. We already have
a couple of implementations that are independent, and a couple of people are
interested in provided a PKI signing function. I think you and I can work on
establishing the right set of text around that, if you’re comfortable with what
I’ve just said. Ekr: I have to think it through, but I’m certainly happy to
have a conversation offline. Eliot: Okay. Thank you for your time, everyone.
Ekr: As I said, I’m in Europe next week - a lot of us will be in Europe next
week! - Maybe Eliot and I, and Ben if he wishes, can find some time to have a
conversation on a European time block. Ignas: It seems like there is some way
forward. Discussion stays and both the comments from others, and what has been
discussed and needs to get into the document. Amy: Revised ID needed.

 o draft-ietf-mmusic-rid-14  - IETF stream
   RTP Payload Format Restrictions (Proposed Standard)
   Token: Ben Campbell

Amy: No discusses, any objection to approving? Hearing no objection, this will
go into Approved announcement to be sent::Point raised, for Ben to make sure
everything is to his satisfaction. Adam: You might just go ahead and move it
directly into Revised ID Needed; as an author I can tell you that some of the
comments that came in will require at least small changes. Amy: Okay. Approved
announcement to be sent::Revised ID per an author. Thank you.

 o draft-ietf-mmusic-sdp-bundle-negotiation-49  - IETF stream
   Negotiating Media Multiplexing Using the Session Description
   Protocol (SDP) (Proposed Standard)
   Token: Ben Campbell

Amy: This has a discuss, do we have to discuss now?
Ekr: I think it’s going to require a Revised ID, there’s been a bunch of back
and forth about some of the text. I think it’s clear at this point that at
least the text is technically incorrect. I think that’s a fair statement. Adam,
do you agree? Adam: I believe that’s correct. Ekr: I left a really extensive
comment. At some point it will turn into discussion and Ben will tell me we’re
done. This particular problem needs to be resolved. Amy: I’m hearing Revised ID
Needed is the correct substate for that. Thank you both.

 o draft-ietf-stir-rph-03  - IETF stream
   PASSporT Extension for Resource-Priority Authorization (Proposed
   Token: Adam Roach

Amy: Has a discuss, do we have to discuss them now?
Adam: I believe that we do [need Revised ID].
Amy: This will go into IESG Evaluation: Revised ID needed.

 o draft-ietf-tram-stunbis-16  - IETF stream
   Session Traversal Utilities for NAT (STUN) (Proposed Standard)
   Token: Spencer Dawkins

Amy: Has discusses, do we have to discuss them now?
Spencer: I don’t think so. The author is still working his way through the
sector and genart reviews and has started replying to the discuss ballots yet,
so I think that the only thing worth mentioning now is one of Eric’s discuss
points was about a requirement; there was a should that ICE was assuming was a
must, and I think that’s a discussion in the WG just to make sure that’s not a
surprise to anybody. The other stuff looked easy to resolve. I really
appreciate Alexey’s comments, which were basically, why aren’t you reusing
mechanisms that were designed for what you’re trying to do? That was a really
useful cross-area comment, thank you for that. Does anybody else think we need
to talk more? Ekr: Not on this call, but I think there will be more back and
forth with the authors. Spencer: I think we can count on that! Amy: That goes
into Revised ID Needed, thank you.

 o draft-ietf-uta-smtp-tlsrpt-18 (Has RFC Editor Note)  - IETF stream
   SMTP TLS Reporting (Proposed Standard)
   Token: Alexey Melnikov

Amy: No discusses, any objection to approving? Hearing no objections, Alexey, I
have an RFC Editor note. Is that true for this version of the document? Alexey:
There are good comments. Amy: This will go into Approved, announcement to be
sent, Revised ID needed. You can let us know when that’s all set.

2.1.2 Returning items


2.2 Individual submissions
2.2.1 New items


2.2.2 Returning items


2.3 Status changes
2.3.1 New items


2.3.2 Returning items


3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-bmwg-sdn-controller-benchmark-term-09  - IETF stream
   Terminology for Benchmarking SDN Controller Performance
   Token: Warren Kumari

Amy: No discusses, any objection to approving? Hearing no objection. Do we need
any notes in the tracker? Warren: I don’t believe we do. There were a lot of
useful comments. I don’t think it will need Revised ID. Amy: Approved
announcement to be sent, will go on Monday as usual. [Later: Warren: Can you
make it Revised ID needed, so I remember to address the comments.]

 o draft-ietf-bmwg-sdn-controller-benchmark-meth-08  - IETF stream
   Benchmarking Methodology for SDN Controller Performance
   Token: Warren Kumari

Amy: No discusses, any objection to approving?
Warren: Actually, can you write Revised id needed? Revised ID for the previous
one too, so I remember to address the comments. Amy: I had heard no objections.
Benjamin: I was about to jump in, not to object per se, but to ask that if
we’re going to be producing documents about benchmarking methodology, how much
should we try care that the statistical methods are actually reasonable? We’re
a standards group, not a statistics and benchmarking group, so maybe we don’t
need to care that it’s rigorously correct from an academic perspective. Warren:
We described the methodology, then I assume people who actually publish them —
Whether or not people believe in the results of benchmarking is a separate
thing. Some people have a view that people who publish reports of benchmarks
randomly make stuff up, but that’s aside. These more describe how you do stuff,
and then if you want useful results out of it you need to apply a lot more
rigor than these documents describe. Wow, that was a handwavy answer. Benjamin:
And yet, I am happy with it. Amy: I’ve still got both of these in Approved,
announcement to be sent, Revised ID needed.

3.1.2 Returning items


3.2 Individual submissions via AD
3.2.1 New items


3.2.2 Returning items


3.3 Status changes
3.3.1 New items


3.3.2 Returning items


3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 o conflict-review-young-entity-category-00
   IETF conflict review for draft-young-entity-category
     The Entity Category SAML Attribute Types (ISE: Informational)
   Token: Eric Rescorla

Amy: No discusses, any objection to approving?
Ekr: I’ve been unable to find anyone who has any opinion about this topic, so I
think we can conclude that it’s fine. Amy: Okay, this is approved.

3.4.2 Returning items


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


4.1.2 Proposed for approval

 o IETF Administrative Support Activity 2 (iasa2)

Amy: I have no objections to approving this charter. Any objections now?
Hearing none, we will get that approved and sent tomorrow as we usually do.
Thank you all.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review


4.2.2 Proposed for approval


5. IAB news we can use

Amy: Deborah, anything from the IAB this week?
Deborah: No, there wasn’t anything I caught. They’re busy working on their
agenda, and we’ll see them next week on Wednesday afternoon.

6. Management issues

6.1 [IANA #1056644] Designated expert for RFC-ietf-bier-isis-extensions
(Sabrina Tanamal / IANA)

Amy: Alvaro updated this yesterday and it looks like he has identified 2 people
to be the experts for this IANA registry, Les Ginsberg and Chris Hopps. Does
anyone have an objection to approving Les and Chris as the designated experts
for this document? Hearing no objection, we will send an official note to IANA
with their names and contact information.

6.2 Update to "AEAD Algorithm" IANA registry to point to
draft-nir-cfrg-rfc7539bis (Alexey Melnikov)

Benjamin: I sent the email this morning. I was not 100% sure the Cisco address
was still correct for him, so we’ll see if he replies. Amy: It sounds like
Benjamin, you took action on this already? Alissa: I missed who we were talking
about, but I can tell you Benjamin: David McGrew Amy: Do you want us to add
this as an action item for you so it doesn’t get lost? Benjamin: Yes please.

6.3 [IANA #1055836] Designated expert for RFC 8225 (Adam Roach)

Amy: Adam added this to approve Chris Wendt as the designated expert for the
registry created by RFC 8225. Any objection to approving? Hearing no objection,
so we will send official note to IANA with his information.

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

Terry: Within hopefully the next two weeks, i.e. before the next formal
telechat, I will be closing sunset4. I’m just doing a little back and forth at
the moment with the chairs. Amy: Any other business?

07:47 PDT Amy adjourned meeting.