Narrative Minutes interim-2020-iesg-25 2020-11-05 15:00
narrative-minutes-interim-2020-iesg-25-202011051500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2020-11-05 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
---------------------------------
Adrian Farrel
Olivier Gimenez
Mike McBride
Rich Salz
Mohit Sethi
Barbara Stark
Greg Wood

1.2 Bash the agenda

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

Rob: Yes please, can we have an executive session at the end to discuss some of
the emails on ietf@ please?

Roman: Can I also have a slot, not an executive session, to make sure we button
up everything on the FTP plan?

Amy: We'll add both of those, thank you.

1.3 Approval of the minutes of past telechats

Amy: Is there any objection to approving the minutes from the October 22
telechat? Hearing no objection. Any objection to approving the narrative
minutes from October 22? Hearing no objection. We'll get both of those posted.

1.4 List of remaining action items from last telechat

     o Warren Kumari to work on acknowledging shepherds, directorate
       reviewers in a more standardized/formal way.

Warren: I still think it's useful, but seeing as I've made no progress in a
long time, I'm inclined to drop it. I think it was largely just a suggestion
that people should say at the end of their draft 'thank you very much to X and
Y for having helped with the review,' etc. But I haven't done anything. Is this
worth still pushing?

Eric V: Happy to drop it.

Warren: Okay, I guess let's drop it.

Amy: Okay, we'll drop that from the list.

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

Eric V: Still a work in progress. I sincerely hope next time it will disappear
from the list.

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

Murray: I met with Alvaro last week and I've been exchanging messages with
Sandy because they have additional feedback about things like stable references
that they would like to add. This is progressing and I expect to have something
to the IESG to review in the next day or so.

     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 have an outline of what we want to do.

     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: I'm going to say this is in progress. We put it on hold a little bit
pending some other work.

     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: Still in progress. Robert reminded me earlier this week that I need to
pick this up.

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

