Subject: [Enum] Re: draft-ietf-enum-rqmts-01.txt: Sections 3.7 and 3.10

From: Hong Liu <[email-masked]>
Date: Sun, 23 Jul 2000 22:19:26 -0400

Anne,

Sections 3.7 and 3.10 are related, so I raise my concerns about them in one
email.

It seems that Section 3.7 is too brief, in the sense that if 3.10 has
numbers on the performance of the system, then the timeout shall be set
consistent with that. Do you mean the response timeout set by the ENUM
client or among ENUM NSs? Do we need to consider timing requirements from
PSTN when the ENUM client is a switch?

I would like to know if the requirements set in Section 3.10 can be met by
the DNS technology or not. Maybe Patrik or Randy can comment on this. My
intent is that I don't want to tax the DNS with too strict requirements. On
the other hand, I am wondering if these numbers are derived from current SCP
requirements in the PSTN (I recall that the SCP has more stringent time
requirements on response time, but I need to double check with my
colleagues). Again, I do NOT intend to put all PSTN requirements on ENUM,
but just as a reference point.

A related point that is related to this is availability and/or reliability.
I would like to see it addressed in the ENUM requirements document, too.

--Hong

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

---

From: Hong Liu <[email-masked]>
Date: Sun, 23 Jul 2000 22:19:44 -0400

Anne,

Section 3.12 "Privacy" says,

"The system MUST allow the owner of the telephone number to control  the
information which prospective callers may receive. "

I am not sure if this is within the scope of ENUM, since Section 3.17
says that service logic is outside of the scope.  You may want to
implement this feature in the server that ENUM points to, or in a call
control entity after the results are returned, but before the results
are passed back to the caller (e.g. caller-ID blocking). It is also
inconsistent with Section 3.4, which says information filtering based on
caller qualification is not required for ENUM.

--Hong

---

From: Hong Liu <[email-masked]>
Date: Sun, 23 Jul 2000 22:19:56 -0400

Anne,

These two sections deals with ENUM security.  I would suggest that they
be put in Section 4 instead. In addition, I would like to see some text
on how DNSSEC is going to be used in these context, since DNSSEC is
mentioned in Section 5 of the protocol document
enum-ietf-enum-e164-dns-02.txt. It would be nice to harmonize these two
documents on security.

I would like to solicit experts of DNSSEC to comment whether
requirements 3.13 and 3.14 can be fulfilled by DNSSEC.

Patrik, are we assuming that DNSSEC is the only security mechanism
required for ENUM?

--Hong

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 23 Jul 2000 19:51:43 -0700

At 22.19 -0400 00-07-23, Hong Liu wrote:
>the DNS technology or not. Maybe Patrik or Randy can comment on this.

I don't see any problems with the values in the requirements 
document. You should though remember that DNS is a very distributed 
database, and doesn't use mirroring the same way as most Telco 
systems do. I.e. in DNS you always go to the source for knowing the 
answer (then you can cache the response of course). This means that 
you will get a fresh response all the time, and no mirroring 
(pre-loading of your database) is needed. On the other hand, if you 
don't run your DNS servers correctly, noone will be able to find 
_your_ ENUM NAPTRs.

Example, in Sweden I have seen during tests that about 20% of the 
zones in DNS is in some way not correctly set up, but, you will still 
get a response quite fast (less than 0.5 seconds + RTT) because at 
least one of the NS in the parent zone do respond.

Also, note that I don't feel these operational problems being too bad 
for ENUM, as people _have_ to be better on running their DNS, or 
their email, webserver, electronic commerce, telephone system etc etc 
will not work. DNS is the source of all routing on the Internet, 
regardless of whether the data can be found in DNS, in LDAP or via 
HTTP.

The problem we have is that DNS maybe is "too stable" and works "too 
good" even though the configuration is wrong.

Just like AppleTalk on Localtalk. IP on top of Ethernet is better in 
some sense, as if a cable is broken, it will not work. Localtalk sort 
of works even though it is not terminated correctly for example.

    paf

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 23 Jul 2000 19:57:03 -0700

At 22.19 -0400 00-07-23, Hong Liu wrote:
>In addition, I would like to see some text
>enum-ietf-enum-e164-dns-02.txt.

When you use DNSSEC you can verify responses. With transaction 
signatures you can authenticate the peer which is sending the query. 
Information in DNS is public data, so if you need authenticated 
access (true such) you should protect the data in some other 
database, like LDAP, ensure that strong bind is needed, and handle 
authentication there.

    paf

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 23 Jul 2000 19:59:14 -0700

>Patrik, are we assuming that DNSSEC is the only security mechanism

Yes, for fetching URIs.

I really want someone talking about how stuff is stored in an LDAP 
database, and maybe a beginning of this is in some documents that 
Greg has written (for example in the VPIM wg). What is there is 
though not sufficient to solve problems that DNS can not resolve 
already, it is unclear what query to issue etc etc.

So, I urge someone to write something about the following (fast) 
resolution mechanism:

   - E.164 -> Domainname
   - NAPTR RRs are fetched from DNS
   - LDAP URI is selected
   - LDAP is used for fetching accurate information
   - Whatever should happen happens

      paf

---

From: Richard Shockey <[email-masked]>
Date: Mon, 24 Jul 2000 08:30:37 -0500

>I would like to see it addressed in the ENUM requirements document, too.

You have raised enough points here to push me into holding off going to 
IESG last call for a little while.

Let me see what I can do to have some clarifications put into the document.

Greg V and Anne Brown have worked together on many of these 
documents..perhaps he can clarify some of the language and then resubmit it 
on Anne's behalf. [ Greg is this possible? Do you support this? ]

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