Hi Jensen, Thanks for the comments. Please see below.
On Thu, Mar 1, 2018 at 3:12 AM, Jensen Zhang <jingxuan.n.zh...@gmail.com> wrote: > Hi Sabine, all > > Let me post some considerations on this topic. Please see my comments > inline. > > On Wed, Feb 28, 2018 at 6:17 AM Randriamasy, Sabine (Nokia - > FR/Paris-Saclay) <sabine.randriam...@nokia-bell-labs.com> wrote: > >> Hi Jensen, Kai, Vijay, all >> >> >> >> Thanks all for this discussion on registries, which needs a separate >> thread so I added “registry” to the initial thread. >> >> The ALTO Entity Domain Registry of the Unified Properties (UP) draft is >> to be seen as an extension of the ALTO Address Type Registry specified in >> RFC 7285. Indeed ipv4 and ipv6 map to both ALTO Address Type and ALTO >> Domain Type where the latter set covers the first one. >> >> >> > Yes. I think the goal of the ALTO Entity Domain Registry is to be an > extension of the ALTO Address Type Registry. But the relationship between > these two registries need to be clarified in the documents. > This is a good discussion. I can see two views regarding the extension word: 1. ALTO Entity Domain Registry is a superset of ALTO Address Type Registry; 2. ALTO Entity Domain Registry and ALTO Address Type Registry are two distinct sets, and we only want the intersection to be specified consistently. My understanding/view is one, and we should make it clear. > > >> Definitely, Jensen’s explanations (items 1) and 2) ) in his e-mail of Feb >> 27, 2018 at 3:10 PM should be used in sections 2.7 or 9.2 of the UP draft >> to clarify the relation between both. >> >> >> > Yes, agree. I will edit it. > OK. Let's edit it. > > >> For section 9.2 of the UP draft, I agree with Jensen’s views and >> understand Kai’s concerns. We may consider adding a sentence generalized >> from Sections 3.1.1.2 and 3.1.2.2 to have something like : >> >> "When a new address type is registered in the ALTO Address Type Registry >> of [RFC7285], the same identifier MUST be also registered in the ALTO >> Entity Domain Registry. And the Entity Address Encoding for this entity >> domain identifier MUST cover both Address Encoding and Prefix Encoding of >> the same identifier registered in the ALTO Address Type Registry [RFC7285]." >> >> “For the purpose of defining properties, an individual Entity address and >> the corresponding full-length prefix are considered aliases for the same >> entity.” >> >> >> > Yes, such a sentence is helpful. > > >> Would this help addressing the issue? >> >> > Yes, enforce address type registered as entity domain can help to > guarantee consistency. But I think it is not enough. > > Considering a prior document registers a new entity domain called 'AAA' > first, the 'AAA' can be a valid entity domain but not a valid address type > at this moment. Then, another later document registers a new address type > also called 'AAA'. If the encoding of the address type 'AAA' is not > consistent with the encoding of the entity domain 'AAA', there will be some > issue. > > So I propose we add a new column in the ALTO Entity Domain Registry table, > maybe called 'Valid for ALTO Addresses', to indicate which entity domain > can also be used as an address type and which cannot. Those entity domains > marked as 'Valid for ALTO Addresses' don't have to be registered in ALTO > Address Type Registry again. In this way, we can make 'ALTO Entity Domain > Registry' a superset of 'ALTO Address Type Registry'. But of course, other > columns of the ALTO Entity Domain Registry should be adjusted to > distinguish individual address encoding from the prefix/block address > encoding. > > Any thougthts? > > This seems to be a good idea---I always like syntax enforced consistency. Thanks! Richard > Thanks, > Jensen > > >> >> Thanks, >> >> Sabine >> >> >> >> >> >> >> >> *From:* alto [mailto:alto-boun...@ietf.org] *On Behalf Of *Jensen Zhang >> *Sent:* Tuesday, February 27, 2018 10:11 AM >> *To:* Kai Gao <gao...@mails.tsinghua.edu.cn> >> *Cc:* alto@ietf.org >> *Subject:* Re: [alto] unified-props, cellular addresses and path-vector >> >> >> >> Hi Kai, >> >> Thanks for your comment. See inline. >> >> On Tue, Feb 27, 2018 at 4:38 PM Kai Gao <gao...@mails.tsinghua.edu.cn> >> wrote: >> >> Hi Jensen, >> >> Please see inline. >> >> >> >> On 02/27/2018 03:44 PM, Jensen Zhang wrote: >> >> Hi all, >> >> >> >> Continue the discussion above. I suggest modifying the first paragraph of >> page 26 of draft-ietf-alto-unified-props-new-01 >> >> >> >> "It is RECOMMANDED that a new ALTO entity domain be registered when the >> corresponding address type is registered based on ALTO Address Type >> Registry [RFC7285]." >> >> >> >> as the following: >> >> >> >> "When a new address type is registered in the ALTO Address Type Registry >> [RFC7285], the same identifier MUST be also registered in the ALTO Entity >> Domain Registry. And the Entity Address Encoding of this entity domain >> identifier MUST include both Address Encoding and Prefix Encoding of the >> same identifier registered in the ALTO Address Type Registry [RFC7285]." >> >> It might be odd to have two encodings for a single entry. Since address >> encoding is actually a special case of prefix encoding, maybe we can use >> prefix encoding alone? >> >> >> >> The words may need to be revised. But we indeed hope to accept both >> Address Encoding and Prefix Encoding as the valid Entity Address Encoding. >> Using prefix encoding alone is not consistent with what "ipv4" and "ipv6" >> domain do in Section 3.1 of draft-alto-unified-props-new-01. >> >> >> >> >> >> Any comment? >> >> >> >> >> >> On Tue, Feb 27, 2018 at 3:10 PM Jensen Zhang <jingxuan.n.zh...@gmail.com> >> wrote: >> >> Hi Vijay, >> >> It is a good point to explain the relationship of "ALTO Address Type >> Registry" and "ALTO Entity Domain Registry". >> >> >> >> See my comment inline. >> >> On Tue, Feb 27, 2018 at 3:21 AM Vijay K. Gurbani <vijay.gurb...@nokia.com> >> wrote: >> >> [As co-chair] >> >> Sabine, Richard: If you decide to proceed as you outline below, then >> please realize that time is of essence. >> >> [As individual contributor] >> >> I am a bit confused by this discussion though. Are cellular addresses >> ALTO address types? In which case they will have to be registered in >> the ALTO Address Type Registry as detailed in Section 14.4 of the base >> ALTO RFC [1]. >> >> Yes, cellular address are ALTO address types. So of course they should be >> registered in the "ALTO Address Type Registry" based on RFC7285. >> >> >> >> Or are cellular address ALTO entities? In which case they will have to >> be registered through unified-props registry in Section 9.2 of the >> unified-props document [2]? >> >> And yes, cellular addresses "should" also be ALTO entities. But let's >> delay the answer to this question and see the following questions first. >> >> >> >> Why do we have legacy identifiers like 'ipv4' and 'ipv6' being >> registered in two registries, i.e., in the registries of [1] and [2]? >> >> In fact, why do we have a ALTO Entity Domain Registry in [2] at all? >> >> Why we introduce a new Registry? Because the key idea is to move the >> property map service from endpoint scope to the more general scope (which >> we call "entity domain" in the draft). >> >> >> >> So, >> >> 1) in this general scope, *an entity MAY or MAY NOT be an endpoint*. For >> example, "pid" is introduced as an entity domain, but it is not an endpoint >> address type. To allow this, we need this new registry. >> >> 2) But to cover the capability of the endpoint property service, *an >> endpoint MUST be an entity*. As the result, "ipv4" and "ipv6" are >> registered in both "ALTO Address Type Register" and "ALTO Entity Domain >> Registry". >> >> >> >> Now let's go back to the question "are cellular addresses ALTO >> entities?". Sure, as they are ALTO endpoint addresses, they MUST be ALTO >> entities. So they MUST be registered in the "ALTO Entity Domain Registry". >> >> >> >> I am afraid I am missing something ... can you please elaborate? >> >> >> >> Is it clear now? Do we agree on this? Or Sabine and Richad want to say >> anything? >> >> >> >> I think we need to well define the process of the ALTO Entity Domain >> Registry to guarantee the syntax and semantics of the same indentifier >> registered in both Registries are consistent. And I think this may be a >> missing item in the current unified-props draft. If we fix this part, the >> draft should be ready. >> >> >> >> Thanks, >> >> Jensen >> >> >> >> >> >> [1] https://tools.ietf.org/html/rfc7285#section-14.4 >> [2] >> https://tools.ietf.org/html/draft-ietf-alto-unified-props- >> new-01#section-9.2 >> >> Thanks, >> >> On 02/26/2018 10:18 AM, Randriamasy, Sabine (Nokia - FR/Paris-Saclay) >> 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? >> >> - vijay >> -- >> Vijay K. Gurbani / vijay.gurb...@nokia.com >> Network Data Science, Nokia Networks >> Calendar: http://goo.gl/x3Ogq >> >> _______________________________________________ >> alto mailing list >> alto@ietf.org >> https://www.ietf.org/mailman/listinfo/alto >> >> >> >> _______________________________________________ >> >> alto mailing list >> >> alto@ietf.org >> >> https://www.ietf.org/mailman/listinfo/alto >> >> >> >> > _______________________________________________ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto > > -- -- ===================================== | Y. Richard Yang <y...@cs.yale.edu> | | Professor of Computer Science | | http://www.cs.yale.edu/~yry/ | =====================================
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
