[Devel] [patch] Carrier ENUM support according to draft-haberler-carrier-enum-01.txt

[Otmar Lendl]

On 2005/11/01 11:11, Juha Heinanen <jh at tutpro.com> wrote:
> Otmar Lendl writes:
> 
>  > I've added support for the carrier ENUM setup as described in 
>  > draft-haberler-carrier-enum-01.txt. This code is indended to
>  > facilitate a trial. This certainly is not the final release as
>  > the spec itself is in flux.
> 
> the spec is not even a working group draft.

Yes. It's the old chicken/egg problem: What's first? The code or
the standard. Given the IETF motto, we decided not to wait until
the RFC before we start implementing this idea.

>  > Anyway: please have a look and give me some indication whether
>  > the patch could be incorporated into the default openser release.
> 
> since i have been maintaining enum module, i would like to know if this
> patch some has performance impact on enum function as used currently?

Basically the change moves the main code from enum_query_2 to a new
function enum_query_3 in which the additional code is only execute
if carrier enum was desired.

So, maybe one function call overhead plus one "if" statement. The
minor rearrangement I made in the string-handling should be 
performance-neutral.

> also, would you be willing to maintain enum module if this patch is
> incorporated?

Short term, probably yes. Longer term is a question which my boss
has to answer.

> in my opinion, these kind of experimental features should be done using
> experimental modules until the feature stablilizes and is found
> generally useful.

I thought of that as well, but then decided against duplicating
a lot of code into a new module. After all, my changes only 
affect the "turn number into domainname"-part of ENUM and not the
much trickier NAPTR parsing and selection.

Any changes to the original enum module are very likely to apply to 
a spinoff module as well, so weighed the maintenance hassle of
two almost identical modules against the introduction of an
experimental feature in a mature module.

The make future reintegration with the main trunk easy such an
experimental module would look exactly like my patched enum module. 

Anyway, there is an IETF meeting next week and this should give me
some direction on the protocol evolution. 

If it's the consensus here that such trials should not happen in 
the current enum module, I'll fork the module. 

/ol
-- 
< Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer >