Dear all,
The DB WG chairs' advice was that the purpose and/or future of "rev-srv" should be discussed here first. That said, what do you think about deprecating the "rev-srv" attribute?
Deprecate it, perhaps in 2 steps (first make sure it can't be inserted anymore, and updated objects can't have it, remove from old objects later).
Yes, I think this is a wise approach, I support it. Keeping the inetnum in sync with DNS (domain objects) seems to be a hopeless task, if not enforced by the automatic in-addr.arpa zone generation. Having only inetnum defining the reverse zones is not an alternative (due to assignment longer than /24). Hence inetnum/rev-srv is redundant. Peter originally said:
(A2) even if the leaf zone name cannot be guessed for RFC 2317 delegations, the "rev-srv" attribute might help in locating the zone containing the CNAME RRs
I do not think this helps. If you cannot guess the domain name (e.g. 0/25.2.0.192.in-addr.arpa), knowing that the zone is on ns.A.domain and some.other.name.server (expample on page 2 of RFC 2317) is of no help in my view. At the same time, you can easily get the domain name with a `host -a 1.0.192.in-addr.arpa` query on a recursive server. Therefore I do not think this is a valid reason for keeping rev-srv. Having outdated/erroneous data in the DB is not desirable at all. In short: I think rev-srv can be deprecated. Best regards, Janos