Subject: [alto] required resources

From: Wendy Roome <[email-masked]>
Date: Fri, 09 Aug 2013 11:09:00 -0400

I have a few questions about required resources that need to be clarified,
especially in the case of multiple network maps.

1. {10.1.1} says that a server MUST provide at least one full Network Map
resource. If a server has multiple network maps, it can satisfy that
requirement by providing a full NM resource for one map -- and it doesn't
have to be the default map -- and filtered network map resources for the
others.

I'm not a big fan of requirements, but I do think a network map isn't very
useful unless the server is willing to give the full map. So I suggest
changing {10.1.1} to say, "An ALTO Server MUST provide a Network Map
resource for each Network Map."

2. {10.1.2} says that a server MUST provide a full cost map for the
"routingcost" metric. I think that's reasonable for the default network
map. But must a server provide that for every network map?

I don't think that's necessary, so I suggest changing {10.1.2} to say, "An
ALTO Server MUST provide a Cost Map resource for the ¹routingcost¹ Cost
Metric, using the default Network Map."

3. Must an ALTO Server provide a full Cost Map resource for every cost
metric it defines? Eg, suppose a server provides a Filtered Cost Map
resource for "hopcount". Must it also provide a Full Cost Map for
"hopcount"? I don't think that's necessary, and I don't think draft 17
requires that.

So if anyone thinks that should be required, speak now or forever hold
your peace.

	- Wendy Roome

---

From: "Y. Richard Yang" <[email-masked]>
Date: Sun, 11 Aug 2013 13:24:20 -0400

Hi Wendy,

Thanks for resolving the consistency issue. Please see below.

> resource for each Network Map."

In -17, there is no "uses" for a filtered network map. Hence, one may not
know from which base NM a filtered NM is derived. So with your proposal, if
we require that each filtered NM MUST have a "uses" to declare the base NM,
the problem is solved. Do I understand it correct?

> Metric, using the default Network Map."

Agree.

> "hopcount"? I don't think that's necessary, and I don't think draft 17

I also agree with this.

Richard

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

---

From: Wendy Roome <[email-masked]>
Date: Tue, 13 Aug 2013 10:50:09 -0400

I don't think that's enough; I think it's much better to explicitly say that
a server MUST provide a full NM resource for each NM.

If we just say that a filtered NM must have a "uses" attribute, then a
server might define a filtered NM that uses a nonexistent resource ID. The
associated cost maps would use that nonexistent resource as well. Yes, most
people will assume that the dependent resource must exist -- but I don't
think the protocol actually requires that.

BTW, a sleazy implementor might even declare the filtered NM as "using"
itself.

In any case, we should say that a filtered NM MUST have a "uses" clause for
a *full* NM. Otherwise a filtered NM is not very useful -- it would be in
limbo, and a client could not connect it with any cost maps.

Also, we should say that cost maps must "use" a full network map resource,
not a filtered one.

- Wendy

From:  "Y. Richard Yang" <[email-masked]>
Date:  Sun, August 11, 2013 13:24
To:  Wendy Roome <[email-masked]>
Cc:  IETF ALTO <[email-masked]>
Subject:  Re: [alto] required resources

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 13 Aug 2013 14:00:05 -0400

Hi Wendy,

Good discussions. Here is some background on my thinking: a frame that I
liked a lot of modern programming language design is type theory, which
tries to enforce correctness (or more realistically, prevent bugs), through
syntax.

Now, let's consider the issue of providing full NMs. Here is some reasoning:

- An ALTO service can have multiple NMs that it does not provide to a
specific client, due to access control. This is legitimate. Hence, the
issue is not that an ALTO service must provide every NM as a resource.

- Hence, the issue is an ALTO Service provides a resource of a filtered NM
without specifying the base full NM. This syntax problem reveals some
semantics issues.

First, underlying, there can be two cases:
  - the filtered NM is based on a full NM which is specified in an
announced resource,
  - the filtered NM is based on a full NM which is not specified in an
announced resource.

>From the IRD, the client cannot distinguish between the two cases (we
require that there is always a default full NM).

Second, the map vtag in the response to a query through a filtered NM
should indicate the base full NM. Consider two filtered NM entries (say due
to load balancing) based on the same full NM. If the map vtag is the
resource name of the filtering resource name, this is not ideal, because
vtag should name the data, not the program accessing the data.

By adding the "uses" to indicate the resource name of a full NM
in a filtered NM, we solve the two issues. Note that these two issues are
different from the issue of if ALTO should provide a full NM uri if it
provides a filtering uri.

There are alternatives to using "uses" to solve the issues. One example is
to introduce an NM name attribute. This alternative reveals that the
current design couples name and locator. In other words, what is the
meaning of a resource name? Does an filtered NM need a name?

The bugs you pointed out below are interesting. We will specify in the
revision the conditions for the "uses" to indicate the correct type.

Thanks!

Richard

On Tuesday, August 13, 2013, Wendy Roome wrote:

> I don't think that's enough; I think it's much better to explicitly say
> that a server MUST provide a full NM resource for each NM.
>

> In any case, we should say that a filtered NM MUST have a "uses" clause
> for a *full* NM. Otherwise a filtered NM is not very useful -- it would be
> in limbo, and a client could not connect it with any cost maps.
>

> - Wendy
>
> From: "Y. Richard Yang" <[email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>>
> To: Wendy Roome <[email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>>
> Cc: IETF ALTO <[email-masked] <javascript:_e({}, 'cvml', [email-masked]');>
> >
> On Aug 9, 2013 11:16 AM, "Wendy Roome" <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>>
> wrote:
> >