Re: [Detnet] RtgDir Review: draft-ietf-detnet-yang-16

[Don Fedyk <[e-mail]>]

Hi Julien

Thanks for you review. I will go through you points and address them shortly for the next update.  I will align with the other authors. I will send a separate response addressing the points once I have a resolution.

Thanks
Don

-----Original Message-----
From: [e-mail] <[e-mail]>
Sent: Tuesday, September 13, 2022 10:03 AM
To: <[e-mail]> <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: RtgDir Review: draft-ietf-detnet-yang-16

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide
assistance to the Routing ADs. For more information about the Routing
Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF
Last Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-detnet-yang
Reviewer: Julien Meuric
Review Date: 2022-09-13
Intended Status: Standards Track


_Summary_

I have some minor concerns about this document that I think should be
resolved before publication.


_Comments_

The YANG module itself seems almost ready but the text that introduces
it needs a few clarification or rewording.


_Minor Issues_

- First of all, IdNits points out 3 normative references on
informational RFCs 8938, 9016 and 9055. Are you sure the 3 of them are
mandatory to implement the YANG module?

- In the abstract, I don't really understand the point of the sentence
"An operator or network controller programs the configuration of the
devices" since service provisioning on devices along the path is
previously mentioned. If the intent was to say: "The configuration of
the devices can be programmed by an operator or a network controller.",
that feels like stating the obvious for a device-embeded YANG module.

- In section 4, the wording of "ingress" and "egress" definitions feel
odd. Is it meant to say "Ingress refers to entering the DetNet
application layer and egress to leaving the application layer."?

- The described aggregation cases are scoped either as layer N to layer
N or as layer N to layer N-1. However, there's a relay node case where
aggregation is described as layer N (forwarding) to layer N+1 (service).
Since there's no forwarding to forwarding relay case, I suspect a
mismatch... [Later note: in the model itself, one can find
"forwarding-to-forwarding aggregation at the ingress node or relay node
or transit node", so it looks like an issue in the text part.]

- In section 8, the max-loss leaf is an uint32 but is defined as a
"ratio". Considering the value in the examples (2), it seems that the
description text (and units?) should be adjusted.


_Nits_

------
Abstract
---
s/operational data for DetNet Flows/operational data of DetNet Flows/
[already 2 "for"s in the phrase]

------
Section 4.
---
     OLD
Node types typically are logical per DetNet service and one DetNet
service can be one node type while another is another node type on same
device.
     NEW
Node types are logical roles per DetNet service: a device along one
DetNet service can be of one node type, while another service may use
the same device with a different node type.

s/edge node(egress/edge node (egress/
s/These may used/These may be used/
s/the configuration need to/the configuration needs to/
s/IP based path/IP-based path/
s/parameters for aggregated flow/parameters for aggregated flow/

------
Section 10.
---
     OLD
o this also coudl be considered moer sensitive. The trafic profiles liked to
     NEW
so this also could be considered more sensitive. The traffic profiles
linked to

------

Regards,

Julien