The need for smaller protocol specifications

[Bound, Jim]

I agree with Charlie but not hearing anyone comment?

Maybe I am paranoid but here is what I hear happening:

1.  Bob Hinden suggested an idea for time to market.  Not one IESG
person said this is a good idea not as IESG person but folks who have
IESG experience.

2.  Charlie gives below I think accurate description at a minimum a
problem we face. Again no IESG response here.

It could be we are still in define problem space so discussion solution
is not time.  Or anything we propose that fixes anything other than an
intergalitic high level process will not be discussed and esp by the
IESG members not as IESG members but as persons in that role with
experience.

Chairs I have to ask where are you at with the above two bullets if
adopted they clearly require a change and action by the IESG.  It feels
to me the IESG and even past IESG persons don't want to do anything that
causes that?  Thats my read of all these threads.
We are experiencing the same problems on this mail list we are
discussing.
What are your thoughts?  If we are just going to flirt with fixing
problems again I see not point in continuing.  This is exactly what the
ADs do too. A member makes a very logical base statement as the two
above and then we get silence from ADs.  Why?  IMO because it shows a
problem in their ranks and they won't admit it.  But all here are more
than willing to blast WGs, Chairs, and Authors.  This list is proving
there is a problem real time.  It is happening before your eyes.
Another IESG member blasted vendors twice this weekend.  I asked them
will you stop this?  No answer and none privately.  If I was not a nice
guy I would send that mail directly to Sr. VPs I know in those companies
and say here is what IESG member said about you on a public mail list.
But I am trying to be a nice guy.  The key problem with IESG is they
think they are beyond the rules and basic codes of engineering
discussion and responding to questions.  Or they don't answer the
question as engineers but as politicians with quip mores and folkways
that are not answers to the questions.  How do we document this problem?
I simply do not know.

thanks
/jim

> -----Original Message-----
> From: Charlie Perkins [mailto:charliep at IPRG.nokia.com] 
> Sent: Monday, June 09, 2003 3:28 PM
> To: Harald Tveit Alvestrand
> Cc: problem-statement at alvestrand.no
> Subject: Re: The need for smaller protocol specifications
> 
> 
> 
> Hello Harald,
> 
> I agree with your statements, and I wonder if you see the 
> value of my argument.
> 
> Do you think that protocol specifications today are (generally
> speaking) too complicated, about right, or not yet complicated enough?
> 
> Regarding "good for AT LEAST ONE THING", does it
> mean there has to be a killer app?  What about IPv6--?
> 
> Regards,
> Charlie P.
> 
> 
> 
> Harald Tveit Alvestrand wrote:
> 
> > 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
> >
> >
> >
> >
> >
> 
> 
>