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

["Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[e-mail]>]

Hi,

Definitely there is a need to expose the motivation to cell addresses registered in the ALTO address type registry and the ALTO domain registry.  For the moment, I will add the related text to the [draft-randriamasy-alto-cellular-adresses] draft.
Thanks,
Sabine


From: [e-mail] [mailto:[e-mail]] On Behalf Of Y. Richard Yang
Sent: Saturday, March 03, 2018 12:44 AM
To: Jensen Zhang <[e-mail]>
Cc: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <[e-mail]>; [e-mail]
Subject: Re: [alto] unified-props, cellular addresses and path-vector - registry

Hi Jensen,

Thanks for the comments. Please see below.

On Thu, Mar 1, 2018 at 3:12 AM, Jensen Zhang <[e-mail]<mailto:[e-mail]>> 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) <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>] On Behalf Of Jensen Zhang
Sent: Tuesday, February 27, 2018 10:11 AM
To: Kai Gao <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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 / [e-mail]<mailto:[e-mail]>
Network Data Science, Nokia Networks
Calendar: http://goo.gl/x3Ogq

_______________________________________________
alto mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/alto


_______________________________________________

alto mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/alto


_______________________________________________
alto mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/alto



--
--
 =====================================
| Y. Richard Yang <[e-mail]<mailto:[e-mail]>>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================