Subject: [Enum] please post issues from yesterdays session

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 09 Nov 2005 18:37:58 +0100

All,

i'd like to ask you to post any issue which you brought up during 
yesterday's WG session on the list.

that would make tracking those issues much more easier.

thanks,

alex

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

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 9 Nov 2005 14:08:11 -0500

I noted that during my presentation on "draft-ietf-enum-pstn-00" the
following issues were discussed and decided upon:

1.  Minor nits with the draft will be resolved and I will re-submit to
up-rev to -01.

2.  Must revisit the section on Distribution of Data to note that it may
or may not be done on a private basis.  This will be primarily
determined based on regulatory requirements in a particular country.  I
have not determined the exact wording of this yet.

3.  After fixing the nits and word-smithing #2 above (resulting in -01),
we will work on -02 with new suggested data types.  These include CNAM
and 800 number data, per feedback from Kevin McCandless.  (This would
not include Global Title Translation - which was a question raised by
the co-chair.)  The co-authors are open to any other suggestions.

Separately, the need was again confirmed for a guide to creating an
enumservice I-D.  This work will be undertaken by members of the WG in
the near future.

Regards
Jason Livingood

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Alexander Mayrhofer
> Sent: Wednesday, November 09, 2005 12:38 PM
> To: [email-masked]
> Subject: [Enum] please post issues from yesterdays session
> 
> All,
> 
> i'd like to ask you to post any issue which you brought up 
> during yesterday's WG session on the list.
>

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 9 Nov 2005 21:08:06 +0100

One issue raised during the discussion on Ed Guys IAX was to finally
clarify the rules for subtyping of ENUMservices.
 
1. should there be subtypes or not
2. what should be used at subtypes (e.g. the URI)
 
This discussion is not new, some years? ago it was discussed
if you need subtypes indication the URI on the right side at all,
because you just have to look at the right side of the NAPTR to see it
 
So basically the registration template is indicating which URI are
valid to be used with this ENUMsevice type
 
This was rejected because then a client is required to evalute
ALL NAPTRs for this ENUMservice type (including regexp) to find
out the URI and then decide which ob to take
 
As stated by co.chair Patrik this must not be the case, it must
be possible by the client to select the NAPTR only by the information
in the ENUMservice field, taking stupid clients into account.
 
Therefore the praxis was established to use subtypes indication the
URI on the right side, and also to use the the URI name itself, to avoid
confusion, although this is not necessary. If only one URI is possible,
no subtype is used (e.g. ENUMservice sip or H323).
 
The only problem here exists when an ENUMservice is defined which
contains at the moment only one URI, but MAY be expanded later
with an additional URI.
 
We (e.g. Lawrence, Rudi and I) prefer in this also to use a subtype
(the URI), even if it seems not necessary, just to be on the save side
for future extensions.
 
My proposal is that in future all new ENUMservice registration SHOULD
contain the URI as subtype
 
regards
Richard

________________________________

Von: [email-masked] im Auftrag von Alexander Mayrhofer
Gesendet: Mi 09.11.2005 18:37
An: [email-masked]
Betreff: [Enum] please post issues from yesterdays session

All,

thanks,

alex

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 9 Nov 2005 22:43:52 +0100

This was not brought up by me, but concerns 
our draft:
 
The definitions and terminolgy used in 
draft-haberler-carrier-enum-01 should be moved over and aligned
with the definitions and terminology in
draft-lind-infrastructure-enum-reqs-01
 
Richard

All,

thanks,

alex

---

From: "McCandless, Kevin" <[email-masked]>
Date: Wed, 9 Nov 2005 15:41:57 -0600

I would also add to the list that if you perform a PSTN URI query and no
record exists that you consider a value to return.  One that comes to
mind is 'Void'.  There was a draft discussed in this working group for
the use of value.

Thoughts?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Livingood, Jason
Sent: Wednesday, November 09, 2005 1:08 PM
To: Alexander Mayrhofer; [email-masked]
Subject: RE: [Enum] please post issues from yesterdays session

