[alto] Review of draft-ietf-alto-xdom-disc (Part 1: Sections 1 - 3)

"Y. Richard Yang" <yry@cs.yale.edu> Wed, 19 July 2017 19:01 UTC

Return-Path: <yang.r.yang@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 69670131B9B; Wed, 19 Jul 2017 12:01:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 jF6TdXJ_Dl-N; Wed, 19 Jul 2017 12:01:21 -0700 (PDT)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 CE587131BD5; Wed, 19 Jul 2017 12:01:04 -0700 (PDT)
Received: by mail-wm0-x234.google.com with SMTP id k69so6771238wmc.1; Wed, 19 Jul 2017 12:01:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=5zc40ROZ9j5fd0+/5P/9AqsxuWGBaBVJlVVGhWneY4Y=; b=ar7EOn+lj+L00Fc32AdtIjByO9sX8kk7XZW5uTWnuaML3lgYssIRAIaEpaqwtbuYgI 9WRGEl94UXcGNYKim1dKnYBX16VwMXKFftZpb4LpcIeDvMEobCAJY55PaAznutTZvHwX k74E5L2q+aKu6k2cJMikRPZyASlaXRUGksULsj8O/Utt29/0iF4ygbalXL9HELvyCCO3 tdSxCdrV8nckjwUib2RruzsYGwIoHQzaGlUXgkcLg8EeKMxB26Sw3uAx4T6lw1C17+Bz rxKxmRgEk3Kd8pygyNc4tqvTqIGwadS4WHuCcvSzuITZ9lzETrELGX84U30hhmoNNhvn BqAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=5zc40ROZ9j5fd0+/5P/9AqsxuWGBaBVJlVVGhWneY4Y=; b=J9JJ4hI2j9trcqcmzoYRYb4qG34z/trUGNeW3Ipxv7NLFpm/IO3fpWz1AdEPb+HJAu 8gUO4+ZCe6xvvsIDpu9iEUzoOApXEaMmJ9QRv1+mSpQpTn4wEt7v3aYtBKsnYvlefAbA AY1MZ5zoknKRivh5dSEnA653LrE3BgYwSUx7SP1rIrCaFxP+jY32EgfJpYUJ3YOfhuEw C/vCLwQMh6zRDuCOBo0+X5DA8VczXkl+U2sIZp/SExvFsEC/XIMOzCLhQ94Ksj9sWDV2 0OtsPnmIHxsbqAVKVIF21aloB14XsEmYishK22+zCTZfettpAd/ngNqVkUKWka+OlCeV CWpA==
X-Gm-Message-State: AIVw111pgmR+vI78UtS6RcZT+yEZqUtdKZBYcTveFKOEeQh1Dgyou/qb cOt4Rzl8+g2f2xdkXlNJtp2DeI16n8C0
X-Received: by with SMTP id e14mr667492wme.10.1500490862999; Wed, 19 Jul 2017 12:01:02 -0700 (PDT)
MIME-Version: 1.0
Sender: yang.r.yang@gmail.com
Received: by with HTTP; Wed, 19 Jul 2017 12:01:02 -0700 (PDT)
From: "Y. Richard Yang" <yry@cs.yale.edu>
Date: Wed, 19 Jul 2017 21:01:02 +0200
X-Google-Sender-Auth: HMgyeokUS4FY5-b55Jw9xOLpnR4
Message-ID: <CANUuoLobAY9drhLEkeYgynvMG17AH9y6gC0xDrMuKRgek_xhzQ@mail.gmail.com>
To: IETF ALTO <alto@ietf.org>
Cc: draft-ietf-alto-xdom-disc@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c093aa2e0c51f0554b040f3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/3x2L9swHgBQ6qAp96vwfmGC5iUA>
Subject: [alto] Review of draft-ietf-alto-xdom-disc (Part 1: Sections 1 - 3)
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.22
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, 19 Jul 2017 19:01:24 -0000

Dear authors of draft-ietf-alto-xdom-disc,

This is a very well thought out, very well written draft, with interesting
ideas and important use cases.

I plan to divide my review into two parts. First part is Sec. 1-3, covering
the design; The next part will be the rest, focusing more on discussions. I
will post later.


- abstract: In some deployment scenarios, in particular, if the information
about the network topology is partitioned and distributed over several ALTO

