Subject: [drinks] Agreed on Protocol To-Do List

From: "Cartwright, Ken" <[email-masked]>
Date: Thu, 29 Jul 2010 10:53:29 -0400

Design team has just agreedd on the following action items and ownerships.

Updated To-Do List:
JFM has the "token" until next Wednesday.

1) (Ken) Write the add/get Destination Group operation sub-sections of section 8.
2) (Syed) Write the general "del" operation sections of sub-section 8.
3) (Alex & Ken) Make sure that the portions of section 8 that I wrote and the portions that
Syed will write are in sync from a specificity standpoint and a functionality
stand point, and that they are all correct from a spelling and grammar
perspective.
4) Update/tweak/add sections that describe the XSD and protocol concepts that
 apply to all of the operations in section 8.  This includes the following:
         a) (Ken) BasicRqstType  and BasicRspns Type
         b) (Syed) BaseObjType
         d) (Syed) Transactional boundaries and transaction IDs
         e) (Ken) Response codes
         f) (Ken) Authorization to objects and information
         g) (???HowDoWeWantToDocumentThis)??? Object keys (business keys vs synthetic keys).
         h) (Syed) spppRequest and spppResponse data elements and the "transactional"
 element.  Related to (d) above.
         j) (Ken) Organization ID documentation.
 5) (Syed) Evaluate and incorporate what Syed comes up with on the open number plan
concept and add this into Syed's Public Identity portion of section 8.
6) (Syed, Alex for SIP Redirect example) Add more information in section 8 to explain how the URIType is used (to
meet the LUF requirements).  This will be part of an example section.  We will add an example appendix at the end.
7) (JFM first pass then, Ken) Clean up and partially re-organized the introductory sections 1 through 7 to make them more
focused and clear cut.  Perhaps move parts of their content into section 8, etc.
7.5) (Alex) Review the requirements section.  I'm not sure why we have the use cases and requirements re-stated in this
document.  I think we should not do that.  Also see my comments on section 1 through 7 sent out on Monday, 7/26.
8) (Sumanth) Make sure the terminology and definitions in the intro sections are now in
sync with our new understandings of the use cases in the use case document.
9) Updates to Public Identifier Type Documentation and XSD as follows:
       a) (JFM)corClaimStatus boolean instead of "approved" enum and corClaimStatusChanges date/Time
       b) (Syed) Open numbering plan support for TN Range
       c) (JFM) TNRange should not inherit from TN
11) (Ken) File based bulk provisioning.
12) (Ken, Alex) Data validation rules for each data element.

________________________________
From: Cartwright, Ken
Sent: Thursday, July 29, 2010 8:57 AM
To: Jean-Francois Mule; Syed Wasim Ali
Subject: RE: For review - review of CORInfoType: CORclaim and CorClaimApproved

Protocol To-Do List:

Using the previous to-do list I'd put together back in June, adding in the items from JFM's notes below, and items from my review of the document this Monday, I'd like to offer the following to-do list and proposed allocated ownerships.  Needless to say, these ownerships are just a suggestion as I certainly do not manage the time of others on the design team.  We can walk through this as a group today and modify it as necessary:

1) (Ken) Write the add/get Destination Group operation sub-sections of section 8.
2) (Syed) Write the general "del" operation sections of sub-section 8.
3) (Ken) Make sure that the portions of section 8 that I wrote and the portions that
Syed will write are in sync from a specificity standpoint and a functionality
stand point, and that they are all correct from a spelling and grammar
perspective.
4) Update/tweak/add sections that describe the XSD and protocol concepts that
 apply to all of the operations in section 8.  This includes the following:
         a) (Ken) BasicRqstType  and BasicRspns Type
         b) (Syed) BaseObjType
         d) (Syed) Transactional boundaries and transaction IDs
         e) (Ken) Response codes
         f) (Ken) Authorization to objects and information
         g) (???HowDoWeWantToDocumentThis)??? Object keys (business keys vs synthetic keys).
         h) (Syed) spppRequest and spppResponse data elements and the "transactional"
 element.  Related to (d) above.
         j) (Ken) Organization ID documentation.
 5) (Syed) Evaluate and incorporate what Syed comes up with on the open number plan
concept and add this into Syed's Public Identity portion of section 8.
6) (Syed) Add more information in section 8 to explain how the URIType is used (to
meet the LUF requirements).
7) (Ken) Clean up and partially re-organized the introductory sections 1 through 3 or 4 to make them more
focused and clear cut.  Perhaps move parts of their content into section 8, etc.
And I'm not sure why we have the use cases and requirements re-stated in this
document.  I think we should not do that.  Also see my comments on section 1 through 7 sent out on Monday, 7/26.
8) (Ken) Make sure the terminology and definitions in the intro sections are now in
sync with our new understandings of the use cases in the use case document.
9) (Syed) Updates to Public Identifier Type Documentation and XSD as follows:
       a) corClaimStatus boolean instead of "approved" enum and corClaimStatusChanges date/Time
       b) Open numbering plan support for TN Range
       c) TNRange should not inherit from TN
11) (???) File based bulk provisioning.
12) (???) Update LRF / LUF sections of the document and move after section 8.
10) (?Who/When/If?) Prototype a small implementation of the final XSD to make sure
we have not missed anything.  We can't be sure that we have al the right bases
covered the right way until we prototype it.

________________________________
From: Jean-Francois Mule [[email-masked]]
Sent: Tuesday, July 27, 2010 5:31 AM
To: Syed Wasim Ali; Cartwright, Ken
Subject: For review - review of CORInfoType: CORclaim and CorClaimApproved

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

Protocol changes and fixes:
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.

Changes to add explanation and other text inside the document:
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.
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.

Jean-Francois.

________________________________
This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.