Remove HTML comments and security considerations for digital assets

The removed "Security Considerations for DIGITAL ASSETS" section was a
leftover and TODO-comments referred aspects already mentioned in other
sections.

EIPS/eip-6956.md

@@ -562,8 +562,6 @@ Legend:
 
 ## Backwards Compatibility
 
-<!-- NEEDS FURTHER DISCUSSION -->
-
 No backward compatibility issues found. 
 
 This EIP is fully compatible with ERC-721 and (when extended with the `IERC6956Floatable`-interface) corresponds to the well-known ERC-721 behavior with an additional authorization-mechanism via attestations. Therefore we recommend - especially for physical assets - to use the present EIP instead of ERC-721 and amend it with extensions designed for ERC-721.
@@ -589,8 +587,6 @@ Test cases are available:
 
 ## Security Considerations
 
-<!-- NEEDS FURTHER DISCUSSION -->
-
 **If the asset is stolen, does this mean the thief has control over the NFT?**
 Yes.The standard aims to anchor an NFT to the asset inseperably and unconditionally. This includes reflecting theft, as the ORACLE will testify that PROOF-OF-CONTROL over the ASSET is established. The ORACLE does not testify whether the controller is the legitimate owner,
 Note that this may even be a benefit. If the thief (or somebody receiving the asset from the thief) should interact with the anchor, an on-chain address of somebody connected to the crime (directly or another victim) becomes known. This can be a valuable starting point for investigation.
@@ -631,22 +627,6 @@ In case the ASSET is a physical object, good or property, the following ADDITION
 - Is RECOMMENDED to employ ANCHOR-TECHNOLOGIES featuring irreproducible security features.
 - In general it is NOT RECOMMENDED to employ ANCHOR-TECHNOLOGIES that can easily be replicated (for example barcodes, "ordinary" NFC chips, .. ). Replication includes physical and digital replication.
 
-
-
-### Security Considerations for DIGITAL ASSETS
-
-<!-- NEEDS DISCUSSION -->
-
-<!--
-- TODO formal definition, shall extend to digital-only AND abstract assets (for example memberships)
-- Maybe use Physical and non-physical assets (to extend to abstract assets)?
-- Requirements on Oracles and Proof-of-Control for Digital ASSETs will not be defined in this EIP
-- Valid anchors
-  - Outline merkle-tree salt leaves
-  - Why using merkle-trees and not simply store all available anchors on-chain (besides memory issues)
-- Maintenance-role over using ownership (Ownable is used by marketplaces to manage the collection)
--->
-
 ## Copyright
 
 Copyright and related rights waived via [CC0](../LICENSE.md).