Narrative Minutes interim-2022-iesg-21 2022-09-22 14:00
narrative-minutes-interim-2022-iesg-21-202209221400-00

DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT
INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2022-09-22 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Andrew Alston (Liquid Intelligent Technologies) /  Routing Area
Jay Daley / IETF Executive Director
Roman Danyliw (CERT/SEI) / Security Area
Jenny Bui (AMS) / IETF Secretariat
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
Erik Kline (Aalyria Technologies) / Internet Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
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
Qin Wu (Huawei) / IAB Liaison

REGRETS
---------------------------------
Warren Kumari (Google) / Operations and Management Area
Francesca Palombini (Éricsson) / Applications and Real-Time Area
Alvaro Retana (Futurewei Technologies) / Routing Area

OBSERVERS
---------------------------------
Henk Birkholz
Robert Sparks
Greg Wood

1.2 Bash the agenda

Amy: Does anyone want to add anything new to today's agenda? I added the two
management items requested. Any other changes?

Lars: Should we talk about whether to have another BOF call next Thursday? I
guess we would only do one if one of the ADs wants to discuss a BOF proposal.

Amy: For your informal agenda you do have that item that's been held over until
Warren gets back, and I did also put on the final BOF approvals this morning.

Lars: I hadn't seen that. Okay, then let's do that.

Éric V: For today, can we put the SNAC discussion up front while I'm still here?

