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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 18 September 2020 14: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 20B9F3A09BE; Fri, 18 Sep 2020 07:15:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.62
X-Spam-Level:
X-Spam-Status: No, score=-9.62 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=kwSz4H1J; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=EJgCU4oo
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 4V5WgzmLai27; Fri, 18 Sep 2020 07:15:25 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82DF3A0991; Fri, 18 Sep 2020 07:15:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5318; q=dns/txt; s=iport; t=1600438524; x=1601648124; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kqBierMOggQ337vbPooRJ+nQlMDR2ctCEm/5HTwy3ho=; b=kwSz4H1Jo2pRPoRvXs4wpHK9roK4Sfmi+1FwkzgvsmuReqxej7Y/AWZ9 pyMXkJ6fNQIGahTbPrj1dLWNNOrNNi+5o3Ay4upJ0I15BuxL91owvgC+I FvlD1rkeaRiZalPjwBAh7Ak4PswDDxpsFUer/5rBZgW9GL+2aIPJA0Fh7 M=;
X-IPAS-Result: =?us-ascii?q?A0CqAQCMwGRf/4cNJK1fDgwBAQEBAQEBAQEBAwEBAQESA?= =?us-ascii?q?QEBAQICAQEBAUCBT4FSUQeBSS8shDmDRgONdoECgWuHIY5mglMDVQsBAQENA?= =?us-ascii?q?QEtAgQBAYFWgnUCF4IUAiQ4EwIDAQEBAwIDAQEBAQUBAQECAQYEbYVcDIVyA?= =?us-ascii?q?QEBBBIRBA0MAQE3AQsEAgEIEQQBAQECAh8HAgICMBMCCAgCBAENBQgahVADL?= =?us-ascii?q?gGqdQKBOYhhdn8zgwEBAQWFJQ0LghAJgQ4qgnGCXEtCS4F2BoQLG4FBP4ERQ?= =?us-ascii?q?4IYNT6CGoIFIIMVM4ItjSMJgxWCNDyjLlEKgmeVSoUjgwyJeoU4jkSSeo1Lj?= =?us-ascii?q?gWELAIEAgQFAg4BAQWBayOBV3AVgyRQFwINjh8MFxSDOooYPnQ3AgYBCQEBA?= =?us-ascii?q?wl8jWMBAQ?=
IronPort-PHdr: =?us-ascii?q?9a23=3ASkqgZBaOfniazMrtzxsM1DT/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaRD4Da97RJh/eF+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGHcfiIVDevy764TsbAB?= =?us-ascii?q?6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw=3D=?= =?us-ascii?q?3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.77,274,1596499200"; d="scan'208";a="536288468"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Sep 2020 14:15:23 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 08IEFN3q005418 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 18 Sep 2020 14:15:23 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 18 Sep 2020 09:15:23 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 18 Sep 2020 09:15:23 -0500
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 18 Sep 2020 09:15:22 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=U/1cG8c7fa+pqbX3V1xW9LnQVnZPvCH2BWceAqpZCKOCglcHDv4hnD6inSHBah3o2+TdOsPzhQdFU8HWawrlb+zcggJvKlP7DQiYIR/PYZoBNQkTYl1jnbbQAgJ4t4CXhd3ybMMI62EOF36HTa2PT+YKvwBfBP+DOabLS4Pfia5FeWm3MfNK8C8vIGa2vbfLX5K1iGrkDQZiDUmoP5NxXhKwSKlQ5F/QBi28nopM9yu6Phvw+bRR7uKrgHwt3DAsn6WypDiodB6kCXmfO4FArf1G2F91t1ueZZzRQTAcWefcYOCWCsc5c61Iv+afKWmFdXQCmj0LXc8/2CVwKSgkGQ==
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=kqBierMOggQ337vbPooRJ+nQlMDR2ctCEm/5HTwy3ho=; b=RSAppAHaNCBictoPW7R70xQ494pXj8F1YnjJayvL0tbIc++I6B4HcqXX233kd6u9uABTbVxSYaanroI8g5pPqne46Lr9XygdjMp3D7fe4vioyuwIyZOeatccAVVanmIHWglHmelFb+/GSck49nhspV/7lJaQdiWrgssQRJ6M0RXn5vmlj3XRZ/UIlVBnwRuTLWK/jUGKvz0U1zBoPA4Apw704oOnfLj/c4UfyNVCik0/WPGpxNdOhXh1og04LfCU8hZwfXO2cSwFGR2Sr+aGD8lYPRf/2Ogm3sLQ+6FEMmTRVxFPPe1oGEovbSzt38gDLK3dH2TUrm1DpK1baOohnw==
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=kqBierMOggQ337vbPooRJ+nQlMDR2ctCEm/5HTwy3ho=; b=EJgCU4ooHNmlMhYEZDRCxzAe/Kf0Iv04wYuNa2hRZhbNGI/X9bmtMmt3mUZvhJqrWp9lpZEycA8Y8KtWF+gALVHGvitKELD2g+mEKhqIy7fNubx0myMqCZ4eCi99KM8iX0mpiTiu83gKvUk2q0mar9Nz9igYcMkeA/B2Tn4QKo0=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB3936.namprd11.prod.outlook.com (2603:10b6:208:13f::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.19; Fri, 18 Sep 2020 14:15:21 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::119:f851:5860:da95]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::119:f851:5860:da95%4]) with mapi id 15.20.3370.019; Fri, 18 Sep 2020 14:15:21 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Benjamin Kaduk <kaduk@mit.edu>, Alvaro Retana <aretana.ietf@gmail.com>
CC: Michael Richardson <mcr+ietf@sandelman.ca>, "Routing Over Low power and Lossy networks" <roll@ietf.org>, "roll-chairs@ietf.org" <roll-chairs@ietf.org>, Alvaro Retana <aretana.ietf@yahoo.com>, Ines Robles <mariainesrobles@googlemail.com>, "draft-ietf-roll-turnon-rfc8138@ietf.org" <draft-ietf-roll-turnon-rfc8138@ietf.org>, The IESG <iesg@ietf.org>
Thread-Topic: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT)
Thread-Index: AQHWhvbDFnz+ZxCN2kqfSLm4/QQEM6lhafFggADkOACAAVPGAIAAAK+AgAAvlRyACqqkkA==
Date: Fri, 18 Sep 2020 14:15:21 +0000
Deferred-Delivery: Fri, 18 Sep 2020 14:14:45 +0000
Message-ID: <MN2PR11MB3565F2602A0DC55DE9FF3604D83F0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <159968972884.1065.3876077471852624744@ietfa.amsl.com> <MN2PR11MB35659A0710E687A7C9995E6ED8270@MN2PR11MB3565.namprd11.prod.outlook.com> <20200910200744.GE89563@kduck.mit.edu> <17053.1599841430@localhost>,<20200911162617.GQ89563@kduck.mit.edu> <8F19C753-DCA0-4A32-BA3B-A124B2F7F745@cisco.com>
In-Reply-To: <8F19C753-DCA0-4A32-BA3B-A124B2F7F745@cisco.com>
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:6192:af3d:a5cb:aa13]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d21378ef-1271-45ae-a1da-08d85bdd4788
x-ms-traffictypediagnostic: MN2PR11MB3936:
x-microsoft-antispam-prvs: <MN2PR11MB3936581BE0761B01031A6DCDD83F0@MN2PR11MB3936.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: HVFzvWy8VLlc9uO7UM39c3/wBN7ZXXWYURPx/jn+5Afd/m7LfDW1YzCzEJSV55F8NBQFBm3q3U13zqeYtdTxLy7CeIsZhM12Io1ib/sJJBLqHDQkMZnhnmbtT4h4EDUrYcVmTci7xd2JHv64oCTtiRzoYPb33eJhNerxklle5wZ3ooSuXtM2NfQFckHbYecsk3s/+4IT1U03msK1Pgk9ADLpX86IgBvBA1f5zMBb9y1QMH7ODOiUvw+++OEsDzsXRj1veEbqnaA13ZGLpxKAfvSzob9J51R5oe8eqgJbwVUoOHkCyK0SH0hSNB1W+f6tXV8mg/ZaVIEXE5ZYNuq/uw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB3565.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(39860400002)(136003)(376002)(396003)(346002)(5660300002)(8676002)(54906003)(52536014)(316002)(8936002)(110136005)(478600001)(66946007)(76116006)(64756008)(66476007)(66556008)(6506007)(4326008)(66446008)(53546011)(71200400001)(7696005)(186003)(83380400001)(2906002)(55016002)(86362001)(9686003)(66574015)(33656002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: lXc8gN2OjLrh9kybEyFhfg0poJ3y24+L0HwtIKBavGXsHSJ6EWAo1D975EKQNRPi74Ql/Omf0Iq4cEKQv8OL6/XJHlIZmW+8JTy7W7yKWDEkRR0CP7g6PqGTFvmDP+VAYg1EJZrZsmqi0zLjwLkPTnxMgJpAhY26k/AAka6XfAXQFzc16uUvrlpjdcxOWhFPoOwSDBZsOesOc839EEbdUoDNh1HsKL19AcRC0DWxyANwXQ3Xo2H1OMV6l9ZjrWMyX1VfJe9Pizyq9l3O2tiAI2Jm0VzyYS2ZZDB+WskixWntKPmJWxZOuw04CzGNPEoabIk8/Yn8xas1Fs3GBICJdbDx5/F9mdq2ymnHee5diPiGkJOXvZLrfQuYNaRQD6j3O3abusL+6VGFnPNSEdV5DdXLvw37SfPiYcJoCMis6W1DOYr0OWB5YNfUMyVlzVxiUoDG2woCkzp0GJ+MuJfWNqYbYymxhrIX5NY8tKowNmvsAhxtTZ3RJq4Uoa+Lt6xgl+5KWRMBnXmzfNB4rev/5JIlmlFV/CUzVu8Uq/c+hBGIfdU0+GYEh3IgwFSMODRPqbXKLG39snAVWv7Fy6i3aNgGPfzsQ4Pknn4pJRXHyhmutIe8YyWfwuyFzAqAHrYeT/QMZTwE3tTh9LjhPFUltHQeWnn45t6T4AlLWSI/HIHzKow7Z7RvA4UkN449NhFJ1/qPUDQ8MagMHolY8sUL5g==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB3565.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d21378ef-1271-45ae-a1da-08d85bdd4788
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2020 14:15:21.8022 (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: JwxXr6OseV5lWKTwGKak5hTngyLokZrj3dbF2+uKzYGGmqhzNvC/DlP07G4KM/DdN1+tb9GGDu3trUruwiJjHA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3936
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/o1a00vf7mMCLC7aeCK7NqbAxC_g>
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: Fri, 18 Sep 2020 14:15:27 -0000

Hello Benjamin and Alvaro

I published the latest to have a fresh reference point.

There seems to be an agreement that 
1) we need to tell the implementer what to do when MOP ==7
2) The changes are updating RFC 6550 formally.

