RE: Comments on ENUM Minimum Requirements

["Stastny Richard" <]

Good morning, Vince
Comments inline

> Vince (2): If you mean that we should try and identify issues 
> for possible harmonisation now, in order to encourage 
> evaluation of different options for addressing each issue 
> during the trials, that is something I think would be quite 
> useful (if we can get the work done quickly enough).

Thats what I meant with workplan: We should define the minimum
requirements (maybe in steps - e.g. DNSSEC), but during the
discussion (as we see already) a lot of things will pop up, which
are not relevant for "minimum requirements for interoperablity", but
should be harmonized. So after finishing the ETSI guide, we could
continue an further work.
> Vince (2): Ok, I follow you now.
> As is often in debates about harmonisation/standardisation, I 
> think we need to ensure that harmonisation/standardisation 
> work (especially in relation application SW) does not hinder 
> innovation.
> 
Agree, but this is always to consider with harmonization/standardization

> > Will sleep over it.
Done.
> 
> Vince (2): Sorry to have been overly complicated. What I 
> meant is perhaps illustrated by a couple of examples. The 
> first and easiest one is cancellation by a subscriber of 
> their contract with a TSP during porting of a number. The 
> cancellation of the contract does not mean that the number is 
> withdrawn. I recognise, however, that there may be 
> streamlined procedures to handle this particular case. The 
> second example is a number which has been assigned directly 
> to a user by an NRA (as is possible for service numbers in 
> many European countries), and which is used on a seasonal 
> basis only. Between seasons, while the number is "dormant", 
> the user may cancel its contract with a particular TSP, and 
> only initiate a new contract (with the same or a different 
> TSP) at the beginning of the next season. During the same 
> period, the user may have its ENUM NAPTRs removed... or maybe 
> not. I would regard it as the user's prerogative to decide. 
> The point here is that the status of a number (assigned,
> withdrawn) is independent of any contract that the user has 
> with a TSP.

Fine, now I get your point. We discovered already, that there
may (or already is) be a feedback on the treatment of numbers
in conjunction with ported numbers and personal numbers,
especially the need to "park" numbers.

In VISIONng two weeks ago we already decided to broaden the 
status of UPT-numbers in the admin part of the TRC
Unassigned
Assigned to TSP
Assigned to ENUM SP
Parked

Depending on the final policy, you may have now a bunch
of different tranactions, e.g. we may allow ENUM only numbers,
as you suggested.

If ENUM only is not allowed, we also have solved the problem
Paul mentioned to trigger the deregulation (this has also
decided to be done by the TRC, if necessary).

Just to answer a potential question on ENUM-only beforehand:
calls to ENUM-only UPT numbers will be terminated on the PSTN
in the UPT environment by routing to an announcement.

Regards
Richard