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

[John Evans <[e-mail]>]

Hi Éric,

> I am afraid that my DISCUSS #2 still hold as the even if the mtu-exceeded
has moved out of the rx container it is still in the errors-l3-rx whose
description is `Layer 3 ingress packet error discard counters.`.

On DISCUSS #2: the rx class has a specific operational meaning: discards
due to errors in the received packet itself, which localizes the fault
upstream and narrows the mitigation to the upstream device or link.
mtu-exceeded was moved out of rx because an MTU-exceeded packet is not an
errored packet; it is a valid packet exceeding a constraint determined at
this device, so the upstream-fault mapping does not apply. Structurally it
is reportable on both directions, since the errors tree instantiates under
the direction-keyed discards list (e.g.,
discards[direction="egress"]/errors/l3/mtu-exceeded). You are right,
though, that mtu-exceeded was still defined inside a grouping named
errors-l3-rx, which misrepresented its contents. We have renamed the
grouping to errors-l3 and updated its description to distinguish
received-packet errors (the rx container) from discards arising during
forwarding at this device, reported per direction:
https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/pull/148/changes

> Same for DISCUSS #3 it is still unclear whether only the router that
needs to process the next SID count this packet error or all SR-aware
routers on the path.

On DISCUSS #3: this is a discard counter, not an error-detection counter: a
packet is discarded at exactly one node, so it is counted exactly once, by
the discarding node. Under SRv6 [RFC8754] that is the node processing the
SID (where the packet's destination address matches a locally instantiated
SID); transit nodes forward on the destination address without inspecting
the SID list, so they neither detect nor discard. Agreed this should be
stated rather than implied; the leaf description now says so explicitly in
the next revision:
https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/pull/146/changes

> I am not convinced by the explanation of DISCUSS#5 as some text would
have been welcome IMHO.

On DISCUSS #5: agreed, the explanation belonged in the document. The dos
leaf description now states this explicitly in the next revision: the
counter covers dedicated DoS-protection mechanisms (e.g., vendor heuristics
that identify and discard DoS traffic), while attacks mitigated via an ACL
or null route are reported under acl or null-route respectively, consistent
with the no-double-counting requirement. A discard increments exactly one
policy subtype, and the association of an ACL or null route with DoS
mitigation is known only to the operator:
https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/pull/147/changes

Please let us know if anything is still open.

Thanks,
John


On Thu, 23 Jul 2026 at 15:35, Eric Vyncke (evyncke) <[e-mail]>
wrote:

