Subject: [Enum] Last Call: 'ENUM Validation Architecture' to Informational RFC (draft-ietf-enum-validation-arch)

From: "chenhui" <[email-masked]>
Date: Tue, 22 Aug 2006 18:33:26 +0800

Dear Alex and Bernie,

Quite important draft to promote ENUM application!

We studied this draft and had a discussion. Here are some questions and suggestions for you:

1. The data flow of validation process says "A Validation Entity may choose to perform all communication with the Assignee via the requesting Registrar rather than contacting the Assignee by itself." in last paragraph of Sec 4.3, but actually Figure 4 of Sec 5.2 shows VE directly communicates with Assignee.
   We are not clear that how does VE directly communcates with Assignee, or that VE draws the effective validation inforamtion out of the Assignee/Registrant's registration information from Registrar.

2. It says VE possess the validation function, but the description of VE in the implementation  seems VE is only an agent to preform validation, such as Figure 4 of Sec 5.2 that VE fetches information from NAE and Assignee.
----suggestion: VE possess validation database as the third validation center, and need not to inquire of other entities about the assignee's information during validation process.

3. Sec 2 requirement mentions "recurring validation" or "revalidation", and Sec 4.1 describes revalidation workflow. We think it is rather complex when expiration of E.164 number and expiration of ENUM domain name both need to be considered.
----suggestion: Period of E.164 number validity need to be refered only when E.164 number is assigned. And after registration of ENUM domain name and ENUM services, E.164 number validity equals to ENUM domain name/services validity.

4. The different entities have different demands of benefit, so it is difficult to level the relation of each entities in ENUM provision model, especially Registry, Validation Entity and Number Assignment Entity.
----suggestion: Registry has the right to delegate NAE, and NAE is also the VE.

