[netconf] Re: Default statements on udp-client-server groupings

[Kent Watsen <[e-mail]>]

Hi Alex,

Please see inline below.

K.


> On Sep 16, 2024, at 4:42 AM, Alex Huang Feng <[e-mail]> wrote:
> 
> Dear Kent and Andy,
> 
> Thank you for the provided feedback.
> 
> Here a few comments about udp-groupings:
> - When I meant user, I meant YANG module’s writer or designer, which can be a IETF contributor or not.
> - I agree with Andy that the default port on the generic grouping should be removed.

The above sentence is hard to parse because 1) there’s more than one port (local vs remote) and 2) there’s more than one grouping (i.e., client vs server).

Did you mean “I agree with Andy that the default *remote-port* in the ietf-[tcp/udp]-client-grouping should be removed.”?   This is what I agreed to, and was able to get the RFC Editor to fix in RFC9643-to-be (i.e., the tcp-client-server draft)


> Personally, I would remove all of them, just for the fact that by having them we are limiting the scope of usage of this generic grouping.
> Maybe adding a section (or text) explaining that service models SHOULD define (or prioritize) having a default port request within the YANG module would be useful? See proposal below
> Because I can see a user/designer wanting to implement a YANG module with a “mandatory" port but unable to do so because of this “default” statement.

Here I think you are referring to having the client's and server’s *local-port* to NOT be "default 0”.  

On one level, I agree with you.  i.e., it can always be added by a consumer, and it prevents the local-port from being “mandatory true".

On the flip-side, every socket-level API I’ve used has always defaulted the client’s local-port to “0” (meaning that it’s a wildcard, and the OS gets to choose), and I’ve never seen a client not default its local-port to 0.   As for servers, one might think that the local-port should always default to its well-known/assigned value. 


> Proposed text:
> NEW:
> 	The "remote-port" and "local-port" leaves are defined without any	
>  	   "default" or "mandatory" statements in the "udp-client-grouping"	
>  	   grouping.  YANG models using this grouping SHOULD refine the grouping	
>  	   with a "default" statement, usually with the port allocated by IANA,	
>  	   or a "mandatory" statement, if the ports needs to be always present.
> 
> Diff: https://author-tools.ietf.org/diff?doc_1=draft-ietf-netconf-udp-client-server-03&url_2=https://raw.githubusercontent.com/netconf-wg/udp-client-server/master/draft-ietf-netconf-udp-client-server-04.txt
> 
> Better this way?

I think that it’s fine.  

As written above, such can always be added by consuming modules.


> Regarding udp-notif:
> - Personally I am not against having a default IANA port for UDP-Notif. I actually asked for it on the -13 iteration.
> But from the feedback received on the ML [1] and the last IETF meeting [2], the conclusion was that a port is not needed because an operator already needs to configure the IP address where the collector is located.
> I also see the same use case on the NC/RC Call home RFC. Even though a default port is defined, the operator still needs to configure the IP address of the NC client on the network management system...
> 
> [1] https://mailarchive.ietf.org/arch/msg/netconf/gP5AApWL0Ha8uey9yIQvBlqOJ7A/
> [2] https://datatracker.ietf.org/doc/minutes-120-netconf-202407251630/

It’s true that it’s not a “first contact” situation, but many times Operators want a port for firewalls, wireshark, etc.   And if we’re lucky, udp-notif will be very popular, easily justifying its allocation.

Looking at the numbers, I see a 50/50 split in proponents of the two choices.  This is far from WG consensus (not to mention weak participation).

The minutes [2] show Rob suggesting asking a designated expert.  This is what we should do.

Kent