Subject: Re: [alto] [Alto-disc] [Fwd: New Version Notification fordraft-song-alto-server-discovery-01]

From: Song Haibin <[email-masked]>
Date: Mon, 13 Jul 2009 15:24:36 +0800

Hi,
 
Here is the link for the merged document. More comments are appreciated!
 
http://tools.ietf.org/id/draft-song-alto-server-discovery-01.txt
<BLOCKED::http://tools.ietf.org/id/draft-song-alto-server-discovery-01.txt> 

Thanks!
Haibin

  _____  

From: [email-masked]
[mailto:[email-masked]] On Behalf Of TOMSU, Marco
Sent: Monday, July 13, 2009 2:37 PM
To: [email-masked]; [email-masked]
Subject: [Alto-disc] [Fwd: New Version Notification
fordraft-song-alto-server-discovery-01]

FYI

CU,
  Marco

-------- Original-Nachricht --------
Betreff:        New Version Notification for
draft-song-alto-server-discovery-01
Datum:  Sun, 12 Jul 2009 18:01:11 -0700 (PDT)
Von:    IETF I-D Submission Tool <[email-masked]>
An:     [email-masked]
CC:     [email-masked], [email-masked],
[email-masked], [email-masked]

A new version of I-D, draft-song-alto-server-discovery-01.txt has been
successfuly submitted by Song Yongchao and posted to the IETF repository.

Filename:        draft-song-alto-server-discovery
Revision:        01
Title:           ALTO Service Discovery
Creation_date:   2009-07-11
WG ID:           Independent Submission
Number_of_pages: 20

Abstract:
Application-Layer Traffic Optimization (ALTO) service aims to provide
distributed applications with information to perform better-than-
random initial peer selection when multiple peers in the network are
available to provide a resource or service.  In order to discover an
Application-Layer Traffic Optimization (ALTO) Server, a set of
mechanisms are required.  These mechanisms enable applications to
find an information source which provides them with information
regarding the underlying network.  This document discusses various
scenarios of ALTO discovery and specifies the use of several
available options such as DHCP or DNS.

The IETF Secretariat.

---

From: "TOMSU, Marco" <[email-masked]>
Date: Mon, 13 Jul 2009 08:36:37 +0200

FYI

CU,
  Marco

-------- Original-Nachricht --------
Betreff: 	New Version Notification for draft-song-alto-server-discovery-01
Datum: 	Sun, 12 Jul 2009 18:01:11 -0700 (PDT)
Von: 	IETF I-D Submission Tool <[email-masked]>
An: 	[email-masked]
CC: 	[email-masked], [email-masked], 

A new version of I-D, draft-song-alto-server-discovery-01.txt has been successfuly submitted by Song Yongchao and posted to the IETF repository.

Abstract:

The IETF Secretariat.

---

From: John Leslie <[email-masked]>
Date: Mon, 13 Jul 2009 08:28:57 -0400

> http://tools.ietf.org/id/draft-song-alto-server-discovery-01.txt

   One quick comment:
] 
] 5.1.2.1.  Using DHCP option for access domain name
] 
]  There are DHCP options (OPTION_V4_ACCESS_DOMAIN and
]  OPTION_V6_ACCESS_DOMAIN) proposed in [I-D.ietf-geopriv-lis-discovery]
]  to discover the local access domain names.  The retrieved access
]  domain name can be used to form a SRV name by prefixing the ALTO
]  service label to the access domain name.  If it failed with the SRV
]  lookup with this service name, then it will remove one tag from the
]  left hand of the access domain name and prefix the ALTO service label
]  to form a new SRV name.  It will iterate the process until it
]  succeeds in getting an ATLO server information or failed.

   This iterative process can lead to problems, both in that it will
search towards Top-Level-Domains that have no relation to the network
to which the host is actually attached, and in that (if ALTO usage grows)
it could generate excessive (and pointless) DNS queries at or near the
Top-Level-Domain servers.

   In particular, note that many of the .us locality servers have
limited bandwidth; and I'm sure there are other Country-Code servers
whose bandwidth is even more limited.

   I recommend caution in applying this strip-the-leftmost tactic even
once, and strongly recommend against applying it iteratively without
limit.

   If used at all, there is a need for a standardized signal to say
"Search no further".

--
John Leslie <[email-masked]>

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 13 Jul 2009 18:56:56 -0500

+1

We once proposed exactly the same mechanism.  It wasn't popular.

There's no reason why the parent domain has any particular ability to provide the information you are looking for.  Add to that the cases John pointed to where it's going to do harm, and you end up in trouble.

There's a tendency to think of the DNS hierarchy as mapping to other hierarchical systems, such as the networks linking a host to the Internet.  This is demonstrably not the case.  There's an (IAB?) RFC that covers the topic, but I can't remember its number nor find it; I'll leave that to the experts.  

--Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> John Leslie
> Sent: Monday, 13 July 2009 10:29 PM
> To: Song Haibin
> Cc: [email-masked]; 'TOMSU, Marco'; [email-masked]
> Subject: Re: [alto] [Alto-disc] [Fwd: New Version Notificationfordraft-
> song-alto-server-discovery-01]
> 
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Song Haibin <[email-masked]>
Date: Wed, 15 Jul 2009 15:52:56 +0800

I understand your question. It's good. I think an ISP could probaly register
the SRV record of the local ALTO server to each of the DNS server for the
access network domain (that retrieved from the DHCP option) that this
particular ALTO server covers. Then it does not need to do this kind of
strip leftmost iterative lookup.

Initially, I had thought of mapping IP addresses to domain names using
reverse lookup of DNS (just like BEP-22), but that domain name may not be
relative to your access network. So it will bring problems if the ALTO
server provider (ISP) wants to register its ALTO server record to that
domain.

Thanks!

Haibin

>From: Thomson, Martin [mailto:[email-masked]] 
>Sent: Tuesday, July 14, 2009 7:57 AM
>To: John Leslie; Song Haibin
>Cc: [email-masked]; TOMSU, Marco; [email-masked]
>Subject: RE: [alto] [Alto-disc] [Fwd: New Version 
>Notificationfordraft-song-alto-server-discovery-01]
>
>+1
>
>There's no reason why the parent domain has any particular 
>ability to provide the information you are looking for.  Add 
>to that the cases John pointed to where it's going to do harm, 
>and you end up in trouble.
>
>There's a tendency to think of the DNS hierarchy as mapping to 
>other hierarchical systems, such as the networks linking a 
>host to the Internet.  This is demonstrably not the case.  
>There's an (IAB?) RFC that covers the topic, but I can't 
>remember its number nor find it; I'll leave that to the experts.  
>
>--Martin
>
>> From: [email-masked] [mailto:[email-masked]] On Behalf 
>> Of John Leslie
>> Subject: Re: [alto] [Alto-disc] [Fwd: New Version 
>> Notificationfordraft- song-alto-server-discovery-01]
>> 
>> ] 5.1.2.1.  Using DHCP option for access domain name ] ]  There are 
>> DHCP options (OPTION_V4_ACCESS_DOMAIN and ]  
>OPTION_V6_ACCESS_DOMAIN) 
>> proposed in [I-D.ietf-geopriv-lis- discovery] ]  to discover 
>the local 
>> access domain names.  The retrieved access ]  domain name 
>can be used 
>> to form a SRV name by prefixing the ALTO ]  service label to the 
>> access domain name.  If it failed with the SRV ]  lookup with this 
>> service name, then it will remove one tag from the ]  left 
>hand of the 
>> access domain name and prefix the ALTO service label ]  to 
>form a new 
>> SRV name.  It will iterate the process until it ]  succeeds 
>in getting 
>> an ATLO server information or failed.
>>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 30 Jul 2009 11:52:21 +0200

On Mon, Jul 13, 2009 at 06:56:56PM -0500,
 Thomson, Martin <[email-masked]> wrote 
 a message of 79 lines which said:

> There's an (IAB?) RFC that covers the topic, but I can't remember
> its number nor find it;

Probably RFC 1535  "A Security Problem and Proposed Correction With
Widely Deployed DNS Software"