Narrative Minutes interim-2024-iesg-18: Thu 14:00
narrative-minutes-interim-2024-iesg-18-202409051400-00

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

These are not an official record of the meeting.
Narrative Scribe: Liz Flynn, 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
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
Zaheduzzaman (Zahed) Sarker (Nokia) / Web and Internet Transport Area
John Scudder (Juniper) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
Gunter Van de Velde (Nokia) / Routing Area
Eric Vyncke (Cisco) / Internet Area
Paul Wouters (Aiven) /  Security Area

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
Roman Danyliw (CERT/SEI) / IETF Chair, General Area
Francesca Palombini (Ericsson) / Web and Internet Transport Area
Tommy Pauly (Apple) / IAB Chair
David Schinazi (Google) / IAB Liaison
Orie Steele (Transmute) / Applications and Real-Time Area

OBSERVERS
---------------------------------
Sarah Jennings
Pete Resnick
Greg Wood

1.2 Bash the agenda

Liz: Does anyone have anything to add to today's agenda?

Murray: One of my work items is an IESG statement on BCP 14; I'd like a couple
of minutes to discuss that and see if we can proceed to publish it.

1.3 Approval of the minutes of past telechats

Liz: Does anyone have an objection to the minutes from the August 22
teleconference being approved? Hearing none, so those are approved and we'll
get those posted. Does anyone have an objection to the narrative minutes from
August 22 being approved? Hearing none, so those are also approved and we'll
get those posted.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

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

Liz: Francesca isn't here, so we'll keep this one marked in progress for her.

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

Paul: I thought I sent names for this? Oh no, it was the other one. This one is
in progress.

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

