Subject: [alto] Current status and a way forward for ALTO

From: Enrico Marocco <[email-masked]>
Date: Fri, 1 Mar 2013 16:12:42 +0100

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

---

From: Richard Alimi <[email-masked]>
Date: Sat, 2 Mar 2013 21:50:16 -0800

Thank you very much Enrico for helping to target the discussions.

My opinions on the outstanding issues that you mentioned below:

> Hi all,
...

>     o reason phrase for error messages;

I'd prefer to leave it out, but I don't feel strongly. Ted Hardie proposed
to remove it in his review of the draft, citing that free-form strings
typically introduce more complexity due to internationalization.  If it is
added back, I would propose that it be a US-ASCII string, just like the
other strings already in the protocol.

I believe that allowing relative URIs is a good thing.  Speaking from some
experience, it actually would have simplified my implementation.

>     o behavior of degenerated map filtering;

I support returning the whole map when the list of sources and destinations
are empty.

>     o merge of cost-mode and cost-type in a single type;

I'd prefer to keep them separate. I believe that the proposals for merging
them will make the registry very messy and cumbersome when new cost types
are registered.

There has been discussion over whether cost mode is useful.  I believe it
is for the following reasons:
(1) There are good use cases for numerical costs (e.g., P4P).
(2) There are good use cases for ordinal costs (e.g., the proxidor
approach).
(3) Removing support for either numerical or ordinal costs means that we
are going to revisit one of the discussions from very early on in the
working group, where people worked together quite well to merge 3 drafts
into a single alto protocol.
(4) It should be up to the server as to whether it supports numerical or
ordinal costs, and a client needs to be able to tell which it is receiving

Cost Mode is currently the way we communicate how the client should treat
the costs it has received from the server.

>     o format of endpoint properties;

The current draft allows them to be generic json values (not only strings),
though the base protocol only requires clients to understand strings.

This is exactly how we treat cost values today, and I don't see a reason
for it to be different.

Extensions can define property and cost values that have other formats,
such as arrays, objects, etc.

>     o mandatory vs. optional services;

I don't think there has been much debate over what is mandatory and what is
optional, right?   Can you point me to this discussion?

> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>
>

---

From: "Y. Richard Yang" <[email-masked]>
Date: Sun, 3 Mar 2013 02:49:35 -0500

Good discussions. Here are some of my comments.

> other strings already in the protocol.

I would also support that we leave out free-form strings for error messages.

> experience, it actually would have simplified my implementation.

I also think allowing relative URIs is good, as the current spec stated,
per Section 5 of RFC3986.

> I support returning the whole map when the list of sources and
> destinations are empty.
>

Thinking the issue a bit, I am somehow leaning towards returning empty
instead of full map.

Consider the Network Location Map filter. Suppose the filter specifies a
set S of PIDs. The semantics (code) appears to be

foreach p in S
  return network map of p

Now, if S is empty, the for loop does not execute and the result should be
empty. If we allow *, then it will return all, but we are discussing empty.

Similarly for Network Cost Map filtering. Given source set S and
destination set D, the code appears to me to be:
foreach s in S
  for each d in D
    return cost from s to d

Hence, when S or D is empty, the program returns null.

This appears to be simple, consistent. Does this make sense?

> the costs it has received from the server.
I am also OK with keeping Mode for now.

> The current draft allows them to be generic json values (not only
> strings), though the base protocol only requires clients to understand
> strings.
>

One possibility to address this discussion is to demonstrate generic json
value for endpoint property up front. For example, we demonstrate the pid
endpoint property as an object: {"value" : "PID1",
"map-vtag": "1266506139"} for the current example (Sec. 9.3.1.6):

  {
    "meta" : {},
    "data": {
      "map-vtag" : "1266506139",
      "map" : {
        "ipv4:192.0.2.34"    : { "pid": "PID1", "example-prop": "1" },
        "ipv4:203.0.113.129" : { "pid": "PID3" }
      }
    }
  }

