On 1/20/2016 12:27 PM, Phillip Hallam-Baker wrote: > > >> -----Original Message----- >> From: Joe Touch [mailto:touch@xxxxxxx] >> >> 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