On Fri, Jul 19, 2013 at 1:30 AM, Sebastian Kiesel <[email protected]>wrote:
> Hi Richard, > > On Fri, Jul 19, 2013 at 01:12:34AM -0700, Richard Alimi wrote: > > On Fri, Jul 19, 2013 at 12:55 AM, Sebastian Kiesel <[email protected] > >wrote: > > > > > Richard, > > > > > > sure. we should get it done ASAP. but i am wondering whether we can > ever > > > reach consensus if we have different understandings what a server is. > > > > > > if you believe this is an academic discussion and the issue can be > > > resolved without a definition, forget my question ... > > > > > > > If it helps, here's how I would interpret it and why: > > > > RFC 5693 defines the following: > > > > ALTO Service: Several resource providers may be able to provide the > > same resource. The ALTO service gives guidance to a resource > > consumer and/or resource directory about which resource > > provider(s) to select in order to optimize the client's > > performance or quality of experience, while improving resource > > consumption in the underlying network infrastructure. > > > > > > ALTO Server: A logical entity that provides interfaces to the > > queries to the ALTO service. > > > > > > The protocol draft states the following: > > > > > > > > In this architecture, an ALTO Server prepares ALTO Information; an > > ALTO Client uses ALTO Service Discovery to identify an appropriate > > ALTO Server; and the ALTO Client requests available ALTO Information > > from the ALTO Server using the ALTO Protocol. > > Sure. I know these paragraphs. But these would be compatible with all > of the three definition approaches in my original mail (see below). > So I am wondering whether we need a more precise definition. What is > the unique thing that defines an individual ALTO server? The single IRD, > the single network map, ...? > I don't think we should be defining a "server" as being parameterized by certain resources in the ALTO protocol. A server is the logical entity with whom the client is interacting when it executes the steps documented in the protocol. (And I tend to think the definitions we have already convey that.) Extending the protocol in the future would be hampered if we started defining "server" by some set of resources that were defined in the base protocol. > > > > The ALTO Protocol is a RESTful protocol which is built upon links > > between resources. As such, I interpret ALTO Server in the way that > > Richard Yang mentioned earlier (analogous to "website"). > > I fully agree. > > Thanks > Sebastian > > > > On Fri, Jul 19, 2013 at 12:42:40AM -0700, Richard Alimi wrote: > > > > As one of the editors who needs to ensure this draft gets done ASAP, > we > > > > need to close on this issue of dependencies in which we discussed > having > > > > multiple network maps per server. We opened a thread on June 20th > asking > > > > for input on a proposal and received positive feedback. Based on the > > > > responses, we implemented what we believed satisfied the discussion > > > there. > > > > > > > > I recognize that there are different opinions here, but we need to > have a > > > > single conclusion that can go into the draft. Can the chairs help > us to > > > > come to a consensus here? > > > > > > > > Thanks, > > > > Rich > > > > > > > > > > > > On Thu, Jul 18, 2013 at 1:30 PM, Sebastian Kiesel < > [email protected] > > > >wrote: > > > > > > > > > Wendy, > > > > > > > > > > Thanks for answering! I know that this might be the starting > point for > > > > > a longer discussion thread but I feel it has to be done ... > > > > > > > > > > My approach for finishing the costmap discussion would be based on > two > > > > > steps: > > > > > > > > > > 1. Agree on a definition what "an ALTO server" is > > > > > > > > > > 2. Optionally add furhter constraints/rules/requirements for "an > ALTO > > > > > server" as defined in step 1. > > > > > > > > > > > > > > > > > > > > ----- > > > > > > > > > > For step 1, my feeling is that the definition should be related to > > > > > the IRD, as this is also the result of the discovery procedure. > > > > > > > > > > My proposal > > > > > > "An ALTO Server is an IRD with a given URI, plus all the > information > > > > > > resources listed therein" > > > > > would allow it to distribute an ALTO server over multiple boxes, > > > > > processes, etc. > > > > > > > > > > > > > > > For step 2, we *could* then add the constraint that an IRD may only > > > > > list one network map. I can understand your arguments below, but > > > > > I still need to think about it for a short while. > > > > > > > > > > > > > > > Does this make sense to you? > > > > > > > > > > Thanks > > > > > Sebastian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jul 18, 2013 at 04:07:51PM -0400, Wendy Roome wrote: > > > > > > Thanks for asking! > > > > > > > > > > > > Personally, I prefer to think of "an ALTO Server" as *one* > network > > > map > > > > > and > > > > > > all the cost map resources associated with that network map. If > an > > > > > > organization offers several network maps, fine! They just offer > > > several > > > > > > ALTO Servers. > > > > > > > > > > > > Note that "ALTO Servers" are orthogonal to "boxes" or > "hostnames". > > > One > > > > > > "ALTO Server" can span many physical hosts. Or several "ALTO > > > Servers" can > > > > > > use the same box. That's up to the provider. The IRD gives the > > > provider a > > > > > > lot of flexibility. Our examples not withstanding, nothing says > that > > > all > > > > > > services advertised in one IRD have to be on the same host. > > > > > > > > > > > > Here's why I prefer that over the current scheme of multiple > network > > > maps > > > > > > within one server: > > > > > > > > > > > > * If there are multiple network maps, the client must be > configured > > > with > > > > > > the id of the desired network map, as well as the uri of the > IRD. If > > > > > > there's one network map per server, the client just needs the > uri of > > > the > > > > > > IRD. Thus the "one network map" interpretation pushes the 'id' > of the > > > > > > network map into the uri of the IRD. Isn't one of the tenants of > > > "REST" > > > > > > that resources should be identified by uris? > > > > > > > > > > > > * If an ALTO server has multiple network maps, the cost-map > services > > > are > > > > > > partitioned by network map. There are no interactions between > them, > > > and > > > > > no > > > > > > advantage to folding them together. The client picks the network > map > > > it > > > > > > wants, and ignores the cost services associated with other maps. > > > > > > > > > > > > * Draft 17 adds a lot of baggage to partition the set of > services by > > > > > > network map. If a server has one network map, none of that is > > > necessary. > > > > > > > > > > > > Okay, Sebastian, I was going to keep my big mouth shut. But you > had > > > to > > > > > ask! > > > > > > > > > > > > - Wendy Roome > > > > > > > > > > > > > > > > > > On 07/18/2013 15:43, "[email protected]" < > [email protected]> > > > > > wrote: > > > > > > > > > > > > >Message: 2 > > > > > > >Date: Thu, 18 Jul 2013 21:18:16 +0200 > > > > > > >From: Sebastian Kiesel <[email protected]> > > > > > > >To: alto <[email protected]> > > > > > > >Subject: [alto] What is an ALTO server? > > > > > > >Message-ID: <[email protected]> > > > > > > >Content-Type: text/plain; charset=us-ascii > > > > > > > > > > > > > >Dear all, > > > > > > > > > > > > > >at a first glance the the question may seem strange, but > reading the > > > > > > >recent discussions on Costmap IDs / IRD structures, I'm > wondering > > > how > > > > > > >we define "an ALTO server"? > > > > > > > > > > > > > >- A physical box? (hopefully not!) > > > > > > > > > > > > > >- The software process that listens on <IPaddress>:80/tcp and/or > > > > > 443/tcp ? > > > > > > > > > > > > > >- All the information resources that are listed in an IRD with > > > > > > > a given URI? > > > > > > > > > > > > > >What do you think? > > > > > > > > > > > > > >Thanks > > > > > > >Sebastian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > alto mailing list > > > > > > [email protected] > > > > > > https://www.ietf.org/mailman/listinfo/alto > > > > > _______________________________________________ > > > > > alto mailing list > > > > > [email protected] > > > > > https://www.ietf.org/mailman/listinfo/alto >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
