[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.