Dear colleagues, rather recently I was involved in clearing up some old inetnum assignments in the RIPE database. During that archaeologic work a couple of objects with the "rev-srv" attribute were discovered and it turned out that the presence of this attribute not necessarily contributed to an easy solution. The rev-srv attribute was intended to specify the name servers for the "reverse mapping" for a given address range. However, it is just informative in nature. For quite some time now the automatic generation of the IN-ADDR.ARPA zones has been based solely on the "domain" objects (see <http://www.ripe.net/reverse/>). So, it turns out "rev-srv" has some disadvantages: (D1) the "rev-srv" attribute is redundant, because only "domain" objects cause delegations to be present in reverse zone maintained by the NCC (D2) "rev-srv" lacks consistency checks with both the reality and any potential "domain" object; several attributes just contain incorrect information (D3) the "rev-srv" attribute does not really help finding the zone for address ranges smaller than /24 (where delegations are following RFC 2317) On the other hand, it might still have advantages: (A1) where there is a delegation from an NCC maintained zone to an LIR for, say, a /16 address range, the "rev-srv" attribute for enclosed /24s may provide useful additional information (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 (A3) "rev-srv" attributes could provide additional information in legacy class B space (D1), (D2), and (A1) similarly apply to v6 reverse and inet6num objects. Today, approximately 5% of all "inetnum" objects have at least one "rev-srv" attribute. Of these objects, 17% have been changed in 2007 (which does not imply the rev-srv was changed or checked), and 35% were changed in 2006 or 2007. That means "rev-srv" does not only appear in old objects, but may still be carried as a legacy. The objects with "rev-srv" are maintained by 1300 different maintainers, almost 500 of which own only a single object with "rev-srv". Given the confusion mentioned in the introduction and looking at the pros and cons (where the lists above are not meant to be exhaustive), what is the use of "rev-srv" for a "user" of the object or for its publisher/maintainer? 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? -Peter (speaking as $self)