Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-dhc-problem-statement-of-mredhcpv6-05

Christopher Wood <caw@heapingbits.net> Mon, 25 May 2020 14:05 UTC

Return-Path: <caw@heapingbits.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A85B3A07F5 for <secdir@ietfa.amsl.com>; Mon, 25 May 2020 07:05:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=heapingbits.net header.b=QMc5lSDb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=vIDRSflD
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 nSs1mxa_hXZ2 for <secdir@ietfa.amsl.com>; Mon, 25 May 2020 07:05:11 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D3683A0C1B for <secdir@ietf.org>; Mon, 25 May 2020 07:05:11 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 8E3955C0192; Mon, 25 May 2020 10:05:10 -0400 (EDT)
Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Mon, 25 May 2020 10:05:10 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=KUtgqLqH3Yzqkm59wjgJrUUbnLFI VJM38Kc6YwopFTY=; b=QMc5lSDbYR4Y6FswwhAzLwo7DHQ8ddIZOI4q28EpK7ih A60sUluZmIqBisUbwY192Wp84qX3Vb1rWd4Np8h5DfalIwdoBerVyb0L6X0lBZYh k+TqFfWnhivY2pTYlhVpdgIN5daqfCrM4xavoudoaGLcYW7zi7SwnwE8ecrzT9d1 f08T74+A2CMvqghcN2IUW/NBiNg6KwdW698WOw4KbffOkfLRAhRe9nYWxz1UBUlu VAbsY2W0PFxAt+JymC8G/wGOvNDVYty1ITIKI1kinSnl/f9fuAgvljroDIzkoWzd w2N8QL1RlIyorUg3DuQA0aBrZ+uId5XQv5nrUaMEOQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=KUtgqL qH3Yzqkm59wjgJrUUbnLFIVJM38Kc6YwopFTY=; b=vIDRSflDdNHlmdA/m7lCNM bCsti6++YYirkcsV/t4ouRyGgglTaajrexZ7vqmBA5zWHC5x6bbw4PVo/l7u2ABU XQi6Wx86lR0sP5fqUS10bmsn39bGp3M03SR8JQBFd/KfnFlHCTdjYqj1ydBbIocQ w3ITGZhnwk5e2ShuD9/7cm0ekOFJsrpgGr6PgYJShQ+ZX5mnEnsLECUMTk+jY9wI th664bpG7tRw1k39BkWUadfSlYRKgn3cFUX6QUxOXM/iN8U3yr6T2alaMR6YOEF8 m7E67UfHP9R7lSiXYGIsLCYF7odDUd6E5SEutaps0fmMNIb8q73C2HZl9TWmtObw ==
X-ME-Sender: <xms:ltDLXpXTTKQ3i3N0rToqd-P5yubTt-Uk-cvzehw3N3IO8BvKMbNS0g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvtddgjeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdevhhhr ihhsthhophhhvghrucghohhougdfuceotggrfieshhgvrghpihhnghgsihhtshdrnhgvth eqnecuggftrfgrthhtvghrnhepudffteffkeevhfdvueehffegteefgeelveegffefvdev jeehvdeugeekheelvdelnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhg sghithhsrdhnvght
X-ME-Proxy: <xmx:ltDLXpkQIIbjRyNK7ENzjTi-9OPnUwiQfVOpm5uKaLFEVuiJf-kohA> <xmx:ltDLXlbf_NzRTJHvro0sIjOziBgsujy99PyTG_Ew8xanR3ik-uhuAA> <xmx:ltDLXsXHfQRpWDBhKeO1__T8ndRT7u6CAiWJ6o8LT2Di32csyz46TQ> <xmx:ltDLXvw7KpHXDndk-BXlFAd45skQA8qMfr7NOa-ICnTQgk4kScqnPg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 360923C00A1; Mon, 25 May 2020 10:05:10 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-488-g9249dd4-fm-20200522.001-g9249dd48
Mime-Version: 1.0
Message-Id: <94c2afbe-c621-424e-8ac3-f7d28f7c80bc@www.fastmail.com>
In-Reply-To: <20200524231513.GN58497@kduck.mit.edu>
References: <158993226788.7058.12159366851189346862@ietfa.amsl.com> <20200524231513.GN58497@kduck.mit.edu>
Date: Mon, 25 May 2020 07:04:49 -0700
From: "Christopher Wood" <caw@heapingbits.net>
To: "Benjamin Kaduk" <kaduk@mit.edu>
Cc: "secdir@ietf.org" <secdir@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/xc2JdJyeXw5NgzUui6BHRVmyJCo>
Subject: Re: [secdir] =?utf-8?q?=5BLast-Call=5D_Secdir_last_call_review_of_dr?= =?utf-8?q?aft-ietf-dhc-problem-statement-of-mredhcpv6-05?=
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 May 2020 14:05:18 -0000

