Narrative Minutes interim-2024-iesg-16: Thu 14:00
narrative-minutes-interim-2024-iesg-16-202408081400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2024-08-08 IESG Teleconference

These are not an official record of the meeting.
Narrative Scribe: Jenny Bui, Secretariat

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Amanda Baber (ICANN) / IANA Liaison
Jenny Bui (AMS) / IETF Secretariat
Deb Cooley (Department of Homeland Security, Cybersecurity and
 Infrastructure Security Agency) / Security Area
Jim Guichard (Futurewei Technologies) / Routing Area
Mahesh Jethanandani (Arrcus) / Operations and Management Area
Erik Kline (Aalyria Technologies) / Internet Area
Murray Kucherawy (Meta) / Applications and Real-Time Area
Warren Kumari (Google) / Operations and Management Area
Karen Moore (AMS) / RFC Editor Liaison
Cindy Morgan (AMS) / IETF Secretariat
Tommy Pauly (Apple) / IAB Chair
Zaheduzzaman (Zahed) Sarker (Nokia) / Web and Internet Transport Area
Orie Steele (Transmute) / Applications and Real-Time Area
Gunter Van de Velde (Nokia) / Routing Area
Éric Vyncke (Cisco) / Internet Area

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
Roman Danyliw (CERT/SEI) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat
Sandy Ginoza (AMS) / RFC Editor Liaison
Francesca Palombini (Ericsson) / Web and Internet Transport Area
David Schinazi (Google) / IAB Liaison
John Scudder (Juniper) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
Paul Wouters (Aiven) /  Security Area

OBSERVERS
---------------------------------
Martin Duke
Jeffry Handal
Greg Wood
Kaliya Young

1.2 Bash the agenda

Cindy: Does anyone want or have any changes to today's agenda?

1.3 Approval of the minutes of past telechats

Cindy: Does anyone have an objection to approving the minutes from the July 11
meeting? Are there any objections approving the narrative minutes from the July
11 meeting? We'll get those posted onto the Datatracker.

