Narrative Minutes interim-2023-iesg-25 2023-11-30 15:00
narrative-minutes-interim-2023-iesg-25-202311301500-00

DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT
INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes of the November 30, 2023 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
Dhruv Dhody (Huawei) / IAB Liaison
Martin Duke (Google) / Transport Area
Lars Eggert (Mozilla) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat
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
Éric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area
Paul Wouters (Aiven) /  Security Area

REGRETS
---------------------------------
Roman Danyliw (CERT/SEI) / Security Area

OBSERVERS
---------------------------------
Mike Jones
Frederik Reiter
Greg Wood
Jeffrey Zhang

1. Administrivia
1.2 Bash the agenda

1.3 Approval of the minutes of past telechats

Liz: Does anyone have an objection to the minutes of the October 19, 2023
Teleconference being approved? I'm hearing no objection, so those are approved
and we will place the minutes in the public archives.

Liz: Does anyone have an objection to the minutes of the October 26, 2023
Teleconference being approved? I'm hearing no objection, so those are approved
and we will place the minutes in the public archives.

Liz: The narrative minutes of the October 19, 2023 Teleconference need more
time for review. We'll bring them back to the next telechat for approval.

Liz: Does anyone have an objection to the narrative minutes of the October 26,
2023 Teleconference being approved? I'm hearing no objection, so those are
approved and we will place the minutes in the public archives.

1.4 List of remaining action items from last telechat

  * DESIGNATED EXPERTS NEEDED

     o Roman Danyliw to find designated experts for draft-yee-ssh-iana-
       requirements-03 (Key Exchange Method Names) [IANA #1281831].

Paul: I think I already did this?

Liz: We do have a management item from you…yes, it looks like this is the same
item. I wasn't sure if these were the same. We'll mark this as provisionally
done and take that up later in the agenda.

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

Liz: We'll leave this in progress for Roman.

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

Rob: In progress.

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

Rob: In progress.

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

Francesca: In progress.

   * OPEN ACTION ITEMS

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

Warren: Martin and I talked to Barry and he promised something would be done by
the second week of December. In progress.

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

Andrew: In progress. I spoke to Pete Resnick and I'll send an email by the next
telechat.

     o Lars Eggert and Warren Kumari to 1) draft a revision of RFC 4858,
       2) draft a revised IESG Statement on Document Shepherds (original
       statement October 2010), and 3) update the WG Chairs wiki to point
       to the new IESG Statement.

Lars: In progress.

     o Erik Kline to follow up with authors of draft-ietf-6man-rfc6874bis
       to schedule a conversation about the document.

Erik K: I think we can mark this done. We discussed some things in Prague and I
don't think a further conversation will happen.

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

Francesca: In progress.

     o Lars Eggert to send email to Dan Harkins regarding the PR action.

Lars: I did this before Prague.

     o Martin Duke to send email to Secretariat to create WIT area mailing
       list and to move subscribers from tsv-area over.

Martin: I sent this two minutes ago.

Liz: We'll mark this done.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-spring-mpls-path-segment-20  - IETF stream
   Path Segment Identifier in MPLS Based Segment Routing Network
   (Proposed Standard)
   Token: Jim Guichard

Liz: We have no Discusses, so unless there's an objection now it looks like
this is ready to be approved.

Jim: Put this in AD Followup, please. There were a lot of comments and I want
to double check they were addressed.

Liz: Okay, we'll put this in Announcement to be Sent, AD Followup and you can
let us know when that's ready.

 o draft-ietf-ace-key-groupcomm-17  - IETF stream
   Key Provisioning for Group Communication using ACE (Proposed Standard)
   Token: Paul Wouters

Liz: We have no Discusses, so unless there's an objection now it looks like
this is ready to be approved.

Éric V: Francesca, have you or the other authors replied to the IOT directorate
review?

Francesca: No we haven't, but yes we have seen it and we absolutely plan to.
We've started the responses to the other reviews as well but we haven't sent
them yet. We'll reply to all the reviews. Thank you very much to everyone for
the reviews.

Paul: If you could put this in AD Followup, please.

Liz: This will be Approved, Announcement to be Sent, AD Followup.

 o draft-ietf-bier-evpn-11  - IETF stream
   EVPN BUM Using BIER (Proposed Standard)
   Token: Andrew Alston