The following figure explains our point of view:
        +----------+
        | Registry | \
        +----------+  \ 
             ^         \ 
             |          \
             |           \
             |            \ 
             |             \
             |              \
             |               \ 
             |                \ 
             |(8)              \(9)
             |                  \ 
             |                   \
             |          (6)       v
        +-----------+ ---------->+---------+
        | Registrar |<---------- | NAM(VE) |
        +-----------+   (7)    > +---------+
             ^                     ^  |
             |                     |  |
             |                     |  |
             |(5)                  |  |
             |                  (2)|  |
             |                     |  |
             |                     |  |
             |                     |  |
             |                     |  |(3)
             |                     |  |
             |                     |  V
       +------------+    (4)     +---------+ 
       | Assignee = |<---------- |  NAAE   |
       | Registrant |----------> |         |
       +------------+    (1)     +---------+

         NAM: Number Assignment Management
         NAAE:  Number Assignment Agent Entity
         VE:   Validation Entity

   (1) The Assignee applys for an E.164 number from NAAE and submits personal particular information .
   (2) NAAE sends Assignee's information and the applied E.164 number to NAM.
   (3) NAM checks whether the E.164 number has been assigned in its Validation database, if not-assigned adds record in database(Assignee's information and the applied E.164 number are used as validation information, and period of ENUM validity is created) and returns successful result, otherwise returns failed result.
   (4) NAAE tells Assignee the result got from NAM.
   (5) The Assignee applies the corresponding ENUM domain name at a ENUM Registrar.
   (6) The Registrar requests validation at NAM(VE).
   (7) The VE verify that the Assignee of the E.164 number corresponds to the Registrant of the ENUM domain name and return result.
   (8) The Registrar sends an ENUM registration request to the Registry. Additional information about the validation process might be sent along with the registration request.
   (9) Finally, Registry sends to NAM the information that the certain E.164 number has been used.(this information is used to renew period of ENUM validity)

The benefits of our opinion are as following:
1.Registry gets delegation from government and answer for the whole process of ENUM number assignment and ENUM domain name registration, which can avoid benefit and responsibility of different entities.
2.Unification of ENUM number expiration and ENUM domain name expiration can reduce operation and combine the ENUM number and ENUM domain name/ENUM services.
3.Independence of VE provides rather absolute validation database, and is useful for management and validation of ENUM application.

We just bring out some thinking, and if any different opinion, let's discuss further.

Yours sincerely 

Chenhui, Wangfeng, Chenliang

----- Original Message ----- 
From: "The IESG" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, August 17, 2006 5:59 AM
Subject: [Enum] Last Call: 'ENUM Validation Architecture' to Informational RFC (draft-ietf-enum-validation-arch) 

> The IESG has received a request from the Telephone Number Mapping WG to 
> consider the following document:
> 
> - 'ENUM Validation Architecture '
>   <draft-ietf-enum-validation-arch-03.txt> as an Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by 2006-08-30.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-arch-03.txt
> 
> 
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum
>

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

---

From: Alexander Mayrhofer <[email-masked]>
Date: Tue, 22 Aug 2006 17:04:53 +0200

> Quite important draft to promote ENUM application!

Hi chenhui,

>    We are not clear that how does VE directly communcates with Assignee, or that VE draws the effective validation inforamtion out of the Assignee/Registrant's registration information from Registr…

Actually, it's pretty much a local choice how a VE together with a Registrar
would like to operate. If the registrar already provides enough information
together with the validation request, there may be no need to contact the
assignee at all, however, we can't explude it in the draft.

Please note that section 5 provides just examples - in the first case
(section 5.1), the VE does not interact with the Number holder at all - the
number holder might not even be aware of the VE. In the second example,
however, the VE uses some kind of eg. call back mechanism to check the data
provided by the registrar in the validation request.

Conclusion: By not limiting if, when and how a VE interacts with the
Assignee, our model becomes flexible enough to fit current (and hopefully
most future) models of ENUM administration. There may be rather "free"
models (as we have implemented it in Austria), and there may be models where
the actual form of communication is dictated by the NRA or an industry
consortium. Our draft, again, does not preclude either case.

> 2. It says VE possess the validation function, but the description of VE in the implementation  seems VE is only an agent to preform validation, such as Figure 4 of Sec 5.2 that VE fetches informat…

yes, that's exactly its purpose. To handle the validation process, however
that is implemented. What do you mean by "posessing the validation
function"? Do you mean that the VE posesses all relevant data?

> ----suggestion: VE possess validation database as the third validation center, and need not to inquire of other entities about the assignee's information during validation process.

I don't understand what the other two validation centers would be. However,
to make it work as you indicated, you would need to force every telco in
every country of this world to hand over his complete customer database to
all VEs in that country - i can't imagine that this will happen anytime soon.

Again, we do not exclude a case where a VE _could_ have the information that
you describe - our model gives freedom in this perspective as well.

> 3. Sec 2 requirement mentions "recurring validation" or "revalidation", and Sec 4.1 describes revalidation workflow. We think it is rather complex when expiration of E.164 number and expiration of…

In many countries, E.164 numbers do not "expire". My parents have their
phone number since about 25 years, they even switched their telcos a few
times, and kept their number. Their number will be relinquished when they
cancel their phone line, but that's up to their decision, and not tied to
any date.

> ----suggestion: Period of E.164 number validity need to be refered only when E.164 number is assigned. And after registration of ENUM domain name and ENUM services, E.164 number validity equals to…

As outlined above, there are existing numbers out there which do not expire
"automatically". Most of the phone numbers out there are also not tied to an
ENUM-Domain, because the corresponding ENUM domain has not been registered.
Therefore, the validity of the ENUM domain cannot be tied to the expiration
of the number itself. Of course would it be easier to know when a certain
number is returned, but this information is only with the respective NAE
(who might not cooperate with the registry for this purpose).

But: there might be cases where revalidation is trivial (or not even
required), eg.:

- trivial: Like in Example 5.1, where the Service provider acts as the NAE
as well as the Registrar and the VE. Revalidation becomes just a lookup in
the customer database.

- not required: When the ENUM domain existance is the basis for the number
allocation (like the Austrian number range +43 780). Because number and
domain are intrinsically tied to each other (and the number is actually
created and deleted when the ENUM domain is created and deleted), no
revalidation is neccessary.

That's the reason for the "In most cases, ..." at the beginning of the
revalidation workflow - that there might be scenarios where it's _not_
neccessary - decision about this is a local matter, again.

> ----suggestion: Registry has the right to delegate NAE, and NAE is also the VE.

Again, this precludes certain scenarios (including most current
implementations), because: The entity to appoint NAEs is the NRA (in most
cases the regulator), so if you require that the Registry appoints NAEs you
essentially require the roles of Registry and NRA to collapse into one
single entity.

By requiring that NAE and VE are the same entity, you collapse another two
roles.

When we started with the draft, our feeling was that collapsing roles is
much easier than splitting them, so we clearly seperated each role, without
precluding that an entity may perform several roles.

So, according to our draft and your scenario, you would have:

Entity "A", which assumes the role of NRA and Registry
Entity "B", which assumes the role of NAE plus a VE

This is perfectly possible with our document, but ultimately a national matter.

> The following figure explains our point of view:

Most of what you described above sounds like you're proposing an actual
validation method. Our draft does not do this for a reason: it reduces
flexibility.

On the other hand, i think that our role definition fits pretty well into
your method - the entity which serves as VE just assumes another new role
that you defined for your method (the NAM), and you introduce another role
(the NAAE).

Generally, i don't see how the method that you proposed above would work
with already assigned numbers, because verifying information provided by the
Assignee in the first place does not seem to make much sense.

> 1.Registry gets delegation from government and answer for the whole process of ENUM number assignment and ENUM domain name registration, which can avoid benefit and responsibility of different enti…

Again, our model allows to collaps several roles into a single entity as you
are proposing. We're not saying that the entity operating the registry must
not assume any other role as well.

> 2.Unification of ENUM number expiration and ENUM domain name expiration can reduce operation and combine the ENUM number and ENUM domain name/ENUM services.

I don't think you can change the way E.164 numbers are assigned, and
therefore, applying an expiration on numbers is not an option.

Additionally, E.164 numbers and ENUM domains are assigned completely
independent - that was the reason in the first place why ENUM validation was
neccessary. If both addressing elements would be assigned together,
validation would be superflous (as, again, it is the case for +43 780).

> 3.Independence of VE provides rather absolute validation database, and is useful for management and validation of ENUM application.

Sorry, i didn't get this point. Could you elaborate on this?

i hope that clarifies some of the issues - i didn't talk to bernie yet, so
he might have more comments on your suggestions. Please don't hesitate to
contact us again if there's anything which remains unclear.

thanks,

Alex

---

From: "chenhui" <[email-masked]>
Date: Wed, 23 Aug 2006 17:18:09 +0800

Dear Alex,

Thank you for your detailed explanation！
After think again, we highly agree with the flexibility of your draft.

And the suggestions we mention mainly proceed from actual domestic situation and some extension.

As you bring out in the other draft "Telephone Number Mapping and Domain Keys  as a Distributed Identity Infrastructure" that ENUM number can be used the identifier for many application such as P2P Communication/VoIP, we are also carring on this study. Thus, in order to insure authenticity of ENUM user's information, we consider the following question 1 and 2. And question 3 and 4 is about number transfer and revalidation.

1. We think the validation includes two aspects, one is the registrant's authenticity, the other is that ENUM registrant is the same with E.164 holder.
In Austrian model, "ENUM domain existence is the basis for the number allocation", ENUM domain registration is on internet, thus, how to insure the user's authenticity? Or you consider nobody will submit the mendacious information?

2. The third VE we mentioned is the neutral validation entity, which has responsibility for validation of the ENUM registration and application.
The draft shows NAE/CSP can be trusted. But actually, VoIP service providers in many countries may be lack of enough supervisal, and if certain VoIP provider goes bankrupt, transfering of users' information belonged to the VoIP provider will be a problem, so we prefer to trust the third/neutral VE who holds the total users's information.

3. You did not mention ENUM number transfer, and is it possible to transfered an ENUM number from one person to another as genaral domain transfer? 
If ENUM number permits to be transfered, then we think the Number Assignment Entity of a national range is prefered, so that users can apply ENUM number from any number assignment agents. Also, if certain ENUM number is transfered, NAE needs to tell Registry/Registrar the transfered information.

4. We want to confirm whether the revalidation in the draft denotes that ENUM validation itself has expiration date as all kinds of validation, so if ENUM delegation is beyond expiration date, revalidation is needed.
Furthermore, if ENUM number can be cancelled or transfered, maybe ENUM revalidation is needed.

BTW, E.164 number maybe has expiration time in some countries such as China. For example, a person apply one E.164 number(of course including telecommunication service) from CSP, and the default expiration time is usually three months, then if the person donnot pay again, the telecommunication service will be stopped and the number will be taken back and reassigned.

Best regards!

Yours sincerely

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 23 Aug 2006 14:02:03 +0200

> And the suggestions we mention mainly proceed from actual domestic situation and some extension.

I'm happy to hear that our draft fits your actual implementation plans -
that's the proof that it's flexible enough.

> 1. We think the validation includes two aspects, one is the registrant's authenticity, the other is that ENUM registrant is the same with E.164 holder.

exactly. See section 2 of the draft.

> In Austrian model, "ENUM domain existence is the basis for the number allocation", ENUM domain registration is on internet, thus, how to insure the user's authenticity? Or you consider nobody will…

The "number follows ENUM" model is only applied to one special number range
(+43 780). In all other number ranges, the ENUM domain follows an existing
number.

For the special number range mentioned above, numbers may be allocated
anonymously. For validation purposes, i don't need to know _who_ the owner
of the number is as long as number holder and ENUM domain name holder are
the same (anonymous numbers are possible in that range). If someone enters
wrong data for such a number, he will have a hard time recovering it once he
eg. lost his password or wants to change ISP.

There might be other validation methods where you don't need to know _who_
the number holder is, as long as you can ensure the requirements, eg. a
SMS-loop to a mobile phone may be fine for ENUM validation, but does not
transport any number holder information.

> The draft shows NAE/CSP can be trusted. But actually, VoIP service providers in many countries may be lack of enough supervisal, and if certain VoIP provider goes bankrupt, transfering of users' in…

It's the same issue when a classical telco goes bankrupt. Yes, we had that
already in Austria, where all of a sudden several thousands of customers
were disconnected because of such a case. So, this is not special to ENUM.

> If ENUM number permits to be transfered, then we think the Number Assignment Entity of a national range is prefered, so that users can apply ENUM number from any number assignment agents. Also, if…

Our local assupmtion is that the new Registrar needs to re-perform initial
validation, and then can issue a transfer request.

Additionally, there are no ties between a special NAE and a special VE or
registrar. You can register any Austrian number at any registrar (given he
accepts you as a customer, of colurse ;).

> Furthermore, if ENUM number can be cancelled or transfered, maybe ENUM revalidation is needed.

The actual expiry of validation information is local policy. eg. for
"normal" number ranges in Austria, the max. validity is 6 months, for those
"special" number range listed above the validation does not expire at all.

Our general assumption in the draft (see section 4.1) is that ENUM
delegations for which no valid validation (sic!) exists need to be suspended
from DNS (however that might be implemented).

> BTW, E.164 number maybe has expiration time in some countries such as China. For example, a person apply one E.164 number(of course including telecommunication service) from CSP, and the default ex…

yes, in that case it might be desireable to tie the validation expiry to the
expiration of the number itself.

cheers

Alex

---

From: Niall O'Reilly <[email-masked]>
Date: Wed, 23 Aug 2006 12:38:04 +0100

On 23 Aug 2006, at 10:18, chenhui wrote:
> 1. We think the validation includes two aspects, one is the  
> registrant's authenticity, the other is that ENUM registrant is the  
> same with E.164 holder.
> In Austrian model, "ENUM domain existence is the basis for the  
> number allocation", ENUM domain registration is on internet, thus,  
> how to insure the user's authenticity? Or you consider nobody will  
> submit the mendacious information?

If I've understood correctly, this is for a special category of number:
the kind of number whose allocation is coupled to an ENUM registration.
In this case, the E.164 number and the ENUM domain are aspects of a  
single
transaction, and are simultaneously issued to the same subscriber/ 
registrant;
validation is thereby considerably simplified.

If "mendacious information" is involved, the same mendacious information
is necessarily attached to both the number and the domain.

/Niall

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 23 Aug 2006 16:56:02 +0200

Niall O'Reilly wrote:

> Or arrange that the period for which a validation is effective is
> related to the
> period for which an expired number is routinely quarantined before
> re-assignment.

That was exactly the reason for those "6 months" we chose - it's the roughly
agreed "cooldown" period for geographic numbers in Austria.

Alex

---

From: Niall O'Reilly <[email-masked]>
Date: Wed, 23 Aug 2006 13:24:32 +0100

On 23 Aug 2006, at 13:02, Alexander Mayrhofer wrote:

>> BTW, E.164 number maybe has expiration time in some countries such  
>> as China. For example, a person apply one E.164 number(of course  
>> including telecommunication service) from CSP, and the default  
>> expiration time is usually three months, then if the person donnot  
>> pay again, the telecommunication service will be stopped and the  
>> number will be taken back and reassigned.
>

Or arrange that the period for which a validation is effective is  
related to the
period for which an expired number is routinely quarantined before re- 
assignment.
This approach would provide for resynchronization of validity between  
the number
and the the ENUM validation token in case the expiry date of the  
number is not
conveniently available to the VE, or that the number has to be  
prematurely
withdrawn for commercial or operational reasons.

/Niall

---

From: "chenhui" <[email-masked]>
Date: Thu, 24 Aug 2006 16:37:07 +0800

Dear Alex,

Thank you, and we have almost understanded your opinions.

The reason we mention neutral VE is that we care so much about authenticity of ENUM users. 

If NAEs can be trusted in the draft, we wonder whether _NAEs_ have the two functions:
1. NAEs have responsibility for authenticity of the ENUM number holders. (except the case of "+43780" number ranges)
2. Assignee can be assigned _any_ ENUM number from any _NAE_ in order to make ENUM number transfer more conveniently. (You have explained "You can register any Austrian number at any _registrar_" in the last letter. But if ENUM number is not +43780 number, maybe the user gets number before domain).

*****************

We have the following opinion to share with you:

ENUM, as a bridge of telecommunication and internet, should be able to promote the applications of two networks. As time as developing ENUM, the influence of VoIP, the most important application of ENUM, to traditional telecommunication needs to be considered.

In traditional telecommunication, authenticity/consistency/validity of the user's identity can be guaranteed because E.164 number is assigned according to real identity and the number is tied to a certain terminal. But it is different for VoIP service(a user can get a VoIP account by interent registration, even the user can be login from anywhere and use VoIP service).

If authenticity of ENUM users is ensured during ENUM registration and application, we think maybe ENUM can provide as an important user's validation mechanism for VoIP, to prevent falsification and warrant some security. Furthermore, ENUM can be used in NGN/3G to provide a kind of creditable and secure addressing technology.

So we consider whether the draft could mention some matters of ENUM users' authenticity.

The validation architecture we mentioned which emphasizes the function of VE is just for ENUM users' authenticity. Actually, this validation architecture has not much difference with the architechture mentioned in your draft, and the main difference is that VE needs to store users' information. If ENUM transfer happens or NAE/CSP/VoIP SP goes bankrupt, the data can be transfered or reserved effectively --- which is similar with the management of domain names in domain system between domain name Registry and registrar. It makes resolution independent of registration. Also, a replica of number allocation at VE can make validation more efficient.

And also, if there is a (Number Assignment Management) to communication with Registry, it will be more easy to implement and provide standardized ENUM services. Therefore, an independent NAM/VE is needed, it will do good to supervisal of government too.

Best Wishes!

Yours Sincerely,

---

From: Alexander Mayrhofer <[email-masked]>
Date: Thu, 24 Aug 2006 11:47:40 +0200

> The reason we mention neutral VE is that we care so much about authenticity of ENUM users. 

That's very much a local policy decision, how much and what kind of
information the different roles need to store. We tried to stay away from
mandating the actual amount of information as much as possible.

> If NAEs can be trusted in the draft, we wonder whether _NAEs_ have the two functions:

Our assumption is that the NAEs have the authoritative information about
numbers they did assign. The actual amount of that information might range
from the pure "is assigned / is unassigned" (eg. in the case of anonymous
prepaid mobile numbers) to a fully verified set of personal data (eg. for
fixed lines which include an entry in the white pages directory).

The question here is whether they cooperate in providing that data when the
entity serving as NAE does not also provide VE services. Our experience is
that it's very unlikely they cooperate unless they are forced to.

> 1. NAEs have responsibility for authenticity of the ENUM number holders. (except the case of "+43780" number ranges)

It's important to distinguish between "number allocation" and "ENUM
registration". Yes, the NAEs _should_ have the authoritative information
about the number holder (if available, see above), but they might not even
be aware that the number holder aquired the ENUM domain for that number.

> 2. Assignee can be assigned _any_ ENUM number from any _NAE_ in order to make ENUM number transfer more conveniently. (You have explained "You can register any Austrian number at any _registrar_" i…

Again, it's important to seperate the actual "E.164 number" from the "ENUM
domain". Both may be handled by completely different entities, but the
potential Registrant somehow needs to prove to the VE that he's
also the Assignee of that number.

In that actual process, information that the NAEs collected might definitely
be helpful - some of that information is already publicly available (eg.
white pages, other directories), so the VE _may_ make use of that information.

It's very similar to the number portability process, where you also have to
prove that you own the number to a different company than the one that
originally assigned you the number. That's also the reason why a successful
ENUM validation is very often a byproduct of a successful number porting
process to a ITSP.

cheers

Alex

---

From: "chenhui" <[email-masked]>
Date: Fri, 25 Aug 2006 10:57:51 +0800

Dear Alex,

Yes, ENUM number, as identity of the user, has inherent feature of NP, which is important for the various services identified by ENUM numbers.

We hope this RFC about full-scale number assignment and validation comes on, and hope it will play an vital role in the actual ENUM provision and implementation.

Best Wishes!
Yours Sincerely,