Re: [alto] Final Decision of Unified Properties Design before Moving to WGLC

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

Hi Jensen,

Thanks for your answer. I was just resuming one use case that was motivating the need to disambiguate resource dependencies.

Would it be possible to look at the example where:
- entity = pid:MYPID
- property = FCI.capability10
Property definition depends on FCI map, entity ID depends on a Network map.

And write an example for:
- IRD entry for filtered/unfiltered propmaps,
- example request ,
- Example response

The purpose is to illustrate the problem and collect more WG feedback. Maybe the use case above does not exist but we may want to make sure we don’t miss other cases where both entity ID and property depend on an information resource.
Thanks,
Sabine



From: Jensen Zhang <[e-mail]>
Sent: Thursday, April 11, 2019 6:35 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <[e-mail]>
Cc: IETF ALTO <[e-mail]>; Richard Yang <[e-mail]>
Subject: Re: Final Decision of Unified Properties Design before Moving to WGLC

Hi Sabine,

I remember that is the problem I proposed to motivate the design option 1. But in design option 2, we no longer have this problem. Let me clarify a little bit:

Why a property map requires dependencies? Because the client requires other resources to help it to understand the information on a property map. More specifically, the client wants to understand every key appearing in a property map. Those keys include entity identifiers and property names. Each entity identifier or property name may be defined in another resource (its origin). Without this resource, the client cannot understand the corresponding entity identifier or property name. That is one of the insights of design option 2.

In design option 2, we require the server to explicitly expose the origin of each entity identifier and property name to avoid ambiguity. But we notice that each entity identifier or property name has exactly one origin. I cannot come up with an example where an entity identifier or a property map has more than one origin.

In your PID-FCI example, if FCI capabilities are defined on PIDs, the map would depend on both Network Map and FCI map. But the Network Map is the origin of PIDs, and the FCI map is the origin of FCI capabilities. So each key still has one dependent resource.

I'm not sure if we will have an example where the entity identifier encoding is so complex that the client needs multiple information resources to parse this entity identifier correctly in the future. But so far, I cannot come up with such a real example. If we consider how to handle this, we may take a risk dragging on the overdesign.

Best,
Jensen


On Wed, Apr 10, 2019 at 6:01 AM Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Jensen,

Thanks a lot for the provided examples. It will be indeed be helpful to present a fully fleshed example for the 2 options and the related pros & cons.
That is: example information resource in IRD, example request and response.

My question on option 2 and in general is to see how to handle examples where a property map depends on 2 or more resources.
For example, if FCI capabilities are defined on PIDs, the map would depend on both Network Map and FCI map.
Questions:
- does this example make sense?
- what is the probability of having similar cases of property maps depending on multiple other information resources?

Thanks,
Sabine



From: Jensen Zhang <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, April 09, 2019 4:28 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <[e-mail]<mailto:[e-mail]>>
Cc: IETF ALTO <[e-mail]<mailto:[e-mail]>>; Richard Yang <[e-mail]<mailto:[e-mail]>>
Subject: Final Decision of Unified Properties Design before Moving to WGLC

Hi all,

Authors of the document draft-ietf-alto-unified-props-new had a discussion about the unified properties design last week. We reviewed two design options proposed in IETF 104 and analyzed the pros and cons of both.

For the design option 1, binding resource dependencies to property type, it is easy to process but hard to understand (we spend a lot of time trying to clarify the design).
For the design option 2, binding resource dependencies to each entity and property, it is easy to understand (analogous to the relational database) but hard to specify (e.g., IANA registry). Fortunately, authors already have a proposal about the IANA registry design of design option 2, which requires three new registries for entity domain types, properties, and resource types.

But we still need to make the final decision before we move forward.

Hi Sabine,

You mentioned that you still had some questions for the design option 2. Could you post them here? I started to revise the document based on the design option 2, but have not merged it to the latest revision. I hope our co-authors can agree on a design at least before we moving to the document revising for WGLC.

There are some materials talking about two design options:

[1] https://datatracker.ietf.org/meeting/104/materials/slides-104-alto-unified-properties-for-alto-01.pdf
[2] https://docs.google.com/presentation/d/1lCcLLbyKqZjGADxcHSorfADKx_CoG1fz_j6GBfPGZQY/edit?usp=sharing

Best regards,
Jensen