Re: [6tisch] Alvaro Retana's Discuss on draft-ietf-6tisch-enrollment-enhanced-beacon-13: (with DISCUSS and COMMENT)

Alvaro Retana <> Tue, 25 February 2020 17:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F8E73A1091; Tue, 25 Feb 2020 09:01:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0kX1DagQmSCD; Tue, 25 Feb 2020 09:01:50 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 04F593A108F; Tue, 25 Feb 2020 09:01:49 -0800 (PST)
Received: by with SMTP id g19so171534eds.11; Tue, 25 Feb 2020 09:01:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=YOBEL1VY19NnL/hRTRBqP9bY88Cx48iuP5cbTIzHQgM=; b=gnQSfoq0DecBZqPAfiSeMbqEQLSz3Fq79YBqBwQwutsmdKVFfhHPPDh+EGJHpCFbX4 Bv1sIuRXKnZjuqAEbYg0P8SneBYl9JE25ZG8x873Hh5YZ6cBVyuA5smbS5cDXGqfpnLv YDwMT0dPE96/Evoc/4DqbMo+jvgVsJxpnvL0bKbJnGBFowV0tOwr03ahghLwuSL02cLa A4JZYlSFT92FapIDLzKpaQmrjNm/4h0wswPCn0kdXkgST2FwKoLTTdLjm7HJap3OM3FG x8I3mZ1PD8qf+YywspCCs4ro8rLrvUl96epj65h0/DPbZszj4jY7OLKa8RHJDa03noQe Ozzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=YOBEL1VY19NnL/hRTRBqP9bY88Cx48iuP5cbTIzHQgM=; b=qn9w7IbFubtVI7W031Qedzk6l/R+jSPN76nkkGWGJm6Bd7spvU/Z/6ZZtUjwCxZybR 4+0XyZSwo+T79nSNe/Zh2vSm/rJZvDMcmljRT9wYJ5xLUQCgwMz8Av2DFOzIsCieA6q7 jToowMgFhitZFzJlblAawuzQTNSa/eKgAmC2eU70HC4EeN1W5Ahnnvko6dAm1N2EBzLW +eHo8USpLayvueipuf2vdXM9j5Mc0+sZCHn7RydduQodhjEei+1fwhzoN+fsCwtEobyO NpauhliMGgfKKU3O72ZGNLAEQp4Hnj1pVROI0lzubQlBL2HIpxGrI91GStTg7lNPNvW7 nOFA==
X-Gm-Message-State: APjAAAUfwcPP6RijqEy4AZ6MG8mk7N8kNNzEcwDRfgi4XWI2K9XEWo/i 17LogVUGlr2QOG3f0jB+10k/YLAWraY0leHuNNAhSo8K
X-Google-Smtp-Source: APXvYqxuXYbTmb70gf3l5nkza5FNzkpWhNqJfw/Zyq/eeAg5GxYW6F5zOgq7KOCv3LFMpZoYc1NGaduzgZE76mceR50=
X-Received: by 2002:a50:f396:: with SMTP id g22mr54020724edm.336.1582650108369; Tue, 25 Feb 2020 09:01:48 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Tue, 25 Feb 2020 09:01:47 -0800
From: Alvaro Retana <>
In-Reply-To: <27353.1582493020@localhost>
References: <> <29710.1582208163@dooku> <> <20565.1582316488@dooku> <> <27353.1582493020@localhost>
MIME-Version: 1.0
Date: Tue, 25 Feb 2020 09:01:47 -0800
Message-ID: <>
To: Michael Richardson <>
Cc:, Pascal Thubert <>, The IESG <>,,
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [6tisch] Alvaro Retana's Discuss on draft-ietf-6tisch-enrollment-enhanced-beacon-13: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Feb 2020 17:01:52 -0000

On February 23, 2020 at 4:23:42 PM, Michael Richardson wrote:
> Alvaro Retana wrote:
> > Interpreting and acting on the values is exactly the piece I have a
> > problem with. The rank priority is an "indication of how willing this
> > 6LR is to serve as an RPL [RFC6550] parent". How is the receiver
> > expected to that the value into account for parent selection? That
> > part is not specified. The same for the pan priority; the text says
> > that a receiver "MAY consider this value when looking for an eligible
> > parent device",
> The intention is not to change the parent selection algorithm at all.
> The intention is to help the *PAN* selection algorithm by giving a hint as to
> what kind of parents are available on a particular PAN.
> Once the PAN has been joined (which may involve an additional onboard process
> to get a 2-byte address and local keys, or might just mean pulling some keys
> out of NVRAM, and synchrozing to the schedule), then the node can receive
> DIOs (possibly from many other possible parents), and run the normal parent
> selection algorithm.
> But, it can't see multiple PANs.

The slides help a lot and now I understand! :-)

It would be great if the text reflected more what the slides say, but
given the background, I think that what you added in -14 is good
enough...and in any case it doesn't justifies keeping my DISCUSS, so
I'm clearing.