Narrative Minutes interim-2023-iesg-06 2023-03-02 15:00
narrative-minutes-interim-2023-iesg-06-202303021500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2023-03-02 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
Jenny Bui (AMS) / IETF Secretariat
Jay Daley / IETF Executive Director
Roman Danyliw (CERT/SEI) / Security Area
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) / Incoming Routing Area
Erik Kline (Aalyria Technologies) / Internet Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Applications and Real-Time Area
Alvaro Retana (Futurewei Technologies) / Routing Area
John Scudder (Juniper) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
Amy Vezza (AMS) / IETF Secretariat
Éric Vyncke (Cisco) / Internet Area
Paul Wouters (Aiven) /  Security Area
Qin Wu (Huawei) / IAB Liaison

REGRETS
---------------------------------
Warren Kumari (Google) / Operations and Management Area
Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area
Robert Wilton (Cisco Systems) / Operations and Management Area

OBSERVERS
---------------------------------
Oooonduke
Jason Hall
Lee-Berkeley Shaw
Greg Wood

1.2 Bash the agenda

Amy: Does anyone have anything to add to today's agenda? Any other changes?

1.3 Approval of the minutes of past telechats

Amy: Is there any objection to approving the minutes of the February 16
teleconference being approved? I'm hearing no objection, so those are approved.
We have narrative minutes as well; any objection to those being approved?
Hearing no objection there.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

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

