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

["Eric Vyncke (evyncke)" <[e-mail]>]

Hello Don,

Thanks for your reply and for your patience while waiting for this reply ;-)

See below for EVY> 

Regards

-éric


On 21/02/2024, 20:01, "iesg on behalf of Don Fedyk" <[e-mail] <mailto:[e-mail]> on behalf of [e-mail] <mailto:[e-mail]>> wrote:


Hi Eric


Comments inline [Don]


Thanks
Don


-----Original Message-----
From: detnet <[e-mail] <mailto:[e-mail]>> On Behalf Of Éric Vyncke via Datatracker
Sent: Wednesday, February 14, 2024 2:46 AM
To: The IESG <[e-mail] <mailto:[e-mail]>>
Cc: [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
Subject: [Detnet] Éric Vyncke's No Objection on draft-ietf-detnet-yang-19: (with COMMENT)


É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/ <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/ <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// <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 ?


[Don]
These items are read only leaf-references to the applications, service sub-layer and forwarding sub-layers that reference the traffic profile. (Defined the traffic profile and allowing applications or service-sublayer of forwarding sub-layer to reference them saves having to repeat traffic profiles that are common.) 
A system can populate these back pointers to the applications refencing them if it desires, and the schema can display the reference list. It is not what I would call circular but forward and backward. 


When you are looking at an application, you can see which profile it uses. When you look at a profile you can see which application, service sub-layer or forwarding sublayer is using it is using it. But the configuration is only at the application, service sub-layer or forwarding sublayer to point to the profiles. 

EVY> I would assume that YANG has tools to do these kinds of searches/enumerations without twisting the data model itself ? But, I am not a YANG expert. 

### 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 ?


[Don]
We used lists titled: 
member-app
member-service
member-fwd-sublayer


Elsewhere we use: 
+--rw app-flows
| +--rw app-flow* [name]
+--rw service
| +--rw sub-layer* [name]
+--rw forwarding
+--rw sub-layer* [name]


So, I concur not totally consistent. 
I suggest: 
member-app-flows
member-svc-sublayers
member-fwd-sublayers

EVY> indeed, consistency reduces the number of human mistakes and makes life easier (except for the authors)


Would be more consistent (And I will manage the ripple effect this has on the examples.) 
Eg: 
"member-app-flows": [
"app-1",
"app-2"
]




## 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 ?


[Don]
I was not aware that link local could not be expressed as inet:ip-address-no-zone I thought inet:ip-address-no-zone was simply ip-address without the extra characters of zone. IE purely hexadecimal alpha numeric IPv6 format RFC 6991. On further reading I see that is not correct. 


I think we need the to replace with:
inet:ip-address for Next-hops 


When specifying interfaces. Good catch. -- The routing YANG uses ip-address for next-hops.

EVY> thanks for the changes

We use prefixes for matching packets. 






### 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.


[Don] suggest.
description
"Internet Protocol number. Refers to the protocol of the
Payload for IPv4.";


## Section 13.2


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


[Don] Thanks - will update. 

EVY> good

## 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.
[Don] We ran into using non-ietf document addresses earlier - so the numbers are within IETF doc standard ranges but yes, the examples might somewhat unrealistic. I hesitate to change and make another mistake.

EVY> this is not a mistake per se but a very weird example

You may also want to refresh the dates to 2024 rather than 2020 ;-
[Don] Sure. 

EVY> thanks

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.
[Don] it was WG consensus that a PowerPoint presentation of examples from a meeting would be good to capture in the document. Little did I know a picture is worth some 3000 xml tags. 

EVY> ;-)




_______________________________________________
detnet mailing list
[e-mail] <mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/detnet <https://www.ietf.org/mailman/listinfo/detnet>