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
_______________________________________________
Devel mailing list
Devel@openser.org
http://openser.org/cgi-bin/mailman/listinfo/devel
