Skip to main content

Narrative Minutes interim-2022-iesg-23 2022-10-20 14:00
narrative-minutes-interim-2022-iesg-23-202210201400-00

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

narrative-minutes-interim-2022-iesg-23-202210201400-00
INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2022-10-20 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) /  Routing Area
Roman Danyliw (CERT/SEI) / Security Area
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
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

REGRETS
---------------------------------
Jenny Bui (AMS) / IETF Secretariat
Jay Daley / IETF Executive Director
Francesca Palombini (Ericsson) / Applications and Real-Time Area

OBSERVERS
---------------------------------
Daniel Migault
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?

Éric V: Can we do my drafts at the beginning? I may need to leave for the last
hour. Thank you.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes from the October 6 telechat
being approved? I'm hearing no objection. We also have final narrative minutes
from October 6; any objection to approving those? I'm hearing no objection. We
also have the BOF coordination call minutes for IETF 115; any objection to
approving those as well? Okay, I'm hearing no objection.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

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

Roman: I'd like to close this item without action. I looked at the registry; in
the 2.5 years we've had it open we have not added any additional entries beyond
the import we get from W3C and we already have 2 well qualified DEs. I don't
think we need to add a third.

Amy: So for specifically this RFC, you want to keep the two people there? IANA
did ask for names to add.

Roman: Maybe I'm misunderstanding. The ask was that we used to have three, one
of the individuals retired, and proposed another candidate to replace them. I
looked at it and I think we have two solid ones, there is no volume on this
registry, and there has never been anything beyond the initial registration.

