# Éric Vyncke, INT AD, comments for draft-ietf-opsawg-teas-attachment-circuit-19
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Luis Contreras for the shepherd's detailed write-up including the WG consensus even if the justification of the intended status is rather light.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

Thanks for the use of SVG graphics, it makes reading much easier in the HTML rendering.

### One or two models ?

When reading the abstract and section 1, it is unclear whether this I-D is about 1 or 2 data models ? It seems that the 2 modules build one service data model...

### Section 1.1

`This document specifies a YANG service data model ("ietf-ac-svc")` I think that "ietf-ac-svc" is a *module* and not a *model*. Of course in this case, the model includes only one module but let's try to be correct ;) The "ietf-bearer-svc" is also a module as it is written later in the section.

The text is mainly about how to add a new AC but not how to modify or to delete it. Should there be some text about the lifecycle of an AC ?

### Section 1.2

`The AC model specified in this document is` but this document is about *two* models... so this sentence should probably in the plural form or be restrictive to "AC service model".

The section title should probably be "Positioning ACaaS model vs. Other Data Models"

### Section 4.1

Should there be a "b4" in figure 1 ?

### Section 5

The apparent confusion between model and module happens again, the section 5 title is about data models but the sub-section titles are about YANG modules.

### Section 5.1

How can a location address be changed if the location is "ro" ?

Are all location only by street/city addresses ? Should there be more generic location (especially for mobile) or more details locations (e.g., floor, ...).

Please bear with my lack of knowledge about YANG language, but if there are several AC on the same location, does this mean that the location information will be repeated several times ?

### Section 5.2.1

As the decision has been made, it is perhaps time to revisite the following with a more assertive tone `The rationale for deciding whether a reusable grouping should be maintained in this document or be moved into the AC common module [I-D.ietf-opsawg-teas-common-ac] is as follows`

### Section 5.2.5.1 (and possibly others)

It seems that the tree view repeats the content of imported YANG modules (e.g., ac-common:layer2-ac) grouping, isn't there a risk of incoherency between two future RFC ? 

### Appendix A

Reading examples with date in the future made me smile ;-)

And thanks for some dual-stack examples.

## NITS (non-blocking / cosmetic)

The use of `Layer 2` is hurting my eyes as it should be "layer 2" and in some cases "layer-2"...