Skip to main content

Narrative Minutes interim-2023-iesg-26 2023-12-14 15:00
narrative-minutes-interim-2023-iesg-26-202312141500-00

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

narrative-minutes-interim-2023-iesg-26-202312141500-00
INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2023-12-14 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Andrew Alston (Liquid Intelligent Technologies) /  Routing Area
Jenny Bui (AMS) / IETF Secretariat
Jay Daley / IETF Executive Director
Martin Duke (Google) / Transport Area
Lars Eggert (NetApp) / IETF Chair, General 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
Francesca Palombini (Ericsson) / Applications and Real-Time Area
John Scudder (Juniper) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
Éric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area
Paul Wouters (Aiven) /  Security Area

REGRETS
---------------------------------
Roman Danyliw (CERT/SEI) / Security Area
Dhruv Dhody (Huawei) / IAB Liaison
Zaheduzzaman (Zahed) Sarker (Nokia) / Transport Area

OBSERVERS
---------------------------------
Greg Wood

1.2 Bash the agenda

Liz: Does anyone want to add anything new to today's agenda? Any other changes?

1.3 Approval of the minutes of past telechats

Liz: Does anyone have any objections to the minutes of the November 30
teleconference being approved? Hearing no objections, so we will get those
approved and posted in the public archive. Does anyone have objections to the
narrative minutes of the November 30 teleconference being approved? I'm hearing
no objections there either, so we'll get those approved and posted as well.
Then we have the delayed narrative minutes from the November 19 teleconference
that you had a couple of weeks to review now, any objections to those being
approved? Hearing no objections, so we'll get those approved and posted as well.

