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

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Fri, 21 Jul 2000 13:13:59 -0500

I would not expect call forwarding to hit DNS.  That is far too dynamic and
should be handled by a gatekeeper or other service-specific directory.  

I completely agree with Patrick, DNS needs to deal with assignment of
addresses to service registrars and at the next level down, the mapping of
services (RRs) to addresses.  If you have a "one number" type
follow-me-wherever service, it should be done in a service-specific
directory, not as a laundry list of NAPTR records....

I can agree that a 15 minute TTL for address assignment and service record
mapping is OK.  It is clearly not OK to wait 15 minutes for a
call-=forwarding action to take hold.  That should be nearly instantanious,
but again, I do not see that as an ENUM problem.

Greg V.

-----Original Message-----
From: Manfredi, Albert E [mailto:[email-masked]]
Sent: Friday, July 21, 2000 11:25 AM
To: 'Hong Liu'
Cc: [email-masked]
Subject: RE: [Enum] draft-ietf-enum-operation-00.txt

> -----Original Message-----
> From: Hong Liu [mailto:[email-masked]]

> If we assume a
> distributed administration scheme like DNS today, then Greg's 
> concern is quite
> valid. Note that domain names are generally not portable, 
> hence we need to come
> up with special guidelines for using DNS to handle portable 
> E.164 numbers.

Hmmm. Domain names can be portable. Why not? Which is why I thought this
model works quite well for portable phone numbers too. Except, as Patrik
points out with his numbers, not portable "enough" in a conservative
scenario to handle mobility. But close.

Fast enough to forward the number to your cell phone if you dropped your
keys somewhere before leaving your house, but not always fast enough to keep
track of the actual location of your cell phone while you are driving down
the autobahn.

> So which model do we assume for ENUM, or both, or do we care?
> 
> I hope we can start discussing how delegation is done for 
> ENUM, unless the WG
> chairs declare that it is out of scope.

Agreed.

Bert
[email-masked]

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

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

---

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

>but again, I do not see that as an ENUM problem.

...and I would like to have text about this in your paper about enum 
operations. I.e. what is suitable for what, exactly like this thing 
you and I agree on.

   paf

---

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

Hi, all,

I complete agree with Patrik on this, and I think we are getting there... on
classifying potential applications using ENUM according to the "fast" and "slow"
update required for a particular application. I really enjoy the discussions
thus far.

As an aside, I used  call forwarding as an example of fast update, not to
advocate that it should be done via ENUM directly. I agree that this should be
done in a network element closer to call control, such as a gatekeeper, an MGC
or a SIP proxy server. In fact, depending on implementation, it may not involved
ENUM at all. The call control function can do the substitution before querying
ENUM.

Cheers,

--Hong

---

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

>ENUM at all. The call control function can do the substitution before querying

This IMHO is clearly a function of the Call Control element ..aka the SIP 
proxy, gatekeeper etc.

ENUM is about Telephone Number to URL / service.

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