Narrative Minutes interim-2024-iesg-17: Thu 14:00
narrative-minutes-interim-2024-iesg-17-202408221400-00

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

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Jenny Bui (AMS) / IETF Secretariat
Deb Cooley (Department of Homeland Security, Cybersecurity and
 Infrastructure Security Agency) / Security Area
Jay Daley / IETF Executive Director
Roman Danyliw (CERT/SEI) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat
Sandy Ginoza (AMS) / RFC Editor Liaison
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
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Web and Internet Transport Area
Zaheduzzaman (Zahed) Sarker (Nokia) / Web and Internet Transport Area
John Scudder (Juniper) / Routing Area
Orie Steele (Transmute) / Applications and Real-Time Area
Sabrina Tanamal (ICANN) / IANA Liaison
Gunter Van de Velde (Nokia) / Routing Area
Éric Vyncke (Cisco) / Internet Area
Paul Wouters (Aiven) /  Security Area

REGRETS
---------------------------------
Tommy Pauly (Apple) / IAB Chair
David Schinazi (Google) / IAB Liaison

OBSERVERS
---------------------------------
Adrian Farrel
Patrick Meenan
Laura Nugent
Behcet Sarikaya
Kent Watsen
Greg Wood

1.2 Bash the agenda
Liz: Does anyone want to add anything new to today's agenda?

Roman: I would like to bash the agenda for an executive session so we can talk
about some of the things I've been trading relating to the IETF 125 survey.

Liz: Great. We can add an executive session at the end. Any other changes to
the agenda?

1.3 Approval of the minutes of past telechats

Liz: Does anyone have any objections to the August 8 minutes being approved?
Hearing no objections so we'll get those posted in the archives. Does anyone
have an objection to the narrative minutes from the August 8 teleconference
being approved? Not hearing any objections there either, so those are also
approved and we will get those posted.

1.4 List of remaining action items from last telechat

   OUTSTANDING TASKS

        Last updated: August 19, 2024

   * DESIGNATED EXPERTS NEEDED

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

Francesca: Got it, thanks. There's an email to answer to the IESG from the RFC
editor, so just to say i've seen it.

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