Liz: We do have a Discuss here from Andrew which is a placeholder Discuss for
IANA. Do we need to discuss anything here today?

Andrew: I just want to know what the process is from here. I've never held a
Discuss on my own document.

Francesca: You move to Yes and if it's still green, you can change the status
to Approved.

Andrew: Perfect, just wanted to double check I don't need to bring this back to
another telechat.

Liz: We'll leave this in IESG Evaluation for you and you can let us know when
it's ready to go.

 o draft-ietf-opsawg-rfc7125-update-07  - IETF stream
   An Update to the tcpControlBits IP Flow Information Export (IPFIX)
   Information Element (Proposed Standard)
   Token: Robert Wilton

Liz: We have no Discusses, so unless there's an objection now it looks like
this is ready to be approved.

Rob: Thanks everyone for the reviews. Let's put this in AD Followup so I can
check if there are any comments that need to be addressed.

Liz: This will be Approved, Announcement to be Sent, AD Followup.

 o draft-ietf-netconf-over-tls13-03  - IETF stream
   Updates to Using the NETCONF Protocol over Transport Layer
   Security (TLS) with Mutual X.509 Authentication (Proposed
   Standard)
   Token: Robert Wilton

Liz: We do have a Discuss here; do we need to discuss that today?

Rob: I don't think so, unless Paul wants to. I think it just needs the authors
to reply back. Paul?

Paul: No, that sounds good.

Liz: Do you think this is going to require a revised I-D?

Paul: It depends on the outcome. The question is, is netconf different enough
from generic applications that it needs a different mandatory to implement
cipher list or not. And if they don't really have a good justification for
that, then I think it needs changes because then they should just follow the
standard documents.

Rob: Yeah, I don't know the answer. I mean, obviously it's deployed normally
more often than deploying close networks, but I'm not sure that's guaranteed to
be the case. So, I don't know. Um, I think if you put it in AD follow up that
would be fine because it's not going to be approved today anyway.

Liz: Yes, it'll stay in IESG Evaluation with a substate of AD Followup.

 o draft-ietf-extra-jmapaccess-06  - IETF stream
   The JMAPACCESS Extension for IMAP (Proposed Standard)
   Token: Murray Kucherawy

Liz: We have no Discusses, so unless there's an objection now it looks like
this is ready to be approved.

Francesca: Murray dropped. It's probably AD Followup.

Liz: Let's mark this Approved, Announcement to be Sent, AD Followup for now and
when Murray comes back we can do something different if he wants.

Paul: While we are here, there's a statement in there like "the authors
believe.." Should we ever allow that in a WG document? Should authors be able
to express their opinion? I think they shouldn't.

Francesca: I don't think this was the draft. Did this draft say that?

Paul: I think so, I just saw it on the shared screen.

Francesca: I believe you; it sounds very weird to have that statement on an
IETF consensus document.

John: Personally I see it as a writing style thing rather than a consequential
process thing.

Warren: I agree it's a writing style thing, but it does sound a little weird
and I don't think the authors would strongly object to changing it. Maybe "we
believe" instead of "the authors believe."

Paul: Or generalize it, "it is generally considered that" or something. If the
authors have a view that's separate from the WG, that's something that should
be solved.

Liz: I see Murray has rejoined; Murray, we're discussing this JMAP document.

Murray: I only caught the last 30 seconds, sorry.

Paul: There was a comment from the authors in the document and we were
discussing whether authors should be allowed to have comments in WG documents.

Francesca: There's a sentence like "the authors believe that" or something.

Rob: You could probably just change it to "we."

Murray: Is everyone okay with approving this but put in AD Followup and I can
deal with that?

Éric V: I'd prefer we don't use "we" in this context.

Liz: So we're ending up here with this document approved and put in AD Followup
so Murray can deal with this wording.

Murray: Thanks everyone.

 o draft-ietf-nfsv4-scsi-layout-nvme-05  - IETF stream
   Using the Parallel NFS (pNFS) SCSI Layout to access NVMe
   storage devices (Proposed Standard)
   Token: Zaheduzzaman Sarker

Liz: There is a Discuss. Zahed,  would you like to discuss that today?

