Narrative Minutes interim-2023-iesg-16 2023-07-13 14:00
narrative-minutes-interim-2023-iesg-16-202307131400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2023-07-13 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
Jenny Bui (AMS) / IETF Secretariat
Roman Danyliw (CERT/SEI) / Security Area
Dhruv Dhody (Huawei) / IAB Liaison
Martin Duke (Google) / Transport Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Jim Guichard (Futurewei Technologies) / Routing Area
Erik Kline (Aalyria Technologies) / Internet Area
Murray Kucherawy (Meta) / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Zaheduzzaman (Zahed) Sarker (Nokia) / 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

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
Lars Eggert (NetApp) / IETF Chair, General Area
Francesca Palombini (Ericsson) / Applications and Real-Time Area

OBSERVERS
---------------------------------
Karen O'Donoghue
Lee-Berkeley Shaw
Greg Wood
Juan Carlos Zuniga

1.2 Bash the agenda

Amy: Does anyone want to add anything new? Any other changes?

1.3 Approval of the minutes of past telechats

Amy: We generally give two weeks for this and it's only been a week since the
last telechat, so we'll give you some more time for review.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

     o Rob Wilton to find designated experts for RFC 9390 (Diameter Group
       Signaling) [IANA #1275381].

Rob: In progress.

     o Murray Kucherawy to find designated experts for RFC 9122 on IANA
       Registry for Sieve Actions IANA #1275603].

Murray: In progress.

     o Roman Danyliw to find designated experts for RFC 9393 on Concise
       Software Identification Tags [IANA #1275658].

Roman: In progress.

     o Warren Kumari to find designated experts for RFC 9432 DNS Catalog
       Zones [IANA #1276081].

Amy: This approval is on the agenda later as a management item.

   * OPEN ACTION ITEMS

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

Rob: The Secretariat has provided this data again. I'm wondering whether we
should look at this just before the meeting.

Warren: I think so.

Amy: Then let's look at adding this to the Sunday morning agenda. Do you want
to talk about it today or just Sunday?

Rob: Let's just do it Sunday.

     o Warren Kumari to follow up on a bis document for RFC 8126 regarding
       designated experts.

Warren: In progress.

     o Lars Eggert to send email to the LLC about Letters of Invitation
       for Interim Meetings and Retreats

     o Lars Eggert and Martin Duke to rewrite IESG statement to give more
       guidance about issuing LOIs for interim meetings.

     o One AD from each area to diagram their Area topology and send it to
       Martin Duke for collation.

Martin: In progress. The core of my proposal was to merge INT and TSV and I
have enough to do something, so I'll come up with a strawman. If anyone else
would like to join the party, please submit something soonish.

Warren: Is a spreadsheet fine or do you want it as a pretty picture?

Martin: A spreadsheet is fine.

     o Roman Danyliw to open a Datatracker issue suggesting a feature to
       better signal individual contributions

Roman: In progress.

     o Lars Eggert to ask the LLC to come up with a proposal on how we can
       support a pre-configured remote participation option in side
       meeting rooms.

     o Lars Eggert to write an update to the Support Documents in IETF
       Working Groups statement.

     o Murray Kucherawy to respond to the email "RFC 1952: Any plan for a
       new extra field registry."

Murray: In progress.

     o John Scudder to collect AD qualifications for NomCom.

John: We're making reasonable progress.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 NONE

2.1.2 Returning items

 o draft-ietf-acme-integrations-16  - IETF stream
   ACME Integrations for Device Certificate Enrollment (Proposed
   Standard)
   Token: Roman Danyliw

Amy: I have no Discusses, so unless there's an objection now, this document is
approved. I'm hearing no objections. I do have to point out that it has a
downref to a document that was replaced by another document.
Draft-ietf-uta-use-san was replaced by another document (RFC 6125bis) but it
still shows up as a normative reference here.

Roman: Okay, we'll need to clean that up. Can you please put that in AD
Followup so I can figure that out with the authors?

Amy: That will be Approved, Announcement to be Sent, AD Followup.

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-ntp-chronos-20  - IETF stream
   A Secure Selection and Filtering Mechanism for the Network Time
   Protocol with Khronos (Informational)
   Token: Erik Kline

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

Erik K: I see the author has been responding to comments; do we need to discuss
this?

Paul: One of the big questions is who should use this protocol. The security
considerations knock out a lot of things that aren't appropriate. They throw a
lot of the security considerations out, saying if you have these problems don't
use this. In his email response to me, the use case was reduced to looking at
the health of NTP pools which is odd. As far as I know there's only one big
pool we know about, pool.ntp.org. Basically this document says how can you
check that the pool is healthy or which servers in the pool are malicious? If
that's what this document is doing, why does it need an RFC? People shouldn't
implement this, only a few researchers interested in the pool should run this.
I have questions whether this should be published.

Erik K: Sounds to me like there might be a misunderstanding in the threat model
it's trying to address. There are two pools; one is the pool your NTP is
syncing, and the other is the pool that's being used as this cross checking
pool. The threat model is not somebody who has total control over your link,
it's not someone attacking you in a coffee shop, it's someone who is attempting
to take over fractional control of time servers that you happen to be talking
to.

Paul: And it's also not data centers. Who is left?

Erik K: Clients can run this. You can run this in a coffee shop yourself, but
it's not against someone attacking you owning your entire link.

Paul: The authors have ruled coffee shops out of focus, because if you control
the upstream router you can do so many bad things that this doesn't matter
anymore.

Warren: I'd like to use this for my own systems at home. I have a couple of NTP
servers at home I use over GPS. I wouldn't mind if every now and then they
check against pool.ntp.org, but I don't want to add it to my system. I fall
into the use case.

Erik K: It's about an attack attempting to take over the time servers, which
you might be talking to, and/or controlling the path between you and those time
servers. Not controlling your sole link. If you're running in the cloud, you're
talking to data centers, even there you could still cross check. As I
understand it, it's a strategy for cross checking, validating what your NTP
servers are talking to. The threat model it's attempting to address is people
aiming to take over NTP servers, or able to take over paths in front of those
servers.

Paul: I think the document needs to better clarify the scope and who should use
this. The second item I had was when you take the samples, and the samples are
deemed to be too far apart to be usable, they have a different strategy. That
strategy as far as I can read is to take new samples. I don't understand how if
you take new samples the problem would go away. I'm a little confused how this
works if the first set of sampling didn't work. You're inevitably going to have
a lot of samples you cannot use; what do you do?

John: That was clear to me.

Paul: In the pseudocode?

John: No, not in the pseudocode, in the prose. It seemed like their strategy
was threat model is that the attacker can't subvert a large proportion of the
servers if they've subverted a small proportion and if your randomness source
is good. The probability of randomly picking subverted servers three times in a
row is quite low. That's what I thought the story was.

Paul: I did not read that in the pseudocode. The story is a really long and
elaborate white paper, but not RFC implementation language.

John: It's not in the pseudocode. I thought it was in the surrounding
explanatory text. It's a natural consequence of their threat model.

Erik K: That was my understanding as well.

Paul: The pseudocode reads weird because it says if security issue is raised,
sample.

Erik K: It should re-select a random set of servers. But yeah, there are
recommendations to fix the pseudocode. Sample means gather samples from
randomly chosen servers, so resampling I assumed to include re-randomly
choosing.

Paul: The pseudocode doesn't say start from scratch, it just says take the
samples and don't do any checks on them anymore. I'll go reread it. My biggest
issue is that I would really like the use case of who should deploy this.

Erik K: It could have been easier to follow for sure. Thank you.

Roman: I don't know what the magic words are about NTP extension. A little of
my confusion was that NTP extensions would suggest the protocol is changing,
but this chronos thing seems like a superset of NTP. I would have benefited
from some upfront language walking me through what is NTP, what this is.

Erik K: It runs parallel to. It's validating and checking some things but it's
not actually doing stuff in your local time.

Roman: Maybe i didn't understand; i was under the impression that the
deployment model was you rip out a bunch of logic from your existing NTP client
implementation and you jam this additional reasoning because it directly
controls what NTP traffic gets put on the wire and how you reason about the
results because it's putting out additional NTP requests, doing DNS stuff,
changing how you reason bout the responses you get. Or maybe it's two separate
processes. It sounded like they're publishing an algorithm and then there is
additional protocol and operations language that's a little loose for me.

Erik K: There is a part of NTP where you try to find what they call truechimers
and falsetickers. That's in 5905. In theory you could replace that part with
this, but when they wrote the watchdog process, this is a separate thing.
Anything can make NTP queries. This watchdog process is just making queries and
making an assessment.

Roman: Oh, I didn't get that. I misunderstood. I was on the fence whether this
was an additional process in parallel, an additional process inline, or this is
in the client.

Erik K: As a strategy, it could be either. You could in theory replace the
truechimers and falsetickers validation process with this, but it can also run
separate and provide information. In the mode where it thinks it's under
attack, it can stop it from skewing your time.

Roman: what you're saying is a lot clearer, but I would have benefited from
some architectural framing and some talk about what tickles what when. It would
probably need language saying none of this is actually in scope because all
we're talking about is an algorithm and then non standard approaches for what
to do with it.

Paul: And should this run on my laptop, my iphone, my NTP server, my security
infrastructure…where should this run?

Erik K: Okay. I can circle back with the authors.

Amy: Okay, so it sounds like this will need a Revised I-D. This will stay in
IESG Evaluation.

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 NONE

3.2.2 Returning items

 NONE

3.3 Status changes
3.3.1 New items

 NONE

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 NONE

3.4.2 Returning items

 o conflict-review-urn-ddi-00
   IETF conflict review for draft-urn-ddi
     draft-urn-ddi-05
     A Uniform Resource Name (URN) Namespace for the Data
   Documentation Initiative (DDI) (ISE: Informational)
   Token: Roman Danyliw

Amy: I have no Discusses for this conflict review, so unless there's an
objection this can go back to the ISE with the writeup in the tracker. I'm
hearing no objection, so we'll send that.

3.4.3 For action

 o conflict-review-irtf-icnrg-icnping-00
   IETF conflict review for draft-irtf-icnrg-icnping
     draft-irtf-icnrg-icnping-09
     ICN Ping Protocol Specification (IRTF: Experimental)
   Token: Lars Eggert

Amy: This conflict review needs a reviewer. Any volunteers?

Éric V: Do you know how many pages it is?

Cindy: It's 20 pages.

Éric V: Put my name, since no one has volunteered and I don't have to read the
DNSSD draft since it's mine.

Amy: Thank you, Éric.

 o conflict-review-irtf-icnrg-icntraceroute-00
   IETF conflict review for draft-irtf-icnrg-icntraceroute
     draft-irtf-icnrg-icntraceroute-09
     ICN Traceroute Protocol Specification (IRTF: Experimental)
   Token: Lars Eggert

Amy: We have a second ICNRG document that needs a conflict reviewer, also 20
pages.

Roman: I'll take it.

Amy: Thank you, Roman.

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

 NONE

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

Mirja: There was no meeting yesterday. We uploaded the agenda for the IAB Open
session, there will be something on the new identity management program. We'll
also probably have an invited talk by somebody from Berkeley about Internet
fragmentation.

Roman: We're going to look at SAAG to showcase the identity program at 117 and
proponents are asking for a non-WG mailing list.

6. Management issues

6.1 Nominations for the IESG Appointed RSWG Co-Chair (Secretariat)

Amy: Reminder that nominations for RSWG co-chair are still open. The
nominations period closes on Friday the 20th and we also need a small interview
team for the chair candidates who accept nominations. We currently have four,
two self-nominated and two accepts, and two declines. The feedback period will
begin at 117 and you're going to want to do interviews concurrently. I don't
know whether you want to discuss some possible questions for the candidates.

John: I was about to suggest we put this as an agenda topic for the in person
meeting at 117 but maybe we need to have a committee before that.

Éric V: It might be short notice.

Cindy: When the IAB does stuff like this it's usually about three people who do
interviews; they try to get 3-5 people to volunteer knowing that you may not be
able to get everyone at every interview, but making sure you have at least a
couple at each one. We also have the questions from last year and we can give
you those to start with.

Roman: When do we have to decide?

Amy: I think it's the end of august. There's a four week feedback period that
will begin the 21st.

Rob: When is Lars back?

Amy: Monday.

Rob: I'm assuming he has the most experience with RSWG, and that he might want
to be involved.

Amy: August 18 is the deadline for sending feedback, the IESG finalizes the
decision by Thursday August 24, then August 31 you follow up with all
candidates and make the announcement.

Rob: In terms of the questions, is that just questions we need to ask them in
the interview, or do we send them in advance?

Cindy: Usually just what you ask in the meeting.

Roman: I was on the panel that chose the current slate when it was joint with
the IAB. We had 5-7 questions and we just round robined to ask them. We should
think about whether we need more specific or tailored questions this time.

Mirja: I roughly know what's going on there and I know Lars does too. I think
we should volunteer Lars for this. I'd volunteer myself but I'm on the IAB and
we have a separate process. Most of the discussion was around the XML format
and if it needs a new version, or update v3, and things are moving slowly. That
might resolve with the choice of a new chair.

Rob: The key question is if we try to get interviews during 117 or after.

Mirja: If you want to get Lars it will be impossible during the meeting.
Everyone is in one place but I don't see an urgent reason to have them during
the week.

Roman: I concur with that. Let's deal with it after the meeting.

John: I'm not completely opposed but I have a vacation in August so it might
not work logistically.

Mirja: It's really not a hard job but you just want at least three people on it
to get their impressions.

John: So we're putting Lars on it and put my name down too, sure.

Warren: If John's going to do it, I can do it too.

Rob: You can add me.

Zahed: I can do it.

Andrew: Me too.

Cindy: We usually have a Secretariat person taking notes who sends them out to
the iesg-only list so everyone can see the notes, if you want to do that.

Roman: We should not have any world where we don't do that. We can't be trusted
alone.

6.2 [IANA #1276081] Designated experts for RFC 9432 DNS Catalog Zones (Warren
Kumari)

Amy: Warren has identified three people as designated experts for this
registry. Any objection to approving these three? Hearing no objection, so
we'll send the official note to IANA.

6.3 [IANA #1272932] renewing early allocation for
draft-ietf-idr-wide-bgp-communities (IANA)

Amy: Andrew, where is this in your queue? This expires at the end of the month.

Andrew: No, this expired in 2019 long before I was around. This is kind of
important for two documents, both of which are in my queue and I'm having
discussions with the chairs. I'm okay with renewing this and don't see any
issues. They want to bring this back and it was there before; I do think this
will move ahead.

Amy: Okay, any objections to renewing this early allocation that lapsed? I'm
hearing no objections, so we'll send this official note to IANA.

Éric V: Out of curiosity, what is the code point space? Is it 8 bits or larger?

Andrew: I'd need to check. I can come back to you.

Éric V: Sure, just wondering.

Warren: This is also being used in the wild.

John: It's a path attribute so it's 1 bit.

Andrew: The discussion around this is about two documents and this is for a
container defined in one, with stuff under it. Alvaro wanted one document split
in a particular place, I suggested another, and we're having discussions. But
the container will stay no matter what.

6.4 Action Item Review: Mailing List Statistics (Rob Wilton and Warren Kumari)

Amy: This was on today's agenda but at the top of the call we decided to cover
this during IETF 117.

6.5 Open Roaming Experiment (Warren Kumari)

Warren: Juan Carlos is here, someone who has actual knowledge.

Éric V: Are there any questions that Juan Carlos can answer? I sent a reply to
the IESG about the four questions Roman asked.

Warren: I think Lars is going to need a recommendation from the IESG on what
should happen. I don't know if Lars's questions have been answered. I think
there are still a number of things in the document we'd been told we would get
answers to that we don't have yet. There are also a number of things in the
experiment we don't understand the answers to. I'm assuming the proponents have
set up open roaming so they know how to do it. I feel like we have that answer
and understand the technical complexity.

Juan Carlos: This was a prerequisite for running the experiment, to make sure
it wouldn't disrupt the network. We were allowed to test it at the end of
Yokohama; we tried it, it worked, and we were happy with that. Indeed to the
group this was a question up until the end of Yokohama.

Warren: Okay. Also for understanding the requirements of user devices, I
thought there was still going to be documentation provided on which is being
proposed. I thought Cisco was proposing using the Cisco open roaming app, so I
guess that's another thing we have the answer to.

Juan Carlos: Right. The app will be the one provided for whoever wants to join
the experiment. Having said that, we also know there are devices that have
already been provisioned with open roaming by different agreements that are
outside the scope of IETF. Some users may already have devices that are
preconfigured and could also participate in the experiment not necessarily
using the Cisco app.

Warren: It says the MAC address randomization was so users can't be easily
tracked when they move between networks. What open roaming does it provide a
unique chargeable user identity which then gets logged every time you connect
to the network. What we see here is that it doesn't preserve or enhance
privacy, instead it takes all of the work which MADINAS did to randomize MAC
addresses and negates that by saying here's the actual user identity and you
can now track the user as they connect and disconnect.

Juan Carlos: That's a good point and that's part of the questions we want to
answer. Our understanding is that identity is exchanged between the user and
the identity provider but it's obscured to the network provider. Unlike eduroam
where you see the credentials.

Warren: The access network can see the credentials, because I got these logs
from my radius server. The radsec proxy my network talks to on my network is
where these logs come from. I'm assuming you all have actually set up one of
these networks and collected the logs and looked at them, or maybe not.

Juan Carlos: INdeed. MADINAS hasn't done it but they are asking IETF to do it,
which is why we want to have an official unbiased way of looking at things with
multiple people providing comments and expert views. Let's say we have not done
it. There are of course implementations of open roaming out there in the wild,
commercial and not, but we in MADINAS haven't done it. In fact we were asked by
the WBA when you request identity is this part of the experiment, and they did.
We have not done it outside your private use and the one we want to do at the
IETF.

Warren: The other bit is to observe potential leakage of PII.

Juan Carlos: Privacy is a relative term. Privacy against whom? In this case we
are looking at it from the optic of the access network.

Warren: The access network sees the user who connects. At home I'm running the
access network and I uniquely see the user when they connect.

Éric V: In this case, this is the radius proxy that sees it. Not an access
point. Because you change the MAC address, right?

Warren: Okay. You are exposing it to the access network. But it says by saving
up the IETF network asn an IMP, we'll be able to observe potential leakage of
PII. There's been no discussion as far as I know on how exactly and where
exactly and who is supposed to be collecting this potential leakage of PII.
Unless there's a  set of discussions I didn't hear. How will we observe this;
is the NOC supposed to be collecting logs and if so, where and how? Was this
discusseD?

Juan Carlos: It was, though it's not documented there. That was part of the
discussion iht the NOC. They said we don't have to set up a separate SSID but
we do want to, so we can collect the logs and see exactly what's going on. What
we saw in Yokohama, from what I remember in the NOC, was that we saw a Samsung
phone connecting now; is it yours, is it yours, whose? We just see it's from
Samsung. At that level, we know what it is but not the user.

Warren: Observe potential leakage, it doesn't feel like there's enough detail
in this. The NOC will set up a radsec proxy and collect the set of logs and
scrub this information out but keep this information….I'd like more details
around it.

Juan Carlos: It's been discussed but not documented, that's a good idea.

Warren: I thought there was supposed to be a writeup for the users to
understand as well, what's being shared with whom, what the concerns are if any
about giving public IP addresses to non-IETF people. Also Jay and Lars had
questions on whether people can choose their identity provider and at least
from what I've seen on the US IRS app on Apple devices always sends it through
the Apple identity provider. If you're using a Cisco app it always sends it
through Apple.

Juan Carlos: There was an option to use Google as well.

Warren: hang on, that's the authenticator, not the identity provider. IF I sign
in with a Google identity it still gets authenticated through oauth, but every
time I connect it sends a counting response to my unique identity at
apple.openroaming.net. I don't think you can choose your identity provider.

Juan Carlos: I believe it's an API from Apple that's being used but the IDP is
Cisco on the Cisco app. I'd need to check that with the experts.

Roman: Could I ask a more basic experimental design question? In my brain of
constructing experiments that increasingly capture real live user data, there's
a set of questions I can answer in a closed network with an experiment very
much like what Warren did. Then I turtle out on scale because there are certain
questions I can't answer without live dynamic behavior or real user data, or I
want to confirm what I found on a synthetic or closed network against a real
one. A number of the questions I'm haering us talk about seem like things we
don't need the live IETF network for ;we could answer some of these questions
in a synthetic environment. Am I wrong here? What is it that we need live user
data for?

Juan Carlos: Scale is one thing. What we're hearing from Warren is fine. The
network setup is not that complicated. The fact that he was able to join the
federation was because there were some agreements. With PII you get into legal
things as well, not just the technical. It's not anyone who can set up an open
roaming network. There are exchanges between WPA and us, is this part of your
experiment and should we allow it? Okay, you can run an experiment. We wouldn't
let just anyone do it; we know Warren is part of the IESG and the NOC,
knowledgeable and a trustworthy person that won't reveal your identity if you
connect to his network. It's not anyone that can do this. We weren't suggesting
for someone to set it up and report the results, we were thinking the best way
to check this is to do it on the IETF and tell people exactly what it is. We
want to be transparent, run the results, and have lots of people participate.
We'll have WPA people at the MADINAS meeting to explain how it works. It's part
of the collaboration.

Roman: I'm still stuck because I don't understand. I'm imagining it's me, I
have seven cell phones, and I'm willing to reprovision them. The options are to
remember other wifi networks, provision with a carrier that's going to push
open roaming on me, and maybe I install the app. I have this infrastructure in
a Faraday tent and I'm going to have at it. It seems like I can answer a whole
lot of questions with just that configuration. I'm trying to understand what's
the question I want to answer beyond those I can answer by wiping phones on a
configuration with a self controlled infrastructure? That would be the leap to
say why we need the big live experiment.

Juan Carlos: Right now I don't know how many implementations there are, so
scale helps in finding out that none of these combinations will provide a PII.
I personally don't have the means to set up something like that. When we ran a
MAC address randomization we were able to see some different behaviors between
operating systems that we were not expecting, for instance. You can run the
network but the fact you're connecting to IDPs that belong to the WPA
Federation, it's another degree that not anyone can do. We need to have a
certain level of credibility or an institution like the IETF to run this. We
can probably ask an operator of a network to open it up and let us run an
experiment, but I'm not sure they would be willing.

Warren: A quick clarification. Anyone can become an open roaming participant,
right?

Juan Carlos: You mean like institutions?

Warren: I didn't really get special treatment other than the fact that they
expedited approving the certificate.

Juan Carlos: My understanding is that you did get special treatment to be
allowed. We did get pinged by the WPA about the request to ask if they should
agree to provide. Normally it's companies that apply.

Warren: For the Google one, which  is basically open roaming with a different
label, anybody can join. The only difference is which federation it is. Looking
at the open roaming terms and conditions, it largely says you can join.

Juan Carlos: There are people with IDPs and network providers. The Google one I
guess is just the networks, not the IDPs, right?

Warren: They make a big thing about becoming an open roaming access network
provider.

Juan Carlos: So the open roaming access and IDPs are open.

Éric V: By the way, regarding the PII, eduroam is doing the exact same thing
except for the back end. When you do eduroam, the radius server, we're seeing
the same thing, right?

Warren: With eduroam you're exposing the actual user's identity itself. Whereas
with this you see a made up user identity which I think stays the same, it's a
mapping of a hash of your identity.

Juan Carlos: That's one of the questions I have; is it the same? Is it a hash?

Warren: I put it in the document. It looks like Google and Apple generate these
differently. If I connect through an Android device it's one thing, and if I do
it from an Apple device it's a different format of unique identity. Either way,
it's a unique identity. It's even in the open roaming specification called
Chargeable User Identity Attribute. The IDP needs a way to identify the actual
user.

Juan Carlos: I don't know all the details but my understanding is that's part
of the agreement between the user and the IDP.

Warren: What's worrying is that you can share your email address with the
access network or not and that's an option in the app. Toggling it didn't seem
to change anything at all. That's a separate thing. Okay.

Éric V: So how do we proceed? As kind of the messenger between open roaming and
the IESG, do I send a mail to the IESG and everyone replies with a few words?
Yes, no, and why, and then it's up to Lars to make a consensus call?

Roman: That sounds like a great plan.

Éric V: Okay. I put in the chat as well the possibility to run this specific
SSID just during the MADINAS WG meeting? Maybe half an hour before and after?
Not to overload the NOC too much.

Juan Carlos:  That would be worse, no? If we ask the NOC to do that? I was
asked by the NOC to arrive the Wednesday before so we can set it up and test it
and then not touch it after the Friday before.

Warren: I've spent easily 120 hours on this. The NOC has spent time on it. The
actual turning it on or off, and Jay has already approved this; when we arrive
and start setting up the network we'd turn it on so we know we can. We'll turn
it on for a bit Tuesday or Wednesday when we set up the network to make sure it
works. We could technically flip it off and then flip it on just for the
MADINAS meeting and turn it off again. I'll point out though that it's still
the same privacy concerns and we still don't have the info for the users on
what the privacy implications are. Also i think there's still not nearly enough
detail on what information exactly are we expecting the NOC or someone to
collect and who does it get shared with, does it get anonymized, what happens
to the log at the end of it, etc. the experiment says the MADINAS WG will write
up something, but do these logs get shared with the MADINAS people?

Juan Carlos: Like what we did with the MAC address randomization, it was just
statistics. We wouldn't share the actual logs; we'd collect information, digest
it, and report. Having said that, I still have a little concern with turning it
on and off just for the meeting, so if that's the case we'd need to understand
exactly what we do. There was a demo in Yokohama where a local roaming network
was shown turning on and off. Here the purpose was not to turn it on and off,
we were telling people you could download the app and connect automatically to
this unknown SSID. If we turn it on and off only for the duration of the
meeting, and I still can't picture what would be the purpose of that, it
becomes a live demo during the meeting which is not quite what we were
envisioning. My suggestion would be to turn it on for the whole week and
explain during MADINAS what is happening. We could do one live demo but
otherwise let the experiment run the whole week so we can collect information.

Éric V: Okay. Any more questions fo rJuan Carlos or anything to add?

Warren: No. I'll just say from the NOC standpoint we're all ready and can flip
it on if the IESG or Lars or whoever says so. We have the technical ability to
flip it on. We still need more details for the NOC and more explanation for the
users.

Éric V: Thank you for bringing that up, Warren, and thank you for joining us,
Juan Carlos. I think we can move on.

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

No other business.