Skip to main content

Narrative Minutes interim-2022-iesg-05 2022-02-17 15:00
narrative-minutes-interim-2022-iesg-05-202202171500-00

Meeting Narrative Minutes Internet Engineering Steering Group (iesg) IETF
Date and time 2022-02-17 15:00
Title Narrative Minutes interim-2022-iesg-05 2022-02-17 15:00
State (None)
Other versions plain text
Last updated 2024-02-23

narrative-minutes-interim-2022-iesg-05-202202171500-00
INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2022-02-17 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Andrew Alston (Liquid Intelligent Technologies) / incoming Routing Area
Jenny Bui (AMS) / IETF Secretariat
Ben Campbell (Independent Consultant) / IAB Liaison
Roman Danyliw (CERT/SEI) / Security Area
Martin Duke (Google) / Transport Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Benjamin Kaduk (Akamai Technologies) / Security Area
Erik Kline (Google) / Internet Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Applications and Real-Time Area
Colin Perkins (University of Glasgow) / IRTF Chair
Alvaro Retana (Futurewei Technologies) / Routing Area
Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area
John Scudder (Juniper) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
Amy Vezza (AMS) / IETF Secretariat
Martin Vigoureux (Nokia) / Routing Area
Éric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
Lars Eggert (NetApp) / IETF Chair, General Area
Paul Wouters (Aiven) / incoming Security Area

OBSERVERS
---------------------------------
Luc Andre Burdet
Bruno Decraene
Daniam Henriques
Robert Raszuk
Lee-Berkeley Shaw
Ketan Talauilkar
Greg Wood
Shuwan Zhuang

1.2 Bash the agenda

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

Warren: It would be nice if we could do the babel and bess [documents] early.

Martin V: That would help me, because I need to go outside in 40 minutes or so.

Rob: Is it worth bumping up the agenda deconfliction?

Amy: That's always taken last because we don't know how long that conversation
is going to last.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to approving the minutes from February 3?
Hearing no objection. I also saw final narrative minutes from February 3, any
objection to approving those? Hearing no objection there either, so we will get
those posted.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

     NONE

   * OPEN ACTION ITEMS

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

Amy: I saw the final text of this come in email, is that right?

Martin D: This is done. Lars has the ball right now. If anyone has anything
they really can't live with, email me and we can make the edit, but at some
point we just had to call it done. We took most of the suggestions from last
week and eliminated some redundant text and that's how we got the final
product. Thanks, everyone.

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

Alvaro: We already drafted the note; we're waiting for the announcement of the
new template to go out. I'll send the link of this note to everyone so you can
see it before we send it out. The next one, it turns out there is already a
warning in the submission tool. If you submit something with more than five
authors it'll tell you something like are you sure you really want to do this?
So that one is already done.

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

Amy: This is on hold.

     o Murray Kucherawy to look into updating the guidance in BCP 13 on
       when to add organizations to the "Standards-related organizations
       that have registered Media Types in the Standards Tree" list.

Murray: I just put some text out to the list last night for us to consider a
path forward, so it's with the IESG to debate. In progress.

     o The IESG to report back to the community on the early plenary
       experiment.

Amy: Did I see draft text on this or did this already go out?

Mirja: There was a blog post about it, right?

Martin D: Yes, that went out.

Amy: Great, we'll mark that as done.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-bess-srv6-services-11  - IETF stream
   SRv6 BGP based Overlay Services (Proposed Standard)
   Token: Martin Vigoureux

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

Martin V: It's up to the ADs to decide. I don't think so, honestly, in the
sense that Ketan seems to be really on top of every item, even those which I
consider not really Discuss criteria. It's really up to you to decide. What
appears to me is that we may not have reached a conclusion but Ketan is very
proactive so I'm confident everything will resolve smoothly.

Warren: Interesting; I thought there was a fairly fundamental set of issues
with it.

Martin V: Could you elaborate?

Warren: Yes. Basically what I put in my Discuss; the fact that this requires
always perfect filtering on all of your interfaces that could possibly be part
of the SRv6 domain in order to keep VPN traffic safe seems like something that
sounds nice in principle but isn't actually doable in practice. I don't see how
this really gets fixed. The issue is similar things are done with MPLS and
that's relatively safe because it's a different protocol, you can't easily
construct MPLS packets and inject them. Doing this over SRv6 means that if
there's ever an issue with your filtering, people can inject packets into
signal VPNs. It also means that if any of the machines within the SRv6 domain
have issues, like your billing server or the secretary's workstation, that
machine can be used to inject packets into VPNs. What's different between this
and regular SRv6 is once you're doing VPN type stuff with it, it's not just
your own network you're putting at risk, it's anybody who has a signaled VPN
across your network. Any customer you're selling this service to. The fact that
it's carried in BGP, yes, handwave, there are different AFI/SAFIs, so hopefully
they won't leak. But if and when they do, you have a serious issue. I don't
really see how this gets fixed. I think a number of other people had similar
concerns.

