Hi Michael, On 9 Nov 2012, at 20:53 , Scharf, Michael (Michael) wrote: > U-NAPTR application service tags are registered with IANA, and that is what > the current ALTO discovery draft does. > > I wonder how and where ALTO would register its URI if it were using > draft-jones-simple-web-discovery for discovery. Probably in new IANA registry? > > Such questions would probably have to be sorted out elsewhere in the IETF > before ALTO discovery could rely on draft-jones-simple-web-discovery.
Hmmm, I think you have a point here. But I'll investigate whether there is a URN namespace associated with DNS names, so an URI built according to current registration could be directly used. > I don't really understand your argument regarding the client. The ALTO client > has to perform DNS queries anyway, i. e., DNS is not a new protocol on the > client side. Indeed, but my take is that the client relies on DNS in an indirect way, by requesting HTTP(S) connections that use DNS to parse the URL, but not directly accessing the DNS interface. Therefore, using HTTP(S) again would be the most natural way to perform discovery. > However, my impression is that draft-jones-simple-web-discovery could result > in quite some complexity on the server side. My understanding of the proposal > is that, if applied to ALTO, an access network provider would have to run a > Web server for each access network domain names announced in the DHCP option > according to RFC 5986. I could imagine that this results in quite some > operational issues for an ISP: > > - Today, an operator might not run Web servers for domain names such as > "dsl.westcoast.myisp.net", i. e., this might require a new server > infrastructure. Compared to that, the DNS infrastructure already exists and > just has to be extended by entries. Deploying virtual Web servers is a rather trivial task (in a typical Apache setup, we are talking about adding a few lines to configuration files), and you need Web servers anyway to run the ALTO base protocol > - There may be synchronization issues, e. g. in case of domain mame > renumbering, because different databases have to be kept in sync. Right now, > for ALTO discovery to work well, an ISP may have to keep DHCP and DNS in > sync, which are both well-established network services. With > draft-jones-simple-web-discovery, a third Web infrastructure has to be taken > into account. Again, this maintenance is straightforward, since it is related to dealing with virtual servers in any modern Web server framework. It is more a matter of which branch in an organization has access to DHCP, DNS, and Web servers for infratsructural matters. My point is that DNS is usually the most hard to change, due to it being a critical service for many others. > - I could imagine that load balancing mechanisms and strategies for DNS could > be quite different from Web load balancing, also taking into account HTTP > proxies etc. ALTO discovery requires that a topologically close server is > discovered. The DNS infrastructure is a network service and thus somehow > linked to topology, unlike a Web platform. Sorry, I do not follow your reasoning here. Will not that imply that the whole ALTO infrastructure would be better suited for running on DNS? > Right now, all the points are speculation. It might be doable to engineer an > ALTO discovery solution based on draft-jones-simple-web-discovery, if it > becomes an IETF standard. But, as of now, I don't really understand what the > benefit would be for ALTO. Unifying protocol stack to a single one, HTTP(S), and relying in a fully controled server framework. And there is another reason related to trust and security: while HTTPS is well understood and easy to deploy, DNSsec is in not such a good situation. A trustworthy discovery mechanism would be much simpler to implement and easier to adopgt by using HTTPS... If the current status of draft-jones-simple-web-discovery we could even dare incorporate in the draft the mechanisms there that are related to ALTO discovery. As far as I can tell, they are rather straightforward. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: di...@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
