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

[Jensen Zhang <[e-mail]>]

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]> 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]>
> *Sent:* Tuesday, April 09, 2019 4:28 PM
> *To:* Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <
> [e-mail]>
> *Cc:* IETF ALTO <[e-mail]>; Richard Yang <[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
>