diff --git a/keps/0017-pipe-tasks.md b/keps/0017-pipe-tasks.md
index 12f508fe2..49e8d1e0b 100644
--- a/keps/0017-pipe-tasks.md
+++ b/keps/0017-pipe-tasks.md
@@ -57,7 +57,7 @@ tasks:
         key: {{.Pipes.Certificate}}
 ``` 
 
-`containerSpec` field is described in detail below. `pipe` field defines how the produced file will be stored and referenced. The key `{{.Pipes.Certificate}}` value will be generated by KUDO to avoid collisions and to make sure that it is not used before the file is generated. In the above example we would generate a secret name like `instance-myapp.deploy.bootstrap.gencert.pipes.certificate-#hash` to capture instance name along with plan/phase/step/task of the secret origin and the hash of its content. KUDO would use this hash to avoid recreating secrets for unchanged files on a plan rerun. We would also use labels ensuring that the secret is cleaned up when the corresponding Instance is removed. Note that pipe tasks can only have one resource in the `resources` list.
+`containerSpec` field is described in detail below. `pipe` field defines how the produced file will be stored and referenced. The key `{{.Pipes.Certificate}}` value will be generated by KUDO to avoid collisions and to make sure that it is not used before the file is generated. In the above example we would generate a secret name like `instance-myapp.deploy.bootstrap.gencert.pipes.certificate-#hash` to capture instance name along with plan/phase/step/task of the secret origin and the hash of its content. KUDO would use this hash to avoid recreating secrets for unchanged files on a plan rerun. We would also use labels ensuring that the secret is cleaned up when the corresponding Instance is removed. 
 
 The corresponding `gencert` task can be used as usual in e.g.:
 ```yaml
@@ -73,7 +73,7 @@ plans:
            - gencert
 ```
 
-Note that piped files has to be generated before they can be used. In the example above, `bootstrap` phase has a strategy `serial` so that certificate generated in the `gencert` step can be used in subsequent steps. Or stated differently resources can not reference piped files generated within the same step or within a parallel series of steps. 
+Note that piped files has to be generated before they can be used. In the example above, `bootstrap` phase has a strategy `serial` so that certificate generated in the `gencert` step can be used in subsequent steps. Or stated differently resources can not reference piped secrets/configmaps generated within the same step or within a parallel series of steps (it has to be a different step in the phase with serial strategy or a different phase). 
 
 For the pipe task `containerSpec`, we allow a [ContainerSpec](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/#container-v1-core) to be specified. Reasons for that are explained below in the implementation details. The ContainerSpec has to define a shared volume where the files are stored.
 
@@ -170,4 +170,4 @@ An alternative approach would use the provided ContainerSpec as the main contain
 - Once the main container exits, it would copy the referenced files and store them as specified
 - We would use `restartPolicy: Never/OnFailure` to prevent the main container from restarting
 
-While this approach would allow users to specify complete Pods as pipe task resources, a sidecar implementation would be an additional source of complexity and failure potential. The best code is no code at all.
\ No newline at end of file
+While this approach would allow users to specify complete Pods as pipe task resources, a sidecar implementation would be an additional source of complexity and failure potential. The best code is no code at all.