Subject: [alto] Lookup Table for Cost Types

From: Richard Alimi <[email-masked]>
Date: Fri, 15 Mar 2013 07:47:20 -0700

For the IRD, there are a couple of ways we could go.

[ In the examples, I'll use the proposal where we add "cost metrics";
adjust as necessary depending on the outcome of that discussion. ]

In the first, we have the cost-types expanded in each of the individual
resource entries:

resources = [
   {
    "uri" : "http://alto.example.com/costmap/num/somemaps",
    "media-types" : [ "application/alto-costmap+json" ],
    "capabilities" : {
        "cost-types" : [
          {"mode" : "numerical", "metric": ”routingcost"},
          {"mode" : "numerical", "metric": ”hopcount"}
        ]
  }
]

A second way is that we could have a lookup table accompanying the IRD:

"cost-types": {
  "num-routing": {"mode" : "numerical", "metric": ”routingcost"},
  "num-hop": {"mode" : "numerical", "metric": ”hopcount"}
}

"resources" = [
   {
    "uri" : "http://alto.example.com/costmap/num/somemaps",
    "media-types" : [ "application/alto-costmap+json" ],
    "capabilities" : {
        "cost-types" : [ "num-routing", "num-hop" ]
  }
]

Some benefits I see to this second approach is that it makes the IRD as a
whole more concise when there are multiple cost maps and just generally
seems "cleaner" to me.  It remains concise if we add more descriptors to a
"cost metric" in the future.  The identifiers are opaque and local to the
IRD so there is no need to register them or even require them to be
consistent between IRDs delivered to a client.

Thanks,
Rich

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 15 Mar 2013 11:35:14 -0400

Richard A.,

Thanks a lot for quickly start the discussions right away! Please see below.

On Fri, Mar 15, 2013 at 10:47 AM, Richard Alimi <[email-masked]> wrote:

> For IRD, I like the second approach later as well. We can later extend the
fields, such as to have:
  "num-routing": {"mode" : "numerical", "metric": ”routingcost",
"description":"My descriptoin"}, by adding some fields that Wendy suggested.

A further step is on individual IR, for example, Cost Map, do we specify
"num-routing" or  ?
{"mode" : "numerical", "metric": ”routingcost"}

If we use "num-routing", then the ALTO Client needs to fetch the name from
IRD, which may or may not be desirable.

But overall, I support putting "mode" and "metric" into a single object for
ease of enumeration. Otherwise, I am flexible.

Richard

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

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 15 Mar 2013 13:47:53 -0400

resource entries:
>> Some benefits I see to this second approach is that it makes the IRD as
a whole more concise when there are multiple cost maps and just generally
>>
> For IRD, I like the second approach later as well. We can later extend
"num-routing" or  ?
> If we use "num-routing", then the ALTO Client needs to fetch the name
from IRD, which may or may not be desirable.

Some possibilities using named model/metric in individual IR

- give a pointer (uri or uri to ird) on where the name can be fetched

- define the name again in the individual IR but this may not be too useful
to define a variable that will be used only once.

Any other possibility?

Richard

> But overall, I support putting "mode" and "metric" into a single object
for ease of enumeration. Otherwise, I am flexible.

---

From: Richard Alimi <[email-masked]>
Date: Fri, 15 Mar 2013 12:51:06 -0700

On Fri, Mar 15, 2013 at 10:47 AM, Y. Richard Yang <[email-masked]> wrote:

> - define the name again in the individual IR but this may not be too
> useful to define a variable that will be used only once.
>
> Any other possibility?
>
I would tend to prefer just stating the cost metric and the cost mode
directly in the individual IR.  The major reason is that it reduces
coupling between the entity providing the IR and the entity providing the
initial IRD.  For example, if the IR were static content hosted somewhere,
then it doesn't even have to be updated when scheme for creating this
identifier in the IRD is changed.  Furthermore, its possible for multiple
IRDs to point to a single IR and they don't even have to have the same
scheme for generating these identifiers.

In general, I don't see a reason for the IR and the IRD to be coupled
(other than saving a few bytes in the IR itself, which I don't think is
going to matter).

Thanks,
Rich

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 15 Mar 2013 16:59:21 -0400

>> >>
>> >> In the first, we have the cost-types expanded in each of the
individual resource entries:
>> >> Some benefits I see to this second approach is that it makes the IRD
as a whole more concise when there are multiple cost maps and just
generally seems "cleaner" to me.  It remains concise if we add more
descriptors to a "cost metric" in the future.  The identifiers are opaque
and local to the IRD so there is no need to register them or even require
them to be consistent between IRDs delivered to a client.
>> >
>> > A further step is on individual IR, for example, Cost Map, do we
specify "num-routing" or  ?

I agree with this design: Named in IRD and unnamed in individual IR so no
linking to IRD, for now, unless we see new uses that benefit from using a
cost type dictionary in individual IR. We can hear if there are other
opinions. How about if no objection by Monday,  we start to revise this
way, as we have cycles next week.Hence, please do comment soon if you feel
strongly otherwise. Of course there are comments opportunities after the
revisions, but we can start revision as soon as possible. What do you think?

Richard
> Thanks,
> Rich
>>
>> Richard
>>
>> > But overall, I support putting "mode" and "metric" into a single
object for ease of enumeration. Otherwise, I am flexible.