Zahed: No, not really, since Roman is not here on the call. I'll just wait to
see how the author responds to that.

Liz: Okay, we'll leave this in IESG Evaluation. Do you think this is going to
require a Revised I-D?

Zahed: Most likely, yes.

 o draft-ietf-sidrops-rfc6482bis-08  - IETF stream
   A Profile for Route Origin Authorizations (ROAs) (Proposed Standard)
   Token: Warren Kumari

Liz: We have no Discusses, so unless there's an objection now it looks like
this is ready to be approved.

Warren: I just want to make sure everyone is okay with their explanation of why
they didn't want to change their SHOULDs to MUSTs. I think it seems reasonable.

Paul: I missed it, what was their response?

Warren: Largely that some stuff is already deployed and they didn't want to
make too many changes from the original when doing this update. If you change
these things to MUST some existing behaviors would no longer be allowed. Also,
if it was a MUST, it would say you MUST do the following things except blah
blah blah, which is basically what SHOULD means.

Murray: I was uploading my ballots when the power died, so I didn't get as far
as this one. If you're going to use SHOULD so you don't force something to
become incompatible, you should say that's why it's a SHOULD. Because then
you're discouraging people from doing it the old way just because the document
allows it.

Warren: Okay. Let me chat with the authors. Thank you.

Liz: This is approved; would we like to put this in AD Followup?

Murray: Can you just wait a second for me to post my ballot? Once it's approved
I can't do a ballot.

Liz: I won't touch anything. We can move on to our next one while you finish.

 o draft-ietf-cose-cwt-claims-in-headers-10  - IETF stream
   CBOR Web Token (CWT) Claims in COSE Headers (Proposed Standard)
   Token: Paul Wouters

Liz: We have no Discusses, so unless there's an objection now it looks like
this is ready to be approved.

Paul: Just put it in AD Followup.

Liz: This will be Approved, Announcement to be Sent, AD Followup, and you can
let us know when it's ready.

 o draft-ietf-ippm-stamp-on-lag-05  - IETF stream
   Simple Two-Way Active Measurement Protocol Extensions for
   Performance Measurement on LAG (Proposed Standard)
   Token: Martin Duke

Liz: We do have a Discuss here; would we like to discuss that today?

Martin: No, I think this just goes in Revised I-D Needed. I'll wait for the
authors to respond.

Liz: Okay, this will stay in IESG Evaluation, Revised I-D Needed.

 o draft-ietf-ippm-otwamp-on-lag-07  - IETF stream
   One-way/Two-way Active Measurement Protocol Extensions for
   Performance Measurement on LAG (Proposed Standard)
   Token: Martin Duke

Liz: We have no Discusses, so unless there's an objection now it looks like
this is ready to be approved.

Martin: Revised I-D Needed, please.

Francesa: Before we approve it, I didn't Discuss it but I do have a question.
Never mind, it's for the next one.

Liz: Okay, then we can mark this one as Approved, Revised I-D Needed.

 o draft-ietf-tsvwg-rfc6040update-shim-22  - IETF stream
   Propagating Explicit Congestion Notification Across IP Tunnel
   Headers Separated by a Shim (Proposed Standard)
   Token: Martin Duke

Liz: We do have a Discuss here.

Martin: This is just about the boilerplate. Good catch, everyone, sorry I
missed it. This is Revised I-D Needed.

Éric V: And the Discuss will be cleared immediately after.

Martin: It's very straightforward.

Francesca: Éric had a comment about the boilerplate text and it also contains a
disclaimer for pre-5378 work. I was wondering if there's a reason for that?

Martin: I think Bob just has a really old template. I don't know but I suspect
that's the case.

John: Especially on bis documents, idnits will cause people to throw that in
sometimes. Which is not a good reason to do it

Fracesca: Also the idnits says something like 'can you not instead contact the
authors and make sure they're okay?' instead of putting this warning.

Lars: 6040 doesn't have the warning, though.

Francesca: I really didn't know why that was there. The next draft updates
something older, but I still didn't think that was a reason to have this
disclaimer anyway. It makes more sense that it's a copy paste but I wanted to
check with Martin.

Martin: I don't know offhand but I can look into it. These are both going to be
Revised I-D Needed.

Francesca: This document had the sentence in the acknowledgements that said
they were 'solely the view of the authors' or something like that. I was
surprised to see that.

Martin: I'll follow up.

Sandy: It would be helpful if this gets sorted out beforehand. When it gets to
us, we don't question this part and we don't know what would be appropriate.

Martin: Sure. I got it. Thank you.

 o draft-ietf-tsvwg-ecn-encap-guidelines-21  - IETF stream
   Guidelines for Adding Congestion Notification to Protocols that
   Encapsulate IP (Best Current Practice)
   Token: Martin Duke

Liz: We have no Discusses, so unless there's an objection now it looks like
this is ready to be approved.

Martin: This has the same issues. Éric, did it not have the same text the other
one had?

Éric V: I was maybe not paying enough attention, sorry.

Martin: This is definitely Revised I-D Needed, we don't have to make you push
the Discuss button.

Liz: Okay, this will go into Approved, Revised I-D Needed.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 NONE

2.2.2 Returning items

 NONE

2.3 Status changes
2.3.1 New items

 NONE

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-ippm-pam-08  - IETF stream
   Precision Availability Metrics for Services Governed by Service
   Level Objectives (SLOs) (Informational)
   Token: Martin Duke

Liz: We have no Discusses, so unless there's an objection now it looks like
this is ready to be approved.

Martin: Zahed, Roman isn't here. Have you gotten a response to your email?

Zahed: No, I haven't. I didn't Discuss it but I would like you to put some
pressure on to address my comments.

Martin: Let's put this one in AD Followup.

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-pkcs12-gost-00
   IETF conflict review for draft-pkcs12-gost
     draft-pkcs12-gost-06
     Generating the Transport Key Containers Using the GOST Algorithms
   (ISE: Informational)
   Token: Roman Danyliw

Liz: We have no Discusses, so unless there's an objection now it looks like
this is ready to go back to the ISE. This is ready to be approved, but since
Roman isn't here, maybe we'll just put this in AD Followup so he can check in
case there was anything else he wanted to do with it before it goes.

 o conflict-review-irtf-cfrg-frost-00
   IETF conflict review for draft-irtf-cfrg-frost
     draft-irtf-cfrg-frost-15
     Two-Round Threshold Schnorr Signatures with FROST (IRTF:
   Informational)
   Token: Roman Danyliw

Liz: We have no Discusses, so unless there's an objection now it looks like
this is ready to go back to the IRTF. This is approved, but since Roman isn't
here, maybe we'll just put this in AD Followup so he can check in case there
was anything else he wanted to do with it before it goes.

 o conflict-review-irtf-qirg-quantum-internet-use-cases-00
   IETF conflict review for draft-irtf-qirg-quantum-internet-use-cases
     draft-irtf-qirg-quantum-internet-use-cases-19
     Application Scenarios for the Quantum Internet (IRTF:
   Informational)
   Token: Roman Danyliw

Liz: We have no Discusses, so unless there's an objection now it looks like
this is ready to go back to the IRTF. This is approved, but since Roman isn't
here, maybe we'll just put this in AD Followup so he can check in case there
was anything else he wanted to do with it before it goes.

3.4.2 Returning items

 NONE

3.4.3 For action

 o conflict-review-irtf-hrpc-guidelines-00
   IETF conflict review for draft-irtf-hrpc-guidelines
     draft-irtf-hrpc-guidelines-20
     Guidelines for Human Rights Protocol and Architecture
   Considerations (IRTF: Informational)
   Token: Lars Eggert

Liz: Would anyone like to volunteer to do this conflict review?

Paul: I can do it.

Liz: Thanks Paul, we'll have this assigned to you.

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

 o Network Management Operations (nmop)

Rob: I'd like to discuss both Lars's and Paul's comments. Lars, you were
concerned about the charter being too vague in the sense the group could start
work without IETF consensus. Quite a lot of the focus of this WG is discussing
issues, bringing to the IETF, and less so on actually doing protocol work; the
idea is that would mostly go to other WGs. If we said that any protocol or Yang
model work would have to be put into the charter, would that be enough to clear
your block?

