Hello, I have been selected to do a routing directorate “early” review of this draft. https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-attachment-circuit/ The routing directorate will, on request from the working group chair, perform an “early” review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft’s lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached. As this document has recently been adopted by the working group fairly recently (November 2023), my focus for the review is on catching any issues early on in the document's life cycle. For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir Document: draft-ietf-opsawg-teas-attachment-circuit-07.txt Reviewer: Donald Eastlake Review Date: 8 March 2024 Intended Status: Standards Track Summary: -------- I have some minor concerns about this document that I think should be resolved before it is submitted to the IESG. This document specifies a YANG service data model for Attachment Circuits and a set of reusable groupings. I am not that deep a YANG expert but it seems to be headed in the right direction. Comments: --------- I found the writing in this draft to be reasonably good in quality and readability. It seems curious that the first sentence of Section 1.1 does not mention PEs. Also, Service Functions (and Service Function Forwarders?) seem to usually be listed first in such lists giving them great importance. In Section 3.2, I don't think "advanced network services", which sounds like a marketing term, is well defined. If you mean network slicing, just say that. The list of references to section 4.2.5.3.x at the start of the 2nd paragraph of Section 4.2.5.3 is missing VRRP (Section 4.2.5.6). Except that actually a number of the sections seem like they should be one level deeper: 4.2.5.4 -> 4.2.5.3.4, 4.2.5.5 -> 4.2.3.5, and 4.2.5.6 -> 4.2.5.3.6. This would change the numbering of a few following sections such as 4.2.5.7 -> 4.2.5.4. Figure 11 seems to be missing ospf. In Section 6 there are two sentences that begin "These data nodes are defined with ". It is not clear to me if "These" refers to the nodes listed before or those listed after the sentence. Nits: ----- "merit to decorrelate the" -> "merit of decorrelating the" "An example to retrieve a" -> "An example of retrieving a" "SAPs" is not spelled out where first used but rather in the following paragraph. "the ACs that the ordered" -> "the ACs that they ordered" "If these provisioning of these services require specific" -> "If the provisioning of these services requires" Section 1.2 heading: "Position" -> "Positioning" Section 1.2.1 and 1.2.2 headings: "Using" -> "Use" "L2SM" and "L3SM" are not expanded. Section 3.1, Since "VRRP" is used and expanded, a reference to draft-ietf-rtgwg-vrrp-rfc5798bis-18 would be appropriate. (That draft is in the RFC Editor queue in the final stage of editing so should not become a blocking reference.) In Figures 1, 35, 36, and 40, vertical lines are usually represented by the ASCII VERTICAL LINE character, 0x7C, which is what is normally used in ASCII art, but in some cases the Unicode character BOX DRAWINGS LIGHT VERTICAL, 0x2502, is used. This causes garbles in the htmlized version of the draft. I recommend a global replacement of character 0x2502 with character 0x7C and, in any case, they should be consistent. In the first line after the Figure 3 caption, there is an "NF", which I would guess stands for Network Function, that is not expanded or explained anywhere. Since LLDP is used and expanded, there should probably be a reference to IEEE Std 802.1AB. In Section 4.1, there are several references to "PE" and "PoP" but I don't think these are expanded anywhere. "If these status values differ, a trigger to detect an anomaly." -> "These status values differing should trigger the detection of an anomaly condition." "The profiles definition are" -> "The profile definitions are" "abovementioned" -> "above mentioned" "request avoiding to connnecting" -> "request avoidance of connecting" Section 4.2.5.1 "encapsulation type defined" -> "encapsulation types defined" Suggest changing the heading of 4.2.5.7 (which should probably be 4.2.5.4 as mentioned above) from "OAM" to "Operations, Administration, and Maintenance (OAM [RFC6291]" There are about three uses of "ACes" in the draft but many uses of "ACs". Suggest changing all "ACes" to "ACs". Globally replace "commited" with "committed". Section 6: "this lead to" -> "this leads to", "leading to malfunctioning" -> "which can lead to malfunctioning" Suggest "ASCII" -> "ASCII [RFC0020]" Sometimes it is "c-vlan" and sometimes it is "cvlan". Probably best to standardize. The first word of Section A.4, instead of the character 0x27 apostrophe, has unicode character 0x2019 RIGHT SINGLE QUOTE. This causes a grable in the htmlized version. Suggest using the usual ASCII apostrophe. In the caption of Figures 27, 28 and 29: non-initial "The" -> "the". But some more words in the caption of Figure 30 should be capitalized. "reponse" -> "response" "latencey" -> "latency" First word of Acknowledgements section: "The" -> "This" There are a number of idnits complaints about lines too long but I think these are due to non-ASCII characters and are not actual problems. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com