Remove the apostrophe 's from plural acronyms

This is to be consistent with our common usage of just using a
plural "s" without apostrophe.

This was brought up via discussion in ticket 37505.

I didn't have this reviewed.

diff --git a/bin/dnssec/dnssec-dsfromkey.docbook b/bin/dnssec/dnssec-dsfromkey.docbook
index 9473e4fecf1658e34aaa0fba0c6349c08255b4b8..08175baf26e5bd02a9e856a7a1ef3d04a7925aa7 100644 (file)
--- a/bin/dnssec/dnssec-dsfromkey.docbook
+++ b/bin/dnssec/dnssec-dsfromkey.docbook
@@ -167,7 +167,7 @@
         <term>-A</term>
         <listitem>
           <para>
-            Include ZSK's when generating DS records.  Without this option,
+            Include ZSKs when generating DS records.  Without this option,
             only keys which have the KSK flag set will be converted to DS
             records and printed.  Useful only in zone file mode. 
           </para>

diff --git a/bin/dnssec/dnssec-keygen.docbook b/bin/dnssec/dnssec-keygen.docbook
index cab897487415256e4a7aff9b6146f09c35cb7713..ec0d5a352c32e9cbfd46e0be9d9a1d5046c78797 100644 (file)
--- a/bin/dnssec/dnssec-keygen.docbook
+++ b/bin/dnssec/dnssec-keygen.docbook
@@ -158,7 +158,7 @@
           <para>
             The key size does not need to be specified if using a default
             algorithm.  The default key size is 1024 bits for zone signing
-            keys (ZSK's) and 2048 bits for key signing keys (KSK's,
+            keys (ZSKs) and 2048 bits for key signing keys (KSKs,
             generated with <option>-f KSK</option>).  However, if an
             algorithm is explicitly specified with the <option>-a</option>,
             then there is no default key size, and the <option>-b</option>

diff --git a/bin/rndc/rndc.docbook b/bin/rndc/rndc.docbook
index 1ab0417274f4cb5c7d0d5047dc5b4b6a21c53dcd..ace6f11651741c2d58ad1a09b64fcbc7358d962f 100644 (file)
--- a/bin/rndc/rndc.docbook
+++ b/bin/rndc/rndc.docbook
@@ -620,7 +620,7 @@
             abort the DNSSEC validation process and treat the data as
             insecure rather than bogus.  This continues until the
             NTA's lifetime is elapsed, or until the server is
-            restarted (NTA's do not persist across restarts).
+            restarted (NTAs do not persist across restarts).
           </para>
           <para>
             An existing NTA can be removed by using the

diff --git a/doc/arm/Bv9ARM-book.xml b/doc/arm/Bv9ARM-book.xml
index 83feb88c9710d812edb5f5dcbb0afa4b3307a53a..1bdf2d3f27b6f831721c95bebcaef0aebf5c6ca0 100644 (file)
--- a/doc/arm/Bv9ARM-book.xml
+++ b/doc/arm/Bv9ARM-book.xml
@@ -5731,7 +5731,7 @@ options {
                  abort the DNSSEC validation process and treat the data as
                  insecure rather than bogus.  This continues until the
                  NTA's lifetime is elapsed, or until the server is
-                 restarted (NTA's do not persist across restarts).
+                 restarted (NTAs do not persist across restarts).
                </para>
                <para>
                  For convenience, TTL-style time unit suffixes can be
@@ -5764,7 +5764,7 @@ options {
                <para>
                  Validity checks can be disabled for an individual
                  NTA by using <command>rndc nta -f</command>, or
-                 for all NTA's by setting <option>nta-recheck</option>
+                 for all NTAs by setting <option>nta-recheck</option>
                  to zero.
                </para>
                <para>

diff --git a/doc/arm/managed-keys.xml b/doc/arm/managed-keys.xml
index 51949487fbb402179cae2731ff5508a826273af5..24f3b19a53a6ac609d6866387bd50264017a4546 100644 (file)
--- a/doc/arm/managed-keys.xml
+++ b/doc/arm/managed-keys.xml
@@ -40,7 +40,7 @@ also in DNSSEC section above here in ARM -->
     <para>To set up an authoritative zone for RFC 5011 trust anchor
     maintenance, generate two (or more) key signing keys (KSKs) for
     the zone. Sign the zone with one of them; this is the "active"
-    KSK. All KSK's which do not sign the zone are "stand-by"
+    KSK. All KSKs which do not sign the zone are "stand-by"
     keys.</para>
     <para>Any validating resolver which is configured to use the
     active KSK as an RFC 5011-managed trust anchor will take note
@@ -82,8 +82,8 @@ $ <userinput>dnssec-signzone -S -K keys example.net</userinput>
     increasing by 128, and wrapping around at 65535. So, for
     example, the key "<filename>Kexample.com.+005+10000</filename>" becomes
     "<filename>Kexample.com.+005+10128</filename>".</para>
-    <para>If two keys have ID's exactly 128 apart, and one is
-    revoked, then the two key ID's will collide, causing several
+    <para>If two keys have IDs exactly 128 apart, and one is
+    revoked, then the two key IDs will collide, causing several
     problems. To prevent this, 
     <command>dnssec-keygen</command> will not generate a new key if
     another key is present which may collide. This checking will
@@ -95,6 +95,6 @@ $ <userinput>dnssec-signzone -S -K keys example.net</userinput>
     multiple directories or on multiple machines.</para>
     <para>It is expected that a future release of BIND 9 will
     address this problem in a different way, by storing revoked
-    keys with their original unrevoked key ID's.</para>
+    keys with their original unrevoked key IDs.</para>
   </sect2>
 </sect1>

diff --git a/doc/arm/pkcs11.xml b/doc/arm/pkcs11.xml
index 9a4c2f4c6c3fb693692cf93b65718ce097dc21af..2708bf8f86dd0e74d4b92c55f1b5b65bf2f9d916 100644 (file)
--- a/doc/arm/pkcs11.xml
+++ b/doc/arm/pkcs11.xml
@@ -64,7 +64,7 @@
       need. The HSM's provider library must have a complete implementation
       of the PKCS#11 API, so that all these functions are accessible. As of
       this writing, only the Thales nShield HSM and the latest development
-      version of SoftHSM can be used in this fashion.  For other HSM's,
+      version of SoftHSM can be used in this fashion.  For other HSMs,
       including the AEP Keyper, Sun SCA 6000 and older versions of SoftHSM,
       use OpenSSL-based PKCS#11. (Note: As more HSMs become capable of
       supporting native PKCS#11, it is expected that OpenSSL-based