Re: [Roll] I-D Action: draft-ietf-roll-nsa-extension-02.txt

"Georgios Z. Papadopoulos" <georgios.papadopoulos@imt-atlantique.fr> Mon, 01 July 2019 15:51 UTC

Return-Path: <georgios.papadopoulos@imt-atlantique.fr>
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 C6795120356 for <roll@ietfa.amsl.com>; Mon, 1 Jul 2019 08:51:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=imt-atlantique.fr
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 rVwiGxWx3-JC for <roll@ietfa.amsl.com>; Mon, 1 Jul 2019 08:51:43 -0700 (PDT)
Received: from zproxy130.enst.fr (zproxy130.enst.fr [137.194.2.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FCA0120344 for <roll@ietf.org>; Mon, 1 Jul 2019 08:51:43 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by zproxy130.enst.fr (Postfix) with ESMTP id 0C1F01208EF; Mon, 1 Jul 2019 17:51:42 +0200 (CEST)
Received: from zproxy130.enst.fr ([IPv6:::1]) by localhost (zproxy130.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id lLY0Ey-vkfcU; Mon, 1 Jul 2019 17:51:41 +0200 (CEST)
Received: from localhost (localhost [IPv6:::1]) by zproxy130.enst.fr (Postfix) with ESMTP id 21DC21205B5; Mon, 1 Jul 2019 17:51:41 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy130.enst.fr 21DC21205B5
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1561996301; bh=BL/5rXGndEuPOJ9hOtEuMiYjXHG88ohswPWjL77kPWI=; h=Mime-Version:From:Date:Message-Id:To; b=JdNhkvhrtHyO52qDQ0xFn/4UhxBr4mx43RYJ62HiPYTE/uzfjmiRezjh5gsYQeSyG 7VX1Ovuy6IS6vrIc0gzy6KfP/MfwiQFj2i0MSIwv0XLA0u5uDonsMDQKJC8N76l1bl jCxLMv2qBEvTiCs58Nxs90cVMIlvnmJLVXy0u+Vc=
X-Virus-Scanned: amavisd-new at zproxy130.enst.fr
Received: from zproxy130.enst.fr ([IPv6:::1]) by localhost (zproxy130.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id i3c0YOQt_pIN; Mon, 1 Jul 2019 17:51:40 +0200 (CEST)
Received: from [IPv6:2001:660:7301:3728:e0e7:a553:a0a1:5c1] (unknown [IPv6:2001:660:7301:3728:e0e7:a553:a0a1:5c1]) by zproxy130.enst.fr (Postfix) with ESMTPSA id B9431120504; Mon, 1 Jul 2019 17:51:40 +0200 (CEST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_46BE243C-9A83-4390-8811-5A5E8A052288"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: "Georgios Z. Papadopoulos" <georgios.papadopoulos@imt-atlantique.fr>
In-Reply-To: <MN2PR11MB35659CC596E5F23ED47CFC9AD8F90@MN2PR11MB3565.namprd11.prod.outlook.com>
Date: Mon, 01 Jul 2019 17:51:40 +0200
Cc: "dominique.barthel@orange.com" <dominique.barthel@orange.com>, Routing Over Low power and Lossy networks <roll@ietf.org>, Aris <aris@ariskou.com>
Message-Id: <19B2FF84-F99B-40BF-81BF-8788D3478B1C@imt-atlantique.fr>
References: <156139562335.17453.10181644975970552720@ietfa.amsl.com> <CAK76Pr=cOTdAfnxyC9Bq2BPqEzwsH=2LvbZsGuSJjuV6uyvqrQ@mail.gmail.com> <20818_1561994784_5D1A2620_20818_214_5_D93FEF87.62BE1%dominique.barthel@orange.com> <MN2PR11MB35659CC596E5F23ED47CFC9AD8F90@MN2PR11MB3565.namprd11.prod.outlook.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/6Mue53u0bU-a0-hrtcxnwbIgIGM>
Subject: Re: [Roll] I-D Action: draft-ietf-roll-nsa-extension-02.txt
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: Mon, 01 Jul 2019 15:51:57 -0000

Hello Pascal,

Below is the summarized discussion.

Basically, is it good idea to use capitalized "SHOULD”" or lower case “should” when talking about compressing the parent address list.
In the draft we suggest using a implementation similar to SRH-6LoRH for the IPv6 address (which we have implemented in Contiki btw).
However, its similar but not identical to the one in SRH-6LoRH.
Dominique says, if we use capitalized “SHOULD” then it might create problems in the WGLC, if we do not have have an explicit spec.
Thus, in the -3 version we have used lower case "should”.

What do you think?
Georgios and Aris

— — — 

Happy to contribute : )
 
Can someone summarize the discussion?
 
All the best,
 
Pascal


> On Jul 1, 2019, at 17:44, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
> 
> Section 4.2: "Therefore, the PS IPv6 address(es) field SHOULD be compressed using the compression method for Source Routing Header 6LoRH (SRH-6LoRH)". I understand that a similar compression mechanism could be used. However, this requires defining a protocol element that does not exist today, unless I missed something. Therefore, the normative SHOULD is irrelevant. I guess this section is merely suggesting future work. 
> We do have this almost fully implemented (almost: only works in single root RPL instances).
> Would it make sense to spell out the exact specification of the compression even if it is largely a copy of the SRH-6LoRH compression method?
> I can lowercase the SHOULD, but using this kind of compression really makes big difference in practice.

> [DB] talk to Pascal about this, he looks pretty knowledgeable in SHOULDs. Anyway, if you capitalise SHOULD, then you have to explain the consequences of not following the recommendation. Whereas if you lowercase it, it's only free advice. You can stil explain why you think it is a good idea. My worry is that a capitalised SHOULD here will stop the draft later in the IESG processing because you are referring to a non-existent specification (formally speaking). Again, ask Pascal, I totally trust him on this question.