YANG Groupings for UDP Clients and UDP Servers
draft-ietf-netconf-udp-client-server-10

Yes

Mahesh Jethanandani
Mohamed Boucadair

No Objection

Andy Newton
Deb Cooley
Éric Vyncke
Gorry Fairhurst
Gunter Van de Velde
Jim Guichard
Ketan Talaulikar
Mike Bishop
Roman Danyliw
(Erik Kline)
(Orie Steele)
(Paul Wouters)

Note: This ballot was opened for revision 09 and is now closed.

Mahesh Jethanandani
Yes
Mohamed Boucadair
Yes
Comment (2025-12-06 for -09) Sent 
Hi Alex, Pierre, and Kent, 

Thank you for the effort put not into this specification. 

I only reviewed the changes since the last time I reviewed the doc. Please find below some minor comments:

# RFC6991bis

CURRENT:
  This module imports types defined in [RFC6991].
  ..
  The "ietf-udp-server" imports types defined in [RFC6991].

I see that draft-ietf-netmod-rfc6991-bis is about to be published as (RFC-to-be 9911). The RFC Editor is likely to ask whether we replace RFC6991 with RFC9911. You may consider adding a note about this.

# RFC8407bis IETF Template

Please replace this part in both modules as follows:

CURRENT:
       This version of this YANG module is part of RFC XXXX
       (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
       for full legal notices.";

NEW:
        All revisions of IETF and IANA published modules can be found
        at the YANG Parameters registry group
        (https://www.iana.org/assignments/yang-parameters).

        This version of this YANG module is part of RFC XXXX; see
        the RFC itself for full legal notices.";

# The grouping can be used for state retrieval as well

CURRENT:
   This YANG module defines the "udp-server" grouping for configuring
   UDP servers.

You may s/configuring/managing or the like.

Please consider a generic wording in the description clause of the module as well.

# The module does not define any data node, so reasoning about configuration is not adequate here. You have it right in the preamble of 3.1 or Section 2, BTW.

Please consider:

OLD:
   Section 3.1 provides an overview of the YANG module for configuring
   UDP servers. 

NEW :
   Section 3.1 provides an overview of the "ietf-udp-server" YANG module.

# Tree Diagram

CURRENT:
7.1.  Normative References

   …

   [RFC8340]  Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
              BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
              <https://www.rfc-editor.org/info/rfc8340>.

Please move this one to be listed as informative per 8407bis:

   If YANG tree diagrams are used, then an informative reference to the
   YANG tree diagrams specification MUST be included in the document.
   Refer to Section 2.2 of [RFC8349] for an example of such a reference.

Cheers,
Med
Andy Newton
No Objection
Deb Cooley
No Objection
Éric Vyncke
(was Discuss) No Objection
Comment (2025-12-16) Sent 
Thanks for addressing my previous DISCUSS/COMMENTS issues, all is well now :)

For archive, my previous ballot:
https://mailarchive.ietf.org/arch/msg/netconf/ULCVlTfEocjHeqHimGHPBogGwBs/
Gorry Fairhurst
No Objection
Gunter Van de Velde
No Objection
Jim Guichard
No Objection
Ketan Talaulikar
(was Discuss) No Objection
Comment (2025-12-17) Sent 
Thanks to the authors and the WG for their work on this document.

The updated normative text in v10 with the BCP14 addresses my original discussion point.

I have an editorial comment - please consider moving examples into the appendix. I am not sure if there is convention/guidance on this topic but I remember seeing documents where all examples were place in the appendix. I will leave this part to the responsible AD.
Mike Bishop
No Objection
Roman Danyliw
No Objection
Comment (2025-12-10 for -09) Not sent 
Thank you to Elwyn Davies for the GENART review.
Erik Kline Former IESG member
No Objection
No Objection (for -09) Not sent 

                            

                        
                    

                
            
                
                    

                        

                            Orie Steele Former IESG member
                        

                        

                            
                            No Objection
                            
                        

                    

                    

                        

                            

                                No Objection 
                                
                                    ()
                                
                                
                                    
                                         Not sent
                                    
                                
                            

                        

                        
                            

                                

                            

                        
                    

                
            
                
                    

                        

                            Paul Wouters Former IESG member
                        

                        

                            
                            No Objection
                            
                        

                    

                    

                        

                            

                                No Objection 
                                
                                    (2025-12-15 for -09)
                                
                                
                                    
                                         Sent
                                    
                                
                            

                        

                        
                            

                                
Like Eric, I have some issues with:

        "The IP address or hostname of the remote UDP server.
        If a domain name is configured, then the name resolution
        should happen before each datagram is sent, unless a
        previously resolved address is cached and still valid.";

It is very weird for an application to "hang on" to the TTL of a DNS record and to stop using it once that TTL has expired. I do not think you should define this here.

Applications tend to resolve the DNS entry, and use the resulting IP address and have some application level detection if/when the remote is not responding, and to then retry a fresh new connection, which will include a fresh new DNS lookup. (whether those DNS lookups are cached on the host, the LAN or elsewhere isn't relevant to the UDP client here)

I would probably just remove the text "If a domain is ..... still valid"