The need for smaller protocol specifications

[Erik Nordmark]

Did you intend to send this to the list? Read like more of a personal note

to me.



Let's discover what good beer we can find in Vienna and chat then!!

When will you arrive? I'm coming in Sat afternoon and have an IESG meeting

part of Sunday.



  Erik

>----- Begin Included Message -----<

Date: Thu, 3 Jul 2003 00:53:23 -0400
From: "Bound, Jim" <jim.bound at hp.com>
Subject: RE: The need for smaller protocol specifications
To: "Erik Nordmark" <Erik.Nordmark at sun.com>, "Charlie Perkins"
<charliep at IPRG.nokia.com> Cc: problem-statement at alvestrand.no, "Bound, Jim"
<jim.bound at hp.com>

Erik,

I am off this list but your catching up on old email I guess.  I will
respond to you privately engineer to engineer not IETF politician to
politician which I will not even bother with anymore and ignore.  

But there was something else that came up and as you ship products too,
is that the IETF needs to ship a product faster and leaner and more
often.  Never has the IETF been the subject of concern in the industry
as it is today many factions, entities, and governments are highly
concerned the IETF has lost it completely to achieve time to market.  I
am on vacation now and your one of the few humans on the planet that I
will respond to in the all to infrequent exercise of doing something
besides our technology work/life.

Or we can talk in Vienna privately.  The problem is treat this work here
with a deliverable and fix the IESG work load.  There are individual
problem children across the IETF with bad manners, impolite, and a
legend in their own mind.  So what!! they exist everywhere in all
aspects of life and here in the IETF.  It is unfortuneate when they are
leaders but that happens too.  But if you all focus on time-to-market
and the mass numbers of specs using SIR or some other such group most of
the problems that can be resolved will  begin to get fixed.

To bad you left the IESG and that put me over the top, after the Nomcom
decided Scott should not stay, for now I give up and will watch the IESG
on my work in detail.  But given your rationale I would have done the
same and why I am riding my harley around the east coast and your
resignation influenced me too, so in that respect thanks for that
"honest" open mail.  Like common sense that is rare to see these days.

/jim

> -----Original Message-----
> From: Erik Nordmark [mailto:Erik.Nordmark at sun.com] 
> Sent: Wednesday, July 02, 2003 12:11 PM
> To: Charlie Perkins; Bound, Jim
> Cc: problem-statement at alvestrand.no
> Subject: Re: The need for smaller protocol specifications
> 
> 
> > I'm going to try to describe what I see as a major problem, but the 
> > solution is not a black-and-white cure-all rule.  It's more 
> a matter 
> > of perspective, balance, and judgement.
> > 
> > Put simply, protocol specifications are being required to 
> contain too 
> > many features.  In my favorite example, a very simple signaling 
> > protocol specification was eventually required to also incorporate 
> > other related specifications:
> > - A discovery algorithm
> > - A key distribution algorithm
> > - Renumbering algorithms
> > - Compatibility recipes for an incompatible security protocol
> > - other stuff too.
> 
> Let me try to add my 2 cents on this topic even though I'm 
> behind on the list.
> 
> The way I would characterize the problem is that the 
> protocols the IETF undetakes today might take a longer time 
> to develop because:
>  - the problem is harder - we've solved the easy problems already
>  - we as a community place higher requirements (for instance, 
> deployable security
>    for the protocol; congestion control; and we might desire 
> less manual   
>    configuration; etc)
>  - interaction with other artifacts, whether our own protocol 
> specifications
>    or something else that is deployed on the net.
> 
> If you look at the third bullet alone for Internet Area stuff 
> there is an amazing list. Making it concrete using mobile 
> IPv6 (Charlie's example) I immediately come up with:
>  - interaction with DHCP (assigned home and/or care-of addresses)
>  - interaction with stateless addrconf (assigned home and/or 
> care-of addresses)
>  - interaction with RFC 3041 temporary addresses (assigned as 
> home and/or 
>    care-of addresses)
>  - interaction with IPsec for protecting the data traffic (as 
> opposed to
>    using IPsec to protect the Mobile IPv6 signalling protocol itself)
>  - interaction with renumbering (the home link and/or the 
> visited link)
>  - combinations of the above...
> 
> For other protocols there might be concerns about other 
> interactions, such as 
> interaction with NAT boxes in the path. Presumably there are 
> other lists that are more pertinent for other parts of the stack.
> 
> My point isn't about Mobile IPv6 or the individual items in 
> the above lists, 
> but about the total complexity of the space.
> 
> I suspect that as a result of this, protocol specifications 
> become longer and more complex and, even if the solutions to 
> deal with individual pieces are separable, in order to get 
> the protocol approved it might be necessary to deal with 
> many, if not all, of the issues.
> 
> Presumably the community doesn't want to compromise away some 
> key requirements (such as a reasonable level of security; 
> congestion control) but what about the interaction with other 
> protocols and artifacts; is it ok to not worry about those 
> initially? As a hypothetical example, would there have been 
> concerns if DHCPv6 worked and Mobile IPv6 
> worked, but the combination couldn't be made to work? (Again, 
> I'm not asking about the specifics but about the general case 
> of interaction with existing protocols or protocols that are 
> being developed in parallel.)
> 
> In other cases working groups have first specified a protocol 
> and later made some extensions to e.g. make it cope better 
> with NATs. While such an approach could be taken for more of 
> the "interactions" above to make smaller separate 
> specifications, it doesn't really address the 
> complexity of the total solution.
> 
> So I think part of the issue is that protocols end up being 
> complex because they need to fit into a complex world, and at 
> least some of that complex world the IETF has created itself. 
> Restraining what the community creates could be one approach 
> to limit the complexity. Perhaps better modularity and/or 
> less number of ways to do the same thing is another way. [As 
> an aside, note that in the above list there are interactions 
> with the 3 different ways that IPv6 addresses can be autoconfigured.]
> 
> 
> Jim said:
> > PROBLEM: The IETF process to complete specifications puts to many 
> > features in those initial specifications. [This would be sub bullet 
> > again above].
> 
> In Charlie's example many the "features" aren't there as 
> improvements to the 
> protocol itself (the dynamic home agent discovery might be), 
> but instead driven by the complexity outside of the protocol 
> being specified.
> 
> One possible problem could be that WGs wants to put too many 
> features in the 
> initial specification.
> Another possible problem could be that the external word (or 
> the IETF community, or the IESG) requires interaction with 
> too many different things. From the wording above I can't 
> tell whether you had one or both of these in mind.
> 
>    Erik
> 
> 


>----- End Included Message -----<