Hi Med, I have reviewed the changes you made and am happy with them. I consider all my comments to have been resolved.
Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com On Mon, Mar 11, 2024 at 2:31 AM <mohamed.boucad...@orange.com> wrote: > Hi Donald, > > > > (adding OPSAWG as it seems the review was not shared on that list) > > > > Thanks for the careful review. > > > > A diff to track the changes to address your comments can be seen at: > > > > > https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-opsawg-teas-attachment-circuit&url_2=https://boucadair.github.io/attachment-circuit-model/draft-ietf-opsawg-teas-attachment-circuit.txt > > > > See more context inline, fwiw. > > > > Cheers, > > Med > > > > *De :* Donald Eastlake <d3e...@gmail.com> > *Envoyé :* samedi 9 mars 2024 04:16 > *À :* teas-cha...@ietf.org; > draft-ietf-opsawg-teas-attachment-circuit....@ietf.org > *Cc :* Routing Directorate <rtg-...@ietf.org>; t...@ietf.org > *Objet :* RTGDIR Early Review of draft-ietf-opsawg-teas-attachment-circuit > > > > 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. > > *[Med] That list focuses on the customer terminating points, not the > network-facing ones. Added a PE mention in the para when provider network > is mentioned.* > > > > Also, Service Functions (and Service Function Forwarders?) seem to usually > be listed first in such lists giving them great importance. > > *[Med] SF is mentioned (and changed all occurrences of network function to > SF for consistency). No need to call out SFF.* > > 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. > > *[Med] Reworded. * > > > 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). > > *[Med] Added a new sentence to mention VRRP. * > > > > 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. > > *[Med] Good catch. Fixed.* > > > Figure 11 seems to be missing ospf. > > *[Med] You are right. Fixed. * > > > 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. > > *[Med] Reworded to clarify the intent.* > > > > Nits: > > *[Med] Went with almost all your suggestions. Please note that I didn’t > add a ref to RFC20 given that we provide the authoritative reference > RFC8177 for key strings. I also didn’t change to vrrp-bis for now. Will > take care of that when the RFC is published.* > > > ----- > > "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 > d3e...@gmail.com > > ____________________________________________________________________________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > >
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
