Re: [alto] FW: I-D Action: draft-ietf-alto-unified-props-new-04.txt

Qiao Xiang <> Sun, 08 July 2018 03:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 55EFD130F63 for <>; Sat, 7 Jul 2018 20:16:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.738
X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RHEfFl1doluF for <>; Sat, 7 Jul 2018 20:16:24 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4DBFC130F65 for <>; Sat, 7 Jul 2018 20:16:23 -0700 (PDT)
Received: by with SMTP id g15-v6so11260328edr.12 for <>; Sat, 07 Jul 2018 20:16:23 -0700 (PDT)
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=/ghuBOr9E79COo/IR8tNM3Ly9AqJqPyqBeEqjnMlDjI=; b=ZuGBJdp5noPaAQW6rFsFEICnJrab062BumvDOPO2kjfXXtwvQ1YgCj3Wq/TqJgZ5dz Hl/UJbJJpUi33dvstqzw+1chSlsLaCIfVkJ/FqOmfH9IS/+KrYG1FPvaIRYtmm6wPFZ9 ww1yoj67df/Z28DDcmbUL7zBE2ZzY4aPCukYTmBh7mv8oHbZHdBvLy74C8Vezz2X83hu lnpQSfORzAME85Kkb41oR5O1oDiOAEqJ9HYgALoAfAIy9gTh7an6g1uLLYGKbmwrxgMd FSR5RVc31uiz/VnrWLQqv4ObKjlK3NSYzA4mwaHitJbqsRxu/NpHWPnc9KkAZ0WJTLaQ UEKw==
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=/ghuBOr9E79COo/IR8tNM3Ly9AqJqPyqBeEqjnMlDjI=; b=ohNLLkle6dyc1vPHp9Kf5M82mntPcIFhnOCVJd5fULxPi5mTYOtGEeJUdv6Z/nApeT rxOgwlLDzYV0W2d4OHrlT7Le+VVFgljeZzBJQsw2FRTd2AdGQ8kIBC1v3brcKbTQcSnh AbwoDvoKORbx5nQFLJpPGxNISwlB6abHTE1SnP1yiIDqaDEhxWPCPNKcy7YfU3DvtYYY Sprq9bgyBVEsbZXNKyzz29jXo5Ywi8m6Txh9vhKrhnLN5znN6YhPHFMOIyX96lo7wgA3 X1/+hL37cyCMATrKLjrp2zkG3Arr+zyW67/d9+cVbASMQN7q2IChJheHeBjH/xMz/g6a L9Hg==
X-Gm-Message-State: APt69E0mhlO5Np/07lLVEzYrUmT26QQThgqyD42316l+5zDN0MxbxKDP u4/ln9DaLdFyNA2kNtUa0eRAV0aVYC3D5p1dWmk=
X-Google-Smtp-Source: AAOMgpeHjPMQtglb9h3l9gRUXVB3UPhTyrVmYODYrKzqeyVn4qJGQlxq226F+7CJd7vlmsUiM3seubJ3x2/AbnXHsDs=
X-Received: by 2002:a50:8a9b:: with SMTP id j27-v6mr16161002edj.36.1531019781736; Sat, 07 Jul 2018 20:16:21 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Qiao Xiang <>
Date: Sat, 7 Jul 2018 23:16:09 -0400
Message-ID: <>
To: "Randriamasy, Sabine (Nokia - FR/Nozay)" <>
Content-Type: multipart/mixed; boundary="0000000000003c1f0e0570745250"
Archived-At: <>
Subject: Re: [alto] FW: I-D Action: draft-ietf-alto-unified-props-new-04.txt
X-Mailman-Version: 2.1.26
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, 08 Jul 2018 03:16:30 -0000

Dear Sabine, Jensen and Dawn,

I finished my review on Section 1-6 of the Unified Property draft. In the
attached file,, all the comments are marked wtih "[qiao]". I will send out
the reviews for the remaining sections soon.

Most of my comments are related to consistency and clarity. However, there
are two technical issues I want to emphasize here, to seek the opinions
from you and other WG members:

1. In Section 4.4: in the PropertyMapCapabilities object to define the
capabilities of a Property Map:  the types of entity domains and the types
of properties provided in this map are each defined using a list,
respectively. With such a spec, how should the client know which domain has
which property? Consider the case where the server announces that it has a
property map with two entity domains d1 and d2, and property p1 and p2. If
the client wants to know the property of some entities in domain d1, it
sends a filtered property map query to the server. But it turns out, the
server only provides property p1 for domain d2. As such, the client gets a
bunch of "null" or error code. Only by now the client knows that the server
only provides property p1 for domain d2 entities, but a round-trip is
wasted. Simple as this example is, it can turn into a much troubling
scenario: imaging X (e.g., 10) domains and Y (e.g., 20) properties.

One solution to fix this issue, proposed during my offline discussion with
Jensen, is to redefine the PropertyMapCapabilities using an array of
(entity, property) combination.

2. In Section 6.3, the writing seems to only focus on the pid property of
IP entities. But conceptually other entity domains may also have a "pid"
property, right? I understand that this section is mainly to discuss the
compatibility with the pid property provided by ALTO EPS service, but it
should be stated clearly so that the readers would not be confused.

Please let me know if you have any thoughts on these. Thanks.


On Fri, Jun 29, 2018 at 2:11 PM Randriamasy, Sabine (Nokia -
FR/Paris-Saclay) <> wrote:

> Hello,
> The main updates in this new version relate to the consistency procedure
> between ALTO Address Type Registry and
>  ALTO Entity Domain Registry as discussed during the ALTO WG session in
> London. This is addressed in section 9.  IANA Considerations, where 9.2
> specifies the ALTO Entity Domain Registry and 9.2.1. proposes an algorithm
> to ensure consistency between both registries.
> Other updates include:
> - in section 1. Introduction: a paragraph introducing ALTO Entity domains,
> - In section 6.3, some rewording to clarify between "pid" and "PID" to
> avoid headaches,
> - section 7.3 example IRD: name update for the Endpoint property resource
> - section 7.4: example transaction
> - Section 10 References: updates and reformatting
> - usage of expression "ALTO Entity Domain" throughout the document
> Your feeback will be highly appreciated
> Thanks
> Sabine, Jensen, Dawn
> -----Original Message-----
> From: alto [] On Behalf Of
> Sent: Friday, June 29, 2018 7:29 PM
> To:
> Cc:
> Subject: [alto] I-D Action: draft-ietf-alto-unified-props-new-04.txt
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Application-Layer Traffic Optimization WG
> of the IETF.
>         Title           : Unified Properties for the ALTO Protocol
>         Authors         : Wendy Roome
>                           Shiwei Dawn Chen
>                           Sabine Randriamasy
>                           Y. Richard Yang
>                           Jingxuan Jensen Zhang
>         Filename        : draft-ietf-alto-unified-props-new-04.txt
>         Pages           : 30
>         Date            : 2018-06-29
> Abstract:
>    This document extends the Application-Layer Traffic Optimization
>    (ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint
>    properties" to domains of other entities, and by presenting those
>    properties as maps, similar to the network and cost maps in ALTO.
> The IETF datatracker status page for this draft is:
> There are also htmlized versions available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> alto mailing list
> _______________________________________________
> alto mailing list

Qiao Xiang
Postdoctoral Fellow,
Department of Computer Science,
Yale University