[Devel] [ openser-Patches-1344272 ] Carrier ENUM support according to draft-haberler-carrier-enu

[Klaus Darilion]

Hi Juha!

Since August the interims infrastructure ENUM methods based on branching 
inside the e164.arpa domain is working group item.

http://www.ietf.org/internet-drafts/draft-ietf-enum-combined-00.txt

This draft is supported by Otmars patch at
http://sourceforge.net/tracker/index.php?func=detail&aid=1344272&group_id=139143&atid=743022

This patch adds the following items:
1. extend openser's resolver to support TXT and EBL records.

2. extend the ENUM module to allow the use of the TXT-record based 
interm solution as described in draft-ietf-enum-combined

3. extend the ENUM module to allow usage of the EBL-record based interm 
solution as described in draft-ietf-enum-branch-location-record

4. extend the ENUM module to allow branching at the country-code level


What about adding the patch to the enum module?

btw: It does not break existing syntax

regards
klaus

Juha Heinanen wrote:
> Klaus Darilion writes:
> 
>  > At least I referred to one working group item, but the problem is it 
>  > will take at least one year for ie164.arpa to come. Should we wait till 
>  > next year before doing infrastructure ENUM?
> 
> i don't know about that but usually in ietf if a draft has working group
> support, it will become a working group draft and its name starts
> draft-ietf instead of draft-author.  none of the drafts you referred
> were draft-ietf.  waiting for registration of ie164.arpa would not be a
> reason for a draft not becoming a working group draft.  on the contrary,
> i would think that ie164.arpa registration would REQUIRE a working group
> draft where it is proposed.
> 
>  > I know you do not like to add features which are not useful for 
>  > everybody - but I hope that infrastructure ENUM will be useful for 
>  > others too and they will start sooner as the ie164.arpa becomes
>  > available.
> 
> i have nothing against infra enum.  i just don't want release version of
> enum module to be a test bed for ideas.  ser had experimental modules.
> i would suggest that you include infra enum implementation in such a
> module until dust settles. what comes to support for new standard DNS RR
> types, those could very well be included in openser core.
> 
>  > I know things would be much easier if it would be a standalone module, 
>  > but it really does not make much sense to copy 99% of the enum module 
>  > int a new ienum module. Further it requires changes to the core 
>  > (resolve.c) to support TXT records and the EBL record. This is why 
>  > integration with openser would be nice.
> 
> see above:  copy enum module until you get a working group draft to
> refer to and include the new standard RRs into core.
> 
> -- juha