Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3941C3A125F for ; Wed, 24 Jun 2020 20:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxvCCuMZIvRg for ; Wed, 24 Jun 2020 20:53:54 -0700 (PDT) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255096.outbound.protection.outlook.com [40.92.255.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 640893A1260 for ; Wed, 24 Jun 2020 20:53:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gflGbVBSZK7tu/7/yzSpE0Sw+IuY6kn/k0deHRiYSZKPFYA231TMh7gkmbmEGXZV/tF535ld4caKAAMMe2CxNnUlJuQEKwHOCQytlV7pad4/jWYHNwBcEecGIR3pM2yvEm6NnnLD0vUJj0WcFdKfqwC5Q4hYoBfc0Y1JZU8RFJB40h3O5yVSxJagmQaba413EOaBqtaqJjwER4KW0koZScvoHjwKBkYWTt+92zebPLVQWNENzay3uk0i+Y+9CLX4VSP00QVTV3K4JeJ4N2aPqqRJA7QRk4itMhefKVnnpJsJH7rQARV7l+t8C1GcH5+zMM1xIGy2jfvKV7N1vbNt3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jhChIk3LHp+cNLxgFv7hkhYfORLEcv2mMOJM/PzzrYk=; b=IIvoRn4chT5ln9stKQRtpLu/Mc7+7a9i9pKbWWSonTR7+5RFc2TxrICHrJnm1KcGhQIfmq0U2DN61MyK0OwnBlYZvAXdouIsqf3kvqzFgFAK1RQe2GRLKZr8Uark+y6Kw+Ny5G7fapES2G8gupnv0jI9aKxfdWPPSS6uuOr2l0DpoKS2eA2eieTfa+FYR0v+ZT9bss65OMSSCm5t1ODrLKZdE7easojNLFNEsMvm2iwn2gjF623Wst0nkCe1GQKgXsBJ9MBW9vfsGD9FMTn4xbboZunkDPoBOrH0Tz2mnflMQ/YJCqn3JDb/2F50jyyaFGKNp/myFY7MXvjqwNtlxQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jhChIk3LHp+cNLxgFv7hkhYfORLEcv2mMOJM/PzzrYk=; b=Gx6AR9Mxw4s3XhGpBp+G78pqHZyqzpfXT8BEM7s5ADYgq3bShClHOMJ+UcnZGV3Ft1CaHiP2ve051QHtZp8BAjzbT9AxZgxzzU8GI5azDPbZsvsqr/vRw3fprSUytOSydrjLnYvlrgIEkOHiH9DmEg4RJOMrCLCYmOE+Iy9REZRE1lZ1s004V+CS97ASAOdeTzKQXrPsieTNBzhCCEie26CuI97HaxFG0OFmM26HwDLlKomflw7sE4vNKt/I/B92h+wUjOETgrsvAbZuQunzc+d91sQ5eyB/+K2JAj9VY+kaZo3nF2LB8JfMKndJdw17YFFUmUVGReolcQ3C0+bicw== Received: from SG2APC01FT010.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebd::53) by SG2APC01HT126.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebd::473) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20; Thu, 25 Jun 2020 03:53:51 +0000 Received: from MAXPR01MB2493.INDPRD01.PROD.OUTLOOK.COM (2a01:111:e400:7ebd::49) by SG2APC01FT010.mail.protection.outlook.com (2a01:111:e400:7ebd::134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20 via Frontend Transport; Thu, 25 Jun 2020 03:53:51 +0000 Received: from MAXPR01MB2493.INDPRD01.PROD.OUTLOOK.COM ([fe80::e874:bbdb:9f9e:9564]) by MAXPR01MB2493.INDPRD01.PROD.OUTLOOK.COM ([fe80::e874:bbdb:9f9e:9564%7]) with mapi id 15.20.3131.021; Thu, 25 Jun 2020 03:53:51 +0000 From: Rahul Jadhav To: "dominique.barthel@orange.com" , Routing Over Low power and Lossy networks Thread-Topic: [Roll] I-D Action: draft-ietf-roll-mopex-01.txt Thread-Index: AQHWOwzCVlO/cQSRb0a3yOaskASri6jJo7K4gB55zQCAAKJGEIAAEfYQ Date: Thu, 25 Jun 2020 03:53:51 +0000 Message-ID: References: <159134282158.9958.9959185769917010945@ietfa.amsl.com> , <22823_1593018389_5EF38815_22823_277_1_DB1952B5.7689D%dominique.barthel@orange.com>, In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-IN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:B09C09793B9E85FE62CAD9E51CCB71D1987440ECBE7DE09265EF60DB723C2BE1; UpperCasedChecksum:B441FFD396168E752B6E214509427987177AF67B71317D96712C31A4B75308E2; SizeAsReceived:7154; Count:43 x-tmn: [yfeO0BwbJJTM522avf5nDmTw+YEd0uBO] x-ms-publictraffictype: Email x-incomingheadercount: 43 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: e487b472-8a63-4d0e-45c0-08d818bb5f6b x-ms-traffictypediagnostic: SG2APC01HT126: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XRQwIDItgnCDNkgPb1FxZp8nqgOutjm24Quu6a7cMSlXJcBlKAdTWupz54cTd7KWWVOS1ZW9C0xNx8I1p9wpU1Whn4qGs9nclYMbZ6JU27KiLY5hc663SZY/nn011PV5u5NBDVPpCLbpHYZJfNRlFt+DdGwQveisTiQiG4xqoTJWt/SdcBrE+2ZjFe4ra4hErCCreayeZpfazaXSUKAonqu+bzTMTf5eUVgBahL8XbDVLFmAq6k5vRWaNF1fyckZ x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:MAXPR01MB2493.INDPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:; DIR:OUT; SFP:1901; x-ms-exchange-antispam-messagedata: jvfFzIFo2/cBtc1FCWLYpanTAQsC2AujodLI0o7sQUR5olNJocX6SoWb5NnuMmBH2TRUiM4aWRyIU3tdhDwAgNkx8kWgYqiIxQlO/qyVbYY4OQMMN+59pRmJ9Zl4llxIdOBPlJ3zYorpPNShyc1Qpg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MAXPR01MB24933B20742BBFF9DC862D27A9920MAXPR01MB2493INDP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-AuthSource: SG2APC01FT010.eop-APC01.prod.protection.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: e487b472-8a63-4d0e-45c0-08d818bb5f6b X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2020 03:53:51.1152 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT126 Archived-At: Subject: Re: [Roll] I-D Action: draft-ietf-roll-mopex-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 03:53:57 -0000 --_000_MAXPR01MB24933B20742BBFF9DC862D27A9920MAXPR01MB2493INDP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dominique, I have added PR [1] and will upload the draft after the interim once we are= aligned. Diff can be viewed here: https://github.com/nyrahul/mopex/blob/master/diff-= draft-ietf-roll-mopex.html Also many thanks for the nit-fixes PR. Thanks, Rahul [1]https://github.com/roll-wg/mopex/pull/7 [https://avatars3.githubusercontent.com/u/41386261?s=3D400&v=3D4] RPL Extended Control Option Fixes by nyrahul =B7 Pull Request #7 =B7 roll-w= g/mopex updates based on Dominique review IANA consideration added @dbarthel-ol Tha= nks. github.com ________________________________ From: Roll on behalf of Rahul Jadhav Sent: 25 June 2020 11:08 AM To: dominique.barthel@orange.com ; Routing Ov= er Low power and Lossy networks Subject: Re: [Roll] I-D Action: draft-ietf-roll-mopex-01.txt Thanks Dominique for the review. Your points about extended options are rig= ht. Please find my comments [RJ] inline. Thanks, Rahul Hello Rahul, Food for discussion at the upcoming interim: I'm surprised the Extended Control Option is recognized by the X bit being = set, where X is bit 6 of the Option Type (or bit number 1 counting from 0 l= eft to right in the byte). "Option Type 0x40 to 0x7F are thus applicable only as extended options." What is your intention regarding Option Type 0x80-0xFF? [RJ] I was under the confusion that the MSB bit of option type means "secur= e" bit and thus I option Types 0x80-0xff were considered to be secure optio= ns. But my understanding is wrong. Only the RPL control codes have this MSB= set to indicate secure message so indeed we are free to use MSB of the Con= trol Option type. But yes my assumption was we reserve set of option type as extended option = types and currently the draft reserves range 0x40-0x7f for this. With the current definition, it follows that "Option Type 0xC0 to 0xFF are = thus applicable only as extended options." as well. [RJ] Like I mentioned that the MSB was assumed to be the secure bit (this a= ssumption is clearly wrong). Thus 0xC0 to 0xFF was assumed to be extended o= ptions with secure message. But just ignore this part since it does not mak= e sense anymore (because of incorrect assumption of secure bit). Or should X be a two bits field, where 0b00 designates the legacy Control O= ption and anything different from 0b00 the Extended Control Option? [RJ] I didn't get this. 0b00 represent two bytes however Control Option Typ= e field is of 1 byte. I'm assuming the Extended option is better, and we don't want to save have = of the space for the legacy one. [RJ] It is better to have legacy option as well since it saves 1 byte per o= ption. Ext options can be used only when the RPL extension intends to use t= he 'J/I/C' flags. The draft has also mandates what an implementation should= do on witnessing an unknown regular control option (not ext opt). Overall, I will change the draft to use MSB as ext bit and thus reserve, 0x= 80 to 0xff for extended options. Thank you very much for pointing this out. Thanks Dominique De : Roll > on behalf o= f Rahul Jadhav > R=E9pondre =E0 : "roll@ietf.org" > Date : Friday 5 June 2020 09:44 =C0 : "roll@ietf.org" > Objet : Re: [Roll] I-D Action: draft-ietf-roll-mopex-01.txt Hello All, The primary update is about the Extended Control Option format that we disc= ussed during the interim. Best, Rahul ________________________________ From: Roll > on behalf = of internet-drafts@ietf.org > Sent: 05 June 2020 03:40 PM To: i-d-announce@ietf.org > Cc: roll@ietf.org > Subject: [Roll] I-D Action: draft-ietf-roll-mopex-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy networks = WG of the IETF. Title : Mode of Operation extension Authors : Rahul Arvind Jadhav Pascal Thubert Michael Richardson Filename : draft-ietf-roll-mopex-01.txt Pages : 8 Date : 2020-06-05 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-mopex/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-mopex-01 https://datatracker.ietf.org/doc/html/draft-ietf-roll-mopex-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-mopex-01 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_MAXPR01MB24933B20742BBFF9DC862D27A9920MAXPR01MB2493INDP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Dominique,

I have added PR [1] and will upload the draft after the interim once we are= aligned.

Also many thanks for the nit-fixes PR.

Thanks,
Rahul

3D""
updates based on Dominique review IANA consideration added @dbarthel-ol Tha= nks.
github.com

From: Roll <roll-bounces= @ietf.org> on behalf of Rahul Jadhav <nyrahul@outlook.com>
Sent: 25 June 2020 11:08 AM
To: dominique.barthel@orange.com <dominique.barthel@orange.com>= ;; Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] I-D Action: draft-ietf-roll-mopex-01.txt
 
