Subject: Re: [arch-d] [Off-topic] Further thoughts: about systems theory and the theory U

From: [email-masked] (Noel Chiappa)
Date: Thu, 9 Nov 2006 20:25:04 -0500 (EST)

> From: David Meyer <[email-masked]>

    > We plan to use this list for discussion of the outcomes of the routing
    > and addressing workshop, and about the (technical) ways forward. ... We
    > do, however, need to focus on the our task, and this is the list that
    > we're going to use for that.

David, that's all well and good, but architecture isn't engineering either -
and that needs to happen elsewhere too - that's what IETF WG's (and, in
particular, design groups of WG's) are for.

These are the kind of questions I think of when I think of architecture,
at least in the current region of discussion:

- 1) What are the classes of objects we have names for
- 2) What are the characteristics of the namespace(s) for each kind of object

I'm kind of fried at the moment, so I can't think of what others I should list.
John, what am I missing?

Questions like "how many bits should this field in the name be" and "what's
the mechanism to map between namespace A and namespace B" are *not*
architecture; they are engineering. Which brings up one I missed:

- 3) Which namespaces do we need to be able to map beween? (E.g. given a
bare EID, do we need to be able to turn that into a locator, or is the
expectation that they always travel in pairs, and that a DNS lookup always
returns the pair?)

Are the answers to these settled, or do they need more work? The NSRG started
to think heavily about these issues, but we were just getting into it when
the effort died, for a variety of reasons.

A long time ago I put a stake in the ground on 1, claiming that we should
name a) network interfaces (i.e. places the system of routers deliver packets
to), and b) fatesharing entities which participate in end-end communication.
(In other words, something like "one end of a TCP connection(s), along with
the application(s) using it".)

I've sometimes wondered since, in light of things like server farms, etc
whether that was really the right thing, whether we shouldn't in fact be
naming higher-level things. (So that, e.g., the actual server you could be
talking to die, but there was some shared transaction state that another
server could get to, and you could keep going, but with a new TCP connection -
which is what clicking from page to page on web sites will do for you. We do
this now in an ad-hoc way with cookies, and data in URL's, but is there a need
for something more formal?)

But perhaps I was correct to begin with, and we do need names for end-end
things, and we *also* need a higher level of naming for the applications.

I don't think a mailing list is the way to answer these kinds of questions.
You have to take <12 very smart people, and put them in a room for 3 days,
and lock the door and keep everyone else out.

Sorry, but to quote Brooks, ("Mythical Man-Month", chapter 4, 'Aristocracy,
Democracy and System Design') "there must be few architects".

Sure, their output should be reviewed and commented on by everyone, once the
door opens, and perhaps they need to close the door again and respin, but from
experience with NSRG (particularly one design sub-group), and looking at the
vagueness of the questions above, any attempt to discuss such issues on a
mailing list with many people on it, all dropping a comment in here and there,
will not reach closure. It was hard enough in a small room with 4 people
actually phsyically there....

Or do you think the community is ready to just "ship it" with something like
the endpoints concept - add naming of endpoints, and split IPv6 addresses in
half to name the two classes of things, and call it a day quickly on the
architecture?

Which sounds a lot like a quick kludge, actually. Then again, some quick
kludges (e.g.  CIDR) have been reasonably good. But they aren't as good as
starting from scratch, of course. CIDR bought us a few years, but it's hardly
a "possession for all time".

    Noel

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: David Meyer <[email-masked]>
Date: Thu, 9 Nov 2006 17:34:28 -0800

> I'm kind of fried at the moment, so I can't think of what others I should list.

	Understood. Maybe we need more than one list?

> Democracy and System Design') "there must be few architects".

	Sure, again, understand.

> half to name the two classes of things, and call it a day quickly on the

	Definitely not.
 
> a "possession for all time".

	I guess it depends on things like whether you're looking
	at clean slate v. incremental deployability on the
	existing Internet, etc. These are all reasonable things
	to discuss (IMO), and as I said above, maybe we need more
	than one list. 

	--dmm

---

From: Jefsey_Morfin <[email-masked]>
Date: Fri, 10 Nov 2006 03:24:30 +0100

>things, and we *also* need a higher level of naming for the applications.

Correct. Physical addresses for the plug to plug. Domain names for 
end to end. Authentication for brain to brain/CPU.

>and lock the door and keep everyone else out.

Correct. But you have to unpollute these people from their pet 
technology prior to entering the room. Or to gather them on the basis 
of a general enough common vision.

>actually phsyically there....

Mailing lists permit to consider <12 people groups and to make sure 
all the premises have been listed in case they forget some.

Because there will not be one solution, but a diversity.
This is why their first need is interoperability, starting with the 
current IPv4 and tentative IPv6 architecture.

On 02:53 10/11/2006, Noel Chiappa said:
>     >> do you think the community is ready to just "ship it" with something
>     >> like the endpoints concept - add naming of endpoints, and split IPv6
>     >> addresses in half to name the two classes of things, and call it a
>     >> day quickly on the architecture?
>
>     > Definitely not
>
>Well, now you're making me wonder - to be very frank and blunt - whether this
>whole exercise is really anything other than a (yet another) paper design
>exercise which is destined to go nowhere. Because in saying that, you're
>putting on the table the possibility of a major change to IPv6, not just a
>fairly minor tweak.
>
>The issue, to put it bluntly, is: how much will is there to change IPv6?
>(Even sticking a shim layer in between the internetwork layer and the
>tranport layer, so the IPv6 protocol itself doesn't have to be changed,
>is still a change to IPv6 in a larger sense.)

Everything and nothing. When you can use IPv4 use it. When you can 
use IPv6 use it. When you need more develop it.

>If there's no community will to change IPv6, we're wasting out time.

No. You just say that community cannot develop something new. You 
only need <12 smart committed people. If their deliverable is good 
and interoperable it will fly.

>This is where the IESG and IAB *have* to suck it up and try and lead on this
>issue - and, yes, probably get some people pissed off at them - and say
>something.

This may help those who believe in IESG and IAB. But will they really 
be committed to change. I do not think that people able to design, 
test and deploy a new architecture are people who need the IESG and 
IAB to tell them they failed.

RFC 3935 says "The Internet isn't value-neutral, and neither is the 
IETF.  We want the Internet to be useful for communities that share 
our commitment to openness and fairness.  We embrace technical 
concepts such as decentralized control, edge-user empowerment and 
sharing of resources, because those concepts resonate with the core 
values of the IETF community.  These concepts have little to do with 
the technology that's possible, and much to do with the technology 
that we choose to create."

If IESG and IAB say the technology the IETF chosed to create is not 
adequate, it could mean that the IETF core values above (and IMHO 
rough consensus) are not adequate. This would call for more than just 
a mail. This should be the very matter of this mailing list.

jfc