Subject: RE: [Enum] draft-ietf-enum-operation-00.txt

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 20 Jul 2000 10:35:03 -0400

> -----Original Message-----
> From: Patrik Fältström [mailto:[email-masked]]

> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-ietf-enum-operation-00.txt
> 
> I object to the following parts in this draft:
> 
> >An
> >    effective ENUM service requires that DNS time-to-live 
> fields be set
> >    to an appropriate value consistent with the telephone number
> >    reassignment policies if the delegating authority.
> 
> Having a too low TTL is not appropriate in DNS. Therefore this draft 
> needs to be much more specific on when a number is possible to change 
> according to a "slow" or "fast" update. In normal telephony systems, 
> the switch itself (or accordingly) handles "slow" updates, and IN 
> systems handle the "fast" updates.
> 
> DNS is only suitable at this stage for "slow" updates.

I'd like this settled, myself. I've seen claims on this list that DNS can
now be updated in seconds, including master and slave servers. True? False?

> I claim DNS is not suitable for fast updates just because DNS do have 
> caching and do have delay between updates of slave servers from the 
> master servers. We should and can not fight that. If DNS one day can 
> handle "faster" updates, fine, but today we have a certain limit in 
> what speed DNS updates propagates over the Internet.

Bert
[email-masked]

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

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 21 Jul 2000 09:01:10 +0900

>now be updated in seconds, including master and slave servers. True? False?

Updated in seconds IFF all servers:

- Can handle the extension NOTIFY
- Have enough spare CPU-cycles to actually request a zonetransfer within
   a short time span after a NOTIFY arrives
- Have enough I/O to transfer and handle the zone itself (or can handle
   IXFR for incremental updates) within the timespan

Most servers can handle all of the above.

What is not true though is that we can set TTL to zero. That have 
some weird consequences which caching and the impact on the number of 
queries that are sent. Having TTL on an RR zero is not recommended at 
all. 15 minutes, ok, 15 seconds....hmmm....I would not have that.

So, I would say that 15 minute delay for updates are probably pretty 
ok, so for updates that need faster updates (propagation time is what 
I would like to call it) than 15 minutes should update the 
information somewhere else than in DNS.

Personally, I feel that a redirect of a phonecall with 15 minute 
delay of propagation is normally quite ok. I.e. when I am at home and 
request the number at home to be redirected to my cellphone, it takes 
me more than 15 minutes to take on my shoes, jackets, forget the car 
keys, find them, find the cellphone, pick up my bag, leave the house 
and go to the car.

I have no experience in what propagation time one have in the 
traditional phone system, but do know that the time is different 
depending on what operation you do. For example, when changing data 
within one IN system, the update is probably quite fast (modulo time 
for eventual mirroring internally in the database that the IN system 
uses) while porting a phone number between two telco's is probably 
slower (slower than 15 minutes).

    paf

---

From: Hong Liu <[email-masked]>
Date: Thu, 20 Jul 2000 21:44:42 -0400

Patrik,

I generally agree with your comments. There are two factors that affect the
propagation of changes in DNS:
(1) Caching delay, as determined by the TTL of individual NAPTR RR;
(2) Zone update delay, as determined by the REFRESH timer of the SOA RR of the
zone if NOTIFY is not used.
As you pointed out, setting TTL close to 0 may cause strained behaviors on the
DNS system. In your document draft-ietf-enum-e164-dns-02.txt (Section 5), you
also mentioned that TTL should be kept minimum. Since we are discussing
operational guidelines here, do you or other DNS experts in IETF have any
recommendation as to what constitutes minimum TTL in the context of ENUM? I
think that will really help to move this document forward.

I have some additional comments below.

> Most servers can handle all of the above.

Agree. Zone transfer delay can be minimize via NOTIFY and incremental transfer
IF all name servers for a zone are configured to handle these two features. As
operational guidelines, shall we recommend that all ENUM servers should use
NOTIFY and IXFR for zone transfer?

> all. 15 minutes, ok, 15 seconds....hmmm....I would not have that.

Again, can we provide operational guideline here as to how minimum shall a NAPTR
RR TTL be set for ENUM systems?

> slower (slower than 15 minutes).

I guess you and Greg were talking about slightly different things regarding
"fast" or "slow" updates in switches and IN databases. Loosely speaking, IN
databases, such as 800 or LNP databases, are called real time databases. The
update on a real time database is scheduled on a daily basis in batch mode
through the SMS based on a common reference database, where changes are made
continuously during the day. There is no real-time update from the subscriber
directly, it is done by the operator via the SMS console. Once master copy is
downloaded to the real time database, there is little delay in propagation since
there is no caching mechanism in PSTN.

