[appendix]
= Technical Review comments

* *Comment 1*

Not sure you can reference 14-102 as it has never been uploaded outside of the SWG as pending for the TC, let alone public. 

* *Response to comment 1*

The reasons for referencing OGC 14-102 are:

* The servers deployed for this experiment using a REST binding of WFS.  This
binding is most completely described in OGC 14-102.

* This work is experimental.  By the time all the kinks have been worked out and
the content of this ER makes its was into the WFS specification, 14-102 will
likely be an adopted version.

* *Comment 2*

In 7.4.4 you have:

* "These parameters shall be set by a responding peer to communicate its service identifier and the checkpoint value to a requesting peer."

and 

* "These parameters may be set by a requesting peer to communicate its service identifier and a checkpoint value to a responding peer."

Does the responding server (beta) keep the record of requester and checkpoint?
I do see where the requester (alpha) keeps the responder and checkpoint. I
thought you had mentioned that in a telecon, but I missed it here.  Is it optional for the responding server to store that record?

* *Response to comment 2*

In order for a server to implement the sync operation it must do 2 things:

1. It must keep track of all changes made to all the feature that is offers (i.e. an AUDIT TRAIL)

2. For each requester it must keep track of the checkpoints in order to know up 
to which point each requester has been synced.

Requesters are identified using the "serviceId" parameter and the checkpoints 
are pointers into the responder's audit trail indicating that, that specific
requester has  sync'ed up to that point.

* *Comment 3*

In 7.4.2, If I, as Alpha, change my filter between requests, does that negate the checkpoint?  Say I want just schools within 1000 meters of me and we sync.  Then I say I want schools within 2000 meters.  Will the server limit the schools within 1000 meters response to changes since the sync and then give all schools between 1000 and 2000 meters, or would it think of it as a new sync and give all features within 2000 meters?  

* *Response to comment 3*

Except for the initial sync, every sync request has to include a checkpoint and 
every sync response (i.e. ChangeSet) has to include the next checkpoint to use. 
Put another way, any Sync request will negate the checkpoint specified on the 
request once the operation has completed (because the responding server will 
give you a new checkpoint each time).  This is true whether there is a filter
on the Sync request or not.  The filter has no effect on which records appear
in the change set or the checkpoint.  The filter only affects which records
from the change set are transmitted (or presented) to the requester.

Explaining just a bit further, you said "Say I want just schools within 1000 
meters of me and we sync".  The way you pose your question implies that it is 
the filter the determines which features appear in the change set.  This is not 
the case at all.  It is the Transactions that have been executed on the 
responding server that determine which features appear in the change set.  Once 
the set of changed features is known, THEN you can say give me all the schools 
in the change set that are within 1000 meters of me.  If no schools were 
modified (insert, update or delete) since the last checkpoint, no schools will 
appear in the change set and so your "schools withing 1000 meters of me" filter 
will not return any rows.  How does the responding server know which features 
are in the change set?  It simply looks that information up in the AUDIT TRAIL 
that I mentioned in answer to your first question.