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

Jensen Zhang <> Sun, 09 December 2018 16:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6122A126C7E for <>; Sun, 9 Dec 2018 08:21:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JqSHmcR8kA-v for <>; Sun, 9 Dec 2018 08:21:25 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::b35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 49F3E1252B7 for <>; Sun, 9 Dec 2018 08:21:25 -0800 (PST)
Received: by with SMTP id f4so3752269ybq.4 for <>; Sun, 09 Dec 2018 08:21:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=N7RZ6/clcorqoK+JcRHgG/6T++77xZfhHfsPUYjMWco=; b=GTpBKSyNpsun+J/v3jDY7vVyemH4tqPVk5DAekcI1zEVC0VUTDKbQRXF8pmzsyrV9A iOWAmeOdwb4aiWGvJEMJWwgQx4Iri4tujY6T7fvCc8D3bHFN2kZh+OOmoIzMLwrXG30A rRMGPDEBReav/78YJsUhW/U88Tt0+vGOREC0d/xX70brRTKUcjR1B0wWdafPO7Km9FaU B583wniOOw0Mo/4OAynb8najA8aBlJVemagIoTpDYoYbYg3Oc9A4t3vEljXn8C6gXtXD exr2e3cdSSd+ioHA1BtLfkgdBMwidw5s7+RjDHrWFg098J1eipT3xPtrnl5a6rJMxh5V /rEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=N7RZ6/clcorqoK+JcRHgG/6T++77xZfhHfsPUYjMWco=; b=ENuyHbrxYPINEGaCpbsDl7okVMdiTUrj7mdgrEbG3s3IN+0WzsagsgnoONaqE/mK3A YHAJunpe2fRITglFEoBEKHUHtxWbChmxdzTuhQLL727rIoBBtod/Nl0K0dIbd8D/Z9Pt w5XE+D8676d00z7KtrR/XBugNaL3HyNa0NKVfPSwSCEXRBhqV0eE4vQQepaogUyPaqw4 v8VeiZ1bRyXsyCFVdKvI5mV0fzZ7fGLQeRT4PU1EsllBClFlh5sm5k5H0OhGIv/y5k9P 0+Vl0al9TJxvT/HlTh6zKLTb25Z91MMYKLlSgFBXJ9c3VkV+pe71E2kLjHTjApsNAfq7 DClg==
X-Gm-Message-State: AA+aEWag66o0ZJJdmCOr3TrTB4Gws0R+5YDs477aMDNd2dq8LDTw8C4k 96j0/mxUe59eZSfsPi4rPhH9JDmuQDfw9y0AEbU=
X-Google-Smtp-Source: AFSGD/WjeID6A9EMz10xco3uO+PSAAuNCJTyc2GLJu8nfYwxSQVPCwJb9ID2SBqZWMcDEgT3KrYWxlYpRVKUwrUstRE=
X-Received: by 2002:a25:d4d4:: with SMTP id m203mr4655667ybf.157.1544372484453; Sun, 09 Dec 2018 08:21:24 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Jensen Zhang <>
Date: Sun, 9 Dec 2018 11:21:13 -0500
Message-ID: <>
To: Gao Kai <>, "Randriamasy, Sabine (Nokia - FR)" <>, Richard Yang <>
Content-Type: multipart/alternative; boundary="000000000000563b8d057c993d48"
Archived-At: <>
Subject: Re: [alto] Review on draft-ietf-alto-unified-props-new-04
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 09 Dec 2018 16:21:27 -0000

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

Sabine and Richard, do you have any opinions?


On Sun, Dec 9, 2018, 10:45 AM Kai GAO <>; 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