Subject: [Madinas] MADINAS Charter after BoF @IETF111

From: Juan Carlos Zuniga <[email-masked]>
Date: Thu, 29 Jul 2021 13:27:49 -0400

Hi all,

Thank you very much for your participation at the MADINAS BoF meeting
yesterday!

Below is a new version of the charter addressing the comments that were
received during the meeting.

Please let us know if there are any other suggestions, and/or if you
support this version.

Best,

Juan-Carlos & Carlos

(MADINAS co-Chairs)

--------------------------------

MAC Address Device Identification for Network and Application Services
(MADINAS) Charter

The Medium Access Control (MAC) address is the Link Layer address used in
IEEE 802 technologies. It was originally assigned statically for each
physical network card by the Network Interface Card manufacturer, out of
the space reserved by the IEEE Registration Authority Committee (RAC) for
globally unique MAC addresses. The MAC address is used as source or
destination target when sending and receiving frames. The default static
assignment of the MAC address raises privacy concerns for personal devices,
which have recently started to be mitigated by end-device vendors
implementing and SDOs specifying the use of Randomized and Changing MAC
addresses (RCM).

Device identity is important in scenarios where the network needs to know
the device or user identity in order to offer, operate and maintain certain
services. Currently, many use cases and applications make an implicit
assumption about the unique association between the device identity and its
MAC address. This assumption is being used in both control plane and data
plane functions and protocols. RCM breaks this assumption. This requires
updating applications to function across MAC address changes.

The MADINAS Working Group will examine the effect of RCM schemes on network
and application services in several scenarios identified as relevant. The
group will also evaluate various identifiers (i.e., beyond the MAC address)
that can be used by the network to provide services, as well as scenarios
where personal device identity is not required.

For scenarios where personal device identity stability is desirable, the
Working Group will recommend protocols that can be used to protect the
request and exchange of identifiers between the client and the service
provider. For scenarios where privacy is paramount, the group will
recommend best practices to ensure that the privacy achieved with RCM is
not compromised by the communication of other identifiers. The MADINAS
Working Group will examine other IETF work that may be applicable.

The Working Group will work together with other IETF WGs (e.g., DHC,
IntArea), and will liaise with other relevant SDOs such as IEEE 802 and the
Wireless Broadband Alliance (WBA). The Working Group will coordinate on the
different recommendations, as well as potential follow-up activities within
or outside the IETF.

MADINAS is expected to be a short timeframe (12-18 months) Working Group to
quickly assess these needs. Additional solution space documents would only
be published if identified as necessary, requiring a rechartering process
in coordination with other relevant SDOs.

The group will produce the following deliverables:

1. Document Current State of Affairs:

An Informational Use Cases and Requirements document (e.g.
draft-henry-madinas-framework)

An Informational MAC Address Randomization current state-of-affairs
document (e.g. draft-zuniga-mac-address-randomization)

2. Document Best Practices handling RCM

A Best Common Practices document

---

From: "Jerome Henry (jerhenry)" <[email-masked]>
Date: Thu, 29 Jul 2021 18:57:14 +0000

Thank you, Juan Carlos and Carlos, for organizing this BoF.

I support the new version of the charter, I believe that it answers the comments that were received.

Best

Jerome

From: Madinas <[email-masked]> on behalf of Juan Carlos Zuniga <j.c.zuniga=[email-masked]>
Date: Thursday, July 29, 2021 at 1:28 PM
To: "[email-masked]" <[email-masked]>
Cc: Carlos Jesús Bernardos Cano <[email-masked]>, Juan Carlos Zuniga <[email-masked]>
Subject: [Madinas] MADINAS Charter after BoF @IETF111

Hi all,

Thank you very much for your participation at the MADINAS BoF meeting yesterday!

Below is a new version of the charter addressing the comments that were received during the meeting.

Please let us know if there are any other suggestions, and/or if you support this version.

Best,

Juan-Carlos & Carlos
(MADINAS co-Chairs)

--------------------------------
MAC Address Device Identification for Network and Application Services (MADINAS) Charter

The Medium Access Control (MAC) address is the Link Layer address used in IEEE 802 technologies. It was originally assigned statically for each physical network card by the Network Interface Card manufacturer, out of the space reserved by the IEEE Registration Authority Committee (RAC) for globally unique MAC addresses. The MAC address is used as source or destination target when sending and receiving frames. The default static assignment of the MAC address raises privacy concerns for personal devices, which have recently started to be mitigated by end-device vendors implementing and SDOs specifying the use of Randomized and Changing MAC addresses (RCM).

Device identity is important in scenarios where the network needs to know the device or user identity in order to offer, operate and maintain certain services. Currently, many use cases and applications make an implicit assumption about the unique association between the device identity and its MAC address. This assumption is being used in both control plane and data plane functions and protocols. RCM breaks this assumption. This requires updating applications to function across MAC address changes.

The MADINAS Working Group will examine the effect of RCM schemes on network and application services in several scenarios identified as relevant. The group will also evaluate various identifiers (i.e., beyond the MAC address) that can be used by the network to provide services, as well as scenarios where personal device identity is not required.

For scenarios where personal device identity stability is desirable, the Working Group will recommend protocols that can be used to protect the request and exchange of identifiers between the client and the service provider. For scenarios where privacy is paramount, the group will recommend best practices to ensure that the privacy achieved with RCM is not compromised by the communication of other identifiers. The MADINAS Working Group will examine other IETF work that may be applicable.

The Working Group will work together with other IETF WGs (e.g., DHC, IntArea), and will liaise with other relevant SDOs such as IEEE 802 and the Wireless Broadband Alliance (WBA). The Working Group will coordinate on the different recommendations, as well as potential follow-up activities within or outside the IETF.

MADINAS is expected to be a short timeframe (12-18 months) Working Group to quickly assess these needs. Additional solution space documents would only be published if identified as necessary, requiring a rechartering process in coordination with other relevant SDOs.
The group will produce the following deliverables:

1. Document Current State of Affairs:
An Informational Use Cases and Requirements document (e.g. draft-henry-madinas-framework)
An Informational MAC Address Randomization current state-of-affairs document (e.g. draft-zuniga-mac-address-randomization)

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 29 Jul 2021 19:04:18 +0000

I also support the new charters.

Thanks,
Yiu

Date: Thursday, July 29, 2021 at 13:27

Hi all,

Best,

Juan-Carlos & Carlos
(MADINAS co-Chairs)

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 29 Jul 2021 19:24:10 +0000

Same here.

Regards,

Pascal

Le 29 juil. 2021 à 20:58, Jerome Henry (jerhenry) <jerhenry=[email-masked]> a écrit :

Best

Jerome

Hi all,

Best,

Juan-Carlos & Carlos
(MADINAS co-Chairs)

--
Madinas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/madinas

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 29 Jul 2021 14:41:41 -0500

Hi JC,

My comment is the name of the WG to be formed should include or be derived
from:
Randomized and Changing MAC addresses

we missed this in the MADINAS  BOF process but maybe not too late for the
WG.

Behcet

On Thu, Jul 29, 2021 at 12:28 PM Juan Carlos Zuniga <j.c.zuniga=
[email-masked]> wrote:

> The MADINAS Working Group will examine the effect of RCM schemes on
> network and application services in several scenarios identified as
> relevant. The group will also evaluate various identifiers (i.e., beyond
> the MAC address) that can be used by the network to provide services, as
> well as scenarios where personal device identity is not required.
>
> MADINAS is expected to be a short timeframe (12-18 months) Working Group
> to quickly assess these needs. Additional solution space documents would
> only be published if identified as necessary, requiring a rechartering
> process in coordination with other relevant SDOs.
>

---