My pleasure! I'm happy to take another look at future revisions if needed.

Best,
Chris

On Sun, May 24, 2020, at 4:15 PM, Benjamin Kaduk wrote:
> Thanks for the review, Chris!  I skimmed the doc and agree that the main
> point is not readily apparent; hopefully it will get some edits before it
> comes to the IESG.
> 
> -Ben
> 
> On Tue, May 19, 2020 at 04:51:07PM -0700, Christopher Wood via 
> Datatracker wrote:
> > Reviewer: Christopher Wood
> > Review result: Serious Issues
> > 
> > Summary: Series Issues
> > 
> > Comments:
> > 
> > - Section 1. The introduction needs a lot of work. It seems to be trying to say
> > something, but I cannot tell what that is. It's claimed that many documents
> > attempt to extend DHCPv6, yet no extensions are cited. There's mention of
> > "multi-requirement extension problems," but no example of such a problem.
> > There's reference to the possibility of administrators modifying DHCPv6 code
> > (and possibly breaking things in the process), but that does not seem relevant
> > to or follow from the previous text. Please revise this entire section and make
> > the goal clear. What is the problem being solved, why is it important, and what
> > is the summary of the proposed solution?
> > 
> > - Section 3.2. This section seems largely irrelevant. What is its purpose? It
> > mainly documents software support, rather than "extension practices."
> > 
> > - Section 4.1. Figure 1 could benefit from some descriptive text to match the
> > diagram. For example, it's clear how "options" are points of extensibility, but
> > how are "message processing functions" points of extensibility? An example
> > might help clarify.
> > 
> > - Section 4.2.3. What does "not all DHCPv6 software considers this extension"
> > mean? Does it imply that not all server implements support for this extension,
> > or something else?
> > 
> > - Section 5. This seems to be the crux of the document, yet I failed to glean
> > much from its contents. There are some examples of extensions which may require
> > multiple more than one "moving part," such as (1) client identity transmission
> > and (2) server use of those identities for address allocation. Is there
> > guidance that should be followed for specifying this type of multi-requirement
> > extension? If so, what is it? (Is that not the whole point of this document?)
> > Are there considerations administrators or specification writers should be
> > mindful of when designing these extensions? If so, what are they?
> > 
> > In general, it seems that if a document is to emphasize considerations for
> > folks, then those considerations out to be clearly articulated. Instead, this
> > document seems to just list some examples (current practices) without any
> > further insight. This makes me question its overall value for the community.
> > 
> > Nits:
> > 
> > - Section 1. "The IP address plays a significant role in the communication of
> > the Internet." Did this mean to say communication *on* the Internet?
> > 
> > - Please remove unnecessary gender terms from the document ("his").
> > 
> > - This text:
> > 
> >    For example, considering such a requirement that
> >    DHCPv6 servers assign IPv6 addresses generated by user identifiers to
> >    the clients in a network to hold users accountable, two extensions
> >    should be fulfilled to meet this requirement.
> > 
> > Could probably be simplified. Also, what does it mean for an extension to be
> > fulfilled?
> > 
> > 
> > -- 
> > last-call mailing list
> > last-call@ietf.org
> > https://www.ietf.org/mailman/listinfo/last-call
>