Comcast replies to -- Comcast files "recommended practices" draft RFC with IETF for DNS Redirection

[David Farber <dave () farber net>]

Begin forwarded message:

From: "Livingood, Jason" <Jason_Livingood () cable comcast com>
Date: July 9, 2009 10:59:55 PM EDT
To: Dave Farber <dave () farber net>, ip <ip () v2 listbox com>, <dpreed () reed com 
>
Subject: Re: [IP] Comcast files "recommended practices" draft RFC with  
IETF for DNS Redirection

Hi David – A few replies inline below.  I’m happy to take specific (by  
section, for example) and direct off-list feedback on this very early  
draft at jason_livingood () cable comcast com.

Regards
Jason


From: "David P. Reed" <dpreed () reed com>

 I note that this draft RFC proposes practices that routinely return  
*valid* responses to erroneous DNS lookups, and encourage an opt-out  
policy rather than an opt-in policy.

[JL] I tried to describe both opt-in and opt-out methods, as I think  
each approach could be valid depending upon the network or the  
individual use cases.  But in real networks, in most cases this is opt- 
out and I found some existing practices to either vary substantially  
or not be particularly friendly and/or persistent from the perspective  
of the end user.  So the first draft in that particular area is  
intended to start the conversation about the best ways to do opt-in,  
as well as the best ways to do opt-out.

 The sole justification is that the default way that a browser such  
as Firefox or IE would present an error message is inadequate for  
users, thus an ISP should take matters into its own hands to fix that  
cosmetic problem, rather than asking the browser vendors to do a  
better job!

[JL] Well, they’ve had a lot of time in that regard and the problem  
still exists.  Most new browsers solve this better, and I think it’s  
nice when the edge can handle it anyway (Chrome is very interesting in  
their approach with pre-fetching names as you type).  But reality is  
there are still an awful lot of people on rather old browsers.  I  
never cease to be amazed at this when looking at browser stats on some  
of my web sites, for example.

 And the side effects identified do not include the impact on http  
requests not generated by typing into web browsers, but instead used  
as part of "web 2.0" service apis and other uses of port 80 that do  
not arise from end users typing into the url bar of their browser.

[JL] I’m definitely looking for more information on these concerns and  
I would like to very, very specifically document them in subsequent  
versions of the draft.  I’m happy to take as many specific examples as  
you or others might be able to offer.  (see my email addr above)

The potential to disrupt non web-browser features is noted in the  
"draft RFC", but instead of a balanced analysis of benefits and costs  
to other uses, the draft is silent.  In fact, the draft refers to this  
as "enhanced" functionality.

[JL] As noted above, I’m happy to record as many specific use cases of  
concern as folks can provide, and to try to address those in future  
updates.  Whenever I ask this, though, I am usually met with silence  
and no one can provide me with specific example — and I can’t really  
solve or avoid a problem unless I can really define it, as I know you  
know from experience.

 I expect the wiser heads at the IETF to prevail....  This is a  
solution to a non-existent "problem", with bad side effects.

[JL] I am under no illusions about the concerns related to DNS  
redirect.  But the reality is, like it or not, this is a pretty  
widespread practice in the Internet community.  Given that is the  
case, I thought it might benefit the community to (1) informationally  
describe how the heck these systems function, and (2) describe how  
these systems might best be operated in a transparent, user-friendly,  
application-friendly manner.  And if there are use cases that cause  
grievous problems, well I want to document them and describe how to  
avoid them if I can.

[JL] I’d also like you and others to bear in mind that this is but a  
first draft and that there will be many revisions to come (one of my I- 
Ds that is moving towards RFC status is on the –10 version and I think  
another is on –16) over what is probably a one to three year period of  
comment and regular revision.  Thus, this draft is not an end point  
but a starting point for comment.

 While this is not exactly the same as directing a misdialed phone  
call to call a Caribbean phone company number with the consequent  and  
unavoidable billing charge to the user, it seems very close to that  
sort of thing - a surprise to all application developers, and a  
modification to the expected semantics of directory lookup.

[JL] Except of course, the user (1) isn’t being charged when they  
enter an invalid domain and (2) is being offered suggestions on what  
site they may have intended to visit rather than automatically being  
directed there (following your analogy).  Also, it is difficult to see  
how this may surprise app developers, as this is a practice that has  
been in place at many large ISPs for years now; we’re basically among  
the last to implement it (we just happen to be more transparent about  
it — which you might note as a bit of hard-earned learning).  A more  
apt analogy in the telephony world might be that you dial a phone  
number that is invalid and does not work, you get a network  
announcement that “We’re sorry but the telephone number you dialed is  
not in service...” and it then continues to say, “this number is  
similar to 123-555-1212 and 456-555-1212.  To be automatically  
connected to the first number, press 1 now, and the second number,  
press 2 now.  Or, say press 3 to connect to directory assistance and  
speak the city/state and name of the listing you’d like to connect  
to.  Otherwise, please hang up and try dialing your call again.”




-------------------------------------------
Archives: https://www.listbox.com/member/archive/247/=now
RSS Feed: https://www.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com