Lars: That might get us somewhere. My main concern is the protocol work. They
can discuss whatever they want and go wide on discussion, I don't mind that one
bit. I'm worried when they can basically decide to do new work just with AD
agreement, without a rechartering. I'm a little nervous about the technical
work anyway because it's not really clear that they would do this very often
and it's difficult to see when they could just start it and when they can't.
Some more clarity on this would be good. If we don't know they actually have
something technical to work on, maybe we don't let them do any technical work
and force them to recharter if they want to.

Rob: There are four or five side topics that came up, they had side meetings or
had been discussed in other places, and there's appropriate work that could
potentially come here. But I don't think that's protocol work. Most of that's
reporting back on experiments and figuring out what needs to be done. The
actual protocol work would go to NETCONF or NETMOD or somewhere else. The one
question mark I have is that the topology Yang might be updated and that's
I2RS. At that stage we'd have to work out whether that go to RTGWG, another WG,
or here. At that stage I have no issue saying they would need to recharter for
an explicit work item.

Lars: I'm specifically concerned with the part saying small protocol
enhancements, whatever that means, are in scope but anything larger isn't.
That's vague. I'd be fine if we could list things they are okay to work on that
are small, but leaving them unspecified is setting yourself or your [successor]
up for discussion on whether something is actually small or not.

Rob: Of all those, small or large, if we require a recharter to cover those,
that would be okay?

Lars: Yeah, or if you know some already, stick them into this charter now and
then you don't need to recharter for the first phase. If there aren't any,
let's let them recharter when it comes to that. There's always the ability for
an AD to sponsor something while rechartering happens and so on.

Rob: AT the moment, the idea is that this is operator led so they will choose
the things they'll focus on. I don't think any protocol work would happen in
this WG from the things I know about now, but it may cause protocol work in
NETMOD or NETCONF.

Lars: That's great except the charter lets them do protocol work.

Rob: Okay, I think I have a lead for that. Paul…

Paul: Ignore the first sentence, I'm sure you can wordsmith something that's
more clear. The last thing is what we just talked about with Lars. What's left
is the middle bit where I find it odd for an operational group to talk about
unexpected things and things in practice, that you'd put the BCP document
writing as the least preferred document at the end of your list. I'd think that
would be the most preferred document on your list; you're coming up with
problems and then best current practices to work around them. Why don't you
fold in the last itemized item with the first one and put them at the top?

Rob: They're supposed to bring problems here, work out solutions, maybe run
experiments and things, then at the end of that process you document. That's
the order of the list.

Paul: To me it feels like the outcome of a discussion of these problems is a
BCP document. The formal end of your open discussion of new problems.

Rob: I don't think that will happen in the short term, they're going to be
talking about issues that need to be fixed. Later on, once those issues have
been fixed, they can come back and document how it all fits together. I do know
they're planning to document the moving parts. I don't know if that stays a
draft or becomes an RFC but that's the logic that was applied here.

Paul: Okay, that's fine. I'll open-end the interpretation of a list of
important things. IT's just a guideline anyway, it doesn't have to go top to
bottom. I'll lift my block.

Rob: I'll send out to the ADs what I'm proposing to change and try and feed in
the other comments as well. Thanks all for the reviews.

Zahed: Do you have something about this open source engagement and which I
thought at least by reading, that is not clear to me what actionable thing we
could do in this working group. So do you have any plan to be more concrete on
this? What is the relationship with open source engagement?

Rob: I don't know that there will be a formal relationship. Some of the
operators are driving some open source communities to work together on solving
this problem. It's a matter of bringing that conversation to the IETF and
they're working with those people outside. I don't know if there will be any
formal relationship.

Zahed: You touched on the two things I was thinking. Do you really want to have
this open source discussion in the IETF, because that's not usually how they
work. Coordinating what needs to be discussed with the open source community
can be done in the WG.

Rob: I think it's just a matter of coordination.

Francesca: I already removed my block, but I just want to underline there
should be some text about collaborating with other SDOs and such because it
says discussion is not solely limited to things within the IETF.

Rob: I'll try to clarify a bit more.

Francesca: I think that's totally fine and didn't want to block over it, but
probably needs a bit of careful wording to make sure we don't step on anyone's
toes.

Liz: Do you have everything you need from this discussion?

Rob: I hope so.

Liz: We'll just wait for instructions from you on how to move forward, then?

Rob: Yes, thanks.

4.1.2 Proposed for approval

 o vCon (vcon)

Liz: We do have one block from Martin. Do we need to discuss this now?

Murray: This drew an alarmed reaction from the proponents because we'd already
asked them to take all the interesting details out of the charter because it
was too big, and then they're being asked to put some back in. I totally get
where you're coming from that this is a peculiar privacy issue that's not
common to the other use cases. It's a totally legitimate question to ask. What
I think they're going to say is that this is out of scope for the base
specification. The compromise I'd propose is that the WG is expected to pay
particular attention to privacy implications, which could exist in other use
cases. Does that sound reasonable?

Martin: Yeah. I've read this a couple times now. Initially you read this and
there's all sorts of metadata or data associated with conversations, like
transcripts and so on. This is fundamentally about making it easier to
aggregate that information. That obviously has legitimate use cases but is also
by definition pervasive monitoring.

Murray: I hear what you're saying. My understanding of what they're talking
about is that it's the format for doing this. The pervasive monitoring is not
in the format, it's in the action, so there could be metadata around the
transcript rather than being part of the transcript. There's a layer.

Martin: I was confused by this. It's not clear if the transcript is metadata or
not.

Murray: The transcript itself, that stuff is inside vcon. A flag on that to say
person X gave consent would be in an envelope around it. And that's not in
scope, but the transcript itself is.

Martin: Zooming out from my specific nag here about the consent thing, my
thoughts are fragmented. I want to get to yes here. The entire purpose of this
is to make it easier to gather data about conversations and have a standard
format that encourages people to collect data about conversations. This
accelerates the ease of widespread collection of data about conversations,
which has totally legitimate enterprise use cases, but also not quite as
legitimate use cases. Am I in the rough or are other people concerned about
this?

Paul: I agree with you.

Zahed: To me, the Vcon thing is about the format and the protocols that allow
us to do these things. For me, that would be a regulatory requirement of
whatever the software is that uses that protocol. It's hard for me to say that
a concern should be captured in a protocol.

Paul: As long as it's possible to express it. That's the only thing you should
insist on. There should be a way to express whether or not the user has given
consent, and then all the other protocols can properly implement this in their
security considerations.

Zahed: For me that's what it is.

Martin: I understand this cannot specify a button you have to press in Google
Meet or whatever to record a conversation. That's clearly out of scope.
Certainly there are nation state use cases where no one is going to care
whether anyone gave consent. I don't know that we can solve that here. But
there is certainly a middle case where a way to attest this has been provided
does prevent some unlawful surveillance cases, and that would be useful. If I'm
in the rough I'm in the rough, but if there's a way to somehow capture that,
that would be good.

Murray: Even if there's not a way to do it directly in the format, I think it's
fine for ust o say that you need to say that in the document. Even if it's not
in the vcon layer itself there needs to eb an indication that it needs to be
somewhere one level out from what we're producing. I Think that's a reasonable
thing to insist on.

Zahed: I think so too.

Paul: I put a short half sentence in the chat to add to the proposal.

Martin: I'd be fine with that.

Murray: Let me wordsmith this a bit. I just want to make sure we're not forcing
it into a specific layer. Do we want to talk about this more?

Martin: There are a million attestation methods in the SEC area and I'm
confused by them all, but Paul, this is possible, right? I don't want to force
them to invent some new thing.

Paul: Selective disclosure is something happening, you could do something like
that and basically take some piece of data and pick out pieces of it you wish
to disclose which can be separately authenticated. There's work being done on
selective disclosure and that might be useful here. You might want to just
relay part of this conversation.

Martin: I can live with that. Again, to zoom out, I'm a little concerned that
the purpose of this is to grease the wheels of large scale processing and that
has a dark side. I don't know how that's fixable. Unless other people are
willing to stop and yell I think I'm willing to let that go.

Murray: I'll suggest Paul's text with a small tweak which is that they need to
figure out how the notion of user consent will be part of this story. Even if
it doesn't go directly in the vcon layer, you can't ignore it, and we won't
approve a document that papers over that problem.

Paul: That sounds good.

Martin: I'm comfortable with that.

