The introduction section of the Quantum API states: "The v2.0 API does this by introducing a new entity, called a Subnet. Subnets can represent either a IPv4 or IPv6 address block, ..."
This text should be corrected in the following way:
The introduction section of the Quantum API states: "The v2.0 API does this by introducing a new entity, called a Subnet. Subnets can represent the binding of either a IPv4 or IPv6 address block to a previously created Quantum Network, ..."
Proof Point: The High-Level flow is flawed, as it states that a subnet gets associated with a network, however, there is no API "associate Subnet", only an API "create Subnet, which associates (binds) a CIDR to a network. Therefore, the nature of the object "subnet" is not correctly reflected in the definitions. While this may sound like a minor negligence in the introductory text, this could lead to high cost as this object is so central in the data model. Some implementers may be mislead to believe, that a subnet can indeed exists without binding to a previsouly created network, i.e. that an address range already constitutes a subnet.
Here is the current text describing the high level flow
• Tenant creates a network (e.g., "net1")
• Tenant associates a subnet with that network (e.g., "10.0.0.0/24")
Here is a proposal to correct this text and bring it inline with the API "create subnet":
• Tenant creates a network (e.g., "net1")
• Tenant creates a subnet (e.g., "10.0.0.0/24"), which implicitly associates the address space with that network. This association creates a binding of the adress space to the previously created network. While it is common to say, that a subnet is represented by an IPv4 or IPv6 address range, the adress range alone is not a subnet. Rather it is the binding of the address space to the network, which creates the subnet.
This text is in the and not a manual.