Spelling corrections.

doc/scripting/index.rst

@@ -581,7 +581,7 @@ While actions like the ``Notice::ACTION_EMAIL`` action have appeal for quick ale
    :linenos:
    :lines: 59-62
 
-In the ``expiring-certs.bro`` script which identifies when SSL certificates are set to expire and raises notices when it crosses a pre-defined threshold, the call to ``NOTICE()`` above also sets the ``$identfier`` entry by concatenating the responder ip, port, and the hash of the certificate.  The selection of responder ip, port and certificate hash fits perfectly into an appropriate identifier as it creates a unique identifier with which the suppression can be matched.  Were we to take out any of the entities used for the identifier, for example the certificate hash, we could be setting our suppression too broadly, causing an analyst to miss a notice that should have been raised.  Depending on the available data for the identifier, it can be useful to set the ``$suppress_for`` variable as well.  The ``expiring-certs.bro`` script sets ``$suppress_for`` to ``1day``, telling the Notice Framework to suppress the notice for 24 hours after the first notice is raised.  Once that time limit has passed, another notice can be raised which will again set the ``1day`` suppression time.   Suppressing for a specific amount of time has benefits beyond simply not filling up an analyst's email inbox; keeping the notice alerts timely and succinct helps avoid a case where an analyst might see the notice and, due to over exposure, ignore it.  
+In the ``expiring-certs.bro`` script which identifies when SSL certificates are set to expire and raises notices when it crosses a pre-defined threshold, the call to ``NOTICE()`` above also sets the ``$identifier`` entry by concatenating the responder ip, port, and the hash of the certificate.  The selection of responder ip, port and certificate hash fits perfectly into an appropriate identifier as it creates a unique identifier with which the suppression can be matched.  Were we to take out any of the entities used for the identifier, for example the certificate hash, we could be setting our suppression too broadly, causing an analyst to miss a notice that should have been raised.  Depending on the available data for the identifier, it can be useful to set the ``$suppress_for`` variable as well.  The ``expiring-certs.bro`` script sets ``$suppress_for`` to ``1day``, telling the Notice Framework to suppress the notice for 24 hours after the first notice is raised.  Once that time limit has passed, another notice can be raised which will again set the ``1day`` suppression time.   Suppressing for a specific amount of time has benefits beyond simply not filling up an analyst's email inbox; keeping the notice alerts timely and succinct helps avoid a case where an analyst might see the notice and, due to over exposure, ignore it.  
 
 The ``$suppress_for`` variable can also be altered in a ``Notice::policy`` hook, allowing a deployment to better suit the environment in which it is be run.  Using the example of ``expiring-certs.bro``, we can write a ``Notice::policy`` hook for ``SSL::Certificate_Expires_Soon`` to configure the ``$suppress_for`` variable to a shorter time.  
 
@@ -590,7 +590,7 @@ The ``$suppress_for`` variable can also be altered in a ``Notice::policy`` hook,
    :linenos:
    :lines: 6-12
 
-While ``Notice::policy`` hooks allow you to build custom predicate-based policies for a deployment, there are bound to be times where you don't require the full expressiveness that a hook allows.  In short, there will be notice policy considerations where a broad decision can be made based on the ``Notice::Type`` alone.  To facilitate these types of decisions, the Notice Framework supports Notice Policy shortcuts.  These shortcuts are implemented through the means of a group of data structures that map specific, pre-defined details and actions to the effective name of a notice.  Primarily implemented as a set or table of enumerables of ``Notice::Type``, Notice Policy shortcuts can be placed as a single directive in your ``local.bro`` file as a conscise readable configuration.  As these variables are all constants, it bears mentioning that these variables are all set at parsetime before Bro is fully up and running and not set dynamically.
+While ``Notice::policy`` hooks allow you to build custom predicate-based policies for a deployment, there are bound to be times where you don't require the full expressiveness that a hook allows.  In short, there will be notice policy considerations where a broad decision can be made based on the ``Notice::Type`` alone.  To facilitate these types of decisions, the Notice Framework supports Notice Policy shortcuts.  These shortcuts are implemented through the means of a group of data structures that map specific, pre-defined details and actions to the effective name of a notice.  Primarily implemented as a set or table of enumerables of ``Notice::Type``, Notice Policy shortcuts can be placed as a single directive in your ``local.bro`` file as a concise readable configuration.  As these variables are all constants, it bears mentioning that these variables are all set at parsetime before Bro is fully up and running and not set dynamically.
 
 +------------------------------------+-----------------------------------------------------+-------------------------------------+
 | Name                               | Description                                         | Data Type                           |