Murray: You decide if you want to leave your block or lift it while we figure
it out.

Martin: I'll just leave it.

Liz: So from our end, this won't pass today. Should we go ahead and put this
back on the agenda for the next telechat or do you want to let us know when
it's ready, Murray?

Murray: Why don't you do that and if we manage to sort it out we can just take
it off.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o Open Specification for Pretty Good Privacy (openpgp)

Liz: There are no blocks, so unless there's an objection now I think this is
approved for external review.

John: I think there are a few comments that if I was Roman I would want to look
at first.

Liz: We'll mark this as Approved and put it in AD Followup for Roman.

 o Transport and Services Working Group (tsvwg)

Liz: There are no blocks, so unless there's an objection now I think this is
approved.

Martin: I just changed the text to fix some typos, so this is ready to move
forward.

Lars: It's going for external review? Unless you think it doesn't need it.

Martin: I'm not sure. There's no change to the scope; all it does is basically
redefine it without reference to the transport area and updates what's
happening now. If anything wouldn't require external review it's probably this,
but I have no objection to external review.

John: The ballot question is is it ready for external review, so we should do
it.

Éric V: I don't disagree that it could do a short pass but if anyone complains,
they'll complain.

Martin: Okay, let's do external review.

Liz: Okay, then this is approved for external review and put it back on the
agenda for the next telechat.

 o TCP Maintenance and Minor Extensions (tcpm)

Liz: There are no blocks, so unless there's an objection now I think this is
approved for external review.

Martin: There was some grumbling about milestones being unchanged.

John: My comment on the milestones was there are literally no milestones
associated with the new charter. You can just copy over the old milestones.
That's it.

Martin: Got it, thank you. This is ready for external review.

Liz: Are we ready to push the buttons or do you want to take some time?

Martin: Let me just copy these milestones over. Okay, it's ready.

Liz: Great, then we will send this for external review.

 o Path Computation Element (pce)

Liz: There are no blocks, so unless there's an objection now I think this is
approved for external review.

John: I think yes. I probably want to spin one more version of it. Can you put
it into AD Followup? I'll open a ticket when I've done the update and then
we'll send it for external review.

 o Locator/ID Separation Protocol (lisp)

Liz: There are no blocks, so unless there's an objection now I think this is
approved for external review.

Jim: Can you put this in AD Followup as well? Lars had some comments I saw the
chairs responded to but Lars hasn't had a chance to review them, so I may need
to tweak it before it goes to external review.

Lars: I think my comment is similar to John's, that the charter seems to add a
lot of work to a group that hasn't worked very well in the past. The motivation
for some of that work looked pretty iffy. Changing the words doesn't actually
change reality; it's questionable whether this is work that someone actually
wants to deploy or if it's just work that people want to do. That's a
conversation that should be had.

Jim: It's difficult to gauge.

Lars: One thing we could try is ask them to prioritize this long list of things
and ask them to pick three. When they finish those, they can charter again.

Jim: I can talk to the chairs and maybe get them to do that.

Lars: I didn't block, I don't feel strongly about it, I just worry we're going
to see LISP run another 20 years.

Jim: Okay, I'll talk to the chairs and see if we can reduce the list a bit
based on priorities and then if they achieve the milestones we can recharter
again.

Liz: Thanks. We'll wait to hear from you on this one, Jim.

 o Javascript Object Signing and Encryption (jose)

Liz: We do have a block on this one but Roman isn't here. Do we need to discuss
this now?

Paul: I'll talk to Roman. Maybe put it in AD Followup for him.

Liz: Okay; we'll put this in AD Followup for Roman.

 o Deterministic Networking (detnet)

Liz: There are no blocks, so unless there's an objection now I think this is
approved to go forward. But we have both questions here; is this going for
external review or just approval?

John: I noticed the tooling was weird. I hope we can just ship it, but if
anybody has an objection let's send it for external review and also get rid of
this ballot question option or fix the tooling. I think we should just approve
it as done.

Liz: Does anyone have an objection to making these changes without external
review?

Éric V: Thank you for changing based on my comment.

Liz: I'm not hearing any objection to making these changes, so I think we are
ready to do that.

John: Let's ship it. I'm done.

 o WebRTC Ingest Signaling over HTTPS (wish)

