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

[Ralph Droms <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg