@Michael: I do understand your point of view, and what you are saying for static addresses is true if your environment is safe. In many environment, devices are mobile and used across environments where Privacy considerations are very important. Having a standardized solution (that you may support or not in your device) could be a very useful tool. On the infrastructure side, I think that the same way you propagate the information for 1 MAC address across the infrastructure, you can propagate 2 or more...
", "time": "2022-07-28T20:18:25Z"}, {"author": "\u00c9ric Vyncke", "text": "@MCR: RFC 5415 could possibly be used to transport this layer-2 among AP
", "time": "2022-07-28T20:19:22Z"}, {"author": "\u00c9ric Vyncke", "text": "FYI: the MOPS WG also uses github to keep 'live data' once RFC is published
", "time": "2022-07-28T20:21:02Z"}, {"author": "Jabber", "text": "mcr: Yes, exactly, CAPWAP needs to be extended to deal with the changes.
", "time": "2022-07-28T20:21:12Z"}, {"author": "Jabber", "text": "mcr: Massimiliano, if you carry a device around, then it should generate a new stable MAC address for each environment. Not change it every 12 hours.
", "time": "2022-07-28T20:22:01Z"}, {"author": "Jabber", "text": "mcr: In environments like this hotel, the MAC address filtering is mostly not done at the AP. It's done centrally.
", "time": "2022-07-28T20:22:50Z"}, {"author": "Massimiliano Pala", "text": "@MCR: Mmm... difficult answer here :D I would say that even using an individual identifier for \"environment\", (a) it might be difficult to distinguish among \"environments\" besides a network id, and, most importantly, (b) you might want to protect tracking users across your infrastructure. Given these two factors, it might make sense to consider transferring a secret after associating (a seed, a value, etc.) that is not known to \"external\" attackers and allows the infrastructure, but not an observer, to link sessions. Believe me, I think I understand where your objections come from ... but I think that having such a protection can be quite important (and force us to be better at privacy with the next gen of wireless protocols... ?)
", "time": "2022-07-28T20:32:50Z"}, {"author": "Jabber", "text": "mcr: @Massimiliano, yes. One really simple way is to use WPA-Enterprise (EAP-TLS1.3) with certificates. But that's not how home networks work today. It's where we need to go.
", "time": "2022-07-28T20:39:54Z"}, {"author": "Jabber", "text": "mcr: (curious if that showed up in blue)
", "time": "2022-07-28T20:40:04Z"}, {"author": "\u00c9ric Vyncke", "text": "in black
", "time": "2022-07-28T20:43:03Z"}, {"author": "Jabber", "text": "mcr: I copied Massimiliano's name, and it was in blue, and the rest of the content was blue for me.
", "time": "2022-07-28T20:50:00Z"}, {"author": "Sri Gundavelli", "text": "Relation to MADINAS can be about the RCM.. since they are maintaining the MAC to IP relationship
", "time": "2022-07-28T20:56:22Z"}, {"author": "\u00c9ric Vyncke", "text": "Sure but not to the point of becoming a MADINAS WG document IMHO
", "time": "2022-07-28T20:57:03Z"}, {"author": "Yiu Lee", "text": "Please post the link of the draft into the mailing list. Thx!
", "time": "2022-07-28T20:57:05Z"}, {"author": "Sri Gundavelli", "text": "Agree!
", "time": "2022-07-28T20:59:03Z"}, {"author": "\u00c9ric Vyncke", "text": "Thanks to the chairs and participants
", "time": "2022-07-28T20:59:06Z"}, {"author": "Sri Gundavelli", "text": "Just the RCM aspect
", "time": "2022-07-28T20:59:08Z"}]