Liz: Orie isn't here, so we'll keep this in progress for him.

     o Gunter Van de Velde to find designated experts for RFC 9650
       (IS-IS Neighbor Link-Attribute Bit Values) [IANA #1373058]

Liz: We'll mark this one as provisionally approved, since we have a management
item later in the call to approve some names here.

     o Paul Wouters to find designated experts for RFC 9588 (Kerberos
       SPAKE Groups) [IANA #1373059]

Liz: We also have some names to approve for this one today, so this one is
provisionally done.

   * OPEN ACTION ITEMS

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

Paul: Still pending.

     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: Orie did a really good start and sent us a document to look at and I
think the rest of us slacked off. Also known as in progress.

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

Murray: This is the one I just added to the agenda, so we'll talk about that
today.

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

Murray: In progress.

     o Roman Danyliw to reach out Systers about the value of writing
       recommendation letters to employers.

Liz: Roman's not with us today so we'll leave this one in progress for him.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-anima-brski-ae-12  - IETF stream
   BRSKI-AE: Alternative Enrollment Protocols in BRSKI (Proposed
   Standard)
   Token: Mahesh Jethanandani

Liz: There are no Discusses in the tracker, so unless there's an objection now,
this one is approved. Mahesh, is this ready to go or do you want more time with
it?

Mahesh: Just put it in AD Followup please.

Liz: Okay, this will go into Approved, Announcement to be Sent, AD Followup,
and you can let us know when it's ready.

 o draft-ietf-mpls-inband-pm-encapsulation-15  - IETF stream
   Encapsulation For MPLS Performance Measurement with
   Alternate-Marking Method (Proposed Standard)
   Token: Jim Guichard

Liz: We do have a few Discusses here. Do we want to discuss these now?

Jim: I don't. This one's giving me heartburn, to be honest. I noticed there are
a bunch of responses in email I haven't gotten to yet. Unless John or Zahed
have anything, we can just put this in AD Followup.

Zahed: I think I'm having a good discussion in email; they proposed some text
to address my comment which is saying let's do these things in a controlled
domain. I honestly don't know what MPLS performance measurement means in a
controlled domain. Unless there's a clear indication that MPLS performance
measurement can be done in a controlled domain, some sort of boundary I don't
know. If there's a reference to that or someone saying it's okay, then I think
my Discuss is done. Otherwise we need to discuss it more to see what it means.

Jim: I think the assumption is that MPLS is…this goes back to Warren's work,
it's a fail-close protocol with an ethertype and everything else. Whether
that's good enough, we can discuss. I did see that there's a bunch of email
flying around which i haven't gotten to yet, so hopefully we can resolve this
through email.

Warren: MPLS is one of the very very few protocols we have where limited domain
is a defined, understandable term. You actually have to try really hard to leak
MPLS out to the Internet or to another provider.

Zahed: Warren, I completely understand that. That's my interpretation as well.
From that point of view, this proposed text is good, but I haven't found a
reference to that. I know the practice, but I was making sure we understand
what we're doing.

Warren: I was more responding to Jim's comment, not yours. I agree that having
some text is good.

Jim: The other thing that came up, which I picked up in my AD review and got a
response from the chairs and I kind of let it go seeing if anyone else in the
IESG picked it up. Eric did, which was this text around wanting to standardize
the document but they're going to move it to Historic later once some other
work they're doing gets standardized. I thought that was odd. I did question
it, but their response was that it was well discussed in the WG and there was
consensus that was what they wanted, so I let it through. Eric, I don't know if
you have anything you wanted to mention on that or whether we can let that go.

Eric V: I abstained, so I didn't Discuss it. There's technically no Discuss
point there. But the whole process, it means the WG, the IETF community in Last
Call, and all of us have reviewed a document which will become useless in one
month, one year. It's a waste of our time, that's how I feel.

Warren: Yes, this made me twitch as well when I read it. Then I looked more and
there are a bunch of implementations, and it's in use. It's unclear to me how
long until the next document gets published, but even when it does, this is
still going to be deployed for quite a while. I think it's better to have
things, even questionable things, documented than not. But it's very weird, I
strongly considered abstaining along with you.

Jim: I kind of let it go for the same reasons, Warren. As I said the document
gives me heartburn and that was one of the things contributing to it. I just
hadn't seen that before and it seemed odd that you'd put a document through
that you know is going to be put in Historic. But knowing what's going on with
the other work, it could be a long time before that happens. I don't see it
happening within the next twelve months.

Warren: Even a historic document still exists, so it's written up.

Eric V: And we have two technical solutions for one problem in the IETF, which
is typically something we don't like. Think about SPRING and a few other
things. Whatever; I abstained and I cannot Discuss it. I don't like this
paragraph at all.

Jim: I didn't want to push back on that too much because if you look at the MNA
work, they're working on in-stack and post-stack stuff. Technically you could
say that's two separate solutions, so i don't want to push back on it. One
particular chair has been trying to kill one aspect of that and I've been
pushing back saying there's clearly no consensus in the marketplace that one is
the solution so you should probably work on them.

Eric V: I say let it be.

Jim: I'll follow the email threads until those Discusses are taken care of. I
guess this goes into AD Followup.

Liz: Great; this one will stay in IESG Evaluation::AD Followup.

 o draft-ietf-lamps-rfc8708bis-02  - IETF stream
   Use of the HSS/LMS Hash-Based Signature Algorithm in the
   Cryptographic Message Syntax (CMS) (Proposed Standard)
   Token: Deb Cooley

Liz: We have a Discuss here; do we want to discuss this today?

Paul: No, I don't think so. I'm sure Russ will answer promptly and then we can
clear it one way or the other.

Deb: I agree.

Liz: Okay then, this will stay in IESG Evaluation with a substate of AD Follow
Up.

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-sidrops-rrdp-desynchronization-02  - IETF stream
   Detecting RRDP Session Desynchronization (Informational)
   Token: Warren Kumari

Liz: There are no Discusses in the tracker, so unless there's an objection now,
this is approved.

Warren: This is a document where a number of fooks, maybe just 2. People have
said it might be better if it were a Proposed Standard. It was Last Called as
Informational. I kind of think PS might have been a better option, considering
it more. Would the IESG like me to redo IETF LC as PS and we will have another
short IESG eval? One of the people pushing for that was Roman, who's not on the
call.

Eric V: I wouldn't mind too much but one section is about the numbers of missed
data. Could you provide some guidance on the numbers of missed whatever? If we
go to PS, I think this part should be more quantitative. Let me think about it.

Warren: I should have more discussion with the authors then, because I'm not
sure we'll be able to get consensus on what that number should be. I will check
with them if they think it should just go through as is now or if they want to
have a discussion on that. I'll also check with Roman how strongly he feels
that it should be PS. I guess that's AD Followup.

Eric V: To be clear, if it's kept like this I wouldn't oppose it, just a strong
suggestion.

Warren: Does anybody else have any strong views they think would need to be
addressed if we did this as PS? And Roman could have put a  Discuss if he felt
very strongly it should be PS, but I think it was more on the fence. Okay, I
don't hear any more, so I'll check with Roman and it will either go through as
Informational or you'll see it again.

Liz: This one will move to Approved, since there aren't any Discusses, and
we'll put it in AD Followup; Warren, if you want to, you can un-approve it and
put it back through a Last Call as PS.

Warren: I'm not quite sure how to do that but I guess you can help me figure it
out?

Liz: Yes, we'll help you.

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 o draft-wkumari-rfc8110-to-ieee-02  - IETF stream
   Transferring Opportunistic Wireless Encryption to the IEEE 802.11
   Working Group (Informational)
   Token: Eric Vyncke

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

Eric V: I think you can go ahead and send the announcement. Just to be clear,
if IEEE is going faster than us, in auth48 we can put a reference to the IEEE
802.11/24. It's a chicken and egg; they are waiting for us. And thank you to
Warren for writing this. I think it's the shortest RFC I've ever approved.

Warren: I am a little sad, because this was the work I've been most proud of
that I've ever done.

Eric V: I can consider writing a gen draft for the process we should follow in
similar cases. I'm not convinced we should, because it won't happen often and
every SDO we'd transfer to is different. I don't think it's necessary but I can
do it.

Warren: Whatever you think. We can chat after.

Sandy: You mentioned a timing issue. This should move fast, since it's only 4
pages, but is there a reason we should expedite this?

Eric V: As I mentioned, it's a chicken and egg issue. I think based on the
liaison statement, IEEE is waiting for us to approve this or put on an RFC
number before publishing their thing. On the other hand, if we expedite it we
can't put in a pointer to the IEEE one. Let me go back to the IEEE people. I
don't see that expedited processing is required here.

Sandy: Okay. Maybe there can be some coordination so both can be updated to
point to the right thing.

Eric V: Exactly. I will ask them. The action item is on my side.

Liz: So this one is Approved, Announcement to be Sent, and we will go ahead and
get those announcements out.

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

 o Secure Shell Maintenance (sshm)

Liz: There are no blocking comments here, so unless there's an objection I
think this is ready for external review.

Deb: We're going to make an update to the charter and the milestones, because
there were some objections to our milestones. And also to answer Erik K's
question. The answer there is yes, of course, SSH has made changes in the past
due to problems, it doesn't have to be formal methods verification tools that
do it. We are going to make a modification; if I do that, can it then go to
external review, or does it have to come back here first?

Liz: No, it doesn't have to come back here first. You can just make your change
and let us know and we can send out the external review announcement after
those changes are made.

Deb: They're small changes, typos and the like. And also to add three or four
milestones; that's the scope of the changes.

Liz: If someone has an objection they can object, but if we had to bring
everything back every time a typo was fixed we'd never get anything done.

Murray: If you want to bring it around for another round that makes it
bulletproof against appeals, but i don't think you have anything major planned
here. It's your choice.

Deb: And it comes back here after external review anyway, right?

Murray: That's right.

Paul: You're not doing anything algorithm specific in the text, right? That's
the only appealable thing that could happen.

Deb: No. I am adding the chacha-poly draft to the milestones to adopt it, but I
don't think that's controversial.

Paul: No, it's not.

Deb: Okay. I'll run it by Paul before I push it forward but I think that's low
risk.

Liz: Okay, so this is approved for external review but we will wait for your
go-ahead, Deb, and you can let us know when it's ready.

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: Is this recharter ready for external review?

Jim: I believe so. I've gone through all the comments and Gunter did a lot of
really good changes. That's all updated and I think every other comment has
been addressed. I think it's ready.

Liz: I'm not hearing any objection, so I think this is ready to go for external
review. Is this ready to go as-is or do you want to do any tweaks?

Jim: No, it's ready to go.

Liz: Okay, then this one is ready to go for external review and we'll send the
announcements.

 o Messaging Layer Security (mls)

Liz: There are no blocking comments, so unless there's an objection now this is
also ready for external review.

Eric V: I don't want to block on it, but typically when you get work items in
the charter you also state the intended status. Will all those extensions be
informational, PS?

Paul: I think that will depend on the extension, so I'm not sure. I can put
some language in that says experimental and standard extensions. I think some
will start as experimental or informational and then become standards later on.

Eric V: It's maybe worth saying in the charter.

Paul: I'll see about adding a sentence for that and I'll run it by you.

Eric V: Thank you.

Liz: Paul, do you want us to wait for your instructions?

Paul: Yes please.

Liz: Okay, so this is ready to go but we will wait for Paul.

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

John: The things I noted down were they talked about the AI control workshop,
which is coming together well. Also the NEMOPS workshop, and I think Warren and
Mahesh know more about it than I do but it seems like there's progress in doing
outreach at NANOG and RIPE for that. They talked about the GDC open letter that
Paul pasted in the everyone channel, and in the end Alissa was going to reach
out to the people who sent that letter and talk more in a kind of informal way.
But they didn't think it would be appropriate or necessary to send a formal
reply.

Warren: Some of that is because the response wasn't actually to an IAB letter,
it was to an open letter that had been signed by some people who happened to be
on the IAB.

John: Right. And they talked a bit about the TTPoE, the Tesla internet
transport thing. There wasn't any very solid outcome of that.

6. Management issues

6.1 IETF 125 (Roman Danyliw)

Liz: This is to record the decision from last week's informal telechat about
IETF 125. I don't know if everyone has had a chance to check out the paragraph
Roman sent around. Since we don't have anyone external on the call right now,
I'll read it:

   "The management issue was discussed. Pursuant to Step 4b of the
   IETF Venue Identification and Selection Process (https://
   www.ietf.org/meeting/planning/), the IESG was asked by the IETF
   LLC to decide if Shenzhen would meet the core objective in RFC
   8718 (BCP 226) of "Why We Meet".  After consultation with the
   community via the July 2024 survey, the IESG decided in the
   affirmative “meeting in Shenzhen would satisfy that core
   objective."

Eric V: You know better English than me; is it "would satisfy" or "satisfies" ?
Would is conditional, right?

Murray: I think given the form of the question, would is fine. Either one is
correct though.

Eric V: Okay, let's keep the would then.

Liz: Okay, we'll go ahead and put this in the draft minutes and as you know
we'll have a couple of weeks to fine tune it even more if we want to.

Eric V: And would this go in the minutes from today?

Liz: This would be in the official non-narrative minutes; so we'll put up a
draft of those today, and then in two weeks those will be approved and posted
publicly.

Eric V: So nobody knows about this yet, basically, outside us.

Liz: Correct.

Murray: There was one other comment here I'll leave for Roman, about whether to
say Shenzhen or not.

Liz: I'll just put it in the minutes the way it is here and if Roman wants to
change it we can.

6.2 [IANA #1373058] Designated experts for RFC 9650 (IANA)

Liz: Gunter has identified Chris Hopps, Hannes Gredler and Les Ginsberg as
designated experts for this registry. Is there any objection to approving them?
I'm not hearing any objection, so they are approved and we'll send an official
note to IANA.

6.3 [IANA #1373060] Designated Experts for RFC 9605 (Secure Frame (SFrame)
(IANA)

Liz: This one came in without an AD assignment because SFRAME is a concluded
WG. Murray, it was one of yours; do you mind taking this on?

Murray: No, I got it. The recommendation in the shepherd writeup was to use the
document authors so I'll email them and I think at the next formal I'll have
their names or a subset of their names.

6.4 IANA #1373059] Designated experts for RFC 9588 (SPAKE) (Paul Wouters)

Liz: Paul has identified Simo Sorce and Greg Hudson as designated experts for
this registry. Is there any objection to approving them? I'm not hearing any
objection, so they are approved and we'll send an official note to IANA.

6.5 Possible IESG Statement on BCP 14 (Murray Kucherawy)

Liz: Murray, you wanted a few minutes to talk about this statement?

Murray: Yes please. Eric and I have this draft about the use of BCP 14
keywords. Thanks everybody for having a look.

[Live editing session of document was not transcribed.]

Murray: So how do people feel, is this ready to publish?

John: I'd prefer not to ship this today after a bunch of live editing. Any time
next week would be okay with me. We could say at the informal or whatever other
day you want to choose.

Eric V: Or even the next formal. There's no urgency.

Murray: Okay. I'll notify the list since we have some people absent and we'll
aim for the informal.

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

Warren: I have something short. Can I screen share? Talking about making things
historic, here's a document (RFC 5933). This was made historic, but the only
way you notice that is this tiny sentence over here. I think it should be more
clear that a document is historic or obsolete. Should I open something with the
tools team suggesting if there's a status change, there's a big red box or
banner or the background changes or something? Anything more obvious. I can
never find status change things.

Paul: I think it would be good.

Eric V: I'm pretty sure this issue is already open in the Datatracker; we've
talked about it before.

Warren: I couldn't easily find one but I'll go and have a look. But nobody has
a big sad if I ask for that?

Gunter: No. One question to the ADs who have been here longer; can part of a
document be made historic? If a document for example describes options A, B,
and C, and option C is now historic, what do we do then?

Warren: I believe a status change makes a document historic, not a portion.
That's done with an updates. The whole process of making things historic or
changing status seems like it has lots of weird hoops.

Eric V: So basically Gunter, you need to do a bis.

Jim: I've struggled with it as well. One is 7506, for example, and I know I
made that historic but if I do a search for 7506 and bring it up in the
Datatracker, there's nothing there that says it's historic. You don't see that
from the front page of the RFC, so anyone who hasn't been involved comes across
this and doesn't realize it's historic.

Warren: Someone suggested before that when we make an RFC historic, we publish
it as a new RFC with a new number and a banner on the top saying this makes
document blahblah historic. That's weird but it's sort of what we did with the
8110bis thing.

Sandy: As a heads up, Alexis has been working on revamping the RFC Editor
website and I know that is one of her big things; trying to highlight what's
currently active and what's obsolete or historic or whatever. I will be sure to
pass this along to her but I think it's already on her list.

Warren: Great. It does feel like the whole process may need to be discussed as
well. Some of the reason I haven't moved more things to historic is because
it's confusing. Does anybody else want to work on the larger problem of how to
make the process of status changes less confusing overall? Maybe this is just
internal documentation, but the process isn't really written up in an RFC.

John: I agree that the whole process is gross. The other way to do it is to
progress an RFC to do the work, which has the advantage that the only thing we
really know how to do well is progress documents through to RFC. The bad aspect
is the evergreen critique of why are we cluttering up our RFC series to make
status changes. I kind of don't care about that.

Warren: Okay, I'll think about this some more.

Liz: Thanks for that, Warren. Any other business? A couple of reminders; one
from me, I sent around a link to a doodle for a BOF coordination call so if you
haven't yet filled that out, please do. And one reminder from Francesca; if you
haven't yet weighed in on her alldispatch mail thread, please share your
thoughts there. Bye everyone!