Subject: Re: complex extensions attacking IETF protocols

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 4 Nov 1998 01:03:47 -0800

> >>implementations -- and if I had to make a criticism stick, it would be
that
> >>very often the impact of proposals on the overall architecture is not
> >>considered. The result can be patchwork quilt of protocols that makes
> >>very little sense in totality, while being defensible in the
particulars.
>
>the IAB (as well as the IESG) consider architecture A LOT - the
>problem is that we are in an evoliving situation - a prescriptive
>architectural approach would be restrictive of innovation - i think a
>lot of us feel that an evolutionary approach which permits many flower
>to blossom, and then the market garderner to come along and pick the
>best, is reasonable.....of course, we can prune completely abherrant
>proposals early, but...

I think that this underestimates the growing influence that the
IETF has on the marketplace.  Today many customers put
protocols into their "required list" as they approach proposed
standard status. While there are protocols where implementation
does not begin until proposed standards status has been reached,
it seems these represent a smaller fraction of the total. Rather,
there is increasing pressure in the marketplace to deliver
implementations coincident with reaching Proposed, or even
before.  Part of this results from the fact that trade magazines are
more closely tracking IETF activity. I cannot tell you how many
times I have heard the question "When are you going to
have X?" in the week after a trade magazine published an
article on IETF activity in a given area.

Similarly, the issuence of an Applicability Statement can
have a significant impact on customer perceived usefulness
of a document, deflating some of the demand.

The result of all this is that the decisions of the IESG have
significant impact on the market place. Rather than merely
offering the opportunity to "let a thousand flowers bloom" the
decision to advance a document to Proposed is in many
cases a work order for vendor implementation.

If a persuasive case cannot be made for a document, then advancing it
to Proposed may not be a good decision. Such proposals should
be published as Informational or Experimental instead.

>but we can distinguish between intra-protocol complexity, and
>inter-protocol complexity - the IETF
>Has historically been very good at both, but as the world gets richer
>in types of networks and applications, the latter just naturally gets
>harder -but the former as an engineering design goal should not be
>lost...
>

Indeed, dealing with intra-protocol complexity does become harder
and harder as time goes on. We are increasingly seeing unexpected
interactions between proposals. In order to deal with these interactions,
it seems to me that we are going to need to explicitly bring some new
considerations into the process. Some things to think about:

1.  What is the effect of the proposal on the overall configuration and
management complexity of the system?

       a. What is the diagnostic model for the proposal and how is this
model enabled by the MIB, if one exists?
       b. What parameters need to be set out of band and how
many can be managed via the MIB, if one exists?
       c. If ACLs are involved, how do these interact with other
system ACLs or ACLs in other proposals?
       d. If keys are involved, how are these keys to be managed?
       e. If policies are required, how are they to be distributed and how
is global consistency of these policies to be guaranteed?

2. How does a proposal interfact with other proposals?
      a. Does it duplicate the functionality of other proposals
and if so, is it envisaged that the mechanisms will coexist, and
if so, how?
      b. Is there an inherent contradiction between this proposal
and another proposal that is also advancing on the standards
track? If so, how is this to be resolved?

3. Is the proposal scalable for use on the Internet?
      a. Does the proposal impact the allocation of scarce resources
such as addresses or the efficiency of critical processes (i.e. routing
table size)?
If so, is the impact demonstrably benign?
      b. Is it possible to imagine a world in which this proposal would be
widely deployed? If not, why not?

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 4 Nov 98 19:51:19 JST

Bernard;

> considerations into the process. Some things to think about:

You need Occam's Razor.

More formality means more complex and less useful protocols.

If we really want to "let market decide", isn't it simple enough
to make all the RFCs Informational and publish anything satisfying
minimal syntax requirement?

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 4 Nov 98 19:51:19 JST

Bernard;

You need Occam's Razor.

							Masataka Ohta