[OPSAWG]Éric Vyncke's Discuss on draft-ietf-opsawg-discardmodel-14: (with DISCUSS and COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-opsawg-discardmodel-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-discardmodel/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


# Éric Vyncke INT AD comments for draft-ietf-opsawg-discardmodel-14
CC @evyncke

Thank you for the work put into this document.

Please find below some blocking DISCUSS points, some non-blocking COMMENT
points/nits (replies would be appreciated even if only for my own education).

Other thanks to Carlos Pignataro, the Internet directorate reviewer (at my
request), please consider this int-dir review (Ready with issues):
https://datatracker.ietf.org/doc/review-ietf-opsawg-discardmodel-14-intdir-telechat-pignataro-2026-07-03/
(and I have yet to read a reply by the authors)

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of
https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by
a tool to create github issues.

## DISCUSS (blocking)

As noted in
https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/,
a DISCUSS ballot is a request to have a discussion on the points below; I
really think that the document would be improved with a change here, but can be
convinced otherwise.

### Section 4.1

```
      leaf checksum-error {
        type yang:counter64;
        description
          "The number of received packets discarded due
           to a checksum error.";
      }
```
is ambiguous as there is no check-sum in the IPv6 header. Be specific and
states that it only applies to IPv4/MPLS.

```
    leaf mtu-exceeded {
        type yang:counter64;
        description
          "The number of received packets discarded due to
           MTU exceeded.";
      }
```
MTU exceeded does not happen when receiving a packet but when transmitting
(i.e., after forwarding) a packet on (an)other interface(s). Same for
"no-route". The problem is even more complex when the forwarded packet is a
multicast one where it can be forwarded on n egress interfaces but cannot for m
egress interfaces.

`leaf invalid-sid` it is unclear whether only routers whose address is the
destination address have to count or other routers in the path (which should
not check) also have to count.

`"The number of packets discarded due to parity errors."` does it mean that the
device CPU experimented a parity error during the receiving/forwarding of the
packet ? Please be specific.

I wonder how to ``"The number of packets discarded due to Distributed
Denial-of-Service (DDoS) protection policies."` as many DDoS are mitigated by
routing to a null-route or layer-3 ACL, which are different counters. Should it
be counted twice ?

### Lack of layer-4 ACL

I am puzzled by the absence in the model and in the text about layer-4 ACL
support as they are often used. There should be at least some text in the
introduction and abstract about this limitation.

### Lack of encapsulation/decapsulation discard

Probably due a misreading of mine, but I see no discard counters when
en/decapsulating a tunneled packet ? And/or how it can be differentiated from a
forwarding operation.

### Lack of addressing the INT-directorate review

As I second most of Carlos Pignataro's int-dir review, I am elevating them to a
DISCUSS level: please address Carlos' issues.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


## COMMENTS (non-blocking)

### Section 4 (and its sub-section)

To be pendantic, I am really surprised (dare I say shocked) by the use of a
data modeling language to specify an information model rather than UML or ER
diagrams. See also RFC 3444.

Even more 'data model' flavour are the specific data types such as `type
yang:counter64;`, which clearly belongs to a data model and not an information
model.

Suggest renaming section 4 as a YANG *data* model (as well as changing the
title & abstract to remove 'information model').

If I was cynical, I would hint that it is more to have more implementations
having 'something' like the information while not implementing exactly the YANG
data model... But, this is only my personal feeling.

### Section 4.1

s/leaf ttl-expired/leaf hop-limit-expired/ after all we are in 2026.

`grouping errors-l2-tx ` would benefit from more leaves (e.g., interface down,
no carrier, exceeded transmission attemps, buffer full, ...).

Should something more specific about IPv6 extension headers be added in
addition of `leaf invalid-packet ` ?

While I am sure that some people will disagree with me (hence a COMMENT and not
a DISCUSS), `leaf invalid-label ` should be in errors-l2-rx as MPLS is more a
layer-2 (e.g., labels are valid only on a link) especially when a label is
flagged as 'invalid'.