Document: draft-ietf-widex-requirements-03
Reviewer: David L. Black
Review Date: December 19, 2006
IETF LC End Date: December 25, 2006

Summary:
This draft is basically ready for publication, but has nits
that should be fixed before publication.

Comments:
A short draft describing the requirements for the widex framework
and protocol design.  It's generally in good shape - all of these
comments are minor.

The opening sentence of section 3.4 mentions "the Widex working group".
This mention should be removed as the published RFC will significantly
outlive the working group.

Section 3.4 switches between Widex objects and messages entirely too
quickly, e.g.:

   There are two types of Widex Objects:

   WO Update (WO.Update):
      WO.Update messages contain description ...

The word "messages" should be removed from Section 3.4 and replaced
by "objects" throughout to avoid this confusion, especially as a Widex
"message" may wind up containing multiple "objects".

Section 4.1: 

   o  The framework MUST be modular, e.g. multiple service discovery and
      session setup mechanisms may be used.

Nice examples, but a list of components that MUST be replaceable would
be even better.

   o  The synchronisation MUST occur at a fairly loose level that allows
      for a simple approach to propagating changes.

Synchronization of what with what?

   o  The framework and the synchronisation protocol SHOULD be
      stateless.

Huh?  As I understand what's going on, there's a large XML document
on both sides that describes the user interface, and the exchanged
objects describe changes to that document.  That does not sound like
a stateless protocol.  What was this supposed to mean?

Section 4.3:

   o  The Widex Objects MUST support client initiated updates.
   o  The Widex Objects MUST support server initiated updates.

Should that be client initiated events (cf. interfaces in
diagram in Section 2)?

Section 6:

   As a means to support remote user interfaces, a number of security
   considerations need to be addressed, including the potential for
   unauthorized access to application services, monitoring of
   interactions by unauthorized third parties, spoofing of application
   services as a means to support phishing attacks, and denial of
   service attacks.  Requirements defined in this document MUST allow
   for the implementation according to best common practices.

The last sentence seems wrong, as it's pointing to this draft - it
should be placing requirements on the to-be-designed widex protocol
and framework to address these considerations.

Also need a new email address for Vlad ...