Regards
Jason Livingood

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Wed, 9 Nov 2005 19:49:20 -0500

Your reasoning and conclusion are the same ones I'd arrived at. And I think your use of the word SHOULD rather than MUST is important to allow for the cases where it may not be best to use the URI Scheme as the sub-type.
 
Last I checked, about 12 of the roughly 15 registered ENUM services do define required sub types, with SIP and pres being the most notable exceptions.  And of the 12 or so that do require sub types almost all of them simply echo the URI Scheme.
 
Furthermore, in trying to make the ill-fated counter argument that the Service/SubService Field should *not* be used to infer anything about the URI in the regexp replacement substring (including the URI's Scheme) you would end up having to say that the following NAPTR is a good one, which of course it's not:
IN NAPTR 100 50 "u" "E2U+sms:mailto" "!^.*$!tel:[email-masked]!" .

It's not a good NAPTR because the obvious intention of the ENUM service registration doc for sms is that when the service field is "E2U+sms:mailto" then the URI Scheme in the URI should be mailto, not tel.  And when it's E2U+sms:tel the the URI Scheme in the regexp should be tel, not mailto.

Jason's plan to precisely address this matter in an ID is important.

Ken

From: [email-masked] on behalf of Stastny Richard
Sent: Wed 11/9/2005 3:08 PM
To: Alexander Mayrhofer; [email-masked]
Subject: Re: [Enum] please post issues from yesterdays session

regards
Richard

All,

thanks,

alex

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 10 Nov 2005 02:03:20 +0100

Kenneth wrote:

>Your reasoning and conclusion are the same ones I'd arrived at. And I think your use of the word SHOULD rather than MUST is important to allow >for the cases where it may not be best to use the URI Scheme as the sub-type.
 
correct, I already had written MUST and then changed it to SHOULD exactly for this reason
 
>Last I checked, about 12 of the roughly 15 registered ENUM services do define required sub types, with SIP and pres being the most notable >exceptions.  And of the 12 or so that do require sub types almost all of them simply echo the URI Scheme.

quod licet jovi, not licet bovi ;-)
 
<snip>.

>Jason's plan to precisely address this matter in an ID is important.

agree

Richard

regards
Richard

All,

thanks,

alex

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Wed, 9 Nov 2005 20:18:53 -0500

Right, I feel that the Requirements section (section 3) in the haberler document further clarifies the carrier er. infrastructure ENUM problem, and is mostly complementary with what's already in the lind document.  ...but it's a small point.
 
Ken

From: [email-masked] on behalf of Stastny Richard
Sent: Wed 11/9/2005 4:43 PM
To: Alexander Mayrhofer; [email-masked]
Subject: Re: [Enum] please post issues from yesterdays session

Richard

All,

thanks,

alex

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Wed, 9 Nov 2005 20:41:10 -0500

I think it's a vital point that Patrik and Richard schooled me on:  The fact that the IETF will make *no* judgments or statements about the appropriateness, precedence, or "conflict" resolution of NAPTRs in the User ENUM tree and the Carrier ENUM tree for the same TN.  The Carrier ENUM tree may very well have NAPTRs for any ENUM service type for a given TN, while NAPTRs for the same TN and the same ENUM service types, but with perhaps different URIs, may also reside in the User ENUM tree at the same time.  The decision on which tree to query, and perhaps in what order to query them, and perhaps how to resolve "conflicts" (I don't use the term "conflict" in a negative sense) is entirely up to the ENUM client application.   I had not heard this said before or seen it written, but it certainly simplifies the problem of having two trees.
 
Ken.

Richard

All,

thanks,

alex

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 10 Nov 2005 06:31:24 +0100

HI Ken,
 
I think it is a good idea to state this clearly somewhere. I am not sure if this is a "requirement"
but it may be useful to make this clarifcation there.
 