[yry: partitioned seems to imply single control. It seems that just
"distributed" is enough. A gentle comment is that this sentence may become
clearer if rewritten, e.g., "... if the ALTO network information is
distributed over several...]

- abstract: Technically, the algorithm specified in this document takes one
IP address or prefix...

[yry: "algorithm" implies less on requirements on standard. Given the need
to introduce ALTO:http or ALTO:https, it is more like a protocol or
procedure. Section 2 uses Procedure. How about change "algorithm" to

The construction will depend on IP address or prefix (the truncation). But
you can handle both. Hence, one way to convey why address and prefix is to
change the wording slightly, say "...can take either an IP address or a

- Table of content
[yry: Consistent subsection title. How about make 2.5 "Perform DNS

- Sec. 1.1.1
1    Ensure that all ALTO servers have the same knowlegde

[yry: The word "all" is a bit strong, as it may imply all servers ever
deployed. How about "a set of"?

The use of the word "knowledge" may imply that there is a common truth. The
word "have" might have some ambiguity. How about change "have the same
knowledge" -> "provide the same information"? Same for 2]

- Sec. 1.1.2
1.1.2.  Discussion of Solution Approaches

[yry: An overall comment is that (1) I like the discussion of the design
options as well as the discussion on the pros and cons of the solution
approaches. A suggestion is to make the organization of the discussions
more explicit. For example, will a table format more explicit?]

- Sec. 2.1
The algorithm specified in this document takes one IP address or

[yry: see the algorithm vs procedure discussion above]

- Sec. 2.1
For the remainder of the document, we use the notation:

[yry: The service parameter can be other than ALTO:http/ALTO:https]. How
about call it Y and then say that this document considers Y = "ALTO:https"?
This way, the generality of the design maybe better exposed.

- Sec. 2.2
- 2.2.  Basic Principle

[yry: The description below is more on an overview of a procedure and less
on a principle or principles. For example, I consider the longest search a
principle. The text below also an expanding search principle. Both are
great. I feel that it helps to call out the principles explicitly here, in
the overview.]

- Sec. 2.3.1
   If the parameter "X" is a single IPv4 address, the domain name is
   constructed according to the rules specified in Section 3.5 of
   [RFC1035] and it is rooted in the special domain "IN-ADDR.ARPA.".

[yry: Maybe picky. IN-ADDR.ARPA in the sentence above and in-addr.arpa in
the example. Domain name is case sensitive. How about use the same case?]

- Sec. 2.3.2
If the parameter "X" is an IPv4 prefix (i.e., an address block in
   CIDR [RFC4632] notation), the domain name is at first constructed as
described in section Section 2.3.1.  Then,

[yry: section Section -> Section. My first reaction is 2.3.1 is in RFC4632
and then realize it is this document. How about you add "... in Section
2.31 above". Also, it is not clear the domain construction rule below is
specified by this document or from RFC4632. It helps to make it clearer.]

- Sec. 2.3.4
2.3.4.  IPv6 prefix
If the parameter "X" is an IPv6 prefix (i.e., an address block in CIDR
[RFC4632] notation), the domain name is at first constructed as described
in section Section 2.3.3.  Then,

[yry: section Section. See comments above on more explicit source of the

- Sec. 2.3.4
   2.  if the prefix length is 64 bits, the domain name is shortened by
       16 labels (i.e., purge the 16th dot from the left and everything
       left of it),

[yry: 127-64?]

- Sec. 2.4
   This list is intended to provide network operators with a degree of
   flexibility in where discovery-related resource records can be placed
   without significantly increasing the number of DNS names that are
   searched.  This does not attach any other significance to these
   specific zone cuts or create a classful addressing hierarchy based on
   the reverse DNS tree.

[yry: Instead of using fixed demarcation points, we might wonder an
interesting question of flexible  points, say through a new service for a
top domain. This is just a question/comment, not a request to resolve this

- Sec. 3.1
   Trying to assemble a more densely populated cost map from several
   cost maps with this very sparse structure may be a non-trivial task,
   as different ALTO servers may use different PID definitions (i.e.,
   network maps) and incompatible scales for the costs, in particular
   for the "routingcost" metric.

[yry: Great section discussing a very interesting issue! My first reaction
is that there can be more complexity regarding the refinement process of
URI discovery specified in this document and that of specifying different
levels of network guidance. I feel that a paragraph on the consistency or
joint specification can be quite helpful!]