Skip to main content

Narrative Minutes interim-2021-iesg-03 2021-01-21 15:00
narrative-minutes-interim-2021-iesg-03-202101211500-00

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

narrative-minutes-interim-2021-iesg-03-202101211500-00
INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2021-01-21 IESG Teleconference

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

1. Administrivia
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
Lars Eggert (NetApp) / incoming IETF Chair, General 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 (Google) / 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
Francesca Palombini (Ericsson) / incoming Applications and Real-Time
 Area
Alvaro Retana (Futurewei Technologies) / Routing Area
Zaheduzzaman (Zahed) Sarker (Ericsson) / incoming Transport Area
John Scudder (Juniper) / incoming 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
---------------------------------
Mike Bishop
Alan Findell
Matt Joras
Brenda Lyons
Lucas Pardue
Adam Roach
Rene Struik
Dmitri Tikhonov
Greg Wood

1.2 Bash the agenda

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

Alissa: I think it would be nice to take a minute here to welcome our new area
directors, who are all with us today. Thanks for joining and for agreeing to
serve the IETF community. There's lots to learn but there are lots of people
here to help you. We're really happy to have you all and glad we have a few
weeks here for everybody to get settled in before we do the handover. Thanks
and welcome.

Alissa: I also have an agenda bash, to add on this
draft-carpenter-eligibility-expand document. I'd asked the RFC Editor to do
expedited processing so we could get it published before IETF 110, but I didn't
mention that to anybody in the IESG so I think we need to minute that or
something.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes from January 7 being
approved? Hearing no objection so we will get those posted. Does anyone have an
objection to the narrative minutes from January 7 being approved? Hearing no
objection there.

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've gotten lots of feedback, thanks. Sandy has been very busy dealing
with the C238, and so have I, so there hasn't been update from either of us. I
can probably get a finished version together by the next telechat.

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

Alvaro: Still in progress. We have to pick it up again after we discussed it in
December and we haven't done that yet.

     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'm still a little behind. I'll tackle it next week.

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

Alvaro: In progress.

Barry: I'll take an informal action for the three of us to set up a call for us.

     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 sent some text to Alvaro and Wes for review a few hours ago. Once
we agree on that we can get back to Jay to start playing with the interface. In
progress.

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

Erik K: In progress.

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

Warren: Still in progress.

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

Erik K: Still 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].

Ben: These two are both in progress.

     o Ben Kaduk to talk to Kathleen Moriarty about status of
       draft-seantek-ldap-pkcs9

Ben: In some sense this is done, because I heard back from Kathleen and heard
back that the change control for PKCS9 has been transferred to the IETF, so in
theory we should be able to proceed and publish this document. But if we go and
actually look at it, it hardly has any ballot positions that are still valid. I
think we need to assign a new responsible AD for it and probably bring it back
onto a telechat or maybe run another IETF Last Call since it's been so long?

Amy: Sure, is there an AD who wants to pick this up?

Ben: I guess it seems likely that it should be security area. I guess I can
take it over.

Roman: We can sort it out. I missed the bubble a little bit on what to do
there. We'll sort it out, Ben.

