Subject: RE: [Enum] Potential Agenda for ENUM Adelide

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 21 Mar 2000 13:43:52 -0500

Why don't we move draft-foster-e164-gstn-np-00.txt up before
anything with discussion.  I think we can keep the Q21 material
short - it's pretty self explanatory.

I'm not sure we can get through draft-faltstrom-e164-05.txt in
10 minutes.

Brian

> -----Original Message-----
> From: Richard Shockey [mailto:[email-masked]]
> Sent: Tuesday, March 21, 2000 12:42 PM
> To: [email-masked]
> Cc: Scott Bradner
> Subject: [Enum] Potential Agenda for ENUM Adelide
> 
> 
> 
> In the interests of moving the work along I'd like to suggest 
> a possible 
> agenda for next week.
> 
> We do have a 2 1/2 hour session and there is much to discuss.
> 
> If you have any additions or suggestions... NOW is the time.
> 
> 
> TUESDAY, March 28, 2000 0800-1700 IETF Registration - Foyer 1
> 0800-0900 Continental Breakfast - Foyer and Circulation Area
> 0900-1130 Morning Sessions
> 
> Hall D TSV enum Telephone Number Mapping WG
> 
> 
> Agenda Bashing - 5 Min
> 
> Appoint Scribe - Volunteers needed !!!
> 
> Review of Problem Statement - 2 Min
> 
> Report on IETF-ITU Joint meeting in Geneva .. where ENUM was 
> presented and 
> discussed at some length - 10 Min
> 
> Communication from ITU-SG2/Q1 15 Min
> 
> SG2/Q1 which deals with numbering issues has been kind enough 
> to forward 
> some information that should be relevant to our discussions. 
> Please attempt 
> to review this material for comments.
> 
>     
> http://www.itu.int/ITU-T/ip-telecoms/nnar/nnar-e164-dns-iw-info.txt
>     
> http://www.itu.int/ITU-T/ip-telecoms/nnar/nnar-carrier-sel-supp.txt
> 
> 
> Drafts for Review:
> 
> ENUM Requirements  (raft-ietf-enum-rqmts-00.txt  20 Min
> 
> Additions Subtractions ???
> 
> E.164 number and DNS  draft-faltstrom-e164-05.txt  10 Min
> 
> Telephone Number Based Directory Service 
> draft-vaudreuil-enum-e164dir-00.txt  1 Hour ++
> 
> Number Portability in the GSTN: An Overview  
> draft-foster-e164-gstn-np-00.txt
> [no discussion ] Note the Number Portability draft is 
> informational. It is 
> not directly ENUM charter but the information is useful in 
> understanding 
> the context numbering plays in the GSTN.
> 
> General discussion.
> 
> Future steps and directions.
> 
> 
> 
>  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Richard Shockey
> Shockey Consulting LLC
> 8045 Big Bend Blvd. Suite 110
> St. Louis, MO 63119
> Voice 314.918.9020
> eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
> INTERNET Mail & IFAX : [email-masked]
> GSTN Fax 314.918.9015
> MediaGate iPost VoiceMail and Fax 800.260.4464
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> 
> 
> _______________________________________________
> enum mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/enum
> 

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

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 21 Mar 2000 20:13:21 -0800

> I'm not sure we can get through draft-faltstrom-e164-05.txt in

I am sorry if the text in the draft is confusing. The text talk about two
things, and the latter probably should be deleted, as it is confusing
people:

(1) How to do a mechanical transformation of one E.164 number into a
domainname which can be stored in DNS

(2) Give examples of existing services defined for use given arbitrary DNS
names (including the ones defined under (1) above)

It is only (1) above which is important. The second thing is that when
having E.164 numbers as DNS names, that they try to guess/experiment/try
what things can be done given _existing_ operations and data that can be
stored.

It should not be in a draft only talking about the E.164<->DNS
transformation though, and I am happy to remove that text. It is already
described in other RFCs and doesn't have to / should not be repeated.

   Patrik

---

From: Richard Shockey <[email-masked]>
Date: Wed, 22 Mar 2000 00:04:00 -0600

>domainname which can be stored in DNS

Oh yes.. I get it now.  Patrik you are on to something fundamentally 
correct here.

There will have to be multiple RFC here but the core is TN  to >domain of 
authority as Greg outlines.

At least hint to references to service provisioning.

Second level is service provisioning which may or may not require 3rd level 
resolution to LDAP authority.

Am I making sense here?

>described in other RFCs and doesn't have to / should not be repeated.

Examples in the primary ENUM resolution document may be useful but not 
binding on others wishing to demonstrate service provision.  Am I making 
sense here?

Richard Shockey
Shockey Consulting LLC

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 22 Mar 2000 06:33:48 -0800

--On 2000-03-22 00.04 -0600, Richard Shockey <[email-masked]> wrote:

> Second level is service provisioning which may or may not require 3rd
> level resolution to LDAP authority.
> 
> Am I making sense here?

Yes.

As soon as you have a domain name, you can do with that name whatever you
want which is defined in other RFCs (which I am using in part (2) in my
paper) and/or define special algorithms (which Greg is doing via the PTR
record) for specific ENUM-related services.

This has nothing to do with the mapping between E.164 and domainname
though. This is service provisioning.

> binding on others wishing to demonstrate service provision.  Am I making

Yes.

As the draft talks about DNS, I thought it was ok to have examples on how
to use other DNS RR types already defined for VOIP services given the
definition of E.164->DNS names.

I will rewrite that part of the paper. Too late for the IETF though.

   paf

---

From: Richard Shockey <[email-masked]>
Date: Wed, 22 Mar 2000 12:51:39 -0600

>though. This is service provisioning.

So the basic issue we need to sort out in defining  1st level resolution 
..Is the PTR RR the most appropriate RR for the purpose of of discovering 
the "domain of authority" for the number?

Right ?? ...everything else is service specific provisioning.

Richard Shockey
Shockey Consulting LLC