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

[[e-mail]]

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]<mailto:[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.