Proposal to remove "referral-by" attribute in "mntner" object or make it optional
Hello, "referral-by" attribute(defined in RFC2725) is mandatory in "mntner" object: [martint@ ~/ripe-db]$ whois -BHrh whois.ripe.net -t mntner | grep referral-by referral-by: [mandatory] [single] [ ] [martint@ ~/ripe-db]$ I checked the db-wg mailing-list archive since January 2000 and only discussion I found regarding this attribute was from Engin Gunduz(former RIPE NCC Senior Software Engineer) in June 2004: [martint@ ~/ripe-db]$ for year in {2000..2014}; do for month in January February March April May June July August September October November December; do wget -q --no-check-certificate https://www.ripe.net/ripe/mail/archives/db-wg/$(printf '%s-%s.txt.gz\n' "$year" "$month"); done; done [martint@ ~/ripe-db]$ zgrep -Hi "referral-by" * 2000-August.txt.gz:-irb (or -ireferral-by) <maintainer name> 2000-August.txt.gz:Returns all objects whose referral-by attribute matches the query 2001-August.txt.gz:referral-by: RIPE-DBM-MNT 2001-May.txt.gz:If you mean referral-by, it points to mntner handle, mandatory in mntner 2003-April.txt.gz:referral-by: RIPE-DBM-MNT 2003-April.txt.gz:referral-by: RIPE-DBM-MNT 2003-August.txt.gz:> referral-by: RIPE-DBM-MNT 2003-December.txt.gz: referral-by: MAINT-RGNET 2003-December.txt.gz: referral-by: MAINT-RGNET 2003-December.txt.gz: referral-by: MAINT-RGNET 2003-December.txt.gz: referral-by: MAINT-RGNET 2003-December.txt.gz: referral-by: MAINT-RGNET 2003-December.txt.gz:> referral-by: MAINT-RGNET 2003-December.txt.gz:> referral-by: MAINT-RGNET 2003-December.txt.gz:> > referral-by: MAINT-RGNET 2003-December.txt.gz:> > referral-by: MAINT-RGNET 2003-July.txt.gz:referral-by: RIPE-DBM-MNT 2004-April.txt.gz:referral-by: RIPE-DBM-MNT 2004-June.txt.gz:referral-by: [mandatory] [single] [inverse key] 2004-June.txt.gz:referral-by: RIPE-DBM-MNT 2004-June.txt.gz:Subject: [db-wg] Proposed Change 2004.2: Removal of "referral-by:" Attribute 2004-June.txt.gz:[2004.2] Removal of "referral-by:" Attribute from the MNTNER Object 2004-June.txt.gz:Remove the "referral-by:" attribute from the MNTNER objects' schema. This 2004-June.txt.gz:The "referral-by:" attribute was introduced into MNTNER objects when the 2004-June.txt.gz:"referral-by:" is defined in RFC2725: 2004-June.txt.gz: referral-by This attribute is required in the maintainer object. It 2004-June.txt.gz: referral-by. An auth-override can only be added to a maintainer 2004-June.txt.gz: those identified by the maintainer in the referral-by have 2004-June.txt.gz: "referral-by" attribute is now mandatory in the "maintainer" object 2004-June.txt.gz: referenced by a "referral-by" attribute elsewhere. 2004-June.txt.gz:The RIPE NCC introduced the "referral-by:" attribute as a place-holder, 2004-May.txt.gz:referral-by: [mandatory] [single] [inverse key] 2005-May.txt.gz:> referral-by: [mandatory] [single] [inverse key] 2005-May.txt.gz:> > referral-by: [mandatory] [single] [inverse key] 2005-November.txt.gz:>referral-by: RIPE-DBM-MNT 2005-November.txt.gz:> >referral-by: RIPE-DBM-MNT 2005-November.txt.gz:> > >referral-by: RIPE-DBM-MNT 2007-July.txt.gz:> referral-by: RIPE-DBM-MNT 2007-July.txt.gz:>> referral-by: RIPE-DBM-MNT 2007-June.txt.gz: referral-by: RIPE-DBM-MNT 2007-June.txt.gz: referral-by: RIPE-DBM-MNT 2007-June.txt.gz:> referral-by: RIPE-DBM-MNT 2007-June.txt.gz:> referral-by: RIPE-DBM-MNT 2012-April.txt.gz:referral-by: DEV-ROOT-MNT 2013-March.txt.gz:referral-by: TRUBNIKOV-MNT 2013-March.txt.gz:> referral-by: TRUBNIKOV-MNT 2013-March.txt.gz:> referral-by: TRUBNIKOV-MNT 2013-March.txt.gz:>> referral-by: TRUBNIKOV-MNT 2013-March.txt.gz:>>> referral-by: TRUBNIKOV-MNT [martint@ ~/ripe-db]$ He also proposed to remove the "referral-by" attribute, but there was no feedback to his e-mail. One can read his e-mail here: https://www.ripe.net/ripe/mail/archives/db-wg/2004-June/002797.html In addition, while RIPE database manual says that "referral-by attribute may never be altered after the addition of the maintainer", one can easily change it at least in current RIPE database version. Is the "referral-by" attribute obsolete? Or is it needed in some specific situation? If not, I propose to remove the "referral-by" attribute in "mntner" object or at least make it optional. WBR, Martin Tonusoo -------------------------- LINXTELECOM www.linxtelecom.com -------------------------- NOC 24/7: +372 622 3300
On Fri, Mar 14, 2014 at 06:19:14PM +0200, Martin Tõnusoo wrote:
"referral-by" attribute(defined in RFC2725) is mandatory in "mntner" object:
[martint@ ~/ripe-db]$ whois -BHrh whois.ripe.net -t mntner | grep referral-by referral-by: [mandatory] [single] [ ] [martint@ ~/ripe-db]$
I checked the db-wg mailing-list archive since January 2000 and only discussion I found regarding this attribute was from Engin Gunduz(former RIPE NCC Senior Software Engineer) in June 2004: <snip>
He also proposed to remove the "referral-by" attribute, but there was no feedback to his e-mail. One can read his e-mail here: https://www.ripe.net/ripe/mail/archives/db-wg/2004-June/002797.html In addition, while RIPE database manual says that "referral-by attribute may never be altered after the addition of the maintainer", one can easily change it at least in current RIPE database version.
Is the "referral-by" attribute obsolete? Or is it needed in some specific situation? If not, I propose to remove the "referral-by" attribute in "mntner" object or at least make it optional.
What is to be gained by removing this attribute (or making it optional)? Currently the attribute is is quite prevalent in the existing database, so outright deletion is out of the question in my honest opinion: princess@worker02:/var/spool/irr_database$ grep -c referral-by ripe.db 46753 princess@worker02:/var/spool/irr_database$ Maybe one of the RIPE database administrators can comment on current "referral-by" usage? What has changed between 2004 and 2014? How are other RIRs using the attribute? If RIPE is to deprecate the attribute, it might be worth writing a small Internet-Draft to update RFC 2725. Kind regards, Job
Dear Job and Martin I am sure this point was also raised by Engin at a RIPE Meeting. But there was no reaction either for or against. The RIPE NCC has proposed a number of such cleanups in the RIPE Database syntax, business rules and data over the years. But unless we get a stamp of approval we cannot move forward with them. A quick history of the "referral-by:". When version 3 of the RIPE Database software was released in 2001 it was not possible for users to create their own MNTNER objects. You had to contact ripe-dbm and ask for one and justify why you needed 'another' MNTNER object. So only the RIPE NCC created MNTNER objects. That is why the documentation said the value of "referral-by:" had to be set to 'ripe-dbm-mnt' and could not be changed. In general RFC2725 defined it as a chain of trust where any existing MNTNER could create another one and be referred from it. At some point the community decided asking ripe-dbm to create new MNTNER objects was over bureaucratic and not necessary. So it was opened up to allow anyone to create a MNTNER object, without any verification, validation or accountability. This is the situation we have now where a MNTNER is an anonymous box holding credentials of unknown and un-identifiable people. These are the people who maintain data in the RIPE Database. There was a cost to removing the bureaucracy. As Engin pointed out, there was never any functionality implemented based on the "referral-by:" attribute. When we allowed anyone to create their own MNTNER we dropped the restriction on the value and changes to the value. The recommendation was to make it self-referencing. This was the easiest way to explain to new users what to put for the value. But it still confuses users today and if the community agrees it would be a good move to deprecate it, this would help a lot of people to understand the database. When we set up AFRINIC's database in 2005, we dropped the "referral-by:" in their implementation of the whois software. As there is no usage or dependency on this attribute at all, we can deprecate it from the syntax and mass update all MNTNER objects to remove it very easily. If you wish to consider updating RFC2725 and RFC2622 (and later versions) bear in mind this is not the only deviation from the RFCs in the RIPE Database implementation. In fact from the start in 2001, the RIPE Database software was never strictly compliant with the RFCs. We used to say it conformed to RIPE RPSL, which was derived from the RFCs. To bring the RFCs into line with practical reality would be quite a task. Especially as the RIPE Database is a routing, reverse delegation and Internet number registry. 'RPSL' was adapted to make it work for all elements of the database. I hope this explains where we are with "referral-by:". If you wish to proceed with changing this, you may wish to take another look at some of the other changes we suggested over the years that also never achieved any consensus. Some of those suggestions are still applicable now and would help to simplify aspects of the database and it's usage. Regards Denis Walker Business Analyst RIPE NCC Database Team On 14/03/2014 18:14, Job Snijders wrote:
On Fri, Mar 14, 2014 at 06:19:14PM +0200, Martin Tõnusoo wrote:
"referral-by" attribute(defined in RFC2725) is mandatory in "mntner" object:
[martint@ ~/ripe-db]$ whois -BHrh whois.ripe.net -t mntner | grep referral-by referral-by: [mandatory] [single] [ ] [martint@ ~/ripe-db]$
I checked the db-wg mailing-list archive since January 2000 and only discussion I found regarding this attribute was from Engin Gunduz(former RIPE NCC Senior Software Engineer) in June 2004: <snip>
He also proposed to remove the "referral-by" attribute, but there was no feedback to his e-mail. One can read his e-mail here: https://www.ripe.net/ripe/mail/archives/db-wg/2004-June/002797.html In addition, while RIPE database manual says that "referral-by attribute may never be altered after the addition of the maintainer", one can easily change it at least in current RIPE database version.
Is the "referral-by" attribute obsolete? Or is it needed in some specific situation? If not, I propose to remove the "referral-by" attribute in "mntner" object or at least make it optional. What is to be gained by removing this attribute (or making it optional)?
Currently the attribute is is quite prevalent in the existing database, so outright deletion is out of the question in my honest opinion:
princess@worker02:/var/spool/irr_database$ grep -c referral-by ripe.db 46753 princess@worker02:/var/spool/irr_database$
Maybe one of the RIPE database administrators can comment on current "referral-by" usage? What has changed between 2004 and 2014?
How are other RIRs using the attribute? If RIPE is to deprecate the attribute, it might be worth writing a small Internet-Draft to update RFC 2725.
Kind regards,
Job
Job and Denis, Thank you very much for your comments and explanations! Just for sake of interest, what does the "stamp of approval" mean in context of RIPE database, i.e. who(and how) needs to approve such proposals? WBR, Martin Tonusoo -------------------------- LINXTELECOM www.linxtelecom.com -------------------------- NOC 24/7: +372 622 3300 ________________________________________ From: Denis Walker [denis@ripe.net] Sent: Sunday, March 16, 2014 9:10 PM To: Job Snijders; Martin Tõnusoo Cc: db-wg@ripe.net Subject: Re: [db-wg] Proposal to remove "referral-by" attribute in "mntner" object or make it optional Dear Job and Martin I am sure this point was also raised by Engin at a RIPE Meeting. But there was no reaction either for or against. The RIPE NCC has proposed a number of such cleanups in the RIPE Database syntax, business rules and data over the years. But unless we get a stamp of approval we cannot move forward with them. A quick history of the "referral-by:". When version 3 of the RIPE Database software was released in 2001 it was not possible for users to create their own MNTNER objects. You had to contact ripe-dbm and ask for one and justify why you needed 'another' MNTNER object. So only the RIPE NCC created MNTNER objects. That is why the documentation said the value of "referral-by:" had to be set to 'ripe-dbm-mnt' and could not be changed. In general RFC2725 defined it as a chain of trust where any existing MNTNER could create another one and be referred from it. At some point the community decided asking ripe-dbm to create new MNTNER objects was over bureaucratic and not necessary. So it was opened up to allow anyone to create a MNTNER object, without any verification, validation or accountability. This is the situation we have now where a MNTNER is an anonymous box holding credentials of unknown and un-identifiable people. These are the people who maintain data in the RIPE Database. There was a cost to removing the bureaucracy. As Engin pointed out, there was never any functionality implemented based on the "referral-by:" attribute. When we allowed anyone to create their own MNTNER we dropped the restriction on the value and changes to the value. The recommendation was to make it self-referencing. This was the easiest way to explain to new users what to put for the value. But it still confuses users today and if the community agrees it would be a good move to deprecate it, this would help a lot of people to understand the database. When we set up AFRINIC's database in 2005, we dropped the "referral-by:" in their implementation of the whois software. As there is no usage or dependency on this attribute at all, we can deprecate it from the syntax and mass update all MNTNER objects to remove it very easily. If you wish to consider updating RFC2725 and RFC2622 (and later versions) bear in mind this is not the only deviation from the RFCs in the RIPE Database implementation. In fact from the start in 2001, the RIPE Database software was never strictly compliant with the RFCs. We used to say it conformed to RIPE RPSL, which was derived from the RFCs. To bring the RFCs into line with practical reality would be quite a task. Especially as the RIPE Database is a routing, reverse delegation and Internet number registry. 'RPSL' was adapted to make it work for all elements of the database. I hope this explains where we are with "referral-by:". If you wish to proceed with changing this, you may wish to take another look at some of the other changes we suggested over the years that also never achieved any consensus. Some of those suggestions are still applicable now and would help to simplify aspects of the database and it's usage. Regards Denis Walker Business Analyst RIPE NCC Database Team On 14/03/2014 18:14, Job Snijders wrote:
On Fri, Mar 14, 2014 at 06:19:14PM +0200, Martin Tõnusoo wrote:
"referral-by" attribute(defined in RFC2725) is mandatory in "mntner" object:
[martint@ ~/ripe-db]$ whois -BHrh whois.ripe.net -t mntner | grep referral-by referral-by: [mandatory] [single] [ ] [martint@ ~/ripe-db]$
I checked the db-wg mailing-list archive since January 2000 and only discussion I found regarding this attribute was from Engin Gunduz(former RIPE NCC Senior Software Engineer) in June 2004: <snip>
He also proposed to remove the "referral-by" attribute, but there was no feedback to his e-mail. One can read his e-mail here: https://www.ripe.net/ripe/mail/archives/db-wg/2004-June/002797.html In addition, while RIPE database manual says that "referral-by attribute may never be altered after the addition of the maintainer", one can easily change it at least in current RIPE database version.
Is the "referral-by" attribute obsolete? Or is it needed in some specific situation? If not, I propose to remove the "referral-by" attribute in "mntner" object or at least make it optional. What is to be gained by removing this attribute (or making it optional)?
Currently the attribute is is quite prevalent in the existing database, so outright deletion is out of the question in my honest opinion:
princess@worker02:/var/spool/irr_database$ grep -c referral-by ripe.db 46753 princess@worker02:/var/spool/irr_database$
Maybe one of the RIPE database administrators can comment on current "referral-by" usage? What has changed between 2004 and 2014?
How are other RIRs using the attribute? If RIPE is to deprecate the attribute, it might be worth writing a small Internet-Draft to update RFC 2725.
Kind regards,
Job
Hi Martin Historically, technical changes like this to the RIPE Database, that are not considered to affect any existing policy or require a new policy (at the discretion of the WG chairs), have been discussed on the DB WG mailing list or at the DB session at a RIPE Meeting. If the DB WG chairs agree that a consensus is reached by the community as a result of these discussions the WG chairs can approve the RIPE NCC taking the action. Regards Denis Walker Business Analyst RIPE NCC Database Team On 17/03/2014 12:37, Martin Tõnusoo wrote:
Job and Denis,
Thank you very much for your comments and explanations! Just for sake of interest, what does the "stamp of approval" mean in context of RIPE database, i.e. who(and how) needs to approve such proposals?
WBR, Martin Tonusoo -------------------------- LINXTELECOM www.linxtelecom.com -------------------------- NOC 24/7: +372 622 3300
________________________________________ From: Denis Walker [denis@ripe.net] Sent: Sunday, March 16, 2014 9:10 PM To: Job Snijders; Martin Tõnusoo Cc: db-wg@ripe.net Subject: Re: [db-wg] Proposal to remove "referral-by" attribute in "mntner" object or make it optional
Dear Job and Martin
I am sure this point was also raised by Engin at a RIPE Meeting. But there was no reaction either for or against. The RIPE NCC has proposed a number of such cleanups in the RIPE Database syntax, business rules and data over the years. But unless we get a stamp of approval we cannot move forward with them.
A quick history of the "referral-by:". When version 3 of the RIPE Database software was released in 2001 it was not possible for users to create their own MNTNER objects. You had to contact ripe-dbm and ask for one and justify why you needed 'another' MNTNER object. So only the RIPE NCC created MNTNER objects. That is why the documentation said the value of "referral-by:" had to be set to 'ripe-dbm-mnt' and could not be changed. In general RFC2725 defined it as a chain of trust where any existing MNTNER could create another one and be referred from it.
At some point the community decided asking ripe-dbm to create new MNTNER objects was over bureaucratic and not necessary. So it was opened up to allow anyone to create a MNTNER object, without any verification, validation or accountability. This is the situation we have now where a MNTNER is an anonymous box holding credentials of unknown and un-identifiable people. These are the people who maintain data in the RIPE Database. There was a cost to removing the bureaucracy.
As Engin pointed out, there was never any functionality implemented based on the "referral-by:" attribute. When we allowed anyone to create their own MNTNER we dropped the restriction on the value and changes to the value. The recommendation was to make it self-referencing. This was the easiest way to explain to new users what to put for the value. But it still confuses users today and if the community agrees it would be a good move to deprecate it, this would help a lot of people to understand the database.
When we set up AFRINIC's database in 2005, we dropped the "referral-by:" in their implementation of the whois software.
As there is no usage or dependency on this attribute at all, we can deprecate it from the syntax and mass update all MNTNER objects to remove it very easily.
If you wish to consider updating RFC2725 and RFC2622 (and later versions) bear in mind this is not the only deviation from the RFCs in the RIPE Database implementation. In fact from the start in 2001, the RIPE Database software was never strictly compliant with the RFCs. We used to say it conformed to RIPE RPSL, which was derived from the RFCs. To bring the RFCs into line with practical reality would be quite a task. Especially as the RIPE Database is a routing, reverse delegation and Internet number registry. 'RPSL' was adapted to make it work for all elements of the database.
I hope this explains where we are with "referral-by:". If you wish to proceed with changing this, you may wish to take another look at some of the other changes we suggested over the years that also never achieved any consensus. Some of those suggestions are still applicable now and would help to simplify aspects of the database and it's usage.
Regards Denis Walker Business Analyst RIPE NCC Database Team
On 14/03/2014 18:14, Job Snijders wrote:
On Fri, Mar 14, 2014 at 06:19:14PM +0200, Martin Tõnusoo wrote:
"referral-by" attribute(defined in RFC2725) is mandatory in "mntner" object:
[martint@ ~/ripe-db]$ whois -BHrh whois.ripe.net -t mntner | grep referral-by referral-by: [mandatory] [single] [ ] [martint@ ~/ripe-db]$
I checked the db-wg mailing-list archive since January 2000 and only discussion I found regarding this attribute was from Engin Gunduz(former RIPE NCC Senior Software Engineer) in June 2004: <snip>
He also proposed to remove the "referral-by" attribute, but there was no feedback to his e-mail. One can read his e-mail here: https://www.ripe.net/ripe/mail/archives/db-wg/2004-June/002797.html In addition, while RIPE database manual says that "referral-by attribute may never be altered after the addition of the maintainer", one can easily change it at least in current RIPE database version.
Is the "referral-by" attribute obsolete? Or is it needed in some specific situation? If not, I propose to remove the "referral-by" attribute in "mntner" object or at least make it optional. What is to be gained by removing this attribute (or making it optional)?
Currently the attribute is is quite prevalent in the existing database, so outright deletion is out of the question in my honest opinion:
princess@worker02:/var/spool/irr_database$ grep -c referral-by ripe.db 46753 princess@worker02:/var/spool/irr_database$
Maybe one of the RIPE database administrators can comment on current "referral-by" usage? What has changed between 2004 and 2014?
How are other RIRs using the attribute? If RIPE is to deprecate the attribute, it might be worth writing a small Internet-Draft to update RFC 2725.
Kind regards,
Job
Discussion on the db-wg mailing list has sometimes been difficult to kick start. As Denis says, we then tend to bring it up at the DB WG meeting at RIPE and raise an action on the RIPE NCC based on the discussion at that meeting. Nigel -----Original Message----- From: db-wg-bounces@ripe.net [mailto:db-wg-bounces@ripe.net] On Behalf Of Denis Walker Sent: 17 March 2014 12:24 To: Martin Tõnusoo; Job Snijders Cc: db-wg@ripe.net Subject: Re: [db-wg] Proposal to remove "referral-by" attribute in "mntner" object or make it optional Hi Martin Historically, technical changes like this to the RIPE Database, that are not considered to affect any existing policy or require a new policy (at the discretion of the WG chairs), have been discussed on the DB WG mailing list or at the DB session at a RIPE Meeting. If the DB WG chairs agree that a consensus is reached by the community as a result of these discussions the WG chairs can approve the RIPE NCC taking the action. Regards Denis Walker Business Analyst RIPE NCC Database Team On 17/03/2014 12:37, Martin Tõnusoo wrote:
Job and Denis,
Thank you very much for your comments and explanations! Just for sake of interest, what does the "stamp of approval" mean in context of RIPE database, i.e. who(and how) needs to approve such proposals?
WBR, Martin Tonusoo -------------------------- LINXTELECOM www.linxtelecom.com -------------------------- NOC 24/7: +372 622 3300
________________________________________ From: Denis Walker [denis@ripe.net] Sent: Sunday, March 16, 2014 9:10 PM To: Job Snijders; Martin Tõnusoo Cc: db-wg@ripe.net Subject: Re: [db-wg] Proposal to remove "referral-by" attribute in "mntner" object or make it optional
Dear Job and Martin
I am sure this point was also raised by Engin at a RIPE Meeting. But there was no reaction either for or against. The RIPE NCC has proposed a number of such cleanups in the RIPE Database syntax, business rules and data over the years. But unless we get a stamp of approval we cannot move forward with them.
A quick history of the "referral-by:". When version 3 of the RIPE Database software was released in 2001 it was not possible for users to create their own MNTNER objects. You had to contact ripe-dbm and ask for one and justify why you needed 'another' MNTNER object. So only the RIPE NCC created MNTNER objects. That is why the documentation said the value of "referral-by:" had to be set to 'ripe-dbm-mnt' and could not be changed. In general RFC2725 defined it as a chain of trust where any existing MNTNER could create another one and be referred from it.
At some point the community decided asking ripe-dbm to create new MNTNER objects was over bureaucratic and not necessary. So it was opened up to allow anyone to create a MNTNER object, without any verification, validation or accountability. This is the situation we have now where a MNTNER is an anonymous box holding credentials of unknown and un-identifiable people. These are the people who maintain data in the RIPE Database. There was a cost to removing the bureaucracy.
As Engin pointed out, there was never any functionality implemented based on the "referral-by:" attribute. When we allowed anyone to create their own MNTNER we dropped the restriction on the value and changes to the value. The recommendation was to make it self-referencing. This was the easiest way to explain to new users what to put for the value. But it still confuses users today and if the community agrees it would be a good move to deprecate it, this would help a lot of people to understand the database.
When we set up AFRINIC's database in 2005, we dropped the "referral-by:" in their implementation of the whois software.
As there is no usage or dependency on this attribute at all, we can deprecate it from the syntax and mass update all MNTNER objects to remove it very easily.
If you wish to consider updating RFC2725 and RFC2622 (and later versions) bear in mind this is not the only deviation from the RFCs in the RIPE Database implementation. In fact from the start in 2001, the RIPE Database software was never strictly compliant with the RFCs. We used to say it conformed to RIPE RPSL, which was derived from the RFCs. To bring the RFCs into line with practical reality would be quite a task. Especially as the RIPE Database is a routing, reverse delegation and Internet number registry. 'RPSL' was adapted to make it work for all elements of the database.
I hope this explains where we are with "referral-by:". If you wish to proceed with changing this, you may wish to take another look at some of the other changes we suggested over the years that also never achieved any consensus. Some of those suggestions are still applicable now and would help to simplify aspects of the database and it's usage.
Regards Denis Walker Business Analyst RIPE NCC Database Team
On 14/03/2014 18:14, Job Snijders wrote:
On Fri, Mar 14, 2014 at 06:19:14PM +0200, Martin Tõnusoo wrote:
"referral-by" attribute(defined in RFC2725) is mandatory in "mntner" object:
[martint@ ~/ripe-db]$ whois -BHrh whois.ripe.net -t mntner | grep referral-by referral-by: [mandatory] [single] [ ] [martint@ ~/ripe-db]$
I checked the db-wg mailing-list archive since January 2000 and only discussion I found regarding this attribute was from Engin Gunduz(former RIPE NCC Senior Software Engineer) in June 2004: <snip>
He also proposed to remove the "referral-by" attribute, but there was no feedback to his e-mail. One can read his e-mail here: https://www.ripe.net/ripe/mail/archives/db-wg/2004-June/002797.html In addition, while RIPE database manual says that "referral-by attribute may never be altered after the addition of the maintainer", one can easily change it at least in current RIPE database version.
Is the "referral-by" attribute obsolete? Or is it needed in some specific situation? If not, I propose to remove the "referral-by" attribute in "mntner" object or at least make it optional. What is to be gained by removing this attribute (or making it optional)?
Currently the attribute is is quite prevalent in the existing database, so outright deletion is out of the question in my honest opinion:
princess@worker02:/var/spool/irr_database$ grep -c referral-by ripe.db 46753 princess@worker02:/var/spool/irr_database$
Maybe one of the RIPE database administrators can comment on current "referral-by" usage? What has changed between 2004 and 2014?
How are other RIRs using the attribute? If RIPE is to deprecate the attribute, it might be worth writing a small Internet-Draft to update RFC 2725.
Kind regards,
Job
Dear Nigel, On Mon, Mar 17, 2014 at 03:30:36PM +0000, Nigel Titley wrote:
Discussion on the db-wg mailing list has sometimes been difficult to kick start. As Denis says, we then tend to bring it up at the DB WG meeting at RIPE and raise an action on the RIPE NCC based on the discussion at that meeting.
I personally see no difference between online (db-wg@) and offline (RIPE[0-9]+), and little value in regarding RIPE meetings as a "flag day" of sorts. I'd want to avoid a loop from mailing-list to meeting back to mailing-list due to community indecisiveness. :-) We can ask the RIPE NCC communications department to help engage our community in conversations on this mailing-list. Maybe they can do a tweet "Spring clean-up: Do you like or dislike the 'referral-by' attribute? Have you ever used it? Voice your opinion on db-wg@ripe.net!". Already 6 people are involved, and importantly: with quite unanimous sentiment. Why would we not try to reach consensus in the next four weeks? Kind regards, Job
We certainly could on this one, where we've got some engagement with the community. My comment was a reply to Martin's question, way back in this thread, about what do we do when we get no engagement from the community. Nigel -----Original Message----- From: Job Snijders [mailto:job.snijders@hibernianetworks.com] Sent: 17 March 2014 17:13 To: Nigel Titley Cc: Denis Walker; Martin Tõnusoo; db-wg@ripe.net Subject: Re: [db-wg] Proposal to remove "referral-by" attribute in "mntner" object or make it optional Dear Nigel, On Mon, Mar 17, 2014 at 03:30:36PM +0000, Nigel Titley wrote:
Discussion on the db-wg mailing list has sometimes been difficult to kick start. As Denis says, we then tend to bring it up at the DB WG meeting at RIPE and raise an action on the RIPE NCC based on the discussion at that meeting.
I personally see no difference between online (db-wg@) and offline (RIPE[0-9]+), and little value in regarding RIPE meetings as a "flag day" of sorts. I'd want to avoid a loop from mailing-list to meeting back to mailing-list due to community indecisiveness. :-) We can ask the RIPE NCC communications department to help engage our community in conversations on this mailing-list. Maybe they can do a tweet "Spring clean-up: Do you like or dislike the 'referral-by' attribute? Have you ever used it? Voice your opinion on db-wg@ripe.net!". Already 6 people are involved, and importantly: with quite unanimous sentiment. Why would we not try to reach consensus in the next four weeks? Kind regards, Job
On Mon, Mar 17, 2014 at 01:24:02PM +0100, Denis Walker wrote:
Historically, technical changes like this to the RIPE Database, that are not considered to affect any existing policy or require a new policy (at the discretion of the WG chairs), have been discussed on the DB WG mailing list or at the DB session at a RIPE Meeting. If the DB WG chairs agree that a consensus is reached by the community as a result of these discussions the WG chairs can approve the RIPE NCC taking the action.
Based on the feedback from this group it seems a good idea start dialogue about phasing out "referral-by" in one way or another. So far we have not heard anything positive about referral-by and no statements supporting its continued existance, I personally would not mind getting rid of this attribute. DB-WG (and RIPE DB Staff), what, in your vision is the least destructive way is to deprecate a mandatory attribute? I've compiled some things that came to mind, between each step a pause of sorts can be applied. phase 0) reach consensus in some way (our process now) phase 1) Change status from mandatory to optional, no errors are thrown in any scenario, whether MNTER objects contain the referral-by attribute or not. phase 2) Have API/Mailrobot/etc throw soft warning (but accept data) when attribute is present when updating an existing MNTER object. phase 3) Omit the attribute when presenting data to whois/api clients and omit the attribute in the webupdates interface. phase 4) Deny creation of _new_ MNTER objects containing a referral-by attribute: throw hard error. phase 5) Deny updating of _existing_ MNTER objects with a referral-by attribute: throw hard error. phase 6) delete all referral-by attributes from database (However, still show the attribute when clients request old versions with 'diff'). Thoughts? Kind regards, Job -
Denis I think your proposal is good and cautious (perhaps over-cautious, but experience has taught us that cautious is good). There should definitely be roll out on the sandbox systems at each stage to allow testing in advance. Folk use the DB for strange things and in strange ways. Nigel -----Original Message----- From: db-wg-bounces@ripe.net [mailto:db-wg-bounces@ripe.net] On Behalf Of Job Snijders Sent: 17 March 2014 15:53 To: Denis Walker Cc: db-wg@ripe.net Subject: Re: [db-wg] Proposal to remove "referral-by" attribute in "mntner" object or make it optional On Mon, Mar 17, 2014 at 01:24:02PM +0100, Denis Walker wrote:
Historically, technical changes like this to the RIPE Database, that are not considered to affect any existing policy or require a new policy (at the discretion of the WG chairs), have been discussed on the DB WG mailing list or at the DB session at a RIPE Meeting. If the DB WG chairs agree that a consensus is reached by the community as a result of these discussions the WG chairs can approve the RIPE NCC taking the action.
Based on the feedback from this group it seems a good idea start dialogue about phasing out "referral-by" in one way or another. So far we have not heard anything positive about referral-by and no statements supporting its continued existance, I personally would not mind getting rid of this attribute. DB-WG (and RIPE DB Staff), what, in your vision is the least destructive way is to deprecate a mandatory attribute? I've compiled some things that came to mind, between each step a pause of sorts can be applied. phase 0) reach consensus in some way (our process now) phase 1) Change status from mandatory to optional, no errors are thrown in any scenario, whether MNTER objects contain the referral-by attribute or not. phase 2) Have API/Mailrobot/etc throw soft warning (but accept data) when attribute is present when updating an existing MNTER object. phase 3) Omit the attribute when presenting data to whois/api clients and omit the attribute in the webupdates interface. phase 4) Deny creation of _new_ MNTER objects containing a referral-by attribute: throw hard error. phase 5) Deny updating of _existing_ MNTER objects with a referral-by attribute: throw hard error. phase 6) delete all referral-by attributes from database (However, still show the attribute when clients request old versions with 'diff'). Thoughts? Kind regards, Job -
Dear Nigel, Job and others I think this may be a bit over cautious for this object type. The MNTNER object is not created, update or queried as often as operational data. And it is one of the least likely objects to be subject to automated scripts creating or querying & fully parsing it. Because of the hidden password hash, most MNTNER objects can only be fully accessed by an authenticated lookup in Webupdates. This takes care of issues surrounding a missing, previously mandatory, attribute. So for this object maybe we can: -drop referral-by to an optional attribute with warning if used. Of course it will follow our now standard deployment process. -send the reminders to the DB WG after 1 and 2 months -deprecate the attribute fully after 2 months Regards Denis Walker Business Analyst RIPE NCC Database Team On 17/03/2014 17:17, Nigel Titley wrote:
Denis
I think your proposal is good and cautious (perhaps over-cautious, but experience has taught us that cautious is good). There should definitely be roll out on the sandbox systems at each stage to allow testing in advance. Folk use the DB for strange things and in strange ways.
Nigel
-----Original Message----- From: db-wg-bounces@ripe.net [mailto:db-wg-bounces@ripe.net] On Behalf Of Job Snijders Sent: 17 March 2014 15:53 To: Denis Walker Cc: db-wg@ripe.net Subject: Re: [db-wg] Proposal to remove "referral-by" attribute in "mntner" object or make it optional
On Mon, Mar 17, 2014 at 01:24:02PM +0100, Denis Walker wrote:
Historically, technical changes like this to the RIPE Database, that are not considered to affect any existing policy or require a new policy (at the discretion of the WG chairs), have been discussed on the DB WG mailing list or at the DB session at a RIPE Meeting. If the DB WG chairs agree that a consensus is reached by the community as a result of these discussions the WG chairs can approve the RIPE NCC taking the action. Based on the feedback from this group it seems a good idea start dialogue about phasing out "referral-by" in one way or another. So far we have not heard anything positive about referral-by and no statements supporting its continued existance, I personally would not mind getting rid of this attribute.
DB-WG (and RIPE DB Staff), what, in your vision is the least destructive way is to deprecate a mandatory attribute? I've compiled some things that came to mind, between each step a pause of sorts can be applied.
phase 0) reach consensus in some way (our process now)
phase 1) Change status from mandatory to optional, no errors are thrown in any scenario, whether MNTER objects contain the referral-by attribute or not.
phase 2) Have API/Mailrobot/etc throw soft warning (but accept data) when attribute is present when updating an existing MNTER object.
phase 3) Omit the attribute when presenting data to whois/api clients and omit the attribute in the webupdates interface.
phase 4) Deny creation of _new_ MNTER objects containing a referral-by attribute: throw hard error.
phase 5) Deny updating of _existing_ MNTER objects with a referral-by attribute: throw hard error.
phase 6) delete all referral-by attributes from database (However, still show the attribute when clients request old versions with 'diff').
Thoughts?
Kind regards,
Job
-
On Mon, Mar 17, 2014 at 05:51:49PM +0100, Denis Walker wrote:
I think this may be a bit over cautious for this object type.
When none of the other participants in this thread have objections to a 'fast phase-out', I will not persue a more cautious approach for this attribute. :-)
The MNTNER object is not created, update or queried as often as operational data. And it is one of the least likely objects to be subject to automated scripts creating or querying & fully parsing it. Because of the hidden password hash, most MNTNER objects can only be fully accessed by an authenticated lookup in Webupdates. This takes care of issues surrounding a missing, previously mandatory, attribute.
I agree.
So for this object maybe we can:
-drop referral-by to an optional attribute with warning if used. Of course it will follow our now standard deployment process. -send the reminders to the DB WG after 1 and 2 months -deprecate the attribute fully after 2 months
Would it be possible to monitor the amount of creations/updates to MNTER objects which contain a 'referral-by' attribute from the moment the attribute becomes optional and generates soft warning? Kind regards, Job
On Tue, Mar 18, 2014 at 12:46:14PM +0100, Job Snijders wrote:
I think this may be a bit over cautious for this object type.
When none of the other participants in this thread have objections to a 'fast phase-out', I will not persue a more cautious approach for this attribute. :-)
Although I'm quite happy to move forward with this case without any unnecessary steps/hassle, I would like to avoid such discussions like this one from last year about urgent release of RIPE DB software. And yes - this is over cautious from my side. ;-)
The MNTNER object is not created, update or queried as often as operational data. And it is one of the least likely objects to be subject to automated scripts creating or querying & fully parsing it. Because of the hidden password hash, most MNTNER objects can only be fully accessed by an authenticated lookup in Webupdates. This takes care of issues surrounding a missing, previously mandatory, attribute.
I agree.
So for this object maybe we can:
-drop referral-by to an optional attribute with warning if used. Of course it will follow our now standard deployment process. -send the reminders to the DB WG after 1 and 2 months -deprecate the attribute fully after 2 months
Would it be possible to monitor the amount of creations/updates to MNTER objects which contain a 'referral-by' attribute from the moment the attribute becomes optional and generates soft warning?
Good idea. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Hi All Lets be clear that there are two very separate issues here: -making a change to functionality -deploying new software including any change For the second issue, we will follow our now accepted deployment process. If the change is made in several steps, each step is a change to the software and will be deployed according to the accepted process. There is not much point monitoring updates to MNTNER objects with a "referral-by:" during the transition phase as most updates are done with Webupdates. This will not include "referral-by:" in the template and will not allow it to be added. So unless they do an update in text area mode and manually add a "referral-by:" there will not be any. Regards Denis Walker Business Analyst RIPE NCC Database Team On 18/03/2014 14:24, Piotr Strzyzewski wrote:
I think this may be a bit over cautious for this object type. When none of the other participants in this thread have objections to a 'fast phase-out', I will not persue a more cautious approach for this attribute. :-) Although I'm quite happy to move forward with this case without any unnecessary steps/hassle, I would like to avoid such discussions like
On Tue, Mar 18, 2014 at 12:46:14PM +0100, Job Snijders wrote: this one from last year about urgent release of RIPE DB software.
And yes - this is over cautious from my side. ;-)
The MNTNER object is not created, update or queried as often as operational data. And it is one of the least likely objects to be subject to automated scripts creating or querying & fully parsing it. Because of the hidden password hash, most MNTNER objects can only be fully accessed by an authenticated lookup in Webupdates. This takes care of issues surrounding a missing, previously mandatory, attribute. I agree.
So for this object maybe we can:
-drop referral-by to an optional attribute with warning if used. Of course it will follow our now standard deployment process. -send the reminders to the DB WG after 1 and 2 months -deprecate the attribute fully after 2 months Would it be possible to monitor the amount of creations/updates to MNTER objects which contain a 'referral-by' attribute from the moment the attribute becomes optional and generates soft warning? Good idea.
Piotr
On Tue, Mar 18, 2014 at 04:35:39PM +0100, Denis Walker wrote:
-deploying new software including any change
There is not much point monitoring updates to MNTNER objects with a "referral-by:" during the transition phase as most updates are done with Webupdates. This will not include "referral-by:" in the template and will not allow it to be added. So unless they do an update in text area mode and manually add a "referral-by:" there will not be any.
If the MNTER object truely has such a low churn in terms of automated modifications & creation, it does make sense to skip over some of the steps in my initial layout. -------------- <insert period of time> phase 1) Make the 'referral-by' attribute optional, and throw a warning when somebody modifies a MNTER object which retains the atttribute after the update. In the webupdates interface hide the attribute. When new MNTER objects are created throw an error when the 'referral-by' is present and deny the update. <insert period of time> phase 2) Deprecate the attribute: Do not allow any updates containing the 'referral-by' attribute, thrown an error 'this attribute is deprecated'. <insert period of time> Phase 3a) From all existing MNTER objects in the RIPE Database, with source: RIPE, delete the referral-by attribute Phase 3b) but still show the attribute when client requests old versions with the 'diff' command. -------------- I've included phase 3b because part of me does not want to modify the past, however I do not oversee the consequences from a data manageability perspective, and could live with deleting the attribute from present & past. Kind regards, Job
First of all, thanks to Martin for bringing this up (again) and to Denis for explaining the history and the current situation. Denis Walker wrote:
Hi All
Lets be clear that there are two very separate issues here:
Indeed :-)
-making a change to functionality
I guess this is an easy one, as there is no real (i.e. operational) need to have this attribute. As it was stated already, the governing RFCs are mostly outdated by now, and some of the architectural aspects in the set have never been implemented. But this maybe another aspect for this list of items, like: - have a look at the RFCs and bring the set in line with reality, and/or re-label as historic (mandate for a TF??)
-deploying new software including any change
Yes, and for this one I have two thoughts in my mind - ° in the interest of not making this too lengthy, boring and complex, we may want to limit the number of phases to the bare minimum! ° from a consistency point of view, I don't like the idea of "hiding" attributes which are present in an object, by a particular interface for updates. I think this would be a bad habit and can cause major confusion for people who (locally) keep an "authoritative" copy of an object; or use a diferent path for updates. With that in mind I would - roughly - propose to 1) agree to deprecate the attribute, 2) make that widely known (on the DB list and probably on the Services list), then 3) bounce (soft/hard?) all update requests including that attribute, and 4) eventually remove the attribute from all objects in a bulk operation. 5) Done :-) I think we have used such an approach already. And to explicitly state the obvious, I am also in favour of getting rid of that beast :-) Regrads, Wilfried
For the second issue, we will follow our now accepted deployment process. If the change is made in several steps, each step is a change to the software and will be deployed according to the accepted process.
There is not much point monitoring updates to MNTNER objects with a "referral-by:" during the transition phase as most updates are done with Webupdates. This will not include "referral-by:" in the template and will not allow it to be added. So unless they do an update in text area mode and manually add a "referral-by:" there will not be any.
Regards Denis Walker Business Analyst RIPE NCC Database Team
Hi everyone, I agree with the deprecation of 'referral-by:' and it's removal from the RIPE Database. Kind regards, Elvis On 16/03/14 20:10, Denis Walker wrote:
Dear Job and Martin
I am sure this point was also raised by Engin at a RIPE Meeting. But there was no reaction either for or against. The RIPE NCC has proposed a number of such cleanups in the RIPE Database syntax, business rules and data over the years. But unless we get a stamp of approval we cannot move forward with them.
A quick history of the "referral-by:". When version 3 of the RIPE Database software was released in 2001 it was not possible for users to create their own MNTNER objects. You had to contact ripe-dbm and ask for one and justify why you needed 'another' MNTNER object. So only the RIPE NCC created MNTNER objects. That is why the documentation said the value of "referral-by:" had to be set to 'ripe-dbm-mnt' and could not be changed. In general RFC2725 defined it as a chain of trust where any existing MNTNER could create another one and be referred from it.
At some point the community decided asking ripe-dbm to create new MNTNER objects was over bureaucratic and not necessary. So it was opened up to allow anyone to create a MNTNER object, without any verification, validation or accountability. This is the situation we have now where a MNTNER is an anonymous box holding credentials of unknown and un-identifiable people. These are the people who maintain data in the RIPE Database. There was a cost to removing the bureaucracy.
As Engin pointed out, there was never any functionality implemented based on the "referral-by:" attribute. When we allowed anyone to create their own MNTNER we dropped the restriction on the value and changes to the value. The recommendation was to make it self-referencing. This was the easiest way to explain to new users what to put for the value. But it still confuses users today and if the community agrees it would be a good move to deprecate it, this would help a lot of people to understand the database.
When we set up AFRINIC's database in 2005, we dropped the "referral-by:" in their implementation of the whois software.
As there is no usage or dependency on this attribute at all, we can deprecate it from the syntax and mass update all MNTNER objects to remove it very easily.
If you wish to consider updating RFC2725 and RFC2622 (and later versions) bear in mind this is not the only deviation from the RFCs in the RIPE Database implementation. In fact from the start in 2001, the RIPE Database software was never strictly compliant with the RFCs. We used to say it conformed to RIPE RPSL, which was derived from the RFCs. To bring the RFCs into line with practical reality would be quite a task. Especially as the RIPE Database is a routing, reverse delegation and Internet number registry. 'RPSL' was adapted to make it work for all elements of the database.
I hope this explains where we are with "referral-by:". If you wish to proceed with changing this, you may wish to take another look at some of the other changes we suggested over the years that also never achieved any consensus. Some of those suggestions are still applicable now and would help to simplify aspects of the database and it's usage.
Regards Denis Walker Business Analyst RIPE NCC Database Team
On 14/03/2014 18:14, Job Snijders wrote:
On Fri, Mar 14, 2014 at 06:19:14PM +0200, Martin Tõnusoo wrote:
"referral-by" attribute(defined in RFC2725) is mandatory in "mntner" object:
[martint@ ~/ripe-db]$ whois -BHrh whois.ripe.net -t mntner | grep referral-by referral-by: [mandatory] [single] [ ] [martint@ ~/ripe-db]$
I checked the db-wg mailing-list archive since January 2000 and only discussion I found regarding this attribute was from Engin Gunduz(former RIPE NCC Senior Software Engineer) in June 2004: <snip>
He also proposed to remove the "referral-by" attribute, but there was no feedback to his e-mail. One can read his e-mail here: https://www.ripe.net/ripe/mail/archives/db-wg/2004-June/002797.html In addition, while RIPE database manual says that "referral-by attribute may never be altered after the addition of the maintainer", one can easily change it at least in current RIPE database version.
Is the "referral-by" attribute obsolete? Or is it needed in some specific situation? If not, I propose to remove the "referral-by" attribute in "mntner" object or at least make it optional. What is to be gained by removing this attribute (or making it optional)?
Currently the attribute is is quite prevalent in the existing database, so outright deletion is out of the question in my honest opinion:
princess@worker02:/var/spool/irr_database$ grep -c referral-by ripe.db 46753 princess@worker02:/var/spool/irr_database$
Maybe one of the RIPE database administrators can comment on current "referral-by" usage? What has changed between 2004 and 2014?
How are other RIRs using the attribute? If RIPE is to deprecate the attribute, it might be worth writing a small Internet-Draft to update RFC 2725.
Kind regards,
Job
On Mon, Mar 17, 2014 at 12:48:44PM +0100, Elvis Velea wrote: Dear All
I agree with the deprecation of 'referral-by:' and it's removal from the RIPE Database.
+1 However, this have to be (as always) carefully done and announced well in advance. I assume that there are some systems which rely on objects syntax. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Dear Piotr As this has never been agreed can we determine what is considered to be 'announced well in advance'? Would you consider this condition satisfied if: -it is announced on the DB WG mailing list when consensus for a change has been reached -a reminder is sent to the DB WG mailing list after 1 month -a final reminder is sent to the DB WG mailing list 1 week before the (minimum) 2 month boundary when the change is completed -during this time, if the change can be made in a non fatalistic way, it may be implemented earlier by non fatalistic I mean in this example we can deprecate the "referral-by:" attribute, but when any update to a MNTNER object is received containing this attribute the software strips it out and adds a warning message, but does not fail the update. The announcement period would be a minimum of 2 months. If it is a complex change requiring significant engineering effort to be scheduled it may take more time. In this case the timing of the announcements may be adjusted. If the change affects other working groups, say for example syntax of a routing or dns related object, other appropriate working group mailing lists will be CC'ed. Regards Denis Walker Business Analyst RIPE NCC Database Team On 17/03/2014 14:01, Piotr Strzyzewski wrote:
On Mon, Mar 17, 2014 at 12:48:44PM +0100, Elvis Velea wrote:
Dear All
I agree with the deprecation of 'referral-by:' and it's removal from the RIPE Database. +1
However, this have to be (as always) carefully done and announced well in advance. I assume that there are some systems which rely on objects syntax.
Piotr
On Mon, Mar 17, 2014 at 02:40:35PM +0100, Denis Walker wrote: Dear Denis
As this has never been agreed can we determine what is considered to be 'announced well in advance'? Would you consider this condition satisfied if:
As this is not a surprise, I'm not the only one here. ;-) I do prefer some kind of discussion about that and either agreed consensus or (if the consensus could not be reached) the decision made by WG Chairs.
-it is announced on the DB WG mailing list when consensus for a change has been reached -a reminder is sent to the DB WG mailing list after 1 month -a final reminder is sent to the DB WG mailing list 1 week before the (minimum) 2 month boundary when the change is completed -during this time, if the change can be made in a non fatalistic way, it may be implemented earlier
by non fatalistic I mean in this example we can deprecate the "referral-by:" attribute, but when any update to a MNTNER object is received containing this attribute the software strips it out and adds a warning message, but does not fail the update.
I can imagine that there is some kind of software which query DB after successful update (with or without warning) just to update some internal state. In this scenario, this could fail since this software could expect different object schema then this one which it received.
The announcement period would be a minimum of 2 months. If it is a complex change requiring significant engineering effort to be scheduled it may take more time. In this case the timing of the announcements may be adjusted.
If the change affects other working groups, say for example syntax of a routing or dns related object, other appropriate working group mailing lists will be CC'ed.
All this seems very reasonable to me (including proposed time boundaries). Hope there will be some discussion or at least some votes for/against there. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
+1 On Mon, 17 Mar 2014, Elvis Velea wrote:
Hi everyone,
I agree with the deprecation of 'referral-by:' and it's removal from the RIPE Database.
Kind regards, Elvis
On 16/03/14 20:10, Denis Walker wrote:
Dear Job and Martin
I am sure this point was also raised by Engin at a RIPE Meeting. But there was no reaction either for or against. The RIPE NCC has proposed a number of such cleanups in the RIPE Database syntax, business rules and data over the years. But unless we get a stamp of approval we cannot move forward with them.
A quick history of the "referral-by:". When version 3 of the RIPE Database software was released in 2001 it was not possible for users to create their own MNTNER objects. You had to contact ripe-dbm and ask for one and justify why you needed 'another' MNTNER object. So only the RIPE NCC created MNTNER objects. That is why the documentation said the value of "referral-by:" had to be set to 'ripe-dbm-mnt' and could not be changed. In general RFC2725 defined it as a chain of trust where any existing MNTNER could create another one and be referred from it.
At some point the community decided asking ripe-dbm to create new MNTNER objects was over bureaucratic and not necessary. So it was opened up to allow anyone to create a MNTNER object, without any verification, validation or accountability. This is the situation we have now where a MNTNER is an anonymous box holding credentials of unknown and un-identifiable people. These are the people who maintain data in the RIPE Database. There was a cost to removing the bureaucracy.
As Engin pointed out, there was never any functionality implemented based on the "referral-by:" attribute. When we allowed anyone to create their own MNTNER we dropped the restriction on the value and changes to the value. The recommendation was to make it self-referencing. This was the easiest way to explain to new users what to put for the value. But it still confuses users today and if the community agrees it would be a good move to deprecate it, this would help a lot of people to understand the database.
When we set up AFRINIC's database in 2005, we dropped the "referral-by:" in their implementation of the whois software.
As there is no usage or dependency on this attribute at all, we can deprecate it from the syntax and mass update all MNTNER objects to remove it very easily.
If you wish to consider updating RFC2725 and RFC2622 (and later versions) bear in mind this is not the only deviation from the RFCs in the RIPE Database implementation. In fact from the start in 2001, the RIPE Database software was never strictly compliant with the RFCs. We used to say it conformed to RIPE RPSL, which was derived from the RFCs. To bring the RFCs into line with practical reality would be quite a task. Especially as the RIPE Database is a routing, reverse delegation and Internet number registry. 'RPSL' was adapted to make it work for all elements of the database.
I hope this explains where we are with "referral-by:". If you wish to proceed with changing this, you may wish to take another look at some of the other changes we suggested over the years that also never achieved any consensus. Some of those suggestions are still applicable now and would help to simplify aspects of the database and it's usage.
Regards Denis Walker Business Analyst RIPE NCC Database Team
On 14/03/2014 18:14, Job Snijders wrote:
On Fri, Mar 14, 2014 at 06:19:14PM +0200, Martin Tõnusoo wrote:
"referral-by" attribute(defined in RFC2725) is mandatory in "mntner" object:
[martint@ ~/ripe-db]$ whois -BHrh whois.ripe.net -t mntner | grep referral-by referral-by: [mandatory] [single] [ ] [martint@ ~/ripe-db]$
I checked the db-wg mailing-list archive since January 2000 and only discussion I found regarding this attribute was from Engin Gunduz(former RIPE NCC Senior Software Engineer) in June 2004: <snip>
He also proposed to remove the "referral-by" attribute, but there was no feedback to his e-mail. One can read his e-mail here: https://www.ripe.net/ripe/mail/archives/db-wg/2004-June/002797.html In addition, while RIPE database manual says that "referral-by attribute may never be altered after the addition of the maintainer", one can easily change it at least in current RIPE database version.
Is the "referral-by" attribute obsolete? Or is it needed in some specific situation? If not, I propose to remove the "referral-by" attribute in "mntner" object or at least make it optional. What is to be gained by removing this attribute (or making it optional)?
Currently the attribute is is quite prevalent in the existing database, so outright deletion is out of the question in my honest opinion:
princess@worker02:/var/spool/irr_database$ grep -c referral-by ripe.db 46753 princess@worker02:/var/spool/irr_database$
Maybe one of the RIPE database administrators can comment on current "referral-by" usage? What has changed between 2004 and 2014?
How are other RIRs using the attribute? If RIPE is to deprecate the attribute, it might be worth writing a small Internet-Draft to update RFC 2725.
Kind regards,
Job
mvh Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm
On Mon, Mar 17, 2014 at 12:48:44PM +0100, Elvis Velea wrote:
I agree with the deprecation of 'referral-by:' and it's removal from the RIPE Database.
+1 Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On 17.03.2014 12:48 PM, Elvis Velea wrote:
I agree with the deprecation of 'referral-by:' and it's removal from the RIPE Database.
+1 -Tim
On Fri, Mar 14, 2014 at 06:19:14PM +0200, Martin Tõnusoo wrote: <snip>
Is the "referral-by" attribute obsolete? If not, I propose to remove the "referral-by" attribute in "mntner" object or at least make it optional.
A few weeks have passed and no new comments have been added to the thread. Can the WG chairs declare consensus has been reached and rubber stamp the removal of the "referral-by" attribute in mnter objects? Kind regards, Job
On 15/04/14 12:33, Job Snijders wrote:
On Fri, Mar 14, 2014 at 06:19:14PM +0200, Martin Tõnusoo wrote:
<snip>
Is the "referral-by" attribute obsolete? If not, I propose to remove the "referral-by" attribute in "mntner" object or at least make it optional. A few weeks have passed and no new comments have been added to the thread.
Can the WG chairs declare consensus has been reached and rubber stamp the removal of the "referral-by" attribute in mnter objects?
Agreed, consensus has been reached. Can RIPE NCC action this please? Nigel
Dear working group, On 16 Sep 2014, at 14:57, Nigel Titley <nigel@titley.com> wrote:
Agreed, consensus has been reached. Can RIPE NCC action this please?
Nigel
We plan to implement these changes in conjunction with already planned whois releases for the replacement of "changed" with "last-modified". The removal of "referral-by" was not controversial, so we expect no major issues from this additional change. More importantly, we already plan to use a longer than usual period in the Release Candidate (RC) environment for the more controversial phase 2 of replacing "changed", so separate releases would be somewhat impractical. Phase 1: "referral-by" becomes optional ======================================= Shortly after RIPE 69 26 Nov 2014: RC 10 Dec 2014: Production (2 weeks of RC, coincides with the introduction of "last-modified" and "created") = "referral-by" becomes optional = updates for MNTNER objects that include "referral-by" are accepted, but warnings are shown Phase 2: "referral-by" is deprecated ==================================== Two months after RIPE 69 21 Jan 2015: RC 4 Mar 2015: Production (6 weeks of RC, coincides with "changed" becoming optional) = "referral-by" is no longer accepted in updates = "referral-by" is removed from all MNTNER objects = "last-modified" is not updated, since this is not a semantic change = "referral-by" is still shown for old versions Please let us know if you have any questions or comments about this. Kind regards, Tim Bruijnzeels Assistent Manager Software Engineering RIPE NCC
participants (13)
-
Daniel Roesen -
Daniel Stolpe -
Denis Walker -
Elvis Velea -
Job Snijders -
Job Snijders -
Martin Tõnusoo -
Nigel Titley -
Nigel Titley -
Piotr Strzyzewski -
Tim Bruijnzeels -
Tim Kleefass -
Wilfried Woeber