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

"Y. Richard Yang" <> Tue, 10 July 2018 23:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1F57B130E23; Tue, 10 Jul 2018 16:18:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5a3-_4D5s3RP; Tue, 10 Jul 2018 16:17:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9981E130DCF; Tue, 10 Jul 2018 16:17:58 -0700 (PDT)
Received: by with SMTP id p6-v6so18004171ljc.5; Tue, 10 Jul 2018 16:17:58 -0700 (PDT)
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=lCzSrbxwF7tOXeAifjDRLrozrLOChHAP6J5YMRVLUSI=; b=d8mgizDU1AEcl2vxtqTDvCGAq9Da83lf8fleq7a95cTOHeGM1LxFHJTzC4XsWonwvE vQeXab+7ZHjAMb25Zf96h+9cofNwysGkRFeGeu8oj70tIbXrRJ2A5JEkbAwlUzA4YVWJ Boc70yOv+leUxW4nrs70+mm5S+vW6OjWdfwDjB+Wz8c3hIX45gUwFCiXq1c9tL46dxJ+ S5012Q0EcWj5bifkCFppwfNEt70YkS1AYnnVUMmwo2Y+QoemUJYArMqjDDltsHGzhwqi yCVct9XT1GdY26hDV6r0U1AfOuSSTjDGZARGySQ5ApYpj/ZdQEuRCmRah2vJlfa74ciL jItg==
X-Gm-Message-State: APt69E0elHsyrcU+5r7BJCtGIpEakTItsUz14mdzvQbokfTf+3Vqr/68 aKjWP/DE4337F8mKZotEe0h/Vc/gLHOQUy0ZGmLzZA==
X-Google-Smtp-Source: AAOMgpfljdlgPex7/M2vEvi9onCJud2HRLqhJjgSYAWtFiQ6+LD2wyC2NYWNKWs3eB6ggY8tuHvpdkUeS8AO3QxsNTc=
X-Received: by 2002:a2e:8346:: with SMTP id l6-v6mr4493069ljh.72.1531264676427; Tue, 10 Jul 2018 16:17:56 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: "Y. Richard Yang" <>
Date: Tue, 10 Jul 2018 19:17:44 -0400
Message-ID: <>
To: Drafts IETF <>
Content-Type: multipart/alternative; boundary="000000000000187e1c0570ad5786"
Archived-At: <>
Subject: Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-04.txt
X-Mailman-Version: 2.1.27
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: Tue, 10 Jul 2018 23:18:02 -0000

Dear WG,

In the process to revise UP to address the comments and make the protocol
as clean as possible, the authors identify one technical issue which we
need WG opinions.

Specifically, it is related to response (Sec. 5.6) to a filtered property

The related new text:
"   The response MUST indicate an error, using ALTO protocol error handling,
   as defined in Section 8.5 of [RFC7285], if the request is invalid.

   Specifically, a Filtered Property Map request can be invalid as

   o  An entity address in "entities" in the request is invalid if:

      *  The domain of this entity is not defined in the "entity-domain-
         types" capability of this resource in the IRD;

      *  The entity address is an invalid address in the entity domain.

      A valid entity address is never an error, even if this Filtered
      Property Map resource does not define any properties for it.

      If an entity address in "entities" in the request is invalid, the
      ALTO server MUST return an "E_INVALID_FIELD_VALUE" error defined
      in Section 8.5.2 of [RFC7285], and the "value" field of the error
      message SHOULD indicate this entity address.

   o  A property name in "properties" in the request is invalid if this
      property name is not defined in the "property-types" capability of
      this resource in the IRD.

      It is not an error that the Filtered Property Map resource does
      not define a requested property's value for a particular entity.
      In this case, the ALTO server MUST omit that property from the
      response for that endpoint.

      If a property name in "properties" in the request is invalid, the
      ALTO server MUST return an "E_INVALID_FIELD_VALUE" error defined
      in Section 8.5.2 of [RFC7285].  The "value" field of the error
      message SHOULD indicate the property name.

   The response to a valid request is the same as for the property map
   (see Section 4.6), except that it only includes the entities and
   properties requested by the client.

   It is important that the Filtered Property Map response MUST include
   all inherited property values for the specified entities.  A Full
   Property Map may skip a property P for an entity A if P can be
   derived using inheritance from another entitiy B.  A Filtered
   Property Map request may include only A but not B.  In such a case,
   the property B MUST be included in the response for A.

   [QUESTION to WG: Need to make a decision.] It is possible that the
entities in
   the response are different from the entities in the request.
   Consider a request for property P of entity A (e.g.,
   ipv4:  Assume that P has value v1 for
   A1=ipv4: and v2 for A2=ipv4:  Then, the
   response will include entities A1 and A2, instead of the request
   entity A.

An alternative design is to not enforce this decomposition. The authors feel
that the current revision is better but is open to WG guidance.


On Fri, Jun 29, 2018 at 1:29 PM <> wrote:

> 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

| Y. Richard Yang <>   |
| Professor of Computer Science       |
|        |