This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
193.in-addr.arpa block delegation procedures (draft)
- Previous message (by thread): 193.in-addr.arpa block delegation procedures (draft)
- Next message (by thread): 193.in-addr.arpa block delegation procedures (draft)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Antonio_Blasco Bonito
bonito at nis.garr.it
Fri Mar 19 13:29:36 CET 1993
> > bonito at nis.garr.it (Antonio_Blasco Bonito) writes: > * > Yes and no inconsistent. I was just brainstorming a bit here, and since it > * > would be nice for some people to have the delegated blocks in the database > * I > * > was looking for a way to include them in the database. I do NOT want to > * > suggest here that all the rev-srv fields should be changed by sending in > * > in-addr,arpa domains for individual nets, just for the blocks. This might > * be > * > a bit confusing. I am just looking for possibilities that are both easy an > * d > * > clear ... > * > > * > -Marten > * > * OK, but at least we have to decide about 193.something networks. > * Either we use rev-srv network tags or we use nserver domain tags. > * Using both is certainly tedious and confusing. > > Blasco, > > I agree and I do not agree here (maybe I should make up my mind ;-) > I agree that using both can be confusing, but they are used for different > purposes. I would not like to see individual nets as in-addr.arpa domains in > the database, because that information is superfluous in my view. Maybe, but: - some individual net has already been registered in ripe db as in-addr.arpa domain and you have no way to avoid that, I guess. - when using inetnum entries and rev-srv tags an important information is missing: the zone-contact. > There are > no delegated blocks in the database yet, so I kind of like the idea of > putting them (and only them) as in-addr.arpa domains in the db. The only ones > that have to deal with these domains are registries, who I hope are not too > easily confused. What you are suggesting is to store in the database only one level of delegation (between RIPE-NCC and local registries). OK but the registries need to further delegate reverse resolution. If the ripe db cannot store the information about individual nets, local registries have to use some other tool, likely to be different for each registry. > I could be wrong here. Anyone else with bright ideas ? I don't think is a bright idea, but at this point I'm in favour of definining rev-srv tags obsolete and use only in-addr.arpa domains at any level. > Another thing would be to create YADO (Yet Another Database Object) for > delegated blocks only, but I do not quite like that idea either. me too. ---------- ---------- Antonio_Blasco Bonito E-Mail: bonito at nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246 Via S. Maria, 36 Telex: 500371 CNUCE I 56126 PISA Italy Fax: +39 (50) 904052 ---------- ----------
- Previous message (by thread): 193.in-addr.arpa block delegation procedures (draft)
- Next message (by thread): 193.in-addr.arpa block delegation procedures (draft)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]