Re: [Roll] MOPex updates and extended control option query

On Mon, 1 Nov 2021 at 14:02, <dominique.barthel@orange.com> wrote:

> Hello Rahul,
>
>
>
> I’m digging up open items regarding our active documents., sorry if this
> comes up very late.
>
> I’m curious about your proposal for an option “for the node to not join
> the network at all (not even as 6LN) if a control option is not understood”.
>
> Do you have a use case for it that you could share?
>

I do not have a use-case for this. Michael also pointed out this on the
repo <https://github.com/roll-wg/mopex/issues/8#issuecomment-811380561>if
this is necessary. I think this point was raised during one of the interims
(but I do not know exactly who raised this point).

Thank you for bringing this up.

> I fail to see in which circumstance the node should not be allowed to join
> as a leaf node?
>
> Thanks
>
>
>
> Dominique
>
>
>
>
>
> *From:* Roll [mailto:roll-bounces@ietf.org] *On Behalf Of *Rahul Jadhav
> *Sent:* mercredi 31 mars 2021 16:25
> *To:* Routing Over Low power and Lossy networks <roll@ietf.org>
> *Subject:* [Roll] MOPex updates and extended control option query
>
>
>
> Hello All,
>
>
>
> The MOPex draft is refreshed with just editorial changes in this version.
>
>
>
> However, I would like to raise one point that Pascal made during the IETF
> 110 session.
>
>
>
> Currently, the MOPex draft extends the RPL control options with certain
> flags to handle cases where the control option is not understood by the
> node:
>
> J-flag: Join only as 6LN
>
> C-flag: copy option as-is even if not understood
>
> I-flag: Ignore message altogether.
>
>
>
> We could have an option for the node to not join the network at all (not
> even as 6LN) if a control option is not understood.
>
> Any feedback on this would be appreciated.
>
>
>
> Thanks,
>
> Rahul
>
>
>
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>
> Date: Wed, 31 Mar 2021 at 19:43
> Subject: New Version Notification for draft-ietf-roll-mopex-03.txt
> To: Michael Richardson <mcr+ietf@sandelman.ca>, Pascal Thubert <
> pthubert@cisco.com>, Rahul Arvind Jadhav <rahul.ietf@gmail.com>
>
>
>
>
> A new version of I-D, draft-ietf-roll-mopex-03.txt
> has been successfully submitted by Rahul Arvind Jadhav and posted to the
> IETF repository.
>
> Name:           draft-ietf-roll-mopex
> Revision:       03
> Title:          Mode of Operation extension
> Document date:  2021-03-31
> Group:          roll
> Pages:          9
> URL:
> https://www.ietf.org/archive/id/draft-ietf-roll-mopex-03.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-roll-mopex/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ietf-roll-mopex
> Htmlized:       https://tools.ietf.org/html/draft-ietf-roll-mopex-03
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-mopex-03
>
> Abstract:
>    RPL allows different mode of operations which allows nodes to have a
>    consensus on the basic primitives that must be supported to join the
>    network.  The MOP field in [RFC6550] is of 3 bits and is fast
>    depleting.  This document extends the MOP for future use.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>