Alvaro: This is in the same state as last time we talked about it.

     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: In progress still.

     o Roman Danyliw and Murray Kucherawy to find designated experts for
       RFC 8894 [IANA #1177950].

Murray: I have one. I notice the request is for experts plural. Michelle, do
you need two or is one good enough for this one?

Michelle: Let me check on that and I'll get back to you.

Murray: Should we put a management item at the end to dispatch with this, or do
you want to wait until we have multiple?

Michelle: If we have one expert we should get them designated, we don't have to
wait.

Murray: Should we do it at this meeting?

Amy: Unless anybody objects to the person you're going to name, I think we can
just put it on at the end and we'll find out when we get there if someone
objects.

Murray: Okay. And same for the next one, I have one there too.

     o Murray Kucherawy to find designated experts for RFC 8876 [IANA
       #1178766].

This is being placed at the end of the telechat as a management item to approve.

     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: In progress. We're moving to step two of that work item so we've
identified a subset of things we could report through the tool. We'll be
working on generic descriptions of those and provide the list to all of you for
review. It's progressing.

     o Barry Leiba to draft a policy about when to create and announce
       mailing lists for new potential Working Groups in order to
       facilitate discussion of the Proposed WG charters.

Barry: This is done.

     o Erik Kline to find designated Experts for RFC  8915 [IANA #1179647].

Erik K: This is still in progress.

     o Barry Leiba to write up a request for change in the Datatracker
       behavior to automatically move a document to the state
       IESG Evaluation when the document ballot is issued.

Barry: This one is also done. I posted this to the IESG list and after this
call I'll send it to Robert.

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

Amy: There's a new management item to assign this to you today, Alvaro.

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

Amy: This is also a new management item today.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-babel-source-specific-07  - IETF stream
   Source-Specific Routing in Babel (Proposed Standard)
   Token: Martin Vigoureux

Amy: I have quite a number of Discusses in the tracker. Do we need to discuss
any of those today?

Martin V: I think the authors are pretty much on top of everything. One that I
wanted to rapidly discuss was Rob's. I think it's not a bug, I think it's a
good catch. If you look at Ben's comments, you'll see that it might simply be
resolved by some clarifications. Also if you look at 6126bis you'll see that
prefix can refer to the prefix itself or to both prefix and prefix-len tuple. I
fully agree with you that this is confusing, so I believe that can be easily
resolved. Since nobody had replied I wanted to rapidly give you some background.

Rob: That sounds fine with me. I agree it should be easy to resolve.

Warren: I think Alvaro and I had fairly similar concerns. The authors replied
via email but I think there's going to have to be a bunch more text in the
document describing how this should actually be used and deployed.

Martin V: Yeah, I didn't mean to say that everything had been addressed. I
meant to say that it will be addressed, but considering how effectively the
authors are already replying, they ultimately will address it.

Warren: What I'd understood from the authors was that [they thought] we didn't
understand what they wrote and they think it's done. I have not replied to them
yet.

Martin V: If you have that feeling, and if you think more clarification is
needed, I hope you will reply.

Warren: Yes, I will.

Martin V: Thank you very much. So this one will require a Revised ID.

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

 o draft-ietf-i2nsf-sdn-ipsec-flow-protection-12  - IETF stream
   Software-Defined Networking (SDN)-based IPsec Flow Protection
   (Proposed Standard)
   Token: Roman Danyliw

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

Roman: We do not. I want to thank everyone for the reviews. The feedback looks
entirely appropriate and the authors will work it. I also wanted to acknowledge
that the Yang doctors process was really phenomenal. They provided a really
great review on this and got a good iteration on making sure this module was
more generally useful. It's a great service to the community. Plug for the
directorate reviews.

Ben: I did want to jump in. My first point was about having vendor specific
functionality in a Standards track document and I kind of suspected that there
was some precedent here and I just wasn't remembering it. If anyone does
remember having vendor specific stuff, like linux kernel specific stuff in a
standards track document, please speak up. If not, we should move on.

Mirja: In 6man there was an interface document which was quite specific. But I
didn't read this document so I'm not actually sure what you're asking for.

Roman: Don't we make all sorts of vendor-specific carve-outs for stuff? For
some of the teep documents, we do it all the time, and don't we say we're doing
it so because that's how the world is currently running the code?

Mirja: We also have a set of documents where we say this is Company X's method
for it. That's usually informational, which is not what you're looking for.

Roman: Is that what you're looking for?

Ben: I think we can assert RTO and move on.

Roman: Excellent review, everyone. The authors will respond. Revised ID Needed
please.

 o draft-ietf-dots-server-discovery-14  - IETF stream
   Distributed-Denial-of-Service Open Threat Signaling (DOTS) Agent
   Discovery (Proposed Standard)
   Token: Benjamin Kaduk

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

Eric V: By the way, I just cleared my Discuss right now.

Ben: I was checking just five minutes ago and it was still there. We will need
to hold this one in AD Followup because there's some IANA stuff that still
needs to arrive, and I need to look through all the comments.

Magnus: Question here. The comment I had, I didn't like to put it in a Discuss
but I hoped you could at least look into the security considerations on .local.
Maybe it needs a little bit more forward with that, especially if you're using
mDNS you don't have the same security as if you're using a regular DNS,
especially with DNSSEC.

Ben: I will definitely take a look at that before pushing the approve button.

Magnus: Thank you.

Amy: So I'm hearing this is Approved, Announcement to be Sent, AD Followup
until you let us know it's good to go, Ben.

 o draft-ietf-sfc-serviceid-header-12  - IETF stream
   Service Function Chaining: Subscriber and Performance Policy
   Identification Variable-Length Network Service Header (NSH) Context
   Headers (Proposed Standard)
   Token: Martin Vigoureux

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

Martin V: I think Mohamed is pretty much on top of it. I think there are very
valid questions. The thing is that I can't help thinking if that hadn't been
called a subscriber ID, we wouldn't have had that discussion. So I'm very
sympathetic to all the comments, but I think you need to view that as a generic
identifier and it's not pointing to specifically someone. That's why I think
Med calls it opaque.

Alissa: There's text early in the document that contradicts that, isn't there?
Or maybe I just didn't understand it. It talked about IP addresses, to put the
private IP address on the subscriber side in the NAT and then it talks about
other mobile network identifiers.

Martin V: But I don't think it says specifically how you derive that
identifier. The whole document is about transporting that and using it in an
NSH context.

Ben: Yes, but in the past when we've had protocol mechanisms that give examples
of using it for this or that, where there are particular concerns about those
use cases that are given as examples we still need to make sure those security
considerations are covered.

Warren: This document does imply that that's the right thing to do. I think
that's part of the concern.

Roman: Maybe I misunderstood but I thought one of the use cases noted was
lawful intercept, which seems like it's the user.

Warren: Yep. To me a little bit of this feels like this is similar to another
document, we didn't really define this thing but here's a way you can propagate
it that feels like it's implicitly approving it.

Roman: The way I read it is it seems like we're putting a marker inside every
packet to tie it to a user for further inspection by someone down the chain. I
think we have to talk about that and put some text in there, maybe.

Deborah: I said they should really clarify this. Even lawful intercept, that's
not done low in the chain at this level. They really have to clarify what they
mean by subscriber information. It doesn't make any sense to me at that chain
level.

Martin V: But subscriber information is something that exists already in the
access. Maybe I'll let you have that discussion with Med but it's not creating
something that doesn't exist. It's simply using information that exists to
apply policies or whatsoever, exactly as the other identifier does.

Warren: That sounds a little bit like the 'guns don't kill people, people with
guns kill people' argument. The fact that it exists is one thing, the fact that
it exists and you're using it and propagating it is  different and more
dangerous.

Eric V: If we go this way, I see it much like the flow ID in IPv6 header.
Something that's opaque that's meaningless, that no observer really can know
what's inside and apply any semantics to it.

Ben: The flow ID is only 20 bits, and this is definitely allowed to be longer
and we explicitly suggest that it might use these longer-lived identifiers. I
agree with Martin that yes, the information is already present in the access
network, otherwise it wouldn't know what information to add to the packet in
the header, but having it be sent around to more places and longer lived in the
life cycle of the packet does make there be different considerations and we
need to document those, at least.

Alissa: Also, even if it is opaque, if it's derived from the same identifier
and therefore it's persistent and unique, it creates a vector for linkability
for anyone who gets access to it between when it's inserted and when it's
removed. So there's still an additional concern even if the identifier itself
doesn't have a semantic that a passive observer can glean.

Martin V: I could argue that IP addresses are also a way to identify a user,
and those are in every packet. But I understand your point, and I'll work with
the authors to address your concern.

Ben: Thank you.

Amy: Okay, it sounds like this is going to require a Revised ID. This will go
into IESG Evaluation with Revised ID Needed.

 o draft-ietf-idr-flow-spec-v6-19  - IETF stream
   Dissemination of Flow Specification Rules for IPv6 (Proposed
   Standard)
   Token: Alvaro Retana

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

Alvaro: I think the authors have already talked with Ben. I'll let them figure
that out. Eric, I just saw your response from a little bit ago. I'm not sure
exactly what you want us to do. You said you don't understand the motivation of
the WG. Are you expecting us to add extension headers to port here?

Eric V: What I really fail to understand is that they are able to specify 'I
want to follow all the extension and the chain until the upper layer protocol,'
which is very complex. This specified the behavior but they do not specify the
behavior within the 40 bytes of the IPv6 header. I always look in the same
place to find the next header. I'm completely lost why they cannot specify the
feature to look at the easy one, and to specify something many hardwares,
including my employer, is unable to do.

Alvaro: What we're trying to do here with this spec and with 5575bis is to
catch up and show what is already implemented. IDR requires an implementation
for everything. According to our implementation report, everyone, Cisco,
Huawei, Juniper, supports this already. We can go back and add more support. 
What that means is that because this is IDR, we're going to wait for
implementation of that. Among other things, it's not a problem. We are holding
5575bis, which is the IPv4 part. I don't want to hold that any more because if
we need to wait for implementations again it might take a long time. The other
part of this is that we probably won't get implementations because the WG is
already working on flow spec, I guess we're calling it version 2, which is one
of the issues that flow spec now is that it's not really extensible and adding
other things is really really hard. So what that means is that probably
whatever it's going to do is, if they're going to go do extension headers in
IPv6, is do it in flow spec version 2. In other words, we can either progress
this as a reflection of what's implemented or we can not progress it.

Eric V: I still want to get confirmation from the authors about the exact
behavior. Again, I'm pretty sure some Cisco devices are unable to do exactly
what they do and so saying Cisco can do it, I get a mismatch. Maybe we are the
only vendor unable to do it, that may be the case why it's not possible to do
the thing. After an explanation either way I will change position. I will not
block for this.

Alvaro: I don't know if they know all the details of the implementations but
there's a link there to where the implementations are documented. But sure,
let's wait to see what Chris says and go from there.

Eric V: Okay. I don't expect to hold my Discuss for more than a couple of days.
No more blocking.

Alvaro: Sounds good, thanks. So we're going to need a Revised ID for this one.

Amy: This will go into Revised ID Needed, thanks.

 o draft-ietf-lpwan-schc-over-lorawan-13  - IETF stream
   Static Context Header Compression (SCHC) over LoRaWAN (Proposed
   Standard)
   Note: AD has checked with authors whether the Lora Alliance has
   reviewed this document: yes, review done.
   Token: Eric Vyncke

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

Eric V: Let's put this in Revised ID Needed; we need to address a few minor
comments.

Magnus: Question here. Do you know the answer to my question, when will there
be something that establishes the contexts for schc?

Eric V: On this one?

Magnus: Or any of them. So far all the documentation in the WG has been to
totally, no, should we establish the context here? No, we don't tell anybody
how we do it.

Eric v: Indeed, there is no way in lpwan or the schc document, they do not
establish the context. They assume it is done in outside means. In provisioning
or something like that.

Magnus: It seems to be a significant missing step if you're going to have
interoperability. Or is everyone deploying inside the particular link
technology that they assume they can configure all the devices they put down,
including rule sets that matches the gateway implementation at the end points?

Eric V: That's indeed my understanding. I'll need to review the overall schc
document to be sure. We can continue this discussion at some point in time.

Magnus: It's just that interoperability for this work seems to be a little bit
lacking in that aspect, about the context establishments and the lack of it in
the description of any example of how a protocol actually does it.

Eric: I linked to the specific lorawan case, it's global to all the schc
documents.

Amy: This is going to go into Approved, Announcement to be sent, Revised ID
Needed and Eric, 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-babel-information-model-11  - IETF stream
   Babel Information Model (Informational)
   Token: Martin Vigoureux

Amy: I have an Unknown consensus, I think we'll change it to Yes.

Martin V: Sorry about that, yes.

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

Martin V: No, I don't think so. I think it's important to resolve it. The issue
is that Barbara is also Nomcom chair so she might not have a lot of time to
dedicate to this. I'll check in the WG who can effectively be responsible. In
any case this will require a Revised ID.

Amy: This will stay in IESG Evaluation and go into Revised ID Needed.

 o draft-ietf-acme-email-smime-10  - IETF stream
   Extensions to Automatic Certificate Management Environment for
   end-user S/MIME certificates (Informational)
   Token: Roman Danyliw

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

Roman: We can continue to talk about the rest of them but the only one I wanted
to address was Barry's, about Informational vs PS vs Experimental.

Barry: I wanted to discuss that as well.

Roman: I think primarily the pitch for Informational is that the WG generally
feels if we don't have widespread adoption of said practice it's informational.
In this particular case this is *a* way to do the S/MIME issuance, but it is
not the collective *the* way across all those folks issuing certificates. So
when we danced around this particular question it was largely around going
Informational.

Barry: This is not a proposal for a standard.

Roman: It feels like a semantic thing you're embedding in there, can you talk
me through it?

Barry: Well, the Proposed Standard says we're proposing a standard. That's what
this document feels like to me. If the WG thinks they are documenting one way
of doing something it should be a little more explicit that there are other
ways to do it and we're just giving an example or something. The way that reads
to me is a a proposal for a standard. I don't feel hugely strongly about this
but I wanted to have the discussion.

Roman: That's fair. I can talk with the authors to put something a little more
soft that there's a broader discussion amongst CAs about how to play it, and
this is an approach.

Barry: Okay.

Ben: I think that's similar to the expectations I had when reading it. In
particular, in the broader ACME field of things we've had a few iterations of
challenge types that ended up not actually being a good idea, because we don't
know how this is going to interact with the different CA policies and we don't
necessarily have a huge amount of experience or review on it, trying to say
that this is something that might become a standard feels premature to me.

Barry: That to me says Experimental. That's why I said PS or Experimental. I
guess let's see where we get with the discussion with the authors or the WG.
The document does not read like Informational to me, it reads like it's some
sort of proposal for 'let's try this' or something like that. I'm not going to
hold out on this, I just want to have the discussion so let's see where it
goes. The other thing, Alexey has not been extremely responsive. He responded
once and I'm waiting for him to come back on the DMARC issue. So we'll see
where that goes. I'm really confused about what DMARC is expected to do, what
benefit DMARC is expected to provide for this particular thing.

Murray: He just replied in the last half hour or so; there's something in your
inbox.

Barry: Cool, I will go look at that.

Ben: I just want to call out Barry, thank you for taking that issue on. I
appreciate that you're doing it which means I don't have to.

Roman: It's definitely Revised ID Needed, and let's leave it in IESG
Evaluation. I know Alexey has been quite busy so he's doing his best.

 o draft-ietf-suit-architecture-14  - IETF stream
   A Firmware Update Architecture for Internet of Things
   (Informational)
   Token: Roman Danyliw

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

Eric V: If you don't mind, I'd like to thank Mohit Sethi, who has been the IoT
Directorate reviewer and an observer on this call. Thank you Mohit.

Amy: I don't see any notes in the tracker; Roman, are any needed?

Roman: I think there are a number of good items of feedback in the comments I'd
like the authors to fold in. If we could mark this Revised ID Needed after
approval.

Amy: Great, you can let us know when that's ready.

 o draft-ietf-emu-eaptlscert-06  - IETF stream
   Handling Large Certificates and Long Certificate Chains in
   TLS-based EAP Methods (Informational)
   Token: Roman Danyliw

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

Roman: Barry, are you good with my response on the status on this one? Either
way we're going to need a Revised ID, but since we're on the call here if you
wanted to talk about that [we can].

Barry: I don't recall your response. Can you summarize?

Roman: Pretty much you were asking about why it's Informational as opposed to
BCP and my response was there are a lot of different things summarized in this
document, it's primarily taking field experience and talking about both the
future and implementation, so there's not really a one size fits all of
normative behavior. It's more saying this is a problem and here's a menu of
different things for different audiences and no one individual implementer can
take it all, it's very situationally dependent, and that's why it's
Informational.

Barry: I don't recall receiving that response, but that's fine. My comment was
non-blocking, so I'm good with that.

Amy: Sounds like this will go into Approved, Announcement to be Sent, Revised
ID needed.

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 NONE

3.2.2 Returning items

 NONE

3.3 Status changes
3.3.1 New items

 NONE

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 o conflict-review-huitema-rfc-eval-project-00
   IETF conflict review for draft-huitema-rfc-eval-project
     draft-huitema-rfc-eval-project-07
     Evaluation of a Sample of RFC Produced in 2018 (ISE:
   Informational)
   Token: Alissa Cooper

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

Alissa: Great, thank you.

3.4.2 Returning items

 NONE

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

 o Open Specification for Pretty Good Privacy (openpgp)

Amy: I have no blocking comments so unless there's an objection, this is ready
to go for external review.

Ben: I'm noting in the datatracker Eric has put in some comments I haven't seen
yet. Should I try to make changes based on those comments before external
review?

Eric V: I think it would be better. They are very simple.

Ben: They look like it. Amy, how about we put this in AD Followup?

Amy: It will be approved pending the edits, so we'll wait for you to tell us
you've made the edits and it's ready to go.

4.1.2 Proposed for approval

 o Secure Media Frames (sframe)

Amy: There are no blocking comments for this charter, so unless there's an
objection now it looks like this charter is approved.

Murray: I just wanted to draw attention to Barry's comment, where he was
curious about whether this should be chartered in SEC instead of ART. I don't
know if the SEC ADs have a comment about that. I'm comfortable with either.

Roman: My general feeling is that I can see it staying in ART primarily because
of how closely it's tied to those remaining protocols, and it seems like that
expertise is there and we can bring the necessary SEC expertise to that
discussion which is already somewhat present.

Ben: It needs integration with the WEBRTC type stuff and most of the crypto
going on here is going to be fairly standard integration. There might be a
little bit of complexity with the MLS schedule but I'm pretty sure we've got
the right people from MLS who are going to be in the room. On that note though,
I wanted to check -- in my comment on the previous version I had something to
note about how in the text we say there might be some extra work for adopting
the MLS key schedule to SFRAME. I'm pretty sure that doesn't preclude using
other sources of keys, I just wasn't sure if there was anything else to say
about whether there are cases where similar work would be useful for other
sources of key material or if there's just going to be a base version of SFRAME
that will work with most simple sources of key material and MLS is just special
because it's more complicated.

Murray: Hmm, what to do with this. What do you suggest? Is there a sentence or
two we should add to this effect before we go forward?

Ben: I think if I was going to add anything it would probably just be something
about doing the work with MLS does not preclude integrating with other sources
of key material. Something like that.

Murray: I can work with you on adding something like that as long as it's
innocuous, since we're right at the end of the approval process. Unless someone
else objects we can just do that.

Ben: I'm happy to work with you and find something innocuous to put in.

Amy: Okay, so for the charter for this, is this approved pending edits?

Murray: What I just got from that is Ben and I will add one more sentence to it
and then we can move it to the next state once that edit has been made.

Amy: Okay, and the next state is creating the WG, so it will be out of the nest.

Murray: Which is perfect since this has a slot at 109. Thank you.

Warren: Just so folks know, we're not moving the IOTOPS charter forward quite
yet. There were a few people who felt they hadn't been consulted on the charter
text, so we've opened it for a wider discussion with the IOTOPS list. I just
wanted to let people know we haven't forgotten it.

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: The IAB is organizing a COVID-19 network impact workshop next week.
It's divided into three parts. If any of you are interested in attending,
please let Stephen Farrell know so he can add you to the list and you can get
the agenda.

Mirja: Those three sessions are Monday, Wednesday, Friday at 2 pm UTC time.

6. Management issues

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

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

6.2 [IANA #1180363] renewing early allocations for
draft-ietf-grow-bmp-local-rib (IANA)

Amy: This had some early allocations coming up for renewal. The AD for the
document is Warren.

Warren: I would like approval for this. The document is about to show up on the
IESG eval. At least the chairs say they're about to send it to me soon. So I
believe this should be approved.

Amy: Is there any objection to extending the early allocation which will expire
in the early part of December? Hearing no objection, so we'll call that
approved and we'll send an official note to IANA.

6.3 Proposed schedule for BOF approvals for IETF 110 (Alvaro, Alissa)

Alvaro presented a slide deck with a proposal to change the BOF proposal and
approval process to be on a one-month cycle, where there are monthly proposal
deadlines to encourage a continuous cycle.

Martin D: What is the incentive for a BOF proponent to try to meet this? If I
want to have a BOF at 110, what is my incentive to make the December review
rather than punt until February?

Alvaro: Ideally, what we see with a lot of proposals is that with a little more
time we got better proposals. The incentive for you to propose something in
December and not wait until February, for example, is that ideally you might
get more time with your AD, with an IAB shepherd, etc, that will make the
proposal better. Whether it's December or January. Ideally it will give you
better odds.

Barry: That's assuming people get things in earlier. What we found this time
was that having the preliminary deadline for them to get it in so we could
review it more and discuss it with them didn't happen. They just didn't do it.
Two deadlines ends up being effectively one deadline. I'm certainly willing to
try it but if people do put in their proposals early then we need to get calls
with the IAB more frequently, which will be logistically difficult.

Alvaro: Maybe the proponents wait until the last cycle. Ideally we would
complete the cycle before the session request deadline happens. In other words,
if the IETF is in March, proposing something in February might not make it to
the next IETF.

Ben: Have we considered virtual BOFs for any of these cases?

Alvaro: I think that's something the AD has to eventually decide. Right now
we're all virtual anyways. So yes, there would be a difference between having
it during the IETF week or some other week in between meetings. That would be a
call the AD can make. If you're approved in December you can wait until the
next IETF to have it.

Martin D: I think what I'm hearing is that a single proposal might be the
subject of multiple BOF coordination calls in a cycle. I think that feature is
important but probably unreasonable to expect ADs to perfectly anticipate all
objections from the IESG and IAB, and we saw that in the last cycle. If there's
a rhythm where they go to one coordination call and get kicked to a second one,
that takes us out of the situation we were in this time where we're pressured
to approve something that we don't think is ready.

Warren: I don't really think this is going to change the fact that people wait
until the last minute, but I also don't see a downside to trying it. Some
people might get it together earlier and be better off. I suspect we'll still
end up with panic at the last few days but it will be potentially less bad.

Martin D: I think if we have a monthly BOF coordination call, the stricter we
are that it has to be perfect before we accept it, you're unlikely to get your
BOF approved on the first try.

Warren: Convincing people to do it will be entertaining.

Alvaro: We'd also get the opportunity to kill some things before. Sometimes
just because the BOF is in the wiki we have to consider it, and because we have
that one call. If it's not the proponents deciding it's ready for review, but
the ADs, we may have a better idea of when we think it's ready and what others
may think.

Warren: I am concerned about us having monthly BOF coordination calls and
setting aside time with nothing happening. What if we discuss them on IESG
calls, if there are any, and then we can figure out if we're going to schedule
the monthly BOF call?

Alvaro: I don't think we schedule monthly BOF calls, we just schedule them as
needed.

Alissa: I think our perception of how much time actually exists between the
meetings is off here, and how much time things take to get coordinated and
scheduled with the 30 people implicated. Because usually, the cutoff for
figuring out the agenda for the next meeting is like a month before. That's one
month down. And then I don't know how close in time you'd want to have the
first deadline after the previous meeting. If we had a meeting the third week
of November, we put a deadline three weeks after that? Then we're down to one
BOF call in between the November and March IETF. Normally in order to identify
the time to schedule a joint call with the IAB, we have the doodle that runs
for at least a week and then it gets scheduled for a week or two out. We'd have
to not do it that way, we'd have to reserve the slot for the coordination call
at the same time every month and cancel it if we don't need it. If we do a
doodle we'll lose half the weeks we have to make it happen.

Alvaro: My main purpose with all this is that what I'd like to see is a
continuous type of process deadline, so people don't feel like they can only
propose BOFs three times throughout the year. They can propose at any time and
an AD will at least look at them. We probably need to adjust these numbers and
be strict about the deadlines. Maybe we do have the only one in January for the
March IETF.

Wes: I was going to suggest the same thing as Alissa, having a standing meeting
that both groups would be willing to leave open and cancel the majority of
them. The other thing is it affects the agenda scheduling. If the agenda
scheduling date is the 14th vs the 16th it totally changes the timeline.

Alvaro: I think we reset the cycle and that's it. Sometimes we'll have more
meetings in between, sometimes we'll have less, but we'll always have one.

Alissa: I think the most logical thing would be to put it in the telechat
scheduling. We don't do the telechat scheduling based on a numeric what day of
the month it is, because the weeks shift every year. We'd have to peg it to the
rest of the meeting cycle.

Rob: I like what you're proposing here in terms of getting more regular
reviews. I do wonder if the issue is actually more regular BOF coordination
calls, or having the ability to comment on BOF proposals more frequently. If we
can get BOFs into the Datatracker and treat them more like a charter, and IAB
members and ADs can comment, I wonder if we'd get a better proposal and more
comments about issues such that when the coordination calls actually happen
those things have been resolved up front and it becomes more productive.

Mirja: I'm not fully agreeing with your problem analysis here. I don't think
the problem itself is time. We usually have two types of BOF proposals; one
type is people are experienced, they know exactly what they do, they do it
well, and they could use all the time we give them right now on their own, they
propose it and we go on. The other kind of proposal are people who are
completely lost about how a BOF is organized and they need help. We just need
to find those people and provide them help. Adding more deadlines is probably
not solving this problem from my point of view.

Alvaro: I'm hoping those people who don't know what to do, not only can they
come at any time but they'll have more flexibility. The intention here is to be
on a continuous cycle.

Mirja: My analysis this time was that people made progress because we had this
time pressure. The IAB shepherds and the ADs put time into this because we
actually had time pressure and the proponents really needed this kind of
intensive support. I'm not sure it would have happened otherwise. I think
people will keep pushing stuff out just before the IETF meeting. I actually
like what we did this time, where we effectively had one deadline but two
calls. The timing was tough, but one call with discussion and another call with
a decision makes sense to me.

Alissa: I think more than half of the problem here is that we are also deadline
driven and we don't always do work in advance. But if we have more deadlines
then we do, it seems.

Mirja: I think just putting the deadlines in without actually making sure
people get the support they need will not help.

Alissa: I just meant that's what we did this time. If Martin and Eric did
nothing in between the BOF call and when we had said we would follow up, it
would have been very obvious to the rest of us and it would have been a
definite no. I thought that was a forcing function.

Deborah: Is it that when we have the BOF coordination call that they're getting
more of a cross area input and that feedback should have come earlier? If we
could just tag it on to the end of a telechat, that an AD could introduce the
topic they're considering and get input from the other ADs, and go back to the
proponents on it. The other important part is that they get an IAB advisor on
it. Maybe we should approach it more informally.

Mirja: Maybe we should provide an opportunity for the proponents to quickly
propose something to the IESG a couple of weeks before the deadline. That would
be an opportunity for the proponents to get direct feedback instead of
indirectly.

Warren: I really like that idea.

Barry: I love that idea.

Deborah: It's easy to tag it on a telechat.

Mirja: We could reserve an informal telechat and if we have proponents we can
do it.

Roman: I'm a little leery of having a mini BOF pitch to help us decide. We'd
have to be really conscious not to hold the mini BOF there.

Mirja: That's a risk but I didn't mean this for deciding, I mean for an
opportunity to talk to the IESG and get feedback.

Deborah: I thought we could give them feedback. Often they're not aware of the
cross area implications.

Warren: One of the big advantages is it would help the proponents get
organized. Being a BOF proponent I don't always prepare until close to the
meeting. Having the BOF proponents present the reason for the BOF and what
they're hoping to accomplish will help clarify both in our minds and theirs.
Even if it's not done in front of the whole IESG it might be a helpful function
to get organized and ready.

Alvaro: So we'd have the final deadline, we have that early deadline, and then
we'd have some sort of middle deadline that's come talk to the IESG?

Alissa: I thought people were not feeling like the first one helped that much.
This soft early deadline, people don't really avail themselves of that.

Warren: What I don't know is how much of it didn't happen because people are
used to waiting until the end, and how much was it that people aren't
organized? I suspect both, leaning more towards the latter.

Barry: If you have two deadlines, you effectively have one, the later one.
People don't get their act in gear in time.

Warren: One of the advantages to two deadlines is sometimes it's easier to push
back if you say you could have been preparing this earlier.

Mirja: When we discussed these two deadlines I had something more in mind like
an abstract, like a fixed mandatory deadline but the only thing you have to
send is an abstract. It's still a hard deadline, if you don't send an abstract
you can't send a paper. That's what I originally had in mind and we softened it.

Martin V: Isn't it what we have already today?

Mirja: Yes, that we set the first deadline but don't mean it.

Alvaro: But having people come to the IESG is not a requirement either. It's
just great if they do.

Warren: What I'm going to start doing with BOFS in my own area, I'm going to
have Rob and I meet with the proponents and have them do a call with us to
present what they're trying to do. You often end up with the text in the wiki
and it's unclear what they're actually trying to do.

Alissa: I thought what we ended up doing this time was good. If we could just
move it back a little bit so we're not crunched for the scheduling, it worked
out pretty well. But I didn't have to work with any of the BOF proponents [this
time].

Martin V: I think it worked well but from my perspective the time between the
BOF call and the decision call wasn't long enough to have a final proposal
which would have been approved. But I don't know if the solution is to extend
the time between those two calls or to make people understand that if they come
with a half baked proposal, even with two calls, it won't make it through.
There is work on both sides, us helping but people understanding the less
prepared they are at some point the AD or whoever will work with them can't
change the odds. I agree with Alvaro's solution that maybe we could have more
cycles than IETFs. I think it worked but it's not a perfect solution either.

Alvaro: What we've been doing the last few cycles is incrementally changing
things. Moving the deadline back, have two calls, maybe we make that more
official next time. I don't have a problem doing that. This proposal is more
disruptive and has more changes. To do it we'd have to try it for much longer
to see if it really worked. Maybe we can try something next time and then try
something else.

Mirja: I hope we can change the way people handle this. I'm worried people
won't change their behavior, they'd just still submit at the last possible
deadline. We have an opportunity here to move away from the wiki to the
datatracker, where people will have to change their behavior already. When I
was proposing BOFs I had the feeling that once it was in the wiki it was
official. I would always put it in last minute. I'd hope people can use the
datatracker earlier on to submit a first draft and then iterate. Then we have a
big green button where you can say "now I want to propose officially" when it's
ready.

Alissa: I asked Robert a couple weeks ago about the timing of that and it's
unlikely to be available for 110.

Mirja: That was my expectation at this point already. But given that that's an
opportunity to change behavior already we should carefully review whatever we
get there before we launch it.

Alissa: For the 110 cycle, because the holidays reduce peoples' time, we could
try to have two deadlines or an earlier deadline or something. Or two calls, at
least, for the 110 cycle, and then we could maybe try something more dramatic
when the Datatracker improvements are available.

Roman: To be clear, the ball drop on not having this ready for 110 is my fault.
I hadn't been iterating enough with the Tools Team. My apologies, that's on me.

Alissa: It sounds like we're still refining it anyway. So I guess the question
is for the next cycle, what do we want to do and how far in advance do we want
to do it? If we want to have a December deadline of any kind we should try to
announce it around 109.

Alvaro: As much as I like my slides I thought we were leaning towards trying
something smaller. Maybe try what we did this time and make it a little more
official and see how it goes for another cycle. So no, we wouldn't have a
deadline in December.

Eric V: It makes sense to change one step at a time. A week or two in advance
for the first call.

Alissa: I'd mapped out something with the Secretariat with similar spacing to
the last time.

Eric V: The first call was with the IAB. In this case it should rather be the
first call with the IESG at the end of a telechat and then the IAB common call
for BOF coordination would make more sense.

Mirja: The IAB doesn't make the decision, they're there to just provide input.
If we have dedicated calls and it's not just added to an IESG call, we could
try to add the IAB to both. I don't have a strong opinion.

Alissa: Am I understanding properly, we have one deadline which is earlier in
the cycle than it normally is, and we have a scheduled call the week following
the deadline. So we'd have that as normal. We're unclear on whether that would
be the call where the IAB joins or not, but then maybe a little more than 2
weeks after we have a second call where possibly the IAB joins.

Alvaro: I think the first one is the one the IAB joins, because there's a
possibility we just approve everything there.

Alissa: I agree. We can also invite them to the second one if they want.

Wes: Can one of you write an email to the IAB summarizing?

Alissa: Do we want more than two weeks between these calls? Do we want three
weeks? That puts it way into the holidays, I don't think we could do three
weeks. We could do a little more than two weeks.

Mirja: Two weeks isn't bad if we could shift it all a bit earlier. The closer
you get to a meeting the more crowded time is.

Alissa: I think we have a plan for the next cycle at least, and we can keep
iterating on the future plan.

Mirja: In addition to that as an independent thing we could offer a meeting for
proponents to get feedback from the IESG and IAB or not? Are people still
interested in that idea? If so I would just bring it back to the joint IESG/IAB
meeting. We could offer to the community a call that if they have a proposal
they want feedback on, they can come and present it.

Warren: I think it would be useful. It helps people get their proposal figured
out earlier.

Mirja: There's a chance nobody picks it up but that's also good information to
have.

Barry: That's a good idea.

Eric: Are you thinking like a telechat?

Barry: I would invite them to an informal.

Warren: I think having them show up and talk, not quite present but not quite
not, will give people the opportunity to organize their BOF better, not wait
until the last minute to panic.

Roman: So does everyone get a fixed amount of time? Any guidance we give?

Mirja: We'd need to know in advance if people want to join. They'd have to
register or something.

Warren: We can discuss it when the requests come in, but I'd think ten or 15
minutes max, so it doesn't turn into a BOF.

Alvaro: It sounds like you want a pitch.

Roman: Do you pitch, no questions? Presentation time vs Q&A time? We have to
structure this up front so those getting on the call know what they're getting
into and on our side that we give everyone the same opportunity that comes up
to us.

Mirja: My proposal was just to put this on the joint IAB/IESG call next week to
discuss. It seems like I should do that, I propose to discuss it with the rest
of the IAB.

Alissa: Okay, let's do that.

6.4 [IANA #1181828] Secondary designated expert for RFC 7107, RFC 7114, RFC
8411, and RFC 8696 (IANA)

Amy: This is assigned to Ben and/or Roman. IANA has suggested someone you can
contact and confirm if they're interested.

6.5 FTP Plan (Roman Danilyw)

Roman: As we discussed last week, we had the finalized plan almost down to the
last couple of details and we were going to use this week to resolve that and
the intent was to potentially go to the community as early as tomorrow or next
week on getting feedback on said plan. To bring everyone up to speed on that
Google doc's progress, there were two outstanding things to confirm. First,
what do we do with the two IAB documents that are documenting liaison
agreements? Mirja and I synced up with the two liaisons and their opinion is we
can just add these documents into the big FTP service document with the new
pointers and both confirmed they're fine with that. The thing I wanted to put
up for discussion because it didn't seem resolved was what do we want to do
with 2648? Barry was clear that we don't want to do a bis on that. He said he
was fine with including it as part of the big RFC that says here are some new
pointers. I ask this because Ben noted he felt that was a big deal to handle
with just an errata. Is everyone okay with Barry's plan?

Barry: You did summarize it correctly.

Roman: So what's on the table is RFC 2648 would not be handled specially, the
way it was noted before, it's just going to get handled like all the other
documents. It's got some pointers to FTP and it's going to get updated by the
big master document. With 2648 we're going to be happy with the perl code
that's in there which will be broken further than it is already. Any objection
to that? I'm not hearing any. Appreciate everyone doing all the review and I'll
work with Greg to make a PDF for that Google Doc to go on the website and I'll
send a note to the community asking them how they feel about the proposed plan.
Thanks.

6.6 Designated experts for RFC 8894 [IANA #1177950] (Murray Kucherawy)

Amy: Are there any objections to naming Peter Gutmann as the designated expert
for this registry?

Ben: What's this registry for?

Murray: It's SMI Security for SCEP Attribute Identifiers.

Ben: No objection.

Amy: Okay, it looks like Peter is approved and we will send an official note to
IANA.

6.7 Designated experts for RFC 8876 [IANA #1178766] (Murray Kucherawy)

Murray: This registry is SIP Alert Message Error Codes and Brian Rosen, who is
a major participant in ECRIT working group, has volunteered.

Amy: Any objection to naming Brian as the expert for RFC 8876? I'm hearing no
objection, so we'll send official note to IANA.

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

Alissa: I wanted to ask about our topics for the pre-IETF meeting next week. As
of right now we don't have any IESG specific topics on the agenda. We have some
joint topics. I was curious if anyone plans to add topics or if you have them
that you want to add right now. The other things we have on the agenda are
updates from the RFC Editor and IANA, so we can have a very short meeting with
those two if we want to do that. I guess we should put plenary prep on there
too, so we'll have three things.

6.8 Executive Session: Emails on IETF List