The need for smaller protocol specifications

[Bound, Jim]

Harald,

That was a good example below.  A very good one.  It gets to the
engineering trade off and I do think there is a responsibility to fix
that which can break in some way with other sceanrios.  Where we may be
failing is that we have to ship for the one scenario and we document
better the failure modes in other scenarios or where we simply do not
know. But I think it good to ship it and tell the market do it this way
any other way is at your own risk.  I feel fine and comfortable with
that risk its their trip and they own the trip not us.  The market will
always find dumb things to do with what we produce and also smart things
to do with what we produce.  If we keep trying to redue the risk for the
market by missing time lines for technology the market will not support
us.  That is one of our customers.

This is where we may have divergance on the list here and important
point of discussion.

/jim

> -----Original Message-----
> From: Harald Tveit Alvestrand [mailto:harald at alvestrand.no] 
> Sent: Monday, June 09, 2003 3:15 PM
> To: Charlie Perkins; problem-statement at alvestrand.no
> Subject: Re: The need for smaller protocol specifications
> 
> 
> Charlie,
> 
> clipping mercilessly from your message....
> 
> --On mandag, juni 09, 2003 11:20:52 -0700 Charlie Perkins 
> <charliep at IPRG.nokia.com> wrote:
> 
> > Another way to say this, is that we are being required to specify 
> > entire systems instead of protocol components.  I think 
> this is a very 
> > bad idea.  I think the IESG should sincerely reconsider 
> this policy, 
> > and let protocol specifications be published EVEN IF they 
> do not solve 
> > the entire problem domain, but just a part of it. 
> Typically, the part 
> > that the original protocol specification DOES solve, will be 
> > implemented and tested for interoperability.  The other stuff that 
> > gets glued on will just sit there like a dark jungle.
> 
> The way I thought of it in the apps area 5+ years back was 
> that a proposal 
> has to document that it is good for AT LEAST ONE THING. (I 
> failed that at 
> times - for instance with TIP, which I still don't know if 
> anyone uses).
> 
> We (the IETF) want to standardize useful protocols. If there 
> isn't at least 
> one scenario where the protocol is clearly useful, I see 
> absolutely no 
> reason to standardize it. So describing the scenario, 
> including all the 
> bits and pieces from other protocols that have to be there in 
> order to make 
> the protocol useful in that scenario, is, to my mind, a 
> necessary part of 
> documenting the protocol.
> 
> On the other hand - if a scenario is described, and it's 
> obvious that 5 
> mins after the protocol-implementing product hits the street, 
> it will be 
> used in another scenario, where the proposed "supporting 
> bits" are clearly 
> going to lead to undesirable situations (I'm thinking about 
> SNMPv1 and the 
> "community string" here, for instance), then we as a community have a 
> responsibility to describe those scenarios too, and 
> provide/reference the 
> adequate mechanisms for those scenarios. For instance by 
> saying that all 
> IPv6 implementations MUST have IPSec support (the "Danvers 
> Doctrine"), or 
> saying that applications MUST behave in the face of 
> congestion (RFC 2914).
> 
>                  Harald
> 
> 
> 
> 
> 
>