Original text:
4.1. <del> The following are the core requirements for the Digital Map (note that some of them are supported by default by RFC8345): </del>  Basic model with network, node, link, and interface entity types. <del> This means that users of the Digital Map model must be able to </del>  understand topology model at any layer via these core concepts only, without having to go to the details of the specific augmentations to understand the topology. <del> Layered Digital Map, from physical network (ideally optical, layer 2, layer 3) up to service and intent views. </del>  <del> Open and programmable Digital Map. </del>  This includes "read" operations to retrieve the view of the network, typically as application-facing interface of Software Defined Networking (SDN) controllers or orchestrators. It also includes "write" operations, not for the ability to <del> directly change the Digital Map data (e.g., changing the network or service parameters), but for offline simulations, also known as </del>  what-if scenarios. Running a "what-if" analysis requires the ability to take snapshots and to switch easily between them. Note that there is a need to distinguish between a change on the <del> Digital Map for future simulation and a change that reflects the current reality of the network. </del>  <del> Standard based Digital Map Models and APIs, for multi-vendor support. </del>  <del> Digital Map must provide the standard YANG APIs that provide for read/write and queries.  These APIs must also provide the capability to retrieve the links to external data/models. </del>  <del> Digital Map models and APIs must be common over different network </del>  domains (campus, core, data center, etc.). <del> This means that clients of the Digital Map API must be able to </del>  understand the topology model of layers of any domain without having to understand the details of any technologies and domains. <del> Digital Map must provide semantics for layered network topologies and for linking external models/data. </del>  <del> Digital Map must provide intra-layer and inter-layer relationships. </del>  <del> Digital Map must be extensible with metadata. </del>  <del> Digital Map must be pluggable.  That is, </del>  Must connect to other YANG modules for inventory, configuration, assurance, etc. Given that no all involved components can be available using <del> YANG, there is a need to connect Digital Map YANG model with other modelling mechanisms. </del>  <del> Digital Map must be optimized for graph traversal for paths.  This means that only providing link nodes and source and sink relationships to termination-points may not be sufficient, we may need to have the direct relationship between the termination points or nodes. </del>  4.2. <del> The following are design requirements for modelling the Digital Map. Theey are derived from the core requerements collected from the operators and although there is some duplication, these are focused on summarizing the requirements for the design of the model and API: </del>  <del> Digital Map should contain only topological information. </del>  <del> Digital Map is not required to contain all models and data required for all the management and use cases.  However, it should be designed to support adequate pointers to other functional data and models to ease navigating in the overall system.  For example: </del>  <del> ACLs and Route Policies are not required to be supported in the Digital Map, they would be linked to Digital Map </del>  <del> Dynamic paths may either be outside of the Digital Map or part of traffic engineering data/models </del>  <del> Digital Map entities should mainly contain properties used to identify topological entities at different layers, identify their roles, and topological relationships between them. </del>  <del> Digital Map should contain all topological relationships inside each layer or between the layers (underlay/overlay) </del>  <del> Digital Map should contain links to other models/data to enable generic navigation to other YANG models in generic way. </del>  <del> Provide capability for conditional retrieval of parts of Digital Map. </del>  Must support geo-spatial, temporal, and historical data.  The temporal and historical can also be supported external to the <del> Digital Map. </del>  4.3. The following are the architectural requirements for the controller <del> that provides Digital Map API: </del>  Scale, performance, ease of integration.

Reviewer comments:
Added Service & Infrastructure Maps (SIMAP) terminology Updated inventory use case to mention passive inventory Added requirements REQ-PASSIVE-TOPO: to include passive topology based on input from Brad Peters

Revised text:
4.1.  <ins> The following are the core requirements for the SIMAP (note that some of them are supported by default by RFC8345): </ins> Basic model with network, node, link, and interface entity types.  <ins> This means that users of the SIMAP model must be able to </ins> understand topology model at any layer via these core concepts only, without having to go to the details of the specific augmentations to understand the topology.  <ins> Layered SIMAP, from physical network (ideally optical, layer 2, layer 3) up to service and intent views. SIMAP must support topology of the complete network, including active and passive parts. For Access network providers the ability to have linkage in the SIMAP of the complete network (active + passive) is essential as it provides many advantages for optimized customer service, reduced MTTR, and lower operational costs through truck roll reduction. </ins>  <ins> Open and programmable SIMAP. </ins> This includes "read" operations to retrieve the view of the network, typically as application-facing interface of Software Defined Networking (SDN) controllers or orchestrators. It also includes "write" operations, not for the ability to  <ins> directly change the SIMAP data (e.g., changing the network or service parameters), but for offline simulations, also known as </ins> what-if scenarios. Running a "what-if" analysis requires the ability to take snapshots and to switch easily between them. Note that there is a need to distinguish between a change on the  <ins> SIMAP for future simulation and a change that reflects the current reality of the network. </ins>  <ins> Standard based SIMAP Models and APIs, for multi-vendor support. </ins>  <ins> SIMAP must provide the standard YANG APIs that provide for read/ write and queries.  These APIs must also provide the capability to retrieve the links to external data/models. </ins>  <ins> SIMAP models and APIs must be common over different network </ins> domains (campus, core, data center, etc.).  <ins> This means that clients of the SIMAP API must be able to </ins> understand the topology model of layers of any domain without having to understand the details of any technologies and domains.  <ins> SIMAP must provide semantics for layered network topologies and for linking external models/data. </ins>  <ins> SIMAP must provide intra-layer and inter-layer relationships. </ins>  <ins> SIMAP must be extensible with metadata. </ins>  <ins> SIMAP must be pluggable.  That is, </ins> Must connect to other YANG modules for inventory, configuration, assurance, etc. Given that no all involved components can be available using  <ins> YANG, there is a need to connect SIMAP YANG model with other modelling mechanisms. </ins>  <ins> SIMAP must be optimized for graph traversal for paths.  This means that only providing link nodes and source and sink relationships to termination-points may not be sufficient, we may need to have the direct relationship between the termination points or nodes. </ins> 4.2.  <ins> The following are design requirements for modelling the SIMAP.  Theey are derived from the core requerements collected from the operators and although there is some duplication, these are focused on summarizing the requirements for the design of the model and API: </ins>  <ins> SIMAP should contain only topological information. </ins>  <ins> SIMAP is not required to contain all models and data required for all the management and use cases.  However, it should be designed to support adequate pointers to other functional data and models to ease navigating in the overall system.  For example: </ins>  <ins> ACLs and Route Policies are not required to be supported in the SIMAP, they would be linked to the SIMAP </ins>  <ins> Dynamic paths may either be outside of the SIMAP or part of traffic engineering data/models </ins>  <ins> SIMAP entities should mainly contain properties used to identify topological entities at different layers, identify their roles, and topological relationships between them. </ins>  <ins> SIMAP should contain all topological relationships inside each layer or between the layers (underlay/overlay) </ins>  <ins> SIMAP should contain links to other models/data to enable generic navigation to other YANG models in generic way. </ins>  <ins> Provide capability for conditional retrieval of parts of SIMAP. </ins> Must support geo-spatial, temporal, and historical data.  The temporal and historical can also be supported external to the  <ins> SIMAP. </ins> 4.3. The following are the architectural requirements for the controller  <ins> that provides SIMAP API: </ins> Scale, performance, ease of integration.