Last Call Review of draft-ietf-dnssd-requirements-04

Request Review of draft-ietf-dnssd-requirements
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-01-07
Requested 2014-12-28
Authors Kerry Lynn, Stuart Cheshire, Marc Blanchet, Daniel Migault
Draft last updated 2015-03-03
Completed reviews Genart Last Call review of -04 by Ben Campbell (diff)
Opsdir Last Call review of -04 by Sheng Jiang (diff)
Assignment Reviewer Sheng Jiang 
State Completed
Review review-ietf-dnssd-requirements-04-opsdir-lc-jiang-2015-03-03
Reviewed rev. 04 (document currently at 06)
Review result Has Nits
Review completed: 2015-03-03


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,


>-----Original Message-----
>From: Sheng Jiang
>Sent: Tuesday, January 06, 2015 11:05 PM
>To: ops-ads at
>Cc: draft-ietf-dnssd-requirements.all at
>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
>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,