Éric V: Actually, Warren, I got an opposite one at the beginning. I think we
all need to take for granted that there will be leaks. Basically we need to
rely on this border, or blocking in the data plane. This was my original
Discuss; I put a Discuss on this document at the beginning because I was
thinking the security considerations were too strict. BGP leaks will happen,
but we need a way to build a wall or whatever around the SRv6 domain. It must
be done. Whether it's leaks, whether it's inside information, you need to build
walls.

Warren: So you're putting all of your security and all of your customers'
security, because the difference between MPLS and SRv6, for example, is it's
really hard to construct an MPLS packet from somewhere random on the internet
and send it. It's easy to create an SRv6 packet from somewhere on the internet
and send it. You're putting all of your security and your customers' security
on the 'we will always have perfect ACL filtering on all points at all edges of
our network.'

Éric V: But you need to do it anyway, right? Whether there are BGP leaks or
not, you need to do it. You've got the same thing as a CEP link. On your P you
have to filter many traffic coming out of your CE.

Warren: It's very common when people are debugging issues with connectivity to
assume maybe there's something wrong with the firewall filter on this; I'll
drop it on the interface for a little bit. And now if your SID information is
leaked, now packets come in. Or it's very common, as you say. You have to build
this hard set of filters all around the outside of your network. You build
that, but chances are your NOC workstation is not on the outside of your
network. It's on the inside of your network. This means that when your NOC
monkey downloads the latest version of whatever piece of software and sticks it
on his machine so he can watch videos during boring times at 3 AM, or when he
gets the Word document that says this is my billing dispute and opens it, now
people can inject packets from in the workstation into a VPN.

Éric V: Yeah, but I mean, honestly, if you have such malware or whatever inside
your NOC, you have much bigger problems. Anyway, I'm not an operator and I'm
not filled in on BGP, but I'm failing to see the issue here.

Andrew: Can I add something here? As an operator, my biggest issue with this is
that as Warren says, you need this perfect filtering. If I look at the hardware
that's out there today, if I were to say I'm going to filter a VPN at every
port on the network, considering what Warren is saying where I've got to
protect against the NOC machines and I've got to protect against whatever, I am
going to blow up my ticams on that hardware every time. That means the
filtering is not only very difficult to maintain, it's also practically
impossible to implement because you have to consider that with mpls, where it
is a fail closed, because very simply, with MPLS [...] you can't just inject
that from every node on your network. With this, you can, unless it is
expressly LPM filtered. The moment you don't have an LPM filter on any machine
on your network that can inject those packets, which will blow up your ticams,
you have a problem. Now whether or not we say this is just the BGP aspects of
it and this applies to any SRv6, therefore this is okay. Well, we could say
that, but my question then becomes, are we not building on quicksand? Are we
not exacerbating a very real, very deep security problem? That would be my
thoughts on this.

Warren: That, I believe, is the actual root issue. MPLS, or the other ways
we've been doing this, fail closed. With SRv6 it fails open. Yes, we could say
SRv6 was a major issue, or had introduced this early, I think the tipping point
is this makes it somewhat more likely that the information in a sense will be
visible to things that are not directly part of the routing.

John: I stuck some of this in Slack, but I think it bears repeating. It seems
like what Éric says is right; 8402 gave us a Tootsie Pop security model. I
don't love it, but it's what 8402 has. But unless someone wants to argue that
that's not a brittle security model and if you want to argue that, stand up and
make the argument. Unless somebody wants to make that argument, I think that
means that every time you extend the architecture of this thing, it's fair to
say now we have to take a really hard look at these sorts of consequences. How
much farther does it take you down the slippery slope of expanding
vulnerabilities? One thing you can do is say all we're doing is saying please
take a really comprehensive look at the possible security consequences and
don't just do the minimal three paragraphs that says the security is already
analyzed in these other documents. I think Warren and Andrew have both made
some pretty good points about actually this does add some new vulnerabilities
in certain operational cases, versus how the thing was being proposed to be
deployed before. That's option 1. I think it's kind of a minimal option because
all it's saying is do the homework to think about this really hard and disclose
the consequences. The other option is to do something more like what Éric said
in his Discuss, or at least hinted at, which is to say this isn't the only way
you could build this piece of the control plane; you could build it in a way
that isn't likely to leak instead of one that is likely to leak. We know how to
do that in BGP, it's just more work and more costly and I acknowledge that it's
not easy. It wouldn't make me happy if I were somebody who had written this
document or had built a product based on it, but it's an option. And it
deserves to have a serious conversation about it instead of just saying, this
ship has sailed and there's nothing we can do. Done.

Alvaro: This goes back to the base architecture. Yes, I agree with that. This
builds over that. We need to consider whatever extra things this is adding. I
don't think at this point we can go back and say you need to re-architect the
whole solution because for better or worse, we already published 8402.

