[Detnet] Éric Vyncke's No Objection on draft-ietf-detnet-yang-19: (with COMMENT)

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

Éric Vyncke has entered the following ballot position for
draft-ietf-detnet-yang-19: No Objection

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-detnet-yang/



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


# Éric Vyncke, INT AD, comments for draft-ietf-detnet-yang-19

Thank you for the work put into this document.

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

Special thanks to János Farkas for the shepherd's detailed write-up (using the
old template) including the WG consensus and a simple but present justification
of the intended status.

Please note that Jean-Michel Combes is the Internet directorate reviewer (at my
request) and you may want to consider this int-dir review as well when it will
be available (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-detnet-yang/reviewrequest/18768//

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Section 7

The following points may be purist or even pedantic, but here they are:

### Circular references

'traffic-profile' includes leaves such as 'member-app' and 'app-flow' has a
leaf 'traffic-profile'. This can lead to *inconsistency* if the values are not
compatible. Do YANG/netconf have functions to retrieve which 'app-flow' use
'traffic-profile' ?

Or did I miss something ?

### Leaves names

Why the leaves under 'traffic-profile' are named 'member-app',
'member-fwd-sublayer' rather than 'member-app-flows' and 'member-forwarding' to
match the naming used elsewhere ?

## IPv6 in the YANG module

I am uneasy with the model of an IPv6 flow

### inet:ip-address-no-zone

The use of inet:ip-address-no-zone is fine when purely matching on an IPv6
packet, but this also means that link-local addresses cannot be used probably.
Is it on purpose ?

### protocol-next-header

```
      description
        "Internet Protocol number.  Refers to the protocol of the
         payload.  In IPv6, this field is known as 'next-header',
         and if extension headers are present, the protocol is
         present in the 'upper-layer' header.";
```

This description is rather vague... It should be really specific when using
IPv4. For IPv6 with extension headers, there is no protocol in 'upper-layer'
header.

## Section 13.2

Reference IEEE8021QCX is marked as 'superseded' since 2022 at
https://ieeexplore.ieee.org/document/9212765 apparently by
https://ieeexplore.ieee.org/document/10004498.

## Appendix B

Thank you for using IPv6 examples and very nice SVG diagrams.

Albeit using flows 2001:db8::1/128 <-> 2001:db8::8/128 seems a little
unrealistic as both nodes are probably in the same layer-2 link. But, DTN also
work on a layer-2 link w/o actual layer-3 routing. Same for the IPv4 examples.

You may also want to refresh the dates to 2024 rather than 2020 ;-

Having some examples is really a good thing, I am just slighlty concerned by
the large amount of them in this document. It is a matter of taste, so no need
to reply.