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

[Douglas Otis <[e-mail]>]

Dear Andrew,

Please forgive my awkward summary of what I understood you to be proposing.  Your document does not appear to address the chartered problem.  Clearly you are also unhappy with my use of the term U-Label.  My apologies. 

See comments inline.

On Jan 28, 2014, at 10:27 PM, Andrew Sullivan <[e-mail]> wrote:
> Doug,
> 
> On Tue, Jan 28, 2014 at 09:53:20PM -0800, Douglas Otis wrote:
>> 
>> Disagree.  A globally resolvable label in DNS might not satisfy
>> applications expecting to discover local services. 
> 
> But a significant part of the _reason_ we started this WG was because
> the services aren't actually local.  They're on-campus, but they're
> not in a link-local context.  So far, there are exactly two contexts:
> link-local and not.  You seem to be proposing something further, but
> if so I really don't know what it is.  It'd be nice to get a pointer.

The goal is to facilitate access to mDNS gateways or proxies for access to services likely publishing non-global addresses in mDNS which do not permit direct Internet access and are not on a common network bridge.  Profoundly not the same as transparently resolving global services which you seem to suggest.

Here are some pointers to proprietary products that may help compose a definition of the problem being solved.  Rather than using Rbridge (RBridge overview), these products use VLANs (RFC5517) into adjacent network segments.

 Xirrus_BonjourDirectorAppNotes
 Aerohive Bonjour Gateway
 ArubaNetworks AirGroup
 
>> up resolvers.  In addition, U-labels complying with RFC5198 will not
>> ensure valid A-Labels 
> 
> There is no such thing as a U-label that does not generate an A-label,
> and conversely.  This is a property of U-labels and A-labels.  If what
> you're talking about is a non-U-label string that is nevertheless a
> valid string using 5198, please say that.

Read section 1.1 of RFC5895.  There are few protocol checks on U-Labels.  U-Label enforcement is normally incumbent on those often called registrars to ensure compliance with Unicode Standard Annex #15 Unicode Normalization Forms which was revised three times since 2012.  http://www.unicode.org/reports/tr15/.

IDNA2008 takes an anamorphic view of UTF-8 input described as depending on geographic or cultural factors.  As such, it does not offer fixed translations between user input in UTF-8 form and A-labels.  Any such view has been deprecated along with the changed definition for A-Labels also prefixed with the same "xn--".  It is risky to assume symmetry between A-Labels and encoded UTF-8 user input.  U-Label validity is assumed when a process defined in RFC3492 encodes A-Labels that resolve records.  Do not assume symmetry between UTF-8 user input and A-Labels or that symmetry is being enforced by the protocol.  Such enforcement is not practical.  Strong statements about U-label and A-label symmetry is misleading. 

>> A user may not be helped who expects local services that resolve
>> elsewhere.  There should be a preference for .local.
> 
> You do realise, right, that users never see ".local." on anything? 

Users don't see the DNS search list either. A 'single operational convention' for mDNS/DNS services outside the ".local." domain may have applications obtaining domain search lists provided by DHCP (v4  RFC2131, v6 RFC3315) or RA DNSSL (v6 RFC6106).  DNS service domains must be published as A-Labels (RFC5891).  Since domain compliance depends on A-label enforcement by registrars, A-Labels and not U-Labels must be published in DNS.  There is a DNS extension to support the live browse feature found in mDNS.  

The suggestion was to recommend an implied ".local." be positioned first in a domain search list when fewer than 3 labels are entered when applications make use of search domain lists.   This would mean for users not entering FQDNs they might experience a 3 second delay with the benefit of better protecting the Internet and the user alike.

>> Trill is able to transparently bridge multicast traffic by encapsulating packets in a manner that protects against routing loops.
> 
> Ok.  So, you are saying that DNS-SD has to be used onlt with mDNS?
> That seems contrary to the specification.  Also, it's contrary to
> deployed practice.  For instance, printers at IETF meetings are
> discoverable using DNS-SD in the global DNS.

In specific cases it may be practical to administratively pin services to specific addresses and then use any number of publishing methods.  At the last meeting the printer's address was published in DNS as term-printer.meeting.ietf.org and in mDNS within the terminal room.  Have been unable to find evidence DNS-SD had been implemented by the IETF within DNS, although the charter did mention its use.

term-printer.meeting.ietf.org. 	3600 IN	AAAA	2001:67c:370:128:200:74ff:fee0:6cf8
term-printer.meeting.ietf.org. 	3600 IN	A		31.133.128.18

It seems highly doubtful most organizations will want selectively configured local services exposed to the Internet, unlike the IETF.

In my view, Rbridge represents an example that satisfies the WG charter as does Xirrus, Aerohive, and Aruba products.  For all of these examples, a type of cross-link node filter is likely desired.  As such, one of the work products might include a standard format describing desired service cross-links via VLAN or Rbridge.  

Regards,
Douglas Otis