Hi Wendy, Sorry for the late reply--a big burst of workload in the last few days. Please see below.
On Mon, Jul 15, 2013 at 11:32 AM, Wendy Roome <[email protected]>wrote: > Here's another unresolved question about [5]. Suppose a server provides > full and filtered network map services for the same network map. Does the > server use the same id for both IRD entries? > > If so, fine. > > But "id" usually means "unique id", so if they're not unique ids for each > service, the document should say that. > > This is also a problem for cost map services. Suppose the server provides > full and filtered cost map services for "routingcost". Do those services > have the same id? > > It's tempting to say yes -- that the id refers to the underlying data, not > the particular viewport that returns it. Unfortunately that doesn't work. > Suppose a server provides full-map services for "routingcost" and > "hopcount" metrics. I think we'd agree those services should have > different ids. Now suppose the server offers a filter cost map service > that can return either metric. What's the id for that service? > > So if we want an "id" for each service, I think it has to be a unique id. > Which in turn means that a cost-map service's "uses" field would have to > list the ids of all the network-map services that return that map. > > All good comments! How about we agree on the following guiding principle: every object should have a unique "id"? Suppose we can agree on this principle, then let's try to answer the following questions: - Q1: what is the unique "id" of a network map? A: It is the id+version tag. In this sense, we can say that the id field in the current draft is the "class" name, and the version tag is the "instance"/version name. - Q2: should a filtered map object have the same id as the base map object? A: No, as you said. Because they are different objects, unless they have the same content. For now, let's ignore the overriding-comparison-use-content-based-comparison part, and we say that they are different. A question that one may raise at this point is whether we want to represent the relationship between objects (the filtered map and the base map, in this context). For now, I do not see the need yet, although the Server can remember it internally. But as you may already see, if we start the work of multiple layer topologies, this dependency issue will raise again. - Q3: What is the meaning of "uses"? A: Currently, "uses" only lists the "id", which is only the "class" name, not including the instance/version. Hence, we may encounter consistency problem, for example, the cost map object retrieved may be based on one instance of the "uses" id but the current instance version of "id" is no longer the version. This case is already raised by you and Rich. I am not surprised by Rich's answer of using eventual consistency, because I believe that this is Google's software package management design, but I also heard that Amazon uses snapshot based design, which works as well. In other words, one approach is that we extend the API to return a given version (vtag) of an id, and the uri announced is the base uri that one can retrieve different versions. For the example in [5]: { "uri" : "http://alto.example.com/networkmap";, "media-type" : "application/alto-networkmap+json", "id" : "default-networkmap" }, It means that one can fetch http://alto.example.com/networkmap/<tag> to obtain a given tag of "default-networkmap", if the server still has it. I thought about making "uses" to list the unique id (i.e., the id and vtag), just as software packages list not only python but python-3.3.2. But this then will imply highly dynamic IRD. - Q4: What is the unique id of a cost map object from a resource that lists multiple cost types? A: Consider the example entry in [5], but with two cost types: { "uri" : "http://alto.example.com/costmap/num/routingcost";, "media-type" : "application/alto-costmap+json", "id" : "default-costmap", "uses": ["default-map"] "capabilities" : { "cost-type-names" : [ "num-routing", "num-hop" ] } } I believe that the right semantics is that the server assigns "default-costmap" as the id and gives different version for different cost type. Do they address all of the questions? Thanks! Richard - Wendy Roome > > > On 07/14/2013 15:00, "[email protected]" <[email protected]> > wrote: > > >Message: 1 > >Date: Sun, 14 Jul 2013 09:13:57 -0700 > >From: Richard Alimi <[email protected]> > >To: "Vijay K. Gurbani" <[email protected]> > >Cc: alto <[email protected]> > >Subject: Re: [alto] Chair summary: Status on ALTO protocol document > >Message-ID: > > < > ca+cvdabk_vnxtkuph8wedno8irehgdlf9ws5ovqeps3sfcx...@mail.gmail.com> > >Content-Type: text/plain; charset="iso-8859-1" > > > >Hi All, > > > >We have posted a new version of the protocol draft. We believe that this > >should address all outstanding issues that Vijay has listed here. > > > >Thanks, > >Rich > > > > > >On Wed, Jul 10, 2013 at 12:16 PM, Vijay K. Gurbani > ><[email protected]>wrote: > > > >>Folks: As you are aware, Enrico and my aim has been to get the ALTO > >>protocol document out of the WG to the IESG as soon as possible. > >> > >>We will like to thank the ALTO protocol editor team for taking the > >>time to engage the WG and close open issues in preparation for an > >>upcoming revision (-17) that should be available in the archives on > >>Monday, at the latest. > >> > >>It seems that we are well within the sight of the proverbial light at > >>the end of the tunnel. While it would have been desirable to be a bit > >>ahead in the process of sending the draft to IESG as we go into Berlin, > >>it is nonetheless gratifying to witness the protocol mature further. > >>Besides the editors, Enrico and I thank all the WG participants that > >>have contributed time and discussion points to make it so. > >> > >>Post interim meeting on June 20, 2013, all open issues have been > >>resolved. To wit, these are outlined below. > >> > >> - Jan's questions on security consideration thread [1] are > >> adequately answered by Sebastian's response. > >> > >> - Sebastian's thread on the introduction section [2] appears > >> to have reached consensus with Richard Y.'s response [3] > >> that contains suggested text changes. > >> > >> - The cost map dependency thread [4] seem to have been > >> concluded as well by Richard Y.'s summary of the discussion [5]. > > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
