RE: Comments on ENUM Minimum Requirements
- Date: Thu, 24 Oct 2002 18:05:24 +0200
Hi Vince,
Comments inline:
> -----Original Message-----
> From: Vincent Humphries [
]
> Sent: Thursday, October 24, 2002 5:09 PM
> To: Stastny Richard
> Cc: 'SPAN11_nar : ETSI SPAN11_nar list'
> Subject: RE: Comments on ENUM Minimum Requirements
>
Snip
> 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).
>
> - 7.: I suggest to add:
> Gaining experience in provisioning ENUM delegation
> processes between ENUM Registrars and Tier1 Registries.
> Exploring options for unified provisioning protocols across
> different countries as well as for unified validation processes.
>
> Vince: By 'unified', do you mean 'harmonised' or
> 'standardised'? If so, I am not with you as to the
> advantages, at this point, in seeking harmonisation or
> standardisation of provisioning protocols and validation
> processes. Moreover, I'm not sure how one would go about
> exploring options for harmonising or standardising these
> protocols and processes except by encouraging different
> implementation across trials, or even within the same trial
> in order to see what worked well and what did not.
Yes, I MEANT harmonized, and this finally leading to standardized. For
ENUM
to be a success, the pricing will be of crucial importance. People
already thinking about business models are raising serious concerns
about the costs of providing these service to an attractive price
to the customer, especially in the small European markets. If have
heard voices from manufacturers and operators (Tier 1 and 2)
that they do not want country specific solutions and also want to
provide services on more than one country.
So we should at least try to harmonize as much as possible, and this
includes validation, interfaces between the entities on all tiers, etc.
IMHO this is the MAIN task of ETSI as an European Standards Institute
to allow manufacturers to build products for more than one European
country,
to allow providers to buy non-nationalized products and to operate
in more than one country. This is also the reason, why the policy
frameworks in Europe should finally be harmonized. Even if the
regulators
do not want to hear this, a separate policy framework for ENUM in
each European country is not helpful for a globally available service.
I agree with your last remark, that we should not be to strict in
this early stage and give room for different implementations across
trials to find out what worked well and what did not, but the final
Goal should be to find out what worked well ;-) and take it.
>
> - 9.: "At least manual interface ..." (Note: exploring
> options for a
> unified automated Registry-Registrar-Protocol)
> Stastny: can this be enhanced to at lest structured e-mail?
>
> Vince: Again, I am not sure what is achieved by stipulating
> that a more sophisticated solution is adopted now, in order
> to facilitate interworking between trials. It raises the
> threshold as to what is regarded as acceptable for a trial,
> without any corresponding benefits that I can see, and may
> just encourage national trial organisers to ignore the document.
>
See above
>
> 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.
>
> [12]
> "Bind version 9.1 _should_": DON'T require specific
> software versions. Bind 9 is much slower than Bind 8 and
> (imho) overfeatured for production use. For that reason, Bind
> 8 is still the most widely used Name server.
> What were the reasons to require Bind 9.1?
>
> Vince: Actually, the document does not require the use of
> BIND 9.1; it says that whether version 9.1 or another version
> should be stated as a minimum requirement is a question to be
> resolved over the next few months (see the title of section
> 12). It is fair to say that, as with today's discussion on
> the RIPE list, there were different views at last week's ETSI
> meeting as to whether it was appropriate or necessary to
> specify BIND, and a particular version of it, as a
> requirement. That said (and foreshadowing the discussions we
> will have on section 12 over the next few months), I am
> inclined to agree with the remarks of David Conrad on the
> RIPE list, that a better approach is to specify the minimum
> functionality that is required (...for trial
> interworking...), and allow national trials to pick for
> themselves which software to use in order to meet those requirements.
>
Agree with David and you.
>
> - 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.
>
> Finally, glad to see the ETSI document is stimulating a
> vigorous discussion!!
Me too ,-)
Regards
Richard
>
> Regards...
>
>
> Vince Humphries
> European Radiocommunications Office
> tel: +45 33 89 63 03
> fax: +45 33 89 63 30
> e-mail: humphries@localhost
> web: www.eto.dk; www.ero.dk
>
