Other than the following from nits no substantive comments:

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589'

  ** Downref: Normative reference to an Informational RFC: RFC 7348

  == Outdated reference: A later version (-13) exists of
     draft-ietf-opsawg-ac-lxsm-lxnm-glue-12

  == Outdated reference: A later version (-15) exists of
     draft-ietf-opsawg-ntw-attachment-circuit-14

  == Outdated reference: A later version (-19) exists of
     draft-ietf-opsawg-teas-attachment-circuit-18

# Éric Vyncke, INT AD, comments for draft-ietf-opsawg-teas-common-ac-14
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 Reza Rokui for the shepherd's detailed write-up including the WG consensus *but* the justification of the intended status is rather light: being "valuable" is not enough to be a "standard".

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

Thanks for using SVG graphics, it makes reading the HTML rendering much easier and nicer.

### Abstract

Should 'model' be used rather than 'module' in `The document specifies a common attachment circuits (ACs) YANG module` in order to be consistent with the title ? I understand that a model can consist of a single module.

### Section 1

Should `ancillary node` be better explained as it can mean multiple things depending on the context?

Figure 1, when the text writes `The same CE may terminate multiple ACs.` it would help if the text mentioned CE3 & CE4 and the associated bearer (assuming that `b*` is for a bearer).

### Section 2

When defining "bearer", please associate  the previously defined terms (CE, CPE) with `customer node`.

### Section 3

Not really about this I-D, but I find the use of `ietf-ac-glue` rather than 'ietf-ac-bind' a little too trivial especially when the text is about `To bind Layer 2 VPN` ;-)

### Section 4

Thanks for splitting the whole tree in parts, it helps.

### Section 4.1

It is rather unclear what `server` means in this document, even if I can guess some controllers in the SP domain.

### Section 4.3

Should there be a `*l3*-tunnel-type` in addition to `*l2*-tunnel-type` ?

Should the layer of the next hop be specified in `local-defined-next-hop`?

Should there be reference to `UNI`and `NNI`?

About figure 5 explanations about ipv6-connection, should there be a possibility for multiple IPv6 addresses per service ? Should there be SLAAC for dynamic address allocation ?

Should there a choice on how to authenticate OSPFv3 either RFC 4552 or RFC 7166 ?

### Section 5

In the vxlan grouping, the modules writes `"Specifies the VXLAN access mode. By default, the peer mode is set to 'static-mode'.";` but I see nothing in the YANG module to set a default (unsure whether it is possible though).

## NITS (non-blocking / cosmetic)

s/Layer 2 VPN/layer-2 VPN/ ? same for layer 3 of course

****