ietf
[Top] [All Lists]

Re: On IETF policy for protocol registries

2016-01-20 16:42:55


On 1/20/2016 12:27 PM, Phillip Hallam-Baker wrote:


-----Original Message-----
From: Joe Touch [mailto:touch(_at_)isi(_dot_)edu]

On 1/20/2016 5:47 AM, Phillip Hallam-Baker wrote:
Having been involved in the creation of a few registries, I think that
the designation of the registry should be determined by the Internet
architecture rather than the personal taste of the people who wrote
the specs.

The specs are the result of either individual contributions or IETF process. 
In
the former case, who else should be involved? In the latter case, the entire
community is already involved in the review of the proposed registry
management procedures.

I don't see it that way.

Part of the problem with IETF process is that every working group
tends to be left to choose its own color to paint its bikeshed when many
times it would be a lot easier if there was at least some guidance.

Agreed so far...

The design of the Internet is supposed to be guided by a very 
specific set of principles, namely simplicity and stability at the
core, anarchy and chaos at the edges. If those are what we accept as
the principles it follows that we should not get in the way of
innovation at the edges without very good reason.

Although those are generally accepted as driving principles, we don't
have anything that forces them either. I.e., for the same reason that
you want flexibility at the edge, others want it in the core.

One of those very good reasons right now is the fact that assigned
port numbers are a finite and dwindling resource.

Yes and no. At our current rate of assignment, which has been basically
stable for the past 13 years, we still don't run out for another 80
years (see RFC 6335, Sec. 7).

The point of the
proposal to use SRV and .well-known in combination is to provide a
direct replacement for an assigned port number that works for a very
large fraction of the problem space (most new protocols are built on
HTTP even if they don't call themselves Web Services).

There are two types of such services:

- those which are services, i.e., stand-alone, custom protocols

        these already qualify for port assignments and have been
        receiving them as fast as they've been requested; this has
        not appeared to put a new or higher load on port assignment

- those which are not services, but are duplicates of HTTP

        these are the "I really wanted port 80, but it's already
        taken, but I need to run my own web server so users can
        open a browser window to see how to monitor or configure
        my device"

        these have been turned down, but not at any astounding rate.
        They are declined as duplicates of HTTP, the same way that
        requesting your own DNS port or NFS port would be.

What we really need is a way for many interfaces to be able to
"register" with their local web server, to reserve URL prefixes, etc.

This is not at all related to services over HTTP.

Joe