Subject: RE: [arch-d] Defining terms

From: "Bound, Jim" <[email-masked]>
Date: Thu, 23 Mar 2006 11:55:38 -0500

John, all opinions are important and there is no gospel for layers or
architecture. I hear you but several of us who have lived this too
simply don't agree.  Noel is spot on.
/jim 

> -----Original Message-----
> From: John Day [mailto:[email-masked]] 
> Sent: Thursday, March 23, 2006 9:25 AM
> To: Noel Chiappa; [email-masked]
> Cc: [email-masked]
> Subject: Re: [arch-d] Defining terms
> 
> At 21:15 -0500 2006/03/21, Noel Chiappa wrote:
> >     > From: John Day <[email-masked]>
> >
> >     > Now of course, this collection of users can also 
> cooperate to do
> >     > something and provide a black box to their users.
> >     > So now, if these are not layers what are they? 
> pancakes? waffles?
> >     > I would contend that layers are a means of organizing 
> functionality
> >
> >The problem with layers is that are a simplification of 
> reality - and,
> >moreover, a simplification that rapidly becomes stultifying 
> and confusing.
> 
> Then you don't have the layers right.
> 
> >The reality of the subsystem/protocol dependency graph, in 
> real networks, is
> >too complex to be captured with the simple ordered layer model.
> >
> >As one example, look at BGP. It's used for passing around 
> routing info - so
> >it's part of the inter-network layer, right? Yes, but, it 
> uses TCP. So it's
> 
> Is it?  What is its scope?
> 
> >above the transport layer, right? "Does not compute! Does 
> not compute!" Or
> 
> No.  There is no rule that says a protocol and the layer it is used 
> in are fixed.  Protocols are means to providing certain kinds of 
> coordination.  I can use any protocol in any layer where it does what 
> I need done.  Sure it computes.
> 
> >what about those things that open a PPP link over a TCP 
> connection? Similarly
> >confusing.
> 
> Not in the least.  In fact, they show a deep understanding of what 
> network architecture is all about.
> 
> >What's really important, for a system architect, is the 
> subsystem dependency
> >graph. Anything which confuses that representation is 
> non-optimal - and an
> >ordered layer model definitely counts.
> 
> Yep.
> 
> >
> >To put it another way, layers may a fine device for introducing basic
> >networking concepts to beginning students, but they are 
> really a bad idea for
> >use by anyone past the level of "initial introduction". To 
> mangle one of my
> >favourite military axioms, "Beginners think in layers, 
> everyone else thinks
> >in subsystem dependency graphs."
> 
> Then you haven't gotten your layers organized right.  When they are, 
> they not only work but they do more things than we are currently 
> doing and do them well and easily.
> 
> C'mon Noel, I know you better than this.  Step back and look 
> carefully.  Use all of these as data.  Consider what the data is 
> telling us.
> 
> >
> >     > So we have a collection of things in different 
> systems all cooperating
> >     > with some amount of shared state and doing it in some 
> black box to hide
> >     > the complexity from the user of the black box.
> >
> >Right - and this touches on a point I like to rant about, 
> which is that too
> >often: In drawing block diagrams, people treat "the part of 
> subsystem X in
> >machine A and "the part of subsystem X in machine B" as more 
> distantly
> >related than "the part of subsystem X in machine A" and "the part of
> >subsystem Y in machine A". In other words, they tend to draw 
> diagrams in
> >which the main boxes are machine A and machine B, with maybe 
> little sub-boxes
> >inside those boxes for subsystems X and Y. However, when 
> you're trying to
> >understand the subsystem dependency issues, this makes those 
> dependencies
> >much harder to see. The other kind of diagram, in which the 
> main boxes are
> >subsystems X, Y, etc are much rarer - alas.
> >
> 
> Indeed they do. This (as you know) is usually to indicate the degree 
> of coupling.  modules in the same system are generally more tight 
> coupled than those that are not.  At the very least modules in the 
> same system can coordinate with a test-and-set.
> 
> >     > Although, if you *need* a boundary for some reason, 
> some place a layer
> >     > boundary is a good place to do it, if you have chosen 
> your layers
> >     > wisely.
> >
> >A layer boundary is, in many ways, just a subsystem 
> interface definition.
> >
> >Of course, anytime you break a system up into subsystems, 
> the issue of where
> >you put the boundaries, and what info is passed across them 
> - that is (to me)
> >the heart of architecture.
> 
> Most definitely.
> 
> Take care,
> John
> 
> _______________________________________________
> 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: John Leslie <[email-masked]>
Date: Thu, 23 Mar 2006 12:45:27 -0500

