updates.

diff --git a/doc/draft-riikonen-silc-spec-07.nroff b/doc/draft-riikonen-silc-spec-07.nroff
index 48e3accf853b8447e84b20c7d7df08947f35bbee..4aaf34806a10e091c7c087ed082f0fba6e70abe9 100644 (file)
--- a/doc/draft-riikonen-silc-spec-07.nroff
+++ b/doc/draft-riikonen-silc-spec-07.nroff
@@ -2396,15 +2396,15 @@ keys generated by the servers to secure the messages.  This is
 intentional design feature to allow ease of use for end user.  This way
 the network is still usable, and remains encrypted even if the external
 means of distributing the keys is not working.  The implementation,
-however, may like to not follow this design feature, and always negotiate
-the keys outside SILC network.  This is acceptable solution and many times
-recommended.  The implementation still must be able to work with the
-server generated keys.
+however, may like to not follow this design feature, and may always
+negotiate the keys outside SILC network.  This is acceptable solution and
+many times recommended.  The implementation still must be able to work
+with the server generated keys.
 
 If this is unacceptable for the client or end user, the private keys
 negotiated outside the SILC Network should always be used.  In the end
-it is always implementor's choice whether to negotiate private keys by
-default or whether to use the keys generated by the servers.
+it is implementor's choice whether to negotiate private keys by default or
+whether to use the keys generated by the servers.
 
 It is also recommended that router operators in the SILC Network would
 form a joint forum to discuss the router and SILC Network management