From: Bob Hinden <[email-masked]>
Date: Thu, 29 Jul 2021 12:43:05 -0700

Juan-Carlos & Carlos,

I was one of the few who didn’t raise my hand regarding creating a Madinas w.g.  I wanted to explain why I did this.

I have two concerns.

The first is that I am not sure there is enough work for a w.g.   Seems to me that there will be one or two documents that describe what happens when MAC Address change, and some examples of equipment that breaks.   I asked, and the answer to my question was there aren’t going to be any solutions/protocols/etc. to provide an alternative to how some products have used static MAC addresses.   Using static MAC addresses as identifiers was, of course, aways a hack that was easy to work around by having the device change its MAC address.

The second, probably more important, is that Random MAC addresses are now shipping in volume, it’s not a future problem, it’s now.  See the picture of my Eero router list of devices showing it thinks my wife has a new Apple Watch.   She doesn’t, of course.

By the time the IETF produces some documents, product vendors will have solved the problem in a variety of ways.   None of them are going to wait for this w.g. complete its work.

Bob

> On Jul 29, 2021, at 10:27 AM, Juan Carlos Zuniga <j.c.zuniga=[email-masked]> wrote:
> 
> Hi all,
>

---

From: Tim Cappalli <[email-masked]>
Date: Thu, 29 Jul 2021 20:11:00 +0000

I also did not raise my hand and agree with everything that Bob said below.

Given existing standards already exist to solve all these network access uses cases, this topic should be covered by an industry whitepaper or deployment guide from an industry organization like WBA. I don't think a new IETF WG is appropriate.

The industry has taken the easy way out on these network identity topics for the last decade. Another WG will not change that.

Tim

From: Madinas <[email-masked]> on behalf of Bob Hinden <[email-masked]>
Date: Thursday, July 29, 2021 at 15:44
To: Juan Carlos Zuniga <[email-masked]>, Carlos Jesús Bernardos Cano <[email-masked]>
Cc: Bob Hinden <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [Madinas] MADINAS Charter after BoF @IETF111
Juan-Carlos & Carlos,

I have two concerns.

Bob

On Jul 29, 2021, at 10:27 AM, Juan Carlos Zuniga <j.c.zuniga=[email-masked]<mailto:j.c.zuniga=[email-masked]>> wrote:

Hi all,

Best,

Juan-Carlos & Carlos
(MADINAS co-Chairs)

--
Madinas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/madinas

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Thu, 29 Jul 2021 16:37:38 -0400

Hi Bob,

Thanks for detailing your concerns. My personal responses in-line:

On Thu, Jul 29, 2021 at 3:43 PM Bob Hinden <[email-masked]> wrote:

> The first is that I am not sure there is enough work for a w.g.   Seems to
> me that there will be one or two documents that describe what happens when
> MAC Address change, and some examples of equipment that breaks.
>

Indeed these could be some of the identified use cases. Some others could
be services beyond pieces of equipment that cannot be supported any longer

>   I asked, and the answer to my question was there aren’t going to be
> any solutions/protocols/etc. to provide an alternative to how some products
> have used static MAC addresses.   Using static MAC addresses as identifiers
> was, of course, aways a hack that was easy to work around by having the
> device change its MAC address.
>

In this case more than a hack it is a feature being implemented to reduce
privacy-related issues.

>
> The second, probably more important, is that Random MAC addresses are now
> shipping in volume, it’s not a future problem, it’s now.  See the picture
> of my Eero router list of devices showing it thinks my wife has a new Apple
> Watch.   She doesn’t, of course.
>

