IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 21 September 2020 00:31 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 3CEE13A107F for <roll@ietfa.amsl.com>; Sun, 20 Sep 2020 17:31:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 6vMHUjreZcYt for <roll@ietfa.amsl.com>; Sun, 20 Sep 2020 17:31:24 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 841A23A107D for <roll@ietf.org>; Sun, 20 Sep 2020 17:31:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id D877A389B7; Sun, 20 Sep 2020 20:09:50 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8N7RsaEuZTcY; Sun, 20 Sep 2020 20:09:46 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 859A53899B; Sun, 20 Sep 2020 20:09:46 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 208ED721; Sun, 20 Sep 2020 20:31:07 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
to: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, roll@ietf.org, Ines Robles <mariainesrobles@googlemail.com>, Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <15752.1600553316@localhost>
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>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sun, 20 Sep 2020 20:31:07 -0400
Message-ID: <5049.1600648267@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/OVY0co-O8-Ln5X8IW7wxuBszjk8>
Subject: [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 00:31:26 -0000

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

v2.23.0 | Report a Bug | By Email