Subject: [p2p-sip] DNS for inter-domain? Yes; intra-domain? No

From: eunsooshim at gmail.com (Eunsoo Shim)
Date: Tue, 5 Dec 2006 10:05:37 -0500

It is not easy for me to follow every details of the current hot debate
about DNS for P2P SIP.
Though, it seems to me that one thing is confusing, at least, some of us.
Some of us may remember the presentation on a two-layer P2P SIP architecture
back in the ad-hoc meeting in Dallas.
http://www.p2psip.org/ietf-65/IETF65_P2PSIP_BOF_P2P_SIP_Architecture_Shim.pdf

Slide 4 of the presentation shows how various P2P SIP domains can
interconnect.
Two choices were shown in the slide - Inter-domain P2P overlay and DNS.
Actually later the authors of the draft proposed only DNS for P2P SIP domain
interconnections.

Take a look at also the slides presented by Dean during the first BOF in
Dallas.
http://www.p2psip.org/ietf-65/IETF65_P2PSIP_BOF_Charter_Willis.pdf
See Assumption 4 and 5.

So, if someone wants to set up her/his own P2P SIP domain and interconnect
with other P2P SIP domains, she/he just needs to register the proxy for the
domain with DNS.
Peers of other domains will find the proxy via DNS.
If this is what the current debate is about, I think actually there is not
much difference among people.

However, for intra-domain lookup, some of us think we need to develop a DHT
(or DHT-like) protocol for P2P SIP.
Using DNS for intra-domain lookup is not different from using a central
location server.
The client/server SIP architecture already assumes such a central location
server for each domain.
So my understanding is that what P2PSIP group is trying to do is designing
mechanisms for P2P-style intra-domain location lookup where location records
are distributed among peers rather than in a central location server. A DNS
server is just another type of such a central server.

Am I missing any important aspect?

Thanks.

Eunsoo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061205/6b5230e0/attachment.html

---

From: dbarrett at quinthar.com (David Barrett)
Date: Tue, 5 Dec 2006 13:41:18 -0800

_____  

From: Eunsoo Shim
Subject: [p2p-sip] DNS for inter-domain? Yes; intra-domain? No

So my understanding is that what P2PSIP group is trying to do is designing
mechanisms for P2P-style intra-domain location lookup where location records
are distributed among peers rather than in a central location server.

.

I agree, this is what P2P-SIP is trying to do.  I'm just not certain why,
because mDNS can do the same thing in a way that is already standardized,
already deployed, and already works.  Basically, for every real-world case,
it seems mDNS is adequate for ad-hoc unauthenticated namespaces, and DNS is
adequate for global, authenticated namespaces.  There is already a seamless
interface to graduate from mDNS to DNS depending upon what is available; it
already covers the whole range of use cases (minus the extreme security
cases, which I believe remain unsolved problems by any means).

I don't dispute you could make a DHT bootstrapped with UPnP or whatever.
You can build a lot of things.  I just don't see why we should bother when
there are easier, adequate technologies available.

-david

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061205/ef131e88/attachment.html

---

From: eunsooshim at gmail.com (Eunsoo Shim)
Date: Tue, 5 Dec 2006 18:04:27 -0500

I understand that mDNS can be used in ad-hoc networks where multicast works.
Some of us, including me, have discussed about using mDNS and noticed that
there is little to do to use mDNS or any other multicast-based discovery
protocol.
Those people decided not to focus on the approach because assuming multicast
availability was not general and they did not want to limit P2PSIP into such
network environments.
They said such an approach (using mDNS or similar ones) could be discussed
maybe in SIPPING.

The proposed charter is targeting to address intra-domain lookup that works
even if there is no multicast support.

Using DNS for intra-domain lookup is not different from using a central
server, which is not interesting to many of us, I believe. So transition
from mDNS to DNS is not appealing, either.

What do you say?
Thanks.

Eunsoo

On 12/5/06, David Barrett <dbarrett at quinthar.com> wrote:
>
>
>   ------------------------------
>
> *From:* Eunsoo Shim
> *Subject:* [p2p-sip] DNS for inter-domain? Yes; intra-domain? No
>
>
>
> ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061205/540d24ec/attachment-0001.html

---

From: dbarrett at quinthar.com (David Barrett)
Date: Tue, 5 Dec 2006 16:02:02 -0800

Does the actual, real-world availability of multicast factor into the
decision as to whether or not to use it?

I mean, we *could* assume that every odd IP address won't work, and then
design around that.  But odd IP addresses *do* work.

Likewise, multicast *is* (or could easily be made) available for all of the
real-world use cases that demand it.

It just seems like there are much more interesting *actual* problems to
solve than those that don't affect real users.  But if you're excited about
solving the non-multicast ad-hoc P2P-SIP problem on the assumption that
someday, somebody will have reason to use it (even though we can't really
brainstorm anybody who would use it today), then I guess that's a cool
research project.

But it's a *research* project, not an IETF standardization exercise.  DNS
and mDNS work everywhere the *actual* users are, and thus I think the IETF
should focus on them, first.

-david

  _____  

From: Eunsoo Shim [mailto:eunsooshim at gmail.com] 
Sent: Tuesday, December 05, 2006 3:04 PM
To: David Barrett
Cc: P2P-SIP
Subject: Re: [p2p-sip] DNS for inter-domain? Yes; intra-domain? No

What do you say?
Thanks.

Eunsoo

  _____  

From: Eunsoo Shim 

.

-david

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061205/52c1335a/attachment.html

---

From: hgs at cs.columbia.edu (Henning Schulzrinne)
Date: Tue, 5 Dec 2006 19:20:15 -0500

I have to admit that I'm confused by this whole discussion. I thought  
we had agreement that

(1) specifying mDNS + SIP operation is useful (and hopefully simple),  
but easily handled within the framework of SIPPING;

(2) specifying dynamic DNS + SIP might be useful, subject to working  
out issues such as proxy discovery, authentication and the like and  
that interested parties should work out, at least to the extent of  
identifying the pieces that might need work (as a random example: can  
I expect my SIP Digest secret to work as a DNS update secret?). If,  
as claimed, this is easy to do, SIPPING is again the natural home for  
such a BCP effort, with the DNS-related WGs as the home for any DNS  
extensions that might prove necessary.

