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

From: [email-masked]
Date: Thu, 11 Jan 2007 15:50:02 -0500

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-00.txt
	Pages		: 26
	Date		: 2007-1-11
	
   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-00.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-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

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-00.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: "Richard Shockey" <[email-masked]>
Date: Thu, 11 Jan 2007 16:18:45 -0500

Folks I hope we can have a through review of this document in the upcoming
weeks this is a very useful document to folks and I can see going to WGLC
very quickly on this.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, January 11, 2007 3:50 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Enum] I-D ACTION:draft-ietf-enum-unused-00.txt
>

---

From: "Pfautz, Penn L, GBLAM" <[email-masked]>
Date: Thu, 11 Jan 2007 18:20:07 -0500

I guess I have a lot of questions about this document.

1. How does this relate to "void"? Is it replacing it or doing something
else?

2. The draft seems directed to user ENUM and, as such, I'm not sure this
is the right place for information not about user registrations which at
least part of this (unassigned numbers, unallocated ranges) seems to be.
There is an implicit burden placed on Service Providers and NRAs that
not all will find acceptable. I think we're crossing the streams here.

3. I still have problems seeing the problem. We're talking about calls
to numbers that aren't in service. Unless the caller is a spammer (in
which case, why help them?) isn't it just an error that won't be
repeated when the call goes the PSTN and an error message is provided?
How frequent will these calls be? 
BTW, I've not convinced about the looping issue. Shouldn't the gateway
to which call to ENUM-only ranges would be routed provide a "not in
service" message?  

4. Re security, I think there should be an acknowledgement that this
approach would support identification of unpublished numbers in the
Security section rather than a vague reference to conditions in 7.4. I'm
pretty sure my NRA would NOT want this implemented.

5. In 7.4 case 3 the fallback seems to imply the SP will provision a
capability record indicating the services it provides for the block if
the user doesn't choose to register. If this is user ENUM why do this?

6. Finally some nits: 7.3.2 has a reference to RFC 308 rather than 2308
and the statement in 7.2.1.1 that fixed numbering plans typically
require the full number to be dialed is not true, at least in the NANP.
A number of US states will give up their 7-digit home NPA dialing over
their (or more likely your) dead body :-)

Maybe it's late in the day and I just need a drink...

Happy New Year

Penn

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]] 
Sent: Thursday, January 11, 2007 4:19 PM
To: 'IETF ENUM WG'
Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-unused-00.txt

Folks I hope we can have a through review of this document in the
upcoming
weeks this is a very useful document to folks and I can see going to
WGLC
very quickly on this.

> This draft is a work item of the Telephone Number Mapping Working
Group of
> the IETF.

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 12 Jan 2007 11:01:55 +0100

Hi Penn,

thank you for your comments

> I guess I have a lot of questions about this document.

Some answers
> 1. How does this relate to "void"? Is it replacing it or doing
something

It is replacing "void". We thought this was clear after the 100+ e-mails
exchanged in November. We originally planned to call the draft
draft-ietf-enum-void-03 and only change the Enumservice to "unused",
but because we changed the I-D extensively, it
was also agreed in San Diego with the co-chairs to rename
it to draft-ietf-enum-unused-00 and do another WGLC.

> not all will find acceptable. I think we're crossing the streams here.

When "void" was started, there was only user ENUM. Since there is
no distinction yet between Enumservices for user and infrastructure
ENUM, "unused" may be used in both also (and in private ENUMs)

We see the usage mainly in Infrastructure ENUM, where it may be used
by carriers. We do not think that carriers will provide unassigned
numbers
in User ENUM. It will definitely be used and useful in private ENUMs.

In user ENUM it may be used by NRAs for unallocated ranges and it
will be needed for "ENUM only" ranges
> How frequent will these calls be?

Of course, now it is a matter of efficiency. And finally, you need
something if there is no PSTN.

> to which call to ENUM-only ranges would be routed provide a "not in

And how does the gateway know when to provide a "not in service
message"?
You are assuming that there is a dedicated gateway for a given number
range
We are assuming that a gateway may serve potentially all number ranges.

> pretty sure my NRA would NOT want this implemented.

We will think about this

> the user doesn't choose to register. If this is user ENUM why do this?

