[alto] Review on draft-kiesel-alto-xdom-disc-02

Gao Kai <gaok12@mails.tsinghua.edu.cn> Wed, 13 July 2016 05:46 UTC

To: IETF ALTO <alto@ietf.org>
From: Gao Kai <gaok12@mails.tsinghua.edu.cn>
Message-ID: <5785D5C6.3070903@mails.tsinghua.edu.cn>
Date: Wed, 13 Jul 2016 13:46:46 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------080503040909030101030708"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/SbFtzE_Xen6wULDyt8Nmn5gLo28>
Subject: [alto] Review on draft-kiesel-alto-xdom-disc-02
Precedence: list

Dear Sebastian and all,

I think this draft can be a good extension to RFC 7286.  The process
described
in Section 2 is based on the discovery method standardized in RFC 7286 using
NAPTR records, which is already implemented in current DNS servers such
as ISC
bind and DNSMASQ, and uses the reverse DNS lookup to query the "nearby" ALTO
server of an arbitrary IP address, which makes cross-domain discovery
possible.
The mechanism is very simple and easy to deploy.

However, I have a few questions:

1.  The approach requires an IP address but the meaning of the IP
address is not
    very clear.  It can either be the address of the ALTO client, which
    represents the "nearest" ALTO server to the client, or the address in a
    query (source or destination), which represents the capability to
handle the
    queries.  This might be important which can effect the ALTO servers'
    behaviours.  With the first semantic, similar to LIS, the ALTO
server may
    just register the NAPTR records with domain names constructed from
its own
    IP address, while with the second semantic, the ALTO servers may try to
    register records for multiple prefixes.

2.  I am not sure but it seems that one DNS record belongs to a single
entity.
    What if there are multiple ALTO servers with common prefixes?

3.  For location services, it is easy to make the assumption that the
closer a
    server is to the client, the more accurate the information can be. 
However,
    this may not always be true for ALTO services, especially for
cross-domain
    queries.  For example, a local server may have only partial network
    information while a upstream server may have a more complete view which
    results in more accurate routing costs.

These problems might be trivial at the time because it is unlikely that
many ALTO
servers are running in the same domain now and I think the method
introduced in the
draft can be a good start. However, we may still need to find more
sophisticated
mechanisms, probably as the draft mentioned, a "search engine" for
ALTOservices.

The discussion in Section 3 is more related to the information
aggregation of
multiple ALTO servers.  Personally I think it can be very difficult to
aggregate
answers from different ALTO servers without standard units, especially
by making
partial queries.

p.s. A typo in the draft: Section 2.3, paragraph 2 line 3: Extra "in the".

Regards,
Kai

[alto] Review on draft-kiesel-alto-xdom-disc-02 Gao Kai