Indeed this is happening now and it is a good start. One issue though is
that MAC addresses are being randomized in different ways by different
vendors (see
https://datatracker.ietf.org/doc/html/draft-zuniga-mac-address-randomization-01#section-7).
Hence, one cannot guarantee that a specific solution will work across
multiple OSs, use cases, etc.

>
> By the time the IETF produces some documents, product vendors will have
> solved the problem in a variety of ways.   None of them are going to wait
> for this w.g. complete its work.
>

True. However, since each vendor (device, network infrastructure, etc.) is
solving the problem for their specific use case, no one can really
guarantee that a specific solution will work for other use cases and/or
other vendors.
At the IEEE, 802.11bh/bi will provide guidelines about how to handle the
MAC address randomization. We want the MADINAS WG to liaise with 802 to
understand where they are going, look at existing solutions (from IETF,
WFA, WBA, etc.), and make a gap analysis. If we find out that there is a
magic bullet, great! We just have to document it in a BCP so that multiple
vendors can look at it and implement it correctly. If on the other hand we
find a gap, we can then debate what is the best way to fill that gap and
where it should be done - either at the IETF or elsewhere.
The purpose of the charter is to let the WG write the first informational
documents, and be a focal point to discuss these issues with other relevant
WGs and SDOs.

Best,

Jc

>
> Bob
>
>
>
>
>
> On Jul 29, 2021, at 10:27 AM, Juan Carlos Zuniga <
> j.c.zuniga=[email-masked]> wrote:
>
> Hi all,
>
> implementing and SDOs specifying the use of Randomized and Changing
> MAC addresses (RCM).
>

---

From: "Peter Yee" <[email-masked]>
Date: Thu, 29 Jul 2021 14:00:08 -0700

While I agree with Tim that the industry has taken the easy way out on
network identity topics, I’m going to disagree that an IETF WG would be
inappropriate.

The WBA has indeed been voicing industry concerns about RCM. But they are
also asking for help from IEEE 802.11 and looking at areas that are not
within IEEE’s purview such as CAPPORT. (See the embedded PDFs in
https://mentor.ieee.org/802.11/dcn/21/11-21-0703-00-0000-2021-april-liaison-
from-wba.docx). IEEE 802.11 TGbh, as Jerome noted yesterday, is working on
IEEE 802’s response to the cited liaison statement. But there are definitely
items that the task group will not touch. The very much work-in-progress
issues tracking document (see
https://mentor.ieee.org/802.11/dcn/21/11-21-0332-12-00bh-issues-tracking.doc
x) lists some of the use cases that have been discussed, but it should be
made clear that IEEE 802.11bh will not provide solutions for every use case.
There are simply some that we consider out of scope for a layer 2-focused
task group. That’s where a short-lived, focused effort in the IETF might
make sense. Such a WG would also be a good entity for the (hopefully
short-lived) IEEE 802.11bh to liaise with as well. While some of us attend
both groups, the interaction is informal. 

                                -Peter Yee

From: Madinas <[email-masked]> On Behalf Of Tim Cappalli
Sent: Thursday, July 29, 2021 1:11 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Madinas] MADINAS Charter after BoF @IETF111

Given existing standards already exist to solve all these network access
uses cases, this topic should be covered by an industry whitepaper or
deployment guide from an industry organization like WBA. I don't think a new
IETF WG is appropriate. 

The industry has taken the easy way out on these network identity topics for
the last decade. Another WG will not change that.

Tim

From: Madinas <[email-masked] <mailto:[email-masked]> >
on behalf of Bob Hinden <[email-masked] <mailto:[email-masked]>
Date: Thursday, July 29, 2021 at 15:44
To: Juan Carlos Zuniga <[email-masked]
<mailto:[email-masked]> >, Carlos Jesús Bernardos Cano
<[email-masked] <mailto:[email-masked]> >
Cc: Bob Hinden <[email-masked] <mailto:[email-masked]> >,
[email-masked] <mailto:[email-masked]>  <[email-masked]
<mailto:[email-masked]> >
Subject: Re: [Madinas] MADINAS Charter after BoF @IETF111

Juan-Carlos & Carlos,

I was one of the few who didn’t raise my hand regarding creating a Madinas
w.g.  I wanted to explain why I did this.

I have two concerns.

