The need for smaller protocol specifications

[Erik Nordmark]

> 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