IETF Last Call Review of draft-ietf-netconf-distributed-notif-17
review-ietf-netconf-distributed-notif-17-yangdoctors-lc-bjorklund-2026-02-25-00

Request Review of draft-ietf-netconf-distributed-notif
Requested revision No specific revision (document currently at 19)
Type IETF Last Call Review
Team YANG Doctors (yangdoctors)
Deadline 2026-03-08
Requested 2026-02-22
Requested by Mahesh Jethanandani
Authors Tianran Zhou , Guangying Zheng , Eric Voit , Thomas Graf , Pierre Francois
I-D last updated 2026-04-21 (Latest revision 2026-04-13)
Completed reviews Yangdoctors Early review of -13 by Martin Björklund (diff)
Opsdir Early review of -14 by Jürgen Schönwälder (diff)
Opsdir IETF Last Call review of -19 by Yingzhen Qu
Yangdoctors IETF Last Call review of -17 by Martin Björklund (diff)
Genart IETF Last Call review of -18 by Joel M. Halpern (diff)
Secdir IETF Last Call review of -19 by Daniel Migault
Tsvart IETF Last Call review of -18 by Magnus Westerlund (diff)
Intdir IETF Last Call review of -18 by Florian Obser (diff)
Comments 
The SEDDIR review should look for any security implications as far as sending traffic from the Component (a.k.a. line cards) to an entity outside the chassis. Similarly, the INTDIR review should examine the implications of establishing an IP network inside and outside the box. The transport experts should examine the use of UDP and any possible issues with sending data over it. Finally, the YANG doctors should (re)examine any changes to the YANG module and OPSDIR on any operational considerations that were not obvious before.
Assignment Reviewer Martin Björklund
State Completed
Request IETF Last Call review on draft-ietf-netconf-distributed-notif by YANG Doctors Assigned
Posted at https://mailarchive.ietf.org/arch/msg/yang-doctors/79azUCQBDUPBuymjTtI9v61ccXg
Reviewed revision 17 (document currently at 19)
Result Ready w/nits
Completed 2026-02-25
review-ietf-netconf-distributed-notif-17-yangdoctors-lc-bjorklund-2026-02-25-00
This is my second YANG doctor's review of this document.

My only comment is about the terminology.  This document claims that it imports
the term "Capability" from RFC 9196, but RFC 9196 doesn't define this term. 
That RFC defines a generic capability model and then defines some specific
capabilities, so it is unclear what this term is supposed to refer to.

The term Global Capability is defined as "The overall subscription
capability..."  What is a "subscription capability"?

It would perhaps help if there was an example that clearly mapped these terms
to specifics.

/martin