The intersting issue about this is that this "non-conflict" was always intrinsically there in User ENUM.
If you made an entry in User ENUM for lets say a geographic number, there was always the intrinsic
asumption made that you still had a DIFFERENT terminatiion on the PSTN. User ENUM is an additional
service for the end-user. Nobody sees a "conflict" here.
 
Infrastructure ENUM is now dealingwith  the termination mentioned above. An entry
in Infrastucture ENUM is pointing to a border element of a "carrier" hosting the number in
question, regardless if this end-user is on IP or on the PSTN.
 
So nothing has changed here. Before Infrastructure ENUM, a carrier could choose to route
the call conventionally on the PSTN or query User ENUM in addition (as some VoIP providers do)
 
Now the Carrier could chose again to route the call by querying Infrastructure ENUM or to
query User ENUM in addition.
 
Looking up User ENUM is always a subscriber feature and opt-in. So the user
may either query User ENUM by himself, or the provider is querying User ENUM
ON BEHALF of the User. 
 
Richard

Von: [email-masked] im Auftrag von Cartwright, Kenneth
Gesendet: Do 10.11.2005 02:41
An: [email-masked]
Betreff: RE: [Enum] please post issues from yesterdays session

Ken.

Richard

All,

thanks,

alex

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Thu, 10 Nov 2005 11:31:28 -0500

Right.  And furthermore, based on yesterday's explanation, the carrier (COR) could legitimately choose to enter an "E2U+email:mailto" NAPRT or an "E2U+web:http" NAPTR, etc, etc in the carrier ENUM tree for any of their TNs.
 
Ken

From: Stastny Richard [mailto:[email-masked]]
Sent: Thu 11/10/2005 12:31 AM
To: Cartwright, Kenneth; [email-masked]
Subject: AW: [Enum] please post issues from yesterdays session

HI Ken,

Richard

Ken.

Richard

All,

thanks,

alex

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 10 Nov 2005 20:29:16 +0100

Yes. provided they do not disclose any privacy information of the
end-user without asking him:
 
Additional question: they could, but why should they?
 
Richard

Von: Cartwright, Kenneth [mailto:[email-masked]]
Gesendet: Do 10.11.2005 17:31
An: Stastny Richard; [email-masked]
Betreff: RE: [Enum] please post issues from yesterdays session

Ken

HI Ken,

Richard

Ken.

Richard

All,

thanks,

alex

---

From: "Creighton, Tom" <[email-masked]>
Date: Fri, 11 Nov 2005 14:18:42 -0500

What would be the purpose of querying for PSTN routing data (LNP data in the case of North America) as described in Jason's proposal if you aren't destined for the PSTN?  I envision querying for E2U+pstn records in a private tree only after all other VoIP options are exhausted.  That being the case, if I were to receive an NXDOMAIN from this tree, it would indicate that the number is not ported and that the call still needs to be routed to the PSTN.
 
If the number were VoIP only, it would either have a NAPTR or void record in e164.arpa that would route or terminate the call prior to reaching the step mentioned above.

From: Jim Reid [mailto:[email-masked]]
Sent: Fri 11/11/2005 1:33 PM
To: Creighton, Tom
Cc: McCandless, Kevin; Livingood, Jason; Alexander Mayrhofer; [email-masked]
Subject: Re: [Enum] please post issues from yesterdays session

On Nov 11, 2005, at 17:28, Creighton, Tom wrote:

> What happens if the number you are performing a PSTN URI query on 
> isn't ported?  Wouldn't you want to receive an NXDOMAIN and fall 
> back to the PSTN anyway?

Nope. That only works if the number is reachable over the PSTN. If 
the number is VoIP only, it may be impossible to terminate calls to 
that number on the PSTN. This was one of the motivations behind the 
void NAPTR draft. That allows ENUM clients (such as SIP) gateways to 
make a distinction between numbers that are not entered into ENUM and 
numbers which don't have service or can't be reached from the PSTN.

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 14 Nov 2005 10:05:29 -0500

I don't know why it would happen or if it would happen.