Amy: So it sounds like this action item is done, and we'll see this document
again.

     o Rob Wilton to find designated experts for RFC 8819 [IANA #1186621]

Amy: This is to let you know you have an action item, Rob.

     o Robert Wilton, Alissa Cooper, Alvaro Retana, and Warren Kumari to
       report back to the IESG on the impact of COVID-19 to the IETF in
       January 2021.

Amy: This is the action item that was taken off the list earlier and put off
until January.

Alissa: I checked with Alexa yesterday and I'm just double confirming the
mailing list and I-D submission data. There are some new numbers in that
spreadsheet we were using in December and I will confirm with her later today
whether they reflect all of December or not and I will re-share the link once
it's updated.

Amy: Is this [action item] to continue in progress?

Alissa: Yes.

     o Murray Kucherawy to find designated experts for RFC 8839 [IANA
       #1187517].

Amy: Murray, this is a new action item for you.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-tls-oldversions-deprecate-11  - IETF stream
   Deprecating TLSv1.0 and TLSv1.1 (Best Current Practice)
   Token: Benjamin Kaduk

Amy: I have no Discusses in the tracker, and a long list of Yeses, so unless
anyone has an objection now, this document is approved.

Murray: I was just going to say, I don't think I've ever seen a document with
ten Yeses.

Ben: It is pretty rare. I think some of the quic documents came close and some
of the status change ones on this week are close. There were some good comments
that came in. Let's leave this in AD Followup.

Amy: I also have to ask the question, because there are so many of them. There
are a lot of downrefs on this document; I know not all of them are appropriate,
like all the Proposed Standard ones. There's also a long list of Experimental,
Informational, and Historic documents that would go on the downref list if
that's appropriate.

Ben: We do not expect to update the downref registry with any of those. I'm
pretty sure the shepherd writeup was clear about that.

Amy: Okay, I haven't looked at that yet. I just saw the long list here and
thought I'd better ask. So none of these should be added to the downref?

Ben: Correct.

 o draft-ietf-bess-evpn-proxy-arp-nd-11  - IETF stream
   Operational Aspects of Proxy-ARP/ND in EVPN Networks (Proposed
   Standard)
   Token: Martin Vigoureux

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

Martin V: It's really up to the two Erics to say. Jorge told me that he would
react soon. Since there are many questions and comments, maybe it's better to
let him do that. It's up to you guys. I have to admit that I didn't have a lot
of time to review your Discuses so I might not have all the answers.

Eric V: Honestly this is a good and useful document, so there's no objection of
mine on the purpose of it. Speaking of IPV6 NDP, this is very intricate and
complex and I'm afraid the authors did not spot all the complexities.

Martin V: I kind of agree with you. Please go on.

Eric V: Basically everything is fixable, but it needs to be fixed.

Erik K: I only sent this in last night in my time zone, so maybe we should give
the authors more time to respond and see what happens.

Martin V: Okay. Thank you very much for your reviews.

Erik K: To ask a question, this is like the second time this situation [has
happened], the other document was the ND flags document. Should these documents
be run by 6man, or should I talk to the 6man chairs to ask them if they want to
take a look at them, or find some way to get 6man involved officially?

Eric V: And V6ops too.

Martin V: I'm happy either way. I think having the WG or the chairs to review
the documents is perfectly okay. We've had a similar situation with Alvaro
asking for a specific BFD and IDR review on [a document]. I'm okay if you want
to give a heads up to the group, please do, otherwise I'm happy to do it.

Erik K: Eric and I have a sync after this so we'll discuss what to do. Thanks.

Eric V: We should also do it for v6ops too.

Martin V: That was included in my mind but I didn't say it explicitly. On the
other hand, that's a discussion I've had with Alvaro is that those documents
went through IETF Last Call so in principle everyone has had the opportunity to
comment on it. I'm not reluctant to having a new review by a specific WG or
WGs, but....

Eric V: Those IETF Last Calls are not reaching the right people. This is not
the first one, it happens quite often.

Martin V: Maybe we should find a way to flag documents so that the relevant WGs
get a specific notification. If it's just a matter of us ADs doing it, it's not
always clear which WG would need to review which document.

Ben: One thing I've been attempting to do is look at the Last Call
announcements when they go out and ask myself if it would be particularly
relevant to any of the WGs I'm responsible for, and try to forward it on at
that time. But I don't always get everything.

Erik K: That sounds like something I should do. Thanks Ben.

Martin V: So Amy, this document can be Revised ID Needed. I'll wait for Jorge
and then discuss with 6man and v6ops.

Amy: Excellent, this will stay in IESG Evaluation and go into Revised ID Needed.

 o draft-ietf-mpls-spl-terminology-05  - IETF stream
   Special Purpose Label terminology (Proposed Standard)
   Token: Deborah Brungard

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

Deborah: Thanks. We'll keep it in AD followup. Loa had exchanged some email
with Ben and they I believe will be updating some of it and uploading a new
revision. AD Followup.

Amy: Great, that will be Approved, Announcement to be Sent, AD Followup and you
can let us know when that's ready.

 o draft-ietf-core-dev-urn-10  - IETF stream
   Uniform Resource Names for Device Identifiers (Proposed Standard)
   Token: Barry Leiba

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

Ben: I did have a question. I balloted quite late. The document sort of says
that this is taking over a couple of subtypes from the OMA LwM2M and I wasn't
really sure what that entailed or how much had actually happened in LwM2M. If
there was a reference I didn't see any discussion of this there, so I was
looking for a bit more clarity on that.

Barry: I saw your ballot. We're going to keep this in AD Followup while we get
the authors to respond to that.

Ben: Great, thank you.

Barry: So Amy, AD Followup please.

Amy: Great, that will be Approved, Announcement to be Sent, AD Followup and you
can let us know when that's ready.

 o draft-ietf-spring-sr-yang-29  - IETF stream
   YANG Data Model for Segment Routing (Proposed Standard)
   Token: Martin Vigoureux

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

Martin V: Very quickly. Roman, I understand your question but I think what
you're asking is already identified in the first bullet. The last three which
only mention DoS, don't affect directly forwarding. They are configurations out
of which labels would be allocated, the label blocks. But these are not the
bindings which are effectively donned by the node. So I don't think you could
have, by messing up with the label blocks, you could do anything on forwarding.

Roman: Maybe I'm misunderstanding. My read of the current document  was that I
would use this to make labels and describe the routing set of these labels, and
I fully recognize that if I could create arbitrary labels I could create a DoS
in the system. That made sense to me. But it would seem to me that if I had the
power to create a DoS, that would suggest that I can create labels in such a
way that traffic drops or goes someplace else, which would then argue that I
can get a node to go to perhaps not completely arbitrary but domains or places
I control that get you to the point where I could subject you to increased
inspection or route around controls. I wasn't looking for anything big, other
than something to the effect of that sentence in addition to the reiteration
that DoS occurs.

Martin V: You perfectly understand. What I meant is, let me find the exact
sentence. There is a sentence in section 9 which says for the bindings,
"Modification to the local bindings could result in a Denial of Service (DoS)
attack. Additionally, the addition of bindings could result in traffic being
redirected to the router." I believe that second sentence corresponds to what
you expect, no? Or are you expecting something different?

Roman: Maybe I don't understand what it means to be redirected to the router.
Does that mean the same thing as directed to an arbitrary route or an arbitrary
path?

Martin V: No, because the bindings are for the prefixes that the router owns.
You can only mess with the association between a label and a prefix that router
owns.

Ben: I understand how that works for the local prefixes, but we also have some
nodes for connected prefixes. My understanding was that the connected prefixes
were not exactly addresses the advertising router owns, but they can connect to
and are outside of the SR domain.

Martin V: Not sure what you mean by connected prefixes?

Ben: There's a node connected prefix SID map, bindings tree, subtree? [pause]
Maybe we shouldn't try to answer it on the call.

Martin V: I'll try to follow up with you. I understand and agree with your
comment. I felt that it was covered in the text for the bindings and I also
felt that it doesn't apply to the other bullet points, namely the label blocks,
because those don't have any direct impact on forwarding. But let's see what
Acee answers, and I can jump in if necessary. Okay?

Ben: That works for me.

Roman: Makes sense.

Martin V: Amy, this one will be Revised ID Needed. Thank you very much everyone
for your reviews.

Amy: Okay, this will stay in IESG Evaluation and go into Revised ID Needed.

 o draft-ietf-quic-http-33  - IETF stream
   Hypertext Transfer Protocol Version 3 (HTTP/3) (Proposed Standard)
   Token: Magnus Westerlund

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

Magnus: I don't think so, unless any of the Discuss holders want to bring up
something. The WG needs time to react to and discuss these.

Amy: Sounds like this is going to require a Revised ID?

Magnus: Yes.

Amy: Okay, this will stay in IESG Evaluation and go into Revised ID Needed.

 o draft-ietf-quic-qpack-20  - IETF stream
   QPACK: Header Compression for HTTP/3 (Proposed Standard)
   Token: Magnus Westerlund

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

Magnus: I think we should put it in Revised ID Needed anyway because it's
linked to the HTTP one.

Ben: I decided that I did not need to put a discuss on for the examples because
the only things I was concerned about were in the prose attached to the
examples, and the actual protocol bit seemed okay.

Murray: Alan is an author of this and Matt is co-chair of Quic. They're on the
call and I just wanted to say congratulations on a cluster of documents very
well done.

Roman: Hear hear, that took a tremendous amount of work to get across the
finish line and we're almost there.

Eric V: And the documents are perfectly readable, even to non experts, and
that's quite unusual. So congratulations.

Amy: Excellent, this will go into Approved, Announcement to be Sent, Revised ID
Needed and hold there until it's ready. Thank you all.

 o draft-ietf-pce-association-policy-15  - IETF stream
   Path Computation Element (PCE) Communication Protocol (PCEP)
   extension for associating Policies and Label Switched Paths (LSPs)
   (Proposed Standard)
   Token: Deborah Brungard

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

Deborah: Thanks. We'll do it as AD Followup. Ben as always has a very careful
review, and several nits the authors will be updating for. The other point was,
Ben, I don't know if you want to discuss your email, which was just targeted
for the IESG on implementation. I might say on this one the routing area we
have different measures of how we [phone noise] documents and some of them are
quite strict that they require two implementations. Here in the PCE group we do
not have that and we often say there are no implementations but there was a lot
of interest, considering the variety of the authors on this document. On this
one I would not be concerned that we actually do say here in this document
there's an implementation, because that section will be removed from the
document so it's not like we're commercializing one vendor's implementation. So
that's my take on it. That's how we consider it in PCE.

Ben: Thanks for the extra background. I definitely don't have the extra context
there so I'm not particularly concerned, I was just noting that I didn't have
much data. If you have more information and you're not concerned, that works
for me.

Deborah: In a way I think it is good to remove it for publication. I think it's
fine and we're very careful that we don't require two implementations like they
do in some of the other routing groups.

Ben: Okay, thanks.

Amy: Great, that will be Approved, Announcement to be Sent, AD Followup and you
can let us know when that's ready.

2.1.2 Returning items

 o draft-ietf-cose-x509-08  - IETF stream
   CBOR Object Signing and Encryption (COSE): Header parameters for
   carrying and referencing X.509 certificates (Proposed Standard)
   Token: Barry Leiba

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

Ben: I think probably Approved is correct. We had an interim yesterday morning
and we did mention briefly a couple of the Github issues and underlying topics.
I think the WG has not really had a great progress towards clear agreement on
those topics, but I also think they're not controversial and so we have some
flexibility to do what looks like the right thing.

Barry: I guess Revised ID is probably the best. It's going to be a Revised ID.

Amy: Okay, thanks, that will go in Revised ID Needed.

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

 o status-change-tls-oldversions-to-historic-01  - IETF stream
   Moving TLSv1.0, TLSv1.1, and DTLSv1.0 to Historic (None)
   Token: Benjamin Kaduk

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

Sandy: I have a quick question. Do you want us to move these documents to
Historic when the I-D is approved for publication, or when the RFC is actually
published?

Ben: That's a good question. My understanding of the process that we have
documented is that the RFCs are moved to Historic when the status change
document is approved. And then we have this intermediate period where the
reference documents are Historic but the indication of why that happened is the
status change document. Then a few months later we publish the RFC and then
we're supposed to remember to go back and update the fields in the datatracker
to point to the RFC instead of the status change document. We don't, to my
knowledge, have a great way to remind ourselves to actually go and do that.
We've been looking at these changes for long enough that it's the right thing
to do to move them to Historic now, and not wait for the other RFC.

Sandy: Okay, that sounds good.

Michelle: I know you and I are talking on the side about what IANA needs to do
here, if anything, as far as reference updates and making sure if the first
document in the agenda needs to say anything. We just want to make sure if
there's any reference updates we need to do or not.

Ben: I think there was the note in the approval announcement that talks about
replacing the status change document as the reference for the status change
event, and I'm pretty sure that just means fiddling some bits in the
Datatracker. At least that aspect of the approval does not affect IANA but I'll
double check if there are any other IANA actions in the cluster of status
change stuff.

Amy: So it sounds like this one is ready to go?

Ben: Yes. Nothing but net.

Amy: This is Approved, Announcement to be Sent, and we'll send that on Monday
as usual.

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-teas-pce-native-ip-15  - IETF stream
   Path Computation Element (PCE) based Traffic Engineering (TE) in
   Native IP Networks (Informational)
   Token: Deborah Brungard

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

Deborah: We'll keep it as AD Followup since there are revisions to be made. I
thank everybody for their very careful reviews of this informational document.
Thank you very much. Maybe for the new ADs this might help a little bit. It's
always difficult to decide if a document is informational or experimental or
what. On this document, early in its lifetime it was very iffy what it was even
trying to propose. As it went through its evolution they decided they could do
it with PCE. If we had done this with the maturity and continued on
experimental, it would have meant experimental instead of PCE extensions, which
have already gotten pretty far along. So we decided to make it informational,
and it is only an architecture document. It went to informational because of
the chain of impacts it would have had if it had gone to experimental. Once we
get to PCE extensions, if there was uncertainty there, we could maybe make
those experimental. It would be interesting to have the experiment defined,
which was actually my first critique on this document. As I say, so far the
feedback from them has been that they feel there's not really a need to make it
experimental. So that's always questionable, if you want to make something
experimental you have to think of the long term impacts. Thank you everyone.

Amy: So this will be Approved, Announcement to be Sent, AD Followup and
Deborah, you can let us know when that's ready.

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 o draft-foudil-securitytxt-10  - IETF stream
   A File Format to Aid in Security Vulnerability Disclosure
   (Informational)
   Token: Benjamin Kaduk

Amy: The consensus here is Unknown, I'm going to go ahead and set that to Yes
for you.  I have quite a number of Discusses in the tracker; do we need to
discuss those today?

Ben: We might. I confess I did not get to review these in depth, but we have
several people unhappy with the file system part of things and also with the
question of human readable vs machine readable. I guess there was also thing
about the Expires. So both the human readable part and the expiration were
added as a result of IETF Last Call. There was some concern that making things
machine readable would open up too much risk in the ecosystem as a whole,
invite the use we don't want for instant response that would allow an attacker
to compromise the file contents itself and then redirect the report of the
compromise. Likewise for the expiration, there was concern that these would be
a passing fad and then grow stale, so if you had something that was put in
several years ago and then ignored there was no way to know if it was still
accurate or not. I pushed pretty hard for the mandatory expiration as a way to
solve that perceived issue. For the file system part, perhaps that was
something that was not as well discussed as the web server part, and I'm
sympathetic to the concerns that it's under-specified. My main question for
people is whether we think it is worth trying to flesh that out and trying to
get it solid or if we should just remove that and defer it to a separate
document.

Murray: I was thinking about, and didn't have time to go back and look at the
ISO and the CERT document that it references. Perhaps those two documents have
some better explanation of how the file system piece works that could be
referenced or incorporated or something. I don't know how to use the file
system part, I don't know how to interpret it.

Roman: Yeah, in my opinion there's no citable reference in either the CERT
document or the ISO reference that will inform the file system thing. What's
unclear to me is that just the basic concept of operations is not defined. Is
this a SWID tag or something else? I think based on that articulation of which
one it is it might inform whether it just needs polish or if it needs to go
somewhere else. But for me there isn't a foundational definition of who puts it
in and what the life cycle management process is here.

Murray: To answer your question, I don't have a preference about removing it
and putting it in another document or flesh it out here, it just can't stay in
the state that it's in.

Ben: Okay, I hear that. I think it would be beneficial for us to hear from the
authors on this one. I don't know for sure if they will be giving a prompt
response but I did hear back from them when I put my comments in and they said
they were going to wait until all comments were in before making any changes to
the document, so I'm hopeful we can hear back from them soon. This one is
definitely going to be Revised ID Needed.

Amy: This will stay in IESG Evaluation and go into Revised ID Needed, thank you.

3.2.2 Returning items

 o draft-kucherawy-rfc8478bis-06 (Has RFC Editor Note)  - IETF stream
   Zstandard Compression and the application/zstd Media Type
   (Informational)
   Token: Barry Leiba

Amy: This document is back for a specific question. Barry?

Barry: This was a little weird but I wanted to make sure we had a chance to
take another look at it since there's no ballot. I'll repeat what I said in my
email. This is updating an RFC, and during auth 48 for this, the RFC got
another errata report posted that we felt we needed to address rather than
letting it sit. That was more than just a trivial editorial change, so it
involved a couple of paragraphs. Just wanted to make sure the community and the
IESG had a chance to look at it. I put it back in Last Call with the community
and no comments for that. Now it's up to us to have a quick look for comments
and I didn't get any. I assume we can go ahead and tell the RFC Editor to go
ahead and continue processing this. Does anyone object to that? Hearing none,
thank you, and we can just minute that this will go back to the RFC Editor.

Amy: Sandy, do you need an official notice from us that it can come back to you?

Sandy: I think just a message from Barry would be good enough.

Barry: I forget which editor I was working with but I said I would report after
this call.

Amy: Great, so that will go straight back to the RFC Editor. Thank you Barry,
thank you Sandy.

3.3 Status changes
3.3.1 New items

 o status-change-tls-des-idea-ciphers-to-historic-01  - IETF stream
   Moving single-DES and IDEA TLS ciphersuites to Historic (None)
   Token: Benjamin Kaduk

Amy: I have no Discusses for this document, so unless there's an objection now
it looks like this status change is approved. Hearing no objection, so it looks
like this is just a plain approval.

Ben: Yes, nothing to do here.

Amy: Great. We will send that status change announcement on Monday.

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 NONE

3.4.2 Returning items

 NONE

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

 o WebRTC Ingest Signaling over HTTPS (wish)

Amy: There are no blocking comments for this charter, so unless there's an
objection now that external review message can be sent.

Murray: I see the comments from various IESG members that have been added in
the last 24 hours and I'll look into all of those all. Since I put this on the
telechat I've added chairs and a milestone which I think takes care of about
half of the feedback, and the others I'll look into.

Magnus: I think I have the most fundamental comments on this. The charter
doesn't really address what the model is at all that it's targeting. I went
looking at the draft to understand it and after thinking about it I realized it
doesn't really say what's the relationship between the media producer and the
media consumer. In some sense that last comment about displays consumptions
would prevent, for example the consumer to initiate towards the producer, if
that's a use case or not. I do have questions on what the scope is.

Murray: I just saw that now. I'll go back to the protagonists and get them o
answer these questions before we send it forward. Or, we could send it out to
review and just include their answer for the next time this comes around on a
telechat, if that's okay with you.

Magnus: This was for approval, wasn't it?

Murray: No, this is initial.

Amy: This is for external review. So you'll see it again.

Murray: I'll make sure this is all addressed before it comes back the second
time.

Magnus: Thank you.

Amy: Did you want to hold this pending edits or did you want to send it out
now? It would probably go out tomorrow.

Murray: I think what we just resolved is that this is okay to go as is and I
expect Magnus to block it if I don't take care of it the second time around.

Amy: I just wanted to check if you wanted to do any more edits first. External
review is approved, then, and we will send that announcement out.

 o IOT Operations (iotops)

Amy: I do have a Block for this charter.

Rob: I just wanted to discuss with Alissa for her block. The first one is easy
to resolve; that was a suggestion that was put in relatively late and we can
just change that back to what it was before. On the second one, I'm slightly
more concerned about losing the sentence about it being a discussion venue,
since I think that sets the scope of the WG quite well. How strongly do you
feel about us dropping that sentence? Or is there any leeway?

Alissa: The discussion venue part I think is fine, it's the rest of the
sentence that's kind of problematic because it's dramatically broader than
what's stated later in the charter. If you want to keep the term 'discussion
venue' that's good, but the rest of it like how technologies fit together and
what gaps remain, is not at all specific to the actual operation and management
of these devices and networks, it could be about anything.

Rob: Okay, that's fine. I'll delete the first bit and move that one reference
back to the text below.

Warren: As a followup, a number of people have suggested we add a bunch more
WGs. We're happy to do that. When we'd initially started listing the WGs, they
were purely supposed to be examples. This includes work done in X, Y. It now
feels like people feel they would also like their WG listed there as well so
you understand this is also the sort of thing that can be discussed. We're
happy to do that, but there was a suggestion to use "and others" or something
similar. I think we'll add the other ones people have asked for and add "and
others" or "and similar" so it's clear and every time there's a new WG that
mentions IOT that we don't have to add it to the charter. I assume everyone is
okay with that.

[Various murmurs of approval]

Warren: Thank you. You don't know how relieved I am that this is almost over.

Amy: So is this going to get edits or are we just waiting for you to let us
know it's ready for external review, Warren?

Warren: No, we have some edits to put in. Rob and I have a call after this so
maybe we'll do them then.

Rob: If we've solved Alissa's comments and she's happy, do we need this to be
reviewed again before it goes out?

Amy: Once Alissa clears the block, all you need to do is alert us that it's
ready for external review and then we'll send out the announcement.

Rob: Thanks.

Warren: Thank you everyone for helping us get this polished and better.

4.1.2 Proposed for approval

 NONE

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o Authentication and Authorization for Constrained Environments (ace)

Amy: I have no blocking comments. Does this require an external review or is it
small enough to just make the changes? I was unclear.

Ben: This is definitely going to need an external review. There were a couple
of wording suggestions that I will take, so please wait to hear back from me
before you send it out. Martin had pointed out that nine drafts to the IESG
this year in the milestones might be ambitious, but we do already have the
individual drafts and the WG has been talking about them, so it's not
completely out of the question but it is perhaps ambitious. Thanks everyone for
the review.

Amy: So I hear external review is required, and it's also approved pending
edits so we'll wait until you tell us it's ready to go, Ben.

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Alvaro: There's nothing specific I really want to report on but I do want to
comment that over the last few weeks there have been some interesting
discussions in the IAB around topics we've discussed here as well, things like
living documents and a discussion last night triggered by the APN BOF, also
some discussions related to diversity and inclusion. That's perfectly fine but
I'm just thinking we need to keep it in mind so that when we get to the retreat
in the next couple of months we should have some joint sessions to cover some
of those topics.

6. Management issues

6.1 [IANA #1186621] Designated experts for RFC 8819 (IANA)

Amy: This is just to alert Robert that he has an action item to find these
experts.

6.2 [IANA #1186792] Renewing early allocations for
draft-ietf-bess-evpn-bum-procedure-updates (IANA)

Amy: Martin V is the AD for this document. It looks like the early allocation
will expire next month and we need IESG approval for a second extension. 
Martin, did you want to speak to this?

Martin V: I don't have anything to say specifically.

Amy: So unless there's an objection this is approved. I'm hearing no objection
so we will send official note to IANA.

6.3 Approving LS to 3GPP (Magnus Westerlund)

Magnus: I know it's a bit short on time but several IESG members have reviewed,
so I wonder if you're fine with me sending this out. I have edited a bit, there
are final edits in since Alvaro's suggestions.

Mirja: I provided a bunch of comments and I think they're mostly good. I just
really want to make sure that it doesn't sound like we never want to hear from
them again. We definitely want that they bring those ports that need
registration to us and not just use them without registering or whatever, that
should not happen. So we should be very clear about that part.

Magnus: I updated that part. They still request to apply for port assignment if
you have clear needs, etc.

Mirja: I left another comment because it said 'completely avoid port
assignments' in an earlier sentence and maybe we can be more careful about the
wording. And then did you see this message from Lionel who expressed that he
was requesting to get more information than what's in the RFC because that
didn't seem to be helpful for him?

Magnus: Yeah, and I don't know really how to answer that. I did send a response
to him during the day. It's tough to say. I can't guarantee that the port
reviewer is fine with things, they have guidance and they're trying to be
consistent. I think service discovery is part of a few things which is fairly
certain but if it's very insecure you could still be turned down. I don't want
to bind IESG in general for what you think if you're going to override the port
experts in the future. I don't want to pre-decide, that Magnus wrote an LS that
said this is fine.

Mirja: I think he would like to have something written down he can point people
to, and our interest is not to write anything down in a liaison statement that
is not documented anywhere else. I just wanted to make sure you were aware of
that. I hope we can just coordinate directly with him when needed instead of
writing more liaison statements.

Magnus: Yes, I hope so too.

Mirja: We could say that explicitly at the end of the statement. 'Please feel
free to reach out to us whenever there is any doubt' or whatever.

Alissa: I think that would be a helpful addition, because the thing that he
wants can actually just be resolved by talking. They don't have to go directly
to requesting the port if that's a problem for them. That's what he's
requesting guidance on, and let's take it case by case and talk about it, then
if it seems like a good idea they can request it.

Magnus: Okay. I will draw up some text for that then. But it seems that people
are reasonably fine with the general structure of this LS. I would like to send
it out no later than tomorrow because they have a meeting coming next week.

Mirja: You didn't have a chance to show this to any of the port reviewers, did
you?

Magnus: I sent it to the port expert list at the same time I sent it to the
IESG, so they've had as much chance as the IESG to look at it and I haven't
heard anything from them.

Mirja: That's fine. Thanks.

Magnus: I'll draft some text. I do have a question here, do I send this from
the IESG or is it Alissa?

Mirja: I think it should still go through the liaison manager.

Alissa: You mean the "from" field?

Magnus: Can I send it on behalf of the IESG myself or do you need to send it?

Alissa: In the datatracker you can set the from to be The IESG but last time I
did this I just sent this to statements@ietf.org and then I had a back and
forth with the Secretariat about the fields. I think you can do it such that
your name is not the sender.

Magnus: Okay. I will try it and otherwise I will contact the Secretariat.

Amy: Thank you Magnus, let us know if you need any help.

6.4 [IANA #1187517] Designated experts for RFC 8839 (IANA)

Amy: This is just to alert Murray that he has an action item to find these
experts.

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

7.1 Expedited processing for draft-carpenter-eligibility-expand (Alissa Cooper)

I did already request this expedited processing but should have given people an
opportunity to object. The idea here is that this is setting eligibility rules
for the Nomcom that's going to be established for the upcoming cycle, so
getting it published as soon as possible is very helpful. Having it published
before people have to decide about registration for 110 is good and even before
the Nomcom Chair is selected is good, just so that there's advanced information
for everybody who's implicated. That's why I did it. Does anybody object to
expedited processing for this one?

Sandy: I'm totally happy if you want to expedite this, but you don't formally
need to. The document will be moving into auth-48 in the next week or two.

Alissa: Oh, okay. When we put it in there was a giant cluster. That's fine
then, I guess the point is moot.

Amy: Great, thank you Sandy and Alissa.

7.2 Update on C238 (Murray)

Murray: Obviously everyone's seen there's been a big push. We got it down to
just two documents that the authors then started saying there's a conflict
between these two we need to resolve, otherwise we're shipping broken
documents. There was a lot of intense conversation towards the end of last
week. The way we decided to proceed with it was to leave a note in a new
introduction section that said we acknowledge that these two documents are in
conflict. We intend to fix this forward. We are going to publish them with the
fault known, as they were approved by the WGs, the IESG, and the Last Calls,
and ship them that way, and then immediately begin work to resolve them in the
WG context so that the solution can develop consensus. They are about to ship
that way. These last two documents were the jsep document and the bundle
document. The introductory text identifies what the conflict was but doesn't
talk about solutions. In fact the authors regularly devolved into talking about
how we're going to solve this. With Barry's help we limited them to just
describing the conflict, talk about where we are, this is what got approved,
and we're going to proceed. The plan is to ship it that way and then
reconstitute the rtcweb WG to solve this one problem, with a charter that is
constrained exactly as described. They're only going to work on one thing and
publish updates to these two documents, and that will be the end of it. You
should see a very quick rechartering of rtcweb coming through and I'll probably
request a session for that at 110, if everybody is okay with that.

Eric V: Do you need to revive the WG for just this? Not put it in another WG?

Murray: I could if we're all okay with that. Part of the process I had in mind
was to create a venue for them to do this. I had a choice between restarting
rtcweb or putting it in mmusic. Both were amenable to this idea, mmusic is
still alive and not too busy, but the original chairs of rtcweb said they'd
take it. I could AD sponsor them but I'd probably feel better doing this
through the WG. I'm happy to take your suggestions.

Eric V: My main concern is to go fast. We know what the update will be and
there's no point pushing the update in March or April.

Barry: It's going to take some significant discussion to resolve this. The
reasons I'd like to see it done in a revived rtcweb WG is that the mmusic
people are still around, and we can still post things to that list. I'm not
sure the rtcweb people are still watching the list. Reconstituting the WG will
make it sure that they will realize they're actively participating in this
discussion, not just the authors of the documents.

Murray: So we have the advantage that we have either venue available to us,
since the original chairs of rtcweb said they'd do it for this limited charter.
It's nice to have options.

Eric V: Thank you for the explanation.

Alissa: Greg is working on a joint press release with the W3C for next week.
We're trying to try to get a little extra exposure on this, since it's a lot of
documents and it took twelve years.

Murray: The last thing, Matt suggested that I make sure to notify the rtcweb
community of what's happened and I will do that shortly.

Ben: My kneejerk response to hearing that we were just going to add a paragraph
was that this is writing new text nobody else has looked at a very late stage
and how do we make sure it's correct. But on further reflection I don't feel
the IESG needs to formally look at that text.

Murray: It was reviewed by all the authors of both documents and Barry and
myself, so if you trust us it's done.

Barry: It was also exposed to the entire C238 authors. So anyone who was an
author on any document in the C238 cluster is at least aware of the situation
and the text we're putting in.

Magnus: Assuming they looked at that list in the last week, since this has all
unfolded in a week.

Barry: I think also the text we've got going in is relatively uncontroversial.
We aren't committing to anything other than that we will deal with resolving
the problem. It's pretty clear there is a problem and we didn't want to hold up
the whole cluster to resolve it.

Murray: And we did go out of our way to deflect attempts to add text that
preferred a particular solution. All we did was describe the conflict.

Ben: Much appreciated.

Barry: And I will say somewhere other than just an institutional memory of a
few ADs, we need to document that this stuff is never going to happen again.
It's one thing to have a handful of documents that depend on each other, it's
another thing to have that be 40 or 50 documents that get approved over the
course of four years. It's been very difficult getting people whose documents
were approved four years ago who are gone to come back and participate in
auth-48.

Murray: I had to issue a number of overrides for people who have been
unresponsive since their documents went into auth-48. I'ave never even seen
that done before.

Magnus: And unfortunately there hides more issues which are smaller that people
haven't cared about resolving in some sense, which is another effect of this
process. I agree that we should really avoid doing anything like this ever
again and try to compartmentalize things in a nicer way. Quic is better. We
learned a lot in this process and found a lot of gaps, etc.

Murray: So I will notify the rtcweb community of what we're doing.

Barry: I think we should alert mmusic that it will be discussed there but to
make sure the rtcweb community is engaged in it we'll do it that way.

Murray: So we'll do a quick rechartering of rtcweb so we'll have that on the
next telechat. And I'll request a session for them at 110.

Barry: I just wanted to add many thanks to the RPC gang for all of the work you
had to put in for this, especially making sure the cluster was internally
consistent. That had to be a hell of a job, thanks.

Amy: So Murray, you're going to request a session for rtcweb, so email Liz with
those particulars. It will go from concluded to proposed WG, but it probably
won't happen fast enough to get a session request in unless you alert her
separately.

Murray: Do I need to ask for a Bof, or just recharter and go?

Amy: Just recharter and go.

7.3 Question about assigning a code point (Ben)

Ben: This is a situation I haven't come across before. There's an ISO final
draft international standard it says they're in the final stages of publication
for, and they want to get a code point from an IANA registry that's
specification required. I guess there's a catch 22 because they want their
final specification to refer to the actual assigned code point but the
specification won't exist until they do that, so there's a blocking dependency
each way. Do we have prior experience with this?

Barry: The designated expert is responsible for making sure there's an adequate
specification and the designated expert can use their expertise on this. That's
an easy solution.

Ben: That was my expectation but I just wanted to check since it's not
something I've run into before.

Barry: It's happened before.

Michelle: If the designated expert approves it, would there be some type of
draft documentation that we would point to, or would we just be coordinating
upon final publication?

Barry: I think you'd point to whatever the current version is now, and then
update that reference when the final document is published.

Ben: I don't have a great handle on what public drafts are currently available
but I can follow up on that thread, which Michelle I think you are on.

Michelle: Yes I am, and I'm catching up on it. We'll work together to do what's
needed to get those assigned and point to the right documents.

Barry: Even if it's the case that the draft is not public, but they can make it
available to the designated expert, there's precedent for that also. You can
then make the registration with a pending reference and add it when it's
available.

7.4 Affiliation change (Erik K)

Erik K: Just to let everyone know, I've had a change of affiliation and have
gone back to Google.

6.5 Executive Session: LLC Board slot (Alissa Cooper)