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

[Dave Thaler <[e-mail]>]

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:[e-mail]] On Behalf Of Tim Chown
Sent: Saturday, April 2, 2016 5:25 AM
To: [e-mail]
Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-mdns-dns-interop-02

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 <[e-mail]> 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.

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 [e-mail] 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