Subject: [Enum] ENUM Requirements comments

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Wed, 12 Apr 2000 09:34:25 -0500

The following are specific comments on the requirements document, some of
which I presented at the working group meeting in Adelaide.  
 
Net-new Requirement
 
Interoperability Goals
 
     This solution SHOULD work with the common, deployed DNS
     resolver libraries in the most common operating systems.  It is
     understood that application clients will have to be created that
     understand the specific "schema" for ENUM address resolution.  
     Requiring a new generation of resolvers or DNS servers will impose 
     an excessive barrier to widespread adoption of this service.
 
Suggested Revised Requirements
 
3.1 Endpoint address lookup
 
I do not believe the solution must return a URL for a specific service.
While this may be useful for a particular service using ENUM, other services
such as email routing or service location simply need a domain name.  I
suggest the following revised text:
 
    "The system SHALL provide a service for the retrieval of service
specific endpoint addresses (e.g., email address, IP address, SIP address,
URL, etc. ) or the retreival of the addresses of servers, if available,
which may contain this endpoint information."
 
3.5 Provisioning
 
The ENUM service clearly has to be provisionable in the real world.  Given
that telephone numbers are delegated top-down in a hierarchical manner with
existing administrative structure, I believe we have a requirement to make
the system work within that structure.  It may also support many other
administrative models, but at at minimum, it must meet this existing one.
Further, because in the real world, the authorities to which telephone
numbers are delegated are not involved with specific service registratration
or arbitration (remember slaming?), at a minimum, it must be possible for
the server that provides telephone number delegation information to be
separate from the one that provides service specific information. To this
end, it must be possible to redirect the query from the E.164.foo domain
into the domain of the assignee of a given telephone number.  I suggest the
following revised text:
 
    "The architecture and protocol MUST support at least the existing
administrative model as the current E.164 telephone number delegation
system.  It SHOULD NOT require an additional centralized administrator
beyond that required for the existing telephone number system.  Further, it
must be possible for the authority to which a telephone number has been
delegated to redirect the query to a different entity which provides
service-specific information for that number."
 
3.8 Scaleability
 
The ENUM service must support the return of service-specific information
based telephone number ranges on digit boundaries.  While local number
portability is expected to imposes a per-user provisioning requirement for
some countries in the near future, most of the billions of phone numbers in
use today and most for the forseable future will be delegated and served in
blocks.  At the current time, most numbers within these blocks have
identical sets of available services.  A requirement that per-number
provisioning is required for the initial ENUM service to be deployed is
unacceptably high.  I suggest the following revised text:
 
    "The system MUST scale to handle quantities of telephone numbers and
queries comparable to current and expected future PSTN usage.  Further,
because most phone numbers are assigned in blocks to entities with
homogenous service profiles, it must be possible to operate the system based
on telephone number blocks defined at the digit boundaries.  The system
SHOULD NOT require, but MUST support explicit per-number configuration."
 
3.9 Query Performance
 
It must be possible to administer the ENUM service such that the current
user expectations for latency in telecommunications services can be met.
This latency expectation is currently for a 2 second response 95% of the
time and a 5 second response 99% of the time.  Given that ENUM is only part
of the lookup required to fufil many service, and that SIP, LDAP, or others
will also be needed, the performance budget for ENUM is tight.  In
particluar, if the protocol is designed such that it is not possible to
administer the system to a 1 second response 95% of the time, the system
will not have met this requirement.  I suggest the following revised text:
 
    "It SHOULD be possible to administer the ENUM service using the selected
protocols and structures such that the current user expectations for latency
in telecommunications services can be met.  In particular, it SHOULD be
possible to operate the system in such a manner that an ENUM query for a
service-specific record can be satisfied within one second 95% of the time
and that within two seconds, the query can be satisfied 99% of the time."
 
3.10 Other PSTN numbering services
 
We have discussed at length that the resolution of non-e164 based telephone
numbers is outside the scope of this work item.   The clarity from those
discussions should be reflected in this requirement.  I suggest the
following revised text:
 
    "Other PSTN type services such as Emergency 911, directory assistance
411, and other carrier codes for services accessible via non-E164 (or
subset) telephone number service access codes are outside the scope of
ENUM."
 
2.12 Competition
 
I disagree that this requirement as stated is real, and further assert that
it cannot be met as stated.  There can only be one authorative source for
information about a given phone number, the single authority to which it has
been delegated.  If this is not true, there is no possiblity for a client to
authenticating the validity of the response without extensive out-of-band
configuration information, additional service specific information, and
interactive end-user selection.  I suggest the following replacement
requirement:
 
    "The solution should permit competing service providers to offer
telecommunications service for a given number.  Competing telecomunications
services should be enabled where the ENUM entry is administered by the
single entity to which the number is delegated."

Greg V.
[email-masked] <mailto:[email-masked]>  

 

_______________________________________________
enum mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/enum