headers
Pfautz, Penn L, NEO | 1 Mar 2006 01:35
Picon
Favicon

RE: RE: Section 3.2 of draft-ietf-enum-enumservices-guide-00

 Lawrence,
I don't want to belabor this as I'm not even sure that *I* wish to go
forward with the non-terminals but I'm not sure the working group came
to a consensus that non-terminals were generally not workable. They
clearly have their limitations with the regard to the specific problem
space I wanted to use them in - mostly because of the POSIX's weak-kneed
string processing capabilities (:-). The (non-binding) hum in Paris
indicated a strong preference for alternate or branching domains for
meeting the carrier ENUM need and I accept that.

If the WG is really ready to ban non-terminals than we should agree
formally and reflect it in the guidelines draft.

Regards,
Penn

-----Original Message-----
From: lconroy [mailto:lconroy <at> insensate.co.uk] 
Sent: Tuesday, February 28, 2006 6:42 PM
To: Stastny Richard
Cc: Pfautz, Penn L, NEO; Livingood, Jason; enum <at> ietf.org
Subject: Re: [Enum] RE: Section 3.2 of
draft-ietf-enum-enumservices-guide-00 

Hi Richard, Penn, folks,
  Like he said. Sub-types are good.
Even with SIP, the type is typically the kind of thing you do (all
that wonderful negotiation, rendezvous, and stuff), whilst SIP is
also the protocol you use to carry the exchanges to do it. In that
particular case, the two are and always will be synonymous.
(Continue reading)

Permalink | Reply | 1 comment |
headers
lconroy | 1 Mar 2006 02:30
Picon

Re: RE: Section 3.2 of draft-ietf-enum-enumservices-guide-00

Hi Penn, folks,
   OK - I was not clear.
I don't think that Non-terminals are a bad idea. They're just hard to
understand and to test the clients we develop to support them. In fact,
I think that there definitely IS a place for Non-terminals, and would
be very unhappy with any decision to BAN them before we have had a
chance to play with them properly.

The Experiences draft already states that one should not use them for
"prime time" as many clients do not yet support them - that is not at
all the same as saying that they should be banned.

The new ideas we kicked around last year were interesting, and I'm
pretty sure could be added as I listed - it's just not trivial, and
there was a simpler way of solving the Carrier ENUM issue (i.e. one
that does not involve a lot of waiting around for a enhanced and
re-written standard to grind through the process ;).

Personally, I think that it would be a lot of fun to add a new flag.
However, in practice it would take some time - 3761 was not exactly
"fast out of the traps" in replacing 2916. Thus maybe we defer doing
that for the future - It's something to discuss in Dallas.

I suspect that the existing Non-terminal mechanism works for a lot
of different use cases - few have really tried them out yet in ENUM.
They may well be enough for even fairly whacky situations - just
not quite right for User/Carrier splits.

all the best,
   Lawrence
(Continue reading)

Permalink | Reply | 0 comments |
headers
rfc-editor | 1 Mar 2006 02:52
Favicon

RFC 4414 on An ENUM Registry Type for the Internet Registry Information Service (IRIS)


A new Request for Comments is now available in online RFC libraries.

        
        RFC 4414

        Title:      An ENUM Registry Type for 
                    the Internet Registry Information Service (IRIS) 
        Author:     A. Newton
        Status:     Standards Track
        Date:       February 2006
        Mailbox:    andy <at> hxr.us
        Pages:      51
        Characters: 89985
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-enum-iris-ereg-02.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4414.txt

This document describes an Internet Registry Information Service
(IRIS) registry schema for registered ENUM information.  The schema
extends the necessary query and result operations of IRIS to provide
the functional information service needs for syntaxes and results used
by ENUM registries.  [STANDARDS TRACK]

This document is a product of the Telephone Number Mapping
Working Group of the IETF.

This is now a Proposed Standard Protocol.
(Continue reading)

Permalink | Reply | 0 comments |
headers
James McEachern | 1 Mar 2006 04:38
Favicon

RE: General question on Enumservices

Richard,
I fully understand that E.164 numbers are indispensable in the short term.  My question was whether the
intent was to make E.164 numbers more, or less, important in the long term. 

Jim 

-----Original Message-----
From: Stastny Richard [mailto:Richard.Stastny <at> oefeg.at] 
Sent: Friday, February 24, 2006 5:13 PM
To: McEachern, James [CAR:5N00:EXCH]; enum <at> ietf.org
Subject: Re: [Enum] General question on Enumservices

>But with all these Enumservices, we may achieve exactly the opposite effect, by making E.164 numbers
indispensable. 
>I assume this is not our intent.

Hmm, aren't they indispensible?

How many people can you reach via a SIP URI and how many with a phone number?
How many large voice providers give you a sip URI? 

And I still wonder how they will provide global connectivity
with SIP URIs (public user identities) in IMS

Richard
Permalink | Reply | 0 comments |
headers
James McEachern | 1 Mar 2006 04:38
Favicon

RE: General question on Enumservices

Richard,
You correctly point out that 

> ... there are two globally reckonized naming and addressing schemes for 
> communications. E.164 and the ICANN domain root.

> ENUM is the definitive mapping between the two.

Part of my earlier point was that ENUM may be the definitive mapping, but it is only a one way mapping, which
effectively makes E.164 the definitive global addressing scheme.  Maybe I'm missing something here, but
this still seems ironic for an IETF working group.

Jim

