[Ecrit] Review of draft-ietf-ecrit-lost-sync-04

[Richard Barnes <rbarnes at bbn.com>]

I reviewed lost-sync-04 in order to update my earlier comments on -01.
This version is much improved from the previous versions in terms of
specificity (although it's still vague in places).  It still seems to me
that there are a few layers of detail missing.  Specific comments below.
--Richard

1. The document describes transactions for requesting and delivering
mapping structures, but doesn't describe at all how these transactions
create a synchronization system.  There is clearly some tracking of
state needed (especially for "pushMappings"), and the document is silent
on how this state is initially established and then maintained.

2. In a similar vein, it would be helpful for this document to have some
discussion of how this synchronization system relates to others that are
out there (e.g., rsync).  Since the name of the draft is
"synchronization", there should be some discussion of how bidirectional
sync is handled.

3. It seems like there should really be only 3 message types here
instead of 4: (1) a "syncRequest" message sent from destination to
source (getMappingsRequest), (2) a "syncUpdate" message sent from source
to destination (getMappingsResponse == pushMappingsRequest), and (3) a
"syncResult" message sent from destination to source
(pushMappingsResponse).  There can still be two types of transaction,
but they're determined by which type of message (syncRequest or
syncUpdate) is sent in the HTTP request.

4. In a similar vein to 2 and 3, the use of "client" and "server" is
confusing.  I would suggest using more appropriate names for these roles
like "source" and "destination", along with some text that explains how
these roles map to HTTP roles in each type of transaction.

5. My comment about the security considerations has not been addressed.
 The security considerations section is essentially a pointer to LoST,
but this protocol is only peripherally related to LoST (at a technical
level).  Since it's about synchronization, I would expect this document
to note that the primary risk is the injection of false location
information (since the mappings themselves are public), which means that
the parties should use HTTPS to carry the XML, authenticate the source,
and use a ciphersuite that provides integrity protection to messages.