Added open issues section to TE topology profile (#276)

* Added open issues section, as requested by TEAS WG chairs

drafts/te-topo-profile/draft-ietf-teas-te-topology-profiles.md

@@ -6,7 +6,7 @@ title: >
    Applicability to non-TE Use Cases
 
 abbrev: TE Topology Profiles
-docname: draft-ietf-teas-te-topology-profiles-00
+docname: draft-ietf-teas-te-topology-profiles-latest
 submissiontype: IETF
 workgroup: TEAS Working Group
 category: info
@@ -130,8 +130,8 @@ contributor:
        +--rw te!
           +--rw admin-status?
           |       te-types:te-admin-status
-          +--rw inter-domain-plug-id?          binary
-          +--ro oper-status?                   te-types:te-oper-status
+          +--rw inter-domain-plug-id?        binary
+          +--ro oper-status?                 te-types:te-oper-status
 ~~~~
 {: #uni-discovery-tree title="UNI Topology"}
 
@@ -215,21 +215,21 @@ contributor:
        +--rw te-node-id?   te-types:te-node-id
        +--rw te!
           +--rw te-node-attributes
-          |  +--rw admin-status?               te-types:te-admin-status
-          |  +--rw name?                       string
-          +--ro oper-status?                   te-types:te-oper-status
+          |  +--rw admin-status?          te-types:te-admin-status
+          |  +--rw name?                  string
+          +--ro oper-status?              te-types:te-oper-status
      augment /nw:networks/nw:network/nt:link:
        +--rw te!
           +--rw te-link-attributes
-          |  +--rw name?                       string
-          |  +--rw admin-status?               te-types:te-admin-status
-          +--ro oper-status?                   te-types:te-oper-status
+          |  +--rw name?                  string
+          |  +--rw admin-status?          te-types:te-admin-status
+          +--ro oper-status?              te-types:te-oper-status
      augment /nw:networks/nw:network/nw:node/nt:termination-point:
        +--rw te-tp-id?   te-types:te-tp-id
        +--rw te!
-          +--rw admin-status?                  te-types:te-admin-status
-          +--rw name?                          string
-          +--ro oper-status?                   te-types:te-oper-status
+          +--rw admin-status?             te-types:te-admin-status
+          +--rw name?                     string
+          +--ro oper-status?              te-types:te-oper-status
 ~~~~
 {: #admin-oper-state-tree title="Generic Topology with admin and operational state"}
 
@@ -259,7 +259,7 @@ contributor:
        +--rw te!
           +--rw te-node-attributes
              +--rw underlay-topology {te-topology-hierarchy}?
-                +--rw network-ref?   -> /nw:networks/network/network-id
+                +--rw network-ref? -> /nw:networks/network/network-id
      augment /nw:networks/nw:network/nt:link:
        +--rw te!
           +--rw te-link-attributes
@@ -559,21 +559,43 @@ max-link-bandwidth can only be defined in the technology-specific TE
 Topology Model (Option 1 or Option 3). These attributes can be TE or
 non-TE and require the implementation of the te container.
 
+{: #open-issues}
+
+# Open Issues
+
+## Supporting node/link versus overlay/underlay
+
+Some more explanation of the difference between supporting-node/supporting-link and overlay/underlay has been requested.
+
+Note: that this issue is also tracked in github as issue #167.
+
 {: #implement}
 
-# Implemented profiles
+## Implemented profiles
 
-When a server implements a profile of the TE topology model, it is not clear how the server
-can report to the client the subset of the model being implemented.
+When a server implements a profile of the TE topology model, there is no standardized mechanism for the server to report to the client the subset of the model being implemented.
+
+This might not be an issue in case the TE topology profile is read by the the client because the server reports in the operational datastore only the leaves which have been implemented, as described
+in section 5.3 of {{!RFC8342}}.
+
+More investigation is instead required in case the TE topology profile is configured by the client, to  avoid that the client tries to write an attribute not used in the TE Topology profile implemented by the server.
 
 It is also worth noting that the supported profile may also depend on other attributes
-(for example the network type).
+(for example the network type), so the YANG deviation mechanism is not applicable to this scenario.
 
-In case the TE topology profile is reported by the server to the client, the server will report
-in the operational datastore only the leaves which have been implemented, as described
-in section 5.3 of {{!RFC8342}}.
+Note: that this issue is also tracked in github as issue #161.
+
+## Applicability to non-TE use cases
+
+Extending the applicability of RFC8795 to non-TE use cases is important. However, it is desirable to avoid any debate about whether these use cases in section 2 are or are not TE.
+
+Note: that this issue is also tracked in github as issue #276.
+
+### Update UNI topology discovery use case
+
+{{uni-discovery}} points to individual drafts and does reflect the progress made since then. For example, the UNI draft was replaced by other drafts that then led to the SAP model {{?RFC9408}}, which covers both UNI and NNI.
 
-More investigation is required in case the TE topology profile is configured by the client.
+Note: that this issue is also tracked in github as issue #275.
 
 {: #security}