From joao at ripe.net Tue Dec 1 12:42:52 1998
From: joao at ripe.net (Joao Luis Silva Damas)
Date: Tue, 01 Dec 1998 12:42:52 +0100
Subject: Ripe change to whois
In-Reply-To: Your message of Tue, 01 Dec 1998 07:34:43 +0100.
<19981201073443.A12290@nuss.hannover.sgh-net.de>
References: <19981201073443.A12290@nuss.hannover.sgh-net.de>
Message-ID: <199812011142.MAA10881@x41.ripe.net>
Hi again,
I am hearing complaints about lack of communication regarding this change in
the DB.
I would like to point out the following:
We try to announce things as much as possible and are always looking for
suggestions and ways to improve this.
However, it is and will be impossible to reach all end users (we don't want to
start spamming, do we?)
We expect to reach people whose interaction with the DB is a bit stronger than
the occasional end user.
For this we have the mailing lists, the RIPE meetings and the Web site.
Discussions about developments take place in RIPE meetings and mailing lists.
For the people that can't attend RIPE meetings all presentations are available
at the Web site. This has been so for a some time.
If you are not subscribed to mailing to mailing lists there is not much we can
do, other than suggest you to subscribe if you rely on the RIPE DB for your
work. I don't think we should be sending mails with announcements to everyone
registered in the RIPE DB.
Now, in a previous mail I pointed out a few URLs regarding discussions of the
referral mechanism.
These, in my view, are hardly 4 light years away (more like a click away) and
they are at a place where people interested are supposed to look anyway.
Not only this, but discussions have been going on since then and as you can
see in the archives (publicly available at our web site) details regarding the
referral mechanism were being discussed in the tld-wg and db-wg lists as
recently as October 6th 1998 when we were finishing the coding and changes
could still be easily introduced (as they were).
If people don't want to be subscribed to these lists but the work going on
there is relevant to them may be it would be a good idea to, at least, make it
a monthly task to overview the archives and look at the presentations given
during RIPE meetings. Otherwise, how can we make sure that we reach all
interested parties without spamming the rest?
So, although we may have room for improvement in getting announcements to a
wider audience (and we will do our best), in this particular case and the
people involved, the excuse of not knowing anything about what was going on is
hardly one at all.
As to why the referral as is implemented makes sense or not, I will leave this
to the tld community, as the interested parties, to explain.
And, I want to stress this again, everything is open to change if we a
consensus is reached on what is needed/wanted.
Regards,
Joao
Alexander Koch writes:
* Hello Joao.
*
* [snip]
* > Well the purpose of the design is to give the user information about the
* > parent domain if a certain domain is missing. That's also how the rest of
* the
* > lookups in the RIPE DB work and is also what you do when looking in the DN
* S
* > for contact info for a domain and you can't find it.
*
* Yes, sure, if I do a lookup for a single IP address I am more than happy
* to get shown the next inetnum segment.
* But for domains it fails to make much sense for me. How rare are the
* cases in which you have to look up the domain object of de? And if you
* need to, I cannot help but ask why it is not done by hand.
*
* inetnum and domain objects are rarely mixable when speaking of
* hierarchical systems... it does not scale equally, I am afraid.
*
* I would like to know some reason for this change by the tld workgroup.
*
* > May be people now see the need for an exact matching option (there is alre
* ady
* > one to disable referral: -R). However if you make this the default behavio
* ur
* > then the purpose of the referral mechanism is defeated.
*
* Let us think the other way round. Make it an whois option.
* Whatever, whois -L nothing.de works fine enough for me, but
* it is been all but nice hearing from users something weird
* happened about domains (and they were not even using the RIPE
* DB itself). Nicer If I had found out reading the announcement,
* nothing more.
*
* Regards,
* Alexander Koch
*
* --
* SGH Internet Division, Alexander Koch, Systems Administration
* Hannover, Germany, Phone +49 511 909198 0, Fax +49 511 391307
*
-------- Logged at Tue Dec 1 13:39:01 MET 1998 ---------
From akoch at sgh-net.de Tue Dec 1 07:34:43 1998
From: akoch at sgh-net.de (Alexander Koch)
Date: Tue, 1 Dec 1998 07:34:43 +0100
Subject: Ripe change to whois
In-Reply-To: <199811301558.QAA23219@x41.ripe.net>; from "Joao Luis Silva Damas" on Mon, 30 Nov 1998 16:58:09 +0100
References: <19981130163000.A1306@xlink.net> <199811301558.QAA23219@x41.ripe.net>
Message-ID: <19981201073443.A12290@nuss.hannover.sgh-net.de>
Hello Joao.
[snip]
> Well the purpose of the design is to give the user information about the
> parent domain if a certain domain is missing. That's also how the rest of the
> lookups in the RIPE DB work and is also what you do when looking in the DNS
> for contact info for a domain and you can't find it.
Yes, sure, if I do a lookup for a single IP address I am more than happy
to get shown the next inetnum segment.
But for domains it fails to make much sense for me. How rare are the
cases in which you have to look up the domain object of de? And if you
need to, I cannot help but ask why it is not done by hand.
inetnum and domain objects are rarely mixable when speaking of
hierarchical systems... it does not scale equally, I am afraid.
I would like to know some reason for this change by the tld workgroup.
> May be people now see the need for an exact matching option (there is already
> one to disable referral: -R). However if you make this the default behaviour
> then the purpose of the referral mechanism is defeated.
Let us think the other way round. Make it an whois option.
Whatever, whois -L nothing.de works fine enough for me, but
it is been all but nice hearing from users something weird
happened about domains (and they were not even using the RIPE
DB itself). Nicer If I had found out reading the announcement,
nothing more.
Regards,
Alexander Koch
--
SGH Internet Division, Alexander Koch, Systems Administration
Hannover, Germany, Phone +49 511 909198 0, Fax +49 511 391307
-------- Logged at Tue Dec 1 16:15:53 MET 1998 ---------
From mlelstv at xlink.net Tue Dec 1 14:51:34 1998
From: mlelstv at xlink.net (Michael van Elst)
Date: Tue, 1 Dec 1998 14:51:34 +0100
Subject: Ripe change to whois
In-Reply-To: <199812011142.MAA10881@x41.ripe.net>; from Joao Luis Silva Damas on Tue, Dec 01, 1998 at 12:42:52PM +0100
References: <19981201073443.A12290@nuss.hannover.sgh-net.de> <199812011142.MAA10881@x41.ripe.net>
Message-ID: <19981201145134.A5833@xlink.net>
On Tue, Dec 01, 1998 at 12:42:52PM +0100, Joao Luis Silva Damas wrote:
> Hi again,
Hi Joao,
> I am hearing complaints about lack of communication regarding this change in
> the DB.
> I would like to point out the following:
[...]
> So, although we may have room for improvement in getting announcements to a
> wider audience (and we will do our best), in this particular case and the
> people involved, the excuse of not knowing anything about what was going on is
> hardly one at all.
yeah, it's the victims fault all over again.
Sorry, this 'discussion' is only wasting time. If you don't see
that this sudden modification causes problems then I cannot help
you.
Regards,
--
i.A. Michael van Elst / phone: +49 721 6635 330
Xlink - Network Information Centre \/ fax: +49 721 6635 349
Vincenz-Priessnitz-Str. 3 /\ link http://nic.xlink.net/
D-76131 Karlsruhe, Germany /_______ email: hostmaster at xlink.net
[ Xlink Internet Consulting GmbH, Sitz Koeln ]
[ Amtsgericht Koeln HRB 3526, Geschaeftsfuehrer: Michael Rotert ]
-------- Logged at Tue Dec 1 19:44:17 MET 1998 ---------
From Niall.oReilly at ucd.ie Tue Dec 1 19:35:23 1998
From: Niall.oReilly at ucd.ie (Niall O'Reilly)
Date: Tue, 01 Dec 1998 18:35:23 +0000
Subject: Ripe change to whois
In-Reply-To: <2.2.32.19981130151444.006f4948@max.ibm.net.il>
Message-ID: <0F3A00I1UUB2TP@hermes.ucd.ie>
On 30 Nov 98, at 17:14, Hank Nussbacher quoted someone
who had written:
> >
> >As a matter of fact the referral mechanism was seen as a way for ccTLD
> >administrators to include information in the Database pointing to their own
> >authoritative sources of information.
I can confirm that this was indeed the intention when this was first proposed in
the RIPE (25, I think) DNS-WG meeting.
> > * > The RIPE NCC is therefore acting according to users directives that were
> > * > discussed and agreed on an open way.
> > *
>
Yes and no, I have to say.
At RIPE 31, the functionality proposed certainly appeared to me to be what had
been sought. I am no longer certain that this is indeed the case. In particular,
the following surprises have arisen.
First, the key notion of making the referral function available per TLD at the
option of the TLD registry concerned seems to have been lost. This is a
fundamental element of the original concept of over two years ago.
Second, the "feature" of returning the data relating to the parent domain in the
case that the specified domain cannot be found seems to me to have nothing
to do with referral. The referral concept has to do with re-directing the query to
an authoritative whois server, not with second-guessing the intent behind the
query and substituting other data which is available locally. I suggest that this
"feature" be declared a bug and removed.
I am sure that these technical problems are based on misunderstandings which
can easily be resolved.
A more significant surprise is that TLD registries, who have had no specific
prior notification, now find that data about their domains is being returned in
response to a class of query for which this was not formerly the case, and that
they have to deal with the unexpected fallout.
Niall O'Reilly
IE Domain Registry at UCD
Chair, RIPE TLD-WG
-------- Logged at Wed Dec 2 08:04:58 MET 1998 ---------
From hank at ibm.net.il Wed Dec 2 08:04:26 1998
From: hank at ibm.net.il (Hank Nussbacher)
Date: Wed, 02 Dec 1998 09:04:26 +0200
Subject: Ripe change to whois
Message-ID: <2.2.32.19981202070426.006eda2c@max.ibm.net.il>
At 06:35 PM 12/1/98 +0000, Niall O'Reilly wrote:
>On 30 Nov 98, at 17:14, Hank Nussbacher quoted someone
>who had written:
>
>> >
>> >As a matter of fact the referral mechanism was seen as a way for ccTLD
>> >administrators to include information in the Database pointing to their own
>> >authoritative sources of information.
>
>I can confirm that this was indeed the intention when this was first
proposed in
>the RIPE (25, I think) DNS-WG meeting.
>
>> > * > The RIPE NCC is therefore acting according to users directives that
were
>> > * > discussed and agreed on an open way.
>> > *
>>
>
>Yes and no, I have to say.
>
>At RIPE 31, the functionality proposed certainly appeared to me to be what had
>been sought. I am no longer certain that this is indeed the case. In
particular,
>the following surprises have arisen.
>
>First, the key notion of making the referral function available per TLD at the
>option of the TLD registry concerned seems to have been lost. This is a
>fundamental element of the original concept of over two years ago.
>
>Second, the "feature" of returning the data relating to the parent domain
in the
>case that the specified domain cannot be found seems to me to have nothing
>to do with referral. The referral concept has to do with re-directing the
query to
>an authoritative whois server, not with second-guessing the intent behind the
>query and substituting other data which is available locally. I suggest
that this
>"feature" be declared a bug and removed.
>
>I am sure that these technical problems are based on misunderstandings which
>can easily be resolved.
>
>A more significant surprise is that TLD registries, who have had no specific
>prior notification, now find that data about their domains is being
returned in
>response to a class of query for which this was not formerly the case, and
that
>they have to deal with the unexpected fallout.
Niall,
Thank you for bringing sanity to this! I am sure now that this can all be
cleared up and we can all go back to what we are all doing and let RIPE
continue working the way it has always done - with no hiccups, technical
excellence and 3 years ahead of the USA.
-Hank
>
>
>Niall O'Reilly
>
>IE Domain Registry at UCD
>Chair, RIPE TLD-WG
>
>
-------- Logged at Thu Dec 3 16:20:11 MET 1998 ---------
From Daniel.Karrenberg at ripe.net Thu Dec 3 16:19:24 1998
From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg)
Date: Thu, 03 Dec 1998 16:19:24 +0100
Subject: Domain Object Queries and Referrals (was: Ripe change to whois)
In-Reply-To: Your message of Tue, 01 Dec 1998 18:35:23 GMT.
<0F3A00I1UUB2TP@hermes.ucd.ie>
References: <0F3A00I1UUB2TP@hermes.ucd.ie>
Message-ID: <199812031519.QAA08031@kantoor.ripe.net>
Folks,
I have been pondering this for a day now and I conclude that there is no
easy answer to this issue, i.e. it is not yes/no 1/0 black/withe in any
aspect. I'll address two aspects here: process and technology. I'll
then tell you what the RIPE NCC will do now. I apologise for the
wordiness of this but I find no way to say it more concisely and stay
civil at the same time.
Process
The number of regular database users is certainly measured in the
thousands these days. This means is not OK any longer for Daniel or the
RIPE NCC to decide what is right or wrong, or what gets implemented.
Over the years we have developed a process within RIPE to develop
database policy: the database working group which involves other working
groups as required. Developments are discussed and announced in these
fora. However it comes with a back side and that is that quick
pragmatic changes are more difficult. Deciding to undo policy derived
by proper process in an ad-hoc way is something the RIPE NCC has to be
uncomfortable with and do only in rare exceptional cases. But it should
be done when necessary and the RIPE NCC will take the responsibility
when it does so. But it cannot be something one does lightly or even
regularly.
Technology
In this particular case there are two changes that are relevant to the
issue and they are inter-related. The first change is the introduction
of a referral mechanism by which an object in the database can cause the
query to be referred to another server. This apparently was well
understood by everyone concerned, especially the fact that it is at the
user's discretion whether to use this mechanism or not. A second but
tightly related change is recursive resoloution of queries for domain
object. This changes the database behavior on *all* domain name
queries: if no object with the exact name queried exists this will
search the domain name hierarchy upwards and return the first object
found in this way; in other words subdomains will be stripped until a
match occurs. At the time of the discussion it was explicitly noted
that recursive referral will return a parent domain object for
non-existing domains. This was regarded as a feature since it would
return a pointer to the correct registrar with whom to register the
non-existant name and we have seen that it works ;-).
The reason these changes are inter-related is that without recursive
querying TLD administrators will still be obliged to enter one object
for each domain and all these will have the same content: a referral to
the TLD whois server. With recursive querying, only one object is
required and the need for regular redundant updates is eliminated.
So the two changes are tightly inter-related and just switching off
recursive querying will hurt those implementing referral.
How to Proceed
When deciding how to proceed we first had to consider whether the
problems raised by a few users warranted a deviation from the process.
Our conclusion in this case is positive because apparently even some of
those involved in the process did not understand the proposal they
agreed to. But we also do not want to make a fix that hurts those
who have been waiting for this change and are abut to make use of the
new functionality.
So we decided to do a quick and *very* ugly fix: We will leave recursive
querying active. But in the case of finding a parent domain the result
will be determined by the content of the object found: if it is a
referral, the query will be referred as before; if it is a normal
(non-referral) object, the answer will be "no such object" as before the
change. While addressing the problems raised by a few users this will
not hurt those planning to use referral based on recursive querying.
Anyone with half a background in computer science and anyone with a bit
of intelligence will tell us that name scoping dependent on content of
the object named is a bad idea. We agree! This is why this fix will
only be kept up until the next RIPE meeting when the proper process can
determine the permanent soloution. If the database WG can ome to a
conclusive decision before the RIPE meeting we will implement it
earlier. We also do not expect to modify this fix further based
on anything other than a decision based on proper process.
We will also set up a special announcement list via which those not
participating in the policy developemnt process can be notified of
changes.
Kind regards
Daniel Karrenberg
RIPE NCC Manager
-------- Logged at Mon Dec 7 20:08:56 MET 1998 ---------
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
-------- Logged at Wed Dec 9 14:38:43 MET 1998 ---------
From hank at ibm.net.il Wed Dec 9 14:38:16 1998
From: hank at ibm.net.il (Hank Nussbacher)
Date: Wed, 09 Dec 1998 15:38:16 +0200
Subject: FYI: .il Rules change
Message-ID: <2.2.32.19981209133816.00706c50@max.ibm.net.il>
After 18 months of work, the .il ccTLD will be changing its rules as of Jan
1, 1999. To review the new rules, FAQ, ACP fee schedule, etc. see:
http://www.isoc.org.il/domains
Regards,
Hank
-------- Logged at Tue Dec 29 15:45:40 CET 1998 ---------
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
*
-------- Logged at Wed Dec 30 12:06:30 CET 1998 ---------
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
-------- Logged at Wed Dec 30 12:08:06 CET 1998 ---------
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
-------- Logged at Wed Jan 20 18:34:47 CET 1999 ---------