Re: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-00

[Douglas Otis <[e-mail]>]

On Jan 22, 2014, at 7:25 PM, Andrew Sullivan <[e-mail]> wrote:

> Hi Doug,
> 
> On Wed, Jan 22, 2014 at 05:48:20PM -0800, Douglas Otis wrote:
>> 
>> mDNS.  Before going into that, the basis of your MI profile seems
> 
> Why are we discussing the miprofile draft?  The _whole point_ of this
> new draft is to avoid discussing a solution, because the WG isn't
> chartered to come up with one.

Dear Andrew,

It was the use of "profile" that lead to the consideration of http://tools.ietf.org/html/draft-sullivan-dnssd-label-miprofile-00.  My apologies, but it was unclear what your use of "profile" meant.  There are serious problems with your draft that discusses profiles.

>> services user friendly.  mDNS is not DNS nor should protocols
>> attempt to use mDNS and DNS interchangeably without a directed
>> discovery process.
> 
> I _thought_ the draft as written made clear that this is exactly the
> problem:
> 
>   Users of applications are, of course, frequently unconcerned with
>   (not to say oblivious to) the name-resolution system(s) in service at
>   any given moment, and are inclined simply to use the same names in
>   different contexts.  As a result, the same string might be tried as a
>   name using different name resolution technologies.

As I pointed out, mDNS does not represent the only use of UTF-8 for accessing local services.  Various schemes have been around many years without users being confused by their own local namespace often making use of local access tools. 

IMHO, Rbridges http://tools.ietf.org/search/rfc6325 offers a superior means for transparently extending mDNS within multi-router (campus/office/home) settings.  Switches would not be exposed to everyone's MAC address while permitting more robust configurations making better use of limited network deployments.

> In my opinion at least, that is the problem we actually have that
> caused the formation of the WG, because people want DNS-SD over mDNS
> to work outside the link-local context and it doesn't today.  If you
> think this is a problem not to be solved, then we may have a charter
> problem.

Rbridges http://tools.ietf.org/search/rfc6325 offers such a solution without any change to mDNS or DNS.  Either way, bridging routers represents a larger environment where visual presentation represents normal one-off service selection methods.  As such, it seems prudent to impose constraints defined by IDNA2008 while still permitting punctuation and spaces since people find this freedom helpful.  To enable effective management of this local namespace, after normalization there should be only one result for each instance. 

RFC5198 is too broad to be used to locate services in these larger settings, IMHO.  It seems applying IDNA2008 normalizations and restrictions while permitting additional punctuation can be implemented without disrupting use of mDNS by describing any resulting conflicts as name collisions. 

While Rbridges seems ideal, using DNS with EDNS0 extensions over different ports isolates local namespace from that of the Internet.  The namespace in my office offers both local and Internet namespace.  Often access requires some form of authentication for local services, which is currently being done using a non-standard TLD.   I have seen configurations that employ ".mdns." as a TLD to clarify how the namespace is resolved.  Alas, I don't see that being proffered as a designated TLD.  ".local." works but does not offer a clue for how the namespace is resolved. Trying to make local and Internet namespaces appear similar invites greater confusion, IMHO.

Regards,
Douglas Otis