Simpler text, MAY skip validation

draft-ietf-quic-multipath.md

@@ -112,11 +112,8 @@ non-zero connection IDs in order to identify the path and respective
 packet number space.
 
 To add a new path to an existing QUIC connection with multipath support,
-a client starts a path validation on
+a client starts a path validation on or send a packet
 the chosen path, as further described in {{path-initiation}}.
-A new path can only be used once the associated 4-tuple has been validated
-by ensuring that the peer is able to receive packets at that address
-(see {{Section 8 of QUIC-TRANSPORT}}).
 In this version of the document, a QUIC server does not initiate the creation
 of a path, but it can validate a new path created by a client.
 
@@ -381,16 +378,17 @@ with the same, unused Path ID. When the peer receives the PATH_CHALLENGE,
 it MUST pick a Connection ID with the same Path ID for sending the PATH_RESPONSE.
 
 When the multipath extension is negotiated, a client that wants to use an
-additional path MUST first initiate the Address Validation procedure
+additional path SHOULD first initiate the Address Validation procedure
 with PATH_CHALLENGE and PATH_RESPONSE frames as described in
-{{Section 8.2 of QUIC-TRANSPORT}}, unless it has previously validated
+{{Section 8.2 of QUIC-TRANSPORT}}. It MAY skip the validation and
+simply send packets on the paths if it has previously validated
 that address.
 
 After receiving packets from the
 client on a new path, if the server decides to use the new path,
-the server MUST perform path validation ({{Section 8.2 of QUIC-TRANSPORT}})
+the server SHOULD perform path validation ({{Section 8.2 of QUIC-TRANSPORT}})
 unless it has previously validated that address.
-An endpoint that receives a PATH_CHALLENGE and does not want to establish
+An endpoint that receives packets on a new path and does not want to establish
 this path is expected to close the path by sending a PATH_ABANDON
 on another path, as specified in section {{path-close}}.
 
@@ -444,18 +442,6 @@ a server should issue a token that is capable of validating
 any of the previously validated addresses. Further guidance on token usage can be
 found in {{Section 8.1.3 of QUIC-TRANSPORT}}.
 
-### Immediate path initiation
-
-The server may receive packets for a yet unused Path ID that do not
-contain a path challenge. Such packets are valid if the can be properly decrypted
-and if they contain a valid connection ID. ({{path-initiation}}
-specifies that the client may send data packets immediately if "it has previously
-validated that address".) The server SHOULD create a new path, accept the
-packets arriving on that path from the client, and acknowledge them.
-
-If the server decides to not accept the packet, it MUST close the path as
-specified in {{path-close}}.
-
 ## Path Status Management
 
 An endpoint uses the PATH_BACKUP and PATH_AVAILABLE frames to inform the peer that it should