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

[Vijay K. Gurbani]

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 / ***@nokia.com
Network Data Science, Nokia Networks
Calendar: http://goo.gl/x3Ogq

[Dawn Chan]

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 <***@nokia.com<mailto:***@nokia.com>> 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 / ***@nokia.com
Network Data Science, Nokia Networks
Calendar: http://goo.gl/x3Ogq

[Y. Richard Yang]

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

Post by Dawn Chan
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?
All: In preparation for moving the unified property draft [0] ahead, the
minutes of the December 2017 Virtual Interim Meeting [1] indicate that
(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
--
Network Data Science, Nokia Networks
Calendar: http://goo.gl/x3Ogq

[Randriamasy, Sabine (Nokia - FR/Paris-Saclay)]

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: ***@gmail.com [mailto:***@gmail.com] On Behalf Of Y. Richard Yang
Sent: Friday, February 23, 2018 8:11 PM
To: Dawn Chan <***@hotmail.com>
Cc: Gurbani, Vijay (Nokia - US/Naperville) <***@nokia.com>; Wendy Roome <***@wdroome.com>; Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <***@nokia-bell-labs.com>; ***@ietf.org
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 <***@hotmail.com<mailto:***@hotmail.com>> 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 <***@nokia.com<mailto:***@nokia.com>> 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 / ***@nokia.com<mailto:***@nokia.com>
Network Data Science, Nokia Networks
Calendar: http://goo.gl/x3Ogq

[Vijay K. Gurbani]

[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].

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

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?

I am afraid I am missing something ... can you please elaborate?

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

Post by Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
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 / ***@nokia.com
Network Data Science, Nokia Networks
Calendar: http://goo.gl/x3Ogq

[Jensen Zhang]

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.

Post by Vijay K. Gurbani
[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.

Post by Vijay K. Gurbani
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.

Post by Vijay K. Gurbani
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".

Post by Vijay K. Gurbani
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

Post by Vijay K. Gurbani
[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,

Post by Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
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
--
Network Data Science, Nokia Networks
Calendar: http://goo.gl/x3Ogq
_______________________________________________
alto mailing list
https://www.ietf.org/mailman/listinfo/alto

[Jensen Zhang]

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]."

Any comment?

Post by Jensen Zhang
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.

Post by Vijay K. Gurbani
[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.

Post by Vijay K. Gurbani
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.

Post by Vijay K. Gurbani
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".

Post by Vijay K. Gurbani
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

Post by Vijay K. Gurbani
[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,

Post by Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
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
--
Network Data Science, Nokia Networks
Calendar: http://goo.gl/x3Ogq
_______________________________________________
alto mailing list
https://www.ietf.org/mailman/listinfo/alto

[Kai Gao]

Hi Jensen,

Please see inline.

Post by Dawn Chan
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]."
"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?

Post by Dawn Chan
Any comment?
On Tue, Feb 27, 2018 at 3:10 PM Jensen Zhang
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
[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 -

Post by Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
Hi Richard,
I agree, the Unified Property draft is definitely a good

placeholder for

Post by Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
the cellular addresses. Domain and entities are already

defined in
https://tools.ietf.org/html/draft-randriamasy-alto-cellular-adresses-01

Post by Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
. So how about in a next step, we consider pouring the

content of the

Post by Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
latter draft in the UP draft and in a further step propose a

list of

Post by Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
properties, while looking at other WG to see whether they

already

Post by Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
specified any?

- vijay
--
Network Data Science, Nokia Networks
Calendar: http://goo.gl/x3Ogq
_______________________________________________
alto mailing list
https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
https://www.ietf.org/mailman/listinfo/alto

[Jensen Zhang]

Hi Kai,

Thanks for your comment. See inline.

Post by Kai Gao
Hi Jensen,
Please see inline.
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]."
"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.

Post by Kai Gao
Any comment?

Post by Jensen Zhang
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.

Post by Vijay K. Gurbani
[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.

Post by Vijay K. Gurbani
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.

Post by Vijay K. Gurbani
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".

Post by Vijay K. Gurbani
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

Post by Vijay K. Gurbani
[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,

Post by Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
Hi Richard,
I agree, the Unified Property draft is definitely a good placeholder

for

Post by Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
the cellular addresses. Domain and entities are already defined in

https://tools.ietf.org/html/draft-randriamasy-alto-cellular-adresses-01

Post by Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
. 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
--
Network Data Science, Nokia Networks
Calendar: http://goo.gl/x3Ogq
_______________________________________________
alto mailing list
https://www.ietf.org/mailman/listinfo/alto

_______________________________________________

[Kai Gao]

Hi Vijay and all,

I think what Jensen elaborates here is that any address type has a
corresponding entity domain. As unified property map is basically an
extension to the endpoint property map, it also extends the domain of
address types to entity domains.

Unfortunately, there are cases where we still need to distinguish
between address type (for example, in endpoint cost map) and entity
domain, so two registries seem inevitiable.

Regards,

Kai

Post by Jensen Zhang
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
[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 -

Post by Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
Hi Richard,
I agree, the Unified Property draft is definitely a good

placeholder for

Post by Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
the cellular addresses. Domain and entities are already defined in

https://tools.ietf.org/html/draft-randriamasy-alto-cellular-adresses-01

Post by Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
. So how about in a next step, we consider pouring the content

of the

Post by Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
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
--
Network Data Science, Nokia Networks
Calendar: http://goo.gl/x3Ogq
_______________________________________________
alto mailing list
https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
https://www.ietf.org/mailman/listinfo/alto

[Dawn Chan]

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) <***@nokia-bell-labs.com<mailto:***@nokia-bell-labs.com>> 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: ***@gmail.com<mailto:***@gmail.com> [mailto:***@gmail.com] On Behalf Of Y. Richard Yang
Sent: Friday, February 23, 2018 8:11 PM
To: Dawn Chan <***@hotmail.com<mailto:***@hotmail.com>>
Cc: Gurbani, Vijay (Nokia - US/Naperville) <***@nokia.com<mailto:***@nokia.com>>; Wendy Roome <***@wdroome.com<mailto:***@wdroome.com>>; Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <***@nokia-bell-labs.com<mailto:***@nokia-bell-labs.com>>; ***@ietf.org<mailto:***@ietf.org>
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 <***@hotmail.com<mailto:***@hotmail.com>> 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 <***@nokia.com<mailto:***@nokia.com>> 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 / ***@nokia.com<mailto:***@nokia.com>
Network Data Science, Nokia Networks
Calendar: http://goo.gl/x3Ogq

[Jensen Zhang]

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

Post by Dawn Chan
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)
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
*Sent:* Friday, February 23, 2018 8:11 PM
*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
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?
All: In preparation for moving the unified property draft [0] ahead, the
minutes of the December 2017 Virtual Interim Meeting [1] indicate that
(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
--
Network Data Science, Nokia Networks
Calendar: http://goo.gl/x3Ogq
--
--
=====================================
| Professor of Computer Science |
| http://www.cs.yale.edu/~yry/ |
=====================================
_______________________________________________
alto mailing list
https://www.ietf.org/mailman/listinfo/alto

[Randriamasy, Sabine (Nokia - FR/Paris-Saclay)]

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:***@gmail.com]
Sent: Tuesday, February 27, 2018 10:04 AM
To: Dawn Chan <***@hotmail.com>
Cc: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <***@nokia-bell-labs.com>; Y. Richard Yang <***@cs.yale.edu>; Wendy Roome <***@wdroome.com>; ***@ietf.org
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 <***@hotmail.com<mailto:***@hotmail.com>> 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) <***@nokia-bell-labs.com<mailto:***@nokia-bell-labs.com>> 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: ***@gmail.com<mailto:***@gmail.com> [mailto:***@gmail.com] On Behalf Of Y. Richard Yang
Sent: Friday, February 23, 2018 8:11 PM
To: Dawn Chan <***@hotmail.com<mailto:***@hotmail.com>>
Cc: Gurbani, Vijay (Nokia - US/Naperville) <***@nokia.com<mailto:***@nokia.com>>; Wendy Roome <***@wdroome.com<mailto:***@wdroome.com>>; Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <***@nokia-bell-labs.com<mailto:***@nokia-bell-labs.com>>; ***@ietf.org<mailto:***@ietf.org>
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 <***@hotmail.com<mailto:***@hotmail.com>> 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 <***@nokia.com<mailto:***@nokia.com>> 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 / ***@nokia.com<mailto:***@nokia.com>
Network Data Science, Nokia Networks
Calendar: http://goo.gl/x3Ogq
--
--
=====================================
| Y. Richard Yang <***@cs.yale.edu<mailto:***@cs.yale.edu>> |
| Professor of Computer Science |
| http://www.cs.yale.edu/~yry/ |
=====================================

_______________________________________________
alto mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/alto

[Jensen Zhang]

Hi Sabine,

Sorry for the delay. Please see my comments inline.

On Wed, Feb 28, 2018 at 8:54 AM Randriamasy, Sabine (Nokia -

Post by Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
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

Post by Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
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

Post by Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
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.

I understand your point. Of course, we need to highlight the novelty:
extensible. This is one of the design philosophy of UP. So the introduction
wrote:

"Entity domains and property names are extensible. New domains can be
defined without revising the messages defined in this document, in the same
way that new cost metrics and new endpoint properties can be defined
without revising the messages defined by the ALTO protocol."

But I think the another design philosophy of UP should be minimal. The only
reason we define ipv4, ipv6 and pid domain in this draft is that they have
been used in the existing RFCs. But for ANE, esgi and other future network
related domains, they are still not mature. So we need to avoid their
effect to UP.

For example, if you register ecgi as a new *entity domain* in UP now, but
you want to modify the encoding of the esgi *address type* in another
document later, it will introduce unexpected consistency issue.

This is my opinion. We still need comments from Wendy, Richard and other WG
members.

Post by Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
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.
[(entity1, entity4), (propA, propB)
(entity2), (propC)
(entity3), (propD)]
Instead of [(entity1, entity2, entity3, entity4) X (propA, propB, propC, propD)

That's an interesting point. This proposal can reduce the unnecessary
information from the UP's response. My only concern is whether it will
introduce unexpected complexity.

I think such a request can always be equal to multiple separated
"cross-product" requests. It is different from the flow cost service.
Because a single request for correlated flows is not equal to separated
cross-product flow requests. Or can we find an example that such an
improvement is necessary?

We need to collect more feedback from WG.

Post by Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
Any thoughts?
Thanks,
Sabine
*Sent:* Tuesday, February 27, 2018 10:04 AM
*Cc:* Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <
*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
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)
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
*Sent:* Friday, February 23, 2018 8:11 PM
*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
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?
All: In preparation for moving the unified property draft [0] ahead, the
minutes of the December 2017 Virtual Interim Meeting [1] indicate that
(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
--
Network Data Science, Nokia Networks
Calendar: http://goo.gl/x3Ogq
--
--
=====================================
| Professor of Computer Science |
| http://www.cs.yale.edu/~yry/ |
=====================================
_______________________________________________
alto mailing list
https://www.ietf.org/mailman/listinfo/alto