From joao at ripe.net Mon Dec 7 20:07:26 1998 From: joao at ripe.net (Joao Luis Silva Damas) Date: Mon, 07 Dec 1998 20:07:26 +0100 Subject: Maintainer creation policy Message-ID: <199812071907.UAA11881@office.ripe.net> Dear all, the RIPE NCC is considering relaxing the requirements for obtaining a maintainer. This has certain consequences that we would like people to consider and then put forward comments either supporting or rejecting this proposal. We propose the following new policy: - The RIPE NCC will create maintainers for all users whose person/role object is mentioned in any object in the RIPE database except if it is only mentioned in other person or role objects. - If the person/role is not mentioned in any other object, the maintainer will not be created. This should allow all users to protect their data but prevent the database from becoming some sort of "phone book". Some consequences of this would be: - The RIPE NCC would no longer do any identity checks on the requester (compliance with the policy will be, of course, checked). - Users may wish to protect objects that already have (soft) maitainers. A clear example would be a user protecting a domain object with a soft maintainer (eg: auth: NONE) with their own maintainer (which may have PGP on it). - Users with inetnum,route,etc objects are strongly encouraged to protect their objects with a strong maintainer to prevent accidental or malicious "protection" by other users. Note: Any object can have more than one maintainer. To modify/delete an object only one maintainer authentication needs to be matched. In order to add a maintainer to an object that already has one (or more) the user will need cooperation from one of the previous maintainers. Waiting for your comments, Joao Damas RIPE DB Group RIPE NCC From mike.norris at heanet.ie Mon Dec 28 21:58:13 1998 From: mike.norris at heanet.ie (Mike Norris) Date: Mon, 28 Dec 1998 20:58:13 -0000 Subject: Afrinic Proposal Message-ID: Paula many thanks for that good news. I'm sure RIPE and the NCC wish Afrinic every success and will give every possible help and advice to the formation process. Can we invite some of the people concerned to RIPE 32? Perhaps Rob could feature this in the agenda? Regards. Mike ---------- > From: Paula Caslav > To: local-ir at ripe.net; lir-wg at ripe.net > Subject: FYI: Afrinic Proposal > Date: 28 December 1998 14:20 > > > Dear Registries, > > After a meeting in Cotonou Benin, there is a proposal to create a new > Regional Registry for the continent of Africa. If you are interested > in reading the proposal, please look at the web site: > > www.afrinic.org > > and if you wish to participate in the discussions, please subscribe to > the afrinic-discuss at afrinic.org mailing list. (Subscribe by sending a > "subscribe" request to afrinic-discuss-request at afrinic.org.) > > Kind regards, > > Paula Caslav > RIPE NCC From daniele at orlandi.com Mon Dec 28 23:24:54 1998 From: daniele at orlandi.com (Daniele Orlandi) Date: Mon, 28 Dec 1998 23:24:54 +0100 Subject: Not seeing updates form RIPE RR to Merit's RADB Message-ID: <36880536.84B31E90@orlandi.com> Hello, I'm seeing important changes to the RIPE route registry not being propagated to the RADB. As a result, I'm having serious reachability problems with many mae-east and mae-west peers. For example, the 62.212.0.0/19, AS-NACAMAR, AS3257, AS9026 objects are different between whois.ra.net and whois.ripe.net. Is this right ? Am I doing somethin wrong ? Thanks in advance. Best regards. -- Daniele ------------------------------------------------------------------------------- Daniele Orlandi - Utility Line Italia - http://www.orlandi.com Via Mezzera 29/A - 20030 - Seveso (MI) - Italy ------------------------------------------------------------------------------- From daniele at orlandi.com Mon Dec 28 23:47:09 1998 From: daniele at orlandi.com (Daniele Orlandi) Date: Mon, 28 Dec 1998 23:47:09 +0100 Subject: Not seeing updates form RIPE RR to Merit's RADB (SOLVED) Message-ID: <36880A6D.8F65BB6F@orlandi.com> Gerald Winters just wrote me saying that the problem is fixed. Best regards and happy new year. -- Daniele ------------------------------------------------------------------------------- Daniele Orlandi - Utility Line Italia - http://www.orlandi.com Via Mezzera 29/A - 20030 - Seveso (MI) - Italy ------------------------------------------------------------------------------- From Havard.Eidnes at runit.sintef.no Tue Dec 29 13:50:44 1998 From: Havard.Eidnes at runit.sintef.no (Havard.Eidnes at runit.sintef.no) Date: Tue, 29 Dec 1998 13:50:44 +0100 Subject: Maintainer creation policy In-Reply-To: Your message of "Mon, 07 Dec 1998 20:07:26 +0100" References: <199812071907.UAA11881@office.ripe.net> Message-ID: <199812291250.NAA00312@snylteveps.runit.sintef.no> > the RIPE NCC is considering relaxing the requirements for obtaining a > maintainer. This has certain consequences that we would like people > to consider and then put forward comments either supporting or > rejecting this proposal. > > We propose the following new policy: > > - The RIPE NCC will create maintainers for all users whose person/role > object is mentioned in any object in the RIPE database except if it is > only mentioned in other person or role objects. > - If the person/role is not mentioned in any other object, the > maintainer will not be created. > > This should allow all users to protect their data but prevent the > database from becoming some sort of "phone book". Maybe I'm getting out of touch with things, but frankly, I do not see how this solves the "phone book" problem or any other problem for that matter. Instead I see it creating a few new problems... I also do not really understand from the description above what exactly is going to happen. Some interpretations: o All "person" objects referenced from other objects (except "role" objects) will result in the creation of a new maintainer object for that user, and the user's maintainer will be added as a mnt-by: attribute of the objects where the person was referenced earlier. If the total size of the database is a problem (and I think it is), this will not help one little bit, as this will add new objects corresponding to a *large* percentage of the person objects in the database. Furthermore, it is not necessarily true that users referenced as admin-c, tech-c or zone-c *own* the information registered, although there may be consensus that this is so for the Internet registry part of the RIPE database. For the other "subparts" of the database there may be policy implications of updating the information, a prime example could be information from the domain registry side. o The RIPE NCC will add mnt-by: attributes on all person objects referenced from other objects (except "role" objects). Which maintainer is to be used is not exactly stellar clear. I consider this to be an unlikely interpretation, although I must say that the statements above are sufficiently unclear that I do not clearly understand what is going to happen. I do not understand at all how this will reduce the "phone book" problem of the RIPE database, as this will not prevent the creation of "free- standing" objects in the RIPE database (?). I furthre presume that the "phone book" problem is exactly this -- free-standing, un-referenced person objects? Another alternative to the "phone book" problem could be that a large part of the RIPE database is indeed objects resulting from it making double duty as a domain registry information repository, although I still seem to remember statements by the RIPE NCC to the effect that this is not regarded as a problem. Why not just permit maintainer object creation by anyone satisfying the above requirements ("reference exists"), but not create the maintainer objects themselves or the mnt-by: attributes? I cannot see that there have been any comments to this proposal, so am I the only one who does not understand what is going to happen, and what the rationale for it is? I do however think that the effective time between announcement and implementation is way too short -- with IETF and Christmas and New Year holdays in-between it comes down to 1-2 weeks only. Regards, - H?vard From joao at ripe.net Tue Dec 29 15:44:58 1998 From: joao at ripe.net (Joao Luis Silva Damas) Date: Tue, 29 Dec 1998 15:44:58 +0100 Subject: Maintainer creation policy In-Reply-To: Your message of Tue, 29 Dec 1998 13:50:44 +0100. <199812291250.NAA00312@snylteveps.runit.sintef.no> References: <199812291250.NAA00312@snylteveps.runit.sintef.no> Message-ID: <199812291444.PAA03362@x41.ripe.net> Havard.Eidnes at runit.sintef.no writes: * > the RIPE NCC is considering relaxing the requirements for obtaining a * > maintainer. This has certain consequences that we would like people * > to consider and then put forward comments either supporting or * > rejecting this proposal. * > * > We propose the following new policy: * > * > - The RIPE NCC will create maintainers for all users whose person/role * > object is mentioned in any object in the RIPE database except if it is * > only mentioned in other person or role objects. * > - If the person/role is not mentioned in any other object, the * > maintainer will not be created. * > * > This should allow all users to protect their data but prevent the * > database from becoming some sort of "phone book". * * Maybe I'm getting out of touch with things, but frankly, I do not see * how this solves the "phone book" problem or any other problem for that * matter. Instead I see it creating a few new problems... * Per se, it doesn't. But it prevents users from protecting their objects if the only thing they have is a person (or role) object. And, as experience goes, anything can happen to an unprotected object. As for interpretations... This is just the criteria we will use to create (or not) a new maintainer upon a user request. The RIPE NCC will not create maintainers *automatically* nor will it modify users' objects after creating a new maintainer (eg. to include mnt-by lines). This is up to the user. This doesn't reduce the phone book problem but it doesn't increase it as it would if we gave out maintainers to everyone. May be, eventually, some day, somehow, someone will carry out a free-standing, un-referenced object cleanup. The problem with creating maintainers is that they require a security override, so normal users can't do it themselves. The RIPE NCC does it upon request. * I also do not really understand from the description above what exactly * is going to happen. Some interpretations: * * o All "person" objects referenced from other objects (except "role" * objects) will result in the creation of a new maintainer object for * that user, and the user's maintainer will be added as a mnt-by: * attribute of the objects where the person was referenced earlier. * * If the total size of the database is a problem (and I think it is), * this will not help one little bit, as this will add new objects * corresponding to a *large* percentage of the person objects in the * database. * * Furthermore, it is not necessarily true that users referenced as * admin-c, tech-c or zone-c *own* the information registered, although * there may be consensus that this is so for the Internet registry part * of the RIPE database. For the other "subparts" of the database there * may be policy implications of updating the information, a prime * example could be information from the domain registry side. * * o The RIPE NCC will add mnt-by: attributes on all person objects * referenced from other objects (except "role" objects). Which * maintainer is to be used is not exactly stellar clear. I consider * this to be an unlikely interpretation, although I must say that the * statements above are sufficiently unclear that I do not clearly * understand what is going to happen. * * I do not understand at all how this will reduce the "phone book" problem * of the RIPE database, as this will not prevent the creation of "free- * standing" objects in the RIPE database (?). I furthre presume that the * "phone book" problem is exactly this -- free-standing, un-referenced * person objects? Another alternative to the "phone book" problem could * be that a large part of the RIPE database is indeed objects resulting * from it making double duty as a domain registry information repository, * although I still seem to remember statements by the RIPE NCC to the * effect that this is not regarded as a problem. * * Why not just permit maintainer object creation by anyone satisfying the * above requirements ("reference exists"), but not create the maintainer * objects themselves or the mnt-by: attributes? * * * I cannot see that there have been any comments to this proposal, so am I * the only one who does not understand what is going to happen, and what * the rationale for it is? * Well, I have tried to explain above what this is about. If there are more questions I will happily answer them. * I do however think that the effective time between announcement and * implementation is way too short -- with IETF and Christmas and New Year * holdays in-between it comes down to 1-2 weeks only. * May be it's 1-2 weeks for a particular individual but it's nevertheless a month with a lot of working days. If people think extending the implementation period is a good thing, we can do it, but it's only worth it if there is going to be a discussion about this. Keep in mind that this is mostly a RIPE NCC internal procedure (modification of the criteria for creating/denying maintainers) and the announcement is mainly intended to wake up people that have unprotected objects before maintainer availability becomes more widespread (just in case someone misuses maintainers). Regards, Joao Damas RIPE NCC * * Regards, * * - H?vard * From phk at critter.freebsd.dk Tue Dec 29 14:52:16 1998 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Tue, 29 Dec 1998 14:52:16 +0100 Subject: Maintainer creation policy In-Reply-To: Your message of "Tue, 29 Dec 1998 13:50:44 +0100." <199812291250.NAA00312@snylteveps.runit.sintef.no> Message-ID: <78704.914939536@critter.freebsd.dk> It sounds to me like it would be a better solution to make a person object maintain itself in the absense of any other maintainer, basically changing to rules such that: A person object can have either a maintainer or an authentication mechanism (password/mailfrom or pgp) That would prevent a doubling of the number of records in the database. -- Poul-Henning Kamp FreeBSD coreteam member phk at FreeBSD.ORG "Real hackers run -current on their laptop." "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal