Summary: Has enough positions to pass.
Section 3.5.2 We now allow for multiple Canonical directives to be present. I think we should clarify that this directive is used to indicate that a file retrieved from a given URL is intended to apply to that URL; it is not a direct indication that a single file, retrieved from whatever location, applies to all listed locations. Some additional authority, such as a trusted PGP signature or the ambient authority granted from retriving the file from the listed location, is needed in order to know that the claimed canonical location applies. Section 3.5.3 We should s/email address is the preferred/email address firstname.lastname@example.org is the preferred/ (since we now have two email addresses listed) Section 6 Since we make heavy use of URIs pointing to remote content, we should probably explicitly reference the URI security considerations from RFC 3986, especially with respect to reliability and consistency (https://tools.ietf.org/html/rfc3986#section-7.1). Section 6.1 I think we should s/DNS-based/DNSSEC-based/, since we want there to be a cryptographic mechanism involved in out-of-band verification of the data. Section 7.2 We should update the initial registration for Canonical to allow multiple appearances, as the body text now does.