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

From: Andrew Sullivan <[email-masked]>
Date: Wed, 22 Jan 2014 17:26:17 -0500

Dear colleagues,

At the last meeting, there was a request that I adapt the draft I
presented in order to get rid of the solution proposal (work we're not
chartered to undertake), and extract just the motivation or
requirements bit.  I think I've done that with
draft-sullivan-dnssd-mdns-dns-interop-00.  I hereby solicit review.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Wed, 22 Jan 2014 17:48:20 -0800

Dear Andrew,

Thank you for your effort but this seems headed in the wrong direction although there are a few areas that should be improved in mDNS.  Before going into that, the basis of your MI profile seems like a good place to start about why this approach seems wrong.

The MI profile has three rules:

   1.  If the label is made entirely of LDH code points, then the label
       MUST be an LDH label.

[ Simply refer to a hostname in compliance with RFC1123 section 2.1. ] 

   2.  All LDH code points MUST be folded to lower case.

[ This requirement is well beyond https://tools.ietf.org/html/rfc1123#section-2.1.  A method used to enhance transactional security is to modify query case which DNS handles well without issue??? ]

   3.  If the label contains any other code point, then the label MUST
       be a well-formed U-label.

[ IDNA2008 clarifies the need to avoid code points that are neither PROTOCOL-VALID or CONTEXTUAL RULE REQUIRED.  This requirement is not reflected in an ambiguous U-Label reference.  See: http://tools.ietf.org/html/rfc5894#section-7.2.3 which goes beyond what http://tools.ietf.org/html/rfc5198 required.

It even seems mDNS servers might treat IDNA2008 code-point violations as name collisions to force renaming.

The underlying goal is to ensure an idempotent result. Use of Rbridges http://tools.ietf.org/search/rfc6325 would be a superior means to transparently extend mDNS requiring far less intervention.  As network video content increases, spanning-tree constraints cause unfortunate bottlenecks that operates at the IP layer not well suited for IPv6.

As mDNS RFC6762 points out, this is not the only link-local protocol making use of UTF-8.  LLMNR http://tools.ietf.org/html/rfc4795 has not been updated to reflect current implementations however. See: http://download.microsoft.com/download/9/5/E/95EF66AF-9026-4BB0-A41D-A4F81802D92C/%5BMS-LLMNRP%5D.pdf  This document makes an inaccurate statement that ignores RFC1123 Section 3.1.5 in their modification as follows:  
,---
[RFC4795] does not specify whether names in queries are to be sent in UTF-8 [RFC3629] or Punycode [RFC3492]. In this LLMNR profile, a sender MUST send queries in UTF-8, not Punycode.
'---

At least http://tools.ietf.org/html/draft-sekar-dns-llq-01 takes an extra step to call out an extension to permit use of UTF-8 instance names defined for mDNS within DNS.  BTW, why is this document excluded from those developed by the dnssd group?  It is called out in draft-cheshire-mdnsext-hybrid.  

Perhaps mDNS RFC6762 should reference IDNA2008 described in RFC5891 instead of the older RFC5198.  This might better fix some of these issues the MI profile misses, especially with reference to uppercase code points. 

It seems attempts to make instance names compliant with host names defeats the intent to make environments normally lacking DNS services user friendly.  mDNS is not DNS nor should protocols attempt to use mDNS and DNS interchangeably without a directed discovery process.  It is not healthy to use URLs found lying about. :^)

Regards,
Douglas Otis

On Jan 22, 2014, at 2:26 PM, Andrew Sullivan <[email-masked]> wrote:

> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 22 Jan 2014 22:25:53 -0500

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.

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

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.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Thu, 23 Jan 2014 13:53:59 -0800

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.

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

> think this is a problem not to be solved, then we may have a charter

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

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 24 Jan 2014 14:32:05 -0500

Hi Doug,

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

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
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Mon, 27 Jan 2014 17:03:34 -0800

Dear Andrew,

> If your concern is the use of this word "profile", perhaps you can

What is meant by "single operational convention" while discussing mDNS and DNS is difficult to comprehend.  These two services are not operationally similar.

One conventional change that could have value are some of the constraints defined in IDNA2008 that ensure a single valid UTF-8 string for any apparent visually duplicated instance (except ASCII case folding).  Any such visual duplication created by different UTF-8 strings might prove problematic when spoofed instance names are presented prior to legitimate names.  These constraints would ensure any visual presentation offers a single valid UTF-8 result. This would mean replacing RFC5198 with a document following IDNA2008 sans Puny-code and A-Labels while permitting various punctuations and spaces.  I would be happy to compose a draft making the appropriate references as a means to leverage IDNA benefits. 

This is not to merge mDNS and DNS namespaces.  The present operational strategy depends on the correct mDNS resolution process where ".local." TLD signifies the necessary convention.

Resolving .local. services contained in other non-local networks may make use of DNS to establish a type of gateway.  IMHO,Trill represents a simpler and more robust alternative.  Trill extends multicast via Rbridges located by their MAC address.  Regardless of the access method, mDNS discovery conventions can be extended with various search domains, ideally after a user selection process from available local services. 

> If that's not clear from the text, I'd like to understand how to help

Perhaps a protocol prefix could remind users a local namespace is involved.  Those developing a proxy or gateway could resolve these issues. This could be done using curly brackets around instance labels for example.  i.e. {instance}.service.domain.  Allow those developing these services to impose the necessary syntax. 

The gist of your document seems aimed at unifying the DNS and mDNS namespace without this providing greater clarity or security.

> addresses the problem we're talking about, so I don't understand why

I hope I have explained this more clearly.  The only agreeable aspect that seems related to your statements would be in regard to ensuring idempotent results.  Am I to assume you don't find that to be a concern?  It seems there are few excuses for taking shortcuts on security.  The results of such shortcuts are likely to prove expensive and difficult to justify. 

> reading the other two paragraphs I deleted.)

