base draft version 09

  “An SRP-ID-number is considered unacknowledged and cannot be reused
until a PCErr or PCRpt arrives with an SRP-ID-number equal or higher
for the same LSP. A PCRpt with state "Pending” is not considered as an
acknowledgement.” - INa - this text is incorrect, as it will lead to
unacknowledged SRPs if you send for going-up, and was  removed, this is
leftover from Robert’s initial efforts on doing SRP without SRP
For end-of-sync, specify that you send an empty ero (Siva and Ramon)
clarification on error handling when the signaling of a path fails.
added back pcreq and pcrep
handling the wrap of srp-id and avoiding leaking ids.

Minor
Ed and Ina’s names together (Julien’s request because at the same
company)
Rename the section “"Architectural Overview of Protocol Extensions"” to
“overview of teh protocol extensions” ( per Cyril 2/25)
Lsp-id-tlv had the wrong length (after the addition of the endpoint
address in version 07) 2/25 [Hari]
Replaced “pending” state with “going-up” - “ For each LSP, it sends an
LSP State Report carried on PCRpt message to the PCE, indicating that
the LSP’s status is ‘Pending’. “ [Hari] What is the “Pending” status
corresponds to in LSP Object ? - modified to going-up
"If the PCRpt message is in response to a PCUpd message, the SRP object
SHOULD be included and the value of the SRP-ID-number in the  SRP
Object MUST be the same as that Should be MUST, not should (originally
it was should because cannot be enforced, but there is a good point to
mandate) - Cyril 2/25
flags field - fix size of the operational field (3 instead of 2 in the
figure), fix the iana text to relate to the correct numbering starting
with bit 0