Thanks to Carlos P. for the INTDIR review.  Thanks to Derrell P. for the SECDIR review.

Thanks for the edit to fix my discuss.


Thanks to the authors for a nice draft.

Authors, please look at Derrell's SECDIR review if you haven't already.

This is a nit, but why only DDoS and not just DoS traffic, (which would include DDoS)?

Thanks for referencing the IPFIX models and methods but they seem to be a rather weird comparison to the YANG approach.  It would not be strange to have an IPFIX exporter on each line card capturing the details of all the interfaces on that line card.  It would export as a unique observation domain to a mediator in the chassis providing a single external export.  That would create potentially more work on the collector process to make sense of drops compared to the YANG model approach.  I'm not sure that the abstract information models easily translate back and forth between YANG and IPFIX - even though you would hope they would.  They might, if you focused the information model less on a hardware centric construct and more on the protocol centric view point.  Then provided linkage of the protocol actions (L2 drops, L3 drops, etc.) with a pointer back to the hardware realizations of those action points.  Then the information model would be grounded in the core pieces of information that this model is trying to capture.  A more agnostic view point of the information model vis a vis YANG or IPFIX.

Lastly, I'm not really sure how to think about the `flow` entry in the information model.  It's orthogonal to the device and interface grouping logically.  And it might be that packets get dropped / changed based on flow based rules, but that is accounted for very differently in this draft.  I'm struggling to understand the intention, but it doesn't hamper implementing the model defined in the draft.

Thanks to Derrell Piper for their secdir review.

Section 8.2, para 2:  Please consider asking the RFC Editor to swap out RFC 8446 with RFC 9846 when it is published (near the end of Auth48)

Thanks for the work done and for addressing my previous [blocking DISCUSS](https://mailarchive.ietf.org/arch/msg/opsawg/tI3uke7iTUdIithvGD5ofYCL7lY/) concerns.

Regards

-éric

I really do like the intended scope of separately identifying the reasons for discard to enable automated network mitigation of unintended packet loss and appreciate the work that has gone into this model. I would love to see this supported in deployment.

Thanks to the authors and the WG for their work on this document.

Also thanks for the discussion and updates to the documents to address the concerns raised in my original ballot.

# IESG review of draft-ietf-opsawg-discardmodel-14

CC @MikeBishop

## Nits

### Terminology

#### Section 2, paragraph 4
```
-    Packet discard:  It accounts for any instance where a packet is
-                     ^^^^^^^^^^^^^^^^^
+    Packet discard:  Any instance where a packet is
+                     ^
```

#### Section 2, paragraph 5
```
-    Intended packet discards (Intended discards, for short):  Are packets
-                                                              ^^^^^
+    Intended packet discards (Intended discards, for short):  Packets
+                                                              ^
```

#### Section 2, paragraph 6
```
-    Unintended packet discards (Unintended discards, for short):  Are
-                                                                -----
-       packets that were dropped, which the network operator otherwise
-       ^
+       Packets that were dropped, which the network operator otherwise
+       ^
```

Thank you to Roni Even for the GENART review.