The first is that I am not sure there is enough work for a w.g.   Seems to
me that there will be one or two documents that describe what happens when
MAC Address change, and some examples of equipment that breaks.   I asked,
and the answer to my question was there aren’t going to be any
solutions/protocols/etc. to provide an alternative to how some products have
used static MAC addresses.   Using static MAC addresses as identifiers was,
of course, aways a hack that was easy to work around by having the device
change its MAC address.

The second, probably more important, is that Random MAC addresses are now
shipping in volume, it’s not a future problem, it’s now.  See the picture of
my Eero router list of devices showing it thinks my wife has a new Apple
Watch.   She doesn’t, of course.   

Bob

 

On Jul 29, 2021, at 10:27 AM, Juan Carlos Zuniga
<j.c.zuniga=[email-masked]
<mailto:j.c.zuniga=[email-masked]> > wrote:

Hi all,

 
Please let us know if there are any other suggestions, and/or if you support
this version.
 
Best,
 
Juan-Carlos & Carlos
(MADINAS co-Chairs)

The Medium Access Control (MAC) address is the Link Layer address used in
IEEE 802 technologies. It was originally assigned statically for each
physical network card by the Network Interface Card manufacturer, out of the
space reserved by the IEEE Registration Authority Committee (RAC) for
globally unique MAC addresses. The MAC address is used as source or
destination target when sending and receiving frames. The default static
assignment of the MAC address raises privacy concerns for personal devices,
which have recently started to be mitigated by end-device vendors
implementing and SDOs specifying the use of Randomized and Changing MAC
addresses (RCM).

For scenarios where personal device identity stability is desirable, the
Working Group will recommend protocols that can be used to protect the
request and exchange of identifiers between the client and the service
provider. For scenarios where privacy is paramount, the group will recommend
best practices to ensure that the privacy achieved with RCM is not
compromised by the communication of other identifiers. The MADINAS Working
Group will examine other IETF work that may be applicable.

MADINAS is expected to be a short timeframe (12-18 months) Working Group to
quickly assess these needs. Additional solution space documents would only
be published if identified as necessary, requiring a rechartering process in
coordination with other relevant SDOs.

1. Document Current State of Affairs:
An Informational Use Cases and Requirements document (e.g.
draft-henry-madinas-framework)
An Informational MAC Address Randomization current state-of-affairs document
(e.g. draft-zuniga-mac-address-randomization)

-- 
Madinas mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/madinas

---

From: Alan DeKok <[email-masked]>
Date: Thu, 29 Jul 2021 18:04:22 -0400

On Jul 29, 2021, at 5:00 PM, Peter Yee <[email-masked]> wrote:
> 
> While I agree with Tim that the industry has taken the easy way out on network identity topics,

  I would describe it as "fragmented".  The standards organizations are doing their own thing for network identity topics.  There are overlapping solutions, and insufficient coordination.

> I’m going to disagree that an IETF WG would be inappropriate.

  Someone has to do it.  And the IETF is the only organization which is open, and free to join.  As such, it's the best place to create a solution.  And/or recommendations for other organizations.

  Alan DeKok.

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 30 Jul 2021 01:04:38 +0000

I echo JC. The current RCM implementations are OS vendor driven for good. This is a wakeup call to the industry. We should no longer see mac as a reliable identifier. Unfortunately, many apps today are using mac for identity. Instead of each app inventing a way to solve it, I think it is beneficial to have IETF working closely with IEEE, WBA and BBF to analyze the problem domain and make recommendations. In the end, we want to provide the best experience and safest technology to end users including ourselves.

As IEEE standardizes RCM, I expect the vendor community will adopt the IEEE standard. So it is also important for IETF to work closely with the community together to define a future-proof framework that cover most common use cases that could be impacted by RCM.

Best,
Yiu