John: I'm not saying you need to re-architect all of SRv6, that's silly. What
I'm saying is that bess-srv6-services could be done in other ways. The most
obvious has to do with introducing a new AFI/SAFI to carry the sensitive
information around.

Alvaro:  Now we're moving into working group consensus and were they wrong or
whatever.

John: Isn't that what we're supposed to be talking about here?

Martin V: I don't think we discuss WG consensus, no.

Warren: We have in the past realized that things we published maybe had some
issues that should have been more fully addressed before we approved it.
Somebody offlist poked me about, well, how is this different to the standard
thing? One of the things was this is largely for signaling EVPNs. I think there
is more concern, because if somebody injects a packet and can steer it, instead
of them just being able to mess with traffic which happens to be transiting a
network, you can now steer packets into someone's VPN. If I have an EVPN across
a Telia network, packets can be injected into my internal network which I am
using Telia as an example for a transit for the VPN. So I think that this is
not just that leaks potentially now make bad things happen within Telia's
network. It's Telia and everybody who is carrying an EVPN network across Telia.
So I think that the scale, or scope, of the problem is larger if it is used for
EVPN services. Alvaro is looking very confused. I suspect I worded things badly.

Alvaro: No, I think what you're saying means yes, let's go consider more of
what the impact may be, which is further from just my network. I completely
agree with that. I was just confused at what John wrote in the chat.

John: If you want to take that up, we can, but I don't think we have to.

Alvaro: I think that's fine.

Martin V: There is Ketan on the call; do you want to hear from him on that
aspect?

John: I'm okay with hearing it; if Ketan has made time to come to the call, and
we have time on the agenda, he should go ahead and share his perspective.

Ketan Talauilkar: Thanks everybody for giving me the time. I was here really to
listen and grasp what the key concerns were better than over email. What I take
away from Warren is really the security aspect and the ability to inject
packets into other VPNs, and that's really the concern. So I don't want to take
too much time because we're already discussing over email threads, but I will
also work with my co-authors and we'll try to elaborate and explain those
things and how the filtering is not really that difficult. But we'll discuss
that over emails if that's okay so we don't take too much time here. Warren, I
understand that's really the main concern on this document.

Warren: A large part is the fact that if I'm a customer and I'm using a
provider for EVPN services, I am now vulnerable if something bad happens
because of an issue with the provider network. People can inject packets into
my internal network. Yes, that's somewhat of a base concern with SRv6 and
EVPNs, but it's made it somewhat more likely because if the bess information
leaks, or BGP information leaks, people are more likely to be able to
accomplish that. Thank you.

Ketan Talauilkar: Thank you.

Martin D: So, we're two ballots short on this. I'm one of the six people who
did not ballot, is this a traditional thing where there are a couple of
Discusses and we're going to work through it and it'll be ready to go, or is
this going to go back somewhere for some significant rework? Is it worth the
time of the six of us to ballot this now in the next couple of days, or is this
just going to…

Martin V: I would welcome the additional ballots, yes. Your view is relevant
regardless of whether there are already Discusses on it.

Erik K: If there's some substantial re-architecture work that ends up being
requested?

Martin V: Well, that's only a hypothesis.

Erik K: True.

Amy: Okay, well, it sounds like this is going to have a Revised ID, so with
that we're going to move on.

 o draft-ietf-babel-v4viav6-07  - IETF stream
   IPv4 routes with an IPv6 next hop in the Babel routing protocol
   (Proposed Standard)
   Token: Martin Vigoureux

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

Martin V: I think so, since Warren asked to move it to the top. Warren, I think
I pushed this document to the IESG as a standards track knowing there would
likely be questions on that specific aspect you raised. I myself had that same
question in my AD review. I had asked some advice on the slack chat a few
months ago about what I should do. I think I got a response from Ben which I
interpreted as okay, maybe you should try standards track. As you have seen,
the authors and most likely the WG are okay with moving back to experimental,
which is the same type of document as the one who is already documenting the
use of that IP address. So would that help clear your concerns?

Warren: That would help clear my concerns. I replied to that thread too.

Martin V: Okay, I didn't see that.

Warren: No worries, it was just a very short while ago. But I still don't know
what the right thing to happen here is. I think it would be really really
useful to have this space v4-via-v6 documented somewhere. We have some use of
it in BGP already, but that just says you can set the next top like that, it's
all good. This document spoek a little bit about the potential side effects,
like path MTU discovery, etc. What I would really like is if we had a document
that explained how this works and all the implications, like the actual
forwarding parts. I'd be fine with experimental but I'd be a bit sad because I
think it would be really nice to have a standards track document doing it. I
don't think this is the one to do it, though.

Martin V: I fully agree with you.