Bound, Jim <[email-masked]> wrote:
> To: "John Day" <[email-masked]>,
> 
> simply don't agree.

   We need to put _some_ effort into seeking consensus...

> Noel is spot on.

   Umm... Noel really _isn't_ spot-on in his BGP example...

>>> routing info - so it's part of the inter-network layer, right?

   That really doesn't follow.

   BGP is a "routing" protocol, in the Routing Area sense.

   To Routing Area folks, "routing" is generating path information and
passing _some_ of that path information toward forwarding engines.

   I don't mean to insult folks familiar with Routing Area terminology,
but I expect some folks on this list aren't familiar with it.

   Recall, John Day sees three pieces called "routing":
] 
] Actually, I would say routing is 3 distinct tasks:
]   exchanging information about connectivity and other information,
]   calculating connectivity based on what you have collected,
]   and then choosing a next hop/path based on the calculation and
]     the other info.

and I don't think he even referred to the function I mentioned which
many folks call "routing" but Routing Area folks call "forwarding":
] 
]> passing packets to another router "closer" to the destination.

   (It doesn't help that even Routing Area folks use the term "router"
to refer to a box which does "forwarding".)

   Of all of these, only the last, "forwarding", one in any sense
deserves to be called "part of the inter-network layer". The others
may or may not deserve to be called "necessary to" the inter-
network area, but that would not make them "part of" it.

   Noel certainly knows that BGP is not "forwarding", even if every
box he may have seen it implemented in also does forwarding ( I
venture no guess as to whether that condition is true).

   What functions go in a box is engineering, not architecture.
What functions are implemented in a box _cannot_ determine their
architectural purpose.

>>> Yes, but, it uses TCP. So it's above the transport layer, right?

   This statement at least makes sense. The BGP routing function
can be considered "above" the transport layer.

   But we have no need to enter that argument. From an architectural
standpoint, we should see "exchanging information about connectivity"
as a network function which is out-of-band to the inter-network layer,
and the rest of "routing" (in the Routing Area usage) as not network
functions at all.

>>> "Does not compute! Does not compute!"

>> I need done.  Sure it computes.

   John Day and I are perhaps thinking from an academic standpoint.
Noel may be thinking from an engineering standpoint (or not, YMMV).
But all of us should be _trying_ to think from an architectural
standpoint.

--
John Leslie <[email-masked]>

---

From: "Tony Li" <[email-masked]>
Date: Thu, 23 Mar 2006 12:29:21 -0800

> and the rest of "routing" (in the Routing Area usage) as not network

I think that we're having a bit of miscommunication here.  At the risk
of speaking for Noel...  

BGP is certainly part of the routing function.  Within the conventional
"layering" that is normally discussed, it is always placed within the
internetworking layer, along with all of the rest of routing.  The fact
that BGP uses a transport protocol that actually exists at a higher
layer is certainly a layering violation to those who are pedantic about
layering.

However, I suspect that Noel is not one of those people and is NOT
defending the pedantic layerists.  Quite the opposite: his point is that
layering is an obsolete concept and adhering to it excludes an important
and beneficial part of the architectural solution space.  Good
architecture is partitioning functionality into a loosely coupled DAG.

Tony

---

From: John Day <[email-masked]>
Date: Thu, 23 Mar 2006 13:20:25 -0500

>to refer to a box which does "forwarding".)

Yes, you are absolutely right.  I was considering "forwarding" as the 
output of the routing function.  We do tend to get sloppy and talk 
about routing so much I think we sometimes forget that we do all of 
this calculation of routes just to get the next hop!  Seems like 
quite a waste of effort. ;-)

>and the rest of "routing" (in the Routing Area usage) as not network

Take all of this as data.  What is the problem telling us?  Are we 
using TCP as a transport protocol in the traditional sense or are we 
using it as an error control protocol in a layer with a different 
scope?

What is the scope of TCP as used by BGP?  Is it different from the 
scope of TCP used by say Telnet or FTP?  If it is, then it is a 
different layer.

>But all of us should be _trying_ to think from an architectural

