Subject: [Enum] Comments on draft-ietf-enum-infrastructure-enum-reqs

From: [email-masked]
Date: Wed, 22 Nov 2006 00:17:50 -0500

I hope this isn't too late for the Last Call...

In regard to draft-ietf-enum-infrastructure-enum-reqs-03.txt:

* Section 2.1. Definition

It would make reading easier, IMO, if the first uses of the phrases
"infrastructure ENUM" and "user ENUM" were quoted (as I just did) --
the terms really have meaning only as phrases, and it is helpful to
the naive reader to use quotes to point that out.  (A lot of math
books will italicize any phrase the first time it is defined, which
makes it clear the exact extent of the term being defined.)

The first sentence is also rather complex, and is structured in a way
that is a bit unnatural -- it uses the construction "use of the
technology in RFC 3761 to map a telephone number", but the action
isn't the mapping itself, the action is the *publishing* of a
mapping.  A clearer phrasing would be:

   "Infrastructure ENUM" is defined as the use of the technology in
   RFC3761 [2] by the carrier-of-record for a specific E.164 number
   [3] to publish the mappping of the E.164 number into a URI [4] that
   identifies a specific point of interconnection to that carrier's
   network that could enable an originating party to establish
   communication with the [a?] terminating party identified by the E.164
   number.

   Infrastructure ENUM is separate from any URIs that the end-user of
   the E.164 number may wish to associate with that number.

   Infrastructure ENUM is distinguished from "user ENUM", defined in
   ...

   From a domain registration perspective, in user ENUM, the end user
   number assignee is the registrant; in infrastructure ENUM, the
   carrier-of-record is the registrant. ...

There is also a lot of test discussing what is a "carrier-of-record".
But it seems to me that this is not a good idea -- if "infrastructure
ENUM" is to mean anything, the concept of the "carrier-of-record of an
E.164 number" must *already* be defined by some mechanism outside of
ENUM.  It might be useful to elucidate what the various possibilities
are, but the text must make clear that carrier-of-record is externally
defined.  Moving the discussion to section 2.2 seems to be a good idea.

* Section 2.2. Background

This sentence reads better without the reference to the DNS tree
apex.  If there are real statements to be made about the apex, they
should be in the requirements:

   Infrastructure ENUM allows service providers to link Internet based
   resources such as URIs to E.164 numbers.

These sentences should be joined with a dash or semicolon:

   There is also no guarantee that the originating service provider
   querying infrastructure ENUM is able to access the ingress network
   element of the destination provider's network; additional peering
   and accounting agreements requiring authentication may be
   necessary.

* Section 3, item 1

Add a hyphen:

       in a single common publicly-accessible namespace.

* Section 3, item 2

   2.  Queries of infrastructure ENUM fully qualified domain names MUST
       return a result, even if the result is a Name Error (RCODE = 3).
       Queries must not be rejected, e.g., based on access control
       lists.

This seems to narrow the issue to a specific detail.  Better would be
a general statement:

   2.  Queries of infrastructure ENUM fully qualified domain names MUST
       return the same result regardless of the source of the query.

Returning an empty response based on access control is no more helpful
than returning an NXDOMAIN based on access control.

* Section 3, item 8D

It seems like this could be better phrased:

       D.  Minimize the DNS efford required to obtain the complete set
           of infrastructure ENUM DNS records.

Or perhaps "... of infrastructure and user ENUM DNS records".

* Section 3, items 5 and 8F

The term "end-user ENUM" is used in these items, but that term is not
defined.  "User ENUM" is probably meant.

* Section 3, item 8G

Add spaces in "private ENUM trees.  (In this context".

* Section 3, additional item

This section needs a requirement statement about the interaction of
infrastructure ENUM with E.164 number portability.  And given that the
number portability policies in various E.164 subdomains are likely to
change over time, number portability requirements seem to be particularly
important to specify well.

Dale

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

---

From: "Pfautz, Penn L, GBLAM" <[email-masked]>
Date: Wed, 22 Nov 2006 10:35:26 -0500

Dale:
Thanks for your comments. I'm looking through the ones on explication
but wanted to address some substantive ones
Below:

Penn 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, November 22, 2006 12:18 AM
To: [email-masked]
Subject: [Enum] Comments on draft-ietf-enum-infrastructure-enum-reqs

>defined.  Moving the discussion to section 2.2 seems to be a good idea.

I believe the bullets in 2.1 make clear that carrier-of-record *is*
externally
defined and how in an easy to operationalize way while noting that
national regulators have the final say.

>than returning an NXDOMAIN based on access control.

This requirement was to address a specific request from the chairs that
queries
not simply be dropped on the floor without response causing re-queries
and traffic flood. 
The requirement you propose is actually much different and, while the
initial (e.g., Tier 1)
response may not be origin-sensitive, further processing is likely to be
since
A carrier may have different POIs for different interconnection
partners.

>important to specify well.

I think the carrier-of-record definition has clear implications about
the relationship
Of infrastructure ENUM to number portability: if the number ports the
right to register
it moves to the recipient carrier as well.

---

From: [email-masked]
Date: Wed, 22 Nov 2006 11:32:46 -0500

From: "Pfautz, Penn L, GBLAM" <[email-masked]>

I found the discussion quite confusing.  Let me try to explain why:

At the end of paragraph 2 of section 2.1, it says 'The
"carrier-of-record" is:', and since the section is titled
"Definition", this suggests that section 2.1 is authoritative in
defining the term.  Then there are three bullets which are presented
as alternatives to each other, but it's not particularly clear which
one applies in what cases.  And at the end, there is a sentence saying
the national authorities might change all this -- which suggests that
the national authorities are the authoritative definition anyway.

(BTW, shouldn't that last sentence be "It is understood that the
definition of carrier-of-record for E.164 numbers associated with a
geographic area is subject to modification by the national authorities
with jurisdiction over that geographic area."?  Otherwise, it sounds
like the definition depends on the jurisdiction of where the reader is
standing, not where the number is standing.)

The central problem is that this section doesn't make it clear what
the authoritative definition is.  IMO, it needs to state first that
the authoritative definition is in the telco universe.  If it then
wants to provide an explanation which is *likely* to remain consistent
with the authoritative definition, that's fine.  But the explication
has got to be explicitly marked as non-authoritative, especially
because it is in a section titled "Definition".

(Remember -- You work for AT&T and are very familiar with the concept
of carrier-of-record.  I (and most of your readers) have only a vague
idea of what carrier-of-record might mean.)

   This requirement was to address a specific request from the chairs
   that queries not simply be dropped on the floor without response
   causing re-queries and traffic flood.  The requirement you propose
   is actually much different and, while the initial (e.g., Tier 1)
   response may not be origin-sensitive, further processing is likely
   to be since A carrier may have different POIs for different
   interconnection partners.

OK, I hadn't looked at it like that.  But then I think the second
sentence of item 2 would be better phrased "Queries must not be
discarded without response..." -- "rejected" to my mind means an
explicit error response.  I doubt the DNS RFCs use the term
"rejected", but an NXDOMAIN response seems pretty close to "rejected"
to me, especially if it was generated due to some permissions
situation, rather than because there *really isn't* any information
for that name.

   I think the carrier-of-record definition has clear implications
   about the relationship Of infrastructure ENUM to number
   portability: if the number ports the right to register it moves to
   the recipient carrier as well.

If it's understood in the telco world that number porting changes the
carrier-of-record of the number, then I see no reason to mention it in
the I-D.

Dale

---

From: [email-masked]
Date: Thu, 23 Nov 2006 11:05:59 -0500

Hmmm...  If that's so, you might want to add some explication of that
in the requirements.  The current definition suggests to the naive
that the mapping from E.164 number to URI is offered to all comers .

Indeed, from a technological point of view, it's a fairly complex
feature to allow different mappings to be delivered to requests made
on behalf of different originating parties.

Dale

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 23 Nov 2006 17:10:48 +0100

I would not go down this path in ENUM

We had this discussion also in Speermint
and it seems to be very complex

Leave it there

ENUM is delivering an AoR, period

Richard

