Re: [v6ops] [Last-Call] Genart last call review of draft-ietf-v6ops-cpe-slaac-renum-04

Pete Resnick <resnick@episteme.net> Fri, 11 September 2020 23:51 UTC

Return-Path: <resnick@episteme.net>
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 30A6E3A0A53; Fri, 11 Sep 2020 16:51:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1HsVFtPb_0Ie; Fri, 11 Sep 2020 16:51:46 -0700 (PDT)
Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1B7A3A091F; Fri, 11 Sep 2020 16:51:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 68898BC4C1A0; Fri, 11 Sep 2020 18:51:41 -0500 (CDT)
Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1-VUBL6tzKP; Fri, 11 Sep 2020 18:51:39 -0500 (CDT)
Received: from [172.16.1.6] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 8F359BC4C191; Fri, 11 Sep 2020 18:51:39 -0500 (CDT)
From: "Pete Resnick" <resnick@episteme.net>
To: "Bernie Volz" <volz@cisco.com>
Cc: "Fernando Gont" <fgont@si6networks.com>, gen-art@ietf.org, last-call@ietf.org, v6ops@ietf.org, draft-ietf-v6ops-cpe-slaac-renum.all@ietf.org
Date: Fri, 11 Sep 2020 18:51:39 -0500
X-Mailer: MailMate (1.13.1r5706)
Message-ID: <BD967623-7316-45A9-9271-327472F2C107@episteme.net>
In-Reply-To: <2C9BF3C2-A611-4F18-8F03-104405DD9799@cisco.com>
References: <159968036707.9786.16859070438001357349@ietfa.amsl.com> <8d777075-25b5-1817-5c2a-18162bfb9e71@si6networks.com> <2C9BF3C2-A611-4F18-8F03-104405DD9799@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/vAIHMa1D7AGvZC-dLGnGtBJvC24>
Subject: Re: [v6ops] [Last-Call] Genart last call review of draft-ietf-v6ops-cpe-slaac-renum-04
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: Fri, 11 Sep 2020 23:51:48 -0000

I missed that. And indeed the Last Call went out for Proposed Standard. 
Warren should probably look into this before it goes to the IESG.

pr

On 9 Sep 2020, at 19:50, Bernie Volz (volz) wrote:

> Interesting that the datatracker says the document is "Proposed 
> Standard", but the document has "Intend status: Informational". The 
> two should be made to agree.
>
> - Bernie
>
>> On Sep 9, 2020, at 8:45 PM, Fernando Gont <fgont@si6networks.com> 
>> wrote:
>>
>> Hello, Pete,
>>
>> Thanks a lot for your feedback! In-line....
>>
>> On 9/9/20 16:39, Pete Resnick via Datatracker wrote:
>> [....]
>>> Major issues: None
>>> draft-ietf-v6ops-cpe-slaac-renum
>>> Minor issues:
>>> The shepherd writeup says:
>>>    The document so far has been approved by the V6OPS working group
>>>    (successful working group last call). The document does not 
>>> specify
>>>    new protocol, but rather changes to the default parameters in
>>>    existing protocols.
>>> However, the document is Informational, as confirmed by the shepherd 
>>> writeup.
>>> If this is actually updating default parameters in protocols, that 
>>> sounds like
>>> it should either be a Standards Track document or more likely a BCP. 
>>> As 2026
>>> says:
>>>    The BCP subseries of the RFC series is designed to be a way to
>>>    standardize practices and the results of community deliberations. 
>>> [...]
>>>    ...[G]ood user
>>>    service requires that the operators and administrators of the
>>>    Internet follow some common guidelines for policies and 
>>> operations.
>>>    While these guidelines are generally different in scope and style
>>>    from protocol standards, their establishment needs a similar 
>>> process
>>>    for consensus building.
>>> That sounds like what this is doing, especially with all of the 2119 
>>> language
>>> in here. Maybe this is Informational because 7084 (and 6204 before 
>>> it) were
>>> Informational, but perhaps 7084 (and other such document) should be 
>>> BCP as
>>> well. Indeed, it sounds like all of these SLAAC operational 
>>> documents could be
>>> in one BCP together.
>>
>> FWIW, the reason for which this document is informational is because 
>> the document it's formally updating (RFC7084) is also informational. 
>> -- Me, I'd probably agree with you that both RFC7084 and this 
>> document should be BCPs, rather than Informational. I'd like to hear 
>> from our AD regarding how to proceed here.
>>
>> FWIW, I'm fine with changing the track to BCP, although I'd also note 
>> that there's plenty of existing practice of documents of this type 
>> published as Informational.
>>
>>
>>
>> Either way, Informational seems wrong.
>>> Nits/editorial comments:
>>> Throughout the document, it says, "This document RECOMMENDS..." or 
>>> "This
>>> document also RECOMMENDS" or "Additionally, this document 
>>> RECOMMENDS". RFC 2119
>>> does not use "RECOMMENDS". You can say "CE Routers SHOULD..." or "A 
>>> Router
>>> Lifetime of ND_PREFERRED_LIMIT is RECOMMENDED" or if you must "It is
>>> RECOMMENDED that..." (blech, I hate the passive form), since SHOULD 
>>> and
>>> RECOMMENDED are equivalent in 2119, but using the "This document 
>>> RECOMMENDS..."
>>> form is weird and isn't in 2119.
>>
>> Fair enough. I'll apply the suggested edit unless I hear otherwise 
>> from others.
>>
>>
>>
>>
>>> In 3.3, it says:
>>>    o  Upon changes to the advertised prefixes, and after 
>>> bootstrapping,
>>>       the CE router advertising prefix information via SLAAC SHOULD
>>>       proceed as follows:
>>> But then each of the things under there has a SHOULD or a MUST. The 
>>> SHOULD here
>>> is confusing. Instead, the sentence could simply be:
>>>    o  Upon changes to the advertised prefixes, and after 
>>> bootstrapping,
>>>    the CE router advertising prefix information via SLAAC proceeds 
>>> as
>>>    follows:
>>> Similarly:
>>>    This document RECOMMENDS that if a CE Router provides LAN-side 
>>> DHCPv6
>>>    (address assignment or prefix delegation), the following behavior 
>>> be
>>>    implemented:
>>> Just make the sentence:
>>>    If a CE Router that provides LAN-side DHCPv6 (address assignment 
>>> or
>>>    prefix delegation), then:
>>
>> FWIW, the motivation for the "SHOULD" in Section 3.3 is that it 
>> generally implies that the device records prefixes on non-volatile 
>> storage. But there are valid reasons for which a device might be 
>> unable to (e.g., economical, if you wish).
>>
>> Then, the "MUSTs" elsewhere essentially try to signal how crucial 
>> implementation of each specific behavior is.
>>
>> Thoughts?
>>
>> Thanks!
>>
>> Regards,
>> -- 
>> Fernando Gont
>> SI6 Networks
>> e-mail: fgont@si6networks.com
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>
>>
>>
>>


-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best