Re: [Roll] Agenda for Monday (Re: MOP==7 live discussion )

Ines Robles <mariainesrobles@googlemail.com> Mon, 21 September 2020 13:40 UTC

Return-Path: <mariainesrobles@googlemail.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 4DC963A0F52 for <roll@ietfa.amsl.com>; Mon, 21 Sep 2020 06:40:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.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 Zcik-7X6e2ai for <roll@ietfa.amsl.com>; Mon, 21 Sep 2020 06:40:34 -0700 (PDT)
Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA7A3A0F38 for <roll@ietf.org>; Mon, 21 Sep 2020 06:40:33 -0700 (PDT)
Received: by mail-ua1-x92f.google.com with SMTP id q26so4306120uaa.12 for <roll@ietf.org>; Mon, 21 Sep 2020 06:40:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pdyxBfD4lJI26sJNZYTfN+X/DTXiE3K9R/3bEzCTSlU=; b=sM1n4un5Y+psPi4lCEB+KQOfBOA1kdwFeabi0XFM6aMXME5KS/TFXhj5szD2V/jalx kR9S33eZ51nZ0SUnenc9+990Zu0i2O+mENliQenilbM7K8FWaIeoJlqS25Ek6f//SPEr 5n+/VUo4H+B1LZdWMpymjLpQE5Q+v3WG1Drzy+Zi8uA/vaXmpWOuCkYXNcvM6Jn23xdL rl5DvjtlWbuVF4w9amQjOvXG2FjzjZDV83gNjHzvXJS/2/Cl5gklwPgYxmjRWnG2ZuJn Fz05z6v+VzPLoY6hM9QMAKIUJc6sSvkTlF4xJnScSh6x1jLIgPaXgvbpkcgoG52WDOOQ bBzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pdyxBfD4lJI26sJNZYTfN+X/DTXiE3K9R/3bEzCTSlU=; b=jqw6Hx68aY+lwbdL3kYBYyWgOVVehepPb1Q2naTDXqxYk+q8hjstwummZEDgiKDrYo IyODuD5Q57teg/BSe/Isd0cEcjUTAt0weM8htUNiM9rZ+CSmAVhFoLyEgNEPI3MX2EO5 hmoinQVMN8J/CzVHZ+CNheYNav1gYsKKADRmGLPeFBi1M0kqCuDaeNaRh7UJoMs8OIBw dXoCPRv95bGNB/J6ojEV61lqik0jE9TZscSvI/Ysq3B6/IjvcFfQ7Wr35l+VuJwjMALx zxSGdlW2quFPCmgejOPv7xDtFkPZDA6gsqIQMl+fBxju23vSUzBmEZjU9XUcV9s4NTzD 5rIQ==
X-Gm-Message-State: AOAM53212jmrR5rzV1fqXe+8NWAiJzI5YkYSGVL3Cyp3DY07ZklhpdUE 7h3vYkDjaH+YsU9zZsvRqazuCWSGVj8LIjY10Q4=
X-Google-Smtp-Source: ABdhPJyMydKJGuIyrF117g+n+tfhHiD2ftpoH+mjf537/9dHTnVAhF9l8YEBOCPeVVsXDqEEAOAWqQihnorreoKR4oA=
X-Received: by 2002:ab0:1d99:: with SMTP id l25mr46197uak.56.1600695632321; Mon, 21 Sep 2020 06:40:32 -0700 (PDT)
MIME-Version: 1.0
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> <MN2PR11MB3565F2602A0DC55DE9FF3604D83F0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAMMESswYqh_XdHMkQRCzKrJAdj_iH1DOuz7qy+RFiECUwK6OnQ@mail.gmail.com> <117301.1600480771@dooku> <CAP+sJUcGQQE4WJfJe56p8dGH2_W80KY=5bHsGzQeTOLEazKxXA@mail.gmail.com> <9778D10D-91FE-496B-B679-8A3E8B7B5300@cisco.com> <15752.1600553316@localhost> <5049.1600648267@localhost> <BYAPR11MB355839686C4B2CB0BF17CC21D83A0@BYAPR11MB3558.namprd11.prod.outlook.com> <CAMMESszWt=ttrCU9yEc521juN0zHpTKRJ9XgrkJ_N6q2xNcT5w@mail.gmail.com> <MN2PR11MB35651358934EA53BC829816FD83A0@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB35651358934EA53BC829816FD83A0@MN2PR11MB3565.namprd11.prod.outlook.com>
From: Ines Robles <mariainesrobles@googlemail.com>
Date: Mon, 21 Sep 2020 16:39:56 +0300
Message-ID: <CAP+sJUdZcF_CMf7aQMMx6_zgkONeF6tSd1VHO7nbm8UCsk9v1Q@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: Alvaro Retana <aretana.ietf@gmail.com>, "roll@ietf.org" <roll@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>
Content-Type: multipart/alternative; boundary="0000000000008edfad05afd2fe39"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/beAbUOxWZOhx5dLcIgj7WvTuGWM>
Subject: Re: [Roll] Agenda for Monday (Re: MOP==7 live discussion )
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, 21 Sep 2020 13:40:43 -0000

