Use 1.1 / 1.1.0 when referring to the current P4Runtime version

docs/v1/P4Runtime-Spec.mdk

@@ -5613,7 +5613,7 @@ field [@ProtoAny]. At the moment, there is not any mechanism to extend the
 `p4.v1.TableEntry` message based on the value of architecture-specific table
 properties, but we may include on in future versions of the API.
 
-# Known limitations of P4Runtime v1.0.0
+# Known Limitations of Current P4Runtime Version
 
 * `FieldMatch`, action `Param`, and controller packet metadata fields only
   support unsigned bitstrings, &ie; values of one of the following types (not

docs/v1/guidance-for-generating-p4info.md

@@ -38,7 +38,7 @@ representing the name of the library, its major version, etc.
 
 ## Handling P4_16 `type` and the `p4runtime_translation` annotation
 
-The P4Runtime v1.0 specification restricts the types that it supports
+The P4Runtime v1.1 specification restricts the types that it supports
 for the following kinds of things:
 
 + table search key fields, defined in the P4Info message in a
@@ -50,17 +50,17 @@ for the following kinds of things:
 + metadata fields in a header sent from data plane to controller, or
   from controller to the data plane, defined in the P4Info message in
   a `Metadata` message (the `type_name` field was added to `Metadata`
-  messages in P4Runtime version 1.0.1).
+  messages in P4Runtime version 1.1.0).
 
 Later in this section, we will use the term "constrained value" for
 brevity, instead of repeating all of the kinds of objects listed
-above.  For such values, the P4Runtime specification v1.0 supports all
+above.  For such values, the P4Runtime specification v1.1 supports all
 of the following types, but currently no others:
 
 + `bit<W>`
 + an `enum` with an underlying type of `bit<W>`, also called a
   serializable `enum` (TBD whether all of the pieces needed to make
-  this work are actually supported for P4Runtime 1.0)
+  this work are actually supported for P4Runtime 1.1)
 + a `typedef` or `type` name that, when "followed back" to the lowest
   base type, is one of the above.  (As of the P4_16 language
   specification version 1.2.0, it is not required to support a `type`
@@ -100,7 +100,7 @@ type_list(x) {
 Note that `type_list(x)` always starts with zero or more `type` names,
 and always ends with one type that is neither a `type` nor `typedef`
 name, e.g. `bit<W>`, a header type, struct type, etc.  It never
-contains the name of a type declared using `typedef`.  P4Runtime v1.0
+contains the name of a type declared using `typedef`.  P4Runtime v1.1
 only supports `p4runtime_translation` annotations on `type`
 definitions.  If any such annotations occur on a `typedef` definition,
 they should be ignored.
@@ -111,7 +111,7 @@ of type names.  In order to create such a cycle, the first `type` or
 type name, and this is not allowed.
 
 If the last type is not `bit<W>` or `enum bit<W>`, that is an error
-for P4Runtime v1.0.  The "base" type must always be one of those for
+for P4Runtime v1.1.  The "base" type must always be one of those for
 every constrained value.