Automatically merged updates to draft EIP(s) 173 (ethereum#2804)

Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing

EIPS/eip-173.md

@@ -34,8 +34,6 @@ Here are some examples of kinds of contracts and applications that can benefit f
 
 ## Specification
 
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
-
 Every ERC-173 compliant contract must implement the `ERC173` interface. Contracts that inherit from OpenZeppelin's `Ownable` contract are compliant with ERC-173. However future contracts should also implement `ERC165` for the ERC-173 interface.
 
 ```solidity
@@ -52,7 +50,8 @@ interface ERC173 /* is ERC165 */ {
     /// @return The address of the owner.
     function owner() view external;
 	
-    /// @notice Set the address of the new owner of the contract   
+    /// @notice Set the address of the new owner of the contract
+    /// @dev Set _newOwner to address(0) to renounce any ownership.
     /// @param _newOwner The address of the new owner of the contract    
     function transferOwnership(address _newOwner) external;	
 }
@@ -72,6 +71,8 @@ The `owner()` function may be implemented as `pure` or `view`.
 
 The `transferOwnership(address _newOwner)` function may be implemented as `public` or `external`.
 
+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.
 
 ## Rationale
@@ -84,6 +85,8 @@ Here are other schemes that were considered:
 
 This standard does not exclude the above ownership schemes or other schemes from also being implemented in the same contract. For example a contract could implement this standard and also implement the other schemes so that ownership could be managed and transferred in multiple ways. This standard does provide a simple ownership scheme that is backwards compatible, is light-weight and simple to implement, and can be widely adopted and depended on.
 
+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.
+
 ## Backwards Compatibility
 
 OpenZeppelin's Ownable contract is actively being used in contracts. Contracts that inherit Ownable are in compliance with this standard.