Bug #97337 for AnyEvent-SNMP: Typos in POD

I just noticed some typos while reading the documentation. It would be nice to see them fixed, patch is attached. Thank you :)

? SNMP.pm.diff Index: SNMP.pm =================================================================== RCS file: /schmorpforge/AnyEvent-SNMP/SNMP.pm,v retrieving revision 1.12 diff -u -r1.12 SNMP.pm --- SNMP.pm 15 Apr 2012 11:02:07 -0000 1.12 +++ SNMP.pm 18 Jul 2014 14:22:33 -0000 @@ -34,14 +34,14 @@ and memory usage. Most AnyEvent backends (including the pure-perl backend) fare much better than the Net::SNMP dispatcher. -Another major added fetaure of this module over Net::SNMP is automatic +Another major added feature of this module over Net::SNMP is automatic rate-adjustments: Net::SNMP is so slow that firing a few thousand requests can cause many timeouts simply because Net::SNMP cannot process the replies in time. This module automatically adapts the send rate to avoid false timeouts caused by slow reply processing. A potential disadvantage of this module is that replacing the dispatcher -is not at all a documented thing to do, so future changes in Net::SNP +is not at all a documented thing to do, so future changes in Net::SNMP might break this module (or the many similar ones). This module does not export anything and does not require you to do @@ -71,7 +71,7 @@ To avoid this, you can (and should) limit the number of outstanding requests to a number low enough so that parsing time doesn't introduce -noticable delays. +noticeable delays. Unfortunately, this number depends not only on processing speed and load of the machine running Net::SNMP, but also on the network latency and the @@ -82,7 +82,7 @@ Increasing C<$MAX_OUTSTANDING> will not automatically use the extra request slots. To increase C<$MAX_OUTSTANDING> and make -C<AnyEvent::SNMP> make use of the extra paralellity, call +C<AnyEvent::SNMP> make use of the extra parallelity, call C<AnyEvent::SNMP::set_max_outstanding> with the new value, e.g.: AnyEvent::SNMP::set_max_outstanding 500; @@ -105,10 +105,10 @@ it increases $MAX_OUTSTANDING. This has the result of adjusting the number of outstanding requests so that -the recv queue is between the minimum and maximu, usually. +the recv queue is between the minimum and maximum, usually. This algorithm works reasonably well as long as the responses, response -latencies and processing times are the same size per packet on average. +latencies and processing times are the same per packet on average. =back