Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18

Ralph Droms <rdroms.ietf@gmail.com> Sat, 31 May 2014 00:57 UTC

Return-Path: <rdroms.ietf@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0911A043C for <dhcwg@ietfa.amsl.com>; Fri, 30 May 2014 17:57:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 zOD-R5OMhjMi for <dhcwg@ietfa.amsl.com>; Fri, 30 May 2014 17:57:21 -0700 (PDT)
Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F2AC1A030D for <dhcwg@ietf.org>; Fri, 30 May 2014 17:57:21 -0700 (PDT)
Received: by mail-qg0-f50.google.com with SMTP id z60so7562837qgd.9 for <dhcwg@ietf.org>; Fri, 30 May 2014 17:57:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ag/TpYVTaEDJ5ky/+9WwaHI4Al7+TWXnJZ/5rmmkFek=; b=WT4UOxrfD4Vq1hpSY2kUN0Yb7jblEuVKaOZk3w0HSOM85NF3OCGX2GA0zJdIpdp+xf ucpjJH8c5NscfOuB29QtkLOepCvWbI0O4nt2pCsDKxI4lB5WPRsvE/+6DEwjhPreoLpo JS9L0ip+KA1Ssf5hmI7ZMZZb2/rssWM44S3bvEnAvuW/o5hd0caakGqArOKJBJRyB8X+ 2I1yrg+sD9Fc9HQ6uAbIvAyznz1H3OPsXik+tG/b8oWkrX2Djlp2g7t6eKyRBcVGQL2C T+jx0n8y+W6mqWKHAXKqoxZHGJVqcLRqlYKWhWtayE2zQNC/E6tt3dEPz7LYjSUVC1xu t/EQ==
X-Received: by 10.224.37.10 with SMTP id v10mr26243307qad.98.1401497836598; Fri, 30 May 2014 17:57:16 -0700 (PDT)
Received: from che-vpn-cluster-2-271.cisco.com (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPSA id b10sm8784698qag.31.2014.05.30.17.57.13 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 May 2014 17:57:14 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ralph Droms <rdroms.ietf@gmail.com>
In-Reply-To: <78B235AF-D94C-40F1-9C76-4159B3A0A043@nominum.com>
Date: Fri, 30 May 2014 20:57:12 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <F079574B-FF8A-4C8B-B562-0E0F8D4DC47F@gmail.com>
References: <535FEDAD.5010103@gmail.com> <5388F901.1000709@gmail.com> <78B235AF-D94C-40F1-9C76-4159B3A0A043@nominum.com>
To: Lemon Ted <ted.lemon@nominum.com>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/u1Ne8jQlMH4dZh4RXv8bLSNm1XA
Cc: dhcwg <dhcwg@ietf.org>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 May 2014 00:57:24 -0000

On May 30, 2014, at 8:47 PM 5/30/14, Ted Lemon <ted.lemon@nominum.com> wrote:

> On May 30, 2014, at 5:32 PM, Tomek Mrugalski <tomasz.mrugalski@gmail.com> wrote:
>> I think it is important to add a section that enumerates those and
>> similar use cases. Otherwise you risk that this work will be stalled
>> and you'd be asked to write a separate problem statement document.
> 
> A use case can't be theoretical.   You should have an actual use for it.   So I think documenting use cases like a "high security network" is pointless.   The point of this mechanism is to authenticate DHCP transactions in both directions using public keys.   Why do we need a list of use cases for this?   This is something we've been asked for for over a decade.   Does someone seriously think there's a different way to do this that's more appropriate?   If so, please explain!   Does someone think that the actual uses documented in the draft won't work?   If so, please say why.

In my opinion, there is a need in the document for an applicability statement that gives guidance about what this mechanism provides and in what situations it is useful.  I have come to this opinion because a precise understanding of exactly what the protocol will provide will be important to those considering its deployment.

- Ralph

> 
> I certainly think that if people want to suggest ways of clarifying the document, that would be beneficial, but let's not get carried away throwing the kitchen sink into the document for no good reason.   That makes it slower to review and is as likely to generate controversy as quell it.
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg