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