MADINAS@IETF118  
note taker: Jen Linkova  
***Presentation #1***: *MAC address randomization, Carlos J. Bernardos* 

**\*\*Bob Hinden:**\*\* Section 6, description for IPv6 is wrong: the
text is unclear that EUI-64 is not recommended method. Shall be fixed
before the IETF LC.  
**\*\*CB**\*\* Thanks, we will fix that.

***Presentation #2:\*\* Randomized and Changing MAC Address Use Cases
and Requirements, Jerome Henry (remote)*  
\*\*Carlos Bernardos:** REQ3 might need to be rephrased (smth like
"different solution")  
**Juan-Carlos Zuniga:** the doc has been stable, next steps? Not sure if
BCP is needed - maybe just recommendations, it might change Section 7
(move to Annex?)  
**Tianji Jiang:** REQ2: Tethered devices: there is a MAC for UA, and
MACs for tethered devices (one per device). What to do when a new
tetehred device connects to the UA (phone) - re-authenticate?  
**Yui Lee:** Clarification for the previous quetion. The phone is just a
router?   
**Tianji Jiang:** in 5G there is smth like L2 bridging. So when another
tethered device appears - it will be a new MAC visible to the network. A
comment will be sent to the list to clarify the issue and the potential
text changes.

***Presentation #3:** Liaison from WBA and OpenRoaming update (the
chairs)*  
(the statement was read by the chairs)

***Presentation #4\*\* Hackathon: OpenRoaming update, Mark Grayson
(remote)*  
\*\*Joe Clarke** (on behalf of the NOC): hash, unless the user explictly
agreeed to the terms, what NOC saw - a pop-up window "agree or
otherwise" - instead of the proper agreement explaining options. Also,
you can reach out to NOC.  
**Juan-Carlos:** 3 different levels of actions we can take: 1) RADIUS
recommendations 2)how is it going to be used? Types of deployments?
3)agreement to share personal data  
**Alan DeKok:** initially: you username is your public identifier. But
it's not always the case. Then: we want a UI which is public but not
tied to the user, so CUI was added. Then an opaque token - which is
useless for everyone except. The ID is supposed to be opaque/meaningless
for everyone else.  
**Bart Brinckman:** WRT sharing ID's from IDP to ANP: WBA OpenRoaming
workgroup originally thought that many ANP would require real id (email)
in order to offer service, but over time it has become clear this is not
a requirement in the majority of use cases, the default is definitely
anonimised.   
**JC**: There are useful findings, which shall be documented. What would
be the preferred way of documenting?   
**Eric Vyncke, as AD**: we shall keep our findings but we can not do it
here (based on the charter). What abouyt RADEXT?  
**Alan DeKok:** RADEXT charter: there is an item in the charter for
roaming. But MAC-related things - no. Not the network access. Half of
this can be done there (privacy etc). Something can be done in WBA. The
rest (LAN/MAC) - somewhere else.  
**Eric Vyncke**: User-ID thing - is a kind of business, or maybe there
might be something said in RADEXT. Actual work needs to be moved to
RADEXT or somewhere else.  
**JC**: THis WG can document our findings, and actual work will be done
elsewhere.  
**Alan:** RADEXT is working on a deprecating draft that can be used as
home for this.  
**Karri Huhtanen:** MAC randomisation belongs here. User identify -
RADEXT.  
**JC:** in presenation - inconclusive results mentioned in the
presentation, so there is room for more tests/work (like is same CUI is
provided to different networks).  
Carlos: Another hackathon? Or offline work? Let's talk on the list.  
Mark: Maybe hackathon is not the best place. Maybe better in more
controlled envinronment.   
**Jan-Frederik Rieckers** it's not just users who shall agree on sharing
IDs. Maybe some network provides do not care about IDs - they just want
to have data to give to government if ask. Others might care about real
IDs. Some migth do not want to store personal data, they prefer to have
a random ID.

***Presentation #5:** Next Steps (The Chairs)*

**JC** Let's discuss on the list. The technology is adopted by various
provides already. How can we help to do it properly.  
**Bob Hinden** I have a bad news - maybe there is no more work to do in
this WG. The last talk has nothing to do with the charter. We are done. 

**Eric Vyncke** +1 to Bob. It's the WG decision: recharter or... Let's
publish what's in the pipeline and move something to RADEXT. If we want
more work - we'd need to recharter. If nobody wants to work on BCP - we
can just close (ADs LOVE closing WGs) ;)  
**JC** The important thing is make sure the info we discovered is not
lost.  
**Eric** The WG created Sep 2021 - effective, fast for IETF to get so
much work done.

***Presentation #6:\*\* Other topics: Mobile Subscription Info in DHCP
and Router Advertisement*, Yiu Lee  
\*\*Eric** (Introducing the talk): There are people with roaming
experience in this room - they might be the right audience for this
talk.

**Bob Hinden** not sure I understand what's proposed. MY phone connents
to both mobile and WiFi and works seamlessly. I have privacy concerns (I
do not want mobile operators to know I connected to this network).
What's the problem to solve

**Lorenzo Colitti** What's "service continuity"?  
**Yiu Lee**. QoS - the same on all networks.  
**Lorenzo Colitti** The term is confusing. I assumed "the same prefix"
but looks like you mean something else  
**Yiu Lee** Same type of service at mobile and, let's home network.   
**Tianji Jiang:** \[missed the comment\] There are cases when it's
valuable. When you share the same core network but different access
netyworks (home/5G).  
**Lorenzo Colitti** There are other ways of doing it \[missed examples\]

**Bart** It's 3GPP problem to solve and they have a solution already.  
**Yiu Lee** all we want is to signal smth to the device/communicate, pls
point us to the right place.