[6tisch] Alvaro Retana's Discuss on draft-ietf-6tisch-enrollment-enhanced-beacon-13: (with DISCUSS and COMMENT)
Alvaro Retana via Datatracker <noreply@ietf.org> Wed, 19 February 2020 23:12 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: 6tisch@ietf.org
Delivered-To: 6tisch@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A811D120957; Wed, 19 Feb 2020 15:12:19 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Alvaro Retana via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-6tisch-enrollment-enhanced-beacon@ietf.org, Pascal Thubert <pthubert@cisco.com>, 6tisch-chairs@ietf.org, 6tisch@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.118.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alvaro Retana <aretana.ietf@gmail.com>
Message-ID: <158215393967.17661.15214952317681663416.idtracker@ietfa.amsl.com>
Date: Wed, 19 Feb 2020 15:12:19 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/rVa-0usT-S8VckCohgoHEHGamMY>
Subject: [6tisch] Alvaro Retana's Discuss on draft-ietf-6tisch-enrollment-enhanced-beacon-13: (with DISCUSS and COMMENT)
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
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" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Feb 2020 23:12:22 -0000
Alvaro Retana has entered the following ballot position for draft-ietf-6tisch-enrollment-enhanced-beacon-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6tisch-enrollment-enhanced-beacon/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I am balloting DISCUSS because the relationship between this document and RPL parent selection is not clear. I expect that the issues I point at will be easy to address, either by clarifying the text or my potential confusion. It is not clear to me what is the "RPL status" of an enrolled node. IOW, is an enrolled node to be considered one that has joined a DODAG already? This is then causing some confusion on how RPL parent selection and the new structure defined here are related. More details/questions below. (1) rank priority What is the relationship between the rank priority and parent selection as described in rfc6550? The text says that "it is to help enrolled devices only to compare different connection points", but no details on the use are provided. The rank priority is described as "an indication of how willing this 6LR is to serve as an RPL {?RFC6550} parent", which points directly at parent selection. The only mention (that I could find) in rfc6550 of an indication of how "willing to act as a parent" a node may be shows up as a guideline when describing the DAO-ACK. The relative values ("Lower values indicate more willing, and higher values indicate less willing.") are aligned, but the size of the fields is different. How, if at all, are these values related? (2) What is the PANID? Is there a relationship with the DODAGID or the RPL Instance? (3) The text says that the pan priority "typically is used by devices which have already enrolled...MAY consider this value when looking for an eligible parent device." As with the rank priority, there are no details about how a node may use this value during parent selection. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- §2 says that the "network ID...[is]...communicated by the RPL Configuration Option payloads". I scanned rfc6550, but couldn't find a place where the network ID is mentioned. Maybe I'm looking in the wrong place -- please point me in the right direction.
- [6tisch] Alvaro Retana's Discuss on draft-ietf-6t… Alvaro Retana via Datatracker
- Re: [6tisch] Alvaro Retana's Discuss on draft-iet… Michael Richardson
- Re: [6tisch] Alvaro Retana's Discuss on draft-iet… Benjamin Kaduk
- Re: [6tisch] Alvaro Retana's Discuss on draft-iet… Alvaro Retana
- Re: [6tisch] Alvaro Retana's Discuss on draft-iet… Michael Richardson
- Re: [6tisch] Alvaro Retana's Discuss on draft-iet… Michael Richardson
- Re: [6tisch] Alvaro Retana's Discuss on draft-iet… Alvaro Retana
- Re: [6tisch] Alvaro Retana's Discuss on draft-iet… Michael Richardson
- Re: [6tisch] Alvaro Retana's Discuss on draft-iet… Alvaro Retana