Iotdir last call review of draft-ietf-6man-grand-04
Carles Gomez via Datatracker <noreply@ietf.org> Fri, 18 June 2021 10:18 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: ipv6@ietf.org
Delivered-To: ipv6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 606C23A0D2E; Fri, 18 Jun 2021 03:18:43 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Carles Gomez via Datatracker <noreply@ietf.org>
To: iot-directorate@ietf.org
Cc: draft-ietf-6man-grand.all@ietf.org, ipv6@ietf.org, last-call@ietf.org
Subject: Iotdir last call review of draft-ietf-6man-grand-04
X-Test-IDTracker: no
X-IETF-IDTracker: 7.32.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <162401152333.27933.7850491971631462513@ietfa.amsl.com>
Reply-To: Carles Gomez <carlesgo@entel.upc.edu>
Date: Fri, 18 Jun 2021 03:18:43 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ZAlQy6bpvOQ_txMal2VKX9ZDVFo>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 18 Jun 2021 10:18:44 -0000
Reviewer: Carles Gomez Review result: Ready with Nits In my opinion, the document is well written. I found no major issues. I have reviewed the document from the perspective of constrained nodes or constrained-node networks. 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. 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. - 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 - 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. - Section 5.1, title: s/Other That/Other Than - Section 5.3.2, bullet 6: s/and wait up/and waits up - 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). - Section 6: shouldn't the last dotted line need to be placed right before Section 7? - Section 10: s/layer2/layer-2
- Iotdir last call review of draft-ietf-6man-grand-… Carles Gomez via Datatracker
- Re: Iotdir last call review of draft-ietf-6man-gr… Jen Linkova
- Re: [Iot-directorate] Iotdir last call review of … Carles Gomez Montenegro