Skip to main content

Narrative Minutes interim-2022-iesg-11 2022-05-12 14:00

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

Narrative minutes for the 2022-05-12 IESG Teleconference

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

1. Administrivia
1.1 Roll call

Andrew Alston (Liquid Intelligent Technologies) /  Routing Area
Jenny Bui (AMS) / IETF Secretariat
Martin Duke (Google) / Transport Area
Lars Eggert (NetApp) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Erik Kline (Aalyria Technologies) / Internet Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Applications and Real-Time Area
Alvaro Retana (Futurewei Technologies) / Routing Area
Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area
John Scudder (Juniper) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
Amy Vezza (AMS) / IETF Secretariat
Éric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area
Paul Wouters (Aiven) /  Security Area
Qin Wu (Huawei) / IAB Liaison

Jay Daley / IETF Executive Director
Roman Danyliw (CERT/SEI) / Security Area

Jake Holland
Spencer Dawkins
Lee-Berkeley Shaw
Greg Wood

1.2 Bash the agenda

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

1.3 Approval of the minutes of past telechats

Amy: Our procedure is to keep these under review for two weeks and May 5 was
just last week, so we'll keep both regular and narrative minutes under review
until our next formal telechat on June 2.

1.4 List of remaining action items from last telechat


     o Roman Danyliw to find designated experts for RFC 8809 (WebAuthn)
       [IANA #1229681].

Amy: Roman could not be on the call today.

     o Francesca Palombini to find designated experts for RFC 9176
       (Constrained RESTful Environments (CoRE) Resource) [IANA #1229995]

Amy: This is on the agenda later as a management item to approve the experts.

     o Security ADs to find designated experts for RFC 9116 (A File Format
       to Aid in Security Vulnerability Disclosure) [IANA #1230049].

Paul: We have some ideas; we're still following up on it.


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

Amy: This is on hold until the end of June.

     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.

Murrray: That's going to be a note on the IESG wiki, it's not going to be a
draft. But I still haven't done it, so leave it in progress.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-dnsop-nsec3-guidance-08  - IETF stream
   Guidance for NSEC3 parameter settings (Best Current Practice)
   Token: Warren Kumari

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

Warren: I think a brief discussion. I think it's not uncommon for BCPs to
request code points. I'm sure if I looked I could find some.

Andrew: Just to clarify that, I debated with myself about that Discuss. When I
looked at this document in combination with what I saw there and the other
Discuss, which raises the fact that you've got a BCP that is updating a
standards track document, and reading the rest of it I got the feeling this
almost felt more standard-ish. I was on the fence. I'm happy to clear the
Discuss but I thought it would be useful to just talk about this, because I was
a little confused here. When I read the document and asked some other people
what they thought of it and they said, this is a standard. So I don't know.

Warren: The WG did discuss it some, in fact a reasonable amount, if it's
standards track or BCP, and I think they decided it was BCP because basically
what it's doing is documenting the best practice for choosing your [cut off]

Paul: I'm not sure if that's entirely correct because the recommendation also
causes interrupt failures if not everybody does it, so that does feel like
Standard to me.

Andrew: The other question is, can you have a BCP that updates a standard?

Warren: I believe you can. We've had a lot of long discussions about what
"updates" actually means. There is no clear consensus, but one of the
interpretations is if you read whatever other document, you should really read
this one as well. That's the sort of flavor of the updates that was intended.

Paul: But that's really true in this case, right? Because if you leave your
iterations at 100, you're going to cause failures.

Warren: Yes. and that's the sort of updates [intended], not the kind that takes
this text away and replaces it with this other text.

Andrew: Warren, do you think we could then potentially ask for a wording
update? That 'update' word implies almost a change to the original one, not
just a 'read this with' that has more connotation to it. I don't know.

Paul: You must read this document to properly implement NSEC 3, right? So this
is as hard of an update as it can be.

Andrew: In which case, it becomes the original question.

Warren: A BCP is the same level as a standards track document. One isn't more
impactful than the other. I can talk to the WG, but the main utility of the
updates is when you look at the original document it will point to this one as
well and say you really really really need to read this as well. It's
referenced as part of the metadata and says it's sufficiently related that it
updates and you need to read it.

Andrew: If it had been that they ask for a code point without the update, or
one of those three issues. But when you put all those 3 issues together and in
my reading of that document that was when I went, oh, this is kind of checking
too many boxes in my mind that it doesn't feel like what I would see as a BCP.

John: I want to jump in on this code point thing. I checked and the registry is
FCFS, which means not only do they not need a standards track document to
request a code point, they don't even need a document at all. All they need to
do is send an email to IANA and ask for a code point. That's the bar that is
set for that registry.

Andrew: I saw that just before this call as well.

John: So let's talk about the other stuff, but the code point thing is not
relevant to this conversation.

Warren: The description of a BCP, to me seems to describe much more what this
document is. The fact that as John says, it mentions a code point but they
could easily have just scribbled on a napkin.

Paul: To me it still feels that it is actually really updating a specific part
of the protocol. You can't really opt out and say they might be best common
practices but I'm going to go my own way because I think I know better than the
best common practices. If you do that you're actually going to break what
you're doing. In that sense it really to me feels like it's a protocol update.
While it also includes best common practices, to me it really feels like a
proposed standard update.

Warren: I think we can do that without having another Last Call, because it's
not going up or down a level. I still disagree because there's no real
definition of what 'updates' means, it's perfectly fine for a bcp to update a
standards document. They're at the same level. But I don't think the authors
will object. I think it's not correct by my interpretation, but it's not a hill
I'm willing to die on. Let me check with the WG and I guess I can resubmit as
standards track.

Murray: I have a suggestion. As I read it and as I hear the discussion, can we
think of this as a profile of a way NSEC3 is used? If it is, you could call
this an applicability statement, which has clearly got to be standards track
and that solves everything.

Warren: I think they can just resubmit it as standards and just change the type.

Paul: IIt's not a profile because you can't really have different profiles. The
world has to agree on at what point you say this is too much CPU and we're
going to ignore it.

Murray: Okay. I've seen work done before where you're describing a specific way
to use NSEC3, for example, that has these outcomes, and whenever you write a
document like that, that's a standards track document.

Warren: Sure. The description of BCP is designed to be a way to standardize
practices and the result of community deliberations. To me this feels like part
of the standardized practices.

Paul: You don't have a choice of going this way or that way, right? If you
don't do what this document says you will not interrupt the rest of the

Warren: Well, I guess that feels like somewhat of a reach. We have a bunch of
BCPs which say you really need to do this in your BGP stuff or nobody will
accept your routes, as a made-up example. And that's a similar, if you don't
follow this operational practice you're not going to interop with other things.
What this says is if you choose a number that is too high for what the current
practice on the internet is, it's not going to end well for you and to me that
feels like a lot of what the BCP series covers.

Éric V: On this one I agree with you, Warren. The complete text of the document
is more a recommendation, so it's really a bcp. Paul's point is valid, though.
But besides this point it's clearly a BCP, right?

Warren: I believe there have been a number of other BCP documents which have
changed what the parameters are that people are willing to accept on the
internet. I'm sure if I look I can find a list. Actually, the more I read
comments and things, the more I think it is BCP. Alvaro has got a thing; "The
BCP subseries of the RFC series is designed to be a way to standardize

Andrew: For me, I'm okay clearing my Discuss. I needed this discussion to get a
bit more clarity in my head as to the views on this because as I said, when I
asked some of the other people I know who work with DNSSEC what their thoughts
were, someone said it's a standard. I had a couple other people say similar
things. I was on the fence and then I got that, so I needed the discussion.

Warren: Thank you. And clearly it was a useful discussion to have, because A,
Updates is poorly defined, B, there was enough back and forth that it's clear
it was a good and valid point to raise. I think that BCP is okay for this.

Andrew: I'll clear mine after this call. I'm not sure, Paul, what your view is.

Paul: For the BCP vs standard, that is not my hill to die on but I do think it
needs an update clause. If someone implements the older document and they don't
read this new one, they decide they can do a count of 10 or something and get
mistreated. I do think the update is required.

Warren: Okay, so we should add an updates thing by making it clear that big
numbers are not good.

Paul: That's right.

Warren: That makes sense to me. Is everyone happy with that?

Andrew: Yes, I've just cleared my Discuss.

Warren: Thank you, and thank you for raising it. It was a good and useful
discussion. If you want a windmill to tilt at I'm sure Mirja will be happy to
let you take over the "what does Updates mean?" topic.

Amy: Okay, so Andrew has cleared his Discuss and we're waiting for a revised ID
with that updated text and this is going to stay a BCP.

2.1.2 Returning items


2.2 Individual submissions
2.2.1 New items


2.2.2 Returning items


2.3 Status changes
2.3.1 New items


2.3.2 Returning items


3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-mops-streaming-opcons-10  - IETF stream
   Operational Considerations for Streaming Media (Informational)
   Token: Éric Vyncke

Amy: I have a Discuss in the tracker, and unfortunately Roman isn't here to
discuss his Discuss. Éric, is this going to require a Revised ID to clear, or
do you want it in AD Followup?

Éric V: First, I think the complete IESG has balloted this document, so thank
you so much. Many comments, and I think Roman's comment is valid. He will read
it in the narrative minutes and it's already replied to. We have an author on
the call, Jake Holland. Jake, if you don't mind, can you explain the plan to
address everything in one minute?

Jake Holland: Sure. In the response message we sent to Roman and the IESG, we
tried to distill what we thought he was looking for as we understood the guts
of the comment. I think he raised a good point that traditionally in targeted
advertising it relies on user tracking. We thought the important thing to try
to communicate to media operators was A, that this is a privacy problem, and
that it's happening with some regularity. And B that there are some proposed
mitigations for this, although at the time of this writing they are not
standardized. You might be aware Google had a [flock?] proposal and that
stopped, but they've replaced it with a topics proposal, so that's the one we
were going to link there. This is very recent and a sort of ongoing
development. We were not sure if there was anything else we needed to cover in
there; we had a few suggestions for places to find worthwhile references about
it but I don't think we were super happy with the references we found about
documents outlining the scope of the privacy problem. We're hoping we could
find others. It's really the archivability and the stability of the reference
as far as I could tell. I didn't really find good scholarly articles about it.
So I feel like there is still a little bit of tuning on the proposal and I'd
like to get Roman's feedback on it, but we think we've tried to address what he
was asking for.

Éric V: Thank you. And Zahed, as I wrote, I'll check whether the TSV-ART
comments have been addressed. We need to wait for Roman to clear his Discuss so
Revised ID Needed is the next step. Thank you, Jake.

Amy: Thank you Éric and Jake; this will stay in IESG Evaluation with Revised ID

3.1.2 Returning items


3.2 Individual submissions via AD
3.2.1 New items


3.2.2 Returning items


3.3 Status changes
3.3.1 New items


3.3.2 Returning items


3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 o conflict-review-dashevskyi-dnsrr-antipatterns-00
   IETF conflict review for draft-dashevskyi-dnsrr-antipatterns
     Common implementation anti-patterns related to Domain Name System
   (DNS) resource record (RR) processing (ISE: Informational)
   Token: Warren Kumari

Amy: We have a new Discuss; do we need to discuss that today?

Warren: Yes please, I'd like to discuss it. I actually had a conversation with
the DNSOP chairs about this document. Firstly, the authors have taken it to the
ISE and we only have a fairly limited number of things we can say in the
feedback thing. It didn't really seem like this was conflicting with the DNSOP
WG work, but more importantly, the authors had actually taken it to DNSOP and
DNSOP made it fairly clear they were not interested in working on this. There
was some discussion, DNSOP seemed to not like the cut of their jib, and so
while we could say this conflicts with work in DNSOP that feels like a bit of a
reach. It could also be viewed as trying to stop the work from progressing by
making them take it to a place where it's clearly just going to languish and
die. I don't know if that covers it; I believe I put a link into the actual
part of the thread in the DNSOP discussions. I don't know if that addresses
your question at all.

Paul: It does; I'll clear my Discuss.

Warren: Good. It was a good point; I actually followed up with the chairs and
asked what I should do. They looked back through it as well. Okay, thank you.

Amy: It sounds like Paul is clearing his Discuss so it looks like this conflict
review message is approved to go back to the ISE for this document. I'm
assuming you want us to remove the additional background/context in the square
brackets from the announcement?

Warren: From the announcement, yeah I guess so. We had somewhat of a discussion
about this with the previous ISE and it seems like having an easier way to
include that sort of thing might be nice. I guess from the announcement it's
worth removing but hopefully the ISE still sees it. What do people think?

Francesca: Where are we supposed to put that into the ballot?

Amy: The conflict review message does say that the IESG encourages the authors
and ISE to look at the comments brought up in the ballots which might have more
information. It's not a forcing mechanism, it's very passive saying you might
want to look at the comments.

Warren: To me it seems like it's useful background information.

Amy: You can leave it in the announcement message, absolutely, if you feel it
is important enough that they know that.

Warren: I guess we'll remove it for now but sometime we should probably have a
longer discussion, possibly with the ISE, on a useful way to provide comments
so that when anybody else reads the document they have a way to find other
places it's been discussed, other background. Let's remove it for now.

Amy: Did you want to remove it and make it a comment on your ballot?

Warren: Yes. Is there a button to do it or would I do it manually, or can you
push the button?

Amy: Well, we would do it manually for you, if that's the way you want to go.

Warren: Yes please.

Amy: Okay, we'll make that extra information into a comment on Warren's ballot.

 o conflict-review-rprice-ups-management-protocol-00
   IETF conflict review for draft-rprice-ups-management-protocol
     Uninterruptible Power Supply (UPS) Management Protocol --
   Commands and Responses (ISE: Informational)
   Token: Robert Wilton

Amy: There are no Discusses for this conflict review, so unless there's an
objection now, it looks like this conflict review message can go back to the
ISE. Okay, I'm hearing no objection, so this is approved and we'll get that
sent on Monday as usual.

3.4.2 Returning items

 o conflict-review-irtf-nwcrg-nwc-ccn-reqs-00
   IETF conflict review for draft-irtf-nwcrg-nwc-ccn-reqs
     Network Coding for Content-Centric Networking / Named Data
   Networking: Considerations and Challenges (IRTF: Informational)
   Token: Francesca Palombini

Éric V: Francesca, don't you think it's vaguely related to MOPS?

Francesca: It might be, yeah. I will take your word for it. I was also looking
up a bunch of other WGs that might have been related but I thought it was quite
far so I didnt add them. I actually wanted to have your opinion here and I'm
glad to change it to related to MOPS but does not prevent publication if that's

Éric V: Of course it won't prevent publication, so that's not the point there.

Lars: Do you think it's related to MOPS, Eric?

Éric V: Simply because [it has] a lot of things related to content distribution
and media.

Warren: We sort of had this discussion last week when I had a similar one, I
didn't mention it was related to someone. It turns out you can easily add it
and we don't have to re-ballot. I don't see any disadvantage to mentioning that
work is related, because I don't really know what the purpose ends up being of
saying it's related. What do people use that information for?

Éric V: My point of view is that if we write that the IESG has decided this is
related but does not prevent, it also protects our decision for somebody in
another year to say hey, I'm appealing this because it conflicts with MOPS.
Which will not be the case, but.

Warren: Thank you, I've always kind of wondered what the purpose of that lever

Mirja: I thought the purpose was to give the ISE a pointer, if there has been
some kind of discussion in a WG or whatever that the ISE should be aware of. Or
the IRTF chair in this case, sorry.

Éric V: To add to what Mirja said, I would love to get the authors of this
draft presenting this at MOPS at IETF 114 because it could be interesting for
many people. That's how I see it.

Lars: I really doubt that. This is ICN which is very far from what we are doing
in the IETF, and then they apply network coding, which we're also not doing
anywhere in the IETF. I would rather send the MOPS people over to the RGs
rather than having the opposite traffic. These are two technologies that have
basically not found a home in the IETF.

Mirja: I agree with Lars and this is also just a requirements document, it's
not like something that needs huge advertisement in the IETF.

Éric V: It could only be interesting for the MOPS people. I don't go further in
my attention. That's all.

Warren: Is there a downside to saying, this sounds interesting, want to chat?

Éric V: That's basically it. I would suggest to the MOPS chairs to contact
these authors and see if they are willing to present 5-10 minutes for education.

Warren: It sounded as though Mirja/Lars had some larger concerns. You know
what, that's not a useful discussion to have now; let's move on.

Lars: One reason is that both ICN as a technology and network coding is full of
patents. Both RGs have research groups that basically own patents on various
schemes here. While that's not different from many other things related to
media, there are a lot of patents in encoding anyway, both of these groups have
in the past tried to push their patents into RFCs and standards. I'm not sure
if they would be super productive, I can't stop you, but I'm sort of wondering
if MOPS doesnt have more important things to spend their time on.

Warren: Thank you.

Mirja: It's good to coordinate stuff and make people aware but I just didn't
feel this document is a really important document, it's just smashing a couple
of things together and not thinking any further. I didn't think this is the
right starting point to have cooperation here.

Éric V: Fair enough.

Francesca: Going back to the conflict review, I'm fine with adding MOPS as
related work. Does anybody have an objection to that?

Mirja: I don't think it's actually necessary, but do whatever you want.

Zahed: I read the document and I'm also interested in MOPS and MOPS never came
up in my head. Maybe this is something I don't believe the media industry and
distribution industry will pick up in the next 10 or 20 years, but just my
feeling was that MOPS didnt pop up when I read the document. I don't care but
maybe it's good to add for the future as Eric mentioned.

Francesca: Any other opinions? I'm very split here, I don't have an opinion
either way.

Warren: It seems like the purpose of 'is related to' is so the ISE knows about
it, and if people don't say why didn't you mention this later, we can just
point at it and say we did.

Mirja: Creating awareness is really important if it could impact protocol
standards that we are doing, or it could even be an item that could have been
adopted by a certain WG and they rejected it. That kind of information would be
really important and I don't think that's the case for MOPS. I don't think MOPS
would take any work in that space and I don't think it would directly impact
any work in MOPS. just having awareness is not the bar here, I think.

Zahed: Francesca, if it helps, I'm changing my opinion to just add it for

Warren: Why not?

Francesca: This is my first conflict review as well so it's kind of the
question of how far related do we want to go to. Okay, I'm calling it, I will
add it.

Éric V: Thank you, and no hard feelings if you decided not to add it.

Amy: Okay, so I'm hearing that the conflict review is approved and the note is
going to be slightly edited to add MOPS. After that's done it's ready to go
back to the IRSG.

3.4.3 For action

 o conflict-review-schanzen-gns-00
   IETF conflict review for draft-schanzen-gns
     The GNU Name System (ISE: Informational)
   Token: Lars Eggert

Amy: Is there a feeling on who might be able to do the conflict review for this

Warren: I cannot; I am deeply conflicted on this topic and it would look bad if
I were to do it.

Paul: I probably feel pretty negative about this so I think I will be out too.

Lars: It would be helpful if it's someone who knows something about the proto
technology area. The purpose here is to figure out whether there's a conflict
with IETF or not.

Warren: Personal views only, I believe that this does conflict with IETF work
because when somebody looks up a name, www.who, it is unclear which name
service it should be looked up in. In addition, it has been stated quite
clearly that the belief is that a name like can be overridden
using this protocol. To me that feels like it does conflict with the DNS work.

Paul: That is new to me because I thought they were having their own fake top
level domain.

Warren: There was a DINRG meeting where Christian Grothoff stated that because
DNS and others had requested special use names and were not granted them, they
have decided to instead squat on the whole name space. Whether or not that is
still true is unclear, or whether that was just Christian's stance, but he
specifically stated it was a feature that anybody can decide that they believe
a name should be resolved to this and not to that, and that's the choice they
can make.

Paul: That's interesting new information.

Rob: Can I ask two process questions here? One is, Warren, are you really
conflicted? It sounds to me like you'd be a good person to do the conflict
review on this because you know the technology on both sides of this. And the
second question is, even if the IESG comes back with a recommendation saying
they should not be published, does the ISE have an opportunity to override that?

Warren: Yes, the ISE can always ignore our Do Not Publish.

Rob: So really it's just our recommendation and our opinion. I'm not saying the
ISE would override in this situation. I'm just wondering whether Warren, you
would be a good person to do this. Not trying to throw you under the bus.

Lars: I have a similar feeling because it sounds like Warren would really argue
for a DNP here. So if anybody else did a conflict review that didn't say DNP, I
think we would have a discussion with Warren who really thinks this should not
be published, right?

Warren: I don't know if I would say DNP. I believe that it conflicts with the
name space, but not necessarily the DNS protocol. And even if it does conflict
with the DNS protocol, who's to say that our protocol is the best one or the
right one? I believe that it's really complex.

Erik K: Don't we have a document about a single DNS route?

Warren: There's an IAB document on a single DNS route.

Erik K: And if you can't tell which tree you're looking it up in, isn't that
like, indirect conflict?

Warren: It's an IAB document, it's not an IETF document.

Alvaro: And it would only refer to the DNS, not to other systems.

Warren: Yes. I can't actually remember if the IAB statement is actually
specifically clear on name space.

Lars: But it's also the name space that's ours, right? Or ICANN's. It's not
only the protocol. The two are not separate.

Warren: That's an ICANN fight, not an IETF fight.

Éric V: If you have two www.example.orgs pointing to different machines at the
end, we do have an issue, right? Which is our mission. And there are 2 RFCs,
right? If I'm implementing this one I go there, if I'm implementing this other
one I go another place. That's a problem.

Alvaro: We already produce multiple solutions for different things. Routing has
27 different protocols.

Éric V: But you reach the same destination, right?

Warren: Again, that's not really a protocol conflict, it's that ICANN should
possibly care.

Rob: Warren, am I right in thinking that they can redirect that domain to
somewhere else if enough people said actually, this domain should be X?

Warren: I believe so, but also I believe that it's largely a person or group of
people who can decide which sort of resolution they use.

Paul: So that really combines two things. It's not just that they are having an
alternative protocol to DNS and we could all argue and say if someone develops
DNS 2.0 at some point it comes here and as long as the ownership of the domain
names are held intact, that could be okay as an alternative method.  But here
we're really looking at a method that overlays and splits existing ownership,
and that is more problematic.

Warren: You said domain name and ownership of domain name. That's clearly not
the IETF's prerogative, that's ICANN's.

Paul: Yes, but this protocol is meant to almost attack that concept.

Warren: Not the IETF's problem, as far as I can see. That's something ICANN may
wish to care about and take up the fight over.

John: I just pasted the first line of our mission statement, which is "The
mission of the IETF is to make the internet work better." So are you sure it's
not the IETF's problem?

Warren: I saw a company who was trying to invent a whole new thing called the
metaverse, and I don't think that makes the internet work better. Should we
have an opinion on that? There's this other company who makes routers and they
charge more than they should because they're making a profit. That's a major
issue. Should I shout at them? I'm being a complete ass here.

John: You're making a slippery slope argument. The reason they pay us the big
bucks is so we can decide.

Warren: I personally think the GNS stuff is potentially dangerous for the
internet and bad for end users. However, some of that falls into opinion and
the fact that we have the DNS and it's the primary name resolution service is
sort of a happy accident. IT could have been a different name resolution
service. The fact that their name resolution service and our name resolution
service can map the same strings to different results, I think is not good for
the user but it's not that the IETF owns any set of words that are made up of
labels, digits, and hyphens with dots between them. Obviously I've had lots of
discussions about this topic in various places, and there was the IAB E name
workshop, etc. but there is a musician called, and that is a name
which refers to a person, and it is using a structure which looks like a DNS
name. But I think it would be a massive overreach if the IETF claimed you can't
use something to map from that string to an object simply because we happen to
have started using  it a long time ago to map names to computers.

John: That really seems kind of like a specious example though, because in the
one case, this document that is in front of us, they specifically do want to
map from names to computers, right? Nobody is trying to claim ownership on's name. I think the argument here is mapping names with a particular
format out of a particular name space to IP addresses. It's that restricted.

Warren: We didn't publish the onion protocol, we said we'll eventually add your
string to our set of things we will treat interestingly. Yes, this is somewhat
different. There's also a bunch of other things where there are ways to refer
to computers that use systems that could conflict with the DNS.

John: I have a question, and I also noticed Lars has his hand up and is waiting
patiently. My question is don't we have a way of puting a statement into these
things in addition to the yes, no, maybe so that says we think this is a really
stupid idea but whatever.

Warren: Yes, I believe we can add an IESG note. The ISE editor will include, I
don't know if they're required to, but generally will. We have tried a number
of times in DNSOP and the IESG and the IAB to address this whole problem of
alternative name resolution systems and conflicts between naming systems, and
even what the hell a naming system means, like what is a name space? And we
have sadly failed fairly spectacularly. A while ago DNSOP managed to publish a
document called special use domain name problem statement and it was planned
that there would be followup work from that. We have been unable to move it
forward. When .onion was delegated, it was also said that we're going to
largely pause new special use domain names for now, but we didn't follow up
from that. There's a lot of background and history ehre. If the IETF had been
much more organized and we had a clear statement of this is what a name space
is, this is what it means to use, this is how other resolution systems should
work to interoperate with ours, I think we would have a better place to stand.
This is actually a huge long topic so probably we shouldn't spend it all now.

Lars: That's why I had my hand up. We need a name at this point and then we can
have a discussion later. I would also point out that I think the ISE is
supposed to have done their technical review with the editorial board or by
themselves by now, so we can ask Eliot to see if there's anything he can
forward, maybe confidentially to us, that would shed some light on whether
there has been enough discussion about whether this should be published on the
ISE's stream. I'm also looking at 5742 and if we want to put a DNP flavor on
it, there are three options. One is that it would disrupt IETF work done in
some WG, which i'm not sure if we can make that argument, we can say it
violates IETF procedures for something and we would need to say what that
something is, and i'm not sure if we can because administration of the global
name space isn't really an IETF procedure. Or we could say it extends an IETF
protocol, which it doesn't do either. I don't think we technically have a lot
of availability here to say no. We should definitely think about doing an IESG
note and that might be a discussion to be had in parallel with the conflict

Warren: Thank you. Whatever we do here, I just want to let people know there is
a huge amount of background and please take some time to become familiar with

Lars: Warren, I think realistically it will need to be you who has that
background already, or someone else like you. I don't think the person doing
the conflict review is going to get that background just for the purposes of
doing this conflict review. If you think the background matters I would really
ask that you take it on.

Warren: I think the background matters hugely regardless of this document. I
think the fact that nobody knows what means is a problem that the IETF
should address. We have said that we would take it on and work on it but we
have not really managed to do so. Does the conflict review have to be proposed
by an IESG member? Otherwise I think we could either kindly ask Suzanne Wolff
or Wes Hardaker to do it. Because of my previous statements on this, if I
propose one, unless I propose we can publish this, which I actually probably
think is the right thing, even if I believe we should DNP, and suggested that,
I believe there would be huge grounds for appeal which would succeed. I
actually think it should be published.

Mirja: Let me say something. This is just a conflict review. Everything you are
supposed to say is this should not be published because there is a conflict
with the work in the IETF, not because you think it's a bad document. That's
not the question here. If you think it's a bad document you should send this
information to Eliot and give him your review and input because he has to
decide at the end. What Lars just proposed, reaching out to Eliot and asking
what the review panel thought of this, is really the wrong thing to do. It's
the Independent stream. If you want to have a discussion about the document do
it in your personal capacity with Eliot, not from the IESG.

Zahed: I think we are discussing this without having a reviewer on board, and
I'm getting a biased view. That will not help me reviewing whatever the
proposed conflict review is. I don't like this discussion right now, sorry.
This is not helping. I agree with Mirja. Please send the background information
to Eliot in your personal capacity but I'd like to see a review and then I'll
read the document and see whether the review makes sense or not.

Lars: That's not how this process works; you're not going to get a review.
You're going to get a post-conflict review response.

Zahed: That's what I meant.

Lars: So it's just three lines. If you're lucky the person putting that
conflict review together will put a comment on the ballot.

Warren: I would really rather someone else do it. If that's not possible, it's
easy enough for me to choose the thing that says it's related to work but
doesn't prevent publication and you all can disagree with me publicly on that.

Erik K: I don't think there'd be disagreement, warren.

Warren: I don't actually know what the right position is, but I think because
I'm conflicted, the only thing I can suggest is does not prevent publication.

Mirja: It's not you who says it, it's the IESG that provides the conflict

Lars: We're balloting on this.

Mirja: The message that goes to the ISE is from the IESG, not from one person.

Warren: However, if I'm the one proposing that, the authors would have a
reasonable position to say the person who proposed that…

Éric V: Do you want to get the freedom of someone saying this doesn't relate to
the IETF and then discuss it?

Warren: No, because it clearly does. It relates to work in DNSOP. It's just
whether that prevents publication or not.

Éric V: If someone else writes it, let's say I do it and say it's related to
DNSOP but doesn't prevent publication, would you object to it?

Warren: I don't know.

Lars: We've got to move on.

Warren: I will take it and I will propose a conflict review.

Lars: Thank you, Warren.

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


4.1.2 Proposed for approval


4.2 WG rechartering
4.2.1 Under evaluation for IETF review


4.2.2 Proposed for approval


5. IAB news we can use

Warren: There was some discussion on the BOF charters, and the main thing I
wanted to note is about one BOF being proposed
[bofreq-hardjono-secure-asset-transfer-protocol-04]. I wanted to note for folks
that this is different to the secure credentials BOF which we had last time.
When the IESG looks at the BOFs, just a note that when the IAB looked at it
they were confused if they'd already talked about it. Also on the call there
was a discussion on the retreat agenda with the note that if you've got an
agenda item it's useful to have slides and please share them before the retreat
so others can look at them, and I think that's good advice for the iesg as
well. Those were the two primary things.

6. Management issues

6.1 [IANA #1229995] Designated experts for RFC 9176 (Constrained RESTful
Environments (CoRE) Resource) (Francesca Palombini)

Amy: Francesca has named Carsten Bormann, Jaime Jiménez, and Christian Amsüss
as designated experts to these two registries. Is there any objection to these
three people for the registries named in the email? Okay, hearing no objection,
they are approved and we'll send official notice to IANA.

6.2 [IANA #1230489] renewing early allocation for
draft-ietf-bess-evpn-ipvpn-interworking (IANA)

Amy: Andrew is the AD for this WG and we are asked to approve the renewal of
this early allocation. Andrew, do you have anything to add?

Andrew: I did look at this and I didn't have any objection. I responded to IANA
as such before they sent this through to put it on the agenda, so I'm okay with

Amy: Is there any objection to continuing the early allocation for this

Éric V: Do we know the status of the draft, Andrew?

Andrew: There seems to be a lot of back and forth but they do seem to be making
some progress on it.

Amy: Okay, I'm hearing no objection to this renewal so we'll send official note
to IANA.

6.3 [IANA #1230488] renewing early allocations for
draft-ietf-lsr-ospf-bfd-strict-mode (IANA)

Amy: The AD for this document is John. John, anything to say on this renewal?

John: The document is in my queue for publication; we should approve it. It
doesn't seem like a big deal.

Amy: Any objection to approving the renewal of the early allocation for this
document? Hearing no objection, so we'll send official note to IANA.

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

Francesca: If you remember in March I had brought this format for the ballot
from the HTTP WG. I have a document coming, soon to be in AD Evaluation so it
needs to go through Last Call and everything, but since we are meeting again in
the beginning of of June maybe on the next telechat or the one after, I wanted
to give a heads up that I will be asking everybody to please format your
ballots with that format. I also had taken questions and comments last time we
talked about it and I will make sure they are all answered in an email I will
send to the IESG at the same time I bring this to IESG Evaluation.

John: Can I request that you put a link or something about the requested format
in the ballot text so we can find it and remember to use it?

Francesca: Definitely. I will add it to my ballot as well so it's easy to find,
and I will also add a pointer to an email that is not yet written but will be
when it comes, with more explanation there.

Warren: What I was objecting to before was the way that it was presented as
creating a policy you all will follow.

Francesca: That was not the intent, and I'm sorry it was taken like that. I
didn't mean to and I'm sure Mark didn't mean to. They presented it as, can you
ask the ADs to try this out.

Warren: That's certainly not the tone in which it was presented and I'm not
saying by you, but that's not the tone that it came across in the original
discussion and how it was written up in a bunch of documents in Github and
other places. Moving on.

Francesca: Maybe we can have that discussion as well separately and try to
improve that text as well so it doesn't come off like that. There were a number
of other practical questions, and I saw Erik K and Lars have formatted a couple
of their ballots like that. I brought all of that to Mark and I'll put all the
answers in an email I'll send to the IESG. Just a heads up this is coming and
you'll see more about it. Thanks. And thanks for being willing to try.

Lars: Could I get an action item to facilitate the repeated update of the
document shepherd writeup form? John has initiated a discussion with BRAd which
is great and will lead us to some changes, and Mark Npottingham has sent
suggestions. It's on Github under the WG chairs repository so we could do a PR
and discuss it there. Let's give me an action item and figure out the details
later. I also just replied to Robert on this whitelisting thing which has been
hanging a little bit and maybe I deserve an action item for that so it doesn't
get forgotten, basically just pushing out the global whitelist again to all WG
mailing lists. I think that would get us 95% of what we want. I got annoyed
earlier in the week when we got all of these errata submitted and removed as
junk. Jay is going to talk to the RPC about whether they can change their
workflow or their tooling or both so that no email gets generated until a human
has looked at this, rather than two emails getting generated for every junk
errata, because we get more junk than not. That also leads to some broader
discussion that ties into the revamp of the RFC Editor systems because we
actually get duplicate errata every once in a while because nobody is looking
at a version of an RFC that has errata applied, so people find the same things
over and over and over again sometimes years apart and that's an indicator that
our errata display isn't working. We need a better way to do this so they're
going to try and look into it. That's all I had at the top of my mind.