From: Madinas <[email-masked]> on behalf of Juan Carlos Zuniga <j.c.zuniga=[email-masked]>
Date: Thursday, July 29, 2021 at 16:37
To: Bob Hinden <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Carlos Jesús Bernardos Cano <[email-masked]>, Juan Carlos Zuniga <[email-masked]>
Subject: Re: [Madinas] MADINAS Charter after BoF @IETF111

Hi Bob,

On Thu, Jul 29, 2021 at 3:43 PM Bob Hinden <[email-masked]<mailto:[email-masked]>> wrote:
Juan-Carlos & Carlos,

I have two concerns.

The first is that I am not sure there is enough work for a w.g.   Seems to me that there will be one or two documents that describe what happens when MAC Address change, and some examples of equipment that breaks.

Indeed these could be some of the identified use cases. Some others could be services beyond pieces of equipment that cannot be supported any longer

  I asked, and the answer to my question was there aren’t going to be any solutions/protocols/etc. to provide an alternative to how some products have used static MAC addresses.   Using static MAC addresses as identifiers was, of course, aways a hack that was easy to work around by having the device change its MAC address.

In this case more than a hack it is a feature being implemented to reduce privacy-related issues.

Indeed this is happening now and it is a good start. One issue though is that MAC addresses are being randomized in different ways by different vendors (see https://datatracker.ietf.org/doc/html/draft-zuniga-mac-address-randomization-01#section-7<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-zuniga-mac-address-randomization-01*section-7__;Iw!!CQl3mcHX2A!XtHWOeZ7IkqI0KBiOA1llB9SYJZKd8swAzAESS5WEHbKSEtAHwmkWC17yOrJb28$>). Hence, one cannot guarantee that a specific solution will work across multiple OSs, use cases, etc.

True. However, since each vendor (device, network infrastructure, etc.) is solving the problem for their specific use case, no one can really guarantee that a specific solution will work for other use cases and/or other vendors.
At the IEEE, 802.11bh/bi will provide guidelines about how to handle the MAC address randomization. We want the MADINAS WG to liaise with 802 to understand where they are going, look at existing solutions (from IETF, WFA, WBA, etc.), and make a gap analysis. If we find out that there is a magic bullet, great! We just have to document it in a BCP so that multiple vendors can look at it and implement it correctly. If on the other hand we find a gap, we can then debate what is the best way to fill that gap and where it should be done - either at the IETF or elsewhere.
The purpose of the charter is to let the WG write the first informational documents, and be a focal point to discuss these issues with other relevant WGs and SDOs.

Best,

Jc

Bob

Hi all,

Best,

Juan-Carlos & Carlos
(MADINAS co-Chairs)

--
Madinas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/madinas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/madinas__;!!CQl3mcHX2A!XtHWOeZ7IkqI0KBiOA1llB9SYJZKd8swAzAESS5WEHbKSEtAHwmkWC17X5b2yGE$>

--
Madinas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/madinas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/madinas__;!!CQl3mcHX2A!XtHWOeZ7IkqI0KBiOA1llB9SYJZKd8swAzAESS5WEHbKSEtAHwmkWC17X5b2yGE$>

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Fri, 30 Jul 2021 01:41:41 +0000

Hi Behcet,

I personally think that the charter description and the deliverables are more important than the name of the WG. Also, the MADINAS name is already been recognised beyond IETF. However, if the IESG decides to change the name for other reasons I would not object.

Best,

Jc

________________________________
From: Behcet Sarikaya <[email-masked]>
Sent: Thursday, July 29, 2021 15:41
To: Juan Carlos Zuniga
Cc: [email-masked]; Carlos Jesús Bernardos Cano; Juan Carlos Zuniga
Subject: Re: [Madinas] MADINAS Charter after BoF @IETF111

Hi JC,

My comment is the name of the WG to be formed should include or be derived from:
Randomized and Changing MAC addresses

we missed this in the MADINAS  BOF process but maybe not too late for the WG.

Behcet

On Thu, Jul 29, 2021 at 12:28 PM Juan Carlos Zuniga <j.c.zuniga=[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Best,

Juan-Carlos & Carlos
(MADINAS co-Chairs)

--
Madinas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/madinas<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmadinas&data=04%7C01%7Cjuancarlos.zuniga%40sigfox.com%7C552ee5af1df2434586f108d952c8ead6%7Cfcbc8bb1061e4b949f703ad917b0c8d3%7C0%7C0%7C637631845150669450%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CMT9vr7XqgyPU3WSN8FtL%2FMo9LWbuSzaTH0jE0i8xUw%3D&reserved=0>

Your privacy is important to us. Please see our Privacy Notice<https://www.sigfox.com/en/privacy-and-cookies-policy> for further details. The information contained in this Message is confidential. If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this Message in error, please delete it and all copies from your system and notify the sender immediately by return message. Any use of information contained in this Message not in accordance with its intended purpose, any dissemination or disclosure (either whole or partial), is prohibited unless expressly authorized. Email communication cannot be guaranteed to be timely secure, error or virus-free. The sender cannot be held responsible for any alteration, errors or omissions, which arise as a result.

..................................................................................................................

La protection de vos données personnelles est primordiale pour notre établissement. Merci de consulter notre notice sur la protection des données personnelles <https://www.sigfox.com/en/privacy-and-cookies-policy> pour plus d'informations. Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires. Les informations qui y figurent sont confidentielles. Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Veuillez également en avertir immédiatement l'expéditeur par retour du Message. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse. Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, soient sécurisées ou dénuées de toute erreur ou virus. L'expéditeur ne peut être tenu responsable des modifications, erreurs ou omissions qui pourraient en résulter.

---

From: Mathieu Cunche <[email-masked]>
Date: Fri, 30 Jul 2021 13:23:24 +0200

Hi Bob, all

On 29/07/2021 21:43, Bob Hinden wrote:
> By the time the IETF produces some documents, product vendors will 
> have solved the problem in a variety of ways.   None of them are going 
> to wait for this w.g. complete its work.

I agree that some vendors will not wait to develop their own 
solutions, but I don't think this invalidate the utility of this work.

Taking the example of address randomization in 802.11, a number of 
vendors did not waited for specifications. As underlined by numerous 
discovered issues, correct implementation is not straightforward and 
only a small number of vendors have been able to fix the majority of 
those issues (although some serious ones remain to be fixed). As of 
today, there are still a large number of more modest vendors who lack 
the expertise/resources required to build state-of-the-art and robust 
implementations and who could benefit clear specifications and guidelines.

This is why I believe the outcome of this group would still be 
beneficial even if some vendors did not waited the completion of this 
work.

Furthermore, I support the new version of the charter.

Regards,

Mathieu Cunche

---

From: "Jerome Henry (jerhenry)" <[email-masked]>
Date: Fri, 30 Jul 2021 12:43:55 +0000

I also concur. RCM (while connected) behavior has been observed since 2016. The approach between vendors is inconsistent and changing, and one of the major contributing factors is the feedback from their customers in various verticals. Some say “you should do more RCM as privacy is paramount”, others “your RCM is breaking this, but maybe we can find a workaround”, others “your RCM breaks everything and makes my network operations impossible”.

If the community does not do anything, then this deconstructed scenario will continue, with some vendors implementing one scheme, others another scheme etc. (because each focuses on the particulars of their primary verticals), and this might prevent unified network operations. I do not see a high risk in attempting to assess the situation and come up with possible gap lists or existing solutions/recommendations.

Thus I support the group formation.

Best,

Jerome

From: Madinas <[email-masked]> on behalf of "Lee, Yiu" <Yiu_Lee=[email-masked]>
Date: Thursday, July 29, 2021 at 9:05 PM
To: "[email-masked]" <[email-masked]>
Subject: Re: [Madinas] MADINAS Charter after BoF @IETF111

Best,
Yiu

Hi Bob,

I have two concerns.

Best,

Jc

Bob

Hi all,

Best,

Juan-Carlos & Carlos
(MADINAS co-Chairs)

---

From: Luther Smith <[email-masked]>
Date: Fri, 30 Jul 2021 14:16:53 +0000

To the point that vendor implementations different, history has shown that even within a single vendor RCM implementation has changed based on releases. Thus not only is the implementations vary across vendors but within single vendors.

I agree with the charter of the working group as common approach to RCM will only benefit the industry.

Cheers,
Luther

Luther E. Smith
Director Wireless Access Technologies/ Distinguished Technologist
CISSP

CableLabs®
858 Coal Creek Circle
Louisville, Colorado 80027-9750
303-661-3305  voice
303-661-9199  fax
303-931-1759 mobile
www.CableLabs.com<http://www.cablellabs.com/>

From: Madinas <[email-masked]> On Behalf Of Jerome Henry (jerhenry)
Sent: Friday, July 30, 2021 6:44 AM
To: Lee, Yiu <Yiu_Lee=[email-masked]>; [email-masked]
Subject: Re: [Madinas] MADINAS Charter after BoF @IETF111

Best,

Jerome

From: Madinas <[email-masked]<mailto:[email-masked]>> on behalf of "Lee, Yiu" <Yiu_Lee=[email-masked]<mailto:Yiu_Lee=[email-masked]>>
Date: Thursday, July 29, 2021 at 9:05 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Madinas] MADINAS Charter after BoF @IETF111

Best,
Yiu

From: Madinas <[email-masked]<mailto:[email-masked]>> on behalf of Juan Carlos Zuniga <j.c.zuniga=[email-masked]<mailto:j.c.zuniga=[email-masked]>>
Date: Thursday, July 29, 2021 at 16:37
To: Bob Hinden <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Carlos Jesús Bernardos Cano <[email-masked]<mailto:[email-masked]>>, Juan Carlos Zuniga <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Madinas] MADINAS Charter after BoF @IETF111

