Re: [dnssd] Benoit Claise's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT)

On Thu, Mar 12, 2015 at 10:12 AM, Benoit Claise <bclaise@cisco.com> wrote:

> Benoit Claise has entered the following ballot position for
> draft-ietf-dnssd-requirements-05: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> The IETF should definitively focus on this problem space. Thanks.
>
> Some comments below:
>
> - I agree with Martin's comment.
>
> As do I.

> - Section 4, REQ8 looks a very fundemental requirement for all service
> discovery mechanism. It does not look like a specific requirement for
> SSD
>
> Are you suggesting we should remove REQ8?  This specifically includes
M2M, which may not be a requirement of *all* SD mechanisms.

> - Some of the requirements will be hard to fulfill, if taken literally:
>    REQ9:   SSD should operate efficiently on common link layers and link
>            types.
>
> Are you suggesting we should remove REQ9?  I think this specifically
relates
to reducing the dependence on multicast.

>    REQ12:  SSD should enable a way to provide a consistent user
>            experience whether local or remote services are being
>            discovered.
>
> I agree; this one seems hard.  But I still think we should try to satisfy
it.

> - Very surprised that the Security Considerations don't lead to formal
> requirements
> For example, in connection with "6.1 Scope of Discovery" and "6.5 Access
> Control", I was expecting a requirement such as
>    REQXX:  the owner of the advertised service must be able to configure
> whether his service should be advertised beyond the local link
>
> I think you make a good point.  As I read REQ1 & REQ2, it seems that in a
typical multi-subnet residential case the user might have to take some
action
to make a service visible beyond the local link or site.  OTOH, it might be
a
good idea to explicitly say that a user must OPT-IN to global
advertisements.

BTW, I believe it's in plan to produce a separate threat analysis document
which may help clarify additional requirements.

Regards, Kerry Lynn

> The way the requirements are specified: all services will be visible to
> everybody, and the access control will accept/reject the service request.
> That reminds me of the typical airport wireless situation: you try every
> wireless network to see which one will accept you.
>
>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd
>