Skip to main content

Narrative Minutes interim-2022-iesg-19 2022-09-08 14:00

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

Narrative minutes for the 2022-09-08 IESG Teleconference

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

1. Administrivia
1.1 Roll call

Andrew Alston (Liquid Intelligent Technologies) /  Routing Area
Jay Daley / IETF Executive Director
Jenny Bui (AMS) / IETF Secretariat
Martin Duke (Google) / Transport Area
Lars Eggert (NetApp) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Erik Kline (Aalyria Technologies) / Internet Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area
John Scudder (Juniper) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
Amy Vezza (AMS) / IETF Secretariat
Éric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area
Paul Wouters (Aiven) /  Security Area
Qin Wu (Huawei) / IAB Liaison

Roman Danyliw (CERT/SEI) / Security Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Francesca Palombini (Ericsson) / Applications and Real-Time Area
Alvaro Retana (Futurewei Technologies) / Routing Area

Marc Blanchet
Spencer Dawkins
Christian Hopps
Kiran Makhijani
Lee-Berkeley Shaw
Robert Sparks
Greg Wood

1.2 Bash the agenda

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

Paul: Can we add a small item on DNSSEC for and another one for the
executive session.

Lars: I have an addition which is also probably for the executive session.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes from August 25 being
approved? Hearing no objection so it sounds like those are approved. I know the
narrative minutes haven't been out for the full two weeks but I also didn't get
any changes for those; do you want to keep those another couple of weeks or is
there any objection to approving those as well? I'm hearing no objection, so it
looks like those are approved as well.

