Re: [RTG-DIR] RTGDIR Early Review of draft-ietf-opsawg-teas-attachment-circuit

[Donald Eastlake <[e-mail]>]

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   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]


On Mon, Mar 11, 2024 at 2:31 AM <[e-mail]> 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 <[e-mail]>
> *Envoyé :* samedi 9 mars 2024 04:16
> *À :* [e-mail];
> [e-mail]
> *Cc :* Routing Directorate <[e-mail]>; [e-mail]
> *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   [phone] (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  [e-mail]
>
> ____________________________________________________________________________________________________________
> 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.
>
>