Paul: In progress.

     o Orie Steele to find designated experts for  RFC 9581 (CBOR)
       [IANA #1372387]

Liz: We'll make sure that Orie has that on his list.

   * 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.

Roman: We need to talk, Warren. This was a large thing now, we should talk
about whether we can really close this and if this still makes sense or whether
its OBE cause it's been awhile.

Warren: Can we declare it OBE because I don't think anyone's clamoring for it.

Roman: Yeah. I would like to go that way. Let's pull it off and say, we thought
it was a good idea, let's stick to the status quo.

Warren: I think we should mark it as completed so that we can at least pretend
we did something.

Eric: OBE stands for overtaken by events, right?

Roman: Yes. We said we would do it a year ago, we didn't do anything with for
the first six months and I didn't do anything with it in the next six months.
It's clearly not pressing the way we though it was a year ago, unless someone
wants to take it from us.

Francesca: Is there a list of items that were overtaken by events?

Warren: This is basically, we thought we wanted to work on it at the time, a
lot of people seemed excited but nobody really cares anymore.

Francesca: I understand but sometimes things come up again so it might be good
for history reasons to have such a list of things the IESG wanted to do but
didn't get to or they didn't happen and that's why.

Liz: We could definitely start a list like that in the wiki, but usually we
would just remove it from the list of any progress items whether it's completed
or not completed. Ok, we'll take this one off the list.

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

Paul: I'll put it back for the informal for next week.

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

Roman: My question to the IESG is, have you felt like you've had enough time to
kind of work through that and do want to batch close whatever has been marked
as close and stop tracking that because we've been working on this since April.
Has everyone felt like they've had a chomp at this?

Warren: I think so, yes. I mean i'm sure we could do a more thorough one but i
think it's good enough for that that we could just batch close the ones that we
haven't. I know we have also closed a bunch of them ourselves already.

Roman: Then I will go into the spreadsheet you had indicated that you wanted to
close and we were going to batch up in one request to say like we would now
like kind of them closed. I'll take that action and we'll say from there that
the review has kind of happened in the non working group list we want to keep
open, we'll keep open.

Paul: Can you share that link again? So I know that the groups I think the
lists that I need to close are on your list.

Roman: If i'm not mistaken, the magic is in the IESG only Slack channel. if you
look at the pinned non working group list, you can see those that are marked
with that status. I'll send a pointer.

Mahesh: I think I told the Secretariat to close the list, maybe I didn't update
the list.

Warren: I've also gone through and closed a number of mine.

Roman: That's my fault. I thought in certain cases folks went direct and closed
and I think in certain cases we were holding things for a batch. If I
misunderstood, I'll go in there and take a look if there's any questions, i'll
follow up with all of you. Thanks for taking the time to look through all of
that. It wasn't easy.

Liz: It seems like this particular action item is done so we'll take this off
the list as well.

     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: That's actually really in progress. Orie has a good start on it. I know
that we had meant to go back and complete it, but I think we got sidetracked.
Orie, if you wouldn't mind pasting it again or sending the link again.

Orie: Will do.

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

Eric: In progress.

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

Liz: We'll mark this 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.

Roman: So the next two are marked for me, if i'm reading the dates right they
came out from the Vancouver meeting, right?

Jenny: Yes, they came out of the IESG only meeting in Vancouver.

Roman: I vaguely recollect the first one in the thread. I've been talking to
Dhruv about the second one. Do the meeting minutes have further details?
Because I don't remember saying that was an action for me because i'm not sure
what we're supposed to better track because Dhruv and I were talking and he was
saying 'do you know what I should be doing more of?' I don't know what i'm
supposed to tell you.

Jenny: I can review the meeting minutes.

Roman: Does anyone remember this?

Mahesh: Roman, I know that the IAB is conducting a bunch of workshops and as
part of that, they're also trying to do an outreach into the operator
community, going to events such as NANOG so I don't know if this discussion
came up in that context.

Warren: I think you might already have done this. I'm gong to NANOG, and i'm
having discussions with some of the IAB folks, including Dhruv on presentations
there. I think that you had this discussion on the IAB meeting two or three
days ago.

Roman: I'm going to declare that done and full credit to Dhruv, he's the only
one doing all the work. He is organizing all of us in a great way. It's better
with the community coordinator now. Let's call that one done, and let's leave
the first one about recommendation letters.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-netconf-http-client-server-23  - IETF stream
   YANG Groupings for HTTP Clients and HTTP Servers (Proposed Standard)
   Token: Mahesh Jethanandani

Liz: We have a discuss. Do we want to discuss this now?

Francesca: First, I want to thank the authors and Mark for engaging. I sorted
the HTTP DIR review sort of late, and  Mark was kind to provide one very quick.
I just want to remind everyone that anyone can ask for HTTP DIR review. We
probably should have had this conversation a bit before the telechat. I've
looked at the back and forth, and I just wanted to bring up Mark's concerns and
the use of or configuration for HTTP client, I think it's the one thing that
stands out. I looked at Kent's reply, and I see you're on the call. The main
issue I see, Kent was saying that working group members said it should be
possible to configure a client to use only specific HTTP versions and that's
why it was added to the document. I guess I do not understand why this needs to
be stated in the document, and that's from me not having netconf experience or
knowing the background of this. Assuming it is that you actually have, I don't
understand how this configuration maps to the HTP implementations and make sure
that this configuration does not add requirements HTP that sound not exist
because of the way HTTP works. If there are some text that we can add to
clarify that, that would be a compromise, it's just not clear to me. I also
reached out to Mark offline to see if he can also provide more information
about that.

Mahesh: I think part of it is really Kent trying and me trying to understand
really where the concern is coming from Mark. As you said, really it comes down
to that one issue of the client trying to specify a version of HTTP that it
wants to use. But I'll let Kent talk or give a little more background than I
have on it, and essentially explain why it's needed.

Kent: It's not so much that netconf needs it. This particular YANG module is
useful for protocols beyond netconf working groups, any HTP protocol could
possible use it, but the question at hand is, is it desirable to allow an HPD
client to want to restrict the versions of HPD it's willing to use and
certainly when using a browser or a human in the loop, and you can type in an
URL, it's understood that, the browser will negotiate. But here we're talking
about configured, it's configuration, you're configuring a device to act like
an HTTP client and so in that sense, it's not really first contact. It's like
second contact. The first contact is being configured and the second contact is
acting on the configuration so why would it not be OK to say, I only want to
use HTTP3 for instance. I don't want to use HTTP2 or HTTP1.1, and that's the
issue at hand. It's unclear why this would be a problem to allow for a client
to specify which version.

Mahesh: I think maybe part of the thing which I'm not sure entirely with that
Francesca brought up is, would specifying a version, e.g., impact I don't even
want to say the internet, right? I think the  point that you were also
mentioning is that if the worst case that can happen is the client will never
find a version that it can negotiate and fail.

Kent: Possibly. Absolutely. So if the client says it only wants to do HTTP3,
but it connects to a server, it says it can only do HTTP2 then it should fail
and that's perfect. That's exactly what we'd want, and then the client would
then move on to another server, presumably it's a configured to be able to
connect to more than one serve. Also, I just want touch on something that
Francesca said, no way is the configuration model intended to impact the
protocol. The protocols, they are what they are, we're simply trying to enable
them to be configured. It's not implying any restraints or restrictions on
protocol development going forward.

Francesca: Because of the way HTTP works, and the way the versioning is
negotiated also at runtime, you are impacting the protocol if you say you're
only allowing a certain version and you're not allowing this negotiation to be
done the way it's done.

Kent: True. I mean in terms of a standardization process, we're not
restricting. HTTP3 and even HTTP2, using TLS 1.3 and it has APLN application
level protocol negotiation, and so built into TLS is the ability to negotiate
what protocol you're using. It says that the client specifies a list of
protocols that they're willing to run and the server responds with what it's
going to use. It's how to configure the client as to which protocols it will
advertise in the APLN header in the TLS negotiation.

Francesca: That's on par of what I meant when I said how this maps to the
actual HTTP implementation or client implementation. I think that we can
continue maybe this discussion with Mark also on the list, and hopefully we can
get some clarification text or some actionable thing that can be done. I
appreciate you working with us Kent, on this.

Zahed: During our conversation, I also realized this is something related to
what you guys have been discussing so far, HTTP and TLS 1.3, have a very close
relation and the way we'll fine it for HTTP2, you have TCP and TLS and all this
thing. We might need to think if we might need to do for the same for HTTP3. I
think we just need to think a bit more about how you do that. I think you have
some really good alternative versions but now i mean, as you mentioned, none of
them perhaps the perfect one. I also wrote in my mail, this all depends on what
you want to do. You want to configure something or get the configuration out of
the device, then that's a different case like if client wants to connect to a
serve because the server by default supports a variety of clients and variety
of versions of HTTP so you have negotiation and all these things. But if it's
just configuration, you might actually get to skip a lot of things and more
details, like this is the certificates I want, this is the port I want, this is
the version I want, and all these things. Let's have the discussion but don't
forget the QUIC, TLS, and HTTP part because that will need some discussion.
I'll encourage you can also involve QUIC experts. I'll also ping the QUIC
working group chairs too to see how they can help here.

Kent: That'd be great. But Zahed, the conversation you and I have been having
just recently has been on the HTTP server side or how to configure the HTTP
server. Mark's discussed this with regards to how to configure the HTTP client.
But slightly different, but, I agree, actually he probably should had the
discuss on the HTTP server.

Zahed: I was actually thinking of putting a discuss on this one, but as I said,
if it's not discussed even but as it is now, there already Mahesh knows about
this one I think, please handle it as a discuss otherwise I will change the
ballot, if that helps. But it doesn't matter like now we have an issue that
needs to be solved whether it's a discuss or comment, it doesn't really matter
or at least  for me.

Kent: The what we're discussing right now is, not fundamental, it's not like
architecture, like what should be done, it's just how it should be done with
Mark,  it's more the architecture it's like what should be done? Like, should
it be possible to configure a client? So it's a much higher level question and
that's the one that we're trying to resolve right now. Happy to take it offline
Francesca, if that helps.

Zahed: If it helps, I can elevate my comment to a discuss, but I trust you guys
to handle it and just ping me when it's done.

Mahesh: If you want to, but otherwise I will when the document comes up for
review track to make sure that the comments are addressed.

Liz: So this document is staying in IESG Evaluation for now, and i'm guessing
maybe revised ID needed?

Kent: Yes.

Liz: Ok. Great. This will be IESG Evaluation with a substate of revised ID
needed.

 o draft-ietf-bess-evpn-fast-df-recovery-10  - IETF stream
   Fast Recovery for EVPN Designated Forwarder Election (Proposed
   Standard)
   Token: Gunter Van de Velde

Liz: We have a discuss, do we want to discuss this one today?

Gunter: I think it is being discussed between author and John, so progress is
on the way.

Liz: This one will also stay in IESG Evaluation, will it also need a revised ID?

Gunter: Probably.

Liz: This one will be in IESG Evaluation, revised ID needed.

 o draft-ietf-nfsv4-delstid-05  - IETF stream
   Extending the Opening of Files in NFSv4.2 (Proposed Standard)
   Token: Zaheduzzaman Sarker

Liz: There are no discusses in the Tracker so unless there's a objection now,
it looks like this one is approved. Ok. This one is approved. Is this ready to
go as is, Zahed?

Zahed: No, I think Gunter has some really good comments. I think it needs a
revised ID. Thanks everyone for your review, I think this will help the
document. Gunter, do you want to say something? This is approved, but I think
i'll ask the authors.

Gunter: No, I'm not a NFS person, just some comments.

Zahed:  I think most of the comments are editorial and clarification so then
that should be done before it gets to publication, so this is approved, revised
ID needed.

Liz: This one is approved announcement to be sent; revised ID needed.

 o draft-ietf-dnsop-rfc8109bis-06  - IETF stream
   Initializing a DNS Resolver with Priming Queries (Best Current
   Practice)
   Token: Warren Kumari

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

Paul: Warren, do you think we can get the DNS cookies?

Warren: We can probably mention something that the client could ask for cookies
or something.

Paul: I think we should write it because right now it talks about you should
use source port randomization.

Warren: The reason for that part and not originally mentioning cookies is that
this is supposed to be from the client standpoint and the servers would need to
be supporting cookies in order for it to actually be useful and it didn't want
to be putting it on the server. But I just chatted with Paul Hoffman and we
could probably just put in something saying: should ask, should do
randomization, and use cookies if they're available or something which is
hitching bets.

Paul: That's fine, as long as it puts him in the right direction.

Warren: Approved announcement to be sent; revised ID needed, please.

Liz: Ok. That's approved announcement to be sent; revised ID needed, and you
can let us know when it's ready.

 o draft-ietf-httpbis-compression-dictionary-14  - IETF stream
   Compression Dictionary Transport (Proposed Standard)
   Token: Francesca Palombini

Liz: We have a discuss, do we want to discuss this now?

Francesca: I think so. First of all thank you all for the reviews, and thanks
to the authors and I see Patrick is one the call, thanks for joining for a very
quick reaction and I believe Patrick has addressed all the comments. There is
this discuss from Roman that we should talk about, but there have been a lot of
messages, and i'm not sure that I have caught up with all of them. I would
appreciate for some summary if someone has followed the whole discussion, and
we can it from there about the references to living specification.

Patrick: So on the discuss specifically, as far as I understand, this is the
best practice for referencing the living standards. There are get snapshots
available for all of the what WG standards, but they don't allow you to link to
them for implementing standards. They require you to link to the heads. What I
did do though is the fetch standard is huge. So the parts of the fetch standard
that this actually requires, I added anchor based links and references to, so
they should be more stable over time and it'll bring people to the specific
part of the standard they need. For the URL pattern standard, it's a much more
concise thing and the whole URL pattern applies for the document. So I left the
reference to the main URL pattern spec.

Francesca: Thanks Patrick. Roman, did you want to?

Roman: First, I want to say, Patrick thanks for the quick response and also on
the edits for my comment. I had a clarifying kind of question. I'm certainly
aware that on the living standards because I try to find the github links in
the commit messages that if you try to do the deep link, there is a clear kind
of warning that says don't do that. So my confusion on the presentation here is
that if living standards from this organization or this gu github repo our
living standards, there is no sense of timing or dates, it's just whatever is
at the URL. I'm trying to understand, why, like, e.g., what does it mean to say
fetch living standard June 2024, right? There is no such thing as June 2024.
You would never want to reference June 2024, let alone June 24 at 1005. There
is only one kind of URL. So is the pattern of citation, just the URL plus the
date or was the date just added to, can you just tell me why there's a date?

Francesca: I can answer to this, I don't have a final answer to this, but I
I've asked the authors to format the reference, this way just because of
precedence. I saw it was done in previous documents that way and I thought this
is the way we do it and let's do it the same, but i'm against removing the date
if you think it makes more sense to not have the date. And now we also have the
anchors that Patrick has added in the reference as well, so hopefully that.

Roman: Here's my personal feeling is that it is in every other place where we
reference a github kind of repo, we never reference head we go on the deep
commit and we previously kind of ballotted kind of on that. I appreciate that
this is different and the pitch is being made that it's different. The thing
that I don't understand, kind of here is I thought in the past precedent it was
cited without dates, so what I don't know how to handle is that if I go to that
URL but I'm told only to use the June 20 2024, I don't know how to get there
and I'm being kind of told I shouldn't do that. So I don't love it, but the
positions to me a deep link to github repo then in fact, you can deliver this,
a data kind of snapshot or it's the other end of the extreme to say there's no
such thing as kind of deep linking, there is only a URL kind of without the
date. I think what we've done here is like something weird in between that's
violating both
 the both the premise of the what working group of actually providing kind of a
 date, but not satisfying the IETF of
actually providing a reference to the deep link.

Warren: So I think that some of it is the sort of templating part for putting a
reference has a date and we generally stick to a date, so I think it's kind of
like we usually do this. It doesn't make much sense to me in this particular
case. I think that it would be better if we were to just deep link to the
commit. And yes, I understand that that's not official. In the same way we say
draft should only be referenced as a work in progress. I think it would be not
unreasonable to say when we said fetch.spec.what wg.org, this is the one we
actually meant. On a separate note though, I was a little unsure how well this
whole thing worked, so I actually had a chat with Patrick and it turns out like
this actually works way better than I was thinking, like the whole document,
not the or the whole method, not the specific discussion on the, on the
reference.

Orie: For consideration, I had a chat with some folks who were more experienced
with what working group and I asked them, is it appropriate to include a date
when you cite a living standard and their position was that it wasn't and then
it would confuse people and that they would then attempt to find a commit and
then they would see the warning. Don't use this commit. So if it's possible I
would remove the date in references to what working group living
specifications. It's the, the appropriate way to cite them is top of the
treehead. When you use a what working group specification is a normative
reference, your intention is to commit to the change control policy to what
working group has, and I think their preferences don't include a date, just use
the URL and with that comes, a dependency on their change control process and
their organizational structure, kind of how they handle living documents.

Francesca: I think that this is my fault for for requesting this this specific
formatting and the author just complied with,  my request when I asked for this
fix, or what I thought was the fix and I don't think Patrick for the authors or
the working group would have any problem updating the reference that way.

Patrick: No, and I looked quickly at  the HTTP working group directory and
there's a mix, like half of the RFCs have a date, half of them don't.

Francesca: I happen to have looked at the wrong one then, but we should
definitely be consistent and from now on let's try to remember this discussion
and I will make sure to follow up if this comes up again. So I guess the
resolution is to remove the date.

Warren:  I mean, in this particular case, I think referencing it as, as they
would like makes sense because it's largely the living standard is going to be
probably always the same. But I think in the future, there might be cases where
we are speaking about a specific detail within things and so possibly in the
future, we might need to actually reference specific commits. So I don't know
if this is a hard and fast rule, but it does seem like.

Roman: Practically Patrick, I know this is a big can of kind of words here.
We're talking about it in lots of different channels. If you're ok with it, I
would prefer if you would drop the date from those two and just for just cite
the bearer URL with the anchor. You've already have kind of the anchor I'll
clear the discuss on that. Thanks for the other changes in the dashboard.

Paul: Jay actually made a good suggestion in Slack that you could add a
retrieved date somehow in a reference, so you're not pointing to a specific
version, you're just saying like when we looked at it wasn't this date.

Warren: And speaking of good suggestions, we have Sandy from the RPC here. I
don't know if she's got anything she wants to add.

Roman: I would love to hear from Sandy.

Sandy: My personal preference without knowing that the what Working Group
doesn't want you to link to specific portions, my personal preference would be
to use the deep link so that it refers to the specific version that's
available. But understanding that there is a disclaimer about that, I think
it's fine to include it without it point to the living standard, and, we don't
typically include access dates, but I could see it being relevant for this one.
We actually have someone on our team now who is doing the research on on ways
to reference different documents, different types of documents, and to help
 us formulate our style, right? Like what is the proper way to reference these
 different types of materials.  I would really
like to have him take a look at this and make a recommendation for the general
case.

Francesca: Sounds good, but hopefully we don't need to block this document,
hopefully we can do this when it's at the RFC editor if there is anything that
needs to be changed.

Sandy: I'm going to take note of the discussion that's happening here so that
we know what we're agreeing to. What the IESG has agreed to basically is what
I'm hearing is no date right now. And if something comes up where the citation
specialist is like, 'Oh I really, really recommend against that.' I'll let you
know, but I I don't really expect that to happen.

Roman: And what I'd also like to get an opinion on the retrieve date situation
as well. I don't know whether that's in between.

Warren: Isn't that the same thing as what we currently have? I mean, if we've
got in July 2024, I thought that was fairly clear. That's what we meant.

Francesca: That's what I thought too.

Warren: We could reword it to retrieve, but what I thought was June 2024 means
what WG at that point.

Roman: I'd love an official question kind of from Sandy for like the long term
kind of guidance, so I don't want to block here. I think the ecosystem has been
explained to me. Folks continue talking, but from my perspective, Patrick, when
you drop the date, i'll clear the discuss. Thank you for your responsiveness
and your kind of education for me.

Deb: When you say retrieve and you say access, that's the same thing, right?

Roman: I think it's the same thing.

Sandy: I think they're the same thing.

Deb: Is there a reason you use access and we're using retrieve? I mean I know
nothing here.

Roman: I said retrieve because I thought that's what Paul said.

Deb: Patrick said.

Roman: Jay made a comment about something.

Deb: That's just the format of the date, right?

Roman: There's nothing special to me, I don't know who said it. There's nothing
special to me about the words retrieved,
 if access is the right word, I'm fine. Whatever I mean, Sandy in the RPC knows
 better stylistically here.

Sandy: The other thing is I had seen that some of the discussion happening in
the IESG-IAB chat room, are you OK with me sharing some of that thinking or
concerns that were listed there with the citation specialist?

Roman: You can certainly extract anything I said.

Francesca: Yes.

Warren: And sort of as a more general thing I think whenever we're running into
these sorts of like what's the best way to cite stuff or things, it would be
really useful if the RPC, if they've got views can just jump in and tell us
instead of us.

Francesca: I'm sure they do already.

Warren: Kind of. Sandy felt that she wasn't necessarily supposed to chime in
until I was like, Jay mentioned we should ask Sandy and then she was like yes,
I've got views. It's also not very clear because we say people are generally
observers unless called on.

Sandy: I appreciate that. We'll speak up next time.

Francesca: Revised ID needed for this one for the same change, and I think
everything else is addressed, is that correct, Patrick?

Patrick: As far as I know, the main sticking point that's sort of still out
there is the shared broadly, files format stream format is a long ago expired
draft that has never pushed forward and how we feel about that versus going
back to the team and making them go through the steps of publishing it as a
informative RFC or something along those lines.

Roman: I was going to call that out exactly, Patrick. You're going to sit in
misref now because of that.

Warren: Does this need to be a normative reference?

Roman: It sure does, in my opinion.

Warren: It does feel a little worrying that we potentially end up with useful
documents stuck on things that are never gonna move forward. Like, it's unclear
to me that SHARED-BROTLI would ever actually finish being published so
normative reference to draft or something.

Murray: We have done that before. I'm trying to remember there like you can you
can include a reference to something that's still a draft and the references
will mark it as a work in progress, maybe not for normative references though.
Is Sandy here? Am I talking crazy here?

Sandy: For informative references it's totally fine to reference a draft that's
as a work in progress, but that's for normative references we would wait
because it means there's a dependency. Like you need to understand that
document.

Murray: That's right.

Roman: And I think we're definitely in this situation where you need to
understand that.

Warren: What do we do if we don't think SHARED-BROTLI isn't going to move
forward?

Francesca: Is there so is there any way we can extract the part of that
document that are normative to this one and and move that reference back to
informative as a if you want to read more, please see this document. That's
what I would do.

Warren: That sounds like a reasonable option. I did I had thought that we had
also in the past normatively referenced a specific version of a draft. I'm
trying to remember where, but I thought we'd had a normative reference to, as
stated in, you know, version draft-fu-bar.

Roman: Francesca, feel free to tell us you're gonna take it offline as well. We
I don't know if we need to engineer your solution for you here.

Francesca: If anyone else has opinions otherwise yes, we can continue this
discussion online. It's faster to do it, sorry, offline. It's faster to do it
online.

Warren: How much text is there in SHARED-BROTLI that we would need to?

Patrick: I imagine quite a bit of it, at least all of the file format, stream
format, tokenizing, and that kind of stuff and how the dictionaries are
referenced. Cause if you have to know how to build a SHARED-BROTLI stream to
use the bR-D content encoding, that's kind of all of the draft.

Eric: And then it's too much and we would need to redo the process, right? From
IETF LC.

Deb: You could put it in an appendix, right?

Paul: Other documents will live on and change and now things get really
confusing when it breaks in the future because people are implementing
different things.

Warren: SHARED-BROTLI was a individual submission and it was started in 2018,
abandoned in 2021, popped up again in 2022 and is abandoned again or expired.
It's unclear to me that.

Eric: AD sponsor then?

Warren: Yeah potentially. What is interesting is I had forgotten this, I just
had a look. It has six authors, all of whom are Google folks, so maybe Patrick
could go and find them and ask him, ask them nicely to please.

Patrick: I've already asked, I've been working with the team a lot on this
stuff. I think it's just more of a priority thing and kicking them and finding
the right working group and process to go through to push it over the goal.

Francesca: Maybe we need to continue this discussion offline.

Liz: This document will stay in IESG Evaluation; revised ID needed. Francesca,
just a heads up for you, this one does have a down ref, so by the time it gets
approved, we'll be asking whether or not to add 8878 to the downref registry.

Francesca: I just realized that now it has one more down ref because, the
BROTLI, which is individual is also informational, so, we haven't Last Call
that because it wasn't a normative reference before Roman's comment. Checking
with the IESG that if we move forward, that's OK. Otherwise, I'm not really
sure how we're gonna fix this, but, for a process point of view, objections to
having this down ref? None? Ok. Thanks.

2.1.2 Returning items

 o draft-ietf-ntp-interleaved-modes-07  - IETF stream
   NTP Interleaved Modes (Proposed Standard)
   Token: Erik Kline

Liz: We have a discuss here, do we want to discuss this now?

Erik: We can if people want. I see that has been responding to people although
I just got logged out of my email, so, he did reply to Roman. I haven't had a
chance to really catch up on all this stuff. It's definitely a revised ID you
needed though.

Roman: I likewise have not had a chance to look at the response.

Erik: We can take it on email. Do people have nothing in particular they want
to get at today?

Liz: This will stay in IESG Evaluation; 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

 NONE

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-pce-pcep-extension-native-ip-34  - IETF stream
   Path Computation Element Communication Protocol (PCEP) Extensions
   for Native IP Networks (Experimental)
   Token: John Scudder

Liz: We have a discuss, do we want to discuss this now?

John: Just for a hot second, so Roman looks like the authors have pushed
version 35 that takes in the fix that we discussed, so whenever it's convenient
for you, I think that you're probably clear to clear as it were.

Roman: Ok. Let me take a quick look. I did not see the new version.

John: It just was like an hour ago or something. Assuming that Roman goes ahead
and clears, please put it in AD follow up because I want to take a last look
just to make sure.

Zahed: I do have a comment. I think I'd like to get an answer to that one. I
didn't want to discuss but I think it would be good to have the author's view
on it before we move on.

John: I don't remember what your comment was. We could talk about it now or if
you're just saying, please don't advance it until we've had a conversation
about it. Duty noticed.

Zahed: I'm just saying, please ping me before you approve it.

John: Ok.

Deb: So I looked at this one this morning, they've made a bunch of changes and
most of the comments that were made by the SECDIR review and Mallory Knodel and
a bunch of other things have been fixed. So look at the diff it's per easy. I
think they've made a bunch of changes.

Roman: John, I was juggling a lot of documents, I actually did look at the diff
here. So my response is, thanks for addressing the kind of the the making the
edit with the addition of the reference to deal with: 'Do you have the ability
to register based on the registration kind of policy.' My concern is that they
introduce new text into the document, which I think is problematic. The text
initially said IANA something something should register lowercase, should,
these fields, but somehow that should became a normative should, that these
fields should be the one registered, which is confusing because that would
suggest that it's possible to register without those fields. So does someone
understand why we are now putting normative should about fields?

John: I sure don't. I mean I just looked at the diff this morning too and I it
looked almost like somebody did a search and replace of lower should for upper
should, which is, you know, if that's what happened, that's obviously
 a bad idea so I will look into that and get them to revert it perhaps if it
 doesn't seem to be appropriate.

Roman: Please do because it begs the usual question as we have with the NTP
document before and it was we often kind of have, so what happens if I don't
follow that should, like how do you do that registration? That just feels, that
feels like the original text was more accurate.

John: I mean I'm I'm a little less personally when I'm reviewing these things
I'm a little less upset about, not having complete clarity on should in an
experimental document because in my view the experimental document just has to
be good enough to put something in the field to try it out. However, like if if
we're, like you said dropping, 2119 keywords into IANA sections, that's just
crazy.

Liz: So this is staying in IESG Evaluation for now with a substate of AD follow
up, so John can check into all those things.

 o draft-ietf-extra-imap-messagelimit-10  - IETF stream
   IMAP MESSAGELIMIT Extension (Experimental)
   Token: Murray Kucherawy

Liz: There are no discusses so unless there's an objection now, it looks like
this one is approved.

Murray: If that's the case, then please AD follow up. Announcement to be sent,
AD follow up.

Liz: Ok. Great. This one is approved announcement to be sent; AD follow up, and
Murray, you can let us know when it's ready.

 o draft-ietf-teas-applicability-actn-slicing-09  - IETF stream
   Applicability of Abstraction and Control of Traffic Engineered
   Networks (ACTN) to Network Slicing (Informational)
   Token: Jim Guichard

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

Paul: Two small comments. One was I suggested putting IETF in the title before
network slicing just to make sure that we're talking about that one thing and
it seemed that the authors were OK with that, but they were a little nervous
because it's been juggled around for a bit previously on this term, so I just
want to make sure that IESG actually agrees to that. Is anyone objecting?

Jim: I think Paul just judging by Adrian's responses to all the different
comments, it looks like that's not gonna be an issue.

Paul: I just wanted to make sure that the IESG doesn't think it's an issue
because that's what they were afraid of because we kind of forced the name
before. And then the other thing which I think might be normal or not is that I
see that there's a bunch of email addresses in the contributor contributing
section at the bottom that has like email addresses with work, email addresses.
So it looks a bit like advertising like and we're already sort of concerned if
that like, when people sort of used that for the author name, but are we
objecting to having like, such-and-so@Cisco.com contributed to this thing at
the bottom of an RFC? Or are we reserving that for authors? I understood that
probably there were too many authors here and that's why the section was
created but I just wanted to raise it like, I just want to make sure that, you
know, this doesn't become a habit all over the IETF.

John: Not only do I not have a problem with it, I actually don't understand
what the problem would be with it.

Paul: Paul, as I pointed out that there's precedence for this anyway. I mean I
can point to some FRCs where we've done that and certainly from our area. It's
typical if there's too many authors on the front page, which is a big
percentage of the documents, I might say we move the ones that have done the
least or object the least into a contributed section and typically we would
leave the email addresses there and as I say, there are other RFCs out there
that you can look at where we've done that. I gave you one yesterday 9491 for
example. My perspective is, it's fine, it's not the same as acknowledgement,
but obviously i'm only one member of the IESG.

Paul: And that's fine with me. I just wanted to raise it to see if this, if
this happens all the time then I will just shut up, it's fine.

Eric: Basically, I agree with Jim on this one.

Jim: I think it's gonna require a revised ID. There are some changes that need
to be made made by based on the comments and Adrian seems to be dealing with
that. So, if you could put it in revised ID needed.

Liz: This one will be approved announcement to be sent; revised ID needed.

 o draft-ietf-httpbis-zstd-window-size-02  - IETF stream
   Window Sizing for Zstandard Content Encoding (Informational)
   Token: Francesca Palombini

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

Francesca: Thanks everyone for the reviews, and AD follow up.

Zahed: I think Murray and me have been discussing with the authors about one
comment that this is an informational document updating another informational
document and it is so small that you just changed couple of words basically
from recommendation to must must not. The comment I made was this got so much
deployment and so much users that people are thinking is worth updating, then
it might be the case that we consider if information is the right status. You
remember like AKA, the document they were doing it and we turned the
information to the standard tracks and this is my question here. I will not
like put a discuss on it just to stop it, but I definitely would like to see
like if it is out considering changing the category of this document from
informational to something more standard track.

Francesca: Okay, thanks. I didn't see those emails so it's so good that you
brought it up, from process point of view, that will require quite a bit of
work.

(crosstalk)

Zahed: Like is this like available everywhere people are using it because they
I mean this question bite me because the the update is so simple and it has
almost like, I don't know like if you want to post this to any implementation,
then you can do that. If it is a small set of implementations on some like a
really small set. You can't just do that. You don't need this, don't need this
document. But as we're doing it, must and must not, it's kind of reinforcing
the implementation to actually do something so that there is a standard way of
doing things. It screams to me like, the information is not the right thing to
do.

Francesca: Warren, did you want to say something?

Warren: I mean, to me it seems like if anything, this document should be pushed
as is informational, but if people are using Z standard and application C
standard enough, that should be moved to standard.

Murray: That was my point, is Z standard is seeing enough widespread use then
moving it up after this because if we move Z standard up before this, then this
has to become proposed standard as well. So like that was my thought is finish
this, but then we should consider moving Z standard up the standards try it, if
people think it has that kind of maturity, then that's where it deserves to be.
Probably should get someone else to do that because I was an author on Z
standard and I don't or an editor on Z standard and I probably shouldn't be
seen to promote my own stuff, but I think that that's the right thing to do.

Zahed: That's fine with me, but let's move on with this one but reconsider like
change the whole whole thing as a standard track. That's fine. But I mean as I
said like this, this brought me up to this question like is it like that much
deployed like you actually do these two lines of you due to the whole
boilerplate of document object to just to say one thing. I mean, what exactly
we achieved by doing this object?

(crosstalk)

Zahed: So the window side changes a must, right? That's the only thing it does,
right? It changes the recommendation to a must and and there is a must note
also. That's the update, so why are doing this update if this is not that
important? Why you do that?

Warren: For interoperability, right? We published an informational document, we
discovered that people weren't all doing things the same way and that hurt
interoperability, and so this document clarifies something in the other
document. To me this seems perfect.

Zahed: So this, this is, this is informational, actually getting deployed and
used and people has problem? Why shouldn't the standard then be a standard?

Warren: I think we have different views on what informational is. It's
something that people use to publish a document still for interoperability,
right?

Zahed: For education and interoperability, definitely. I mean you you do
certain things on a certain way and you would like to tell people about it and
you do it informational. But if people start to use that one and that becomes
like a de facto thing perhaps or that really gets deployed in the internet.

Warren: I think there's a huge number of informational documents that people
are using and are widely deployed. So I don't think I agree with you once
something starts to get deployed, it moves from informational to standards
track.

Zahed: What do we do with those kinds of things? Do we keep doing informational?

Warren: Yes.

Zahed: We didn't do that more and for for the AKA document that was actually
informational and then we actually make it a standard track because we thought
that's like getting deployed and getting useful.

Francesca: What I would do in this case is I would continue publishing this as
information on this updating and information and I would go ahead with a
different action which is the status change that takes the last call and nd I
would do that for the original, which is 8878 I believe. Let me just double
check. Then we can discuss if that status change should also update the status
of this one, but I would not block. This one it doesn't make sense to move it
to proposed standards before that one is also moved to proposed standard.

Zahed: That's fine. I think let's let's build up the consensus and the working
group see like if you actually want to move to the standard to from
informational based standard right but yeah I think that's a really good way
forward.

Liz: This one will be approved announcement to be sent; AD follow up.

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 NONE

3.2.2 Returning items

 NONE

3.3 Status changes
3.3.1 New items

 NONE

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 o conflict-review-li-arch-sat-00
   IETF conflict review for draft-li-arch-sat
     draft-li-arch-sat-07
     A Routing Architecture for Satellite Networks (ISE: Informational)
   Token: Jim Guichard

Liz: There are no discusses in the Tracker, so unless there's an objection now
it looks like this conflict review is ready to send. This is one approved. Jim,
is this ready to go? Do you want to give it any final checks?

Jim: This is ready to go.

Liz: This conflict will be sent.

3.4.2 Returning items

 NONE

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

 NONE

4.1.2 Proposed for approval

 NONE

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o Routing In Fat Trees (rift)

Liz: There's a block, do we want to discuss this now?

Jim: I'm not sure, Gunter and I have been talking about it and there is some
response from the chairs that one of them is currently traveling, but they kind
of agreed with the comments because it's an internal review, I've kind of let
it, go at the high level and we need to really drill down now before it goes
any further. So we're gonna work with the chairs to do that. I think we can
resolve the block pretty easily. Do you have any comments?

Gunter: No, I think you covered it all. I think it's gonna be easy to look it's
not gonna be difficult to  resolve the block at all. It's like putting a better
framework around it and closing it down a little bit on deliverables.

Liz:  So do you want us to put this back on the agenda for next time or do you
want to just take it and work on it and let us know when it's ready to go to
the next.

Jim: Let's put it back on the agenda because I think it's gonna be pretty quick
to go through the comments and the and the block. They're very responsive to
chairs,  know we'll get some, some closure on this next week. Let's go ahead
and do that.

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Liz: John, is there any IAB news we can use?

John: It took like a few short notes which I meant to send but didn't. Yeah, so
the only thing that I noted, was that there was some talk about the end to end
encryption workshop that I think Tim Pull kind of brought up on Slack. But sort
of the end of that discussion was to say this is, you know, will take a while
to actually discuss it properly. So let's defer it to later. Tommy did say that
there's currently no intention to have that workshop, but, maybe glad to
discuss  whether about whether the IAB can help by saying, here's the statement
we published before about why the things you want won't work, other than that
was it for me. I don't know if Roman has anything to add or Tommy.

Roman: I would just add that the IAB is working on some key appointments right
now as well.

6. Management issuess

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

Liz: John, do you have any comments to make for this early allocation?

John: It's in my public queue. It is not gonna be with the RFC editor before
the end of the month considering that's just a few days off. I think this is
pretty much a no brainer too.

Liz: Any objections to renewing this early allocation? I'm hearing no
objections and we'll send that official note to IANA.

6.2 [IANA #1372387] Designated experts for RFC 9581 (Concise Binary Object
Representation (CBOR) Tags for Time, Duration, and Period) (IANA)

Liz: Orie, make sure you got this one on your list.

Orie: Acknowledged.

6.3 [IANA #1366742] renewing early allocation for
draft-ietf-idr-wide-bgp-communities (IANA)

Liz: This is another one of John's.

John: So this one was slightly more painful because it's been getting renewed
and renewed and renewed since 2017, as you can see. I checked in with the
chairs and authors and they said, no, no really, we're getting back to work on
this and we're gonna progress it. And furthermore, there are other drafts that
depend on this spec and some of them have code in the field. So yeah, it seems
like we should, we should renew it.

Liz: Any objections to renewing this early allocation? So we'll go ahead and
send that official note to IANA.

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

Eric: Maybe just a warning you have seen that I opened a ballot for the next
formal telechat about Warren's draft to move OWEE to IEEE. It's AD sponsored,
four weeks Last Call and it's kind of a hurry to be pushed IEEE because they
need it so I pushed on the telechat on Thursday in two weeks, and the Last Call
finished on Wednesday but it's only 3-4 pages. And the Last Call until now is
perfectly fine. So feel free to hit the defer if you don't like it, and if
there's any comments on the Last Call, i'll hit the defer.

Francesca: If there's a comment, you don't need to defer, you can just remove
it.

6.4. Executive Session

An executive session was held.