The -04 version of the Widex Requirements draft has addressed
all of the comments in my Gen-ART review, and hence is ready for
publication as an Informational RFC.
Many thanks to the authors,
--David
p.s. My spell checker wants to render Widex as Windex - I
suspect there's a horrible UI joke hiding in there ...
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
[EMAIL PROTECTED] Mobile: +1 (978) 394-7754
----------------------------------------------------
> -----Original Message-----
> From: Black, David
> Sent: Tuesday, December 19, 2006 6:24 PM
> To: [email protected]; '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
> Cc: Black, David; 'Dean Willis'; 'Lisa Dusseault'
> Subject: Gen-ART review of Widex Requirements Draft
>
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> 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.
>
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA 01748
> +1 (508) 293-7953 FAX: +1 (508) 293-7786
> [EMAIL PROTECTED] Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>
>
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