Ken

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]] 
Sent: Thursday, November 10, 2005 2:29 PM
To: Cartwright, Kenneth; [email-masked]
Subject: Re: [Enum] please post issues from yesterdays session

 
Richard

Right.  And furthermore, based on yesterday's explanation, the carrier
(COR) could legitimately choose to enter an "E2U+email:mailto" NAPRT or
an "E2U+web:http" NAPTR, etc, etc in the carrier ENUM tree for any of
their TNs.
 
Ken

HI Ken,

I think it is a good idea to state this clearly somewhere. I am not sure
if this is a "requirement"
but it may be useful to make this clarifcation there.

The intersting issue about this is that this "non-conflict" was always
intrinsically there in User ENUM.
If you made an entry in User ENUM for lets say a geographic number,
there was always the intrinsic
asumption made that you still had a DIFFERENT terminatiion on the PSTN.
User ENUM is an additional
service for the end-user. Nobody sees a "conflict" here.

Infrastructure ENUM is now dealingwith  the termination mentioned above.
An entry
in Infrastucture ENUM is pointing to a border element of a "carrier"
hosting the number in
question, regardless if this end-user is on IP or on the PSTN.

So nothing has changed here. Before Infrastructure ENUM, a carrier could
choose to route
the call conventionally on the PSTN or query User ENUM in addition (as
some VoIP providers do)

Now the Carrier could chose again to route the call by querying
Infrastructure ENUM or to
query User ENUM in addition.

Looking up User ENUM is always a subscriber feature and opt-in. So the
user
may either query User ENUM by himself, or the provider is querying User
ENUM
ON BEHALF of the User.

Richard

