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

[Kent Watsen <[e-mail]>]

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