Subject: Re: [iucg] We need an architecture, not finger pointing.

From: JFC Morfin <[email-masked]>
Date: Sat, 31 Oct 2015 17:28:24 +0100

Amen.
I answer at the end for IUCG (the [email-masked] subset I have access
to) readers to read in sequence.

At 23:23 30/10/2015, John C Klensin wrote:
>--On Friday, October 30, 2015 20:42 +0000 Ted Lemon
><[email-masked]> wrote:
> >> AFAIK everything I've talked about is described in an RFC
> >> somewhere. Indeed, the problem isn't that it's not there,
> >> it's that there's too much and it's difficult for
> >> inexerienced people to match up the right capabilities and
> >> architecture to solve a given problem.
> >
> > That may well be so.   It may be that all that's needed (by me
> > anyway) is a document of some sort that points out where all
> > this stuff is.  Having read the SMTP documents pretty closely
> > recently, there is definitely a substantial amount of stuff in
> > there that I don't see implemented in systems that are
> > available to me.   However, I am fairly sure that there are in
> > fact gaps in the docs in terms of the features i want to see.
> > Even if I'm wrong, I think it's worth going through the
> > exercise of figuring that out.   By which I do not mean "go do
> > some work for me."   I'm interested in this and willing to do
> > work, but as I'm sure you've gathered, I do not have a
> > complete picture of what's been documented and what hasn't
> > been.
>
>Ted,
>
>As the guy who is sitting on, rather than holding and moving,
>the pen on some of the critical documents (notable 5321bis), let
>me explain why because it is an important part of the picture.
>
>First, the path from 821 and 974 and through 1123 plus 1869 and
>assorted extensions and small modifications to 2821, then from
>2821 to 5321, became largely an exercise in merging text.  The
>result contains a number of artifacts, including in how the
>document is organized, and is consequently redundant in some
>places and _very_ hard to read in others.  I can't keep track of
>all of it: if someone asks me a question, I typically have to go
>back and check.  When I don't, I make mistakes more than half
>the time.  Others may have better memories (some probably as a
>consequence of working with the specs every day) but, if I can't
>keep track, expecting casual readers to do so is probably
>unrealistic.
>
>I wanted to do a complete rewrite in the 5321 timeframe and even
>engaged a very good technical editor to help with reorganizing
>and structuring.  I eventually gave up because, especially in
>the absence of a forcused WG, several members of the community
>(including a large subset of the obvious experts) were concerned
>about the risk of inadvertent changes accompanying changes in
>organization and some needed changes in terminology.  Much as I
>might wish otherwise, I don't see any 5321bis being any
>different.  We could fix or patch known issues (of which the
>current errata list is a subset), fold in some of the EAI
>material if it were ready and make informative references to it
>is it were not, but what is needed to make things clear and
>coherent to you and others is unlikely to happen in 5321bis for
>the same reason it didn't happen in 5321.  That reason might be
>summarized as a hypothesis that the relevant community just
>doesn't have the energy to deal with a very careful review of a
>significantly rewritten and restructured document.
>
>The second issue is that I believe that we have ample evidence
>that any attempt to open 5321bis would generate a tremendous
>amount of discussion (some would say "noise") from people who
>believe that email is obsolete, people who believe that multihop
>email models are unnecessary and harmful, people who believe
>that hop-by-hop in-transit (TLS-based or otherwise) encryption
>is an important security measure and those who don't, and people
>who have better ideas than SMTP or even MIME.  Think "final
>ultimate solution to the email problem".  It is hard to figure
>out a model that would prevent those people from being heard and
>it would probably not be desirable if we could figure it out.
>But if resolving even a large fraction of those arguments
>becomes prerequisite to 5321bis, then I suggest that the
>community will run out of energy before we have an approved
>spec, even if it is the minimum update to 5321 with none of the
>structural changes suggested above.
>
>So we are stuck, have been stuck for several years, and I have
>no idea how to get unstuck.
>
>In addition, there are some areas where the IETF could do useful
>architectural work.  For example, there is a common trend these
>days (one referred to indirectly in several recent notes) to
>view email addresses as good personal identifiers.  They
>probably aren't, especially in a world where the mailboxes are
>not really under the control of the user being identified.  But,
>while it is mostly not a technical problem (certainly one that
>can't be "solved" by protocol changes) no one has ever explained
>the issues in terms that can be understood by those who are
>making the decisions, much less publicly recommended against it.
>
>That work, and similar things, may be more important than
>"fixing" SMTP... and new SMTP documents would be easier to write
>and get agreement about if those issues were under control.
>
>best,
>john

Dear John,

This mail of yours is the most realistic mail I have read over the
last 40 years in this business.
My entire relation to the IETF is motivated there. Thank you!

The only difference that I have with this text is that, IMHO, a
different architecture is not enough: we need an architectonical
review. The very basic networking principles are to be reassumed. (*)

Actually, it took 20 years for me to accept that this is not feasible
within the IETF, even if it has to be done with the IETF.

I adhere to Richard Buckminster Fuller's remark: "You never change
things by fighting the existing reality. To change something, build a
new model that makes the existing model obsolete." However, in
networking, you need to ensure a transition, making the old and the
new model compatible. So you need to test the new model within the old
one. This is what I call "intertesting".

This transitional obsolescence capacity is Vint Cerf's second
motivation of the Internet project (EIN 48): "A second motivation is
to allow new networking technology to be introduced into the existing
catenet while remaining functionally compatible with existing systems.
This allows for the phased introduction of new, and obsolescence of
old networks without requiring a global simultaneous change." This was
blocked in 1986 when the IETF was created, and I was made to close
Tymnet Extended Services further to RFC 923, while the "end to end
status quo" strategy established itself.

This is why I also adhere to the RFC 6852 analysis and I appealed its
lack of practical conclusion. This is also why I challenged the
ianaplan conclusions to be sure that they represented the IETF
consensus as they clearly identified two practical technology paths:

- the IETF internet "end to end" approach: IP/TCP/SMTP and now ICANN
- a "fringe to fringe" (RFC 1958) "permissionless innovation"
approach: IP/PLUS - where PLUS stands for "presentation layer on the
user side", as per the subsidiarity principle exemplified by RFC 5895.

This is eventually why I am launching the (http://xlibre.net) XLIBRE
µGlobal Community and starting-up the (http://open-labs.net)
Open-Labs Network project.

The point is to look into what a presentation layer as a virtual box
or an OPES may imply and can permit in terms of network overlaying and
of IUse (intelligent use).

The first and main point is that this IP/PLUS approach is 100%
consistent with 1978. So there is not an architectural disruption: the
"internet" resulted from successive forks among different options. The
preceding fork was the datagram option of Louis vs. the byte option of
Tymnet. In 1986, NSA/McDD and IETF introduced the "BUG" (wanting to Be
Unilaterally Global) issue, politically in line with the Unix
"super-user" culture vs. the declared "non-NSA-compatible" DEC/IBM
based networking culture by Tymshare (and my Tymnet Extended Services,
i.e. the layer six+ enacted capacities) and the attempts to curb the
CCITT X's recommandations.

This has resulted in a 30 year rewarding experience by the IETF, which
led the datagram and byte oriented expectations to quasi converge in
terms of operational capabilities, but not security. I evaluate that
this convergence is now can be an acceptable operational compromise.

- In 1985, we had to address the Tymnet cateneting issue with the
increased granularity of the global networking. We were not permitted
to develop our solution (I understand LeRoy Times was hired further on
by BT to develop a part of it that still may be in use) and IP covered
the world.

- the IP datagram container is transparent to its content, layer six+
extended services Tymnet Engine ISIS slots: there is no problem for IP
to transport intersem (semiotic exchanges) intelligrams (formatted
datagrams) subject to an internetix interoperating system between
Virtual Network Boxes, supporting an application layer seven+
(distributed ASAP [as a protocol] applications).

Let IP datagrams be the IP/PLUS intelligrams vehicle between them.

This leaves us with the Catenet as a plug to plug raw socket
infrastructure, able to commute inter raw socket IP datagrams.

What next?

- IETF has proposed UDP, TCP, SCTP … And based SMTP upon them and use
requirements : a big and brillant second generation.

- an integrated cortege-ing "intersem" (the semiotic stratum I look
for) intelligram, very similar in structure to the node to node Tymnet
packet, but on a fringe to fringe basis. Cortege-ing, meaning that
intelligrams come in "corteges" of any number of intelligrams.

I note that the IETF knows about intelligram support through OPES and
reach-out hosts. It does not know about Netix and VGN (things were not
mature enough for the WG/OPES to consider my ONES "open network of
edge services" proposition, yet what is Google?).

Best,
jfcm

(*) Datagrams are not to carry the message, a message is an
intelligram cortege.

---

From: John C Klensin <[email-masked]>
Date: Sat, 31 Oct 2015 15:29:31 -0400

Jefsey,

Thanks for the kind words, but I want to make one clarification
lest I be credited with supporting something I'm not sure I even
understand.  I was talking strictly about SMTP, a mail
transport/ transfer protocol that was defined to run over either
NCP or TCP/IP and that could easily be (and has been) adapted to
run over a variety of other transport-layer infrastructures.
Because it is an application transport protocol, it has nothing
to do with presentation layers either.  If one accepts the
relevancy of that that layer, it would interact with message
content (and, in Internet mail context, message headers) but not
with message transport.

best,
    john

--On Saturday, October 31, 2015 5:28 PM +0100 JFC Morfin
<[email-masked]> wrote:

>...
 
>...