Re: [dhcwg] Minor inconsistencies with draft-ietf-dhc-packetcable-04.txt

Ralph Droms <rdroms@cisco.com> Sun, 17 November 2002 14:38 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19028 for <dhcwg-archive@odin.ietf.org>; Sun, 17 Nov 2002 09:38:56 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAHEf5s20609 for dhcwg-archive@odin.ietf.org; Sun, 17 Nov 2002 09:41:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAHEf5v20606 for <dhcwg-web-archive@optimus.ietf.org>; Sun, 17 Nov 2002 09:41:05 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19025 for <dhcwg-web-archive@ietf.org>; Sun, 17 Nov 2002 09:38:25 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAHEcgv20531; Sun, 17 Nov 2002 09:38:42 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAHEXTv19897 for <dhcwg@optimus.ietf.org>; Sun, 17 Nov 2002 09:33:29 -0500
Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18919 for <dhcwg@ietf.org>; Sun, 17 Nov 2002 09:30:50 -0500 (EST)
Received: from rdroms-w2k.cisco.com (rtp-vpn1-128.cisco.com [10.82.224.128]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA12631; Sun, 17 Nov 2002 09:33:25 -0500 (EST)
Message-Id: <4.3.2.7.2.20021117090645.00b97c08@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sun, 17 Nov 2002 09:33:19 -0500
To: ted.lemon@nominum.com
From: Ralph Droms <rdroms@cisco.com>
Subject: Re: [dhcwg] Minor inconsistencies with draft-ietf-dhc-packetcable-04.txt
Cc: dhcwg@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>

This draft has an unfortunately complex history.  It was, in its original 
incarnation, in front of the WG at least 24 months ago.  The WG provided 
some feedback, but there was no followup from the authors, and the draft 
lapsed.

In the meantime, CableLabs decided to go ahead with the use of an option 
code from the "reserved for local use" range and defined an option and 
several sub-options.  Now, CableLabs recognizes that it would be a Good 
Thing to standardize the definition of that option through the IETF.  The 
starting point for the process was that non-standard definition.  The draft 
has gone through several revisions, with edits based on WG input (during WG 
last call) and Area Director input.

So, what we're seeing in the current PacketCable/CableLabs draft is a 
revision of what CableLabs has been shipping for some time, based on input 
from the dhc WG and the internet ADs.  Paul has taken the initiative for 
CableLabs to bring the CableLabs client configuration option into the IETF 
standards process.

Of course, ideally, we would have worked through the standard process with 
Cablelabs without the unfortunate delay and unilateral standard definition 
by Cablelabs.  Thomas Narten and I have been talking with CableLabs to come 
to an understanding about how to cooperate in the DHCP options standards 
process in the future.

- Ralph

At 10:47 AM 11/15/2002 -0600, Ted Lemon wrote:
>>The polarity flip will not be a big deal.  PacketCable/Cablelabs will 
>>vigorously oppose any further changes.  I need you both to understand 
>>that this option has been before the WG for over 18 months...with very 
>>active review over the last 6 months.  Why have you both waited so long 
>>to deliver this input...we are trying to ship product here !
>
>Your problem is that you have volunteers in your critical path.    The 
>IETF is a volunteer organization, whose purpose is to define internet 
>standards.   Its purpose is not to help you ship product.   Members do not 
>always have time to review your work when you want it reviewed, 
>particularly if it's presented late.   When someone does have time to 
>review your work, and finds a problem, you just have to deal with it.
>
>I have drafts on my critical path that have been stalled for way longer 
>than 18 months.     This is IETF's strength and its weakness.   One of two 
>RFCs I have been working on for about three years now *finally* advanced 
>this month, after being in last call for over a year.
>
>I first became aware of this draft in Yokohama - I'm not sure to what WG 
>you refer when you say 18 months.   Look, you know who the players are in 
>the DHCP community, or you should.   If you want people to read your 
>draft, the least you can do is ask them to.   I don't remember you coming 
>up to me and asking at IETF, and I've been to every IETF in the period you 
>describe.   Rich Woundy asked people in the DHC WG to read the draft in 
>Yokohama.   I skimmed it, but didn't have time for a careful read, so I 
>wasn't aware of the problem with this draft until Bud mentioned it.
>
>If, in the future, you would like to avoid this sort of trouble, I'd 
>suggest a couple of things.   First, present the draft to the working 
>group _as soon as you know what you want in it_.   Second, hire 
>consultants to look at it who are experienced with DHC and know the 
>issues.   Paid workers are more likely to read your draft.   That's lame - 
>this is a volunteer effort and all - but if you are in a hurry, you 
>shouldn't put volunteers in your critical path.   Ideally, hire the 
>consultants when you are writing the draft, so that you don't even go down 
>the wrong path.
>
>This is moot for the present moment - given that SIP has already broken 
>ground on this switch, I see no reason to oppose some other option using 
>it in the same way.   But I mention this because I think if you have 
>realistic expectations going into the process, you will get a better outcome.

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg