The need for smaller protocol specifications

[Keith Moore]

> My belief is that the IESG demands full-blown system specifications
> because anything less "could" be implemented inside systems that
> have features they don't like.

I don't think this is true in general.  To the extent that it is true, 
I suspect it has something to do with the expectations that the IESG 
(and perhaps the public) have for that particular technology.

I'll give an example not involving IESG.  Once I had lunch with the 
person who was then the head networking official for the University of 
Tennessee.  He complained to me about the limitations of Mobile IP.  I 
replied that Mobile IP was just fine as long as you understood its 
limitations and didn't expect it to solve every version of the "I want 
my host to be able to be mobile and still talk to the network" problem. 
  (note, this conversation was a few years ago, so it's not a statement 
about the state of mobile IP today).

But the natural expectation of something called "mobile IP" is that it 
_will_ solve your version of the mobile IP access problem (which given 
the number of different versions of that problem, essentially means 
that mobile IP is expected to solve all versions of that problem).

Now actually I think it's perfectly reasonable if IESG declares that 
something that calls itself "mobile IP" needs to solve a fairly general 
version of the "mobile IP network access" problem, including security 
etc.  But sometimes the right action might be to change the name or 
otherwise make it clear that this isn't a general solution, and approve 
it for use in the more narrow set of circumstances in which it works 
well - especially if deployment of the 'limited' solution would not 
preclude a later migration to a more general solution.

Other technologies that might be implicitly over-stating their 
applicability include IPsec, DHCP, zeroconf / linklocal addressing for 
IPv4.

(and we're used to thinking that marketing isn't important...)