Subject: RE: [arch-d] Defining terms

From: "Bound, Jim" <[email-masked]>
Date: Tue, 21 Mar 2006 19:33:04 -0500

Now that is very interesting view.  I can go there but would like for it
to be other than just the two of us ---). Anyone not ok with this
suggestion?  

But at the end if we break compatibility with today it may never happen
for the right or wrong reasons.  Thus we could spin and never get to
deployment of the idea.  Again that is ok with me too.

/jim

> -----Original Message-----
> From: JFC (Jefsey) Morfin [mailto:[email-masked]] 
> Sent: Tuesday, March 21, 2006 1:42 PM
> To: Joe Touch
> Cc: [email-masked]
> Subject: Re: [arch-d] Defining terms
> 
> At 17:46 21/03/2006, Joe Touch wrote:
> 
> >See RFC 3884 for the differences ;-)
> 
> I suggest that discussing architecture (to also have confusion with 
> "configurations") means never alluding to an RFC, ISO standard, etc. 
> Because they talk of a specific and past approach.
> jfc 
> 
> 
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/architecture-discuss
> 

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

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 22 Mar 2006 02:20:02 +0100

At 01:33 22/03/2006, Bound, Jim wrote:

>deployment of the idea.

I think not. Because there is no real architecture RFC. Even RFC 1958 
is more recipes for good design.
Also because a good architectural solution should support the 
convergence of the existing technologies. We all know/want it.
Also because this architecture is to deliver communications within 
the same digital ecosystem. By definition there will be bridges. The 
practical test of credibility will be the ROI of a transition.

We want a model which will last. It cannot depend on the engineering 
solutions it is to replace. Retro-compatibility with passed 
limitations cannot be the base of a brillant future.
jfc

>Again that is ok with me too.
>
>/jim
>

---

From: <[email-masked]>
Date: Wed, 22 Mar 2006 06:44:00 +0200

JFC,

>We want a model which will last. It cannot depend on the 
>engineering solutions it is to replace. Retro-compatibility 
>with passed limitations cannot be the base of a brillant future.

We want a model that over comes the problem areas of today and
can be made to (inter)work with the existing stuff.  This is
engineering.  Nothing lasts forever, and if you plan to have
such a solution, mostly likely, it will be horribly over-engineered
and miss it's window of opportunity.

I think we have some idea of what is broken, and so the next
architecture is one that should solve those problems in a coherent
and straight-forward manner.

John

---

From: Alexis Turner <[email-masked]>
Date: Wed, 22 Mar 2006 05:32:58 +0000 (UTC)

I believe a less "buzz-laden" but just as meaningful way to make Jefsey's point 
is that the current Internet is nothing but a series of patches building upon 
endless series of patches.  At some point, engineering a system that is held 
together by tape and string and ever-conflicting protocols becomes an excercise 
in both futility and stubborness - an excercise which can hardly be called 
engineering.  It is at that point that the system designers must take a step 
back, learn from their mistakes, and start over from the beginning.  

Who on this list would realistically disagree with that?  Can we honestly say 
the current system is not broken as hell?  If we continue to insist on making 
something that works with the current system, the predecessors will remain 
broken.  This is Jefsey's point, pure and simple.
-Alexis

On Wed, 22 Mar 2006 [email-masked] wrote:

::JFC,
::
::>We want a model which will last. It cannot depend on the 
::>engineering solutions it is to replace. Retro-compatibility 
::>with passed limitations cannot be the base of a brillant future.
::
::We want a model that over comes the problem areas of today and
::can be made to (inter)work with the existing stuff.  This is
::engineering.  Nothing lasts forever, and if you plan to have
::such a solution, mostly likely, it will be horribly over-engineered
::and miss it's window of opportunity.
::
::I think we have some idea of what is broken, and so the next
::architecture is one that should solve those problems in a coherent
::and straight-forward manner.
::
::John

---

From: Joe Touch <[email-masked]>
Date: Wed, 22 Mar 2006 09:05:12 -0800

JFC (Jefsey) Morfin wrote:
> I think not. Because there is no real architecture RFC.

Perhaps, though the standards doc together, esp. 1122-1123, 791, 793,
and a few more, do constitute an architecture even if sometimes implicit.

However, this is not the context in which I cited the RFC. I noted 3884
only in the reference to the discussion on IP-in-IP vs IPsec tunnels,
noting that the distinction between the two is addressed there.

While I agree that we should not confine ourselves to existing
architectures or backward compatibility, there are broader principles at
work, notably the need to keep firewall, tunneling, forwarding/routing,
and security services sufficiently independent as to be interoperable.
Those lessons can either be learned from the existing architecture or
repeated.

Joe

---

From: "Fleischman, Eric" <[email-masked]>
Date: Wed, 22 Mar 2006 10:15:22 -0800

I spent most of the Vancouver IETF asking IETF luminaries whether there
was a current IP architecture or not.  I didn't encounter a single
person, including conversations with the IAB, that didn't state that the
Internet/IP doesn't currently have an architecture but rather is only an
ad hoc assemblage of technologies and techniques today. 

What I learned is that because IP doesn't currently have an
architecture, none of the questions for which I was seeking an answer
(or at least a basis for resolving technical differences I was having
with others), could be answered in terms of references to agreed upon
architectural precepts since no such architecture currently exists. 

>From where I stand, this is a very serious state of affairs. I fear that
Steve Deering's many warnings to our community (e.g., about the dangers
of a "fat IP layer") during the late 90s have come true.

-----Original Message-----
From: JFC (Jefsey) Morfin [mailto:[email-masked]] 
Sent: Tuesday, March 21, 2006 5:20 PM
To: Bound, Jim; Joe Touch
Cc: [email-masked]
Subject: RE: [arch-d] Defining terms

At 01:33 22/03/2006, Bound, Jim wrote:

>Now that is very interesting view.  I can go there but would like for 
>it to be other than just the two of us ---). Anyone not ok with this 
>suggestion?
>

I think not. Because there is no real architecture RFC. Even RFC 1958 
is more recipes for good design.
Also because a good architectural solution should support the 
convergence of the existing technologies. We all know/want it. Also
because this architecture is to deliver communications within 
the same digital ecosystem. By definition there will be bridges. The 
practical test of credibility will be the ROI of a transition.

> > Because they talk of a specific and past approach. jfc
> >
> >
> > Architecture-discuss mailing list [email-masked]

---

From: Scott W Brim <[email-masked]>
Date: Wed, 22 Mar 2006 13:30:31 -0600

> ad hoc assemblage of technologies and techniques today. 

The IETF has architectural *principles*, plus building blocks, and in
my experience explicitly avoids too much restriction of instantiation
of those principles.  This is a mixed blessing.

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sat, 25 Mar 2006 14:56:37 +0100

At 11:51 22/03/2006, [email-masked] wrote:
>engineering.

Dear John,
You are obviously correct in your definition of engineering and of 
what could be done.

But is the matter here not architecture? It is a step further to 
address the situation. Take the Coliseum in Rome or the Pyramids. 
There is a lot of daily engineering to keep them in good shape. But 
their architecture lasts for twenty and forty centuries. But you are 
right: private buildings engineered at the same time, are long gone 
and replaced and may still have to be replaced. Hopefully in a better 
way each time.

Now, there is certainly a choice to make: engineering fixes or 
architectural change. What is the best? What is the fastest?

>Nothing lasts forever, and if you plan to have

Examples I took, and experience, would show otherwise. Because their 
builder did want to please engineers, but to use engineers' help to 
please people.

>and straight-forward manner.

The next architecture should be the one which will not even know such 
problems may exist.

This is why I prefer considering people needs. Usually permanent 
needs. I prefer to list them as services (people want services, not 
solutions). And to consider the network OS (and its resulting 
protocols - most probably plural) able to support these services. I 
am amazed that local nets are dealt with network OS and not the 
network of the network. This is why I kept refering to "usage 
architecture". But now I see that John Day used the word...

In this process let disregard the solutions and protocols we know the 
weaknesses and conflicts. Let try to reduce the whole thing to the 
simplest proposition. Call them layers, modules, functions, building 
blocks, etc. there will be ways to reduce complexity and to measure 
their applied architectural consistency.

Now, you will have an architectural framework. Where engineering may 
and have to develop. Both ways - down the layers for network 
engineering, and up for applications, procedures and parametering.

Unfortunately I feel the Internet went the other way around. An 
engineering feasibility test, which lasted, patch after possibly 
conflicting patch. It works, but are we not hampered, delayed? I 
think we are, and for a long.

hmmm... I talked a lot, now I listen what people on this list have to 
answer to the users of their deliberables like me.
Cheers.
jfc