Hi Bob,

I have two concerns.

Best,

Jc

Bob

Hi all,

Best,

Juan-Carlos & Carlos
(MADINAS co-Chairs)

---

From: Michael Richardson <[email-masked]>
Date: Fri, 30 Jul 2021 19:38:44 -0400

Bob Hinden <[email-masked]> wrote:
    > I asked, and the answer to my question was there aren’t going to be any
    > solutions/protocols/etc. to provide an alternative to how some products
    > have used static MAC addresses.
    > Using static MAC addresses as identifiers was, of course, aways a hack
    > that was easy to work around by
    > having the device change its MAC address.

I agree with you Bob:  if we can't use a MAC address as the primary key in
the (management) database to attach attributes to, then what can we use?

This goes to basically device identification.

MAC randomization can only work if we move from non-device-specific
connections keys (WPA-PSK) to device-specific keys (certificates with WPA-Enterprise).

Within the current charter I see that we have some places where we can
recommend that some classes of devices do NOT randomize, or at least, do not
change unless the ESSID or WiFi AP ethernet changes.
(Access points themselves, for instance, shouldn't ever randomize)

    > The second, probably more important, is that Random MAC addresses are
    > now shipping in volume, it’s not a future problem, it’s now.  See the
    > picture of my Eero router list of devices showing it thinks my wife
    > has a new Apple Watch.   She doesn’t, of course.

Apple is shipping, but the majority of other smartphones are not yet shipping
something that changes even when not moving.
And IoT device vendors are not doing this ... and I hope many will never.
(Devices you wear on your person, ought to though)

    > solved the problem in a variety of ways.   None of them are going to
    > wait for this w.g. complete its work.

Agreed.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 31 Jul 2021 15:23:43 +0100

Hiya,

> (Access points themselves, for instance, shouldn't ever randomize)

Really? What about the one I can turn on on my phone?

S.