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

[Pete Resnick <[e-mail]>]

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] 
> <mailto:[e-mail]>> wrote:
>
>     On Fri, Mar 13, 2015 at 1:47 PM, Pete Resnick
>     <[e-mail] <mailto:[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.

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/>
Qualcomm Technologies, Inc. - [phone]