Re: [Madinas] About draft-ietf-madinas-use-cases-07 and a potential way forward

["Lee, Yiu" <[e-mail]>]

Hi Med,

The new version removed the requirements as suggested by the WG. We are working on the next version that will address Carlos and your comments. Stay tuned.

Thanks,
Yiu


From: Yiu L Lee <[e-mail]>
Date: Thursday, February 22, 2024 at 08:39
To: "[e-mail]" <[e-mail]>, CARLOS JESUS BERNARDOS CANO <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Madinas] About draft-ietf-madinas-use-cases-07 and a potential way forward

+1

From: Madinas <[e-mail]> on behalf of "[e-mail]" <[e-mail]>
Date: Thursday, February 22, 2024 at 08:33
To: CARLOS JESUS BERNARDOS CANO <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Madinas] About draft-ietf-madinas-use-cases-07 and a potential way forward

Hi Carlos, all,

I agree that the requirements should be removed but not for the same reasons as you :-)

Except, req#1 which can be moved to the use case,

  *   req#2 is actually implementation-specific. For example, one would design a solution that allows a device to coordinate the MAC@ migration with a service/CPE/ACP/etc. that enforces policies based on an OLD MAC@ and thus service continuity is ensured. Similarly, a device support a provision for a list of pre-generated MAC@ that can be communicated with an expiry timers, etc.
  *   req#3 is not a requirement for obvious reasons.

FWIW, some more comments/edits can be found at:

  *   pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-madinas-use-cases-07-rev%20Med.pdf<https://urldefense.com/v3/__https:/github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-madinas-use-cases-07-rev*20Med.pdf__;JQ!!CQl3mcHX2A!CC6NpE1fM269YHmDQy9Dse9vCCJGG32epxsMo6t2UH7sPcb1IRp98yckm0tRvInRAl9c2JTIFx5WK54aEqsY-EIYRNc$>
  *   doc: https://github.com/boucadair/IETF-Drafts-Reviews/edit/master/2024/draft-ietf-madinas-use-cases-07-rev%20Med.doc<https://urldefense.com/v3/__https:/github.com/boucadair/IETF-Drafts-Reviews/edit/master/2024/draft-ietf-madinas-use-cases-07-rev*20Med.doc__;JQ!!CQl3mcHX2A!CC6NpE1fM269YHmDQy9Dse9vCCJGG32epxsMo6t2UH7sPcb1IRp98yckm0tRvInRAl9c2JTIFx5WK54aEqsYWuHnnf0$>

Cheers,
Med

De : Madinas <[e-mail]> De la part de CARLOS JESUS BERNARDOS CANO
Envoyé : mardi 20 février 2024 01:03
À : [e-mail]
Objet : [Madinas] About draft-ietf-madinas-use-cases-07 and a potential way forward

Hi,

I've checked one more time draft-ietf-madinas-use-cases-07, and I'd like to make a proposal to move forward with the document.

I think the document is valuable, and therefore should be published (as the WG is chartered to do). My personal opinion is that we should remove the requirements section of the draft, making it less formal (I believe the WG will probably not recharter to do any protocol work, and therefore there is no need for "formal" requirements).

Additionally, since it also seems that the WG will not work on the BCP document that we were originally chartered to do, I think that we can bring back the text on existing solutions (802.1X, OpenRoaming, etc.) to an annex, and perhaps refer to the other WBA/OpenRoaming draft(s). I found this text quite informational.

I'd appreciate feedback from the WG, to help the draft authors understand what changes are needed in the next revision.

Thanks!

Carlos

--
CARLOS J. BERNARDOS https://www.it.uc3m.es/cjbc/<https://urldefense.com/v3/__https:/www.it.uc3m.es/cjbc/__;!!CQl3mcHX2A!CC6NpE1fM269YHmDQy9Dse9vCCJGG32epxsMo6t2UH7sPcb1IRp98yckm0tRvInRAl9c2JTIFx5WK54aEqsY9bjiGSU$>
Universidad Carlos III de Madrid
RTS/CTS podcast: https://podcasters.spotify.com/pod/show/rts-cts<https://urldefense.com/v3/__https:/podcasters.spotify.com/pod/show/rts-cts__;!!CQl3mcHX2A!CC6NpE1fM269YHmDQy9Dse9vCCJGG32epxsMo6t2UH7sPcb1IRp98yckm0tRvInRAl9c2JTIFx5WK54aEqsYHJnhoTk$>
YouTube channel: https://www.youtube.com/CacharREDando/<https://urldefense.com/v3/__https:/www.youtube.com/CacharREDando/__;!!CQl3mcHX2A!CC6NpE1fM269YHmDQy9Dse9vCCJGG32epxsMo6t2UH7sPcb1IRp98yckm0tRvInRAl9c2JTIFx5WK54aEqsYZlnwWI8$>

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.