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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 11 November 2020 17:46 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 77FCC3A51F5; Wed, 11 Nov 2020 09:46:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level:
X-Spam-Status: No, score=-9.601 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_H2=-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=TM5+VUzl; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=PM5uzlfB
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 LD_gbfDe3WLd; Wed, 11 Nov 2020 09:46:17 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34BFC3A1DBC; Wed, 11 Nov 2020 09:31:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10050; q=dns/txt; s=iport; t=1605115908; x=1606325508; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=g7X1MjC6EbISEpln7I8P0O/OR35AL07WAmK56NWNjBY=; b=TM5+VUzl980HBaEezQGpckHgSwDwjO3lRxKq/4yCJ8mjcynMQ7MTqfeC SjjctNUPIrRoEUMOm7/lwjM3YUZgIxNPsqPXVHq5DzTq1u6OK6V7uxQ6g lK5aguLcWfBY3MaUsbfk6MITWY4Tt99J8a/rM8z0OC4wU/tkXE3f5GM1Z Q=;
X-IPAS-Result: =?us-ascii?q?A0AcBQDWHqxffYgNJK1iDg4BAQEBAQEHAQESAQEEBAEBQ?= =?us-ascii?q?IFPgVJRe1kvLogGA41UihaObYFCgREDVAsBAQENAQEjCgIEAQGESgKCFgIlO?= =?us-ascii?q?BMCAwEBAQMCAwEBAQEFAQEBAgEGBBQBAYY8DIVyAQEBAwESLgEBNwEEBwQCA?= =?us-ascii?q?QgRBAEBASMLIREdCAIEDgUIGoMFglUDDiABDqUbAoE8iGh0gTSDBAEBBYE3A?= =?us-ascii?q?g5Bgw8NC4IQAwaBOIJzgmVOhxkbgUE/gRFDgVF+PoIbQgEBAgEBFYEdCwQcg?= =?us-ascii?q?0iCLJMoAYkaik6QSlQKgm2JD4xyhTWDGYoVlEmVUIh9gm6OMYQ0AgQCBAUCD?= =?us-ascii?q?gEBBYFrIYFDDwdwFYMkUBcCDY4fDBcUgzqFFIUEQHQCNgIGCgEBAwl8iwaCR?= =?us-ascii?q?gEB?=
IronPort-PHdr: =?us-ascii?q?9a23=3AvvRlGBN77QompOiv+HAl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKw13lrIQcPW5+8Xw+bVsqW1X2sG7N7BtX0Za5VDWl?= =?us-ascii?q?cDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoNElJXsvyeg6arni79zVHHB?= =?us-ascii?q?L5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZ5LQ69qkPascxFjA=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.77,470,1596499200"; d="scan'208";a="605671022"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Nov 2020 17:31:47 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 0ABHVlxJ010711 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Nov 2020 17:31:47 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 11 Nov 2020 11:31:46 -0600
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 11 Nov 2020 11:31:46 -0600
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 11 Nov 2020 12:31:45 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZE8NTCBO2AEYK8RbDryE/Em1C0yHrXDIEquxPCKYv23E3satnlPukuaaRM2+XQp8gIPRC2StRC6T5dfddXOq/WKBrk4WZ7KCrf/FnQeArh5uHAsaVBwb6F0EMH2TSkFYl5a1MWjN2WgFPMgbPLMzh5t8YoPU/T/0eImMUEDUTGAnwG+3jFIWOv9QDh6pAIO/7MlaPJbd/2MgCh7STyz4rRW3LUST1qxGuoX7JO7IUHc+wJnvprRaesBJgCEqRnl4WGzJK0Uk56vq7BK7cn8QBLwqI/GBVziTLOQp8o/DFGxzfrJ93SvHx7Xt5XmOs/gSjEiBVYh0LursbLaH1oe3qg==
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=SEsiBu0VPE1VE7nU/pgc74xZCojUzEGll0Aa8fPzCS4=; b=Ha/5v70nabnSIM6msObDLZFTUZ6D7A3KwaVCxr34HJSDvthbq9mwehTM4le/1vnJLlX1bqv8cX49TQlIQpUR3VgWHDjR7LFHueK/9AMsclltndjsVlv2/7gcsZdpEmHxE8s6vSnd32AbfPjpKBCoHykcMqNHYoIYmnbyNpnrEQS1Oev6U2yd7+3gZiCsAXZylei8j4FRjkyjlUc72hMnHNv50n+nretRDOrDCMhLmwx95NtLs9ibfh2Tpu2RyhVayYP/EnPxvno6cWhpr7aLoE+YXLC9hGpwTeNWGVOoS58ekkCRpBffEABrXc1bpqqGVLZz+7Cu5RcEUJN2SkDpsQ==
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=SEsiBu0VPE1VE7nU/pgc74xZCojUzEGll0Aa8fPzCS4=; b=PM5uzlfB2LzSfaLb+PrTLYMw7IHawjQlZNuh1XmnE/lhDET4HJyAv2p8ckd1iyieTEtXH8ba1OiVdAaQ+vidSGaICYikPzsyJDdaZRo+pUckKm6fRsnCry/1uVVGcS3FEcLTqqOxhoj164xXGEf46ShGOx3++Qcsz/uZT+IVNWw=
Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR11MB1824.namprd11.prod.outlook.com (2603:10b6:300:110::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.24; Wed, 11 Nov 2020 17:31:44 +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; Wed, 11 Nov 2020 17:31:44 +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+ZLwCAAEVDsIABhn8AgACo+UA=
Date: Wed, 11 Nov 2020 17:31:28 +0000
Deferred-Delivery: Wed, 11 Nov 2020 17:30:32 +0000
Message-ID: <CO1PR11MB48817CF317D9DC3611F7C5B8D8E80@CO1PR11MB4881.namprd11.prod.outlook.com>
References: <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> <CO1PR11MB48815ED81CFBBF1EC97A2DB2D8E90@CO1PR11MB4881.namprd11.prod.outlook.com> <20201111070010.GU39170@kduck.mit.edu>
In-Reply-To: <20201111070010.GU39170@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:90d6:2c75:2304:2eda]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b0219558-8ee1-4985-ecbe-08d88667a8f6
x-ms-traffictypediagnostic: MWHPR11MB1824:
x-microsoft-antispam-prvs: <MWHPR11MB18248D36462453254158AB37D8E80@MWHPR11MB1824.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: Qq8RaeiGkbECNGHeEpXGF9p5HbR54edV9TG4W9tJvbNxEi6zirGqy4v9EtOB4OEZai5xnvPNDzDbIzsTyzhTio6fyK6pH+PB5IY6/O+OQmelv9t2WWdR5gMVq/jJmq44vaQnTSakI6Gqt6+PhoQObGb88EPlMZtAhA4G5qq1AAHbKzqx7zR4HZ9RHOmIoMZjr4/BsV/+zfnAYBM9rg4lOOzBmzQqS90jx77RErzK1RV3K0vgpge94k2dB6/UFCZ9E7gT7j+crXAbF/kh0+RPJWiG+d4YtEuEOBR4O9fMBzv9dLEVRetgSgAd+HOjA82GgAaOzjifsa9VNx3/ly0/838DCPSLbcf6/Sr6i6yaThW2IE+lBe2N+ZbGXTMb526HiPOvbx0D50o730/FbFR+bw==
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:(376002)(366004)(346002)(136003)(39860400002)(396003)(55016002)(5660300002)(8676002)(7696005)(8936002)(6506007)(53546011)(33656002)(86362001)(6916009)(76116006)(478600001)(186003)(71200400001)(316002)(52536014)(2906002)(4326008)(66556008)(83380400001)(66476007)(64756008)(66446008)(966005)(6666004)(66946007)(54906003)(9686003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?8XpoMLIg8Oma4ENhG1N/YQv9brBXA9iHEr1GjZYAyTgDFA6IpvAF0M58yl?= =?iso-8859-1?Q?KwDLpr5JBldmIwcRvBFnNLsyAlA8enByUa392SZ0b/U0Dj57k4GSGbCVaM?= =?iso-8859-1?Q?BDPljcOaLI0CUUwmdT8GC6EEXr20cPqo0EKHmDHVaI5a1Q3w4vS+TSXVuU?= =?iso-8859-1?Q?sU1D7IACLVilFoul8n5JIIspaYVVlSrpHrivHHpRujW58943LXmtLYqj1Q?= =?iso-8859-1?Q?o8FycQ9cxCqu6/mof5Qjk2QyxfGJ4GBA/pI97rc1PhYE8mJWbyll9dEeK0?= =?iso-8859-1?Q?mxs0bFIYcZ81mSpjWpauVWc0LhJnqLS7josBdC5CKDYJneWTjhdhsxNfSk?= =?iso-8859-1?Q?RTURtFk7Msmm7F1fXhJT517Azc+EEHNH1jZmWJW2ufd1Uo96kl4CRZG6Yg?= =?iso-8859-1?Q?6+2ZFz9Qh8KxBf6QX0ga0r6lnYbrsrKwmdO7nCGoyl4m75nS/GXGCkpD/B?= =?iso-8859-1?Q?PZsVQzTk17xWeueOulSDOqDJuV/QKwaXEnmcC9Jx+84c5P/eeUuiUDW3zA?= =?iso-8859-1?Q?BMM1M7IaoeExnTrBo4f/pYtoLLCn0YcOTtYmOVS6w/+lRmAGikTYm+brA1?= =?iso-8859-1?Q?wyWhbVlSKed39Fz/ZZpuoz+dCfF0zgeesXNTWKdTGPKA5utLImnAMd1kST?= =?iso-8859-1?Q?tBShsx4JPeD2BZAOaGq00FyxH7PbUYn5zj//ZrsMX1pL9RL0CZCBaROZ9p?= =?iso-8859-1?Q?G6jaWU4hJTGoMbjjbmrat7IYb6zb3uxpUPi0pQBITGu+zAZ0fncet6G9gs?= =?iso-8859-1?Q?E60aqL1ti4L1vJ6DkNAuCKs9pbxlJ4tCng+91g+2DhHBBbUiQXaX2P/Xis?= =?iso-8859-1?Q?iGxznijlpoP2tBt12Ztyb43uMC7lyWkhpgkijTLQz8n65fBSRzovf28XBC?= =?iso-8859-1?Q?tgqxvVLwYEiepN0YOEYbwmkFTVbiArujM63xAEU8UpcHJS7vK8qR1Os2pM?= =?iso-8859-1?Q?WxnUf5fiBtasXAjunij08CQgfDkVkiXPEUCc1O7JdehulDWZiA77VA=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: b0219558-8ee1-4985-ecbe-08d88667a8f6
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2020 17:31:44.6756 (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: yT6wHUdBt8fNl5breE/ttS3fQRwSfSTtSGOVJNFpPjE3b6yBmm1LMB3clqRwCeBttNe+VYFXozQccomgzNEA6g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1824
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/4U3phMecLBANYftrvsINbtYcyD4>
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: Wed, 11 Nov 2020 17:46:24 -0000

Hello Benjamin

 
> I will say a bit more inline, but want to note upfront that my primary unease
> here is that we seem to be assigning some (partial) semantics to MOP value 7
> here (even though we do not specify full semantics for MOP value 7):
> 
>                               For a MOP value of 7, [RFC8138] MUST be
>    used on Links where 6LoWPAN Header Compression [RFC6282] applies and
>    MUST NOT be used otherwise.

True; we considered the position of an implementer testing for MOP < 7 to decide if the flag was meaningful.
That implementer would have to populate the else statement and we preferred to give him instructions rather than have different implementations do different things.


> 
> yet there is no "trail of breadcrumbs" for someone to follow from "I want to
> implement MOP 7" and end up at the sentence I quoted above.  A formal
> Update to 6550 would provide such a trail, as would being listed as a
> reference in the IANA registry for MOP value 7.  My current understanding is

There was this traceability statement in https://tools.ietf.org/html/draft-ietf-roll-turnon-rfc8138-15#section-3 which is gone now.
I followed Alvaro's lead there; we removed it based on an interpretation of the "updates" that denotes a change in RFC 6550 implementations, which is not the case here. Using a reserved flag is not an "update" per this interpretation.

But yes, I see your point. 

> that the only thing we have right now is "repeat this requirement in whatever
> document ends up providing a full specification for MOP value 7", and I don't
> think that relying on the IETF's collective memory is a great way to enforce
> such a requirement -- we can and have in the past slipped up and published
> RFCs that are inconsistent with requirements imposed by previous ones.

True.  We have created a file to store this kind of memory. I added your quote there, please see:

https://github.com/roll-wg/RPLv2/blob/main/README.md

I've been thinking about it so more but cannot find a better answer...

Many thanks!

Pascal

> 
> On Tue, Nov 10, 2020 at 08:15:33AM +0000, Pascal Thubert (pthubert) wrote:
> > 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.
> 
> Yes.
> 
> > 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.
> 
> Not a MOP at all, or not a "normal" MOP that behaves like 0..6?
> 
> > 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.
> 
> Yes, we are saying "if you see a MOP field that is all ones, do this".  To me,
> that seems like we want to be listed as an additional reference for MOP value
> 7 in the IANA registry.
> 
> > 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.
> 
> It will stay true forever (until amended), but how does a new person making
> an implementation know to find this document and do so?  [useofrplinfo] says
> that MOP value 7 is special and needs dedicated handling, but it doesn't say
> anything about using 8138 [on links where 6LoWPAN Header Compression
> applies].  I'm missing the trail of breadcrumbs.
> 
> Thanks,
> 
> Ben
> 
> > 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-2
> > > > 1.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.