Standards
Ralph Droms
rdroms at cisco.com
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
>market.
>
>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.
>
>Margaret
>
>
>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.
>>
>>regards,
>> john
>
>
More information about the Problem-statement
mailing list