Narrative Minutes interim-2020-iesg-26 2020-12-03 15:00
narrative-minutes-interim-2020-iesg-26-202012031500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2020-12-03 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Deborah Brungard (AT&T) / Routing Area
Jenny Bui (AMS) / IETF Secretariat
Alissa Cooper (Cisco) / IETF Chair, General Area
Michelle Cotton (ICANN) / IANA Liaison
Roman Danyliw (CERT/SEI) / Security Area
Martin Duke (F5 Networks Inc) / Transport Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Wes Hardaker (USC/ISI) / IAB Liaison
Benjamin Kaduk (Akamai Technologies) / Security Area
Erik Kline (Loon LLC) / Internet Area
Magnus Westerlund (Ericsson) / Transport Area
Martin Vigoureux (Nokia) / Routing Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Barry Leiba (Futurewei Technologies) / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
Alvaro Retana (Futurewei Technologies) / 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

OBSERVERS
---------------------------------
Darren Dukes
Adrian Farrel
Peter Koch
Brenda Lyons
David Millman
Brian Sipos
Greg Wood

1.2 Bash the agenda

Amy: Does anyone have anything they'd like to add? Any other changes? Hearing
none.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes of the November 5
teleconference being approved? I'm hearing no objection. I saw final narrative
minutes; is there any objection to approving those? Hearing no objection.

1.4 List of remaining action items from last telechat

     o Eric Vyncke to write up draft text on Special Interest
       Groups and send to the IESG for comment.

Amy: This is on the agenda for today; is this done now?

Eric V: I think we should wait until the discussion at the end of this call to
remove it.

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

Murray: I've received some additional feedback from the RFC Editor so this is
crawling along.

     o Alvaro Retana and Martin Vigoureux to draft text on guidance
       regarding the number of document authors on documents.

Alvaro: This is in progress. We've been talking about it and we think we'll put
something on the informal for next week about this.

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

Alvaro: This is in progress. I think we probably want to put this on hold for a
month or two and pick it back up again.

     o Roman Danyliw to draft text for a request to the Tools Team to move
       BoF requests from the BoF Wiki to the Datatracker.

Roman: I'm going to get to that after the FTP thread wraps up.

     o Alvaro Retana, Warren Kumari, and Barry Leiba to draft clarifying
       text on Errata Best Practices.

Alvaro: As much in progress as it was last time.

Amy: Is this something that should be dropped or reassigned?

Barry: It's something we need to get to, for some value of we. I'd like to keep
it.

Alvaro: I agree. We need to get to it, it's just not first on the list.

Eric V: Should we rename the authors to IESG?

Barry: We need somebody to be responsible for it. If we just put IESG, no one
will get to it. I'm happy to leave it as is and keep bothering us every two
weeks.

     o Eric Vyncke to follow up on the suggestion at IETF 108 to share a
       list of grammar checking tools with the community.

Eric V: This is done and on tools.ietf.org. We can remove this item.

     o Martin Vigoureux and Alvaro Retana to work with Jay Daley on the
       process for using EthicsPoint incident management software as
       the mechanism of private feedback and anonymous reporting.

