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

From: "Pete Resnick" <[email-masked]>
Date: Fri, 13 Mar 2015 10:47:49 -0700

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.

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 13 Mar 2015 16:41:22 -0400

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

> 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

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 13 Mar 2015 16:41:22 -0400

Regards, Kerry Lynn

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 13 Mar 2015 18:07:33 -0400

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

> 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

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

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 13 Mar 2015 18:07:33 -0400

---

From: Pete Resnick <[email-masked]>
Date: Fri, 13 Mar 2015 15:42:51 -0700

Starting with the last question first:

> 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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Fri, Mar 13, 2015 at 1:47 PM, Pete Resnick
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     This draft is now more than a year late, due in part to much
>     discussion about

I am happy (and committed) to figure out a way to get this to move 
forward as quickly as possible.

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

>     very vocal critic and addresses, I believe, a different problem. 
>     It is often the

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

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. - +1 (858)651-4478

---

From: Pete Resnick <[email-masked]>
Date: Fri, 13 Mar 2015 15:42:51 -0700

pr

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 13 Mar 2015 20:49:24 -0400

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

> I absolutely meant for this to remain a DISCUSS. I think the current text
> is a real problem.
>
>>  On Fri, Mar 13, 2015 at 1:47 PM, Pete Resnick <[email-masked]
>> > wrote:
>>
> I am happy (and committed) to figure out a way to get this to move forward
> as quickly as possible.
>
> 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:
>
> 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
> 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
> [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-

> 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
>
> Pete Resnick <http://www.qualcomm.com/~presnick/> <http://www.qualcomm.com/~presnick/>

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 13 Mar 2015 20:49:24 -0400

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

>>>    looking name "Bi11" (using the digit "1" in place of the letter "l")

---

From: Pete Resnick <[email-masked]>
Date: Fri, 13 Mar 2015 17:58:30 -0700

On 3/13/15 5:49 PM, Kerry Lynn wrote:

>>         <[email-masked]
>>         <mailto:[email-masked]>> wrote:
>>
>>             OLD
> I don't have a problem with deleting that sentence and patching the 
> prose as necessary.

Seems perfectly reasonable to me.

> 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

I'm not about to hold up the document over that. I think you ought to 
put it in as a reminder to consider the IETF technology that has been 
worked on to deal with the issue, but enough folks will certainly remind 
you later if you forget when it comes time to work on the protocol. :-)

pr

---

From: Pete Resnick <[email-masked]>
Date: Fri, 13 Mar 2015 17:58:30 -0700

pr