I think it's a vital point that Patrik and Richard schooled me on:  The
fact that the IETF will make *no* judgments or statements about the
appropriateness, precedence, or "conflict" resolution of NAPTRs in the
User ENUM tree and the Carrier ENUM tree for the same TN.  The Carrier
ENUM tree may very well have NAPTRs for any ENUM service type for a
given TN, while NAPTRs for the same TN and the same ENUM service types,
but with perhaps different URIs, may also reside in the User ENUM tree
at the same time.  The decision on which tree to query, and perhaps in
what order to query them, and perhaps how to resolve "conflicts" (I
don't use the term "conflict" in a negative sense) is entirely up to the
ENUM client application.   I had not heard this said before or seen it
written, but it certainly simplifies the problem of having two trees.

Ken.

Richard

All,

thanks,

alex

---

From: "McCandless, Kevin" <[email-masked]>
Date: Mon, 14 Nov 2005 11:48:04 -0600

I still think that using VOID is cleaner the NXDOMAIN.  You could have
VOID for two reasons.  Record does not exist for VoIP and there is no
LNP data available.

-----Original Message-----
From: Creighton, Tom [mailto:[email-masked]] 
Sent: Friday, November 11, 2005 1:19 PM
To: Jim Reid
Cc: McCandless, Kevin; Livingood, Jason; Alexander Mayrhofer;
[email-masked]

What would be the purpose of querying for PSTN routing data (LNP data in
the case of North America) as described in Jason's proposal if you
aren't destined for the PSTN?  I envision querying for E2U+pstn records
in a private tree only after all other VoIP options are exhausted.  That
being the case, if I were to receive an NXDOMAIN from this tree, it
would indicate that the number is not ported and that the call still
needs to be routed to the PSTN.
 
If the number were VoIP only, it would either have a NAPTR or void
record in e164.arpa that would route or terminate the call prior to
reaching the step mentioned above.

From: Jim Reid [mailto:[email-masked]]
Sent: Fri 11/11/2005 1:33 PM
To: Creighton, Tom
Cc: McCandless, Kevin; Livingood, Jason; Alexander Mayrhofer;
[email-masked]
Subject: Re: [Enum] please post issues from yesterdays session

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 16 Nov 2005 14:16:20 -0500

Kevin McCandless wrote:
> I still think that using VOID is cleaner the NXDOMAIN.  You 
> could have VOID for two reasons.  Record does not exist for 
> VoIP and there is no LNP data available.

I have been thinking more about this discussion since the IETF meeting.
A VOID is intended to be used to tag a number as not in service, as
compared with NXDOMAIN being for no record found.  

In the call routing process, VOID should trigger a switch/proxy/user
agent to play an announcement to the effect that a number is not in
service.  This typically stops any further call routing or call
progression.  

A query response of NXDOMAIN will result in a switch/proxy/user agent in
progressing to the next step in the call lookup process.  After failing
all of the lookups, this may mean there is a default PSTN route of last
resort which is used, or that a route to an IXC is used, or whatever.

A primary purpose of using E2U+PSTN is to consolidate "on-net" and
"off-net" call queries into a single DNS lookup (rather than say a DNS
lookup, followed by an LNP dip, followed by a lookup in a LERG table,
etc.).  A service provider would typically create VOID records just for
their numbers that were inactive so that takes care of that use case.
And if there is no LNP data, there may still be an E2U+PSTN record; keep
in mind that these records could very well include ported, pooled, and
block numbers.  

In any case, I think you want a return of NXDOMAIN if no record is found
so that the call lookup process continues.  Thus, I don't see a need for
VOID records specific to E2U+PSTN as the existing VOID Enumservice type
can be used by a service provider to indicate which of their numbers is
not in service.

Jason

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 17 Nov 2005 09:42:42 +0100

May I add:

As long as not ALL E.164 numbers are in ENUM, in one tree and the PSTN
exists for default fallback, VOID is useful, for the reasons Jason
points
out below.

If finally ALL E.164 numbers are in ENUM in the long term (when we
are all dead ;-), NXDOMAIN may replace it, but even then direct
response may be useful because of time-out purposes.

There is only one problem with this: for "privacy?" and competitive
reasons it currently looks like that ALL numbers of a number range
assigned to an operator will be entered into Infrastructure ENUM
(except the ported-out) and the signalling of "number not in service"
will be left to the destination network.

I do not consider this useful, but ... Even in the PSTN devices
exist to "war-dial" number ranges and find out not-in-service
numbers, so what?

Richard

> Sent: Wednesday, November 16, 2005 8:16 PM
> To: McCandless, Kevin; [email-masked]

---

From: "McCandless, Kevin" <[email-masked]>
Date: Thu, 17 Nov 2005 08:29:02 -0600

Good summary Jason.  NXDOMAIN then for no records.

-----Original Message-----
From: Livingood, Jason [mailto:[email-masked]] 
Sent: Wednesday, November 16, 2005 1:16 PM
To: McCandless, Kevin; [email-masked]
Subject: RE: [Enum] please post issues from yesterdays session

Jason

---

From: "Schiefner, Carsten" <[email-masked]>
Date: Mon, 21 Nov 2005 19:59:46 +0100

Jason, all -

> Sent: Wednesday, November 09, 2005 8:08 PM
> [...]

even in the absence of any regulatory requirement, the LNP club itself might decide to not disclose this data to the public. Should that be reflected in your I-D, too - as a sort of fallback?

Best,

	Carsten
-- 

Carsten Schiefner                  |                 p: +49 441 234-4571
Deutsche Telekom AG                |                f: +49 431 7163-3972
T-Com Zentrale TK44                |                 m: +49 151 14525458
Ammerlander Heerstr. 138           |  mailto:[email-masked]
D-26129 Oldenburg                  |    http://www.t-com.de/kundendienst

---

From: "James McEachern" <[email-masked]>
Date: Mon, 28 Nov 2005 10:05:06 -0500

This proposed text looks good to me.

Jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carsten Schiefner
Sent: Monday, November 28, 2005 5:21 AM
To: [email-masked]
Subject: Re: [Enum] please post issues from yesterdays session

Jason,

> I think you are correct.  Here is the text of that section of the
> document.  I have included IN CAPS the text I was considering adding to
> address this.  Let me know what you think.

how about:

===

3. Distribution of Data

The distribution of number portability data is often highly restricted 
either by contract or regulation of a National Regulatory Authority 
(NRA), THEREFORE NAPTR records described herein MAY OR MAY not be part 
of the e164.arpa DNS tree.

Distribution of this NAPTR data would be either (a) on a private basis 
(within a service provider's internal network, or on a private basis 
between one or more parties using a variety of security mechanisms to 
prohibit general public access), (b) openly available, BUT MAYBE on a 
national basis ONLY according to national regulatory policy, OR (C) 
DISTRIBUTED BY THE RELEVANT NUMBER PORTABILITY ORGANIZATION OR OTHER 
INDUSTRY ORGANIZATION.

The authors believe that it is more likely that these records will be 
distributed on a purely private basis.  If such data was distributed 
nationally, the national telephone numbering authority, or some other 
regulatory body OR NUMBERING ORGANIZATION, may have jurisdiction.  Such 
a body may choose to restrict distribution of the data in such a way 
that it may not pass over that country's national borders.  How number 
portability data is collected and distributed is out of scope of this 
document.

===

Best,

	Carsten

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 28 Nov 2005 11:24:38 -0500

All those changes look fine with one exception in wording on the 2nd
change you requested.  I have worded it as such:

"Distribution of this NAPTR data would be either (a) on a private basis
(within a service provider's internal network, or on a private basis
between one or more parties using a variety of security mechanisms to
prohibit general public access), (b) openly available, but possibly on a
national basis and subject to or in accordance with national regulatory
policy, or (c) distributed by the relevant number portability
organization or other industry organization."

I think this still captures what you were looking for.  Let me know if
that is not the case and I will take a second crack at it.

Jason 

> Behalf Of Carsten Schiefner
> > document.  I have included IN CAPS the text I was 
> considering adding 
> > to address this.  Let me know what you think.
> 
> how about:
> 
> ===
> 
> 3. Distribution of Data
> 
> The distribution of number portability data is often highly 
> restricted either by contract or regulation of a National 
> Regulatory Authority (NRA), THEREFORE NAPTR records described 
> herein MAY OR MAY not be part of the e164.arpa DNS tree.
> 
> Distribution of this NAPTR data would be either (a) on a 
> private basis (within a service provider's internal network, 
> or on a private basis between one or more parties using a 
> variety of security mechanisms to prohibit general public 
> access), (b) openly available, BUT MAYBE on a national basis 
> ONLY according to national regulatory policy, OR (C) 
> DISTRIBUTED BY THE RELEVANT NUMBER PORTABILITY ORGANIZATION 
> OR OTHER INDUSTRY ORGANIZATION.
> 
> The authors believe that it is more likely that these records 
> will be distributed on a purely private basis.  If such data 
> was distributed nationally, the national telephone numbering 
> authority, or some other regulatory body OR NUMBERING 
> ORGANIZATION, may have jurisdiction.  Such a body may choose 
> to restrict distribution of the data in such a way that it 
> may not pass over that country's national borders.  How 
> number portability data is collected and distributed is out 
> of scope of this document.
> 
> ===
> 
> Best,
> 
> 	Carsten
>

---

From: "Schiefner, Carsten" <[email-masked]>
Date: Tue, 29 Nov 2005 09:46:25 +0100

Hi Jason,

> I think this still captures what you were looking for.

exactly - thanks! :-)

Best,

	Carsten

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 29 Nov 2005 12:08:28 +0100

Folks,

apologies for jumping in, I did not completely follow this
thread being busy otherwise, but could anybody please
explain to me how this is intended to be implemented technically?

> (b) openly available, but possibly on a
> policy,

How is data in the DNS openly available, but only on a national basis?

Please elaborate

Richard

> Sent: Monday, November 28, 2005 5:25 PM
> To: Carsten Schiefner; [email-masked]
> Cc: Richard Shockey