Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions
draft-ietf-dnssd-requirements-06

The IETF should definitively focus on this problem space. Thanks.

Some comments below:

- I agree with Martin's comment.

- Section 4, REQ8 looks a very fundemental requirement for all service discovery mechanism. It does not look like a specific requirement for SSD

- Some of the requirements will be hard to fulfill, if taken literally: 
   REQ9:   SSD should operate efficiently on common link layers and link
           types.

   REQ12:  SSD should enable a way to provide a consistent user
           experience whether local or remote services are being
           discovered.

- Very surprised that the Security Considerations don't lead to formal requirements
For example, in connection with "6.1 Scope of Discovery" and "6.5 Access Control", I was expecting a requirement such as
   REQXX:  the owner of the advertised service must be able to configure whether his service should be advertised beyond the local link

The way the requirements are specified: all services will be visible to everybody, and the access control will accept/reject the service request. That reminds me of the typical airport wireless situation: you try every wireless network to see which one will accept you.

   Wireless networks such as Wi-Fi [IEEE.802.11] may be adversely
   affected by excessive mDNS traffic due to the higher network overhead
   of multicast transmissions.

It's excessive becasue they are adversely affected not the other way around.

A nit:
Please expand the terms DNS-SD and mDNS at their first use, for instance, in the Abstract.

Section 5:

   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.

A reference to soon-to-be-RFC-draft-ietf-precis-framework would be nice here.

I'm glad to see this moving forward. I have a few minor comments, but just do the right thing.

I was at at least one BOF where this was discussed, so I kind of knew what to expect, but I didn't find the title clear. Could the word "multi-link" be added someplace?

This text:

      It is common practice for enterprises and
      institutions to use wireless links for client access and wired
      networks for server infrastructure, typically on different
      subnets.
      
didn't seem quite right. Is it saying 

      It is common practice for enterprises and
      institutions to use wireless links for client access to wired
                                                           ^^
      networks for server infrastructure, typically on different
      subnets.  
      
? As written, this excludes my office network, which includes both clients on wired and wireless links, and I suppose that's an environment where this extension might be useful ...

(an embarrassingly small nit) In this text:

   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 two requirements don't seem particularly related, and I wonder if the second would get more attention if it was a separate paragraph.

- section 6 intro: I'm not sure I buy that the set of relevant
threats is only a union as stated. There are often new threats
in new environments.

- 6.6: I think one can also leak private information by
searching in too broad a scope, e.g. if the client can be
fingerprinted allowing re-identification. I think that's
different from the example given, and maybe worth noting too.