-----Original Message-----
From: Richard Shockey [mailto:richard <at> shockey.us] 
Sent: Friday, February 24, 2006 9:40 PM
To: Michael Hammer (mhammer)
Cc: enum <at> ietf.org; Stastny Richard; Scott Bradner; Tony Rutkowski
Subject: Re: [Enum] General question on Enumservices

Michael Hammer (mhammer) wrote:
> In the end, which number/name is the index (business card) to the others
> is arbitrary.
> 
> The choice of E.164 number is an artifact of the fact that phones have
> keypads (0-9, #, *) and most of the world uses phones, while access to
> computers is not as universal.

and E.164 numbers are linguistically neutral. We cannot forget there are
(Continue reading)

Permalink | Reply | 17 comments |
headers
Richard Shockey | 2 Mar 2006 20:45
Picon

FYI ENUM and Speermint look solid for Monday.


For those of you dealing with flights etc.

--

-- 

 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 7 Mar 2006 08:50
Picon
Favicon

I-D ACTION:draft-ietf-enum-infrastructure-enum-reqs-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Telephone Number Mapping Working Group of the IETF.

	Title		: Infrastrucure ENUM Requirements
	Author(s)	: S. Lind, P. Pfautz
	Filename	: draft-ietf-enum-infrastructure-enum-reqs-00.txt
	Pages		: 7
	Date		: 2006-3-6
	
This document provides requirements for "infrastructure" or "carrier"
ENUM, defined as the use of RFC 3761 technology to facilitate
interconnection of networks for E.164 number addressed services, in
particular but not restricted to VoIP.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-enum-infrastructure-enum-reqs-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Shockey | 7 Mar 2006 16:28
Picon

Almost complete Agenda for IETF 65 Dallas

IETF 65 Dallas Telephone Number Mapping (ENUM) WG Agenda Preliminary

Chair(s):
Patrik Faltstrom <paf <at> cisco.com>
Richard Shockey <rich.shockey <at> neustar.biz>

WG Secretary:
Alex Mayrhofer <axelm <at> nic.at>

Real Time Applications Infrastructure Area Director(s):
Cullen Jennings <fluffy <at> cisco.com>
Jon Peterson <jon.peterson <at> neustar.biz>

Real Time Applications Infrastructure Area Advisor:
Cullen Jennings <fluffy <at> cisco.com>

MONDAY, March 20, 2006
0800-1800 IETF Registration -
0800-0900 Continental Breakfast -
0900-1130 Morning Session I
APP	apparea	Applications Area Open Meeting
INT	dna	Detecting Network Attachment WG
OPS	netconf	Network Configuration WG
RAI	enum	Telephone Number Mapping WG
RAI	mmusic	Multiparty Multimedia Session Control WG
RTG	mpls	Multiprotocol Label Switching WG
SEC	krb-wg	Kerberos WG

AGENDA BASHING (5 min)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stastny Richard | 7 Mar 2006 19:05
Picon

Re: Almost complete Agenda for IETF 65 Dallas

Dear Co-chair,

I requested some time ago some time on the agenda for the up issue of
our I-D :

 "Combined User and Carrier ENUM in the e164.arpa tree" -
draft-haberler-carrier-enum-02.txt .

Abstract:

ENUM as defined now in RFC3761 is not well suited for the purpose of
interconnection by carriers, as can be seen by the use of various
private tree arrangements based on ENUM mechanisms. A combined
end-user and carrier ENUM tree solution would leverage the ENUM
infrastructure in e164.arpa, increase resolution rates, and decrease
the cost per registered telephone number. This document describes a
minimally invasive scheme to provide both end-user and carrier data in ENUM.

until it comes out of the queue, the I-D is available at:

http://mah.priv.at/i-d/draft-haberler-carrier-enum-02.txt
http://mah.priv.at/i-d/draft-haberler-carrier-enum-02.html

 
and the 

>General Discussion of Infrastructure ENUM Apex [ 2 years + minimum ]

Adding the proposed agenda times together, only 10 minutes are left for
these two items. I am also getting the slight impression that our esteemed co-chair
(Continue reading)

Permalink | Reply | 2 comments |
headers
Richard Shockey | 7 Mar 2006 19:54
Picon

Re: Almost complete Agenda for IETF 65 Dallas

Stastny Richard wrote:
> Dear Co-chair,
> 
> I requested some time ago some time on the agenda for the up issue of
> our I-D :
>  
>  "Combined User and Carrier ENUM in the e164.arpa tree" -
> draft-haberler-carrier-enum-02.txt .
> 
> Abstract:
> 
> ENUM as defined now in RFC3761 is not well suited for the purpose of
> interconnection by carriers, as can be seen by the use of various
> private tree arrangements based on ENUM mechanisms. A combined
> end-user and carrier ENUM tree solution would leverage the ENUM
> infrastructure in e164.arpa, increase resolution rates, and decrease
> the cost per registered telephone number. This document describes a
> minimally invasive scheme to provide both end-user and carrier data in ENUM.
>  
> until it comes out of the queue, the I-D is available at:
> 
> http://mah.priv.at/i-d/draft-haberler-carrier-enum-02.txt
> http://mah.priv.at/i-d/draft-haberler-carrier-enum-02.html

I havent seen the 02 draft come across the announce wire but thats not a 
problem ..

> 
>  
> and the
(Continue reading)

Permalink | Reply | 1 comment |

Gmane