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

[Jensen Zhang <[e-mail]>]

Just realized I forgot to attach the draft...

Best,
Jensen


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

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