IETF mission (RE: pausable explanation for the Document Series)
Bound, Jim
Jim.Bound at hp.com
Sun Jun 8 00:10:08 CEST 2003
This will work and good idea. But it should not be a red herring for
the IESG to use and really keep PS as high bar and not hear Bob Hindens
input.
/jim
> -----Original Message-----
> From: Ralph Droms [mailto:rdroms at cisco.com]
> Sent: Friday, June 06, 2003 8:08 AM
> To: problem-statement at alvestrand.no
> Subject: Re: IETF mission (RE: pausable explanation for the
> Document Series)
>
>
> Regarding Brian's call for radical thinking...
>
> Is the problem:
>
> the 3 step standards track is largely fictional
>
> the root problem or just a symptom?
>
> I think it's just a symptom of a mismatch among industry
> uses for IETF standards, WG processes and IESG goals.
>
> The current *usage* of the standards track effectively
> has a single hurdle at PS. I suggest we need to devise
> a process and set of hurdles that include some intermediate
> states that are not well-defined in the current usage of the
> standards track.
>
> One of the important states that is missing today is
>
> stable specification used for prototyping
>
> My recent experience with specifications in the dhc WG
> has been that "running (prototype) code" trumps
> (potentially ad infinitum) speculative discussion about
> whether the protocol is correct and completely
> specified.
>
> The design problem, of course, is devising the right
> document classifications and process to strike a balance
> among nimbleness (getting to a stable specification
> quickly), correctness and allowing for changes after
> the prototypes have been developed (avoiding the
> "we've deployed the prototype and now we can't change
> the protocol" problem)...
>
> - Ralph
>
> At 01:50 PM 6/6/2003 +0200, Brian E Carpenter wrote:
> >john.loughney at nokia.com wrote:
> >>
> >> Hi Charles,
> >>
> >> > I also wholeheartedly support the inclusion of an applicability
> >> > statement whenever it makes sense. However, I also suggest that
> >> > the protocol SHOULD (within engineering discretion) not
> >> > intentionally restrict its applcability to the situations
> >> > delineated in the applicability statement.
> >> >
> >> > I would restate Postel's maxim:
> >> >
> >> > Be conservative in the claimed applicability, but
> generous in the
> >> > potential applicability.
> >>
> >> What I am concerned about is there seems to be a movement
> to make a
> >> super-PS, one which would be the equavalent of a DS & have
> no bugs.
> >> I am not sure of the feasibility of this, but I have noticed that
> >> simple protocol documents are getting overloaded with a lot of
> >> applicability info, deployment concerns, best practices and
> >> implementation guides. Somehow, I think overloading a single
> >> document with this info, is not a reciepe for success.
> >
> >In any case, since we don't actually use the complexity we
> already have
> >(3 grades of standard), the need is clearly to
> >*simplify* the document scheme, not to complicate it. My thinking is
> >getting more radical the longer this discussion continues.
> Let's think
> >seriously about
> >
> > Problem: the 3 step standards track is largely fictional
> >
> >and possible solutions along the lines of
> >
> > Solution: let's scrap it and have all "standards" RFCs as a single
> > level (with recycling in grade for corrections/updates).
> >
> > Brian
>
>
More information about the Problem-statement
mailing list