Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT)

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 10 November 2020 08:15 UTC

Return-Path: <pthubert@cisco.com>
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 969763A0D86; Tue, 10 Nov 2020 00:15:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=aUlvePR9; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=iZI/hDWQ
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 S5w_9xz9lWFF; Tue, 10 Nov 2020 00:15:49 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C4F03A0D82; Tue, 10 Nov 2020 00:15:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6481; q=dns/txt; s=iport; t=1604996149; x=1606205749; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vnyv8/UJOxuFJ4fv4ljiuwMYw/oUN+DdMPtetAXpkg8=; b=aUlvePR95W1y4delKozEz1WmcKV5PABBV4uKTPF+WZzswXtmZRfOK+kU sbV5THfdrMO9TQZ1qMYDTa8E51du40tWoQ8D4BMxMpCl3E3LvXL7cWDaH e9GDpyrXf+ZZ/NKc5tcGEFFAltgIM8roaCMCcikNyXRRxKXKgWu9vhcaX o=;
X-IPAS-Result: =?us-ascii?q?A0AdBQC4S6pffZxdJa1iDg4BAQEBAQEHAQESAQEEBAEBQ?= =?us-ascii?q?IFPgVJRe1kvLogGA41TihWObIFCgREDVAsBAQENAQEjCgIEAQGESgKCEgIlO?= =?us-ascii?q?BMCAwEBAQMCAwEBAQEFAQEBAgEGBBQBAYY8DIVyAQEBAQIBEi4BATcBBAcEA?= =?us-ascii?q?gEIEQQBAQEjCyERHQgCBA4FCBqDBYJVAw4gAQ6iWwKBO4hodIE0gwQBAQWBN?= =?us-ascii?q?wIOQYMFDQuCEAMGgTiCc4JlTocZG4FBP4ERQ4JPPoIbQgICAQEVgR0LBByDS?= =?us-ascii?q?IIskycBiRmKTZBIVAqCbYkNjG2FNYMYihKURpVMiHuCbo4thDICBAIEBQIOA?= =?us-ascii?q?QEFgWshgUMPB3AVgyRQFwINjh8MFxSDOoUUhQRAdAI2AgYKAQEDCXyLBoJGA?= =?us-ascii?q?QE?=
IronPort-PHdr: =?us-ascii?q?9a23=3AAsxF6RK9NViZsmaWsNmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGvK0/iV7VG4jX9qEMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iK+MFQTFcrjNBXep3So5msUHR?= =?us-ascii?q?PyfQN+OuXyHNvUiMK6n+C/8pHeeUNGnj24NLhzNx6x6w7Ws5ob?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.77,465,1596499200"; d="scan'208";a="585447161"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Nov 2020 08:15:48 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AA8FmnG003750 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 Nov 2020 08:15:48 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 10 Nov 2020 02:15:47 -0600
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 10 Nov 2020 03:15:46 -0500
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 10 Nov 2020 03:15:46 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P98hAffOzUKFSmLm6k7DISKYkCmFaYDbNfv3aqN851bFUNEEnGL090/MkgB6o1M+7ZPVeNfX696hcxK7PCwxRGY4maow/8jpRVU1XZYzNH0g/d1YwjRWzoTmi+dY2IlgVQc4/gISL7As6C7a+7W1pOgE35wNFWp8LjsvidXxdd2c1Dr/K4I8jgHwlFxBIBE0g4T7HLfb68e19E7S3OQk25NyHhqUcORQ49yI+5xRXcGrR3i6Q1Us2uPXsClJchdkfWgyZ/hwXD15b6ScFdp0DpXfTcg00FNd/V7D17IslNE77gAAPjLnkFhNoCdb8Kt63u4xTYcoJtypEnsjOFYdFQ==
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=vUYsY4yNidTO61sYSHAmK7nfNmUi+0HIwF2dqT3ymxE=; b=ASeEs8csgq6Ks06Jrl1bDcDaDXOEfnN+nf9HLQIY8D8H/U7IV+0m0vV1YniqaaF1U1jgp5hCAPgupdBMM5yxya2DT7w48mhJ2l3XrNS1w/8A3UGUdJ6PGbzd1QIFrHjzYh6Pxp1ZOMXip8u9Uhcct+kZD7ZGmj15LY0rGX9w2FOxpoEWWbLqs/Jqu6z38q0lbYldJDBjtlgyYJOzAJT4kT6A9zo9eMjTugPkenysjj98ohzL5Uppfoy9lTCwanndmZpRsxl7PRM2xHeEX+4vwrVaFy8S0Kb296aFa5SBhOxjdgQDBl6jahN7GcvHS+uafq9L8NUFOSOVFd1Hn8VPzQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vUYsY4yNidTO61sYSHAmK7nfNmUi+0HIwF2dqT3ymxE=; b=iZI/hDWQjryh4icSyxiLczx+yAMzebBraOkKtmQ4XwO8tUSVhlqkGuZj+Ah4GGLz0bb1iHethnliHBs/RRXR3oDU2yjyWG+/fYnsJek/H4k1FQ2VE9DyVSCsbVlP+tJinKUCFhN8mfq56KZMb8LJm8A8uCOAoxQ2pZFACm6JaqU=
Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by CO1PR11MB4833.namprd11.prod.outlook.com (2603:10b6:303:99::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Tue, 10 Nov 2020 08:15:43 +0000
Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::ad88:1b7e:c9f2:b30d]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::ad88:1b7e:c9f2:b30d%6]) with mapi id 15.20.3541.025; Tue, 10 Nov 2020 08:15:43 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: Alvaro Retana <aretana.ietf@gmail.com>, The IESG <iesg@ietf.org>, "draft-ietf-roll-turnon-rfc8138@ietf.org" <draft-ietf-roll-turnon-rfc8138@ietf.org>, Martin Duke <martin.h.duke@gmail.com>, Routing Over Low power and Lossy networks <roll@ietf.org>, "roll-chairs@ietf.org" <roll-chairs@ietf.org>, "Michael Richardson" <mcr+ietf@sandelman.ca>
Thread-Topic: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT)
Thread-Index: AQHWhvbDFnz+ZxCN2kqfSLm4/QQEM6lhafFggADkOACAAVPGAIAAAK+AgAAvlRyACqqkkIAAO8YAgAAzb6aAAAQpAIAAVGSAgAiD2ECAAD3vgIAJd1hAgD+ZLwCAAEVDsA==
Date: Tue, 10 Nov 2020 08:15:33 +0000
Deferred-Delivery: Tue, 10 Nov 2020 08:15:24 +0000
Message-ID: <CO1PR11MB48815ED81CFBBF1EC97A2DB2D8E90@CO1PR11MB4881.namprd11.prod.outlook.com>
References: <20200911162617.GQ89563@kduck.mit.edu> <8F19C753-DCA0-4A32-BA3B-A124B2F7F745@cisco.com> <MN2PR11MB3565F2602A0DC55DE9FF3604D83F0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAM4esxQBL+4wNzJTZ_+QKMCGuo4fgyxZKxr3xmFDVEAn9J7HLQ@mail.gmail.com> <E8B2CE91-7FEE-4728-A280-935B69EF3E91@cisco.com> <CAM4esxQpcWROj9mMd3iUXr1EF8kvoF8Zmq-w4BPFVW+BtDU93w@mail.gmail.com> <117497.1600481093@dooku> <MN2PR11MB356549C173D8027709AAC777D8390@MN2PR11MB3565.namprd11.prod.outlook.com> <CAMMESswOs7ZQ3502dNYBN=qJp7O9Ddi=F3UL40Ce7JGknMq-wA@mail.gmail.com> <MN2PR11MB3565C3DB9AFAABD9E8F57CF4D8330@MN2PR11MB3565.namprd11.prod.outlook.com> <20201110033438.GE39170@kduck.mit.edu>
In-Reply-To: <20201110033438.GE39170@kduck.mit.edu>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2a01:cb1d:4ec:2200:dc4f:b025:348a:d66a]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 41bb7bee-35c7-44fa-c945-08d88550d16b
x-ms-traffictypediagnostic: CO1PR11MB4833:
x-microsoft-antispam-prvs: <CO1PR11MB4833F56FF5DB069ADAA43FE2D8E90@CO1PR11MB4833.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 8devRXFRkPQTZm6gVAqFHG/PJEeti1opVm3NLhzVs0mvBXCvHYN85lNsqixkWESjudKOTtejFibm3/nqb2fo6T6t8mH4DluDLRuYoTFxsZHtZmPMfaC/9g8QNWUwqVh6ML7Ku6vhZssbLMbyPrvrmcPyEFFASvOkJzOGGTuDz9k4gtB/WYtLEhzs1imTWnfzThiDypML1PMm0vIHHxMGrTavn9w4qFpHm4FqepweMFGmbOc9sWEt/VJfZuxMjSj+hvOkN5My1PBN32VHvjYqe7gXnI4JZUbPxkCFfr227vC7zAawBLz4e9x5QUFjybn8YUkz9a+w2CkhDVHbCxomUgXQOlh/BrHSxTiS6aWYhF8F2LU+TQWQvt3DlO1+DYgQkNpAt/TScd61qHepvTW5Zg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(346002)(396003)(376002)(366004)(136003)(66446008)(6506007)(4326008)(53546011)(83380400001)(9686003)(66476007)(86362001)(66946007)(33656002)(66556008)(64756008)(7696005)(76116006)(2906002)(55016002)(5660300002)(6666004)(966005)(186003)(316002)(478600001)(52536014)(8936002)(71200400001)(54906003)(6916009)(8676002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?gAHcN9o9JCu8RCj7QKrvE+3YTanmDE60sFPFaandm1mEVhyrmqRf/UH/NV?= =?iso-8859-1?Q?21FCV4oSwBZVQHvmmL0HZokgC8LEnwnVZDhTeJlWqCYUAElw5Da+H+w0ti?= =?iso-8859-1?Q?idCh2fyT4+moDPC6FKpsvJfObenM9Oo/efwBAJhW74hWpznN8nIVN8o18i?= =?iso-8859-1?Q?CmUsD4N7chsMsbXVT1j2ssQDNLAy+LyJqm/xdw4Tg9ccjcQLg/pz3ZqPFd?= =?iso-8859-1?Q?hl61ngHNG1gnI2PkrQEtsblXdxl0zSqXPgbvtLhHFAx97KCrf/vdxHXvKH?= =?iso-8859-1?Q?WzTojPHgtGjCwDEh4HxmJK0POcph0t1jdji7iPE2y8yapgCVjyBTiYdvz1?= =?iso-8859-1?Q?zzB/xRsN+ca1vNw9ZWg4gL3jPb4uq5IomapvaerI50mnBgYTYOpdGXnWMY?= =?iso-8859-1?Q?1Aa2pOmitvB997J72+gNMdj8fLRG6Ug6MYAgcTqgUoH8TGAWIHxzsUBIN0?= =?iso-8859-1?Q?GBGkf1eY4CHcYOoCDezVQM9bNH1Rf46JtMWoHsWdQpWkezKqizeQ8ze674?= =?iso-8859-1?Q?ySW0sukJpVbyEXI41wmWCJZfE8oUxqPe4Df0B9bZ+r4BGZhpSY8xkA9LlD?= =?iso-8859-1?Q?QHx4HbC+986YfmC3vKM2ieUU2tJ6iu4TjotkTHLsT3xn3oix9QpS0RN35v?= =?iso-8859-1?Q?TiKcir2RSItuedodq/CbYfs2jbZXYKEdRrWcuw+Dx/NKDB5RajC1f+BDyu?= =?iso-8859-1?Q?Dkb4PPvXmGNY4gEd+jzo1JIagQY0X4464YXKC/PIALNgpshg17NLGzIoca?= =?iso-8859-1?Q?MshRoQRx1gh15uR2J1pHxggHKGW+UOJmLlSRWGdY9JZ00suYqnncWN9rk3?= =?iso-8859-1?Q?c3VEuC+yK/AOYRUP/xjkczXPi8eBF6cLVFN6x+BjE5wKWzpVdN5txELYQx?= =?iso-8859-1?Q?YVFDz2jUaYW2fT05rJNT4OHcyrvxFDRuPmCeswHo8Ez3wO7lnGEymaApok?= =?iso-8859-1?Q?Jnh6VW84x4gElSC15WLonysyArUFaSmxgUN5mn+wtiPEbhC9q8VFLQ=3D?= =?iso-8859-1?Q?=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 41bb7bee-35c7-44fa-c945-08d88550d16b
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2020 08:15:42.9160 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: T0Q7eVJjs0MoKn/RbOqiRYH578E3FVhlD8r/sH5oqKXK+RCROXY9YY/E9lwjhTKNR6RGna0nkcqNFto3MuipXQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4833
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/IcbGN0MNbm7Elo4e6lEACxq2g6I>
Subject: Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Nov 2020 08:15:52 -0000

Hello Benjamin:
 
> That said, and my apologies for a hazy memory coming back to this after a
> couple months, in a year or N from now when mopex is finalized, how will
> someone looking at mopex know to use RFC8138 on links where 6LoWPAN
> Header Compression applies (and not use it otherwise)?  We are claiming in
> the -14 of this document that:
> 
>                               For a MOP value of 7, [RFC8138] MUST be
>    used on Links where 6LoWPAN Header Compression [RFC6282] applies and
>    MUST NOT be used otherwise.
> 
> but I am not sure (or have forgotten) what the chain of references is supposed
> to lead someone who is implementing RPL plus MOP=7 to the requirement to
> use RFC 8138.  I don't think we should just rely on the mopex text to do so,
> since we are trying to impose the requirement with this document (which
> predates mopex by some time), and there's not anything (other than our
> collective memories, of course) requiring mopex to remain consistent with
> that requirement.

