Subject: Re: [alto] Resource Attributes -- new draft

From: Wendy Roome <[email-masked]>
Date: Fri, 10 Oct 2014 16:56:13 -0400

See inline.

On 10/10/2014, 15:00, "[email-masked]" <[email-masked]>
wrote:

>Date: Fri, 10 Oct 2014 17:39:19 +0000
>From: "RANDRIAMASY, SABINE (SABINE)"
>	<[email-masked]>
>Subject: Re: [alto] Resource Attributes -- new draft
>Message-ID:
>	<[email-masked]
>nt.com>
>
>Hi Wendy,
>
>
>I find this proposal very useful and agree with the simplicity of having
>attributes rather than capabilities.

Thanks!  And thanks for the comments. They were very helpful.

>
>Here are some questions hoping they're clear:
>
>- section 1.1: I didn't get the meaning of  "A client deduce attributes
>by using the resource. Capabilities cannot be deduced"

I was trying to say the a client could figure out the attributes from the
data (perhaps with some work). But that¹s not really true. And a client
could deduce some capabilities from the data.

So I¹ll drop that paragraph.

>- In the example IRD and sections 3.3 there are 2 terms:
>"authoritative-prefixes" and "authoritative-exclusions" that are sets of
>prefixes.  In Section 3.4 they are characterized by 3 points (i.e. more
>detail). Section 3.4 then  "define the authoritative set with two sets of
>prefixes, one  inclusive, the other exclusive".  Does this mean that the
>"inclusive" set is the "authoritative-prefixes" set?

Yes.  I¹ll rewrite that to make it clearer.

>- section 5:
>* I'm fine with using "attributes" as I understand this term expresses
>that there is additional information on the resource object  e.g.
>"xxx-map"
>** w.r.t. the term authoritative, then how about integrating the term
>"provider" in the attribute to form something like
>"provider-prefixes-incl" or "provider-documented"?

I¹m reluctant to use ³provider², because while it probably will be an ISP,
that is not a requirement. Anyone else care to comment?

>- in general: if we take the set of "authoritative-prefixes": is it
>possible one of these sets, say "1.2.0.0/16",  a specific level of detail
>is provided, that is not provided on another set of the "authoritative
>prefixes", say a particular endpoint cost on metric or property. If yes,
>can the IRD advertise a resource "numerical-metricX-cost-map" available
>on some custom sub-domain that would have an attribute like
>"authoritative prefixes" : "1.2.0.0/16". This would offer flexibility and
>scalability to the provider of the ALTO Server and allow the client to
>get directly to the focused information instead of having to download and
>cross-match large  cost-maps.
>
>Thanks,
>Sabine

Are you asking if an ALTO server could define one network map, for say
1.0.0.0/8, with a large number of PIDs and a lot of detail for that entire
space, plus a separate network map for (say) just 1.3.0.0/16, with a
subset of the big map? The second Network Map (and associated Cost Maps)
would have the same level of detail for that 1.3.0.0/16 subset, but less
detail for the rest of the ISP¹s space. But because those maps are
smaller, clients who are only interested in that /16 subset would prefer
them.

If so, yes. I hadn¹t thought of that, but that¹s a good idea.

On the other hand, my proposal does tie the ³authoritative set² notion to
the Network Map, not the Cost Maps. Thus I assume that all Cost Maps
associated with a Network Map are authoritative for all addresses in the
Network Map¹s authoritative set. In particular, every Cost Map has costs
for all addresses in the Network Map¹s authoritative set.

We could handle Cost Maps with different authoritative sets by allowing
Cost Maps to have authoritative sets as well as Network Maps. However, I¹m
reluctant to add that level of complexity unless there¹s a real need.
Particularly because a server can accomplish that by defining a new
Network Map.

	- Wendy Roome