[alto] Resume Discussion about the Remaining Issue of draft-ietf-alto-unified-props

Jensen Zhang <jingxuan.n.zhang@gmail.com> Wed, 26 September 2018 13:15 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 74CB7130DCB for <alto@ietfa.amsl.com>; Wed, 26 Sep 2018 06:15:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id i7RDHl3Futw2 for <alto@ietfa.amsl.com>; Wed, 26 Sep 2018 06:15:38 -0700 (PDT)
Received: from mail-yw1-xc35.google.com (mail-yw1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (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 D3F9B120072 for <alto@ietf.org>; Wed, 26 Sep 2018 06:15:37 -0700 (PDT)
Received: by mail-yw1-xc35.google.com with SMTP id p206-v6so10742999ywg.12 for <alto@ietf.org>; Wed, 26 Sep 2018 06:15:37 -0700 (PDT)
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=lCpNiV3AgOrngyU2wHNJaBifxlZ9s2NAd4V/QKjiRTw=; b=joFP91IpvzzLgIyLn/V3EObScgQRlanWOpCZJyuEQjd/Sa/hSuu0V3JeDsTlF/opus t6289pc+ZJS4g2IXHJlCG1Z2sTYZ69hmjvPIQIN4NjeLtwgOT8M8yrXuVPRdIdWfqPHM GZDwDopx5CcOSUrUuvMGuFcwMlyKZP1QAwmMd3d/ovK8Vg+pU9Y01F4XKAGIBlXP/y2s FjWM8XS1HkbYeWyDwZVHtzhbJcoVr75gbISTlMmlAmk/qWQ923nQb90zLMwPkbZ0E/A/ Utfcmc3a9nb+vuP5Hkj+x5GgDymi+6dsfODnaNta8XG+W6oa+951oWMQV17RV3Bixvwq Wk+A==
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=lCpNiV3AgOrngyU2wHNJaBifxlZ9s2NAd4V/QKjiRTw=; b=GfGkMK0RyengReljnnZ0cCmbsgyxv41Z6BRq2jK8bmZBPf4/29STh4+G89XpPAudQ3 8oAkfd/KWUO3ODiPUv+Fhset2BazGhCCLB1LrCOikLJl8JPdt/s4kRQonS7b0eC2djPJ 78fOyXDG73hL9KAPoppUNlZn0S7fvU2B/xnj2zOrOYHxRJkYWfj2xMwT4/NjTa58f2c6 8sCRdFEZKIyNHZTeojaCNfQzaccY2NnWVb4bO5ZxItIxG9y3k1RGs/3SdrU472dwe8xn nTqM+yxzaXI/F6osh1fWYRAoAdfxHszDMzkVBX9sz/wII6IdhC0d+TD2LUgTFgmyelYi Mc7w==
X-Gm-Message-State: ABuFfoi6okjSUuI+P8RAyHKZLCom59rIpeOxwvJAN+re4ilYMa6nvJz0 Rajff/AR6kw+ijNT+FVa2ERFF/geiFb5fhZJOth4Npps
X-Google-Smtp-Source: ACcGV63hVWleo4++uQONPX2fKgKp3rPSnBj4YjTiJDJgz+J+Wjx0pdnYvxVhOguYXEzL53Ff0vfjxTD7hq7uEKH+fmg=
X-Received: by 2002:a81:6186:: with SMTP id v128-v6mr2982579ywb.13.1537967736578; Wed, 26 Sep 2018 06:15:36 -0700 (PDT)
MIME-Version: 1.0
From: Jensen Zhang <jingxuan.n.zhang@gmail.com>
Date: Wed, 26 Sep 2018 09:15:24 -0400
Message-ID: <CAAbpuyp2YRxVVJSReW9uZ0Dx3H3zxV=1Z-qAN9fGdnXyQ8hrTA@mail.gmail.com>
To: IETF ALTO <alto@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009d6c490576c604ba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/1ROtOPYn4_T0OMgEMiIRXiLmY_w>
Subject: [alto] Resume Discussion about the Remaining Issue of draft-ietf-alto-unified-props
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: Wed, 26 Sep 2018 13:15:40 -0000

Hi ALTOer,

During IETF 102, we agree that the unified properties draft is important
and need to be processed first. From the update which we presented at IETF
102, the latest draft has been almost stable. But there are still two
unclear points in the previous revisions:

1. The response of filtered property map query for address blocks.
2. The resource dependencies declaration.

For the first point, we presented the issue and the potential solution
during IETF 102 (p12-p13 of
The proposed solution should be reasonable. The authors are updating the
draft and including it.

But for the second point, we have not figured out a reasonable solution. So
I want to involve all of the related people to discuss this part.

Briefly, the second point is unclear because the "uses" attribute of a
unified property resource may have ambiguity from the current
specification. We take a simple example to show the ambiguity:

"uses": ["networkmap1", "pv-costmap1"],
"capabilities": {
  "entity-domains": ["ipv4", "ipv6", "ane"],
  "properties": ["pid"]

Based on the current draft, the "uses" attribute is "An array with the
resource ID(s) of resource(s) with which the entity domains in this map are
associated", the client can have several different understandings in this
example: (1) all the entities in this property map depend on networkmap1 or
pv-costmap1; (2) entities in ipv4 and ipv6 domain depend on networkmap1,
and entities in ane domain depend on pv-costmap1; (3) entities in ipv4
domain depend on networkmap1, entities in ipv6 domain depend on
pv-costmap1, entities in ane domain have no dependency. (4) ...

But all those understandings are not correct. The understanding the server
expects should be: the PID property values of all entities in this map
depend on networkmap1; the entities in ane domain depend on pv-costmap1.

To make the client can understand the resource dependencies of a property
map correctly, we should modify the specification of its "uses" attribute.
I have two proposals:

1. Each combination of "entity-domain" and "property" SHOULD specify its
dependent resource type explicitly. For example, <ipv4, pid> or <ipv6, pid>
depends on a network map; <ane, pid> depends on a network map and a cost
2. Each combination of "entity-domain" and "property" SHOULD specify how to
use the dependent resources to interpret this combination. For example, for
<pid4, pid>, the dependent network map is used to validate and interpret
the pid property values; for <ane, pid>, the dependent cost map is used to
validate and interpret the entities in ane domain, and the dependent
network map is used to validate and interpret the pid property values.

If we agree on these two proposals, they will be required for all the
registered ALTO Entity Domains and ALTO Properties, and the future ones. It
may be a critical change but may be necessary.

Do we have any better solution to make the resource dependency declaration
clear? I will appreciate people sharing thoughts.

Best regards,