Team,

As promised - these are the issues/assumptions/definitions we identified

on today's call:

1) ALL Pooled Numbers must have a"pooled" indicator. This is true

regardless of which option is selected. The assumption is that a

"pooled" indicator is required to support cost allocation and unique

processing strategies. Therefore it is irrelevant whether we preport or

snap back, this pooling indicator is required.

2) Snap Back Definition - For the purposes of this subcommittee snap back

is framed in terms of NPAC SMS functionality only. This does not apply

to separate M&P processes an SP may support. More specifically, snap

back requirements in the NPAC SMS mean either there are requirements to

snap back to a block holder or no unique requirements, allowing the NPAC

SMS to behave as currently designed i.e. snap back to code holder.

3) There is an issue regarding Intra-SP ports and tracking of pooled

numbers: here is my attempt at explaining both sides of the issue:

Side A)

If there is no preporting , the block-owner SP will create an Intra-Sp

port when the TN is assigned. This TN remains marked as pooled. If the

SP creates a subsequent Intra-SP port, the TN should not be counted as

pooled but now ported. If preported and SP enters a Intra-SP port this

same logic would apply i.e. now ported not pooled

Side B)

If there is no preporting when the TN is assigned the block-owner SP will

create an Intra-Sp port when the TN is assigned. This TN remains marked

as pooled. If the Sp creates a subsequent Intra-Sp port, the TN will

remain marked as pooled. If preported and SP enters an Intra-SP port

same logic applies - TN stays pooled.

I hope this captures the spirit of our issues and we willl continue to

discuss on Monday's call at 4 pm, CDT

Donna

LNP Diva