Maybe those individuals interested in solving (2) should form an  
informal design team and get beyond the hand-waving stage and  
identify the problems, if any, that would have to be addressed in  
either protocol or operational standards. I have unfortunately seen  
little such effort so far, although I suspect that such level of  
detail isn't terribly well suited to be hashed out in front of  
several hundred mailing list members.

We also have had 2 BOFs and numerous ad-hoc meetings on this topic,  
with a rough consensus on the current charter. Are you trying to keep  
people from working on a specific topic you consider inferior?

We seem to be rehashing the same arguments again and again.

Henning

On Dec 5, 2006, at 7:02 PM, David Barrett wrote:

> Does the actual, real-world availability of multicast factor into  
> the decision as to whether or not to use it?
>
>
>
> I mean, we *could* assume that every odd IP address won?t work, and  
> then design around that.  But odd IP addresses *do* work.
>
>
>
> Likewise, multicast *is* (or could easily be made) available for  
> all of the real-world use cases that demand it.
>
>
>
> It just seems like there are much more interesting *actual*  
> problems to solve than those that don?t affect real users.  But if  
> you?re excited about solving the non-multicast ad-hoc P2P-SIP  
> problem on the assumption that someday, somebody will have reason  
> to use it (even though we can?t really brainstorm anybody who would  
> use it today), then I guess that?s a cool research project.
>
>
>
> But it?s a *research* project, not an IETF standardization  
> exercise.  DNS and mDNS work everywhere the *actual* users are, and  
> thus I think the IETF should focus on them, first.
>
>
>
> -david
>
>
>
> Some of us, including me, have discussed about using mDNS and  
> noticed that there is little to do to use mDNS or any other  
> multicast-based discovery protocol.
> Those people decided not to focus on the approach because assuming  
> multicast availability was not general and they did not want to  
> limit P2PSIP into such network environments.
> They said such an approach (using mDNS or similar ones) could be  
> discussed maybe in SIPPING.
>
> The proposed charter is targeting to address intra-domain lookup  
> that works even if there is no multicast support.
>
> Using DNS for intra-domain lookup is not different from using a  
> central server, which is not interesting to many of us, I believe.  
> So transition from mDNS to DNS is not appealing, either.
>
> What do you say?
> Thanks.
>
> Eunsoo
>
> So my understanding is that what P2PSIP group is trying to do is  
> designing mechanisms for P2P-style intra-domain location lookup  
> where location records are distributed among peers rather than in a  
> central location server.
>
> ?
>
> I agree, this is what P2P-SIP is trying to do.  I'm just not  
> certain why, because mDNS can do the same thing in a way that is  
> already standardized, already deployed, and already works.   
> Basically, for every real-world case, it seems mDNS is adequate for  
> ad-hoc unauthenticated namespaces, and DNS is adequate for global,  
> authenticated namespaces.  There is already a seamless interface to  
> graduate from mDNS to DNS depending upon what is available; it  
> already covers the whole range of use cases (minus the extreme  
> security cases, which I believe remain unsolved problems by any  
> means).
>
>
>
> I don't dispute you could make a DHT bootstrapped with UPnP or  
> whatever.  You can build a lot of things.  I just don't see why we  
> should bother when there are easier, adequate technologies available.
>
>
>
> -david
>
>
>
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061205/7ffc85ac/attachment-0001.html

---

From: br at brianrosen.net (Brian Rosen)
Date: Tue, 5 Dec 2006 20:08:08 -0500

I?ve spent a good deal of time dealing with systems that depend on multicast
and I conclude that multicast is a very wonderful thing, every network can,
and should support it, and almost none actually do.

Multicast DOES NOT work in 99.9% of networks beyond a subnet.  It?s a lot
more than a research project to fix that.  IPTV may cause some networks to
allow multicast in some very restricted circumstances.  It's a step, but you
won't be able to use mDNS within those networks as I understand deployment
plans.

I think in some really interesting ad-hoc networks we may be able to deploy
multicast.  I would not be willing to place bets on that.  They certainly
don't support it now.

Brian

________________________________________
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David Barrett
Sent: Tuesday, December 05, 2006 7:02 PM
To: 'Eunsoo Shim'
Cc: 'P2P-SIP'
Subject: Re: [p2p-sip] DNS for inter-domain? Yes; intra-domain? No

I mean, we *could* assume that every odd IP address won?t work, and then
design around that.? But odd IP addresses *do* work.

It just seems like there are much more interesting *actual* problems to
solve than those that don?t affect real users.? But if you?re excited about
solving the non-multicast ad-hoc P2P-SIP problem on the assumption that
someday, somebody will have reason to use it (even though we can?t really
brainstorm anybody who would use it today), then I guess that?s a cool
research project.

But it?s a *research* project, not an IETF standardization exercise.? DNS
and mDNS work everywhere the *actual* users are, and thus I think the IETF
should focus on them, first.

-david

________________________________________
From: Eunsoo Shim [mailto:eunsooshim at gmail.com] 
Sent: Tuesday, December 05, 2006 3:04 PM
To: David Barrett
Cc: P2P-SIP
Subject: Re: [p2p-sip] DNS for inter-domain? Yes; intra-domain? No

What do you say?
Thanks.

Eunsoo
________________________________________

Am I missing any important aspect?
I agree, this is what P2P-SIP is trying to do.? I'm just not certain why,
because mDNS can do the same thing in a way that is already standardized,
already deployed, and already works.? Basically, for every real-world case,
it seems mDNS is adequate for ad-hoc unauthenticated namespaces, and DNS is
adequate for global, authenticated namespaces.? There is already a seamless
interface to graduate from mDNS to DNS depending upon what is available; it
already covers the whole range of use cases (minus the extreme security
cases, which I believe remain unsolved problems by any means).
?
I don't dispute you could make a DHT bootstrapped with UPnP or whatever.?
You can build a lot of things.? I just don't see why we should bother when
there are easier, adequate technologies available.
?
-david

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Tue, 5 Dec 2006 20:25:34 -0500

