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

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 -
FR/Paris-Saclay) <sabine.randriamasy@nokia-bell-labs.com> wrote:

> 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> 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
> https://www.ietf.org/mailman/listinfo/alto
>
>