Early Review of draft-ietf-netconf-udp-notif-20
review-ietf-netconf-udp-notif-20-yangdoctors-early-schoenwaelder-2025-04-16-00

- It is kind of funny to do an early review for a document that is
  about five years in the making already... I guess early is relative
  in the IETF.

- I refrain from asking any question on the usage of UDP that I expect
  the transport people to ask.

- Is it really desirable / necessary to mandate that message-ids start
  with 1, i.e., that they are easy to predict?

- Is there a need to spell out that implementations must reject wild
  things like overlapping segments?

- The text in the secure layer section primarily talks about
  encryption. Perhaps it is worth to note that using something like
  DTLS also provides protection against other attacks, like injection
  of malicious packets.

- The definition of the feature dtls says that DTLS 1.2 or later MUST
  be supported, and DTLS 1.3 SHOULD be supported. While this may make
  sense today, what happens if in the future we move on to other
  versions of DTLS? Would it be an option to factor out the specific
  version requirements so that you do not need to revise the modules
  when crypto agilty hits you?

- The enable-segmentation leaf defaults to true. The max-segment-size
  leaf, however, has no default. So is the max-segment-size than an
  implementation specific? Or is an implementation expected to perform
  PMTU discovery?

- The security considerations say that an "encryption layer MUST be
  implemented for non secured networks". As explained earlier, the
  security concern is not just privacy but also message integrity and
  authentication of the senders and receivers as well as limited
  replay protection. A secure transport	is more	than an	encryption
  layer.

- In examples, please use IP addresses allocated for examples.
  Furthermore, show both IPv4 and IPv6 addresses in examples.