[netconf] Re: Review of draft-ietf-netconf-udp-client-server-05

[[e-mail]]

Dear Mex and Alex,

Some feedback on Med's remark as part of my review. I have the same two remarks on the second and third sentence in leaf remote-address and a proposal to simplify and align.

    leaf remote-address {
      type inet:host;
      mandatory true;
      description
        "The IP address or hostname of the remote UDP server.
        If a domain name is configured, then the DNS resolution should
        happen on each connection attempt. If the DNS resolution
        results in multiple IP addresses, the IP addresses
        are tried according to local preference order until
        a connection has been established or until all IP
        addresses have failed.";
    }



  *   # Generalize the description as the groupings are not only meant for configuration.

For me the term management also includes operation, thus reporting state.



  *   # Add some discussion about address family compatibility when both remote/local are present (including when resolving a hostname)

I find this rather obvious and common knowledge.



  *   The description assumes that a name is resolved per connection attempt. I guess this is more a local policy of the UDP endpoint. Resolved names can be cached + local timer to flush out the entries can be supported, etc.

I understand it comes from RFC 9643 and not being used anywhere else. I agree with Med. I suggest to remove the sentence "If a domain name is configured, then the name resolution should happen on each connection attempt."



  *   # Idem for how connections are established, but I guess we have the "local preference" out there. Still, it smells from the text that connections are tried sequentially (and independent of any configured address family) while nothing prevents reusing the grouping in a context with parallel connections are established.

I suggest to remove "according to local preference order" and example https://datatracker.ietf.org/doc/html/rfc6724#section-6 as Med suggested.

And on the use of "client". I suggest instead of " This feature indicates that a client supports" to use " This feature indicates that a NETCONF or RESTCONF client supports" to distinguish from UDP clients. Since this term is only used once in the document, I wouldn't bother to define it in a terminology section.

Best wishes
Thomas

From: [e-mail] <[e-mail]>
Sent: Tuesday, February 4, 2025 8:34 AM
To: [e-mail]
Cc: [e-mail]
Subject: [netconf] Review of draft-ietf-netconf-udp-client-server-05

Be aware: This is an external email.

Hi Alex, all,

FWIW, please find a review of -05 at:

  *   pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-netconf-udp-client-server-05-rev%20Med.pdf
  *   doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/refs/heads/master/2025/draft-ietf-netconf-udp-client-server-05-rev%20Med.doc

I think that the document is in a good shape. There are some few points to address:

# Generalize the description as the groupings are not only meant for configuration.
# Add some discussion about address family compatibility when both remote/local are present (including when resolving a hostname)
# Other (local) resolution libraries may be available than DNS.
# The description assumes that a name is resolved per connection attempt. I guess this is more a local policy of the UDP endpoint. Resolved names can be cached + local timer to flush out the entries can be supported, etc.
# Idem for how connections are established, but I guess we have the "local preference" out there. Still, it smells from the text that connections are tried sequentially (and independent of any configured address family) while nothing prevents reusing the grouping in a context with parallel connections are established.
# Update the security cons section (second + last paragraphs)

Thank you.

Cheers,
Med

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.