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

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 19 Jul 2017 21:01:02 +0200

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.

Richard

====
- 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
"procedure"?

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
prefix"...]

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

- 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:
   IRD_URIS_X := XDOMDISC(X,"ALTO:https")

[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
rule.]

- 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
issue.]

- 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!]
====

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 19 Jul 2017 22:10:40 +0200

Hi Richard,

many thanks for the review - already looking forward for part 2.

After quickly browsing your comments, most seem to be more or
less editorial, except for one technical issue:

>        16 labels (i.e., purge the 16th dot from the left and everything

I think our wording is correct.  We want to strip 64 bits (from 128 total).
These 64 bits correspond to 16 hexadecimal digits, called labels in DNS speak,
each separated by a dot.

Does this make sense to you?

Thanks again!
Sebastian

---

From: "Y. Richard Yang" <[email-masked]>
Date: Thu, 20 Jul 2017 10:47:06 +0200

Hi Sebastian,

Indeed. Most comments are editorial as your draft is very well written
already. The main issues which may become non-editorial are (1) whether to
make the demarcation points flexible; (2) some more discussions on the
mapping between prefix and information mapping. I will be more than happy
to send a few more sentences right after this ietf.

Regarding the 64 bits example. What if the prefix is say 65 bits. It looks
that the nested if will skip it. Do I misunderstand?

Richard

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

---

From: Sebastian Kiesel <[email-masked]>
Date: Thu, 20 Jul 2017 10:55:04 +0200

Hi Richard,

> to send a few more sentences right after this ietf.

Looking forward to see a text proposal!

Regarding (1): our goal was to have a simple and well-defined algorithm
which causes as few as possible load on the DNS - the demarcation points
are following the usual prefix lengths that registries delegate.

> that the nested if will skip it. Do I misunderstand?

Well, a prefix length of /65 should not occur with "regular" IPv6
unicast ... Do we need to open tha can of worms about IPv4 addresses
encoded as v6 addresses etc.?

Thanks,
Sebastian