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

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

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.
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.

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?

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...

Regards,
Alex

[1] https://mailarchive.ietf.org/arch/msg/netconf/gP5AApWL0Ha8uey9yIQvBlqOJ7A/
[2] https://datatracker.ietf.org/doc/minutes-120-netconf-202407251630/

> On 10 Sep 2024, at 21:18, Kent Watsen <[e-mail]> wrote:
> 
> Hi Andy,
> 
>>> And here is in the “tcp-client-grouping” grouping:
>>> 
>>>      leaf remote-port {
>>>        type inet:port-number;
>>>        default "0”;                          <--  THIS IS THE LINE BEING CONTESTED 
>>>        description                                    ^— it seems 50/50 if useful, but it doesn’t harm either, does it?
>>>          "The IP port number for the remote peer to establish a
>>>           connection with.  An invalid default value is used
>>>           so that importing modules may 'refine' it with the
>>>           appropriate default port number value.";
>>>      }
>>>      leaf local-port {
>>>        if-feature "local-binding-supported";
>>>        type inet:port-number;
>>>        default "0";                          <—  AND THIS LINE ALSO
>>>        description                                    ^— this seems like a *good* value for all services, e.g., universal behavior
>>>          "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.";
>>>      }
>>> 
>>> 
>> 
>> 
>> default "0" should be removed.
> 
> Which one?  I assume just the one in “remote-port”, since the one in “local-port” is used.
> 
> 
>> Using zero as a special value to mean "not set"  is a common hack, but not good practice in YANG.
> 
> Okay, I agree.  It’s better for remote-port to not specify a default "0”.
> 
> NEW:
> 
>      leaf remote-port {
>        type inet:port-number;
>        description
>          "The IP port number for the remote peer to establish a
>           connection with.  Importing modules should 'refine' in
>           an appropriate default port number value.";
>      }
> 
> Good?
> 
> PS: I just made this change to my local copy of the tcp-client-server document, and then recompiled to entire suite of client-server documents without error, meaning all examples are still valid.  This is great because it can be a very focused request to RFC Editor.
> 
> K.
> 
> 
>> Andy 
> 
> 
> _______________________________________________
> netconf mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]