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

From: "Pete Resnick" <[email-masked]>
Date: Wed, 11 Mar 2015 19:07:08 -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:
----------------------------------------------------------------------

Procedural issue - The shepherd writeup says:

   (7) Has each author confirmed that any and all appropriate IPR
   disclosures required for full conformance with the provisions of BCP
   78 and BCP 79 have already been filed. If not, explain why?

   The draft includes the boilerplate confirming that the document "is
   submitted in full conformance with the provisions of BCP 78 and BCP
   79". No disclosures have been made, nor are expected to be made in an
   Informational requirements draft.

   (8) Has an IPR disclosure been filed that references this document?
   If so, summarize any WG discussion and conclusion regarding the IPR
   disclosures.

   No.

There was an IPR disclosure made on the earlier pre-WG version of this
document back in 2013. Were the authors asked whether that disclosure
also applies to this version of the document? Is the WG aware of this
disclosure? Did the WG discuss the disclosure? Were any concerns raised?

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.