Returning Values from Forms: multipart/form-data
draft-ietf-appsawg-multipart-form-data-11

Thanks for adding the form-data parameter to the registration update.

I concur with Kathleen's comment to move the last paragraph in the security considerations to the front.

Please consider moving the last paragraph to the first in the security considerations section.  I agree with the point made by the SecDir reviewer that it improves readability and makes this point clear with reasons before subsequent paragraphs detail it a bit more specifically.
https://www.ietf.org/mail-archive/web/secdir/current/msg05555.html

I also agree with the SecDir reviewer and suggest you reword the following paragraph in Appendix B:
   More problematic is the ambiguity introduced because implementations
   did not follow [RFC2388] because it used "may" instead of "MUST" when
   specifying encoding of field names, and for other unknown reasons, so
   now, parsers need to be more complex for fuzzy matching against the
   possible outputs of various encoding methods.

Perhaps to something like:

   More problematic is the ambiguity introduced because implementations
   of [RFC2388] opted to not follow the specification of encoding field names when the term "may" appeared, where in hindsight it should have been "MUST". As a result,
   parsers need to be more complex for fuzzy matching against the
   possible outputs of various encoding methods.

If I go something wrong, hopefully you get the point and can easily adjust the text.

From the SecDir review:
Please correct me if I'm off base here, but it sounds like the ambiguity
set in because implementations WERE following RFC 2388 by making
choices on their own (due to the "may"s) rather than being directed to
make uniform choices which would have been mandated if that RFC had used
"MUST"s.

Thanks for your work on this draft!

- abstract: the "(re)defines" is a bit confusing, I'd say just
stick with "defines"

- 4.3, typo "may seems to be present"