Joel M. Halpern wrote:
If the network operators gained anything by having Netconf running on ports below 1024, I would be more inclined to see that used.As far as I can see from the discussion, there is no benefit.And the notion of user space routers is not theoretical. I would like the ForCES CE to be able to be managed using netconf. And it is a specific design goal that ForCES CEs are NOT part of the kernel.And that is just one example.Looking at the list of assigned ports, there are an awful lot of things there that I can imagine would be run on a router control processor, and which better not have their port stolen. (I am not naming protocols because the odds are that some of them are not for routers, and that some I am not even noticing are for routers.) It also looks like there are plenty of host oriented protocols that would need to have their ports remain available above 1024. It sure looks like folks have learned to live with protocols (not just SIP and STUN, but many, many operationally necessary protocols) running above 1024. Hence, it does not seem to me that the risk of "port occupation" is any more relevant for this protocol than for many, many other protocols.So, is there some other reason that I have not seen for wanting to use a low numbered port?
There are ways to allow users specific access to root programs (e,g,. 'su'). There is really no way to logically conclude this discussion. You and Ira are arguing that no protocol should ever use the system port space again, including NETCONF. If this is IESG policy, then I guess we are done discussing it. Some others have said the port number doesn't really matter, except a bit for unix implementations, and some "legacy bias" against using higher port numbers for system services. (Large "don't care" camp) Eliot and I are arguing that the task of configuring a networking device (a server, not a plain host!) is clearly a privileged task in almost all environments, which is NETCONF's chartered purpose. If device configuration and control isn't a system task on a networking device, then I don't know what is. If there are no possible reasons for assigning system port numbers anymore, then IANA can stop asking which range the new protocol should be assigned, and WGs like us don't need to argue about anymore.
Yours, Joel
Andy
At 08:45 PM 3/17/2006, Andy Bierman wrote:Joel M. Halpern wrote:I believe that the correct, current, answer to your question is "nothing." Netconf is clearly not a better use of those ports than a large number of things that have been assigned higher numbered ports.Hence, I think Netconf should live in the same space as everyone else.The 1024 port space was reserved based on a certain model of the world. That model no longer obtains.There is arguably even a good reason that Netconf should not be using, by default, a reserved port. I can easily imagine experimental router implementations where the control logic (and even the router and router config logic) are living in user space. They are not running as priviledged processes. They could support Netconf, and the standard port, if that port were not in the kernel set. But could not use the normal Netconf port if it was in the system space.Using a <1024 port buys us nothing.Your previous paragraph clearly contradicts this statement. I am interested in current practice for operational systems, not experimental systems that might exist in the future. Current practice is to make it harder for users to attach processes to system port numbers that higher port numbers.Not using one is more appropriate, and may even be useful.I disagree -- current practice by network operators is contrary to this conclusion. The logic that no protocol should ever use the <1024 range again instantly makes the "Registered Port" range a more scarce resource for no apparent reason.Yours, Joel M. HalpernAndyAt 07:53 PM 3/17/2006, Eliot Lear wrote:Finally I do wish you would answer the question that was asked several times: if NETCONF is not a good use of well known ports, what is?-- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/netconf/>
-- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/netconf/>