ietf
[Top] [All Lists]

Re: On IETF policy for protocol registries

2016-01-22 09:55:33
On Fri, Jan 22, 2016 at 9:57 AM, Eggert, Lars <lars(_at_)netapp(_dot_)com> 
wrote:
On 2016-01-22, at 10:42, Eliot Lear <lear(_at_)cisco(_dot_)com> wrote:
On 1/22/16 10:08 AM, Eggert, Lars wrote:
Right. Or the ability to run multiple web servers on different ports
in a way that results in a priori known URLs, such as result from
assigning unique ports and then including them in the URLs. (That is
why I earlier in the thread proposed to start allowing service names
in addition to ports in URLs.)

But .well-known could easily provide, if nothing else, a redirect to
such services.

If whoever wants to deploy this other service has the ability to change the 
configuration of the server running on 80/443, to add that redirect. For the 
IANA assignment requests we see, they usually don't. (Fragile or impossible 
due to permissions to have one software install change the configuration of 
another.)

Allowing a service name in the URL that is looked up with DNS-SD

Lars

Just to see we are discussing the same issue:

Alice is the administrator of the system, she is running a Web Server
for the company on http://example.com/ with a redirect mapping from
http://www.example.com/*

Bob wants to setup an XXX service which is a Web Service with a HTTP
binding. Alice will let him run that service but does not want to
grant unrestricted access to the corporate Web service on port 80/443.
How do we support that?

Like many other IETF questions, this is one that comes up repeatedly
and consistency is important. It is not at all helpful if the answer
for protocol X is different from that for protocol Y.


The tools we have at our disposal are:

1) TCP/UDP port assignments
2) SRV Records
3) .well-known

Port assignments are a finite resource which was one of the reasons
SRV was invented in the first place. The other equally important
benefit of SRV is that we can direct services to different ports.

One solution to the permissions problem is to use SRV

* Alice assigns Bob the use of a port - 666 say and configures the SRV
record to point to that port:

_xxx._tcp.example.com SRV 0 10 666 example.com

Note that it is not necessary for 666 to be reserved, it is a purely
local choice. It doesn't even need to be constant at the same site.
For testing purposes, this is my current config:

_mmm._tcp.example.com SRV  0 10 9001 mmm.test.com
_mmm._tcp.example.com SRV  0 10 9002 mmm.test.com

Running both service host instances on the same machine makes
debugging the clustering code rather easier.

SRV solves the need to isolate Web Services from the corporate Web
service without needing to assign a separate port per service at the
global level. Bob can run a completely different Web Server which is
quite likely necessary if the Web Service is a standalone executable
with its own server code.


The only problem with this approach is that you don't always want to
burn a port on the local machine. Let us say that Bob has permission
to deploy multiple Web Services. Alice is willing to cut as many SRV
records as he likes but she doesn't want to give him multiple ports
because she has to reconfigure the firewall for each one.

That is what makes use of .well-known the natural adjunct to SRV.