Dear Thomas and Ahmed, Just a comment on point 2. As I commented during the OPSAWG meeting, in the last iteration of ietf-platform-manifest.yang, these fields have been implemented as a reusable grouping “platform-details” in draft-ietf-opsawg-collected-data-manifest. I suggest to use the grouping instead of copy/pasting all the fields, and then referencing data-manifest draft. This should remove the ‘overlap’ issue.
Regarding strings vs more structured way to approach these fields, I think that as these identifiers are implemented differently on each vendor, the string provides the most flexible approach. A third comment is, as this draft also offer augmentations of the model for YANG-Push, I wonder myself whether the notif-envelope extensions may be of interest to add into this draft. I think yes, but I am also aware that some may be already present in the current model (hostname). It really depends at which level the 'payload' is decomposed. Do you have an idea of how a YANG-Push message would look like in the payload? Cheers, Alex > On 17 Mar 2025, at 08:55, thomas.g...@swisscom.com wrote: > > Dear Rob, > > Thanks a lot for the review. > > Do you want to add any text to explain that the fields are optional, > providing choice at to which fields are populated? > Valid point, We will take it as action item for the next iteration. > > Quite a few of these are unstructured strings. It would be nice if these > fields could have more structure, but I appreciate that may be tricky, and > using strings is a simple choice. > This is derived from draft-ietf-opsawg-collected-data-manifest. Maybe the > authors of draft-ietf-opsawg-collected-data-manifest could comment on that. > > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-collected-data-manifest-06#section-5.1 > > module: ietf-platform-manifest > +--ro platforms > +--ro platform* [id] > +--ro id string > +--ro name? string > +--ro vendor? string > +--ro vendor-pen? uint32 > +--ro software-version? string > +--ro software-flavor? string > +--ro os-version? string > +--ro os-type? string > > Here, I think that you are not picking up the right stream filter, this is > the generic subscribed notifications stream filter rather than the yang-push > specific one that you probably want. > I need to look into that. Ideally we want to populate the same information > then > > ietf-subscribed-notificati...@2019-09-09.yang > <mailto:ietf-subscribed-notificati...@2019-09-09.yang> > --- > notification subscription-started { > sn:subscription-state-notification; > if-feature "configured"; > description > "This notification indicates that a subscription has started > and notifications will now be sent."; > leaf id { > type subscription-id; > mandatory true; > description > "This references the affected subscription."; > } > uses subscription-policy { > refine "target/stream/replay-start-time" { > description > "Indicates the time that a replay is using for the > streaming of buffered event records. This will be > populated with the most recent of the following: > the event time of the previous event record sent to a > receiver, the 'replay-log-creation-time', the > 'replay-log-aged-time', or the most recent publisher > boot time."; > } > refine "target/stream/stream-filter/within-subscription" { > description > "Filter applied to the subscription. If the > 'stream-filter-name' is populated, the filter in the > subscription came from the 'filters' container. > Otherwise, it is populated in-line as part of the > subscription."; > } > augment "target/stream" { > description > "This augmentation adds additional parameters specific to a > 'subscription-started' notification."; > leaf replay-previous-event-time { > when '../replay-start-time'; > if-feature "replay"; > type yang:date-and-time; > description > "If there is at least one event in the replay buffer > prior to 'replay-start-time', this gives the time of > the event generated immediately prior to the > 'replay-start-time'. > > If a receiver previously received event records for > this configured subscription, it can compare this time > to the last event record previously received. If the > two are not the same (perhaps due to a reboot), then a > dynamic replay can be initiated to acquire any missing > event records."; > } > } > } > } > > Do you want to add content-id here at all? > Well spotted. We do want and missed the latest change in > ietf-yang-push-revision. We will take it as action item for the next > iteration. > > I think that you probably need more text/clarity on exact which port numbers > you are referring to. E.g., it is the telemetry session, or the > configuration port, source/dest, etc. > Valid point, We will take it as action item for the next iteration. > > Best wishes > Thomas > > From: Rob Wilton (rwilton) <rwil...@cisco.com <mailto:rwil...@cisco.com>> > Sent: Monday, March 17, 2025 5:41 AM > To: Elhassany Ahmed, INI-NET-VNC-E2E <ahmed.elhass...@swisscom.com > <mailto:ahmed.elhass...@swisscom.com>>; Graf Thomas, INI-NET-VNC-E2E > <thomas.g...@swisscom.com <mailto:thomas.g...@swisscom.com>> > Cc: n...@ietf.org <mailto:n...@ietf.org> > Subject: Comments on draft-netana-nmop-message-broker-telemetry-message-00 > > Be aware: This is an external email. > > Hi Ahmed, Thomas, > > Before today’s NMOP session, I was having a quick read of this draft, and I > had a few comments. > > > (1) p 3, sec 2. YANG Module > > Network Operator Provenance: Is the operator specific metadata. > Some operators enrich the collected data with specific > information. For instance: type of the network node (MPLS > provider or provider edge node) or which operational unit the node > is operated by. For this purpose the document defines a generic > metadata map with key/values that can be used freely by the > network operator. > > Do you want to add any text to explain that the fields are optional, > providing choice at to which fields are populated? > > > (2) p 4, sec 2. YANG Module > > | +--ro software-version? string > | +--ro software-flavor? string > | +--ro os-version? string > | +--ro os-type? string > > Quite a few of these are unstructured strings. It would be nice if these > fields could have more structure, but I appreciate that may be tricky, and > using strings is a simple choice. > > > (3) p 5, sec 2. YANG Module > > +--ro filters > | +--ro stream-filter* [name] > | +--ro name string > | +---u sn:stream-filter-elements > > Here, I think that you are not picking up the right stream filter, this is > the generic subscribed notifications stream filter rather than the yang-push > specific one that you probably want. > > > (4) p 5, sec 2. YANG Module > > +---u ypr:yang-push-module-version-list > > Do you want to add content-id here at all? > > > (5) p 7, sec 2. YANG Module > > leaf port { > type inet:port-number; > mandatory true; > description > "Node port number"; > } > > I think that you probably need more text/clarity on exact which port numbers > you are referring to. E.g., it is the telemetry session, or the > configuration port, source/dest, etc. > > Kind regards, > Rob > -- > Nmop mailing list -- n...@ietf.org > To unsubscribe send an email to nmop-le...@ietf.org
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
