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!]
====
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
