Subject: Re: [Enum] New DNS record class values?

From: "David P. Peek" <[email-masked]>
Date: Wed, 19 Jan 2000 23:28:16 -0500

I'd like to comment on this issue now that a pointer to LDAP has been
brought up. (For those that dont know me I've been working with the
VMA (Voice Messaging Assoication) as the technical working group chairman.
We have been sponsoring VPIM voice messaging demonstrations with eight major
VMS vendors worldwide including a global directory service...the last
demonstration was
at Telecom 99 in Geneva. )  I feel we have learned a lot about
communications and messaging
over the last 18 months and I'd like to share a few key issues.

Services such as voice messaging (VPIM) and enhanced messaging systems
(unified messaging) will require additional information that can't be
supplied by a DNS server alone.  (e.g. Spoken-Name, preferred codecs,
individual preferences, vCards, LATA values, etc.)   For IP-PBX IP-Telephony
servers
and gateways they may not always be static depending upon service level
agreements
and individual gateway capabilities.  Service operators and network
operators are faced
with delivering large/global services where the users expectations are based
on high featured
local communications environments.   Our solutions must enabled the support
of these
features that require more knowledge then is available at the DNS level
alone.
With the use of LDAP external systems can query these attributes and
capabilities or even
retrieve rerouting information to support dynamic environments.

We have also found that service providers demand more control over access to
their data. Service providers and network operators want to control who has
access to entries down to the attribute level and service level.  This is
difficult to do with DNS alone.  Security of information such as what is
public and what is private can be eloquently supported using LDAP servers
with access control information.

A solution today that is gaining acceptance from large service providers and
messaging vendors is a two tiered model that uses both DNS and LDAP.   DNS
is being used as a Directory Locator Service (DLS) which really what this
group has brought up.  This DLS points to an Authoritative Directory Server
(ADS) containing specific information based on an E.164 number that is
controlled by large service providers and network operators. These ADS(s)
contain information needed for multiple services that need to be integrated
into communications and messaging platforms.  Integration is being driven by
service providers that need to deliver expanding services.  Performance is
also a concern with all proposed solutions and any ADS is expected to be
fast, highly available, fault tolerate, and redundant in order to provide an
expected quality of service.

The specific implementation is being debated and this ENUM work group can
clearly add value to
this for the DLS.

I look forward to hearing your comments about this two-tier approach that
combines DNS and LDAP.

>
>>
>>
>>Back again to the first solution (1) and let's use a NAPTR line from
>>Patrik's draft for an example:
>>
>>   IN NAPTR 102 10 s potscall+N2R "" _potscall._tcp.paf.swip.net.
>>
>>I believe this NAPTR line ought to look something like this if we want to
>>omit the SRV record:
>>
>>   IN NAPTR 102 10 p potscall+N2R ""
>>_potscall._tcp.2.8.0.4.6.2.6.5.8.6.4.e164.int.
>>
>>I'm not quite happy with the format above since "potscall" is not an
>>internet service, although the CLASS parameter (class=IN) says so. Further
>>more, the protocol that the "potscall" service uses is a SCN-protocol like
>>ISUP, not TCP.
>
>
>I must agree with your basic premise. I've never been too happy with the
>place holder syntax myself. Your suggestions are most welcome.
>
>
>
>>The ENUM requirement draft says that "The system MUST support existing
local
>>number portability mechanisms" and should not "impede future global number
>>portability" So, does the solution above support number portability?
>>
>>Well, the NAPTR record can rewrite a dialed number and, for instance, add
a
>>routing prefix. However, global routing prefixes are seldom appreciated by
>>SCN operators since they often interfear with local number plans and local
>>routing prefix schemes. It's probably better to specify the terminating
SCN
>>operator explicitly and let the operator map it to locally significant
>>routing information. The NAPTR record might then look something like this:
>>
>>   SC NAPTR 102 10 u potscall+N2R "" [email-masked].
>
>Now this is also very interesting. In private conversations I've heard talk
>about the possibility of the DNS record actually carrying the LRN

>Location Routing Number ] for the terminating switch or somehow creating a
>pointer to a database [LDAP?] for retrieving that data.
>
>In your opinion what might be the best approach to this?
>
>
>
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>Richard Shockey
>Shockey Consulting LLC
>8045 Big Bend Blvd. Suite 110
>St. Louis, MO 63119
>Voice 314.918.9020
>eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
>INTERNET Mail & IFAX : [email-masked]
>GSTN Fax 314.918.9015
>MediaGate iPost VoiceMail and Fax 800.260.4464
><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
>_______________________________________________
>enum mailing list
>[email-masked]
>http://www.ietf.org/mailman/listinfo/enum
>

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

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 20 Jan 2000 06:48:50 +0100

> I look forward to hearing your comments about this two-tier approach that

That is one way of spreading/collecting more information about an E.164
number.

The charter for the ENUM working group have though limited the scope  of
their work to only work with the basic listing service, and not go into the
discussion of where to store spoken name and other higher-level attributes.
Discussions about those imply that things like access control must be
resolved, which is not an easy task across boundaries between legal bodies
(such as two ISPs).

So, my personal view is that we will have exactly this two-tier approach
which you talk about. A basic listing service so I very easilly can get
information about what services exists so I can initiate the next step in
call setup, routing exploration, getting more information about peer etc.
This second layer can though often be different between different protocols
or type of endpoints (one way in VOICE, one way for FAX, one way in the
local environment etc).

ENUM is though not the place to discuss it, but Scott should probably say
that :-) 

   paf

---

From: Graham Klyne <[email-masked]>
Date: Thu, 20 Jan 2000 12:01:18 +0000

>I look forward to hearing your comments about this two-tier approach that

A similar, but very much more lightweight, approach currently under 
consideration is RESCAP.

#g

------------
Graham Klyne
([email-masked])

---

From: Richard Shockey <[email-masked]>
Date: Thu, 20 Jan 2000 09:58:24 -0600

>he charter for the ENUM working group have though limited the scope  of

Which is why Local Number Portability data is maintained by 3rd parties :-)

>or type of endpoints (one way in VOICE, one way for FAX, one way in the

I agree completely agree with Patrik. I'm convinced the 2 tier approach is 
the one that will be  globally deployed.  I have read all of  Greg 
Vaudreuil's excellent vpimdir ID's on this subject and have found them very 
instructive on what goals and requirements the voice messaging industry has.

Richard Shockey
Shockey Consulting LLC

---

From: Richard Shockey <[email-masked]>
Date: Thu, 20 Jan 2000 10:05:16 -0600

>A similar, but very much more lightweight, approach currently under 

I wish we had it NOW so we could consider its use. I still have questions 
about the speed of LDAP response during call setup.

Even if RESCAP were ready we would then still have to have a SRV record 
pointing to the host where the RECSAP data is maintained. I've begun to 
reject the idea that RESCAP data could be contained within the 164 DNS data 
record...even if you used the "kitchen sink" RR.  I think we would be very 
close to pushing the 256 byte limit.

Richard Shockey
Shockey Consulting LLC

---

From: Dean Willis <[email-masked]>
Date: Thu, 20 Jan 2000 14:21:30 -0600

> features that require more knowledge then is available at the DNS level

I'd like to point out that one way to transmit the additional information is
in the context of a URI.

This approach is proposed in:

http://www.ietf.org/internet-drafts/draft-campbell-sip-service-control-00.tx
t

If rather than LDAP, one uses ENUM approaches to locate the SIP server
responsible for dealing with a number, then this kind of URI-loading can be
brought to bear.

--
Dean