> Sent: Thursday, November 23, 2006 5:06 PM
> To: [email-masked]
> Subject: Re: [Enum] Comments on
draft-ietf-enum-infrastructure-enum-reqs
>    response may not be origin-sensitive, further processing is likely
to
> be

---

From: Otmar Lendl <[email-masked]>
Date: Thu, 23 Nov 2006 17:56:45 +0100

On 2006/11/23 17:11, [email-masked] wrote:
>    The requirement you propose is actually much different and, while
>    the initial (e.g., Tier 1) response may not be origin-sensitive,
>    further processing is likely to be since A carrier may have
>    different POIs for different interconnection partners.
>
> in the requirements. The current definition suggests to the naive that
> the mapping from E.164 number to URI is offered to all comers .
>

I agree with Richard here: I-ENUM should return an AoR which act
as a "name" and does not contain source specific routing information.

It may well be that further processing is done on this AoR that leads
to different ingress points depending on the source network.

That, though, is out of scope for I-ENUM and thus need not be
mentioned in this document.

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

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 23 Nov 2006 12:20:00 -0500

Hi Otmar,

>as a "name" and does not contain source specific routing information.

But isn't this relevant under the Missoula Plan?

--tony

---

From: lconroy <[email-masked]>
Date: Thu, 23 Nov 2006 17:32:03 +0000

Hi Otmar, folks,
Me too. We were talking about ->E2U<- NAPTRs, right?
iENUM or (user) ENUM concentrates on NAPTRs using the
'E2U' DDDS application specified in RFC 3761. In effect,
it returns a universal name, not a routing ID. Routing
can and (IMHO) should be done elsewhere.

D2U/D2T/D2S NAPTR and SRV lookups as per RFC 3263 (almost
certainly in different zones) look like a much better way
to deal with any such source differentiated processing.

all the best,
   Lawrence

On 23 Nov 2006, at 16:56, Otmar Lendl wrote:
>> that

---

From: "Pfautz, Penn L, GBLAM" <[email-masked]>
Date: Sun, 26 Nov 2006 16:38:01 -0500

To clarify: I do believe infrastructure ENUM will deliver a single AoR
to all- and it will be in subsequent processing that differentiation
takes place. I just didn't want to imply that the ultimate PoI derived
would be the same for all.
My apologies for any confusion.

Penn 

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]] 
Sent: Thursday, November 23, 2006 11:57 AM
To: [email-masked]
Subject: Re: [Enum] Comments on draft-ietf-enum-infrastructure-enum-reqs

/ol

---

From: [email-masked]
Date: Mon, 27 Nov 2006 15:04:38 -0500

From: Otmar Lendl <[email-masked]>

If the carriers who are going to be the ones using I-ENUM need to have
source-specific routing, we need to make sure that the I-ENUM system
permits source-specific routing, in some method or another.  Given its
apparent importance, the requirements should at least mention the
subject and require that we not generate a standard which cannot
support source-specific routing.

Although I agree that it would probably be best not to have
source-specificity in the mapping to the SIP AoR, but rather
downstream in processing from there.

Dale

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 28 Nov 2006 10:27:32 +0100

> support source-specific routing.

There is one minor problem here: I-ENUM is based on the DNS and the
DNS (at least the public DNS) has no method for source specific replies.

So either we do not use the DNS for E.164 to URI mapping, or we change
how the DNS works. Both options are not within the scope of ENUM WG

Richard

> Sent: Monday, November 27, 2006 9:05 PM
> To: [email-masked]

---

From: lconroy <[email-masked]>
Date: Tue, 28 Nov 2006 16:33:54 +0000

Dale, folks,
  i-ENUM does not stand alone.
Source specific routing may well be a requirement of the overall
architecture, within which i-ENUM plays a part.

Please explain why it is a requirement of i-ENUM itself (rather than
other elements specific to the particular communications services  
offered)?

all the best,
   Lawrence

---

From: [email-masked]
Date: Tue, 28 Nov 2006 13:56:21 -0500

From: lconroy <[email-masked]>

I would say that it's a requirement that how we design I-ENUM *doesn't
prevent* source-specific routing.  Whether I-ENUM implements
source-specific routing itself is a question to be decided later.

Dale