This discussion ended a long time ago and it is now just a game of
loop-de-loop trolling.

---

From: matthew at matthew.at (Matthew Kaufman)
Date: Tue, 5 Dec 2006 18:02:11 -0800

Brian RosenL
>
> Multicast DOES NOT work in 99.9% of networks beyond a subnet.  

Agreed. Absolutely.

> I think in some really interesting ad-hoc networks we may be able to
> deploy multicast.  I would not be willing to place bets on that.
> They certainly don't support it now.

All of the ad-hoc network scenarios that have been proposed are confined to
a single subnet, on which multicast will work. Therefore, on those networks
and in those use cases, zeroconf mDNS (not to be confused with network-wide
multicast DNS, about which I am not talking) will work.

Any ad-hoc network that is built which is larger will need to be built with
DHCP servers on each subnet which can provide the gateway address *and* DNS
server addresses pointing at local DNS servers which will also need to be
set up... and I say *need* to be set up because without that level of
infrastructure, a routed ad-hoc network can't run any of the *other*
applications it would have been deployed to support (web intranet access,
email, etc.) If those DNS servers can accept dynamic updates or are manually
configured appropriately, that covers the other half of the problem.

While it is clear that the mailing list has morphed from "discussion of
peer-to-peer issues with SIP" into "the official mailing list of a working
group which is set on using a DHT because that's what 'P2P' means to them",
the first topic could still be interesting. Maybe one of the subsets of
people should find a new mailing list.

Matthew Kaufman
matthew at matthew.at

---

From: dbarrett at quinthar.com (David Barrett)
Date: Wed, 6 Dec 2006 00:07:39 -0800

I think the value of this discussion is in identifying and clarifying
misimpressions about how DNS and mDNS work (and do not work) so we can make
a more informed choice on whether or not to use them.  Already we've
clarified:

-          How can DNS records be automatically updated? (Through dynamic
DNS protocols)

-          How fast can DNS propagate?  (Extremely fast with short TTLs)

-          What if I have multiple SIP proxies? (Put multiple IPs into the
DNS record)

-          Is DNS only for IP addresses? (No, can store other records)

-          How does DNS work in on ad-hoc networks? (Using mDNS via
multicast)

-          Where is multicast supported? (Only everywhere it's needed - on
subnets)

-          Is mDNS an IETF standard? (It's on the standards track.)

-          Is mDNS actually in use? (It's the foundation of zeroconf, which
is used extensively by Apple)

-          Are there any use-cases that DHT supports that DNS/mDNS cannot?
(Apparently not.)

Lack of clarity on these points could call for the unnecessary dismissal of
these technologies on false premises, which I think nobody wants.

-david

  _____  

From: Henning Schulzrinne [mailto:hgs at cs.columbia.edu] 
Sent: Tuesday, December 05, 2006 4:20 PM
To: David Barrett
Cc: 'Eunsoo Shim'; 'P2P-SIP'
Subject: Re: [p2p-sip] DNS for inter-domain? Yes; intra-domain? No

I have to admit that I'm confused by this whole discussion. I thought we had
agreement that

(1) specifying mDNS + SIP operation is useful (and hopefully simple), but
easily handled within the framework of SIPPING;

(2) specifying dynamic DNS + SIP might be useful, subject to working out
issues such as proxy discovery, authentication and the like and that
interested parties should work out, at least to the extent of identifying
the pieces that might need work (as a random example: can I expect my SIP
Digest secret to work as a DNS update secret?). If, as claimed, this is easy
to do, SIPPING is again the natural home for such a BCP effort, with the
DNS-related WGs as the home for any DNS extensions that might prove
necessary.

Maybe those individuals interested in solving (2) should form an informal
design team and get beyond the hand-waving stage and identify the problems,
if any, that would have to be addressed in either protocol or operational
standards. I have unfortunately seen little such effort so far, although I
suspect that such level of detail isn't terribly well suited to be hashed
out in front of several hundred mailing list members.

We also have had 2 BOFs and numerous ad-hoc meetings on this topic, with a
rough consensus on the current charter. Are you trying to keep people from
working on a specific topic you consider inferior?

Henning

-david

  _____  

What do you say?
Thanks.

Eunsoo

  _____  

From: Eunsoo Shim 

.

-david

p2p-sip mailing list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061206/aa60b5ae/attachment-0001.html

---

From: tme at multicasttech.com (Marshall Eubanks)
Date: Wed, 6 Dec 2006 11:34:56 -0500

Hello;

> Multicast DOES NOT work in 99.9% of networks beyond a subnet.  It?s  

I actually monitor this, and it's more like 3 % (to a factor of 2 or  
3), see

http://www.multicasttech.com/status

The only place where support is decent is in the NREN/academic  
network world.

There is also the AMT automatic tunneling proposal, which comes close  
to P2P :
http://www.ietf.org/internet-drafts/draft-ietf-mboned-auto- 
multicast-07.txt

> won't be able to use mDNS within those networks as I understand  

Not generally; these are typically NBMA networks.

> multicast.  I would not be willing to place bets on that.  They  

There is a lot of talk about it...

> Brian

Regards
Marshall

> then
> problems to
> solve than those that don?t affect real users.  But if you?re  
> excited about
> exercise.  DNS
> noticed that
> multicast
> central
> designing
> certain why,
> security
> whatever.

---

From: hgs at cs.columbia.edu (Henning Schulzrinne)
Date: Wed, 6 Dec 2006 12:38:06 -0500

