Skip to main content

Narrative Minutes interim-2023-iesg-10 2023-05-04 14:00

Meeting Narrative Minutes Internet Engineering Steering Group (iesg) IETF
Date and time 2023-05-04 14:00
Title Narrative Minutes interim-2023-iesg-10 2023-05-04 14:00
State (None)
Other versions plain text
Last updated 2024-02-23

Narrative minutes for the 2023-05-04 IESG Teleconference

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

1. Administrivia
1.1 Roll call

Andrew Alston (Liquid Intelligent Technologies) /  Routing Area
Jenny Bui (AMS) / IETF Secretariat
Roman Danyliw (CERT/SEI) / Security Area
Martin Duke (Google) / Transport Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Jim Guichard (Futurewei Technologies) / Routing Area
Erik Kline (Aalyria Technologies) / Internet Area
Murray Kucherawy (Meta) / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area
John Scudder (Juniper) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
Amy Vezza (AMS) / IETF Secretariat
Éric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area
Paul Wouters (Aiven) /  Security Area

Jay Daley / IETF Executive Director
Dhruv Dhody (Huawei) / IAB Liaison
Lars Eggert (NetApp) / IETF Chair, General Area
Francesca Palombini (Ericsson) / Applications and Real-Time Area

Greg Wood

1.2 Bash the agenda

Amy: Does anyone want to add anything new to today's agenda? We added a new
management item this morning to talk briefly about the SWOT/PEST.

Andrew: There was something I sent to support to add to the agenda but I forgot
what it was now.

Amy: That's already on the agenda.

1.3 Approval of the minutes of past telechats

Amy: The last minutes have only been out for a week, so we'll come back to this
at the next formal telechat.

1.4 List of remaining action items from last telechat


     o Roman Danyliw to find designated experts for RFC 9347, ESP
       AGGFRAG_PAYLOAD registry [IANA #1265971]

Roman: In progress.

     o Murray Kucherawy to find designated experts for RFC 7462 (URNs for
       the Alert-Info Header Field of the Session Initiation Protocol
       [SIP])[IANA #1266696].
     o Murray Kucherawy to find designated experts for RFC-ietf-jmap-
       blob-18 (JMAP Blob management extension) [IANA #1267309].
     o Murray Kucherawy to find designated experts for Structured Syntax
       Suffixes (RFC 6838) IANA #1270651]

Murray: These are all in progress. I'm waiting for replies from people.


     o Robert Wilton and Warren Kumari to report back to the IESG on the
       impact of COVID-19 to the IETF in July 2023.
       - On hold

     o Éric Vyncke to follow-up with the tools team on auto-populating the
       approval announcement text in the "ballot text" section (document
       abstract, responsible AD, document shepherd).

Éric V: I just checked and this is working fine now, so you can remove this
now. The question now is whether to add the IESG Note to the announcement.
Which may be another topic, have you seen the discussion on email about what's
the IESG Note we can write into the ballot proposal? Should it be put into the
announcement as well? I think no.

John: Or alternately, should we just take that out of the template completely?
You can still type anything you want, as it's still a free form text field. But
maybe if nobody knows what it means, we should stop prompting people to put it
in there.

Éric V: I'm fully with you, John. Can we change this action item to a new one,
removing this IESG Note from the template?

Jim: I found that note confusing as well. I just did my first one and there
were a couple of comments I wanted to make on the document and thankfully John
and Andrew prevented me from doing it in the IESG Note section, which might
have been embarrassing.

Warren: I did recently use that note section to fairly good effect. I don't
know of an easy way other than the IESG Note spot to provide interesting
background information for people who are going to look at the document.

Jim: That's what I was looking for, where do I put something that's helpful for
reviewers in the IESG but isn't going to go out publicly. I thought it was the
IESG Note but John told me that's not what it's for.

John: If you don't want it published, use slack or email; that's pretty much
it. Anything in the Datatracker is public record.

Warren: In my case I wanted it to be public. It seems like it's useful
sometimes to add an annotation to a document so that everyone who looks at it
understands its purpose. The reason I used it fairly recently is because with a
status change document, nobody ever understands what they are, so I wanted to
say go look at this other document and here's what a status change is. Maybe
rename it from IESG Note?

Éric V: Public IESG Note?

Warren: IESG Helpful Annotations? Additional Note?

Éric V: I think "public" is important. I'll open an issue on this later today.
You can close this action item and open another one about renaming the IESG

     o Warren Kumari to follow up on a bis document for RFC 8126 regarding
       designated experts.

Warren: We spoke about this a little bit on the last call and I think Murray
and I are supposed to be working on this together, but I think it's actually
Barry. I'll follow up with both Barry and Murray. In progress.

     o Rob Wilton to draft a proposal to the tools team for what the
       requested information regarding mail statistics should look like.

Rob: This is in progress.

     o Lars Eggert to send email to the LLC about Letters of Invitation
       for Interim Meetings and Retreats
       - On hold until after 2023 retreat

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-sfc-ioam-nsh-11  - IETF stream
   Network Service Header (NSH) Encapsulation for In-situ OAM (IOAM)
   Data (Proposed Standard)
   Token: Andrew Alston

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

Andrew: I don't think there's anything I need to talk about on the Discusses
themselves but I do have a question for the IESG about this document. There's
one more document that's in Last Call for SFC and then we were going to close
SFC. I've been warned by the shepherd that I may never get responses to these
Discusses and that would leave this document open. What do I do in the case of
a WG that was going to close when I have a document with Discusses that the
authors may never respond to?

Roman: I've encountered this situation to do one of two things. You work with
the chairs to ask if the WG still cares about this document and wants to add
more authors, or you flush it and close the WG. In the end, the document is the
product of the WG, not the authors. If the authors aren't doing it, there needs
to be someone else in the WG to close it.

Warren: You can close the WG with live documents still if you want to. If you
think the document is moving along and the WG doesn't need to remain open, or
if it's not moving along and you don't think the WG needs to remain open, you
could just close it and hold the document.

John: The only reason you'd need the WG is if you need to return the document
to the WG, and at that point you do what the others said.

Zahed: the other reason you might need a WG is for auth-48, if you find
something that needs some sort of consensus call in the WG. For RMCAT I waited
until the auth-48 was done on the last document before I closed it.

Roman: I'm with Zahed. You're going to be AD sponsoring that document if you
close the WG.

Andrew: One of the things the chairs suggested to me was that if the other
document that's in Last Call at the moment goes through the IESG and they
haven't responded, then I always have the option of kicking the document back
to the WG and when stuff moves to RTGWG for maintenance they can fix it there
and it just goes through the process again. So that's another option. I just
wanted to hear some other thoughts on this.

Rob: How difficult are the Discusses on here? I think people wanted
clarifications but I don't remember how many changes people were asking for.

Andrew: I don't think there is anything massive in here, but the authors still
have to respond to those Discusses.

Éric V: Frank is a colleague and he's still at Cisco. I think he will react.

Andrew: Okay. I was just warned by the shepherd and the WG chairs that he might
be slow to react. Other than that, I'm working on these Discusses and I've
chased the shepherd. This will definitely need a Revised I-D.

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

2.1.2 Returning items


2.2 Individual submissions
2.2.1 New items


2.2.2 Returning items


2.3 Status changes
2.3.1 New items


2.3.2 Returning items


3. Document actions
3.1 WG submissions
3.1.1 New items


3.1.2 Returning items


3.2 Individual submissions via AD
3.2.1 New items


3.2.2 Returning items


3.3 Status changes
3.3.1 New items


3.3.2 Returning items


3.4 IRTF and Independent Submission stream documents
3.4.1 New items


3.4.2 Returning items


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


4.1.2 Proposed for approval


4.2 WG rechartering
4.2.1 Under evaluation for IETF review


4.2.2 Proposed for approval

 o Multiplexed Application Substrate over QUIC Encryption (masque)

Amy: I have no blocks for this recharter, so unless there's an objection this
recharter is approved.

Éric V: I would still suggest that my comment is addressed, though.

Martin: I'll make sure.

Amy: Is this good to go or is it waiting for anything?

Martin: No, it's not waiting for anything.

Amy: Excellent, then we'll send our recharter announcement.

5. IAB news we can use

Roman: I had a dayjob conflict so I don't have any.

Mirja: Yesterday we had a technical discussion about fragmentation. We decided
to announce it on the arch-discuss list for the first time and there was a lot
of interest and a bunch of observers joined. So let's see what will happen

Martin: Packet fragmentation or Internet fragmentation?

Mirja: That was the initial question on the mailing list. No, it's not packet

Roman: This was news to me, for example, that the IAB was doing this and it was
being shared for the first time. It looked like the community was responding
like what's this new thing, why aren't you including us, while this has beet he
usual business of the IAB for quite some time now so there was a mismatch of
expectations and not an understanding that this was something that had been
happening in the IAB for quite some time.

Mirja: Exactly. We did announce this a couple of times in IAB-Open but it
didn't make the news. Our calls are always public, we just didn't send out an
announcement before. We just did it for the technical discussion because people
said that would be interesting but they weren't aware of it. Two things came
together, one was the unawareness of the community about this and one was also
this topic which people have opinions on.

6. Management issues

6.1 [IANA #1271795] Alert URN Identifier registration request (IANA)

Amy: This is a registration request that there is no expert for, so they're
looking to the IESG to approve or not.

Sabrina: It sounds like they are still working on finding experts for this
registry and we checked in about this request since it's been pending since
February 17. This is a low volume registry so we were hoping the IESG could
approve this while we're still waiting for experts to be designated, if that's

Éric V: It's not my patch but I don't see why not.

Andrew: I don't have a problem with it but it's not my patch at all.

Roman: I don't see an issue with it either.

Amy: Okay, I'm hearing no objection to going forward and approving this request
while we wait for designated experts. Okay, we'll send an official note to IANA
stating that.

Éric V: The only thing is that I see 3GPP on the last line; should we check
with 3GPP whether there's a conflict?

Andrew: Didn't this request come from 3GPP? Look at the top of the request.

Sabrina: Yes, this was submitted by 3GPP.

Éric V: Oh, okay. That's fine then. Thank you.

6.2 Normative changes to documents in RFCEDIT state with RFC Editor (Andrew

Andrew: I've asked the RFC Editor to hold this document pending the outcome
here. Basically there's a document, RFC 7752bis, and it has certain
restrictions in the document. The guys in LSVR suddenly realized they couldn't
do what they were doing because of these restrictions. They asked for a change
to 7752bis which is in RFC Editor state at the moment. It's a normative change,
because effectively the document says you should ignore certain things. But you
can't ignore them and have LSVR still work. I can tell them to write a one page
document which would sort this out or I can ask IDR to approve this, and if I
get unanimous agreement, we can make the change while it's still in the editor
state. I'm not quite sure what to do here so I wanted to ask for some advice.

Rob: I think it depends on the size of the changes. It's really just a judgment
call whether the IETF consensus would have changed on the balance of that
change. If they think it might have done, you need to push it back to the WG.
If the change is relatively small and sensible, either just ask the WG, give
them a week to consider the changes, and as long as nobody objects then go
forward. If you think the change is sensible.

Éric V: Is it a change from informative to normative or normative to

Andrew: In this case it changes something pretty specific in the document. It's
a really short change but the document explicitly says that you need to ignore
certain SAFIs, and this would change that. Because it actually brings
processing the SAFI into it.

Jim: From the LSVR perspective, the issue that was caught was that I've been
reviewing some documents and this immediately stood out to me. I spoke to one
of the chairs and that's where the objection came from. Essentially in BGPLS
they use an attribute that there's a one line in the RFC that says this
attribute should not be used by any other address family. Which is problematic
because LSVR is a different SAFI, but it's closely related to BGPLS because
it's all about link state. When that line in the RFC was put into place, there
was no other address family that was related with BGPLS in terms of link state.
Now there is, and there's a specific line in the RFC that says we can't do what
we want to do. Hence the issue.

Andrew: I just pasted the text into the chat.

Warren: This seems very similar to what happened recently with the ESNI and
[crosstalk] where we said this is already in the RFC Editor queue, we want to
make this change, dear WG does anybody strongly object? Then I did a fairly
short IETF Last Call saying we found this issue, this is what we're going to do
to fix it. Yes, it did add three weeks of time, but it wasn't a major faffle.

Andrew: That's what I wanted to check, Warren. Is it simply a case of me asking
the WG or do I need to issue another Last Call?

Warren: I think the way I did it, we actually had an IETF Last Call but I don't
think it was needed.

Éric V: In this specific case, ESNI and the same thing in ADD is quite touchy,
very sensitive. So we wanted to play by the rules. I'm not sure whether this
thing in LSVR is very sensitive.

Jim: This particular one, if you look at the text Andrew put into the chat, the
second sentence said the attribute should only be included with link state and
LRIs. That sentence is okay because LSVR uses the same link state and LRIs as
BGPLS. It's the next sentence that's the problem because it says it must be
ignored for all other address families. LSVR uses a different sAFI than BGPLS
so the change is pretty simple, it should say something like it must be ignored
for all other non-link state address families, or something like that. It's a
pretty straightforward change.

Andrew: I'm reluctant to make that change because at the same time I'm not 100%
convinced that the IDR working group is necessarily going to support what
they're trying to do in LSVR. That is what kind of worries me.

Warren: I think send an email saying this is what we want to change, this is
why we want to change it, assuming there are no objections, please let me know
in 1  or 2 weeks. If anybody is really uptight about it they've had their
opportunity to comment. Maybe this is a covering your ass kind of strategy.
Even if you think people aren't likely to object, give them a chance to.

Andrew: If they object, do I then take the document and send it back to the WG?

Warren: If they object, I think send it back to the WG saying that we already
had WGLC, IETF LC, the only bit we're discussing is this, please do not reopen
discussions on other things.

Andrew: Okay, I can do that. I'll ask for objections in IDR then and Jim, you
and I can talk about it after this call. I don't think I'll issue another Last
Call; if I get unanimous from IDR I think it's okay.

Jim: You should probably copy LSVR as well.

Warren: I think you can also make it clear which way you think it goes, and
that you're doing this for transparency to make sure everybody gets a chance to
see it. The way you frame the question is important. And also reiterate that
this has already gone through the process and was already with the RFC Editor
so now is not the time to re-open any other discussions.

Andrew: That makes sense, thank you for the advice. I was hesitant to make a
change that while small, could potentially have impact.

Zahed: I think this approach is good, I've done this a few times with QUIC and
I delegate the consensus call to the chairs too.

Andrew: Thanks very much, I've got what I need.

6.3 SWOT/PEST Analysis (Éric Vyncke)

Éric V: We need to combine the results. We have nine answers including myself
and Rob, but we're still missing six or seven.

Andrew: I thought it said 10 am tomorrow morning UTC?

Éric V: 8 am UTC tomorrow we'll meet to compile results so that's the latest.
Put aside half an hour and think about your responses.

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

Warren: I finally put in the conflict review for the draft I did; I can't
remember if there's anything I need to do other than put in the conflict review
text in order to make the next bits happen.

Amy: I think you have to open a ballot for it and then it will go on a telechat.

Warren: I'm going to click the button to put it in IESG Evaluation and see what

Amy: Yes, I see that it has opened a ballot, so it will go on the next
telechat. Thanks everyone, a couple of reminders; the BOF coordination call
doodle poll is out so please fill it out. Please also send Cindy your
unexpected facts about yourself for a retreat activity.