[v6ops] comments on draft-xiao-v6ops-nd-deployment-guidelines

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 22 October 2021 17:08 UTC

Return-Path: <mcr@sandelman.ca>
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 468573A1176 for <v6ops@ietfa.amsl.com>; Fri, 22 Oct 2021 10:08:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 m55eOtrtuSGB for <v6ops@ietfa.amsl.com>; Fri, 22 Oct 2021 10:08:32 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00:e000:2bb::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 407D33A1188 for <v6ops@ietf.org>; Fri, 22 Oct 2021 10:08:31 -0700 (PDT)
Received: from dooku.sandelman.ca (cpe788a207f397a-cmbc4dfb96bb50.sdns.net.rogers.com [174.116.121.43]) by relay.sandelman.ca (Postfix) with ESMTPS id B989C1F458; Fri, 22 Oct 2021 17:08:24 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 308791A0272; Fri, 22 Oct 2021 13:08:23 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Xipengxiao <xipengxiao@huawei.com>
cc: v6ops@ietf.org
In-reply-to: <2e52bafc6bf1420ba71107ec68a30be1@huawei.com>
References: <c439c632853b453cb57af2134a2741f5@huawei.com> <2e52bafc6bf1420ba71107ec68a30be1@huawei.com>
Comments: In-reply-to Xipengxiao <xipengxiao@huawei.com> message dated "Thu, 14 Oct 2021 07:05:40 -0000."
X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Fri, 22 Oct 2021 13:08:23 -0400
Message-ID: <462150.1634922503@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Jkqxz2k7uhVe1WHrswA8t7af-uI>
Subject: [v6ops] comments on draft-xiao-v6ops-nd-deployment-guidelines
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, 22 Oct 2021 17:08:38 -0000

XiPeng, Some editorial comments/questions first.
Are you using kramdown and/or xml format?  Or doing something with a Word macro?
I strongly recommend using kramdown format,
   https://www.ietf.org/live/previous/live104/ietf104-create-i-d-tutorial/
because then you upload XMLv3, and you get much more beautiful and readable
HTML.

What made me notice this is that "OPSECv27" reference is not linked,
and that document is now RFC9099.

I don't want to go through the document word for work.
I think that this is premature.  I think that the goals of the document are
clear, but I think that some restructuring is in order to meet the needs of
what I think are the intended readers.  I think that intended readers are a
variety of different operators.
A secondary list of readers are product managers at L2/L3 switch vendors.

The operator would say, "I'm deploying IPv6 in my XXX network using RFFyyyy,
method 4".  The vendor would say, "oh yes. wonderful. We support that, and
you want to read section zzz of our manual"

Section 2 has a lot of information, and is close, but not quite, a tutorial
on each mechanism. Perhaps that belongs in a series of appendixes.
I think that the better approach is to have a section two ask questions
(i.e. a self-assessment) as to what kind of scenario they want to do.
Some of the results might be aspirational vs actual.
As in, "I really want to get to UPPH support, but not all my hosts are
capable yet, so until then, I want MLSN"

I suggest that section 3 then more about characteristics of each solution,
and how each solution accomplishes the different goals.  The text there is
good, but I think it should come in a different order.

The Security Considerations will need to do a lot more.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-