Amy: I see. Okay, we will communicate that back to IANA. Thank you.

     o Paul Wouters to find designated experts for RFC 9200 (ACE-OAuth)
       [IANA #1239251].
     o Paul Wouters to find designated experts for RFC 9203 (The (OSCORE)
       Profile of the (ACE) Framework) [IANA #1239258].
     o Paul Wouters to find designated experts for RFC 9237 (An
       Authorization Information Format (AIF) for Authentication and
       Authorization for Constrained Environments (ACE))[IANA #1239259]].

Paul: Still in progress on these.

     o Lars Eggert and Colin Perkins to find designated experts for RFC
       8609 (Content-Centric Networking (CCNx) Messages in TLV Format)
       [IANA #1239154].

Lars: We talked about this but we mostly talked about whether ICN should become
a standards group. The chairs are thinking it shouldn't be done. But we haven't
really discussed the experts, so let me pick that back up.

     o Robert Wilton, Alvaro Retana, and Warren Kumari to report back to
       the IESG on the impact of COVID-19 to the IETF in October 2022.
       - On hold until next week

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-homenet-front-end-naming-delegation-18  - IETF stream
   Simple Provisioning of Public Names for Residential Networks
   (Proposed Standard)
   Token: Éric Vyncke

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

Éric V: First, as some of you may have noticed, Daniel is on the call as an
observer. He's the main author on these two documents. He has a couple of
revisions based on the reviews and thanks so much for the very very detailed
reviews. I did my own AD review with a couple of comments.  afaik by looking at
the revised id, most discussion regarding the security aspect and the use of
TLS has been at least addressed somehow. He has also removed the complicated
section about dynamic DNS, because there was no point comparing the two.
Hopefully the clarity has been improved. My major concern is your abstain,
Lars. I understand your point. It's maybe a bit too late. It would not be the
first time we do such protocol work.

Lars: But we typically wouldn't do it as Proposed Standard. I'd be fine with it
as Informational or something, but PS seems like we really think this is a
solution, which I don't think it is. Specifically, removing a section doesn't
really help me. I'm not against it but I'm also not for it. The section made it
pretty clear that some of these assumptions have changed. There seems to be
this baked in assumption that the gateway is somehow trusted and the gateway is
the thing that's in the control. I don't trust my gateway, I probably trust my
phone more, because it's in my hand and I can actively do something with it.
Why should I trust this gateway? I think there are a lot of things here that
have changed. Aside from that part, most of the Discusses spelled out how you
can't really implement this because it's a smorgasbord of stuff. I really think
the time for this solution has come and gone and everybody has moved on.
Everyone here is using Dyn DNS. for historical record, sure we can publish this
as informational no problem, but as Proposed Standard I don't see it. Probably
for the other documents too, because they all tie in to the same architecture,
gateway being the thing that is your proxy.

Éric V: That's clear for the other Homenet documents. The Homenet WG has been
kind of a failure, to be direct, on this one. I'm pretty sure Daniel will work
and address all the other Discusses and comments, and then we will come back
and check your abstain, Lars. You may have followers on this.

Lars: I don't think you can address the Abstain other than not making it a
Proposed Standard. And that's fine, abstain is not a block and it doesn't
prevent it from being published. This is not a technical thing I can point to
to change the protocol and make it clearer, it's this meta argument that times
have changed and this solution isn't it anymore.

Éric V: I agree. I meant to address the point of your Abstain and it will be
the remaining issue once the others are fixed by Daniel. Then we will see if
anyone else adopts your position and if we need to do anything about the
publication status.

Paul: To chime in a little bit, I honestly don't understand how some of this is
supposed to work because all of the non-standard IETF protocol stuff is really
not specified. I was mostly confused that it says DNS updates and having hidden
primaries don't really work, the solution is deploying that anyway, but calling
them differently.  in the end it's still the same solution, hidden primary,
primary, secondary. I'm a little confused by the thought of this not being
deployable and then also being the solution. For Me, the DNS updates are
secured using various RFC standards we have, and TLS is not one of them because
TLS has only transport security, not data authenticity security. So I felt
those were kind of mixed up and I don't understand how this solution works from
start to finish. Not sure if we should do this on this all, maybe Daniel we can
talk at 115 and you can explain it to me. Hopefully it's just the language that
I don't understand.

Warren: I'll chime in here as well. I will happily note I was unable to figure
out how the whole system is supposed to actually work. I was having a
sufficiently difficult time reading and parsing it that I couldn't get the
bigger picture in my head of how the bits tie together and which bits do what.
Most of my reviews were just that I don't understand how to read this and I
don't have the bigger picture in my head. My comments were only up to page 13;
I have a PDF with more scribbles in it and I don't know if that would be useful
to send or not. I did not transfer all the notes.

Éric V: I'm pretty sure Daniel would be happy to receive your PDF with your
notes, if they're readable. And maybe if nobody objects, I would love to give
the floor to Danielt o make a couple of statements about your plan; not for too
long, please.

Daniel Migault: Hi everyone. Some of the comments are saying it's not
implementable. I have a hard time understanding that and I'm happy to clarify
that. Then the debate on whether this is going to happen or not, if we don't
publish it, it will for sure never happen, but I think we should have the
discussion on the technical basis as opposed to speculation on what is
possible. Paul, yes, I can clarify many of those things.

Éric V: I think the best way to move forward, Daniel, is to try to address all
the Discusses and comments in a revised ID and then we can talk in London. Will
you be there?

Daniel: No, I won't be there in person. I think I already addressed most of the
comments I received so far. Maybe I didn't respond to Paul, I'll have to check.
My intention is to respond today to all of the comments and I think I've done
most of them.

Lars: What's your view on moving this to informational?

Daniel: My point is that if we want to deploy it at Ericsson, we will need to
have it as standards track.

Paul: Can we start as experimental? Isn't that how this is supposed to start?

Daniel: No. Anytime we want to deploy something in a product, it has to be
standard. That's the only reason I want it to be a standard. If Ericsson wasn't
interested at all, I'd say fine.

Éric V: I think we can close the discussion here. Obviously this will be
Revised ID Needed.

 o draft-ietf-homenet-naming-architecture-dhc-options-21  - IETF stream
   DHCPv6 Options for Home Network Naming Authority (Proposed Standard)
   Token: Éric Vyncke

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

Éric V: I don't think so, unless somebody wants to. It's connected to the first
document so we can't really talk about this one if the first is not approved.
Zahed, on your point about the non-default port, I had the same point during my
AD review but the WG says it will be the default port.

Lars: This is not for the WG to decide. If an operator decides to deploy this
on a non-standard port, it can't work with this. Right?

Zahed: There is no enforcement and no text in the document saying it has to be
this way.

Lars: Unless there is an agreement between the two parties.

Zahed: This has to be resolved some way. You can say this is only designed to
work on the standard port, but this might be different if somebody else wants
to do it on some other port.

Lars: There's no such thing as a standard port. There's a default assigned port
but each deployment can pull ports out of a hat and if you want your thing to
work you have to handle that.

Éric V: That was my point in the AD review as well. Maybe they will change it.
So Revised ID Needed and thank you for your review on this as well.

Amy: This will go into Revised ID Needed, thank you.

 o draft-ietf-ipsecme-mib-iptfs-09  - IETF stream
   Definitions of Managed Objects for IP Traffic Flow Security
   (Proposed Standard)
   Token: Roman Danyliw

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

Zahed: I can talk about my Discuss. I'm on the verge of clearing it but I had
communicated with the authors about something similar to Lars's. I don't know
about Lars but it looks good to me and I think with that in place I can remove
my Discuss and Lars can decide if he wants to.

Lars: They recognize it's a cap so they want to change that text, which seems
fine.

Zahed: The new text would be clearer about the cap and the condition control.

Lars: If it's a congestion controlled mode, it's up to that particular limit,
and if it's a non congestion controlled mode, it is that limit.

Zahed: Yes.

Roman: Having found the mute button, the thing is, the authors have this in
hand and the discussion is happening. The key thing to remember is that there
is the protocol document which actually says what knobs you have, the Yang and
the MIB should not reinvent what the knobs are and what the protocol document
says, and whatever's in the Yang text should be the same as the MIB text.
That's where we're headed. Thank you for the find.

Zahed: If you want me to clear the Discuss now, I can do it.

Lars: I will wait until there is a new document so there is no change today
anyway.

Roman: This will be Revised ID Needed.

 o draft-ietf-pce-vn-association-09  - IETF stream
   Path Computation Element Communication Protocol (PCEP) extensions
   for establishing relationships between sets of Label Switched Paths
   and Virtual Networks (Proposed Standard)
   Token: John Scudder

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

John: Thank you everybody. AD Followup, please.

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

 o draft-ietf-opsawg-yang-vpn-service-pm-13  - IETF stream
   A YANG Model for Network and VPN Service Performance Monitoring
   (Proposed Standard)
   Token: Robert Wilton

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

Rob: Thank you everyone for the reviews and comments. This is in good shape but
a Revised ID is needed to pick up the comments.

Amy: This will be Approved, Announcement to be Sent, Revised ID Needed.

 o draft-ietf-pce-lsp-extended-flags-07  - IETF stream
   Label Switched Path (LSP) Object Flag Extension for Stateful PCE
   (Proposed Standard)
   Token: John Scudder

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

John: Not as far as I'm concerned, it seems like it's moving along. Lars, do
you want to talk about it?

Lars: It's pretty straightforward.

John: Okay. The substate would be Revised ID Needed.

 o draft-ietf-dnsop-dnssec-bcp-05  - IETF stream
   DNS Security Extensions (DNSSEC) (Best Current Practice)
   Token: Warren Kumari

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

Warren: I don't think so.

Lars: I would like to, if you don't mind. I'm sorry for breaking the Discuss
record on this call. I don't see why this is a BCP. Basically they say DNSSEC
is a good idea, here's the document. This is not what a BCP is for. It's
written as if it's on the standards track which it isn't.

Warren: Much of the original intent was so that there is a single way to refer
to the whole set of things, and it is also supposed to be so that a lot of
people are not implementing DNSSEC. When you say why aren't you doing this,
they say it's not a standard or a thing the IETF has said is best practice.
Maybe it's not very well worded, but the intent was to make it so that we think
DNSSEC is a BCP.

Lars: I think the people who say that don't understand what a BCP is. First
off, for these rollnet documents, we have that document and it says here are
the gazillion other documents you need to read, and that was informational. If
DNSSEC wanted to make it something more, it is a proposed standard now, let's
make it a standard. But it can't be a BCP because protocols aren't BCPs. We
could have a BCP document that says here are all of the reasons and operational
stuff why DNSSEC should be used to secure the DNS system, that might be a BCP.
But this is not that document, this is basically a roadmap.

Paul: Does it say it's mandatory to implement?

Warren: Mandatory for whom to implement?

Roman: Yeah. We would need some clarity on who's accepting that MTI?

Paul: Anything that is a DNS software library, resolver, server? Just to
clarify that DNSSEC is not optional. Just like we clarified that TCP for DNS is
not optional.

Warren: I do understand what you're saying, but there was a fair bit of
discussion in the WG about we want DNSSEC to be a best current practice and I
think the thought was that this would be accomplishing that. That seemed to
make sense to me, at least at the time. I guess we need to have more discussion
with the authors and WG.

Roman: Correct me if I'm wrong, I thought the intent of this was to strongly
signal that DNSSEC is a really really good idea. I did not think we were
signaling a followup statement to that as then it is MTI to implement it if you
have a DNS stack and if you are operating DNS you must turn this on.

Warren: There are some people who believe that is what we should say, but I
don't think that's what this is. What this is really trying to say is that we
believe it is a best current practice, it's what people should be doing, and I
think we'd thought that by bundling the things together and saying this is what
DNSSEC is, this set of things, and marking this document as a best current
practice that says it's best current practice to use DNSSEC.

Lars: I have nothing against having a BCP that says DNSSEC is a good idea and
you should use it. But the text here talks about DNSSEC the protocol and it
becoming a BCP, and that is not something we do. Maybe it just needs to be
rephrased. It does it in several places, which is why I couldn't just overlook
it. We don't have a document that says QUIC is a BCP, or DNS itself is a BCP.

Warren: Do you think we could address your concern by wording it more as moving
DNSSEC to best current practice status?

Lars: I'd talk about using DNSSEC to secure the DNS, that is the best current
practice. It needs to give community deliberations. The community thinks that
using DNSSEC to secure DNS is the best current practice for DNS deployment.
That would be a fine statement. But DNSSEC as the protocol bits, moving them to
best current practice status, I think it's just badly written.

Warren: Okay. So do you think that it's salvageable in this document to replace
all of that? Once we make sure the WG does agree, change it to [what you said],
or does it need a whole new document?

Lars: I don't think it needs a whole new document. If they made that wording
change consistently and look at it with that sort of perspective to see if any
other rephrasing would be useful, I think that would be fine.

Warren: Now that you word it that way, I understand and that all makes sense.
Thank you. Revised ID Needed.

Murray: I was just looking at 2026 while that discussion was going on and the
definition of BCP seems to include the case we're talking about, at least the
way it's written. I agree though that you kind of have to turn your head
sideways to see how this fits. As this draft is written. But it seems like
there's probably a path to make this fit so I think I agree this just needs to
be revised. There was some language in here that made me think this is trying
to change the status of DNSSEC without actually changing the status of DNSSEC
and that's what felt improper about it. I didn't put a Discuss on it but I'm
going to change my position to support Lars's while we figure this out.

Warren: Okay.

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

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-dots-telemetry-use-cases-14  - IETF stream
   Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry
   (Informational)
   Token: Paul Wouters

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

Paul: I haven't had time to read the comments yet and I'm not sure if it will
need a revision. Let's put it in AD Followup.

 o draft-ietf-rmcat-rtp-cc-feedback-11  - IETF stream
   Sending RTP Control Protocol (RTCP) Feedback for Congestion Control
   in Interactive Multimedia Conferences (Informational)
   Token: Zaheduzzaman Sarker

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

Zahed: Thanks for the reviews. I think we have the critical one, whether some
of the references should be normative. We have talked about it with the authors
so it felt like these were all informative but there's a thin line here. This
is informational anyway. I see Colin might have ideas. I suspect there might be
a Revised ID. Lets' see what Colin says but let's put it in Revised ID Needed
or AD Followup.

Amy: This can be Approved, Announcement to be Sent, Revised ID Needed until
you're satisfied with it.

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-smyshlyaev-tls13-gost-suites-00
   IETF conflict review for draft-smyshlyaev-tls13-gost-suites
     draft-smyshlyaev-tls13-gost-suites-08
     GOST Cipher Suites for Transport Layer Security (TLS) Protocol
   Version 1.3 (ISE: Informational)
   Token: Paul Wouters

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

Paul: I had one small related question. The document does say recommended no
for the cipher in the column that has TLS WG recommending that cipher or not.
Technically, I guess, this is not going to the TLS WG. Someone could change
that recommendation to yes, right, and then we would have to stop that from
happening. Is that something we could stop with a note? How would that happen?
How can I pass this saying 'yes but only if you keep recommended = no.'

Lars: You say no if it isn't that.

Paul: You mean when it comes back to IESG review? After the conflict review…

Lars: Oh, you mean if they change it afterwards? We would need to hope that the
ISE would question that change. Auth48 also happens, where we have to trust
that the RFC Editor would catch that change.

Alvaro: If I understand you correctly, that entry right now is something we
would require the TLS WG to agree on? One of the responses is that this
document conflicts with IETF stuff because it requires a WG to look at it, or
something along those lines. You could force it that way. But theoretically, if
you make the comment and they change it, Eliot should be on top of not letting
them change it. The stronger hammer is to just stop the document because it
goes against IETF policy.

Roman: Wouldn't the designated experts also catch that during the IANA procesS?

Paul: Yes, but can we stop it if it's the ISE?

Warren: We can advise them it's a bad idea, but they can do whatever they want.
The only thing we can do is if an ISE document wants to make a reservation in a
registry we can tell them they can't have one. But the I in ISE stands for
independent.

John: You asked what the designated expert can do if ISE publishes, and it
depends on what's in the guidelines to the designated expert. If they have
reasonable guidance, they can look at this document and say sorry, no.

Paul: Okay, thanks. I was mostly just curious about the process.

Amy: So I have that this conflict review is approved with the note that's
currently in the tracker and we can send that back to the ISE.

 o conflict-review-irtf-cfrg-vrf-00
   IETF conflict review for draft-irtf-cfrg-vrf
     draft-irtf-cfrg-vrf-15
     Verifiable Random Functions (VRFs) (IRTF: Informational)
   Token: Roman Danyliw

Amy: I have no Discusses for this conflict review, so unless there's an
objection now it looks like this is ready to go back to the IRSG. This will go
into Approved, Announcement to be Sent.

3.4.2 Returning items

 NONE

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

 o Application-aware Networking (apn)

Amy: I have quite a few blocks here.

Andrew: I've looked at the blocks. I think version 1 of the charter solved some
blocks but introduced a lot of others. I would have said this needs a BOF at
this point, but at the same time, looking at the blocks and the responses on
the mailing list, I think there is zero hope of getting through a BOF at this
point. After I discussed this with John and Alvaro at our AD meeting, what
we're going to do for now is say this isn't going to happen and return the time
slot, and after 115 I'm going to work with these guys to set up a bof at 116.
IF I look at the responses from the list on the charter, we got responses from
the proponents to address some of the concerns, but I didn't see any other
support on the list for modifying the charter, which makes me nervous. I'm
going to call this for 115, say it moves to 116, and I will work with them to
set up for a BOF then. I don't think we can proceed without a BOF at this
point. Comments, thoughts?

John: We already discussed this, but it seems reasonable to me.

Zahed: Sounds like a plan.

Roman: Sounds good. I don't think we can move ahead with what we have, and you
have a plan for making changes, so we'll see what that yields.

Andrew: What do we do about the time slot on the agenda?

Amy: Send in a support ticket and Liz will take care of it. It'll be marked
canceled on the agenda.

Warren: If it's canceled, maybe you and the proponents can get together in that
room or somewhere else to discuss the concerns.

Andrew: Yes, I think I can say something like that to the proponents. I just
need to confirm that once we cancel the meeting, that room will be available
and won't be allocated to something else.

Amy: It is likely to be allocated if the room is needed. You can always sign up
for a side meeting room or use the IESG office, as that's what that is there
for.

Warren: That's probably better.

Andrew: I'll set up a chat with them. Thanks very much for all of the comments.

4.1.2 Proposed for approval

 NONE

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 NONE

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Warren: I don't know of any news this week, I missed the meeting because I was
at NANOG. Maybe Lars or Mirja could speak, maybe about the MTEN workshop?

Mirja: There was no meeting because of the workshop. The workshop was quite
smooth and we had some good discussion. There is no concrete outcome but
everyone got a better understanding of the problem and hopefully we can reflect
this in a report at the end.

6. Management issues

6.1 Policy Regarding IANA Registry Tombstone Entries (Murray Kucherawy)

Murray: This is Tim McSweeney again. He would basically like to cancel
everything he's ever done at the IETF, so he's trying to de-register even his
provisional URI scheme. He can do that if he wants, but the designated expert
for that registry would like to install a tombstone entry showing the IESG as a
change controller. Tim objects, saying that's his name and he can do what he
wants with it, including leave it blank. My position and that of the designated
expert is that once you remove the entry, there's no entry there and we can do
what we want, and the right thing to do is to put the tombstone in because
otherwise someone comes along later and says they want drop, now you have a
collision even though the provisional one was only ever private use. IANA is
asking us to make that official, basically.

Warren: An option might be instead could a new registration be made which
assigns drop to the IESG or something, and then the IESG changes it and puts in
a tombstone? OR would that be weird? I'm not sure if what I said made sense.

Murray: Not quite. Can you go over it again?

Warren: Currently, if there was a registration, and it was to someone, and that
person doesn't want the registration anymore, could the registration be made to
a different entity and then that entity says let's return it and put the
tombstone in?

Murray: Why would it not be us, though?

Warren: It would be us, I mean a different entity to who originally registered
it.

Murray: I guess the question is, is it reasonable for him to be able to say he
doesn't want anything there including the tombstone? I think he gave up change
control when he deleted everything. The name is now available again and IANA or
the IESG can choose to put an entry there if they want to.

Warren: If only the change controller can put the entry in, maybe the change
controller can become the IESG and then we can immediately put in a tombstone.

Murray: You mean make that a regular practice? Sure.

Alvaro: Two things. In a previous IESG there was some effort to make everything
with the IESG as a change controller. That's just a side note. I don't think we
should make a decision on this registry. This is a designated expert managed
registry. The decision we should make is that the designated expert is the one
in charge of making the decision, whatever that is. In this case we happen to
agree with the designated expert. In some future case we may not agree with
them, but our decision back to IANA should be yes, the DE can make the decision
because it's a DE managed registry. If someone doesn't like that decision, IANA
or Tim or someone else, they can go through normal channels and appeal. For
nowe we should just say that whatever the DE decides is the right thing to do.

Lars: The IESG does have overriding power, so the IESG always has the ability
to put stuff in registries. But in this case I agree, the expert has made a
decision, and I'm happy for us to minute that we approve the decision of the
expert, but the submitter needs to accept that IANA is managing the registries
by a set of policies and those policies are not leading to an outcome they
would prefer.

Alvaro: A slight nit to what you said, I don't think we need to approve the
decision of the expert, we just need to affirm that the expert can make the
decision.

Lars: We can phrase it that way, yes.

Martin: So to be clear, Tim's name and email and all that will not be present
in the tombstone?

Murray: Correct, the tombstone would just say there was an entry here, it's no
longer here, the name is retired.

Martin: I can imagine another person saying look, I'm retired, don't send me
email about this registry or what have you. But that's not the case here. I say
do the right thing.

Murray: In that situation you just described, where someone doesn't want to
deal with it anymore, we'd just make the change controller to the IESG. We have
a way forward there too.

Martin: I think what you're proposing is fine.

Murray: Anyone else? If not, I will go back to Sabrina and say that our
position is that the DE in each case gets to decide and we're fine with that.

Sabrina: Sounds good, thank you.

Lars: If IANA thinks the DE is wrong, they should still raise it with the IESG
obviously, but if the DE otherwise makes a decision that IANA thinks is a fine
decision based on policies given, that's fine.

6.2 Registration for Side Meetings (Secretariat)

Amy: We had a question from a regular IETF participant about who can attend the
side meetings onsite and whether they are open to the public or whether they
are, like any other meeting with the IETF, you have to [be registered for the
meeting].

Martin: I think what Lars proposed, which is basically that they have to go
through the fee waiver process, is fine. I think it's generally fine to give
people an opportunity to participate in these little things without making a
big deal out of it, but I can see avenues to take advantage of that.

Warren: I have a very closely related one I think is worth mentioning so they
can be discussed together. The IEPG meeting is on the Sunday before the meeting
starts. Since it was founded it's always been that you don't need an IETF badge
or registration to attend but pretty much everyone always has had one. I don't
know whether that's worth discussing at the same time. The thing that makes it
interesting other than the historical aspect is that it meets before the IETF
starts.

Alvaro: We've made statements before that the IETF starts on the Saturday, so
technically that meeting happens during the IETF week. I think these meetings
should be open to anyone who wants to come in. Many of them are about new
ideas, attracting people who live nearby, and I think they should be open and
free to everyone. But if we're going to make a policy, it should apply to
everyone, including the IEPG.

Éric V: The same with the ANRW, right, which is also outside the IETF?

Mirja: I think everyone who participates in a meeting should register. That
doesn't apply to closed meetings. We also provide rooms for people who want to
have side meetings and they pay for the room and organize a side meeting.
That's not our business. If we pay for the room, everyone should have a badge.
That doesn't mean they have to pay for it, since we have the fee waiver. We
should welcome people to use the fee waiver for this purpose. We have
registration for the ANRW, and the Hackathon, companions, etc. We could have a
separate registration but I think people can just use a fee waiver and register
normally.

Warren: For IEPG in particular, Tim wanted to be able to bring some of his
students along from university in London. Having them get a fee waiver if
they're just going to show up for two hours of IEPG meeting seems like it would
be not quite wasting fee waivers, but using them for a different purpose.

Lars: It actually doesn't. The stats show that we have participation we're not
even currently tracking. Fee waivers for day passes are no problem. I'd rather
people get those. I do want to say that I'm all for having a consistent
approach and I recognize that IEPG has been around for so long that nobody
remembers. I think it would be good to have this policy. If people want to have
a meeting where they control the attendance and they get a room they pay for,
they can also meet in the bar or the restaurant, but if they want to meet in
part of the venue contracted space, I think it's fair to require that people
who attend are registered for the IETF and not charged extra for it. I think
somebody tried to have a meeting like that.

Roman: To me, there is some cachet in being listed as an official side meeting.
The most important thing to me is whether the Note Well applies. If we want to
do a solid for some other organization, whether it's by money or just inter
organizational relationship, I'm fine with giving them the side meeting rooms,
but then in the agenda it's not a side meeting and the time is blocked. If you
want the official standing of a side meeting, then the Note Well applies and
then we can argue about whether you need to register. The key thing is the Note
Well which depends if we give them a side meeting room or some other room.

Éric V: On the other hand, if the Note Well applies, so do all our other
policies, like the Covid policy. Mask wearing.

Mirja: I think the Note Well applies no matter if people are registered or not,
but we have to make them aware of it. The people who organize the meeting
should make everyone aware. In Warren's case, if they are a student, they can
get a fee waiver on the IRTF track as well. If people have an official
registration they might stay for more sessions or more days and become a
participant, so that's an advantage.

Warren: The RFC which created the IEPG says that meetings shall be made openly
available.

Mirja: Open doesn't mean you don't have to register.

Warren: That's true, but I think there's a difference between having to
register and getting a fee waiver, which implies there is a fee that is being
waived, which makes it not free anymore.

Mirja: Open also doesn't mean free. IETF meetings are open, but not free.

Lars: The fee waiver is not a heavyweight thing. I get a code from the
Secretariat and I just give people the code to register with. If we tell the
Secretariat to look for "IEPG" in the fee waiver note I might not even see it
and they can just do it internally.

Warren: Because the IEPG has always been viewed as not really an activity of
the IETF, it does seem weird that the stats should be mixed in. If there was a
separate fee waiver we can track it in a separate bucket.

Lars: I get what you're saying, but you can't be part of the IETF and not part
of the IETF at the same time. You continuously co locate and the vast majority
of your people come from the IETF community, you are part of the IETF
community. You might not want to be part of it, but for all intents and
purposes you are.

Mirja: I have no problem having a separate IEPG registration but that is just
making it even more formal. Nobody will check the badges anyway.

Rob: Question for Lars, if someone turns up quite late to this meeting and is
told they have to register then and there, will that work or is that an issue?

Lars: They can get a day pass at the registration desk. If the Secretariat is
told that people coming to the IEPG should get a fee waiver if they don't want
to pay, that can be handled then and there.

Rob: I'm happy to make a consistent policy on this. Roman made the point that
there are some meetings that don't fit into this and don't put them on the side
meeting wiki. Where would you put them, then?

Roman: We don't put them anywhere, they're not our meetings. I'm making the
case for the meetings that aren't ours. If we do a solid for someone and give
them a room, we're not running the meeting or advertising it so they should
handle that.

Rob: The example might be one from the UK government, the DCMS or whoever. I
don't know if they've asked for fee waivers.

Lars: They have.

Rob: So they're happy and they will get fee waivers. Maybe that's fine for
these meetings and if the IESG is arranging a meeting they can give a code.

Lars: They have asked for a fee waiver not for the side meeting, but because
they want to stick around for the day and go to the IETF. That's where the fee
waiver came in. It wasn't because of that DCMS meeting.

Rob: Is the DCMS meeting listed on the wiki?

Amy: Yes it is.

Lars: I thought the ISOC one was but this wasn't.

Amy: DCMS is the ISOC one.

Lars: Oh, okay. Sorry, I'm confused.

Rob: That's the consistency I'm trying to get to. If they're listed on the
wiki, does that mean they therefore have to have fee waivers?

Roman: The point I was trying to make is that that meeting we just talked about
is not an IETF meeting, it's not on the wiki.

Lars: But they are listed on the wiki. It's non-IETF people that want to have
an open meeting in one of the side meeting rooms during the IETF week. They
would exactly fall under this policy.

Alvaro: So if they're on the wiki, they have to register, but if they're not on
the wiki, they don't have to register.

Mirja: I think ISOC is aware that the Note Well applies and everything, and
they wanted it that way.

Warren: I wonder if the people attending know what the Note Well is.

Mirja: I explicitly mentioned that to ISOC and I hope they also provide this to
the government people.

Éric V: In the same vein, you've seen the side meeting organized by ETSI, right?

Mirja: The IPE one? I'm not sure if it's organized by ETSI.

Éric V: I got another request to have a side meeting on Saturday for something
on Yang. Is it possible to have a meeting room on Saturday?

Lars: I don't think we have the meeting rooms available on Saturday. They would
need to meet somewhere else. They can sit in the hackathon, but it's not really
going to be a meeting room. Why Saturday?

Éric V: My understanding is that they are an operator group having meetings
Thursday and Friday, so they will stay Saturday and meet with IETF people. I
want to get more information from them. The chance they will stay for the IETF
week is pretty much zero, I think.

Amy: So what I'm hearing is that public side meetings are public in that
they're open to any IETF participant.

Éric V: Registration required.

Roman: That's what I heard.

Amy: I will take that back to the participant who questioned and update the
wiki.

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

Amy: Remember that our next formal telechat is next Thursday in preparation for
IETF 115.

6.3 Executive Session (Lars)