[Devel] [ openser-Patches-1344272 ] Carrier ENUM support according
to draft-haberler-carrier-enu
Klaus Darilion
klaus.mailinglists at pernau.at
Mon Oct 9 13:59:02 CEST 2006
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
More information about the Devel
mailing list