Document: draft-ietf-netconf-distributed-notif Title: Subscription to Notifications in a Distributed Architecture Reviewer: Joel Halpern Review result: Almost Ready
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. _______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
