Re: [dnssd] OPS-DiR review of draft-ietf-dnssd-requirements

[Sheng Jiang <[e-mail]>]

Resend this with right email address. Somehow, the original email missed the most important OPS dir mail list. 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: [e-mail]
>Cc: [e-mail]
>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