See inline. On 10/10/2014, 15:00, "[email protected]" <[email protected]> wrote:
>Date: Fri, 10 Oct 2014 17:39:19 +0000 >From: "RANDRIAMASY, SABINE (SABINE)" > <[email protected]> >Subject: Re: [alto] Resource Attributes -- new draft >Message-ID: > > <a7a5844eb93eb94ab22c2068b10ad65a6add9...@fr711wxchmba01.zeu.alcatel-luce >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 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
