Skip to main content

Narrative Minutes interim-2022-iesg-15 2022-06-30 14:00
narrative-minutes-interim-2022-iesg-15-202206301400-00

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

narrative-minutes-interim-2022-iesg-15-202206301400-00
INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2022-06-30 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
Roman Danyliw (CERT/SEI) / Security Area
Martin Duke (Google) / Transport Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Erik Kline (Aalyria Technologies) / Internet Area
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Applications and Real-Time Area
Alvaro Retana (Futurewei Technologies) / Routing Area
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
---------------------------------
Jay Daley / IETF Executive Director
Lars Eggert (NetApp) / IETF Chair, General Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair

OBSERVERS
---------------------------------
Stuart Card
Lucas Pardue
Lee-Berkeley Shaw
Adam Wiethuechter
Shuai Zhao

1.2 Bash the agenda

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

Francesca: I'd like to add an item to the executive session to discuss a couple
of documents for my upcoming leave.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes of the June 16 teleconference
being approved? I'm hearing no objection so we will get those posted in the
public archive. I saw final narrative minutes from June 16; any objection to
those being approved? I'm hearing no objection there either. We also have the
IETF 114 BOF coordination call minutes to approve; any objection to approving
those? Okay, not hearing an objection there either. Thanks.

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 9260 (Stream Control
       Transmission Protocol) [IANA #1232030].

Amy: This is provisionally done, as we have an action item later in the agenda
to approve experts.

     o Murray Kucherawy to find designated experts for RFC 9248
       (Interoperability Profile for Relay User Equipment) [IANA #1232225].

Amy: Murray is not with us today.

     o Francesca Palombini to find designated experts for RFC 9209 (The
       Proxy-Status HTTP Response Header Field) [IANA #1232222].

Amy: This is provisionally done, as we have an action item later in the agenda
to approve experts.

     o Francesca Palombini to find designated experts for RFC 9246 (URI
       Signing for Content Delivery Network Interconnection (CDNI))[IANA
       #1232482]

Amy: This is brand new for Francesca.

   * 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 July 2022.

This is on hold.

     o Lars Eggert to facilitate an update of the document shepherd writeup
       form.
     o Lars Eggert to ask the Tools Team to push the global whitelist out
       to WG mailing lists again.
     o Murray Kucherawy to draft text for an IESG statement providing
       guidance about patch documents.
     o Lars Eggert to follow-up on the management of the IETF non-wg
       mailing lists.
     o Lars Eggert to draft email about RFC8989 Path 1 for NomCom
       eligibility.

Neither Lars nor Murray was on the call so these will all be marked in progress
for them.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-lisp-sec-27  - IETF stream
   LISP-Security (LISP-SEC) (Proposed Standard)
   Token: Alvaro Retana
   Was deferred by Roman Danyliw on 2022-06-15

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

Alvaro: No, I don't think so. We're making progress on Murray's and I think at
least on email we addressed Roman's. Paul, I saw yours a few minutes ago so
we'll deal with that hopefully soon. We're going to need a Revised ID for this
one.

Amy: This will go into IESG Evaluation, Revised ID Needed.

 o draft-ietf-tcpm-yang-tcp-07  - IETF stream
   A YANG Model for Transmission Control Protocol (TCP) Configuration
   and State (Proposed Standard)
   Token: Martin Duke

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

Martin: I don't think so. It looks like there are some good comments that
should be addressed and then for the most part some clarifying questions in the
Discusses, with a couple of exceptions. This is definitely a Revised ID Needed.
The authors have been a little unresponsive lately so they might take a little
while to respond, but that's the correct state.

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

 o draft-ietf-ippm-ioam-flags-09  - IETF stream
   In-situ OAM Loopback and Active Flags (Proposed Standard)
   Token: Martin Duke

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

Martin: Again, some clarifying issues and some small things. Briefly on
Andrew's review, you mentioned normative words for 2119 words in section 8, but
I believe that section is the security considerations and it is referencing
some normative requirements in section 4.

Andrew: When I read this and went through section 8, it kind of sits above and
it's like here are all of these issues, and then it gets to this section and
says these guys should do this. When I looked at everything above it and the
problems they could create, that just worried me.

John: Two cents to drop in here: I agree that if they've already normatively
said it somewhere else they shouldn't say it again. That's bad practice. Maybe
it would fix Andrew's problem if they said "as per the requirements in section
so and so."

Martin: Right. If you go down a little further in the security considerations
it starts referencing specific requirements in section 7 and section 4. We
don't have to do this in real time.

Andrew: Let's take this offline. I did see the references to section 4; what I
probably should have done is checked exactly how normative the language is in
section 4 and tried to cross reference.

Martin: I appreciate that. There are some SHOULDs in there where maybe you want
MUSTs. One of the issues is that some of these security requirements really
depend on topology. I happen to have gotten involved in this discussion a lot.
In this one there are different security considerations if you're in an overlay
or not in an overlay for reasons I think are obvious. Hopefully the SHOULDs are
qualified properly; I'll have to look at it again to be sure. Let's have an
offline thread about that.

Andrew: Sure thing.

Martin: Other than that, I think the other stuff looks good to me and we'll
wait for the authors to reply. This is definitely Revised ID Needed.

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

 o draft-ietf-ippm-ioam-direct-export-09  - IETF stream
   In-situ OAM Direct Exporting (Proposed Standard)
   Token: Martin Duke

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

Martin: I think most of this is fine. The one worthy discussion is Roman's
Discuss, which is basically a substantial change to the design to say the DEX
cannot exit the domain. It's a little subtle but it's true that putting IOAM
bits in a packet is absolutely restricted to a domain, but I'm fairly certain
they have a use case in mind where you have some storage outside the domain
where this stuff is going.

Roman: Maybe I don't understand all the uses of the IOAM. I was under the
impression that this is a set of primitives to help you do telemetry and
analysis of what's happening on your network to include potentially tagging
production traffic to get a better sense of it.

Martin: There are multiple encapsulations. One example would be to put an IPv6
option that has these IOAM fields in it and gives you things that you can
increment, or in this case, then hoover that up and send it somewhere. Not the
actual user data, not the packet itself but the stuff the network attached to
the packet.

Roman: I think that's a little bit of my finesse back to the earlier statement.
If this is an arbitrary mechanism, which in my mind it is but maybe I need to
re-read the architecture document, that you could label real traffic with this
to extract that telemetry. What prevents it from tagging packets that aren't
just synthetic in nature that would include user data? Back to the idea that if
you follow that logic, you have an arbitrary mechanism to tag arbitrary packets
that will be exploited outside of the IOAM domain.

Martin: To back up, the intent of IOAM is in fact to take user packets and
annotate them, so that is 100% the intent of this architecture. But the fields
themselves that are attached to that packet and then those are the fields that
are manipulated by the routers. Those are also the fields that have data that
are then exported. You're not taking user bits and sending them out into the
world. What you are doing is sending some sort of telemetry about those like
timestamps and sending it out into the world without necessarily an identifier
of what the packet is. I'm not here to say that this was written in a
completely airtight way so that you're not going to leak something important,
and that's something we can work on a little bit. The first order of question
here is this question of can we export outside the domain or not. I don't know
how satisfied you are after this discussion.

Roman: Listen, I'm trying to be eminently practical. I think this is about
bounding it. It's having a conversation on how content data is being protected
should it be leaving. It should be a discussion on how traffic analysis is
being mitigated and it's probably some discussion about identifiers. Let's
assume this is in IOAM, I think it's fair to say that there are probably a
bunch of other instances where log data, and i'm just going to genericize this
by saying log data, is getting shipped outside the administrative domain.
Typically when we would do that we would caveat what's in there or at least
caution what we're losing in that trait.

Martin: I know there is language in there about transport security and so on.
I'm making a lot of assumptions here but presumably the same entity is
operating this storage so you've got a secure communication between the
operator's domain and some sort of cloud storage, or whatever, over being
secured with TLS. TLS as you're well aware has all these things that frustrate
traffic analysis of what's in there. So that doesn't strike me as obviously
insecure to do this.

Roman: The traffic analysis comment I made was not about the pipe that's
ex-filtering this to someplace else. I think this is such a general purpose
mechanism that the specifics are hard. I was envisioning a circumstance where
the metadata about the telemetry, while content free, still informs traffic
analysis. Because again, it's such a  general purpose primitive. I think almost
everything and anything is in scope.

Martin: I certainly don't object to some additional language that essentially
says here be dragons. I'm sure we can agree on that. It sounds like given that
sort of language you're okay with having this export outside the domain. That
would be the big change to what the WG wanted, if you were going to insist on
inside the domain stuff.

Éric V: On the other hand, IPFIX also allows export of plain packets. I'm not
sure what they say there.

Martin: I think we're converging here. This is definitely a Revised ID needed.
Why don't I follow up in your email thread to summarize the discussion, Roman,
and we can iterate with the authors from there?

Roman: My last point is, if in fact we are letting this go outside the domain,
we probably additionally need a whole bunch of language because every document
that comes out says don't worry, all IOAM data is inside the domain and that's
the basis of the security model. If we want to do something different here, we
have to finesse for this new option type to say well, in fact, there are
different types of IOAM data; some is leaking, some is not, and the blanket
statement of 'nothing goes out' is no longer true.

Martin: Okay, I think that's completely reasonable. So, Revised ID Needed, Amy,
and thank you for the comments.

 o draft-ietf-drip-rid-29  - IETF stream
   DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS
   RID) (Proposed Standard)
   Token: Éric Vyncke

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

Éric V: Maybe not discuss, but at least get some more comments. Thank you
everyone for the review. I'm a little ashamed, John, to be honest; I should
have spotted that RECOMMENDED in my AD review. Next time that will be on my
to-do list. By the way, the authors are on the call. Paul, the easiest to
address is for the hhit.arpa zone to become unreachable. Isn't it the same for
the root zones?

Paul: Yes, but if the root zone is not available, I don't think my drone's
either going to go down or get shut down, or can go fly where it's not supposed
to fly. I think there are some different implications here about what happens
when that zone is down. Plus we have a lot of root servers, so the fact is that
the root can't really go down. If this is a critical infrastructure, then it
needs to be set up as critical infrastructure.

Warren: The root zone, there are more than a thousand servers serving it, there
is a lot of stuff caching it, and a lot of people have it locally as well. To
me, a fair bit of this feels like look, here's a big database thing, let's just
stuff everything into the DNS and move our costs onto someone else. Yes, the
DNS scales well, but depending on the use case this could be a lot of extra
traffic for .arpa or whoever runs this and that could be a concern. There also
seems to be a fair bit of hand waving around, there should be a registry that
will do stuff but without a lot of discussion on how that would actually
happen. I'm assuming everyone is familiar with 'we believe in rough consensus
and running code, let's just stick in the DNS' type views.

Éric V: So basically it goes beyond Paul's concern about the security in the
sense of availability, and goes into operational and business issues; right?

Warren: Yes, it goes into that. It might all be perfectly fine but depending on
how it gets used and where it gets queried from it could be extra load on the
DNS. There are also some interesting things about how well the reverse so and
stuff generally works for large v6 addresses. Then there's also a fair bit of
DNSSEC will handle this, there's trust because of DNSSEC. That didn't actually
seem to be tied to anything, it seemed to be that DNSSEC will provide a secure
set of trust for this without any discussion about where the root of the trust
is or what happens there.

Paul: That also wasn't clear to me. There is sort of an alternative, like oh
well we should have something in case we're offline and can't reach the DNS. if
that solution is good enough one might wonder what the DNS solution actually
has.

Warren: Erik K also mentioned there is some stuff about registries, and I didnt
read the registries document. If the registries document covers a lot of this,
that should be better referenced. To me it's unclear why it's shoveling all of
this into the DNS instead of a well formatted API which is specifically
designed to handle this. I will also mention I was distracted by other things
so possibly I missed something.

Éric V: No no, that is perfectly fine. Thank you. The major concern of mine is
this reliance on DNS. If you don't mind, I would love to get Stuart and Adam,
the authors on the call, if you want to say a few things or ask a question for
one minute maximum or something? [pause] I guess no. Revised ID Needed then,
obviously.

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

 o draft-ietf-quic-bit-grease-04  - IETF stream
   Greasing the QUIC Bit (Proposed Standard)
   Token: Zaheduzzaman Sarker

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

Zahed: I think we have time. Let's have a quick discussion. We have two parts
here; one is a confusion about unpredictable value. The question was how
unpredictable could 0 or 1 be? My understanding is that we have a fixed value
for this bit and the unpredictability here is don't predict it will always be
that fixed value; it could just be any random value between 0 and 1, or 0 or 1.

Andrew: My simple point here is that if it said it could be either, I would be
okay with that. When you start talking about unpredictable 0 and 1, I don't
know how to interpret that if I want to implement it.

Zahed: In the beginning of the document it says it's a fixed value and I think
my interpretation of unpredictability was other than that fixed value. But we
have the author Lucas on the call; do you want to say something on that?

Lucas: Thanks for the invitation. I don't want to put words in the mouth of the
author. I was the document shepherd for this so I was familiar with it. I do
remember reading this text and thinking about it a bit but then saying actually
I do understand this. Since it's come up a couple of times since then, I think
we should just try and find some better wording that communicates the intent
without any possibility of confusion. We'll take that on board and find some
way. Just to explain it, it's the fact that the expectation is that value is 1
unless you indicate with this extension that you can receive values that aren't
1. There are some use cases for this where you might be running a UDP server
that can handle QUIC and/or RTP traffic, say, and that bit is needed in order
to demultiplex traffic. If you don't need that capability, you can indicate it.
Yes, the value is either 1 or the other, but you're sending QUIC packets so do
you send 0 all the time, some of the time, do you send it on a holistic or
systematic way across some proportion of all? What you pick is an
implementation choice so my interpretation is that we don't want to say too
much here because we want it to be unpredictable so that it's greased, so
people who aren't part of the discussion at the endpoints don't start to
presume there is any special meaning in that bit.

Andrew: If you wrote something in there to the effect that this is
implementation specific, it would just be a lot less confusing than referring
to unpredictable. I think this is more a wording semantics just to make it
clearer what it actually means rather than any serious problem. I just found
that wording to be a little confusing. Maybe I'm just being dense.

Lucas: I'll take that on board. I'm sure the author Martin can find an
editorial change that can unblock us. I think it's a fair comment to have made.

Zahed: I think that's the resolution. Maybe some better wording would help to
express the intention here. I'm actually more interested in Rob's point. I
don't know if we can discuss it at length here. Rob, you have this discussion
about manageability draft and this one and questioning what we're trying to
achieve here. My interpretation of this when I read the introduction is that it
says we don't want you to predict anything. Unpredictable behavior to secure
the future of using that bit. I think you have some other concerns about
operations so I would like to know if you have anything to say other than what
you wrote. Otherwise we can discuss that with the authors.

Rob: To clarify, I'm not saying QUIC shouldn't do this. What i'm saying is that
when I read this sentence that says 'The purpose of having a fixed value is to
allow QUIC to be efficiently distinguished from other protocols;' that seemed
to contradict what's already in the manageability spec, which says you can't do
that or you can't reliably do that. It was questioning whether that sentence
itself was correct to say that in this draft. That was the first aspect. Then I
was just trying to understand whether the expectation is that people should be
able to identify on the wire QUIC packets generally or whether they shouldn't
be able to. It just felt like these two documents in combination it wasn't
clear in my head exactly what the general expectation is, either now in QUIC v1
or going forward. That was the comment from that side. My secocon comment was
that if we are changing it from you could reasonably identify QUIC traffic to
now they can't, then it mentions in the security considerations that has impact
on security but it could also have other impacts in terms of how the network
handles that traffic. It might be handling QUIC traffic differently, filtering
it, not filtering it, giving it some priority or something, and if it can't
identify that quic traffic, then it will behave differently. That was the
suggestion for some operational considerations or something in the security
section just to make that point quite clear. Does that help clarify?

Zahed: Yes, it does. The only thing I can say is that in my interpretation or
in my head that's been happening at the end point, not at the observer. But you
have other points on the operations so let's see what the authors would like to
respond to that one. Lucas, I don't know if you want to say something about
those things.

Lucas: I don't have anything to add. It is intended for endpoint demultiplex
but I do see Rob's point that these kinds of things kind of seem a bit counter.
We should just add something that addresses the network operators that isn't
just about security but about operations.

Martin: The distinction here really is about endpoint coordination, so when the
endpoint chooses to always set the bit to 1, it's essentially attempting to
cooperate with infrastructure it's aware of that's trying to demultiplex
between QUIC and other UDP traffic or whatever port you're on. It's not in
general intended for just random servers out there on the internet to be able
to sync with this traffic and the manageability draft is pretty clear that you
should not use that bit to identify quic. So the QUIC bit in v1 is an optional
signal for the endpoint to use to allow certain bits of infrastructure to
demultiplex.

Rob: Okay. I think my suggestions would be twofold. One, clarify the sentence
that says "The purpose of having a fixed value is to allow QUIC to be
efficiently distinguished from other protocols;" to clarify under what
circumstances that applies. Two is to have this operational considerations
section which covers what you've discussed there, Martin, or some text to that
effect. I think that would resolve my concerns. That clarity is helpful.

Zahed: all these comments are very valid and important and thanks for doing it
and thanks for making it more read and reviewed for this telechat. We'll need
Revised ID for this.

Rob: Thanks for the conversation.

Amy: This will be Revised ID Needed, thanks.

2.1.2 Returning items

 o draft-ietf-lamps-cmp-updates-23  - IETF stream
   Certificate Management Protocol (CMP) Updates (Proposed Standard)
   Token: Roman Danyliw

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

Roman: I wanted to repeat my gratitude and thank you for everyone re-reviewing
the document. I know there are some concerns about the style in which it was
presented and that was an issue for some folks. After discussion, I appreciate
everyone's flexibility to change some of those Abstains to No Objection. I
believe there are some comments that are not in the draft; I would like to
double check. Can we put this in AD Followup?

Amy: We sure can. This will go into Approved, Announcement to be Sent, AD
Followup and you can let us know when it's ready to go.

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-drip-arch-24 (Has RFC Editor Note)  - IETF stream
   Drone Remote Identification Protocol (DRIP) Architecture
   (Informational)
   Token: Éric Vyncke

Amy: I have a Discuss here; do we need to discuss that today?

Éric V: If Roman wants. I don't think so. Roman, you put a couple of comments
in the slack that I will repeat here. Maybe the document should be smaller and
not go into too many details, and stay generic. I think that's a fair thing. IF
we go in this path with the authors I will send it back to the WG for WG Last
Call. That's all. Thank you again, Roman and the others, for reviewing this
document. Revised ID Needed for sure.

Amy: Great, this will stay in IESG Evaluation with Revised ID 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-santesson-svt-00
   IETF conflict review for draft-santesson-svt
     draft-santesson-svt-08
     Signature Validation Token (ISE: Informational)
   Token: Roman Danyliw

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

Roman: We don't. For everyone else's benefit, Paul and I are talking about this
offline. The concern is does anything in this document violate the guidance we
have in published documents? We're going to go back and forth to make sure that
is not the case. To the idea of it going to LAMPS, as I previously noted in the
ballot, sure it could have but what we needed is positive interest. We've had
multiple rounds where we tried to poll whether there was interest in doing the
work and we did not have that. What we're going to do is check there's no
guidance in this SVT document that conflicts with published RFCs. Thanks.

Amy: Okay, so we'll just leave this in IESG Evaluation and we'll wait for
instructions.

3.4.2 Returning items

 NONE

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

 o Transfer dIGital cREdentialS Securely (tigress)

Amy: I have no blocking comments so it looks like this is approved for external
review. However, this just went into internal review a couple of days ago so we
can either start the external review tomorrow to run concurrently with the end
of the internal review and get it back on the telechat for July 14.

Roman: Yes please.

Amy: Okay. We could wait until Tuesday but that crunches the time for external
review. If running it concurrently is okay, that is a good way to go and we can
send the external review announcement tomorrow.

Roman: I'd like to make a couple of comments about the approach here. There are
a couple of editorial things and clarifying things that I believe I caught in
one of the versions between 2 and 5. Two of the biggest things I wanted to
respond to in the group, and we can continue to iterate. There was some
feedback that it looks like there are some really specific things in the
charter, shouldn't we leave it for later for the WG to figure out? My response
to that is generically we can take a couple of approaches. If in fact the bof
process is narrowing towards what the solution space should look like, I don't
see a reason why we can't have that in the charter and we don't need to leave
that open. Ifn this particular case we went through the bof and teed up on the
mailing list that we would like the solution to have the following properties
and yes, it's specific. But it appeared that we had consensus for it to have
these properties. I'd love to hear if we think that's a problem that we've
already decided what the solution space looks like and put it in the charter.

Zahed: Let me respond to that because I had those kinds of observations. I
think in some cases we need a bof to figure out the problem space and what kind
of solution space you would like to have, but I really don't see the bofs as a
requirement consensus. Bof is about a problem space and whether we have the
idea and the energy to make this problem go away by having some solutions.
Here, what I think I was really focusing on was if I have a set of requirements
given to me from day 1 by a bof or some discussion, can I call it WG consensus
on that? Another thing was then you have a certain stake in the solution and I
don't know if it prefers some solution or if it's really not an issue. I
thought it might be good because you have really good goals there. Let's take
the discussions on the requirements on the wG and work from there. But if
you're saying the bof was very unanimously agreed on the requirements, that's a
good thing, but I don't see the need for it to be in the charter. That's my
point.

Roman: I agree there is a judgment call here when you're mixing this idea of
the requirements for how the solution is made vs. a different set of
requirements that I would say are table stakes, which is there are a lot of
engineering decisions to make but the going in position is this. I feel like
the ones in that bolded list are really of that latter and why I feel confident
is that while we have read the charter a bunch of items, those table stakes
requirements were in the first thing, the first version of that charter was
brought into the bof and there wasn't pushback. There was just clarification of
what they meant by that. That's in a sense how the whole conversation went
through the bof adn on the mailing list. I think it's good we've iterated on it
and any solution we figure out needs to have the following. I think there are
still a lot of design choices to make.

Zahed: That's fine, at the end you are making a call on what to put in the
charter. You're confident the process has been followed. Maybe a couple of
sentences to clarify this isn't the final requirement we're talking about but
this is something that is specifics.

Roman: If I could recast that, it's that the WG needs to figure out additional
requirements above and beyond but this is the mid-set.

Zahed: Right.

Roman: Yeah, I can put some weasel words in there. If it's okay, I'd still like
to launch this to the community and we continue to iterate on this in the final
version.

Zahed: No problem on that, I trust you to do the right thing. I didn't put a
Discuss on it.

Roman: That's good feedback. The other piece is there was some feedback around
the requirements about what does "round trip" really mean and what does "opaque
data" mean. We can get additional language in there to clean that up as well.
This is the long way of saying I'm acknowledging there is some feedback we will
polish in the next round but I would like to launch so that if there is
community consensus and we can resolve these we can have a WG by 114. Much
appreciated from everyone.

Amy: Okay, we will send the WG review announcement and place it back on the
agenda for July 14.

4.1.2 Proposed for approval

 NONE

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o Deterministic Networking (detnet)

Amy: I have no blocking comments. Is this a small enough change that we can
just recharter, or does this require an external review?

John: I was kind of on the fence about that so I didn't click the external
review button. I would value input from you all. On the one hand, it's  a five
word charter change. On The other hand, it's adding a potentially fairly large
additional scope of work to the group.

Martin: I didn't ballot on this because I was confused. You remarked that you
fixed the layer 3 forwarding thing, but I'm looking at the text and it's still
there.

John: You pointed out that explicitly excluded modifications, which you're
right that was contradictory, and we changed it to generally excludes. The
actual case that's driving this is Toerless has a particular QN graph that he
wants to do somewhere. Basically TSV didn't want it and suggested that detnet
should consider taking it. Detnet was willing to consider it but they had a
charter that wouldn't permit them to take it. There were quite a few rounds
back and forth just to make sure everybody really understood that this was
taking something from a scope that would normally be owned by TSV and putting
it into DETNET. Everyone seemed good with it, hence this update. The
"Generally" is meant to express that we're not trying to poach this stuff as a
rule and we would prefer that work be honed in whatever is the most obvious and
logical WG for it. However, if there's consensus between the WGs that it should
go to DETNET, okay.

Zahed: I was questioning how you coordinate those things. I'm still not sure
now.

John: I did reply to Rob during the meeting. He had raised something a little
bit similar, that we need more words around how precisely  that coordination
will take place. I'm not going to dig in my heels and say we won't bend those
words but my own feeling is essentially when we have WGs who are doing their
jobs well, they just need to be asked to please coordinate this. If we don't
have WGs that are doing their jobs well, I'm not sure how much additional
process text is going to fix that for us anyway. I could be talked into adding
some more paragraphs.

Martin: I'm not going to die on this hill but I think it would be clearer for
third parties if instead of just saying that in the data plane section that
layer 3 forwarding was in scope, you'd maybe just say what you just said, which
is that due to prior agreement with TSVWG, layer 3 forwarding under these
particular constraints is in scope, or something to that effect. One part of
this says it's not in scope and another part says yes it is, so just writing
that down would be more clear.

John: I'm not sure the main body of the charter is the right place to do it.
It's almost an appendix that this is a particular work text. If you do have a
specific idea for text, send that over, and if not I'll try to propose
something.

Martin: I'll do a comment. One way would be just to not mention the data plane
section and just have a principle that you won't do this unless coordinated,
and then know in your heads that you're already coordinated so there's an
exception there. The second one is to actually write down the exception because
it is. As it reads, I have no idea if it's in scope or not. On some level it's
fine but your successor might have to deal with this and have no idea.

John: We'll leave this open so you can leave a comment. I still would not mind
input about whether we should send this for external review once we've closed
on it.

Rob: My view is that you don't need to. You've coordinated, you're doing the
right thing, you're updating the charter to make clear that coordination has
happened, and I personally don't think you need external review. The groups who
are interested in this work have already discussed it.

Roman: I'm with Rob. This is coordinated, it's good to go.

Éric V: It's a go for me as well.

John: Okay, thanks for the input on that. This will help the groups make
progress at 114.

Amy: If I've heard correctly it sounds like there's no objection to just making
changes to the charter, so we will send a WG action recharter announcement
pending some text.

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Qin: I can speak up since Lars and Mirja aren't here. The first thing is the
IAB comments on the SAC113 proposal. The IAB is not happy with IANA taking
action to assign a string, although it's not the first time for IANA to take
such an action. The IAB has written a paragraph to suggest that IANA find an
expert to assign the string and Harald will pass this paragraph to the board
for consideration. The second thing is the ICANN board liaison appointment. The
IAB decided to reappoint Harald and the next step is to get community feedback.
The third thing is that the TIGRESS IAB review has been assigned to Mallory.
The IAB also discussed a possible response to the US government RFI relating to
PPM. The IAB agreed to pick up the response from the PPM chairs. They will look
to approve this response at the July 6 meeting. The last thing is the RSWG
appointment; I sent a note to the iesg-only mailing list about the RSWG chair
appointment to discuss the recommendation from the interview team. The IAB
believes two chairs should appear together as a team complementary to each
other. [More on this topic will be covered in executive session.]

6. Management issues

6.1 [IANA #1232030] Designated experts for RFC 9260 (Stream Control
Transmission Protocol) (Martin Duke)

Amy: Martin has identified Michael Tuexen and Randall Stewart as designated
experts for this RFC. Is there any objection to appointing them? I'm hearing no
objection, so we will get the official note to IANA.

6.2 [IANA #1232482] Designated experts for RFC 9246 (URI Signing for Content
Delivery Network Interconnection (CDNI)) (IANA)

Amy: This is a new action item for Francesca.

6.3 IETF 114 Agenda (Liz Flynn)

The IETF 114 agenda was reviewed and several session swaps discussed. There are
three empty slots remaining and the IESG did not decide to allocate those slots
today.

6.4 IESG Telechat Dates Between IETF 114 and IETF 115 (Secretariat)

Amy: I really only found one possible variation. The variation is back-to-back
telechats in October, so you can either have six or seven formal telechats
before IETF 115. To get to seven you would have two back-to-backs on October 20
and 27.

Éric V: Let's do two back-to-back. We can always change one formal to an
informal.

Amy: Okay, we will make it seven and put this in the calendar.

6.5 Updates to draft-ietf-core-problem-details (Francesca Palombini)

Francesca: This is just to make sure that everybody here has seen this email.
I'll try to go quickly. Basically, the IESG reviewed a version of this draft
that was version 5. Version 6 was published as a response to the IESG comments
and then there was a version 7 that was the result of Last Call, late
internationalization directorate review, and the consequent discussion. I
posted the diff between 6 and 7 so that you are aware there was a change
between the version you reviewed and the version that is now in the
datatracker. If you want to update your ballot, I've given the community one
more week until July 6 to send any remaining unresolved objections, so you can
do that. I believe the changes were not substantial enough to need another Last
Call, since the whole discussion was on the Last Call mailing list with cc-ing
the WG mailing list and the ART mailing list. I think the community is aware of
the changes and whoever is interested in participating is participating in the
discussion. More than that, I wanted to ask for an opinion or advice. Basically
this document has the main body and an appendix. The appendix is what the main
discussion on the last call list was about. I've had people saying they don't
think the appendix is normative and they'd rather have the text that is in the
appendix in the main body and other people saying that appendices are
absolutely normative and having the split between the main dco and the appendix
makes it much easier to differentiate the two parts. What is the opinion of the
IESG about appendices being normative?

Rob: My opinion is that all text is normative unless it says otherwise.

[crosstalk, several people agreeing]

Francesca: Okay. I thought so too but I wanted to hear from others as well.

Éric V: On the other hand, it's obviously an appendix and normative, but if you
put normative text it's nicer to have it in the body. [crosstalk]

John: We've approved documents recently with normative appendices so I just
don't see a problem here.

Francesca: Okay. As far as I recall there is no normative text in the appendix
anyway. Some of the discussion got a bit heated so I will work with the authors
to have some text that will work for everyone but it's useful to know that we
consider appendices normative. I think that's it, thank you.

6.6 IESG schedule at IETF 114 (Secretariat)

Amy: The IAB and IESG meeting schedule has been posted on the wiki and put on
the calendars.

6.8 [IANA #1232222] Designated experts for RFC 9209 (Francesca Palombini)

Amy: Francesca added this to approve Mark Nottingham as designated expert for
these registries. Any objection to naming Mark as the expert? Hearing no
objection, we will send an official note to IANA.

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

Éric V: TLS 1.0 and 1.1 on the datatracker has been disabled since yesterday.
That's all.

6.7 Executive Session: RSWG Chair Appointment