Re: [Widex] Review of Requirements document

Dean Willis <dean.willis@softarmor.com> Mon, 18 September 2006 19:13 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPOYP-0004oC-9B; Mon, 18 Sep 2006 15:13:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPOYN-0004nn-OZ for widex@ietf.org; Mon, 18 Sep 2006 15:13:15 -0400
Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPOYL-0002mY-8n for widex@ietf.org; Mon, 18 Sep 2006 15:13:15 -0400
Received: from [64.101.149.162] ([64.101.149.162]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k8IIFwDE023877 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 18 Sep 2006 13:16:00 -0500
In-Reply-To: <1C1F3D15859526459B4DD0A7A9B2268B027DEA61@trebe101.NOE.Nokia.com>
References: <1C1F3D15859526459B4DD0A7A9B2268B027DEA61@trebe101.NOE.Nokia.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <77D30015-71EA-4221-BA18-B8ECB7D1A1A3@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Widex] Review of Requirements document
Date: Mon, 18 Sep 2006 14:13:09 -0500
To: widex@ietf.org
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7
Cc: "Vlad.Stirbu@nokia.com> <Vlad.Stirbu@nokia.com" <Vlad.Stirbu@nokia.com>
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>, <mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>, <mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org

It seems to me that the commentary from Lisa indicates a few things  
that should be touched up before requesting Apps-area expert review  
on the document, which I would like to do either before or in  
conjunction with working-group last call.

With a document of this sort and the small community that we have  
working on it, I think it is important to get some external review so  
that we can discover whether the level of exposition is adequate for   
a new reader.

What do you folks think of revving this document fairly quickly to  
accommodate the suggestions below, then starting area and working  
group final reviews?

--
Dean Willis, as chair


On Sep 7, 2006, at 10:48 AM, <Vlad.Stirbu@nokia.com>  
<Vlad.Stirbu@nokia.com> wrote:

> Hi Lisa,
>
>> -----Original Message-----
>> From: ext Lisa Dusseault [mailto:lisa@osafoundation.org]
>> Sent: 21 July, 2006 22:29
>> To: widex@ietf.org
>> Subject: [Widex] Review of Requirements document
>>
>>
>> This review comes from me as an individual.  These are
>> questions and suggestions for improving the document (not
>> requirements from your advising AD), and it may well be that I
>> don't understand the problem space well enough yet.
>>
>> 4.  Scenarios
>>
>> I am not sure why the NAT traversal and IPv4/IPv6 stuff is in
>> this document in so much detail.  Does it require this much
>> explanation and diagrams?  What requirements follow from these
>> scenarios?
>
> The relation might not be so obvious but, as Widex will define both a
> framework and a message exchange used for synchronization (e.g. WOs),
> implementers needs to be aware of the network environment challenges
> when they will choose the service discovery and session setup  
> mechanism
> and the transport protocol that is most appropriate for their  
> particular
> target environment. We might have gone too deep into details in this
> document and a better place for those should have been the framework
> document but they are quite important to understand the problem.
>
>>
>> To a reader like me, a scenario that described an example use
>> case justifying the "multiple modes of interaction" would be useful.
>
> Would it be enough if we point the reader instead to the W3C's
> Multimodal Architecture which is one possible customer of the Widex
> framework?
>
>>
>> I think your scenarios are designed for a reader that
>> understands the problem that's being solved but may not
>> understand the networking challenges, whereas I'm a reader who
>> understands the networking challenges more than I understand
>> the problem being solved :)
>>
>> 5.  Requirements
>>
>> 5.1:
>> "   o  The framework MUST be modular, e.g. multiple session setup
>>       mechanisms may be used."
>>
>> Flexibility is good; interoperability is even better.  How
>> about adding something like: "There must be ONE
>> mandatory-to-implement session setup mechanism" (you might
>> also add desired characteristics for the mandatory mech.)
>
> The Widex framework can be used in different environments and those  
> can
> have characteristics that differentiate them quite a lot and these
> characteristics were taken into account by the developers of the  
> service
> discovery and session setup protocols. For example, in an unmanaged
> network like those typically found in home networks, an implementer  
> may
> choose between Rendezvous/Bonjour and UPnP. In other environments,  
> where
> SIP infrastructure is available, implementers can use it. Other
> alternatives include SLP or SRV records or it might be possible  
> that in
> some close environments there is no need for service discovery and
> session setup at all if you have means to manually input the URL of  
> the
> server in the client.
>
> It would be great if a mandatory mechanism will be defined but it  
> seems
> that we don't have any mechanisms that is universally applicable. For
> this reason, in order to help interoperability and to provide a  
> somehow
> unified experience regardless of what is the actual service discovery
> and session setup mechanism, the framework has some requirements on  
> what
> the mechanism must and should negotiate (they are listed in the
> framework draft).
>
>>
>> 5.2:
>> "   o  The service discovery mechanism MUST be able to discover both
>>       Widex Renderers and Widex Servers."
>>
>> At a minimum, there are Security Considerations implications
>> from this, particularly w.r.t. privacy of renderers.  I would
>> like to understand better the reasoning behind the requirement
>> for discoverability of Widex renderers.
>
> A TV set or a smart screen can play very well the role of Widex  
> renderer
> and it might be useful if you could use this as a secondary  
> display. Of
> course, privacy of the renderers is very important and implementers
> should balance what capabilities should be revealed and which  
> should be
> kept private. For example, somebody can choose not to reveal anything
> about the renderer besides that it is a Widex renderer but that will
> have quite negative impact as the server will not be able to  
> provide the
> UI that best suits the renderer capabilities, instead providing the
> default UI.
>
> Privacy concerns are valid also for the Widex servers which might host
> sensitive applications and you want to allow only specific
> users/renderers to interact with. Fortunately, these issues were taken
> into account by the designers of service discovery and session setup
> mechanisms.
>
>>
>> 5.3:
>> "   o  The WOs MUST contain only information having remote scope."
>>
>> I just don't understand this requirement.
>
> The meaning of WOs was defined in section 3.3. and specifically refers
> to the WOs.Event. Do you think that we need to be more specific about
> which WOs this requirement is about? We need to think that while
> developing the framework document we detected that we need more WOs  
> than
> initially envisioned in this document (e.g. WO.Selector) and the
> requirement should cover also those ones.
>
>>
>> 5.3:
>> "   o  The WOs MAY support multiple modes of interaction, and it  
>> is the
>>       responsibility of the application to synchronise modalities and
>>       not that of the Widex protocol."
>>
>> I believe this implies that multiple modes would indicate
>> multiple Widex protocol sessions. Is that correct?  It might
>> be good to state the implication.
>
> Yes, this implication in correct.
>
>>
>> Thanks,
>> Lisa
>>
>
>
>
> Thanks,
> Vlad
>
> _______________________________________________
> Widex mailing list
> Widex@ietf.org
> https://www1.ietf.org/mailman/listinfo/widex
>


_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex