Re: [Roll] Iotdir telechat review of draft-ietf-roll-useofrplinfo-40
Ines Robles <mariainesrobles@googlemail.com> Tue, 04 August 2020 07:07 UTC
Return-Path: <mariainesrobles@googlemail.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 CF80C3A0F3E; Tue, 4 Aug 2020 00:07:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.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 l7K_wOnMzsJk; Tue, 4 Aug 2020 00:07:32 -0700 (PDT)
Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (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 612F03A0F33; Tue, 4 Aug 2020 00:07:32 -0700 (PDT)
Received: by mail-ua1-x92a.google.com with SMTP id 4so7901638uav.8; Tue, 04 Aug 2020 00:07:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WLn2zgi4bpsaXTprEoVu0s56oGDrsDDH1Eim5WkWAXM=; b=ryGfKWpaWkiTcxMxQBLPUoqTi3QQ1TB75l7kFvZzEG0WJBPaASYEoSaV06ZxPtGKir Cnb9BDXfP8c35zfqtsEU/JkK+onF7+baQsriJUtNhiEBRHSqNXZfCt83Z0g8en7GKrvE dVqFr4D80zU6r7WrKnnyJqo401KpsHiQnJa2s/G7j9pkZy0kDP0U29W89S9wzSD6dYiV jYrur3TnMxxns8+78jVFNobachdLFuToHO9e/+3rFGjvjjGnzEYOFD2PAQ2gF1QW0pZU nSsF2Iy9Ei5sBGHV1gVJJR49M5bVX8ujNmiyFrdL6zIK4oVu+n48spkGYisyhZYPvkef f9bQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WLn2zgi4bpsaXTprEoVu0s56oGDrsDDH1Eim5WkWAXM=; b=stS63kYqNaS4/8Z/YyGA8z5rqK5jkjbMIakK6V80V11cg7r/xg84Z0OX1VzyLUcpOO KnzH/qlQ2Wxf7BUkPwadLxOeQGPNCcAuUK7W8yuquG/8Z8n+3sP4giEW4oecNDNIV5sP FLetrwDX7sWtKUcGDm/nxSR3V3qf9p9r3arkCnw+jl9+BUWFCNAP77autw34YVjdrl3v hQ7TXKfAJatm2V7ZySwYHj2iKZy/RN1AlF1Rm9zDaEnwg7jMXywsQHue9PpNe07SAzir bGJ9nbHPs+OMDfpp8w1axhj68IbTyeb/jYX64v6TMXxeDZcOjq9p1Xmjy87pXm4IYct1 2x1g==
X-Gm-Message-State: AOAM530sk4EN4NcJKeuADppt3vntVlaqRiA6UcJVhFWxYqShlO6cvIxg Ar6IDQpEzEn4sSN5uhRZZLTx8XNLBBnS+2D13do=
X-Google-Smtp-Source: ABdhPJxaQPH/wtrRfqCleT8SdRr/THwbIarKBX0K0gX1+4oI8fuHNgIlebwlke53sG6jGZ1DJ6LQ4BKL0rrYhRtpEcQ=
X-Received: by 2002:a9f:2106:: with SMTP id 6mr13839595uab.56.1596524851311; Tue, 04 Aug 2020 00:07:31 -0700 (PDT)
MIME-Version: 1.0
References: <159602896040.32219.18351168129491497436@ietfa.amsl.com>
In-Reply-To: <159602896040.32219.18351168129491497436@ietfa.amsl.com>
From: Ines Robles <mariainesrobles@googlemail.com>
Date: Tue, 04 Aug 2020 10:06:54 +0300
Message-ID: <CAP+sJUfXyjtKVSSxtbA6kZPchBgG8L2wWMCTt1X-gtcd-AsCJQ@mail.gmail.com>
To: Mališa Vučinić <malisa.vucinic@inria.fr>
Cc: IETF IoT Directorate <iot-directorate@ietf.org>, draft-ietf-roll-useofrplinfo.all@ietf.org, roll <roll@ietf.org>, last-call@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a33a4d05ac07e8ba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/bCmruYdCB0L_jbBnpIZWE0h5Afw>
Subject: Re: [Roll] Iotdir telechat review of draft-ietf-roll-useofrplinfo-40
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: Tue, 04 Aug 2020 07:07:34 -0000
Hi Mališa, Thank you very much for your review. We will work on it and get back to you. Best, Ines. On Wed, Jul 29, 2020 at 4:22 PM Mališa Vučinić via Datatracker < noreply@ietf.org> wrote: > Reviewer: Mališa Vučinić > Review result: Ready with Issues > > As part of the IoT-Directorate review process, I went through > draft-ietf-roll-useofrplinfo-40. In general, I believe the document is > ready to > proceed once a couple of issues that I outline below are resolved. > > I have concerns whether the use of the normative language is appropriate > in the > use cases section. I believe all such cases are covered either in the > sections > updating RFC 6553, RFC 6550 and RFC 8138 or in these respective RFCs. > Please > consider using lowercase keywords in Section 6. > > As a minor note, there also appears to be an inconsistent use of the > IP6-IP6 > acronym. Please use a single acronym throughout the doc, currently a mix of > IPv6-in-IPv6 and IP6-IP6 is present. > > My detailed comments are given below. > > Section 1: > > > Since some of the uses cases here described, use IPv6-in-IPv6 > encapsulation. > It MUST take in consideration, when encapsulation is applied, the RFC6040 > [RFC6040], which defines how the explicit congestion notification (ECN) > field > of the IP header should be constructed on entry to and exit from any > IPV6-in-IPV6 tunnel. - Please clarify the sentence. Consider whether it is > appropriate to have a normative MUST here. > > Section 4.2: > > The non-storing mode case does not require the type change from 0x63 to > 0x23, > as the root can always create the right packet. The type change does not > adversely affect the non-storing case. - It is not clear what RPI option > type > should non-storing networks use. A pointer to the discussion in Section 4.3 > would be useful. > > Section 4.4: > > > A node that is decompressing this header MUST decompress using the RPI > Option > Type that is currently active: that is, a choice between 0x23 (new) and > 0x63 > (old). The node will know which to use based upon the presence of the flag > in > the DODAG Configuration option defined in Section 4.3. E.g. If the > network is > in 0x23 mode (by DIO option), then it should be decompressed to 0x23. - If > my > understanding is correct, this means that in order to decompress data plane > packets, a node first needs to remember the option type mode the network is > operating in, advertised in DIOs. Consequently, decompression is not > possible > before at least one DIO is received. > > Section 6: > > > The RPI MUST be present in every single RPL data packet. > - How is the normative text here appropriate at this point? Is this not > redundant with RFC6553? > > > This document assumes that the LLN is using the no-drop RPI Option Type > (0x23). - This statement appears twice in the document and is as such > redundant. please remove one appearance. > > Section 8: > > > The root always have to encapuslate on the way down > - It is not clear how come does root need to always encapsulate on the way > down. In the basic case of root to RAL communication, IPv6-in-IPv6 is > marked as > “No”. Please clarify. > > Section 8.1.3: > > > When the RPI is added, the RUL, which does not understand the RPI, will > ignore it (per [RFC8200]); thus, encapsulation is not necessary. - Figure > 22 > states that for root to RUL communication IPv6-in-IPv6 encapsulation is > mandatory which is not consistent with this text. > > Section 8.2.1: > > - A sentence stating how does RAL recognize that the packet is destined > for the > Internet would be useful. > > Section 8.2.3: > > > As RPL headers are added in the RUL packet, the first 6LR (6LR_1) will > add an > RPI inside a new IPv6-in-IPv6 header. - this statement makes it sound as > if RUL > originates a packet with RPL headers. Please rephrase. > > Nits: > > The ROLL WG analysized how [RFC2460] rules apply to storing and > non-storing > use of RPL. - s/analysized/analyzed > > > that transports that abstract information in an IPv6 Hob-by-Hop Header. > - s/hob/hop > > > consumed Routing Header and to ignore a HbH header as prescribed by > - define HbH, assuming Hop-by-Hop > > > The root does not removes the RPI1 > - s/removes/remove > > > The 6LR_ia (ia=1) (Node E) > - s/6LR_ia (ia=1)/6LR_1 > > > The root always have to encapuslate on the way down > - s/have to encapuslate/has to encapsulate > > > If the originating node does not not > - s/does not not/does not > > > and add it's own > - s/it’s/its > > > The migration procedure it is triggered when the DIO is sent with the > flag > indicating the new RPI Option Type. - s/it is/is > > > Namely, it remains at 0x63 until it is sure that the network is capable > of > 0x23, then it abruptly change to 0x23. - s/change/changes > > >
- [Roll] Iotdir telechat review of draft-ietf-roll-… Mališa Vučinić via Datatracker
- Re: [Roll] Iotdir telechat review of draft-ietf-r… Pascal Thubert (pthubert)
- Re: [Roll] Iotdir telechat review of draft-ietf-r… Ines Robles
- Re: [Roll] Iotdir telechat review of draft-ietf-r… Pascal Thubert (pthubert)
- Re: [Roll] Iotdir telechat review of draft-ietf-r… Mališa Vučinić
- Re: [Roll] Iotdir telechat review of draft-ietf-r… Ines Robles
- Re: [Roll] Iotdir telechat review of draft-ietf-r… Mališa Vučinić
- Re: [Roll] Iotdir telechat review of draft-ietf-r… Ines Robles