Amy: We'll mark this in progress for Roman.

     o John Scudder to find designated experts for draft-ietf-lsr-flex-
       algo-25 (IGP Flexible Algorithm) [IANA #1266560].

John: That's actually in progress. I noticed there were seven more registries
in the same group that also need experts so I'm trying to take care of all of
them at the same time. It should be done soon.

     o Murray Kucherawy/Francesca Palombini to find designated experts for
       RFC 7462 (URNs for the Alert-Info Header Field of the Session
       Initiation Protocol [SIP])[IANA #1266696].

Amy: This is a brand new item and I'm not sure who will pick this up.

Murray: I own the SIP stuff now so I guess I'll take this and the next one.

     o Murray Kucherawy to find designated experts for RFC-ietf-jmap-
       blob-18 (JMAP Blob management extension) [IANA #1267309].

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

On hold.

     o Lars Eggert, Warren Kumari, Éric Vyncke, and Rob Wilton to discuss
       whether to reconstruct the document approval announcements to be
       more meaningful.

Amy: I believe we can mark this as done because we had the discussion last week.

Lars: I put a PR in for the DAtatracker so it should automatically stick the
abstract of a document into whatever the first thing is called and it should
also grab the AD and shepherd names and put them in. if there's anything more
to do we should open a new action item.

     o Éric Vyncke to draft a proposal for the tools team to auto-populate
       the approval announcement text in the "ballot text" section
       (document abstract, responsible AD, document shepherd).

Lars: I think I also did this one.

Alvaro: Does that take out the ballot text button thing? If we populate that
will it put that information twice?

Lars: It only changes what goes into the autogenerated ballot text. It doesn't
fully solve it, it basically makes it a little easier to do the ballot text and
maybe that's enough.

Alvaro: So what you did doesn't go into the announcement, it goes into the
ballot text.

Lars: Right. The default ballot text should have two fewer things for you to
copy and paste.

Éric V: I'd suggest keeping this item until the code is live to see how it is
going, maybe for one month.

Amy: I'll keep this in progress and put it on hold until April.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-pim-null-register-packing-14  - IETF stream
   PIM Null-Register packing (Proposed Standard)
   Token: Alvaro Retana

Amy: I have a couple of Discusses in the tracker; do we need to discuss those
today?

Alvaro: Maybe. First of all, thank you everyone for all the comments. Murray,
it seemed to me that the solution was okay with you. Or did you expect
something else?

Murray: It's fine. There was one iteration we were doing on just the way the
action was worded. There was one other thing too, that this document should
update 7761, but the boilerplate at the top left doesn't say that yet.

Alvaro: No, this document doesn't update 7761. That's why we're doing the
8736bis.

Murray: Okay. I guess something there needs to be adjusted. I think it was in
the abstract that it updates some things.

Alvaro: That abstract I pasted there is from 8736.

Murray: Oh, I'm sorry. I get it.

Alvaro: The messages are not all defined in 7761, so we had updated all the
messages and we forgot to make them unassigned.

Murray: Right. Is that actually a necessary step to move them from reserved to
unallocated and then make the allocation? Will IANA not do it directly?

Alvaro: If we're going to do that, then we don't need to do anything, we can
just change the registry. But I figured we shouldn't change the registry to
unassigned without documentation. But if IANA is fine with that, I'm fine with
that too.

Murray: This is the first time I'm stumbling across the idea that reserved
blocks an IANA action. If that's the way we do it, that's fine, I just haven't
seen it before. But I think the tl;dr here is that I'm very close to clearing
and we don't need to talk more about it here.

Sabrina: I think we'd prefer to reference a document.

Murray: I don't mean that, I mean do you actually need to do this in two steps
via documents every time? Take something out of reserve, put it in allocated,
and then a second document makes the allocation? Or would you be fine with an
IESG approved document going straight from reserved to allocated?

Sabrina: I think going from reserved to allocated should be okay if there's a
document backing it up.

Murray: Thank you.

Alvaro: So just so i'm clear myself, the reason we're doing the bis is because
it's not just this field for this message in this draft that we need to update.
Instead of having every document update something we're doing everything once
and that's it. So we're going to need a Revised I-D for this.

 o draft-ietf-opsawg-tlstm-update-12  - IETF stream
   Updates to the TLS Transport Model for SNMP (Proposed Standard)
   Token: Robert Wilton

Amy: Rob isn't on the call and we have a Discuss here.

Paul: They did resolve it but I haven't seen a new revision yet, so once that's
out I'll clear my Discuss.

Amy: I'll put this in Revised I-D Needed since it looks like that's where
they're headed. Thanks.

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-acme-integrations-13  - IETF stream
   ACME Integrations for Device Certificate Enrollment (Informational)
   Token: Roman Danyliw

Amy: I have a Discuss in the tracker; do we need to discuss that today?

John: It needs some kind of response, either a revision or for the authors to
explain why I'm wrong.

Paul: I discussed this with Roman yesterday because I was confused how an
informational document could not have 2119 keywords. The way Roman saw your
Discuss was that the document seems to imply that it adds new keywords, even
though it's just quoting other documents, and that was the main point of your
concern. Is that right?

John: Something like that. Whenever you sprinkle 2119 keywords in it sounds
like you're specifying new behavior. If all they're doing is saying this is the
behavior that's already specified, I think it works better to make it clear
that's what's being done. I'm not expert enough in the area to know which thing
is happening and I'd really just like a discussion with the authors to see how
they're handling it.

Paul: That sounds good. We can do AD Followup for this one.

 o draft-ietf-tsvwg-dscp-considerations-12  - IETF stream
   Considerations for Assigning a new Recommended DiffServ Codepoint
   (DSCP) (Informational)
   Token: Martin Duke

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

Martin: Revised I-D Needed, please.

Amy: Okay; this will be Approved, Announcement to be Sent, Revised I-D Needed.

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 NONE

3.2.2 Returning items

 NONE

3.3 Status changes
3.3.1 New items

 NONE

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 o conflict-review-irtf-cfrg-voprf-00
   IETF conflict review for draft-irtf-cfrg-voprf
     draft-irtf-cfrg-voprf-21
     Oblivious Pseudorandom Functions (OPRFs) using Prime-Order Groups
   (IRTF: Informational)
   Token: Roman Danyliw

Amy: I don't have any Discusses, so unless there's an objection it looks like
this conflict review message is ready to go back to the IRSG. Okay, it looks
like this is approved; we'll get that sent on Monday as usual.

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 Computing-Aware Networking (can)

Amy: I have no blocking comments, but I know there has been discussion about
the name and the acronym.

John: The current version is -06 with milestones. The name is the last thing to
take care of. Thanks for the explanation about the pain that we'll be biting
off by changing the name, but I think we're going to change the name to CATS,
for Computing Aware Traffic Steering. Thanks to Lars and Dirk for coming up
with that name. Any last minute comments or concerns for doing the name change?
I think we'll also close the CAN mailing list and use its subscriber list to
seed the CATS mailing list. I don't know if there are any concerns about opting
people into that.

Éric V: When we moved dns privacy into dprive we kept the old list but provided
an alias for the old list into the new one.

John: The CAN mailing list has been around a really short time, just a month or
two.

Éric V: It's up to you.

Mirja: We had a bit of a discussion about if this is ready for chartering or if
there's another BOF needed; was there discussion I missed?

John: I don't know if there was a formal followup but there has been a
reasonable amount of conversation around it. My read is that there is decent
community consensus for it and there was certainly ample opportunity for people
to raise concerns during IETF Last Call.

Mirja: Thanks, I just wanted to check.

John: Okay, I guess we have a WG. Thanks everyone for your help. I guess we can
take the logistics of doing the renaming offline.

Amy: We can do a lot of that for you. Getting CATS to the point CAN is now may
need tools team intervention. We'll look at that.

John: Should I go ahead and push one more update to the charter that changes
the name and then I'll take my hands off and let you go ahead?

Cindy: We will have to create a brand new Datatracker group, so we can just put
the new name in that group instead of changing it in the existing one.

John: I'll update the charter text but otherwise leave it alone.

Amy: We'll come back to you with anything that looks weird.

 o RADIUS EXTensions (radext)

Amy: This is in the OPS area but we have Paul as area director.

Roman: Did we sort out whether we were putting this in OPS or SEC? I'm fine
either way but that was an open question.

Paul: I think that's still an open question. Warren said he didn't care too
much either way. I guess maybe it mostly matters for avoiding scheduling
conflicts. In that case it might make more sense to put it into SEC.

Roman: That would be the primary driver; I'm with you. I think it's SEC for
scheduling.

Amy: Any objection to moving the WG to the SEC area? Is that going to come as a
surprise to the people involved in this?

Paul: No, I think people were surprised it's OPS. Before moving it I can sync
up with Warren to be sure.

Amy: I don't have any blocks so that seems to be the only issue. Can we say
this is approved pending area?

Paul: That's fine with me.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o IPv6 over Low Power Wide-Area Networks (lpwan)

Amy: I have no blocks. Does this require external review?

Éric V: I think so. It's changing the topic. Thanks for all the reviews; I
think I updated the draft charter to implement all the changes. LPWAN is a very
small set of network. They want to use a protocol defining LPWAN-SCHC to other
protocols which are no longer small constrained networks. Erik is suggesting to
change the name of the WG. I'm okay with it, as long as it doesn't change too
much. I don't mind either way; I think Erik's suggestion does make sense.
Process wise, is changing the name of a WG more complex than rechartering?

Amy: Rechartering is already populated, everyone is already on board, it's
already working. To charter a new WG you'd have to go through all the steps.
It's basically chartering a brand new WG to change the name.

Lars: We're not changing names. You can keep the acronym and make a new
expansion of it, but you can't change the acronym without making a new WG. I
would suggest you just put a note in the charter that says it's called LPWAN
because it used to be about this and now it's different.

Éric V: Okay. So we can change the expansion, right?

Amy: You can change the name but not the acronym.

Éric V: Okay, I'll work with the chairs to maybe change the expansion and I'll
suggest adding something about that in the charter .

Lars: I saw your response to my comment that you wanted to change something to
coordinate and I still don't think this is strong enough. LPWAN had these
documents, remember we had this thing with 3GPP where we had to check if it was
okay for them to do. They have a history of kind of storming ahead with this
stuff and I'd like to have something in there that says you can only adopt
something if you've cleared it with liaisons ahead of time that it's okay for
us to do.

Éric V: You mean for other SDOs?

Lars: Yeah. Internally, one would expect we can handle this at the IESG level,
but for other SDOs they shouldn't adopt any work without having done the
liaison part.

Éric V: In the case of 3GPP they got the liaison before. But yes, it doesn't
hurt. I can edit. Another reason to wait for one more step. Thank you.

Amy: So did you want us to wait on sending out the external review?

Éric V: Yes. I'll send an email when it's ready to go.

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Mirja: I don't think there's any. We had a discussion yesterday on identity
management that was really interesting and we'll maybe have a workshop in the
future. If you're interested in that you can get in touch with us.

6. Management issues

6.1 [IANA #1266696] Designated experts for RFC 7462 (URNs for the Alert-Info
Header Field of the Session Initiation Protocol [SIP]) (IANA)

Amy: This has been assigned to Murray at the top of the call.

6.2 [IANA #1266337] renewing early allocations for
draft-ietf-pce-segment-routing-policy-cp (IANA)

Amy: John is the AD for this document; are we good for renewal?

John: Please.

Amy: Is there any objection to approving the renewal of this early allocation?
I'm hearing no objection, so we'll send an official note to IANA.

6.3 Proposed Telechat Dates Between IETF 116 and IETF 117 (Secretariat)

Amy: We have two proposals here; one has two formal back-to-back telechats
before the retreat and then the week after the retreat is informal, then
another two formal back-to-backs before IETF 117. The second proposal is two
formal back-to-backs before the retreat week and then a formal the week after.

Roman: When there's a formal with a full load, that's most of my week. The idea
of having 3 weeks to focus mostly on IETF is a lot. If we want to do back to
back formals plus a retreat week we should calibrate the maximum load for those
formals.

Amy: In the past the IESG has decided that the first formal would be normal and
the second would be limited pages. You could do that or something completely
different.

Lars: I don't have a strong preference. Does anybody care?

Éric V: I won't be on a telechat on Accession Day.

Amy: Proposal one is the one people are leaning towards.

Roman: Let's go with number one.

Lars: Let's just do it. We can always change it later; this isn't setting us in
stone.

6.4 IANA #1267309] Designated experts for RFC-ietf-jmap-blob-18 (JMAP Blob
management extension) (IANA)

Amy: This is assigned to Murray.

6.5 IESG Lore for New Area Directors Slide Deck (Secretariat)

Amy: There was a question whether we can make this slide deck public, but there
was a question about the private calendar links within. Should we just remove
those URLs and make this public?

Lars: Yes, we can put the URLs somewhere else.

Amy: Great, we'll remove those links and put that slide deck on the public wiki.

6.6 Designated Experts for the new rfc7752bis registries (Alvaro Retana)

Amy: Is there any objection to approving Adrian Farrel and Hannes Gredler as
the designated experts for these registries? I'm hearing no objection, so we'll
send an official note to IANA.

6.7 Designated Experts for the new registry in draft-ietf-lisp-pubsub (Alvaro
Retana)

Amy: Alvaro has identified Dino Farinacci and Albert Cabellos as designated
experts for this registry. Is there any objection to approving them? I'm
hearing no objection, so we'll send an official note to IANA.

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

Amy: Did you want to have a short discussion on retreat space?

Lars: That was only sent to me and the secretariat. The F5 tower is only
available at the beginning of the week and not on Friday. Since the IESG is out
by then it doesn't really matter for us, it will be up to the IAB to decide. I
think we want to stick with F5 for the other four days.

Martin: I'm very close to having that set.

Mirja: The only option that would be better for the IAB would be to go to
Google all five days instead of just one, right? Is that even an option?

Martin: It's an option, but there are tradeoffs. Here you'd have a somewhat
more convenient location vs a shuttle. That's on the IAB but if they think
that's unacceptable we can all take the bullet and go a little further.

Mirja: I think we can just find a room in a hotel somewhere or something but we
need to work with the secretariat to help find something. Maybe if we all end
up in the same hotel we can just go there. I don't know about the hotel options.

Martin: There are a ton of options around there and one hotel in the building.
I'll chat with Cindy and Alexa about finding a venue and I hope to have the
tower set by early next week.

Éric V: Just to come back to this LPWAN changing name, I'll check with the
chairs if they want to do it.

6.8 Executive Session: Confirmation of IAB-selected ISOC Board of Trustees
candidate