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

[Benoit Claise <[e-mail]>]

Hi Kerry,
> On Thu, Mar 12, 2015 at 10:12 AM, Benoit Claise <[e-mail] 
> <mailto:[e-mail]>> 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:
>
>
>     - 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.
No need to remove it.
>
>     - 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.
I'm just asking: what does "efficiently" mean? How are you going to 
evaluate this criteria?
>
>        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, Benoit
>
> 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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/dnssd
>
>