[alto] Review on draft-ietf-alto-unified-props-new-04

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

Hi Kai and Jensen,

Thanks for pointing this out. Indeed the draft may have a section maybe 2.8 explaining how Endpoints are necessarily Entities. And it may recall this in section 9 explaining that the EDR is a superset of the ATR.

If I got Kai’s point:
- “Draft A proposes a new entity domain called "ABCP", which is not an address type. By the time of the registration, no address type of the same name exists...”
We should add “and the entities in that domain are considered as *not* likely to be able to send/receive messages over a network”. Otherwise, these entities fall in definition 2.1 of RFC 7285 and are likely to be endpoints. In which case the Entity Domain registration MUST follow the procedure of section 9.2.1 and also register an new Address type with the same identifier.

Suppose, it’s not the case, i.e. the “ABCP” registered in the EDR did not point to any addressable endpoint. When “Draft B proposes a new (ALTO) address type called "ABCP", which is registered to ATR.”, it MUST look up the EDR to see if the Domain Name ID “ABCP” is already present. If yes, there is no chance that “ABCP” will be present in the proposed column appended to EDR with the corresponding ALTO address type name “ABCP”, otherwise “ABCP” would already be present in the ATR.

So I think Kai’s suggestion to append a “ATR mapping” column is useful for documentation and to prevent the risk pointed out, any registration of an address type that did not map to any standard “S” will need to look up the EDR. This rule will require to extend the ATR procedure defined in section 14.4 of RFC 7285. Some date-based filtering such as look up EDR if last update was before the standardization of “S”.

Any opinion in the WG?

Thanks,
Sabine


From: Jensen Zhang <***@gmail.com>
Sent: Sunday, December 09, 2018 5:21 PM
To: Gao Kai <***@gmail.com>; Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <***@nokia-bell-labs.com>; Richard Yang <***@cs.yale.edu>
Cc: IETF ALTO <***@ietf.org>
Subject: Re: [alto] Review on draft-ietf-alto-unified-props-new-04

About the registry consistency, I agree that the current specification is not enough, although the definition of the consistency looks reasonable.

Adding a column in EDR to alias to the id in ATR makes sense for me. It means that the EDR has more proactivity to enforce the consistency. It can avoid the new registration in ATR to break the consistency. And it only requires a slight change to the current specification. I support this design.

Sabine and Richard, do you have any opinions?

Best,
Jensen

On Sun, Dec 9, 2018, 10:45 AM Kai GAO <***@gmail.com<mailto:***@gmail.com>> wrote:
Hi all,

Another issue is the consistency between Entity Domain Registry (EDR) and Address Type Registry (ATR).

Even with the current proposal, it MAY not be able to guarantee consistency. Consider the following case:

Draft A proposes a new entity domain called "ABCP", which is not an address type. By the time of the registration, no address type of the same name exists, so the entity domain is only registered to EDR.

Draft B proposes a new address type called "ABCP", which is registered to ATR.

Thus, it is impossible to "guarantee" consistency if ATR does not verify the registered domain names in EDR. In that case, it may be a better idea to NOT guarantee implicit consistency at all and make dependencies explicit. This can be easily achieved by appending a column to EDR with the corresponding address type name, (e.g., "ipv4" for "ipv4" and "ipv6" for "ipv6"). Thus, any library which supports UP extension should be able to translate an endpoint address to an entity address and vice versa.

One way to think of it is that the conflicts mainly come from name clashes. This "fallback name" gives address type an alias in EDR, which resolves name clashes.

Just my 2 cents.

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

[Kai GAO]

Hi Sabine and Jensen,

The reason why the inconsistency could happen is that there is no
restriction on how ATR is registered.

One way, as Sabine pointed out, is to extend the procedure in RFC 7285.

Appending a "mapping" column can leave RFC 7285 as it is. Meanwhile, new
domains are RECOMMENDED to follow the current procedure, which can help
avoid naming clashes with existing address types.

To conclude, unless the registration to ATR is updated, developers MUST not
assume a domain and an address type are equivalent even if they have the
same name.

Best,
Kai


On Tue, Dec 11, 2018 at 1:09 AM Randriamasy, Sabine (Nokia -

Post by Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
Hi Kai and Jensen,
Thanks for pointing this out. Indeed the draft may have a section maybe
2.8 explaining how Endpoints are necessarily Entities. And it may recall
this in section 9 explaining that the EDR is a superset of the ATR.
- “Draft A proposes a new entity domain called "ABCP", which is not an
address type. By the time of the registration, no address type of the same
name exists...”
We should add “and the entities in that domain are considered as **not**
likely to be able to send/receive messages over a network”. Otherwise,
these entities fall in definition 2.1 of RFC 7285 and are likely to be
endpoints. In which case the Entity Domain registration MUST follow the
procedure of section 9.2.1 and also register an new Address type with the
same identifier.
Suppose, it’s not the case, i.e. the “ABCP” registered in the EDR did not
point to any addressable endpoint. When “Draft B proposes a new (ALTO)
address type called "ABCP", which is registered to ATR.”, it MUST look up
the EDR to see if the Domain Name ID “ABCP” is already present. If yes,
there is no chance that “ABCP” will be present in the proposed column
appended to EDR with the corresponding ALTO address type name “ABCP”,
otherwise “ABCP” would already be present in the ATR.
So I think Kai’s suggestion to append a “ATR mapping” column is useful for
documentation and to prevent the risk pointed out, any registration of an
address type that did not map to any standard “S” will need to look up the
EDR. This rule will require to extend the ATR procedure defined in section
14.4 of RFC 7285. Some date-based filtering such as look up EDR if last
update was before the standardization of “S”.
Any opinion in the WG?
Thanks,
Sabine
*Sent:* Sunday, December 09, 2018 5:21 PM
*Subject:* Re: [alto] Review on draft-ietf-alto-unified-props-new-04
About the registry consistency, I agree that the current specification is
not enough, although the definition of the consistency looks reasonable.
Adding a column in EDR to alias to the id in ATR makes sense for me. It
means that the EDR has more proactivity to enforce the consistency. It can
avoid the new registration in ATR to break the consistency. And it only
requires a slight change to the current specification. I support this
design.
Sabine and Richard, do you have any opinions?
Best,
Jensen
Hi all,
Another issue is the consistency between Entity Domain Registry (EDR) and
Address Type Registry (ATR).
Even with the current proposal, it MAY not be able to guarantee
Draft A proposes a new entity domain called "ABCP", which is not an
address type. By the time of the registration, no address type of the same
name exists, so the entity domain is only registered to EDR.
Draft B proposes a new address type called "ABCP", which is registered to ATR.
Thus, it is impossible to "guarantee" consistency if ATR does not verify
the registered domain names in EDR. In that case, it may be a better idea
to NOT guarantee implicit consistency at all and make dependencies
explicit. This can be easily achieved by appending a column to EDR with the
corresponding address type name, (e.g., "ipv4" for "ipv4" and "ipv6" for
"ipv6"). Thus, any library which supports UP extension should be able to
translate an endpoint address to an entity address and vice versa.
One way to think of it is that the conflicts mainly come from name
clashes. This "fallback name" gives address type an alias in EDR, which
resolves name clashes.
Just my 2 cents.
Best,
Kai
_______________________________________________
alto mailing list
https://www.ietf.org/mailman/listinfo/alto