Re: Iotdir last call review of draft-ietf-6man-grand-04

Jen Linkova <furry13@gmail.com> Mon, 21 June 2021 09:39 UTC

Return-Path: <furry13@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E334D3A2A3A; Mon, 21 Jun 2021 02:39:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.052
X-Spam-Level:
X-Spam-Status: No, score=0.052 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 V6pQwO_H6QeU; Mon, 21 Jun 2021 02:39:51 -0700 (PDT)
Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 E91A83A2A39; Mon, 21 Jun 2021 02:39:50 -0700 (PDT)
Received: by mail-qv1-xf2b.google.com with SMTP id m15so1166082qvc.9; Mon, 21 Jun 2021 02:39:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l0i4ljaHv46mIKyir+042p5duouoD3l7GV8sEfcNB0Q=; b=YtxDqKv9A1/0WWWP+91XU8E4ubqB20tMctZqi41L16bmQw6lXv8o3G2XezGdnzeZDS 3cX9regH3IQQiaVnvJ9Z1KznAeatXtPefFhFTqZTPlvxIO8d4AYGT7WEvpoGV5M+ZT9v JcVxvbm9uuPX0JT4D6uWtcht2t2UgznZKdR6pVEXWGHLkRrNHltA4WX6VpkXdvjeERYM JN9hpw9yRTpywlEcEbQ5K6MTfCGFzTclxfTgi0hQ3AZMvDHQzVFdbnIky01H5PRZQvRV RIswIgnKa5o6Q7cofwcCIymij6eMBrHWvN6VhOQMdDlpVcB5dDV0skWg5/Bcgbxx0b/N qaJQ==
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=l0i4ljaHv46mIKyir+042p5duouoD3l7GV8sEfcNB0Q=; b=RH8wnwqFaX9djNjfZ2bx/PCSCQL7rj8b4oPNvOb9sCnmVx/RlTINajUK24VQwUPipS kHCFRVdbz8kLcavP8TwygxBzkjEQxHMbl8odAkynctM44dKnDliBAye2tf6MP4aVHRke y2bjdSVssCsbQr3j2JWzkz5lz3isrHp1D0uIAhnUWoHHQoOoWhIgK2rFNzhrYEKAXSgY Nh6bUa4Qclg9TqFGhw1gsN2C+By5T5MteGggoLTEYZSKMZkFYGIXlD6wlrQpY2vVeAY6 XqSN/iTTuXZ2zI8WJ07tkm597ragGuWXZZCY921Yjv1HXf5kNsyEXVqjpzMWGyRwY9K8 9+Ww==
X-Gm-Message-State: AOAM5333cs1gRdlguL7pOKMQ3v74pj0kc4llrIQ7TUZ2rf+3WWh6q2ix TeKv1DQQ8TG8nnABhxcmzPcCFSZJI+F8NVQLCmg=
X-Google-Smtp-Source: ABdhPJy4fnvsB0ULnYZcdby4tu+XYSkjuxVvO0ZQ+j9lTlqoIU9fw4KVy7TjUJhplzsRpq8NK2u50skRcHUl7hSUBSY=
X-Received: by 2002:a05:6214:207:: with SMTP id i7mr19162415qvt.10.1624268387513; Mon, 21 Jun 2021 02:39:47 -0700 (PDT)
MIME-Version: 1.0
References: <162401152333.27933.7850491971631462513@ietfa.amsl.com>
In-Reply-To: <162401152333.27933.7850491971631462513@ietfa.amsl.com>
From: Jen Linkova <furry13@gmail.com>
Date: Mon, 21 Jun 2021 19:39:36 +1000
Message-ID: <CAFU7BAT8gLDB-t12XWh6rUi=rwJ-kDySFTkSz2SZ3dcNBDiR7A@mail.gmail.com>
Subject: Re: Iotdir last call review of draft-ietf-6man-grand-04
To: Carles Gomez <carlesgo@entel.upc.edu>
Cc: iot-directorate@ietf.org, last-call@ietf.org, draft-ietf-6man-grand.all@ietf.org, 6man <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/HUkMHZhmMyLxO9v3n5DDAMYZ2T4>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Jun 2021 09:39:56 -0000

Hi Carles,

Thanks a lot for the detailed review!
Comments below (when I say 'fixed' it means 'added to -05 which will
be submitted today).

On Fri, Jun 18, 2021 at 8:19 PM Carles Gomez via Datatracker
<noreply@ietf.org> wrote:
> I understand that the document is intended for devices that do not use RFC
> 6775/8505. Section 8.2 explicitly discusses why the registration-based approach
> in 6775/8505 is not followed in draft-ietf-6man-grand. However, 6775/8505
> shares the proactive spirit of the mechanisms defined in draft-ietf-6man-grand.
> Regarding  registration-based ND, the document states that "This option
> requires some investigation and discussion.". While it makes sense to defer
> such discussion beyond the timeline for this document, it would appear that
> 6775/8505 would allow to achieve goals similar to those allowed by
> draft-ietf-6man-grand, while offering additional benefits for constrained-node
> networks. Indeed, this area offers opportunities for promising future
> discussion/work.
>
> I am not sure about the "implementation complexity" attributed to RFC 6775/8505
> in section 8.2, in the sense that such documents have been precisely created
> for devices that are typically characterized by significant resource
> constraints. Perhaps some clarification or rephrasing might help.

What I meant by 'implementation complexity' was the scope of changes required.
I rephrased it slightly:
OLD TEXT:
However the implementation complexity and unclear adoption timeline
makes this approach less preferable than one proposed in this
document.
NEW TEXT:

However significant changes to the existing IPv6 implementations would
be needed, so unclear adoption timeline makes this approach less
preferable than one proposed in this document.

> Please find below a number of nits/comments:
>
> - Section 2, bullet 3: "... by creating an INCOMPLETE cache entry...". Perhaps
> adding a reference for 'INCOMPLETE cache entry' at the end of the sentence
> would be helpful.

Done.

> - Section 2, bullet 4: s/it would consider/in the worst case, it would consider
>
> - Section 4.1, first sentence: s/Neighbor Advertisement/Neighbor Advertisements

Fixed.

> - There are several instances of e.g. "NA" and "Neighbor Advertisement"
> throughout the document. It might be good to define the acronym on its first
> use and use the acronym thereafter.

The Introduction does not use any acronym and the next section is the
Terminology, where all acronyms are explained.
I'm just not sure it's worth defining the acronyms twice (in that
section and on first use).

> - Section 5.1, title: s/Other That/Other Than
>
> - Section 5.3.2, bullet 6: s/and wait up/and waits up

Fixed, thanks.

> - Section 5.3.2: "within tens of milliseconds". Perhaps this time could be
> slightly greater in some cases (e.g. with RTTs in the order of ~100 ms).

I've changed the text so it says 'within tens of milliseconds in most cases'.

> - Section 6: shouldn't the last dotted line need to be placed right before
> Section 7?

Oh that was a copy-n-paste artefact, removed.

> - Section 10: s/layer2/layer-2

Fixed.

-- 
SY, Jen Linkova aka Furry