Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-mdns-dns-interop-02

From: Tim Chown <[email-masked]>
Date: Sat, 2 Apr 2016 13:24:45 +0100

Hi,

Ralph and I will take further comments to the list in advance of the dnssd meeting on Monday.

Comments of the form ‘this is ready to ship’ are also very useful.

Tim

> On 17 Mar 2016, at 22:39, Tim Chown <[email-masked]> wrote:
> 
> Dear dnssd WG participants,
> 
> We are initiating a WG Last Call today on draft-ietf-dnssd-mdns-dns-interop-02, as can be found at https://tools.ietf.org/html/draft-ietf-dnssd-mdns-dns-interop-02 <https://tools.ietf.org/html/draft-ietf-dnssd-mdns-dns-interop-02>.
> 
> The call runs for two weeks, and will thus close on Thursday 31st March.
> 
> Please send any comments (including indications of support for progression of the document as is) to the [email-masked] <mailto:[email-masked]> list. This draft will not be advanced for publication unless there is sufficient response and support from the WG.  And, of course, any substantive comments on the draft are strongly encouraged as well. 
> 
> We will discuss the comments arising from the WGLC in the WG meeting in BA on Monday 4th April.
> 
> Abstract
> 
>    Despite its name, DNS-Based Service Discovery can use naming systems
>    other than the Domain Name System when looking for services.
>    Moreover, when it uses the DNS, DNS-Based Service Discovery uses the
>    full capability of DNS, rather than using a subset of available
>    octets.  In order for DNS-SD to be used effectively in environments
>    where multiple different name systems and conventions for their
>    operation are in use, it is important to attend to differences in the
>    underlying technology and operational environment.  This memo
>    presents an outline of the requirements for selection of labels for
>    conventional DNS and other resolution systems when they are expected
>    to interoperate in this manner.
> 
> 
> Thanks,
> 
> Ralph and Tim
> dnssd WG co-chairs
> 
> 
>

---

From: Dave Thaler <[email-masked]>
Date: Sat, 2 Apr 2016 23:44:51 +0000

I think the draft needs some editorial clarifications before it is ready to ship.

Section 1:
> Conventional use of
> the DNS generally follows the host name rules [RFC0952] for labels --
> the so-called LDH rule 

I’m not sure I agree with this phrasing.  See https://wiki.tools.ietf.org/html/rfc6055#section-3 

Perhaps replace sentence with:
    Many applications and resource record types follow the “Internet hostname"
    syntax [RFC0952] for labels – the so-called LDH rule.

> It is worth noting that the LDH rule is a convention,
> and not a rule of the DNS; this is made entirely plain by [RFC2181],
> section 11 .

Suggest appending
“and discussed further in [RFC6055], section 3.”

> 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 domain
> names in different contexts.

Suggest
s/Users of/Users and developers of/
(for rationale for this change, see discussion of figure 2 of RFC 6055)

> If DNS-SD is
> to be used in an environment where multiple resolution systems (such
> as mDNS and DNS) are to be queried for services, then some parts of
> the domain names to be queried will need to be compatible with the
> rules and conventions for all  the relevant technologies.

I don’t follow.   The point of RFC 6055 is that the encoding should be
handled by the name resolution provider (mapping to DNS or to mDNS
or hosts file or whatever else) not by the application.   So which layer
is this talking about?

Section 1.1:
> In practice, applications
> sometimes intercept labels that do not conform to the LDH rule and
> apply IDNA  and other transformations.

Unfortunately this is true, which is what causes many problems that led
to writing RFC 6055 to recommend that applications (as opposed to name
resolution libraries) stop doing so.   No change needed here I think, just
wanted to say I agree that's a problem.  :)

Section 2:
> will perform the U-label/A-label transformation automatically, saving
> applications from these details.  If this were the main problem,

Performing transformations automatically is not a problem, it's a solution.
I think the problem you're trying to point out is if they do the transformation
incorrectly.  E.g., if they do so without taking the protocol or the naming
context into account as discussed in RFC 6055.   Need to reword to clarify
what the problem is and isn't.

