Skip to main content

Narrative Minutes interim-2021-iesg-01 2021-01-07 15:00
narrative-minutes-interim-2021-iesg-01-202101071500-00

Meeting Narrative Minutes Internet Engineering Steering Group (iesg) IETF
Date and time 2021-01-07 15:00
Title Narrative Minutes interim-2021-iesg-01 2021-01-07 15:00
State (None)
Other versions plain text
Last updated 2024-02-23

narrative-minutes-interim-2021-iesg-01-202101071500-00
INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2021-01-07 IESG Teleconference

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

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) / Transport Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Wes Hardaker (USC/ISI) / IAB Liaison
Benjamin Kaduk (Akamai Technologies) / Security Area
Erik Kline (Loon LLC) / Internet Area
Magnus Westerlund (Ericsson) / Transport Area
Martin Vigoureux (Nokia) / Routing Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Barry Leiba (Futurewei Technologies) / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
Alvaro Retana (Futurewei Technologies) / Routing Area
Amy Vezza (AMS) / IETF Secretariat
Eric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area

REGRETS
---------------------------------
Jay Daley / IETF Executive Director

OBSERVERS
---------------------------------
Nick Banks
Mike Bishop
Chris Box
Rob Brown
Lars Eggert
Adrian Farrel
Brenda Lyons
David Millman
Lucas Purdue
Rene Struik
Greg Wood

1.2 Bash the agenda

Amy: Does anyone have anything to add to today's agenda? Any other changes?
Hearing none.

1.3 Approval of the minutes of past telechats

Amy: Does anyone object to the approval of the minutes from December 17? I'm
hearing no objection. Any objection to approving the narrative minutes from
December 17? Hearing no objection to approving those either.

1.4 List of remaining action items from last telechat

     o Alvaro Retana, Benjamin Kaduk, and Murray Kucherawy to look at
       updating the I-D Checklist.

Murray: I have a version out for review. Alvaro and Barry have been commenting
and I just sent it out to the whole IESG and I'll also remind Sandy and
Michelle to look at it, so everyone finally has something to review.

     o Alvaro Retana and Martin Vigoureux to draft text on guidance
       regarding the number of document authors on documents.

Alvaro: We haven't made progress since last time. We're going to pick up the
discussion and probably include Warren, in the next week or so.

     o Roman Danyliw to draft text for a request to the Tools Team to move
       BoF requests from the BoF Wiki to the Datatracker.

Roman: I haven't done anything since we last spoke, I'll pick this up now in
the new year.

     o Alvaro Retana, Warren Kumari, and Barry Leiba to draft clarifying
       text on Errata Best Practices.

Alvaro: We also haven't done much on this one, we should pick it up soon.

     o Martin Vigoureux and Alvaro Retana to work with Jay Daley on the
       process for using EthicsPoint incident management software as
       the mechanism of private feedback and anonymous reporting.