Just to be clear for the other readers: MOPext does not exist as a normative reference for this work.
The only field that exists is the MOP field in the DIO and that field is 3 bits long, values 0..7.

The normative reference that you are after is https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/
This is the spec that updates RPL and changes the IANA registry to indicate that 7 is not a MOP.

There we have:

"

...

  Anticipating future work to revise RPL relating to how the LLN and
   DODAG is configured, this document changes the interpretation of the
   [dodagcfg] Registry to be limited to Mode-of-Operation (MOP)
   specific.  The MOP is described in [RFC6550] section 6.3.1.  The
   Options Flags Registry is renamed, and applies to MOP values zero (0)
   to six (6) only, leaving the flags reserved for MOP value seven (7).

   In addition, this document reserves MOP value 7 for future expansion.

...

11.3.  Change MOP value 7 to Reserved

   This document changes the allocation status of the Mode of Operation
   (MOP) [ianamop] from Unassigned to Reserved.  This change is in
   support of future work related to capabilities.
"

So basically we tell the implementations from now on to test if MOP is 7, and in that case, the Options Flags are undefined. In other words, if MOP is 7, the stack must not use the option flags as if the MOP was <7. In fact, 7 is no more a MOP value but a reserved thingy that can be overloaded in the future. And yes, we intend to do just that in MOPExt.

