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