Hi,

Questions tracked here: https://codimd.ietf.org/roll_MOP_20200921?both

The 2 hours are reserved just in case, I hope everything is solved before
the 2 hours :)

br, Ines




On Mon, Sep 21, 2020 at 4:34 PM Pascal Thubert (pthubert) <
pthubert@cisco.com> wrote:

> Hello Alvaro,
>
>
>
> I cannot believe we’ll need 2 hours. But certainly we can start with the
> high level discussions on how this impacts the 3 drafts, before we dive in
> how to treat RFC 8138 with MOP 7.
>
>
>
> Take care,
>
>
>
> Pascal
>
>
>
> *From:* Alvaro Retana <aretana.ietf@gmail.com>
> *Sent:* lundi 21 septembre 2020 14:51
> *To:* Pascal Thubert (pthubert) <pthubert@cisco.com>om>; roll@ietf.org;
> Michael Richardson <mcr+ietf@sandelman.ca>ca>; Ines Robles <
> mariainesrobles@googlemail.com>
> *Subject:* RE: Agenda for Monday (Re: MOP==7 live discussion )
>
>
>
> Hi!
>
>
>
> I can’t stay the whole 2 hours…so I want to bash the agenda to add another
> question at the top.
>
>
>
> () Should the MOP 7 Updates to rfc6550 be part of the turnon,
> unaware-leaves, useofrplinfo drafts?  I believe the answer is no, and I
> would like to make the case on the call.
>
>
>
>
>
> BTW, on (3), unaware-leaves says that the RUL is not expected to support
> rfc8138.   Not expected is not the same as saying that they never will send
> compressed data…
>
>
>
> Thanks!
>
>
>
> Alvaro.
>
>
>
> On September 21, 2020 at 7:22:26 AM, Pascal Thubert (pthubert) (
> pthubert@cisco.com) wrote:
>
> All very good questions, Michael,
>
> And it seems that we are converging.
>
> I read the quasi-suggestion that we align the default for MOP 7 to whether
> 6LoWPAN HC is running on the medium? Looks good.
>
> I have one last question, how does this discussion impact useofrpl and
> unaware-leaves, since they both define flags in the RPL DODAG config
> option. Should we converge the language? Do they all update RPL?
>
> Talk to you all in a few hours,
>
> Pascal
>
> > -----Original Message-----
> > From: Michael Richardson <mcr+ietf@sandelman.ca>
> > Sent: lundi 21 septembre 2020 02:31
> > To: Pascal Thubert (pthubert) <pthubert@cisco.com>om>; roll@ietf.org; Ines
> > Robles <mariainesrobles@googlemail.com>om>; Alvaro Retana
> > <aretana.ietf@gmail.com>
> > Subject: Agenda for Monday (Re: MOP==7 live discussion )
> >
> >
> > okay, here is my summary of the issues that are outstanding for
> roll-turnon-
> > rfc8138.
> > I am writing this in the hope that I've captured everything.
> >
> > 1) Will RFC8138 be enabled for MOP==7? For what media?
> > I see that my notion that it should be undefined is not reasonable, and
> I
> > step back from this.
> >
> > 2) In what way does the format of the DIO Base Object depend upon the
> MOP
> > value? It seems that we need to update 6550 to say something.
> >
> > 3) While RUL document mandates that RULs must support 8138, it is not
> > clear to me if RULs can operate in a pre-8138 network. What if they
> > send 8138 compression?
> > It may be that none of the compressions that 8138 creates
> > will ever be emitted by a RUL, since they are all about IPIP compression
> > and RH3 compression, but I haven't checked.
> >
> > 4) we seem to be fine for 802.15.4 networks of all sorts.
> > I suspect that we are okay for all the other layers (BTLE, DECT, BACnet)
> > that leverage rfc4944 through the various upgrades. But, we are sure?
> > What happens on devices with multiple interfaces of different types?
> > Maybe this is an RFC8138 issue really.
> >
> >
> >
> > --
> > Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting
> )
> > Sandelman Software Works Inc, Ottawa and Worldwide
> >
> >
> >
>
>