Liz: There are no blocks, so unless there's an objection now I think this is
approved for external review. I'm hearing no objection. Do we need to wait for
anything or are we ready to go ahead and send it now? Murray had to drop off;
let's put this in AD Followup for him just in case he wanted to do anything
else.

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Mirja: I don't think there is anything to report.

6. Management issues

6.1 SSH Registries Designated Experts (Paul Wouters)

Liz: These are the experts Paul found for all the SSH registries. Does anyone
have an objection to naming Peter Yee and Markus Stenberg as experts? I'm
hearing no objection, so they are approved and we will send the official note
to IANA.

6.2 [IANA #1287238] Designated experts for RFC 9487 (Export of
Segment Routing over IPv6 Information in IP Flow Information
Export (IPFIX))

Liz: This is a new action item for Rob.

6.3 [IANA #1287239] Designated experts for RFC 9456 (Updates to the TLS
Transport Model for SNMP)

Liz: This is also a new action item for Rob.

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

Liz: This is an action for Francesca.

6.5 [IANA #1289479] Designated expert for URN Namespaces (RFC 8141)

Liz: Is there any objection to adding Jyrki Ilva as a designated expert for URN
Namespaces as requested? I'm hearing no objection, so this is approved. We will
send the official note to IANA.

6.6 [IANA #1283541] renewing early allocation for draft-ietf-bess-
mvpn-evpn-sr-p2mp

Liz: We have an early allocation renewal request. Andrew, this is for one of
your groups, do you have any comments?

Andrew: I spoke to the requesters and it seems that there is some
implementation and this document is moving forward, so I have no issues
renewing this.

Liz: Any objection? I'm not hearing any, so this is approved and we will send
that official note to IANA.

6.7 ALLDISPATCH feedback review (Martin Duke)

Martin: Time is up for comments, and we didn't get a ton. I don't think there's
anything really notable. One item is that there were some comments on how to
run the meeting, which I think we should defer to the chairs. Next week we're
going to have a call with the five dispatch chairs. Drop me a note if any of
you particularly want to attend. Some people said we should separate
gendispatch because it's thematically different. I think the numbers are that
we have 9 slots and there were 10 dispatch things at 118. At 117 there were 11.

Paul: Could they be scheduled back to back? The only reason to have gendispatch
there is for conflicts, so can you have them together?

Francesca: We can just say that when the chairs prepare the agenda they'll
separate it from the rest so people who want to leave can do that.

Lars: I'm hoping we also won't have anything to dispatch in Gen, so that might
happen.

Francesca: I got some other feedback about other areas, like I don't care about
routing, can I skip it. Having a good agenda will be important.

Éric V: You mean doing some pooling of the topics?

Francesca: More like prepare the agenda in a way that it's topics that belong
together. Maybe there is cross area stuff that could be in between other areas'
topics.

Zahed: If we're doing agenda slots per area then we're already dispatching
things.

Francesca: But the proponents usually have an idea already. Area is usually a
bit easier to figure out.

Martin: I think it would be good for the chairs to order the agenda so there's
some thematic grouping, but the reason we're doing this is because sometimes
it's hard to determine themes.

Lars: When the agenda gets published let's clearly mark starting times for each
slot.

Martin: And for Francesca's friend who doesn't care about routing, we don't
traditionally have a ton of routing stuff to dispatch. But the nature of this
is that sometimes you have to sit through something you don't care about for 20
minutes.

Andrew: I kind of hope we do get some routing, because we don't currently have
a dispatch and RTGWG accepts everything.

Martin: Is this ready to ship? I'll take that as a yes.

Rob: We might need to be careful that we have too many things.

John: We already talked among the routing ADs that we'll go through the rtg
area agenda and anything that's purely dispatch, get the chairs to coordinate
with the dispatch chairs. But there's not much that's purely dispatching.

Lars: One side effect is to prevent area shopping, and if you have dispatch
functions in other places you don't eliminate that possibility. The second
thing is to get a broader audience for these topics that you might not get if
you keep it in the specialized places.

Rob: Back to the original point, I think we should run the experiment and see
what happens. But it might take a couple of times.

Martin: Okay, I'll send this today or tomorrow.

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