Hi Martin, Thank you very much for the comments. Please see inline:
On Thursday 18 March 2010 7:39:15 am Martin Stiemerling wrote: > Rich, > > a few comments inline: > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf Of > > Richard Alimi > > Sent: Thursday, March 11, 2010 11:30 PM > > To: Jason Livingood > > Cc: [email protected] > > Subject: Re: [alto] #1: Message format > > > > Hi Jason, > > > > Thank you very much for taking a look. Please see below: > > > > On Thursday 11 March 2010 3:38:53 pm Jason Livingood wrote: > > > You may want to make some of these tracker notes more verbose. > > > > At this point, since this is a first stab at fully specifying protocol > > details, my personal feeling is that we are still wide-open for > > discussion on > > the whole document. However, there on a few points that I think are > > particular > > important for this go-around: > > > > - IPv4/IPv6 needs much more thought before integrating it into > > > > the document. In particular, what are the right semantics for > > > > handling IPv4 > > > > and IPv6 with respect to indicating provider preferences? (Some > > > > initial > > > > questions are noted on Issue #9 for this)? > > A simple turn on this: limit a single query-object to an IP address family. > However, a query to the server can include multiple query-objects, i.e., > one each for an IP address family or whatever identifier comes up later on > (e.g. HIP IDs ;) Yes, this is one possibility. One limitation of this approach is that we could only convey a _global_ preference for IPv4, IPv6, etc. That is, a network provider could say "please prefer IPv6 regardless of who you are contacting." Another possible preference that one might want to convey is per-destination Network Location. For example, "please prefer IPv6 when contacting endpoints in ISP A, but please prefer IPv4 when contacting endpoints in ISP B." It would be good to hear some opinions (particularly from service providers) as to whether such preferences this would useful or necessary. If so, we can figure out a reasonable way to encode such preferences (one possibility may be a per-PID attribute). > > - With regard to messaging (including usage of HTTP URIs and the actual > > body > > > > encodings), can people think of issues that might cause problems for > > deployment in an operational network (e.g., load-balancing > > > > configuration)? > > > > Difficult or non-intuitive implementation (both server-side and > > client-side)? Are there any ambiguities you can see? > > I thinking through the current protocol details we have tried to > > > > address > > > > these, but input from others would be extremely helpful. > > I'm still browsing through this and how JSON works. Sounds good. > > - For Redistribution, this is a capability that seemed to get favorable > > > > feedback at IETF76. The current implementation uses HTTP > > > > headers/trailers to > > > > send the signatures, and a certificate is encoded in the Server > > > > Capability > > > > response. The idea is that an ALTO Client can locally cache the > > > > certificate > > > > and only contact the ALTO Server very infrequently even if it is > > > > gathering > > > > ALTO information (i.e., ALTOResponse structs) from other ALTO Clients > > instead of the ALTO Server itself. For this part, what do people > > > > think about > > > > how such redistribution information is encoded in the protocol? Is > > > > there a > > > > clean way to do this without requiring custom HTTP headers/trailers? > > > > Does > > > > the spec sufficiently convey when redistribution should or should not > > > > be > > > > used? > > I'm not sure that the spec is doing good in this respect. The emphasize is > on the security (i.e., using certificates), but an important point is > missing. The server should state in what area (i.e., IP prefix) this > information is allowed to be distributed. > > See draft-kiesel-alto-h12-02 under redistribution: > > The response contains also a resource consumer host location > attribute (rc_hla). This rc_hla echos partially the information from > the request, but gives actually guidance to the ALTO client in what > scope this information can be distributed amongst other peers. In > this response, the server allows the redistribution of the received > guidance to peers with the IP prefix 195.37.0.0/16. This is actually what the "server", "request_uri" and "request_body" attributes are for. As stated in the draft: ... This allows ALTO Clients to which the information is distributed to understand the context of the query and interpret the results. Here, the "context" basically means "the full set of input parameters that would have produced this response." Using this, ALTO Clients can determine the distribution scope. Put another way, if another ALTO Client executed the same query (to the same server) with this particular input, they'd get the same response. The only case where such a guarantee is not available is when other information beyond the URI or ALTO Request Body is used to generate the response. In the current protocol, such cases should not (as a side note, perhaps it should be changed to a MUST NOT..) be redistributed: Note that information about ALTO Client performing the Request and any HTTP Headers passed in the request are not included. If any such information or headers influence the response generated by the ALTO Server, the response SHOULD NOT be indicated as redistributable. Such a case *could* be handled as you mentioned by explicitly giving a scope for redistribution, but I'm wondering what particular queries you were thinking about here, and whether it makes sense to redistribute the responses to such queries. Another way to interpret your concern is from an access-control perspective. That is, using such a scope to indicate which other ALTO Clients have permission to receive this particular ALTO Response. If this is the intention (I'm not implying that you think it is, I'm just trying to cover all of the bases), then I don't think this is reasonable to put in the protocol, since ALTO Clients are in no way bound to follow this advice. > > As mentioned above, I would think that comments about the entire > > document are > > very useful, but the major changes in these couple of revisions have > > been to > > sections 6, 7, and 11 (so feel free to focus there). > > I'm still reading... Great :) Thanks again for the comments! -- Richard Alimi Department of Computer Science Yale University _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