1.4 List of remaining action items from last telechat

   OUTSTANDING TASKS

        Last updated: August 5, 2024

   * DESIGNATED EXPERTS NEEDED

     o Éric Vyncke to find designated experts for RFC 9575 (DRIP Entity
       Tag (DET) Authentication Formats and Protocols for Broadcast
       Remote Identification (RID)) [IANA #1367328]

Cindy: There is a management item on this later on the agenda so we'll
provisionally mark this one as done until we get to that management item where
hopefully we can fully mark it as done.

     o Éric Vyncke to find designated experts for RFC 9606 (DNS Resolver
       Information") [IANA #1367528].

Cindy: There's also a management item of that so we will hopefully be able to
mark that done when we get to that management item.

     o Francesca Palombini to find designated experts for  RFC 9595 (YANG
       Schema Item iDentifier (YANG SID)) [IANA #1369452].

Cindy: This was just added on Monday so there's an item later on the agenda to
formally assigned that action item to Francesca.

     o Paul Wouters to find designated experts for RFC 9580 (OpenPGP)
       [IANA #1369457].

Cindy: This was also just added on Monday, and there's a management item to
formally assign this action item to Paul.

Eric: To see this one as a management item, there are so many registries to be
created, about 20 of them.

   * OPEN ACTION ITEMS

     o Roman Danyliw and Warren Kumari to 1) draft a revision of RFC 4858,
       2) draft a revised IESG Statement on Document Shepherds (original
       statement October 2010), and 3) update the WG Chairs wiki to point
       to the new IESG Statement.

Cindy: Warren, any update?

Warren: In progress.

     o Paul Wouters to write a proposal for handling IANA review
       mailing lists.

Cindy: We'll mark this as in progress since Paul isn't here to report on that.

     o All IESG to review Non-WG List Review spreadsheet and note
       which lists may be ready for closure and any needed AD Actions.

Cindy: I don't think we need to discuss this one, it's just a reminder.

     o Orie Steele, Francesca Palombini, Murray Kucherawy, Mahesh Jethanandani,
       Warren Kumari to write draft of IESG statement addressing issue of
       credit in documents & the importance of capturing and addressing all
       comments as a necessary part of the consensus process, mostly
       pointing at existing advice.

Warren: I think that's also in progress, but even less so than the previous
one. No, I lied. Orie is on it.

Orie: It still needs work, but I pinged the document for folks to make some
edits on it.

Murray: There is a document, awesome. That's further along than the next two
are.

     o Murray Kucherawy and Éric Vyncke to create a draft IESG statement
       about using 2119 language.

Murray: Eric and I haven't synced up on this one. I haven't started the next
one.

     o Murray Kucherawy to draft an IESG statement on use of Internet-Drafts
       to meet "specification required" in IANA registries.

Cindy: We'll keep it in progress.

Warren: I think that one is moving along because that's part of the RFC blah
blah bis.

Murray: There is a certain amount of this that is waiting on that to resolve.

Warren: So that one is really in progress.

     o Roman Danyliw to reach out Systers about the value of writing
       recommendation letters to employers.
     o Roman Danyliw to reach out to Dhruv Dhody to better track outreach
       initiatives.

Cindy: We'll keep those in progress.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-rift-yang-16  - IETF stream
   YANG Data Model for Routing in Fat Trees (RIFT) (Proposed Standard)
   Token: Jim Guichard

Cindy: It looks like there are currently no discusses in the tracker so unless
there are any objections, it looks like this one is approved.

Jim: Can you put this one in revised ID needed? There's quite a few comments
from Mahesh and Orie that I haven't seen any responses to yet, and they look as
if they're going to require some changes.

Cindy: Certainly, so this will go into approved announcement to be sent;
revised ID needed, and we'll wait for you to let us know when this is ready to
go.

 o draft-ietf-opsawg-mud-tls-16  - IETF stream
   Manufacturer Usage Description (MUD) (D)TLS Profiles for IoT
   Devices (Proposed Standard)
   Token: Paul Wouters

Cindy: There are a couple of discusses but Paul is not here to discuss them
today. Do the discusser want to discuss them amongst the rest of the IESG?

Mahesh: I don't have a question specifically for Paul, but anybody here who is
a TLS expert. I don't understand that handshake process and this particular
draft is trying to define how they would configure ACL rule essentially filters
on the certificate authority list. My question to anyone who knows and how TLS
handshake is, is that something that's known upfront in the order in which the
certificate authorities are listed such that it can be written into an ACL
rule? Or is that something that's negotiated at the time of the connection?

Deb: Normally that's negotiated at the time of the connection. I was confused
by the use of the term ACL for TLS, and so one of my comments was about
business ACL stuff. I don't know how that works. I know about TLS, but I don't
know about how that works so I think it's a good comment.

Mahesh: Very briefly ACL is all about programming essentially a set of bits
that you match on in hardware, pretty much in hardware. As the packet is coming
in, you essentially load the packet header content and match it against the
number of bits to say, ok, is there a match or no? The thing that they're also
programming is the name, the certificate authority list to match against. Now
i've never first of all, seen strings being programmed into ACLs because
imagine how big that comparison would be like. Number two is, is the order well
known? And do we know what to match against?

Eric: When I read access control list, I read a layer two, a layer, three
layer, two layer, three layer four access control list. I've also seen the word
access control list being applied to anything outside of layer three and layer
four. It's unusual. More about the certificate authority, I know for sure that
my employer, but most probably every firewall or whatever vendors can apply
some access control and the name access control list based on the endshake of
TLS because it's in the clear. They all recognized some malware. For instance,
when you start TLS but the destination that you see that is an encrypted
clientele will defeat this purpose. To prevent because that's surveillance is
basically for the good guy, we can see was the CA that was the destination
name. You want to go to malware.example? We'll block you. You want to go
goodguy.example? We'll allow you. I guess this is where everything is there.
Then again, i'm not an expert.

Erik: I assumed it's not like a literal ACL in the routing config sense, it's
an abstract concept.

Deb: That's the only thing that makes sense right? It doesn't look like an ACL
like anything that i've ever heard described as an ACL before. Only in the very
most abstract sense in that there's a control list that might be a list of
strings, as opposed to a bitmap which is what you'd see in an unix ACL. There's
a lot about this draft that confuses me and I'm glad you lodge discusses. I
wrote comments and one of my comments was 'I don't understand how you're using
the acronym ACL here' and I got a very terse answer back.

Mahesh: I'll continue the conversation with the authors and seems they did
respond but I have to really go through their responses to see if that makes
sense.

Cindy: Do the folks who have discusses think this is going to require a revised
ID or should we just put this in AD follow up and Paul can pick it up when he
gets back?

Warren: Sounds like it needs a new ID, in my opinion.

Deb: I would say it needs a new ID.

Cindy: This will stay in IESG Evaluation; revised ID needed and Paul can follow
up when he gets back.

 o draft-ietf-bess-evpn-mh-split-horizon-10  - IETF stream
   EVPN Multi-Homing Extensions for Split Horizon Filtering (Proposed
   Standard)
   Token: Gunter Van de Velde

Cindy: There is a discuss from Roman who unfortunately is not here with us
today to discuss this discuss.

Gunter: The lead author was away for about two weeks after IETF but he
responded this morning, so I think he will acknowledge the discussion from
Roman. He will update the draft and make it very clear that there will be more
registries and basically Roman was correct. The draft needs to be updated.

Cindy: It sounds like this will stay in IESG Evaluation with a substate of
revised ID needed.

 o draft-ietf-cose-key-thumbprint-05  - IETF stream
   CBOR Object Signing and Encryption (COSE) Key Thumbprint (Proposed
   Standard)
   Token: Paul Wouters

Cindy: There are currently no discusses in the Tracker or unless there is an
objection, it looks like this one is approved. I don't hear any objections but
since Paul isn't here, we're going to put this into Approved Announcement to be
sent; AD follow-up so he can do a last check and confirm that this actually is
all ready to go. There's also a couple of down refs on this that we'll be
asking him if those should be added to the registry when he lets us know that
this is ready to go.

 o draft-ietf-ccwg-rfc5033bis-07  - IETF stream
   Specifying New Congestion Control Algorithms (Best Current Practice)
   Token: Zaheduzzaman Sarker

Cindy: It looks like there's a discuss from Roman, who again is not here.

Zahed: Thanks for all the comments that we got. I think the authors are
replying to that and also the authors are in conversation with Roman with the
proposed changes. I'll let that happen and see how that resolves. For now this
will be revised ID needed.

Cindy: This will stay in IESG evaluation with a substate of revised ID needed.

 o draft-ietf-lisp-name-encoding-11  - IETF stream
   LISP Distinguished Name Encoding (Proposed Standard)
   Token: Jim Guichard

Cindy: There is a discuss from Paul who is not here.

Jim: This one is giving me a headache to be honest because the reviews are
talking about the use of ascii but the reviewers can't seem to agree on what
the right thing to do is. The author, Dino, doesn't seem to know what to do
either so I guess this is going to have to be discussed with Paul when he gets
back because I really don't know what to do here.

Orie: You might find some use in pinging the ART list, if it's related to ascii
Unicode considerations. You may get some good comments.

Deb: So I looked at the list before commenting on this and it looks like
there's a member of the working group that had a suggestion from the author,
but I didn't see the author respond to that and I don't remember the person's
name.

Jim: There's been quite a few things flying around. Dino's response to me was
like: 'It's in your hands now' but no, it's not in my hands. There are comments
that need to be addressed and Paul's got this discuss. I'm hoping that Paul can
guide me a little on this one when he comes back. It's not an area I have
expertise in so i'm kind of flapping around a little bit. We'll put this one in
AD follow-up.

Cindy: This will stay in IESG Evaluation with a substate of AD follow up, and
there downrefs in this, RFC 8060 which is an experimental document. When this
approved should that be added to the downref registry?

Jim: I think so, yes.

Murray: Before we move one, maybe we should make a suggestion to the authors
that a security considerations that say there are none, will always draw fire.

Zahed: I agree, I didn't discuss on it but I really hate saying that there's no
security considerations without beginning any context.

Jim: Yeah, there's several things to be resolved but the main thing i'm
concerned about is, initially, figuring out what encoding this is supposed to
be. He's insistent on ascii, and he's getting feedback saying it's problematic,
but nobody seems to be able to direct on what the right thing to do is.

Warren: Two quick questions, well, a comment and a question. It didn't really
feel ready to me, the document, but I think that some of it is or at least what
I had assumed is the set of people who are actually doing and implementing this
might have more knowledge and I don't really think people who aren't
implementing this are likely to suddenly stop doing so. If we go back, is it a
Datatracker bug that one of reviews shows serious issues, but that tag doesn't
have a circle around it?

Murray: I noticed that too, that should be bright red.

Warren: I'll try to remember to open a Datatracker bug.

Jim: I didn't catch that. I'll follow up with Dino and see where we can take it.

Cindy: Anything else on this lisp document? That will stay in IESG Evaluation
with a substate of AD follow up.

 o draft-ietf-cdni-https-delegation-subcerts-09  - IETF stream
   CDNI Metadata for Delegated Credentials (Proposed Standard)
   Token: Francesca Palombini

Cindy: There are a couple of discusses, does the IESG want to discuss these now
with Francesca? I guess Murray, that's really a question for you since you're
the only discuss holder that's actually on the call.

Murray: Unless they're able to explain what the stuff in my discuss says, it's
going to need a revised ID needed.

Cindy: We will leave this in IESG Evaluation with a substate of revised ID
needed, and Francesca can follow-up on this when she is back.

 o draft-ietf-extra-processimip-08  - IETF stream
   Sieve Email Filtering: Extension for Processing Calendar
   Attachments (Proposed Standard)
   Token: Murray Kucherawy

Cindy: It looks like there are no discusses in the Tracker so unless there's an
objection, it looks like this one is approved.

Murray: Does it have enough ballots now? It didn't before, I guess it must.

Cindy: It does, yes.

Murray: You can approve this one.

Cindy: Is this ready to go as is or does it need any revised ID or follow up?

Murray: That's a good point, I do like to check with them first. Can you do AD
follow up, please.

Cindy: This will go into Approved Announcement to be sent with a substate of AD
follow up, and Murray, you can let us know when this is ready to go.

 o draft-ietf-pim-3228bis-06  - IETF stream
   IANA Considerations for Internet Group Management Protocols (Best
   Current Practice)
   Token: Gunter Van de Velde

Cindy: It looks like there is a discuss from Paul who isn't here to discuss
this discuss with us today. Is there any other discussion that the IESG would
like to have of this document?

Gunter: No, not really. Brian is very responsive to Paul but he was already out
so nothing really changed on that side. I'm looking to Paul at the moment to
look into the answer for Brian and then it take from there.

Warren: Generally, before I put a discuss on a document, I try to poke the
authors off list and just ask them stuff. I've been looking at some of the
discusses this week, and I can't always do that. Obviously, if I ballot very
late or something or if I can't reach them but is that what people are
generally doing or just me? It feels like this week, we got more discusses than
usual.

Gunter: What I do sometimes is, I set it to like no opinion and I sort of like
send something out and based upon that i'll go into discussed or put some other
thing. Just be gentle in the beginning, but that's maybe just me being a rookie
AD. I'm not sure if that's the right thing to do, but it seems to work.

Mahesh: Warren, does it help when you go off list and have the discussion?

Warren: There's one further down from IDR on BGP send failure, I can't remember
what the document is called (draft-ietf-idr-bgp-sendholdtimer) and I just poked
Job on Slack saying I don't understand this, it doesn't seem to make much
sense, and he explained to me what it was and I was like "Yes!" I think it
often does, it depends on what the actual discuss is.

Deb: So I will say that I've never done that. I must confess I don't think
there's been a telechat cycle where we haven't been slammed completely to the
wall. It's hard to read 16 documents and reach out to 16 authors and still get
the work done. In fact, I didn't, like there's like six documents I didn't even
review for this cycle, and I know Paul's on leave so i'm expecting that he
might do that ordinarily , he didn't do it for this one.

Warren: This wasn't poking at Paul, it's just a general, is my workflow
different to other people? What I try very hard to do this time, I think there
were three documents that I didn't actually ballot on is Jen Linkova's comment
at the plenary on, trying to give people 24 hours. I tried really hard to do
that.

Deb: That comment was completely ridiculous, she wants then you would need to
move the actual telechat stuff up. I think the actual answer to that particular
comment was, you can't expect to have comments until the telechat after the
telechat you shake stuff like there's no reason to take away the two weeks were
given to actually review 400 pages of documents.

Murray: I remember someone giving feedback in a panic because they started
getting discusses the night before but that was because that person had an
expectation that they fixed everything before the telechat, which means we have
left them like an eight hour window to respond to everything, or they felt like
we have left them an eight hour window. We had to explain to them there's no
expectation that the document to arrive at the telechat in perfect condition. I
think this might be an expectation thing we need to manage.

Warren: That person who freaked out, I believe they generally participate in
IEEE and they had misunderstood and thought we were trying to submarine destroy
their document. That was some of the impetus for writing how to handle
discussed ballots or something. We added things in there about getting comments
late, and not to worry about it.

Eric: But it's always, the earlier the better. My agenda is more relax than
maybe many other people so i'm more relaxed. Like Erik Kline said in another
thing, the grey old ADs know how to schedule stuff better.

Cindy: So there's still a discuss on this document. Gunter, do you think it's
going to require a revised ID?

Gunter: It really depends on how Paul says, I think.

Warren: I would assume it needs a revised ID because I think it wouldn't hurt
to remove stuff up from the security consideration.

Deb: So he has an empty acknowledgement section, do you want that in an RFC?

Warren: Either way, the RFC editor will probably suggest to remove it. I think
we have a couple of other documents that do. It does seem a little weird, but I
suspect the RFC Editor would be be like 'ok, please remove it.'

Gunter: Probably going to need a revised draft with one line extra, I suspect
but that depends on how Paul sees it.

Warren: I do think it's odd to have an empty acknowledgment section. I
generally acknowledge anybody and everybody because it doesn't hurt and it's
also a good place to put snark.

Deb: You can put snark in the acknowledgment section?

Warren: RFC 8914, extended DNS errors. Myself and Wes Hardaker, scroll down to
the acknowledgement section. I mean, it's not really, but we thought it was.
I've got some other things where Mirja put a discuss on my document because we
had some stuff in the acknowledgement section that was more funny than she
thought was appropriate.

Cindy: This will stay in IESG evaluation with a substate of revised ID needed.

 o draft-ietf-pim-3376bis-11  - IETF stream
   Internet Group Management Protocol, Version 3 (Internet Standard)
   Token: Gunter Van de Velde

Cindy: There are no open discusses so unless there's an objection it looks like
this is approved.

Gunter: There are some comments so I want to check them out before.

Cindy: We can put this is Approved Announcement to be sent; AD follow up and
you can let us know when this is ready to go. There are several downrefs in
this document, all two proposed standard documents, RFC 2113, 2236, 4302, 4607,
and 4604 should those be added to downref registry?

Gunter: Probably, let me double check.

 o draft-ietf-pim-3810bis-11  - IETF stream
   Multicast Listener Discovery Version 2 (MLDv2) for IPv6 (Internet
   Standard)
   Token: Gunter Van de Velde

Cindy: There are no discusses so unless there's an objection, this is approved.

Gunter: There are some comments which I would like to look into.

Cindy: This will be Approved Announcement to be sent; AD follow up and you can
let us know when this is ready to go. There are a number of proposed standard
downrefs, should those go into the registry? I'm assuming you'll want to look
into those and let us know as well.

Gunter: Ok. Thank you.

 o draft-ietf-idr-bgp-sendholdtimer-15  - IETF stream
   Border Gateway Protocol 4 (BGP-4) Send Hold Timer (Proposed
   Standard)
   Token: Roman Danyliw

Cindy: There are no discusses in the Tracker, so unless there's an objection it
looks like this one is approved.

Warren: This is actually the document that I was chatting with Job. I was
originally going to put a discuss saying this should never be needed because
BGP hold timer is supposed to fix this, and it turns out a bunch of
implementations actually generate hellos in a separate thread. The hold time is
actually not as reliable as one would think so the main BGP process can get
wedge or the receive queue can get full and because hellos are generated in a
separate thread or separate process, these still come through. I figured that
was an interesting thing to note.

Mahesh: The receiver is essentially preventing the sender from sending any more
messages because saying, my queue is full so even if it's on a separate thread,
it won't help? Because you'll still get throttled by TCP. It's not really
receivable data.

Warren: It depends on how exactly you've managed towards yourself. If you're
something lke BGP process is sufficiently busy, like RPF is sufficiently busy,
it's not actually making any forward progress then you might not be able to
generate them. For example, I believe BGP hellos are generated in Juniper PPMD,
and so if RPDs are to get wedged, it would not be making forward progress but
you'll still be getting hellos.

Cindy: So there are still no discusses on this, and I didn't hear any actual
objections to approving this one, but since Roman isn't here, we will put this
in Approved Announcement to be sent; AD follow up just so he can give it one
last check.

 o draft-ietf-lsr-labv-registration-03  - IETF stream
   Revision to Registration Procedures for IS-IS Neighbor
   Link-Attribute Bit Values (Proposed Standard)
   Token: Gunter Van de Velde

Cindy: There are no open discusses so unless there's an objection it looks like
this one is approved. Gunter, is this ready to go as is or do you want to give
it a final check?

Gunter: I think it is ready as is. I do want to check with Tony very quickly if
he wants to put eyes on it and things like that. It should be fine.

Cindy: You said it's ready to go as is?

Gunter: I think so, yeah.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 NONE

2.2.2 Returning items

 NONE

2.3 Status changes
2.3.1 New items

 NONE

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-mops-treedn-05  - IETF stream
   TreeDN- Tree-based CDNs for Live Streaming to Mass Audiences
   (Informational)
   Token: Éric Vyncke

Cindy: There are no open discusses for this document, so unless there's an
objection it looks like this one is approved.

Eric: It's approved but put revised ID needed, there are some comments that are
easy to address and it should be addressed.

Cindy: This will go into Approved Announcement to be sent; revised ID needed
and you can let us know when it's ready to go.

 o draft-ietf-teas-gmpls-controller-inter-work-15  - IETF stream
   Interworking of GMPLS Control and Centralized Controller Systems
   (Informational)
   Token: Jim Guichard

Cindy: There are no open discusses in the Tracker so unless there is an
objection, it looks like this one is approved.

Jim: I know there are a couple of nits I saw in the comments. I'm not sure how
important to fix those, but I do want to go through those and double check so
if you can put it in AD follow up for this one.

Cindy: This will go into Approved Announcement to be sent; AD follow up and you
can let us know when it's ready to go.

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 o draft-halpern-gendispatch-antitrust-09  - IETF stream
   Antitrust Guidelines for IETF Participants (Informational)
   Token: Roman Danyliw

Cindy: There are no discusses in the Tracker so unless there's an objection, it
looks like this one is approved.

Murray: Isn't this a BCP so it needs more positions?

Cindy: No, it's going for informational. Hearing no objections, but Roman is
not here, we will put this in Approved Announcement to be sent; AD follow up
just so that he can give it a final look through and let us know when it's
ready to go.

3.2.2 Returning items

 NONE

3.3 Status changes
3.3.1 New items

 NONE

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 NONE

3.4.2 Returning items

 NONE

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

 NONE

4.1.2 Proposed for approval

 NONE

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 NONE

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Cindy: Of the four potential crossover folks, I think Tommy, you were the only
person who was on yesterday's IAB call, so is there any IAB news that the IESG
can use? As I said that, it looks like Tommy has also dropped off from the
call. I was on that call yesterday and I call you that the IAB is working on
their workshop on AI Control that will be in September. The call for papers for
that closed last week, so the program committee is reviewing stuff there and
then they are also planning for the Future of Network Management Operation
workshop that will happen in December. Elliot Lear will join them next week to
discuss the ISOPEN session that happened at IETF 120 and things coming out of
that for the IAB.

Deb: Those calls aren't open are they?

Cindy: They are. IAB calls are open to the public unless they go into executive
session.

Warren: They are also in the IETF calendar, if you want.

Cindy: Yes, they are listed in the Datatracker calendar so you can see them
there. Basically, they're using the interim meeting infrastructure, but not
sending weekly announcements because that was determined to be too noisy.

6. Management issues

6.1 [IANA #1367916] renewing early allocations for
draft-ietf-idr-sr-policy-safi (IANA)

Cindy: This is one of John's document and I don't know if we want to wait for
him to come back or if the IESG is OK approving this without him.

Jim: Probably want to wait for John on this one since it's the fifth renewal.

Cindy: Why don't we put this back on the next agenda so hopefully John can join
us for that.

Erik: Jim, didn't we recently review a document that used this registry?

Jim: I don't remember. I'm trying to remember, i'm pretty sure it's a document
that Linda Dunbar was involved in this SD WAN thing and John was on it for the
Tunnel Encapsulation. I don't remember what the outcome of that one was, I'd
need to go look.

Eric: But five renewal is quite unusual, right?

Jim: That's what caught my eye. Let's just put this on the next telechat, John
will be back by then.

Cindy: Ok. We will pick up this again at the next telechat.

6.2 [IANA #1367328] Designated experts for RFC 9575 (DRIP Entity Tag (DET)
Authentication Formats and Protocols for Broadcast Remote Identification (RID))
(Éric Vyncke)

Cindy: Eric, this was an action item that was assigned to you, and this is to
approve Adam Wiethuechter  and Mohamed Boucadair as the designated experts for
this registry. Are there any objections to that?  Hearing no objections, those
are approved. We will send that official note to IANA.

6.3 [IANA #1367528] Designated experts for RFC 9606, "DNS Resolver Information"
(Éric Vyncke)

Cindy: This was the other action item for Eric, this is to assign  Tirumal
Reddy, Mohamed Boucadair, and Ben Schwartz as the designated experts for RFC
9606. Are there any objections to that? Hearing no objections, those are
approved and we will send that official note to IANA.

6.4 Two new expert reviewers for JMAP registries (IANA)

Cindy: Murray, you wanted to add Joris Baum and Arnt Gulbrandsen as designated
experts for the JMAP registries. Are there any objections? Hearing no
objections, that is approved and we will send that official note to IANA.

6.5 NomCom Updates (Orie Steele)

Orie: I think as you know the NomCom process has started and unfortunately, I
was not aware that I needed to gather up job descriptions from you all, prior
to IETF 120. I have a few days breather room, and I know a lot of people take
vacation after IETF and yet we still need to get the job descriptions posted so
that the process can continue. I had shared a Google Doc with the IESG members,
there's a general desired expertise section which sort of applies to all area
directors, and then for reach area, a job description that sort of specific to
that area and every time we go through a cycle it's an opportunity to make some
adjustments of what talent or expectations we have for area directors in that
area during the next NomCom cycle. My intention is to share with the NomCom
Chair the revised job description after today's meeting. I had hoped Roman and
some of the other folks would be here who could give a final sign off on it,
but I think at this point, I may step out of my liaison limb and share with
them the current job description after applying all comments after today's
meeting unless there are strong objections from anyone on the call.

Warren: Sounds great to me.

Zahed: I was hoping this weight area description is also reviewed by Francesca
but I think she's not available. So I have tagged you and Murray to actually
have a look at it then because you also might need to sync up with what we have
in ART and what we have in WIT due to the changes. I have initially done the
work and I didn't see much of a comment from any others.

Orie: I reviewed and actually stole some of your text regarding the review team
for our area. I think you did a good job and just for the record, if you want
to update any of these position in the NomCom wiki, I can facilitate changes in
the future.

Zahed: That's makes me more comfortable sharing it because what I might see
that couple of working groups that Francesca has might have a kind of different
requirements than what we have right now. We might amend it later.

Orie: I have the action. I will share the revised desired expertise and i'll
coordinate with Roman and the folks who couldn't make the telechat if they had
any additional comments.

6.6 Col Disclosure (Erik Kline)

Erik: During Vancouver, I had found out that Rick Taylor was going to accept an
offer that my company had made him. He formally started, I think at the
beginning of the week. While I was in Vancouver, I discussed with Roman what I
should do about the disclosure process because I read the disclosure document
and it seems like, as I think I put in Slack somewhere, 99% of it lists things
that could qualify as conflict and the actual to do parts seem to be mostly
about disclosure. Roman said that I should talk it over with the other DTN
Chairs, and with Eric, and I did that while I was there. Eric, you can correct
if i'm wrong, but we all agreed that any documents that Rick or I write would
be shepherded by the other chair or another shepherd, if we could find one then
would be AD by Eric. Roman said if Eric was OK with it, to bring it to the IESG
and based on the outcome of this discussion, there would be some email sent to
the DTN working group to see what that community thinks. I don't really know
what the procedures are here though.

Eric: After you check all the things, I think it's done.

Warren: I think you've done it all. This is not uncommon thing especially with
larger companies with Cisco and Juniper, and I guess possibly Google too, where
there's enough people involved where it's unavoidable.

Erik: Well in this case, it's small. Small community and small company.

Warren: I think having all chairs be from the same company is more problematic
than a chair and an AD.

Zahed: So what is the problem?

Warren: It's more like crossing the T's and dotting the I's.

Erik: It's just doing the right thing.

6.7 [IANA #1369452] Designated experts for RFC 9595 (YANG Schema Item
iDentifier (YANG SID)) (IANA)

Cindy: This is brand new and on here to assign the action item to Francesca to
find the designated experts for these registries.

6.8 [IANA #1369457] Designated experts for RFC 9580 (OpenPGP) (IANA)

Cindy: This on here to assign an action item to Paul to find designated experts
for these registries.

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