Hi Rich, For the IPv6/IPv4 part: I would give it an easy start and to simply return two lists (if asked for), one for IPv4 and one for IPv6. Expressing relationships or dependencies between them would go too far (it's not about us to solve the IP4/IPv6 transistion) and would also increase the complexity in the protocol and also the implementation.
Martin [email protected] NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > -----Original Message----- > From: Richard Alimi [mailto:[email protected]] On Behalf Of > Richard Alimi > Sent: Thursday, March 18, 2010 2:50 PM > To: Martin Stiemerling > Cc: [email protected] > Subject: Re: [alto] #1: Message format > > 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