Warren: Once we have it better explored and documented, I'd be happy to help
bring this back and bump it from experimental to standards track or something.
If the WG is fine with experimental, I'll happily clear.

Martin V: I think the WG is fine with that. It was one of my recommendations to
take that part out of the document and try to push it separately. If we can at
least move forward on this with experimental status, I think it's fine.

Warren: Okay. I'll clear now, with the understanding that it will probably move
to experimental. And hopefully somebody will at some point publish this because
it's very cool.

Martin V: Thanks very much.

Amy: If Warren is going to clear his Discuss, we have enough positions and it
can pass. Are you going to revise it to move it back to experimental?

Martin V: Yes. It needs revising anyway so that's Revised ID.

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

 o draft-ietf-spring-segment-routing-policy-17  - IETF stream
   Segment Routing Policy Architecture (Proposed Standard)
   Token: Martin Vigoureux
   IANA Review: IANA OK - Actions Needed

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

Martin V: You tell me! Again, I feel Ketan is pretty responsive, but if there
are burning issues you want to discuss, let's discuss them.

Ben: I guess I was curious if on my first Discuss point about this VPN label V
thing, am I just totally missing the point and this is the normal way to do a
VPN? If anybody knows offhand.

Martin V: Yeah, I think you're missing the point. I rapidly looked through that
part but that's the impression I got when reading it quickly.

Ben: Okay. It may just be that there's a reference I didn't look at or
something. Thanks.

Alvaro: Can we talk a little bit about updating 8402? It seems to me that this
document doesn't just go into detail about what the SR policy is, it adds to
what 8402 is defining; in fact, it adds a lot to what 8402 is defining. What's
your opinion?

Martin V: I kind of agree with you. I have to admit. It didn't strike me as
absolutely needed, but I understand your point and I don't really have a very
strong counterargument to that.

Alvaro: In the overall scope of things it's not a big deal.

Martin V: No, I don't think it's critical, but I understand your point and I
think it makes sense.

Alvaro: Thanks.

Martin D: If I could return to my previous question on the bess draft, I just
want to ask it a different way. Is there a scenario where this is going to be
ready to be approved by the existing IESG but for the missing ballots? Or is it
almost certainly going to roll over to the other IESG and we're going to
certainly put it on a telechat anyway?

Martin V: I'm not sure. I can't say whether all the Discusses will be resolved
before I leave, but I don't think that should enter into the equation of
whether or not you should ballot on it. I think ideally we ballot on it by the
time it comes to the agenda and I can understand that sometimes it's not always
possible and that's perfectly okay, but it's still okay to ballot afterwards
especially since discussions are still ongoing.

Martin D: Okay.

Éric V: The authors are reacting as well, right, so it's getting through.

Martin V: So back to the segment routing policy, this one will require a
Revised ID as well.

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

 o draft-ietf-sacm-coswid-20  - IETF stream
   Concise Software Identification Tags (Proposed Standard)
   Token: Roman Danyliw

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

Roman: No, I think the authors will get back to them and I can provide a quick
summary response.

Rob: Can I quickly ask, on the Semver reference, do you know which way they're
planning to go with that? I think there isn't necessarily a great answer here.

Roman: I think they're going to want to carry the reference forward. I had this
same conversation with them about that. There's no good reference for Semver,
unfortunately. I think they'd want to carry forward the one that comes from the
SWID document. We talked about two different approaches. One way that satisfies
the game of normative references, they could have actually just referenced SWID
as the reference for Semver that you would then ref. Semver just seemed like a
lot of engineering to do that. Because we're just kind of hiding the fact that
it's pointing to the same thing. So, for consistency, I thought they should
just point to the same one.

Rob: Okay. I wonder whether just having a comment to indicate the Semver 2.0.0
standard isn't set in stone or something, maybe that's the solution.

Roman: I don't know the answer to that, but this is where there's a little bit
of quicksand because it almost doesn't matter whether it's set in stone or not.
Whatever SWID said, this is saying the same thing.

Rob: Yes. I think that is key. Okay, thanks.

Roman: Ben, did you want to chat about yours?

Ben: I don't think so. Henk did send a reply that I think agreed these are
pretty straightforward.

Roman: Okay. I appreciate everyone's review. This is definitely a Revised ID
Needed.

Amy: Okay, this stays in IESG Evaluation with Revised ID Needed. Thanks.

 o draft-ietf-i2nsf-nsf-facing-interface-dm-21  - IETF stream
   I2NSF Network Security Function-Facing Interface YANG Data Model
   (Proposed Standard)
   Token: Roman Danyliw

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

Roman: Not unless the holders want to chat. That all seems like good feedback
we need to consider.

Amy: Okay; revised ID needed?

Roman: Yes please.

 o draft-ietf-i2nsf-nsf-monitoring-data-model-15  - IETF stream
   I2NSF NSF Monitoring Interface YANG Data Model (Proposed Standard)
   Token: Roman Danyliw