On the other hand, if you talk about the call forwarding feature, such as
redirect calls to your cell phone, is not slow either. Typically, call
forwarding is a switch-based feature. Once you activate the feature, the
forwarded number will be stored in the switch immediately after you hang up. In
fact, some system will give you a confirmation before you hang up. Even if the
feature is implemented in IN, the redirection will be effective right away,
though the activation duration may take longer since it involves signaling
between the switch and the SCP.

Now the question is: if someone wants to implement a service that needs
immediate update using ENUM, such as the call forwarding feature, what is the
guideline for populating the NAPTR RR? From what you explained above, it seems
that he/she needs to use ENUM as a redirect server to point to a server that
really handles the update in real time. In that case, the pointer is constant,
and there is no update involved for ENUM.

However, porting a number to another provider is different since it usually
involved chaning the NAPTR RR to point to the new provider. In this case, due to
caching, we may have to deal with inconsistent data for a short period of time.
I guess this is what Greg was concerned about. Is that true, Greg?

Cheers,

--Hong

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 21 Jul 2000 13:05:49 +0900

>zone if NOTIFY is not used.

You also have to think about the time negative responses are cached, 
which is the minimum of the TTL for the SOA and the TTL in the SOA.

>think that will really help to move this document forward.

I think TTL can be 5 minutes or so, and we can expect a propagation 
delay of some 15 minutes or so. Not shorter.

As Greg very correctly points out, for the use we expect, caching 
will not very often have any effect for the leaf nodes as one doesn't 
dial one number so many times in the same period of time, but as many 
people have pointed out we are not only talking about telephony.

Also, the problem with propagation of changes in DNS is a problem 
which "the normal" internet community already have because of 
interest in dynamic update and interaction with dhcp(-like) services.

So, writing more specific terms than "kept minimum" in my draft is 
not really good, I feel, as we don't work with DNS operational 
issues. We do though work with ENUM operational issues, and due to 
DNS operations, we can not expect (I belive) that a change propagates 
within a shorter time period than 15 minutes.

Experiments might show that I am wrong, and that changes might 
propagate faster.

But, I also always belive that we will always have a fast and a slow 
update mechanism for the services which uses the ENUM mechanism. The 
definition of what is fast and what is slow is defined by the 
propagation time in DNS. What it is measured in seconds may vary.

>NOTIFY and IXFR for zone transfer?

I think all servers should use whatever mechanism the DNS people 
invent which makes DNS operations being as stable as possible.

Today, yes, NOTIFY is definitely _any_ person running a DNS server 
should use, not only ENUM.

You should talk with the wg chairs (at least) of the DNSOP wg to see 
that you do not replicate any work they do (I am not up to date on 
what they are doing...).

>RR TTL be set for ENUM systems?

Nope. That depends on your configuration of your DNS servers.

>there is no caching mechanism in PSTN.

But, then you have a delay from the time when the change was ordered 
to when the batch process has finished. If that time is longer than 
15 minutes, we have a slow process.

I would _not_ call the above a real time database.

>between the switch and the SCP.

This is fast according to me.

>and there is no update involved for ENUM.

For updates (writes) you can use whatever mechanism you want. For 
slow updates, you can store the actual information in the NAPTR 
record (for reads). That is the first example of yours above. For 
fast  updates (second example of yours) you can in the NAPTR for 
example store an LDAP URI to the database which is updated (write) by 
the use of a phonecall.

>involved chaning the NAPTR RR to point to the new provider.

Yes, but that mean updating the content of the NAPTR RR. And you 
should not forget that you in some cases want to change the party 
which host the NAPTR RR itself, without changing the content of the 
NAPTR itself.

>In this case, due to

My point is that one can accept inconsistencies for a short amount of 
time for some services. Which ones have to be included in this draft 
I think. Just stating that DNS is not usable with broad arguments and 
waving with hands is not a  good thing.

   paf

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 22 Jul 2000 13:42:41 -0700

At 01.33 -0400 00-07-21, Hong Liu wrote:
>That may not be totally true even for telephony, say call center applications.

Correct.

>Do you have any pointers to this work? I really want to take a look at it.

DNSOP wg is working on this. Remember that Microsoft claims that they 
have solved this problem and uses dynamic updates, IXFR and NOTIFY in 
their 2000-version of the DNS server. Personally, I think they have 
ignored the caching problem.

>Agree. It just did not spell out clearly to me by reading the drafts.

It is not there, and that is what I want in the draft of Greg, i.e. 
the one about operation. That's why I wrote the first mail in this 
thread :-)

>Could you explain in more detail how to change the party hosting the 
>NAPTR record?

You have in a parent domain an NS pointing to the server which hosts the NAPTR.

Example:

NeuStar has:

   1.e164.arpa. IN SOA ....
   7.6.5.4.3.2.1.e164.arpa. IN NS ns.number-authority.com.

