Narrative Minutes interim-2020-iesg-27 2020-12-17 15:00
narrative-minutes-interim-2020-iesg-27-202012171500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2020-12-17 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
---------------------------------
David Millman
Lucas Pardue
Willem Toorop
Greg Wood

1.2 Bash the agenda

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

Warren: If people don't mind I'd really like it if [my documents] could go
first so I don't have to be here [while I'm on vacation]. If it's too complex,
the regular order is fine.

Amy: We can take those first if nobody else objects. Also, we had a document
that was deferred yesterday. It was put it on the January 7 telechat
automatically but we were already over the page limit with the Quic documents
for that telechat. That puts us farther over the page limit. Is everyone okay
with that or do you want to push a January 7 document to the 21st?

Eric V: I was hoping to take some real vacation so pushing a smaller one to the
next formal would be better for me.

Amy: If one of the document shepherds can think about that and choose one to
move forward, that would be great.

Alissa: The one that was deferred, had most people already balloted?

Murray: It has seven positions on it.

Eric V: Good point. I already balloted on it so there's no more work for me.

Alissa: This is the EAP-TLS, right?

Magnus: We could push some of the Quic documents.

Erik K: It seems nice to deal with all the Quic documents at the same time.

Magnus: There will still be more later on too.

Amy: It's not something that needs to be solved right now; just remember you
are heavy on page count for next time.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes of the December 3 telechat
being approved? I'm hearing no objection. Is there any objection to approving
the final narrative minutes? 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: Has this been completed?

Eric V: I think so. After multiple revisions the text has received no more
comments. It's still in the Google docs and on the IESG wiki so I consider this
done for now.

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

Murray: I'm hoping to have something for the IESG to look at before Christmas;
in progress.

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

Alvaro: We talked about this last week. Warren brought up another point we need
to consider but we haven't gotten together. Let's keep it here for now and
we'll pick it up after the holidays.

     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 thought we were going to put this one on hold for a couple of months.

Amy: You did put part of that on hold, that will come back in January.

Alissa: What are the two parts?

Amy: This replaced the text for the one where it's going to be discussed again
in January. This was the framing of it and the other is "to report back to the
IESG on the impact of Covid-19 in January 2021."

Alissa: That's separate. This one is from the retreat and I agree, I think we
should let it go dormant until February.

Amy: Okay, we'll remove this one and bring it back in February.

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

In progress.

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

Warren: I thought we'd decided we weren't making progress on it and we'd drop
it. Was that a different one?

Alvaro: I thought we'd decided we weren't making progress but we wouldn't drop
it. Barry, what did you think?

Barry: I thought the same as Alvaro. We need to look at it but it just hasn't
popped to the top of any of our lists yet.

     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: I did a bit of progress on my side and I still need to communicate it
to Alvaro. In progress.

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

Erik K: Still in progress.

     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 on the agenda for approval at the end of the call so this is
provisionally done.

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

Warren: We're making good progress on this. We've had four meetings now and
we've discovered it's a much larger project than we originally thought. It's
not just volunteers, it's somewhat keeping the IETF healthy and deciding what a
volunteer means. Most participants are volunteers in some way. So it's turned
into a larger project but we're making progress and doing stuff.

Deborah: We're doing good.

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

Amy: This is on the agenda for approval at the end of the call so this is
provisionally done.

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

Erik K: Still in progress.

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

