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

Kai GAO <godrickk@gmail.com> Sun, 09 December 2018 15:44 UTC

Return-Path: <godrickk@gmail.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616D51286E7 for <alto@ietfa.amsl.com>; Sun, 9 Dec 2018 07:44:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4T-amFBmDg5d for <alto@ietfa.amsl.com>; Sun, 9 Dec 2018 07:44:53 -0800 (PST)
Received: from mail-vk1-xa31.google.com (mail-vk1-xa31.google.com [IPv6:2607:f8b0:4864:20::a31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A6C12785F for <alto@ietf.org>; Sun, 9 Dec 2018 07:44:52 -0800 (PST)
Received: by mail-vk1-xa31.google.com with SMTP id o130so1973428vke.10 for <alto@ietf.org>; Sun, 09 Dec 2018 07:44:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=snWte0lNCyjGsYGm+n9TIwrnXpv2npfa/Le39D9nkSI=; b=QZGO+mSzKHOztff8hLLySByu2irAVCrq0B69CepF6PtlRYL9/KsL0ColdjqJJDZ0kW cc+erapHQs/iCz9dn9jjv5g9wFrSPeYIsgkYDpYNs+MhrXpXgSv1H9OrYncagjw2rUtw wbXBu3gEVpYFhiI4G7fz9MLBI0Kua5Tmfy2rJg9mIh+w3DwY45Yr0GCHj4492Gi4Jk1M QXOO/xw8daslj1O3hfTAUOKIkO4D7AZkMVpn/5s1hO+MKaYKqTT/vTrfKCbD+SCjE0P3 3dTAWn4+ZZGG6Nx0fjOnNw5mretPipB9TTsSkMEMep75LmSGY0GVmC/puyOpGXcE49Dd Z8RA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=snWte0lNCyjGsYGm+n9TIwrnXpv2npfa/Le39D9nkSI=; b=ROiin4oKFQaJPByiSga2C3s47oG0pB5E03i2Xo+7vT+WNglEhHQZDz7zsvWHoAtBrk VFvo1bpLor97lHKsWhORyR1tCVShDP4wQPI9PefOvqd9LJhMA+fqzSvcrhx1YYODkLOi J9RYhWqxUv0VTOBfsAUH+IVJIHl1OsP3Xb7qxEPLz0ZxWKuELC+am1rMudzkNHPU5FyK 5NHIDK1cvMgQTDD7g6dqh90kdWOZawf8iPoEl1wMtMyBdpsPHksa4SAbujD5/mrsZvhQ wBt/3EmTXHnVHVNd6SdcWVBxMQKtNcaM9wqlkx1AUsmuppr7JhgdWzIADyygH+IK7Avq JCiw==
X-Gm-Message-State: AA+aEWZaRwlbmK8k+vCXWFt9JzBBeb8Kpb58jxRfTu7rBDBRqeJBLAfl Kgkt/mrYWxnX5NYGsrab2DUE6lJ+hFh7UEPlehVC8w==
X-Google-Smtp-Source: AFSGD/Uintz2o6GkBvZVuHuEZhCANtMX6JwNcJbLrKujBGnnA5PtRm8RwTVgxO8hcRP7Q8mo6GcPcidS6Wxg1uuIsmU=
X-Received: by 2002:a1f:acd7:: with SMTP id v206mr3866718vke.5.1544370291009; Sun, 09 Dec 2018 07:44:51 -0800 (PST)
MIME-Version: 1.0
From: Kai GAO <godrickk@gmail.com>
Date: Sun, 9 Dec 2018 23:44:39 +0800
Message-ID: <CAOELiNORK2jAz+PHsEs=S9=Br1_dkHH671tVsbaD18CTnNOicw@mail.gmail.com>
To: IETF ALTO <alto@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000098ed36057c98ba9d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/LGW0DBhsAVovxsVMSpaawMTv9VY>
Subject: [alto] Review on draft-ietf-alto-unified-props-new-04
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Dec 2018 15:44:55 -0000

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