Lawrence? I think this is the case for the UK variant?
> 6. Finally some nits: 7.3.2 has a reference to RFC 308 rather than
2308

Thanks

> their (or more likely your) dead body :-)

Typically is not all

> > You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce

---

From: Duane <[email-masked]>
Date: Fri, 26 Jan 2007 12:33:52 -0500

Stastny Richard wrote:

Not sure if this is inline with your draft or not, but e164.org 
publishes wild card records to route all toll free numbers for a number 
of countries via 1 or more companies that offer routing and in return 
they earn revenue from the calls they route.

However it is not desirable to have some of these calls routed via VoIP, 
at least at this point in time, and people want to inject a no-voip 
response into dns to exclude these numbers.

One reason people want to exclude some numbers is because the call goes 
to a modem bank, and the provider routing the calls doesn't support t.38.

At the same time we don't want to remove the listing for these toll free 
routes as many people take advantage of them to bypass toll charges when 
calling from other countries or bypassing toll charges introduced by 
mobile phone carriers. We would also like to avoid listing every 
possible valid route, so some form of method to exclude records is 
needed, but without hard failing the call.

-- 

Best regards,
  Duane

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 26 Jan 2007 19:09:46 +0100

>Not sure if this is inline with your draft or not, 
 
No, it is not. unused is only for unallocated/unassigned numbers
 
>but e164.org

>needed, but without hard failing the call.
 
You may use voice:tel or pstn:tel for these type of calls
 
Richard

--

Best regards,
  Duane

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 26 Jan 2007 21:18:32 +0100

> they earn revenue from the calls they route.

[..]

> needed, but without hard failing the call.

If I get this correctly, then you have the following wildcard in
your zonefile

*.0.0.8.1.e164.org. 600 IN  NAPTR   200 10 "u" "E2U+SIP"
	"!^\\+1800(.*)$!sip:1800\\[email-masked]!" .
*.0.0.8.1.e164.org. 600 IN  NAPTR   200 10 "u" "E2U+SIP"
	"!^\\+1800(.*)$!sip:1800\\[email-masked]!" .

and you want no ENUM response to e.g. +1800FAXTOME.

You don't have to address this on the ENUM service-type layer, you can
exclude any number from this wildcard by adding *any* RR at that
number's ENUM domain.

e.g. 

3.6.6.8.9.2.3.0.0.1.e164.org. IN TXT "dummy"

should do.

While adding a pstn:tel NAPTR there might be the more correct way to go,
this approach has the advantage that most ENUM clients just get no
records back and thus revert to the defaul call processing.

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

---

From: Duane <[email-masked]>
Date: Fri, 26 Jan 2007 16:09:27 -0500

> 3.6.6.8.9.2.3.0.0.1.e164.org. IN TXT "dummy"

This will only work if the client specifies TXT or ANY, if they search 
for NAPTR records specifically the server will still return NAPTR 
records higher in the tree.

The only way to prevent this is with a NAPTR record.

-- 

Best regards,
  Duane

http://www.cacert.org - Free Security Certificates
http://www.nodedb.com - Think globally, network locally
http://www.sydneywireless.com - Telecommunications Freedom
http://e164.org - Because e164.arpa is a tax on VoIP

"In the long run the pessimist may be proved right,
     but the optimist has a better time on the trip."

---

From: lconroy <[email-masked]>
Date: Sat, 27 Jan 2007 14:05:12 +0000

Hi Richard, Duane, Richard, Patrik, folks,
First - I am beginning to wonder if there should be a separate slot for
discussions that are not concerned directly with unused, but are related
to using the stuff that has been standardised already.

Esteemed co-chairs - would it be sensible to split out the narrow  
"unused"
Enumservice from the more general provisioning and use stuff?
As an alternative, should this be in PEPPERMINT or DNSOPS or DNSEXT?

As Richard says, there is a perfectly usable way of achieving what  
you seem
to want to do - voice:tel. This says to place a call via the PSTN,  
and is
already an RFC (RFC 4415). You don't need unused.

Second - PSTN:tel?
Maybe X-PSTN:tel would be better if you want to do something  
"different".

Final point - Wildcards are evil. If you must play with loaded weapons,
see RFC 4592.

all the best,