No corrections were requested to the November Slow Horse minutes.

In the November LNPA minutes, the revised date for Region 7 was corrected to 3/5 rather than 3/2.

The WNPSC’s minutes are distributed separately. NENA is working on PSAP display requirements for periods of mixed service. NENA has requested that it be made more clear in the Wireless / Wireline Test Plan that testing will include ports from wireless to wireline.

The Slow Horse subcommittee did not meet in December. Because the LSMS availability monitoring capability will not be implemented until release 4.0 and the NPAC traffic data report will not be available until June of 2000, the LNPA decided to not hold separate Slow Horse meetings from January through May. We will maintain an agenda item to discuss slow horse issues during the LNPA-WG meetings.

PIM-5: The working group reviewed Steve Addick’s contribution, which was previously distributed. It was made clear that the Old SP would be given the option of, but not be required to take action to restore the customer who’s service was physically moved without porting the number.

Several SPs expressed concern that it is inappropriate to allow unilateral porting for the scenario where the customer is moved to a different network, but not ported. The group felt that this scenario is very unlikely to occur in practice. General concern was expressed that both the "port in error", and "failure to port" scenarios could be misused and should not be accepted.

One SP re-iterated that the best way to address these situations is for all service providers to provide a 24x7 repair contacts.

After discussion, the LNPA decided to go forward with the PIM and request the LLC to forward a revision adding the new failure to port scenario to Neustar.

NOTE: On Thursday 12/14, Neustar expressed renewed concerns over the legal and neutrality implications of the processes proposed in this PIM, and asked the PIM’s sponsor to consider dropping the request. (SEE THURSDAY NOTES.)

The working group agreed to add a scenario to the business need that this function could be used to split an existing SPID into multiple SPIDs. One possible need for this would be a case where an SP wishes to create a separate SPID for a specific state.

We reviewed the proposed change. Because of the magnitude of the changes required to accomplish a SPID change, this function will require all affected SPs to receive a mass update file from NPAC.

We also discussed the impact of a SPID change on pending and failed SVs. The requirements will be updated to be clear that the NPAC needs to change the SPID on pending SVs. The mass update files (smurf files) were only planned for updating LSMSs & NPAC. However we also need to update the SOAs in a similar fashion. (The change files contain a list of rules for changing SPIDs, not a list of SVs to be changed.)

Sprint will write up the business need changes we agreed to and send it to the CMA. The CMA will bring the revised requirements to the next LNPA for approval and forwarding to the LLC.

Neustar reviewed the change order to propose a reduced cost version that provides similar, if not the full functionality required. The functionality that Neustar proposed eliminating is:

The LNPA WG discussed alternatives such as having some other entity (perhaps the LLC) track the historical and appeal data from the monthly report. This historical tracking could be as simple an Excel spreadsheet or a manila folder. It was pointed out that if this data is to be used to penalize SPs for poor performance in the future, there is an advantage to having a neutral third party, like Neustar, be the keeper of the data.

The group discussed the maintenance window calculation requirements at length. The proposal by Neustar would only allow a fixed length window each week of the month. We determined that there is no requirement to adjust the maintenance window by SP, but we will need to be able to accommodate different maintenance windows on different weeks of the month. (Currently the Canadian region only has maintenance windows twice a month.)

Many SPs questioned the rationale for the proposal to remove functionality. Neustar responded that these are just cost savings proposals, and the SPs are free to retain any or all functionality if they wish. The group agreed to consult with their companies and vote on the proposed cost reduction measures on Thursday. (All four proposals were overwhelmingly rejected. See Thursday notes.)

Last month, SPs were asked to review the implementation of ILL 23 and determine if the frequency, size, and sampling technique used for the data integrity report are adequate.

The SPs determined that the sample size and sampling technique are inadequate, but they do not desire to develop additional capability to enhance the data integrity report requirements.

The LNPA unanimously voted to cancel ILL 23.

Discussion was deferred until January.

We discussed the alternative of establishing an industry quiet period while systems are updated.

We discussed how this will affect congestion and the recovery processes. We also discussed the potential for multiple associations per SP, where the association function of the associations is different. The following clarifications were made:

The working group agree to leave NANC 219 as is, and to either change ILL 5 as required or to propose further changes as required.

This change request was cancelled.

It was pointed out that we have not identified how many user levels are required, and what functions should be assigned to each level.

It was asked whether adding this functionality is outside the scope of what LTI was created for. LTI is intended as a minimum functionality system; how much should it be enhanced? Does this set a precedent? Can this business need be addressed with user education rather than enhanced functionality? Or can it be addressed with a warning that by generating a report the user will incur additional charges.

None of the representatives at this December discussion use LTI as their primary SOA system. The group believes that the LTI users need to define these requirements. Jean Anthony will compose an e-mail requesting input from LTI users and forward it to Neustar. Neustar will forward the message to their LTI users distribution list.

After much discussion we decided three change orders are needed:

No updates or action items.

We discussed the business need for this CR. The working group agrees that the root problem is inadequate availability of some LSMSs, and that this CR does not improve that problem. Additionally, the associations monitoring in release 4.0 should give us the information needed to improve local systems availability. Therefore we agreed to defer 311discussion until after 4.0 implementation.

Proponents of the CR believe an SP may delay the cut of a customer if the incumbent SV’s association is down. Opponents of the CR suggest that for large cut overs, the NSP can call the incumbent to determine their status, and for small cut overs, it is not reasonable to hold a cutover based on one SPs association’s status. It was also suggested that from a global perspective, it would be better to just address the problem of poor local systems reliability than to load the NPAC with more functionality.

The proposal to create a web page showing the status of all associations that is periodically updated (a period of updating once every 5 minutes) was suggested. The merit of adding a process which requires the NPAC to monitor and status this regardless of whether any users require the data was questioned. The proponents of the web site approach expect a high volume of associations status queries, the opponents expect a much lower query frequency and are more concerned with the ongoing load on the NPAC to maintain the website.

It was suggested that NPAC edits need to be added to enforce the following required behavior:

Readout from Rob Coffman: Neustar is testing point release 3.0.11 in their lab now. The 3.0.11 release will be available for industry testing 12/18/00. The final version point release is scheduled to be available for industry testing the week of January 15^th. This will support performance testing on 1/22/01, and disaster recovery on 1/29. The general availability dates are:

NOTE: THESE DATES ARE NOT FIRM. (This proposal needs to go to the LLC.)