Don't know if it is academic or engineering.  I would like to think 
it is scientific. ;-) More than once, I have found what people do is 
for good reason.  They (we, I) may not understand the full 
implication of why it was done, but if you think long and hard and 
look at the problem deeply enough eventually it makes itself clear. 
So as I said before, assume that all of these people aren't stupid, 
but may not quite understand fully what has been proposed, but there 
is likely a grain of truth in it.  The question is how does this 
grain fit in the total picture.

Take care
John

---

From: John Day <[email-masked]>
Date: Thu, 23 Mar 2006 13:20:25 -0500

Take care
John

---

From: John Day <[email-masked]>
Date: Thu, 23 Mar 2006 12:05:52 -0500

>simply don't agree.  Noel is spot on.

Jim, I have been living with this far longer than you have.  And it 
would appear spent far more time thinking about it.  I sense that 
Noel is just discouraged. ;-)

As I pointed out the other day, you can argue it all you want.  There 
is some sort of distributed black box involved here and there is no 
way to escape it.  So you may as well learn to live with it. 
However, it is not clear that layers we came up with in the early 70s 
were in fact layers we should have.  We hadn't seen much of the 
problem space then.  Any more than the layers of an OS today follow 
the layers of Dijkstra's THE paper.

I contend there is a solution that recognizes layers, is simple, 
elegant and solves many problems.  There is lots of data.  As 
Kettering says, one must learn to listen to the problem.  The 
statement of every problem contains its solutions.

Take care,
John

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 27 Mar 2006 10:28:47 -0500

I am having same issue.  But with progress.  The planes help describe
what we can call the layers.  The modules is what lives within the
planes.  The layers are virtual abstractions to identify regions of
planes.  At least that is where I am at on this self-referential
exercise, at least at this point because I believe in planes right now.
Going to try to apply it to some of the IETF work I am going to do for
shim6 and hip comparison the security models used.  Viewing SCTP as a
set of planes and TCP as a set of planes I believe the diff will provide
knowledge of both.

/jim 

> From: John Leslie [mailto:[email-masked]] 
> Sent: Friday, March 24, 2006 7:24 PM
> To: John Day
> Cc: [email-masked]
> John Day <[email-masked]> wrote:
> > At 14:17 -0600 2006/03/23, Scott W Brim wrote:
> >>
> >> Planes are your friend.
> > 
> > ;-)  Good one.
> 
>    Could one of the folks who is saying layers are the wrong approach
> please try describing internetworking architecture in terms of planes?
> 
>    (I've been trying this exercise myself, and I'm afraid I'm failing
> kinda spectacularly...)
> 
> --

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 27 Mar 2006 10:57:35 -0500

I'm still trying to grasp what this discussion is really concerned with, 
but I think I can contribute a thought on the layering question. Taking 
BGP and TCP as an example, the problem is that each can have an impact 
on how the other operates. You have a cycle somewhere in your dependency 
graph.

The reason for layering, if it could be achieved, is to assure 
consistency. However, it is still possible to have consistency even if 
your depedency graph has cycles. It's just harder to analyze and easier 
to break.

John Day wrote:
> output of the routing function.  We do tend to get sloppy and talk about 
> routing so much I think we sometimes forget that we do all of this 
> calculation of routes just to get the next hop!  Seems like quite a 
> waste of effort. ;-)
> 
>>
> Take all of this as data.  What is the problem telling us?  Are we using 
> TCP as a transport protocol in the traditional sense or are we using it 
> as an error control protocol in a layer with a different scope?
> 
> What is the scope of TCP as used by BGP?  Is it different from the scope 
> of TCP used by say Telnet or FTP?  If it is, then it is a different layer.
> 
> Don't know if it is academic or engineering.  I would like to think it 
> is scientific. ;-) More than once, I have found what people do is for 
> good reason.  They (we, I) may not understand the full implication of 
> why it was done, but if you think long and hard and look at the problem 
> deeply enough eventually it makes itself clear. So as I said before, 
> assume that all of these people aren't stupid, but may not quite 
> understand fully what has been proposed, but there is likely a grain of 
> truth in it.  The question is how does this grain fit in the total picture.
> 
> Take care
> John
>

---

From: John Day <[email-masked]>
Date: Mon, 27 Mar 2006 11:09:25 -0500

