Subject: [drinks] review of CORInfoType: CORclaim and CorClaimApproved

From: Jean-Francois Mule <[email-masked]>
Date: Thu, 29 Jul 2010 07:06:38 -0600

We met with Ken and Syed to discuss some of the todo list on the protocol document a couple of times this week.  Here is one set of notes regarding the elements dealing with carrier-of-record indication.

We discussed the procedures and XSD definitions around carrier-of-record: CORInfoType, COR claims and approvals.

Protocol changes and fixes:
We plan to make the following changes in draft-02:
1/ corClaim must not be in both TNType and TNRType because of inheritance (just put it in TNType)

2/ change the name "corClaimApproved" to just "cor"
because the status of a claim may be approved based on a claim (corClaimApproved=true) but then it may change due to a port out operation later and become (false).  So the status of a cor is actually independant of the initial claim in the way we envisioned this functionality to work.
On a given public identifier, the "cor" element represents whether or not the registrant of the record is the carrier-of-record.
3/ add an optional dateTime element associated with the cor
This dateTime will indicate the timestamp of the COR validation (and if the cor is changed due to a port, the timestamp of that change).
4/ verify that the client cannot also set the cor element (previously CORclaimApproved) when provisioning a public identity.

Text changes to add explanation and other text inside the document:
In addition, the following text should be added in the right places:
a) A client SHOULD provision a PI with CORclaim set to true if the registrant of the PI is the carrier-of-record.
b) The server may have a process to validate COR claims and will then set the validated records with "cor"  set to true.
c) explain that the "cor"  for a TNRange must be set to false if only one of the TN in that range is not validated.  The value of the indicator is diminished in that case.  However, we feel that if cor is true for a TNRange, it does carry quite a lot of meaning (it means all the numbers in the TN Range have been validated).

Discussion on registry policy:
Based on our understanding, there are different types of Registry implementations:
- a registry implementation may accept a Public identity with COR claims no matter what, then decide later to validate the claim and set the "cor" accordinly
- a registry implementation may reject the provisioning of a PI with CORclaim for which the registrant is not the carrier-of-record at the time of provisioning

We think that the protocol already allows both but we agreed it would be good to add some text for client implementers to understand that these 2 types of behaviors exist.
- in the first case, the client will always see its provisioning commands succeed, then will have to "pull" the registry to find out which ones are not approved.  This works well for TNRange provisioning where the client does not have to worry about which ones inside the range are ported out to another registrant.
- in the second case, the client will know at the provisioning time which commands failed.
One of the issues is for bulk commands where only a few numbers may fail to be COR validated  and therefore, the whole bulk provisioning is a fail.  In this case, the response to the bulk provisioning command does not provide enough details on which numbers failed.  We think it is the client's responsibility to clean up the list of PIs, and re-submit.

Comments welcome.

Jean-Francois.