doc: minor edit

src/vdp_pesi.vcc

@@ -54,7 +54,7 @@ Includes (ESI). The VDP implements content composition in client
 responses as specified by ``<esi>`` directives in the response body,
 just as Varnish does with its `standard ESI processing`_. While
 standard Varnish processes ESI subrequests serially, in the order in
-which the ``<esi>`` directives appear in the response, the VDP
+which the ``<esi>`` directives appear in the response, the pesi VDP
 executes the subrequests in parallel. This can lead to a significant
 reduction in latency for the complete response, if Varnish has to wait
 for backend fetches for more than one of the included requests.
@@ -63,7 +63,7 @@ Backend applications that use ESI includes for standard Varnish can be
 expected to work without changes with the VDP, provided that they do
 not depend on assumptions about the serialization of ESI subrequests.
 Serial ESI requests are processed in a predictable order, one after
-the other, but the VDP executes them at roughly the same time. A
+the other, but the pesi VDP executes them at roughly the same time. A
 backend may conceivably receive a request forwarded for the second
 include in a response before the first one. If the logic of ESI
 composition in a standard Varnish deployment does not depend on the
@@ -99,10 +99,10 @@ logic in VCL::
 
 But see below for restrictions on the use of ``pesi.activate()``.
 
-All of the computing resources used by the VDP -- threads, storage,
+All of the computing resources used by the pesi VDP -- threads, storage,
 workspace, locks, and so on -- can be configured, either with Varnish
 runtime parameters or configuration settings made available by the
-VDP. And their usage can be monitored with Varnish statistics. So you
+pesi VDP. And their usage can be monitored with Varnish statistics. So you
 can limit resource usage, and use monitoring tools such as
 `varnishstat(1)`_ to ensure efficient parallel ESI processing. For
 details see `CONFIGURATION AND MONITORING`_ below.
@@ -223,9 +223,9 @@ It is strongly recommended to *not* use serial mode from ESI level 0
 parallel ESI threads.
 
 Serial mode may sensibly be used to reduce overhead and the number of
-threads required without relevant drawbacks:
+threads required without relevant drawbacks
 
-* at ESI level > 0
+* at ESI level > 0 _and_
 
 * when the VCL author knows that all objects included by the current
   request are cacheable, and thus are highly likely to lead to cache