There are extensions that ensure mDNS instance labels are supported by DNS. A gateway, proxy, or Trill bridge could claim a name collision with any invalid UTF-8 instance as determined by new IDNA2008 constraints. For Campus/Office/Home networks, Trill offers a more robust, secure, and scalable solution than possible with a proxy scheme.  In addition, Trill would not greatly expand network limitations imposed on mDNS services, while likely covering most current needs.  I see the mDNS proxy effort largely aimed at supporting soon to be legacy devices.

Regards,
Douglas Otis

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 27 Jan 2014 22:50:44 -0500

Hi Doug,

On Mon, Jan 27, 2014 at 05:03:34PM -0800, Douglas Otis wrote:
> 
> What is meant by "single operational convention" while discussing
> mDNS and DNS is difficult to comprehend.  These two services are not
> operationally similar.

Of course not.  _That's the problem_.  Let me see if an example will
make this more plain.  If not, I think I'll have to give up until I
hear from someone else about whether this point is clear in the draft
(or fail to hear from anyone, in which case I'll infer that the WG
just doesn't care about this problem). 

Suppose we have a device, call it téléviseur1.

The device is in use in the Dept of Languages at example university.
So its FQDN in the DNS (were it to have one) would be
téléviseur1.lang.example.edu.

Now, it so happens that Languages is kinda big, and classes have to be
all over campus.  But profs in the department want to use their
devices from all over the campus to get back to télévision, which is
the department's content server administered by Languages's IT monkey.

Inside the department network, télévision works seamlessly.  So IT
configures everyone in the department to have a search path of
lang.example.edu, and so when just télévision is entered, if there's
no mDNS responder for télévision.local (in UTF-8) then the label
gets the search path appended after being turned into
xn--tlvision-b1ab, and the lookup is
xn--tlvision-b1ab.lang.example.edu, and everything is good.

Now, suppose instead that the department's content server is called
instead "Source de Télévision, Département de Langues".  This is great
in an mDNS context: DNS-SD will find it just fine.  But if you enter
"Source de Télévision, Département de Langues.lang.example.edu", the
effects are unpredictable.  On some systems, that will be passed
through to the resolution layer unchanged, and the lookup will match
the octets modulo the 0x20 processing of ASCII characters.  On other
systems, it will be intercepted by the application or the system
resolver or both as a potential IDNA label, and processed according to
local IDNA rules.  Both IDNA2003 and IDNA2008 have trouble with
spaces, so we'll have some problems no matter what; IDNA2008 will
certainly reject it.  If your application is one of those "IDNA2003
except some new stuff we haven't specified", it's hard to know exactly
what will happen, but probably whatever would happen with IDNA2003
(because that label's handling ought not to change).  

The _point_ of the proposal is to say that the first scenario in this
example (télévision) works fine, but the second one does not, and so
we need a way of making these work together.  It's just supposed to
say that, and not presuppose any particular solution.

> string for any apparent visually duplicated instance 

This has nothing to do with any of the visual confusion stuff or any
of that.
 
> Perhaps a protocol prefix could remind users a local namespace is
> involved.

This requires users to have a theory of namespaces, which is already
very far away from users' needs.

> There are extensions that ensure mDNS instance labels are supported
> by DNS.

There are some labels that DNS-SD recommends that, I claim, cannot be
supported in DNS using IDNA.  That's all this is about.  I do not see
how Trill helps this, but I'm sure my ignorance is showing.

> I see the mDNS proxy effort largely aimed at supporting soon to be
> legacy devices.

Again, to the extent I understand you, this sounds like you're arguing
that the WG is chartered to cover a non-problem.  Is that right?

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 28 Jan 2014 13:48:43 -0500

On Mon, Jan 27, 2014 at 10:50 PM, Andrew Sullivan <[email-masked]>wrote:

> Am I correct that in this example you are referring to what is
conventionally
called a "host name", that is, the name of the A or AAAA record for a given
host?
Can we agree that DNS-SD [RFC 6763, section 4.1.3] does not dispute the LDH
convention for host names (even though particular implementations may
currently
allow local UTF-8 host names).  We should be more concerned about Service
Instance Name labels [ibid] and the issues around importing these into the
global
DNS.

> téléviseur1.lang.example.edu <http://xn--tlviseur1-b4ab.lang.example.edu>.
>
> A better example that would put this more squarely in our WG's wheelhouse
might
be a service named
téléviseur1._http._tcp.lang.example.edu<http://xn--tlviseur1-b4ab.lang.example.edu>
The rdata of the SRV
record with this name might contain "0 0 80 some-host.lang.example.edu".

> The current UI model for DNS-based service discovery is to select an entry
from a list, as from a service name browser.  Granted, the main example of
this today is Apple's Safari browser and it displays all instances of a
given
service in one big flat list.  But let's assume a future where multi-zone
browsing is enabled and the user has made the choices "human readable
web sites" (_http._tcp) and "lang.example.edu" as the <service name>
and <domain> parts of the Service Instance Name, respectively.  What then
appears in the list is the set of  <instance> names that match those
constraints.

Perhaps complicating this example is the fact that the name of the service
already exists in the zone file for "lang.example.edu", inserted there by
the
IT monkey who used his favorite editor to emit UTF-8.

> effects are unpredictable.

The format of the user's (service browser) query was for PTR records named
"_http._tcp.lang.example.edu".  The application receiving the responses
is a service name browser.  Is there some library in the path that will
munge
the responses before they get to the application?

>  On some systems, that will be passed
> So have we convinced ourselves that the problem lies not with DNS and
the server, but with host-resident resolver libraries?  This is an important
question, because it potentially divides the problem space in half.

> I, for one, would find it extremely helpful if the draft went into more
depth
about WHY the second one does not work and whether this is true in all
cases for all time.  Just that additional information would seem to
constrain the solution space, which I do think is a useful side-effect of
the draft.

> That is implied by your use of "lang.example.edu" above.  I think as this
scales up to K's of instances for a given service, users will either need to
get comfortable scanning through K's of instance names in a big flat list
or deal with hierarchical paths.  Many users do have a feeling for folders
(directory structures) and files (instances) so maybe we can leverage that
experience.

> I strongly disagree with this statement.  mDNS is becoming more prevalent
as
time goes on (and one would expect that to continue now that it is a
standards
track RFC) and there are literally millions of servers deployed that already
support it.

> To the extent that some of these services must be made visible in the
DNS (the famous homenet "I want to see my home printer from Timbuktu"
problem) I think problem is all about Service Instance Names that will
work both locally and globally.  We are not chartered to solve this problem
but to describe it, and I think Andrew's draft is on point (but perhaps not
quite there yet).

Regards, -K-

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 28 Jan 2014 14:07:46 -0500

> called a "host name", that is, the name of the A or AAAA record for a given

If I thought there were really one convention for what is meant by
"host name", I might be able to answer that question. :-/  But in any case,

> allow local UTF-8 host names).

