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

Jensen Zhang <jingxuan.n.zhang@gmail.com> Sun, 09 December 2018 16:09 UTC

Return-Path: <jingxuan.n.zhang@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 1B5461252B7 for <alto@ietfa.amsl.com>; Sun, 9 Dec 2018 08:09:46 -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 99eM_zMmwWiv for <alto@ietfa.amsl.com>; Sun, 9 Dec 2018 08:09:43 -0800 (PST)
Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 AC216128D68 for <alto@ietf.org>; Sun, 9 Dec 2018 08:09:43 -0800 (PST)
Received: by mail-yb1-xb2e.google.com with SMTP id b4so1310284ybg.9 for <alto@ietf.org>; Sun, 09 Dec 2018 08:09:43 -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=5LPzernA3UDRdk0v8G7Q16Eci7rLBwNk54BtClcIqiU=; b=LXpXpqr0lqQVMFiEMdkqXORxugJMdMEDfWvx8pPYqaGnpXwHyIfPokZ9e0XngL7Z+p OJW0BYv36DYg3vZBeZYDT8N4KB+HFdBJbzjejCpFR5qcFJQph4v7TSEMO680rJuWWLS1 33MxVc1hqbq06oVjBsmNoVSRNqNe9mqBs+f1Bfb35dCKdSorC+LqT1nLLX+uKP2Eut6o MOZuBcxLt6TmpvN9XRhCWSZYW9B2gNq10p3oI5xIeG0D1iuvi+K1fZaxZMH3gO0BAs92 40yIJmvzatrocVP/dgDT5xFUfZKLxQXhmDSt60G9xSxaG52zcXyo3UJ6B5RuHQowvl/p eeMQ==
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=5LPzernA3UDRdk0v8G7Q16Eci7rLBwNk54BtClcIqiU=; b=bymCiyYbKEQQ+1wPSBotqwVtiROoWSyajvqrcEBbPO7/ygSY8KcKujBl0Um/+zfByS zO321Bj2Us+457lzGBag/WQyq8gZaObaexP7SB6uUR7zMn2XEOatWlilMooMTfXFTUzw Rf88DdsHFwCKLIZbBVX08/JH3v1u/85zV50GSGF0i7utk/ruiaGCOQK/t+CCLfzzMCSl ECmrjz6fjZKodbGX+9Wu+nLo5RQ+SoPbbpJ2tWyUZZEHziykIf80S5fPq9l52/GQtkhs C1Xrs5rh8DQcyhoMSmrAwSwwov8D0HKeRu18HdbXKnpH66bjk7u+Ug0eWyzzbEx7v8ir 5WVw==
X-Gm-Message-State: AA+aEWZyNlE7/SMulxyY+M+uc9iDipA6t2QGgOUin5lbIRcMMNmB6Ym/ Rfcp0BMnNVagPrgEVNenVaQZpN2OfUgkT4MYmnCUAg==
X-Google-Smtp-Source: AFSGD/WmdTBkT52xGMbfkWdKXJbSlE+ZLkg1fCZ0+PsJ0fYWb8Xl1H9f/X1ek/pBa9NONzt3k9ayET1lWCaIjFCff4s=
X-Received: by 2002:a25:d4d4:: with SMTP id m203mr4617917ybf.157.1544371782633; Sun, 09 Dec 2018 08:09:42 -0800 (PST)
MIME-Version: 1.0
References: <CAOELiNNXK4T8CaXTALQU7+0Fazxz_-xPnH=uArygYsuxFoB8fw@mail.gmail.com>
In-Reply-To: <CAOELiNNXK4T8CaXTALQU7+0Fazxz_-xPnH=uArygYsuxFoB8fw@mail.gmail.com>
From: Jensen Zhang <jingxuan.n.zhang@gmail.com>
Date: Sun, 9 Dec 2018 11:09:31 -0500
Message-ID: <CAAbpuypk+gJu-EJRaY6mTATmpnNecgVKFOVDjHbf45=CqTTdjQ@mail.gmail.com>
To: Kai GAO <godrickk@gmail.com>
Cc: IETF ALTO <alto@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000814da8057c9913bc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/z5EmfbHKn1SL84kBnr8Z8mJi-0w>
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: Sun, 09 Dec 2018 16:09:46 -0000

Hi Kai,

Thanks for your review. Please see my comments inline.

On Sun, Dec 9, 2018, 10:25 AM Kai GAO <godrickk@gmail.com>; wrote:

> Hi everyone,
>
> Below is a review on the unified property map extension:
>
> 1. In Sec 2.1, the first sentence reads "The entity is an extended concept
> of the endpoint ...". Here the word "extended" may not be very precise, and
> the term "generalization" (which is also used in the abstract) sounds
> better. Generalization indicates that an endpoint is essentially an entity
> while extension could be misleading and even incorrect. For example, in
> certain languages, A extends B indicates that A is also B.
>

The term "generalization" sounds more precise. If nobody has strong opinion
to disagree, I will update it in the next revision.


> 2. In Sec 2.2, an entity domain is defined as "a set of entities". This
> seems odd because then one can say a set of two entities
> {"ipv4:190.0.2.34", "pid:PID1"} is also a domain, which doesn't make sense.
> An entity domain should be a generalization of endpoint address type, which
> must define the syntax and semantics of the entity addresses in this
> domain. Thus, borrowed from the definition of a domain in math, it could be
> "the complete set of all possible values of a given address type". Here the
> "given address type" is uniquely represented by the domain name, which
> indicates the "semantics" for this domain, while syntax for "all possible
> values" is defined by the "domain-specific entity addresses".
>

Exactly. I will change the wording.


> I also feel Sec 2 can be slightly rearranged for better clarity. Right now
> there are a lot of cross-references between different concepts. I suggest
> having a short section introducing the terms and then using a paragraph to
> specify their relations, for example,
>
> (domain name, domain-specific address type, hierarchies, relations)
> -(1:1)-> domain -(1:n)-> entity address -(1:1)-> entity -(1:m)-> property
> <-(1:1)- (property type, property value)
>

Good point. I will think about it.


> 3. I think the draft should make it clear that the uniqueness of an entity
> address only applies in the same unified property map. For example,
> "pid:PID1" could point to different entities when two UPMs depend on two
> different network maps, both have the PID "PID1".
>

I agree. I will make it clear.


> Best,
> Kai
> _______________________________________________
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto


All the comments on the definition part make the document clearer. I will
update them.

Thank you so much!
Jensen