wrote: > Dear Martin, > > We would appreciate your feedback. Sorry about this delay. I don't have any further comments. /martin > > Best wishes > Thomas > > -----Original Message----- > From: Graf Thomas, INI-NET-VNC-E2E > Sent: Friday, May 16, 2025 9:16 AM > To: Martin Björklund > Cc: yang-doctors@ietf.org; draft-ietf-netconf-distributed-notif.all@ietf.org; netconf@ietf.org > Subject: RE: Yangdoctors early review of draft-ietf-netconf-distributed-notif-13 > > Dear Martin, > > Thanks a lot. The changes are here: https://author-tools.ietf.org/diff?doc_1=draft-ietf-netconf-distributed-notif-13&url_2=https://raw.githubusercontent.com/network-analytics/draft-ietf-netconf-distributed-notif/refs/heads/master/draft-ietf-netconf-distributed-notif-14.txt > > I changed the title from "Subscription to Distributed Notifications" to "Subscription to Notifications in a Distributed Architecture" and expanded the Global and Component Capability terminology to describe the capability relationship to RFC 9196. > > Let me know wherever this addresses your concerns and gives the document more clarity. > > Best wishes > Thomas > > -----Original Message----- > From: Martin Björklund > Sent: Wednesday, May 14, 2025 9:29 AM > To: Graf Thomas, INI-NET-VNC-E2E > Cc: yang-doctors@ietf.org; draft-ietf-netconf-distributed-notif.all@ietf.org; netconf@ietf.org > Subject: Re: Yangdoctors early review of draft-ietf-netconf-distributed-notif-13 > > > Be aware: This is an external email. > > > > wrote: > > Dear Martin, > > > > Thanks. > > > > MB> This fixes the singular/plural issue. But why did you change the module name in the IANA Considerations section? > > > > That was not intentional. Apologies. Fixed. > > > > MB> Do you have some proposed changes to the document that address this? > > > > No I don't. I don't understand what should be addressed. Could you detail and perhaps make a proposal? > > > > The term "Distributed Notifications" is being used in the title > > "Subscription to Distributed Notifications" of the document. > > And this is what I think the problem is. The title introduces a new term that is not used in the document. I think the title should reflect what the document is about. > > I think you mean that you add support for a distributed architecture in the server. > > > > In the abstract the relation to RFC 8639, Subscription to YANG Notifications, is being described. > > > > MB> The draft says: > > > > To preserve data integrity down to the publisher process, the Message > > Publisher ID in the transport message header of the YANG notification > > message is introduced. > > > > MB> How does this ID help preserve data integrity? > > > > It helps to identify from which publishing process the notification was published from and wherever from all publishing processes messages are being published from. With sequence-number, https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notif-envelope-01#section-3.4.1, per publishing process, each message can uniquely be identified, loss recognized and related to a transport session and publishing process. > > Ok! I think this explanation would help in the document. > > > > MB> Well, does the Global Capability refer to one of the capabilities defined in RFC 9196? > > > > The term Global Capability not. The term capability yes since it is relating to YANG-Push capabilities defined in RFC 9196. The term Global refers to its relation within the distributed system to the Component Capability and Subscription. My suggestion is to reference the term capability in the terminology section to RFC 9196. > > The document talks about how the Published Master exposes the Global Capability, so I think it must be clear what this Global Capability is. Is it a specific capability defined elsewhere? If so, which one? > If not, then what is it? > > > > /martin > > > > > > > > MB> But the text in the document claims that they support *this* document. > > > > Fair point. I removed the YANG-Push receiver implementations as they are only related to udp-notif and currently only perform JSON and not YANG transformation. > > > > > > Here the updated diff with the following changes: > > > > - Added term Capability with normative reference to RFC 9196 > > - Removed YANG-Push receiver implementations from implementation > > status section > > > > https://auth/ > > or-tools.ietf.org%2Fdiff%3Fdoc_1%3Ddraft-ietf-netconf-distributed-noti > > f-13%26url_2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fnetwork-analy > > tics%2Fdraft-ietf-netconf-distributed-notif%2Frefs%2Fheads%2Fmaster%2F > > draft-ietf-netconf-distributed-notif-14.txt&data=05%7C02%7CThomas.Graf > > %40swisscom.com%7C57f3ab558a6f4c336b9b08dd92b904f9%7C364e5b87c1c7420d9 > > beec35d19b557a1%7C0%7C0%7C638828046473072519%7CUnknown%7CTWFpbGZsb3d8e > > yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF > > pbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=zSfy4HgwjrC7P70Z56yQBLtzn > > Cc6UYHkrWJWthlbnRE%3D&reserved=0 > > > > > > Best wishes > > Thomas > > > > -----Original Message----- > > From: Martin Björklund > > Sent: Monday, April 28, 2025 5:47 PM > > To: Graf Thomas, INI-NET-VNC-E2E > > Cc: yang-doctors@ietf.org; > > draft-ietf-netconf-distributed-notif.all@ietf.org; netconf@ietf.org > > Subject: Re: Yangdoctors early review of > > draft-ietf-netconf-distributed-notif-13 > > > > > > Be aware: This is an external email. > > > > > > > > Hi, > > > > > > wrote: > > > Dear Martin, > > > > > > I would appreciate your feedback wherever the proposed changes are > > > addressing your comments and the clarifications to the questions > > > answered your questions. > > > > See inline. > > > > > > > > > > > > Regarding leaf-list being singular, Med already gave me the pointer > > > to > > > > > > https://data/ > > > tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netmod-rfc8407bis-24%23se > > > ct > > > ion-4.3.1&data=05%7C02%7CThomas.Graf%40swisscom.com%7C18f26fb259ec45 > > > 97 > > > 659208dd866bf015%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638814 > > > 52 > > > 0341458926%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwL > > > jA > > > uMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C% > > > 7C > > > &sdata=ibea7GorPPQsZ4ge2F0OsNbxV941tlvo31ugi04sO%2FU%3D&reserved=0 > > > List identifiers SHOULD be singular with the surrounding container name plural. > > > > > > Best wishes > > > Thomas > > > > > > -----Original Message----- > > > From: Graf Thomas, INI-NET-VNC-E2E > > > Sent: Saturday, April 12, 2025 9:43 AM > > > To: Martin Björklund ; yang-doctors@ietf.org > > > Cc: draft-ietf-netconf-distributed-notif.all@ietf.org; > > > netconf@ietf.org > > > Subject: RE: Yangdoctors early review of > > > draft-ietf-netconf-distributed-notif-13 > > > > > > Dear Martin, > > > > > > Thanks a lot for the YANG doctors review. > > > > > > I applied "https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-22#name-template-for-ietf-modules" and made the leaf-list singular by removing the "s". Could you please refer me to the document where this is being defined that leaf-lists are singular. I wasn't able to find any reference. In particular I would have expected it in draft-ietf-netmod-rfc8407bis-22. In case it is missing, I will bring this to the draft-ietf-netmod-rfc8407bis-22 authors. > > > > > > https://auth/ > > > or-tools.ietf.org%2Fdiff%3Fdoc_1%3Ddraft-ietf-netconf-distributed-no > > > ti > > > f-13%26url_2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fnetwork-ana > > > ly > > > tics%2Fdraft-ietf-netconf-distributed-notif%2Frefs%2Fheads%2Fmaster% > > > 2F > > > draft-ietf-netconf-distributed-notif-14.txt&data=05%7C02%7CThomas.Gr > > > af > > > %40swisscom.com%7C18f26fb259ec4597659208dd866bf015%7C364e5b87c1c7420 > > > d9 > > > beec35d19b557a1%7C0%7C0%7C638814520341481281%7CUnknown%7CTWFpbGZsb3d > > > 8e > > > yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT > > > WF > > > pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=XoDh%2B8WNxrBusi67FE7XSJ%2F > > > oH > > > t1GDKgMpS9dj0Qfewg%3D&reserved=0 > > > > This fixes the singular/plural issue. But why did you change the module name in the IANA Considerations section? > > > > > > > Please let me know wherever this addresses your points on the YANG module. I will publish the document then. > > > > > > > > > MB> As for the document as a whole, I have some concerns. It is not at all clear to me which problem this document tries to solve, and the document feels unfinished. The title of the draft is "Subscription to Distributed Notifications", but there is no definition of a "distributed notification". > > > > > > That is correct. There is no "distributed notification". The draft describes how a YANG-Push subscription is being decomposed and managed on a YANG-Push publisher. It augments subscription state change and push-update and push-change-update notifications with message-publisher-id entities. > > > > Do you have some proposed changes to the document that address this? > > > > > > > > > > > > > MB> What is a "Component Subscription"? Is it a NETCONF subscription or something else? > > > > > > Towards the subscriber > > > (https://dat/ > > > atracker.ietf.org%2Fdoc%2Fhtml%2Frfc8639%23section-1.2&data=05%7C02% > > > 7C > > > Thomas.Graf%40swisscom.com%7C18f26fb259ec4597659208dd866bf015%7C364e > > > 5b > > > 87c1c7420d9beec35d19b557a1%7C0%7C0%7C638814520341490164%7CUnknown%7C > > > TW > > > FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi > > > Is > > > IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=43757tZ1yf%2B%2B > > > Ca > > > 0BzdDf3%2FUD15fZ1mmP19o0N3Md%2Bjc%3D&reserved=0) it is a Subscription. > > > Within the distributed system, the "Component Subscription" is being > > > decomposed to "Component Subscription". See Figure https://data/ > > > tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netconf-distributed-notif > > > %2 > > > 3arch&data=05%7C02%7CThomas.Graf%40swisscom.com%7C18f26fb259ec459765 > > > 92 > > > 08dd866bf015%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C6388145203 > > > 41 > > > 499221%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuM > > > DA > > > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s > > > da > > > ta=c5KCIQhVqNJUDz4ln4q3IRk8X6o0Fsm0QIA8ftv2c4I%3D&reserved=0 > > > > > > > > > MB> Why is the "message-pubslisher-id" an unsigned integer? As a client, I am presented with a set of unsigned integers with no further explanation. What is the client supposed to do with this information? > > > > > > Because it is an identifier. The message-publisher-id enables a YANG data consumer (https://datatracker.ietf.org/doc/html/draft-ietf-nmop-yang-message-broker-integration-07#section-4.7) to recognize from which YANG-Push publisher process the message was published from. > > > > The draft says: > > > > To preserve data integrity down to the publisher process, the Message > > Publisher ID in the transport message header of the YANG notification > > message is introduced. > > > > How does this ID help preserve data integrity? > > > > > > > MB> Section 5, Expose the Global Capability that can be served by multiple, Publisher Agents What does this requirement mean? What is the Global Capability that must be exposed, and how is it exposed? > > > > > > The term "Global Capability" is described in https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif#section-2 as following: > > > > > > Global Capability: The overall subscription capability that the group of Publishers can expose to the Subscriber. > > > > > > Would a reference to https://datatracker.ietf.org/doc/html/rfc9196 to bring more clarity? > > > > Well, does the Global Capability refer to one of the capabilities defined in RFC 9196? > > > > > > > > > > MB> 12.2 and 12.3 to see if I could understand more about how this draft could be used, but as far as I could tell, these projects do not actually implement this draft. > > > > > > All listed implementations support draft-ietf-netconf-udp-notif. > > > > But the text in the document claims that they support *this* document. > > > > > > > > /martin > > > > > > > > > Implementations in Section 12.4 and 12.5, 6Wind VSR and Huawei VRP (NE40, NE8000, MA5800) have implemented the document. Cisco is working on implementation. I detailed which implementation supports the Subscription Decomposition in -14 to make it more clearer then just listing the YANG-Push publisher support. > > > > > > Best wishes > > > Thomas > > > > > > -----Original Message----- > > > From: Martin Björklund via Datatracker > > > Sent: Sunday, March 30, 2025 8:07 PM > > > To: yang-doctors@ietf.org > > > Cc: draft-ietf-netconf-distributed-notif.all@ietf.org; > > > netconf@ietf.org > > > Subject: Yangdoctors early review of > > > draft-ietf-netconf-distributed-notif-13 > > > > > > > > > Be aware: This is an external email. > > > > > > > > > > > > Reviewer: Martin Björklund > > > Review result: Not Ready > > > > > > Here is my YANG doctor's review of draft-ietf-netconf-distributed-notif-13. > > > > > > From a pure YANG perspective, this module is trivial. I just have two minor comments: > > > > > > o pyang --ietf complains that the module description doesn't contain > > > the (correct) IETF Trust Copyright statement. > > > > > > "Simplified BSD License" should be "Revised BSD License" > > > > > > o You have "leaf-list message-publisher-ids". By convention, lists and leaf-lists normally > > > have names in singular ("leaf-list message-publisher-id") > > > > > > > > > > > > As for the document as a whole, I have some concerns. It is not at all clear to me which problem this document tries to solve, and the document feels unfinished. The title of the draft is "Subscription to Distributed Notifications", but there is no definition of a "distributed notification". > > > > > > What is a "Component Subscription"? Is it a NETCONF subscription or something else? > > > > > > Why is the "message-pubslisher-id" an unsigned integer? As a client, I am presented with a set of unsigned integers with no further explanation. What is the client supposed to do with this information? > > > > > > Section 5 says: > > > > > > The Collector can only subscribe to the Master. This requires the > > > Publisher Master to: > > > > > > 1. expose the Global Capability that can be served by multiple > > > Publisher Agents; > > > > > > What does this requirement mean? What is the Global Capability that must be exposed, and how is it exposed? > > > > > > At this point, I am quite confused. > > > > > > To me, the proposed changes seem to be very implementation specific. > > > > > > Section 12 lists some projects that supposedly implement this draft. > > > I downloaded the three open source projects listed in sections 12.1, > > > 12.2 and 12.3 to see if I could understand more about how this draft could be used, but as far as I could tell, these projects do not actually implement this draft. > > > > > > > > > /martin > > > > > > > > > > > >