Hi Dawn and Jensen, My 2 cents here,
Indeed, the text in https://tools.ietf.org/html/draft-randriamasy-alto-cellular-adresses-01 has not been explicitly formatted for the Unified Property draft. However, mapping the domain type with “ecgi”, the entities with cells and their addresses with the proposed format is kind of straightforward and example properties can be imported from https://tools.ietf.org/html/draft-randriamasy-alto-cost-context-02 Removing "Section 3.4 ANE Domain" and adding it to Path-Vector and registering each new entity domain in a separate WG document in my view may generate some dispersion and we may lose track of one of the goals of the UP draft which is to broaden the view beyond the ipv6 and ipv4 domains. The UP draft extends entities from Endpoints to PIDs, ANEs, Cells and other potential entities. Path Vector uses ANE as a cost metric and introduces composite information resources that couple ANE properties with classical Cost Maps. ANEs, open the way for a richer network description, the ANE identification scheme and related property maps may be used in other contexts than Path Vector requests. I think the UP draft remains a good placeholder to define domains such as PID, ANE, ecgi and other future network related domains. Sticking to the ipv4 and ipv6 would significantly decrease its novelty. So it is important to identify a “central” placeholder where one can register and keep track of the evolution of domains beyond ipv4 and ipv6. This does not preclude from keeping on proposing new entities in separate drafts with the intent of ultimately adding them to the central register. By the way, the UP design may allow moderating the volume of on the wire data exchange if “cross-product” like responses could be avoided. For instance, similiarly to the flow cost service proposal: [(entity1, entity4), (propA, propB) (entity2), (propC) (entity3), (propD)] Instead of [(entity1, entity2, entity3, entity4) X (propA, propB, propC, propD) Any thoughts? Thanks, Sabine From: Jensen Zhang [mailto:[email protected]] Sent: Tuesday, February 27, 2018 10:04 AM To: Dawn Chan <[email protected]> Cc: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <[email protected]>; Y. Richard Yang <[email protected]>; Wendy Roome <[email protected]>; [email protected] Subject: Re: [alto] unified-props, cellular addresses and path-vector Sabine, Just add some additional comments to Dawn's proposal. In my opinion, I think we need to make the unified-props draft minimal so that we can push it to WGLC asap. So except for those entity domains which has been defined in the existing RFCs (i.e. 'ipv4', 'ipv6', 'pid'), we should not introduce more entity domains into this draft. Base on this principle, we also suggest moving "ane" domain out of the current unified-prop draft. And after the unified-prop draft is pushed to WGLC and published as RFC, we can be comfortable with registering a bunch of practical entity domains and properties (e.g. cellular addresses, cdni capabilities, ane, etc.) by starting a new draft. But before that, there is a major issue we need to fix. Just like what I posted in the previous email, we need to figure out the consistency issue between ALTO Address Type Registry and ALTO Entity Domain Registry. Whether we add cellular addresses as a new entity domain or not, this issue has to be fixed. Do you agree on this? btw. Sabine, would you like to be a co-author of the unified-props draft? Best, Jensen On Tue, Feb 27, 2018 at 4:25 PM Dawn Chan <[email protected]<mailto:[email protected]>> wrote: Hi Sabine, Actually I do find the proposal of the entity domain “ecgi”, but I do not see the detailed definition in https://tools.ietf.org/html/draft-randriamasy-alto-cellular-adresses-01. Actually, since the concept of unified property is clean enough. And I still remember that Shawn proposed to add a new domain country code for CDNI. So the suggestion is to remove the whole "Section 3.4 ANE Domain" in the unified property map, so that it will be defined in the path vector draft itself. This way, other entity domains can be registered in their own related document? Dawn On 27 Feb 2018, at 12:18 AM, Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <[email protected]<mailto:[email protected]>> wrote: Hi Richard, I agree, the Unified Property draft is definitely a good placeholder for the cellular addresses. Domain and entities are already defined in https://tools.ietf.org/html/draft-randriamasy-alto-cellular-adresses-01 . So how about in a next step, we consider pouring the content of the latter draft in the UP draft and in a further step propose a list of properties, while looking at other WG to see whether they already specified any? Sabine From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Y. Richard Yang Sent: Friday, February 23, 2018 8:11 PM To: Dawn Chan <[email protected]<mailto:[email protected]>> Cc: Gurbani, Vijay (Nokia - US/Naperville) <[email protected]<mailto:[email protected]>>; Wendy Roome <[email protected]<mailto:[email protected]>>; Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: unified-props, cellular addresses and path-vector It looks that the suggestion by Dawn is reasonable. I am taking a look again at the possibility of integrating cellular into UP quickly. An alternative is that we get it done shortly, in the next couple days. If this is the approach, Sabine is a great person to work together. Make sense, Sabine? Richard On Fri, Feb 23, 2018 at 1:31 AM, Dawn Chan <[email protected]<mailto:[email protected]>> wrote: Hi all, Draft Unified Property is quite stable at the moment, and the major problem left is whether the cellular address needs to be appended. Actually, since the Unified Property maintains an entity domain registry to achieve extensibility so that we suggest the new entity domain cellular address to be registered in the https://www.ietf.org/id/draft-randriamasy-alto-cellular-adresses-01.txt itself. This way, the draft Unified Property can proceed first. Besides, path-vector and unified property depend on each other so they should move as a bundle. Do you think this is a feasible solution? On 23 Feb 2018, at 3:16 AM, Vijay K. Gurbani <[email protected]<mailto:[email protected]>> wrote: All: In preparation for moving the unified property draft [0] ahead, the minutes of the December 2017 Virtual Interim Meeting [1] indicate that the chairs seek answers to the following questions from the WG: (1) Are cellular addresses an important abstraction that the working group will like to introduce in ALTO? Currently, cellular address format is specified in a companion draft [2]. (2) If yes, is the unified-props-new draft the correct place to add the cellular representation? Please note that the unified property draft [0] gates path-vector [3], as there is a dependency of path-vector on unified-props. Thus, the plan is to move these two drafts ahead as a bundle. Which means that we need to reach a conclusion on the questions posed above so unified-props and path-vector can move ahead. Please express an substantive opinion on the above questions in the mailing list. [0] https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/ [1] https://datatracker.ietf.org/meeting/interim-2017-alto-01/materials/minutes-interim-2017-alto-01-201712180600/ [2] https://datatracker.ietf.org/doc/draft-randriamasy-alto-cellular-adresses/ [3] https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/ Thank you, - vijay -- Vijay K. Gurbani / [email protected]<mailto:[email protected]> Network Data Science, Nokia Networks Calendar: http://goo.gl/x3Ogq -- -- ===================================== | Y. Richard Yang <[email protected]<mailto:[email protected]>> | | Professor of Computer Science | | http://www.cs.yale.edu/~yry/ | ===================================== _______________________________________________ alto mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/alto
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
