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-ip-04.txt Reviewer: Stig Venaas Review Date: 2019-12-20 IETF LC End Date: Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: The document is fairly easy to read and of good quality. But I still have some very minor issues that I think need to be resolved. There are also some nits. I'm not that familiar with DetNet, some things might be more clear if familiar with the technology. Major Issues: No major issues found. Minor Issues: In section 3: It is slightly confusing that the text discusses 6-tuples, and then references RFC 3670 regarding 5-tuples. It would be good to mention how the 6-tuples here relate to the 5-tuples in RFC 3670. It says: Note: The sub-network can represent a TSN, MPLS or IP network segment. This document only covers IP, right? Or does it cover IP with these sub-network technologies as well? I don't know if it is is good to list the other options here. Perhaps new ones may be added later in other ocuments? Maybe rephrase it so they are examples rather than a complete list? In section 4.1: In order to maximize reuse of existing mechanisms, DetNet-aware applications and end systems SHOULD NOT mix DetNet and non-DetNet traffic within a single 5-tuple. Should this be 6-tuple? If not, please be specific what the 5-tuple is here. Same as in RFC 3670? I see the 5-tuple is also mentioned at the end of section 4.2. In section 4.2: As a general rule, DetNet IP domains need to be able to forward any DetNet flow identified by the IP 6-tuple. Doing otherwise would limit the number of 6-tuple flow ID combinations that could be used by the end systems. From a practical standpoint this means that all nodes along the end-to-end path of DetNet flows need to agree on what fields are used for flow identification, and the transport protocols (e.g., TCP/UDP/IPsec) which can be used to identify 6-tuple protocol ports. What does protocol ports mean? Is it which transport protocol includes the source and destination port number in the 6-tuple? This should be rephrased I think, since e.g. IPsec SPI may be used. I guess you may be saying that the SPI indirectly identify the ports? Nits: In section 1: layer is used to provides ^^^^^^^ In 2.2. Abbreviations It seems random which ones have a period at the end. I'm sure the RFC Editor can help, but maybe add or remove it everywhere? Section 5.3: Implementations if this document Should be of ^^^^ Some references are outdated according to idnits. Regards, Stig