Subject: [netconf] Re: WGLC for udp-client-server
From: "Rob Wilton (rwilton)" <[email-masked]>
To: Per Andersson <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 21 Feb 2025 14:36:49 +0000
List-Id: NETCONF WG list <netconf.ietf.org>

Hi,

Thank you to the authors for this work!

We have implemented and I support publication of this document.  I have a couple of questions/comments though.

Moderate level comments:

(1) p 8, sec 3.3.  YANG Module

       list local-bind {

         key "local-address";

Should local-port not also be a key?  I.e., as it stands you cannot bind two separate ports to the same address - but perhaps that is intentional.

I have a nagging feeling that I may have asked the same question during the TCP YANG model review, so perhaps it is right as it is, and I just don't remember the explanation why ;-).

If this does need to be changed, that perhaps the equivalent TCP port YANG module would also need to fixed.

Minor level comments:

(2) p 2, sec 2.1.2.  The "udp-client" Grouping

     grouping udp-client:

       +-- remote-address    inet:host

       +-- remote-port?      inet:port-number

       +-- local-address?    inet:ip-address {local-binding}?

       +-- local-port?       inet:port-number {local-binding}?

RFC 9254 uses "-grouping" after the names of the groupings.  Is there a reason why this is done differently here for the equivalent UDP groupings?  Note, if this is changed then draft-ietf-netconf-udp-notif needs to be updated similarly.

(3) p 2, sec 2.1.2.  The "udp-client" Grouping

   *  The "remote-port" is defined with neither a "default" nor a

      "mandatory" statement.  YANG modules using this grouping SHOULD

      refine the grouping with a "default" statement, when the port

      number is well-known (e.g., a port number allocated by IANA), or

      with a "mandatory" statement, if a port number needs to always be

      configured.  This MAY be ignored when the port number is neither

      well-known nor mandatory to configure, such as might be the case

      when this grouping is used by another grouping.

I think that the last sentence is superfluous here and could be omitted since this is implicit by the SHOULD.  The comment equally applies for local-port in the server model.

(4) p 9, sec 4.  Security Considerations

   Modules that use the groupings that are defined in this document

   should identify the corresponding security considerations.  For

   example, reusing some of these groupings will expose privacy-related

   information (e.g., 'node-example').

This 'node-example' probably needs to be updated - this just looks like boilerplate text.

Kind Regards,
Rob

From: Per Andersson <[email-masked]>
Date: Thursday, 6 February 2025 at 15:39
To: [email-masked] <[email-masked]>
Subject: [netconf] WGLC for udp-client-server
Hi!

This email begins a two-week WGLC on:

YANG Groupings for UDP Clients and UDP Servers
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-client-server-05

Please take time to review this draft and post comments by February
20. Favorable comments are especially welcomed.

None of the authors or contributors have declared IPR:

https://mailarchive.ietf.org/arch/msg/netconf/NncA8JHqZH14wCptMhktgGcngyM/

--
Per, co-chair

_______________________________________________
netconf mailing list -- [email-masked]
To unsubscribe send an email to [email-masked]