Thanks Dominique for the review. Your points about extended options are rig= ht. Please find my comments [RJ] inline.

Thanks,
Rahul


Hello Rahul,

Food for discussion at the upcoming interim:
I'm surprised the Extended Control Option is recognized by the X bit b= eing set, where X is bit 6 of the Option Type (or bit number 1 counting fro= m 0 left to right in the byte).
"Option Type 0x40 to 0x7F are&n= bsp;thus applicable o= nly as extended options."
What is your intention regarding Option Type 0x80-0xFF?

[RJ] I was under the confusion that the MSB bit of option type means &= quot;secure" bit and thus I option Types 0x80-0xff were considered to = be secure options. But my understanding is wrong. Only the RPL control code= s have this MSB set to indicate secure message so indeed we are free to use MSB of the Control Option type.
But yes my assumption was we reserve set of option type as extended op= tion types and currently the draft reserves range 0x40-0x7f for this.

With the current definition, it follows that "Option Type 0xC0 to 0xFF are thus applicable only as extended options.&= quot; as well.

[RJ] Like I mentioned t= hat the MSB was assumed to be the secure bit (this assumption is clearly wr= ong). Thus 0xC0 to 0xFF was assumed to be extended options with secure mess= age. But just ignore this part since it does not make sense anymore (because of incorrect assumption of secure = bit).

