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

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 <jingxuan.n.zhang@gmail.com>
Sent: Sunday, December 09, 2018 5:21 PM
To: Gao Kai <godrickk@gmail.com>; Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <sabine.randriamasy@nokia-bell-labs.com>; Richard Yang <yry@cs.yale.edu>
Cc: IETF ALTO <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 <godrickk@gmail.com<mailto:godrickk@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
alto@ietf.org<mailto:alto@ietf.org>
https://www.ietf.org/mailman/listinfo/alto