Re: [Roll] Benjamin Kaduk's No Objection on draft-ietf-roll-unaware-leaves-26: (with COMMENT)

Alvaro Retana <aretana.ietf@gmail.com> Thu, 17 December 2020 20:09 UTC

Return-Path: <aretana.ietf@gmail.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 E9CA53A0FC7; Thu, 17 Dec 2020 12:09:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, UNPARSEABLE_RELAY=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=gmail.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 V_PpsX_a_Jil; Thu, 17 Dec 2020 12:09:33 -0800 (PST)
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 244DA3A0FBF; Thu, 17 Dec 2020 12:09:33 -0800 (PST)
Received: by mail-ej1-x633.google.com with SMTP id d17so39738561ejy.9; Thu, 17 Dec 2020 12:09:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=f/ZS7+qCvfk+d3yQGfQv03/zl3MnVxef+1Ygn0jX0MA=; b=eBzObY+Xr/k3yFvEXO9yI8zBf2x5PVpTaYmxCOY44EwIVdp9SyzIpzf1aNoRGyWM6Z /opujfnldHAIK8Z0Kh1DDlmFRammCpqjfKafCv/5qciNvZ7waBrht/eaP2TKztsQqTdo /Xqb3TtkU4f2M0RnJfS2barXWFhG2kKnLfDmBx34aT4nE45oXyulDBbe78qoo499Zy8+ fp+bjgDnRqOqgxC+gz937I2NgqUYYejBFMGc0dpoPlR73fdZ+cdFyEJAWrFj2FNshPbp Szvkvlj36y3k4A+FaVEx8KONC7tPFYBFI+ZgTW1fLF7nM39h24EYnDuQiflgMYQpnfE2 cB/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=f/ZS7+qCvfk+d3yQGfQv03/zl3MnVxef+1Ygn0jX0MA=; b=b1K6MeXbOAz5ca3mx9uUzeq6l4DtPyKqpL5kRKjICAvcCyOiCgObtRbtwdZCqE99T4 BM062PJDJvicyTKlrHUCHOrX7KM6hRuDQSXlaXS87L/DL0pVvA5+HVy/vO1me3sl2RdW qn4Cx6IoNlRLd3a+OXobHyIp8cnYcBvgfdRfJUT+S7mJGfDNgqoWXjI5mhaQx3FPvu1J BkRELPhqKVOQkDM0GLXA+McRj5sQ/ZNm3DPb4Lln16GeNK9ODFLciayVc9q/IM6c/4bd +OAtkmb/v5cfFM4PZdwzv29kHP2vKPCXlE4XG5sPAgEDamCDQDT67yRYf9LPi+vdVwk0 wa9A==
X-Gm-Message-State: AOAM5318Ol026gsRku4qGIoQqzLSadt5n1zQSsl9lnPCiCr92rDODf9p c71iP/5RbDpgUK+RJbo4+nvruj+zNEAquQsWIs1bwor7
X-Google-Smtp-Source: ABdhPJxayLRifrHW1I6xpNELOm5oj0u4y2CE2Wigndc0DeFD0iyf5pTAEA2aGiWgnVPHxyjCMxwInP1GW+6HZZu7Lvk=
X-Received: by 2002:a17:907:3f93:: with SMTP id hr19mr700357ejc.235.1608235771375; Thu, 17 Dec 2020 12:09:31 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 17 Dec 2020 15:09:30 -0500
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <16278.1608234508@localhost>
References: <160819432500.25662.694953130654522537@ietfa.amsl.com> <CO1PR11MB4881AF374C813CDD9850756AD8C40@CO1PR11MB4881.namprd11.prod.outlook.com> <16278.1608234508@localhost>
MIME-Version: 1.0
Date: Thu, 17 Dec 2020 15:09:30 -0500
Message-ID: <CAMMESsy5ZHgGw__MT015L1bQvpCf=CtvB1JEb2mq5=ipP9P_HQ@mail.gmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>
Cc: "draft-ietf-roll-unaware-leaves@ietf.org" <draft-ietf-roll-unaware-leaves@ietf.org>, "roll-chairs@ietf.org" <roll-chairs@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000de35d505b6ae91ff"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/FTK8SBUWeXoCREoNcrKD1hm41lo>
Subject: Re: [Roll] Benjamin Kaduk's No Objection on draft-ietf-roll-unaware-leaves-26: (with 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: Thu, 17 Dec 2020 20:09:35 -0000

Hi!

FWIW, I don’t have a problem with listing all as references in the
registry.  We just need to remember to do it if there’s another draft that
does something similar, which we probably will when we go back to look at
the registry.


To do it can be as simple as requesting IANA to add additional references
to MOP 7 in the registry.

Alvaro.

On December 17, 2020 at 2:48:41 PM, Michael Richardson (
mcr+ietf@sandelman.ca) wrote:


About how to mark MOP=7

Pascal Thubert \(pthubert\) <pthubert=40cisco.com@dmarc.ietf.org> wrote:
> I have (plenty of) coffee, it's early afternoon, I had (almost) no red
> wine at lunch... I'm ready for your review comments : ) : )

I'm thinking that there is a market for caffeinated red wine.
Maybe that's already covered by Redbull+Vodka for some.

bk> I still feel that if we're going to incrementally add new properties to
MOP 7, we
bk> should list the relevant documents as references in the registry until
MOP 7 is
bk> fully specified. In this case we can arguably get away with not doing
so since this
bk> document Updates: RFC 6550 already and thus could be said to be doing
the
bk> reservation by modification of the core protocol, but we are not using
that
bk> procedure universally (e.g., for turnon-rfc8138) and it seems prudent
to use a
bk> consistent mechanism.

> Yes, we have a github page for that, see
> https://github.com/roll-wg/RPLv2; I added your concern above in there.

But, Ben is suggested that turnon-rfc8138, unaware-leaves and useofrpinfo
should all be listed under IANA MOP=7 until we actually publish RFC6550
and/or mopex/capex.

Ben, I hadn't thought of that, and I like it.
How do we do this?