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

[Kerry Lynn <[e-mail]>]

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

>  Starting with the last question first:
>
> On 3/13/15 3:07 PM, Kerry Lynn wrote:
>
>  BTW, with the IPR question resolved, did you mean for this to remain a
> DISCUSS
>  or should it be a COMMENT instead?
>
>
> I absolutely meant for this to remain a DISCUSS. I think the current text
> is a real problem.
>
>  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:
>>
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>>>
>>> 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.
>>
>
> I am happy (and committed) to figure out a way to get this to move forward
> as quickly as possible.
>
>     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).
>>
>
> Sure, but you don't want to be documenting problems for which there is no
> technical solution ("People tend to drop mDNS consumer devices on the floor
> because they're small and they break easily, and they get upset about
> that"), at least in your layer. So when I see this:
>
>     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).
>>
>
> I suspect it's not a helpful piece of text to have in the document. If you
> think "l" vs. "1" is fun, wait until you get to "ø" vs. "⌀" vs. "o̷". The
> issue of confusable characters upon display is several layers above what
> this WG can do something about, and even bringing up the topic in a
> requirements document suggests that you intend to tackle it. I think you
> very much should not.
>
>     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.
>>
>
> So, I suggested above simply removing the second sentence of the first
> paragraph. I changed the last sentence of the first paragraph because
> without the second sentence, it doesn't track, but I don't really care how
> you word that. The only other thing I added was "and should look to work in
> using internationalize strings in application protocols
> [soon-to-be-RFC-draft-ietf-precis-framework]." I am not insistent on that,
> but I think in reality, if you're going to "support rich internationalized
> labels" as you do today, looking to the PRECIS work is exactly what you're
> going to do.
>
> <KEL>I don't have a problem with deleting that sentence and patching the
prose as necessary.
Hopefully the chairs and AD will agree.  Are you OK with something like:

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.  This may lead to a local
   label disambiguation problem when results are aggregated (e.g. for
   presentation).

I have more of an issue with the insertion of PRECIS at this late date.
Insofar as that draft
and this one have a common co-author, I think it is reasonable to assume
that it will receive
full consideration during the solution phase.

Regards, -K-



> All that said, this shouldn't be a heavy lift one way or the other. If
> your chair (and AD) think that whatever changes I suggest still represent
> the consensus of the WG, they can say so and you can make the change. If
> the WG disagrees, I'm sure they will let them know. But I do take the word
> "DISCUSS" quite seriously: I am ready and willing to engage in a discussion
> with you and the rest of the WG and drive that discussion to completion
> right quick (in particular, before we all show up in Dallas). Either you'll
> convince me that this isn't a big deal and we should leave the text as it
> is, or I'll convince you that it is a big deal and you should change it, or
> something in between. The bad outcome is to have an open issue that hasn't
> been addressed. (I think someone wrote a document about that. [1] ;-).) So
> let's discuss.
>
> pr
>
> [1] https://datatracker.ietf.org/doc/rfc7282/
>
> --
> Pete Resnick <http://www.qualcomm.com/~presnick/> <http://www.qualcomm.com/~presnick/>
> Qualcomm Technologies, Inc. - [phone]
>
>