How does this sound? If there is agreement, we can do a quick update of the
spec and circulate on the mailing list to move on quickly.

Richard

> I don't think there has been much debate over what is mandatory and what
> is optional, right?   Can you point me to this discussion?
>
>
>>

---

From: Enrico Marocco <[email-masked]>
Date: Mon, 4 Mar 2013 15:03:04 +0100

> is optional, right?   Can you point me to this discussion?

I put this as I found it on my list from Atlanta. If my memory serves me
right, Reinaldo mentioned it during the meeting, but there was no
further discussion neither in the room nor on the mailing list. If there
is agreement on this among -- i.e. people are OK with having only map
services defined as mandatory -- we'll be happy to call this a non-issue.

Enrico

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Mon, 4 Mar 2013 17:54:32 +0100

Enrico, all,

I've read -14. Please find below my thoughts on the open questions.

>     o reason phrase for error messages;

I find the arguments against strings somehow convincing.

>     o relative vs. absolute URIs;

I don't care; others have commented on that already a lot.

>     o behavior of degenerated map filtering;

Both behaviors seem reasonable, and I am fine either way. One reason in favor of returning empty maps could be their size: We know that ALTO maps can be very large, i. e., the server could return many megabytes of data for a query that is not really well-specified. But this is not a strong argument, given that ALTO maps can be large anyway, and the client has to be prepared for that. 

>     o merge of cost-mode and cost-type in a single type;

In my understanding, the difference between numerical and ordinal costs is minor, and the former can mostly emulate the latter. But given that this has been in the spec for a long time, I don't see an urgent need to change that.

>     o format of endpoint properties;

Allowing generic json values seems important for potential future extensions.

>     o mandatory vs. optional services;

Regarding that question, -14 looks fine to me as it is. The services of a server will also depend on the ALTO use case, and I don't think we should mandate too much in the base protocol spec.

Thanks

Michael

---

From: Richard Alimi <[email-masked]>
Date: Tue, 5 Mar 2013 20:38:10 -0800

On Sat, Mar 2, 2013 at 11:49 PM, Y. Richard Yang <[email-masked]> wrote:

>> I'd prefer to leave it out, but I don't feel strongly. Ted Hardie
>> proposed to remove it in his review of the draft, citing that free-form
>> strings typically introduce more complexity due to internationalization.
>>  If it is added back, I would propose that it be a US-ASCII string, just
>> like the other strings already in the protocol.
>>
>
>> I believe that allowing relative URIs is a good thing.  Speaking from
>> some experience, it actually would have simplified my implementation.
>>
>

The protocol currently states in Section 9.2.1.3 which documents the
request for the Filtered Network Map:  "If the list of PIDs is empty, the
ALTO Server MUST interpret the list as if it contained a list of all
currently-defined PIDs."

The rationale for this behavior was that the client could use an initial
un-filtered request to discover the available PIDs, while still just using
the Filtered Network Map service.

> This appears to be simple, consistent. Does this make sense?

The rationale behind the current behavior was to be more parallel in
implementation to the Filtered Network Map service.

I could equivalently see just forgetting both of those and asking the
client to fall back to the unfiltered versions of the services (it should
already have the Information Resource Directory, so there isn't
much penalty .  I would vote that they both be made consistent though as
you were pointing out.  We would just need to make this change to the
current Filtered Network Map service too.

>> I'd prefer to keep them separate. I believe that the proposals for
>> merging them will make the registry very messy and cumbersome when new cost
>> types are registered.
>>
> How does this sound? If there is agreement, we can do a quick update of
> the spec and circulate on the mailing list to move on quickly.
>

I think the downside of this encoding for the PID is that its potentially
very verbose since all PIDs in the response should have the same map-vtag.

Of course, if you use compression that would take care of some of the
overhead on the wire.  It would be a larger uncompressed encoding though.

Rich