Re: [Gen-art] [6lo] Genart last call review of draft-ietf-6lo-blemesh-08

Carles Gomez Montenegro <carlesgo@entel.upc.edu> Tue, 08 December 2020 08:37 UTC

Return-Path: <carlesgo@entel.upc.edu>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7FB3A0E1F; Tue, 8 Dec 2020 00:37:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level:
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Lv0zx4GMHnHI; Tue, 8 Dec 2020 00:37:22 -0800 (PST)
Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 8086A3A03EF; Tue, 8 Dec 2020 00:37:22 -0800 (PST)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.40.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 0B88bA3C009123; Tue, 8 Dec 2020 09:37:10 +0100
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 6E5EB1D53C1; Tue, 8 Dec 2020 09:37:09 +0100 (CET)
Received: from 79.152.1.171 by webmail.entel.upc.edu with HTTP; Tue, 8 Dec 2020 09:37:10 +0100
Message-ID: <4d07e6443cb2b1d0bd76033bb92872b0.squirrel@webmail.entel.upc.edu>
In-Reply-To: <160711595155.19658.8436612763808758937@ietfa.amsl.com>
References: <160711595155.19658.8436612763808758937@ietfa.amsl.com>
Date: Tue, 8 Dec 2020 09:37:10 +0100
From: "Carles Gomez Montenegro" <carlesgo@entel.upc.edu>
To: "Pete Resnick" <resnick@episteme.net>
Cc: gen-art@ietf.org, last-call@ietf.org, draft-ietf-6lo-blemesh.all@ietf.org, 6lo@ietf.org
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.100.3 at violet
X-Virus-Status: Clean
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Tue, 08 Dec 2020 09:37:10 +0100 (CET)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/gn6li_Nu-MceQInVwcgcWnTKilE>
Subject: Re: [Gen-art] [6lo] Genart last call review of draft-ietf-6lo-blemesh-08
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Dec 2020 08:37:25 -0000

Hi Pete,

Thanks a lot for your review of the draft!

We just submitted -09, which aims at addressing the last round of review
comments, including yours:
https://tools.ietf.org/html/draft-ietf-6lo-blemesh-09
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-blemesh-09

Please find below our inline responses to your comments:

> Reviewer: Pete Resnick
> Review result: Ready with Issues
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> Document: draft-ietf-6lo-blemesh-08
> Reviewer: Pete Resnick
> Review Date: 2020-12-04
> IETF LC End Date: 2020-10-21
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: Looks good to me, with two items that seemed confusing enough
> that
> they should be addressed.
>
> Note that this review is being done well after the close of the Last Call.
> Since this is not yet scheduled for a telechat, the AD asked that I go
> ahead
> and complete the review anyway.
>
> Major issues: None
>
> Minor issues:
>
> 3.3.2, #4:
>
>    Implementations of this specification MAY support
>    the features described in sections 8.1 and 8.2 of RFC 6775, as
>    updated by RFC 8505, unless some alternative ("substitute") from some
>    other specification is supported by the implementation.
>
> This bit confused me. I think it was the "unless". Do you mean it MAY
> support
> the 6775/8505 features, or MAY support some substitute, or MAY support
> neither,
> or do you mean that it MUST support either the 6775/8505 features or MUST
> support some substitute? I think you want to rewrite this to make it clear
> which one you mean.

Agreed. We modified the text as follows:

NEW:
   Implementations of this specification MUST either
   support the features described in sections 8.1 and 8.2 of RFC 6775,
   as updated by RFC 8505, or some alternative ("substitute") mechanism.

> 3.3.3, last two paragraphs:
>
>    When a 6LN transmits a packet, with a non-link-local source address
>    that the 6LN has registered with EARO in the next-hop router for the
>    indicated prefix, the source address MUST be fully elided if it is
>    the latest address that the 6LN has registered for the indicated
>    prefix (SAC=1, SAM=11).  If the source non-link-local address is not
>    the latest registered by the 6LN, then the 64 bits of the IID SHALL
>    be fully carried in-line (SAC=1, SAM=01) or if the first 48 bits of
>    the IID match with the latest address registered by the 6LN, then the
>    last 16 bits of the IID SHALL be carried in-line (SAC=1, SAM=10).
>
>    When a router transmits a packet to a neighboring 6LN, with a non-
>    link-local destination address, the router MUST fully elide the
>    destination IPv6 address if the destination address is the latest
>    registered by the 6LN with EARO for the indicated context (DAC=1,
>    DAM=11).  If the destination address is a non-link-local address and
>    not the latest registered, then the 6LN MUST either include the IID
>    part fully in-line (DAM=01) or, if the first 48 bits of the IID match
>    to the latest registered address, then elide those 48 bits (DAM=10).
>
> Both of these were a bit confusing to me. I think you want to reverse the
> order
> of the last two choices. Say something like (for the first paragraph), "If
> the
> source non-link-local address is not the latest registered by the 6LN and
> the
> first 48 bits match..., then the last 16 bits SHALL be carried in-line.
> Otherwise, if first 48 bits do not match, then the 64 bits shall be
> carried
> inline." Similarly for the second. As it is, it takes a while to figure
> out
> what it means.

We modified the two paragraphs as per your suggestion.

> Nits/editorial comments: Do fix the reference nits noted by the nits tool;
> they
> appear to be simple typos.

Done!

Cheers,

Carles (on behalf of the authors)