Amy: I have a few Discusses; do we need to discuss any of these?

Roman: I did want to check in with Francesca and Ben about handling the HTTP
headers. Your question is kind of on point about why are the headers that are
there, why aren't other ones there and why were these chosen and what it's
going to be used for. I think that's a good conversation to have with the
authors. My quick answer to that is something got tripped, it's HTTP related,
and the common headers got included. Certainly the cookie stuff is privacy
sensitive and we should probably put a callout for that in the security
considerations minimally. If you want to talk to the authors about which ones
are needed or whether there's some fancy reference based thing we could do,
that might make sense.

Francesca: I was just looking for some sort of motivation in the text, because
I expect there is some motivation. Also I don't want to delay this document,
but I would be much more comfortable if the httpbis working group was consulted
in that conversation. So maybe while the authors fix the comments we can also
start a thread on the httpbis mailing list to get some feedback. Hopefully it
shouldn't be too much of a problem but it will give me peace of mind that it's
been considered more than just oh, these look good so let's take these headers.

Roman: That makes perfect sense and we should absolutely do that. I think where
they got the list from, is the things you would typically see pop out of
security devices. I think that's why it's in a sense not comprehensive. I'm
putting words in the mouth of the document but what pops out when you talk
about web alerts? What does it expose for you? I think that was the mindset.

Francesca: Okay. Even having a sentence stating that would clarify things for
me.

Roman: Sounds great.

Ben: To augment what Francesca said, understanding the why would be really
helpful to me. In particular, is it always recommended to put the cookie out or
are there some situations where it's recommended to put the cookie out? I think
the answers for those two scenarios might be different. I definitely understand
there are some situations where you want the cookies, but whether the default
should be to always send the cookies is less clear.

Roman: Sure, that makes sense. I'll wait for the authors' response and make
sure they understand the gestalt to explain why a [...] would push this out.

Francesca: I also want to just quickly mention the other Discuss point I have
and just want to clarify that there is a language tag already that was added
after the ART-ART review, and that's great. But my comment is that right now
the document states this tag is optional if the implementation thinks that it
can't process more than one language. I think it should be that it's optional
because the textual fields are optional. And every time you have a textual
field you should have this language tag, possibly with a default value.

Roman: That makes sense. I appreciate the review on both this one and the
other, I know these are large documents. I think this is a Revised ID needed.
Unless Rob or Éric, you want to comment? Okay, thank you.

 o draft-ietf-calext-ical-relations-09  - IETF stream
   Support for iCalendar Relationships (Proposed Standard)
   Token: Francesca Palombini

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

Francesca: I don't think so. Thanks, Ben, for spotting that. I have to admit, I
trusted the shepherd writeup and I didn't go and check the ABNF myself.

Ben: I was also surprised to see that.

Francesca: I think it was probably a copy-paste error or something that came
after the shepherd writeup.

Zahed: I was looking into the langparam also. This langparam is actually a lang
that is basically defined in 8288. I was not sure if maybe I was looking at the
wrong things.

Ben: I think the information content of what it conveys is what's specified in
8288, but I was looking at more how it is represented in the protocol, and the
formal grammar for the ABNF is what I was worried about.

Zahed: Okay.

Francesca: We'll definitely need a revised ID for this one.

2.1.2 Returning items

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

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

Martin D: They dropped a version a couple of days ago that handled the IANA
concerns so I believe all outstanding comments have been resolved. Thanks for
the reviews, everyone, and this is ready for the announcement to be sent. Amy:
Great, we'll send that on Monday as we normally would. Thank you.

2.2 Individual submissions
2.2.1 New items

 o draft-eggert-bcp45bis-07  - IETF stream
   IETF Discussion List Charter (Best Current Practice)
   Note: This document updates BCP45 to reflect how the ietf@ietf.org
   mailing list is currently being used/managed (e.g., covering that
   some discussions, like last-call, have moved to their own dedicated
   mailing lists).
   Token: Robert Wilton

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

Rob: I'd like to thank everyone for the review comments. This document did have
quite a lot of discussion during IETF Last Call and people were picky about
some of the language in it. I would discuss with Lars about what changes we
want to make and be mindful about what discussions were already had, and not
change too much from what was reviewed previously if that's okay.

Ben: Definitely; I tried to be clear that I was not following all the previous
discussions, and I don't want to revisit things they already went over. So I'm
assuming that my comments will not actually be acted upon.

Rob: I'll check with Lars. I think if this goes into AD Followup, maybe, then I
can check with him and I can also follow up with you. Thank you all.

Amy: So this will go into Approved, Announcement to be Sent, AD Followup. As a
point of procedure, I know Lars has been on vacation all week, so probably
didn't ballot a Recuse on this as the document author. I think we need to
officially state that he recused on this. Does that seem right to you, Rob?

Rob: Yes, I think so.

