Narrative Minutes interim-2023-iesg-19 2023-09-07 14:00
narrative-minutes-interim-2023-iesg-19-202309071400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2023-09-07 IESG Teleconference

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

1. Administrivia

Alexa Morris: You may have noticed that Amy is not on the call this morning. I
want to share the news that she is no longer with the IETF Secretariat or AMS.
Her priorities right now are with family and I'm in touch with her and happy to
pass along anything you'd like me to. Please feel free to reach out to me in
Slack.

1.1 Roll call

ATTENDEES
---------------------------------
Andrew Alston (Liquid Intelligent Technologies) /  Routing Area
Roman Danyliw (CERT/SEI) / Security Area
Dhruv Dhody (Huawei) / IAB Liaison
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
Zaheduzzaman (Zahed) Sarker (Nokia) / 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

REGRETS
---------------------------------
Jenny Bui (AMS) / IETF Secretariat
Jay Daley / IETF Executive Director

OBSERVERS
---------------------------------
Gorry Fairhurst
Lee-Berkeley Shaw
Greg Wood

1.2 Bash the agenda

Cindy: Does anyone have anything to add to today's agenda or any changes?

1.3 Approval of the minutes of past telechats

Cindy: Are there any objections to approving the minutes from the August 24
telechat? Hearing no objection, those are approved. There are also narrative
minutes from August 24; any objection to approving those? Hearing no objection,
we will call those approved.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

     o Roman Danyliw to find designated experts for RFC 9393 on Concise
       Software Identification Tags [IANA #1275658].

Roman: In progress.

     o Murray Kucherawy to find designated experts for RFC 9457 on Problem
       Details for HTTP APIs [IANA #1277796]

Murray: I have names for this; can we add a management item at the end to
approve them?

     o Rob Wilton to find designated experts for RFC 9445 (RADIUS
       Extensions for DHCP-Configured Services) [IANA #1279159]

Cindy: This is a new action item to assign this to Rob.

   * OPEN ACTION ITEMS

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

Warren: In progress; I had a long chat with Barry a few days ago and we'll meet
again in a few weeks.

Murray: John Klensin has also offered to write text.

     o Roman Danyliw to open a Datatracker issue suggesting a feature to
       better signal individual contributions

Roman: In progress.

     o Andrew Alston, Murray Kucherawy, Zahed Sarker, Martin Duke, John
       Scudder, and Jim Guichard to draft text regarding document
       authorship/editorship with regards to the number of authors listed.

Andrew: In progress. I need to send mail.

     o Lars Eggert to facilitate a community discussion on priorities for
       IESG processes.

Lars: In progress. This will likely take the shape of a BOF

     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: This is in progress; I made a Github repo and reached out to the original
authors.

     o Warren Kumari to follow up with the tools team regarding removing
       the requirement of needing an author email for deceased authors.

Warren: In progress.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-taps-interface-22  - IETF stream
   An Abstract Application Layer Interface to Transport Services
   (Proposed Standard)
   Token: Zaheduzzaman Sarker

Cindy: We have a number of Discusses; do we need to discuss any of these today?

Zahed: This is a high number of Discusses. First of all I'd like to thank you
all for looking at all these documents really carefully and giving really
valuable comments. Regarding this one particularly, I think most of these
Discusses are solvable. Paul's is some confusion on the scope of this work so
maybe we need to clarify that, and hopefully the authors will do that. Lars,
what you wrote in your comment is a bit more concerning to me. Maybe you can
explain why you said you would abstain because you don't think this is a
Standards track thing. To be honest, this is the only document in the group I
think that should be Standards track.

Lars: I don't think the others should be Standards track either. I didn't have
a lot of time to review things this week so this is the one I reviewed. The
title says it's an abstract API, and it is really that. It's not actually an
API, it's here's some guardrails around how you might structure an API for
this, which is pretty high level and there's a lot of stuff that's missing.
Even for an abstract API it makes a bunch of assumptions and it's really not
abstract, in the sense that you can use this API if you know what all the
underlying transports are doing and why. Then you might know what you need to
ask for to get what you want. I have no idea if this will actually work.
Without any implementations of an actual API that fit this abstract shape, I
don't think this can be a Proposed Standard. I have no idea how you'd ensure
interoperability or how we would even know this works. There's a lot of good
stuff there and this is a complex topic, but it seems immature to me.

Zahed: One thing you brought up is the abstractness of this API. [crosstalk]

Lars: I meant actual operations, the knobs and functions that are exposed. They
are very sketchy.

Zahed: I think the point there is you can tell exactly what transport you want
using these abstract APIs. The idea at that time was we would also like to give
the developers and users to ask for something particular if they know. If
someone wants to ask for QUIC they can get QUIC.

Lars: That's not what I'm concerned about. For example, there are these very
simple examples that leave me with more questions than answers. This
multiprotocol server that speaks HTTPS and QUIC, and so there's some pseudocode
there that says the port is 443 and the service is HTTPS and for qUIC all of a
sudden it says with protocol QUIC. It's completely unclear what the semantics
here are. Why doesnt it say with protocol TCP TLS or TCP and then TLS is a
second statement. Paul had the example in his Discuss about IPSEC.

Zahed: Those are valid comments. Those need to be addressed in some way, either
we clarify that wasn't;' the intention or the authors clarify we need to change
the design. That's the point of technical clarification. You also brought up
this idea of not implementing. [?] project has been implementing and it's not
broken.

[crosstalk]

Lars: Is there an implementation status section somewhere? I didn't see one.

Zahed: There should be. I think there's an implementation draft, right?

Lars: If people have implemented parts of that, and that works, I'd be okay
with standardizing those parts. But there's a lot of stuff here that's at a
conceptual level. That doesn't make the cut for me for Proposed Standard.
Originally the group was not chartered to do Proposed Standards; this changed
sometime in 2018 for some reason.

Zahed: I don't remember that change. It's never been a question for me of not
producing a PS from TAPS.

Lars: Spencer was the AD when the change was made, but I don't know why. There
are some other things. In the beginning it starts out with defining data types,
like integers and strings and things like that. That's not really used. It sets
this expectation of a level of detail that the rest of the specification
doesn't follow through on. Let's say you wanted to implement this API. How
would you say I'm implementing RFC whatever this will be? How can you
interoperate, and say my API is an implementation of TAPS? Do you need to do a
subset of it, is it okay if you do some functions and not others?

Zahed: You're thinking if someone says "I'm implementing some RFC" then whether
it's implementing everything or not? I think that would be an implementation
choice. Every TAPS system will be implementing either the whole or a subset of
it. This comment is valid for a lot of the other standard RFCs I have, I know
people implement them partially.

Lars: If everybody who implements this implements some subset they choose
themselves, what's the point of having an RFC? Effectively everybody is
defining their own API.

Zahed: They won't be interoperating. TAPS also has this thing where you don't
need a peer that supports TAPS. If you have TAPS in your system and use it, it
doesn't really matter if the other system you're communicating with has it. It
doesn't need to be interoperable between two TAPS systems.

Martin: The objective here is that if you write an application to this TAPS API
and then move from one TAPS implementation to a different one, you don't have
to completely restructure the application. Maybe the names change and they're
different languages but the data items involved in all these calls remain
consistent. It's a little loosey goosey because it doesn't need the level of
interoperability in terms of wire images and things, because this is a
different kind of interoperability where different applications can use this
API without major changes.

Lars: What if I have an application in C, and let's assume Linux has a TAPS API
and MacOS has a TAPS API. Is the intention that using the same language I can
port this over with a socket API, or will I still need to make a whole bunch of
changes?

Zahed: Maybe you have a better answer, Martin.

Martin: I was a minor participant in this WG so I don't want to speak for
everyone, but in my mind, the intent was if you were going to port from the C
MacOS implementation to the Linux implementation, I don't want to say there
would be no changes but there would be a fairly mechanical thing where you'd
take the connect MacOS and change it to connect in Linux which maybe has
slightly different parameters or they're in a different order, but you're not
just completely restructuring the data you're storing. You don't have to switch
from a synchronous model to an asynchronous model. I think it's naturally
difficult to express that, so I understand the language is not quite as precise
as it might be otherwise.

Lars: That's helpful, thanks. If that's the goal then I Think it needs to be
specified with more precision. There are certain properties and certain API
functions that are really only mentioned showing up in examples but with no
mention of what they do. That makes it difficult to understand how one would
actually use this.

Zahed: That's a very valid comment and I think we can echo that to the WG and
they can work on clarifying these things. [crosstalk]

Lars: The clarification is one part, but the other belief I have is that
without an implementation, this is at a complexity where more words don't leave
me any more convinced this will actually work. More words help, but if they
want to go for Proposed Standard, they'd need to show an existence proof that
this actually works.

Martin: There are three implementations. In one of these TAPS documents, it's
written down. I don't remember which one. There's the Apple network framework
thing, which is shipped.

Zahed: In the implementation document they have this list.

Martin: So the Apple network framework is what this is based on. And then there
are two others that are academic projects, if I'm not mistaken.

Mirja: Lars, did you read the architecture document?

Lars: I skimmed it. That was the second one I skimmed. That one is okay; it's
higher level.

Mirja: I'm asking because these documents make sense if you read them in order.
You need to read the architecture document before you read the other ones.

Lars: I read them both, but I don't think the architecture document addresses
any of the things I've raised. If anything, it's even higher level.

Martin: I think you make a good point that there's some sort of implied
secondary functions that it's' not clear if you must do them and what they do.
That can be tightened up. I'm not going to say there's no reason to discuss
this or demand edits to the text. But I am interested in defending the idea
that this could be a Proposed Standard instead of Informational. With some
cleanup and a more clear enumeration of you must do these, you may do these,
etc.

Zahed: I also think this is the only document that I want to be on the
Standards track so we can impose something and tell the community to use this
one. We can work years to tighten things up but is it worth putting more effort
out over shipping something that we are confident works and we have some
implementations. To me that's good enough to ship this instead of tightening
every loose end, I don't think it's worth it.

Mirja: It was clear for us when we developed this document that we don't want
to have these kind of 'you must implement this' or 'you may implement this'
kind of difference. The understanding was that if you want to call your system
a TAPS system you have to do all of it. It's also understood that not everybody
will necessarily implement everything. If the underlying protocols only support
certain features, there's no point in providing interface that doesn't have a
protocol underneath. It really depends on the system. If you decide to
implement some of these parts it's better to align with TAPS so you have
portability. Interoperability wasn't a real consideration because you don't
need it to talk over the wire.

Lars: Can you port between the Apple framework and the other implementations?

Mirja: As Martin said, you can't just take your cord and port it right away,
you always have to check.

Lars: I still don't understand what you mean when you say you can use it,
because you actually can't. In other words, I'd be supportive if Apple wanted
to publish their network framework published as an actual API with the rigor
you need for that. And I'd even be okay with them saying others can work on
this. That's kind of what you need for an API. Otherwise you just have design
ideas which I don't think is a Proposed Standard. I think I've said my piece on
this.

Zahed: I think we should move on. Let's have a discussion with the authors and
WG. Thanks for this.

Roman: I know Gorry is on the call, so since Mirja is talking as an author, I
wanted to invite him to say something.

Gorry: Hi. I'm not sure I have much to add. What Mirja said seemed to capture
most of what I understood. I think there has been useful feedback in the IESG
process but I Don't get Lars's comment, really, because I think you can
construct an application design and move it between systems. You can't move the
cord but the design of the application and the calls you make would be the same
in both cases. That seems to be the target of interoperability to me.

Erik K: The logic and the control flow don't need to get completely rewritten.

Warren: I kind of agree. The title of the document is TAPS Interface, and it
describes a generic interface. It's not that you wouldn't have to make any
changes moving between Windows and Mac. I think it's clear enough from the
document description and abstract that it is an abstraction. It seems fine to
me.

Zahed: Thanks Roman for pointing out that Gorry was on the call, and thanks
Gorry for your comment. I think we've had enough discussion for now, and let's
resolve these Discusses in emails. Where does this go, in IESG Evaluation?

Cindy: Right, you can put this in Revised I-D Needed or AD Followup.

Zahed: Revised I-D Needed.

 o draft-ietf-taps-arch-18  - IETF stream
   An Architecture for Transport Services (Proposed Standard)
   Token: Zaheduzzaman Sarker

Cindy: This document also has a Discuss; would you like to discuss this today?

Zahed: Éric wants to discuss it, I think.

Éric V: Exactly. I like the document and just for full disclosure, I vaguely
worked on the TAPS project five or six years ago. For me, it should be
informational. At some point it was in BCP 14 vocabulary describing
requirements. My point is that it should either be informational, and then I'm
fully fine, or they're requirements, and it stays Standards track. Right now
it's in the middle. There is no architectural document defined in the charter,
but it's not forbidden.

Murray: One of the points the authors make in favor of PS is they want to refer
to this from standards documents that will be PS and they don't want to go
straight into downref territory. I understand why they're thinking that way but
I'm not sure that's a valid argument for requiring this to be a PS. It's
perfectly fine to make this Informational and point to the architecture over
there. A PS is going to be able to stand on its own and you don't need that to
be a PS. I think this is fine as Informational too.

Éric V: Like many architecture documents.

Zahed: I think there was some discussion on the mailing list. If I remember it
correctly, the TAPS WG has discussed thoroughly about this being a PS or
Informational and initially I had the same questions. If you look in the email
Brian was talking about this. For me, I don't want to make a biased decision
here so let's have a discussion. Someone else also said the title might not be
that important; maybe we keep the title but emphasize the requirements in the
abstract. I don't know if that helps here or if you are saying no, PS is not
the way forward.

Éric V: It's not the hill I will die on, but I see other people share my point
of view so this might be a signal. Like Murray said, we have dozens of
documents like this. I'm concerned about the precedent.

Zahed: I heard two things, one is that if we say architectural requirements are
fine as PS, and then Murray says it can be informational and downref-ed from
other documents. What would solve both?

Murray: I'm mostly here for the discussion. I didn't have a strong enough
feeling to raise it to my own Discuss. If I have a preference, I'd say just
make it informational.  A downref is just a procedure step, it's not a problem.
I could live with either one.

Éric V: I'd also prefer Informational. Informational doesn't mean it's not a
good document. It just means you can implement the API without reading the
architecture.

Zahed: I don't want to make a decision right now but I'll pass these comments
to the chairs and WG and see if we can decide on something. I'm more in favor
of a title change and more clear description of the document for now.

Mirja: Can I ask one more question? We had a long discussion about this because
it's not clear what the right intended status is. I don't think people had a
clear opinion about this at the end but we had to make a decision. I understand
if people speak up in favor of one or the other but what I don't understand is
if this is a few people on the IESG or the view of the general IESG?

Zahed: Sounds like we need to have a poll?

Lars: I'm very clear on the side that none of these should be Proposed
Standard, they should all be Informational. But that's just me, we don't have
consensus.

Roman: I already put in my ballot I thought this smelled more like
Informational.

Zahed: I think Paul also supported Éric V's Discuss.

Éric V: At some point in time you said the same thing also.

Zahed: That was when I was chair. I got convinced this should be PS. I was
questioning this heavily, you can look at the transcript of the session. Here
we have five ADs who think this should be Informational but none of them have
put on a Discuss so I'm confused what to do.

Éric V: I would suggest you go back to the WG and say that not the majority,
but the leading outcome of the telechat was to go Informational. You can put
some sugar on it, it's not like it's a second class document.

Zahed: No, it's not about the class, it's about the intention here on what you
want to achieve with this document. I can share that with the WG and see if we
can resolve something. The options are basically Informational and keep it as
is, or change the language.

Éric V: I would be so happy to ballot a Yes, then.

Zahed: Okay. So, Cindy, this will be Revised ID Needed.

 o draft-ietf-rats-eat-21  - IETF stream
   The Entity Attestation Token (EAT) (Proposed Standard)
   Token: Roman Danyliw

Cindy: There are a few Discusses on this; would you like to discuss those today?

Roman: I would not. I very much appreciate the feedback and everyone leaning in
at the last moment to get enough ballots, assuming we can resolve the
Discusses. The Discusses were good things and we'll get them adjudicated. Can
you put this in Revised I-D Needed?

 o draft-ietf-privacypass-auth-scheme-12  - IETF stream
   The Privacy Pass HTTP Authentication Scheme (Proposed Standard)
   Token: Paul Wouters

Cindy: There are a few Discusses on this; would you like to discuss those today?

Paul: Put it in Revised I-D Needed, please. If someone wants to discuss, let me
know, but we don't need to.

 o draft-ietf-uuidrev-rfc4122bis-11  - IETF stream
   Universally Unique IDentifiers (UUID) (Proposed Standard)
   Token: Murray Kucherawy

Cindy: There are a few Discusses on this; would you like to discuss those today?

Murray: Not necessary unless they want to. AD Followup, please.

Rob: Quickly, about my Discuss. It's quite a soft Discuss but we've added some
new UUIDs being defined in here. I have a question about whether we should be
trying to deprecate the old ones or not. Maybe that needs to come from the
authors; I don't know if anyone here has a feeling for that.

Murray: I don't. I think it's a perfectly good question; I'll see what the
authors have to say.

Rob: Okay, thanks.

Paul: They did respond to me this morning about my question and they seemed
positive.

Murray: they['re very responsive and receptive to feedback so I think this will
clear up quickly.

Cindy: Thanks; we'll put this in AD Followup.

 o draft-ietf-dnsop-caching-resolution-failures-07  - IETF stream
   Negative Caching of DNS Resolution Failures (Proposed Standard)
   Token: Warren Kumari

Cindy: There are no Discusses, so unless there's an objection, this one is
approved. Is this ready to go as-is or do you need to do any checks or another
revision?

Warren: I guess I should double check since I think there were some comments.
Can anyone tell me if they had important comments?

Éric V: There are a few small things like writing the IPv6 addresses the wrong
way in uppercase so please fix that.

Rob: Mine are trivial as well.

Warren: Let's do AD Followup.

Cindy: We'll put this in Approved, Announcement to be Sent, AD Followup and you
can let us know when that's ready to go.

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-taps-impl-16  - IETF stream
   Implementing Interfaces to Transport Services (Informational)
   Token: Zaheduzzaman Sarker

Cindy: There was a Discuss here earlier today but it looks like that's cleared,
so there are no open Discusses and unless there's an objection now this is
approved. Is this ready to go as-is or would you like to do some followup?

Zahed: I'll put it in AD Followup because I think there will be a revision
coming.

Paul: I'll try to review it today as well because I didn't get to it.

 o draft-ietf-core-target-attr-05  - IETF stream
   CoRE Target Attributes Registry (Informational)
   Token: Robert Wilton

Cindy: We have no Discusses, so unless there's an objection this is approved.

Rob: Before we do that, I think there are a couple of points here it would be
useful to discuss. Roman has raised a question about whether it would be better
to do this as PS rather than Informational. How strongly do you feel about
that, Roman?

Roman: I was under the impression that it's a little odd to update a PS with an
Informational. I didn't drill into the procedural RFCs to suss that out. It
seems like all the things that are going to get serviced out of this registry
are PS type things. Talk to me the other way, what was the thinking from the WG
for making it Informational?

Rob: I don't know.

Francesca: I can answer that. The rationale was just that this is a document
defining an IANA registry and it doesn't need to be a PS. It just gives a
reference for the registry and that's it. The WG thought they didn't need to go
for PS; basically the opposite of what we talked about with Zahed.

Roman: But it does one more thing, it does an update. That's what triggered it
for me.

Murray: I think it's incorrect that it updates 9176. IT changes a registry that
was created by 9176 but it doesn't change anything about 9176. You could just
remove the updates and I think that would satisfy Roman, right?

Roman: This is just the usual thing that we don't know what updates means.

Rob: Having a reference to this is quite nice.

Murray: Absolutely include the reference, but you don't have to say this
updates it.

Rob: If we did move this to PS, does that mean we'd have to do a Last Call
again?

Several: Yes.

Rob: I have to say I've been slow with this so I feel a bit guilty, this is
Francesca's.

Francesca: Don't feel guilty, it's my fault.

Rob: I propose just letting this go as Informational and I think the updates is
fine, because it's not updating the normative language or changing that
specification, just updating the reference to the registry and that can be made
quite clear in the updates.

Roman: I'm not going to die on that hill. You probably want some more language
about how it updates in what specific way. I think the compromise might just be
dropping the updates.

Rob: Okay. I'll discuss that with Francesca and the authors. The other comment,
Paul, you'd mentioned about making specification required; that probably makes
sense, but i'll follow up with the authors to find out if they have strong
objections to that. Thank you. I guess, can this be put into AD Followup?

Cindy: Yes, this can be Approved, Announcement to be Sent, AD Followup and you
can let us know when it's ready.

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

 NONE

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

Roman: There's a nice cadence for those who are interested in tech talks the
IAB is doing. Last week we had a great talk on censorship from Proton. Upcoming
on Sept 27 will be a talk on satellite communications; please attend, I find
them really interesting. There are several IAB statements in flight, one on
client side scanning and there's also one on attestation in the open Internet.
There is a workshop being planned around barriers to Internet access and
services with the clever name of BIAS. There's also some long range planning
happening with engagement on the IGF and an outstanding liaison discussion for
ETSI CYBER.

6. Management issues

6.1 [IANA #1279159] Designated experts for RFC 9445 (RADIUS Extensions for
DHCP-Configured Services) (IANA)

Cindy: This is here to assign the action item to Rob.

6.2 [IANA #1277796] Designated experts for RFC 9457 on Problem Details for HTTP
APIs

Cindy: Murray has identified Mark Nottingham and Sanjay Dalal as experts for
this registry. Is there any objection to these folks? Hearing none, they are
approved and we will get an official note sent to IANA.

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

6.3 Executive Session