> Thank you John for your reply with explanations and the revised I-D.
>
> I am afraid that my DISCUSS #2 still hold as the even if the mtu-exceeded
> has moved out of the rx container it is still in the errors-l3-rx whose
> description is `Layer 3 ingress packet error discard counters.`.
>
> Same for DISCUSS #3 it is still unclear whether only the router that needs
> to process the next SID count this packet error or all SR-aware routers on
> the path.
>
> I am not convinced by the explanation of DISCUSS#5 as some text would have
> been welcome IMHO.
>
> Thank you also for acting on Carlos' int-dir review.
>
> Regards,
>
> -éric
>
> *From: *John Evans <[e-mail]>
> *Date: *Thursday, 23 July 2026 at 14:01
> *To: *Eric Vyncke (evyncke) <[e-mail]>
> *Cc: *The IESG <[e-mail]>; [e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>;
> [e-mail] <
> [e-mail]>; [e-mail] <
> [e-mail]>; [e-mail] <[e-mail]>
> *Subject: *Re: Éric Vyncke's Discuss on
> draft-ietf-opsawg-discardmodel-14: (with DISCUSS and COMMENT)
>
> Hi Éric,
>
> Thanks again for your review. We've published -15, which incorporates the
> changes discussed. Summary against each point:
>
> DISCUSS:
>
> 1. checksum-error IPv4/IPv6 ambiguity: Fixed. The leaf description now
> states the counter is applicable only to IPv4; IPv6 has no internet-layer
> header checksum.
>
> 2. mtu-exceeded placement and semantics: Fixed. mtu-exceeded has moved out
> of the rx container and is now a separate container with
> fragmentation-not-permitted and fragmentation-permitted-not-performed
> counters, distinguishing whether the forwarding node was permitted to
> fragment (with references to RFC 791 and RFC 8200). As discussed, no-route
> remains on ingress since without a route there is no egress interface to
> attribute to.  On the multicast case: per requirement 2, discards are
> attributed to the interface where they occur, so replications discarded on
> m egress interfaces account on each of those interfaces.
>
> 3. invalid-sid scope: As discussed, only SR-aware routers processing the
> SID increment this counter; the references to RFC 8402/8660/8754/8986 have
> been added to the leaf.
>
> 4. parity-error specificity: Fixed. The description now states this means
> the ASIC detected corruption in an internal memory, table, buffer, or
> metadata structure while processing the packet, and dropped it rather than
> forwarding using potentially bad state; a device-internal error, not a
> property of the packet.
>
> 5. DDoS double counting: As discussed, the model has a no-double-counting
> principle (requirement 8): a discard increments exactly one subclass, so
> ACL- or null-route-mitigated attacks report under those counters, and the
> dos counter covers vendor heuristic-based DoS protection. The leaf now
> reads DoS rather than DDoS, per Christopher's related comment.
>
> 6. Layer-4 ACL: The acl leaf description now covers Layer 3 and
> higher-layer ACLs, so these are in scope of the model rather than a
> limitation.
>
> 7. Encapsulation/decapsulation discards: As discussed, tunnel processing
> falls under forwarding; missing tunnel forwarding state is semantically
> no-route from an operator's perspective, and requirement 13 states
> attribution relates to the outer header at the point of discard.
>
> 8. INT-directorate review: Carlos's points are now addressed; the summary
> is in the thread with Carlos [
> https://mailarchive.ietf.org/arch/msg/opsawg/YMALJRc6CraKCVdVd3Mx7IGc-rI/]
> with the GTSM/RFC 5082/RFC 6192 clarification in the next revision.
>
> COMMENTs:
>
> 9. IM in YANG rather than UML/ER: The working group conclusion is now
> stated in the new Design Rationale section (Section 4): YANG with RFC 8791
> structure extensions keeps the model abstract per RFC 3444 while supporting
> different DM realizations (YANG, IPFIX) and lossless translation to the
> YANG DM. This is also consistent with draft-ietf-opsawg-rfc5706bis, which
> explicitly allows YANG structure extensions for information models.
>
> 10. On the "cynical" point: that is in fact the intent: the IM exists so
> the same classification can be realized in IPFIX and flow-level discards
> correlated with device- and interface-level discards. The Introduction now
> says this explicitly, and draft-evans-opsawg-ipfix-discard-class-ie shows
> the IPFIX realization.
>
> 11. ttl-expired naming: Kept, as the class covers IPv4 TTL, IPv6 Hop
> Limit, and MPLS TTL expiry; the description now states all three explicitly.
>
> 12. Additional errors-l2-tx leaves and IPv6 extension headers: Not added,
> consistent with the granularity rationale now in Section 4: subtypes are
> included where deployment experience shows they map to distinct mitigation
> actions, and new subtypes can be added by future augmentation without
> affecting existing implementations.
>
> 13. invalid-label under l2: Kept under l3. An invalid label is a lookup
> failure, and the same operational action applies as for an L3 lookup
> failure, so it belongs in the same class; errors/l2/rx isolates problems to
> the L2 domain (upstream device or link). Reporting label lookup failures
> under l2 would trigger the wrong mitigation.
> Diff:
> https://author-tools.ietf.org/iddiff?url1=draft-ietf-opsawg-discardmodel-14&url2=draft-ietf-opsawg-discardmodel-15
>
> Please let us know if there's anything we missed.
>
> Thanks,
> John
>
> On Thu, 9 Jul 2026 at 12:40, John Evans <[e-mail]> wrote:
>
> Hi Eric,
>
> Thank you for your feedback.
>
> I have replied to Carlos's comments - copied below.
>
> On your other comments:
>
> > ### Section 4.1
> > is ambiguous as there is no check-sum in the IPv6 header.
>
> Now clarified:
>
> https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/blob/0e94aa53e555c438828a92cdc7fbe7cd999f3385/yang/ietf-packet-discard-reporting-common.yang#L375
>
> > MTU exceeded does not happen when receiving a packet but when
> transmitting
> > (i.e., after forwarding) a packet on (an)other interface(s).
>
> The egress interface is the constraint, however, the practical
> implementation that we see across vendors is that the discards occur on
> ingress, once the egress interface has been determined.  Operationally, the
> mitigation can be ambiguous (is the MTU too small or the packet too
> big). We have changed the model to move mtu-exceeds from under /rx:
> https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/pull/91/changes
>
> > Same for "no-route".
>
> No route discards have to be on ingress as there is no route to be able to
> determine the egress interface.
>
> > `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.
>
> Only SR-aware routers will increment this when encountered.
>
> > "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.
>
> A parity error means that the ASIC detected corruption in an internal
> memory, table, buffer, or metadata structure used while processing the
> packet, and dropped the packet rather than forwarding it using potentially
> bad state.
>
> It does not mean the packet had an L2 CRC error, bad IP checksum, invalid
> header, or protocol error. It is not a property of the packet on the wire.
> It is a device-internal forwarding error.
>
> We updated the description to clarify:
> https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/pull/122/changes
>
> > 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 ?
>
> We have a design principle of not double counting discards.  In this
> example, we would report it as ACL or null route discards as only the
> network operator knows the intent of that ACL or null route and can make
> the association.  A number of vendors have implemented heuristics to
> identify and discard DDoS traffic, which is what this class is intended for.
>
> > ### Lack of layer-4 ACL
> > I am puzzled by the absence in the model and in the text about layer-4
> ACL
>
> We have updated the description accordingly:
> https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/pull/114/changes
>
> > ### Lack of encapsulation/decapsulation discard
> > Probably due a misreading of mine, but I see no discard counters when
> > en/decapsulating a tunneled packet ?
>
> This was a point of discussion and we decided not to define dedicated
> encap/decap discard classes: tunnel processing falls under forwarding, so
> when the required forwarding state is missing, semantically it is the same
> as no-route from an operator's perspective. Section 5.3 requirement 13 also
> says that tunnel endpoint attribution relates to the outer header.
>
> > ### 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.
>
> I have replied to Carlos's comments - copied below.
>
> > 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.
>
> This was a point of much discussion in the working group, the conclusion
> of which is noted in Section 4:
>
>    The IM is defined using YANG [RFC7950], with Data Structure
>    Extensions [RFC8791], allowing the model to remain abstract and
>    decoupled from specific implementations in accordance with [RFC3444].
>    This abstraction supports different DM implementations, such as YANG
>    or IPFIX [RFC7011], while ensuring consistency across
>    implementations.
>
> Please note that draft-ietf-opsawg-rfc5706bis also says:
>
>     While an Information Model is typically described in English text (or
>     sometimes UML) to define the conceptual management requirements,
>     authors may choose to express it using YANG Data Structure Extensions
>     [.RFC8791] as described in Section 5.3.1. Using YANG for the
>     Information Model can make it easier to link abstract concepts to
>     concrete data types in the corresponding Data Model, helping maintain
>     consistency between high-level design and practical deployment.
>
> > 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.
>
> That is exactly the point, i.e. so that we can represent the same
> information model in ipfix and correlate discards at the device or
> interface level with the impacted flows.  Please also see:
> https://datatracker.ietf.org/doc/html/draft-evans-opsawg-ipfix-discard-class-ie-02
> .
>
> > 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'.
>
> Our approach has been to define the classification scheme working
> backwards from the operations actions that we need to take, so there is a
> clean mapping from class to action.  errors-l2-rx essentially isolates
> the problem to the L2 domain; adding invalid-label to the class would break
> that isolation.
>
> > s/leaf ttl-expired/leaf hop-limit-expired/ after all we are in 2026.
>
> Because the class is intended to cover IPv4 TTL expiry, IPv6 Hop Limit
> expiry, and MPLS TTL expiry I propose keeping ttl-expired as the
> established operational counter name and have updated the description to
> say explicitly that it reports packets discarded because the packet
> lifetime expired during forwarding, including IPv4 TTL, IPv6 Hop Limit, and
> MPLS TTL expiry:
> https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/pull/123/changes
>
> > `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 ` ?
>
> As per the reply to Carlos:
>
> We took the current level of discard taxonomy granularity as a design
> decision.  The intent was to provide enough classification to support
> common operational mitigation decisions. This is discussed in Section 6.4.1:
>
>    1.  The number and granularity of discard classes defined in the IM
>        represent a compromise.  It aims to provide sufficient detail to
>        enable appropriate automated actions while avoiding excessive
>        detail, which may hinder quick problem identification.
>        Additionally, it helps to limit the quantity of data produced per
>        interface, constraining the data volume and device CPU impacts.
>        While further granularity is possible, the defined schema has
>        generally proven to be sufficient for the task of mitigating
>        unintended packet loss.
>
> cheers
>
> John
> ---
>
> Reply to Carlos:
>
> Hi Carlos,
>
> Thank you for your feedback.
>
> 1. No ICMP generation/suppression signal tied to discard events.
>    ...
>    Recommend either modeling
>    ICMP-sent/suppressed state explicitly, or stating the omission is a
>    deliberate scope decision with rationale.
>
> It was a design decision to report the key discards and not the protocol
> interactions associated with discards.
> We have updated the draft to clarify:
> https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/pull/78/changes
>
> 2. Address-family model does not cleanly represent MPLS/SRv6 traffic,
>    only its discards.
>
> We treated this as a deliberate modelling trade-off rather than an
> omission. There are many possible ways to define the tree, including a
> protocol-rooted or address-family-rooted hierarchy where MPLS, SR-MPLS,
> IPv4, IPv6, and SRv6 each have their own traffic and discard subtrees. The
> current model instead keeps forwarding family and causal discard class
> largely orthogonal.  This is discussed in 6.2.2
>
>    2.  There are many possible ways to define the discard classification
>        tree.  For example, an approach is to use a multi-rooted tree,
>        rooted in each protocol.  Instead, a better approach is to define
>        a tree where protocol discards and causal discard classes are
>        accounted for orthogonally.  This decision reduces the number of
>        combinations of classes and has proven sufficient for determining
>        mitigation actions.
>
>
> That said, if operators find that the current all identity loses useful
> information for mitigation or RCA, a future augmentation could add more
> specific address-family identities such as mpls, sr-mpls, and srv6, while
> preserving the current causal discard taxonomy.
>
> 3. `mtu-exceeded` does not distinguish DF-driven discard (IPv4 DF=1,
>    IPv6 always) from fragmentable IPv4 (DF=0).
>
> We have added this - please see:
>
> https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/pull/91/changes
>
> 4. The discard taxonomy (Section 4.2) is not fully 1:1 with the YANG
>    identities. Internet-area instances of this gap:
>
> We took the current level of discard taxonomy granularity as a design
> decision.  The intent was to provide enough classification to support
> common operational mitigation decisions, while avoiding a protocol-specific
> tree. This is discussed in Section 6.4.1: the model deliberately treats
> protocol context and discard cause as largely orthogonal, rather than
> defining a separate leaf for every protocol-specific discard mechanism.
>
>    1.  The number and granularity of discard classes defined in the IM
>        represent a compromise.  It aims to provide sufficient detail to
>        enable appropriate automated actions while avoiding excessive
>        detail, which may hinder quick problem identification.
>        Additionally, it helps to limit the quantity of data produced per
>        interface, constraining the data volume and device CPU impacts.
>        While further granularity is possible, the defined schema has
>        generally proven to be sufficient for the task of mitigating
>        unintended packet loss.
>
>
> Nonetheless, we agree that the examples you list are useful candidates for
> further discussion and for possible future augmentation of the module.
>
> 5. `checksum-error` (errors-l3-rx) does not note that IPv4 has a header
>    checksum and IPv6 does not (RFC 791 vs. RFC 8200) -- applicability by
>    address family could be stated.
>
> Added:
>
> https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/blob/0e94aa53e555c438828a92cdc7fbe7cd999f3385/yang/ietf-packet-discard-reporting-common.yang#L375
>
> 6. `invalid-sid` lacks an informative reference to SRv6 architecture
>    (RFC 8402 / RFC 8986).
>
> Added:
> https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/blob/0e94aa53e555c438828a92cdc7fbe7cd999f3385/yang/ietf-packet-discard-reporting-common.yang#L470
>
> 7. No neighbor-resolution-failure (ARP/ND unresolved) discard subtype;
>    doesn't map cleanly to `no-route` or `internal`.
>
> Added:
> https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/pull/85/changes
>
> 8. Foundational IP references (RFC 791, RFC 8200) are absent despite
>    heavy dependence on IP-layer semantics (TTL, header validity, MTU).
>    RFC 4884, RFC 5082, RFC 6192, RFC 5085, and RFC 8029 should also be
>    added as informative references if the comments are useful.
>
> That's OK per the IESG statement on the matter:
> https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-normative-and-informative-references-20060419/.
> Especially, this part
>
> "It is not considered necessary to cite basic specifications that may be
> safely assumed to be known to practitioners (for example, RFC 791 need not
> be cited in every specification that mentions IPv4)."
>
> 9. Section 1 scope reads "limited to reporting packet loss at Layer 3
>    and frames discarded at Layer 2" but MPLS/SRv6 discard reasons are
>    present throughout; please tighten the scope statement.
>
> Tightened:
>
> https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/pull/78/changes
>
>
> 10. `invalid-vlan`/`invalid-mac` are Ethernet-specific; note
>     applicability for non-Ethernet L2 technologies.
>
> Noted:
>
> https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/blob/0e94aa53e555c438828a92cdc7fbe7cd999f3385/yang/ietf-packet-discard-reporting-common.yang#L330
>
> https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel/blob/0e94aa53e555c438828a92cdc7fbe7cd999f3385/yang/ietf-packet-discard-reporting-common.yang#L338
>
>
>
>
> On Tue, 7 Jul 2026 at 13:30, Éric Vyncke via Datatracker <[e-mail]>
> wrote:
>
> É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'.
>
>
>
>