Subject: [alto] Fwd: [apps-discuss] Simple Web Discovery (SWD) Enabling Hosted Deployments

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 07 Nov 2012 20:29:20 +0000

Hi,

This is the recent proposal being orginated inside the OpenIDConnect community I mentioned at the mike that
could be useful for not requiring an U-NAPTR lookup.

I think it is worth considering as an alternative way for ALTO server discovery, since it provides a
simple and  coherent interface (based on HTTP GET) for this purpose.

Be goode,

Begin forwarded message:

From: "Paul E. Jones" <[email-masked]<mailto:[email-masked]>>
Subject: [apps-discuss] Fwd: FW: Simple Web Discovery (SWD) Enabling Hosted Deployments
Date: 5 November 2012 08:44:11.000 EST
To: <[email-masked]<mailto:[email-masked]>>

FYI

________________________________
From: Mike Jones <[email-masked]<mailto:[email-masked]>>
Sent: Mon Nov 05 07:55:14 EST 2012
To: "Paul E. Jones" <[email-masked]<mailto:[email-masked]>>
Subject: FW: Simple Web Discovery (SWD) Enabling Hosted Deployments

Paul, could you do me a favor and forward this note to the apps-discuss list so people have context on why I updated SWD?  For some reason, the list doesn’t appear to be accepting my message.

                                                            Thanks,
                                                            -- Mike

From: Mike Jones
Sent: Sunday, November 04, 2012 9:21 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Simple Web Discovery (SWD) Enabling Hosted Deployments

I’ve updated the Simple Web Discovery (SWD)<http://tools.ietf.org/html/draft-jones-simple-web-discovery> specification to incorporate a means of performing discovery on domains for which it may not be possible to create a .well-known endpoint.  This can often be the case for hosted domains, where it is common for e-mail to be provided but no web server.  This solution was developed in discussions by the OpenID Connect<http://openid.net/connect/> working group.

This draft is being published now to facilitate discussions of the need to enable discovery for hosted domains and possible solutions for doing so at the IETF Applications Area working group meeting at IETF 85 in Atlanta<http://www.ietf.org/meeting/85/>.

The updated specification is available at:

·        http://tools.ietf.org/html/draft-jones-simple-web-discovery-04

Changes made were:
·        Specified that the SWD server for a domain may be located at the simple-web-discovery subdomain of the domain and that SWD clients must first try the endpoint at the domain and then the endpoint at the subdomain.
·        Removed the SWD_service_redirect response, since redirection can be accomplished by pointing the simple-web-discovery subdomain to a different location than the domain's host.
·        Removed mailto: from examples in favor of bare e-mail address syntax.
·        Specified that SWD servers may also be run on ports other than 443, provided they use TLS on those ports.

An HTML formatted version is available at:

·        http://self-issued.info/docs/draft-jones-simple-web-discovery-04.html

(This notice was also posted to http://self-issued.info/?p=891.)

                                                            -- Mike

_______________________________________________
apps-discuss mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/apps-discuss

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
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

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 7 Nov 2012 21:50:24 +0100

Hi all,

After briefly scanning through draft-jones-simple-web-discovery, which seems to be an individual draft, I wonder how the ALTO service would be registered in this solution. The text states: "The definition of URIs used to identify principals and services are outside the scope of this specification." If such issues are not clear as of now, it is unclear to me whether this is indeed a mature technology.

At first sight, compared to that, the U-NAPTR lookup is a well-understood mechanism used by other IETF protocols with similar requirements like ALTO.

Michael

________________________________
Von: [email-masked] [[email-masked]] im Auftrag von Diego R. Lopez [[email-masked]]
Gesendet: Mittwoch, 7. November 2012 21:29
An: [email-masked]
Betreff: [alto] Fwd: [apps-discuss] Simple Web Discovery (SWD) Enabling Hosted Deployments

Hi,

Be goode,

Begin forwarded message:

FYI

                                                            Thanks,
                                                            -- Mike

From: Mike Jones

•        http://tools.ietf.org/html/draft-jones-simple-web-discovery-04

Changes made were:
•        Specified that the SWD server for a domain may be located at the simple-web-discovery subdomain of the domain and that SWD clients must first try the endpoint at the domain and then the endpoint at the subdomain.
•        Removed the SWD_service_redirect response, since redirection can be accomplished by pointing the simple-web-discovery subdomain to a different location than the domain's host.
•        Removed mailto: from examples in favor of bare e-mail address syntax.
•        Specified that SWD servers may also be run on ports other than 443, provided they use TLS on those ports.

•        http://self-issued.info/docs/draft-jones-simple-web-discovery-04.html

                                                            -- Mike

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: "Diego R. Lopez" <[email-masked]>
Date: Fri, 09 Nov 2012 18:18:08 +0000

Hi,

As I understand it, the proposal does not intend to keep a registry of the
URIs used for discovery (it is a parameter for a query using HTTP GET) and,
therefore, ALTO could mandate its own URI, in the same way the U-NAPTR
lookup defines the string to be queried.

The requirements on external registrations are essentially the same in both
cases (none, I think). My point is that an ALTO client would have to rely
only in queries aligned with the rest of the transport protocol, i.e.
plain HTTP(S), and not be required to include support for specific DNS
queries.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 9 Nov 2012 20:53:49 +0100

Diego,

> As I understand it, the proposal does not intend to keep a 
> registry of the URIs used for discovery (it is a parameter 
> for a query using HTTP GET) and, therefore, ALTO could 
> mandate its own URI, in the same way the U-NAPTR lookup 
> defines the string to be queried.
> 
> The requirements on external registrations are essentially 
> the same in both cases (none, I think).

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.

> My point is that an 
> ALTO client would have to rely only in queries aligned with 
> the rest of the transport protocol, i.e.
> plain HTTP(S), and not be required to include support for 
> specific DNS queries.

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.

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.

- 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.

- 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.

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.

Michael

---

From: Sebastian Kiesel <[email-masked]>
Date: Fri, 9 Nov 2012 22:00:42 +0100

On Fri, Nov 09, 2012 at 06:18:08PM +0000, Diego R. Lopez wrote:
...
>  My point is that an ALTO client would have to rely

I think we could even do that within the ALTO protocol, see
http://tools.ietf.org/id/draft-kiesel-alto-alto4alto-00.txt but I also
believe that in a multi-domain scenario this inter-ALTO-server mesh
structure would be much more cumbersome than relying on DNS, and a DNS
resolver stub is anyway included in virtually every networked device.

just my 2 cents
S.

---

From: "Diego R. Lopez" <[email-masked]>
Date: Mon, 12 Nov 2012 14:12:57 +0000

Hi Michael,

> 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.

> - 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 al…

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…

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 t…

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…

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,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: "Diego R. Lopez" <[email-masked]>
Date: Mon, 12 Nov 2012 14:13:00 +0000

Hi Sebastian,

> resolver stub is anyway included in virtually every networked device.

Was not aware about this draft, thanks for the pointer. I think this could
be the base for what I mentioned in my last reply to Michael on relying
on only-ALTO documents to make the specification. I still think that a
single GET query sounds simpler than a direct access to the DNS interface,
as well as the trust considerations are applicable.

What would you think of leaving the current discovery document as it is
now and exploring the possibility of aligning HTTPS discovery with this
ALTO4ALTO idea?

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 14 Nov 2012 21:45:35 +0100

Diego, 

> > 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.

My main point is that this has to be sorted out e. g. in APPAREA before we can rely on an RFC in that space. It is unclear to me whether draft-jones-simple-web-discovery will be a mature and widely used technique any time soon.
 
> > 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.

Sure, a HTTP(S) discovery mechanisms has benefits in a Web world. But DNS also has benefits. There is an engineering tradeoff.

Thus, I disagree that HTTP(S) is the "most natural way".

> > 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

My concern is that RFC 5986 announces an access network domain name, such as "dsl.westcoast.myisp.net".

In my understanding, draft-jones-simple-web-discovery requires that a Web server is running at https://sl.westcoast.myisp.net/.well-known/simple-web-discovery . Furthermore, unless I miss something, there is no need for an DNS entry that maps "dsl.westcoast.myisp.net" to specific host right now.

Thus, for draft-jones-simple-web-discovery to work with RFC 5986, an ISP might have to add new DNS entries for each access network domain name, pointing to a Web server, that then figures out the closest ALTO server URI. With U-NAPTR, the DNS server just gives the closest ALTO server URI directly. 

In summary:

- Both variants are likely to require new DNS entries
- draft-jones-simple-web-discovery requires one more indirection, i. e., one more system to configure, and one more system that has to be aware of the network topology to figure out the closest ALTO server, etc.

Obviously, an alternative would be to specify a new DHCP option that directly announces the URI of the SWD Web Server. That is not very different to a DHCP option that just encodes the ALTO server URI. This is all doable, at least in principle. But the approach of encoding URIs in DHCP got pretty strong pushback in previous ALTO meetings, as far as I recall.

> > - 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.

My point is that ALTO server discovery has to figure out what server can provide guidance for a specific access network, taking into account renumbering, domain name migrations, etc. I am not sure if the organizational unit of an ISP that runs the Web platform really has a better understanding of the access network topology and naming than the organization unit that runs DNS and DHCP. I'd assume the opposite. Sure, it is up to an ISP to sort this out.

> > - 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?

No. The sole purpose for the discovery is to find the URI of a suitable ALTO server.

For instance, I am concerned about a scenario where a transparent HTTP proxy is deployed inside the access network. For instance, assume that all client traffic on port 80 and 443 is forced through a proxy. The scenario is then as follows:

ALTO discovery client <---> HTTP proxy <---> SWD discovery server

In that setting, unless I miss something, it can be difficult for the SWD discovery server to figure what ALTO server could provide guidance to clients behind the proxy. Also, note that the ALTO server does not have to run on port 80 or 443, i. e., ALTO queries may or may not have to pass through the HTTP proxy themselves.

Any middlebox scenario is difficult for ALTO discovery, similar like NAPT. But middleboxes on port 80 and 443 are quite frequent. And I don't think it is well understood how this affects ALTO discovery. 
 
> > 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...

I am not a security expert. But in a typical access network scenario both the network (DHCP infrastructure) and the DNS server is under control of the access network operator. If there is a successful attack on the DNS infrastructure, there are probably worse problems than ALTO server discovery.

Also, please have a look at the security consideration section in draft-ietf-alto-server-discovery. The main attack on ALTO server discovery is to provide a forged ALTO server URI, e. g., an server that provides suboptimal guidance regarding peer-selection. While "worse-than-random" traffic optimization is certainly not optimal, it doesn't seem to result in a tremendous security issue neither.

Thus, unless I miss something, I don't see a significant security and trust benefit for HTTP(S)-based ALTO discovery.

Michael

> 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,
> 
> --
> 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:

---

From: Sebastian Kiesel <[email-masked]>
Date: Thu, 15 Nov 2012 21:26:51 +0100

Hi Diego,

> now and exploring the possibility of aligning HTTPS discovery with this

As you can see the ALTO4ALTO draft has expired quite some time ago.
We've been discussing architectural options for quite a while now
and there was not much positive feedback about this draft so far.

My personal favorite topic is still the third-party discovery. If we
had a working solution for that we could also use it for the resource
consumer initiated discovery.  

But 3pdisc causes lots of headaches so we decided to push forward a
simple solution at least for resource consumer initiated discovery. From
a technical point of view I think both is feasible, DHCP/DNS based
discovery as well as ALTO4ALTO style discovery, but I cannot see a clear
winner.  From procedural point of view the DHCP/DNS way has advantages
as it is based on more established and solid base protocols.

Thanks
Sebastian

---

From: "Diego R. Lopez" <[email-masked]>
Date: Mon, 19 Nov 2012 15:49:19 +0000

Hi Sebastian,

> as it is based on more established and solid base protocols.

As I said in my reply to Michael, probably it makes sense to consider
the HTTP(S) based discovery for the future evolution of the protocol (as
mostly discussed in the i2aex BoF), and stay in the DNS path so we
have a first version of all required mechanisms soon.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: "Diego R. Lopez" <[email-masked]>
Date: Mon, 19 Nov 2012 15:49:18 +0000

Hi Michael,

> My main point is that this has to be sorted out e. g. in APPAREA before we can rely on an RFC in that space. It is unclear to me whether draft-jones-simple-web-discovery will be a mature and widely…

And, as I said, that's a good point in what relates to that draft itself.

> Thus, I disagree that HTTP(S) is the "most natural way".

It is natural in the sense that you conceivably write a full ALTO client
using high-level interfaces to HTTP(S) connections (I think we all
know many of them in Java, Python or Perl just to name a few languages),
without requiring any additional interface to network services, with
the exception of the requirements for discovery.

> - draft-jones-simple-web-discovery requires one more indirection, i. e., one more system to configure, and one more system that has to be aware of the network topology to figure out the closest ALT…

My experience with teams operating production DNS servers is that they are
more keen on deploying "well-known" records (note the quotes, I know
U-NAPTR is part of the standard records) like the CNAMEs that would be
required in the case of using HTTP(S) for discovery. Furthermore, the
additional level of indirection can be an advantage for operations since:

1) You won't need to coordinate the DNS and ALTO teams if they are not the
same. DNS being a currently critical infrastructure makes it harder to tweak.