At 10:57 -0500 2006/03/27, Tom-PT Taylor wrote:
>I'm still trying to grasp what this discussion is really concerned 
>with, but I think I can contribute a thought on the layering 
>question. Taking BGP and TCP as an example, the problem is that each 
>can have an impact on how the other operates. You have a cycle 
>somewhere in your dependency graph.
>
>consistency. However, it is still possible to have consistency even 
>if your depedency graph has cycles. It's just harder to analyze and 
>easier to break.

Interesting idea.  But remember TCP is not a layer.  It is a protocol 
that provides certain mechanisms and can be used in any layer where 
those mechanisms are required.  We should not associate particular 
protocols with particular layers.  They make nice examples and we do 
it all the time. But we can't use it as the basis for what a layer is.

The fact that BGP uses it would seem to be that because it operates 
over many relays and provides the necessary mechanisms.  Perhaps if 
we notice that BGP is a sort of embedded application used to aid in 
managing communications, not a user level application like FTP, but 
an application protocol nonetheless.  Hmmmm.

Take care,
John

---

From: John Day <[email-masked]>
Date: Mon, 27 Mar 2006 10:52:21 -0500

It will be an interesting exercise to see what questions it answers. 
All my attempts to pursue that course lead right back to the 
"beads-on-a-string" model.  TCP is such a monolithic whole, it is 
hard to see how one would decompose it into planes.  (I assume we are 
talking about vertical planes, rather than horizontal ones.)

I have found more advantage returning to our roots and using 
operating systems as a guide.

Take care,
John

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 27 Mar 2006 12:01:25 -0800

Hi -

The last few posts on "planes" and "layers" were just a little too abstract for me.
Just to make sure we are talking about the same things, here's how I would
characterize the differences:

    "Layers" are used to bound the scope of specification (and interactions)
     between communicating entities.  The boundaries allow consistent definition
     of the services provided, the services needed, and the protocol interactions.

    "Planes", as in "control plane", "data plane", "management plane" are
    aspects (as in cross-cutting concerns) of layers.  The interactions to
    accomplish these functions may be "in-band" for a protocol at a given
    layer, or may be carried out by some other protocol, even at another
    (commonly application) layer.  For example, setting up routes through
    the network layer's management plane might be accomplished using
    an application layer protocol like SNMP or BGP.  Thus, when we talk
    about a plane, we're talking about a subset of a layer's interfaces, and
    those elements of protocol needed to support it.

    "Modules" are units of implementation; the organization of modules may,
    to the extent that support for a particular protocol is implemented as a
    discreet entity, reflect layering.  Their organization may also, due to
    the commonality of implementation interfaces, reflect the functional
    aspects of the various planes. 

Am I totally in the weeds?

Randy

---

From: "LEVIS Pierre RD-CORE-CAE" <[email-masked]>
Date: Tue, 28 Mar 2006 17:03:23 +0200

Following the exchange on this list with interest I would like to bring up some comments:

- A layered model should not be considered as something stalled and rigid, where any digression would appear like a break in the model. Tunnelling, layers in different orders, should appear as variations on the reference model and normal behaviour, not as faults. That said, I don't mean that any reorganisation is legitimate but only that it should not been rejected just because it does not correspond to the reference model per se. Without being pedantic, this is very much like language, you have grammar that captures the usual way to express things and you have great novelists and great poets that very often use variations from the traditional rules. Would you say Shakespeare didn't write correct English? because it simply didn't write the same way his contemporary fellows used English in there daytime occupations?

- I don't see the architectural problem for BGP to be upon TCP if it needs to be. We find routing protocols in various places: RIP is on top of UDP, OSPF is on top of IP. For me, no matter where the routing protocol is, it is application layer in the sense that there is no layer above. In any layered model, application is the top layer. The ultimate purpose of any network exchange is to convey application data from a source where it is generated, to a destination where it is handled. There is nowhere such a statement as data application should be anything but routing information. Applications are not only end-users applications.

