RE: Comments on ENUM Minimum Requirements

[Vincent Humphries <]

Hi Richard

More comments from me (inline)...

> > Vince: I am not sure why a web-based interface should be a 
> > _minimum_ requirement for interworking between ENUM trials. 
> > If, for simplicity, a particular national trial considers it 
> > sufficient to rely on faxes or some other acceptable method, 
> > how would this affect interworking with other trials?
> 
> You are right, in the strict sense of the title of the document,
> A web-based interface is not a requirement for interoperability.
> But on the other hand, we should keep a certain standard ;-)
> IMHO a fax is not an acceptable method now-a-days (not even for
> registration,
> but definitely not for NAPTR modification).
> 
> Maybe we could (considering also the discussion going on) broaden
> the scope and title to interopeability AND harmonization (see also
> below).

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).

[snip]

> > 	Additionally, i'd like to add that there has to be an 
> > interface between registrant (number assignee) and ENUM DNS 
> > provider allowing modification of NAPTR contents. Using an 
> > unified protocol/mechanism would greatly increase the 
> > interopability between applications and different ENUM DNS 
> providers.
> > 
> > Vince: My earlier comments on unified protocols apply here 
> > also. In addition, are you saying here that a unified 
> > protocol for communications between ENUM subscriber and ENUM 
> > DNS provider would facilitate interoperability between 
> > applications and ENUM DNS providers? If so, I do not follow 
> > how or why applications and ENUM DNS providers need to interoperate.
> 
> Ok, this is an unprecise formulation, my fault. Here is not meant the 
> applications of an ASP, but potential application SW of the "ENUM
> subscriber"
> (starting to use the newly proposed term ,-). Instead of using a
> web-based
> interface, the ENUM subscriber may use an application SW on his PC or
> server
> and communicate e.g. with enhanced EPP. This may come in handy
> considering
> the next logical step of PBX-administrators and ENUM tier 3. 
> This issue
> is currently a bit neglected in Europe, but one of the highrunners in
> US.
> 
> See also Rich Shockey's comments on this. I had some talks to 
> Rich last
> week in Atlanta and got the impression, that on the other side of the
> pond
> the main drive for ENUM and VoIP is mainly in the business market (PBX
> and Centrex)
> for medium and large enterprises, whereas in Europe we 
> concentrate more
> on the residential customer. Correct me, if I am wrong, Rich.

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.

[snip]

> > -	13.3: I'd add "TSP initiated cease - Registrant has 
> > cancelled his
> > contract with his telephony provider and therefore lost his 
> > number assignment." 
> > 
> > Vince: Three comments on this. Firstly, there is a 
> > discrepancy between the title ("TSP initiated cease") and the 
> > remaining text ("Registrant has cancelled his contract...) -- 
> > in the first, the TSP is the action party whereas in the 
> > second it is the registrant. Secondly, the reference to 
> > registrant should be to ENUM subscriber -- some registrants 
> > may not have a contract with a TSP (i.e. they may be an agent 
> > for an ENUM subscriber). Thirdly, the terminology used in 
> > "ENUM Administration in Europe" -- "An E.164 number shall be 
> > removed from ENUM Tier 1 Registry and ENUM Tier 2 Nameserver 
> > provider when... the number is withdrawn" -- is in my view 
> > preferable to references to contracts, which may have nothing 
> > (at least
> > directly) to do with ENUM data. In other words, if a number 
> > is withdrawn as a consequence of the cancellation of a 
> > contract or any other action (e.g. NRA-initiated withdrawal 
> > of a number), there is a need for a cessation process to 
> > remove records from ENUM, but cancellation of a contract may 
> > not, in all countries and in all cases, result in the 
> > withdrawal of the number.
> 
> This is to complecated for me at this time of the day;-)
> Will sleep over it.

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.

Regards...


Vince