Hi Vidja, all, I believe that the charter is narrow and broad enough to cover the topic of ALTO, i.e., the charter is not limiting the solution space. However, when reading your comments, it sounds that you have a very specific solution in mind which is probably not covered by the current charter. [...] > > > > > Overall, I think we should work with the notion of an ALTO > "service" > > > rather than specifically an ALTO "server". > > > > Great. I believe that is exactly what the charter does; the > > charter talks in terms of an "ALTO service" at many places > > (pedantically speaking, the term "ALTO service" occurs eight > > times and the term "ALTO server" occurs six.) The ALTO "server" > > mentioned in the charter refers to the *host* the client > > finally queries (calling it a "peer" is ambiguous; if you > > have a specific term to use here instead of "server", please > > do let us know.) > > > > When we consider ALTO as a distributed service, there may not > necessarily be "a" host that specifically resolves the ALTO queries. > For instance, consider the case where ALTO is a service offered in an > overlay. There may be peers publishing information about themselves on > the overlay and other peers looking up such information. These are not > necessarily client-server style communications. In fact, all that is > important in this context is that the overlay acts as a rendezvous for > sharing such information. Now, of course, that is one possible model. You probably have a publish/subscribe system in mind for p2p overlays. I assume this is not in scope of ALTO. > But, in order to allow for that and other models, I do want the charter > to keep the focus on the service and not on a server. Is the IETF anyhow standardizing services? I don't see this. [...] > > > > We have had discussions on the mailing list about this already. > > Some people felt that providing uplink bandwidth would not be > > a good idea for various reasons running from privacy concerns > > to peers skewing traffic in favor of a high uplink bandwidth. > > Others felt that even if a peers uplink bandwidth was not > > provided, it could calculated nonetheless by other peers. > > That is, there are degrees of disagreement here and > > consequently, including a contentious point in the charter > > would be counter- productive. > > > > I'm afraid that would be a mistake. It actually doesn't matter if we I'm afraid that carrying up/downlink capacity of the peer's local link is a complete waste of resource, as this is not indicating something. For instance, a peer may have a relatively huge uplink but on a shared medium, i.e., a medium which might be shared by hundreds of other hosts/traffic. So what does this information express? > don't agree today on the exact types of information that can be shared. > It is important that we have a protocol that allows peers to publish > ALTO related information. Having this protocol be extensible would > allow for any type of information to be carried in it. So, I strongly The question is, whether the roots of ALTO are actually intended to carry any type of information? The main idea is to carry information to optimize traffic, e.g., decreasing cross ISP traffic. > believe we don't need a recharter to consider any information types - > in fact, I'd be okay if this effort only took on the protocol and if > all information types were to be registered through other means. That > said, I'm not against taking on some subset of those types - I don't > believe that should be the core focus of this work though. > > > > - The ability to register information types with IANA and extend > > > these. > > > > Having a IANA registry for the information type carried in > > the protocol is certainly a possibility the charter does not > > rule out, no? > > > > Well, it is a bit hard to say what the charter does not rule out - > typically we try and do what the charter says we should do. However, > before we get to the registry, we need to agree on the protocol > components. In my view, there are two such components - the publish > protocol mentioned above and the request/response protocol (actually, > more generically, a lookup protocol) mentioned below. It is good to see your ideas but doesn't this go beyond a charter discussion, as your are discussing a solution? This comes back to my initial comment about discussing a specific solution, and we haven't yet reached the times to discuss a solution - at least not here. Martin stiemerling@xxxxxxxxxxxx NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf