Re: [alto] Resume Discussion about the Remaining Issue of draft-ietf-alto-unified-props

[Jensen Zhang <[e-mail]>]

Hi Sabine,

Thanks for resuming the issue. We surely need to wrap up the unified
properties draft. Let me see if I understand your proposal.

In your description, it seems that "consistent", "compatible" and "directly
mapped" are the same thing. All of them just infer that the entities in the
entity domain MUST appear in the dependent resource directly, either as the
mapping key or as the mapping value. But I have the following questions for
this rule:

1. For the "pid-property-map" example, if we only consider the
"entity-domains" but ignore the "properties", why the "default-network-map"
is a necessary dependency for the entity domains [ "ipv4", "ipv6" ]?

2. Even if following your rule, I think it is still hard for the client to
interpret the property map correctly. Let's take your second example
"filtered-cdnifci-pid-property-map" to explain the issue. How the client
know the "my-default-network-map" will map something to pid and the
"my-default-cdnifci-map" will map something to cdni-fci-capabilities? How
can the client know the first dependent resource is
"application/alto-networkmap+json" type and the second one is
"application/alto-cdnifcimap+json" type?

3. And if only follow your rule, the empty "uses" member is always valid.
Is it expected?

4. If two domain entities or domain-specific properties depend on different
types of resources, why we need to provide them in a single property map?
For the "filtered-cdnifci-pid-property-map" example, maybe splitting it
into the following two property maps will make the client easier to
interpret them.

"filtered-cdnifci-property-map" : {

                "uri" : "http://alto.example.com/propmap/lookup/cdnifci
<http://alto.example.com/propmap/lookup/cdnifci-pid>",

                "media-type" : "application/alto-propmap+json",

                "accepts" : "application/alto-propmapparams+json",

                "uses" : [ "my-default-cdnifci-map" ]

                "capabilities" : {

                               "entity-domain-types" : [ "ipv4", "ipv6" ],

                               "prop-types" : [ "cdni-fci-capabilities" ]

                }

},

"filtered-pid-property-map" : {

                "uri" : "http://alto.example.com/propmap/lookup/pid
<http://alto.example.com/propmap/lookup/cdnifci-pid>",

                "media-type" : "application/alto-propmap+json",

                "accepts" : "application/alto-propmapparams+json",

                "uses" : [ "my-default-network-map" ]

                "capabilities" : {

                               "entity-domain-types" : [ "ipv4", "ipv6" ],

                               "prop-types" : [ "pid" ]

                }

}

So far, I have two proposals to make things easier:

1. We need some rule to make sure the client can infer the type of the
dependent resource from the "entity-domains" and "properties" of a property
map. It means each pair of entity-domain and property has fixed dependent
resource types.

2. Only the entity-domain property pairs depending on the same types of
resources can be provided in the same property map.

Do you think they are reasonable?

Thanks,
Jensen

On Tue, Nov 20, 2018 at 11:22 AM Randriamasy, Sabine (Nokia -
FR/Paris-Saclay) <[e-mail]> wrote:

> Hi Jensen and all,
>
>
>
> Resuming on the resources dependency issue, to ensure consistency of the
> "uses" member of an IRD information resource,
> [draft-ietf-alto-unified-props-new] should have a rule to guide the
> composition of resources WRT "used" resources. Would the design below
> address this ?
>
>
>
> Thanks,
>
> Sabine
>
>
>
> --------------------------------------------------------
>
>
>
> Section: Ensuring compatibility of used resources with entity domain
> types:
>
>
>
> A Client Looking at a property map resource will interpret all the
> properties listed in the "prop-types" member as available for entities in
> all of the domains listed in "domain-types". Therefore, the "uses" member
> of a property map information resource must be consistent with its
> "entity-domain-types" member.
>
>
>
> This means that each of the resources listed in the "uses" member of an
> information resource is compatible with all the elements listed in its
> "entity-domain-types" member. Where a used resource is defined as
> compatible with the "entity-domain-types" of an information resource it
> provides information that can be directly mapped with all members of its
> "entity-domain-types" field.
>
>
>
> This can be ensured by the following rule: each resource of the "uses"
> field of a property map resource MUST provide information that can be
> directly mapped with entities of all the members of its
> "entity-domain-types" field.
>
>
>
> --- Example of consistent "uses" member
>
> In the example IRD shown section 7.3 of
> https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-04:
>
> - resource "pid-property-map" uses "default-network-map" and provides
> information for "entity-domain-types" : [ "ipv4", "ipv6" ],
>
> - resource "location-property-map" uses "default-network-map" and provides
> information for "entity-domain-types" : [ "pid" ].
>
>
>
> "default-network-map" maps a PID with sets of ipv4 ot ipv6 addresses. So,
> for both information resources, there is a direct mapping between
> information in the "default-network-map" and entities in all of their
> domain types, resp. ["ipv4", "ipv6"] for the former and "pid" for the
> latter. Thus the used resource "default-network-map" is compatible with all
> of their "entity-domain-types".
>
>
>
> --- Example of composition of property map resources w.r.t. "used"
> resources
>
>
>
> If a Server wants to expose "cdni-fci-capabilities" and "pid" properties
> for entities in the "ipv4", "ipv6", "countrycode" and "asn" entity domains,
> because PIDs cannot be directly mapped to entities in the "countrycode" and
> "asn" domains, it may compose its IRD information resources as follows:
>
>
>
> "filtered-cdnifci-property-map" : {
>
>                 "uri" : "http://alto.example.com/propmap/filtered/cdnifci
> ",
>
>                 "media-type" : "application/alto-propmap+json",
>
>                 "accepts" : "application/alto-propmapparams+json",
>
>                 "uses" : [ "my-default-cdnifci-map" ]
>
>                 "capabilities" : {
>
>                                "entity-domain-types" : [ "ipv4", "ipv6",
> "countrycode", "asn" ],
>
>                                "prop-types" : [ "cdni-fci-capabilities" ]
>
>                 }
>
> },
>
> "filtered-cdnifci-pid-property-map" : {
>
>                 "uri" : "
> http://alto.example.com/propmap/lookup/cdnifci-pid",
>
>                 "media-type" : "application/alto-propmap+json",
>
>                 "accepts" : "application/alto-propmapparams+json",
>
>                 "uses" : [ "my-default-network-map",
> "my-default-cdnifci-map" ]
>
>                 "capabilities" : {
>
>                                "entity-domain-types" : [ "ipv4", "ipv6" ],
>
>                                "prop-types" : [ "cdni-fci-capabilities",
> "pid" ]
>
>                 }
>
> }
>
>
>
>
>
> *From:* alto <[e-mail]> *On Behalf Of *Randriamasy, Sabine
> (Nokia - FR/Paris-Saclay)
> *Sent:* Friday, November 02, 2018 9:48 PM
> *To:* Jensen Zhang <[e-mail]>
>
>
> *Cc:* IETF ALTO <[e-mail]>
> *Subject:* Re: [alto] Resume Discussion about the Remaining Issue of
> draft-ietf-alto-unified-props
>
>
>
> Hi Jensen,
>
>
>
> Thanks for bringing the [draft-ietf-alto-cdni-request-routing-alto-03]
> example that actually does have a case with 2 used resources and the
> ambiguity problem you are pointing.
>
> I would actually also like the insight of the CDNI draft authors on my
> answer.
>
> (In the examples, I corrected some typos with Upper Case letters).
>
>
>
> Thanks, please see below.
>
> Sabine
>
>
>
> [draft-ietf-alto-cdni-request-routing-alto-03] provides an example
> filtered property map transaction in section 6.2.3:
>
>
>
> The request contains:
>
> POST /propmap/lookup/cdnifci-pid HTTP/1.1
>
> ...
>
> {
>
> "entities": [
>
>                 "ipv4:192.0.2.0/24",
>
>                 "ipv6:2001:db8::/32"
>
> ],
>
> "properties": [ "cdni-fci-capabilities", "pid" ]
>
> }
>
>
>
> The response contains in its "meta":
>
> ...
>
> "dependent-vtags": [
>
>                 {"resource-id": "my-default-cdnifci-map",
>
>                 "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"},
>
>                 {"resource-id": "my-default-networkmap",
>
>                 "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf63"}
>
> ]
>
> ...
>
> and provides values for both properties "cdni-fci-capabilities" and "pid".
>
>
>
> The request is fine because these 2 properties can be defined on entities
> in the requested domains ipv4 and ipv6.
>
> However, the corresponding information resource at "uri"
> ./propmap/lookup/cdnifci-pid is specified in the example IRD section 3.7.1
> as:
>
>
>
> "filtered-cdnifci-property-map"
>
> with
>
> "capabilities" : {
>
>                 "domain-types" : [ "ipv4", "ipv6", "couNtrycode", "asn" ],
>
>                 "prop-types" : [ "cdni-fci-capabilities", "pid" ]
>
> }
>
>
>
> The "uses" member is missing but the response in the example transaction
> hints that they are the 2 maps listed in the example response.
>
> The problem with the capabilities of "filtered-cdnifci-property-map" is
> that one understands that for instance a "pid" property can be defined on
> entities in the "couNtrycode" and "asn" domains, which is not possible.
>
>
>
> Therefore, a way to avoid this ambiguity would be to decompose resource
> "filtered-cdnifci-property-map" W.R.T. so to say compatible "used"
> resources as follows:
>
>
>
> "filtered-cdnifci-property-map" : {
>
>                 "uri" : "http://alto.example.com/propmap/filtered/cdnifci
> ",
>
>                 "media-type" : "application/alto-propmap+json",
>
>                 "accepts" : "application/alto-propmapparams+json",
>
>                 "uses" : [ "my-default-cdnifci-map" ]
>
>                 "capabilities" : {
>
>                                "ENTITY-domain-types" : [ "ipv4", "ipv6",
> "couNtrycode", "asn" ],
>
>                                "prop-types" : [ "cdni-fci-capabilities" ]
>
>                 }
>
> },
>
> "filtered-cdnifci-property-map" : {
>
>                 "uri" : "
> http://alto.example.com/propmap/lookup/cdnifci-pid",
>
>                 "media-type" : "application/alto-propmap+json",
>
>                 "accEPts" : "application/alto-propmapparams+json",
>
>                 "uses" : [ "my-default-network-map",
> "my-default-cdnifci-map" ]
>
>                 "capabilities" : {
>
>                                "ENTITY-domain-types" : [ "ipv4", "ipv6" ],
>
>                                "prop-types" : [ "cdni-fci-capabilities",
> "pid" ]
>
>                 }
>
> },
>
>
>
> And [draft-ietf-alto-unified-props-new] should have a rule to guide the
> composition of resources WRT "used" resources and that would look like:
>
>
>
> "Each of the resources listed in the "uses" member of an information
> resource MUST be compatible with all the elements listed in its
> "entity-domain-types" member. Where a "used" resource is defined as
> compatible if it provides information that can be mapped to all the listed
> entity domain types."
>
>
>
> For example in the IRD section 7.3 of [draft-ietf-alto-unified-props-new]:
>
> - resources "pid-property-map" and "location-property-map" both use
> "default-network-map" which provides information mapped to
> "entity-domain-types" "ipv4", "ipv6" in the former and "pid" in the latter.
>
>
>
> *From:* Jensen Zhang <[e-mail]>
> *Sent:* Wednesday, October 24, 2018 1:12 PM
> *To:* Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <
> [e-mail]>
> *Cc:* IETF ALTO <[e-mail]>
> *Subject:* Re: [alto] Resume Discussion about the Remaining Issue of
> draft-ietf-alto-unified-props
>
>
>
> Hi Sabine,
>
>
>
> Thanks for your feedback. See my comments inline.
>
>
>
> On Thu, Oct 18, 2018 at 1:21 AM Randriamasy, Sabine (Nokia -
> FR/Paris-Saclay) <[e-mail]> wrote:
>
> Hi Jensen,
>
>
>
> Regarding the second point on an unambiguous way to associate a property
> map and the information resource it uses, I may have missed something and
> have a question on your example:
>
>
>
> "uses": ["networkmap1", "pv-costmap1"],
>
> "capabilities": {
>
>   "entity-domains": ["ipv4", "ipv6", "ane"],
>
>   "properties": ["pid"]
>
> }
>
>
>
> Independently of the “uses” member, just looking at the capabilities, I
> understand this as:
>
> Client can in particular request the “pid” property of an entity in the
> “ane” domain.
>
> Which by the way assumes no entity is a link with endpoints in different
> PIDs.
>
> As a PIDs is defined in RFC7285 section 5.1 as a set of endpoint
> addresses, does this document extend this set to entity addresses?
>
>
>
> Good point. Although we can consider to extend the semantics of PIDs, it
> is not what this document wants. It is my fault. I took a bad example.
>
>
>
>
>
> The initial design of this extension was to solve ambiguities by having
> one “used” resource per property map, thus “splitting” property maps w.r.t.
> “used” maps, see v00 section 2.6 : “Instead of defining the dependency by
> qualifying the property name, this document attaches the dependency to the
> property map as a whole. Thus all properties in a given property map depend
> on the same resource."
>
>
>
> Would you have a concrete example where retrieving a property on  entities
> in a domain requires to both know a network map and a cost-map?
>
>
>
> Now I understand your concern. I agree that we need a reasonable example.
> I want to take an example to show that one property on entities in a domain
> may depend on more than one ALTO resources. But based on our existing
> standard drafts, we do not have a reasonable example so far.
>
>
>
> But I do think it is necessary to revise the draft to support this. Even
> there is no existing standard example requiring multiple dependencies, it
> is still possible to happen in the future. If we don't want to make the
> draft obsolete very soon, we need to take care. And actually, I find the
> cdni footprint property map proposed in
> draft-ietf-alto-cdni-request-routing-alto may be a reasonable example.
>
>
>
> Before we discuss the property map example, let's clarify one basic
> concept: property
>
>
>
> Without the context of the entity domain, the concept "property" cannot be
> understood. So in this document, we shouldn't use the term "property"
> independently.
>
>
>
> For example,
>
>
>
> the pid property - Invalid
>
> the pid property of the entity in ipv4 domain - Valid
>
> the pid property of the ipv4 entity - Valid
>
>
>
> So the statement "all properties in a given property map depend on the
> same resource" is not invalid. We should revise it as "all properties of
> any entities in a given property map ..."
>
>
>
> Now we see the example of the fci footprint property map. From
> draft-ietf-alto-cdni-request-routing-alto, an ALTO server can provide the
> "cdni-fci-capabilities" property for the cdni footprint entities. In the
> same property map, the "cdni-fci-capabilities" property values of the cdni
> footprint entities should depend on the same cdni-fci-map.
>
>
>
> But there is no entity domain called "cdni footprint". From RFC8006, the
> cdni footprint can be ipv4cidr, ipv6cidr, asn and countrycode. As ALTO can
> provides the PID entity to express a set of ipv4cidr and ipv6cidr, we can
> leverage it. So we can consider the following cdni footprint property map
> resource:
>
>
>
> "cdnifci-prop-map": {
>
>   "uri": "http://alto.example.com/propmap/full/cdnifci",
>
>   "media-type": "application/alto-propmap+json",
>
>   "capabilities": {
>
>     "entity-domains": ["pid"],
>
>     "properties": ["cdni-fci-capabilities"]
>
>   },
>
>   "uses": [...]
>
> }
>
>
>
> What the "uses" of this property map should be? The client should have a
> network-map to understand what a PID entity is. Then the client should have
> a cdni-fci-map to understand what the cdni-fci-capabilities of a PID entity
> is. So to interpret this property map, the client requires two ALTO
> resources.
>
>
>
> I believe it is not a special case. In the future, we may have another
> property map for the entity-domain "A" and the property "P". The entity in
> domain A depends on the resource R1, and the property P of the entity in
> domain A depends on the resource R2. So finally, the property P of the
> entity in domain A depends on R1 and R2.
>
>
>
> Do you think it is reasonable?
>
>
>
> Best,
>
> Jensen
>
>
>
>
>
> Thanks,
>
> Sabine
>
>
>
>
>
> *From:* alto <[e-mail]> *On Behalf Of *Jensen Zhang
> *Sent:* Wednesday, September 26, 2018 3:15 PM
> *To:* IETF ALTO <[e-mail]>
> *Subject:* [alto] Resume Discussion about the Remaining Issue of
> draft-ietf-alto-unified-props
>
>
>
> Hi ALTOer,
>
>
>
> During IETF 102, we agree that the unified properties draft is important
> and need to be processed first.. From the update which we presented at IETF
> 102, the latest draft has been almost stable. But there are still two
> unclear points in the previous revisions:
>
>
>
> 1. The response of filtered property map query for address blocks.
>
> 2. The resource dependencies declaration.
>
>
>
> For the first point, we presented the issue and the potential solution
> during IETF 102 (p12-p13 of
> https://datatracker.ietf.org/meeting/102/materials/slides-102-alto-alto-unified-properties-00.pdf).
> The proposed solution should be reasonable. The authors are updating the
> draft and including it.
>
>
>
> But for the second point, we have not figured out a reasonable solution.
> So I want to involve all of the related people to discuss this part.
>
>
>
> Briefly, the second point is unclear because the "uses" attribute of a
> unified property resource may have ambiguity from the current
> specification. We take a simple example to show the ambiguity:
>
>
>
> "uses": ["networkmap1", "pv-costmap1"],
>
> "capabilities": {
>
>   "entity-domains": ["ipv4", "ipv6", "ane"],
>
>   "properties": ["pid"]
>
> }
>
>
>
> Based on the current draft, the "uses" attribute is "An array with the
> resource ID(s) of resource(s) with which the entity domains in this map are
> associated", the client can have several different understandings in this
> example: (1) all the entities in this property map depend on networkmap1 or
> pv-costmap1; (2) entities in ipv4 and ipv6 domain depend on networkmap1,
> and entities in ane domain depend on pv-costmap1; (3) entities in ipv4
> domain depend on networkmap1, entities in ipv6 domain depend on
> pv-costmap1, entities in ane domain have no dependency. (4) ...
>
>
>
> But all those understandings are not correct. The understanding the server
> expects should be: the PID property values of all entities in this map
> depend on networkmap1; the entities in ane domain depend on pv-costmap1.
>
>
>
> To make the client can understand the resource dependencies of a property
> map correctly, we should modify the specification of its "uses" attribute.
> I have two proposals:
>
>
>
> 1. Each combination of "entity-domain" and "property" SHOULD specify its
> dependent resource type explicitly. For example, <ipv4, pid> or <ipv6, pid>
> depends on a network map; <ane, pid> depends on a network map and a cost
> map.
>
> 2. Each combination of "entity-domain" and "property" SHOULD specify how
> to use the dependent resources to interpret this combination. For example,
> for <pid4, pid>, the dependent network map is used to validate and
> interpret the pid property values; for <ane, pid>, the dependent cost map
> is used to validate and interpret the entities in ane domain, and the
> dependent network map is used to validate and interpret the pid property
> values.
>
>
>
> If we agree on these two proposals, they will be required for all the
> registered ALTO Entity Domains and ALTO Properties, and the future ones. It
> may be a critical change but may be necessary..
>
>
>
> Do we have any better solution to make the resource dependency declaration
> clear? I will appreciate people sharing thoughts..
>
>
>
> Best regards,
>
> Jensen
>
>