Narrative Minutes interim-2021-iesg-10 2021-05-06 14:00
narrative-minutes-interim-2021-iesg-10-202105061400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2021-05-06 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
Michelle Cotton (ICANN) / IANA 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
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
Alvaro Retana (Futurewei Technologies) / Routing Area
John Scudder (Juniper) / Routing Area
Amy Vezza (AMS) / IETF Secretariat
Eric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area
Martin Vigoureux (Nokia) / Routing Area

OBSERVERS
---------------------------------
Sara Dickinson
Rene Struik
Greg Wood

1.2 Bash the agenda

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

1.3 Approval of the minutes of past telechats

Amy: Is there any objection to the minutes of the April 22 teleconference being
approved? I'm hearing no objection to approving those. I also saw final
narrative minutes; is there any objection to approving the April 22 narrative
minutes? Hearing no objection there either so we will post both.

1.4 List of remaining action items from last telechat

     o Alvaro Retana, Benjamin Kaduk, and Murray Kucherawy to look at
       updating the I-D Checklist.

Murray: We are all invited to look at the thing Robert worked on; I sent a link
around. He points out that there are a couple of issues open in the tracker in
his Github repo. What he's got is basically the synthesis I was talking about
doing with his additional content that brings us up to date on xml2rfc and
other tooling things. I read it last night top to bottom and it looks quite
good. I'd imagine that within the next few days I'll last call it to the IESG.

     o Warren Kumari, Deborah Brungard, Stephen Farrell, and Jay Daley to
       investigate ways to recruit, recognize, and retain volunteers in the
       IETF.

Warren: Apparently someone's decided that this is going to be handled by EMODIR
or something, so I guess this gets removed from our to-do list.

Lars: Who said this?

Warren: We were having these meetings fairly regularly, then they sort of
stopped, and I said when are we meeting again, and Jay said this is now going
to be handled by EMODIR or something similar.

Lars: I'm surprised about that, because last I heard from Jay he was planning
to get that small group restarted. So maybe we should check what his plan is
before we cross it off. I'm okay either way, we just have conflicting
information.

Warren: I thought it was doing good work. I guess let's leave it.

Lars: I'll make a note to ask Jay what's going on.

     o Alvaro Retana, Rob Wilton, and Martin Vigoureux to draft text on the
       framework for a long-term future plan for the IETF.

Amy: I know we talked about this at the retreat. Is this action item done?

Alvaro: I'm going to say yes. The draft text is done. There will be ongoing
work on this but this particular item is done.

Eric V: Do we expect to have a management item for all of those subtasks?

Alvaro: There's one later for Rob on the small group project assignments. I
don't know if it makes sense to have individual ones or what later.

     o Alvaro Retana and Martin Vigoureux to draft text to update the IESG
       Statement on Internet Draft Authorship to include "Contributors."

Alvaro: We've been talking about this. Can we have a short management item at
the end to go over the last couple of comments remaining? Then we can close it
after that.

     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.

Alvaro: The plan was to do these two after that first one on the statement, so
they'll be sequential. They'll be in progress as soon as we finish the
statement.

     o Lars Eggert to update BCP 45.

Lars: That's on hold depending on what we're going to do with the IETF discuss
list. That's probably going to be on hold for a while until we finish deciding
what to do.

Amy: Do you want us to remove it for a month and ask again in June?

Lars: That would probably be good. Thank you.

     o John Scudder and Martin Duke to review the document shepherd
       templates and propose changes to include updated questions and
       cross-area checks.

John: We have not done anything on that yet. Should have something to report
next time.

     o Rob Wilton to draft text to expand the document shepherd write-up
       section on use of YANG Models.

Rob: I haven't gotten to this one yet; hopefully will have an update on this
next time.

     o Zahed Sarker and Michelle Cotton to draft text for prospective
       Designated Experts on the basics of the IANA request process and
       "how to be a designated expert."

Michelle: I have some draft text ready to go; I'm just waiting for Zahed to be
back working. In progress.

     o Michelle Cotton to add conflict of interest text to the introductory
       email sent to new Designated Experts.

Michelle: I have some draft text circulating internally that we'll be adding to
the message we send to the experts. I expect that to be done by next time.

     o Michelle Cotton to follow up on the documentation of IANA registries
       and non-IETF publication streams.

Michelle: I have a question for this one. We concluded that for ISE stream
documents, creating IANA registries wasn't possible through expert review. I
think these were discussed in the same topic. I was just double checking what
exactly I needed to do here.

Amy: This was one I had a question on too. I'm not entirely sure. It was
non-IETF publications stream, so not just the ISE.

Lars: This is also IRTF and I guess IAB? Basically whether IANA registries can
be created by outside streams.

Michelle: Okay, so just confirming that, making sure where the documentation
is, and then coming back to you all.

Lars: If it's possible and what is possible, I guess we're asking. I have a
feeling we've discussed it in the past.

Michelle: That's okay; this time we will discuss and document and then we won't
need to discuss it again. I have my marching orders.

     o Rob Wilton to follow up with the IESG on small group project
       assignments regarding topics identified through the poll taken at
       the IESG retreat.

