> On Jan 25, 2024, at 7:50 PM, Dan Shelton <dan.f.shelton@xxxxxxxxx> wrote: > > On Thu, 25 Jan 2024 at 21:25, Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: >> >>> https://datatracker.ietf.org/doc/html/rfc1738 clearly defined >>> "hostport", and that is what should be used here. >> >> RFC 1738 was published very clearly before the widespread use of >> IPv6 addresses, > > Read below, you need [ and ] for IPv6 addresses, or be in parser hell. I'm well aware of how raw IPv6 presentation addresses are wrapped. >> which use a : to separate the components of an >> IP address. > > I think you take the syntax part too seriously, and not Cedric's > message: Address and port should be specified together, as they are > required to be used together to create the socket. It's part of the > address information. I have no argument against the idea that a listener's bind address includes both an address and port. Everyone assumes that fact. Who do you think is going to forget that such that having it baked into our admin interface would be helpful? Note in our case: The usual address is ANY. The usual port is 2049. There's literally no benefit to force everyone to specify both an address or hostname and a port via the user interface, when the command itself can fill in the correct defaults for most people. Look at the mount.nfs command. The address and port are separate because the address carries the high-order information, but the port number has a frequently-used default value, or is obtained via an rpcbind lookup in some cases. Even in URIs: the port number is optional, and for nfs: URIs, the default value is 2049. Truly, this is already the way these admin commands work nearly everywhere else. Here are some examples that would be hard to carry off if we require "hostname@port" : # nfsdctl add_listener xprt udp port 65535 Gives us an ANY listener on UDP port 65535. We could even specify the bind address by device name if we wanted: # nfsdctl add_listener xprt tcp device eth0 port 4045 Gives us a listener on eth0's assigned address at TCP port 4045. That seems quite flexible to me, and does not depend on the administrator providing either an address or hostname. -- Chuck Lever
