[alto] Current status and a way forward for ALTO
Enrico Marocco <enrico.marocco@telecomitalia.it> Fri, 01 March 2013 15:12 UTC
Return-Path: <enrico.marocco@telecomitalia.it>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9D811E809C for <alto@ietfa.amsl.com>; Fri, 1 Mar 2013 07:12:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.719
X-Spam-Level:
X-Spam-Status: No, score=-101.719 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ihjOaRPClXZ for <alto@ietfa.amsl.com>; Fri, 1 Mar 2013 07:12:48 -0800 (PST)
Received: from GRFEDG701RM001.telecomitalia.it (grfedg701rm001.telecomitalia.it [217.169.121.20]) by ietfa.amsl.com (Postfix) with ESMTP id 259A211E80A5 for <alto@ietf.org>; Fri, 1 Mar 2013 07:12:48 -0800 (PST)
Received: from grfhub702rm001.griffon.local (10.19.3.9) by GRFEDG701RM001.telecomitalia.it (10.173.88.20) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 1 Mar 2013 16:12:43 +0100
Received: from MacLab.local (10.229.8.21) by smtp.telecomitalia.it (10.19.9.235) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 1 Mar 2013 16:12:43 +0100
Message-ID: <5130C56A.20301@telecomitalia.it>
Date: Fri, 01 Mar 2013 16:12:42 +0100
From: Enrico Marocco <enrico.marocco@telecomitalia.it>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: "alto@ietf.org" <alto@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms070700030601000609050603"
X-TI-Disclaimer: Disclaimer1
Subject: [alto] Current status and a way forward for ALTO
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/alto>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Mar 2013 15:12:49 -0000
Hi all, following up on recent discussions about the slow progress of the specification process of the ALTO protocol and the considerable amount of extensions being proposed, we would like to propose and discuss a way forward for the work of the ALTO WG. The fundamental consideration is straightforward: The publication process of the ALTO protocol is taking longer than anyone could possibly expect at the start. In the IETF, unfortunately, we are quite used to work under the 80-20 rule -- the remaining 20% of the work takes 80% of the time. However, in this case, while the initial 80% was done in a very active and dynamic way, doing the remainder is turning out particularly painful. This lack of progress is undoubtedly related to the decrease and discontinuity of energy people put in writing, reviewing and discussing the specs. In turn, such situations are often considered to be a highly correlated with the decrease of interest in the topic. But no interest in a standardized protocol implies no need to burn the precious resource required for this as well as for all other IETF publication processes: AD cycles, IESG cycles, RFC-Editor cycles, various review teams cycles, and so on. To be very clear, such situations generally call for the abortion of the publication process itself. At this time the impression is that the interest in the topic is still sound, but this tree is growing disproportionate in its branches and its leaves, rather than the roots. I believe we all agree that this is not sustainable in the long term. As you may have noticed, the fix we propose -- and would like to get feedback on -- consists with forcing the refocusing of all energies on the core blocks, that in the end also all extensions will necessarily have to be based on. We are confident that this phase, that specifically involves the publication process of the ALTO protocol, could be done in the next few weeks, possibly in time for re-arranging the agenda of the face-to-face meeting. But this needs everyone's active contribution in the following tasks: - get acquainted with the issues that have been discussed since the previous meeting, including (in no particular order): o reason phrase for error messages; o relative vs. absolute URIs; o behavior of degenerated map filtering; o merge of cost-mode and cost-type in a single type; o format of endpoint properties; o mandatory vs. optional services; - review the latest version of the protocol, with special attention on the above-mentioned issues; - share your opinion on the list. Please note that this is essential for us to determine consensus, so, regarding the open issue resolution options, even a motivated "don't care" is useful feedback. We'd like to ask the editors of the protocol draft to circulate an update on the changes of the latest version, creating a good starting point for discussion. If we will be able to determine consensus for moving the document forward before the face-to-face meeting (that this time comes very late in the week, and longer than requested), we will be happy to bash the agenda on the list and possibly allocate extra time for unchartered topics that at this time don't have a slot. Comments are welcome. Enrico
- [alto] Current status and a way forward for ALTO Enrico Marocco
- Re: [alto] Current status and a way forward for A… Richard Alimi
- Re: [alto] Current status and a way forward for A… Y. Richard Yang
- Re: [alto] Current status and a way forward for A… Enrico Marocco
- Re: [alto] Current status and a way forward for A… Scharf, Michael (Michael)
- Re: [alto] Current status and a way forward for A… Richard Alimi