Or should X be a two bi= ts field, where 0b00 designates the legacy Control Option and anything diff= erent from 0b00 the Extended Control Option?

[RJ] I didn't get this.= 0b00 represent two bytes however Control Option Type field is of 1 byte.

I'm assuming the Extended option is better, and we don't = want to save have of the space for the legacy one.

[RJ] It is better to ha= ve legacy option as well since it saves 1 byte per option. Ext options can = be used only when the RPL extension intends to use the 'J/I/C' flags. The d= raft has also mandates what an implementation should do on witnessing an unknown regular control option (not ext opt).
Overall, I will change the draft to use MSB as ext bit and thus r= eserve, 0x80 to 0xff for extended options.
Thank you very much for= pointing this out. 

Thanks

Dominique

De : Roll <roll-bounces@ietf.org> on behalf of Rahul J= adhav <nyrahul@outlook.com>= ;
R=E9pondre =E0 : "roll@ietf.org" <roll@ietf.org>
Date : Friday 5 June 2020 09:4= 4
=C0 : "roll@ietf.org" <roll@ietf.org>
Objet : Re: [Roll] I-D Action:= draft-ietf-roll-mopex-01.txt

Hello All,

The primary update is about the Extended Control Option format that we disc= ussed during the interim.

Best,
Rahul
From: Roll <roll-bounces@ietf.org> on behalf o= f internet-drafts@ietf.org &l= t;internet-drafts@ietf.org&= gt;
Sent: 05 June 2020 03:40 PM
To: i-d-announce@ietf.org <i-d-announce@ietf.org&g= t;
Cc: roll@ietf.org <roll@ietf.org>
Subject: [Roll] I-D Action: draft-ietf-roll-mopex-01.txt
 

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Routing Over Low power and Lossy networks = WG of the IETF.

        Title    &nb= sp;      : Mode of Operation extension
        Authors    &= nbsp;    : Rahul Arvind Jadhav
            &nb= sp;            = Pascal Thubert
            &nb= sp;            = Michael Richardson
        Filename    =     : draft-ietf-roll-mopex-01.txt
        Pages    &nb= sp;      : 8
        Date    &nbs= p;       : 2020-06-05

Abstract:
   RPL allows different mode of operations which allows nodes to = have a
   consensus on the basic primitives that must be supported to jo= in the
   network.  The MOP field in [RFC6550] is of 3 bits and is = fast
   depleting.  This document extends the MOP for future use.=


The IETF datatracker status page for this draft is:
https:/= /datatracker.ietf.org/doc/draft-ietf-roll-mopex/

There are also htmlized versions available at:
https://to= ols.ietf.org/html/draft-ietf-roll-mopex-01
= https://datatracker.ietf.org/doc/html/draft-ietf-roll-mopex-01

A diff from the previous version is available at:
ht= tps://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-mopex-01


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet= -drafts/


_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org= /mailman/listinfo/roll
 
______________________________________________________________________=
___________________________________________________=0A=
=0A=
Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc=0A=
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler=0A=
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,=0A=
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.=0A=
=0A=
This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;=0A=
they should not be distributed, used or copied without authorisation.=0A=
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.=0A=
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.=0A=
Thank you.=0A=
--_000_MAXPR01MB24933B20742BBFF9DC862D27A9920MAXPR01MB2493INDP_--