Original text:
Digital Twin <del> Overall, the Digital Map is needed to provide the mechanism to connect data islands from the core multi-layered topology.  It is a solution feasible and useful in the short-term for the existing operations use cases, but it is also a requirement for the Digital Twin. </del>  The following sections includes some initial use case descriptions to initiate the discussion about what type of info is needed to describe <del> the use cases in the context of Digital Map.  The next version of the draft will include more info on these use cases and more input from the operaotors, from the perspective of what the value of the digital map for each use case is and how the Digital Map API can be used. This will also clarify if only read and if/when write interface is needed per use case. </del>  3.1. The application will be able to retrieve physical topology from the <del> controller via Digital Map API and from the response it will be able to retrieve physical inventory of individual devices and cables. </del>  The application may request either one or multiple layers of topology <del> via the Digital Map API and and from the response it will be able to </del>  retrieve both physical and logical inventory.  3.2. 3.3. <del> The application will be able to retrieve all services from the Digital Map API for selected network types.  The application will be able to retrieve the topology for selected services via Digital Map API and from the response it will be able to navigate via the supporting relationship top-down to the lower layers.  That way, it will be able to determine what logical resources are used by the service.  The supporting relations to the lowest layer will help application to determine what physical resources are used by the service. </del>  3.4.

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:
Digital Twin  <ins> Overall, the SIMAP is needed to provide the mechanism to connect data islands from the core multi-layered topology.  It is a solution feasible and useful in the short-term for the existing operations use cases, but it is also a requirement for the SIMAP. </ins> The following sections includes some initial use case descriptions to initiate the discussion about what type of info is needed to describe  <ins> the use cases in the context of SIMAP.  The next version of the draft will include more info on these use cases and more input from the operators, from the perspective of what the value of the SIMAP for each use case is and how the SIMAP API can be used.  This will also clarify if only read and if/when write interface is needed per use case. </ins> 3.1. The application will be able to retrieve physical topology from the  <ins> controller via SIMAP API and from the response it will be able to retrieve physical inventory of individual devices and cables. </ins> The application may request either one or multiple layers of topology  <ins> via the SIMAP API and and from the response it will be able to </ins> retrieve both physical and logical inventory. <ins> 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> 3.2. 3.3.  <ins> The application will be able to retrieve all services from the SIMAP API for selected network types.  The application will be able to retrieve the topology for selected services via SIMAP API and from the response it will be able to navigate via the supporting relationship top-down to the lower layers.  That way, it will be able to determine what logical resources are used by the service.  The supporting relations to the lowest layer will help application to determine what physical resources are used by the service. </ins> 3.4.