Information Model for Abstraction and Control of TE Networks (ACTN)
draft-ietf-teas-actn-info-model-10

This document "covers the requirements identified in" draft-ietf-teas-actn-requirements, which is used as a Normative reference, but it looks like it won't be published after all [1].  The framework document (draft-ietf-teas-actn-framework) does not depend normatively on the requirements; it seems like it should be possible for this document to not depend on them either.

[1] https://mailarchive.ietf.org/arch/msg/teas/Ep3z1YP2QV8JkgDHK3Zuw0V6Nq0

What is the goal of publishing this as an RFC? It seems like an intermediate document that doesn't have archival value. I do not find publication of an information model mentioned on the TEAS charter, but maybe I missed it.

§9: There are three upper-case SHOULDs in this section, but no RFC 8174 or 2119 boilerplate. Normative keywords don't really seem appropriate for an information model, so perhaps they should be lower case?

I echo the comments questioning the archival value for publishing a document like this.
I think it's a good intermediate point to have, including the security considerations text
(thank you for the quick update after the secdir review!), but am unsure what portion(s)
of it could not be easily folded into successor documents.

Section 2

   This section provides an ACTN common interface information model to
   describe in terms of primitives, objects, their properties
   (represented as attributes), their relationships, and the resources
   for the service applications needed in the ACTN context.

nit: The grammar here is a bit odd -- as-is, it says we have a model "to
describe in terms of [a list of things]", but don't say what is being
described.  I'm not entirely sure what the intended text would be, though.

Section 3.2, 3.4

Do I understand correctly that Modify is for CNC-to-MDSC commmunication and
Update is for MDSC-to-CNC communication?  Perhaps this could be made more
explicit.

Section 5.7.2

      [...] For example, permission
      the correct selection from the network of the destination related
      to the indicated VNF It is e.g. the case of VM migration among
      data center and CNC can enforce specific policy that can permit
      MDSC/PNC to calculate the correct path for the connectivity
      supporting the data center interconnection required by
      application.

There seems to be an editing error around "indicated VNF It is e.g.", maybe
just a missing full stop and commas around "e.g."?

Section 9

   The ACTN information model does not directly introduce security
   issues. Rather, it defines a set of interfaces for traffic

I would hope that no product of the IETF directly introduces security
*issues* (problems)!  Maybe "is not directly relevant when considering
potential security issues" is some better wordsmithing.

   Implementations of the ACTN framework will have distributed
   functional components that will exchange this information model.

nit: Perhaps this is overly pedantic, but are they exchanging this
information model, or a concrete instantiation that adheres to this model?

The document does not really specify what a <Path>, or <VN link>, or <VN node> actually is... are those elements identified by IP addresses or something else, or does that not really matter?