we most certainly cannot agree about that.  4.1.3 is perfectly clear
that it recommends that the owner name in the DNS of a Service
Instance Name 'be stored in the DNS, and communicated over the wire,
encoded as straightforward canonical precomposed UTF-8 [RFC3629]
"Net-Unicode" (Unicode Normalization Form C) [RFC5198] text.'  That is
quite the opposite of LDH.  

> We should be more concerned about Service
> Instance Name 

The Service Instance Name in the case of the DNS is the whole name in
question -- in DNS terms what is called the "owner name".

> téléviseur1._http._tcp.lang.example.edu<http://xn--tlviseur1-b4ab.lang.example.edu>

No, it's the <Domain> portion of the Service Instance Name that is the
problem.  That's why I structured the example as I did.

A
 
-- 
Andrew Sullivan
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Tue, 28 Jan 2014 12:01:15 -0800

On Jan 28, 2014, at 10:48 AM, Kerry Lynn <[email-masked]> wrote:

> On Mon, Jan 27, 2014 at 10:50 PM, Andrew Sullivan <[email-masked]> wrote:
> Hi Doug,
> 
> Am I correct that in this example you are referring to what is conventionally
> called a "host name", that is, the name of the A or AAAA record for a given host?
> convention for host names (even though particular implementations may currently
> Instance Name labels [ibid] and the issues around importing these into the global
> DNS.
>  
> A better example that would put this more squarely in our WG's wheelhouse might
> be a service named téléviseur1._http._tcp.lang.example.edu  The rdata of the SRV
> this today is Apple's Safari browser and it displays all instances of a given
> appears in the list is the set of  <instance> names that match those constraints.
> 
> already exists in the zone file for "lang.example.edu", inserted there by the
> is a service name browser.  Is there some library in the path that will munge
> I, for one, would find it extremely helpful if the draft went into more depth
> I strongly disagree with this statement.  mDNS is becoming more prevalent as
> time goes on (and one would expect that to continue now that it is a standards

Dear Kerry and Andrew,

Andrew's concept of a 'single operational convention' for services outside the ".local." domain is to have discovery use DNS where applications obtain domain lists provided by DHCP (v4  RFC2131, v6 RFC3315) or RA DNSSL (v6 RFC6106) where service instances are published as A-Labels (RFC5891) where users enter matching U-Labels.  Any such instance or domain MUST publish A-Labels, not U-Labels. 

Facilitating such an approach, network administrators will need to publish services in DNS as A-Labels with fixed IP address translations whenever their address on the local network is not global.  In essence this means spaces, punctuation, and UTF-8 sequences declared illegal in IDNA2008 can not be used.  While SRV and PTR placed in DNS can facilitate discovery, DNS itself has no way to know when a service is active.  As such, all possible services and addresses will require fixed global translations that are problematic within constrained resources.

Andrew's approach is likely to expose cryptic puny-coded labels in a less friendly format nor does it solve the need for ad-hoc local resolutions. 

The current concept is to provide mDNS gateways to transparently extend the local network.  IMHO, an Rbridge (RFC6325) represents a generic solution that does not impact either DNS or mDNS.  IMHO, the WG hopes to offer similar solutions when an Rbridge is not available.  The IS-IS approach used in Rbridge is more scalable and does not impose path constraints causing undesirable bottle-necks.  With the ever increasing use of video over WiFi, such bottle-necks represent a growing concern.

Regards,
Douglas Otis

---

From: Brian Dickson <[email-masked]>
Date: Tue, 28 Jan 2014 15:36:42 -0500

> On Mon, Jan 27, 2014 at 05:03:34PM -0800, Douglas Otis wrote:
If not, I think I'll have to give up until I
> just doesn't care about this problem).

I'd like to add my support for discussing this issue, and I think this
document
is a good start.

> say that, and not presuppose any particular solution.
I'd like to attempt to articulate where I think the problem resides, and
illustrate
the location.

I have a rough idea on one way to address this, by adding one level of
indirection.
(NOT using any existing DNS indirection, but rather on the UI side, which
necessarily
has impact on existing DNS-SD designs - but which I think is fairly clean.
I leave it
to those doing DNS-SD to address the feasibility of doing this.)

Basically, the problem is attempting to wedge a "UI label" into a place
where a DNS
label is required (per DNS protocol).

The location of the problematic stuff is "<instance>" component in the
DNS-SD
<instance>.<service>.<domain>.

Clearly, the free-wheeling nature of local user-entered "labels" requires
both input
and select-from-list to have the entire kitchen sink of potential "labels"
available.

However, adding one single 1:1 label identifier, provides a clear, clean,
interoperable
way of supporting the input/selection function, while also preserving a
DNS-friendly
owner name.

This would require some DNS RRTYPE, either existing or new (I recommend
new),
allowing for a 1:1 (and onto, preferably) mapping of ID to "UI label".

In this proposed world, adding something into DNS-SD would require two
things to
be added (ideally atomic, two-phase commit style addition):
<ID>.<service>.<domain>   DNSSDLABEL    <UI_LABEL>
<ID>.<service>.<domain>   PTR                   <whatever>

The generation of <ID>, and presenting UI_LABEL instead of <ID>, would be
the
responsibility of the DNS-SD domain browser thing, or whatever it is
properly called.

Having a hash function, would ensure uniqueness in generating <ID>.

An example hash function would be SHA-224 with base32 encoding, i.e.
length=56.
This would support arbitrary UI_LABELs of arbitrary length.

Thoughts?

Brian

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 28 Jan 2014 16:02:12 -0500

Hi Doug,

On Tue, Jan 28, 2014 at 12:01:15PM -0800, Douglas Otis wrote:
> 
> Andrew's concept of a 'single operational convention' for services
> outside the ".local." domain

I have clearly lost my ability to make myself plain, perhaps because
this problem is so obvious to me.  Your description already misses the
point.  The point is that, if people are going to use the same label
under mDNS (which implicitly adds the .local. label and resolves via
mDNS) and under DNS (with an implicit addition by search path and
resolution via DNS), then a single operational convention for naming
in both contexts will be necessary.

In the example I was using of one that would work, I say that
télévision[.local.] works by sending UTF-8 over mDNS in the link-local
context, and that xn--tlvision-b1ab[.lang.example.edu.] works by
sending LDH-labels over DNS in the global context.  This only means
that, if you want to use DNS-SD over global DNS and mDNS both, you
need to have names that work in both systems, and that means that you
have to cleave to certain naming conventions that you otherwise
wouldn't need to do.

Names like "Doug's Own Universal Translator"[.local.], which work just
fine for DNS-SD over mDNS, may not work in the global context; and
"Doug's Own Universal télévision"[.local.] seems to me less likely to
work when used in a global context, because the label may well be
intercepted by a resolver library which tries to treat it as a
U-label.  Such an attempt will fail because it's not a legal U-label.

>  publish A-Labels, not U-Labels. 

I don't know whta that means.  Every A-label has exactly one U-label,
and conversely.

> Andrew's approach is likely to expose cryptic puny-coded labels in a less friendly format nor does it solve the need for ad-hoc local resolutions. 

I don't know what you're talking about here.  There is no "approach"
to begin with, because I'm trying to state a problem, not solve it.

But it sounds like you're worried that people are going to see
A-labels because the device sent an A-label but didn't know how to do
IDNA.  That'd be pretty strange.  It seems more likely that, if some
devices do DNS-SD in the global DNS but don't speak IDNA, they're
going to send UTF-8.  If that's the case, then we have an even bigger
problem: now we need to maintain parallel DNS trees, which turns out
to be less reliable than people might like.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 28 Jan 2014 16:05:10 -0500

On Tue, Jan 28, 2014 at 2:07 PM, Andrew Sullivan <[email-masked]>wrote:

> I'm just trying to determine where our assumptions agree or differ.  Since
you
began your example "Suppose we have a device, call it..." I am simply trying
to determine if you're referring to the name of an A or AAAA record?  That
is what I (and RFCs 1033 and 6763 seem to) refer to as a "host name".

> Quoting from RFC 6763, section 4.1.3:

Because Service Instance Names are not host names, they are not
constrained by the usual rules for host names [RFC1033
<http://tools.ietf.org/html/rfc1033>] [RFC1034
<http://tools.ietf.org/html/rfc1034>]
[RFC1035 <http://tools.ietf.org/html/rfc1035>], and rich-text service
subdomains are allowed and encouraged

I take this to mean that host names and service names are different things
(a given host may "host" a great many of services) and that the names of SRV
and TXT records are not subject to legacy _protocol_ constraints that assume
the LDH convention.  Indeed, [RFC 2782] already departs from LDH for SRV RR
names when it defines the format of service and protocol labels:

An underscore (_) is prepended... to avoid collisions with DNS
labels that occur in nature.

> I haven't any idea what you mean by an "owner name".  Let's look at a
concrete
example (you can try this at home kids):

user@ubuntu:~/src/bind-9.9.2/bin/dig$ ./dig -p 5353
@224.0.0.251_http._tcp.local PTR
; <<>> DiG 9.9.2 <<>> -p 5353 @ff02::fb _http._tcp.local PTR
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 0
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 4

;; QUESTION SECTION:
;_http._tcp.local.        IN    PTR

;; ANSWER SECTION:
_http._tcp.local.    10    IN    PTR
Officejet\032Pro\0328600\032[A266D6]._http._tcp.local.

;; ADDITIONAL SECTION:
Officejet\032Pro\0328600\032[A266D6]._http._tcp.local. 10 IN SRV 0 0 80
HPA266D6.local.
Officejet\032Pro\0328600\032[A266D6]._http._tcp.local. 10 IN TXT ""
HPA266D6.local.        10    IN    A    192.168.1.31
HPA266D6.local.        10    IN    AAAA    fe80::8634:97ff:fea2:66d6

;; Query time: 3 msec
;; SERVER: fe80::8634:97ff:fea2:66d6%2#5353(ff02::fb)
;; WHEN: Mon Jan 27 09:50:24 2014
;; MSG SIZE  rcvd: 162

Which of these is an "owner name"?  If I were to open Safari and navigate to
Bookmarks->Bonjour->Printers, I would see "Officejet Pro 8600 [A266D6]" in
the list.
This is the same name I see in the Print & Scan dialog when I select the
destination
for my print jobs.

When I *select* Bookmarks->Bonjour->Printers->Officejet Pro 8600 [A266D6] in
Safari, what gets populated in the (web) browser's navigation bar is
HPA266D6.local.
The only reason this works is that, by convention, we can find the most
popular
services by dereferencing a host name and using a well known port.  I could
just
as easily access my printer's configuration web page by entering
[fe80::8634:97ff:fea2:66d6]in the web browser.

One advantage of SRV records is that they allow a service to be found at an
arbitrary port.

> > téléviseur1._http._tcp.lang.example.edu<
> http://xn--tlviseur1-b4ab.lang.example.edu>
>
> As far as I can tell, your example has to do with host names (if we agree
on that definition)
and not Service Instance Names, which are structured as
<Instance>.<Service>.<Domain>.

Regards, -K-

A

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 28 Jan 2014 16:11:50 -0500

> <instance>.<service>.<domain>.

No.  If that's the only problem, then what Stuart said in the meeting
in Vancouver is probably right.  DNS-SD resolvers need to ensure that
that portion of the owner name does _not_ go through any system
resolver and is not treated as a candidate for IDNA processing, and
then you can send whatever you like.  The alternatives for treating
<instance> are called out in the draft.  I suppose your proposal is a
third, but it doesn't deal with the object-name problem (which is a
label in the domain part).

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 28 Jan 2014 16:32:05 -0500

> is what I (and RFCs 1033 and 6763 seem to) refer to as a "host name".

That's not a host name.

At least in the DNS, a host name is a DNS owner name that conforms to
the old host name syntax (or "preferred syntax"); that is, it's a DNS
owner name made up entirely of LDH-labels.  It probably (almost
certainly) also has an A or AAAA record at that owner name.  This is
actually made explicit in RFC 1033, and that LDH-label restriction is
exactly what RFC 6763 is saying it doesn't use.

In many contexts, to be clear, people use "host name" to refer to the
left-most label in a DNS name, regardless of whether that label is an
LDH-label or a U-label (or for that matter, an A-label).  

> Because Service Instance Names are not host names, they are not

Yes.  That is, they don't conform to this rule in RFC 1033:

           Because of other protocol
   restrictions, only the following characters are recommended for use
   in a host name (besides the dot separator):

           "A-Z", "a-z", "0-9", dash and underscore

(Note that 1033 includes underscore rather than just LDH.  RFC 1034 is
LDH only; see 1034 section 2.3.1.)

> I take this to mean that host names and service names are different things

They are, but not in the way you seem to think.

> names when it defines the format of service and protocol labels:

Yep.

> > I haven't any idea what you mean by an "owner name".  Let's look at a

The owner name "is the domain name where the RR is found"; see RFC
1034 section 3.6.  This is _different to_ a "host name" because of
what I say above.  Owner names are not constrained to LDH or even
LDHU, but can use any series of octets up to 63 octets per label, with
an overall restriction of 255.  

> _http._tcp.local.

> Which of these is an "owner name"? 

All of the above, less the quote character.  Also, here's an owner name:

télévision.lang.example.edu.

That owner name, however, is not an IDNA2008 name and won't work with
IDNA.  It _does_ work with the DNS, just fine.  Here's another owner
name:

télévision.local.

That owner name works exactly the same way as the above, except that
the resolver library has probably learned to treat the label
.local. as a namespace-shifter and therefore sends the query via mDNS
instead of DNS.  Except when it doesn't; as the root server operators
how often.

Here's another owner name:

xn--tlvision-b1ab.lang.example.edu.

This happens to work with IDNA, and is a host name as well as an owner name.

> <Instance>.<Service>.<Domain>.

Not host names, but the <Domain> part of the Service Instance Name,
which is I believe what the draft says.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Brian Dickson <[email-masked]>
Date: Tue, 28 Jan 2014 17:41:24 -0500

> label in the domain part).
[bpd] I think I now see the problem - I overlooked the 4.1.3 bit about
wire format and _encouraging_ use of non-IDNA/DNS labels.

I think my suggestion might still work, if we just expand the suggestion to
apply the same technique to any non-IDNA label in a Service Instance:
<ID1>.<ID2>._<service1>._<transport>.<ID3>..<ID_N>.<FQDN> PTR <whatever>
<ID1>.<ID2>...<FQDN> NEWRRTYPE "UI_LABEL1"
<ID2>...<FQDN> NEWRRTYPE "UI_LABEL2"
<ID3>...<FQDN> NEWRRTYPE "UI_LABEL3"
etc
<ID_N>.<FQDN>. NEWRRTYPE "UI_LABEL_N"

(The presence/absence of NEWRRTYPE distinguishes things,
if there is any ambiguity, with 56-byte base32-ish labels.)

Ugly, but at least only under the hood. Deterministic, may require
extra DNS queries, but backward compatible. Users see UI_LABELs.

(Since every <ID_N> is an A-LABEL, it is not incompatible with mDNS,
i.e. backward-compatible towards mDNS servers.)

This avoids placing limitations on user input, which I believe Andrew's
draft (with profiles) does.

Brian

---

From: Douglas Otis <[email-masked]>
Date: Tue, 28 Jan 2014 21:53:20 -0800

Dear Andrew,

On Jan 27, 2014, at 7:50 PM, Andrew Sullivan <[email-masked]> wrote:
[]
> xn--tlvision-b1ab.lang.example.edu, and everything is good.

Disagree.  A globally resolvable label in DNS might not satisfy applications expecting to discover local services.  DNS is normally unable to offer addresses suitable for local links without complex name hierarchy.  On the other hand, mDNS offers answers specifically for local links.  Resolved answers might return globally routable IP addresses, but such addresses may prove impractical in many situations.

> effects are unpredictable.

Any domain search list should imply ".local." for names lacking this TLD and having two or fewer labels.  This would ensure local mDNS resolvers are attempted first with a slight risk of causing a 3 second delay.  Normally users are closely associated with search list domains.  Even so, names invalid for DNS should ideally generate errors locally to minimize unintended traffic and delay.  

> (because that label's handling ought not to change).

Hopefully, applications will perform sanity checks prior to walking up resolvers.  In addition, U-labels complying with RFC5198 will not ensure valid A-Labels in a conversion process or that results restore to the original string.  IDNA2008 and mDNS RFCRFC5198 are currently not compatible nor intended to ensure idempotent U-label <<->> A-label results.  

> say that, and not presuppose any particular solution.

Your first example is not fine since the answer may not be suitable even when a result is produced. 

> This has nothing to do with any of the visual confusion stuff or any

IMHO, this property represents the basic difference between RFC5198 and IDNA2008.

> very far away from users' needs.

A user may not be helped who expects local services that resolve elsewhere.  There should be a preference for .local.

> how Trill helps this, but I'm sure my ignorance is showing.

Trill is able to transparently bridge multicast traffic by encapsulating packets in a manner that protects against routing loops.

DNS-SD recommends use of friendly labels which may prove problematic for IDNA.  IMHO, the best way to protect users from any namespace uncertainty is to prefer local, especially when doing so makes sense.  

> that the WG is chartered to cover a non-problem.  Is that right?

No. In the goodness of time spanning tree and IPv4 will be replaced by simpler and more robust ways of handling moderately complex local networks.  In the meantime, other methods will be needed.

Regards,
Douglas Otis

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 29 Jan 2014 01:27:27 -0500

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.

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

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: manning bill <[email-masked]>
Date: Wed, 29 Jan 2014 16:25:20 -0800

service discovery that is bound to a single broadcast domain must make certain assumptions, one that is often made, without
real justification, is that addressing/labeling is _NOT_ globally unique.

its not clear to me that the induced ambiguity of non-unique addressing/labeling is worth the cost, particularly given that device mobility
between broadcast domains is becoming the norm.

/bill
Neca eos omnes.  Deus suos agnoscet.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 29 Jan 2014 19:34:51 -0500

Hi Bill,

> between broadcast domains is becoming the norm.

If I understand this correctly (and I _think_ you're saying something
aligned with something Doug Otis was saying, though I believe I
understood him less), what you're saying is that ambiguous,
not-fully-qualified naming (or labelling -- I assume you mean "IP
addressing" above) is just a bad idea in the current Internet, so we
shouldn't do it.  Is that right?

If so (and if I'm right about what Doug was saying -- again, I'm not
at all confident in my interpretation), I find this hard to square
with the WG charter.  Are you saying that the WG is working on a
problem that can't actually be solved or shouldn't be solved or
something?  (I'm prepared to concede that possibility; I'm just trying
to understand what we're discussing.)

A

-- 
Andrew Sullivan
[email-masked]

---

From: manning bill <[email-masked]>
Date: Wed, 29 Jan 2014 16:53:11 -0800

rants below instead of top posting like God, Microsoft, and Apple intended… :)

/bill

> shouldn't do it.  Is that right?
mostly.   if it was just addressing, then we have RFC 1918 and all the existence proofs that link-local/single broadcast domains have real difficultly
staying that way.  once it involves names/labels,  the ability of multiple parties each claiming to be DC001, each with a divergent view of its service group will cause havoc.

this is a known problem with Appletalk and its successors,  DHCP assigned names, etc.  The problem is aggravated when one assigns security associations with the Fully Qualified Name,
which is then overridden in a link local scope.    I’m not saying we shouldn’t do it, I’m suggesting that all previous attempts have had serious problems that are not being addressed in the current
work products.  All of this goes away if we mandate/presume globally unique names/labels.

> to understand what we're discussing.)

I suggest that the work done to date does not solve the problems stated in the Charter, as I understand it,

---

From: Douglas Otis <[email-masked]>
Date: Wed, 29 Jan 2014 18:44:39 -0800

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.

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

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

> 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

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 29 Jan 2014 22:11:48 -0500

Hi Doug,

On Wed, Jan 29, 2014 at 06:44:39PM -0800, Douglas Otis wrote:
> Please forgive my awkward summary of what I understood you to be proposing. 

If there's anyone to apologise, it's obviously me, since I've made
such a hash of making my meaning clear.

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

I don't think that's right.  Here's what the charter says:

  The focus of the WG is to develop a solution for extended, scalable
  DNS-SD.  This work is likely to highlight problems and challenges with
  naming protocols, as some level of coexistence will be required between
  local zero configuration name services and those forming part of the
  global DNS.

That seems to me to suggest that we have to cope with service
discovery in a global context.  These are, clearly, not necessarily
global services, but I wasn't trying to suggest that.

> Read section 1.1 of RFC5895.  There are few protocol checks on
> U-Labels. 

So what?  We're developing protocol here, and _we_ need to be clear.
There is a perfectly good definition of U-label in RFC 5890, section
2.3.2.1.  Importantly, that section specifically says that a thing
that might be a U-label but that hasn't been determined yet.  We
sometimes call these "putative U-labels" or something of that sort.
It's really important in this conversation to be clear about this
distinction, however, or we'll never get clear on what we're talking
about.

> depending on geographic or cultural factors.  As such, it does not
> offer fixed translations between user input in UTF-8 form and
> A-labels.  

Of course not.  Not all user input is in fact a U-label.  For
instance, depending on your operating system, your user input may not
be UTF-8 in NFC.  And that barely gets us started.  That's why we have
the definition of U-label we have.

Yes, this imposes all kinds of stuff on clients, and no, it is not
reasonable to expect that everyone will do this correctly.  That's why
IDNA suggests so strongly that different layers each need to do their
own validation.
 
> 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.

Why do you think that the right level is fewer than 3 labels?  It
seems to me that you're depending in that case on a view about what's
"probably actually DNS" and "probably not" that is at least dodgy in
the current ICANN policies.
 
> room.  Have been unable to find evidence DNS-SD had been implemented
> by the IETF within DNS, although the charter did mention its use.

Stuart Cheshire has used this repeatedly as an example for DNS-SD, so
I encourage you to look through minutes of past meetings.  He also has
said repeatedly that Apple uses it this way.  

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

Who says they're exposed to the Internet?  First, publishing something
in the DNS hardly means that the service is available.  Second, split
horizons are, despite the IETF's lalalala-i-can't-hear-you act, a reality.

Regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: manning bill <[email-masked]>
Date: Thu, 30 Jan 2014 10:23:11 -0800

to hammer the point home, this from Krebs blog…

"Th[e] analysis looked at a malware component used in Target breach that was uploaded to Symantec’s ThreatExpert scanning service on Dec. 18 but which was later deleted (a local PDF copy of it is here). The ThreatExpert writeup suggests that the malware was responsible for moving stolen data from the compromised cash registers to that shared central repository, which had the internal address of 10.116.240.31. The “ttcopscli3acs” bit is the Windows domain name used on Target’s network. The user account “Best1_user” and password “BackupU$r” were used to log in to the shared drive”

Shared names & addresses, or networks that facilitate the same have the side effect of being easier targets for malware built elsewhere.   DNSSD should try and avoid this trap.

/bill