YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS)
draft-ietf-opsawg-teas-attachment-circuit-20

Thanks to Tero for his secdir reviews.  

It is my opinion that the security consideration template needs work, the language is unclear at best.

# É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"...

# Gunter Van de Velde, RTG AD, comments for draft-ietf-opsawg-teas-attachment-circuit-19

# the referenced line numbers are derived from the idnits tool:
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-teas-attachment-circuit-19.txt

# This is a well written document. I have a non-blocking editorial observation:

The text uses lower and upper case AC vs ac inside the model (in descriptions). For consistency maybe align the representation to either all upper case or all lower case:

4854	           "description": "a first ac with a same peer node",
 versus 
3632	            bandwidth of the AC or download bandwidth from the

Note that the uppercase AC seems to be the most dominant within the document. 

G/

Thank you to Gyan Mishra for the GENART review.

# Internet AD comments for draft-ietf-opsawg-teas-attachment-circuit-19
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S5.2.5.2

* Can the allocation-type "slaac" be used in here as well?  It explicitly
  called out in another doc, but not mentioned here.

## Nits

### S1.1

* "or even the nature or the services" ->
  "or even the nature of the services"?

### S4.3

* "with a focus the provider" ->
  "with a focus on the provider"?

### S5.2

* "only for test and not for setting," ->
  "only for test and not for service," or something?

Just one minor comment, I cannot parse this sentence:

        For example, a given customer must have access only to its
        bearers/ACs and be discarded access to bearers/ACs of other
        customers.

Much thanks to Adrien Farrel for the OpsDir review, noting that their concerns have been addressed.