Amy: Okay, so we will note in the minutes that he officially recused even if he
hasn't put a position in.

2.2.2 Returning items

 NONE

2.3 Status changes
2.3.1 New items

 NONE

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 NONE

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 NONE

3.2.2 Returning items

 NONE

3.3 Status changes
3.3.1 New items

 NONE

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 o conflict-review-pauly-dprive-oblivious-doh-01
   IETF conflict review for draft-pauly-dprive-oblivious-doh
     draft-pauly-dprive-oblivious-doh-10
     Oblivious DNS Over HTTPS (ISE: Experimental)
   Token: Éric Vyncke

Amy: I have no Discusses, so unless there's an objection it looks like this is
ready to go back to the ISE.

Éric V: I think so. Thank you for the review.

Amy: Okay, so we'll move on.

 o conflict-review-irtf-icnrg-nrsarch-considerations-01
   IETF conflict review for draft-irtf-icnrg-nrsarch-considerations
     draft-irtf-icnrg-nrsarch-considerations-07
     Architectural Considerations of ICN using Name Resolution Service
   (IRTF: Informational)
   Token: Erik Kline

Amy: I have no Discusses on this, so unless there's an objection it looks like
this can also go back to the IRSG.

Erik K: I think Alvaro wants me to update the text; I sent a reply to Alvaro in
email.

Alvaro: Sorry, I haven't seen it.

Erik K: I didn't see it until this morning anyway. I didn't list any specific
INT or RTG area groups because it's sort of like a whole new stack in some
ways. But if you want, I can basically say INTAREA and RTGWG? If an explicit
callout of some WGs would be good.

Alvaro: Sure, if you think you need to call out a routing WG, that's fine.

Erik K: I think I do, there's a substantial portion of the document that's
concerned with routing.

Alvaro: Okay.

Erik K: I'll update this with a list of WGs and hopefully that will address
Roman and I think Zahed had a comment on Slack about it as well. So there will
be an -02 I guess.

Amy: Okay, this will be Approved with the tag similar to AD Followup. When
you're satisfied with it, we'll send that back to the IRSG.

 o conflict-review-ietf-regext-tmch-func-spec-00
   IETF conflict review for draft-ietf-regext-tmch-func-spec
     draft-ietf-regext-tmch-func-spec-12
     ICANN TMCH functional specifications (ISE: Informational)
   Token: Murray Kucherawy

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

Ben: I was sort of curious; the shepherd writeup talks about that there are
some URIs that have been squatted on and they're registered in the wrong part
of the registry. It wasn't entirely clear to me if this is the sort of scenario
where we should acknowledge that there was squatting and put an entry in the
registry but still make them also register what the right thing should be, or
would having two possibilities here just cause confusion?

Murray: That's a good question; that never came up during the discussions. I
think the conclusion has been made that it wouldn't do us any good to block
this because it's already been deployed very well and very extensively with the
incorrectly done name. That's kind of where the conversation had stopped. So I
can raise this with him and suggest that we do it as you suggested, but let
this go anyway. I don't think there's a reason for us to block until it happens.

Ben: Okay. I totally lack the domain expertise here to know if it's the right
thing to do. There have been some other vaguely analogous situations where I
understand people are going to do the wrong thing but we still need to make it
possible for people to do the right thing. But maybe that's actually harmful.

Murray: I don't know about harmful, but we might be registering a code point
that it's virtually guaranteed no one will ever use it. I was trying to think
about how we could do something to indicate that this didn't just pass through
unnoticed. Let me take that suggestion back to the ISE, it's a good one.

Ben: I know there's been at least one case where we were able to put a footnote
that's attached to the entry in the registry that says this shouldn't have
happened, but it's here because of reasons.

Murray. Right. So he did add that in the document but I don't know that we
talked about putting it in the registry. That's a good idea; I'll take both
those ideas back to him.

Ben: The other question I had was about the registered contact.

Murray: Yes, on my ballot I even said that, so thanks for the reminder. I think
that should just be IESG. Is there some reason we should do something different?

Ben: I wasn't sure if it was possible to put an ICANN entity or person there?

Murray: We could. Maybe IESG is just the default. Hmm. I'm inclined to leave it
as IESG because by not having it be us making the allocation in the first
place, the wrong thing happened.

Ben: That's a good point.

Alvaro: I thought that at some point a year or two ago there was a discussion
about who it should be in the IETF, and I thought the answer was the IETF, not
IESG.

Murray: But this is coming from the outside, it's the ISE and ICANN. We could
make it ICANN but like I said this is kind of a weird thing. The answer's not
obvious.

Alvaro: What I meant is that if you were going to put the IESG as the contact,
I thought the default should have been IETF.

Ben: The entry that you list for the organization is the IETF but if there's an
email address associated with it it would be the IESG email.

Alvaro: Maybe.

