Last Call Review of draft-zern-webp-05
review-zern-webp-05-opsdir-lc-chown-2021-10-31-00

Hi,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

This draft serves as the IETF standards document through which the WebP image
format is registered with IANA.

The document is ready for publication with Nits to be addressed.  Note I am not
overly familiar with such registration procedure, but have read through RFC6838
since being assigned this draft for review, given 6838 defines the registration
requirements.

General comments

I think the abstract should say this document provides the WebP media type
registration with IANA, as required by RFC 6838, not just what WebP is.

The draft includes pointers to the specifications for GIF, JPG and PNG but it
might be useful to confirm which documents (or additional documents) serve the
registration function for those formats.

In RFC6838 section 4.6, the security requirements are detailed (see
https://datatracker.ietf.org/doc/html/rfc6838#section-4.6).   I don’t think
these have all been addressed in this document.  Section 4.6 for example says
that the draft MUST state whether “active content” is employed or not, and if
it is, detail steps taken, but I don’t see that here.  Similarly it SHOULD
discuss compression.  I’d suggest a quick review of 4.6 for compliance.

I don’t see the IANA registry cited in this document - it is mentioned in
Section 5 but an explicit pointer would use useful.  I believe it’s the one at
https://www.iana.org/assignments/media-types/media-types.xhtml

I also looked at compliance of this draft in Section 2.1 with Section 6.2 of
RFC 6838.  I think this draft should explicitly include the Full Name and
suffix used, and while the subtype name listed is also the suffix, perhaps make
that explicit.

Finally, I see personal email contacts included, though RFC 6838 says “The
"owner" of a media type registered in the standards tree is assumed to be the
standards-related organization itself.”, so should there be a more generic
google contact or owner listed?

—
Tim