Dear authors,
I reviewed the second part of the draft.
-
This data model implements the Information Model defined in Section 4
for the interface, device, and control-plane components. This is
classified as a Network Element model as defined by [RFC1157].
I was not expecting an old SNMP reference here :-)
You might find better (YANG) references with
RFC 8199 YANG Module Classification
RFC 8309 Service Models Explained
RFC 8969 A Framework for Automating Service and Network Management
with YANG
For example RFC8969 mentions:
The following terms are defined in [RFC8309] and [RFC8199] and are
not redefined here:
...
* Network Element Model
- section 5.3 YANG data model
revision 2025-03-03 {
description
"Initial revision.";
reference
"RFC XXXX: Information and Data Models for Packet Discard
Reporting";
}
OLD: Information and Data Models for Packet Discard Reporting
NEW: Data Models for Packet Discard Reporting
This would be inline with the description:
description
"This module defines a data model for packet discard reporting.
Regarding the ietf-packet-discard-reporting-sx IM, this is also not consistent:
description
"This module defines an information model for packet discard
reporting.
...
revision 2024-06-04 {
description
"Initial revision.";
reference
"RFC XXXX: Information and Data Models for Packet Discard
Reporting";
}
- A small section describing the differences/similarities between the IM YANG
and DM YANG would have helped me, early on in the draft, before delving the IM
and DM YANG modules.
- same structure
- -sx suffix
- import statements
minimum for IM because it doesn't matter
but the DM imports the IM because the structure is the same
- reused grouping from IM to DM
- the features are the same, except "feature flow-reporting" -> treated
in the different draft
- NACM
- etc
-
"This section captures practical insights gained from implementing the
model across multiple vendors' platforms, as guidance for future
implementers and operators:"
If you have implementation reports, feel free to add an "Implementation Status"
section.
See RFC 7942.
- I took me a little bit of time to decipher the goal behind this grouping ...
grouping discard-order-policy {
description
"Defines the implementation-specific precedence of discard
classes when multiple discard reasons apply to a single
packet.
The list is ordered from highest to lowest precedence.";
leaf-list discard-order-capability {
type identityref {
base discard-class;
}
config false;
description
"The discard class identity that has this precedence.";
}
}
... and the fact that it came from this sentence, if not mistaken:
9. When there are multiple reasons for discarding a packet, the
ordering of discard class reporting MUST be defined.
- nits
identity discard-class {
description
"Base identity to identify the discard calss.";
}
OLD: calss
NEW: class
Regards, Benoit
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