Murray: I think it probably should be us, unless someone wants to take a
stronger position that it should be ICANN, and I can make that correction.

Ben: I think the argument that we are approving the registration in the wrong
place is a pretty strong one, so I'm happy to have it stay with us.

Murray: Okay. I'll write that up to Adrian right now.

Amy: So I have that the no-problem message is approved and the note that's
currently there is okay.

Murray: We haven't even debated the conflict review itself, so I think that's
correct.

3.4.2 Returning items

 NONE

3.4.3 For action

 o conflict-review-liu-lsr-p2poverlan-00
   IETF conflict review for draft-liu-lsr-p2poverlan
     draft-liu-lsr-p2poverlan-07
     Interface Stack Table Definition and Example for Point-to-Point
   (P2P) Interface over LAN (ISE: Informational)
   Token: Lars Eggert

Amy: This is to assign a reviewer for this draft. Is there anyone who wants to
pick up the conflict review for this document?

Éric V: Somebody suggested someone from the Ops area on this one, right?

Rob: I can check with Warren on this one. I was going to suggest maybe picking
up the other one.

Warren: I haven't looked at it at all yet.

Rob: I just saw the LSR in there and thought it was related to routing.

Warren: I've got no idea what it's about.

Éric V: It's only three or four pages.

Warren: If it's three or four pages, I'll do it.

 o conflict-review-richardson-mud-qrcode-00
   IETF conflict review for draft-richardson-mud-qrcode
     draft-richardson-mud-qrcode-05
     On loading MUD URLs from QR codes (ISE: Informational)
   Token: Lars Eggert

Amy: It sounded like Rob was volunteering for this one?

Rob: I think so.

Amy: Okay, thank you.

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

 NONE

4.1.2 Proposed for approval

 o Privacy Preserving Measurement (ppm)

Amy: I have no blocking comments for this, so unless there's an objection now,
it looks like this new WG can be chartered.

Roman: If possible, could you help me out with the procedures? I'd like to hold
off on officially approving this until I name the second chair. Can I do that?

Amy: Absolutely.  You just have to send a note to support. This is approved
pending information from you, basically.

Roman: I just feel like it gets us on better footing if we have both of them
named. I appreciate all the reviews; Francesca, we talked it through and i
don't think we have another related WG. And Éric, I'll get those editorial nits
fixed.

Éric V: And I think it's pretty sensible to wait for the other chair.

Amy: So it sounds like you're also going to be editing the text of the charter
a little bit?

Roman: Yes.

Amy: Okay, so pending edits and other information from you. When you're ready,
we're ready.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 NONE

4.2.2 Proposed for approval

 o Calendaring Extensions (calext)

Amy: I have no blocks on this rechartering effort, so unless there's an
objection now, it looks like this is approved.

Martin D: I did want to discuss my comment, which I don't think rose to the
level of a Discuss, but one of the chartered items is to document commercial
implementations and designs and stuff, which I always thought was an ISE thing
to do. I don't actually object to a WG deciding to do that work, but if we
don't have change control, what's the thinking here?

Francesca: I think the thinking is just to have a place to talk about it and
formulate the document. Honestly I also don't disagree with you, but if there
is interest and energy to do it in a WG, why not? It gives less work to the
ISE. I don't have a strong opinion on that.

Martin D: That sentiment was why I didn't block. Fair enough, thanks.

Ben: Procedurally it's fine to do it in either place. If there isn't someone
from the company who deploys the protocol who's willing to put the time in to
write the document, and there's someone in the WG who is, this is more natural.

Francesca: And Ben, I saw your comments as well and I'll make sure they are
answered or included or both before it goes out. If we can hold until I get
this fixed?

Amy: We can hold it, just let us know when it's ready.

 o Stay Home Meet Only Online (shmoo)

Amy: I have a block on this charter, and Lars is still not here to discuss it.

Ben: Mallory posted some revised text, which I haven't read but I'm confident
it addresses the issue. So once it gets in the datatracker it should be
straightforward to clear.

Amy: So this is just going to hang until that block is gone and then hopefully
Lars will be back to approve it.

Ben: From the datatracker permissions I guess any AD could change the actual
charter text. I don't know if it's considered rude for me to do that on his
behalf while he's not here. I don't really care.

Amy: We're going to be waiting for Lars to give a final okay anyway, so waiting
for him to change the text is probably fine.

Ben: That makes sense, good point.

Amy: So this will stay here and we'll wait for him.

5. IAB news we can use

Martin V: No news I can give because I missed the calls. Mirja can surely say
something. I'm sorry.

Mirja: Nothing exciting. Just in case you hadn't seen it yet, we appointed a
new ISE, so Eliot Lear is serving as the new ISE starting next month. Then
maybe another point, not directly from the IAB, but there was this request sent
out from Jay about the search committee for the new RSCE. We discussed this
yesterday on the IAB and we'll send some feedback to Jay, but I think the IESG
should also look at that.

