NANC 412

Doc Only Change Order: FRS

Origination Date :05/31/2006

Originator:Neustar

Description:

The current documentation needs to be updated:

1.  NANC 399 data, SV Type and Alternative SPID are incorrectly shown in the NPA-NXX-X Data Model (Table 3-13).  These should be removed from here, and placed in the Number Pool Block Data Model instead (Table 3-8).  The change order definition for NANC 399 correctly shows these two items in the Number Pool Block Data Model.

2.  NANC 399 data, SV Type and Alternative SPID, Appendix E: Download File Examples.  These two items should be added to the numberPoolBlock-objectCreation and numberPoolBlock-attributeValueChange.

3.  NANC 352 data, SPID Recovery.  Service Provider specific tunables need to be added to the NPAC Customer Data Model (Table 3-2).  These two items include:  SOA Supports SPID Recovery, LSMS Supports SPID Recovery.  The default for both is FALSE.  These should also be added to the SP data elements requirement (R4-8), and also new requirements to define the tunables (similar to RR6-123, 4, 5).

4.  NANC 399 data, current status.  The current documentation lists 399 as “inactive in the NPAC”.  This note should be removed from the FRS.

5.  Appendix E, BDD File for Notifications.  The current documentation does NOT list Business Type and Timer Type for Object Creation Notifications, even though these two attributes are currently sent to the SOA over the CMIP interface.  The FRS will be updated to indicate the difference (i.e., they are NOT attributes in the BDD file).

6.  NANC 138, Definition of Cause Code.  Service Provider specific tunables need to be added to the NPAC Customer Data Model (Table 3-2).  These two items include:  SOA Supports Cancel-Pending to Conflict, LSMS Supports Cancel-Pending to Conflict.  The default for both is FALSE.  These should also be added to the SP data elements requirement (R4-8), and also new requirements to define the tunables (similar to RR6-123, 4, 5).  In order to maintain backwards-compatibility, the return response is slightly different for SOA and LSMS.  SOA:  if true, return on a query and return on a notification; if false, do not return on a query and return a replacement value of “1” on a notification.  LSMS:  if true, return on a query; if false, do not return on a query.

7.  NANC 399 data, SV Type and Alternative SPID, several requirements.  These two items should be consistently documented in the following requirements, RR3-210 and R3-7.2 (remove “if the requesting SOA supports Alternative SPID data”, so that both SV Type and Alternative SPID are consistent).

8.  Behavior clarification (new text in bold).  R5-16, Create Subscription Version - New Service Provider Optional input data.

NPAC SMS shall accept the following optional fields from NPAC personnel or the new Service Provider, when the subscriptionPortingToOriginal-SPSwitch is FALSE (ignored if value set to TRUE), upon Subscription Version creation for an Inter-Service Provider port:  (reference NANC 399).

9.  Behavior clarification (new text in bold).  RR3-275, SPID Migration Update – Rejection for ‘pending-like’ Number Pool Blocks or Subscription Versions

Add the following Note to the requirement:  “This applies to pending-like records where the OSP (migrating-from SPID) is either the code holder or the block holder, and also pending-like records where the previous port is an active record (migrating-from SPID is the NSP) that is being migrated (e.g., SV1 is active and will be migrated, SV2 is pending-like and will be cancelled).

Final Resolution:

Func Backwards Compatible:  YES

Correct the current documentation.

For #2, detailed updates attached:

  • Document within NANC 412

    Update Appendix E Download File Examples, Notifications Download File to reflect the SV Type and Alternative SPID attributes in the numberPoolBlock-objectCreation and numberPoolBlock-attributeValueChange notifications:

    In the numberPoolBlock-objectCreation notification add the following rows:

    Download the document Document within NANC 412

Implemented in FRS release 3.3.3a 2/28/07

Re #8: current implementation is documented: On PTO Create if Alt SPID is provided the request fails.  End-User Type/Value and Billing ID may be provided for both PTO and non-PTO.  On PTO Modify ALL attributes EXCEPT Alt SPID are accepted.  Alt SPID causes the modify request to fail.  On NON-PTO Modify all attributes are accepted – Alt SPID is only accepted if the SP Supports the attribute. Addl requirements are affected.

Related Release:

Implemented in FRS release 3.3.3a 2/28/07

Status: Implemented