Rob: I haven't done this yet but I will try to do it by the end of the week.
I'll email the people who I suggested make up the teams and then check the
leads of those teams. I guess the next action is probably to have those teams
tracked separately on this list, but we can see.

     o Martin Duke to draft a proposal for 360 degree reviews of the IESG
       members.

Martin: No progress yet.

     o Eric Vyncke and Francesca Palombini to draft text for guidelines/
       best practices[?] for directorate reviewers.

Amy: Let me know if I got the text on this one right.

Eric V: This is a work in progress in the sense that Francesca and I still need
to get started.

Francesca: We were saying that our first action item is to go through the
minutes and decide what action items could possibly be added. We can keep
something there but it might get changed.

     o Warren Kumari to find additional designated experts for DNS EDNS0
       Option Codes (OPT) [IANA #1196393].

Amy: This is on the agenda as a management item. If you've confirmed those
folks are good to go we can do the approval at the end of the call.

     o Lars Eggert to report on the RFC 8989 experiment.

Lars: That's not really for me but for the IESG to report. If you remember, RFC
8989 is the Nomcom experiment, the eligibility criteria that's going on now
with the new Nomcom. Since Gabriel Montenegro was just announced as the Nomcom
chair that's now underway. If you look at 8989 it defines three different paths
that make you nomcom eligible. There should be more people that are eligible
theoretically than under the previous non-experimental Nomcom eligibility
rules, and RFC 8989 tasks the IESG with reporting to the community on whether
this experiment was successful after consulting with the last Nomcom chairs,
meaning Barbara and Gabriel. It says as soon as the entire 2021/2022 Nomcom is
seated, so  my guess is that will be May or June. I added this as a reminder to
ourselves that we need to talk to the two Nomcom chairs and come back with a
report to the community. That means we can probably postpone this for the next
four weeks, since I don't think the Nomcom is going to be seated before then.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-dprive-xfr-over-tls-11  - IETF stream
   DNS Zone Transfer-over-TLS (Proposed Standard)
   Token: Eric Vyncke

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

Eric: I think at least we have time for some synchronization here. First of
all, thank you for all the reviewers. As always, very detailed and much
appreciated. Thanks also to Sara, one of the main authors, who has joined the
call today. I think I will check with Martin D as to whether this ALPN issue is
solved yet? Not in a Revised ID but basically promises to fix it. I see Martin
nodding.

Martin: Either a SHOULD or a MUST. I think SHOULD is probably better.

Eric V: And that was really a good comment. And Ben, it looks like all your
Discuss points are either resolved or nearly resolved, right?

Ben: Nearly. I know Sara sent mail this morning that I haven't had a chance to
digest yet, but we're definitely making progress.

Eric V: Okay, so we can hope to clear the Discuss sometime soon then.

Ben: Yes. The ALPN thing I can clear when a new version lands, and the other
topic may not require text changes after all. We'll see.

Eric V: Okay, thank you both. So I would suggest, if you don't mind, to
simplify we could put this in Approved, Revised ID Needed?

Amy: So the Discusses are going to clear and then this will go into Approved,
Announcement to be sent, Revised ID Needed?

Eric: Correct.

Amy: I also have to ask about the two downrefs, 6973 and 7626? Do we need to
add those to the downref registry?

Eric V: I need to check, I'm afraid. I will get back to you by email.

 o draft-ietf-core-new-block-11  - IETF stream
   Constrained Application Protocol (CoAP) Block-Wise Transfer Options
   for Faster Transmission (Proposed Standard)
   Token: Francesca Palombini

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

Francesca: Yes. Thank you everyone for the very thoughtful reviews, and the
directorate review was very good as well. For Ben and John, I haven't seen any
answer from the authors yet and I don't have any answer myself at the moment,
so I would say for your points we should wait for the authors. Lars, I wanted
to take your Discuss today. If I understand correctly you're questioning that
this is not maintenance work, and it's an extension in your mind?

Lars: That's not how I understand it. Typically when we talk about maintenance
work it's a bis document or an updates or something. But not another mechanism
to do something that the protocol is already doing.

Francesca: This to me is still in charter because it's providing something. The
WG realized the blockwise was not addressing a certain use case, so it's
providing something that was missing from 7959, so that's why it's doing
maintenance of blockwise. The fact that it's technically formulated as a CoAP
extension is for deployability. It was discussed if this should be a bis
document, and the WG felt this would be the best option for deployability. It's
not an extension in the sense that it's not a new idea or something new to add
in that world. So I guess we are disagreeing on what maintenance means, because
you see it as basically publishing documents it updates, or a bis, or
obsoletes, or fixing errata, etc, whereas I also see this. I talked to the
chairs and the previous AD and we all agreed that this is basically [best].

Lars: If the charter text talked about the WG maintaining the capability to
transfer larger data blocks, I'd probably say you're right, but it's
specifically talking about the document 7959. It says they're chartered to do
maintenance on that document, which they're not doing, because they're
publishing a new document and they leave the old one untouched, and they even
say this document is just for that one thing. That's not an update; that's not
maintenance.

Francesca: Let's see. I see your point, but I think the maintenance on the
document, or the maintenance on the blockwise that is defined by the document,
is a thin line. I wouldn't want to stop progress of this document on this. I
would be okay with doing a quick recharter of CORE. I think this is probably
something that needs clarification in the charter.

Lars: And what if a bigger issue comes in. I don't think this is a quick
recharter. I think this is going significantly  beyond what CORE is supposed to
work on, which is a lightweight protocol for IoT deployments, and this is not
for that use case. I would not let CORE recharter to do this stuff.

Francesca: It is in scope, for a constrained IoT environment. A protocol can be
used outside of the domain that it was...

Lars: The entire document here doesn't even mention IoT. There's nothing in
there about IoT; it just talks about loss and DOTS signaling and telemetry and
stuff.

Francesca: DOTS is mentioned just as an example. It describes a constrained
environment, which is the domain of CORE.

Ben: Can I jump in and ask a clarifying question for Lars? Are you concerned
about this work being done in the WG or about it being done for CoAP at all?

Lars: There are two objections and they are related. One is that I don't think
this is currently in charter as it's presented here because it's not an
extension, which is what the charter says. My broader issue is that I don't
think CoAP should recharter or do work that turns it into a general transport
protocol for the internet, specifically in this case where there's high loss.
This is going quite far away from what CoAP was supposed to be and what CORE is
chartered to work on. The entire CORE charter is IoT related and this is not an
IoT use case.

Francesca: The CORE charter is Constrained restful environments, the WG has
realized that there is a use case for blockwise transport that is not addressed
by the current blockwise specification. We have RFC 5218, I believe, that also
points out that protocols can be used outside of what they were originally
designed for. So just saying that CoAP is turning into something that it wasn't
designed for is unfair.

Lars: They can, but if CORE wants to do that, they have a serious recharter. If
they want to say CoAP is now a protocol for the wider internet, for conditions
where TCP doesn't work well, for example, they can make that case but that's
not something they can just say is part of maintenance.

Francesca: I don't agree with that. I think there might be a recharter to
clarify what maintenance is, because as you were saying maintenance of the
document vs maintenance of the technology that is defined in the document, in
this case blockwise. But I think this is what CORE WG has been doing. This has
always been the understanding and this is what we've been doing. I don't think
this is a major rechartering.

Lars: I think the CORE people need to read their charter, then, because the
charter is pretty clear. It's about IOT deployments. Even if the WG all agrees
they want to work on something else, as long as the charter [doesn't] change I
don't think they can.

Francesca: I'm interested to hear what others think as well. I have not been
reading the chat. If someone wants to jump in, from the rest of the IESG...

Ben: Unfortunately I don't think I've had enough caffeine yet today to be
functional on this topic. I may have to read some things and participate in the
email thread.

Mirja: It sounds like something that should also go back to the DOTS group and
figure out if there's another solution.

Roman: From the DOTS discussion there was a desire to have this functionality
because the story started with CoAP used as a basic 'I need help' signaling
protocol. In the next evolution they realized just some more metadata would
help with the 'I need help' call, and that was the insertion of telemetry. The
only way to put that telemetry in there is in the signal channel and the signal
channel is CoAP. There's no other place to put it because it wouldn't survive
the communication if it was done via the data channel, because the data channel
is RESTCONF. It's either in this channel or it's not done, is the challenge.

Mirja: Could it be in the DOTS charter?

Roman: That's a different level of negotiation. Personally, I don't see a
reason why not, but that's up to Ben.

Ben: I believe there was some consideration given about where to do this work.
The DOTS telemetry use case started off and they were going to do something
kind of hackish to get the higher bandwidth blockwise transfers, and then there
was a discussion that we should rather do the modifications to CoAP in the CORE
WG because they have the relevant expertise.

Francesca: That's where blockwise for CoAP is developed, so it makes sense to
me.

Roman: When DOTS tried to invent some of their own chartering to prevent denial
of service in 2016 when this all started, they got a lot of robust feedback
that they need help from Transport. That's the motivation not to do it in the
Security WG.

Lars: That's a secondary concern. If CORE wants to work on this I think they
need a lot more Transport help than they have currently. They have a blockwise
mechanism that's been designed for IOT devices, right, that's what they
currently have. But it's not fast enough for DOTS. The problem is that DOTS
wants to be fast, when there are very high loss rates. One reason you have high
loss rates is you're under a DDOS attack. Other reasons for high loss rates are
just a lot of traffic. The only way you get through is to be very aggressive
with how you transmit, which is dangerous. That's where my concern comes from.
I can understand they want to be faster than what CoAP has designed, which is
maybe too restrictive for them, but it's quite dangerous to be faster when you
have high loss rates because you have very little feedback on what the network
is like. And that's something that Transport is looking at as a research
question. I don't think we have a lot of things that we know work here.

Francesca: I don't really know how to move this forward now. To me this was
clearly in the scope of CORE as it is. What do you suggest, Lars?

Lars: I have really no idea. The problem started, unfortunately, when DOTS
chose CoAP and then decided they wanted to send more than one message. The
problem is really the desire to send more than the packets when you're on high
loss is really a hard problem. If you look at this IPPM document where they
tried to measure access network capacity which is a whole different problem,
but they also need to send a lot of traffic to get accurate measurements and
there's a whole bunch of concern about that. If this was an easy problem, we
would have a protocol already. But we don't have one because it's a really hard
problem.

Ben: Your point here is roughly that DOTS should not be trying to send very
much data during attack conditions until we've made progress on that research
problem?

Lars: Yes. Is there any experimental evaluation of this protocol? Has somebody
tried this and seen how aggressive it is and what it does if it's run in an
environment where there's not a DDOS attack but just a lot of traffic?

Eric V: I had that question during my evaluation, whether there are
implementations. A library has been used to make some tests but as far as I
know no deployments, which is also a concern of mine.

John: Thank you for bringing up the E word, because I sort of had the
impression that this thing just feels like an experimental document to me. I
wonder if choosing experimental instead of standards track would address your
concern, Lars, or if that would just be deck chair rearrangement.

Francesca: I don't think this document fits in experimental. Also because there
was talk of blockwise-bis, and that wouldn't make sense to me to base it on an
experimental.

Lars: It would make it clearer, in my mind at least, that this is not really
ready to be recommended.

Francesca: I understand that you have concerns, but I don't know how we solve
these concerns. Is it more transport review that's needed?

Lars: The charter problem is one thing, but the larger problem is that even if
you solved the charter problem, if we gave this to Transport the first thing
they would say is there any evaluation of this mechanism in various scenarios?
How much better than the basic one is it and how much more aggressive is it? If
we put it on the experimental track as John has suggested, at least we could
spin the document as saying that it's being published so this question can be
answered. I don't know if that's okay for DOTS though because they might want
to have a normative reference to it, which they can't in a standard.

Francesca: It's also always the fact that people wait to deploy a standard
before they have become a standard, so it's the dog biting its own tail.

Lars: It's also not clear; they're saying the basic blockwise is too slow, but
they're not saying how much faster this is. Does this even solve the problem?
Are we going to next year have another blockwise document that will be even
more aggressive because they want to send even more data over heavy loss?

Francesca: To me, all of these are kind of philosophical questions that are
hard to answer and hard to find a concrete way forward. Again, I would not
block this document based on the charter because in my opinion it is in
charter, and in the opinion of the previous AD it's in charter. We can have a
clarification of the charter if you think it's necessary.

Lars: Let's put the chartering thing on the side, because that we can work
through. I can abstain on it. The bigger problem is that I'm not convinced this
is ready for proposed standard. I didn't look through all of the materials from
previous meetings, but it's not such an old document. I haven't seen any
evaluation being presented for this. I don't know if I missed it. I've no data
to believe that this actually solves the problem they have with the original
blockwise, and has been evaluated for safety in some scenario.

Francesca: What I can answer to that is it went through WG process and IETF
last call. It went through the whole process of getting here. But I understand
your concerns and we should get the authors in the loop and try to work through
this.

Lars: Maybe because it's been hiding in CORE and not been presented in
transport at all. I'm pretty sure if it had come to Transport area they would
have gotten some feedback that asked for the measurements.

Francesca: It did get reviewed by Transport. And the result was, I didn't look
in detail through it, but it was ready with issues.

Martin D: The TSVART review was ready with nits. [audio garbled]

Francesca: So one concrete point I could do is try to get more transport
review. Although I don't know how I would do that except from sending it to the
transport directorate.

Lars: You got a transport review. What I would like to see is whether there's
any experimental data with this mechanism. First that it shows whether it's
actually suitable for the purpose, meaning that it's faster than the existing
blockwise under the scenarios it's looking at, and then also that there is some
indication that they've looked at safety to competing traffic or something else
when it's running in a non-attack scenario, for example. They want to use this
telemetry and they might send it when they're not under attack. Without that, I
think I would be fine if it went for experimental so people could run an
experiment and answer these questions, but that would be another way forward. I
don't think I'd go for proposed standard without that.

Francesca: Okay. My view is that this really makes more sense as standards
track rather than experimental. At least I have some more direction now of what
needs to be done.

Martin D: Yes, we did a TSVART review and obviously at least one Transport AD
waved it through, that would be me. I think both of us were kind of in the
weeds rather than zooming out on Lars's bigger question, which is a good
question, and it happens. Yes we did approve it but I think this is one of
those things where if we'd known this work was going on we probably would have
had you go to the WG beforehand, which would have had richer and more varied
feedback. Luckily Lars was there to catch it. I think there are a bunch of
questions here. One is, if DOTS's requirements have changed, is CoAP even the
right solution? And if not, what is the right solution? I don't think we have
the answer to that either because i'nm not sure anything else we have on the
shelves is the right answer either.

Roman: Ben will correct me here, but ignoring some of the CoAP and transport
issues, in DOTS the two issues are CoAP or RESTCONF? That's the design
constraints of DOTS where they are right now.

Martin D: I recognize that DOTS has an actual use case and it's a little
unsatisfying to say you need to go do a research project for a bunch of years
to figure out how to do this. I'm sorry this comment is not going to emerge
with a clear course of action, but I think we need to have a conversation about
exactly what the requirements are and maybe at the very least they can start by
going to TSVWG and see if they are open to saying here's this other protocol
off the shelf and if you turn these two knobs it will work, or is it too heavy
to have a third transport out there?

Ben: I don't know that I can authoritatively speak for DOTS, but I think if
there was a third transport option that met the requirements we could at least
consider using it. But I haven't really seen evidence that there is such a
third transport option available right now.

Martin D: More minds are better than one, we can take it to the community and
see. There are other things that have different attack patterns, and satellite
stuff. There is stuff out there that might fit. Maybe that's the first step.
Maybe we could take this to the TSVWG, I'm happy to do it, and see what shakes
out. If DOTS is open to some other solution. And if not, maybe a period of
sending this draft through TSVWG while we collect some data. Is that a plan?
Not in a formal last call process, but for a deeper review.

Francesca: I think any way forward is good here. At the same time I feel like
it's a bit disappointing to go to the authors and tell them they've gone
through the whole process and past last call and the IESG sends you back to not
being sure about the motivation. I foresee some frustration.

Martin D: It's a real bummer, you hate to see this. It's an unfortunate thing
in cross-area mission creep, where CORE was trying for something and grabbed
onto something not really IOTish for valid reasons, and then things snowball
from there.

Francesca: I understand, but I didn't see this because to me the DOTS use case
was an example of where this new blockwise could be used. Not the only use
case. Since CORE standardized the original blockwise, I thought this is not
unreasonable that CORE standardizes a version that solves some issues the WG
has identified.

Rob: There's a comment I put into my review. I roughly support what Lars says,
although I don't care so much about the process side, but the question about
whether this is the right thing to be doing. When I was reading the document it
pulled out that this is still somewhat experimental and it's still tied to this
specific use case. It has a paragraph that says it's for this specific use case
and it's not intended for general usage. It also goes on to say that experience
gained with this mechanism can feed future extensions of the blockwise
mechanisms that will both be generally applicable and serve this particular use
case. It does feel to me a bit like that paragraph is saying this is somewhat
of an experiment and may feed into a future version of the blockwise mechanism
that's more widely applicable. So I still wonder whether going down the
experimental path would be a pragmatic way of getting this to progress.

Francesca: I will talk with the chairs and authors to see if they will be happy
with that. The reason why this is here is as I was saying, this was seen as the
basis for a possible blockwise-bis that would obsolete the previous one.

Martin D: so that would actually be the standard, right, if we end up bis-ing
it? I see three possible ways forward. One is to kick this into transport for a
while and poke at it with a lot of experts combing over it. The second option
is to go and get some data. A third option would be just to go to Experimental
to drive data collection. Is that an accurate summation of things that would
solve your problem, Lars?

Lars: I think that would work. I'm wondering how much energy transport would
have to work on this, but you're a better judge.

Martin: I could try to fast track it. I'm just trying to think of possible
things that could resolve this concern.

Lars: The easiest way to resolve this would be the experimental track, because
it doesn't mean the WG has to go back and do a bunch fo stuff, but they need to
be ok with it to be experimental.

Erik K: It might take a long time in transport to "fast track" something that
was a solution, but it wouldn't necessarily take long for something to get a
first pass by all of the attendant experts, right?

Lars: Possibly. I think the first reaction they'll have is ask for the data.
That's what transport people do, they ask how it performs.

Martin D: From a process perspective, yes, the easiest thing to do would be to
make it experimental. From a document perspective, it's fired up for people to
get data, and then when the data comes back we can look at bis-ing the other
blockwise document or this one.

Ben: And to get to Lars's point about whether having this mechanism be
experimental would be problematic for DOTS, I expect that we can convince DOTS
that the DOTS telemetry can also be experimental. We've had some hackathon
experiments, for lack of a better word, that try out with it and they confirm
you can do it and get the data back and forth but there's not clear evidence I
know of that having the telemetry is actually important for efficient
mitigation.

Lars: Francesca, the first bit of my Discuss I will basically remove, given
that I can see how you can read the CORE charter to see this as maintenance. So
that's taken out now.

Francesca: That sounds good to me. I think we have a way forward and I'll
coordinate with Martin to try to bring this to TSV and also with the authors
and we'll be back. I'm happy we have a constructive way forward and thank you
for the discussion. I think this is useful and hopefully we'll also get good
feedback and improve the document. So thank you.

Lars: Thank you and sorry for creating work.

Martin D: Francesca, are you not pursuing the experimental thing and we're just
going to try to get this through transport, or are we doing both?

Francesca: I will talk to the authors, but my expectation is that we will not.
But I will talk to the authors and chairs and see if that's not going to create
problems down the line. I will contact you after that.

Martin D: TSVWG has an interim coming up so we could conceivably grab ten
minutes there. But we can have a conversation.

Amy: So I have this staying in IESG Evaluation, AD Followup.

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

 NONE

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 NONE

3.2.2 Returning items

 NONE

3.3 Status changes
3.3.1 New items

 NONE

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 NONE

3.4.2 Returning items

 NONE

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

 NONE

4.1.2 Proposed for approval

 NONE

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 NONE

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

No news from this week.

Lars: The only thing I would mention is that there's discussion of if the IAB
will start some outreach activity, but there's still ongoing discussion how
this intersects with EMODIR.

Mirja: That's only a small group of people right now, I didn't bring it to the
whole IAB. But if people are interested they can join the discussion of course.

6. Management issues

6.1 Active consent for A/V recordings during side meetings (Lars Eggert)

Lars: Whenever the IETF meeting system is used, and when meetings happen in the
context where people register, like the meeting week, the GDPR requirement of
active consent for recording is given because there is something in the text
you are shown during registration that says you agree to it. The problem is
that the side meetings wiki says that the Note Well applies to side meetings.
Side meetings aren't typically run using IETF infrastructure but they will
still sometimes record the meeting. It was brought up that that's a GDPR
problem because very few people who press the record button actually get active
consent. the proposal is that we would add some text to the side meetings wiki
that says "if you're convening one of these things and you want to record it,
you need to inform all participants that by turning on video and audio they are
being recorded and giving consent." That would get us into the clear legally
and then you'd hope people would actually do it. So basically we're talking
about an extra paragraph being added to the side meeting wiki template. Any
feedback, or should we just do this?

John: Legal thinks that that's sufficient?

Lars: Yes.

John: Okay.

Lars: I'll work with them on exactly what text we want and circle back. thanks.

6.2 Proposed IESG statement on inclusive language (pointing to NISTIR 8366)
(Lars Eggert)

Lars: This is the current feeling in the community in the case of terminology.
I forwarded the relevant emails. The overwhelming desire seems to be to point
to this NIST document instead of chartering TERM to write our own guidance.
That's fine with me if that's what the community wants to do. I said on the
terminology list that I would ask the IESG to put out a statement that
basically does that, and there's text you might have already reviewed for it.
The plan is that once the IESG has made as statement here that we'd send a
liaison statement to NIST that says we used your document in this form, thanks
for making it, so they know we're doing it. People suggested that I also
suggest to the RFC Editor that we add a link to this guidance to the I-D
guidelines, and in Robert's I-D guidelines revision we talked about earlier,
and that I also suggest to all the other owners of RFC streams that they give
the same guidance to their authors, which I will do by emailing Colin and Mirja
and Stephen. That would then put us in a position to abandon chartering the
TERM WG. The question is, has everybody had a chance to look at the proposed
IESG statement and does anybody need more time? Zahed obviously is not with us
so he will need a chance.

Warren: I read it and generally seems really good. My only concern is that last
time we ended up in a bunch of drama because we said "The IESG believes etc"
and I think if we'd said "The members of the IESG" to make it clear it's us as
individuals, not a formal group. I think if we were to do that again in this
document it makes the text more icky but it does avoid the 'who put you in
charge' stuff.

Lars: Sounds like a good suggestion. Do you want to make it in the Google doc
so I can just merge it in?

Warren: I tried but getting the text to flow was tricky. I'll try again and
feel free to edit.

Lars: Okay, will do. My plan is then tomorrow morning my time to put the text
in email to the IESG list so everyone has a copy, and if we're all okay we'll
make it public.

Ben: One other thought about trying to avoid a backlash response, would be if
we want to send a draft version of the statement to a few individuals that we
know have a different perspective than we do to get an advance reaction and
feedback if there are any parts that come across badly.

Lars: That's a good suggestion, let's do that. Let's iterate offline on who we
want to include here.

Mirja: For some statements we ask on the IETF list if everyone is okay with the
statement, but I actually think that's not what a statement is for because it's
usually a statement from the IESG.

Ben: I think asking on the IETF list as a whole is not going to avoid backlash,
it's just going to move the backlash on the consultation instead of the actual
statement. My plan was to just have a couple of hand-chosen individuals who we
know are trying to help and will give us honest feedback without causing a big
storm.

6.3 Boilerplate text change for I-Ds (Lars Eggert)

Lars: This is a suggestion from Brian Carpenter that was floated on the IETF
list. It was triggered by the internet-drafts that we pulled. This was one
suggestion that people seemed to be supportive of in the discussion based on
clarifying that the Internet-Drafts are related to groups associated with the
broader IETF and not just random other people. There were two more proposals
made, one that we should stop serving individual documents from ietf.org until
they're adopted to signal they're not official in some sense, which didn't
really get good feedback. The other was to change the naming more drastically,
so not start everything with draft- but say individual, or adopted, or
something. That also didn't seem to have much support. But this particular
change managed to get that. The question is do we want to it? It's a pretty
minor thing.

Ben: Sorry to spend time on this but I have a grammar nit. The collection of
drafts as a whole is used by the collection of groups, and any given individual
draft is going to be one or the other, most likely, but the "or" there bothers
me for some reason.

Lars: It might say "an Internet-Draft is a working document of the IETF or of
other associated groups or individuals." Would that work?

Ben: That would address my concern. I'd want to mull it over a bit in case it
gives a slightly different connotation.

Warren: One thing that makes it read weird is that we have (IETF) in
parentheses there. Maybe it's just the way it breaks on the line. It just reads
weird. If the (IETF) were removed does that make it less strange?

Ben: I propose we drop this in a Google doc to edit rather than wordsmithing on
the call.

Lars: This is a question for Amy, how do we actually make that change to the
boilerplate?

Amy: That's a really good question. I'm not sure and I'll have to ask. As you
wordsmith this, we will figure it out in the background.

6.4 IETF 111 Session Start Time (Secretariat)

Amy: There's been some email on this but we didn't get an actual decision. The
choices are 09:00 Pacific time and 13:00 Pacific time, and we just need a
decision.

Martin D: We've consistently been in the middle of the day, and I would
encourage us to keep with that model. If we had always been at 9 am in Prague
or Bangkok or whatever, and now we haven't had Pacific time since
not-Vancouver, if you suddenly change it now I don't think that is good.

Francesca: Unfortunately I agree -- unfortunately because I'm going to be one
of those up in the middle of the night.

Martin D: Ultimately I think it's less important to correspond to any
particular time in the local time zone than that we rotate everything by
[about] eight hours each time.

Alvaro: Eventually we're going to get back to in person and it might be more
virtual than in person for a while. Then we're going to want to start at 9.
Having said that, it seems like I might be in the rough as the one who keeps
pushing for 9:00, so maybe we should just move on.

Warren: I'm a little concerned that it feels like by moving the time around
we're optimizing for where the most people are instead of rotating.

Martin D: We're kind of damned if we do, damned if we don't.

Rob: Before we choose one, why have we moved it from 12 to 1? Is that something
we definitely want to be doing?

Mirja: This time slot is particularly bad to have it in July because that's
when the northern hemisphere is in summertime and the southern hemisphere is
wintertime. This was supposed to be the slot that's better for Australia and
New Zealand, and to make it good you have to start at 1 which is like 6 am in
Australia.

Warren: But why are we making it good for Australia and not Africa or
Uzbekistan? We rotate through three places and optimize to the local
participants each time.

Lars: Apologies to the people in Australia but we don't have that many
participants. But we do have a lot of participants in China and the 1:00 is a
little better for them.

Martin D: 12 or 13 is an all nighter in Europe either way, whereas the
difference between waking up at 4 and 3 am is bigger.

Mirja: It's not about how many people are where, everyone should have a chance
to have one meeting at a reasonable time sometimes.

Rob: Before we were optimizing for the local time the meeting would have been
held in physically. Now we're doing one around the world but not that much? My
concern is what's the community going to say to the time we've chosen and how
are we going to justify it, and how are they going to see it as consistent?

Warren: There are a lot of us in North America and Europe, so we've optimized
for ourself, is what the community is going to hear.

Ben: We need to have some kind of reasoning we can point to about why we did it
and what exactly that is is not something I feel super strongly about. It think
the point raised that when we do switch back to in person, we could see this as
a chance to move back to the schedule we would have if we were in person and
gradually make that transition. That's plausible reasoning to me.

Alvaro: It will probably be a lot of people remote at first. Then what do we
do, optimize for people who are not there, or for people who are there? That's
why it makes sense to do it. But maybe we should just do midday like all the
other ones and move on.

Ben: If we do have this mix where some people are in person and others are
mostly remote, are we going to do a six hour day or a nine hour day? A nine
hour day will be lousy for the remote people. But you can't really start a nine
hour day at noon.

John: That's an interesting point. Has this already been covered in SHMOO?

Mirja: I think the Secretariat was thinking about some of this.

Martin D: The day is longer at an in person meeting. You could easily front
load those two hours in the morning for a 9:30 start.

Lars: We seem roughly in favor of the later time. The one thing that was
discussed, I don't know on what call, if we have a hybrid meeting where a
significant number of people are not present but some will be local, it will
still be good to have shorter days because the local people will want to have
social time like they've never had before because they're seeing their friends
for the first time in two years. So a shorter day might work for them.

Roman: Thats a tricky decision we'll have to think about later because that
really begs the question of threshold. If the percentage is 10 onsite / 90
online we should optimize, and when do we decide that?

Eric V: One step at a time.

Lars: It looks like we're 2/3 to the 1:00. Do we want to bike shed on 11 / 12 /
1?

Roman: Can we ask whether anyone would change their mind if we have a 12 option?

Rob: I vote for 12. I'm still concerned that we are optimizing for fairness to
individual participants rather than optimizing for the IETF to be able to get
the most practical work done. I worry whether that's really good strategy.

Warren: +1

Eric V: That's my concern as well.

Rob: Having the most participants able to participate in the meeting seems
maybe better than us optimizing for being fair. I know that seems harsh.

Lars: I'm going back and forth between the two options as well. I don't think
there's a right or wrong decision here, we just need to decide something.

Rob: I'm not sure whether an in person meeting will go forward in the fall or
not.

John: What should we optimize for, is it getting work done or at the risk of
using a bad word, virtue signaling? By the way, I voted for the virtue
signaling.

Lars: Does anybody remember if a previous IESG has made a commitment to
starting at a particular time? For virtual meetings.

Ben: For the virtual meetings, I don't think we specifically promised to do so.
We attempted to be consistent for at least the first three.

Mirja: I think we've used slots between 11, 12, or 1 local time.

Alvaro: We did afternoon slots because we were trying to be consistent. The
first one, 107, where we only had a few sessions, we optimized for some of the
people who were going to participate which was why it was a late start time in
Pacific. Some of the BOFs were specifically people in Australia/NZ who were
going to participate. That's why we made the first one midday and then we just
stayed there. The original justification was fine for that one meeting, but
flawed for the rest. But as I said before, it's probably easier now to justify
that we're going to start midday local time just because we've done it the
whole time. And we can figure out what we're going to do later when we go back
to in person.

Martin D: When you're at home in real life sometimes people really can't do
stuff in the morning to drop kids off at school or the evening for the same
reason, or they can't get away from their day job and they'd like to have an
evening. If I could do this over again I'd say let's just alternate between
0:00, 8:00, and 16:00 UTC and rotate without thinking about time zones. Without
that, using the continental rotation as a proxy for that and staying at roughly
noon local time is the best approximation.

Roman: I hear the argument and support that. We don't know what the future is
going o look like and we don't know how we're going to play the hybrid. To me
that's the argument for a 12 or 1 and not a 9.

Lars: So it sounds like the midday starting time is what we want to go with.
Let's fine tune between 11, 12 and 1.

Mirja: I made a proposal to the SHMOO list that there are three time slots
around the world that are optimized for one or the other participants. This
time slot is particularly bad for the Southern Hemisphere in winter. But that
would be at 1.

Martin D: Can you explain that?

Mirja: Because of summer and winter the difference is bigger. In winter the
time difference is two hours less.

Lars: It sounds like you want to move us away from the 1:00 again.

Mirja: The consequence of what I'm saying is that this time should be the one
that's a good time for Australia and I don't think 5 am is good. That's why I
propose 1, because it's 6 am.

Erik K: Isn't the periodic Asian time zone better for Australia?

Mirja: I'd have to look it up. The three time slots I proposed are not equally
distributed because people are not equally distributed.

Lars: Does anyone want to make an argument for not picking 1 pm?

Martin D: There are a lot in the chat.

Lars: [The slack poll is] 6 to 3 for the 12:00. That would be fine by me too.

Mirja: I don't have a super strong opinion, just providing the reasoning why I
proposed 1.

Roman: I chose 12 primarily on the argument that we're rotating time zones and
tie it roughly to the local time. Starting at 12 means we'll finish mostly in
the business day of the West coast. 9 to 5 or 10 to 6 is the work day.

Mirja: But we've used different starting times in previous meetings. Whenever
we did a time shift forward or back it was to optimize for a non local time
zone. This argument of tying it to the local time zone makes no sense to me at
all. Just because we have been tied to the local time zone over the last 4
meetings we should stick to it.

Lars: In the announcement we can say that we reserve the right to not stick to
it next time. The [slack poll] is slightly in favor of 12.

Francesca: I just want to repeat what I wrote in the chat. Between 12 and 1, I
pick 12, even though it's worse for Australia, because if participants don't
join the whole day but just some sessions at the beginning or the end, this
could work for everybody else as well.

Lars: Okay, 12 noon going once, going twice. 12 noon local time it is. Does the
Secretariat need us to write text of the announcement or do you guys have
something?

Liz: I think these things are generally better coming from you, either the IESG
as a whole or you as chair, since you all are the ones making the decision, not
the Secretariat.

Lars: That's fine. I'll find Alissa's last announcement, stick in in a Google
doc, and you can all look at it and I'll send it tomorrow.

6.5 [IANA #1196393] Additional designated experts for DNS EDNS0 Option Codes
(OPT) (IANA)

Amy: Three people have been suggested to be secondary designated experts for
this registry. Are there any objections to approving these three? I'm hearing
no objection, so we will send official note to IANA and mark this action item
as done.

6.6 IESG Statement on Internet-Draft Authorship (Alvaro Retana)

The IESG reviewed four comments on Alvaro's draft text and finalized the text.

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

Francesca: There is a charter coming your way in the next telechat for a
working group called SEDATE (Serializing Extended Data About Times and Events).
You'll see that next week. It's a charter for a WG that needs to collaborate
with ECMA and ISO 154. I'll probably have questions about liaisons and how to
set that up. Heads up. This was discussed in DISPATCH and there was interest.
It was uncontroversial enough that the proponents just came with a charter and
did not go through a BOF.