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

[Donald Eastlake <[e-mail]>]

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