Hi Benoit, Thanks for your feedback.
Please see replies inline: je# Your feedback is incorporated in the next revision: https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-opsawg-discardmodel&url_2=https://o-pylypenko.github.io/draft-ietf-opsawg-discardmodel/draft-ietf-opsawg-discardmodel.txt cheers John From: [email protected] <[email protected]> Date: Friday, 31 October 2025 at 12:13 To: [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Review of draft-ietf-opsawg-discardmodel-09 - part 2 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 je# changed accordingly 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 je# changed accordingly 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 je# added to section 5 - "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. je# added section 7 - 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. je# added an explicit reference to the discard-order-capability in the requirement - nits identity discard-class { description "Base identity to identify the discard calss."; } OLD: calss NEW: class je# fixed Regards, Benoit Amazon Data Services UK Limited. Registered in England and Wales with registration number 09959151 with its registered office at 1 Principal Place, Worship Street, London, EC2A 2FA, United Kingdom.
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