1.4 List of remaining action items from last telechat

  * DESIGNATED EXPERTS NEEDED

     o Roman Danyliw to find designated experts for RFC 9447, ACME
       Authority Token Challenge Types" [IANA #1281679].

 Liz: Roman is not with us today, so we'll just leave that in progress for him.

     o Robert Wilton to find designated experts for RFC 9487 (Export of
       Segment Routing over IPv6 Information in IP Flow Information Export
       (IPFIX))[IANA #1287238].

Liz: The next two are for Robert. Any updates on these, Rob?

Rob: Still in progress.

Liz: Ok great. Thank you.

     o Robert Wilton to find designated experts for RFC 9456 (Updates to
       the TLS Transport Model for SNMP)[IANA #1287239].

(In progress)

     o Francesca Palombini to find designated experts for CoRE Target
       Attributes Registry (draft-ietf-core-target-attr)[IANA #1287397].

Liz: We'll mark this as provisionally done since we have a management item at
the end of the call to approve some experts that Francesca has found.

     o Roman Danyliw to find designated experts for RFC 9493 (Subject
       Identifiers for Security Event Tokens)

Liz: We'll keep this, for Roman, in progress as well.

    * OPEN ACTION ITEMS

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

Warren: In progress? Murray and I cornered Barry in Prague, he promised to have
something done by the first week of December. He hasn't yet. I think our plan
is now we're just going to write the update and Barry will be mad at us. This
is not a good situation.

Murray: That's right.

Liz: Ok, thanks Warren.

     o Andrew Alston to email the RSWG regarding document authorship/
       editorship with regards to the number of authors listed.

Andrew: Still in progress, I'm checking with Pete Resnick about his thoughts on
this before I send to the whole wider RSWG. In progress.

Liz: Ok, thanks Andrew.

     o Lars Eggert 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.

Lars: In progress.

Liz: Ok. Thanks Lars.

     o Francesca Palombini to draft an update to the wiki page "Getting
       a Document on the Agenda."

Liz: I saw an email about this, but I didn't get a chance to look at it. Is
this one done or are we still working on it?

Francesca: I worked on it this week. I made a PR to the wiki, but I'm not
really sure what's the process to update the wiki. Just go in and change it?
But in this case, it was good to make a PR so people can check the diff easily
with Github. I sent the PR to the IESG so everyone can go in and see if it
makes sense. I hope I reflected what we discussed in the telechat. A reminder
for everyone, this a discussion about can a document get on the agenda before
the last call has ended. We went back and forth about what's right and special
case and what's very special case. So I hope I have summarized correctly what
is the best current practices, and special cases. Hopefully it's good enough.
Let's say for the next telechat we can merge the PR if no one has big
objections to it.

Eric: To be honest, I didn't have enough time to review it.

Francesca: No, no. Of course. I wasn't asking people to review and have
opinions already. Just a heads up that I sent an email about it. I guess the
drafted update is done and maybe we can add a new action item about review and
merge the update.

Liz: Ok great. We can get rid of this current one just to draft it and give you
a new action to review and merge the changes to the wiki page.

Francesca: Yes. Thank you.

Liz: Ok, perfect. Thanks Francesca.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-ccamp-layer1-types-16  - IETF stream
   A YANG Data Model for Layer 1 Types (Proposed Standard)
   Token: Roman Danyliw

Liz: We do have a couple of discusses here, although Roman is not here. John or
Eric as the discuss holders, do you want to discuss this now or do we just wait
for Roman?

John: Even if Roman is the AD this is my working group. He's just doing me a
solid to carry the document forward. So I can discuss my own working group's
document. At least for my discuss, it's just going to hang around until the
authors reply. I'll probably poke the chairs offline to try to get some action
out of the authors.

Eric: John, as you can guess my own discuss, I want to get some discussion on
this and review the chairs. We cannot claim to do a layer one thing when we
only cover one part of the layer one.

John: I thought someone has already replied. Maybe Rob replied to you on that,
was that right?

Eric: Yeah, but he replied on the Slack, right. As far as I remember, I don't
agree. Sorry Rob.

Warren: I didn't actually see Rob's reply, but I agree with Eric here. When I
read the type of the document I was like "Oh this is going to cover ethernet
and everything" and I think that people when they scroll down are going to be
very confused to see the title so am I allowed to change my no objections to to
discuss? At this point?

John: None of us make the rules.

Murray: Yes, as far as I can tell. As long as the ballot hasn't been closed.

Paul: If the button works.

Warren: I guess I'll just ask Eric to carry on.

John: You can change your no discussion to supporting Eric's discuss. It would
be slightly less weird.

Warren: Ok, I'll do that.

Rob: Just to comment on it, so for Ethernet specific types, I would expect
those to be defined by IEEE manually. So that's one thing, I think by and
large, I think the range is to cover any layer 1 type which they need to add
things in. I'm not quite sure what is missing that people want and need. It'd
be good to understand what isn't there that people think should go in there
because it does cost a bit of time. The other aspect is they could rename the
YANG Module, which I think we need to consciously see OTN in the name, rather
than layer one, I think would be fine. I don't know if any of this stuff goes
beyond OTN though, so maybe that it's actually covering stuff that's more
broader than that. I wouldn't want to change the name of the YANG Model in the
future. I would be careful getting too hung up about this or start with this
major at the top of the document, but I'm not sure if it really matters in my
opinion.

Eric: Yeah, we disagree on this one because it's dedicated to OTN then let's
make it OTN, right? That's perfect.

John: Hey Rob, do you mind sticking your comments into email so that the chairs
and authors can also see them. I think that would be helpful to move the
discussion forward.

Warren: I only care a little about the YANG module name, I was talking about
the document name as well. Which is hopefully a lot less controversial for them
to change.

John: I mean, presumably, we're not actually well, maybe I shouldn't presume
this has been done in the past. Quite recently. I was going to say, presumably,
we're not actually going to block this document on getting bike shedding of the
title to be perfect, but let's see how this conversation goes.

Warren: I do think if a document says a YANG Module for defining cookies, and
all it talks about is the shape of a bird,, that's a reasonable position to not
move.

John: If we have a situation like that I would agree, but we don't. Let's not
get ahead of ourselves. Step 1 is to actually have the chairs and authors to
reply.

Eric: Agreed.

Liz: Since we have discusses, this will stay in IESG evaluation. I'm guessing
this might require a revised ID?

Eric: Oh yeah. I think so. I hope so.

 o draft-ietf-openpgp-crypto-refresh-12  - IETF stream
   OpenPGP (Proposed Standard)
   Token: Roman Danyliw

Liz: We don't have any discusses, so unless there's an objection, now, it looks
like this one is ready to be approved.

Paul: I was looking forward to Lar's ballot, but unfortunately he did not
ballot on this one.

Lars: No, because I just started today with my ballots and this one had enough
so I skipped it. I was specifically looking at the ones that needed ballots to
progress. Why were you looking here? Because i'm an openpgp non expert.

Paul: Because I found an interesting ballot from a previous version of this
document from you, which was an abstained. You said I'm abstaining from this
document. I believe it's impossible to develop an interoperable open
implementation based on this document because it merely defines a packet format
without explanation of the semantics.

So I was very curious if you remember that.

Lars: When was that? Please don't say like 2 weeks ago.

Paul: This was in 2007.

Andrew: The fact that you found it Paul is impressive.

Lars: You waited 15 years for this document or were you not an author back then?

Paul: No, I was not involved. Semi seriously, to give a little more, which is
why we should wait for Roman before we approve. For this document, there was a
lot of controversial, the working group closed once, because they couldn't get
consensus then got reopened and then they added Stephen Farrel as a senior
manager on the working group chair and added me as an editor to avoid any
discussions about one of  the Implementers adding text to the document without
concerns of the working group. So basically, two heavy hands were put in and
then there's still resulted in so much unpleasantness. Someone apparently just
started Libre PGP which I was just informed about yesterday. So you can go to
librepgp.org to final all the, not so, in my opinion, truthful comments about
the process we went through. There's definitely some unhappiness, I don't want
to say in the group because it does have strong consensus, but in very few
individuals. So one thing we did was we skipped the original draft number, and
bumped the key version and so we skipped that version. Avoided having the old
draft and the newer draft be different from using the same number so we did
give them all the space to keep using that number, but it did sort of squat on
a number.

Lars: This sounds like it should go to point raise or AD follow up or something
for when we have Roman.

Paul: Yeah, that would be good.

Lars: The silver lining here is the Libre PGP was submitted as an Internet
Draft so we have change control unless they used the boiler point which I
haven't checked.

Mirja: I'm not sure if I understand your concern. If you say there's strong
consensus , then we just need to move ahead. I mean, like, they could appeal or
whatever, and then we have to hand it, but I don't see any other option.

Paul: I guess that's true as well. So on the points raised,  there were a few
points raised in the comments. I hopefully addressed them all. I don't think
there is any causes to exchange in that sense. There is no change needed as far
as I know.

Lars: I mean, if there's any support participants that are unhappy with what
came out of the working group, right? But the point of appeal is sort of passed
in the sense that, they could have appealed to the working group with
consensus.But I don't see any grounds which they would appeal the IESG
consensus or decision.

Paul: That's true. They did raise their objection during the IESG last call
which the chairs responded to.

Mirja: They could make a point that there's no IETF consensus, right?

Paul: They could, as far as I know at least one of the original authors also
agreed with the consensus, and the person objecting was not an author on 4080.
So if anything we have one, maybe two authors that agreed to this update. So in
that sense, there are strong consensus, even though unfortunately it's one
important implementation.

Lars: I added this draft to next week's informal.

Francesca: From a process point of view since no one has to discuss. I believe
it will go into approve, approved announcement to be sent unless someone
discuss it. And then you can have AD follow up, of course, for the
responsibility AD to follow up on whatever came in recently.

Lars: I'm using my nonexistent shepherd privileges to tell the secretary to put
it in AD follow up, which is something Roman could do even if it's otherwise
approved, you can always put it in AD and then take it out.

Francesca: Yeah.

Liz: That's what we'll do anyway since Roman's not here. So it moves into
approved announcement to be sent, but with the state of AD follow up.

Eric: Or somebody hit defer, right? Which is actually what you are doing
somehow, right? AD follow up is fine for me.

Liz: Ok great then we'll put this in AD follow-up.

 o draft-ietf-avtcore-rtp-evc-06  - IETF stream
   RTP Payload Format for Essential Video Coding (EVC) (Proposed
   Standard)
   Token: Murray Kucherawy

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

Murray: Not necessary,  I think that, we'll wait to hear from the authors and
they'll get around to it. So we're good here.

Liz: Ok, great. Will this require a revised ID?

Murray: Please put it in AD follow up. I'll flip it to that, if that's what
they decide.

Liz: Ok, great. This will stay in IESG evaluation with the substrate with AD
follow up.

 o draft-ietf-dnsop-dns-error-reporting-07  - IETF stream
   DNS Error Reporting (Proposed Standard)
   Token: Warren Kumari

Liz: We have a discuss on this one too, do we need to discuss that today?

Warren: I don't think so. I think Paul's write up is fairly clear, I don't
think the authors have responded yet. So I think we just need to give it some
time for the authors to respond.

Liz: Ok, great.

Warren: Unless Paul do you have any comments?

Paul: No, no comment.

Liz: Ok, this will stay in IESG evaluation. Will it require a revised ID?

Warren: I believe so, yeah.

Liz: We'll give this a revised I-D needed.

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

 NONE

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

 NONE

3.4.2 Returning items

 NONE

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

 NONE

4.1.2 Proposed for approval

 o Network Management Operations (nmop)

Liz: This has enough positions to pass, unless there's an objection. It looks
like we have a new working group.

Rob: I'd tell him not to vote, yes, yet. There’s some comments made from Adrian
Farrel that I need to merge into this, and maybe some of the text change in a
way that I need to bring it back. So I want to not approve it just yet and how
to do that? Put a block position on myself, is that the easiest way?

Liz: Yeah, I think so. That would be the simplest way.

Rob: Ok, I will do that.

Liz: Ok, we will have a block from you for this and it will keep it in IESG
evaluation.

Rob: Ok, thank you.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 NONE

4.2.2 Proposed for approval

 o Open Specification for Pretty Good Privacy (openpgp)

Liz: Does any have an objection to the rechartering of this working group? I'm
hearing no objections, so I think this is ready to go but since Roman is not
here, we can go ahead and leave in this AD follow up for him just to do some
final checks.

Lars: Yeah, I don't have an objection, but on all these three chartering, I
wanna put the thought in your head that this might be a good chance to think
about chair changes. Given the discussion we had recently. I'm not saying you
need to do it, but since we're chartering anyway. Right now this might be a
natural point in which to do it. Thanks.

 o Transport and Services Working Group (tsvwg)

Liz: Does anyone have an objection to this rechartering? I'm hearing no
objections so I think this is ready to go. Martin, do you want to send this as
is or do you want to do anything?

Martin: Probably make one small edit, based on the other comments. Based on the
one comment down there, I think it was Lars'.

Liz: Ok, great.  So then we won't send this immediately, but we will wait for
instructions for me Martin and you can let us know when it's ready to go.

 o TCP Maintenance and Minor Extensions (tcpm)

Liz: Does anyone have an objection to rechartering this working group? I'm
hearing no objections so it looks like this one is approved as well. Martin,
same question is it ready now? Or do you want to do some final checks?

Martin: I'll do another review.

Eric: Ok, thank you Martin. I think something to TCP in the Internet
predominant transport protocol is probably not true anymore.

Martin: It depends on how you count it, right? I mean the number of N hosts
that use TCP speedway, way higher if count packets, then like quick. YouTube is
just so many packets. I'll just do a quick pass.

Liz: Great. Thanks Martin.

 o Path Computation Element (pce)

Liz: Does anyone have any objections for pce? Ok, I'm hearing no objections.
John is this ready to go as is or do you want a chance to look it over again?

John: I want to follow it up. There is probably one last set of changes that I
want to do. I just want to close the loop with the chairs first.

Liz: Ok perfect. We'll put this into AD follow up for you and you can let us
know when it's ready.

 o Javascript Object Signing and Encryption (jose)

Liz: Does anyone have any objections for the jose rechartering moving forward?
I'm hearing your objections so it looks like this 1 is approved as well. And
since Roman is not here, we will definitely put this in AD follow up for him so
that he can check it over.

 o WebRTC Ingest Signaling over HTTPS (wish)

Liz: Does anyone have any objections to this recharging going forward? I'm
hearing no objections so it looks like this is approved. Murray, this is one of
your groups. Is this ready to ship as is or do you want to look it over?

Murray: No, we can go to the next steps with this one.

Liz: We'll go ahead and send that recharter announcement.

5. IAB news we can use

Liz: Roman is not here neither is Dhruv. Lars, I don't think you were at the
IAB this week. Mirja, any news?

Mirja: Ok, it's on me. So first of all we have the IESG slate we're about to
confirm them and hopefully today. It will be announced very soon. Hopefully.
Um, then also, maybe something might be of interest for you is that we finally
approve the statement on encryption and client's head scanning so that we'll
publish this in the next few days as well.

Martin: Does the IESG slate include the chair or is that separate?

Mirja: That does include the chair.

Martin: Ok, great.

Mirja:  I would like to remind everybody that the IAB is looking for candidates
for the ISOC board of trustees. We have 2 positions to fill and we currently
only have 2 candidates. So, you know, if you have anybody in mind, especially
if you have diverse people in mind, which are not male and white. It'd be great
if you could reach out to people and kind of encourage people to self nominate
or nominate them. We really need more candidates there. We are also about to
finalize the peer response that we got from John Klensin.

Liz: Ok, thank you Mirja.

6. Management issues

6.2 [IANA #1288077] renewing early allocations for
draft-ietf-pce-segment-routing-ipv6

Liz: John this is one of your groups. Do you have any comments about renewing
this allocation?

John: Yes, we should review it. It's been in my queue.

Liz: Thanks John.

Lars: No, objection, just a question. Where's the doc in terms of progression?

John: It's been sitting in my queue for about 90 days. I should be getting to
it fairly soon.

Lars: If it's in your queue then yeah, let's approve it.

Liz: I'm hearing no objections so this is approved and we'll get that official
note to IANA.

6.3 [IANA #1291684] Designated experts for RFC 9493 (Subject Identifiers for
Security Event Tokens)

Liz: This is here to be assigned to Roman which has been done.

6.4 [IANA #1287397] Designated experts for CoRE Target Attributes Registry
(draft-ietf-core-target-attr) (Francesca Palombini)

Liz: Francesca has identified Carsten Bormann and Marco Tiloca as the
designated experts for this registry and the objection to approving those two
folks?

Lars: Not an objection, but can we find anybody else besides Carsten for CORE?
Or is that just a given that it needs to be him? I'm worrying a little bit
about single points of failure.

Francesca: I don't know if I need to answer this. I understand that concern. I
can try to find other people, but Carsten is usually the best expert for many
of these kinds of documents. It's the obvious choice, and I do try to pair him
with other people all the time.

Murray: For other registries for CORE, is there a backup? Because I'm sensitive
to this whole central point of failure thing given the number of registries
that we own. In ART now that only has one person who's been doing it for 40
years and there seems to be some assumption those people will be around forever.

Francesca: Yes, I always try to have at least two experts. It's rare that I
only have one. I always try to have different people as backup, but it's true
that for many of Carsten's documents he ends up being one of the experts. But I
try not to have the same person, of course, to make two central points of
failure.

Murray: Maybe we should require that he brings a second.

Francesca: I do ask the chairs and the authors and my own feelings of who could
be another person. In general, the answer that I have is to assign two
designate experts rather than just one. And just to highlight, we don't have
this problem not only in CORE. There's also other working groups that have the
same experts for several documents. But again, I don't know if the problem is
we don’t have enough backup experts.

Liz: Ok, I didn't hear any objections about approving these two so I think they
are approved for now and we can send that official note to IANA.

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

Martin: I dutifully did my action item about emailing about moving over the TSV
area list to WIT area list, but it got slapped down that it was too early. I
don't remember what we decided when to start doing Datatracker stuff for this.
Is it January or some other date?

Francesca: I'm not sure that we did decide exactly on when we would start doing
this. And the answer is probably as soon as possible. And my suggestion would
be after Christmas or after winter holidays.

Martin: Ok, in January I made a little list of like, the order of things to do
in Datatracker. I think I can circulate it on a list of people.

Francesca: That would be great. Sorry for blocking your action, Martin. I just
thought before we have the list, we should have the Datatracker page.

Martin: I'll circulate it and then we'll sit out until the first week of
January and then bug Robert.

Francesca: Sounds good. Thank you.

Liz: Any other business for the whole group? If not, we'll move to the
executive session.

6.1 Executive Session: NomCom Confirmations (Lars Eggert)

An executive session was held.