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

[Bogdan-Andrei Iancu]

Hi Otmar, Hi Juha,

I think the basic idea about adding new non-standard patching/feature to 
stable module should be not to affect the original behaviour of the 
modules - if there is a way to disable completely the new feature and to 
use the module as it way before patching, I would say fine by me.
Because we make happy to aspects:
    keep the module's original behaviour stable
    allow new code to get in.

the second aspect is if the new feature will because a standard or not 
:)...we will find out in the next week, according to Otmar.

regards,
bogdan

Otmar Lendl wrote:

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