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

Kai GAO <godrickk@gmail.com> Tue, 11 December 2018 02:08 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 A11BA128D68 for <alto@ietfa.amsl.com>; Mon, 10 Dec 2018 18:08:43 -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 l9cbciuXMNsr for <alto@ietfa.amsl.com>; Mon, 10 Dec 2018 18:08:41 -0800 (PST)
Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (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 AF15C126CC7 for <alto@ietf.org>; Mon, 10 Dec 2018 18:08:40 -0800 (PST)
Received: by mail-ua1-x92d.google.com with SMTP id u19so4595033uae.4 for <alto@ietf.org>; Mon, 10 Dec 2018 18:08:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j4TKgYvNzdghJQfJP3IyZHf7VqO4kKoFb+6uwnJ/f80=; b=H0oY1qg6NHe45YAMV8hR8sXcci8AqC5ccL1LXb67mFXOKj2fmZ2sHAfSaXAj4CGeuP 2Zh0Vgqrw9NulRJwRHRBEmWoDEQwwjKvblEUlKm2mstDpZGS7L/ydWVzDL/TkC+BxrNP qCI44971a4OkFpfj0ZktAZxWT+egSEFTN7BrT48OixUkxSby/2UbeVTdK9VFhTQtzP/4 1EU4V4KP0KjDUWGgHhGvJ1Wt0KYefl4M3/WKA7s7U8z/e1FFrV6VNwKa9r88TxngYrLI ftCHdyeQiWevBrLgnCmjZ/OjdbVG3EQgFlqcufri7J8Hw5s4KfkG4bz9gA//6Z3+vQ1r 3RQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j4TKgYvNzdghJQfJP3IyZHf7VqO4kKoFb+6uwnJ/f80=; b=Wtvnx1tkbkbFJCsDLhFqmZO/mokOy3kJdmaitGB9QhibCQYBajlp5VIFsGsS1Jz42u pDpf1JAX9qtw1QqFh29AkLf3CC5KYdF45XzJEaYBH1EqXgCV8A3ry2Q3wOSu+uYTy1Fc 8lqJNlPDKvUEF2UKrnXolkkafuQ8zRCyLBU11qiegiSSIgNGQ+NWlB1/cM1sC5bu0o/y 4PYOYsUC5j4WESBoQP7TFuaFDG7vMZ8cFGzsADZWziTyEzPXWSOAM4DCoM+xIPRks7W/ M7AAavSbOYTLfFfjcBDZuXY7CGeYETvdgg8EYYs3mDQxW5V2yYWGLnS7Ly27yhQ2Eujd xozg==
X-Gm-Message-State: AA+aEWZDU5YKl92RT1XosLy4Lz21dXT280oj+UKx32fbvYewbn4lVe5G WwMt8ud0udAWnLUWfKeb0wT/5/GSvOywW9N/E9k=
X-Google-Smtp-Source: AFSGD/UGhni6AtUyhbDZeqknl1h0ZWdGfTBhJLzavC5KjCTP2w+PG32VCP4bU415hmHdUZdV6L+loYTTF9kJ9AZDVMI=
X-Received: by 2002:a9f:3e9b:: with SMTP id x27mr6617895uai.94.1544494119694; Mon, 10 Dec 2018 18:08:39 -0800 (PST)
MIME-Version: 1.0
References: <CAOELiNORK2jAz+PHsEs=S9=Br1_dkHH671tVsbaD18CTnNOicw@mail.gmail.com> <CAAbpuyrNUbQp0U5PbDiMe8J3_2-_w9OKL=BUJMUvOCXMUhLXLw@mail.gmail.com> <AM4PR07MB3236D5068C53C1E1D6A4122195A50@AM4PR07MB3236.eurprd07.prod.outlook.com>
In-Reply-To: <AM4PR07MB3236D5068C53C1E1D6A4122195A50@AM4PR07MB3236.eurprd07.prod.outlook.com>
From: Kai GAO <godrickk@gmail.com>
Date: Tue, 11 Dec 2018 10:08:26 +0800
Message-ID: <CAOELiNPrE+yTHaJV+Ki_fHrGOPJwd=fFuwea=Gg+_cuQtWHFQA@mail.gmail.com>
To: sabine.randriamasy@nokia-bell-labs.com
Cc: Jensen Zhang <jingxuan.n.zhang@gmail.com>, Richard <yry@cs.yale.edu>, IETF ALTO <alto@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005cb58c057cb58f39"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/zEqYjJ6z-P8k2GSpN1PfigOPWhI>
Subject: Re: [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: Tue, 11 Dec 2018 02:08:44 -0000

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
>
>