Amy: Yes, thank you. We'll take that after the action items.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes from the September 8
teleconference being approved? Great, I'm hearing no objection. I saw final
narrative minutes too; anyone have an objection to the narrative minutes from
September 8 being approved as well? Hearing no objection there either.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

     o Roman Danyliw to find designated experts for RFC 8809 (WebAuthn)
       [IANA #1229681].

Roman: In progress.

     o Martin Duke to find designated experts for RFC 9297 "HTTP Datagrams
       and the Capsule Protocol" [IANA #1238909].

Amy: This is on the agenda today to approve these designated experts.

     o Paul Wouters to find designated experts for RFC 9200 (ACE-OAuth)
       [IANA #1239251].

Paul: In progress.

     o Paul Wouters to find designated experts for RFC 9203 (The (OSCORE)
       Profile of the (ACE) Framework) [IANA #1239258].

Paul: In progress.

     o Paul Wouters to find designated experts for RFC 9237 (An
       Authorization Information Format (AIF) for Authentication and
       Authorization for Constrained Environments (ACE))[IANA #1239259]].

Paul: In progress.

   * OPEN ACTION ITEMS

     o Robert Wilton, Alvaro Retana, and Warren Kumari to report back to
       the IESG on the impact of COVID-19 to the IETF in October 2022.

Amy: On hold until October.

     o Murray Kucherawy and Martin Duke to contact the HTTPBIS chairs about
       the request to register a HTTP/2 Frame Type registration [IANA
       #1237502].

Martin: I just need to send an email to the IESG that we don't want it anymore.

4.1.2 Proposed for approval

 o Stub Network Auto Configuration for IPv6 (snac)

Amy: I have no blocks on this charter so unless there's an objection now, it
looks like this WG is approved.

Éric V: I will update the charter to include your comments; it was implied but
better to write it explicitly into the charter. Let's wait until tomorrow if
you don't mind.

Amy: That's fine. Once you let us know the charter is updated we are ready to
go.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-lsr-isis-rfc5316bis-04  - IETF stream
   IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS
   and GMPLS Traffic Engineering (Proposed Standard)
   Token: John Scudder

Amy: I have a Discuss in the tracker and our Discuss holder is not with us
today; do we need to discuss this?

John: No, I don't think so. It looks to me like Les has been responsive to all
of you and when Alvaro gets back from PTO we'll sort it out pretty easily.

Amy: Is this going to require a revised ID?

John: Very likely.

Amy: Okay, so this will stay in IESG Evaluation, with Revised ID Needed.

2.1.2 Returning items

 o draft-ietf-ippm-rfc8889bis-03  - IETF stream
   Multipoint Alternate-Marking Clustered Method (Proposed Standard)
   Token: Martin Duke

Amy: I have no Discusses for this document, so unless there's an objection now,
it looks like this document is approved.

Martin: Let's do Approved, Revised ID Needed please. Éric V had a couple of
comments and I need to do a re-read.

Amy: Okay, Martin, let us know when this is ready.

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

 o draft-zern-webp-09  - IETF stream
   WebP Image Format Media Type Registration (Informational)
   Token: Murray Kucherawy

Amy: I have several Discusses here. Murray, you'd said in email it would be
Revised ID Needed, but since you're here do you want to discuss anything?

Murray: No, it's clear what the issue is. We went through an iteration where I
had him add reference material instead of referring to it; he did that for his
stuff but left references to other things that I missed. That's what my
homework is here; I don't need to discuss anything.

Amy: Okay, thanks Murray. This will stay in IESG Evaluation, Revised ID Needed.

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-irtf-qirg-principles-00
   IETF conflict review for draft-irtf-qirg-principles
     draft-irtf-qirg-principles-11
     Architectural Principles for a Quantum Internet (IRTF:
   Informational)
   Token: Éric Vyncke

Amy: Unless there's an objection now, this is approved to go back to the IRSG.
I'm hearing no objection, so this is approved.

 o conflict-review-pkcs5-gost-00
   IETF conflict review for draft-pkcs5-gost
     draft-pkcs5-gost-08
     Generating Password-based Keys Using the GOST Algorithms (ISE:
   Informational)
   Token: Roman Danyliw

Amy: Unless there's an objection now, this is approved to go back to the ISE.
I'm hearing no objection, so this is approved.

 o conflict-review-irtf-icnrg-ccninfo-00
   IETF conflict review for draft-irtf-icnrg-ccninfo
     draft-irtf-icnrg-ccninfo-12
     CCNinfo: Discovering Content and Network Information in
   Content-Centric Networks (IRTF: Experimental)
   Token: Erik Kline

Amy: Unless there's an objection now, this is approved to go back to the IRSG.
I'm hearing no objection, so this is approved.

3.4.2 Returning items

 NONE

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

 o Supply Chain Integrity, Transparency, and Trust (scitt)

Amy: I have no blocks in the tracker, so unless there is an objection now, it
looks like this is approved for community review.

Roman: I wanted to mention a couple of alibis based on the feedback. I don't
disagree with the assessment from many of you that this is long; I will just
comment that there was a lot of difficult consensus that came into producing
this test. I'll review what's possible to trim it up and see what the broader
community says. It took a while to get us to what we have. Second, the
observation that there is this confusion [of] is this software, is this general
thing? That's something that can get fixed. It is too late in the text that
discusses that this is currently chartered for software only, so I'll make that
earlier in the text. And in response to Zahed and Éric, there is a vibe in the
discussion that folks would like to do work in other verticals. We couldn't get
consensus on that, so the feeling is that if we work on software, which is how
the charter is written, it's likely reusable in other verticals, so that's also
contributing to a bit of the vagueness. There's a desire to make sure the text
is written in such a way that we're focused on software, but if it were to be
reused that would be okay too. That has led to the text looking the way it
does. Thank you for all that review. I'm going to want some edits before we
send this out further.

Zahed: Thanks for that clarification. I was not involved in the discussion but
what you said makes sense. I also feel like when people are in conflicting
views, maybe it's better to be a bit more specific so it doesn't create a stall
in the wg. For the httpbis part, i don't think that's a big deal but maybe
somewhere in the charter it might say they will work on these things and then
that becomes a milestone or something. I'm not very opinionated about that, I
was just surprised to see there was a milestone that wasn't mentioned before.
But you have the details so I don't mind that one.

Roman: I appreciate that feedback. I was on the mailing list sending a crisp
negative signal to the problem you were saying, where folks were saying given
how the charter is written, is this in scope? And I was saying absolutely not.
So you guys are right, we'll put it up front to be very crisp that we're in
software only here.

Zahed: Okay.

Roman: I'm good if no one else wants to say anything more. I appreciate it.

Amy: I have this as pending edits so Roman, we'll wait to hear from you to send
this out. I also note there is no session request yet so if they want to have a
session in London, they should get on that. Since this is now a proposed WG
instead of a BOF, you should be able to put in a session request for it.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 NONE

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Mirja: We are working on a response to a call for input about Trade Regulation
Rule on Commercial Surveillance and Data Security. They have a call with a lot
of open questions and our main point will be about how important standards are
and give them some pointers about everything we know about data security and
surveillance. That's ongoing. The other thing we discussed yesterday is that
the IAB is trying to work on an internet vision document, summarizing what the
trends and challenges are. This just started and we will see how that goes. As
a reminder we will have the M-TEN workshop on management in encrypted networks
in a few weeks. We have all the papers, have invited the participants, and will
publish the agenda later today. If someone from the IESG wants to join they
should let us know and we can invite more people. I think that's it.

6. Management issues

6.1 [IANA #1238909] Designated experts for RFC 9297 "HTTP Datagrams and the
Capsule Protocol" (Martin Duke)

Amy: Is there any objection to naming Lucas Pardue and David Schinazi as
designated experts for this registry? I'm hearing no objection, so they are
approved and we will send an official note to IANA.

6.2 [IANA #1239251] Designated experts for RFC 9200 (ACE-OAuth) (IANA)
6.3 [IANA #1239258] Designated experts for RFC 9203 (The (OSCORE) Profile of
the (ACE) Framework) (IANA) 6.4 [IANA #1239259] Designated experts for RFC 9237
(An Authorization Information Format (AIF) for Authentication and Authorization
for Constrained Environments (ACE)) (IANA)

Amy: These three items are all for Paul and he's working on them.

6.5 [IANA #1239661] Management Item: Acceptance of media type registration from
standards organization OpenID Foundation (IANA)

Amy: We need to discuss whether they can be added to the standards tree, I
believe.

Murray: I don't have any objection to this. I think the question we are
supposed to talk about is whether we expect more stuff from them, should we be
communicating more with them and do we need a liaison. I don't interact with
this organization at all. If anyone else does, they might have an opinion.

Roman: OpenID is a significant bridge into the OAUTH WG and GNAP. That's my way
of saying they're a legitimate place with high overlap in the work. Minimally,
we should approve this. As to whether more are coming down the pike and if we
need a liaison, I don't know, but there is a significant overlap in
participation. I'm not sure we need something formal.

Murray: To resolve that question, should we ask OAUTH what they think? Or is it
enough to just say not right now?

Lars: Ask them about the registration, or the liaison?

Murray: Ask them if they think we would benefit from creating a liaison with
OpenID.

Lars: There's no harm in asking, I think.

Murray: I can post to the list and ask them. I guess we have no objection to
the registration, and I'll talk with OAUTH about the liaison.

Lars: I'm fine with approving the registration, but I think we should change
the process and only on the third request from some organization should we
actually have a discussion about recognizing them, rather than doing it on the
first one. Many of them are not going to send us many.

John: Then you need to maintain a count.

Lars: Well, IANA can do that. But yes. I don't have a strong feeling about it
but until we change the process we are sort of stuck with what we have now.

Murray: I have a bis document somewhere that reviewed this process and
explained why we do this review and what the genesis of it is. It ended up just
being in the IESG wiki, but the BCP says we do it after one, so it would take a
standards action to change it.

Lars: Looking at their website now, I think they are a legit organization.

Murray: So we can approve this one and then take up the general question for
later.

Roman: I'm pretty sure we're using some of their stuff in production on our
infrastructure.

Robert Sparks: Datatracker logins for Meetecho, ietc, are using OIDC which are
based directly on these OpenID specifications.

Mirja: Back to the question about establishing a liaison relationship with
them. Just because they're an SDO doesn't mean we need a liaison relationship.
It's mostly used for organizations where we don't have full access to their
documents and having a liaison provides some kind of access, or we can't
participate openly in their process or something. If there's participant
overlap and enough exchange on an informal basis, that's always preferred.

Roman: I think that's the case we are in. It's a very organic and productive
relationship now.

Mirja: Then that's fine.

Lars: Their documents are all open, too. That doesn't need anything else.

Murray: Then I'll skip the OAUTH part.

Mirja: Sounds good, thanks.

Amy: I'm hearing that we are approving the media type registration from the
OpenID Foundation but we haven't approved adding them to the standards related
organizations that have registered media types in the standards tree list?

Murray: My read is that we do add them to the list and then we have a side
thing to figure out if we want to change the limit from one to three or
something. I can look into that informally with IANA.

Amy: Okay, so we are going to add them to the standards related organizations
that have registered media types in the standards tree list.

Lars: Yes.

Amy: Okay. We'll send a note to IANA on that.

6.6 [IANA #1239700] Management Item: Acceptance of media type registration from
standards organization National Emergency Number Association (NENA) (IANA)

Murray: ECRIT the WG works with NENA intimately. I believe the whole idea is to
create a registry or registries that [garbled audio] The whole point of this is
to get them doing it, so I support adding them permanently to that list.

Amy: Is there any objection? I'm hearing no objection, so we will send that
note to IANA.

6.7 Adding an European timezone moderator to the IESG lists (Lars)

Lars: There was some email from Andrew that didn't make it to iesg-only until a
US based moderator did something. It would be helpful if we had somebody who
was not in the US.

Cindy: On the regular IESG list it's Murray, Roman, and the Secretariat, and on
iesg-only it's just Murray and Roman. With this one, Lars specifically asked me
to go check.

Lars: Do we have a volunteer? It would help with getting stuff unblocked faster.

Andrew: I'm quite happy to do it. I don't imagine it's going to take a huge
load. Does anyone happen to know why that email got moderated? I could post to
iesg-only-2022 but iesg-only didn't go through and I don't know why.

Cindy: Your address got DMARC adjusted so whatever thing to kick it through
hadn't happened on that one list. It should be okay from now on. Sometimes it
behaves unexpectedly.

Lars: This doesn't require any other access than to mailman to fix, right?

Cindy: Right, when the moderator gets a message to allow something through,
there's a checkbox to allow this address.

Andrew: Just as a clarification, what is the difference between iesg-only and
iesg-only-2022?

Cindy: iesg-only-2022 is subscribed to iesg-only, and that is so people don't
have to remember which current year to send to. They can just send to iesg-only
and it gets forwarded appropriately. The archives are separated out by year so
that IESG members can't see the archives of iesg-only for years they weren't on
the IESG.

Martin: By year or by term?

Cindy: By term.

Martin: So 2022 starts in March.

Cindy: Yes.

Lars: Do we want to add Adnrew to both lists? I hear violent support, so let's
do that.

Martin: Welcome to the club.

Cindy: We will get you passwords, Andrew.

6.8 [IANA #1233716] Management Item: CoAP Content-Format for
application/tm+json (IANA)

Amy: A designated expert would like the IESG to approve an assignment in the
registry. Can anyone speak to this?

Lars: This seems a similar case to the Google one we had earlier. It's IETF
review, meaning a document, or IESG approval, for some cases like maybe this.
Here there is a published reference that we can base the approval on if we want
to do it.

Mirja: Shouldn't this request come from W3C then?

Lars: It doesn't require it. Or maybe it did come from there. Can we find out
from IANA who made this request?

Sabrina: Yes, I'm looking that up right now. It is from W3C. When we sent it to
the expert, the expert recommended that we assign a value from the IETF review
or IESG approval range, so that's how we ended up with this request.

Lars: I'm a bit confused that there is an expert. Is there another range that's
expert review? Typically IETF review or IESG approval registries don't have an
expert, right?

Sabrina: For this one, there are multiple ranges. The first range is expert
review and then the next one is IETF review or IESG approval. There's also
first come first served.

Mirja: Why is this supposed to go into this range instead of the expert
approval range?

Sabrina: I'm not sure. That's what the expert recommended.

Lars: did the W3C request a specific number, or did they not care?

Sabina: They didn't request a specific value, that's what the expert
recommended.

Murray: Maybe the expert didn't know there was an expert review range? I would
ask just for the sake of clarifying.

Sabrina: I think he might be aware just because the note said he's not sure why
the registry is set up this way, the registration looks good and there's not a
scarcity of code points greater than or equal to 256. It looks like in the past
we've assigned the 432 also via IESG approval for Klaus.

Martin: Looking at the registry policies they don't seem to really make any
sense. IESG review is supposed to be a way to short circuit dumb stuff
happening, and not to just overrule what the policy is.

Lars: I think it's a different case. In your case, there was a document, but it
had failed to get consensus in the WG. here it's a request from another SDO and
there's a range. I don't quite understand why the registry has a smaller expert
review range and then a larger IETF or IESG range. That seems like the wrong
way around. Also, there's a first come first served range and I don't
understand why they didn't go there.

Mirja: There's already an approved value for 432 and they probably wanted 433
or whatever. But then the question is why was 432 approved by the IESG?

Rob: Assuming these are encoded in CBOR, there's a slight benefit in choosing
smaller numbers. That may be the reason, to encode in two bytes rather than
three or four.

Murray: I'd like to ask the expert why they think we should assign it from our
range instead of theirs. Not that I'm being protective of our range, I don't
really care, I just want to know why he kicked it over to us when he had the
ability to make the assignment.

Martin: But the first come first served range starts at 10,000 which is also
two bytes. It's the expert review band that gets you the length savings.

Lars: I have a feeling Mirja is correct that he put it there because it's
closely related. Maybe IANA should ask him and let us know. I have no problem
with approving this, it's just a mystery.

Sabrina: We can follow up with the expert.

Martin: If for some reason they can't use one of the other ranges that doesn't
require us to do this, I would like to see this group either commit to fixing
the registry in a short bis, and then I'd be happy to do IESG approval to
accelerate the process. Stepping on the IETF review range just because we
thought the WG was dumb when they did this is probably not the right way to
proceed.

Mirja: The question here is what happened to 432 and why did that get assigned
to this range initially? We don't know.

Lars: And why is the expert not using their own range. That's the puzzling
thing here. If he believes this should be approved why isn't he putting it into
the range that he can approve it for? Which is slightly different than we had
for the HTTP one.

Murray: But I do agree with sending this back to the WG and asking them to fix
it.

Rob: It seems to me like the range is the wrong way round.

Lars: if you look at the registry, W3C has gotten 21, which is in the expert
range. So it's odd. Anyway, that's not the point. So Sabrina, will you ask the
expert and report back?

Sabrina: Sure.

Lars: Whose WG is this, Francesca's? Who follows CORE and can send them a
message about the registry?

Murray: I can do it.

Lars: If you get overloaded looking at her stuff, let us know and we can
reshuffle. Thank you.

Amy: I'll mark this as coming back after IANA reports back and we'll put this
on hold.

6.10 Request for .ietf.org sub-domains (Lars Eggert)

Lars: This was a request from Jay and there was agreement on the mail list, so
I don't know if we need a discussion. Can Jay get those subdomains?

Roman: Sounds like a plan, we should do that.

Lars: Okay, go ahead then, Jay. Thank you.

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

Martin: The people behind the QUIC deep dive that was supposed to happen in
Philly are planning to do it in London. They're kicking around the idea of
instead of having it a two parter that finishes in Yokohama, doing the whole
thing in London. I guess the question is, how do we feel about that and is
there enough time in the schedule to do essentially two TDD sessions either
back to back or scattered through the week?

Lars: They asked for 2.5 hours. Would they ask for more than that for the full
thing?

Martin: That is my understanding, that it would be five hours of material or
something on that order.

Lars: That seems like a big ask during session time. Does it need to be during
session time? Could it be on Sunday?

Andrew: I'd say if you're going to do this for five hours, putting it on Sunday
would probably make more sense. It also allows people to have the full 5 hours
without breaking it up. That's just me.

Martin: I can tell them that if they want to do both in one meeting, they
should probably do it on Sunday, or at least part of it on Sunday.

Lars: Even if they just want to split it up. I don't see value in having it
parallel with seven other sessions and I don't think they want to do it that
way. They don't need ADs or IAB members who are busy on Sunday. Their request
says "please schedule Tuesday morning" which is very aspirational.

Andrew: Whenever it happens, I hope it doesn't conflict with too many things,
because I'd like to be there if I could.

Martin: I'm not really sure why they want to do it all in one go or do two
mornings. Do people have a preference?

Lars: It's their choice. If it's not during session time I don't care.

Mirja: No strong opinion.

Martin: Okay, I'll tell them it's up to them and they can have two mornings if
they want.

Lars: While we're speaking of session requests, how are we doing? Is everything
going to fit?

Liz: I haven't counted them up yet; we usually get so many last minute requests
on the last day that I'd just have to count again tomorrow afternoon anyway.
I'll count them up [when requests close] and let you know.

6.9 Executive Session Discussions (Lars Eggert and Andrew Alston)