[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