This is reflected in draft 15 as published.

Please let me know if I mossed something!

Take care,

Pascal

Pascal

> -----Original Message-----
> From: Pascal Thubert (pthubert)
> Sent: vendredi 11 septembre 2020 21:17
> To: Benjamin Kaduk <kaduk@mit.edu>
> Cc: Michael Richardson <mcr+ietf@sandelman.ca>ca>; Routing Over Low power
> and Lossy networks <roll@ietf.org>rg>; roll-chairs@ietf.org; Alvaro Retana
> <aretana.ietf@yahoo.com>om>; Ines Robles <mariainesrobles@googlemail.com>om>;
> draft-ietf-roll-turnon-rfc8138@ietf.org; The IESG <iesg@ietf.org>
> Subject: Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-
> 14: (with DISCUSS and COMMENT)
> 
> Now I’m unsure Michael and I agree anymore.
> 
> What will today’s developer code?
> 
> We ask him to test if mop is < 7
> 
> What value will the developer place in his code if the test returns false?
> 
> If there is no code the Boolean will be uninitialized and the result will depend
> on the type of variable and the compiler.
> 
> Whatever the developer does the code will end up having a behavior,
> compression or not.
> 
>  Leaving it to the implementation will have some people choose true and
> others false. This is not what we want.
> 
> We want to control what the code does so we can expect it in the future and
> build our backward compatibility based on that sure knowledge.
> 
> Before the draft the default was no compression. Quite naturally since initially
> it did not exist.
> 
> Also we discussed on the ML that for RPLv2 all implementations MUST support
> the compression.
> 
> In which case it is a better default for a coder today to decide to use the
> compression for mop 7, isn’t it?
> 
> I hope I make the case right. Just think you’re coding it!
> 
> Take care,
> 
> Pascal
> 
> > Le 11 sept. 2020 à 18:26, Benjamin Kaduk <kaduk@mit.edu> a écrit :
> >
> > On Fri, Sep 11, 2020 at 12:23:50PM -0400, Michael Richardson wrote:
> >>
> >> Benjamin Kaduk <kaduk@mit.edu> wrote:
> >>> to MOPs 0..6; but the situation for MOP 7 seems slightly different.
> >>> If we were *just* leaving the bit undefined/free for reuse in that
> >>> situation, that is probably also something that we can do in a
> >>> normal "allocate a bit from an IANA registry" document without need for
> Updates.
> >>
> >> Up to here, we agree.
> >>
> >>> But that's not
> >>> all we're doing; we're also saying that if you see MOP==7, then you
> >>> have to use the 8138
> >>> header/compression/whatever-we-end-up-calling-it.  Yet we are
> >>> *not* allocating MOP==7.
> >>
> >> Tthat's exactly what we don't want to do.
> >>
> >> We are saying NOTHING about rfc8138 when MOP==7.
> >> Nor are we saying that the T-bit exists (or doesn't exist).
> >
> > That's not how I read:
> >
> >       For a MOP value of 7, the compression MUST be used by default
> >   regardless of the setting of the "T" flag.
> >
> >
> >> What behaviour is default and what behaviour is negotiated, and how
> >> it it negotiated, and how the results are turned on, would be up to a
> >> document that specifies MOP=7 (or larger mopex)
> >
> > What you describe here is more along the lines of what I expected.
> >
> > -Ben
> >
> >> As an analogy, when we did the ToS->DSCP + bits-that-became-ECN
> >> change, we did this for IP_version==4 and IP_version==6.
> >> We specifically did not change it for IP_version==7 or 8.
> >>
> >> --
> >> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
> >>           Sandelman Software Works Inc, Ottawa and Worldwide
> >>
> >
> >