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

From: Jensen Zhang <[email-masked]>
Date: Tue, 9 Apr 2019 10:27:53 -0400

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

---

From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Wed, 10 Apr 2019 10:01:56 +0000

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

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.

[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

---

From: Jensen Zhang <[email-masked]>
Date: Thu, 11 Apr 2019 12:35:01 -0400

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) <[email-masked]> 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.
>
> 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.
>
> - what is the probability of having similar cases of property maps
> depending on multiple other information resources?
>
>
>
> Thanks,
>
> Sabine
>
>
>
>
>
>
>
> *From:* Jensen Zhang <[email-masked]>
> *Sent:* Tuesday, April 09, 2019 4:28 PM
> *To:* Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <
> [email-masked]>
> *Cc:* IETF ALTO <[email-masked]>; Richard Yang <[email-masked]>
> *Subject:* Final Decision of Unified Properties Design before Moving to
> WGLC
>
>
>
> Hi all,
>
>
>
> 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).
>

---

From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Wed, 17 Apr 2019 13:37:16 +0000

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 <[email-masked]>
Sent: Thursday, April 11, 2019 6:35 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <[email-masked]>
Cc: IETF ALTO <[email-masked]>; Richard Yang <[email-masked]>
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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jensen,

Thanks,
Sabine

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

Hi all,

Hi Sabine,

Best regards,
Jensen

---

From: Jensen Zhang <[email-masked]>
Date: Wed, 17 Apr 2019 23:40:49 -0400

Hi Sabine,

Thanks for your reply. Actually, you can find this example from our old
version of the IETF104 unified properties slides (p11) [1]. We removed it
from the final slides because it is too complex. But as you can see, design
option 2 can support this case without any ambiguity.

And I agree that we should make sure we don't miss any potential cases. But
if we really want to consider some other case which current design option 2
cannot support, we should give a concrete (even fictitious) example. So
far, I have not come up with an example which cannot work using design
option 2.

I finished a draft to illustrate design option 2. The attachment is the
text file of the draft. I have not submitted this revision yet because we
have not achieved an agreement on the final design.

And also, I made a deck of slides [2] illustrating the updates and issues I
have not figured out. We talked about the early part of the document
updates in our weekly meeting this morning. But most of them have not been
discussed. It will be great if you can take a quick look. In particular, p7
shows how to make design option 2 backward-compatible with design option 1;
p8 talks about the IANA registry issue; and I give a solution proposal on
p9 (not included in the draft revision yet). I would like to see how you
think about the current revision and the introduced issue.

I am looking forward to your feedback.

[1]
https://drive.google.com/file/d/19NO5MgQIGtioxC-lajkADyxpuDmLwmHt/view?usp=sharing
[2]
https://docs.google.com/presentation/d/1ooJHN6VhzPl3MqcbsMw442BnrPIupR_tyHOKa-18pSc/edit?usp=sharing

Thanks,
Jensen

On Wed, Apr 17, 2019 at 9:37 AM Randriamasy, Sabine (Nokia -
FR/Paris-Saclay) <[email-masked]> wrote:

> Hi Jensen,
>
>
>
> Thanks for your answer. I was just resuming one use case that was
> motivating the need to disambiguate resource dependencies.
>
>
>
> 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
>
>
>
>
>
>
>
> *Sent:* Thursday, April 11, 2019 6:35 PM
> *Subject:* Re: Final Decision of Unified Properties Design before Moving
> to WGLC
>
>
>
> Hi Sabine,
>
>
>
> 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

---

From: Jensen Zhang <[email-masked]>
Date: Wed, 17 Apr 2019 23:54:17 -0400

Just realized I forgot to attach the draft...

Best,
Jensen

On Wed, Apr 17, 2019 at 11:40 PM Jensen Zhang <[email-masked]>
wrote:

> And I agree that we should make sure we don't miss any potential cases.
> But if we really want to consider some other case which current design
> option 2 cannot support, we should give a concrete (even fictitious)
> example. So far, I have not come up with an example which cannot work using
> design option 2.
>
> And also, I made a deck of slides [2] illustrating the updates and issues
> I have not figured out. We talked about the early part of the document
>> 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:
>>
>>
>>
>> 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.
>>
>>
>>