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