Subject: RE: IETF mission (RE: pausable explanation for the Document Series)

From: "Bound, Jim" <[email-masked]>
Date: Sat, 7 Jun 2003 22:39:28 -0400

Every spec MUST have applicability statement or it should not get past
the RFC Editor even for experimental.

/jim

> -----Original Message-----
> From: Harald Tveit Alvestrand [mailto:[email-masked]] 
> Sent: Thursday, June 05, 2003 6:34 AM
> To: [email-masked]; [email-masked]
> Subject: IETF mission (RE: pausable explanation for the 
> Document Series)
> 
> 
> 
> 
> --On torsdag, juni 05, 2003 11:36:04 +0300 
> [email-masked] wrote:
> 
> >> The more-core problem is industry running on protocols with design 
> >> flaws and protocol bugs, which cannot be fixed because of the 
> >> installed base.
> >
> > Depends upon how you look at things.  I would say that the 
> more-core 
> > problem is that our quality control may be less than ideal.  As the 
> > IETF is not a protocol enforcement agency, what the 
> industry does with 
> > what we make is beyond our control, in my opinion.
> 
> actually this comes back to the IETF mission statement thing....
> 
> if the mission of the IETF is to "make the Internet work", with our 
> particular task in pursuit of that mission being to "make 
> high quality, 
> timely standards for the Internet", then flaws in the 
> standards that the 
> industry runs on are signs that we haven't achieved our mission.
> 
> I don't think we can assert "control", in the sense of "I decide, it 
> happens" - if I asserted that I was in control of the IETF, 
> I'd be as silly 
> as if the IETF claimed that it was in control of the Internet.
> 
> But I do have influence over what the IETF does (and so do 
> you), and the 
> IETF does have influence over what the industry does.
> 
> Might be semantic quibbling .... then again, it might 
> actually matter when 
> we decide what to do.
> 
> >
> >> If PS was perfect, this would not be a serious problem. 
> But it isn't 
> >> so.
> >
> > This touches on the relevant issue.  Should PS be perfect? At what 
> > level do we raise (or lower) the bar?  What can we do about it? One 
> > possibility would be that we make sure that PS documents are as 
> > perfect as possible (raise the bar).  Another could be to 
> require some 
> > sort of best practices document for most major PS documents (which 
> > would capture operational issues, etc).
> 
> RFC 2026 invented the term "applicability statements" - 
> that's a term that 
> seems to have fallen by the wayside......
> 
> >  Another
> > could be your Maintenance Team idea, especially if it is 
> coupled with 
> > an object that captures all of the relevant RFCs, drafts in 
> progress, 
> > bug reports, etc.  I also think that if we go the route of 
> Maintenence 
> > Teams, perhaps the object could also preserve any issue 
> lists created 
> > during WG / IETF last call.
> 
> The "protocol, its current state and history book" site? 
> Seems to make 
> sense to me..... much of ancient history is actually 
> preserved in various 
> archives, but it can be VERY hard to find......
> 
> Nice thought!
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 7 Jun 2003 22:46:00 -0400

This is not to Charlie.
 
> Be conservative in the claimed applicability, but generous
> in the potential applicability.
  
I disagree with this and its orginal words for many reasons.  It says
NOTHING in logic only in emotion.  And with 911 and SPAM being liberal
in what one receives is history. Customers don't want to hear this.  I
understand well the implememtation of TCP and how that particular and
other transport code works and that part I take as what John was
speaking about.  But these great words have become a political football
for people to tout a strategy when they really don't have a strategy or
a clue at a moment when they believe they want to respond.  Or in the
evil case when they want a backdoor to put proprietary vendor extensions
in their product and force behaviors on SDO protocols in that manner and
that John never meant't to be I strongly believe.

/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 7 Jun 2003 23:10:08 -0400

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

> From: Ralph Droms [mailto:[email-masked]] 
> Sent: Friday, June 06, 2003 8:08 AM
> To: [email-masked]
> 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:
> >> 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
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 7 Jun 2003 23:22:38 -0400

I vote for this.  But would need grandfather for that preceding this or
the market will feed the IETF to pigs :-)

/jim

> From: Eric Rosen [mailto:[email-masked]] 
> Sent: Friday, June 06, 2003 10:58 AM
> To: Brian E Carpenter
> Cc: [email-masked]
> Perhaps we  need to  understand better  just what problem  we 
> are  trying to solve by revising the categorization of standards. 
> 
> I'd make two observations: 
> 
> 1. Nobody  cares  whether  the  IETF  says  that a  protocol  
> is  ready  for
>    deployment or  not.  Service providers, vendors,  
> enterprises, etc., will
>    decide this for themselves. 
> 
>    By "nobody", I mean "nobody who is  in a position to 
> decide whether to do
>    any large scale deployments".  In the old world of the 
> ITU-T people don't
>    deploy  until the  standards  process  is finished,  which 
>  leads to  (a)
>    bizarre standards  and (b) slow progress.   That may have  
> been okay when
>    telecom providers were monopolies, but  it is not okay in 
> the competitive
>    environment of today.
> 
> 2. People  do care  about whether  the protocol  has a  
> public specification
>    which  is sufficiently detailed  so as  to enable  
> interoperability among
>    multiple independent  implementations.  However, they will 
>  not wait (nor
>    should they) for such a specification before deployment.
> 
> Based on these observations, there  has arisen a significant 
> constituency in the IETF  (though not seen much on  this 
> list) which believes  that the only proper  function  of  the 
>  IETF  is  to  publish  specifications  which  are 
> multi-vendor interoperable.  Members of  this constituency 
> see no benefit at all for IESG  review.  Members of this 
> constituency  would also be overjoyed
> if  all  their   specs  could  just  get  published   as  
> "Experimental"  or
> "Informational", and once the specs  get published, they have 
> no interest in moving them further along in the process.
> 
> Most people  on this list seem  to think that there  is a 
> value  in having a category  of  "standard"  which  means  
> something  more  than  "multi-vendor interoperable."  But I  
> don't think there is a clear  consensus on just what we want 
> that to mean, and that's one of our big problems. 
> 
> Some possible considerations are: 
> 
> - correctly achieves the function which it is intended to achieve
> - adequately address scalability and security considerations 
> in the intended
>   scope of applicability
> - adequately (though not excessively) flexible 
> - not a lot more complicated than it needs to be
> - can be reasonably defended against alternatives
> - specification is competently and professionally done
> - impact on other areas has been addressed
> - there exists significant interest in deploying this
> 
> etc. 
> 
> To  me, it makes  sense to  have a  standards category  which 
> says  that the specification is not merely adequate  for 
> interoperability, but also that it has been judged against 
> these other considerations.
> 
> Considerations often cited which I don't agree with: 
> 
> - must not be intended for uses which violate my personal values
> - must not  be intended for uses which  violate my idea of  
> how the Internet
>   should be used
> - must not be intended for uses which allow Service Providers 
> to add value
> - must not violate some alleged philosophical principle 
> articulated 25 years
>   ago 
> - must  not  make  it  more  difficult  to  write  
> multi-party  peer-to-peer
>   applications
> - must have the highest conceivable level of security
> - guaranteed bug-free
> 
> Based on the considerations I think are important, I don't 
> understand why we need  more than one  category of  standard, 
> so  I would  tend to  agree with
> Brian: "let's scrap it all and  have a single level (with 
> recycling in grade for corrections/updates)." 
> 
> 
> 
> 
>