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

[Alex Huang Feng <[e-mail]>]

Dear Kent,

Please see inline.

> On 17 Sep 2024, at 01:12, Kent Watsen <[e-mail]> wrote:
> 
> 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)
> 
Note that the sentence above has been added (with its own tweaks) to both client and server groupings (see rfcdiff link above):


As I said above, I don’t see why a consumer of such groupings (both) should be forced to refine a port just to use these groupings. That is why I removed *all* the default statements. I do think the consumer should decide whether such ports are mandatory or have a default number.
> 
>> 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. 
So, from this, your suggestion is leaving the local port from the client to default 0 (in the grouping). And for consumers using this grouping, if they don’t refine it, that would be mean that it is the OS who chooses it. Am I getting this right?
We would still leave out consumers that want to use this grouping with a mandatory local-port on the client. Is this a valid use case?

On the server, I could agree that I would expect being defaulted to its well-known/assigned value (when it exists). However, by adding this default 0 to the grouping, we are forcing the consumer to do so (even if they have a usecase without well-known/assigned ports or needing a mandatory leave)… Do we want to force them? Shouldn’t we leave this to the consumer?
> 
> 
>> 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.

As I said, I am happy to add it back if it is needed.
I’ll leave this thread to udp-client-server groupings and follow up on udp-notif in another thread.

Regards,
Alex

> 
> Kent
> 
>