Narrative Minutes interim-2021-iesg-25 2021-12-02 15:00
narrative-minutes-interim-2021-iesg-25-202112021500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2021-12-02 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Jenny Bui (AMS) / IETF Secretariat
Ben Campbell (Independent Consultant) / IAB Liaison
Roman Danyliw (CERT/SEI) / Security Area
Martin Duke (F5 Networks Inc) / Transport Area
Lars Eggert (NetApp) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Benjamin Kaduk (Akamai Technologies) / Security Area
Erik Kline (Google) / Internet Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Applications and Real-Time Area
Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area
John Scudder (Juniper) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
Amy Vezza (AMS) / IETF Secretariat
Martin Vigoureux (Nokia) / Routing Area
Eric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area

REGRETS
---------------------------------
Michelle Cotton (ICANN) / IANA Liaison
Jay Daley / IETF Executive Director
Mirja Kuehlewind (Ericsson) / IAB Chair
Alvaro Retana (Futurewei Technologies) / Routing Area

OBSERVERS
---------------------------------
Marc Blanchet
Adrian Farrel
Greg Wood

1.2 Bash the agenda

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

Rob: I only have an hour today and I was wondering if my document could be
moved up so we don't run out of time?

Amy: Certainly.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes of the October 21 and 28
teleconferences being approved? I'm hearing no objection, so those are
approved. I also saw final narrative minutes from both October 21 and 28, with
no edits. Any objection to approving those? I'm hearing no objection there
either, so those are approved.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

     o Roman Danyliw to find designated experts for RFC 8739 and RFC 9115
       (Automated Certificate Management Environment (ACME)) [IANA
       #1210257]

Amy: There is a management item on today's agenda to approve these experts so
this is provisionally done.

     o Zahed Sarker to find designated experts for RFC-ietf-quic-http
       (Hypertext Transfer Protocol Version 3 (HTTP/3))(http3-parameters)
       [IANA #1217617].
     o Zahed Sarker to find designated experts for multiple Bundle Protocol
       Registries (bundle) [IANA #1217632].
     o Roman Danyliw to find designated experts for RFC 9158 (SMI Security
       for PKIX CRMF Registration Controls for Alternate Certificate
       Formats)(smi-numbers) [IANA #1217716].

Amy: These three are all brand new items assigned this week.

   * OPEN ACTION ITEMS

     o John Scudder, Martin Duke, and Robert Wilton to review the document
       shepherd templates and propose changes to include updated questions,
       cross-area checks, and an expanded section on the use of YANG
       models.

Rob: I put some comments in the document and sent some comments to John and
Martin. I suggest we put this on the informal telechat agenda for next week as
a forcing function to review the comments and work out the next steps from
there. John or Martin, are you happy with that?

John: Let's do it.

     o Alvaro Retana and Martin Vigoureux to draft a note to wgchairs
       asking them to always confirm author/contributor status.
     o Alvaro Retana and Martin Vigoureux to draft text to include in the
       I-D submission tool warning about too many authors.

Amy: These two both depend on the first item so they are pending.

     o Murray Kucherawy to update BCP 97 to provide guidance about handling
       normative references to non-SDO documents.

Murray: The draft is out and saw a lot of discussion before 112. I haven't
gotten back to it yet. Let's mark this in progress and I'll light it up again
before the next telechat.

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

Amy: On hold; we'll bring this back in March.

     o Warren Kumari to rewrite the IESG blog post on "Handling IESG ballot
       positions" as an IESG statement.

Warren: That is actually in progress. Ben poked me yesterday and I have
conscripted/kindly asked my wife to help me rewrite it so it gets done.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-acme-authority-token-07  - IETF stream
   ACME Challenges Using an Authority Token (Proposed Standard)
   Token: Roman Danyliw

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

Roman: We do not. I very much appreciate the review of my peer ADs; there's a
lot of good feedback there and we'll require a revised ID. This will stay in
IESG Evaluation, Revised ID Needed.

Amy: Thanks.

 o draft-ietf-acme-authority-token-tnauthlist-08  - IETF stream
   TNAuthList profile of ACME Authority Token (Proposed Standard)
   Token: Roman Danyliw

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

Roman: We do not. As with the previous ACME document, I very much appreciate
the detailed review and feedback on this. The authors are going to continue
working on this feedback. We'll need a Revised ID, please.

 o draft-ietf-lsr-yang-isis-reverse-metric-04  - IETF stream
   YANG Module for IS-IS Reverse Metric (Proposed Standard)
   Token: John Scudder

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

John: I'm going to want to follow up with the authors to make sure they've kept
up with the comments.

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

 o draft-ietf-pim-bfd-p2mp-use-case-09  - IETF stream
   Fast Failover in Protocol Independent Multicast - Sparse Mode
   (PIM-SM) Using Bidirectional Forwarding Detection (BFD) for
   Multipoint Networks (Proposed Standard)
   Token: Alvaro Retana

Amy: Alvaro could not be with us today but I do have a Discuss. Martin, do you
have a feeling on whether your Discuss will require a revision?

Martin V: Possibly not, but Greg has made some updates anyway so there will be
a new I-D published. On my side the discussion with Greg has moved offline. I
will maybe have a chat with Alvaro and possibly John regarding BFD, but I'll
clear my Discuss in the coming days so it shouldn't be blocking any longer.

Amy: Okay, we'll put this as Revised ID Needed and Alvaro can follow up with
you and the authors.

 o draft-ietf-alto-performance-metrics-20  - IETF stream
   ALTO Performance Cost Metrics (Proposed Standard)
   Token: Martin Duke

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

Martin D: We don't have enough positions anyway, so I'm not sure of the
procedure here and if we should punt it to another agenda. I'd say that these
Discusses are generally valid so we need a revised ID anyway. One thing I would
like to discuss is the idea that we need really tightly defined metrics. I want
to say that information collection is out of scope for alto. The way the alto
server gets the data to distribute is not in scope. But also, as long as an
operator's definition is consistent I'm not completely convinced we need to
have super airtight specifications for how one measures, for instance, latency.
I think this is germane to Lars and Zahed's Discusses.

Lars: I disagree a little bit. I agree that metric collection isn't in scope
for the group, but this information is being handed out by a server to a bunch
of clients, and the clients are supposed to do something with that information.
If the clients don't know what that information means or how it's connected,
it's more useless than it should be. That's my concern specifically. There are
some trivial metrics where it's pretty obvious how you're going to use it. But
some of the other ones are not nearly as obvious, specifically TCP stuff and
probably also the bandwidth and latency related things. Just reporting a loss
rate to a client without saying under which conditions can you expect this loss
rate -- is it average loss, peak loss, what is it? What's the client supposed
to do with it? So I'm concerned that they're defining this to share information
around without at the same time giving the client anything crips to work off.
Ideally they'd just cite the emtric we have to find somewhere else rather than
do their own.

Martin D: I definitely agree on the bandwidth thing. That was kind of loosey
goosey and I think what they mean is just raw link capacity, since the other
metrics in there are available and allocated and this is clearly related to
bandwidth reservation. I think that could be tightened up. If it's just a
matter of referencing some IPPM RFC that defines latency or something, I think
I'm comfortable with that. That doesn't seem like a heavy weight change. So
maybe that's the way forward.

Lars: It could be but if I remember correctly the IPPM metrics are defined for
an active measurement scenario where you have the device under test and you
carefully throw traffic at it and then report the metric out. I'm not sure if
that's how they're going to collect this data. Basically saying we're going to
use the IPPM metric here ties them to a certain measurement methodology and I
don't know if they've thought about that.

Martin D: This is getting to a very semantic argument but there's a precise
definition of what it is, and then there's a collection technique that gets you
there. To be super scientifically precise about it, you need to know exactly
how it's collected. I'd like to have a middle ground. Bandwidth is not very
precisely defined right now and I agree that needs to be fixed. But for latency
it is possible to craft a decent definition. There's probably one in that IPPM
document. But I think tying it to the collection mechanism is a bridge too far,
for the reasons you described. I know that makes it a little bit less, it
doesn't give some kind of scientific, metaphysical certitude to the client, but
with the granularity of the decision they're making I think it's probably fine.

Zahed: I don't really care about how these metrics are collected and reported.
But I do agree with the fact that if I get these metrics, I don't know how to
use them. The uses of those metrics are defined somewhere in some document or
in someone's head who understands ALTO better than me. For me, if I'm reading
this draft and trying to implement it, I'd be scratching my head wondering what
I'm supposed to do with this data. Is there anywhere written that these are the
metrics you get and this is how we use them for the benefit of the ALTO system?
If that's not the case, I have a problem with that, because I didn't really
connect these metrics. I know these define the formatting of reporting from
server to client, that I get. I have no problem with that. But what to do after
that [is the question].

Martin D: Okay. I'll have a look at that in a while. 7285 ALTO just has routing
costs, which is what it is. It obviously doesn't have a ton of visceral meaning
to a client. I think the case is actually quite stronger that something like
latency or bandwidth, observing that tradeoff, is something that an application
would be able to make an intelligent decision off, rather than routing costs.
It seems straightforward to me but I'll look at it. The authors can add some
language to the introduction to make it more clear what the motivation is.

Zahed: That would be great. For the delays and other things, the clients will
also get the delay on losses on their own traffic, right? Then they get the
ALTO and get more information. There should be some way of describing how to
tell the applications you have more information from the ALTO server. I'm sure
there's some document somewhere that I don't know which describes what to do to
the application.

Martin D: I would have to look at the literature more carefully to know what's
in there.

Zahed: That's my point. This document should describe all the things that point
me to all of those places and I'm happy with that. Some of them could be a
normative reference.

Martin D: The original use case is peer to peer, so I think we can see what the
utility of this is. In the other draft we're talking about CDNI which is kind
of the new hope for this protocol. Enough about that. Clearly this is a revised
ID Needed and not approved because we don't have enough votes.

Amy: Since you've discussed it on a telechat, when you get enough people to say
No Objection, it can go; unless you really want to bring it back and discuss
other parts of it on the telechat.

Martin D: If there's a new Discuss I think we would obviously need to talk
about it, but if not, I don't think we need to talk about it again. I guess
we'll have to see what comes up.

Amy: Then you'll just have to twist the arms of some of your co-ADs to put in a
position.

Ben: You can either twist people's arms or you can ask to put it back on the
agenda as a returning item to make it more prominent and get some reserved page
count in peoples' schedules.

Amy: So this will go into Revised ID Needed and we'll move on.

 o draft-ietf-mpls-lsp-ping-ospfv3-codepoint-06  - IETF stream
   OSPFv3 CodePoint for MPLS LSP Ping (Proposed Standard)
   Token: Martin Vigoureux

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

Martin V: Thank you all for your review. I'd like the authors to at least reply
to the comments and see if some may impact the draft. Can you put it in AD
Followup?

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

 o draft-ietf-alto-unified-props-new-21  - IETF stream
   ALTO Extension: Entity Property Maps (Proposed Standard)
   Token: Martin Duke

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

Martin D: No, those are uncontroversial. This is just Revised ID Needed, not
yet approved.

Francesca: I just wanted to bring up something that I've been doing for all the
documents. When there is a media type registration, I will be looking at if the
authors have sent it to the media type mailing list for review. It seems like
most authors are not aware that this is recommended. Just so the IESG is aware,
it's an annoying Discuss to put.

Amy: Thanks for the reminder, Francesca. This will stay in IESG Evaluation with
Revised ID Needed.

Warren: I have a general question. Maybe this is something the SEC ADs said and
I hadn't understood it until now. Isn't the fact that the ALTO maps generally
get published potentially sharing a lot more information about a user or entity
than we normally would? I've always been grudgingly okay that my provider knows
how much data I as a user or organization am sending, because they're my
provider and they use that information for network management and there's
nothing I can do about it. What I'm realizing is that ALTO actually shares that
information indirectly with anyone who can download the ALTO map/information.
I'm not quite sure which document I'm talking about. It's kind of performance,
it's kind of props, maybe it's the system as a whole.

Ben: I'm not entirely sure I understand the concern here. I see the risk that
if there's information about an individual user's traffic and what flows they
use, of course there's concern with propagating that. But to assume that type
of information is going to be published by the ALTO server in the map seems to
require a few other steps. In some sense you expect the ALTO server to just be
publishing the overall map based on all the information it knows, and that's
not going to be predicated on, like, there are particular users going between
these two endpoints so I have to include those in the map.

Warren: As an example, Google peers with Comcast. Comcast's ALTO map says
there's no congestion between Comcast and Google. Now Google gets a lot of
traffic. Suddenly, Comcast says the links on the East Coast are very saturated
and you should not be sending traffic here or your performance will be crappy.
That has leaked the fact that there is now substantially more traffic from
Comcast to Google. I'm using that as an easy example.

Martin D: A couple things. I would say that in spite of their best efforts to
mission creep ALTO into that, successive ADs have pushed pretty hard against
real time information being distributed via this architecture. With the
exception of the bandwidth reservation stuff. A few things have gotten in.
Also, this is all within a single domain at this point. There's interest in
doing an extension to have multi-provider ALTO, but that has not been chartered
yet.

Warren: But even within a single domain. The point of this is to publish, at
least as I understood, me as a Comcast user should be able to consume the
Comcast ALTO maps to know where I should send my traffic. The fact that they
tell me "don't send your traffic to Google on the East Coast" even within that
domain, is telling me that Google on the East Coast has a lot of traffic. So it
is leaking that information even within a single domain.

Martin D: It will tell you that it's expensive in some sense to connect to
Google on the East Coast. The time scales of the protocol are such that it will
only do so if that is a persistent condition.

Ben: There are a couple of factors that come into play here. One is that there
is typically going to be some level of aggregation, so you could make the
argument that this is reporting about the overall network conditions and not
any individual user behavior. The other factor is that with some of these new
metric and cost types that we're bringing in in the other document, you do get
a little more fine granularity about yes, there is a lot of traffic here.

Warren: Yep.

Lars: This is something that significantly changed when the scope of the group
went from the initial peer-to-peer to whatever it is now. Initially ALTO was
chartered to specifically address the problem of random peer selection in
peer-to-peer connections. While they over time stabilized, that potentially
[echo, missed word] a bunch of peering links that were very costly for
operators. The idea was that you would tell the client to avoid these and make
it faster for that particular use case. But now it's much more general and the
points that Warren's raising are [echo, missed word].

Warren: Okay.

Amy: It sounds like we might be able to move on to our next document.

 o draft-ietf-alto-path-vector-19  - IETF stream
   ALTO Extension: Path Vector (Proposed Standard)
   Token: Martin Duke

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

Martin D: I think we had a little conversation about this on Slack or email. I
think the suggestion to make this Experimental is a valid one and I don't think
we need to discuss it further, unless people want to weigh in on it some more.
This will just be Revised ID Needed in IESG Evaluation.

 o draft-ietf-alto-cdni-request-routing-alto-17  - IETF stream
   Content Delivery Network Interconnection (CDNI) Request Routing:
   CDNI Footprint and Capabilities Advertisement using ALTO (Proposed
   Standard)
   Token: Martin Duke

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

Martin D: Again, I think these are pretty straightforward and I agree with
them. I think once again we should put this in IESG Evaluation, Revised ID
Needed, unless someone wants to make a point.

Amy: Thanks, we'll move on to the next document.

 o draft-ietf-idr-bgp-ext-com-registry-04  - IETF stream
   BGP Extended Community Registries Update (Proposed Standard)
   Token: Alvaro Retana

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

Eric V: You may want to put it in AD Followup just in case Alvaro wants to do
something on it.

Amy: Yes, that's generally what we do when an AD cannot be on the call. Alvaro
can do his final checks and let us know when it's ready to go.

 o draft-ietf-sfc-nsh-tlv-09  - IETF stream
   Network Service Header Metadata Type 2 Variable-Length Context
   Headers (Proposed Standard)
   Token: Martin Vigoureux

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

Martin V: It's really up to the respective ADs to decide. I have tentatively
replied to all of you, maybe not exhaustively, this morning my time. I don't
know if you've had the time to see my email. Otherwise we can discuss here or
I'll let you go through the emails after the call. I took the liberty of
sending those emails because I wasn't sure if the authors would be responsive.
I expect them to react, though.

John: I wouldn't mind saying a couple of words about my second Discuss point,
which is probably the less important of them. I was kind of bugged that there
are two references in there, [GROUPBASEDPOLICY] and [GROUPPOLICY], that say
nothing other than 'here's a title, it's OpenDaylight, and here's the year' and
that's it.

Martin V: I agree with you, John. I had seen that, but didn't feel very
strongly as I said in my email because those were informative references. But I
agree that it would be much better if we had. I did a bit of search and
suggested two references. I believe the authors are in the best place to
provide the best reference.

John: I didn't check but I hope and assume that the RFC Editors guidelines say
something about what a reference should look like.

Martin V: I think it can be a URL.

John: A URL would definitely be better than what it is.

Martin V: Noting that, the OpenDaylight reference I could find points to an
archived project, so I don't know if it's still alive.

John: I don't think it needs to be alive, it just needs to be a stable
reference that people can go to and find if they want to.

Ben: If we're going to use some arbitrary URL we could make a point of
submitting it to the Internet Archive so it has hope of being archived.

Martin V: Okay, anyone else want to discuss something? Francesca, it was more
of a question to you. I wasn't very clear where the potential interoperability
issues you had in mind are.

Francesca: The problem I had is that several fields are defined and there is a
sentence saying the structure and semantics of this field are deployment
specific. That just made me wonder how that is interoperable.

Martin V: This I understood, but what do you mean by interoperable? Those are
typically opaque values which are set by the operator and typically configured
values. They will be processed by elements which are under the responsibility
of that sole administrator. I can see misconfiguration issues, but not
interoperability.

Francesca: Exactly. With the fact that the values are configured, the
configuration should take care of that. I thought this wasn't very well
explained in the document.

Ben: There were a few places where I got confused as well. It's one thing to
say that it's opaque but then to also say what sort of substructure would be
contained in it kind of muddles the point.

Warren: There are a bunch of things that say here's a packet format, guess what
goes in it. Here's another one, some other data can go in some fields.

Francesca: That's exactly what I was thinking. If you say there should be some
configuration beforehand for that deployment, that's the question. How do you
get that configuration in place?

Martin V: For the tenant ID, typically it's described as coming from an
orchestrator. Not sure what more could be said in that space. The point is
really that both the classifier that we insert to that metadata and possibly
some virtual network function that will process it, be configured the same.

Ben: If it's going to be the byte string that is just configured everywhere and
you just check if it matches or doesn't match, that's pretty straightforward
and that is probably going to be interoperable. I think you can get some
interoperability issues if it's a value that may or may not be configured as
opaque to the NSH implementation but then it has to be processed in some way by
the recipients, as the software implementation on the recipient is only going
to implement support for some fixed set of formats. If that implementation
picks one set of formats and another implementation picks a different set of
formats, there may not be any overlap so you may not be able to actually
interoperate in terms of the contents of that field. That's a little far
removed from the NSH protocol itself but there is perhaps still some
interoperability concern to be worried about there, depending on how this value
is expected to be processed by the recipient.

Warren: Following on from that, the description of node ID, and I mentioned
this in my ballot, is only a little bit longer than the description of other
fields, but it makes a lot more sense because it actually has some examples of
what sort of things might go in there. It specifically says that the structure
and semantics of this are deployment-specific. If the rest of the fields had
that same little bit of example and another two or three sentences explaining
what sort of thing goes in there, even if it just says this is an opaque bike
field that is well understood by the operator, that would kind of help. From
freading this I don't know if my deployment can fill this with 32 bits of 1111
or is it generally an ASCII string or what? Just saying it's opaque, while
true, doesn't really help the reader.

Martin V: Okay, point taken. I agree and I really liked your comment, Warren.
I'll work with the authors to try to clarify that across the different objects
that are defined.

Francesca: I did have a comment about that following up from what Warren said.
My last Discuss comments was about the fact that I didn't feel most of these
fields were clear enough on what their use is, which is a bit like what Warren
was saying about node ID; that was clear because it had a high level definition
and some examples. When I was reading that I felt like the authors are saying
this is supposed to be known by the reader, when the reader gets to this field
there's supposed to know what this is for. What I was looking for is references
where these fields might be defined on what they're used for, possible
semantics, and these types of things. Some fields are much more clear on that
than others.

Martin V: I understand your ask, but I'm not sure it can be clarified for all.
For example, personally at least, I'm not aware of any document defining a
tenant ID.

Francesca: Okay. My ask would be, for those fields that have been defined
somewhere else, if there could be references that would be great. For those
that are defined in this document it should be clearer what they're for. That
would be the solution for me.

Martin V: Yeah. I think the authors have tried to stay away from describing how
or what those IDs could be used for. I think it's better, but I understand that
the reader might at the same time feel that something is missing. We'll try to
find a middle path between the two.

Francesca: Thank you.

Martin V: So this one definitely requires a Revised ID.

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

 o draft-ietf-regext-rfc7484bis-04  - IETF stream
   Finding the Authoritative Registration Data (RDAP) Service
   (Internet Standard)
   Token: Murray Kucherawy

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

Eric V: On my side, no. The fix is pretty easy as far as I know but I could not
let this document go with the mistake in there. It's basically removing one
zero and I'll remove my Discuss and push it with a Yes, even.

Amy: It looks like we may have lost Murray from the call?

Eric V: Revised ID Needed and then I'm clearing my Discuss, basically.

Amy: Thanks Eric; we'll do Revised ID Needed.

 o draft-ietf-oauth-iss-auth-resp-04  - IETF stream
   OAuth 2.0 Authorization Server Issuer Identification (Proposed
   Standard)
   Token: Roman Danyliw

Amy: I have no Discusses in the tracker so unless there's an objection, this
document is approved. Okay, this is approved; I have no notes in the tracker,
are any needed?

Roman: First off I want to say, Francesca, thanks for the quick turn on
revising your ballot based on the iteration. I have not had a chance to do a
full diff on the -04 to make sure some of the smaller items in the comments
here are folded into the document. Could you put it in AD Followup and I'll do
a quick look? Thank you so much for the reviews, everyone.

Amy: Certainly. This will go into 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-opsawg-ntf-12  - IETF stream
   Network Telemetry Framework (Informational)
   Token: Robert Wilton

Amy: Let's skip ahead to Rob's document. We had a Discuss but it looks like
it's been cleared.

Roman: To help us move things along, I haven't processed everything in -12 but
it did look like the Discuss is clear so I updated my ballot to make sure we
could advance this.

Ben: It's not entirely clear to me that they actually got everything that's
needed. It looks like they moved the disclaimer about not collecting end user
traffic payload data, which is now a prominent applicability statement at the
start. Do we think that just saying don't do user data payloads is enough?
We've seen some issues with metadata about user traffic that can still cause
issues with pervasive monitoring and whatnot.

Roman: Are you sure you're looking at the latest version? In the latest version
there's an applicability statement that says this only applies to things that
don't have users on them.

Ben: Oh, you're talking about the network endpoint parts.  I guess I should
look at it more closely.

Roman: The authors adopted the two sample pieces of text and moved them into an
applicability statement. I frankly would have preferred if they'd put the piece
about not collecting the payload in the same applicability statement, but it
still stands in the rest of the text and now it's a little more editorial. If
you want to polish it in some way, we can.

Ben: I don't want to take up more time on the telechat.

Rob: Ben, would you like me to hold it in AD Followup?

Ben: At least for another day. I'll give myself that much time to take a look
and let you time out quickly if I don't get to it.

Rob: Okay. Otherwise, thanks for the reviews. I know people weren't
particularly happy with some aspects of this document but on the whole it has
some useful information.

Amy: Okay, so it sounds like this is going to go into Approved, Announcement to
be Sent, AD Followup and Rob, you can let us know when this is ready to go.

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

 o status-change-http-experiments-to-historic-00  - IETF stream
   Status change of HTTP experiments to Historic (None)
   Token: Francesca Palombini

Amy: There are a number of RFCs here that are changing status to Historic. This
is for 2774, 2310, 2169, 8164, 2660, and 2296. I have no Discusses on this
status change, so unless there's an objection now it looks like this status
change announcement can go out with the note in the tracker.

Francesca: Is there anything more I need to do for the status change?

Amy: I don't think so, no. We'll get this sent on Monday as we normally would.

Francesca: Okay, perfect. Thank you.

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 o conflict-review-irtf-panrg-questions-00
   IETF conflict review for draft-irtf-panrg-questions
     draft-irtf-panrg-questions-11
     Current Open Questions in Path Aware Networking (IRTF:
   Informational)
   Token: Martin Duke

Amy: I have no Discusses for this conflict review response, so unless there's
an objection now it looks like this can go back to the IRSG. I'm hearing no
objections, so this conflict review is approved.

 o conflict-review-touch-sne-00
   IETF conflict review for draft-touch-sne
     draft-touch-sne-02
     Sequence Number Extension for Windowed Protocols (ISE:
   Informational)
   Token: Martin Duke

Amy: I have no Discusses for this conflict review response, so unless there's
an objection now it looks like this can go back to the ISE.

Martin D: I'll add the DTLS 1.3 references.

Ben: Thanks. I didn't want to put a Discuss for that.

Martin D: So this is a revised conflict review needed. Ben's other point about
putting it in the IETF stream is not a terrible point. DTN didn't want it six
months ago when this came up, which was kind of the obvious place. I've got a
couple of AD sponsored drafts already, so I'm disinclined to sponsor it. I
don't know there's a huge difference which way we do it, but unless someone
would like to say now that they will AD sponsor it, I say we just let it
through.

Lars: I have a question for Ben. Would you publish it as a different status if
it went through the IETF?

Ben: Off the top of my head, no. I could perhaps imagine a reworking of the
content that would fit well as a Proposed Standard, but it seems impolite to
ask the author to put in the effort to do that on a speculative basis. I'm
inclined to just let this go through.

Lars: We can let this one go to the ISE and still talk to Joe if he wants to
bring it back and try to find an AD for it for a bis or something.

Ben: That's also true, yes.

Martin D: I'll update that today and then you can ship it.

Amy: So this is approved with kind of an AD Followup.

Martin D: Why don't I just do it now and then I'll speak up when it's done.
Warren: I have a question on conflict reviews in general. I've got a conflict
review which was going to be this week but we punted it to the next telechat.
Some quick background, what happened with this document is that the authors
brought it to DNSOP, who largely said it seems interesting but we don't really
care, do it through the ISE. My actual question/note is when we propose a
conflict review response, we generally just have five or six options we copy
and paste, then we stick that in the ballot and that's all the info there is.
What I did is I stuck in a little parenthetical comment providing some
background. Is that the right thing to do? How should we provide background
info for people to understand why the AD thinks that's a good conflict review
position? We don't have a separate box in the datatracker for why.

Ben: I had a similar problem for the Russian ghost TLS 1.2 ciphers. I had a
long writeup with an intro about this is a conflict review response, I'm tasked
with making this assessment and choosing from one of these options, I have
chosen this option, what follows is a section directed at the IESG to try and
explain why I chose that, there were also some other sections directed at the
authors because i read the document and have comments. Maybe we could take that
and use it as a template for the future.

Martin D: I would say more information is always better, in my personal
opinion. I'd just make sure you include the magic words at the top so people
who just want the status get the status, and then you can go crazy with
exposition after that.

Warren: Maybe I should ask Adrian to provide some views on this. I'd always
gotten the view that the conflict review was you may choose one of the
following sets of text and not change it at all. I've always felt weird adding
extra comments.

Ben: So you're asking about in the ballot text vs. in the actual conflict
review text that gets sent to the ISE?

Warren: Yes. there's the conflict review text, which is the bit everyone looks
at. They often don't read the eval record until they've read the document. In
the base conflict review text, I put 'this is related to work in DNSOP but does
not prevent publication' which is the formal text. I put a paragraph underneath
explaining why and said not to include it as part of the conflict review text;
it's not an IESG statement, just some background. I don't know why this
interaction often feels so stilted.

Adrian: I would basically think that the comment is the right place. In this
one we're looking at, Martin could have balloted yes but still put in a
comment, and his comment could have explained why he'd put in the conflict
review he did and given a small essay. That seems better to me, remembering
that the whole ballot here on the conflict review is basically between you
guys. You're balloting on your own stuff, you're not balloting on the document.
This is where you discuss the ballot. I also hoover up any comments that apply
to the document at the end of the day. If you really wanted to put it in the
conflict review, I guess marking it very clearly with an editorial note of
please remove this before the conflict review is approved, that would be okay
as well.

Warren: Okay. I think I managed to communicate clearly this is just background
and said this is not an official part of the conflict review. It still just
feels to me like maybe a second box in the Datatracker could work. Anyway I
think we have it figured out.

Lars: If someone felt inclined to do so we could discuss it on an informal
call. 5742 is maybe a bit dated and I don't think it's been updated very much.
This would be a discussion with Adrian and Colin to see if there's a better
process we can derive now that we have years of experience with this. But this
call is not the place to have that discussion.

Ben: I just wanted to note one other thing, which is that for this sort of
background information that Warren has in his DNSOP one, a lot of times I've
seen Adrian put that into the shepherd writeup for the document which is very
helpful.

Adrian: I think Lars's idea of discussing 5742 is a great one, but I would
probably suggest that it's something you might want to defer until my successor
shows up.

Lars: But you have experience your successor doesn't have yet. If we did this
we would want you on board in terms of having a couple of years of experience
with it. If we punt it for a couple years none of the current IESG will care
anymore.

Adrian: I don't intend on dying the day after I hand over, so I would be
available to talk to you. I'm just sensitive to dumping a change on the new
guy. Anyway, that's for later discussion.

Martin D: To return to the document at hand, I've updated the conflict review
so Amy, you can ship it.

Amy: I see that update, thanks. This will be approved with the note that's
there and we'll send that back to the ISE on Monday.

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

 o Software Updates for Internet of Things (suit)

Amy: I have no blocking comments for this recharter, so it looks like the
external review message can go.

Eric V: Just a quick question. I see in the charter a SUIT status tracker, with
no explanation of what it is.

Roman: That's an architectural element that's described in the SUIT
architecture document.

Eric V: Okay. Maybe putting a pointer to that would help?

Roman: I can do that. If we still send these on Monday after this telechat,
I'll make some editorial polish before this goes out.

Lars: The only thing I was going to raise is if you're still happy with the
chairs you have or if this is a good chance to pull in some new blood. I will
raise this at every recharter we do, so get used to it; it's fine to say yes
but I want to consciously think about rotating chairs more frequently if we
can. Just a general comment since I mentioned a couple months ago we should try
to cycle chairs more frequently, not a comment on the chairs for this
particular WG.

Roman: Understood. The chairs here have done a great job moving our documents
at a nice cadence but your feedback on how to cycle chairs to get more blood in
the pipeline is fair and I'll give that some consideration. Thanks.

Amy: Okay, so I'm hearing this is okay to go to external review but you'd like
to make some changes to the charter?

Roman: Yes, just a few things. Do we still send these out the Monday after?

Amy: For charters we generally send them on Fridays, so that's tomorrow. If you
want us to wait until Monday for this one, we can do that.

Roman: That would be better, can I have until Monday?

Amy: Absolutely. So SUIT will go for external review on Monday.

 o General Area Dispatch (gendispatch)

Amy: I have no blocking comments for this recharter, so it looks like this is
approved for external review, if it needs it. Lars, does this need external
review?

Lars: I think so. Gendispatch is a pretty special WG, so let's send it out. I
recently cycled one chair so there was some change made.

Amy: Great. I'm hearing no objection to the approval of external review, so
we'll get that message sent and put it back on the agenda for approval next
time.

Francesca: Lars, I did have one comment. I don't know if you saw the email
exchange with Pete, but this was one of the few paragraphs that was added. It's
the one about discussions of proposed work should take place where Gendispatch
directs them. I thought this sentence was kind of strange. I think the problem
I have is that normally, I thought it would be obvious that once work is
dispatched the discussion should take place wherever that work dispatches it
to, but if you think it's necessary maybe rephrasing that to "full discussions"
would be useful.

Lars: Thanks for reminding me. I'll take a look at that text. I think that
mostly came when stuff is being dispatched to AD sponsored, and there's not a
clear home for where discussion should happen. I think we should make it
explicit where we expect discussion to go. It's obvious when you dispatch to a
WG but if you dispatch to an AD they should tell you where to discuss it.

Francesca: Or even if you drop it. If it is rejected, proponents might still
follow up.

Lars: Yes. I'll take a look and see if I can come up with some better wording.
I think we can still send this out for external review and do this in parallel.

Francesca: Yes, of course. Thank you.

Amy: Okay, we'll get that external review message sent tomorrow.

4.2.2 Proposed for approval

 o Network Time Protocol (ntp)

Amy: I have no blocking comments for this recharter so unless there's an
objection, it looks like this is approved.

Erik K: Thanks to Roman in Slack for giving me a clue about proposed milestones
vs. actual milestones. I've added some per his request.

Amy: When this is approved, will it replace whatever is in the charter now?
Excellent. With that, this recharter announcement for NTP will be sent tomorrow.

 o Delay/Disruption Tolerant Networking (dtn)

Amy: I have no blocking comments for this recharter so unless there's an
objection, it looks like this is approved. We'll send that announcement
tomorrow.

Zahed: Thanks for the comments we got. We got one question from Eric asking
about QoS and interaction with INTAREA on the tunnel. One of the chairs has
told me he will reply but I don't expect any drastic change here. We'll update
the milestones and move forward. What is the next step?

Amy: I don't see proposed milestones in the recharter and the current
milestones, we don't have dates attached to move them.

Zahed: Okay, I'll fix that.

Amy: There should be a button that says "Edit Milestones" at the bottom of the
rechartering page and you can put all of those proposed milestones that are
currently in the charter text as milestones, and you can add dates. Once those
are in as proposed milestones you can delete them from the charter text. If you
need help with that, we can always help as well. You can let us know.

Zahed: I'll try it out. Thank you.

Amy: So it sounds like this is approved pending those edits so we'll wait for
that to happen before we send out the recharter announcement.

5. IAB news we can use

Martin V: I've sent a short email to the IESG about IAB news. I can say it here
too. The IAB has started a discussion on the leadership pipeline and also a
discussion on how to improve the existing mechanisms to bring in new work
and/or identify new mechanisms to facilitate that. That's it for me.

6. Management issues

6.1 Designated Expert for RFC 8667 (John Scudder)

Amy: John has proposed Les Ginsberg, Christian Hopps, and Hannes Gredler as
experts. Any objection to naming these three as experts for this RFC? I'm
hearing no objection, so this is approved and we'll send an official note to
IANA.

6.2 [IANA #1216109] Management Item: Acceptance of media type registration from
standards organization Unidata (IANA)

Amy: Did anyone take a look at Unidata to see if they should be added?

Murray: I did. I didn't find any reason to say no but I didn't feel like it was
a clear yes, either. That was before 112. Unless you want to do this now, let
me find my notes and I can circle back to the IESG via email.

Francesca: I don't think I've seen this sent to the mailing list. I know it's
not a requirement, but I would feel much more comfortable if those were not
objected to at least on the mailing list.

Murray: Are you talking about the media type reviewers list, or the media type
list?

Francesca: The media type list, is the one where the feedback for registrations
goes. But of course if the experts would also weigh in, and you're one of them
Murray, that's great too.

Murray: I don't remember that we have specifically asked that list what it
thinks ever, it just goes to the IESG for a decision. Just so everyone knows,
there are two lists: one list that's IANA and the reviewers, and there's one
public IETF list to discuss media types. I've bever seen it sent anywhere
except the IESG for an opinion, but it seems like getting community feedback
isn't a bad idea.

Francesca: It's the first step in the registration request and it's recommended
to be sent to the list.

Murray: For a media type registration, right. For the request to become listed
as an SDO that has access to the standards tree, I think that only ever goes to
the IESG and that's the item here.

Lars: Is it actually? The text sort of ties the two together. I think they're
making a request for a registration and then it says should they also be added.
I'm not clear whether they asked or if IANA automatically asks for every new
request they get.

Murray: If it comes from an organization it seems like the pattern is to couple
the two and issue both requests at the same time. We can decline and just say
we'll approve the registration as a one-off.

Lars: Did Unidata ask to be approved or is it something IANA asks us? There's a
difference, right?

Murray: I haven't seen a request specifically from Unidata.

Lars: A lot of these seem like one-offs and it seems odd that we always get
asked by IANA if we want to approve this organization. I'd maybe only ask IANA
if they get a third one or something, rather than the first request.

John: Amanda did send a followup on Novembre 10 quoting some email she got from
the Unidata applicant and it ends with 'I do not foresee further registration
requests from Unidata.'

Ben: On the other hand, I feel like in some previous rounds of discussion we've
managed to confuse ourselves whether the RFC actually allows us to approve a
one-off registration in the standards tree without recognizing them as an SDO.
I don't remember the details of those prior discussions.

Murray: I'll circle back with IANA and reread this part of 6838 and figure out
how to break the confusion here. If we have an organization that comes in with
a one-off request, why are we polluting the list with those? It should just be
the ones like ISO and W3C, I think those were the ones we were thinking of when
we wrote this provision.

Lars: If the provision is written in a way that we must approve a whole
organization to approve a single request, that should probably be fixed because
it doesn't seem to work very well.

Amy: You have approved a media type without adding the SDO. You have done that.

Ben: I remember us doing that and then I remember looking at the RFC and
wondering if we should have done that.

Amy: Do you want to hold this management item over until the next telechat and
do some research, Murray?

Murray: Yes, that seems best.

6.3 [IANA #1210257] Designated experts for RFC 8739 and RFC 9115 (Automated
Certificate Management Environment (ACME)) (Roman Danyliw)

Amy: Roman has identified Yaron Sheffer, Diego Lopez, and Thomas Fossati as
experts. Any objection to approving these three as experts?

Ben: I just wanted to check. I think we have a different set of experts for the
core ACME registries and off the top of my head I don't remember if these
particular RFCs are sufficiently different that we definitely want a different
set of experts.

Roman: We have the core set of experts for the core ACME protocol. The document
this is representing is a bit of the star set of documents, which is the niche
part of ACME that's doing faster issuance for faster expiration and there's
more metadata associated with that. That's why I have a different set of
experts for diversity.

Ben: Okay, now I remember what's going on. That seems reasonable.

Amy: I'm hearing no objection to approving these three so we'll send an
official note to IANA.

6.4 [IANA #1217617] Designated experts for RFC-ietf-quic-http (Hypertext
Transfer Protocol Version 3 (HTTP/3))(http3-parameters) (IANA)

This is a new item and has been assigned to Zahed.

6.5 [IANA #1217632] Designated experts for multiple Bundle Protocol Registries
(bundle) (IANA)

This is a new item and has been assigned to Zahed.

6.6 [IANA #1217716] Designated experts for RFC 9158 (SMI Security for PKIX CRMF
Registration Controls for Alternate Certificate Formats)(smi-numbers) (IANA)

This is a new item and has been assigned to Roman.

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

Francesca: I just wanted to mention the item I'm bringing to the next informal,
which is that I have invited Adrian and the RPC and Robert to join us for at
least the first part, because I've talked to them about how to make
interactions between editors and authors during auth48 more transparent. I have
a proposal for that and I'm looking forward to hearing everyone's opinions
about that. Just as a heads up, hopefully we will have guests. I still need to
hear back from the RPC and Robert if they're okay to come next week.

Eric V: My point was just to repeat in this call so we can have it in the
minutes. In the 112 debrief we all agreed to continue with MOPS without
rechartering for at least one year. That's all.

Martin D: I wanted to talk briefly about this DNS DPRIVE port business some
more. On Tuesday Zahed and I chatted about this and came to the conclusion that
we should just give them the port again. I think I wrote down the reasons why.
Nobody in the IESG really stated a strong objection, however a couple people on
the IAB did. Technically speaking the port is owned by the IESG with the
contact being the IETF chair. Do we need to continue to discuss this on the
list or should Zahed and I just do what we think we need to do? Oh, Lars is
dropping off the call and I wanted his opinion most. What do people want to see
here in terms of reaching an agreement?

Zahed: To be clear on my side, I saw the arguments and I'm not really convinced
yet that we need to revise our decision. If anyone doesn't agree with that we
can discuss it now but I don't see the need.

Martin D: This is really the wrong venue because our objectors are on the IAB,
but we don't meet with the IAB. I think the way the procedures are set up this
is an IESG decision or maybe a ports team decision.

Ben Campbell: As IAB liaison, I could be wrong on process here but I think you
should treat IAB objections as individual contributors. I don't think there's
any special IAB authority here.

[crosstalk, several people agreeing]

Warren: Apologies for not knowing this, but have you asked the DPRIVE list and
the authors? I think the chance of an appeal is small.

Martin D: The owners of the protocol are asking to keep the same port, which
completely jives with the predilection of the ports team. They're happy not to
have to grant another port. I messed up this whole thing by bringing up the
issue of Quic versions. I will say that as it stands, it's perfectly possible
the only thing is someone has to store in the back of their mind that if
there's a Quic version that doesn't allow this multiplexing, you'd have to
remember not to turn those things on if you're trying to serve both protocols
on the same port. Given that DOD TLS seems like a dead protocol, it doesn't
matter. This is probably overthinking it but because there was some pushback I
wanted to bring it up. I think Zahed and I are going to drive on with what
we're doing.

Warren: I was the chair of DPRIVE and unofficially,  we largely did the DNS
over TLS one just to provide parity with DNS over TLS in case anybody ever used
it. I don't think there was ever really an expectation many people would use it.

Zahed: We've discussed this a bit among Quic stakeholders and there is a
manageability draft in Quic which actually says what should be done when it
comes to Quic. The idea there is we give them the port and point them to what
they should keep in mind. That's basically what I think we should do.

Martin D: I already put it in the WGLC comments but I'm going to push the
authors to add some text about DTLS multiplexing should that ever happen. I'll
take that action item and if it doesn't get fixed I'll Discuss on it, which
should be easy to resolve.

Eric V: Thank you Martin and Zahed for putting in some work on this.