Hi Christer, Thanks for your review. Replies/comments inline marked with <BV>. We are working on an updated version of the draft to incorporate your comments as well. Thanks Bala'zs -----Original Message----- From: Christer Holmberg via Datatracker <noreply@xxxxxxxx> Sent: Sunday, March 15, 2020 11:29 AM To: gen-art@xxxxxxxx Cc: last-call@xxxxxxxx; draft-ietf-detnet-data-plane-framework.all@xxxxxxxx; detnet@xxxxxxxx Subject: Genart last call review of draft-ietf-detnet-data-plane-framework-04 Reviewer: Christer Holmberg Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-detnet-data-plane-framework-04 Reviewer: Christer Holmberg Review Date: 2020-03-15 IETF LC End Date: 2020-03-13 IESG Telechat date: Not scheduled for a telechat Summary: The document is well written, and almost ready for publication. I have no issues on the technical parts, but I have found some editorial nits in the Introduction- and Security Considerations sections that I ask the authors to address. Major issues: N/A Minor issues: N/A Nits/editorial comments: Q1: The first line of the Introduction says: “DetNet (Deterministic Networking) provides a capability…” Please add a reference to DetNet/RFC8655 on first occurance. <BV> OK, the second sentence refers to RFC8655. First sentence provides a general description. Q2: The first line of the 2nd paragraph of the Introduction says: “This document describes the concepts needed by any DetNet data plane specification…” What is meant by DetNet data plane specification? The definition of DetNet flows over a specific network technology? Please clarify, or reference if already defined elsewhere. <BV> Data plane documents focuses how DetNet packets are recognized and served according to DetNet service and forwarding sub-layer functions. The next sentence is intended to clarify that. Q3: The 5th paragraph of the Introduction (“DetNet flows may be carried over network…”) contains text about network topologies that can be used for DetNet flows. Is the text (all, or part of it) in the paragraph somehow specific to this document, or is it simply repeating things that are defined in RFC 8655? If the paragraph is only repeating stuff, maybe start with “As defined in RFC8655, DetNet flows may be carried…”. <BV> YES, framework document is inline with RFC8655 and here we are referring to it. I will modify the sentence according to your suggestion. Q4: The 6th paragraph of the Introduction says: “Different application flows (e.g., Ethernet, IP, etc.)…” The text may it look like the Ethernet, IP etc is the actual application flow. I assume you mean application flow carried over Ethernet, IP, etc? If so, please modify to make it more clear. <BV> It is intentionally formulated so. From DetNet edge nodes perspective the received Ethernet frames or IP packets are treated as an app-flow. The end-host application data carried over Ethernet, IP are not "touched" by DetNet. Q5: The Security considerations say: “Security considerations for DetNet are described in detail in [I-D.ietf-detnet-security]. General security considerations are described in [RFC8655].” The sentence is confusing. General security considerations for what? Doesn’t RFC 8655 also describe security considerations for DetNet? <BV> OK. General security considerations for DetNet were meant here. I will update text to be more specific. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
