Hi Satoru, Thank you for your feedback.
Please see inline: je# Your feedback is incorporated in the next release: 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: Satoru Matsushima via Datatracker <[email protected]> Date: Wednesday, 12 November 2025 at 06:52 To: [email protected] <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]> Subject: [OPSAWG]draft-ietf-opsawg-discardmodel-09 early Intdir review Document: draft-ietf-opsawg-discardmodel Title: Information and Data Models for Packet Discard Reporting Reviewer: Satoru Matsushima Review result: Ready with Nits Document: draft-ietf-opsawg-discardmodel Title: Information and Data Models for Packet Discard Reporting Reviewer: Satoru Matsushima Review result: Ready with Nits I have reviewed this document as part of the IntArea directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the internet area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Overall this draft was well written and well covered various discard cases, TTL expired, exceed MTU size, uRPF, etc., for example. Nits: - It would be better to clarify which counter type should be used for SR-MPLS cases, either invalid-label, or invalid-sid; je# added clarification to use invalid label for SR-MPLS - RFC8704 might be considered as an informational reference for uRPF; - In addition to uRPF, "ingress filtering" in RFC2827/3704 would cover more wider discard cases at ingress nodes: je# added urpf and ingress filtering references to the description - It would be nice if the draft considered that how many ICMP packets were send, or suppressed to the corresponding discard events, such as TTL expired, exceed MTU size, or rejected by policies. je# I think this is hard to do in practise, because the suppression is normally with a rate-limiter which protects the to-cpu path, i.e. where the reason for punting the packet is not known. We are capturing to-cpu policy discards on aggregate. _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected] 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]
