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

From: Hong Liu <[email-masked]>
Date: Fri, 21 Jul 2000 01:37:36 -0400

Oops! I forgot to hit the reply-all button. Sorry.

Subject: Re: [Enum] draft-ietf-enum-operation-00.txt
From: Hong Liu <[email-masked]>
To: Patrik Fältström <[email-masked]>
Date: Fri, 21 Jul 2000 01:33:48 -0400

Paf,

Thanks for your response. I have a few more comments, just for the sake of
discussion.

Cheers,

--Hong

Patrik Fältström wrote:

> At 21.44 -0400 00-07-20, Hong Liu wrote:
> 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.

That is true. Thanks!

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

It is always good to have a rough range.

>
> 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.
>

That may not be totally true even for telephony, say call center applications.

>
> 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.
>

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

>
> 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.

I understand your intent now.

> 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.

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

> 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...).

I was simply requesting more information. If DNSOP already has guidelines, that
will be great.

> 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 just wanted to show that IN update is not necessarily "fast" by your first email
of this thread. It is a slow process for 800 database update.

>
> I would _not_ call the above a real time database.

By real time, I mean real time translation. I did not invent this term. It is
widely used in the PSTN world.

> 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.

Could you explain in more detail how to change the party hosting the NAPTR record?
I am just not knowledgeable enough about all DNS mechanisms. It seems to me that
the same E.164 number is fixed in the e164.arpa hierarchy.

> 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.

I am not objecting the use of DNS. But I also want to understand the limitation of
DNS for potential applications using ENUM.