1.4 List of remaining action items from last telechat


     o Roman Danyliw to find designated experts for RFC 8809 (WebAuthn)
       [IANA #1229681].

Amy: We'll keep this in progress for Roman who's not with us today.

     o Martin Duke to find designated experts for RFC 9297 "HTTP Datagrams
       and the Capsule Protocol" [IANA #1238909].

Amy: This is a new action item for Martin.


     o Robert Wilton, Alvaro Retana, and Warren Kumari to report back to
       the IESG on the impact of COVID-19 to the IETF in October 2022.

Amy: This is on hold until October.

     o Murray Kucherawy and Martin Duke to contact the HTTPBIS chairs about
       the request to register a HTTP/2 Frame Type registration [IANA

Martin: We decided not to do that, I think. We're not going to register the
code point that Google requested. I don't think as the IESG we need to get into
a conversation about changing the policy. I propose we just kill this action

Lars: Why are we not discussing this with the WG?

Martin: For the actual code point request, it turns out that it's an entirely
internal project.

Lars: You're speaking with your Google hat on now?

Martin: There are two things; this specific request, which it turns out not
worth doing because it turns out it's an internal project.

Lars: The request is being withdrawn, is that what I'm hearing?

Martin: it would have been nice not to have to screen these things on our
ingress but…

Warren: But even if it's an internal project, which I don't know anything
about, there is a somewhat regular precedent for code points being assigned for
internal stuff. Otherwise Google is going to choose 63 and somebody is going to
use 63 in the future and it'll either leak from the Google network into the
Internet or when somebody on the internet tries to use it and it doesn't work.
There's still a risk of collision.

Martin: That would be better in my opinion but that's not consistent with the
policy the WG has set up for this registry.

Warren: Should someone at some point say maybe we should have an experimental

Lars: We have a request. It sounded for a minute like Martin said Google is
withdrawing the request. If that's the case, then an email would be nice so we
know it's formally withdrawn. If the request is pending, I think we've got to
go forward with the approach we discussed last time which is to talk to the
HTTPBIS WG about how they feel about this request. I informally looped in Tommy
Pauly because he's on the IAB and we chatted about this on the side a little
bit. The chairs, at least, have heard about this a little bit.

Martin: I think the current situation is, if it's going to be this difficult
then forget it. I think that's the accurate summary of my colleagues here. If
the policy was simpler and didn't require an RFC or whatever, then I think we
would go ahead and request it.

Lars: So if the request is dropped it would be nice to get an email to that
effect. I'm not pushing you to drop it. Otherwise if it's not dropped we have
to figure out what to do with it, and that entails going to the WG.

Martin: Google hat off, I don't know if we want to continue to push the WG
about this policy or not.

Zahed: If it helps, I think the question that you're asking could be best
answered by the WG chairs. If you want to continue, talk to the chairs. If you
think it's too much work and you don't need it, just send us a mail that it's


Martin: My understanding of our discussion last week was that the stated intent
based on the policy for that registry is you better have an RFC and there's
this IESG backchannel if the thing is becoming unnecessarily burdensome. Which
does not really lend itself to these sorts of internal projects. We were going
to push on it because I thought this was going out over the internet. It's not
going out over the internet so the heck with it. If I were an active
participant in HTTPBIS I might suggest we change the policy, but I don't know
if the IESG needs to put in more time.

John: It seems to me like we have an existence proof that the policy on the
registry is wrong, somebody should point that out to the WG, and if they want
to do the right thing they can do it. If they don't, then it's up to them. This
little exercise demonstrates that there's a need for a private use range in
there, I think. That's exactly what you're doing, is private use. But it just
gets punted back to the WG with that observation at this point.

Warren: I know nothing useful about HTTP but I remember that there have been
similar types of things in bgp, where people have said I'll just use this
internally and it will never leak externally, then somebody else started using
it and the world stopped working for some subset of people. Even if it's not
used externally I have no idea what the implication is if one day somebody uses
this in the real world. It seems like somebody should chat with the WG.

Martin: The correct thing for Google to do is to filter out that frame type on
its ingress.

Warren: Until that frame type starts being used externally and suddenly people
want to use it on the internet but Google has filtered it out.

Martin: I agree, but also not my WG. Ultimately if there was a standard that
used this code point we'd probably just change the constant in our code and it
would work fine.

Lars: For this request, if you want to drop it it would be nice to get an
email, otherwise you and Murray are going to talk to the WG chairs. It seems
like somebody should be writing an individual I-D that says there needs to be a
private use range here. I don't care if that's you or somebody else, but that
should also go to the WG and see what they do with it. So my suggestion would
be to leave this open at least until the next telechat to see if we got an
email that withdraws the request or not. We can't simply not do anything with
it, because we got the request.

Martin: All right.

Amy: So this will stay in progress until we get a way forward.

     o The IESG to review the proposed revision to the Tao

Amy: This is on the agenda as a management item today.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-cose-countersign-09  - IETF stream
   CBOR Object Signing and Encryption (COSE): Countersignatures
   (Internet Standard)
   Token: Roman Danyliw

Lars: You might want to refresh; I just cleared my Discuss.

Amy: I have one Discuss; do you think this is going to require a Revised ID,

Paul: Let's discuss this a little bit; we don't need Roman for that. The issue
I have is it actually has a UNIX command but you can see there gem install
cbor-diag. The problem is that with regular occurrences we see that packages
from various installers are either abandoned by the authors, or backdoor
replaced. I'm really nervous to have that exact command in the RFC in the main
body, to say if you do this you can install this software. We have no control
over this if there's ever something where the ownership changes to out of our
control. I wouldn't mind if that was some sort of resource where we
put that code, but I kind of have a problem with saying to install this random
piece of software [in the RFC] because if it's ever backdoored, copies of these
RFCs are all over the internet so we can't undo it or say uninstall this
because it's malicious.

Lars: I agree, actually. I think it would be fine to simply point to the Github
repository where the first line is how to install it. But then it's not in an
RFC. I don't know if they even have a reference to that repository in the
draft, which seems like a useful thing to add anyway.

Paul: I'll take that up with Roman later on. I have no objection to a Github
link or something that points to the software.

Warren: Doesn't that basically apply to any time we talk about any software
implementation at all? You have no way of knowing that certain implementations
are horrendously backdoored.

Paul: But we don't tell them to go and install from a random place on the
internet. At least those commands would be limited to the vendor approved
location and it's on the management of the vendor.

Warren: I think we're giving people a lot more credit than is due, assuming
they would ever do anything like read the code before installing it. But

Paul: If you do a gem install you're not reading the code, you're just
installing it. If we give a github link you can have a look at the link before
you run the command.

Warren: But that's exactly my point. If you point at the source code on github,
like for Bind, yes somebody could go along and read the source code before
downloading it and compiling it. But you know nobody does.

Paul: But that page could be updated to say the bind code has been backdoored,
don't use it anymore. Whereas the RFC text cannot be updated.

Warren: You know what, I don't care. Moving on.

Paul: So I'll talk to Roman about this.

Amy: This will stay in IESG Evaluation and I'm going to put it in AD Followup
for Roman.

Éric V: The problem raised by Paul is much broader than just this draft. I
would love to have this discussion at the IESG level someday.

 o draft-ietf-sidrops-rpki-rsc-10  - IETF stream
   A profile for Resource Public Key Infrastructure (RPKI) Signed
   Checklists (RSC) (Proposed Standard)
   Token: Warren Kumari

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

Warren: Maybe? I looked yesterday and didn't see a Discuss.

Murray: It's [mine] and it's IANA stuff.

Warren: How hard is it to fix this?

Murray: Not hard. I'm already replying.

Warren: In that case, we have just discussed it and thank you Murray.

Amy: Will this be a Revised ID?

Murray: The changes will be small, but yes, it'll need a revision.

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

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-teep-architecture-18  - IETF stream
   Trusted Execution Environment Provisioning (TEEP) Architecture
   Token: Paul Wouters

Amy: I have this as Consensus Unknown, i'm going to change that to a yes for
you. I have no Discusses, so unless there's an objection now it looks like this
one is approved.

Éric V: You may want to make this Revised ID Needed to fix the comments as we

Paul: There are a few comments, so let's put it in Revised ID Needed.

Amy: Okay, this is Approved, Announcement to be Sent, Revised ID Needed.

 o draft-ietf-rats-architecture-21  - IETF stream
   Remote Attestation Procedures Architecture (Informational)
   Token: Roman Danyliw

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

Paul: I see a number of comments so I think it's safe to put it in Revised ID
Needed and I'll ping Roman as well.

Amy: This will go into Approved, Revised ID Needed, and Roman can let us know
when it's ready to go. Thank you.

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-irtf-cfrg-hash-to-curve-00
   IETF conflict review for draft-irtf-cfrg-hash-to-curve
     Hashing to Elliptic Curves (IRTF: Informational)
   Token: Paul Wouters

Amy: Paul did the review for this document. I have no Discusses in the tracker,
so unless there's an objection the no-problem message is clear to go back to
the IRSG. I'm hearing no objections, so that note can go to them.

3.4.2 Returning items


3.4.3 For action

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

 o Stub Network Auto Configuration for IPv6 (snac)

Amy: I have no blocks to sending this for external review, so unless there's an
objection now it looks like this is approved for external review.

Éric V: Just let me fix the charter, because the wording was not clear. I will
clean up the charter a little bit tomorrow my time and then we can go forward.

Amy: Okay, so external review is approved pending edits to the charter and you
can let us know when it's ready to go.

4.1.2 Proposed for approval


4.2 WG rechartering
4.2.1 Under evaluation for IETF review


4.2.2 Proposed for approval


5. IAB news we can use

Warren: There was some discussion on draft-nottingham-avoiding-centralization
and what the future of that will be. I think that will be a document that is
worth people on the IESG having a look at and I will put a link in the chat.
It's interesting. Also, if the IAB is going to be responding to the federal
register's questions on Trade Regulation Rule on Commercial Surveillance and
Data Security. It's unclear if they are going to be responding but it is
something which I think a number of peoples' companies are likely to be
commenting on, also something the IESG might want to have a look at because it
is both architectural and covers stuff we are interested in. I think those are
the primary things.

6. Management issues

6.1 Tao Revision (Lars Eggert)

Lars: I hope everybody has had a chance to look at the new version of the Tao.
Sorry there isn't a very readable diff. Is there any objection to publsihg this
on the website as the current version of the Tao?

Éric V: I didn't have time to review it completely but the beginning is
basically assuming the meetings are occurring in person. There are no words
about hybrid or remote.

Lars: I think that's probably text that's unchanged. If you want to propose

Éric V: No, I have no time to do that. I would have just expected it to [have
reference to that].

Lars: But are you okay with this being published even if it doesn't mention
hybrid meetings?

Éric V: [Nods yes].

Lars: Okay. Everybody else, are you okay with this, or at least not objecting?
Thanks. I'll send a message to the editors and Greg. Oh, Greg is on the call.
Do you need anything from me besides telling you it's okay to go?

Greg: Replying to Niels's email [would be great].

Lars: Okay, I'll do that. Thanks. While we are on the Tao, I'm still waiting
for the gendispatch chairs to tell me what they think the rough consensus was
based on what we are going to do with the Tao going forward. In the meantime,
we're just going to publish this.

6.2 [IANA #1238909] Designated experts for RFC 9297 "HTTP Datagrams and the
Capsule Protocol" (IANA)

Amy: This is the reminder of a new action item for Martin.

6.3 Datatracker and self-contained XML (Éric Vyncke)

Éric V: You know in XML we can basically include files that are either local or
remote. It's kind of dangerous if we put in our XML I-D repository documents
which include documents in other places. So, Robert is on the call and Robert,
please feel free to jump in because he has to explore this much better than I
do. The point is basically to force all the XML I-Ds to have all the includes
done before uploading to the I-D repository so nobody has to do the include
anymore. It's a static XML document.

Robert S: In particular, if the content of the references change, for example,
and you re-render that XML later, you would get the same result and not the
updated reference result. There's an issue on Github that has some of the
details about other places where leaving the wrong includes can go wrong. Where
I'm aiming to take this is that at submission time, there will be a step that
fully expands and executes all the includes, shows the submitter the result,
and then what goes into the repository is the fully expanded draft. The ticket
has discussion about how we make this easy for authors so they can still keep
pronouns for things like references in their source document so that they're
not having to expand and then unexpand. That is technical work to be done but
it is one of the requirements we plan to satisfy when we work towards this
goal. It is a fairly large policy change and we wanted to make sure the IESG
was giving us the direction to go there.

Éric V: Thank you for the explanation, it was slightly different than what I

Warren: I want to know what the implications of this are for people who are
doing things like downloading the draft repositories and parsing them and
things like that. Other than presumably we'll need to upgrade our internet

Robert S: Not particularly. The reference expansion on a typical draft adds
like .2% to the size of the draft.

Warren: I still download and use the text ones for a bunch of stuff.

Robert S: Seriously, size isn't going to be an issue. The important thing is
that at the point of submission, people aren't making a notewell statement. If
there are includes that are left in what was actually submitted, then we don't
have a record of what was actually submitted.

Lars: That makes sense to me, Robert. It seems like in terms of authors, it's
not a terribly big change if they're using modern tools. Specifically kramdown.
I guess authors that author directly in XML will need to change. Or does
xml2rfc spit out a submittable XML?

Robert S: That's what I'm planning to have happen. We're basically there with
prep tool. It would just prep a draft by fully expanding it and the XML that
was the fully expanded result, the authors would get a chance to look and make
sure it got the references they intended for it to get, or other content they
were including with xi:include. And they would not actually have to change
their workflow or how they keep their source, there would just be an extra step
at submit time.

Warren: An extra step the authors have to do? Or an extra step that happens on
the once it's uploaded side? Does this happen before submission?

Robert S: During submission. For the web based submission, authors would go in
and at the point where you normally would wait and see 'did idnits run
correctly?' you would get the 'I expanded your draft, do you want to look at
the bits? Click yes or no.' We can add this to the API for the API submission
if the author wants to look at the expanded bits before it finishes the
expansion process. We can give people the option. Otherwise the API submission
process can just sail past it.

Warren: So for most authors they might not really care about seeing the thing,
but they won't have to change stuff.

Robert S: This is where I'm hoping we can take it.

Rob: Why would we need to ask them to see the expanded one? Aren't the includes
exactly what we would effectively use to generate the output anyway?

Robert S: Some authors still don't trust when they submit the XML, they also
provide text, because we had a long period where was broken.
We're still in a transition period where the bibxml still
sometimes produces surprising results. So if the authors are particularly
particular about what the content of the, for instance, references they had
provided by an include contained, they would want to look to see that the tool
did the thing they expected the tool to do.

Rob: I would just suggest the link to say something like here's the link to see
it, but you probably don't care about it, and that's fine. Or alternatively, if
the tool could diff between what it generates as the text and what you uploaded
and flag any differences, as another way of checking. I don't know if you'd
have other cosmetic differences that would end up being painful.

Robert S: I would have to go review the code to see where we are on this
evolutionary path but we have a long term plan to stop letting people hand us
the text if they're handing us the XML.

Rob: That makes sense to me. I'm broadly supportive of this and I think it's a
good idea. I parse the XML to do grammar checking and things. I'm sure I've set
mine to ignore includes so this is probably good.

Lars: One other thing, I'm thinking about the case where somebody has an XML
that has includes in it, is used to uploading these, we make that change and it
fails. It will be really useful if whatever message is being presented was
actionable so they knew how to fix it immediately and resubmit. The one thing
we don't want is to submit the text only version instead.

Robert S: It's an antigoal to drive people away from submitting XML.

Lars: Right. Something like a friendly 'here's how you should run your xml to
rfc' to generate something we can take in.

Robert S: Agreed.

Lars: Do you want us to minute anything formal that we are okay with this
direction? I guess we will get back to it when there is a bit more?

Robert S: Sure. Just a line that we can point back to to remember we all talked
about it and the IESG was aware and okay with the direction we are headed, and
we can bring it back when we actually have the concrete implementation ready
and people can look again before we pull the trigger.

Sandy: Sorry if you already said this, Robert, but what is the timeline for
implementing this?

Robert S: Hopefully in the next 2 to 3 months.

Sandy: Okay, perfect. As an FYI, we have not tested unprep that well but when
we have run it there have been a couple of issues. We'll do some testing on our
end to make sure it's working for us.

Robert S: To be clear, I'm not thinking we would do a prep on prep thing. IT
would be a prep-lite thing and they could look at the results but they would
still have their source that would be the thing they modify for the next time.

Sandy: So what actually gets stored in the datatracker? So when the RPC pulls
the XML file?

Robert S: The fully expanded version. So you're looking for the ability to get
back to something that would pull references, and this is not intended to be
unprep as currently implemented. It'll have to be something different.

Sandy: Okay, got it.

Lars: I guess we will revisit this when we are ready to try it, and we'll
timeline it so it won't be right before an IETF meeting or something like that.
Maybe the period between 115 and 116. Thank you.

6.5 DNSSEC for (Paul Wouters)

Paul: Jay sent a slack message and he is on the call as well. He was saying
that we might be outsourcing things like hosting or domain name management in
the next weeks or months and maybe it doesn't make sense to do this migration
right now on these custom tools we're using. I just wanted to bring this back
to the IESG and get some input on what people think we should do. Should we do
this anyway with our tools for now or should we move forward?

Jay: To add to that, nothing is going to happen quickly. We're going to have a
process that takes some months to define the new infrastructure strategy. The
current contract with AMS expires at the end of 2023 so our new supply strategy
or whatever will not take effect until the beginning of 2024. That's why I'm
comfortable with you changing signing periods, key strengths, all of that kind
of stuff. The more awkward one about moving to a hidden signer is something I
think is potentially more difficult to achieve in that period of time.

Paul: Okay. That's fair. One of the new items that also came up was that I
didn't realize the RR6 that are used right now on data are valid for
one year. For instance, has been or will soon be changed from an
individual server to our server, and I think that's already happened. But if
someone has that record remembered from nine months ago, they can still play
that record as a valid DNS record because the signature is valid for a whole
year. This is why normally signatures are not valid for more than a couple of

Warren: Yes, they can. I put a link to the standard list of DNS outages. To me
it feels like the threat model of accidentally forgetting to re-sign and having
the signatures go invalid and all of disappears off the internet seems
much larger than the threat model of somebody has kept a copy of a record that
we've changed the TTO of and plays it back.

Paul: Warren, I understand that if you think of it in terms of threat model.
But if you think in terms of what is the policy we are advocating everybody to
use and we're not using it ourselves, it's much more a presentation and
marketing issue. We should use our own recommendations for values we have in
the RFCs and not make up our own.

Warren: I think the advertising and marketing outcome when falls off
the internet because we cocked up the DNSSEC is much more harmful than pretty
much no one has noticed that we've got--

Paul: Yes, but if we reduce the signatures from one year to one month, it's not
going to fall off the internet unless the infrastructure run by Glen is offline
for more than a month. Do we think that's likely? Do we have backups of the
keys so that we can interfere?

Warren: There's a difference between it having fallen off the internet for a
month or somebody deleted the keys, and the job that does the signing didn't
run. But anyway, I think the risk of things not re-signing is much larger than
somebody might think we're using too long a time on the keys. I will just wait
until we fall off the internet. I also think there's a risk when we change the

Martin: So if Glen is hit by a bus do we have a recovery plan?

Warren: The DNSSEC part we could deal with through machinations. We could
recover from that.

Paul: I'm assuming we have backups of the data regardless.

Jay: We have a contract with AMS that requires them to manage such things as
Glen being hit by a bus. It's a black box contract and we don't have some of
the details of things that go on within that contract. So we just have to
assume that this is taken care of for now.

Warren: I'm sure there are backups, but it is a black box contract.

Jay: There are backup systems and we do know some of the details. Robert and I
don't know about specifically accessing the keys and how that's managed within

Warren: The DNSSEC part is trivial. Somebody can log in through the registrar.
My thing is more the embarrassment of when the signer job fails or we try to
change algorithms/key lengths and we break.

Paul: We need to change the algorithm anyway because we're about to publish a
document ourselves that says  MUST NOT use [?]. We simply cannot stay on this
algo. It's not a question of should we do this, it's a question of when to do

Warren: I agree it's when, but if we do it now, and as soon as the contract
ends, we've done it twice.

Paul: Well, maybe. Depending on the new infrastructure we might end up with in
2024 we might just be able to give them our private key and they can just
import the key and run with the same key without doing a rollover. There are
options here.

Warren: I've stated my position. I will happily be in the rough and when it
goes kaboom I will point and laugh.

Paul: Let me propose the following then. Wes and I are going to assist Glen in
setting up a parallel copy that's doing the rollover for some testing. Once
that is functional we will get back to the IESG and look for a final go-ahead.
We can always abort if we don't get that.

Jay: Are you also going to go to the community on the tools-discuss team as

Paul: I'm happy to have more people contribute if this is tied more into tools
or if the tools people are interested in being involved, sure.

Jay: It would be good just to give those people a chance.

Robert S: I think it would be a good idea to leave an artifact on a publicly
archived list that a plan is being developed and there's an opportunity for
other people to say something about it so later when people discover their
cheese has been moved there's something to point to.

Paul: That sounds good. Let me draft up something with Wes and we'll run it
through the IESG first before we send it publicly.

Lars: Was there also a related issue with the TLS certs? Did we talk about
this? Or was it always DNSSEC and I'm misremembering?

Paul: It was always DNSSEC.

Lars: I thought someone mentioned something about TLS….

Robert: We dropped TLS 1 from those certs. That was a change we made at
Cloudflare and nobody noticed.

Lars: Okay, great.

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

Murray: I just emailed everyone about the old/new document , IESG statement we
were preparing. I would love to get that settled so please take a look and tell
me if there are any last comments before we put this to bed.

Lars: We also have the BOF call next Tuesday. I'l be traveling but i hope i can
make it. I saw there are a few BOF requests that are coming in now.

6.4 Executive Session: IESG Appointment to the IETF Trust (Lars Eggert)