Last Call Review of draft-ietf-dnssd-requirements-04
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.
>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
>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
>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
>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.