Re: [alto] unified-props, cellular addresses and path-vector

Hi Jensen,

Thanks for the comments. Please see below.

On Thu, Mar 1, 2018 at 3:12 AM, Jensen Zhang <jingxuan.n.zhang@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.randriamasy@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-bounces@ietf.org] *On Behalf Of *Jensen Zhang
>> *Sent:* Tuesday, February 27, 2018 10:11 AM
>> *To:* Kai Gao <gaok12@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 <gaok12@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.zhang@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.gurbani@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.gurbani@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 <yry@cs.yale.edu>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================

Re: [alto] unified-props, cellular addresses and path-vector - registry