> -          Is mDNS an IETF standard? (It?s on the standards track.)
>
> -
As far as I know, this is not true. (The draft says "standards  
track", but that's a self-declaration.)

https://datatracker.ietf.org/public/idindex.cgi? 
command=id_detail&id=9784

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061206/76276f63/attachment.html

---

From: tme at multicasttech.com (Marshall Eubanks)
Date: Wed, 6 Dec 2006 14:04:42 -0500

There was a long discussion about this on the IETF list last year. I  
am attaching the
letter from Stuart Cheshire that started it; I think it explains the  
relationship between
various protocols and proposals pretty well, except that LLMNR is  
part of Vista

http://www.microsoft.com/technet/community/columns/cableguy/cg1106.mspx

Regards
Marshall

> command=id_detail&id=9784

	From: 	  cheshire at apple.com
	Subject: 	Re: Last Call: 'Linklocal Multicast Name Resolution  
(LLMNR)' to Proposed Standard
	Date: 	August 25, 2005 1:37:42 AM EDT
	To: 	  iesg at ietf.org, ietf at ietf.org

> The IESG has received a request from the DNS Extensions WG to consider
> the following document:
>
> - 'Linklocal Multicast Name Resolution (LLMNR) '
>   <draft-ietf-dnsext-mdns-42.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> iesg at ietf.org or ietf at ietf.org mailing lists by 2005-08-24.
>

My question about this document is one I've asked before in private;
it's time now that it was asked publicly.

What is this document for? No one has implemented this LLMNR  
protocol. No
one has any plans to implement this protocol. No company plans to ship
products using this protocol. Even Microsoft has not even hinted at  
plans
to use LLMNR in Longhorn/Vista. All of Microsoft's hype in this area
centers on a naming protocol they call Peer Name Resolution Protocol
(PNRP). Noah Horton, Program Manager in charge of PNRP, says, "PNRP  
is in
Windows Vista Beta 1. It is there and it is beautiful."

<http://blogs.msdn.com/noahh/archive/2005/08/11/450535.aspx>

I see no similar gossip surrounding LLMNR in Vista. In fact, a Google
search for "LLMNR Windows Vista" finds just twelve hits. A typical burst
of line noise finds more Google hits than that. Eleven of those hits are
accidental -- copies of the IANA port number list. I found only one hit
that looked like a plausible relevant match, but when I followed the  
link
it was an article that begins:

> Say "howdy" to Bonjour
> Apple's zero-config scheme leaves Microsoft and UPnP in the dust
>

<http://www.infoworld.com/article/05/06/03/23TCtigerSB_1.html>

So, what's LLMNR for, if no one actually wants to implement it?

I have my guess, but it's best explained by a brief bit of history:

Back in 1997 I attended a presentation at Stanford about SLP. I was
stunned by all the really obvious flaws it had. I wrote up a critique of
SLP and suggested that Apple should just implement the tried-and-true
AppleTalk Name Binding Protocol (NBP) running over IP Multicast. Partly
as a result of that and other similar things, Apple later hired me.

At an IETF social I discussed this idea of NBP/IP with Bill Woodcock. He
said that the IETF would reject any attempt to mix an AppleTalk protocol
with IP, but... if I could work out how to do the same thing using DNS
packets, then that would be much more acceptable to the IETF community.
It took me a little while, but I worked out how to encode the necessary
semantics in terms of standard DNS records and queries.

I proposed this idea, and was told I needed a working group. So, the
Zeroconf working group was created.

I proposed the idea again, and was told that it wasn't the charter of  
the
Zeroconf working group; I'd have to take it to DNSEXT.

I proposed the idea to DNSEXT and was told (and I quote):

     Multicast DNS... stupid idea.
     Zero Configuration... stupid idea.
     You all stupid people. You go away now please.

(To be fair to the speaker, he was not a native English speaker. My
attempt to say the same in Japanese would have been much less eloquent.
And at least he was honest about his position on the subject.)

So, the DNSEXT working group had made itself clear. They thought
Multicast DNS and DNS Service Discovery were stupid ideas, and would  
play
no part in doing anything that would help or encourage or facilitate
their creation.

So, I did go away. I designed the protocol, documented it in Internet
Drafts, solicited feedback, implemented the protocol, and shipped it  
in a
wide range of products. It's in Mac OS X 10.2, 10.3, and 10.4. It's in
Bonjour for Windows. It's in Apple's AirPort base stations, and it's  
what
lets them effortlessly share printers and stream music to your  
stereo. It
runs on Linux, Solaris, FreeBSD, and pretty much every other Unix
platform. Some Linux distributions already ship with it included. In
addition to Apple's own Open Source implementation, there are several
other competing Open Source implementations under various different
licenses. There are implementations in Java and Python and C#. It's in
your TiVos, your Axis network cameras, and Roku SoundBridges. It's in
pretty much any recent network printer made by HP, Canon, Brother,  
Xerox,
Lexmark, Epson (and probably other vendors I'm forgetting right now). It
was in the printers being used in the IETF terminal room at IETF 63 in
Paris, and if you work in any reasonably large organization that's  
bought
a network printer in the last year or two then it's probably running on
your network right now. If you only have Windows machines, then you're
not out of luck -- you can discover those printers using Bonjour for
Windows:

<http://www.apple.com/bonjour/>.

It is, though I say it myself, a huge success.

What is DNSEXT's response to this? Well, it was clear that the original
plan, ignoring mDNS and hoping it would die on its own, had failed. What
they needed was an IETF antibody. A decoy. A honey pot. Something to go
out and compete against mDNS in the marketplace of ideas. Something that
would have the appearance of being the "official" successor to mDNS, a
siren to lure potential implementers onto the rocks.

Now, I can already hear a certain minority saying, "You've convinced me.
LLMNR should be published as an IETF Standard. Apple's heresy must be
stopped at any cost."

The question for the wider IETF community is whether that's what the  
IETF
wants to do. Is the role of the IETF to foster interoperability, or to
sabotage it? Are Internet Standard RFCs supposed to be useful things to
be implemented, or are they supposed to be traps to ensnare the
uninformed?

It reminds me of OSI. We had a perfectly good networking protocol --
TCP/IP -- so ISO decided they needed to make their own
similar-but-not-quite-the-same protocol to compete with it, just for the
sake of not wanting to adopt something invented elsewhere. ISO thought
that because they were an "official standards body", whereas TCP/IP was
just something that a bunch of guys had made that happened to work, that
ISO could, by legislative fiat, oust the successful incumbent protocol.
How many man-years of work were wasted by that abortive effort? Did OSI
emerge from that debacle looking good, or looking bad?

In fact, this comparison to OSI is overly generous. OSI was implemented
and actually worked. It was just unnecessary. The problem with LLMNR is
that it is deliberately limited to prevent it from being used for  
service
discovery, which, you may recall, was the whole motivation for beginning
this work in the first place. LLMNR is presented as being the "official"
sanctioned successor to mDNS, as if it were somehow equivalent in
functionality but better designed, while in fact it is so
self-contradictory and nonsensical that it actually does nothing useful
at all.

Time and time again LLMNR has come up for last call. Each time I read  
it,
and point out the fatal flaws and contradictions (that would have been
painfully obvious to anyone had they actually tried to implement it). A
few changes get made, and the document comes back around again. Piece by
piece I'm designing a protocol for my competitors, so they can use it to
compete with my own!

If the proponents of LLMNR are sincerely supporting it because they
believe it offers useful functionality (and I like to believe that's the
case), then lets see some actual implementations.

Whatever happened to "rough consensus and RUNNING CODE?"

Once we have some actual implementations to try out, then we can compare
them with mDNS and see what might be necessary (on both sides) to make
them interoperate usefully. I'm quite happy for LLMNR to be a compatible
subset of mDNS. What's silly is for LLMNR to be gratuitously  
incompatible
for the sake of being incompatible. Bernard Aboba has an FAQ Web site
where he writes:

<http://www.drizzle.com/~aboba/DNSEXT/llmnrfaq.html>

> Apple's mDNS protocol differs from LLMNR (and DNS) in more than
> half a dozen ways.
>

He then goes on to list a bunch of similarities like "Apple's mDNS does
not share the DNS cache", and finishes with:

> Apple mDNS and LLMNR use different ports, as well as different
> multicast addresses, and because of the many protocol
> differences, do not interoperate.
>

Isn't that circular logic? They use different ports and multicast
addresses because they're incompatible, but the main reason they're
incompatible is because they use different ports and multicast  
addresses?
Surely that particular incompatibility could be remedied easily, merely
by NOT choosing to use a different port and multicast address?

Stuart Cheshire <cheshire at apple.com>
  * Wizard Without Portfolio, Apple Computer, Inc.
  * www.stuartcheshire.org

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Wed, 6 Dec 2006 12:08:42 -0800

Great summary. Please see my feedback inline.

Peter
  ----- Original Message ----- 
  From: David Barrett 
  To: 'Henning Schulzrinne' 
  Cc: 'P2P-SIP' 
  Sent: Wednesday, December 06, 2006 12:07 AM
  Subject: Re: [p2p-sip] DNS for inter-domain? Yes; intra-domain? No

  I think the value of this discussion is in identifying and clarifying misimpressions about how DNS and mDNS work (and do not work) so we can make a more informed choice on whether or not to use them.  Already we've clarified:

  -          How can DNS records be automatically updated? (Through dynamic DNS protocols)

  [pp]: what is the cost and feasibility to upgrade existing DNS infrastructure to support dynamic DNS globally? is it similiar to the deployment of ipv6 and ip mobility?

  -          What if I have multiple SIP proxies? (Put multiple IPs into the DNS record)

  [pp]: can/will these DNS server also store data like voicemail or other p2p application data?

  -          How does DNS work in on ad-hoc networks? (Using mDNS via multicast)

  -          Where is multicast supported? (Only everywhere it's needed - on subnets)

  -          Is mDNS actually in use? (It's the foundation of zeroconf, which is used extensively by Apple)

  -          Are there any use-cases that DHT supports that DNS/mDNS cannot? (Apparently not.)

  Lack of clarity on these points could call for the unnecessary dismissal of these technologies on false premises, which I think nobody wants.

  -david

------------------------------------------------------------------------------

  I have to admit that I'm confused by this whole discussion. I thought we had agreement that

  (1) specifying mDNS + SIP operation is useful (and hopefully simple), but easily handled within the framework of SIPPING;

  (2) specifying dynamic DNS + SIP might be useful, subject to working out issues such as proxy discovery, authentication and the like and that interested parties should work out, at least to the extent of identifying the pieces that might need work (as a random example: can I expect my SIP Digest secret to work as a DNS update secret?). If, as claimed, this is easy to do, SIPPING is again the natural home for such a BCP effort, with the DNS-related WGs as the home for any DNS extensions that might prove necessary.

  Maybe those individuals interested in solving (2) should form an informal design team and get beyond the hand-waving stage and identify the problems, if any, that would have to be addressed in either protocol or operational standards. I have unfortunately seen little such effort so far, although I suspect that such level of detail isn't terribly well suited to be hashed out in front of several hundred mailing list members.

  We also have had 2 BOFs and numerous ad-hoc meetings on this topic, with a rough consensus on the current charter. Are you trying to keep people from working on a specific topic you consider inferior?

  Henning

  Does the actual, real-world availability of multicast factor into the decision as to whether or not to use it?

  I mean, we *could* assume that every odd IP address won't work, and then design around that.  But odd IP addresses *do* work.

  Likewise, multicast *is* (or could easily be made) available for all of the real-world use cases that demand it.

  It just seems like there are much more interesting *actual* problems to solve than those that don't affect real users.  But if you're excited about solving the non-multicast ad-hoc P2P-SIP problem on the assumption that someday, somebody will have reason to use it (even though we can't really brainstorm anybody who would use it today), then I guess that's a cool research project.

  But it's a *research* project, not an IETF standardization exercise.  DNS and mDNS work everywhere the *actual* users are, and thus I think the IETF should focus on them, first.

  -david

------------------------------------------------------------------------------

  I understand that mDNS can be used in ad-hoc networks where multicast works.
  Some of us, including me, have discussed about using mDNS and noticed that there is little to do to use mDNS or any other multicast-based discovery protocol. 
  Those people decided not to focus on the approach because assuming multicast availability was not general and they did not want to limit P2PSIP into such network environments.
  They said such an approach (using mDNS or similar ones) could be discussed maybe in SIPPING. 

  The proposed charter is targeting to address intra-domain lookup that works even if there is no multicast support.

  Using DNS for intra-domain lookup is not different from using a central server, which is not interesting to many of us, I believe. So transition from mDNS to DNS is not appealing, either. 

  What do you say?
  Thanks.

  Eunsoo

------------------------------------------------------------------------------

  From: Eunsoo Shim 

  So my understanding is that what P2PSIP group is trying to do is designing mechanisms for P2P-style intra-domain location lookup where location records are distributed among peers rather than in a central location server.

  .

  I agree, this is what P2P-SIP is trying to do.  I'm just not certain why, because mDNS can do the same thing in a way that is already standardized, already deployed, and already works.  Basically, for every real-world case, it seems mDNS is adequate for ad-hoc unauthenticated namespaces, and DNS is adequate for global, authenticated namespaces.  There is already a seamless interface to graduate from mDNS to DNS depending upon what is available; it already covers the whole range of use cases (minus the extreme security cases, which I believe remain unsolved problems by any means).

  I don't dispute you could make a DHT bootstrapped with UPnP or whatever.  You can build a lot of things.  I just don't see why we should bother when there are easier, adequate technologies available.

  -david

  p2p-sip mailing list

------------------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061206/ee96c34f/attachment-0001.html

---

From: dbarrett at quinthar.com (David Barrett)
Date: Wed, 6 Dec 2006 17:44:12 -0800

I'm not sure the DNS infrastructure needs much updating at all.  Perhaps
there will be more demand for DNS registrars to offer automated (aka
"dynamic") record updating, but that's really just standardizing what they
already do.

As for voicemail, no, I wouldn't expect to put that into DNS; that's
something best handled by some real storage provider.  You *could* do it in
a DHT, but it'd just be slower and less reliable, and the engineering cost
of building that would pay for central storage many, many times over.

Again, in a vacuum without taking anything else into consideration, be it
engineering cost, performance, reliability, existing systems, standards
support and so on, yes, a DHT could be used.  But when everything else is
factored in, it just makes no sense at all.

-david

  _____  

From: Peter Pan [mailto:huang-ming.pan at comcast.net] 
Sent: Wednesday, December 06, 2006 12:09 PM
To: David Barrett; 'Henning Schulzrinne'
Cc: 'P2P-SIP'
Subject: Re: [p2p-sip] DNS for inter-domain? Yes; intra-domain? No

Peter

----- Original Message ----- 

From: David Barrett <mailto:dbarrett at quinthar.com>  

To: 'Henning <mailto:hgs at cs.columbia.edu>  Schulzrinne' 

Cc: 'P2P-SIP' <mailto:p2p-sip at cs.columbia.edu>  

How can DNS records be automatically updated? (Through dynamic DNS
protocols)

-[pp]: what is the cost and feasibility to upgrade existing DNS
infrastructure to support dynamic DNS globally? is it similiar to the
deployment of ipv6 and ip mobility?

- What if I have multiple SIP proxies? (Put multiple IPs into the DNS
record)

Is DNS only for IP addresses? (No, can store other records)

-[pp]: can/will these DNS server also store data like voicemail or other p2p
application data?

- Is mDNS actually in use? (It's the foundation of zeroconf, which is used
extensively by Apple)

-david

  _____  

 

Henning

-david

  _____  

What do you say?
Thanks.

Eunsoo

  _____  

From: Eunsoo Shim 

.

-david

p2p-sip mailing list

  _____  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061206/e48f4374/attachment-0001.html

---

From: eunsooshim at gmail.com (Eunsoo Shim)
Date: Thu, 7 Dec 2006 07:12:12 -0500

mDNS works only in a subnet. If you limit P2PSIP applications only to that
environment, mDNS should work. You can go to SIPPING to talk about it. Many
of us understand it.
If you suggest mDNS even for other environments, please have the Internet
changed to support multicast almost everywhere first. Then we can talk about
using mDNS for P2PSIP in a general sense.

dynDNS is just another DNS system, i.e. relying on DNS SERVERs. Using dynDNS
is same as retrieving a redirect server information from DNS and getting the
location of a particular user from the redirect server. That means, even we
don't have to update the DNS infrastructure! Just use existing DNS and SIP
and you can get what you propose.

You continuously try to imply that P2PSIP does not use DNS at all. I pointed
out that DNS was assumed for inter-domain connections for P2PSIP (and
actually SIP). All left from your argument is that we got to use DNS servers
even for intra-domain lookups, which is equivalent to using a central
location server.

Now it sounds to me that you are saying "p2p does not work. Stick to central
servers!"
I have no interest in arguing whether C/S architecture or P2P architecture
is better. Neither are many people in this list, I believe. We understand
there are tradeoffs. Maybe you can enjoy that kind of discussion with people
from Skype or eDonkey.

I think we passed already time for that kind of discussion here.

Already the current SIP systems use central servers for location
registration and voicemail storage.
If you are interested in another way/protocol of using central servers for
SIP, this is not a right place to propose it.
If you have a problem with DHT, please propose a different 'P2P' mechanism
for 'P2PSIP'.

Thanks.

Eunsoo

On 12/6/06, David Barrett <dbarrett at quinthar.com> wrote:
> something best handled by some real storage provider.  You **could** do it
> in a DHT, but it'd just be slower and less reliable, and the engineering
> cost of building that would pay for central storage many, many times over.
>
>
>
> *From:* Peter Pan [mailto:huang-ming.pan at comcast.net]
> *Sent:* Wednesday, December 06, 2006 12:09 PM
> *To:* David Barrett; 'Henning Schulzrinne'
> *Cc:* 'P2P-SIP'
> *Subject:* Re: [p2p-sip] DNS for inter-domain? Yes; intra-domain? No
>
>
>
> *From:* David Barrett <dbarrett at quinthar.com>
>
> *To:* 'Henning Schulzrinne' <hgs at cs.columbia.edu>
>
> *Cc:* 'P2P-SIP' <p2p-sip at cs.columbia.edu>
>
> *Sent:* Wednesday, December 06, 2006 12:07 AM
>
> *Subject:* Re: [p2p-sip] DNS for inter-domain? Yes; intra-domain? No
>
>
>
> How can DNS records be automatically updated? *(Through dynamic DNS
> protocols)*
>
> -*[pp]: what is the cost and feasibility to upgrade existing DNS
> deployment of ipv6 and ip mobility?*
>
> - How fast can DNS propagate?  *(Extremely fast with short TTLs)*
>
> - What if I have multiple SIP proxies? *(Put multiple IPs into the DNS
> record)*
>
> Is DNS only for IP addresses? *(No, can store other records)*
>
> -*[pp]: can/will these DNS server also store data like voicemail or other
> p2p application data?*
>
> - How does DNS work in on ad-hoc networks? *(Using mDNS via multicast)*
>
> - Where is multicast supported? *(Only everywhere it's needed ? on
> subnets)*
>
> - Is mDNS an IETF standard? *(It's on the standards track.)*
>
> - Is mDNS actually in use? *(It's the foundation of zeroconf, which is
> used extensively by Apple)*
>
> - Are there any use-cases that DHT supports that DNS/mDNS cannot? *(Apparently
> not.)*
>
>
>
> Lack of clarity on these points could call for the unnecessary dismissal
> of these technologies on false premises, which I think nobody wants.
>
>
>
> -david
>
>
> *From:* Henning Schulzrinne [mailto:hgs at cs.columbia.edu]
> *Sent:* Tuesday, December 05, 2006 4:20 PM
> *To:* David Barrett
> *Cc:* 'Eunsoo Shim'; 'P2P-SIP'
> *Subject:* Re: [p2p-sip] DNS for inter-domain? Yes; intra-domain? No
>
>
>
> I mean, we **could** assume that every odd IP address won't work, and then
> design around that.  But odd IP addresses **do** work.
>
>
>
> Likewise, multicast **is** (or could easily be made) available for all of
> the real-world use cases that demand it.
>
>
>
> It just seems like there are much more interesting **actual** problems to
> But it's a **research** project, not an IETF standardization exercise.
> DNS and mDNS work everywhere the **actual** users are, and thus I think
> the IETF should focus on them, first.
>
>
>
> -david
>
>
> *From:* Eunsoo Shim [mailto:eunsooshim at gmail.com <eunsooshim at gmail.com>]
> *Sent:* Tuesday, December 05, 2006 3:04 PM
> *To:* David Barrett
> *Cc:* P2P-SIP
> *Subject:* Re: [p2p-sip] DNS for inter-domain? Yes; intra-domain? No
>
>
>
> multicast availability was not general and they did not want to limit P2PSIP
> into such network environments.
> The proposed charter is targeting to address intra-domain lookup that
> works even if there is no multicast support.
>
> On 12/5/06, *David Barrett* <dbarrett at quinthar.com> wrote:
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061207/9d9ba147/attachment-0001.html

---

From: dbarrett at quinthar.com (David Barrett)
Date: Thu, 7 Dec 2006 13:37:01 -0800

Hm, I will agree that the conversation has covered all the useful ground
it's going to cover.  As for the confusions you raise:

-          DNS is used when available (internet or private network), and
mDNS otherwise (ad hoc subnet)

-          Multicast only works on subnets.  Ad hoc networks are typically
single-subnets.  Thus mDNS works on ad hoc networks.

-          Multicast does not work between subnets.  The internet and
private networks use multiple subnets.  Thus mDNS will not work across the
internet or on private networks spanning multiple subnets.  However, DNS is
typically available in this case, and thus DNS is used instead. 

-          DNS and mDNS cover the total range of real-world networking
environments.

-          I understand P2P-SIP is currently proposed to use DNS as an
optional extension to the mandatory DHT.  I think it'd be more sensible to
have mandatory support for DNS with optional DHT, particularly because the
DHT is hard work for no real-world gain and it seems wasteful to force
everyone to pay it.

-          The "P2P" system I propose as a replacement for DHT is merely
what Adam originally proposed: configure P2P-SIP UAs to update a DNS record
that points to another P2P-SIP UA as a proxy.  

-          Whether or not that is P2P "enough" is a long boring religious
discussion.  But so far as we've been able to determine, this solves all the
same use cases as the DHT, but with less work and better integration with
existing SIP.

-          P2P works; it's what pays my bills.  But it's a question of when
and where is appropriate.

Please let me know if you have any more questions about this idea or need me
to clarify it more, but I think we've covered it exhaustively.

-david

  _____  

From: Eunsoo Shim [mailto:eunsooshim at gmail.com] 
Sent: Thursday, December 07, 2006 4:12 AM
To: David Barrett
Cc: Peter Pan; Henning Schulzrinne; P2P-SIP
Subject: Re: [p2p-sip] DNS for inter-domain? Yes; intra-domain? No

Thanks.

Eunsoo

-david

  _____  

Peter

----- Original Message ----- 

To: 'Henning Schulzrinne' <mailto:hgs at cs.columbia.edu>  

- [pp]: what is the cost and feasibility to upgrade existing DNS
infrastructure to support dynamic DNS globally? is it similiar to the
deployment of ipv6 and ip mobility?

- [pp]: can/will these DNS server also store data like voicemail or other
p2p application data?

-david

  _____  

 

Henning

-david

  _____  

From: Eunsoo Shim [ mailto:eunsooshim at gmail.com] 
Sent: Tuesday, December 05, 2006 3:04 PM
To: David Barrett
Cc: P2P-SIP
Subject: Re: [p2p-sip] DNS for inter-domain? Yes; intra-domain? No

What do you say?
Thanks.

Eunsoo

  _____  

From: Eunsoo Shim 

.

-david

p2p-sip mailing list

  _____  

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061207/2d28e1bf/attachment-0001.html

---

From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.)
Date: Thu, 7 Dec 2006 17:44:56 -0500

David:
 
Do DNS and mDNS also cover P2P Mobile Ad Hoc Networks (MANET)?
 
We are looking for MANET support right now for P2P-SIP networking.
 
Best regards,
Radhika
 
PS: We are using DNS right now, but no insufficient.

________________________________

From: p2p-sip-bounces at cs.columbia.edu on behalf of David Barrett
Sent: Thu 12/7/2006 4:37 PM
To: 'Eunsoo Shim'
Cc: 'P2P-SIP'
Subject: Re: [p2p-sip] DNS for inter-domain? Yes; intra-domain? No

Hm, I will agree that the conversation has covered all the useful ground it's going to cover.  As for the confusions you raise:

-          DNS is used when available (internet or private network), and mDNS otherwise (ad hoc subnet)

-          Multicast only works on subnets.  Ad hoc networks are typically single-subnets.  Thus mDNS works on ad hoc networks.

-          Multicast does not work between subnets.  The internet and private networks use multiple subnets.  Thus mDNS will not work across the internet or on private networks spanning multiple subnets.  However, DNS is typically available in this case, and thus DNS is used instead. 

-          DNS and mDNS cover the total range of real-world networking environments.

-          I understand P2P-SIP is currently proposed to use DNS as an optional extension to the mandatory DHT.  I think it'd be more sensible to have mandatory support for DNS with optional DHT, particularly because the DHT is hard work for no real-world gain and it seems wasteful to force everyone to pay it.

-          The "P2P" system I propose as a replacement for DHT is merely what Adam originally proposed: configure P2P-SIP UAs to update a DNS record that points to another P2P-SIP UA as a proxy.  

-          Whether or not that is P2P "enough" is a long boring religious discussion.  But so far as we've been able to determine, this solves all the same use cases as the DHT, but with less work and better integration with existing SIP.

-          P2P works; it's what pays my bills.  But it's a question of when and where is appropriate.

Please let me know if you have any more questions about this idea or need me to clarify it more, but I think we've covered it exhaustively.

-david

________________________________

mDNS works only in a subnet. If you limit P2PSIP applications only to that environment, mDNS should work. You can go to SIPPING to talk about it. Many of us understand it.
If you suggest mDNS even for other environments, please have the Internet changed to support multicast almost everywhere first. Then we can talk about using mDNS for P2PSIP in a general sense. 

dynDNS is just another DNS system, i.e. relying on DNS SERVERs. Using dynDNS is same as retrieving a redirect server information from DNS and getting the location of a particular user from the redirect server. That means, even we don't have to update the DNS infrastructure! Just use existing DNS and SIP and you can get what you propose.

You continuously try to imply that P2PSIP does not use DNS at all. I pointed out that DNS was assumed for inter-domain connections for P2PSIP (and actually SIP). All left from your argument is that we got to use DNS servers even for intra-domain lookups, which is equivalent to using a central location server. 

Now it sounds to me that you are saying "p2p does not work. Stick to central servers!"
I have no interest in arguing whether C/S architecture or P2P architecture is better. Neither are many people in this list, I believe. We understand there are tradeoffs. Maybe you can enjoy that kind of discussion with people from Skype or eDonkey. 

Already the current SIP systems use central servers for location registration and voicemail storage. 
If you are interested in another way/protocol of using central servers for SIP, this is not a right place to propose it. 
If you have a problem with DHT, please propose a different 'P2P' mechanism for 'P2PSIP'.

Thanks.

Eunsoo

I'm not sure the DNS infrastructure needs much updating at all.  Perhaps there will be more demand for DNS registrars to offer automated (aka "dynamic") record updating, but that's really just standardizing what they already do.

As for voicemail, no, I wouldn't expect to put that into DNS; that's something best handled by some real storage provider.  You *could* do it in a DHT, but it'd just be slower and less reliable, and the engineering cost of building that would pay for central storage many, many times over.

Again, in a vacuum without taking anything else into consideration, be it engineering cost, performance, reliability, existing systems, standards support and so on, yes, a DHT could be used.  But when everything else is factored in, it just makes no sense at all.

-david

________________________________

Peter

	----- Original Message ----- 

	How can DNS records be automatically updated? (Through dynamic DNS protocols)

	- [pp]: what is the cost and feasibility to upgrade existing DNS infrastructure to support dynamic DNS globally? is it similiar to the deployment of ipv6 and ip mobility?

	- [pp]: can/will these DNS server also store data like voicemail or other p2p application data?

	-david

________________________________

	 

	Henning

	-david

________________________________

	

	What do you say?
	Thanks.
	
	Eunsoo

	
________________________________

	From: Eunsoo Shim 

	...

	-david

	p2p-sip mailing list

	
________________________________

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061207/7c7dacb8/attachment-0001.html

---

From: dbarrett at quinthar.com (David Barrett)
Date: Thu, 7 Dec 2006 17:23:47 -0800

I'm not very familiar with MANET, but I think it supports multicast, so mDNS
could probably play a role in it.

Either way, if someone goes to the trouble of setting up some kind of
grid/mesh network, they'll probably want to do more than just VoIP.  They'll
need *some* kind of DNS to use for everything else.  It's probable they'll
find a way to tunnel normal DNS.  It's possible they'll find a way to use
normal mDNS.  Before inventing a custom, non-DNS solution, it seems sensible
to see how they're going to solve the DNS problem first and put our weight
behind that, rather than inventing a new, competing solution.

-david

PS: What is inadequate about DNS and mDNS for your network today?

  _____  

From: Roy, Radhika R. [mailto:RADHIKA.R.ROY at saic.com] 
Sent: Thursday, December 07, 2006 2:45 PM
To: David Barrett; Eunsoo Shim
Cc: P2P-SIP
Subject: RE: [p2p-sip] DNS for inter-domain? Yes; intra-domain? No

David:

Best regards,

Radhika

  _____  

-david

  _____  

Thanks.

Eunsoo

-david

  _____  

Peter

----- Original Message ----- 

-david

  _____  

 

Henning

-david

  _____  

What do you say?
Thanks.

Eunsoo

  _____  

From: Eunsoo Shim 

.

-david

p2p-sip mailing list

  _____  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061207/ddcab807/attachment-0001.html