Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-unused-01.txt

From: "Stastny Richard" <[email-masked]>
Date: Thu, 1 Mar 2007 14:10:33 +0100

Dear ADs and WG-chairs,
 
this I-D is the follow up from draft-ietf-enum-void-02.txt,
which was already in IESG evaluation (and still is).
(so it is basically draft-ietf-enum-void-03.txt)
 
Since we did extensive changes, we renamed it to
draft-ietf-enum-unused-01.txt 
This I-D is now back to status ID exists.
 
Can you please clarify the correct status of this draft

Richard

________________________________

Von: [email-masked] [mailto:[email-masked]]
Gesendet: Do 01.03.2007 00:50
An: [email-masked]
Cc: [email-masked]
Betreff: [Enum] I-D ACTION:draft-ietf-enum-unused-01.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           : IANA Registration for Enumservice UNUSED
        Author(s)       : R. Stastny, et al.
        Filename        : draft-ietf-enum-unused-01.txt
        Pages           : 25
        Date            : 2007-2-28
       
This document registers the Enumservice "unused" using the URI scheme
   "data:" as per the IANA registration process defined in the ENUM
   specification, RFC 3761.  This Enumservice may be used to indicate
   that the E.164 number (or E.164 number range) tied to the domain in
   which the enclosing NAPTR is published is not allocated or assigned
   for communications service.  When such an indication is provided, an
   ENUM client can detect calls that will fail "early".

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

To remove yourself from the I-D Announcement list, send a message to
[email-masked] 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-unused-01.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

Internet-Drafts can also be obtained by e-mail.

Send a message to:
        [email-masked].
In the body type:
        "FILE /internet-drafts/draft-ietf-enum-unused-01.txt".
       
NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

---

From: "PFAUTZ, PENN L, TCORP" <[email-masked]>
Date: Thu, 1 Mar 2007 09:36:41 -0500

Richard:
I guess I'm still left wondering about the real need for this functionality other than in the case of ENUM only number ranges (and even then, with proper design in the circuit switched network I don't see that it should be a problem.)
Users should know the number they want to call including how many digits it has; if they dial a non-working number the call won't go through and will fail somewhere in the ENUM query process or the CSN. Are misdials to vacant codes and numbers not in service frequent enough to justify the provisioning effort proposed in Section 7.4? I'd much prefer to see this functionality limited to the ENUM only number range case or maybe where CREU (not that I'm in favor of it) is deployed. 

Penn Pfautz
AT&T Global Access Management
+1-732-420-4962

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]] 
Sent: Thursday, March 01, 2007 8:11 AM
To: [email-masked]; [email-masked]; [email-masked]; Patrik Fältström
Cc: [email-masked]
Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-unused-01.txt 

Dear ADs and WG-chairs,

 

Richard

       

Send a message to:
        [email-masked].
In the body type:

---

From: lconroy <[email-masked]>
Date: Thu, 1 Mar 2007 14:55:00 +0000

Hi Penn,
  I don't see place where this draft (or VOID before it) says that
AT&T -MUST- do anything.
This draft is a protocol tool thatpeople can use if they believe it
is convenient for them. If a Carrier decides not to use it, that's fine.
Nothing breaks, but there may be inter-carrier signalling on the SS7
network for the failed call; just the same as now.

As the draft says in the abstract -
'When such an indication is provided, an ENUM client can detect calls
that will fail "early"'
If you don't use it, they can't. If you do they can.
It is OF COURSE your choice on whether or not to provision this data.

all the best,
   Lawrence

On 1 Mar 2007, at 14:36, PFAUTZ, PENN L, TCORP wrote:
>  Richard:
> I guess I'm still left wondering about the real need for this  
> functionality other than in the case of ENUM only number ranges  
> (and even then, with proper design in the circuit switched network  
> I don't see that it should be a problem.)
> Users should know the number they want to call including how many  
> digits it has; if they dial a non-working number the call won't go  
> through and will fail somewhere in the ENUM query process or the  
> CSN. Are misdials to vacant codes and numbers not in service  
> frequent enough to justify the provisioning effort proposed in  
> Section 7.4? I'd much prefer to see this functionality limited to  
> the ENUM only number range case or maybe where CREU (not that I'm  
> in favor of it) is deployed.
>
>
> Penn Pfautz
> To: [email-masked]; [email-masked];  
> [email-masked]; Patrik Fältström
> Cc: [email-masked]

---

From: "PFAUTZ, PENN L, TCORP" <[email-masked]>
Date: Thu, 1 Mar 2007 09:59:25 -0500

Lawrence:
I took Section 7.4 a recommending course of action for providers and NRAs. If it's not then I have no issue.
Regards,
Penn 

Penn Pfautz

-----Original Message-----
From: lconroy [mailto:[email-masked]] 
Sent: Thursday, March 01, 2007 9:55 AM
To: PFAUTZ, PENN L, TCORP
Cc: Stastny Richard; [email-masked]
Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-unused-01.txt 

Hi Penn,

all the best,
   Lawrence

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 1 Mar 2007 11:02:59 -0500

This is a ENUM WG document. That has not changed.

I'll send a note to the ID editors.

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 1 Mar 2007 11:11:59 -0500

I don’t like this either.

We should not make any assumption on how a protocol should be used Public
Private Infrastructure. 

A reminder that what we did in RFC 4769 was to note that there "may be
restrictions" on how such data should be used which is not saying how such
data should be used.

> From: PFAUTZ, PENN L, TCORP [mailto:[email-masked]]
> Sent: Thursday, March 01, 2007 9:59 AM
> To: lconroy
> Cc: [email-masked]; Stastny Richard
> Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-unused-01.txt
> 
> Lawrence: