Re: [v6ops] Benjamin Kaduk's No Objection on draft-ietf-v6ops-cpe-slaac-renum-05: (with COMMENT)

Fernando Gont <fgont@si6networks.com> Wed, 27 January 2021 21:22 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DB03A0AFB; Wed, 27 Jan 2021 13:22:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 jo9UD-5q3hfd; Wed, 27 Jan 2021 13:21:59 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 628713A0AFD; Wed, 27 Jan 2021 13:21:54 -0800 (PST)
Received: from [IPv6:2800:810:464:2b9:69a9:e23f:a699:f848] (unknown [IPv6:2800:810:464:2b9:69a9:e23f:a699:f848]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id B3C48280482; Wed, 27 Jan 2021 21:21:50 +0000 (UTC)
From: Fernando Gont <fgont@si6networks.com>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
Cc: draft-ietf-v6ops-cpe-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, Owen DeLong <owen@delong.com>
References: <160325603610.17357.6914550111489766157@ietfa.amsl.com>
Message-ID: <cf025acf-5192-d9a3-a727-8716d9d7b232@si6networks.com>
Date: Wed, 27 Jan 2021 18:21:30 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <160325603610.17357.6914550111489766157@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/PkHLMxBkEQP-PM9t06uCgcpTDOM>
Subject: Re: [v6ops] Benjamin Kaduk's No Objection on draft-ietf-v6ops-cpe-slaac-renum-05: (with COMMENT)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jan 2021 21:22:02 -0000

Hi, Ben,

Just me going through IESG reviews to find if there's anything I had 
missed. Please see in-line....

On 21/10/20 01:53, Benjamin Kaduk via Datatracker wrote:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I am not sure that we should avoid having the conversation about
> intended status; consider, for example, "CE Routers SHOULD override the
> default [...] values from [RFC4861]" (RFC 4861 is a Draft Standard).  (The
> question was raised in the genart review thread by virtue of skew between
> the datatracker state and the document header, but it looks like the WG chair
> changed the status in the datatracker and there was no further discussion of
> the topic on the list.)
> 
> The diff between Abstract and Introduction is interesting: there is a
> parenthetical "(such as when a Customer Edge Router crashes and reboots
> without knowledge of the previously-employed configuration information)"
> only in the abstract that might also be useful in the introduction, and
> the abstract uses 'hosts' where the introduction uses 'nodes'.  (There
> are a couple other incidental wording differences that the authors might
> wish to consider normalizing on one wording for, as well as the expected
> additional text in the introduction that is not appropriate for an
> abstract.)

What's the specific "text that is not appropriate for an abstract"?




> Section 3.1
> 
>                                                         This means that
>     the advertised "Preferred Lifetime" and "Valid Lifetime" MUST be
>     dynamically adjusted such that they never span past the remaining
>     preferred and valid lifetimes of the corresponding prefixes delegated
>     via DHCPv6-PD on the WAN-side.
> 
> (nitty/editorial) Perhaps it is obvious to most readers, but perhaps it
> is not universally clear that the "advertised" part refers to
> "advertised by the CPE in SLAAC PIOs"; if I wanted to reword to remove
> ambiguity, I might go with something like 'This means that the
> "Preferred Lifetime" and "Valid Lifetime" advertised in PIOs by the CE
> router MUST be dynamically adjusted [...]'.

Done.


> The next paragraph (for the DHCPv6 case) uses a similar wording, but the
> first paragraph of that sentence is a bit more clear about "employed
> with DHCPv6 on the LAN-side" that also serves to reduce the potential
> ambiguity.  I'm happy to see or propose a similar rewording for the
> DHCPv6 case if that would be useful, but don't mind if we leave both
> paragraphs unchnaged, either.

Fixed this one, too.



>     CE Routers providing stateful address configuration via DHCPv6 SHOULD
>     set the DHCPv6 IA Address Option preferred-lifetime to the lesser of
>     the remaining preferred lifetime and ND_PREFERRED_LIMIT, and the
>     valid-lifetime of the same option to the lesser of the remaining
>     valid lifetime and ND_VALID_LIMIT.
> 
> Is it worth mentioning that ND_PREFERRED_LIMIT and ND_VALID_LIMIT are
> defined in Section 4?

Done.



> Section 3.2
> 
>        *  CE Routers need not employ the (possibly long) DHCPv6-PD
>           lifetimes for the Valid Lifetime and Preferred Lifetime of PIOs
> 
> (nit) do we want "received" in there anywhere (e.g., "received DHCPv6-PD
> lifetimes")?
> 
>        *  Similarly, CE Routers need not employ the (possibly long)
>           DHCPv6-PD lifetimes for the valid-lifetime and preferred-
> 
> (Likewise, we could use "received" or "WAN-side" here.)

Applied both.



> Section 3.3
> 
>     In order to phase-out stale SLAAC configuration information:
>     [...]
>     If a CE Router provides LAN-side DHCPv6 (address assignment or prefix
>     delegation), then:
>     [...]
> 
> (editorial) Can/should these sentences use a parallel structure (e.g.,
> "If a CE Router provides SLAAC configuration information, then [...]")?

Done.


> 
>        *  In Replies to DHCPv6 Request, Renew, Rebind messages, send 0
>           lifetimes for any address assignments or prefix delegations for
>           the deprecated prefixes for at least the valid-lifetime
>           previously employed for them, or for a period of ND_VALID_LIMIT
>           if the recommended lifetimes from Section 3.2 are employed.
> 
> Is it deliberate to say nothing at all about Advertise messages (which
> are sent in response to Solicit messages, not any of the listed ones)?

I will double-check this one with my co-authors.


>        *  The requirement in this section is conveyed as a "SHOULD" (as
>           opposed to a "MUST"), since we acknowledge that the requirement
>           to store information on stable storage may represent a
>           challenge for some implementations.
> 
> (editorial/style) It's not entirely clear that we gain much from the use
> of the first person, here.  E.g., we could say 'conveyed as a "SHOULD"
> (as opposed to a "MUST"), since the requirement to store information on
> stable storage may represent a challenge for some implementations'.

Done.



> Section 6
> 
> I suggest noting that the security considerations from RFC 7084 continue
> to apply.  (Also, basically the same comment I had for
> draft-ietf-v6ops-slaac-renum applies, which still does not imply any
> changes to the text.)

Done. We've added that the security implications of rfc4861, rfc4862, 
rfc8415, and rfc7084 still apply.



> Section 8.2
> 
> It would feel more natural, at least to me, if RFC 7084 was listed as a
> normative reference.  (In the sense that we are Updating it to make
> incremental additions, but you need the whole combined assembly of both
> documents in order to have a functional setup.)

I would assume so. But it would be a downref. Is that possible?

Thanks!

Regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492