Skip to main content

Narrative Minutes interim-2018-iesg-15 2018-08-02 14:00
narrative-minutes-interim-2018-iesg-15-201808021400-00

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

narrative-minutes-interim-2018-iesg-15-201808021400-00
INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2018-08-02 IESG Teleconference

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

1. Administrivia
1.1 Roll call

Amy: We have regrets from Deborah, Alvaro, and Martin; and Sandy is still on
leave.

1.2 Bash the agenda

Amy: Does anyone want to add anything new to today's agenda? Any other changes?
Hearing none, we'll move on.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes from July 5 being approved?
Hearing none, we'll get those posted. Any objection to approving the revised
narrative minutes from July 5? Hearing no objection, we will get those posted
as well.

1.4 List of remaining action items from last telechat

   OUTSTANDING TASKS

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

Benjamin: We have experts, I just want to double check that all four of them
are okay with having four experts for the registry. Probably in two weeks we'll
approve that.

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

Ekr: Still in progress.

     o Alexey Melnikov to find designated experts for RFC-ietf-uta-smtp-
       tlsrpt [IANA #1113903].

Amy: There are two management items for two parts of this document. With those
two management items this is provisionally done, correct?

Alexey: Yes.

Amy: Okay, we will discuss it when we get to the management items.

     o Ben Campbell to find designated experts for RFC 7845 [IANA
       #1114867].

Amy: This is also on as a management item so I'll mark it provisionally done.

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

Adam: Mark that as in progress. Thanks.

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

Amy: Martin could not be with us today so we will keep that.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-oauth-device-flow-12  - IETF stream
   OAuth 2.0 Device Flow for Browserless and Input Constrained Devices
   (Proposed Standard)
   Token: Eric Rescorla

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

Ekr: No, I'm going to have to work through them.

Amy: Is this going to be a Revised ID Needed?

Ekr: Almost certainly.

 o draft-ietf-anima-autonomic-control-plane-16  - IETF stream
   An Autonomic Control Plane (ACP) (Proposed Standard)
   Token: Terry Manderson

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

Terry: No I don't think so. The Discusses were very clear. This is going to
absolutely need a Revised ID.

 o draft-ietf-dnsop-session-signal-12  - IETF stream
   DNS Stateful Operations (Proposed Standard)
   Token: Warren Kumari

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

Warren: I don't think so. I thought that they'd addressed Benjamin's Discuss,
but maybe not. But we don't really need to discuss it. They're going to need a
new ID.

 o draft-ietf-regext-rdap-object-tag-04  - IETF stream
   Registration Data Access Protocol (RDAP) Object Tagging (Best
   Current Practice)
   Token: Adam Roach

Amy: I have a Discuss, do we need to discuss that today?

Adam: No, Alexey says he's ready to clear on that. I think we're going to need
a Revised ID based on some of the comments from other ADs. Maybe based on his
as well. So a Revised ID Needed.

Amy: This will stay in IESG Evaluation with Revised ID Needed, thank you.

 o draft-ietf-codec-ambisonics-07  - IETF stream
   Ambisonics in an Ogg Opus Container (Proposed Standard)
   Token: Ben Campbell

Amy: There are no Discusses in the tracker. Unless there's an objection it
looks like this one is approved.

Amanda: We still need an expert review for this one. An expert is being
designated.

Ben: It's going to be Revised ID Needed one way or the other.

 o draft-ietf-extra-imap-objectid-08  - IETF stream
   IMAP Extension for object identifiers (Proposed Standard)
   Token: Alexey Melnikov

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

Alexey: The author was quite good at catching all the comments so I think this
is ready to go.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 o draft-richer-vectors-of-trust-12  - IETF stream
   Vectors of Trust (Proposed Standard)
   Token: Benjamin Kaduk

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

Benjamin: I think we should let the email discussion with the authors continue.
I don't know that we need to talk a whole lot today.

Ekr: Not a Discuss but I'd like to push a tiny bit on the status of this
document. It seems like it has a modest level of consensus and I wonder if it
should really be informational.

Benjamin: Personally I think I would be okay with that. I did not push very
hard when I first took the document on because I was taking it over from
Kathleen. I believe I'd be okay if we wanted to drop it down to informational.

Ekr: Ultimately this is for you, but I have no objection and I would vote for
informational.

Benjamin: Does anyone else want to speak in favor of one or the other or should
I take it on myself to decide?

Ben: My comment was along the lines of experimental, but either one. I shared
what Ekr was thinking; this seemed like an odd choice to make a proposed
standard given the amount of review it had. The shepherds' writeup did mention
that it got some review on a non-WG mailing list.

Benjamin: They made this dedicated mailing list a few years ago and I joined at
the time, and there were several people who were excited at the time and I
stopped following it in the middle somewhere.

Ben: I'm happy to leave it up to you to decide.

Benjamin: Thank you everyone for the input. I'll circle back with the authors
to figure this out.

Amy: It's in IESG Evaluation, do you want AD Followup or Revised ID Needed?

Benjamin: Let's leave it in AD Followup for now.

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-v6ops-conditional-ras-06  - IETF stream
   Using Conditional Router Advertisements for Enterprise Multihoming
   (Informational)
   Token: Warren Kumari

Amy: I have Consensus set as Unknown. Should that be yes?

Warren: That should be yes. I quickly want to poll people and make sure. In the
document it says this document adopts the approach proposed in blah blah blah
draft. I think everyone will be fine if instead we made that the approach for
proposed in RFC whatever it is. The draft is currently in IESG eval. Basically,
it will be held until the other doc it references is published. Is everyone
okay with that? I can't imagine anyone not liking that, but...

Spencer: I was slightly confused about that discussion. I thought the thought
was to get this out while they figured out the more complicated case.

Warren: The more complicated case is currently in IESG Eval. I'll check with
the authors and see how desperately they want to get it out first.

Spencer: I don't have an opinion about what it should be, I think checking with
the authors is right. There are some where one document is waiting on another
document that's not moving very fast. I didn't know if that was the case.

Warren: That was the case. That document went into IESG eval last week or
something.

Mirja: Jen was worried this would delay the document because the other document
is already in IESG eval. I guess you can check with Martin and try to move this
quickly as well.

Warren: That's the plan. Thank you very much.

Amy: So with no Discusses, I have this as Approved, Announcement to be Sent. Is
it waiting for anything or is it good to go on Monday?

Warren: I'll have a look and let you know after I've chatted with the authors.

Suresh: I put in a comment just before the meeting. There's some missing stuff;
its not a discuss level thing but I would like it if it gets looked at before
the document ships.

Warren: Okay, well in that case it's probably Approved, Revised ID Needed.

Amy: You've got it.

 o draft-ietf-tls-tls13-vectors-06  - IETF stream
   Example Handshake Traces for TLS 1.3 (Informational)
   Token: Benjamin Kaduk

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

Benjamin: It will need to go into Revised ID Needed.

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

 o status-change-change-sender-id-to-historic-00  - IETF stream
   Moving RFC 4405, RFC 4406, RFC 4407 (Sender-ID) to Historic (None)
   Token: Alexey Melnikov

Amy: I currently have no Discusses in the tracker. Unless there's an objection
it looks like the status change is approved.

Alexey: Can I have this in AD Followup? I want to wordsmith a message to IANA.

Amy: So it's like a Point Raised? We'll just hold it until you say it's ready
to go. When you do, because it's a status change we'll be sending 3 separate
announcements.

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 o conflict-review-kunze-bagit-00
   IETF conflict review for draft-kunze-bagit
     draft-kunze-bagit-16
     The BagIt File Packaging Format (V1.0) (ISE: Informational)
   Token: Alexey Melnikov

Amy: I currently have no Discusses in the tracker. Unless there's an objection
it looks like this conflict review message can go back to the ISE. Hearing no
objection, that is approved.

Benjamin: I will jump in, not related to the conflict review itself, but to the
more general topic. I did find a technical comment on the document and given
that we've been talking about the more general topic of how the IESG interacts
with the ISE on conflict reviews, I did not put the technical comment in my
ballot position, so I sent a direct email to Adrian. I felt kind of weird about
that. I'm not sure if that's because it feels like a backchannel negotiation
thing. I just wanted to let people know that I did that and it felt weird, as
further input into our discussion.

Alexey: I think that's just the way it is. I had my own comments as well but
they are not significant.

Spencer: I understand why it would feel weird but I think the point on that is
that we don't have much of a front channel for conflict reviews. So any
guidance we're providing is as individuals to the author and the ISE. Not as
part of our normal balloting.

Alissa: None of the other reviews of independent submissions are public, as far
as I know.

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

 o Registration Protocols Extensions (regext)

Amy: I have no blocking comments in the tracker and it looks like it is going
for Ready without external review. If there are no objections we will send a
recharter announcement.

Adam: I want to probe a little bit. There were several people who commented
that they weren't certain this language was tightly scoped enough. I wanted to
get a feel for how strong the objections are there. The notion here was there
are a small number of docs that they themselves are file formats, but what's
envisioned is they may come other docs in the future that aren't necessarily
file formats but are strictly related to registries. We would like to avoid
having to recharter every time one of those come up, which is why there's a
consultation with the AD clause in there. If anyone who asked about that wants
to speak up, if they feel strongly about wanting to change the language, or if
my explanation makes that okay, I'd appreciate it.

Alexey: When I read the sentence it almost felt like they could do
internationalization or IDN work there. I don't want people to be making the
argument that this type of work is registry related.

Adam: Ah, okay. Do you have any thoughts about how to tighten that down in a
way that would avoid internationalization work?

Alexey: I'll think about it. If I come up with a suggestion I'll let you know.

Ben: What Alexey said was a little more precise than what I was thinking. I was
just wondering if you meant any possible work related to the operations of ID
registries. If that's what you mean, that's okay. It just seemed broader than
what your comments in the ballot sounded like.

Adam: That is kind of the notion. The chances we're going to have any other WG
in the IETF with the expertise of how to work with registries seems very low.
It's almost certainly going to be this group of people. It's not going to be
large enough to warrant a new WG.

Ben: To probe on that, if work came in on the open ID space and it involved a
registry of user identifiers, is that in scope?

Adam: That's a different kind of registry.

Ben: It's a registry that involves internet identifiers, in the general sense
of the word.

Adam: We probably need to clarify that this is for the type of registry that
regext operates on.

Ben: That's where I thought we were going, so that's fine.

Adam: That can be clarified.

Alissa: I understand if there's future
slightly-different-but-not-that-different work that it would involve the same
set of people, but the other thing I noticed in this group in particular is you
have some registry operators who come with a narrow frame of interest. It's
useful to have a more narrowly scoped charter for this group that can help
scope what they decide to take on or not. I can imagine it becoming this very
long lived WG where anybody who wants their new bespoke extension comes and
proposes it, and if there's no charter language that actually prevents that
other than consultation with AD, which maybe is okay but puts a lot of onus on
the AD, that could be problematic.

Adam: Are you advocating for specifically calling out file formats as opposed
to generalized registry work?

Alissa: I think so, yes.

Adam: I'll take that feedback back to the chairs and try to craft some tighter
language. Thanks. We're going to have to hold this one then.

Amy: Adam, you can let us know when you think that's ready.

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Amy: I believe Deborah is on vacation. Perhaps Jeff or Ted will have something
to say here?

Ted: I don't think there's a whole lot to report. Yesterday's meeting we had a
long conversation with the folks from ISOC who are developing next year's
internet report, which is focused on consolidation. We also started talking
about how to make the IAB meetings at least partly open. But because we didn't
have quorum, no decision was reached. I think that's all I need to report.

6. Management issues

6.1 Designated Expert for "Report Types" (section 6.2 of
draft-ietf-uta-smtp-tlsrpt) (Alexey Melnikov)

Amy: Any objection to appointing Murray Kucherawy as the designated expert?
Hearing none, we will send an official note to IANA.

6.2 Revisions to the Tao (Niels ten Oever)

Ekr: There's a pile of comments.

Alissa: I was sort of hoping he would join us but it doesn't look like he did.

Adam: Is there a way to take the comments on that patch and export them in a
flat text file and email them?

Ekr: I regret that I have not done that for Github. I have used Phabricator. I
don't know how, sorry.

Alissa: It's his repo, certainly he's seen the comments.

Adam: I didn't look recently but I didn't see any changes based on the various
comments.

Ekr: I concur he's not addressing the comments. If we want to prompt that we
could send an email saying there are lots of comments and you should look at
them.

Alissa: I'll send him an email and cc the IESG. I know it was my responsibility
to find the editors but I haven't reviewed what the process is. I can take an
action to figure it out.

Ekr: Apparently we have some discretion to process the proposed changes any way
we please. The editor publishes proposed changes in a version somewhere or
other. This process does not contemplate us having a back and forth with the
editor about he content of the document.

Alissa: I'll respond to the thread and point out the comments to him.

6.3 Approve DEs for "Opus Channel Mapping Families" Registry. (Ben Campbell)

Amy: Hearing no objection, these are approved and we will send an official note
to IANA.

6.4 [IANA #1113779] renewing early allocations for
draft-ietf-pce-segment-routing (IANA)

Amy: This needs an extension on an early allocation. Deborah is the AD but she
is not with us today. Is there any objection to the renewal of the extension?

Alissa: It would be nice to hear from her about this.

Benjamin: She sent email.

Alissa: Okay, she said she recommends approval because the document is close to
being ready; it's in WG last call. For me that's fine. No objection to
extending.

6.5 [IANA #1116309] Designated experts for RFC-ietf-stir-rph (IANA)

Amy: This is in progress, is that right?

Adam: That is correct.

6.6 [IANA #1117184] Designated experts for RFC-ietf-trill-multi-topology (IANA)

Amy: This is also on the action item list that we reviewed at the top of the
call.

6.7 Expediting TLS 1.3-related work (Benjamin Kaduk)

Benjamin: Now I'm not sure I actually want to ask for this anymore. We
currently have a cluster of a few documents that are TLS 1.3 related or nearby;
there's TLS 1.3 itself and a bunch of IANA registry updates that we pushed off
into a separate document, then these test vectors. From some sort of abstract
niceness point of view, it would be nice if these could all inter-refer to each
other with RFC numbers instead of referring to the drafts. On the other hand,
we have a lot of people pestering us for TLS 1.3 to be done. I know
specifically Open SSL is waiting on this to push their next stable release. I
was hoping to get some input from other people; do we think TLS 1.3 is urgent
enough we should publish it, or is there some priority to being clean and
having the nice pretty numbers?

Ekr: We can still reserve the numbers, right?

Benjamin: We could reserve the numbers but my understanding is the RFC editor
will not actually publish 8446 that refers to 8448 until 8448 is also
published, so they have to be published at the same time.

Alissa: Alice, can you confirm that?

Alice: If 8446 refers to 8448 by number, then yes they need to be published at
the same time.

Alissa: So we can't publish 8446 before 8448 gets published.

Benjamin: We can, we just have to refer to it as the Internet Draft.

Alissa: I mean, with the reference to the RFC number.

Alice: Typically, no.

Alissa: Is that written down somewhere?

Alice: That's the normative reference concept. Is this an informative reference?

Alissa: They're both informative references.

Alice: Typically, if you want to refer to it by RFC number yes. If there's a
special circumstance and you want to publish something with a pointer to an RFC
that doesn't exist, I would recommend against it. Usually if an informative
reference is not published yet it would be referenced to a draft. And the
question of where this is written down, this is the whole concept of normative
references.

Ted: The problem is anyone who reads it before 8448 appears will say there is
no 8448, because to the general public there's no access to it until it's
actually published. There's a period of time there where the doc is pointing to
something that doesn't exist.

Ekr: What if we put in parentheses (to appear)?

Warren: What happens if we never get around to publishing it because it
explodes horribly or something?

Ekr: This is not a riddle of the universe. I've probably done 50 references to
documents which will be in proceedings with (to appear). I don't really think
this is actually a complicated problemĀ  In my order of ranking here I'm not
willing to wait to publish 8446. So if this is a dealbreaker then let us
reference the ID, if not a dealbreaker let us solve it.

Ted: I think you should reference the ID for now and then we can come up with a
more general mechanism in the future. If we are already at the stage where we
know what RFC number it's going to be, referencing a draft and then including
in the document something like "RFC 8448 to be" seems sensible to me personally
but based on my recent experience is something the rest of the community may
want to weigh in on in loud tones, so I wouldn't want to do this without
warning and discussion.

Ben: How long of a delay are we talking about?

Warren: Especially if we ask for expediting?

Ekr: It's 60 pages of stuff with hexadecimals and it could take a week.

Alice: I think expediting 8448 and referencing it by number makes sense from my
perspective. I can bring the (to appear) option to the RFC Series Editor for
discussion if you like.

Ekr: I oppose waiting for any period of time. I've been working on this draft a
lot of my life and I'm not interested in waiting on it for the test vectors.

Benjamin: My current expectation is to publish 8446 as soon as we get author
approval and refer to the draft for expediency. I do want to ask Alice if she
is willing to give an estimate of how long an expedited version of 8448 would
take; if one week is plausible or totally out of bounds.

Alice: Plausible. Faster, if you want to make this hot and turn it around. But
auth48 is an unknown.

Warren: What if it refers to the draft, and expedite 8448, and if 8448 happens
to be done before 8446 is actually stuck on the site, it can be updated.

Benjamin: So you're arguing we should ask for 8448 to be expedited but not
necessarily block publication of 8446.

Warren: That way if 8448 happens to be done in time, we can actually refer to
it by RFC number. If not, because auth48 takes a while or whatever, then it
gets referred to as a draft.

Alissa: What's the status of 8446? If you push the button today it would be on
the site?

Ekr: Yeah. I was hoping to get it done by Friday.

Alissa: So that's not a realistic scenario.

Ekr: Maybe a day or two. But really, it's just the last couple changes.

Alissa: I mean auth48 needs to last at least 48, right?

Warren: Actually it doesn't have to last 48 hours.

Alissa: They could publish the base document today. For us to expedite a
document which we know doesn't actually need to be expedited....

Alice: To clarify how fast 8446 would come out once approvals are complete,
there's a final step where post xml-to-rfc, because there are specific
pagination requests regarding the contributor section that we can't control
using xml-to-rfc, so there's at least one final check there after the doc is
paginated, before it goes out. It's not immediate.

Ben: I want to promote something in the discussion that was in the chat room
between Terry and I. I'm all for publishing TLS 1.3 as soon as we can, but if
we're just talking about a small number of days delay here, that seems like ...
a month or two from now no one is going to care.

Ekr: To be blunt, I'm speaking about this at Crypto on the 19th and I'm going
to be really unhappy if I have to say this doc isn't finished because we're
waiting for the test vectors to have an RFC number.

Ben: Okay, if there's an external force I'm fine.

Ekr: If its the 6th it's okay, but past there I'm going to be pretty unhappy.

Alice: An expedited request can include dates.

Benjamin: I also have an external forcing function; the open SSL project is
doing a FIPS thing and they have an in person meeting August 27 and they need
to do some preparatory work before that. Most of the people who are full time
open SSL people are currently working on TLS 1.3 and getting their final
release out. tHe idea is that we publish TLS 1.3 RFC, they make their final
changes, push those out, then do their release, then switch over. The timeline
is tight to have a couple weeks to bake their final release. That's the
external constraint I sort of have.

Terry: It sounds to me like we should be giving some very strong feedback that
we should give the RFC Editor that we would like this set of documents to come
out by the 19th, which then obviously meets Benjamin's desire as well as Ekr's.
But I feel very icky about breaking referencing rules for standards. That's
just inherently broken. As much as it would be uncomfortable for you Ekr, that
would be broken.

Ekr: Why don't we remove the citation entirely? They're just test vectors.

Terry: Then if they're not normative references... If you want to do it as RFC
numbers, give some feedback to the RFC editor that there's a timeline and they
can prioritize their own work to meet that.

Ekr: It's not a normative reference, it's an informational reference to this
ID. To be blunt, this need not exist at all. I'm happy to hear from the RFC
editor about what timeline they need, but my experience is that everything
takes longer than we expect it to. If we're a week from today and there's no
chance of finishing, I'm going to want to pull the reference back.

Benjamin: I'd say leave it as an informational reference to the ID and proceed
with publishing 8446. If circumstances happen to collaborate such that we can
change that, we can change it, but our plan should be to publish as soon as
it's ready with this informational reference to the draft.

Ted: That seems like the right thing to do in this case.

Benjamin: Do we want to request expedited processing for 8448 given that we
don't actually expect to need it faster?

Warren: I think yes.

Alissa: I think not.

Benjamin: In my mind, requesting expedited processing is an exceptional thing
to do, that incurs extra burden on the RPC, and we should only do with good
reason. This no longer feels like a good reason.

Warren: This particular document I think is going to require a lot less input
from the RFC editor than other documents because it's largely filled with
random stuff. I think having it available and published will still be useful
for people looking at this stuff. But I don't really care that much.

Alissa: Benjamin, you got what you needed?

Benjamin: I believe so. We're not going to take any action as the IESG here and
I'll work with the authors and chairs to get 8446 published.

6.8 promote Murray Kucherawy to be another primary expert for the Media Type
registry (Alexey Melnikov)

Amy: He is secondary expert currently and you want to promote him to primary.
Any objections to that?

Warren: Did we ever decide what the difference is? I don't care, just wondering.

Alexey: I think there is a semantic difference in that the secondary are not
being asked first, so for some registries they never get to do any work.

Amy: Hearing no objection, so we will send a note to IANA.

6.9 Appointing designated experts for the IANA OAuth Authorization Server
Metadata registry (Eric Rescorla)

Amy: You have one, possibly three people. Is that right?

Ekr: There are in fact three people who have accepted: Michael Jones, Nat
Sakimura, John Bradley.

Amy: Any objection to approving these folks? Hearing none, we will send
notification to IANA.

6.10 IANA Designated Expert for STARTTLS Validation Result Types (Alexey
Melnikov)

Amy: Any objection to appointing Alexander Brotman, Daniel Margolis, and Viktor
Dukhovni? Hearing none, we will send a note to IANA.

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

Spencer: I wanted to let people know; it seemed to me there was a certain
moving around of dates on Quic version 1 coming out of the WG. The chairs are
back to trying to hold to the November-ish timeline for Quic v1. It seems to me
there's a lot of stuff lined up behind that, and we could be getting ready to
open up a floodgate that will affect other areas. I think most of the stuff
Iv'e been talking about with people would require more work in other areas but
some work in Transport to support the work being done in other areas. Just
wanted to give a heads up.

Ekr: For the record, I don't believe the November date.

Spencer: There are two things in play: one is that if they finish in time for
us to not do an IESG switchover during IESG Evaluation, that would be awesome.
I've had that conversation with the chairs and they understand that clearly.
The second thing is they will finish eventually, whether that's November or
March. The same thing will happen once they ship what's now being called Quic
v2. Whatever we end up calling the first deliverable out of Quic. When we came
out with multipath TCP, there was not a huge amount of work in other areas
lined up behind that to use it. It seems like there's a decent amount of work
lining up in other areas to use Quic, whenever it comes out. Just wanted to
give other ADs a chance to think about that. That's all I had.

Ekr: I sent this to Jabber yesterday. In a display of amazing timing, Chrome
has announced they do not intend to ship token binding, right after we approved
it. So that's great. We have no current plan to do so either, nor does Apple.
THat's all a little unfortunate, but there it is. Just thought people should
know.

Ted: Do you think Edge will drop it or keep it?

Ekr: I don't know. Microsoft was pushing it very hard, which is part of how it
got as far as it did. I asked them if they intend to drop it.

Ted: It's an interesting data point. Given that the Chrome argument revolved
around there being other ways to accomplish the same things, it would be
interesting if the Edge folks thought any of those other ways were serving the
same purpose or not.

Ekr: I don't think the Chrome people are right, by the way.

Ted: If they're not right and Edge keeps using it for its intended purpose then
I think we're never going to go beyond its current standardization state, but
then we're in actually a reasonable place because anyone who wants to
understand can look at the docs and say Edge is doing bad.

Ekr: I can ask Edge if they plan to continue and report back. I've been hearing
noises from Google for a while but I concluded that from where we were, it
didn't make much sense to do much about it. I can ask Microsoft.

Adam: And your impression is the Chrome team is unlikely to reverse their
position?

Ekr: Yeah. I don't want to say browsers are all that matters, but this is a
browser specific spec so in this case browsers really are what matters. it's
about hardening cookies and I don't think anyone can do it besides browsers.

Ted: And Mozilla had not yet implemented? Was it in the plan somewhere?

Ekr: No, we have no current plan to support it.

Adam: The publicly stated position was that we would accept patches on it but
had not prioritized working on it.

Ekr: It's reasonable for me to email them based on this news and ask them what
their plans are.

Amy: Anything else from anyone else? Personal note, I'm on vacation next week
so Cindy will be your go-to. Thanks everyone.