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

[Richard Alimi <[e-mail]>]

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

> Good discussions. Here are some of my comments.
>
> On Sun, Mar 3, 2013 at 12:50 AM, Richard Alimi <[e-mail]> wrote:
>
>> Thank you very much Enrico for helping to target the discussions.
>>
>> My opinions on the outstanding issues that you mentioned below:
>>
>> On Fri, Mar 1, 2013 at 7:12 AM, Enrico Marocco <
>> [e-mail]> wrote:
>>
>>> Hi all,
>>>
>> ...
>>
>>> - get acquainted with the issues that have been discussed since the
>>>   previous meeting, including (in no particular order):
>>>     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 would also support that we leave out free-form strings for error
> messages.
>
>
>>
>>     o relative vs. absolute URIs;
>>>
>>
>> I believe that allowing relative URIs is a good thing.  Speaking from
>> some 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.
>
>
>
>>
>>
>>>     o behavior of degenerated map filtering;
>>>
>>
>> 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.
>

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.


> 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 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.


>
>
>
>>
>>
>>>     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.
>>
>>
> I am also OK with keeping Mode for now.
>
>
>>      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.
>>
>
> 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.
>

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


>
> Richard
>
>  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?
>>
>>
>>>
>>> - 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 mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/alto
>>>
>>>
>>
>> _______________________________________________
>> alto mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/alto
>>
>>
>