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

[Jensen Zhang <[e-mail]>]

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) <[e-mail]> wrote:

> 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]> 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
>
>