Question about checkprop feature of repadmin

I'm working my way through the repadmin white paper found here.

http://www.microsoft.com/en-us/download/details.aspx?id=9028

I'm a bit confused by the checkprop feature.  I believe the intent of the command is to determine whether or not all domain controllers are up to date with respect to a particular domain controller. 

The syntax of the command is as follows

I have several questions about the command

1. DC_LIST:  I believe I have to specify a DC here because repadmin may not be run from a domain controller.  Is that correct?  If I am running repadmin /checkprop from a DC called"foodc1" but specify "foodc3" for the "DC_List" argument then foodc3 will make all of the queries that checkprop needs to make.  Is that correct?
2. NamingContext:  I'm confused by the need to specify a naming context.  If the point of checkprop is to check if all domain controllers are up to date with respect to a particular domain controller and a particular USN then why specify a naming context at all?  I suspect there is something about USNs and naming contexts which I don't understand here.
3. OriginatingInvocationID:  I understand that this is the invocationID of the AD database on the domain controller which is your baseline for checking replication up to dateness across all domain controllers.  However why does it need to be in GUID format, why not just specify the name of a DC.  One thought I have is that you might need to use checkprop to see how far a change which originated on a now dead (or authoratively restored) DC got.  Is this correct?
4. OriginatingUSN:  Why do I need to specify this at all?  The example in the repadmin whitepaper has you use repadmin /showutdvec to get the highest USN from the baseline DC (same DC as the originatingInvocationID).  However if that is the case why specify it at all?  One thought I had was you may want to get the USN of a particular attribute and run that against checkprop.  Then you could see how far a particular attribute from the dead DC has replicated throughout your environment.  Is that correct?  Are there other reasons or tricks?
5. I'm making the assumption that the Originating USN needs to be from an attribute on the OriginatingInvocationID.  It seems to me that it doesn't make sense otherwise.  Is this a correct assumption?

I'd appreciate any comments or answers to my questions.  I feel I might be missing something fundamental, particularly around the interaction of USNs and naming contexts. 

Thank you for any help

Craig.