Dear all, I agree with Per and Andy.
On the client, I think the default statement from the remote-port should be removed. Consumers of this grouping should have the choice of deciding whether this port has a default statement or should be ‘mandatory’ to set. Regarding the local-port, personally I would also remove the default statement, but I can live with it if we set default 0. The text says that any port is used and I agree with Per that it is what usually happens. (I am not sure if there are use cases where the local-port needs to be mandatory to set. In this case we would leave these users out.) On the server, I would remove the default statement for the local port. I think it should be the consumer of the grouping who defines the default value instead of refining it. Also, it would allow consumers of this grouping to set mandatory statements when using this grouping. Regarding draft-ietf-netmod-rfc8407bis, I think section 4.13 already covers this use case. So the draft does not need any change. Regards, Alex > On 22 Sep 2024, at 15:27, [email protected] wrote: > > Dear Per, Kent, Andy, Tom and Alex, > >> A client normally does this, and this is explained in the text for >> ietf-tcp-client.yang > > Exactly. > >> If the default "0" is not refined by when the grouping is used, a server >> might by mistake listen to a random port. I don't know if this would be an >> issue in practice though, one would hope that this minimal smoke test is >> performed before releasing a YANG module that uses the grouping. > > Agree, I thinks that’s the only point we need to align here and move forward > from there. > > As previously voiced, I think it would make sense to adjust the re-useable > grouping section in > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-16#section-4.13 > with the conclusion of this discussion if necessary. In particular the > follow statement: > > "Do not include a "default" substatement on a leaf or choice unless the value > applies on all possible contexts." > > Either we follow the guidance and remove the default statement from the > tcp-client-server grouping for local-port since in the case where the > grouping is used as server, the default statement should be removed. Or we > remark that the server/client application using the grouping must define the > local resp. remote-port. > > My opinion: follow draft-ietf-netmod-rfc8407bis-16#section-4.13 and refrain > from using local and remote-port in reusable groupings since it does not > apply in all possible contexts. Not acceptable is that udp/tcp-client-server > groupings are not aligned with draft-ietf-netmod-rfc8407bis-16#section-4.13 > guidance. > > Best wishes > Thomas > > -----Original Message----- > From: Per Andersson <[email protected]> > Sent: Sunday, September 22, 2024 3:21 AM > To: Andy Bierman <[email protected]> > Cc: Kent Watsen <[email protected]>; Graf Thomas, INI-NET-VNC-HCS > <[email protected]>; [email protected]; > [email protected]; [email protected] > Subject: Re: [netconf] Re: [netmod] Re: Default statements on > udp-client-server groupings > > > Be aware: This is an external email. > > > > Hi! > > I might have missed significant parts of the discussion, if so please correct > me. > > > On Fri, Sep 20, 2024 at 4:19 PM Andy Bierman <[email protected]> wrote: >> >> >> >> On Fri, Sep 20, 2024 at 9:08 AM Kent Watsen <[email protected]> wrote: >>> >>> >>> Let me clarify, I’m trying to close the "default 0” statement on the >>> "local-port” leafs issue. Whether rfc8407bis is updated is a secondary >>> concern. >>> >>> Andy (and others), do you believe this (to never set “default” or >>> “mandatory”) to be a best-practice for reusable groupings? Or more >>> specifically and better for me, do you think the "default 0” statement on >>> the "local-port” leafs is okay or should be removed (in the >>> tcl-client-server draft)? >>> >> >> In this case, default 0 meant use whatever port you want. >> IMO that is a bad practice and should never be done. > > A client normally does this, and this is explained in the text for > ietf-tcp-client.yang: > > leaf local-port { > if-feature "local-binding-supported"; > type inet:port-number; > default "0"; > description > "The local IP port number to bind to for when connecting > to the remote peer. The port number '0', which is the > default value, indicates that any available local port > number may be used."; > } > > I think this is fine. > > For remote-port in tcp-client it should be removed IMHO. There is no reason > to mandate every TCP client to set a default value for the remote port. > > >> In this case, the default is for an application well-known port >> assignment, so the groupings for the application should set the default port. > > For server, I lean towards agreeing with Andy here. > > If the default "0" is not refined by when the grouping is used, a server > might by mistake listen to a random port. I don't know if this would be an > issue in practice though, one would hope that this minimal smoke test is > performed before releasing a YANG module that uses the grouping. > > > -- > Per > _______________________________________________ > netmod mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