Number Authority is responsible for 1-234-567-xxxx
They have:

   7.6.5.4.3.2.1.e164.arpa. IN SOA ...
   1.0.9.8.7.6.5.4.3.2.1.e164.arpa. IN NS ns.resolver-service.com.

I as a customer have the phone number 1-234-567-8901.
I have told number-authority that the one handling the NAPTRs for me 
is Resolver Service Inc.

Resolver service is responsible for among other things my number:

   1.0.9.8.7.6.5.4.3.2.1.e164.arpa. IN SOA ....
   1.0.9.8.7.6.5.4.3.2.1.e164.arpa. IN NAPTR ....
   1.0.9.8.7.6.5.4.3.2.1.e164.arpa. IN NAPTR ....
   1.0.9.8.7.6.5.4.3.2.1.e164.arpa. IN NAPTR ....
   1.0.9.8.7.6.5.4.3.2.1.e164.arpa. IN NAPTR ....

If I am unhappy with the service of Resolver Service Inc, I tell 
Number Authority that my resolution is handled by some other 
authority, and Number Authority changes the NS which points to 
Resolver Service Inc.

    paf

---

From: Richard Shockey <[email-masked]>
Date: Sun, 23 Jul 2000 07:44:04 -0500

>If I am unhappy with the service of Resolver Service Inc, I tell Number 
>Authority that my resolution is handled by some other authority, and 
>Number Authority changes the NS which points to Resolver Service Inc.

Or ... if I am an enterprise or a university etc I tell "Number Authority" 
to point to a NS under my direct control.

Which brings up the extremely sticky administrative problem ..which we 
cannot solve here ..which is what is the relationship between the 
"facilities based carrier" that issued the number in the first place and 
the "Resolver Service" or enterprise NS that is actually hosting the RR's.

The problem is the disconnect issue.  If PSTN service is terminated for a 
particular number ..the ENUM RR's must be _disconnected_ at the same time 
since the disconnected number will be quickly reissued to another 
individual....who may wish to provision ENUM services as well.

Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : [email-masked]
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Hong Liu <[email-masked]>
Date: Tue, 25 Jul 2000 20:39:30 -0400

Patrik,

Thanks for the clarification. Please see my comments below.

Cheers,

--Hong

> the one about operation. That's why I wrote the first mail in this

You have provided a very important guideline on what ENUM is expected to do. I
would like to capture that before it gets lost in the emails. Please correct me if
I miss anything:

"Propagation delays in ENUM RRs are bounded by a time interval of about 15 minutes.
Any service that involves dynamic update of ENUM RRs SHALL take this delay bound
into account in order to function properly. If a service requires dynamic update be
done faster than this upper bound, it is recommended that the corresponding ENUM RR
contain a pointer to another server that will be able to perform the updates while
satisfying the timing constraints. In this case, the pointer to the server is
static. How update will be done in the server is outside of the scope of ENUM."

> authority, and Number Authority changes the NS which points to

Technically, this does work for a single subscriber. But it may be problematic when
the redirection happens in a higher level of the e164.arpa hierarchy, say an
enterprise with a large block of numbers assigned. The problem is that the new
service provider has to re-create the RRs for all the nodes in the ported subtree
from scratch, which is not a trivial task. It would be nice if the old service
provider can transfer the subtree to the new service provider (say as required by
agreements among service providers or by mandate from the government regulation.).

I am not saying that this is the only way. For example, you may just have a pointer
at service provider level to direct the queries to the enterprise ENUM server.
However, there are two problems with this approach. First, the enterprise may not
want to operate the ENUM server for its numbers for various reasons, such as
operational cost, staff expertise, or security concerns, etc. That is why they
outsource that function to a service provider. Second, if the enterprise is
managing its own ENUM server, they are better off having an RR at the parent level
(in this case, the Number Authority) to point to its ENUM server, without using the
service provider as another level of redirection.

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 25 Jul 2000 17:52:53 -0700

At 20.39 -0400 00-07-25, Hong Liu wrote:
>contain a pointer to another server that will be able to perform the updates

...another service... [not server]

>while
>It would be nice if the old service

Of course that would be nice. Just like when you switch from one 
registrar to another one for your domainname in ".com".

This has though to do with contracts under which the various parties 
got their domainnames delegated to them in the first place, so I 
claim this is something one have to think about in each case in each 
country.

It would be preferrable if in the case of a move of delegation of 
numbers from one provider to another that the first one pass all data 
to the new provider. But, that is not a technical matter, and we can 
not do much about it in an RFC.

>service provider as another level of redirection.

Maybe, these are other ways of solving the problem. Welcome to the DNS :-)

You can solve the same thing in different ways. What suits you(r part 
of the DNS tree) is up to you.

   paf