Re: Alvaro Retana's No Objection on draft-ietf-6man-rfc4941bis-11: (with COMMENT)

Erik Kline <ek.ietf@gmail.com> Mon, 14 December 2020 04:49 UTC

Return-Path: <ek.ietf@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 522E53A0E9D; Sun, 13 Dec 2020 20:49:04 -0800 (PST)
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, RCVD_IN_DNSWL_BLOCKED=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=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 epLNgSjiE0eM; Sun, 13 Dec 2020 20:49:03 -0800 (PST)
Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (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 B7C7F3A0E9B; Sun, 13 Dec 2020 20:48:59 -0800 (PST)
Received: by mail-oi1-x231.google.com with SMTP id l200so17840252oig.9; Sun, 13 Dec 2020 20:48:59 -0800 (PST)
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:content-transfer-encoding; bh=9ocW76U8HnU/r271dprq7nkfg31dLVvHeKPq0VQITX8=; b=qfSbeN46PjfeaO+1MxqNBn/ziUHip2mygeB0Pcktj7KECdab/quHM7CuJ8LmQIVQaS H6TubCS8J7AHQT/csgZM8RTHT7mDFvmd4MYMnVXdECu0GgQ05aSyhyHV56pUMiFRmfrh dgiWy6TPyJ/OdRGqLu3gpL0AMwDXMtr0ajhL+GTwIcbonlrp0q1SPmDC4NflHtOpErWE HK3Nlgrm/CSO+fdPJS4RSd2mAh2yl54GwTsdIyHOZDPOUg7PXpmoZ26B0Tj5bjHWg6Af 9oJCnEXSWbC4M89ITC9/GGu1f04DKy7uud+H6CVV9g/1ybdbeWRtbHWxuOMUtri1kJn0 jttQ==
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:content-transfer-encoding; bh=9ocW76U8HnU/r271dprq7nkfg31dLVvHeKPq0VQITX8=; b=IisPm7NoMpaRyBVOU3BS3wDK07n+SVTkOOlHozU1yG3pUSio9tNkVhj71L9Nv1kgqq iLmREfnzAWIwYTH+YXkmDd2GwYBAelD4zKpovrzD+nxu0taMSKLOg8/XAMCLj/hh+F8q gtAIOK5ZO8xpWNCEXk6hP+zHLPne2wKBB06U1GlPwI81kp5tVEZlpmLQu1K63Y2F7dFL I/Yn4DGvvMGgSOg8Wj5EQSRHVs2as8mDtaKRM9RRgvcQXRmhBk0gRijLfc3loTZapLOr Q8stgdWmtOE5Oo5HxikvSLCM5qWjqzakxYjWyyAknNT+cRF7Y7ouya4jD1HsBSa/eCpD fOAA==
X-Gm-Message-State: AOAM533FIkT11i7jmKB/GSqZE7g7C+9AkNdwdauo1wMx2R8Bp33lse0H YGRBE1lsiPJ0KlZvcnGNsAQiWkjOtSxOSDxQ0U0=
X-Google-Smtp-Source: ABdhPJymEZjz6W7aYk/UadyUFmOPCFODLXMOkwdoQ9GYsBjz06MuQx3oYW5/Av2poG9WFkAGe0ziHTW6xMDmeBwvod4=
X-Received: by 2002:aca:ec13:: with SMTP id k19mr17399190oih.97.1607921338894; Sun, 13 Dec 2020 20:48:58 -0800 (PST)
MIME-Version: 1.0
References: <160313378187.7246.8644532996867850166@ietfa.amsl.com> <d0771c09-a0b6-95b3-ff0c-29cfa9fba7c5@si6networks.com> <CAMMESsz88x2BAF3c6RGnCFNQqgaiF1HD7EH9a=4XgrBnHsPQRA@mail.gmail.com> <85310bac-c72b-57b7-fe0e-d6a494b8d446@si6networks.com>
In-Reply-To: <85310bac-c72b-57b7-fe0e-d6a494b8d446@si6networks.com>
From: Erik Kline <ek.ietf@gmail.com>
Date: Sun, 13 Dec 2020 20:48:48 -0800
Message-ID: <CAMGpriXAAmX7Sm1hG1O4d8z9G9LXD4UBwxvr02DNDtu0Mz=FEg@mail.gmail.com>
Subject: Re: Alvaro Retana's No Objection on draft-ietf-6man-rfc4941bis-11: (with COMMENT)
To: Fernando Gont <fgont@si6networks.com>
Cc: Alvaro Retana <aretana.ietf@gmail.com>, The IESG <iesg@ietf.org>, draft-ietf-6man-rfc4941bis@ietf.org, Ole Trøan <otroan@employees.org>, IPv6 List <ipv6@ietf.org>, 6man Chairs <6man-chairs@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/nFjktt5PFtVD8k55KDMbBiImlP4>
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, 14 Dec 2020 04:49:04 -0000

On Tue, Oct 20, 2020 at 12:38 PM Fernando Gont <fgont@si6networks.com> wrote:
>
> Hello, Alvaro,
>
> On 20/10/20 15:34, Alvaro Retana wrote:
> [....]
> >>> Please clarify the text one way or the other: by eliminating "examples"
> >>> from §3.3, or removing the text in parenthesis in §3.4.
> >>
> >> How about changing that paragraph as:
> >>
> >> OLD:
> >> 6. New temporary addresses MUST be created by appending a randomized
> >> interface identifier (generated as described in Section 3.3 of
> >> this document) to the prefix that was received.
> >>
> >> NEW:
> >> 6. New temporary addresses MUST be created by appending a randomized
> >> interface identifier to the prefix that was received. The
> >> randomized interface identifier MUST comply with the design
> >> guidelines from Section 3.1. Section 3.3 specify some example
> >> algorithms that comply with the aforementioned design goals.
> >
> >
> > I'm ok with this suggestion, except for the "MUST comply with the
> > design guidelines from Section 3.1" part.  There's no interoperability
> > required to justify normatively pointing at §3.1, most of the bullets
> > there don't apply to the generation of random IIDs, and I don't see a
> > strong reference to §3.1 anywhere else in the text.
> >
> > I would be very happy by simply changing that second "MUST" to "must".
> >
> > Having said that, my comment was non-blocking, so I trust you and the
> > Responsible AD to make the right decision.
>
> Ok. Question for Erik: which of the three proposed changes (or Alvaro's
> suggested s/MUST/must/) would be best for you?

I'm good with text in -12.  It points to 3.3 without being overly
prescriptive if an implementation has something that works better
(somehow).