- I'm very surprised to hear that IETF experts asked by Eric don't see any IP architectue at all. I see at least one great architectural principle: the network layer (or may be better internetwork, or SubNetwork Independent Convergence Protocol for OSI buffs is connectionless and provides a single service to the layers just above(see the hourglass model proposed by Steve Deering). I guess TCP/IP has no more and no less architecture than other challengers like OSI, ATM, or UMTS. Making the statement that IP is only ad hoc assemblage of technologies and techniques is reassuring IP opponents that pretend their protocol stack is very cleverly and truly designed whereas TCP/IP is something cheap and shapeless and don't understand that the current Internet has been possible not despite IP but because of IP.

-Layer, plane, module, well ! may be these can be helpful concepts but be sure they don't only bring complexity. A concept is helpful only as far as it helps resolving a specific problem. So if we want to bring a new concept we should be able to show what the associated problem is and how it resolves it. We should avoid defining terms just for the pleasure of providing definitions. However I found in this list interesting reasons raised to consider modules and not only layers, the problem being layers don't correspond to implementation and don't provide enough flexibility. 

Pierre

-----Message d'origine-----
De : Randy Presuhn [mailto:[email-masked]] 
Envoyé : lundi 27 mars 2006 22:01
À : [email-masked]
Objet : Re: [arch-d] Defining terms

Hi -

The last few posts on "planes" and "layers" were just a little too abstract for me.
Just to make sure we are talking about the same things, here's how I would characterize the differences:

Randy

---

From: Scott W Brim <[email-masked]>
Date: Tue, 28 Mar 2006 11:15:14 -0500

On Mon, Mar 27, 2006 10:28:47AM -0500, Bound, Jim allegedly wrote:
> I am having same issue.  But with progress.  The planes help
> describe what we can call the layers.  The modules is what lives
> within the planes.  The layers are virtual abstractions to identify
> regions of planes.  At least that is where I am at on this
> self-referential exercise, at least at this point because I believe
> in planes right now.  Going to try to apply it to some of the IETF
> work I am going to do for shim6 and hip comparison the security
> models used.  Viewing SCTP as a set of planes and TCP as a set of
> planes I believe the diff will provide knowledge of both.

Noel and Tony are right that what is essential is functions and the
relationships between them.  Layers, layer networks and planes are
handy ways to aggregate functions for discussion and when
implementing, especially if there is money involved, but are not
fundamental.  "Modules" can function in more than one plane (example:
all of the forwarding, control and management planes might use IP
forwarding for communication), and in more than one layer (example:
more than one layer can use the same authentication funtion).

If you want to use the traditional plane view, I don't see how TCP can
be a set of planes.  TCP can be used by more than one plane.  Is that
what you mean?

On Mon, Mar 27, 2006 12:01:25PM -0800, Randy Presuhn allegedly wrote:
> The last few posts on "planes" and "layers" were just a little too
> abstract for me.  Just to make sure we are talking about the same
> things, here's how I would characterize the differences:
> 
>     "Layers" are used to bound the scope of specification (and
>     interactions) between communicating entities.  The boundaries
>     allow consistent definition of the services provided, the
>     services needed, and the protocol interactions.
> 
>     "Planes", as in "control plane", "data plane", "management
>     plane" are aspects (as in cross-cutting concerns) of layers.
>     The interactions to accomplish these functions may be "in-band"
>     for a protocol at a given layer, or may be carried out by some
>     other protocol, even at another (commonly application) layer.
>     For example, setting up routes through the network layer's
>     management plane might be accomplished using an application
>     layer protocol like SNMP or BGP.  Thus, when we talk about a
>     plane, we're talking about a subset of a layer's interfaces, and
>     "Modules" are units of implementation; the organization of
>     modules may, to the extent that support for a particular
>     protocol is implemented as a discreet entity, reflect layering.
>     Their organization may also, due to the commonality of
>     implementation interfaces, reflect the functional aspects of the
>     various planes. 
> 

I think so -- good enough for me anyway.  However, I want to add one
more thing: layer networks (distinct from layers).  The anti-ITU crowd
will flinch.  Consider if you're running SIP over IP over ATM over SDH
over DWDM.  Each one of those has its own endpoint identifiers, does
its own switching (classically a "network layer" function),
potentially has its own control and reliability functions, etc.  Each
one has a number of classic "layers" in it -- ATM can even have a
session layer -- and has one or more "planes" (if nothing else a
data/forwarding plane).  Finally we can stack them arbitrarily.  We
can run IP over ATM or ATM over IP, as long as we eventually get down
to something physical at the bottom.  These things are called layer
networks.  Dealing with real networks, I think it's a more useful
concept than the classic layers.

swb

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 28 Mar 2006 22:38:14 +0200

Pierre,
tout cela n'a d'intérêt que si cela aide. Le problème essentiel est 
de savoir vers quoi on veut que cela aide. Tout cela est encore de 
l'ingénierie de construction. Avant que de se demander si l'on met 
d'abord les parpaings, puis le ciment, puis l'appret, puis la 
peinture et quand on place les chassis des fenêtres, ou si on peut 
mettre du préfabriqué, ou des panneaux de fibre de verre, etc. il 
faudrait d'abord un architecte qui fasse un plan d'ensemble, basé sur 
un modèle général externe à l'application Interet, qui fait que l'on 
met d'abord des fondation, des murs, un toit.

Ce qui manque à l'IAB c'est malheureusement cela.

Ceci dit la notion de pile protocolaire (layers network) est la plus 
porteuse à mon avis car elle permet d'utiliser le réseau actuel pour 
tester et prédéployer le réseau futur. A ce niveau j'aimerais bien 
savoir où trouver de la doc sur le réseau des Douanes et de la 
Gendarmerie, ou les messageries d'Auchan, qui - à ce que je comprends 
- on empilé TCP/IP et OSI?

Pour ne pas paraître idiot : je comprends que les planes sont en fait 
une vision fonctionnelle du réseau, comme on dit "sur le plan 
sécurité, sur le plan gestion, etc." Donc trés claire en francais. Ou 
me gourre-je ?

Cordialement
jfc

At 17:06 28/03/2006, LEVIS Pierre RD-CORE-CAE wrote:

>- A layered model should not be considered as something stalled and 
>rigid, where any digression would appear like a break in the model. 
>Tunnelling, layers in different orders, should appear as variations 
>on the reference model and normal behaviour, not as faults. That 
>said, I don't mean that any reorganisation is legitimate but only 
>that it should not been rejected just because it does not correspond 
>to the reference model per se. Without being pedantic, this is very 
>much like language, you have grammar that captures the usual way to 
>express things and you have great novelists and great poets that 
>very often use variations from the traditional rules. Would you say 
>Shakespeare didn't write correct English? because it simply didn't 
>write the same way his contemporary fellows used English in there 
>daytime occupations?
>
>- I don't see the architectural problem for BGP to be upon TCP if it 
>needs to be. We find routing protocols in various places: RIP is on 
>top of UDP, OSPF is on top of IP. For me, no matter where the 
>routing protocol is, it is application layer in the sense that there 
>is no layer above. In any layered model, application is the top 
>layer. The ultimate purpose of any network exchange is to convey 
>application data from a source where it is generated, to a 
>destination where it is handled. There is nowhere such a statement 
>as data application should be anything but routing information. 
>Applications are not only end-users applications.
>
>- I'm very surprised to hear that IETF experts asked by Eric don't 
>see any IP architectue at all. I see at least one great 
>architectural principle: the network layer (or may be better 
>internetwork, or SubNetwork Independent Convergence Protocol for OSI 
>buffs is connectionless and provides a single service to the layers 
>just above(see the hourglass model proposed by Steve Deering). I 
>guess TCP/IP has no more and no less architecture than other 
>challengers like OSI, ATM, or UMTS. Making the statement that IP is 
>only ad hoc assemblage of technologies and techniques is reassuring 
>IP opponents that pretend their protocol stack is very cleverly and 
>truly designed whereas TCP/IP is something cheap and shapeless and 
>don't understand that the current Internet has been possible not 
>despite IP but because of IP.
>
>-Layer, plane, module, well ! may be these can be helpful concepts 
>but be sure they don't only bring complexity. A concept is helpful 
>only as far as it helps resolving a specific problem. So if we want 
>to bring a new concept we should be able to show what the associated 
>problem is and how it resolves it. We should avoid defining terms 
>just for the pleasure of providing definitions. However I found in 
>this list interesting reasons raised to consider modules and not 
>only layers, the problem being layers don't correspond to 
>implementation and don't provide enough flexibility.
>
>Pierre
>
>abstract for me.

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 28 Mar 2006 23:28:28 +0200

At 22:38 28/03/2006, JFC (Jefsey) Morfin wrote:
>Pierre,
>tout cela n'a d'intérêt que si cela aide.

apologies. This mail was supposed to be personal.
For those who read French, there were possibly (if correct) helpful 
clarifications about "planes" and "layers network" based upon French locutions.
jfc