Resend this with right email address. In the original email, my email software made a mistake to auto-spell the OPS dir mail list to ops-ads. It was almost two months ago. Hopefully, with the draft.all email address, it arrived the authors and mail list. Best regards, Sheng >-----Original Message----- >From: Sheng Jiang >Sent: Tuesday, January 06, 2015 11:05 PM >To: ops-ads at tools.ietf.org >Cc: draft-ietf-dnssd-requirements.all at tools.ietf.org >Subject: OPS-DiR review of draft-ietf-dnssd-requirements > >Dear all, > >I have reviewed this document as part of the Operational directorate's >ongoing effort to review all IETF documents being processed by the IESG. >These comments were written primarily for the benefit of the operational >area directors. Document editors and WG chairs should treat these comments >just like any other last call comments. > >Intended status: Informational > >Summary: This document provides a problem statement and a list of >requirements for scalable DNS-SD/mDNS extensions. I found it is well written >with no big concerns. I do have some minor comments. > >In section 2.1, the last (fifth) bullet item of technical issues is actually the >summaried requirement. The followed technical requirements are actually the >detailed requirements for the required mechanism in this bullet item. > >The first paragraph of section 2.3 may need a little bit reorganized. he current >form does not clearly describe why the wireless mesh network require mDNS >need to support over multiple links in a wireless mesch network. > >Section 3, use case A, it would be very useful if some adoption status of Zero >Configuration Network [ZC] could be given. For now, there may be some >concern over whether it is a widely used technology. > >Section3, it seems all use cases are assuming the single exit router. But the >scerarios of multiple exit routers would be a common use case as well. Is this >left out of scope intentionally? If so, some explanation for the reason may >helpful. > >Section 4, REQ8 looks a very fundemental requirement for all service >discovery mechanism. It does not look like a specific requirement for SSD. > >Section 4, REQ13 may need reworded. The first sentense said "closely >reflection reality". The follow-up explanations are all about real-time or close >to real-time. > >Section 4, REQ14, SSD requests some new functions on network devices. It is >a change to the network technology. > >Section 5 looks a specific problem statement for namespace. A better place >may be as section 2.4. Also, there should be some correspondent >requirements, I believe. > >Section 6 raises some security requirements for SSD. They should also be >summaried and listed as numbered requirements in Section 4. > >Best regards, > >Sheng