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

[Kerry Lynn <[e-mail]>]

On Fri, Mar 13, 2015 at 4:41 PM, Kerry Lynn <[e-mail]> wrote:

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

BTW, with the IPR question resolved, did you mean for this to remain a
DISCUSS
or should it be a COMMENT instead?