Skip to main content

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

Request Review of draft-ietf-dnssd-requirements
Requested revision 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
I-D 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
Request Last Call review on draft-ietf-dnssd-requirements by Ops Directorate Assigned
Reviewed revision 04 (document currently at 06)
Result Has nits
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 >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