6. Management issues

6.1 [IANA #1222953] Acceptance of media type registration from standards
organization AutomationML e.V. (IANA)

Amy: It looks like expert Alexey Melnikov provided a review for this. Does
anybody want to speak to this media type?

Murray: Not about the media type, but this is the request to add them to the
list of SDOs that can register straight to the standards tree. I looked at this
and it seems fine.

Amy: Okay. Any objection to sending that message back to IANA that they will be
added to the list? Okay, we'll send official note to IANA.

6.2 [IANA #1224205] Approval of media type application/oblivious-dns-message
(draft-pauly-dprive-oblivious-doh-10) (IANA)

Amy: Can anyone speak to this one?

Ben: It feels really weird to call an ISE document a standards organization.

Francesca: This was the draft that we discussed in the conflict review and I
added it to this agenda because there is precedent for doing this at the same
time as the conflict review.

Murray: The reason we need to look at this is because it wants to go onto the
standards tree; there are only two paths to do it and the ISE has to follow
this path. This isn't an attempt to add the ISE to the SDO list or anything, we
just have to stamp something that isn't coming from an SDO and is not coming
from the IETF.

Ben: Okay, I was confused about that part then.

Warren: Because it's confusing. We've had this discussion a bunch of times and
it always trips us up. Maybe we could just have the ISE recognized as an SDO
and able to make things in any old tree? It does feel weird that we have this.

Francesca: I think this is like a double/triple check because in this case the
experts were also informally reviewing this registration. The IESG can just
triple check.

Murray: There's a WG now that's looking at media type stuff called mediaman,
and we can ask them to say do you want to leave it this way? Is this rule that
was established 2000 RFCs ago something we want to maintain? But on the
question of this particular one, this is an informal review from Alexey. I'd
rather approve a formal review.

Francesca: Informal in the sense that the review wasn't needed. I think that's
all it means. I like having it as a management item on the telechat just
because when I see them I go back and check that this has been posted to the
media type mailing list, which it has, so I'm even more confident that this is
fine. It was posted and there was no objection.

Murray: Other than that I would like to see one of the media type reviewers
formally say yes, we're going to accept this and then stamp it afterwards, but
I don't feel strongly about that. This is fine with me.

Amy: Okay, so it sounds like this is approved and we'll send an official note
to IANA.

6.3 [IANA #1224792] Acceptance of media type registration from standards
organization PDF Association (IANA)

Murray: I looked at this and it seems fine to me.

Amy: Anybody object to approving the PDF Association? I'm hearing no objection,
so we'll send that official notice to IANA.

6.4 [IANA #1224793] Acceptance of media type registration from standards
organization ISO TC 171 SC 2 (IANA)

Murray: I looked at this and it seemed okay to me as well. Not the media type
request itself, but adding this as an SDO.

Amy: Any objection to adding them as an SDO?

Francesca: No objection.

Amy: Okay, we'll send official note to IANA.

6.5 Finalize the text on the AUTH48 message archive experiment (Francesca
Palombini)

Francesca: The only thing that I have changed as a result of comments from
Sandy and the IAB is that now instead of saying RSE, I say Temporary RFC Series
Project Manager. And I also added IAB since the IAB has confirmed that they
want to do the same thing. There was also a comment about having the same for
IANA, but I answered that comment in the Google Document. I have reopened the
commenting for now just for this session so if you want to take five minutes
and look at it. It's basically the same text we discussed last time. I know
there are things like we talk about the IETF in the beginning and this will
also apply to the IRTF, etc, but I don't know it's necessary to go into that
much precision and details.

Colin Perkins: I think it would be useful to clarify that it's not just the
standards process, assuming the IRTF and the IAB are going to adopt the same
process.

Francesca: You don't think this text is clear enough, the fact that the IAB,
IESG, ISE, etc are considering allowing anyone to read auth48 conversations?

Colin: The last version I looked at had something which said as part of the
standards process we are looking to make the following change.

Ben: Nobody is sharing a screen so you can't see the bit.

Francesca: I can do that, give me a moment.

[cross talk]

Colin: It probably just needs to say, the standards process and other
activities or something like that. Just to be a little bit more inclusive.

Francesca: I cannot share for some reason but I put the link in the chat.

Colin: I think we just need to say "our standards process and other activities."

[Some detailed wordsmithing of the document was discussed.]

Francesca: We're waiting for the IRSG next week to discuss and then we can
hopefully agree on sending it out next Thursday or so. What's the process for
that? I guess we'll discuss it at the informal telechat.

Amy: Before you send it you might want to send a ticket to support so that
we're looking for it and can push it through on any lists where it might get
caught in moderation.

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

None.

6.6 IETF 113 Agenda Conflict Resolution (Liz Flynn)

The IETF 113 pre-preliminary agenda was discussed and deconflicted.