Re: [dnssd] Pete Resnick's Discuss on draft-ietf-dnssd-requirements-05: (with DISCUSS)

[Kerry Lynn <[e-mail]>]

On Fri, Mar 13, 2015 at 1:47 PM, Pete Resnick <[e-mail]>
wrote:

> Pete Resnick has entered the following ballot position for
> draft-ietf-dnssd-requirements-05: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> [Updating to reflect that the IPR disclosure issue is addressed. There is
> an IPR disclosure that appears for this document, but it was a mistakenly
> filed disclosure that still remains in the system. We will deal with that
> issue separately.]
>
> Section 5:
>
> OLD
>    Devices on different links may have the same mDNS name (perhaps due
>    to vendor defaults), because link-local mDNS names are only
>    guaranteed to be unique on a per-link basis.  Also, even devices that
>    are on the same link may have similar-looking names, such as one
>    device with the name "Bill" and another device using the similar-
>    looking name "Bi11" (using the digit "1" in place of the letter "l").
>    This may lead to a local label disambiguation problem between
>    presented results.
>
>    SSD should support rich internationalized labels within Service
>    Instance Names, as DNS-SD/mDNS does today.  SSD must not negatively
>    impact the global DNS namespace or infrastructure.
>
> The part about name collisions is fine, and should be said. The part
> about disambiguating similar characters is a rat's nest I really think
> you need to avoid. We can discuss this further, but the i18n community is
> dealing with this issue right now and it's a mess you really don't want
> to get into. I think you should simply stick to something like this:
>
> NEW
>    Devices on different links may have the same mDNS name (perhaps due
>    to vendor defaults), because link-local mDNS names are only
>    guaranteed to be unique on a per-link basis. SSD needs to deal with
>    name collisions beyond local link considerations.
>
>    SSD should support rich internationalized labels within Service
>    Instance Names, as DNS-SD/mDNS does today and should look to work in
>    using internationalize strings in application protocols
>    [soon-to-be-RFC-draft-ietf-precis-framework].  SSD must not
>    negatively impact the global DNS namespace or infrastructure.
>
> Hi Pete,

This draft is now more than a year late, due in part to much discussion
about
the differences between DNS-SD/mDNS and DNS (IDNA2008) name spaces.
Looking back at our charter, we have a requirement

To document challenges and problems encountered in the coexistence
of zero configuration and global DNS name services in such
multi-link networks, including consideration of both the name
resolution mechanism and the namespace.

without necessarily proposing a solution (however, the latter may
ultimately come
about via https://tools.ietf.org/html/draft-ietf-dnssd-mdns-dns-interop-00).

The language you have flagged was inserted during WGLC in response to one
very vocal critic and addresses, I believe, a different problem.  It is
often the
case that DNS-SD/mDNS query results are displayed to the user through the
UI.  The OLD language simply notes that various, otherwise legal, names may
have a similar appearance (without proposing a solution).

If you still find that a change is necessary, I would first ask what we can
merely
delete.  I'm afraid that any additions to this section may require us to go
back to
the WG for further discussion.

Regards, Kerry Lynn