2) Updates won't require dealing with the usual DNS TTL procedures.

> Obviously, an alternative would be to specify a new DHCP option that directly announces the URI of the SWD Web Server. That is not very different to a DHCP option that just encodes the ALTO server…

Agreed. No intention to re-open this issue anyway.

> My point is that ALTO server discovery has to figure out what server can provide guidance for a specific access network, taking into account renumbering, domain name migrations, etc. I am not sure…

The point here is how operations are organized. You assume DHCP and DNS (and
ALTO) management correspond to the same unit. My point is that whoever is
in charge of the ALTO content (not the Web servers themselves) could make
the updates in the case of HTTP(S) discovery.

> No. The sole purpose for the discovery is to find the URI of a suitable ALTO server.

But, following the same model of U-NAPTR, I guess many ALTO queries could
be peformed as well. But, anyway, I acknowledge it was a rather rhetorical
question.

> Any middlebox scenario is difficult for ALTO discovery, similar like NAPT. But middleboxes on port 80 and 443 are quite frequent. And I don't think it is well understood how this affects ALTO disco…

But the problem you describe would be the same in the case of normal ALTO
queries unless explicit client identification is required. The usage of
HTTP(S) transparent middleboxes is an issue for any protocol relying on
that transport.

> I am not a security expert. But in a typical access network scenario both the network (DHCP infrastructure) and the DNS server is under control of the access network operator. If there is a success…