Section 3:
> and transmit labels as UTF-8 in the DNS is likely either to encounter
> problems or  result in unnecessary traffic to the public DNS (or

Grammar: either insert “to” before "result", or change “either to” to “to either”

> In particular, many labels in the <Domain> part of a Service
> Instance Name is  unlikely to be found in its UTF-8 form in the public

Grammar: “labels … is .. its”.  Perhaps “labels … are .. .their”?

> U-labels cannot contain upper case letters.   

Suggest citing [RFC5894] sections 3.1.3 and 4.2.

Section 4.1:
> The first way would be to treat this portion as likely to be
>   intercepted by system-wide IDNA-aware resolvers ,

What do you mean by "system-wide IDNA-aware resolver" here?
One unaware of which protocol will be used to resolve and in which naming context?
Clarify.

>   Instead, DNS-SD implementations can intercept the <Instance> portion
>   of a Service Instance Name and ensure that those labels are never
>   handed to IDNA-aware resolvers that might attempt to convert these
>   labels into A-labels .  

Either I’m confused (which is certainly possible, but would then imply the document
could be better worded for dummies), or neither approach in this document is
consistent with RFC 6055 recommendations.

Section 4.3:
> More important, operators of internationalized domain names will
> frequently publish such names in the  DNS as A-labels

For clarity it would be best to add “public” before "DNS".
This shouldn’t change the meaning since the sentence already says “frequently” so isn’t an absolute.

> DNS-SD implementations ought
>   to identify the <Domain> portion of the Service Instance Name and
>   treat it subject to IDNA2008 in case the domain is to be queried from
>   the global DNS .

If the “DNS-SD implementation” falls into either the “app” category or the “name resolution API”
category of figure 2 of RFC 6055, then I think this text seems to imply what I would consider bad
design (not how we would implement it).  Instead I think the DNS, mDNS, etc components 
should all do the correct transformation.   But RFC 6055 just recommends that it be done by 
some layer that knows both the protocol & the naming context, which could be the protocol layer
or could be the naming API layer, but to me having to change the naming API layer to be protocol-aware
seems architecturally bad.   So I think the confusing is perhaps around the term 
“DNS-SD implementations” which could use some elaboration, or at least rewording for consistency
with RFC 6055.

Dave

From: dnssd [mailto:[email-masked]] On Behalf Of Tim Chown
Sent: Saturday, April 2, 2016 5:25 AM
To: [email-masked]
Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-mdns-dns-interop-02

Hi,

Tim

Dear dnssd WG participants,
We are initiating a WG Last Call today on draft-ietf-dnssd-mdns-dns-interop-02, as can be found at https://tools.ietf.org/html/draft-ietf-dnssd-mdns-dns-interop-02.

Please send any comments (including indications of support for progression of the document as is) to the [email-masked] list. This draft will not be advanced for publication unless there is sufficient response and support from the WG.  And, of course, any substantive comments on the draft are strongly encouraged as well. 

Abstract

Thanks,

Ralph and Tim
dnssd WG co-chairs

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 2 Apr 2016 21:02:46 -0400

Hi,

First, thanks very much for the review.

[ObIHopeObvious: I elided things I just think are good.  Thanks for them.]

> or hosts file or whatever else) not by the application.   So which layer

I think I don't follow.  The point is that, when someone is offering
services across multiple resolution contexts, there are multiple
resolition systems.  There's actually no way for the name resolution
provider to provide the solution here, because it's impossible to know
in advance which kind of provision is likely to happen.  

Hmm.  I suppose the point is made clearer if the draft says something
like, "If you are sure that nothing will go past some context -- where
that context is either the LAN, or the site-network however defined --
then local conventions prevail.  Otherwise, parts of the domain names
to be queried … &c."  Is that clearer?

> consistent with RFC 6055 recommendations.

Stuart has asserted strogly -- and I confess I have some sympathy for
his claim -- that all the use cases involve pick-lists.  If that's
true, then the "first way" is never going to happen, and the "second
way" is the only real option.  And you're right that neither is
actually consistent with 6055.

> “DNS-SD implementations” which could use some elaboration, or at least rewording for consistency

I wish I knew what the WG wanted here.  I'm way more than amenable to text.

A

-- 
Andrew Sullivan
[email-masked]