IETF Last Call Review of draft-ietf-netconf-distributed-notif-18
review-ietf-netconf-distributed-notif-18-genart-lc-halpern-2026-03-04-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-netconf-distributed-notif-16
Reviewer: Joel Halpern
Review Date: 2026-03-04
IETF LC End Date: None
IESG Telechat date: Not scheduled for a telechat

Summary: I think this document is almost ready for publication as a Proposed
Standard RFC.  However, some possible answers to some of my minor comments
below could easily indicate that there are more major issues.

Major:

  While it is possible that I have misread other YANG notification documents,
  it appears that existing YANG Notification mechanisms permit use over TCP and
  TLS.  There is no obvious way for multiple senders to send messages over a
  shared TCP or TLS stream.  Presumably, this implies a restriction on this
  document.  Eithe rthat restriction is missing, or is stated in such a way as
  to not be sufficiently obvious.  Further, assuming DTLS is used for
  notification communication, then some information about what key sharing and
  the other forms of security coordination are required, even if the
  implementation mechanism is out of scope for this draft.  If the intention is
  to permit only pure UDP, then that needs to be stated quite explicitly.  I
  would also expect some discussion of this topic in section 13, Security
  Considerations,

Minor:

   It appears from the last paragraph of section 1 that the authors consider
   that thus draft updates RFC 7923.  If so, the header and abstract should say
   so.

    The terminology appears to assume that one level of delegation is always
    sufficient.  If that is the assumption, the document should say so, and
    explain why that is seen as sufficient.  If the document intends to allow
    for multiple levels of delegation (which strikes me as more useful) then
    there are a number of places that need to be fixed, starting with the basic
    definition of "Component Subscription"

   As I read it "Global" in the document means "device-wide" o r"node-wide".  I
   find this to be awkwward terminology, as Global is usually used to mean a
   network-wide or even broader scope.

   In section 7, Subscription State Change Notification, the text first says
   "the Parent MUST also send subscription state change notifications [RFC8639]
   when events related to subscription management have occurred" which seems
   quite appropriate.  However, the next sentence says "All the subscription
   state change notifications MUST be delivered by the Parent."  At first
   glance, this is merely redundant.  If it is not redundant, then the second
   "MUST" is intended to say somethign additional.  But as I reader I can not
   tell what is being required.

  I would have expected the message-publisher-ids grouping to use the
  message-publisher-id grouping, rather than duplicating the contents of the
  later in the former.  It may be that some nuance of YANG prevents this.

Editorial:

Section 1, last paragraph: s/by the paragraph:/by adding the paragraph/

I suspect that in section 2, Terminologies, in the paragraph that begins "In
addition" that one should substitute s/Global and Component/Global versus
Component/ and s/Parent and agent/Parent versus agent/.

At the beginning of section 3, I suspect that "Network Nodes" is intended to
mean "Network Node".  As distinct to supporting a thing that appears as a
single router to the routing system, but as multiple distinct nodes to the
management system.  If the intention is to cover the later, a lot of work is
needed on this draft.