Re: [dhcwg] Last Call: <draft-ietf-dhc-option-guidelines-14.txt> (Guidelines for Creating New DHCPv6 Options) to Best Current Practice

Barry Leiba <barryleiba@computer.org> Fri, 25 October 2013 15:36 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C589011E818E; Fri, 25 Oct 2013 08:36:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.968
X-Spam-Level:
X-Spam-Status: No, score=-101.968 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3+eBinE4ioS; Fri, 25 Oct 2013 08:36:23 -0700 (PDT)
Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id D6F6D11E819B; Fri, 25 Oct 2013 08:36:14 -0700 (PDT)
Received: by mail-qc0-f169.google.com with SMTP id x12so2318891qcv.0 for <multiple recipients>; Fri, 25 Oct 2013 08:36:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gfT44Qn0ZTBcExal0hG8XrNz/AXNcqEOROLxsWbPN5M=; b=rqMx21OMCADixCWo9ccjQgzEpE1L/sw5dD0ocMI+Ma5uuwaN6Bosa554n4fGTBIB1n C1GZeK4GAgAYB79W6Av0RwNs0i5PwCquk6PHzQ6wVPU4T5mgze0VA3NwUyV9wEBHe6xS GXOulRrZAOD0jSiUOxmm9H0E3jh3QxQAY+Fb5FKuM3QL7nVYAf30Zv9b+Abm455LoLai cqXLbPeCWc4XEwcrRVCVVgKSrvLfNbIt3C/dCeOOiEMVQuAA+K626C4M0dggAPRrk1+Q YDYhQPZ+/Ed3K7jph8eq4UiDEAa5NVfGdT1vu+ZMJaJyuhr2+zPAd8kHQUWgOLXsNa0d /fBg==
MIME-Version: 1.0
X-Received: by 10.49.127.179 with SMTP id nh19mr11360766qeb.1.1382715370622; Fri, 25 Oct 2013 08:36:10 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.224.67.130 with HTTP; Fri, 25 Oct 2013 08:36:10 -0700 (PDT)
In-Reply-To: <A4943223-ADA7-4C3E-BF18-39756F673DB3@nominum.com>
References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com> <C5E08FE080ACFD4DAE31E4BDBF944EB123C933B2@xmb-aln-x02.cisco.com> <EF97C65E-A58C-4076-B737-014126786442@nominum.com> <C5E08FE080ACFD4DAE31E4BDBF944EB123C96CF3@xmb-aln-x02.cisco.com> <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com> <F474FA9D-CDC4-4DB7-937E-1252E203749F@iii.ca> <F1C4B4FB-DD91-43E3-8A01-226237BA68CE@nominum.com> <140C3FBE-AADA-420D-ADFD-80C929AF8EC3@iii.ca> <96FD71CE-ED4F-4F43-A24A-BAC991455C56@nominum.com> <C57B9F23-F8A7-422F-BFC6-F2ABB899B03D@iii.ca> <96AD4029-F81B-4BC5-90EB-D232F0A95A1A@nominum.com> <F769CC42-F242-42E6-9B40-31C875EA0156@iii.ca> <44771FA3-5660-45CB-AE84-3458C7DA4D87@nominum.com> <63557975-9AE8-4C5C-A120-9E3C7E5C84A1@iii.ca> <A4943223-ADA7-4C3E-BF18-39756F673DB3@nominum.com>
Date: Fri, 25 Oct 2013 11:36:10 -0400
X-Google-Sender-Auth: 1H6CfcFaLkFVXmJAmMwkEjICD3g
Message-ID: <CALaySJJR+XXbPGtzXEAOZKNTSy_HZFh6neGUiamjPay=J1W5pQ@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Ted Lemon <Ted.Lemon@nominum.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "dhcwg@ietf.org WG" <dhcwg@ietf.org>, "ietf@ietf.org Discuss" <ietf@ietf.org>, Cullen Jennings <fluffy@iii.ca>, The IESG <iesg@ietf.org>
Subject: Re: [dhcwg] Last Call: <draft-ietf-dhc-option-guidelines-14.txt> (Guidelines for Creating New DHCPv6 Options) to Best Current Practice
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 25 Oct 2013 15:36:24 -0000

>> Ted, as an IESG member, are you really sticking to a that the meaning of a BCP?
>
> Working groups are where IETF consensus comes from.   The IETF mailing
> list review is there to see if the IETF disagrees with the working
> group consensus.   I'm trying to explain to you, the only (late)
> dissenter in the IETF last call, why I think the IETF should have
> consensus to publish the DHC working group's advice about how to
> implement DHCP options as a BCP.   I'm doing this because I think that
> it is the right thing.   If you think it's the wrong thing, at least
> do me the courtesy of walking me through your reasoning.
>
> Can you make a clear argument for why some RAI working group, and not
> the DHC working group, should be the one to offer advice on how to do
> DHCP options?   Would you, for example, want sipping to be where
> advice on how to do new DNS RRtypes comes from?

Really, now, this is over the top.

First, BCPs have IETF consensus, and are applicable across the IETF.
When you said that "RAI working groups are free to go against these
recommendations," you were completely wrong, and the IESG should and
would slap them down if they did.

Second, anyone who participates in the IETF can bring up issues, as
IETF consensus is built.  The output of working groups doesn't have
any magical force field protecting it from challenges from others.
The working group consensus means a lot, of course, but reasonable and
reasoned arguments still have to be addressed.

Third, your second paragraph above is really out of line.  So let's
back away a bit and look at the picture we're painting.

No one has tried to say that some other working group should be
telling people how to use DHCP.

What several of us have said, and what Cullen is saying, is that
various protocols (including some in the RAI area) are using DHCP to
get their configuration information.  Nothing theoretical: they ARE.
And that use has already been approved with IETF consensus.  So IF the
DHC working group means to say that such use by those protocols in
that way is ill advised, it needs to be explicitly clear about that,
and the issue needs to be discussed and have IETF consensus.
Otherwise, the document's recommendations need to be clarified to say
that this is legitimately done to configure application-layer
protocols, and different recommendations may apply to those.  Ideally,
it would give those recommendations as well.

So, one or the other:
- say "don't do that; it's bad, and here's why," *and get IETF
consensus on that*, or
- say "different recommendations apply in those situations, and here
are those recommendations," *and get IETF consensus on that*.

Barry