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 ;) > > - 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. > > - 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. > 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... 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 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
