IETF Last Call Review of draft-ietf-netconf-distributed-notif-18
review-ietf-netconf-distributed-notif-18-tsvart-lc-westerlund-2026-04-01-00

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

So there are one major issue I found here that is not sufficiently handled.

From Section 4:
"For one subscription, there can be one or more Receivers. And the Subscriber
does not necessarily share the same IP address as the Receivers."

So based on this a subscriber can request a subscription to target another IP
address and port. Especially combined with the publishing mechanism being
defined in
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-25 where one
uses UDP to send the data. That draft is clear that it primarily intended to be
used in managed networks. However it does not appear to contain an
Applicability statement that it MUST only be used in managed networks.
Secondly, I think one should ask one self how does the publisher know that the
receiver is within the managed network and the traffic never goes outside of
the managed network path.

Thus, I would suggest a couple of fixes to address the threat that one can use
the combination of the this document and UDP Notif draft as DoS hose towards
any, even if just by accidental misconfiguration.

First UDP Notif should specify a mandatory to use mechanism to determine that
the receiver is present and willing to receive this traffic. I think this can
be solved with a basic return routability check where the publisher before
sending anything more sends a UDP packet with a token. The receiver must echo
this token back to enable the subscription to deliver any more data. If one
uses DTLS security then that handshake is a better such check.

Secondly, I think both draft needs to include in its security consideration the
risk involved due to malicious or accidental misconfiguration of pointing the
subscription at some target/non-intended receiver. And make clear that this
need to be protected against. Which is handled when using connection oriented
or preferably handshake based security mechanism which can identity the
receiver to the publisher to avoid these risks.

If the above return routability and security considerations are provided I
think this document is fine and do not necessarily need an applicability
statement.

When it comes to UDP Notif I would like to have a bit more concrete requirement
on how to deal with congestion control. For managed networks I think one need
to consider what QoS settings and how to ensure that congestion actually result
in detectable packet losses. I do think this document do need an applicability
statement as this really shouldn't be run over Internet. However, as I noted
above it is not clear how an endpoint actually can determine that this is the
case. It is likely that the proposed mechanism at with a sufficient frequent
reviewing of sent versus received one can determine the amount of packet loss
and if one are above threshold so that one can cancel the subscription. This
appears to have a reasonable promise of a circuit breaker mechanism (See
Section 3.1.10 of RFC 8085:
https://www.rfc-editor.org/rfc/rfc8085.html#section-3.1.10).

Cheers

Magnus Westerlund