Update eip-173.md, last call (ethereum#2832)

Final improvements and sets status to last call.

EIPS/eip-173.md

@@ -5,7 +5,8 @@ author: Nick Mudge <[email protected]>, Dan Finlay <[email protected]
 discussions-to: https://github.com/ethereum/EIPs/issues/173
 type: Standards Track
 category: ERC
-status: Draft
+status: Last Call
+review-period-end: 2020-09-06
 created: 2018-06-07
 ---
 
@@ -15,40 +16,35 @@ A standard interface for ownership of contracts.
 
 ## Abstract
 
-The following standard allows for the implementation of a standard API for getting the owner address of a contract and transferring contract ownership to a different address.
+This specification defines standard functions for owning or controlling a contract. 
 
-Key factors influencing the standard: 
-- Keeping the number of functions in the interface to a minimum to prevent contract bloat.
-- Backwards compatibility with existing contracts.
-- Simplicity
-- Gas efficient
+An implementation allows reading the current owner (`owner() returns (address)`) and transferring ownership (`transferOwnership(address newOwner)`) along with a standardized event for when ownership is changed (`OwnershipTransferred(address indexed previousOwner, address indexed newOwner)`).
 
 ## Motivation
 
-Many smart contracts require that they be owned or controlled in some way. For example to withdraw funds or perform administrative actions. It is so common that the contract interface used to handle contract ownership should be standardized to allow compatibility with contracts that manage contracts.
+Many smart contracts require that they be owned or controlled in some way. For example to withdraw funds or perform administrative actions. It is so common that the contract interface used to handle contract ownership should be standardized to allow compatibility with user interfaces and contracts that manage contracts.
 
 Here are some examples of kinds of contracts and applications that can benefit from this standard:
 1. Exchanges that buy/sell/auction ethereum contracts. This is only widely possible if there is a standard for getting the owner of a contract and transferring ownership.
 2. Contract wallets that hold the ownership of contracts and that can transfer the ownership of contracts.
 3. Contract registries. It makes sense for some registries to only allow the owners of contracts to add/remove their contracts. A standard must exist for these contract registries to verify that a contract is being submitted by the owner of it before accepting it.
+4. User interfaces that show and transfer ownership of contracts.
 
 ## Specification
 
 Every ERC-173 compliant contract must implement the `ERC173` interface. Contracts should also implement `ERC165` for the ERC-173 interface.
 
 ```solidity
-pragma solidity ^0.4.24;
 
 /// @title ERC-173 Contract Ownership Standard
-/// @dev See https://github.com/ethereum/EIPs/blob/master/EIPS/eip-173.md
 ///  Note: the ERC-165 identifier for this interface is 0x7f5828d0
 interface ERC173 /* is ERC165 */ {
     /// @dev This emits when ownership of a contract changes.    
     event OwnershipTransferred(address indexed previousOwner, address indexed newOwner);
 
     /// @notice Get the address of the owner    
     /// @return The address of the owner.
-    function owner() view external;
+    function owner() view external returns(address);
 	
     /// @notice Set the address of the new owner of the contract
     /// @dev Set _newOwner to address(0) to renounce any ownership.
@@ -73,10 +69,16 @@ The `transferOwnership(address _newOwner)` function may be implemented as `publi
 
 To renounce any ownership of a contract set `_newOwner` to the zero address: `transferOwnership(address(0))`. If this is done then a contract is no longer owned by anybody.
 
-The OwnershipTransferred event does not have to be emitted when a contract is created.
+The OwnershipTransferred event should be emitted when a contract is created.
 
 ## Rationale
 
+Key factors influencing the standard: 
+- Keeping the number of functions in the interface to a minimum to prevent contract bloat.
+- Backwards compatibility with existing contracts.
+- Simplicity
+- Gas efficient
+
 Several ownership schemes were considered. The scheme chosen in this standard was chosen because of its simplicity, low gas cost and backwards compatibility with existing contracts.
 
 Here are other schemes that were considered:
@@ -87,6 +89,10 @@ This standard does not exclude the above ownership schemes or other schemes from
 
 This standard can be extended by other standards to add additional ownership functionality. For example [EIP-2767](https://eips.ethereum.org/EIPS/eip-2767) uses and extends this standard by adding decentralized contract ownership governance.
 
+## Security Considerations
+
+If the address returned by `owner()` is an externally owned account then its private key must not be lost or compromised.
+
 ## Backwards Compatibility
 
 Many existing contracts already implement this standard.
@@ -101,15 +107,3 @@ Many existing contracts already implement this standard.
 ## Copyright
 
 Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
-
-
-
-
-
-
-
-
-
-
-
-