Subject: Re: The need for smaller protocol specifications

From: Erik Nordmark <[email-masked]>
Date: Wed, 2 Jul 2003 18:11:23 +0200 (CEST)

> 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

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 2 Jul 2003 14:06:17 -0500

Erik said:
> 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.

I suspect that this intersects viciously with the "every possible issue must
be solved before publishing a proposed standard, because nothing ever makes
it to draft" behavior.

We HAVE been setting higher and higher standards for our work. I keep
expecting the next trivial protocol proposal to have to solve the
distributed-PKI problem while proving the NP-completeness of general
relativity and demonstrating a solution to world hunger all in order 0 time.

Seriously, I think the bars are set at the wrong levels -- the first rung is
just too high, the second is unachievable, and the third is unimaginable.

--
Dean

---

From: Keith Moore <[email-masked]>
Date: Wed, 2 Jul 2003 15:34:07 -0400

> I suspect that this intersects viciously with the "every possible
> issue must be solved before publishing a proposed standard, because
> nothing ever makes it to draft" behavior.

I suspect it intersects even more viciously with the "we finalize
the design of the the protocol before we understand the full spectrum of
requirements" behavior.

Or to put it another way, if the WG is finding out only after Last Call
that it's failed to establish the requirements for its work to be
complete and to get sign-off on those requirements from IESG, it's going
to be very difficult to fix that WG's output to everyone's satisfaction.

the surest way to get burned is to deliver a product to a
customer without first having agreed on the deliverables...

> Seriously, I think the bars are set at the wrong levels -- the first
> rung is just too high, the second is unachievable, and the third is
> unimaginable.

I think we need some lower rungs to step on before we get to Last Call.
I also think we might need to raise the rung we're currently calling 
Proposed Standard.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 2 Jul 2003 22:55:24 +0200 (CEST)

> just too high, the second is unachievable, and the third is unimaginable.

Devil is in the details I suspect.
The hard question is what should the criteria be.

While I can see the community agreeing on some general requirements
(like reasonable security; congestion control) it is a lot harder to ssee
where to do incremental work when it comes to things like
 - doesn't handle all the aspects of the layer's it's built upon
 - doesn't fit together with other protocols sitting next to it
 - doesn't provide the assumed set of services to other protocols e.g.
   those layered on top of it

While prptocols that don't have all of the above might be useful
to specify and implement as part of a better understanding of the
problem and solution spaces, it would seem odd to call somethhing
an IETF standard it is doesn't fit into the puzzle of existing
standards.

So perhaps there is an argument that such "components" be experimental
RFCs and when they fit better into the puzzle they can move to the standards
track. Making them fit might involve modifications to the protocol
itself, or the addition of some more components that provide the glue.

  Erik

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 2 Jul 2003 16:38:56 -0500

Dear Erik,

<groping for a solution>

Re: Component specifications as Experimental...

The thing I would wonder about is simply moving the "one stage standard"
problem from Proposed Standard to Experimental.

</groping for a solution>

Trying to frame my question in an on-topic way - does the IETF's multiple
stages of approval matter to the consumers of our specifications?

Variants of this question include:

o When we publish a proprietary specification as Informational and then
publish
a WG specification as Proposed Standard, is this a distinction that matters
to the Internet community?

o When we publish (as we often do) TCP changes as Experimental, do
implementors wait for Proposed Standard approval before including
them in products?

Spencer

----- Original Message ----- 
From: "Erik Nordmark" <[email-masked]>
To: "Dean Willis" <[email-masked]>
Cc: <[email-masked]>; "'Erik Nordmark'"
<[email-masked]>
Sent: Wednesday, July 02, 2003 3:55 PM
Subject: RE: The need for smaller protocol specifications

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 2 Jul 2003 17:13:35 -0500

Erik said:
> While prptocols that don't have all of the above might be 
> useful to specify and implement as part of a better 
> understanding of the problem and solution spaces, it would 
> seem odd to call somethhing an IETF standard it is doesn't 
> fit into the puzzle of existing standards.

Aha! You prove my point. Today, (as you ilustrate above) we seem to think
that any RFC is "an IETF standard". 

By the current official process, a proposed standard is a relatively stable
work that is acknowledged to be incomplete and not expected to be widely
implemented. A draft standard is considered pretty much complete and widely
enough implemented that we know it works (two implementations of each
feature). Only a full standard is expected to be really complete. Does that
line up with the real world's perception, or with the quotation above?

I propose that the four-tracks of RFCs combined with three tiers on the
standards track (Total= seven kinds of RFCs) confuse not only the external
consumers of our work, but have confused us as well. We don't know whether
we're delivering "standards" or instructions about "how to try something at
home, kids."  Result: a Catch-22 where we can't know something works right
until we've tried it, can't try it until it's a standards-track RFC, and
can't write it up as a standards-track RFC until we know it works right.
Result: the dining philosophers have no fork and soon starve.

I think this is a problem. I know it's a pain in the behind. 

Would it be going too far to equate the seven kinds of RFC with the seven
deadly sins?

--
Dean

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 3 Jul 2003 07:51:10 +0200 (CEST)

> that any RFC is "an IETF standard". 

No, I don't think I said that.

> implemented. 

RFC 2026 doesn't say "incomplete" instead it says "has resolved
known design choices". That could easily be interpreted as all the pieces
necessary in the protocol has been specified. For instance, having
a proposed standard say "we need X but haven't specified how to do
that yet" seems to violate 2026, whether X is e.g., a security mechanism,
the ability to interact with different forms  of IP address configuration,
or some agent discovery mechanism.

  Erik

---

From: Steve Coya <[email-masked]>
Date: Thu, 3 Jul 2003 10:18:48 -0400 (Eastern Daylight Time)

>>to the Internet community?

Define Internet Community. IOW, replace "community" with "developers." I
do believe the distinction is understood by the vendors (be they companies
or individuals) who actually implement the protocol defined in the RFC.
Also, when there is both a WG effort and a propriatary Informational RFC,
the latter typically includes an IESG note, pointing out the existance
(and implied preference) of the Proposed Standard. 

>From what I recall, some do and some don't. Those that do are typically
particiants in the WG that produced the Experimental RFC. 

Back in the early 90s, there was a concern that some vendors would not
implement Proposed Standards, but wait for Draft - that was when IETF
meeting attedance was under 500. Today is different as there seem to be
many RFCs remaining at Proposed (and everyone confuses product
differentation with protocol specifications)

That's my recollection, and is based on history - not current events.

Steve