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

From: Qiao Xiang <[email-masked]>
Date: Sat, 7 Jul 2018 23:16:09 -0400

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.

Best
Qiao

On Fri, Jun 29, 2018 at 2:11 PM Randriamasy, Sabine (Nokia -
FR/Paris-Saclay) <[email-masked]> 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 [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Friday, June 29, 2018 7:29 PM
> To: [email-masked]
> Cc: [email-masked]
> 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:
> https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-04
> https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-04
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

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

---

From: Danny Alex Lachos Perez <[email-masked]>
Date: Sun, 8 Jul 2018 14:24:25 -0300

Hello Sabine and WG

I reviewed Introduction, S1, S2, S3, and S4 of the Unified Property
draft. My comments are in the attached file (marked with [DANNY]).

Ss

Danny Lachos

On Fri, Jun 29, 2018 at 3:11 PM Randriamasy, Sabine (Nokia -

---

From: Jensen Zhang <[email-masked]>
Date: Mon, 9 Jul 2018 03:13:53 -0400

Hi Qiao,

Thanks for your review. Authors will consider your comments and update the
document soon. About the technical issues you mentioned, see my comments
inline:

Thanks,
Jensen

On Sun, Jul 8, 2018 at 11:16 AM Qiao Xiang <[email-masked]> wrote:

> attached file,, all the comments are marked wtih "[qiao]". I will send
> out the reviews for the remaining sections soon.
>
> Sure, we already discussed offline. But after that, I rethink about this
problem. In a single property map resource, the "prop-types" and the
"entity-domain-types" should be fully bound. So if an ALTO server wants to
provide property p1 and p2 for domain d1, and only property p1 for domain
d2, the best practice should be to separate domain d1 and d2 to different
property maps. Does it make sense?

Waiting for more comments from others.

> Although we do not mention that "pid" property must bind with the IP
entities, I'm not sure whether we should emphasize this. Because in this
document, we only define IP domain and PID domain. And only IP domain may
own the "pid" property. If the future documents define another entity
domain owning a property called "pid", it can specify the semantics by
itself.

>> This draft is a work item of the Application-Layer Traffic Optimization
>> WG of the IETF.
>>

---

From: Jensen Zhang <[email-masked]>
Date: Mon, 9 Jul 2018 03:23:30 -0400

Hi Danny,

Thanks for your review. I quickly go over your comments. Many of your
comments are about the format issue. Authors will fix them soon.

Thanks,
Jensen

---

From: Danny Alex Lachos Perez <[email-masked]>
Date: Mon, 9 Jul 2018 16:05:46 -0300

Hi Jensen and WG

I finished my review on Sec 5-9.

My comments are in the attached file marked with [DANNY].

Ss

Danny Lachos

On Mon, Jul 9, 2018 at 4:23 AM Jensen Zhang <[email-masked]>
wrote:

> On Mon, Jul 9, 2018 at 1:24 AM Danny Alex Lachos Perez <
> [email-masked]> wrote:
>
>> Hello Sabine and WG
>>

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 10 Jul 2018 19:17:44 -0400

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

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

   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:192.0.2.0/31).  Assume that P has value v1 for
   A1=ipv4:192.0.2.0/32 and v2 for A2=ipv4:192.0.2.1/32.  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.

Thanks!
Richard

On Fri, Jun 29, 2018 at 1:29 PM <[email-masked]> wrote:

> submission
> until the htmlized version and diff are available at tools.ietf.org.
>

-- 
-- 
 =====================================
| Y. Richard Yang <[email-masked]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================

---

From: Jensen Zhang <[email-masked]>
Date: Wed, 11 Jul 2018 01:52:20 -0400

Hi Richard and WG,

My opinion is to make such a decomposition optional. Because the
decomposition is not always possible, and the decomposition solution may
not be unique. It's hard to enforce it.

So I suggest we can add the following paragraphs to explain it:

===
An ALTO client should be aware that the entities in the response MAY be
different from ones it requests. If entities in the requested domain can be
inherited, the ALTO server MAY decompose a requested entity address into
several entities which could inherit it. One example is the Internet
Address domains: Considering a request for property P of entity A (e.g.,
ipv4:192.0.2.0/31), if P has value v1 for A1=ipv4:192.0.2.0/32 and v2 for
A2=ipv4:192.0.2.1/32, then the ALTO server could return the response
including entities A1 and A2, instead of the requested entity A. The ALTO
server could also return v1 for A1 and v2 for A, and the ALTO client can
also deduce v2 for A2 from the inheritance.

An operator should be aware that if the ALTO server supports the entities
decomposition, there will be potential security considerations. Section 8
(points to the Security Considerations section) discusses the details and
potential solutions.
===

There are two security considerations I can find:

1. If an ALTO client requests a large IP prefix like 0.0.0.0/0, the
decomposition may be very large (equal to the full map), which may consume
a lot of computation resource in the server side.
2. The decomposition may expose the confidential information to the ALTO
client, which may be unexpected by the ALTO server.

Waiting for comments from others.

Best,
Jensen

On Wed, Jul 11, 2018 at 7:18 AM Y. Richard Yang <[email-masked]> wrote:

>       not define a requested property's value for a particular entity..

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 11 Jul 2018 13:54:22 -0400

Dear WG,

After extensive discussions, the authors will go with enforcing
decomposition.

Consider a simple use case:
A network map:
           defaultpid:  ipv4:0.0.0.0/0  ipv6:::0/0
            pid1:        ipv4:192.0.2.0/25
            pid2:        ipv4:192.0.2.0/28  ipv4:192.0.2.16/28

Assume that the client queries pid for ipv4:192.0.2.0/26. Without
decomposition, the client will get pid1, through inheritance. Now, the
client can use the result, for example, when lookup pid for 192.0.2.0/28,
locally. The result is pid1 locally but a query to the server is pid2.
Hence, for correctness, the system must notify the client that there are
refinement, which is decomposition.

We are taking a pass of the design and will post by end of this week.

Any comments are greatly appreciated!

Richard