Permission delegation - more small edits

docs/concepts/accounts/permission-delegation.md

@@ -10,6 +10,8 @@ status: not_enabled
 
 Permission delegation is the function of granting various permissions to another account to send permissions on behalf of your account. This can be used instead of or alongside techniques such as [multi-signing](./multi-signing.md) to enable flexible security paradigms such as role-based access control.
 
+_(Requires the [PermissionDelegation amendment][] {% not-enabled /%}.)_
+
 ## Background
 
 Managing your [cryptographic keys](./cryptographic-keys.md) is one of the more challenging parts of using a blockchain. As part of a defense-in-depth strategy, a secure configuration should limit the damage that can occur if a secret key is compromised. One way to do this is to rotate keys regularly and to keep master keys off of computers that are always connected to the internet and serving user traffic. However, many use cases involve frequently and automatically signing transactions, which typically necessitates having secret keys on an internet-connected server.
@@ -21,9 +23,9 @@ Permission Delegation can help optimize for these sorts of challenges by grantin
 
 The account on whose behalf transactions are being sent is called the _delegating account_. The account sending the transactions is called the _delegate_.
 
-The delegating account first sends a [DelegateSet transaction][] to designate an account as its delegate and to specify which permissions the delegate has. The delegating account can update or revoke the permissions at any time by sending another DelegateSet transaction.
+The delegating account first sends a [DelegateSet transaction][] to designate an account as its delegate and to specify which permissions the delegate has. The delegating account can update or revoke the permissions at any time by sending another DelegateSet transaction. A delegating account can have more than one delegate, and can grant different sets of permissions to each delegate.
 
-The delegate can send transactions that execute as if they were sent by the delegating account. These transactions specify both the delegating account's information as well as the address of the delegate who is sending the transaction. The delegate can sign these transactions with any of the following:
+A delegate can send transactions that execute as if they were sent by the delegating account. These transactions specify both the delegating account's information as well as the address of the delegate who is sending the transaction. The delegate can sign these transactions with any of the following:
 
 - The delegate's master key pair
 - A regular key pair that the delegate has authorized
@@ -36,16 +38,27 @@ The delegate can only send transactions that match the permissions it has. Permi
 
 For a complete list of transaction types that can or cannot be delegated as well as a list of granular permissions, see [Permission Values](/docs/references/protocol/data-types/permission-values.md).
 
+### Limitations
+
+The main limiting factor on how many delegates you can have is that you must hold enough XRP to meet the [reserve requirement](./reserves.md). Each delegate's permissions are tracked with a [Delegate ledger entry][], which counts as one item towards the delegating account's owner reserve.
+
+Each delegate can be granted up to 10 permissions.
+
+Some permissions cannot be delegated, especially permissions that would allow the delegate to change cryptographic keys or grant additional permissions.
+
+The available set of granular permissions is hard-coded, and the permissions cannot be customized. For example, you cannot grant permission to send only certain currencies and not others.
 
 ## Comparison with Multi-Signing
 
+Permission delegation is similar to multi-signing in that it allows other key pairs to sign transactions that "come from" your account. However, there are key differences in functionality between the two, as summarized in the following table:
+
 |                  | Permission Delegation | Multi-Signing |
 |------------------|-----------------------|---------------|
 | Transaction cost | Paid by the delegate | Paid by the account that owns the list |
-| Permission control | Can only send transactions matching specific permissions granted | Can send any transactions except specific cases that require the master key pair |
+| Permission control | Can only send transactions matching specific permissions granted | Can send any transactions except [specific cases that require the master key pair](./cryptographic-keys.md#special-permissions) |
 | M-of-N permission | Not supported | Configurable quorum and weights with up to 32 signers |
 | Unfunded accounts | Delegates must have funded accounts on ledger | Signers can be funded accounts or key pairs with no account on ledger. |
-| Key management | Delegate manages their own keys, including multi-signing | Signers can manage their own keys but cannot perform nested multi-signing. |
+| Key management | Delegate manages their own keys, including multi-signing | Signers with funded accounts can manage their own keys but cannot perform nested multi-signing. |
 
 
 ## See Also

docs/references/protocol/data-types/permission-values.md

@@ -6,11 +6,13 @@ label:
 ---
 # Permission Values
 
-The Permission Delegation amendment {% not-enabled /%} defines permissions that can be granted to other accounts. These permissions fall into the following categories:
+[Permission delegation](/docs/concepts/accounts/permission-delegation.md) defines permissions that can be granted to other accounts. These permissions fall into the following categories:
 
 - **Transaction Type Permissions** - Permission to send transactions with the specified [transaction type](../transactions/types/index.md).
 - **Granular Permissions** - Permission to send transactions with a specific subset of functionality.
 
+_(Requires the [PermissionDelegation amendment][] {% not-enabled /%}.)_
+
 ## Numeric and String Values
 
 In the [canonical binary format](../binary-format.md) for transactions and ledger data, permission values are stored in a numeric form (specifically, as a 32-bit unsigned integer). However, in JSON they can be specified and returned in string format for convenience, similar to how transaction type names (`TransactionType` fields) work.
@@ -21,10 +23,10 @@ When specifying a permission value in JSON, you can use either the numeric value
 Not all client libraries support numeric PermissionValue types. In most cases, you should use the string names of the permissions you want to grant.
 {% /admonition %}
 
-- For *transaction type permissions**, the string is the name of the transaction type exactly (case-sensitive). For example, a permission value of `"PaymentChannelClaim"` grants permission to send [PaymentChannelClaim transactions][].
+- For **transaction type permissions**, the string is the name of the transaction type exactly (case-sensitive). For example, a permission value of `"PaymentChannelClaim"` grants permission to send [PaymentChannelClaim transactions][].
 - For **granular permissions**, the string is the name of the granular permission (case-sensitive). For example, a permission value of `"TrustlineAuthorize"` grants permission to send TrustSet transactions that authorize trust lines (but not ones that modify other settings such as the trust line limit or freeze status).
 
-The numeric value `0` is reserved for "full permissions", meaning permission to send transactions of all types. It is technically possible to send a transaction that grants this permission value. However, delegate accounts cannot use full permissions.
+The numeric value `0` is reserved for "full permissions", meaning permission to send transactions of all types, but it is not possible to delegate full permissions.
 
 ## Transaction Type Permissions
 
@@ -50,6 +52,10 @@ The following permissions cannot be delegated:
 | [SetFee][]          | `102` |
 | [UNLModify][]       | `103` |
 
+{% admonition type="warning" name="Known Issue" %}
+With only the PermissionDelegation amendment, it's possible to assign permissions for transaction types that are reserved, unassigned, or part of amendments that are not currently enabled; it's also possible to assign PermissionValue `0` for full permissions. However, these values do not actually grant any permissions. This is a bug, and a future amendment will prevent assigning values outside of currently-enabled, delegatable transaction types or known granular permissions.
+{% /admonition %}
+
 ## Granular Permissions
 [[Source]](https://github.com/XRPLF/rippled/blob/master/include/xrpl/protocol/detail/permissions.macro "Source")