diff --git a/inbox/host-meta-2.xml b/inbox/host-meta-2.xml
index 5aa016bf..edd9e232 100644
--- a/inbox/host-meta-2.xml
+++ b/inbox/host-meta-2.xml
@@ -181,7 +181,7 @@
   <section2 topic='For Server Administrators' anchor='impl-admins'>
     <p>For the forseeable future you will need to maintain legacy SRV records in addition to this file, and you should provide DANE TLSA records too if possible.</p>
     <p>To make your server as accessible to other clients/servers no matter how bad the network they are on, it is advised to use port 443 when possible, as it looks the most like HTTPS.</p>
-    <p>Extra care must be taken in updating "public-key-pins-sha-256" similar to that which is required of HPKP and DANE, summarized here, you MUST add the new key, wait until at least 2 TTL periods have passed, and only then remove the old key.</p>
+    <p>Extra care must be taken in updating "public-key-pins-sha-256" similar to that which is required of HPKP and DANE, summarized here, you MUST add the new key to the file, continue using the old key until least 2 TTL periods have passed, and only then remove the old key from the file and start using the new key.</p>
     <p>To make connection discovery work in web clients (including those hosted on a different domain) the host service SHOULD set appropriate <link url="https://www.w3.org/TR/cors/">CORS</link> headers for Web Host Metadata files. The exact headers and values are out of scope of this document but may include: <em>Access-Control-Allow-Origin</em>, <em>Access-Control-Allow-Methods</em> and <em>Access-Control-Allow-Headers</em>.</p>
     <p>Due care has to be exercised in limiting the scope of <em>Access-Control-Allow-Origin</em> response header to Web Host Metadata files only.</p>
     <code caption="Example header allowing all sites to read host metadata"><![CDATA[
@@ -250,7 +250,7 @@ Access-Control-Allow-Origin: *
   
 <section1 topic='Security Considerations' anchor='security'>
   <p>It should be noted this allows your web host to hijack your XMPP connection, but that's actually been true for quite some time, they could already bypass the need for a certificate with POSH, or get one from LetsEncrypt if you didn't have the proper CAA records, or hijack it for websocket/bosh supporting clients, so this doesn't really open up new avenues of attack.</p>
-  <p>Please refer to the security considerations and warnings of &rfc7469; with regards to having a backup public key and being careful to not break your domain for the whole TTL</p>
+  <p>Please refer to the security considerations and warnings of &rfc7469; with regards to having a backup public key and being careful to not break your domain for the whole TTL. For this reason and others it is advised to put a max limit on TTL of 1 week (604800).</p>
   <p>Validating certs is full of edge cases and must be done with the utmost of care and precision.</p>
 </section1>