Hi Sergio, Thank you for the review. Appreciated.
Your suggestion for Section 2 will be followed in the next revision. Please see: https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/pull/45/files or this rendered diff [1]. Let us know if any further change is needed. Cheers, Med (as author) [1]: https://author-tools.ietf.org/api/iddiff?url_1=https://o-pylypenko.github.io/draft-ietf-opsawg-discardmodel/draft-ietf-opsawg-discardmodel.txt&url_2=https://o-pylypenko.github.io/draft-ietf-opsawg-discardmodel/boucadair-patch-10/draft-ietf-opsawg-discardmodel.txt > -----Message d'origine----- > De : Sergio Belotti via Datatracker <[email protected]> > Envoyé : mardi 21 octobre 2025 19:21 > À : [email protected] > Cc : [email protected]; [email protected] > Objet : draft-ietf-opsawg-discardmodel-09 early Opsdir review > > Document: draft-ietf-opsawg-discardmodel > Title: Information and Data Models for Packet Discard Reporting > Reviewer: Sergio Belotti > Review result: Ready > > The draft is very well written, clear in the scope and the way to > have a solution. The draft is trying to address a base problem for > network operator that is to understand where and why (root cause) > a packet loss occurs in the network. To solve this issue the draft > is defining an information model to classify packet loss (both > intended due to some policy and unintended e.g. due to congestion) > and then a data model to implement the IM framework for network > elementsand reporting the types of discards and where these > discards occur. > General comment: as said the draft is well written but I > appreciated the fact do not go directly with a data model but to > separate the proposal for an IM framework and a specific data > model for network element providing an higher level of abstraction > and independence of specific implementation. (e.g. YANG, gNMI, > SNMPv3 etc.). Section 2 provides terminology section. Comment: I > would rather have a bulleted list for terminology than a simple > format. Section 3 describes the problem statement,reporting what > already provided by present models (RFC2863 and RFC8343)and what > instead added in this draft that is the type of discards. The > section is clear , no issue for me. In Section 5 a YANG data model > is provided. I did not review in details the YANG format (I'm > delegating YangDoctor for that) but it would be good that I could > find in the identities definitons of discard-class all the sub- > types defined in section 4.2, reporting the types of packet > discards in the IM. In conclusion I found the document very > interesting and for sure very useful in an operator prospective as > a way to take the adeguate actions to mitigate the impact of > unintended packet loss. > > ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
