Subject: [Enum] ENUM WG Agenda for IETF 48 Pittsburgh

From: [email-masked]
Date: Wed, 19 Jul 2000 10:08:17 -0400

In the interest of being earlier rather than later...

Our Proposed Agenda

1. 	Agenda Bashing - 5 min

2. 	Document Status: Chair 2 min

Requirements submitted to IESG Last Call

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-rqmts-01.txt

e164-DNS submitted to IESG Last Call

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-dns-01.txt

3. 	ENUM Operations issues... Greg Vaudreuil 20 min
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-operation-00.txt

4 .  	 Service Principles when Public Circuit Switched International Telecommunication Networks Interwork with IP-based Networks Steve Lind  15 min
 draft-lind-itut-e370-00.txt ?????  Not currently posted..may be deleted..

5  	 ENUM Call Flows for VoIP Interworking .   Steve Lind 15 min
draft-lind-enum-callflows-00.txt - (submitted in queue)  

6.   	 ENUM in Signaling Transport: 20 min John Loughney
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-loughney-enum-sigtran-00.txt

7.	ENUM Usage in Cellular Roaming John Loughney  10 min 
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-loughney-enum-roaming-00.txt

8.  	 ITU Number Portability  15 min Andy Gallant
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-e164s2-np-00.txt

9.   	ITU e164 workplan Andy Galant  10min
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-gallant-enum-e164-snap-00.txt

10.  	 Future Directions and revised milestones 10m
	
11.  	General discussion...

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

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 20 Jul 2000 10:28:01 +0900

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.

"fast" update services should for example be handled by having an 
LDAP URI stored in one of the NAPTR RR, and the actual routing is 
fetched via LDAP.

I.e. you have to differ between "fast" and "slow" updates, and 
describe the differences between each one of them, and what is 
suitable to use DNS for, and what is suitable to use other protocols 
for.

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.

I therefore suggest you talk more about these issues and strategies 
to solve them. _THAT_ I feel can be a very needed discussion, and why 
not in this draft?

Further:

>4.2 Second Level: Determining the service registrar and retrieving
>Resource records.
>
>    The second level uses MX or SRV RRs to discover the NAPTR RRs to
>    discover the URL for other service- identity of the appropriate
>    service-specific directory such as an LDAP directory server, H.323
>    gatekeeper, or specific endpoint addresses.
>

You do not use MX and SRV RRs to discover NAPTR RRs.

    Patrik