Until that happens, implementations are at a loss if they encounter when a MOP field that is all ones. So we need to give them instructions to cope with the situation. This draft derives whether to use RFC 8138 from whether the 6LoWPAN compression applies to the link or not.

This will stay true forever, unless another RFC amends it. When/if that happens, the new RFC will have to consider backward compatibility with a legacy implementation that implements the above. 

Note that this line of thought applies to 3 flags, defined respectively in:
- https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/
- https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/
- https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/

Keep safe!

Pascal

> 
> Thanks,
> 
> Ben
> 
> On Wed, Sep 30, 2020 at 04:25:10PM +0000, Pascal Thubert (pthubert) wrote:
> > Hello Alvaro
> >
> > I uploaded both draft with the suggested update, please see
> >
> > https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-turnon-rfc8138-17.
> > txt
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-21.tx
> > t
> >
> > Keep safe
> >
> > Pascal
> >
> > > -----Original Message-----
> > > From: Alvaro Retana <aretana.ietf@gmail.com>
> > > Sent: jeudi 24 septembre 2020 17:49
> > > To: Pascal Thubert (pthubert) <pthubert@cisco.com>
> > > Cc: Benjamin Kaduk <kaduk@mit.edu>du>; The IESG <iesg@ietf.org>rg>;
> > > draft-ietf- roll-turnon-rfc8138@ietf.org; Martin Duke
> > > <martin.h.duke@gmail.com>om>; Routing Over Low power and Lossy networks
> > > <roll@ietf.org>rg>; roll- chairs@ietf.org; Michael Richardson
> > > <mcr+ietf@sandelman.ca>
> > > Subject: Re: [Roll] Benjamin Kaduk's Discuss on
> > > draft-ietf-roll-turnon-rfc8138-
> > > 14: (with DISCUSS and COMMENT)
> > >
> > > On September 24, 2020 at 8:13:09 AM, Pascal Thubert wrote:
> > >
> > >
> > > Pascal:
> > >
> > > Hi!
> > >
> > > > Following the meeting last Monday and subsequent the update of
> > > > useofrplinfo by Michael (thanks Michael!) I published a new
> > > > version of the turnon RFC
> > > > 8138 draft.
> > > >
> > > > The major changes are
> > > > - removed the formal update to RFC 6550
> > > > - refer to useofrplinfo as the justification why the flag is not
> > > > defined for MOP 7
> > > > - defined the operation in MOP 7 as compression on iff the Link
> > > > uses 6LoPWAN HC.
> > >
> > > Thanks for these changes.
> > >
> > > Because we have to cycle useofrplinfo back through (when the WG is
> > > done with it), I asked Ben/Martin to wait for that before coming
> > > back to this document.  It'll make it easier than tracking multiple
> > > changes. :-)
> > >
> > >
> > > OTOH, I do have comments on the recent change:
> > >
> > > OLD>
> > >    Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that
> > > the
> > >    definition of the Flags applies to Mode of Operation (MOP) values
> > >    zero (0) to six (6) only, leaving the flags reserved for MOP
> > > value
> > >    seven (7).  For a MOP value of 7, the bit in position 2 is
> > > considered
> > >    unallocated and [RFC8138] MUST be used on Links where 6LoWPAN
> > > Header
> > >    Compression [RFC6282] applies and MUST NOT be used otherwise.
> > >
> > > NEW>
> > >
> > >    Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that
> > > the
> > >    definition of the Flags applies to Mode of Operation (MOP) values
> > > zero (0)
> > >    to six (6) only.  For a MOP value of 7, [RFC8138] MUST be used on
> > > Links
> > >    where 6LoWPAN Header Compression [RFC6282] applies and MUST NOT
> > > be used
> > >    otherwise.
> > >
> > >
> > > Thanks!
> > >
> > > Alvaro.