Narrative Minutes interim-2022-iesg-26 2022-12-15 15:00
narrative-minutes-interim-2022-iesg-26-202212151500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2022-12-15 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Andrew Alston (Liquid Intelligent Technologies) /  Routing Area
Amanda Baber (ICANN) / IANA Liaison
Jenny Bui (AMS) / IETF Secretariat
Roman Danyliw (CERT/SEI) / Security 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
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Applications and Real-Time Area
Alvaro Retana (Futurewei Technologies) / Routing Area
Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area
John Scudder (Juniper) / Routing Area
Amy Vezza (AMS) / IETF Secretariat
Eric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area
Paul Wouters (Aiven) /  Security Area
Qin Wu (Huawei) / IAB Liaison

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
Martin Duke (Google) / Transport Area
Sabrina Tanamal (ICANN) / IANA Liaison

OBSERVERS
---------------------------------
Brian Campbell
Mike Jones
Lee-Berkeley Shaw
Greg Wood

1.2 Bash the agenda

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

1.3 Approval of the minutes of past telechats

Amy: Is there any objection to approving the  minutes from December 1? I'm
hearing no objection. Is there any objection to approving the narrative minutes
from December 1? I'm hearing no objection there either. Both are approved.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

     o Paul Wouters to find designated experts for RFC 9200 (ACE-OAuth)
       [IANA #1239251].
     o Paul Wouters to find designated experts for RFC 9203 (The (OSCORE)
       Profile of the (ACE) Framework) [IANA #1239258].
     o Paul Wouters to find designated experts for RFC 9237 (An
       Authorization Information Format (AIF) for Authentication and
       Authorization for Constrained Environments (ACE))[IANA #1239259]].

Amy: All three of these are on the agenda later to approve experts, so we will
mark these as provisionally done.

     o Lars Eggert and Colin Perkins to find designated experts for RFC
       8609 (Content-Centric Networking (CCNx) Messages in TLV Format)
       [IANA #1239154].

Lars: I found two experts and I sent an email to IANA cc-ing the IESG.

Amy: Do you want to approve them today?

Lars: I haven't heard from IANA that they got the message. We can approve them.

Amy: Okay; we'll take that up as a management item.

     o Roman Danyliw to find designated experts for RFC-ietf-lamps-cmp-
       updates-23 (Certificate Management Protocol (CMP) Updates) [IANA
       #1241372]

Roman: Did I put them on the agenda as a management item?

Amy: We didn't get a ticket about it.

Roman: Okay, then that's my mistake. I will try to get these on for the end.

     o Francesca Palombini to find designated experts for RFC 9290 "Concise
       Problem Details for Constrained Application Protocol (CoAP)
       APIs" [IANA #1241511].

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

     o Alvaro Retana to find designated experts for RFC 9303 "Locator/ID
       Separation Protocol Security (LISP-SEC)" [IANA #1241556].
     o Alvaro Retana to find designated experts for RFC 9305 "Locator/ID
       Separation Protocol (LISP) Generic Protocol Extension" [IANA
       #1241559].

Amy: Alvaro, these came in for you while you were on vacation..

Alvaro: I'll get on that, thanks.

   * OPEN ACTION ITEMS

     o Robert Wilton, Alvaro Retana, and Warren Kumari to report back to
       the IESG on the impact of COVID-19 to the IETF in March 2023.
       - On hold;

Lars: There seem to be way more experts than there used to be, at least
compared to ten years ago or so. I wonder if it's worthwhile pushing back and
telling people to use RFC required. It seems like every registry now is expert
review and it seems to cause a lot of management overhead, and I'm not sure for
how much benefit. We can take it to an informal.

Eric V: That's a good point.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-idr-bgpls-srv6-ext-12  - IETF stream
   BGP Link State Extensions for SRv6 (Proposed Standard)
   Token: Alvaro Retana

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

Alvaro: No, I don't think so. The authors are usually very responsive and I
think John, you already got a message from Kevin that he's out this week. So
no, we don't need to discuss today and this should be Revised I-D Needed.

Amy: Okay, this will stay in IESG evaluation, Revised I-D Needed.

 o draft-ietf-idr-rfc7752bis-14  - IETF stream
   Distribution of Link-State and Traffic Engineering Information
   Using BGP (Proposed Standard)
   Token: Alvaro Retana

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

Alvaro: No, I don't think we do. Same answer as before, same author. I think
we're okay, thanks. Also we'll require a revised I-D on this one.

Amy: Okay, this will stay in IESG evaluation, Revised I-D Needed.

Eric V: You still need one more ballot on these two, right Alvaro?

Alvaro: Yes. The second [document] needs one. Please take a look, thank you.

 o draft-ietf-bfd-unsolicited-11  - IETF stream
   Unsolicited BFD for Sessionless Applications (Proposed Standard)
   Token: John Scudder

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

John: No. We don't. I'm disappointed we didn't get more Discusses because I
think I would have gotten a special prize if we got to 10. Thank you all for
reading it and for your Discusses. We'll take it offline.

Amy: I'm assuming this is going to require a revised I-D?

John: Oh hell yes.

Amy: This will stay in IESG evaluation, Revised I-D Needed.

 o draft-ietf-oauth-rar-21  - IETF stream
   OAuth 2.0 Rich Authorization Requests (Proposed Standard)
   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.

Roman: Thank you for everyone's review. As it was just noted, there is a -21. I
haven't had a chance to look at it so let's put this in AD Followup.

Amy: Okay, this will be Approved, Announcement to be Sent, AD Followup so you
can look at the rev.

 o draft-ietf-ipsecme-ikev1-algo-to-historic-08  - IETF stream
   Deprecation of IKEv1 and obsoleted algorithms (Proposed Standard)
   Token: Roman Danyliw

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

Roman:  We have the benefit of the author on the call. I want to make sure we
know what we're doing; we're going to put some polished language that we know
what deprecated means; is that what we said in the thread?

Warren: I think so. I just replied to the thread a short while ago saying that
if there is text I can probably clear.  We often use the words deprecated and
historic without anybody quite knowing what it means. We should probably at
some point figure that out. I Think this is the right thing to be doing but I'm
not sure that saying we're deprecating a protocol actually means anything
meaningful. With some version of "we're deprecating it and we're not going to
do any future work on this, and probably you all shouldn't run it" would be
fine. I'm concerned that the original wording made it sound like the IETF can
tell people what to do and they will actually listen. We can tell them, but
they won't listen.

Paul: Francesca also came up with a point there. I'll see about changing the
text. The only thing I did not want to do is change the text from saying IKEv1
is deprecated to "the docs describing IKEv1 are deprecated" because that felt
like silly weasel wording. I'll see about how to best make it clear that we're
not able to tell people what to do but we've considered all maintenance and
development to cease on this.

Warren: I've just cleared my Discuss.

Roman: Thanks Warren and Paul. Can we put this in Revised I-D Needed based on
this conversation?

Paul: Francesca also talked about changing the node to IANA in the registry so
it needs a change.

Amy: This will go into Approved, Announcement to be Sent, Revised I-D Needed
and you can let us know when it's ready.

 o draft-ietf-netconf-https-notif-13  - IETF stream
   An HTTPS-based Transport for YANG Notifications (Proposed Standard)
   Token: Robert Wilton

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

Rob: Yes, I think that would be helpful. I haven't been up on my email to see
what exactly has been discussed but I think it would be useful to discuss with
lars about http3. First of all Lars, your discuss seems to be suggesting, is it
your concern that this should be covering http3 now or that it should support
it in future?

Lars: There are some other aspects. one is that it just talks about https
without citing anything. To me that at least implies all versions, present and
future. Then there is a bunch of text in there specifically when we come to the
yang models that talks about the TCP and TLS configuration.  I guess it's
implying that it's not running over http3 / quic but it's not saying that? I
also don't know, this is a question for ART, but I thought we were not hot on
doing applications over http that were specific to certain versions. I realize
the application is not but all the supporting plumbing is. I guess I just need
more words or some more explanation in the document  about which pieces are
agnostic, which pieces are not agnostic, and why that's okay.

Rob: Okay. At the moment, the name for this is netconf servers to get data off
devices. At the moment, I don't see those moving to http3 in the short term.
When they do, I think you'll have more large updates to the netconf protocols.
Again, I'm not sure whether you'd get the benefits of moving to http3. In the
short term, these are types 1 and 2, but it should certainly be extendable.

Lars: For http deployments, the applications are pretty much agnostic to the
version because the negotiation happens at the http level. So for an
application to have opinions about what version of http is used, that's not
typically how it works, at least on the web.

Eric V: For the server, whether it uses nginx or apache, you don't care. You
just put the application on top of them. Django doesn't care; it should be the
same.

Lars: The browser and the servers will basically figure out which version to
use, and the application, meaning the thing that carries html, doesn't
understand that.

Rob: I don't think it's' going to be a browser providing this data, it's a
stream coming off a router, or another device. I think that's my disconnect
here.

Éric V: But it'll be an http request or a library somewhere to be used, right?

Rob: If they're running a quic stack. It feels to me you'd update the whole of
the manageability interface to run over quic to want to use http3. That's where
I find the disconnect. This definitely should be extensible but I don't see a
market to run on http3.

Zahed: Here we're talking about a couple of things. One is the semantics we
use. That is basically http 1, 2, and 3. We have not changed that. Where we
changed it, the difference between http2 and http3, is that one can support tcp
and another doesn't. If this document only cared about using the semantics of
using http, it might cover then i'm more into the application saying fix
something than the browser. The moment you started saying this is for http1,
this is for http2, the question obviously comes, where is http3? Is it about
transport or application? This document has mixed it up I think.

Éric V: As far as I know, in your queue there are a couple of documents related
to this one, right?

Rob: There are ones that are maybe related to this, I'll need to check.

Éric V: So we don't need to repeat the same conversation, is my concern.

Rob: It depends on exactly what the support needs to be. Making all these
things generic to be http3 supported and have those parameters when we know at
the moment people aren't deploying those, is my concern that we're creating a
lot of work. I'd rather see us standardize and get work done for http1 and
http2 initially and have it extensible to http3.

Lars: That's fine, but then the document just needs to say that. At the moment
it doesn't talk about any http versions and it's all implied. It should say
something like deployment must not use http3, and so on.

Zahed: We have come to that conclusion in other documents previously, to have a
sentence saying http3 is not within future work. Here we can be really generic
more than in transport. That's the confusion to me, do you really care about
these matters?

Rob: I think I'm clear on the way forward here. My other question is to Roman.
On security certificate fields, have you got some suggestions as to what you
are...?

Roman: I'm not sure I fully understand the setup, but let me give you the
analogy of why I think this is a problem. The text says, very flexibly, here's
a Yang representation for all the certificate fields. Really great, good
reference, you're not reinventing the wheel. But then it says there's a local
username. What I don't know is, given a local username, and given an arbitrary
representation of the certificate, which is the correct certificate field I'm
supposed to compare it in? The analog, for example, in web browsers is, I have
a domain name and there's specific guidance on which fields I'm supposed to
check in the certificate about that domain name. Is it in the subject field, is
it in the subject alternative name, when we have either protocols like DTN that
are using identity and saying certificate, they also map the field. If there's
some local username being presented here there just needs to be some guidance
on what PKI field is expected; is it a new one or are you reusing one? If you
are not clear you can end up, I thought it was in one field but it turns out
verification is actually against another field and you can have bogus
certificates.

Rob: Okay, thanks. That one sounds like it's fairly easy to resolve. Thank you.

Roman: Do you have questions about the others or do they make sense?

Rob: I think that's okay, thanks. So this will definitely be Revised I-D
needed, maybe AD Followup.

Amy: We'll keep this in IESG Evaluation, with Revised I-D Needed. Thanks.

Murray: One more thing --The issue about the rules of registry they're
creating, I decided to elevate that. Do you want to talk about that now? I
think that's something we should talk about with them.

Rob: I think it's fine. We'll do it over email.

Murray: That's fine, thanks.

 o draft-ietf-opsawg-service-assurance-yang-10  - IETF stream
   YANG Modules for Service Assurance (Proposed Standard)
   Token: Robert Wilton

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

Rob: Murray's I think we definitely do. He had validly pointed out that the
shepherd writeup was a bit terse. I think they were chasing the shepherd for
quite a long time to write it and they were busy. I can answer those questions
now if that's helpful. So the reason it's right for it to be a standard is
because it contains a Yang model and generally we make all of those standards
because they define an API. So I think PS is the right state for this.

Murray: I figured as much. My problem is not so much the question but my
tolerance for people not giving a damn about doing a half decent job on the
shepherd writeup is reaching its limit and that's why I'm starting to Discuss
these.

Éric V: I support you on this one, Murray.

Rob: It may be that the amount we're asking they've been unhappy with the level
of work. I can ask.

Murray: Thanks. The one I was most worried about is this ambiguous one at the
bottom about IPR. it just says Yes and I don't know if that's something we
should know about or something not, and that's the one that has legal
implications so that's the one i'm most concerned about.

Rob: They've done the IPR request as normal and IPR has been disclosed. I don't
think there's any issue there. For a disclaimer, it's Cisco that's holding the
IPR on this. But I don't think there's any issue.

Éric V: And by the way, I'm on the patent as well.

Warren: I think there's some backstory here as to why this is terse. Apparently
the chairs had asked for someone to volunteer to be document shepherd, that
person volunteered but wasn't actually clear that's what they were volunteering
for or something, and there was some grumpiness between the chairs and the
shepherd [because the shepherd didn't know what to do]. Some of the terseness
is grump; that doesn't excuse it but an explanation for why this particular
one...

Murray: My next question is why didn't you find a different shepherd. I mean, I
get it, it just creates a process mess and it gets me to the point of thinking
if we're not going to get people to do a good job on these, should we just drop
the practice? They get all the way to the telechat in this sort of form and why
did you make me read this?

Warren: I have heard some grumblings from some of my WGs that they much
preferred the older format of writeup, so for some of them I've said, well just
use that one if they find this one unclear. That's a separate discussion.

Murray: Rob, I've cleared.

Rob: And Eric, to your point, I think those have been addressed --

Éric V: Yes, as soon as I see the revision, I'll clear my Discuss.

Rob: Thank you very much, and thank you everyone for the reviews. So Revised
I-D Needed please, thanks.

 o draft-ietf-jmap-blob-17  - IETF stream
   JMAP Blob management extension (Proposed Standard)
   Token: Murray Kucherawy

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

Murray: No. I haven't seen any answers from the authors yet but I think the
Discuss is clear enough for me, so let's see what they say. Let's do AD
Followup and I'll move it to Revised I-D Needed depending on the outcome.

 o draft-ietf-jmap-quotas-10  - IETF stream
   JMAP for Quotas (Proposed Standard)
   Token: Murray Kucherawy

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

Murray: Nope, same answer as the previous one.

Amy: We'll put this in AD Followup as well.

 o draft-ietf-extra-imap-partial-03  - IETF stream
   IMAP Paged SEARCH & FETCH Extension (Proposed Standard)
   Token: Murray Kucherawy

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

Murray: Can you please do AD Followup; I'll just check with them before we
release it.

Amy: Certainly; Approved, Announcement to be Sent, AD Followup and you can let
us know when it's ready.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 NONE

2.2.2 Returning items

 NONE

2.3 Status changes
2.3.1 New items

 o status-change-ikev1-to-historic-00  - IETF stream
   Moving IKEv1, ISAKMP and IPsec DOI to Historic (None)
   Token: Roman Danyliw

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

Paul: I was also not entirely sure if I should recuse or not. Since I wasn't
sure, I asked Roman and he said I should recuse for the appearance, so I did,
but it's an interesting question to figure out if it was needed or not.

Warren: It's not so much the actual recusal, it's all about the optics. Nobody
really thinks you're going to put your finger on the scale here but there's no
downside to recusing, and it makes people feel happier. Technically you
probably didn't have to, but there's not much reason not to.

Mirja: I don't think there's no downside to recusing. If you recuse then you
have a conflict of interest and people will be wondering what that is.

Warren: There's a comment field where you can say the reason. You're right, it
could look wrong.

Éric V: We might reach a point where Paul's ballot is needed, though.

Warren: I thought we'd run into this before and recusal makes it as though the
pool of people is smaller so you don't need the N.

[Cindy in the chat: What's needed to pass is 2/3 of non-recused ADs]

Rob: I wasn't intending to bring this up for discussion, it was more just a fly
on the wall comment, but it feels to me like the reason to do this is to make
the internet safer, and that falls into a Sec AD role rather than you acting on
your own. So it might be that your company has a big benefit to doing this, I
have no idea, but that's' the reason why recusing makes sense. That was the
point I was thinking you're just doing the right thing here. I don't need to
discuss this more, I don't think it really matters.

Amy: Okay, so the other IKEv1 document that moves to historic is in Revised I-D
Needed. I'm assuming these have to go together when they're announced?

Roman: That is my understanding, because we're exercising option 3 where the
status note is referencing the document.

Amy: So we'll put this into AD Followup and when you release that one, can you
remind us that that will also release this one, so we don't forget it?

Roman: Absolutely.

Warren: Technically this could go forward, and would be stuck in something like
misref when the RFC Editor tried to do stuff. But yeah, let's not do that.

Paul: Technically it should go first because the document that matches this
action states it has happened. That document does not do the action. So
technically the document should come last.

Warren: Sure, but if you were to try and progress this, the RFC Editor would
just hold it.

Paul: I agree, we should try to do them at the same time and no one will care
about the few seconds where it's a missing reference.

Amanda Baber: I think there is still an IANA issue with this. I don't think
we've seen a decision as to whether we should close the IKEv1 related
registries.

Warren: Oh. How do we fix that, who makes that decision?

Amanda: In the past, we weren't getting last call evaluation messages for
these, we would just find out that it had happened and ask the ADs if we needed
to do anything. There's not really an established process here; I think we were
just looking to Roman to tell us what to do.

Roman: Thank you for reminding me. Yes, we should stop adding things to these
registries.

Amanda: Okay, we'll make a note of it. I don't know if it needs to go into the
status change document.

[crosstalk]

Warren: I think it feels like it shouldn't go in the status change document,
since it's changing the status of a document, but I understand it might be
really helpful for IANA to have a pointer that someone made this decision. Can
you just say you're not adding anything to the registry because the underlying
RFC has been made historic and point to the document?

Amanda: We will point to the status change document, but it would be helpful if
you want to put it in there. If you don't, I think we're okay.

Roman: I'm happy to put it in as long as I don't have to bring it back to Last
Call or to a telechat. Does anyone know?

Warren: I'd assume this would be handled like any other Discuss where we just
trust you. I don't care, you can change anything you like.

Roman: Does anyone feel contrary to Warren?

Paul: I'll put in some text that makes it more clear. Also just for reference,
the WG has refused to add anything to these registries for many years, so these
have been static for a long time already.

Warren: I think whoever adds a sentence to say the registry is now closed, IANA
can point to that and this doesn't need to come back.

Roman: I'll polish the text to make that clear. Thank you.

Amy: I have that this status change is approved, but with an AD Followup on it
so it can wait until you're ready to release the other.

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-6lo-use-cases-14  - IETF stream
   IPv6 over Constrained Node Networks (6lo) Applicability & Use cases
   (Informational)
   Token: Erik Kline

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

Erik K: I don't think the authors have had a chance to respond to anybody's
feedback apart from Lars. Unless Roman particularly wants to discuss this I
think this can wait until the authors have had a chance.

Lars: I cleared because they forwarded the thing.

Erik K: That's AFC you're thinking of.

Lars: Oh, sorry.

Erik K: I think we can just handle it on email then. It will be Revised I-D
Needed.

 o draft-ietf-opsawg-service-assurance-architecture-12  - IETF stream
   Service Assurance for Intent-based Networking Architecture
   (Informational)
   Token: Robert Wilton

Amy: This has consensus Unknown, so we'll change that to Yes. I have a couple
of Discusses in the tracker; do we need to discuss these today?

Rob: Thank you. Only very briefly; I think this is the same comment as before
because these two docs go together. I think it's the right state because this
is architectural, it doesn't define a Yang model. The other one from Roman I
think is fine and easy.

Murray: In this case the third part is different. It's the IPR questions and he
just said yes, but something has been filed. The shepherd writeup question asks
if this was discussed and I don't know the answer to that. Do you know anything
about the IPR that was filed against this one?

Rob: It's the same against both of them, I think.

Murray: The other one didn't have it.

Rob: The IPR request went out for them both together, and the response covered
both, so I think there's one IPR declaration against both. Éric is nodding.

Éric V: They're the same one.

Murray: Thanks. I'll clear in a minute.

Rob: So I think this will also go into Revised I-D Needed, please.

 o draft-ietf-ippm-ioam-deployment-02  - IETF stream
   In-situ OAM Deployment (Informational)
   Token: Martin Duke

Amy: Martin could not be with us today. I have a couple of Discusses in the
tracker so this isn't going anywhere; do the Discuss holders have a feeling if
they're expecting to see a Revised I-D?

Lars: I don't have a Discuss but I would expect so.

Zahed: I think it does need one to clarify some things. I'll have a chat with
Martin.

Amy: Okay, we'll put this into Revised I-D Needed for Martin.

 o draft-ietf-shmoo-online-meeting-05  - IETF stream
   Guidelines for the Organization of Fully Online Meetings
   (Informational)
   Token: Lars Eggert

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

Lars: Very briefly. I'm not a fan of BCP 14 terms in informational documents,
but it is being done And I think we don't usually block documents for it. it's
mostly the algorithm that the WG felt should be used to figure out what a good
time slot is for a meeting.

Murray: In a private email with one of the authors, I got that the intent of
this was to be binding on the IETF, and as soon as I heard that I thought this
needs to be a BCP. What do people think about that? Does what you just said
still apply when that's the intent?

Lars: I'm surprised that an author said that, because it's clearly not the
intent, otherwise it would be a BCP. The intent is to give information to the
LLC when planning. A lot of the other SHMOO docs are BCPs but this isn't.

Mirja: It's a should or a recommend, so it's not really binding. I think there
was a discussion in the WG about having this as a BCP and from my memory the
view was that a lot of this is really informational. I don't have a strong
opinion myself.

Lars: I think it was for the clarity of the algorithm that these terms were
being used, but the intent wasn't that the algorithm itself was to be required
by the LLC. Maybe we can say that.

Warren: Using the should/must/etc for clarity is often fairly useful, even in
informational documents, as long as people know it's informational.

Murray: Okay. I just wanted to have the discussion. I'm not trying to draw a
line, I just wanted to understand the ambiguity. I'll get out of the way.

Warren: I think it is worth having the discussion.

Murray: I'll change my ballot and record this somehow.

Lars: There are some comments here that will probably want a revision, so you
can put it in Approved, AD Followup once Murray has cleared.

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 o draft-pti-pen-registration-09  - IETF stream
   Registration Procedures for Private Enterprise Numbers (PENs)
   (Informational)
   Token: Robert Wilton

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

Rob: I think so, thank you for the reviews on this very long document. I think
some of Alvaro's comments suggested we should check and maybe fix the
references, so Revised I-D Needed please.

Amy: This will go into Approved, Announcement to be Sent, Revised I-D Needed.

3.2.2 Returning items

 NONE

3.3 Status changes
3.3.1 New items

 o status-change-int-tlds-to-historic-03  - IETF stream
   Moving TPC.INT and NSAP.INT infrastructure domains to historic
   (None)
   Token: Warren Kumari

Amy: I do have a Discuss on this; do we need to discuss this today?

Warren: I think Murray and I have this figured out. Murray can just ask for the
status to be changed in the registry and then he can clear. I believe that was
the decision. Great catch.

Murray: This is a weird case where the original thing created a media type,
this document obsoleted that one, and now this one's going to Historic, which
means there's really no owning document for this registration, and we should
probably mark the media type obsolete as well. I looked up the process for how
to do that and Amanda told me I can just ask Sabrina to make the change, since
I'm a media type reviewer, so that's the path we're going to follow. I'll get
out of the way of this one too.

Warren: This should be kept in AD Followup; even though the document could be
sent to the RFC Editor, nothing will happen until the other one goes, so let's
just hold it. We just have to remember to release it at the same time we
release the other document.

Amy: After Murray clears his Discuss this will go into Approved, Announcement
to be Sent, AD Followup and you can let us know when that's ready.

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 More Instant Messaging Interoperability (mimi)

Amy: The charter is version 00-01 and there are no blocking comments, so unless
there's an objection we can send this for external review. Okay, I'm hearing no
objection to approving the external review. Is this pending anything or can it
go?

Murray: This can go. The only thing it needs is chairs. I'll be talking to
people over the holidays. Someone said to move the milestones into the tracker
the right way and I'll do that too.

Zahed: I had a comment on this one. I didn't block it but I thought it would be
good to address in a subsequent version. Two ways of saying something needs
rechartering as opposed to one. The other thing is we are saying audio/video is
not part of the deal right now but we're also constraining you need to
recharter and this and that.

Murray: I see this now. Can you move it to its next state but put it in AD
Followup and I'll see how they want to address these things.

Zahed: I didn't want to put a Discuss because I think this should go but I'd
really like to see it [changed].

Murray: I'm happy to hold this and have them make the change before it goes
out, or we can count this as something for the external review and do it
together. You decide.

Zahed: I don't mind doing it all together but I would like you and the
proponent to think about it and respond.

Murray: Okay. I'm more of a let's get this done right the first time, so Amy,
let's hold it and get it done.

Amy: Okay, no problem. You can let us know when it's ready to go.

4.1.2 Proposed for approval

 o Javascript Object Signing and Encryption (jose)

Amy: There are no blocking comments, so unless there's an objection we can
approve this rechartering. Okay, I'm hearing no objection. Are the chairs we
have in the charter correct?

Roman: I need to make some chair changes. While we just agreed that it is
approved, I don't want to send it out until I'm able to recalibrate the chairs
team. I'll work on it and let you know.

Amy: Okay, so this is approved pending chairs and you can let us know when it's
ready to announce.

Roman: Thank you and thanks for the feedback, especially the Markdown help.

Amy: I also don't have milestones here. I see them but they're not in the right
place.

Roman: I need to cut and paste them from the text. I'll do that.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 NONE

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Warren: There was a fascinating presentation yesterday from Audrey Randall from
UCSD on "The Challenges of Blockchain-Based Naming Systems for Malware
Defenders." It was a truly fascinating and useful set of presentations. It's
based on a paper that will be being presented and I will share that as well
when it comes out. Well worth the read. I don't believe it was recorded though.

Mirja: It was recorded because a bunch of IAB people missed it.

Warren: It was recorded, but I don't know if it can be shared, I guess.

Mirja: It's not public but if someone really wants to see it. Maybe there's
also a recording of the original presentation. And one more minor point, we
just sent out a call for feedback on the IRTF chair so if you have any feedback
for us, just let us know.

6. Management issues

6.1 Proposed Designated Experts for the ACE / OSCORE registries (Paul Wouters)

Amy: Paul has identified two people for these registries; Göran Selander and
Cigdem Sengul. Is there any objection to naming these two people as experts?
I'm hearing no objection, so they are approved and we will send an official
note to IANA.

6.2 [IANA #1241511] Designated experts for RFC 9290 "Concise Problem Details
for Constrained Application Protocol (CoAP) APIs" (Francesca Palombini)

Amy: Francesca has identified Thomas Fossati and Carsten Bormann as designated
experts for this registry. Is there any objection to approving these two people
as experts? I'm hearing no objection, so they are approved and we will send an
official note to IANA.

6.3 [IANA #1240988] renewing early allocation for
draft-ietf-bess-mvpn-evpn-sr-p2mp (IANA)

Andrew: I've got no objection to this. The document is moving along slowly.

Amy: Does anyone have an objection to renewing this early allocation? I'm
hearing no objection, so this renewal is approved and we will send an official
note to IANA.

Éric V: It looks like this document will expire on 3 January. Do you think it
will be kept alive?

Andrew: Yes, I've had emails from them about this. They are going to be
bringing this back. Renewing now one more time, if they don't renew again, this
won't be renewed but I have had emails about it.

Éric V: Okay, thank you.

6.4 Designated experts for RFC 8609  (Content-Centric Networking (CCNx)
Messages in TLV Format) [IANA #1239154] (Lars Eggert)

Amy: Lars has identified Dave Oran and Hitoshi Asaeda as designated experts for
this document. Any objections to approving these two as experts? I'm hearing no
objection, so we will send this official note to IANA.

6.5 Designated experts for RFC-ietf-lamps-cmp-updates-23 (Certificate
Management Protocol (CMP) Updates) [IANA #1241372] (Roman Danyliw)

Amy: Roman has identified Hendrik Brockhaus, David von Oheimb, and John Gray as
designated experts for this document. Any objections to approving them? I'm
hearing no objections, so this is approved and we will send an official note to
IANA.

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

Francesca: I just wanted to give a heads up to the rest of the IESG that after
quickly chatting with Martin about this COAP/IPPM related draft, I sent an
email to the IESG and no one objected to this being done in CORE. We will keep
IPPM involved.

Andrew: If we don't have an informal next week, Happy Christmas etc etc.

Amy: We have one on the schedule but I don't know if anyone is going to be
available.

Lars: I just put on the topic from earlier but we can move that to January.

Warren: I do still have the topic of surprise authors so I will send around a
document. If people have useful comments we won't have to have an informal.

Lars: None of these are important, so they can pop into January. I also want to
discuss redrawing the boundaries between the areas a bit because Transport is a
lot smaller than all the other areas and we need to balance that out a little
bit. I'm going to go through the last few years of telechats and see how many
RFCs from each area. We don't have to discuss this now but a topic for a future
telechat is how can we share the load from the bigger areas. Heads up that's
going to come at some point.

Zahed: Martin and I have been talking about this because we're looking at
transport shrinking even a bit more with maybe some groups closing.

Lars: There's an opportunity here to rebalance. Maybe it'll be transport plus
something else.

Zahed: I think we should have those discussions. Martin and I are both a bit
concerned.

Lars: Spring is a good time to discuss this.

Zahed: This might be a retreat topic where we can sit down together. It needs
more thinking.

Lars: We can do that but the retreat is unlikely to be before May. Anyway, I'm
going to do some digging and come up with some data that you can all then
disagree with and take from there.