From nobody Sat Oct 31 09:28:34 2015 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1B41A8A08 for ; Sat, 31 Oct 2015 09:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNS9hKuUAWkY for ; Sat, 31 Oct 2015 09:28:29 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB2C41A89A8 for ; Sat, 31 Oct 2015 09:28:29 -0700 (PDT) Received: from 251.47.14.81.rev.sfr.net ([81.14.47.251]:61692 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.85) (envelope-from ) id 1ZsZ11-0000r4-8d; Sat, 31 Oct 2015 09:28:27 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 31 Oct 2015 17:28:24 +0100 To: John C Klensin ,Ted Lemon , Ned Freed From: JFC Morfin In-Reply-To: References: <562F0125.20400@gmail.com> <20151027232802.1DF913B3F286@rock.dv.isc.org> <20151028183440.GR5570@mournblade.imrryr.org> <65E7B559-6B1B-46EA-9BB3-823C47E6A142@nominum.com> <01PSG4P2TNSY013KGW@mauve.mrochek.com> <01PSIKIIV57Y01729W@mauve.mrochek.com> <8D23D4052ABE7A4490E77B1A012B630797A01393@mbx-03.WIN.NOMINUM.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Message-Id: <20151031162829.BB2C41A89A8@ietfa.amsl.com> Archived-At: Cc: iucg@ietf.org Subject: Re: [iucg] We need an architecture, not finger pointing. X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2015 16:28:33 -0000 Amen. I answer at the end for IUCG (the ietf@ietf.org 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 > 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 nobody Sat Oct 31 12:29:36 2015 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F46A1B2CFD for ; Sat, 31 Oct 2015 12:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.101 X-Spam-Level: * X-Spam-Status: No, score=1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYzypUgV5-Jq for ; Sat, 31 Oct 2015 12:29:33 -0700 (PDT) Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 957661B2CFA for ; Sat, 31 Oct 2015 12:29:33 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZsbqC-000Icw-Gm; Sat, 31 Oct 2015 15:29:28 -0400 Date: Sat, 31 Oct 2015 15:29:31 -0400 From: John C Klensin To: JFC Morfin , Ted Lemon , Ned Freed Message-ID: <1A5485031B6CD95F467D5B78@JcK-HP5.jck.com> References: <562F0125.20400@gmail.com> <20151027232802.1DF913B3F286@rock.dv.isc.org> <20151028183440.GR5570@mournblade.imrryr.org> <65E7B559-6B1B-46EA-9BB3-823C47E6A142@nominum.com> <01PSG4P2TNSY013KGW@mauve.mrochek.com> <01PSIKIIV57Y01729W@mauve.mrochek.com> <8D23D4052ABE7A4490E77B1A012B630797A01393@mbx-03.WIN.NOMINUM.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Archived-At: Cc: iucg@ietf.org Subject: Re: [iucg] We need an architecture, not finger pointing. X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2015 19:29:34 -0000 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 wrote: > Amen. > I answer at the end for IUCG (the ietf@ietf.org subset I have > access > to) readers to read in sequence. >... > 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. (*) >...