Sure. But does not preclude that ALTO server discovery would be an additional
service at risk.

> Also, please have a look at the security consideration section in draft-ietf-alto-server-discovery. The main attack on ALTO server discovery is to provide a forged ALTO server URI, e. g., an server…

Indeed, that applies for the current ALTO use cases. But if we think about
those discussed in the i2aex BoF, and the extensions recently proposed on
Scheduled Maps that depicts usage for information on SDN policies, trust
become a much more important part of the equation.

> Thus, unless I miss something, I don't see a significant security and trust benefit for HTTP(S)-based ALTO discovery.

Yeah. You are probably right in that these trust considerations apply to use
cases outside of the current scope. But I still think they are relevant for
the future evolution of the protocol.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Mon, 19 Nov 2012 17:54:21 +0100

Diego, all,

I won't give further pushback, even if I don't agree to quite a number of your statements. Just one further example to explain why SWD won't solve all problems: Even if we replace U-NAPTR by HTTP(S), according to RFC 5986, the ALTO client still needs access to DHCP options, which is yet another non-HTTP(S) interface to care about.

For what it is worth, I am convinced both a DNS-based and a HTTP(S) solution can be engineered, each with pros and cons. Yet, the former variant is much better understood in the IETF, and I fail to see a fundamental benefit of SWD that would compensate this.

In order to move forward, if this helps to sort this issue, I think that we could add a non-normative section to the current draft (or, better, an appendix) that discusses an alternative HTTP-based discovery, in case that such a solution gets widely used in future. It could for instance summarize pros and cons according to this e-mail thread, and leave it up to a future document to standardize this variant (possible, after the mechanism is better worked out in the IETF). It is pretty clear anyway that the current ALTO discovery specification does not address all possible use cases of ALTO (cf. third party discovery).

Any thoughts on that proposal?

Michael

---

From: Sebastian Kiesel <[email-masked]>
Date: Mon, 19 Nov 2012 18:01:32 +0100

> Any thoughts on that proposal?

I propose to add such a discussion to the Deployment Considerations
document, if we want to have one at all.  The discovery document should
contain a technical specification as short and as precise as possible.

S.