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

Andrew Sullivan <ajs@anvilwalrusden.com> Fri, 24 January 2014 19:32 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3A91A00F4 for <dnssd@ietfa.amsl.com>; Fri, 24 Jan 2014 11:32:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Level:
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-GT37X4vNuf for <dnssd@ietfa.amsl.com>; Fri, 24 Jan 2014 11:32:08 -0800 (PST)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 7140B1A0047 for <dnssd@ietf.org>; Fri, 24 Jan 2014 11:32:08 -0800 (PST)
Received: from mx1.yitter.info (unknown [64.150.193.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id D71638A037 for <dnssd@ietf.org>; Fri, 24 Jan 2014 19:32:06 +0000 (UTC)
Date: Fri, 24 Jan 2014 14:32:05 -0500
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnssd@ietf.org
Message-ID: <20140124193205.GB2065@mx1.yitter.info>
References: <20140122222616.GN1271@mx1.yitter.info> <B1173945-F2CB-4086-A5BA-CAC44C0974D1@gmail.com> <20140123032553.GC1580@mx1.yitter.info> <779216FA-E974-4C95-A46F-DD55F6FC4F89@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <779216FA-E974-4C95-A46F-DD55F6FC4F89@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-00
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jan 2014 19:32:10 -0000

Hi Doug,

On Thu, Jan 23, 2014 at 01:53:59PM -0800, Douglas Otis wrote:
> 
> 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.
> 

Which "draft that discusses profiles"?  We're talking about
draft-sullivan-dnssd-mdns-dns-interop-00.  The text says,

 One approach to interoperability under these circumstances is to use
   a single operational convention for names under the different naming
   systems.  This memo posits such a use profile, and outlines what is
   necessary to make it work.

If your concern is the use of this word "profile", perhaps you can
suggest another one?
 
> As I pointed out, mDNS does not represent the only use of UTF-8 for
> accessing local services.

Correct.  But it's the case I happen to be worried about right now.
I'm aware how the DNS works.  

>  Various schemes have been around many years without users being
>  confused by their own local namespace often making use of local
>  access tools.

But our problem -- the actual problem that I'm talking about -- is
when users move from one resolution technology to another without
taking that into account.  I think I state this baldly in the draft.
If that's not clear from the text, I'd like to understand how to help
make it clearer.

> 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.

Yes, you said that already.  But I am not convinced that actually
addresses the problem we're talking about, so I don't understand why
you think it's relevant.
 
> As such, it seems prudent
> to impose constraints defined by IDNA2008 while still permitting
> punctuation and spaces since people find this freedom helpful.

That sentence says, "It seems wise to impose constraints defined by
IDNA2008 and also not to impose those constraints."  I'm not sure how
to implement (A & ~A) using binary logic.  I am a pretty bad
programmer, it's true, but I think I got this part right.  Could you
explain what you mean?  (I didn't understand anything more after
reading the other two paragraphs I deleted.)

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com