Ben: Still in progress.

     o Ben Kaduk to find designated experts for RFC 8879 [IANA #1184206].

Ben: I suspect we'll just reuse the same experts for most of the other TLS
registries. You can mark this in progress and we can come back to it next time.

     o Ben Kaduk to talk to Kathleen Moriarty about status of
       draft-seantek-ldap-pkcs9

Ben: This came out of the informal last week. It's in progress.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-dnsop-server-cookies-04  - IETF stream
   Interoperable Domain Name System (DNS) Server Cookies (Proposed
   Standard)
   Token: Warren Kumari

Amy: Warren asked for his documents to jump to the top. I have a Discuss on
this document; do we need to discuss this?

Warren: If we can. I thought there had been a discussion with Ben and it had
largely resolved, that this is an unusual thing and it doesn't need a
particularly strong MAC but I don't know if that was the final outcome or if
there's still CFRG discussions needed or what.

Ben: What I'm looking for here is just a bit more text in the document about
what we think we actually need from the MAC and then it's easier to verify that
the MAC we're using should provide those properties. Right now it just says 'we
need a cryptographic MAC' and there's nothing about what information is being
MACed and why that's the right information to MAC. I could make a guess at
that, but not necessarily all readers could and I'm not sure my guess would
match up with what the authors expected.

Warren: Okay, so it's not so much specifically the hash that was chosen, it's
what goes into the hash. Is that correct?

Ben: I think it's both. We need to talk about what goes into the hash and then
dependent on that, is the hash that we picked an appropriate one for that
purpose? I did send a note to CFRG but I don't expect to block on responses for
that. We did get a few responses, not least because the author of SipHash is on
the CFRG list.

Warren: Awesome. Thank you.

Amy: So does that require a Revised ID, Warren?

Warren: Yes.

Amy: Great, so that will stay in IESG Evaluation and go into Revised ID Needed.
Let's move on to Warren's next document.


 o draft-ietf-bmwg-b2b-frame-03  - IETF stream
   Updates for the Back-to-back Frame Benchmark in RFC 2544
   (Informational)
   Token: Warren Kumari

Amy: We have a consensus Unknown here so we'll change that to Yes for you. I
also have a Discuss; do we need to discuss that today?

Warren: I guess shortly. I believe there's a fairly active discussion happening
with Scott Bradner on other parts. This part I think they should be able to
address so I think that's just another revised ID Needed. I'm not sure if
Martin has anything he wants to say on it.

Martin D: Al's email was totally satisfactory; I was just waiting for the
revision to appear.

Warren: Excellent; thank you very much.

Ben: Are they really claiming an example where they're claiming there's only
four microseconds of buffer space?

Warren: Yes.

Ben: Okay.

Warren: I think that happens in some of the high speed merch in Silicon.
Buffering stuff at 100 gigs means you need massive massive buffers. I think
there are some chips that do that.

Amy: Okay, so it sounds like that stays in IESG Evaluation and goes into
Revised ID Needed. Thanks Warren and now we can go back to the top of our
agenda.

 o draft-ietf-roll-useofrplinfo-42  - IETF stream
   Using RPI Option Type, Routing Header for Source Routes and
   IPv6-in-IPv6 encapsulation in the RPL Data Plane (Proposed Standard)
   Token: Alvaro Retana

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

Alvaro: No, I don't think so. Pascal, the author, has been talking to Erik
about this and I hope they're close to the text that's going to go here, and
probably not in the other document. We're going to need a revised ID, though.

Erik: I don't think this is particularly difficult. The text that was added
just made it look like there was a behavior change that's not actually
happening.

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

 o draft-ietf-dots-signal-call-home-11  - IETF stream
   Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
   Channel Call Home (Proposed Standard)
   Token: Benjamin Kaduk

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

Ben: Yes I think we can, hopefully briefly. Roman, there was a reply from Med,
but I assume you're still looking for some changes in the text. Is that correct?

Roman: I have to confess that I saw he sent a response but I did not really
internalize what he was saying.  What I'm primarily looking for, without having
looked at the specifics of his response, is that I think there are some
implicit assumptions about how that CPE device is being managed. I'm frankly
completely flexible on what that management is, I would just like some up front
language about that because I would posit that it's unrealistic to assert that
many of the knobs that are being presented are actually tunable or usable by
your average home user, which seems like that's the deployment model. I think
the answer really is, just say the device will be given to them with secure
defaults and/or it's going to be managed by the ISP that gave them that. Then
the guidance there works.

Ben: Sure, that sounds good to me. Magnus, Med just a couple minutes ago asked
if you had seen their existing message to the port expert attempting to explain
why it's a different service.

Magnus: Yes, and I still don't think that holds. My understanding of the
history here is that DOTS was given, despite being a CoAP protocol, and having
the CoAP level of probability to define what the service is, identifying, etc,
it was given a port for the purpose of being able to write rules, etc. but I
don't see that this protocol needs two when there's so many possibilities for
the service to, even if it's used in another context and it's turned around,
there's so much possibility both in CoAP and in TLS to identify these as
different usages. There's no reason to mint another port number out of these
when they've already gotten one.

Ben: We're definitely going to continue having the conversation and exploring
what the options are, so we don't need to come to an answer now. I did just
want to raise to the broader group that the authors sort of feel like the
NETCONF and RESTCONF getting their own dedicated ports is maybe a little bit of
a precedent as to why this should also get its own port. But I don't know the
history of how those NETCONF and RESTCONF pieces were approved.

Magnus: I don't know either and that may be something. I'd claim here that you
actually have -- I don't see there's anything in the protocol that makes it
hard to co-locate these and identify them as being different usages. So from my
perspective it feels like there are a lot of options here which is fairly
simple to implement and get the protocols working which doesn't consume endless
resources, which is port space.

Ben: Right. I'm not going to tell you flat out that you're wrong. I think part
of the motivation here is that at least most of those other options are going
to include some kind of discovery at runtime, and they are feeling pretty
sensitive to the requirement to do runtime discovery given that they're
intending to operate in extremely hostile network environments, so each
discovery step adds to the risk that you're going to fail outright. But let's
keep discussing this over email, I think.

Magnus: Worst case I guess we come back after the holidays anyway on this with
maybe a call or so. We are sending a message, we have this BCP etc, and it does
apply to working groups even if we are the guarding party here as the IESG on
that aspect. In this case I think it's warranted to actually push back a bit
unless they have really good motivations why it's really needed. So far the
motivation in that appendix doesn't for me motivate it well enough, especially
considering which protocols are in use, etc, and it's not hard to actually
define co-locations of it.

Ben: That sounds reasonable to me, so I think we put this in Revised ID Needed
and move on with the agenda, unless there was more you wanted to talk about.

Magnus: No, I'm fine.

Amy: So it sounds like this is going to stay in IESG Evaluation and go into
Revised ID Needed. Thanks.

 o draft-ietf-ipsecme-ipv6-ipv4-codes-05  - IETF stream
   IKEv2 Notification Status Types for IPv4/IPv6 Coexistence (Proposed
   Standard)
   Token: Benjamin Kaduk

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

Ben: Let's leave this in AD Followup. The authors posted a new revision this
morning but I haven't had a chance to look at it yet.

Amy: Okay, this will go into Approved, Announcement to be Sent, AD Followup and
you can let us know when that's ready.

 o draft-ietf-bess-mvpn-fast-failover-13  - IETF stream
   Multicast VPN Fast Upstream Failover (Proposed Standard)
   Token: Martin Vigoureux

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

Martin V: Maybe Alvaro's. Ben, I think Greg is on top of yours.

Ben: Yes, he proposed something that looks fine.

Martin V: Okay, thanks for catching that. Alvaro, sadly, I don't know how this
happened but Greg wrote me this night and said he hadn't received the email of
your Discuss and that's why he hadn't replied yet.

Alvaro: I can send it to him again, that's fine.

Martin V: I wanted to discuss very happily your second Discuss point. I think
the first one can be easily addressed. But I wasn't sure to understand the
second one, in the sense that, do you think the BGP attribute which is proposed
by this document is bad design, or technically flawed, or is it that you think
it's not absolutely necessary and we could do it differently?

Alvaro: There are two parts there. One is that using BFD to monitor the tunnel
doesn't need the bootstrapping of the attribute. You can monitor using BFD
today. That part is not mentioned anywhere. What that means is if the purpose
of the draft is to monitor the tunnel, we can monitor it without the BGP
extension. The other thing that sort of worries me is that the attribute, I
don't think it's not well defined or anything like that, it's very broad and
very extensible. We're using pretty much one bit here, of anything that could
be extended, there's provision for TLVs and subTLVs and a bunch of other things
that are not specified, they're just there. As far as I can see, BFD itself,
the WG hasn't looked at this as a way to bootstrap BFD, which is what they're
trying to do here, tell you [muffled] so you can monitor the session. It caught
my attention that Greg had suggested that part of the work belonged in BFD. So
I don't know if that conversation happened or not, this was before Greg was the
new editor. It caught my attention that even he thought this was a wider thing
and shouldn't be hidden inside this document.

Martin V: Thank you for your clarification. I think Greg's comments were prior
to him becoming an editor on that document. Maybe he revised his opinion after
becoming an editor, you'll have to check with him on that. I understand your
point, though I'm not really sure what's actionable in that, in the sense that
yes, there are provisions for wider things than what this document does, but...

Alvaro: In the end, I'd prefer it if we took the attribute out of this
document, and the document said you can monitor using BFD. How you bootstrap,
how you learn the discriminator from someone else, that's outside the
specification. There are five other mechanisms that are being described here on
how to monitor. I don't think taking the attribute out of this document would
make this document any less valuable.

Eric V: That was one comment of mine as well. This mechanism could be valuable
for other documents. Moving it outside would be great to be used for others.

Alvaro: That's why I would like the BFD WG to take a look at it. If they think
they want to do some bootstrapping of BFD using BGP, this is the attribute to
use. Or maybe they don't like this attribute and they like something else, and
there's a provision to do TLVs and other stuff that's nice they're having
extensibility in, but there's been no discussion of if we need this at all, or
if they think they want something else, or they want TLVs, maybe doing it from
the beginning would be a nice thing.

Martin V: BFD could very well capitalize on that work. [cross talk]

Alvaro: I don't know if this discussion took place in BFD or not. I know Greg
brought it up, I don't know if anyone followed up with the BFD chairs. I tried
in the Discuss tool copying in the BFD chairs. I don't know if they got the
email but if they already saw it and they're fine with it, that would be great.
I just want to make sure if we're defining something that is going to be useful
to many other people, that it's visible to many other people. I would think the
last place someone's going to look for BFD bootstrapping BGP is the
mvpn-fast-failover draft.

Martin V: Maybe we can make sure that this is known to the BFD working group.

Alvaro: That would be a first step, definitely.

Martin V: In any case, I just want to clarify that you don't see a technical
flaw in the design, right?

Alvaro: No, I don't think so. It still needs a little more specification, it
doesn't talk about the length, being that it's so extensible we need to think
about the extended messages, and a couple other things I put in there.

Ben: I had considered making a comment about, it says you can put TLVs in there
but there's no real sense of what the TLV ecosystem would be and in light of
some of the IAB work on [the draft] use-it-or-lose-it, it's not clear that
given the level of specification, all implementations would correctly code up
the TLV handling such that you could actually add TLVs later. Just based on
what's currently in the document.

Martin V: Maybe that needs a bit of tightening up, but it's clearly not
uncommon to define extensibility capabilities without defining any of those
capabilities at the first step.

Ben: That's my understanding too, so that's why I didn't actually comment about
it. I just thought about commenting until now.

Alvaro: I agree with that too. The weird thing is that it's an extensibility
for BFD and this is not coming from BFD.

Martin V: Just like BESS does some BGP work but it's not in IDR.

Alvaro: That's what the charter is for, right?

Martin V: Okay, let's see how Greg handles that. Thank you very much.

Alvaro: I'll just send that to him and everyone else who was supposed to get it
just in case.

Barry: And Martin, please take note of my comment about putting in an RFC
Editor note so the RFC Editor is aware of the distinction between capitalized
Upstream and uncapitalized upstream.

Martin V: Okay. Thank you Barry. I'm not even sure we managed to reach a
satisfactory level on that. I myself struggled during my AD review to try to
clarify things.

Barry: My comment isn't at a Discuss level because I don't think the document
is unclear; I think it's a bad idea to make a semantic distinction from just
the initial capital letter. But I think the document is clear as it is. When
the editing is done it just needs to be done carefully so it doesn't get messed
up.

Martin V: Thanks for that. If anyone has any brilliant idea on how to do it
differently, I'll take it. I'll take note of that and make sure it's handled
properly. Thank you all. I guess this one will need a Revised ID.

Amy: Thank you, so that will go into Revised ID Needed.

 o draft-ietf-roll-unaware-leaves-26  - IETF stream
   Routing for RPL Leaves (Proposed Standard)
   Token: Alvaro Retana

Amy: I have no Discusses for this document but I do have a number of open
positions. Does anyone who has an open position on this document wish to state
a position? I've got Martin D, Martin V, Magnus.

Martin v: I didn't finish reading it. I can do it a bit later.

Amy: It's not necessary for it to pass, unless you have a Discuss. Unless
there's an objection, it looks like this one is approved.

Alvaro: We'll need a Revised ID for this one. The authors have been pretty good
at updating the document as they go. I do have a question for everyone else. I
was approached by the Wi-SUN Alliance, this is the wireless smart utility
network group. They do work on implementing IoT stuff for smart grid things.
They're waiting for this document for one of their documents that's going to
publish sometime in the first trimester of next year, probably around March. I
want to ask if anyone objects if I ask for expedited processing for this
document from the RFC Editor. This document does depend on the useofrplinfo one
that we saw at the beginning [of the telechat], so of course we're going to
wait for that before we move anything forward. That's it. Does anyone object to
tha?

Barry: No objection from me.

[No objections]

Alvaro: Okay, thank you.

Amy: This will go into Approved, Announcement to be Sent, Revised ID Needed,
and after that it sounds like you're going to be requesting expedited
processing.

Ben: If I could jump in real quick, I did not make this a Discuss level comment
because I think we've been having this conversation in the context of the 8138
document, but this does seem to be a thing where it says 'if you're using MOP
value 7, you must assume this is going to be the case' and whatever we decide
for 8138 we should make sure we do the same thing here, giving a trail of
breadcrumbs for people to figure out.

Alvaro: Yes. We'll make sure as we move forward that the three are together.

Ben: I was pretty sure you were going to do that, just mentioning it.

Sandy: There are a couple of normative references in this document that I don't
believe are in our queue yet.

Alvaro: Yes, one is the other document on this telechat that still has a
Discuss on it and the other one may already be. I'll take a look just to make
sure. We can move all three together.

Sandy: So you'll be expediting all three?

Alvaro: I'll get in touch with you because I think what they think they need is
just a number to make a reference, not necessarily a publication. I'll confirm
with them as we get all this approved and talk to you guys.

Sandy: Thank you.

 o draft-ietf-tls-ticketrequests-07  - IETF stream
   TLS Ticket Requests (Proposed Standard)
   Token: Benjamin Kaduk

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

Ben: This one is in quite good shape. Let's keep it in AD Followup because I've
forgotten since when I last checked what the responses were to the ballot
comments.

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

 o draft-ietf-extra-sieve-mailboxid-06  - IETF stream
   Sieve Email Filtering: delivery by mailboxid (Proposed Standard)
   Token: Barry Leiba

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

Barry: We do not. This is going to be Revised ID Needed, please.

 o draft-ietf-tcpm-rack-14  - IETF stream
   The RACK-TLP loss detection algorithm for TCP (Proposed Standard)
   Token: Martin Duke

Amy: There are no Discusses for this document, but I do have some open
positions. It will not block publication, if anyone wants to state a position
now or not.

Ben: I do have some comments that I'm writing up. I only made it about 17 pages
through so far. Martin, do you prefer if I stop now and send those comments?

Martin D: An hour or two is fine. This is going to be a Revised ID Needed, not
only for the comments here but also the Last Call review does have some good
changes in it. So they're going to have to go edit it anyway.

Ben: There's one point in particular that I'm fairly confused about that might
just be a wording issue, but we don't have to talk about it right now because
it would be challenging for me to explain in words. I will finish that up right
after the call.

Martin D: Thanks. Please do change this to Revised ID Needed.

Amy: Since there are no Discusses this will go into Approved, Announcement to
be sent, Revised ID Needed and you can let us know when you're satisfied.

 o draft-ietf-dhc-dhcpv6-pd-relay-requirements-04  - IETF stream
   DHCPv6 Prefix Delegating Relay Requirements (Proposed Standard)
   Token: Eric Vyncke

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

Eric V: This should be Revised ID. I just want to comment on a few other
comments about the update, about the dhc-dhcpv6 document itself. It's a point I
raised during my own AD review with the authors and the chairs and the authors
of RFC 8415. Basically that's not updated formally, so there's no point in
putting Update. It refines a few things and it advises implementations, so
that's not really an update there.

Barry: Is it the case that it would be okay to read 8415 and implement it
completely without paying any attention to this at all?

[crosstalk]

Roman: That's of a similar mind as I am. I didn't have a chance to respond but
I found it confusing that the response to whether it should update or not was
largely 'we're just restating what's someplace else.' My reaction was, well if
that's the case why is this a PS?

Ben: I was also going to say, updates sort of ties into the question of what
status to publish it as. I could maybe see BCP, I could maybe see
Informational, I could maybe see it's an applicability statement, but there's
not really a core protocol you implement with just this document. It's sort of
commentary about the other thing.

Eric V: Besides the word BCP, it's basically common practice to operate this
kind of relay. But when I say best common practice it's outside the IETF
meaning of it. But back to your question, Barry, you can implement 8415 without
reading this. It would not be the most efficient implementation, though.

Barry: My understanding from reading this, and so maybe either I'm not reading
it clearly or there's something unclear, is that some aspect of 8415 simply
does not interoperate unless you do things this way.

Eric V: It's not interoperate nicely, but that's how you define interoperate,
right? Honestly I already got into a lengthy discussion with the authors of
this document and 8415 and the WG chairs, and it was clear for me.

Barry: I didn't raise this to Discuss level, so you guys should just do the
right thing.

Roman: Can I pop a little bit out of this document? Maybe I'm just not clear.
We've seen this before. What's the downside of updates? What's the downside of
having pointers that link documents together? There seems to be a strong
preference not to have it. Can someone educate me on both sides of that
position? I don't get why it's a big thing.

Alvaro: I think the problem is that they're not used consistently.

Ben: If you're interpreting the updates as mandatory, that anybody implementing
the thing being updated needs to take this into account immediately, then
there's motivation to be conservative about it. If you're using updates as a
"See also," then yeah, throw it around with abandon. But we never manage to get
consensus on what "updates" means or even on adding new tags that do have more
well-defined meanings, so we're just sort of stuck in this limbo state.

Roman: Okay. I'm still super confused, but it's all good.

Eric V: I think that's an action item for all of us on this point maybe. Not on
specifically this document, but in consistency there. I remember Warren and
some others working on this but it didn't go anywhere.

Alissa: Mirja and Suresh already talked about this, and they've tried like
fifteen different times to get consensus and it hasn't worked.

Mirja: Still trying! We updated the draft and Suresh is working on doing some
investigation into that but it's a little bit slow.

Roman: So just so I understand it, we're held hostage by the lack of being able
to get consensus, so we live in this ambiguous world of pretty much not being
able to really use update tags. Right?

Barry: It's not that we're not able to, it's just that the use is for several
different purposes and people disagree on whether you should or shouldn't use
it for those purposes.

Roman: What that says to me is that let's say I want update tags and another
group wants update tags, it's pretty much author preference, right? Because we
don't have the stick from the process side to say you have to, because we have
an ambiguity. Right? I just want to make sure so I don't have to raise this
again.

Alissa: The way to not end up in this situation is for all of us to agree that
we're not going to raise it anymore. Whatever we get, that's what we have.

Barry: I don't see anything wrong with raising it and having the discussion and
ultimately leaving it up to the authors and the WG.

Martin D: Doesn't this document meet the strictest requirement in that if
you're doing the base you really ought to implement this?

Roman: That was my read of it, which is why I made the point to begin with.

Eric V: Honestly, we can put it on AD Followup and continue discussion on the
mailing list and agree to move forward. Again, the DHC chairs and the authors
of those documents agree it should not be updating and I trust them. I will
forward their email to the IESG. They convinced me, because I raised this point
too.

Martin D: If they're happy with someone shipping the base protocol without this
in the future, I'll defer to their technical judgment there. My understanding
is that even the strictest interpretation of update would be that if that's a
bad idea they should be updating the other one, that's all.

Erik K: There is no protocol change here. It is and was perfectly possible to
ship a working relay implantation without this document, it's just that some
people couldn't figure it out.

Ben: Yeah, but if that's the case then there's no protocol here. Why is it a
protocol PS?

Erik K: I asked why not a BCP and their answer was they were basing it off the
nodes requirements document. Let me find their answer.

Eric V: There is an IPv6 node requirements, which does not change the protocol,
which is standards track. And this is basically something similar. We don't
have a strict rule so we select the precedent based on whatever.

Amy: So going back to this document, I still don't have a Discuss on it, so it
will be in Approved, Announcement to be Sent, Revised ID Needed.

Eric V: For me that's perfectly fine, and we can continue the discussion.

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-detnet-flow-information-model-13  - IETF stream
   DetNet Flow Information Model (Informational)
   Token: Deborah Brungard

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

Deborah: We'll do it as Revised ID Needed; there were some comments in the last
couple of days for the authors to address.

Amy: Great, this will go into Approved, Announcement to be Sent, Revised ID
Needed and 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

 o Open Specification for Pretty Good Privacy (openpgp)

Amy: There are no blocking comments, so unless there's an objection now it
looks like this is going to be a new working group.

Ben: I saw Magnus's note about the wording. I'm already committed to doing a
couple things in the next few days so I'm not entirely sure I want to hold up
and think about it. I'm tempted to let this get approved as is if that's not a
problem for you

Magnus: That's okay, it was a comment level. I understand what the basis is. I
just hope it's not going to take any lawyering for that charter text.

Ben: I hope so too.

Amy: Okay, it looks like this charter is approved. I have chairs and a mailing
list so this is ready to go. We'll send a WG Action announcement.

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: I don't have anything to report this week.

6. Management issues

6.1 [IANA #1184206] Designated experts for RFC 8879 (IANA)

Amy: This is a new item for Ben.

6.2 [IANA #1184404] Management Item: Acceptance of media type registration from
standards organization Alliance for Open Media (IANA)

Michelle: This is just to approve accepting these media types from the
organization Alliance for Open Media.

Barry: I looked into them and it looks like we should approve this, it's a
legitimate industry standards group.

Alissa: Agree. There are a bunch of IETF people who participate there too.

Michelle: Thank you.

Amy: Any objection to approving these?  Hearing no objection, so this is
approved and we will send official note to IANA.

6.3 [IANA #1181828] Designated Expert for RFC 7107, RFC 7114, RFC 8411, and RFC
8696 (Ben Kaduk)

Amy: Sean Turner has agreed to serve as an additional expert for these
registries. Any objection to approving Sean? Hearing no objection, so Sean is
approved and we will send official note to IANA.

6.4 Designated Experts for RFC 8782 (Ben Kaduk)

Amy: Ben has identified four people to serve as the expert team, Nik, Med,
Andrew and Tiru. Any objection to approving these four? Hearing no objection,
so they are approved and we will send official note to IANA.

6.6 [IANA #1185167] Management Item: Acceptance of media type registration from
standards organization SCIP Working Group

Amy: This is another request to add the organization to the list of
organizations that have registered media types in the Standards Tree list. Is
there any objection?

Alissa: I looked at this one, SCIP, and it's developed by the NSA. I couldn't
find any independent entity that is the SCIP Working Group. I don't know if
anyone else has any information. I was looking at the page with the specs and
it says SCIP is a standard developed by the National Security Agency. So then
we would be adding the National Security Agency as the standards organization,
which I'm not sure about.

Ben: I thought they also had some NATO people, not just NSA.

Alissa: That's for the registration, but for this organization.

Ben: I didn't look that closely.

Alissa: The site had a broken TLS cert. It might be self signed, but it pops a
warning for me. I don't know if we want to chat with them a little bit more?

Ben: We can also just approve the registration but not add them to the list.

Murray: Wikipedia says SCIP is a standard, not an organization. It was designed
by the DOD Digital Voice Processor Consortium in cooperation with the NSA.

Martin D: At the very bottom it says SCIP Working Group and then there's an
email address, so in theory there's a working group.

Barry: The other question is do we expect other media types from them? It's
unlikely they're going to send other media types, so we can just approve this
registration without putting them on the list.

Ben: That would be my default option.

Barry: I think that's the best approach for now. If they come back with another
media type request in the future we can revisit it.

Michelle: Would you like us to inquire if they're expecting to send in
additional media types?

Barry: Yeah, we should go ahead and do that, but in the meantime we can approve
this one on this call.

Ben: We don't approve it, we send it to the experts, right?

Barry: We have to approve putting this in the standards tree, the expert
reviewers will still review the registration. I propose we approve putting this
registration in the Standards Tree, subject to expert review, and we do not add
them to the list. Michelle can come back to us with more information. Any
objections to that path? Okay.

Amy: So it sounds like we approve the specific thing but not adding the group
to the Standards Tree. We'll send the official note to IANA about that.

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

Amy: Please note the AMS offices will be closed from December 25 to January 3.
That includes the RPC. We'll be checking email but any Last Calls or other
requests will be very slow. The preliminary stuff for the January 7 telechat
will go out as normal.

Michelle: The IANA services office is also closed from the 24th, returning back
on the 4th, but we'll also be ensuring requests stay in their SLAs during that
time. You might have some delayed responses but reach out to me if there are
any issues.

Amy: One more reminder, the BOF coordination call is set for Thursday January
14 and that information is in the calendar.

6.5 Executive Session: NomCom Confirmation (Martin Vigoureux))