Tweaks to validation notes

docs/topics/3.0-announcement.md

@@ -188,14 +188,11 @@ Alternatively if you want the errors to be against a specific field, use a dicti
 
 This ensures you can still write validation that compares all the input fields, but that marks the error against a particular field.
 
-#### Limitations of ModelSerializer validation.
+#### Differences between ModelSerializer validation and ModelForm.
 
-This change also means that we no longer use the `.full_clean()` method on model instances, but instead perform all validation explicitly on the serializer. This gives a cleaner separation, and ensures that there's no automatic validation behavior on `ModelSerializer` classes that can't also be easily replicated on regular `Serializer` classes.
+This change also means that we no longer use the `.full_clean()` method on model instances, but instead perform all validation explicitly on the serializer. This gives a cleaner separation, and ensures that there's no automatic validation behaviour on `ModelSerializer` classes that can't also be easily replicated on regular `Serializer` classes.
 
-This change comes with the following limitations:
-
-* The model `.clean()` method will not be called as part of serializer validation. Use the serializer `.validate()` method to perform a final validation step on incoming data where required.
-* The `.unique_for_date`, `.unique_for_month` and `.unique_for_year` options on model fields are not automatically validated. Again, you'll need to handle these explicitly on the serializer if required.
+It's important to note that this change also means that the model `.clean()` method will not be called as part of serializer validation, as it would be if using a `ModelForm`. Use the serializer `.validate()` method to perform a final validation step on incoming data where required.
 
 #### Writable nested serialization.