Martin V: We haven't worked on this for a couple of weeks but it's still in the
pipeline.

     o Erik Kline to find designated Experts for RFC  8915 [IANA #1179647].
       - Added 2020-10-05 (3 telechats ago)

Erik K: I still need to find a second expert, so in progress.

     o Alvaro Retana to find designated experts for RFC 8919 [IANA
       #1181014].

Amy: This is on as a management item to approve experts so this is
provisionally done.

     o Roman Danyliw & Ben Kaduk to find secondary designated experts for
       RFC 7107, RFC 7114, RFC 8411, and RFC 8696 [IANA #1181828].

Roman: In progress.

Michelle: Did you ask Sean Turner? That's who Russ had suggested.

Roman: I meant it was in progress but we haven't done anything.

Ben: I sent Sean a note yesterday.

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

Warren: That's actually in progress. We had a meeting yesterday or the day
before and made some progress.

     o Ben Kaduk to find designated experts for RFC 8782 [IANA #1182453].

Ben: This one is in progress. I've heard back from a couple people but still
want to hear from more.

     o Erik Kline to find designated experts for RFC 8928 [IANA #1183445].

Amy: This is a new item for Erik K.

     o Ben Kaduk to find designated experts for RFC 8935 [IANA #1184035]

Amy: This is a new item for Ben.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-idr-tunnel-encaps-20  - IETF stream
   The BGP Tunnel Encapsulation Attribute (Proposed Standard)
   Token: Alvaro Retana

Amy: I have a few Discusses in the tracker for this document; Alvaro, do we
need to discuss any of those today?

Alvaro: I'm going to say no. Roman, thank you for the Discuss just now. Yours
is related to the point Ben is making in terms of the domains, so we'll
definitely address those. Erik is already talking to John about that. I read
Magnus's this morning too and I don't necessarily agree with him but we need to
figure out a better response than this. I don't think we need to talk about it
unless any of you guys want to talk about it right now.

Roman: I don't; mine is fairly straightforward.

Alvaro: Okay. I will need a Revised ID of course.

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

 o draft-ietf-detnet-mpls-over-udp-ip-07  - IETF stream
   DetNet Data Plane: MPLS over UDP/IP (Proposed Standard)
   Token: Deborah Brungard

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

Deborah: I don't think so. The authors and Transport advisor are already
communicating with Magnus, so if Magnus is okay we'll continue to resolve it
that way.

Magnus: Yeah, that's fine.

Amy: Is this going to require a Revised ID?

Deborah: Yes, definitely.

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

 o draft-ietf-ccamp-layer0-types-08  - IETF stream
   A YANG Data Model for Layer 0 Types (Proposed Standard)
   Token: Deborah Brungard

Amy: I have no Discusses for this document, so unless there's an objection it
looks like this is approved. I'm hearing no objection to approving this
document. I have no notes; are there any needed or is it ready to go as-is?

Deborah: We'll need a revised draft. Let's do it as Point Raised.

Amy: This will be Approved, Announcement to be sent, Revised ID Needed and you
can let us know when that's ready.

 o draft-ietf-ccamp-wson-yang-27  - IETF stream
   A YANG Data Model for WSON (Wavelength Switched Optical Networks)
   (Proposed Standard)
   Token: Deborah Brungard

Amy: I have no Discusses for this document, so unless there's an objection it
looks like this is approved. I'm hearing no objection to approving this
document. I have no notes; are there any needed or does this need to wait for a
revision?

Deborah: We'll do it the same, point raised and a revision.

Amy: Okay, so this will be Approved, Announcement to be sent, Revised ID Needed
and you can let us know when that's ready.

2.1.2 Returning items

 o draft-ietf-dtn-bpbis-29  - IETF stream
   Bundle Protocol Version 7 (Proposed Standard)
   Token: Magnus Westerlund

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

Magnus: I think we need to discuss Murray's question about the IETF Last Call
already now on this whole set of documents before we go to Approved here, so we
don't send the wrong message. I'm feeling a bit like it's probably good to Last
Call them again. As you see they've gone through quite a lot of revisions. The
WG is clearly on top of the changes, but it hasn't had an IETF Last Call since
all these changes happened.

Murray: I just mentioned it because this came up on another document and we
were admonished for not being more careful about it. I noticed it, but however
you want to...

Magnus: Yeah, and you're right, and maybe for this reason we should send it
into another IETF Last Call to verify there's no issues with these three
documents.

Murray: Sorry.

Magnus: No, it's fine. We worked on this for ten months, it can take another
month. I think you have to leave it in IESG Evaluation so I can send it back
into IETF Last Call? Then I will report back to the IESG what feedback I got
and then determine if we can go directly to Approved or not based on if any of
it is substantial.

Murray: Is this the right document?

Magnus: You put your comment on another of the documents but you have the same
history and the same state, so if you're Last Calling one we should Last Call
all the three documents. Put it in IESG Evaluation, Revised ID Needed for the
moment.

Amy: We can just leave it in IESG Evaluation, AD Followup, and when you're
ready to Last Call it, it will just go back into Last Call. It sounds like
that's going to be what's happening for each of these three DTN documents?

Magnus: Yes.

Michelle: I should add that for dtn-bpsec, the author has added some
specification required registrations that we've sent on to the experts, so
we're waiting for those expert reviews to come back as well.

Magnus: Okay.

 o draft-ietf-dtn-tcpclv4-23  - IETF stream
   Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4
   (Proposed Standard)
   Token: Magnus Westerlund

Placed in IESG Evaluation, AD Followup until another IETF Last Call as
discussed above.

 o draft-ietf-dtn-bpsec-25  - IETF stream
   Bundle Protocol Security Specification (Proposed Standard)
   Token: Magnus Westerlund

Placed in IESG Evaluation, AD Followup until another IETF Last Call as
discussed above.

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-suit-information-model-08  - IETF stream
   An Information Model for Firmware Updates in IoT Devices
   (Informational)
   Token: Roman Danyliw

Amy: We have a consensus unknown here; I'm going to swap that to yes for you.

Roman: Thank you, I missed that.

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

Eric V: Should it be slightly modified based on comments?

Roman: It needs a revised ID. There's a copious amount of very helpful feedback
the authors should incorporate. It should be Approved, Revised ID Needed.

Eric V: By the way, regarding all those information models, some are in
Standards track and some are Informational status. We do not have consistency
here. Should we put this on the informal telechat? I'd love to get some point
there. I will put it on the informal, whether I'm the only one speaking or not.

Roman: Consistent guidance we can point out [is good], so that sounds great if
we'd have principles about what would elevate it to PS.

 o draft-ietf-anima-grasp-api-08  - IETF stream
   Generic Autonomic Signaling Protocol Application Program Interface
   (GRASP API) (Informational)
   Token: Robert Wilton

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

Rob: Revised ID Needed, please. There's some work required [muffled].

Amy: Great, this will go into Approved, Announcement to be Sent, Revised ID
Needed and Rob you can let us know when that's 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

 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

Alvaro: Nothing to report this week.

Alissa: I have a question in IAB land that affects the IESG as well. We have
this draft text from Warren to liaise with ISO about the codes being proposed
in the private use TLD draft and I didn't see too much feedback from the IESG
on it, but if we send it it would go out under the IESG's name as well. So if
people can take a look at that, that would be helpful. Right, Warren?

Warren: Sounds good. There's likely to be a meeting about it with the IAB to
provide background sometime next week. We'd like review and comment and
feedback and if people have any questions, feel free to poke me. Largely this
is so that we have followed process and there aren't surprises later if ISO
says 'you did what with what?'

Wes: I'm late getting that out to you and I was going to comment about that
meeting next week too, as news that's probably worthwhile. I'd even suggest,
Warren, that if there are other ADs that wish to join that meeting outside of
the ones that are attending, I don't have a problem personally, and I'm sure
nobody else does, if other people want to contribute to that discussion.

Warren: Thank you; I wasn't sure how, if that was an IAB organized thing.

Wes: I have declared it so, so it will be.

Warren: If I might also ask if Ted can join, since he helped convert my random
thoughts into bureaucrat-ese.

Wes: Since he's been helping to author the documents, that makes sense to me.

Warren: Sweet. Is anybody confused? Questions?

Wes: You and I and maybe Suzanne probably have to work together to frame an
agenda for that meeting. Thanks, we're done.

Amy: If anyone's interested in joining that, it's the regular IAB time slot on
Wednesday.

6. Management issues

6.1 [IANA #1181014] Designated experts for RFC 8919 (Alvaro Retana)

Amy: Alvaro has proposed Les Ginsberg and Chris Hopps. Are there any objections
to approving them for this position? Hearing no objection, so we'll send
official note to IANA.

6.2 [IANA #1182453] Designated experts for RFC 8782 (IANA)

Amy: This is just to assign this item to Ben, so we'll move on.

6.3 Special Interest Groups (Eric Vyncke)

Eric V: Thank you Ben for providing some comments on the Google doc. In the
action item here you have the wiki, which is static, and the google docs [in]
which Ben provided two comments. I'd love to get some feedback. One thing, I
was not completely clear about the consensus last time we talked about it, is
whether a BOF is optional, required, or not needed at all to create a SIG.
Remember, we want to create a SIG like a WG, with some extension, but basically
following the rules of RFC 2418 as usual but applying some variation. So for
instance, I'd love to keep the BOF optional, exactly like a WG. It currently
says "creation is required with optional BoF and a mandatory charter." Are we
happy with this?

Ben: I'm certainly happy with that. One could perhaps misread the optional BOF
to say that it can only have one BOF, whereas for a WG you can have up to two.
But I'm not worried about that question.

Eric V: We could say simply "with optional BOFs" if you prefer.

Ben: Sure.

Eric V: Thank you for those comments. The last comment was about Mirja's issue
about having the SIG competing with the WGs. Last time we talked two or three
months ago, we were saying SIG may have lower priority compared to other WGs
during the agenda building so they may end up outside of the normal hours;
competing with the side meetings but on the agenda. So now, SIGs are basically
a special form of WG, but they're really a WG with a charter and everything. In
my opinion, remote attendance should be possible. But Ben, I get your point, if
we are outside of the hours, the Meetecho contract is probably broken and I
will be dead on this point.

Mirja: I think practically, if they request a slot they will get a slot. I
don't think we will be in a situation where we have to move them outside. So
practically I think that will not happen. I still have the concern that we make
the agenda more and more crowded and we should more focus and prioritize the
active work where we work on drafts and RFCs. But I'm not sure how practically
you can prioritize that anyway.

Alvaro: I don't think we can prioritize it practically. The intent here, Eric,
is for this to be in the wiki?

Eric V: Right.

Alvaro: Because if we want to include Mirja's point somewhere around
scheduling, when we get to conflict resolution, if we all know that there's too
many conflicts or we need to move this sIG to a less preferred spot or
something, it's not that we have a specific process to prioritize it, it's just
that we know in the back of our heads that we can do that if we need to.

Eric V: The point of writing this wiki page is that we get consensus right now
with this IESG, but in two, three, four years how many of us will still be
there? To get some consistency among the IESGs. But you have a good point,
Alvaro, except for the chair there will be no conflict resolution.

Alvaro: That's a question that I have. You listed here 'existing IETF
technologies.' Obviously existing IETF technologies means that there's a
conflict with whoever is working on those technologies. So we can't just
deconflict the chairs, we need to deconflict the technology itself.

Mirja: Based on the experience with MOPS, would it be useful to encourage those
SIGs in shorter slots? The 1 hour slots are usually less crowded than the
longer slots.

Eric V: It depends upon the agenda.

Mirja: I would think the agendas are flexible. Usually you have too many
presentations and if you have too many you keep it for the next meeting. You
don't have to have the presentation then.

Eric V: That's a point. Maybe I will simply rewrite this paragraph, saying that
during the conflict resolution special care must be taken that those SIG
meetings do not illustrate less priority compared to other WG meetings?

Warren: I guess it doesn't hurt to add text like that. It seems like the people
who are going to be on the conflict resolution call can decide that for
themselves. The text doesn't hurt but it seems like additional faff.

Mirja: My concrete proposal was actually to give guidance to the chairs that by
default they should only request a 1 hour slot and only if there's really good
reason to ask for more time they should do it.

Eric V: It's no problem to say this. So now, the next step. This is on the IESG
wiki which is public, this part. Do we leave it like this, leave it and declare
it done? Or it's simply a reminder for us.

Alvaro: I think this is enough. I still have that issue with 'existing IETF
technologies' but instead of just 'IETF technologies.'

Eric V: We can change it. My point is that I don't want to get a SIG about
rockets or something.

Alvaro: But we would never charter that.

Eric V: That's a good point. I will rephrase this. Good point.

Mirja: One other question relating to scope. Are we expecting that these groups
to come from the community or is this rather something the IESG proposes to do?

Eric V: In the text it's coming from either from the community or the IESG.
Like a normal WG. I don't think I put anything specific there.

Mirja: I'm asking because I think what we've observed so far on the IoT
discussion and the MOPS discussion is that this is more coming from IESG, at
least the initial proposal, while I'd expect for other WGs to always try to
have them come from the community.

Eric V: MOPS is coming from the community. I was strongly supporting them but
it's coming from Glenn Deen and Leslie Daigle, so it's not coming from me.

Mirja: I'm sorry, I didn't look at the text. Does the text say anything about
how we want to evaluate these proposals? Like which ones should be granted and
which ones not?

Eric V: Like a normal charter, and approval by the IESG. It says nothing else.

Mirja: Because it's easier to say I have this protocol I want to standardize,
and the protocol makes sense and there's a clear use case. While it's much
harder to say I want to build a community around whatever, and it's much harder
to say no.

Eric V: It's not so much about building a community. A community must already
exist. It's simply a forum for an existing community.

Mirja: But how can you be sure that this community is interested to come to the
IETF? How can you even be sure that this community exists?

Eric V: The reason why the determination is basically this is not because we
have exhausted all the milestones and all the work, it's simply because there
is no more interest. Then we close.

Mirja: So basically you would grant any request you get in and see if it
actually works.

Eric V: I wouldn't say 'any,' but the level of entry should be kind of low.
It's also a goal here. We can kill it later.

Mirja: An example, if we get the 6G charter on our table soon, what will we do?

Eric V: Again, whether the IESG and IAB wants to get this charter, and again
the charter will be simpler than a normal WG, like IOTOPS and MOPS. The goal of
this page is basically to avoid the endless discussion about MOPS and IOTOPS
and summarize what we did for those. If the 6G whatever, or 7G is too weird or
too whatever, then we simply don't accept it.

Warren: I think that a large amount of the reason the IETF works is that we
don't constrain ourselves too much with process and policy. If a request came
in for the 6G SIG, or group, whatever we want to call it, and it looked really
good, then maybe we would. If it looked completely crazy then maybe we
wouldn't. But I think trying to, ahead of time, come up with too much structure
simply makes it that we can't get anything done and we end up tripping over our
own feet.

Mirja: But it has two risks. It's also that we get in these proposals and we
can't really reject them without being untransparent or unfair. Because if
there is a reasonable charter on 6G, what's the reason to reject it? What's the
reason to accept MOPS and not accept a 6G group?

Warren: If it's a 6G charter, and it looks reasonable, then you've answered the
question.

Mirja: I think I can write you a really easy 6G charter that looks reasonable.
If it makes sense to the IETF is a very different question.

Warren: Sure, but that's why we have a group of adults look at it and decide,
although I'm not entirely sure we count as adults.

Eric V: And again, it's just a wiki page. It's not binding or a BCP.

Rob: If the IESG wasn't sure about one these there's always the option to push
it to a BOF and see if it finds wider consensus.

Eric V: Rob, I had trouble hearing you.

Mirja: He said we can always have a BOF and see if there's community feedback
on it.

Eric V: Oh yeah, of course.

Mirja: I think my concern stays. I'm concerned that it's much easier to say no
to these if we accept them from the community because it's not that you have to
do protocol work but I'm also not sure. I also see some value in this so maybe
we should try it. But it's a standing concern.

Eric V: Okay, let me get another hash on the google docs. I'm sending it to the
IESG and Mirja you are on the list of course. If I don't get any comments by
the first of January I will paste the google doc into the wiki page. If you
[plural] object, we stop.

6.4 Session Lengths for IETF 110 (Alissa and Liz)

Amy: Session requests open on Monday so Alissa and Liz wanted to talk about
session lengths.

Alissa: Greg is with us and he's able to screen share the survey results about
this.

Greg: Here are bar graphs; the scale is very dissatisfied to very satisfied.

Alissa: The main thing we really need is just the 60 and 120 minute session
lengths. When we looked at the initial results, there seemed to be a high
degree of satisfaction with the 60 and 120 minute session lengths. Jay and I
and Greg and Alexa looked at them earlier in the week and I think if we're
looking at this, that's still the case. The green bar is the session lengths so
we seem to have a high amount of satisfaction with the session lengths.

Mirja: The question was "How satisfied are you with session lengths?" Not a
comparable question about which did you like more, last time or this time?

Alissa: Correct. We have the data from the previous time so we can compare it.
We don't have that today, but it exists. My sense of this is that we don't have
a reason to change from 60 / 120 minutes.

Mirja: My personal impression was that this worked a little bit better. Meaning
less meetings ran out of time.

Roman: The WGs I was in, these time slots seemed to work well.

Alissa: Okay.

Eric V: I'm looking at the graph and I see some people are dissatisfied with 8
parallel tracks. Too many tracks?

Alissa: We don't have to decide that today. The only thing we need to talk
about today is the length of sessions because that's what WG chairs need to
indicate in their requests. We'll get the full results back and have a later
followup to talk about other meeting planning things.

Mirja: We offer 1 our and 2 hour right now. Would there be an option to have
1.5 hours or would that not fit in the schedule?

Liz: It's really hard to tell before we get all of the requests in. At a normal
in-person meeting we have the three options and the schedule ends up being
whatever fits all of the requests we get. It's difficult to predict what adding
a third option would do, especially if we're trying to keep the days shorter
than we would at an in-person meeting.

Mirja: But if we offer 1.5 hour option and we only get a few of them we can
always put them in a 2 hour slot, right?

Liz: Sure.

Wes: One interesting observation with this data is that people are generally
happy with the length of the sessions and they're generally happy with the
length of the 30 minute breaks but they're sort of leaning on the other side
toward thinking the day is too long, which means you can't have both. I felt
like that too, it would be nice if we could shorten this to ease the pain but
if you're happy with the session length and you're happy with the break length
then there's not much else to compromise on to make the [satisfaction with
overall length of each day] better.

Mirja: There's a third dimension which is the number of days.

Wes: True. The five day meeting people were generally happy with too.

Alissa: Overall length of day, there's still high satisfaction with it.

Wes: It's not bad, but the purple lines are longer on the lower satisfaction
bars because people would prefer a shorter day. Not by a huge margin but by
enough. But at the same time they're happy with the session lengths.

Martin D: It's also a particularly bad time zone for a lot of people, so I'd
expect the satisfaction there to be lower in the middle of the night.

Mirja: But having a 2 hour, 1 hour and 1.5 hour slot to shorten the day by half
an hour, maybe could make a huge difference so maybe it's worth trying.

Alissa: But whether it leads to a shortening of the day is not clear.

Mirja: No, but if we get enough requests we maybe could. We could ask chairs to
request the shortest time slot possible for their meeting.

Alissa: What TSVWG did, running through the whole break, I don't want that to
happen again.

Mirja: There was a Meetecho interruption too.

Martin D: That wasn't the issue though. Even though there was an interruption,
the first day's agenda was completed and the chair decided to keep going.

Alissa: So we want to give 60, 90, and 120 minute options and see what we we
get back?

Mirja: I'd give it a try.

Martin D: If we get a small number of 90 minute requests we can give them 2
hours and we're back where we started. Whereas if there are a couple of days we
can shorten by having a slot be 90 minutes, that's good.

Alissa: I suspect what actually happens is that more groups would move from 60
to 90 than from 120 to 90. I don't think this would end up in a shorter day
because people don't think about the impact on the whole day when they request.

Martin D: That's a good point. I think you're right; maybe this option would
make our day longer, not shorter.

Mirja: I see that risk but maybe we could just send an email to the WG chairs
asking them to use more interim meetings.

Alvaro: I thought we started by saying that most of the sessions didn't run out
of time. If that's true, I'd think that the guys who got 1 hour are ok with 1
hour. This is not a matter of life and death for me but I wouldn't go with 90
minutes, I'd go with the same 1 and 2 hours.

Ben: I tend to agree. On the personal side of things, I've heard a slight
demand for a 90 minute slot but the data we have suggests it's better to stick
with the 60/120.

Mirja: I like Eric's proposal that we only offer 90 and 60 minutes and people
who need 2 hours have to request 2 slots. That might encourage people to be
conservative about it.

Warren: A lot of people who have 120 minute slots use most of it. Having people
ask for more slots feels like we're penalizing people who are getting work done.

Liz: That can also make deconflicting really challenging, because if a lot of
popular groups want two slots each that just means everyone is twice as
conflicted trying to get to both sessions.

Mirja: What I was suggesting would not make a practical difference, if someone
requested two 1 hour slots we give them one 2 hour slot.

Liz: We already do that. We did it several times at this last meeting.

Barry: I have two WGs who generally request 2 of the longest slots they can
get, and they use that time effectively.

Mirja: I do have to question if all this work needs to be in the IETF week or
if you could split up some of it into an interim.

Alissa: That's more of a generalized guidance we're giving to people anyway. It
worked really well this time, maybe we should just go with what's working well.

Mirja: I'm fine with it as well. I just got the impression from chairs that
they requested the same kind of slots they would for an in person meeting
without changing.

Martin D: I'm reluctant to use these tools to try to socially engineer what
people should do with their sessions. We can send an email asking to do
different things but we should stick with this system. Given how disgruntled
the population usually is, this seems like an outstanding success.

Alissa: Okay, so we're going to go with 60 and 120.

Liz: Sounds great; thanks everyone.

6.5 [IANA #1183445] Designated experts for RFC 8928 (IANA)

Amy: We assigned this item to Erik K at the top of the call.

6.6 [IANA #1184035] Designated experts for RFC 8935 (IANA)

Amy: We assigned this item to Ben at the top of the call.

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

Murray: Barry and I wanted to ask Sandy something about the BCP 14 stuff.

Barry: What's the status of it; how many documents are still pending BCP 14
reviews by the authors? Do you need anything from us at this point or are we
still waiting for you to get back to us?

Sandy: After we sent the last reminder, a good handful of authors replied. I
just need to update the list and see where we are at the moment. I can send
that within a few minutes after this call.

Murray: There's also one that wasn't approved by me but there's an approval
date. Just let me know if I need to do something on that one. I can send you a
message with which one it is.

Sandy: Okay, thank you.

Murray: That's it, thanks.

Alissa: I have one other thing. I was just looking at the list of documents
with outstanding Discusses, which have been in that state for a long time. On
the informal next week would it be useful for us to go through some of these
together and see what's necessary to clear? The number of these that seem like
the authors may have been waiting for a while is getting to be long. Would
people be up for that?

Barry: That sounds like a good use of informal time.

Magnus: We'll have a really long informal next week.

Warren: It does seem like a good use of informal time. Maybe we should try and
do that more often, once every five or six informals we have it dedicated to
this. That's a really good idea.

Alissa: I'll start a thread, and if you have specific documents you know you
want us to talk about, respond to the thread and list them. If the docs haven't
been updated it's obviously a waste of time. We don't have to go through all of
them, but I'll go through the list and look for ones that seem like it's
inaction on our part.

Eric V: It should be the responsible AD who's more familiar with the documents.

Alissa: I'll start a thread and people can reply with ones they want to talk
about, and if some of you don't suggest any I might suggest some for you based
on what I see from looking at it. I did this project for myself last week which
is what triggered this.

Martin D: Certainly if we don't clear some of these then we're going to end up
with conditions expiring, so getting this done before is very valuable. Thanks.

Alissa: Thanks.

Amy: I have one reminder. The informal next week, we've invited Ignacio Castro
to give his talk about RFC authorship. I'll confirm with Colin that he'll be
there as well to introduce Ignacio.

Warren: I don't know if we normally record informals, maybe we could do it for
this one and decide later to share it?

Amy: We do generally record the informals, yes.

Warren: If it seems like something that would be of benefit to the rest of the
community to share, maybe we could discuss it.

Amy: We could trim the recording to just that piece.

Warren: Just a thought. We can decide after.