Early Review of draft-ietf-netconf-distributed-notif-13
review-ietf-netconf-distributed-notif-13-yangdoctors-early-bjorklund-2025-03-30-01

<Thomas.Graf@swisscom.com> 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 <mbj+ietf@4668.se>
> 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 <mbj+ietf@4668.se> > Sent: Wednesday, May
14, 2025 9:29 AM > To: Graf Thomas, INI-NET-VNC-E2E <Thomas.Graf@swisscom.com>
> 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. > > > > <Thomas.Graf@swisscom.com> 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 <mbj+ietf@4668.se> > >
Sent: Monday, April 28, 2025 5:47 PM > > To: Graf Thomas, INI-NET-VNC-E2E
<Thomas.Graf@swisscom.com> > > 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, > > > > > > <Thomas.Graf@swisscom.com>
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 <mbj+ietf@4668.se>;
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
<noreply@ietf.org> > > > 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
> > > > > > > > > > > >