Subject: Re: providing generic mechanisms

From: Noel Chiappa <[email-masked]>
Date: Sun, 14 Mar 1999 02:43:20 -0500

> From: Dave Crocker <[email-masked]>

    > However as you've stated it, I believe it is wrong and dangerous.

Just like you said CIDR was wrong and bad, huh Dave? Sure Dave, whatever you
say.

    > It is one thing to provide a reasonably familiar, basic construct and
    > leave the details for later. Designing a generic mechanism, when there
    > is no real idea how it will be used, can too easily lead to providing
    > the WRONG generic mechanism. The generic net mask mechanism was
    > reasonable

This happens to be a substantial misrepresentation of what happened, but it's
instructive, so I'll correct the record.

There were some people who wanted to make the mask apply only *inside* the
"rest" field (as defined by the high bits, in the usual A/B/C manner).
Luckily, the more generic proposal (to just use a flat mask, and not have
hosts know about the structure of A/B/C) was accepted.

Note that the base architectural principle was "getting the hosts out of the
business of understanding address formats" - the mask mechanism was just a
way to do that. But the mechanism-free architectural principle *preceded* the
specific mechanism.

Those who proposed applying the mask inside the "rest" field clearly had
either i) completely missed the underlying architectural principle above, or
ii) did not think it had any value (if the latter, incorrectly, obviously).

And as it happens, the *particular* use I had in mind for that mechanism, at
the time, never panned out. But the general architectural concept, of getting
the hosts out of the business of understanding address formats, was sound.

    > It's not that the details are trivial, but rather than the risk of not
    > being able to work them out is small.

Exactly. And the likelihood that we won't be able to work out a secure way of
changing the endpoint<->locator binding is equally small.

(The validity of the general architectural concept, separating out
indentification of communicating entities, and identification of network
attachment points, is undeniable. Equally obviously, once you have two
namespaces, you have to have a set of bindings between them. All this is 100%
on a par with getting hosts out of the business of understanding address
formats.)

    > By contrast, SNMPv1 had a generic security field that turned out to be
    > useless. There was not enough experience to have a serious idea of the
    > way it would/should be used, at the time it was designed. When there
    > was a serious effort at providing SNMP security, later, they had to
    > toss out the original field and start over.

Exactly. They threw in a random field without much thinking about how it
would be used, and lost. On the other hand, there has been a *lot* of thought
given to separating out indentification of communicating entities, and
network attachment points.

But this entire discussion is a waste of electrons.

        Noel