[Roll] AD Review of draft-ietf-roll-useofrplinfo-41
Alvaro Retana <aretana.ietf@gmail.com> Mon, 09 November 2020 18:57 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 650D83A0C1F; Mon, 9 Nov 2020 10:57:13 -0800 (PST)
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, 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 vvVow1ES4ihS; Mon, 9 Nov 2020 10:57:12 -0800 (PST)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (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 9A4393A0846; Mon, 9 Nov 2020 10:57:11 -0800 (PST)
Received: by mail-ej1-x629.google.com with SMTP id me8so4376552ejb.10; Mon, 09 Nov 2020 10:57:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc :content-transfer-encoding; bh=QbzGuvefxIVdI1bQOgBTaV/PwGjbm7skIRPJPre4BZ0=; b=TBl/yQzWCQtHexTrx1hxizwZolweLK+iRcmt8W2lWyltWUQKFbzoLTKx/xbAt7kj9q YTxaDP6yv4RzWhDPCdtZxACNxhHEg8faPCzroAdRCSxGEM+CCKV2HJRmj5lp20cwdbJe NwqRdgCqtloLCh0dO7h+y2dk761SIIP4gsWeoVxz8ytKzbDUrywuelFg644rA28pdzaR PxrO6cIFoSHnlXitbIoJgy40usJWSKh7jcp6ICVoRfzW2b23LhzOwMOLmYuIzQYlvJfG lfbXShClgkdzQ4j/hxV6T6XE8ULRe1NtKEhCwxe4V5L496QeMSNMJrlq850byBIYcHDi k8Zw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc :content-transfer-encoding; bh=QbzGuvefxIVdI1bQOgBTaV/PwGjbm7skIRPJPre4BZ0=; b=mGhH8qoOPNDxM0blv/zOXPm10ZmieSW0vwgqYjmH+m+Np0Aqn2Zyp9VMbg/CQ9Idko 3xRI4g9CWkhIsIBCfBQHMcPV2ph5rZDLyVSSYkF0hwBEEaYiw71rixWxJPiZt8RA5jPW TDq1FolWBZUmCyaDwRX1RWHFTfD1V7EJFeUWcppGR9CXpvQT2TvVrysjya7DlWuE6/VF NiAFnyCWh+SgJWOZD0WV44MipP81ByDBbh3FjdocGTHYP8xL0ARQvZXEe7B/GD+9AaJx cXtRjqY4qyf4aMkQ1Ih2QSKVgEsmalWe8SddnAKhwNN2yM8Xg7Zqa06Rf4myin9KPOR5 UCZw==
X-Gm-Message-State: AOAM5319AphClgyZV+B1ehX1y8GQ40jeP+csM/Vk54AhzFOKZcNbIcCm uHHd4sHh/aiAhx97ZB/QRVDgIrnGnhaV/VDrvJc8Y3LyPuj3mQ==
X-Google-Smtp-Source: ABdhPJyoDZSTJZs+lzF5ODhGbG+xWsA2T5ds4ZpXPmfSLnirq38EihhJMHf/MIIebVyPVpVzjLqa/bL2ZIeem2XFK5A=
X-Received: by 2002:a17:906:f744:: with SMTP id jp4mr16202354ejb.122.1604948229442; Mon, 09 Nov 2020 10:57:09 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 9 Nov 2020 10:57:08 -0800
From: Alvaro Retana <aretana.ietf@gmail.com>
MIME-Version: 1.0
Date: Mon, 09 Nov 2020 10:57:08 -0800
Message-ID: <CAMMESsw9Ryj+aLmhqYu+NwkdQ11BoWxsEfbAvCr8OBk_DwRUGw@mail.gmail.com>
To: "draft-ietf-roll-useofrplinfo@ietf.org" <draft-ietf-roll-useofrplinfo@ietf.org>
Cc: Peter van der Stok <consultancy@vanderstok.org>, "roll-chairs@ietf.org" <roll-chairs@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/-bVUL_aDX3yVknlbzHbTJHLQn1I>
Subject: [Roll] AD Review of draft-ietf-roll-useofrplinfo-41
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, 09 Nov 2020 18:57:13 -0000
Dear authors: Thank you for all the work on this draft. I have a couple of comments in-line -- nothing hard to address. I mostly looked at the diffs (wrt -31) and so my comments are just on new text. I want to progress this draft with unaware-leaves -- to make it easier on the IESG. I'll start the IETF LC when both are ready. Thanks! Alvaro. >From idnits: ** The abstract seems to contain references ([RFC8138]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. [Line numbers from idnits.] ... 66 4. Updates to RFC6553, RFC6550 and RFC8138 . . . . . . . . . . . 7 67 4.1. Updates to RFC6550: Advertising External Routes with Non- 68 Storing Mode Signaling. . . . . . . . . . . . . . . . . . 7 69 4.2. Updates to RFC6553: Indicating the new RPI Option Type. . 8 70 4.3. Updates to RFC6550: 71 Configuration Options and Mode 72 of Operation . . . . . . . . . . . . . . . . . . . . . . 11 73 4.4. Updates to RFC6550: Indicating the new RPI in the 74 DODAG Configuration option Flag. . . . . . . . . . . . . 12 75 4.5. Updates to RFC8138: Indicating the way to decompress with 76 the new RPI Option Type. . . . . . . . . . . . . . . . . 13 [nit - no action needed, just a suggestion] Group all the updates to rfc6550: either in one sub-section or in consecutive ones. ... 493 4.3. Updates to RFC6550: Configuration Options and Mode of Operation 495 RFC6550 section 6.7.6 describes the DODAG Configuration Option. In 496 this option are a series of Flags in the first octet of the payload. 497 These flags are described by the DODAG Configuration Option Flags 498 registry [dodagcfg], in section 20.14 of RFC6550. 500 Anticipating future work to revise RPL relating to how the LLN and 501 DODAG is configured, this document changes the interpretation of the 502 [dodagcfg] Registry to be limited to Mode-of-Operation (MOP) 503 specific. The MOP is described in [RFC6550] section 6.3.1. The 504 Options Flags Registry is renamed, and applies to MOP values zero (0) 505 to six (6) only, leaving the flags reserved for MOP value seven (7). 507 In addition, this document reserves MOP value 7 for future expansion. [] NEW> Section 6.7.6 of RFC6550 describes the DODAG Configuration Option as containing a series of Flags in the first octet of the payload. Anticipating future work to revise RPL relating to how the LLN and DODAG are configured, this document renames the DODAG Configuration Option Flags registry so that it applies to Mode of Operation (MOP) values zero (0) to six (6) only, leaving the flags unassigned for MOP value seven (7). The MOP is described in [RFC6550] section 6.3.1. In addition, this document reserves MOP value 7 for future expansion. See Sections 11.2 and 11.3. 509 4.4. Updates to RFC6550: Indicating the new RPI in the DODAG 510 Configuration option Flag. ... 529 For a MOP value of 7 or above, the flag MAY indicate something 530 different and MUST NOT be interpreted as "RPI 0x23 enable" unless the 531 specification of the MOP indicates to do so. For a MOP value of 7, a 532 node SHOULD assume that the RPI 0x23 option is enabled. [major] The text in §4.3 says that the flags for MOP 7 are reserved (I'm suggesting unassigned -- but that makes no difference in the context of this comment), but this text seems to want to pre-define what to do with the reserved/unassigned flags. Please take the first sentence out; then MOP 7 is defined it can figure out what to do with the flags. [major] How do you normatively enforce "SHOULD assume"? When is it ok to not do so? IOW, why use SHOULD and not MUST? Suggestion> For a MOP value of 7, a node MUST use the RPI 0x23 option is. ... 691 6. Use cases ... 821 - In the uses cases, we dont assume that the RUL supports IP-in-IP 822 encapsulation. [nit] s/dont/don't ... 993 7.1.3. SM: Example of Flow from Root to RUL ... 1033 IP-in-IP encapsulation MAY be avoided for Root to RUL communication. 1034 In SM, it can be replaced by a loose RH3 header that indicates the 1035 RUL, in which case the packet is routed to the 6LR as a normal SM 1036 operation, then the 6LR forwards to the RUL based on the RH3, and the 1037 RUL ignores both the consumed RH3 and the RPI, as in Non-Storing 1038 Mode. [major] s/encapsulation MAY be avoided/encapsulation may be avoided Not a Normative statement, just a fact. ... 2378 11.2. Changes to DODAG Configuration Options Flags [nit] s/.../Change to the DODAG Configuration Options Flags registry 2380 This document changes the name of the "DODAG Configuration Option 2381 Flags" [dodagcfg] to "DODAG Configuration Option Flags for MOP 0..6". [] NEW> This document requests IANA to change the name of the "DODAG Configuration Option Flags" registry to "DODAG Configuration Option Flags for MOP 0..6". 2383 11.3. Change MOP value 7 to Reserved 2385 This document changes the allocation status of the Mode of Operation 2386 (MOP) [ianamop] from Unassigned to Reserved. This change is in 2387 support of future work related to capabilities. [] NEW> This document requests the changing the registration status of value 7 in the Mode of Operation registry from Unassigned to Reserved. This change is in support of future work. ... 2564 14.1. Normative References ... 2571 [dodagcfg] 2572 IANA, "DODAG Configuration Option Flags", Sept 2020, 2573 <https://www.iana.org/assignments/rpl/rpl.xhtml#dodag- 2574 config-option-flags>. 2576 [ianamop] IANA, "Mode Of Operation", Sept 2020, 2577 <https://www.iana.org/assignments/rpl/rpl.xhtml#mop>. [minor] These references are not needed. ... 2636 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 2637 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 2638 January 2019, <https://www.rfc-editor.org/info/rfc8504>. [minor] This reference can be Informative.
- [Roll] AD Review of draft-ietf-roll-useofrplinfo-… Alvaro Retana
- Re: [Roll] AD Review of draft-ietf-roll-useofrpli… Pascal Thubert (pthubert)
- Re: [Roll] AD Review of draft-ietf-roll-useofrpli… Alvaro Retana
- Re: [Roll] AD Review of draft-ietf-roll-useofrpli… Ines Robles
- Re: [Roll] AD Review of draft-ietf-roll-useofrpli… Michael Richardson
- Re: [Roll] AD Review of draft-ietf-roll-useofrpli… Alvaro Retana
- Re: [Roll] AD Review of draft-ietf-roll-useofrpli… Alvaro Retana