Ralph Droms rdroms at
Wed Feb 19 09:51:31 CET 2003

I can follow up on Margaret's first paragraph with first-hand experience 
with DHCPv6.  The spec was accepted as PS just a couple of months ago.  We 
had four implementations to test at the TAHI interop event.  Based on the 
results of the interop testing, we identified about 10 issues that require 
some amount of clarification or other editing in the spec (we have 
consensus among the authors and some of the participants at TAHI that none 
of the issues require fundamental changes to the protocol).  I will publish 
an I-D describing the issues and giving explicit changes to 
draft-ietf-dhc-dhcpv6-28.txt (the rev accepted for RS) to resolve the 
issues.  We expect to make these changes during the authors 48 hour edit 
period prior to publication of the RFC.

I consider this a good outcome; at the same time, I think it's a creative 
interpretation of the current process.  I think a better process might have 
been, as Margaret describes, to have a stable spec as of a year ago.  The 
changes we've identified are based on real interoperability experience (no 
deployment experience yet).

Perhaps a twist on Margaret's proposal would be to initiate IESG review of 
the initial stable spec in parallel with implementation, interoperability 
and deployment experience.  The DHCPv6 spec hasn't changed much - most of 
the changes have been in the security area - as a result of the IESG review 
over the last several months.  The results of our interoperability testing 
and the IESG review could be, I think, integrated into the final spec at 
the same time.

Finally, I understand that the history of DHCPv6 is atypical of IETF specs 
and I don't claim that we should look at the recent experience with DHCPv6 
as a definitive source of input...

- Ralph

At 09:30 AM 2/19/2003 -0500, Margaret Wasserman wrote:

>Another thought on this point...
>If it were easier to get documents to PS faster, we might
>actually be able to improve them on the road to DS.  Right
>now, it can be very difficult to get a WG to change a
>document between PS and DS (based on implementation experience,
>etc.) because it has usually been several years before the
>document reaches this point, and there may be many, widely
>deployed implementations that have the force of law in the
>What we need is a way to:
>         (1) Quickly create a stable document for a potentially
>                 useful standard (this is what PS should be).
>         (2) Refine that standard based on early implementation
>                 and deployment experience (While it is still
>                 early in the implementation and deployment!)
>                 into a mature standard that is ready to be
>                 widely deployed (DS).
>         (3) Acknowledge that a standard is working well in
>                 wide-scale deployment (FS or STD).
>By creating a higher hurdle for the first step (PS) we are
>actually breaking the whole process...
>The entire perfection/refinement phase is happening during
>the PS publication process, before we have actually determined
>that the potential standard has been implemented and found
>to be useful in practice.  In some cases, this is a big waste
>of time, because we expend a lot of effort to "perfect"
>something that never gets used.  In other cases, it is even
>more damaging, because we diddle endlessly with a useful
>standard, driving up the costs of its initial implementation
>and deployment, and creating resistance to later changes.
>It would be much healthier and more effective to use a
>lighter weight process for initial publication, and to
>refine and perfect standards _after_ we have the initial
>implementation and deployment experience.
>At this point, though, the current terminology has acquired
>a great deal of baggage.  So, it might be necessary to
>re-name the phases in order to change their meaning.
>At 09:19 AM 2/19/2003 -0500, John C Klensin wrote:
>>--On Wednesday, 19 February, 2003 20:46 +0700 Robert Elz 
>><kre at munnari.OZ.AU> wrote:
>>>This is also (IMO) contributing to the (IMO unreasonable)
>>>demand for perfection in everything published as a PS, because
>>>most people realise that for most documents, that's as far as
>>>they'll ever actually go. Not because they wouldn't qualify
>>>for more, but because no-one has enough interest in doing the
>>>extra work.
>>Let me suggest a different, but equally problematic, interpretation of 
>>the same data.  If the IESG (and RFC Editor ?) insists on perfection at 
>>PS, doing so sufficiently exhausts people and process that there is no 
>>energy for doing the work to advance the document further.  In this 
>>model, a lighter-weight approach to PS might produce somewhat weaker 
>>documents, probably much more rapidly.  Such documents, and the reduced 
>>level of burnout from producing them, might then provide both more 
>>incentive and more energy for going to Draft.
>>Same issue, same symptoms, different cause and effect hypothesis.  It is 
>>probably worthwhile to document both hypotheses.
>>    john

More information about the Problem-statement mailing list