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

["Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[e-mail]>]

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?

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?

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