Martin V: I haven't worked on this for the past few weeks, I need to pick it up
again. Let's keep it in progress.

     o Erik Kline to find designated Experts for RFC  8915 [IANA #1179647].

Erik K: No progress.

     o Warren Kumari, Deborah Brungard, Stephen Farrell, and Jay Daley to
       investigate ways to recruit, recognize, and retain volunteers in the
       IETF.

Warren: This one is actually still in progress. Not a huge amount of updates
since last time but we have met since the last telechat and we've reached out
to a couple of other organizations to ask how they interact with their
volunteers and help recognize them.

     o Erik Kline to find designated experts for RFC 8928 [IANA #1183445].

Erik K: In progress.

     o Ben Kaduk to find designated experts for RFC 8935 [IANA #1184035].
     o Ben Kaduk to find designated experts for RFC 8879 [IANA #1184206].
     o Ben Kaduk to talk to Kathleen Moriarty about status of
       draft-seantek-ldap-pkcs9

Ben: All three of these are in progress.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-emu-eap-tls13-13  - IETF stream
   Using EAP-TLS with TLS 1.3 (Proposed Standard)
   Token: Roman Danyliw
   Was deferred by Benjamin Kaduk on 2020-12-16

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

Roman: I think there's two flavors of Discusses. One is around the binding to
the TLS WG, and I think we need to keep talking on the list to resolve that.
Our discussions here aren't going to resolve that, so thank you Ben for
bringing that up. I guess I wanted to talk with you though, Robert, on your
more process editorial related set of feedback. I sent something three minutes
before the conversation so I think the bottom line is, the way we talked at the
last telechat, we don't have common semantics on "update." I don't disagree
with everything you're saying in terms of the clarity we'd get with
streamlining, but there's a bunch of work associated with that and since we
don't have common semantics, it seems to me at least that it's a nice-to-have,
not a need-to-have.

Rob: I think the key one is actually whether the previous document should be
obsolete or not. Obviously by it being an update to it, you can't obsolete the
one that's got a dependency on TLS 1.2.

Roman: Right.

Rob: So is that something we want longer term, to have the one that relies on
TLS 1.2 hanging around and not being able to be obsoleted, when TLS 1.2 has
been obsoleted? I guess that's the key question.

Roman: I don't know whether we have the WG feedback that we're obsoleting it
despite the fact that TLS 1.2 is obsoleted, in terms of the cascading effect on
EAP.

Rob: But presumably we can't obsolete this document if we're updating it for
TLS 1.3. That's the bit that doesn't make sense to me, if this is the one going
forward, and updates that one that we then obsolete, doesn't that by definition
mean that the one for TLS 1.3 would end up being obsoleted? That's my main
concern. If it's that this is too much work to change and it would be too hard
to do, fair enough, I'm not going to block on this. But it does feel that it's
going to be probably confusing and potentially causes issues longer term.

Roman: I'll take this offline with you. I guess I'm missing something here and
it'd probably be more efficient to address it offline.

Rob: Okay, that sounds fine.

Roman: I think we're good, in terms of talking about this document.

Amy: Is this going to require a Revised ID to clear those Discusses?

Roman: I think it will, yes.

Amy: Okay, this will go into Revised ID Needed.

 o draft-ietf-tls-external-psk-importer-06  - IETF stream
   Importing External PSKs for TLS (Proposed Standard)
   Token: Roman Danyliw

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

Roman: We do not. I think that's good feedback. I think we're going to need a
Revised ID here.

Amy: Okay, this will stay in IESG Evaluation with Revised ID Needed.

 o draft-ietf-quic-transport-33  - IETF stream
   QUIC: A UDP-Based Multiplexed and Secure Transport (Proposed
   Standard)
   Token: Magnus Westerlund

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

Magnus: I think we could spend a little time to just check where we are on
things. Let's start with Ben's.

Ben: I was trying to take some notes in the earlier part of the call. So I
think I got some good responses from several people, actually, and probably
things would be better if some of the information that came out in email could
make its way into the document. In particular, to summarize my current
understanding, currently I think we have two ways that you can find out, and do
a kind of service discovery that you can talk QUIC to another end point. At
least in terms of some in-band method, if you have some out of band thing
that's your own custom thing. We've got the HTTP alt service and I think the
service B DNS record. If I understand correctly, both of those will tell you
which version of the protocol to use, and that would obviate the need for in
band QUIC version negotiation at the present time. So there's in that sense not
an urgent need for the negotiation. I was trying to double check what the
current text in the document that is not slated for removal actually says, and
if my notes are correct we say it is left for a future version of QUIC to
define this, but we don't give any qualifications on who would be doing that,
what future version it might be, in particular it seems like a future non IETF
version of QUIC might feel empowered to do so, and that might risk a free for
all. I would kind of expect we'd want to limit this for a future IETF version
of QUIC to define, and that would give us more freedom to make sure we get it
right and to avoid the explosion of competing things that only sort of work. So
I think some of the key points from the email to get into the document are
about how we decided it's better to not have anything than to have something
that's broken, if you only have one version then you don't need the
negotiation, we plan to have it in the future in a future IETF version, and
until there is the official version negotiation you effectively have to treat
each version as its own thing. I think the practical effect is that we prohibit
in-band version negotiation until there is an official version negotiation
method, and in light of the current state of discovery and whatnot it doesn't
sound like that's going to be a problem. Obviously I'm just reading some of
these emails this morning so I still have to digest everything, but that's sort
of my current thinking on what the right thing to do is.

Magnus: Yeah. The WG is already discussing having a draft solution for the
version negotiation problem, but it's on the WG's table going forward now after
version one being approved. So we can focus more on that.

Ben: To reiterate, I do not think that we need to delay the publication of this
document until we have a version negotiation thing.

Magnus: It sounds like you're maybe asking for a clarification or a tightening
of the language around that saying that due to versions you need to check if
there exists a mechanism and then use that IETF mechanism that's specified for
this.

Ben: That's my understanding of what my preferred outcome would be.

Magnus: From my perspective it sounds reasonable. Let's go check that with the
WG and I hope that should be fine.

Ben: I will send mail on that thread after the telechat.

Magnus: Okay, good. Rob?

Rob: Yes, so I'm quite conflicted on this in terms of the spin bit. I'm not
really happy with how it's defined at the moment, but at the same time I
appreciate that there's been a lot of discussion on this in the past that I've
not been involved in and the WG consensus is on the text around where it is. I
don't like the fact that the behavior is entirely unspecified if you don't
support it what you're meant to do, and that's left really ambiguous. It feels
to me that the option to introduce random noise when the spin bit is turned off
is entirely pointless in a sense you're able to filter it out, so I don't
understand why the spec would actually encourage someone to do something that
takes effort to do and has no benefit. However, I appreciate that trying to get
these changes would be contentious and I think I'm probably in the rough, so
I'll probably change my position to Abstain. That's the pragmatic answer here.
I don't want to block a QUIC draft going forward.

Magnus: From my perspective the rough consensus has been fairly rough in
establishing, getting to this point. Starting this discussion I think could
take significant time to reestablish if that's okay, etc, and people might go
further into this requesting additional changes. I'd prefer to not change this,
I think it's one of the most tricky.

Warren: I agree with what Rob said. I think it's fairly clear that a number of
the people in the WG really did not want the spin bit, so I think the way that
it's being defined and implemented to me feels like it's intentionally made
difficult to use and less useful. But I think I'm in the rough here. I think it
hurts manageability but I understand that's my view, and many operators' views.
I think this is a case where having the protocol move forward is important so
I'm holding my nose.

Magnus: On the aspect of when the spin bit is spinning, it has been proven that
getting a signal out of that when it's actually spinning compared to being
randomly set or fixed, etc, is not a real issue. There is an implementation
experience with that.

Rob: Yes I agree, but I think the question is then, why go to the effort to
introduce the random noise in the first place? Does it actually have any
benefits?

Warren: To me, adding random stuff, not just saying make it always be zero if
you're not doing spin, makes it significantly harder to implement and use. It
makes it so that it's really hard for me to, for example, in a router type
device, try to figure out stuff from this. It basically makes it almost
unusable for network devices to actually get and act on this data.

Ben: I think it's making it very explicitly clear that this is not a reliable
signal in any means. Even if the thing that ends up requiring an eighth of
connections to not use it, that also makes it not a reliable signal but it was
sort of a reliable signal for the other ones. The random thing is, this is
definitely an unreliable signal so don't build key infrastructure on top of it
because it's not reliable. That's sort of the vibe I was getting.

Warren: But it's not just that it's not reliable, I can't even now make
heuristics based upon it.

Magnus: So yes, you need to capture multiple RTTs, etc, of a sequence of
packets for a flow to determine what is the actual RTT sample. But there's an
aspect of why this is random which I think should be clear, which is that in
case this fails in deployment in some sense, by actually setting it random etc,
there's no built in middle box behavior that will not accept, etc. I think
that's one of the aspects where this random comes from, it's ensuring that by
exercising the bits, independent of if the spin bit is used or not, those bits
are active and live and it's not assumed that they will have a particular
[inaudible, Webex beep] and it's only that we let through. This is part of this.

Warren: To me this does not feel like greasing, to me this feels much more like
we don't actually want this to be usable by middleboxes, or at least by router
type middle boxes, so we make it so you'll need to pay a lot of attention to
the stream. Whatever the case, I'm abstaining. I disagree with this but the
protocol itself is sufficiently useful.

Martin D: Magnus is right, it's about greasing. We're not sure how widely
deployed spin bit is going to be, and we have some indication, but if it turns
out to be a relatively small part of internet traffic.... The general principle
in QUIC has been to grease everything we can. This is another example of that.
If spin bit turned out to be very unpopular in the wild and it always turned
out to be zero, that would be an ossification opportunity.

Warren: I think setting it like this makes it that it's almost definitely not
going to be deployed, because my big expensive routers cannot look at it so I'm
not going to deploy it. But you know, whatever.

Rob: Just in terms of the greasing, it sets it once per connection, either to
zero or 1. Would that not be sufficient to grease the bit? Does it need to
randomly change on a per-packet basis? But again, I'm with Warren here. I don't
know if we need to discuss it further.

Magnus: I don't know if it would be sufficient or not. I guess we're not going
to get further here.

Mirja: I think the two options exist because they are implementation tradeoffs.
If you do it on a per-connection basis you still have to hold state. If you do
it on a per-packet basis it's really easy to implement.

Rob: That's very useful information. I don't know if that would be worth saying
in the document. It hadn't occurred to me.

Mirja: I don't think the document gives a strong recommendation about what you
should do, it just says you should kind of grease it or not set it to a
permanent value, right?

Rob: It says you should either set it randomly per packet or you should set
it-[cut off]

Mirja: These are the two options you have.

Rob: The third option is to set it to zero. The only other comment here, while
we're talking about greasing, the behavior if it's not supported is undefined.
If you don't support the spin bit at all, implementations can set it to zero or
one or do whatever they like. It's only if you support spin bit but it's
disabled, you're obliged to follow those two SHOULDs.

Mirja: I think that's a good point we should address.

Rob: I'll put that back to the authors, and I'll change to an Abstain. Thanks
for the discussion.

Eric V: About all the QUIC documents, the chair put all my comments and most of
the comments from others in GitHub, which is fine, but I would still be curious
to see the reply on my comments. If the WG could be nice enough to reply by
email, that would be really cool and appreciated.

Magnus: On that point, I haven't discussed it but your reviews resulted in 150
different issues and because it's a combination of the WG's GitHub process
here, this looks like so many comments are late. I will take that discussion
with those who brought it up. I think this is one aspect of GitHub and
comments-[interrupted]

Mirja: I believe the request was similar as Lucas just put in the link to each
GitHub issue he created, as soon as that issue is resolved he can send one more
email saying this is resolved here, this is resolved here. I think that's the
request.

Eric V: Yes. It's just a wish.

Alissa: In mine they tagged me so I got email automatically.

Martin D: You can also subscribe manually.

Mirja: I do fully understand the request to get some notice that everything has
been resolved so you have a trigger to look at it again if you want to, rather
than feed the whole discussion into email.

Magnus: Yes, but I think in this case you are going to get to see a revision
where this is resolved. Unless you want to engage in particularly I think you
probably have to look into GitHub and follow your issues, or you can see this
is what the WG concluded on your comments. I think that's where we're probably
going to end up here, so you will get a new revision. So on this document, this
is Revised ID Needed.

Amy: Okay, so this will stay in IESG Evaluation, Revised ID Needed.

 o draft-ietf-quic-recovery-33  - IETF stream
   QUIC Loss Detection and Congestion Control (Proposed Standard)
   Token: Magnus Westerlund

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

Magnus: I still think we can put all the QUIC documents in Revised ID Needed.
They are too interlinked.

Amy: This will go into Approved, Announcement to be Sent, Revised ID Needed and
you can let us know when they're released.

 o draft-ietf-quic-tls-33  - IETF stream
   Using TLS to Secure QUIC (Proposed Standard)
   Token: Magnus Westerlund

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

Magnus: Ben, are you happy with the discussion?

Ben: I'm pretty happy with the discussion. The second point is not an issue.
The first point I think we have agreement on what to do that will require some
text changes, in that I think Martin proposed something and I proposed that we
should do that. I think Martin may be asleep or buried under a deluge of IESG
comments on the cumulative documents, so I have not gotten that explicitly
confirmed yet. But I don't think we need to talk about it today as the IESG.

Magnus: Okay, good.

Amy: So like the others it sounds like this is going to be a Revised ID Needed.

 o draft-ietf-quic-invariants-12  - IETF stream
   Version-Independent Properties of QUIC (Proposed Standard)
   Token: Magnus Westerlund

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

Magnus: Put it also in Approved, Announcement to be sent, Revised ID Needed.

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-detnet-security-13  - IETF stream
   Deterministic Networking (DetNet) Security Considerations
   (Informational)
   Token: Deborah Brungard

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

Deborah: I don't think so, unless someone wants to. Thanks everyone for their
careful reviews. The authors are communicating so I'd say keep it in IESG
Evaluation and Revised ID Needed.

Amy: Thanks Deborah.

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 o draft-carpenter-eligibility-expand-09  - IETF stream
   Additional Criteria for Nominating Committee Eligibility
   (Experimental)
   Token: Alissa Cooper

Amy: Consensus is currently set as Unknown; I'm going to change that to Yes.
There are no Discusses in the tracker, so unless there's an objection it looks
like this is approved.

Alissa: Great! Put it into Point Raised just so I can check with the authors.

Amy: Okay, I'll put this into Approved, Announcement to be Sent, AD Followup.

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-yang-tls-tls13-sm-suites-01
   IETF conflict review for draft-yang-tls-tls13-sm-suites
     draft-yang-tls-tls13-sm-suites-06
     ShangMi (SM) Cipher Suites for Transport Layer Security (TLS)
   Protocol Version 1.3 (ISE: Informational)
   Token: Benjamin Kaduk

Amy: There are no Discusses in the tracker, so unless there's an objection now,
this conflict review can go back to the ISE. I'm hearing no objection, so this
is approved with the note that's currently there and we'll send this no-problem
message on Monday.

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

Alvaro: I missed the IAB meeting yesterday but I can report that the IAB
confirmed the IESG slate from the Nomcom and it was minuted last night. Hoping
we'll all have news soon.

6. Management issues

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