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

---

From: Dave Crocker <[email-masked]>
Date: Sun, 14 Mar 1999 00:04:26 -0800

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

Noel, I was pretty careful in my note to say just the opposite.  I think 
you are bringing in an entirely different set of issues I (and others) 
raised, during the CIDR deployment work, with concerns over up-stream 
provider control over leaf (downstream) providers.  The problem turned out 
to be quite real, but is irrelevant to this discussion.

The discussion you introduced concerns defining something only partially, 
leaving detail for later.  You said that it is a good idea.

I said it is ok sometimes and very dangerous other times.  For moving to 
classless IP addresses, and lots of other times, it worked well.  For SNMP 
security, it worked badly.

I tried to offer a basis for determining when it was a good idea and when 
it was bad.

The remainder of your note appears to apply my statements rather 
differently than I intended.  When stating the "bad" case, I did not cite 
classless IP as an example.  Quite the opposite.  I said it was an example 
of low risk because the nature of address masking was (and is) pretty well 
understood.

>changing the endpoint<->locator binding is equally small.

I don't have an opinion about the risk, other than to believe that there 
needs to be consensus on the matter.  If there is a broadly held belief 
that the risk of agreeing to the details later is small, fine.

d/

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dave Crocker                                         Tel: +1 408 246 8253
Brandenburg Consulting                               Fax: +1 408 273 6464
675 Spruce Drive                             <http://www.brandenburg.com>
Sunnyvale, CA 94086 USA                 <mailto:[email-masked]>

---

From: Dave Crocker <[email-masked]>
Date: Sun, 14 Mar 1999 00:04:26 -0800

d/

---

From: Tony Li <[email-masked]>
Date: 14 Mar 1999 07:16:58 -0800

> But this entire discussion is a waste of electrons.

Let's try to alleviate that, because I think the discussion has degenerated
into advocacy of two well-known design principles:

- No unnecessary mechanisms.

- The mechanisms that are necessary should be as general as possible.

Tony

---

From: Tony Li <[email-masked]>
Date: 14 Mar 1999 07:16:58 -0800

Tony