Proposed change 2003.1: notification for more-specific
Colleagues, This is one of a number of proposed changes to the way the RIPE Database works. These are changes that are intended to make the database work more consistently, as well as provide an increased level of security and control to users. Please have a look, and discuss it here. [2003.1] Notification on more-specific object creation authorisation -------------------------------------------------------------------- Change: When the creation of an object requires authorisation by a less-specific object, normal mntner notification will apply; "upd-to:" is notified of failure, and "mnt-nfy:" is notified of success. Where there are multiple maintainers, only one is needed to successfully authorise the creation, but all the maintainers in the list will be notified. For example: inetnum: 192.168.101.0 - 192.168.101.255 . . . mnt-by: EXAMPLE-MNT mnt-lower: ANOTHER-MNT mnt-lower: YET-ANOTHER-MNT If the successful creation of the more specific inetnum: inetnum: 192.168.201.0 - 192.168.201.255 . . . mnt-by: SOME-MNT Is authorised by YET-ANOTHER-MNT in the less specific inetnum, notifications will be sent to the "mnt-nfy:" listed in both ANOTHER-MNT and YET-ANOTHER-MNT. Motivation: This is useful for two cases. The first is so that the maintainer of an object will be notified when unauthorised attempts to create objects occur and will receive confirmation when objects are successfully created. The second is for cases where there are multiple maintainers in a position to authorise a creation (as in the example above). The maintainers that did not specificially authorise the creation are still notified (this is how notification for updates works today). -- Shane Kerr RIPE NCC
Change:
When the creation of an object requires authorisation by a less-specific object, normal mntner notification will apply; "upd-to:" is notified of failure, and "mnt-nfy:" is notified of success. Where there are multiple maintainers, only one is needed to successfully authorise the creation, but all the maintainers in the list will be notified.
My comment is not specifically related to this proposal, but I have long been concerned about the optional status of the mnt-nfy: attribute. This means if someone cracks a mntner password and begins submitting updates (which naturally will be successful since they have the password), no notification will be sent to the mntner. I'm not sure of the best way to handle this. I suppose there are some people who don't want to be bothered by notification of successful updates and if they're using PGP that might be okay. It also seems the upd-to attribute name was very poorly chosen as it is difficult to differentiate it's function from that of mnt-nfy (I often get the two confused and I deal with this stuff every day). I personally feel that the mnt-nfy should be mandated in RPSL and those mntner's who do not have one should have it replicated from their upd-to attribute value. For those who really don't care to see the results of successful updates, they could simply direct the email address to /dev/null. -Larry Blunk Merit
On 2003-03-07 17:56:46 -0500, Larry J. Blunk wrote:
My comment is not specifically related to this proposal, but I have long been concerned about the optional status of the mnt-nfy: attribute. This means if someone cracks a mntner password and begins submitting updates (which naturally will be successful since they have the password), no notification will be sent to the mntner.
I'm not sure of the best way to handle this. I suppose there are some people who don't want to be bothered by notification of successful updates and if they're using PGP that might be okay. It also seems the upd-to attribute name was very poorly chosen as it is difficult to differentiate it's function from that of mnt-nfy (I often get the two confused and I deal with this stuff every day). I personally feel that the mnt-nfy should be mandated in RPSL and those mntner's who do not have one should have it replicated from their upd-to attribute value. For those who really don't care to see the results of successful updates, they could simply direct the email address to /dev/null.
I am personally agnostic on the issue, but do not think there would be a problem making "mnt-nfy:" mandatory. As a data point, of the 8808 maintainers in the RIPE Database, there are 2322 that use password-based authentication (CRYPT-PW or MD5-PW) and have no "mnt-nfy:" attribute. -- Shane Kerr RIPE NCC p.s. I also think that "upd-to:" and "mnt-nfy:" are probably not the best names. But what can we expect of a standard with things like "mntner:" and "aggr-mtd:"? (These names can't be to shorten them, or we wouldn't have "peering-set:" and "mbrs-by-ref:")? Would it make sense to make an alias for "upd-to:" of something reasonable, e.g. "auth-fail-nfy:"?
O
p.s. I also think that "upd-to:" and "mnt-nfy:" are probably not the best names. But what can we expect of a standard with things like "mntner:" and "aggr-mtd:"? (These names can't be to shorten them, or we wouldn't have "peering-set:" and "mbrs-by-ref:")? Would it make sense to make an alias for "upd-to:" of something reasonable, e.g. "auth-fail-nfy:"?
You beauty!! and one for the other "mnt-nfy", something reasonable, e.g. "hey-your-update-worked" -- McTim
Hi all, 1. I just want to point out that the example is not exactly correct? 192.168.201.0/24 is not more specific than 192.168.101.0/24. They don't even overlap ;-) 2. Just to confirm my understanding: the successful creation of a more specific inetnum will trigger a notification to all mnt-nfy: of the parent block's mnt-lower(s). Is this correct? Cheers, Sanjaya
-----Original Message----- From: db-wg-admin@ripe.net [mailto:db-wg-admin@ripe.net] On Behalf Of Shane Kerr Sent: Wednesday, 5 March 2003 12:49 AM To: db-wg@ripe.net Subject: [db-wg] Proposed change 2003.1: notification for more-specific
Colleagues,
This is one of a number of proposed changes to the way the RIPE Database works. These are changes that are intended to make the database work more consistently, as well as provide an increased level of security and control to users.
Please have a look, and discuss it here.
[2003.1] Notification on more-specific object creation authorisation --------------------------------------------------------------------
Change:
When the creation of an object requires authorisation by a less-specific object, normal mntner notification will apply; "upd-to:" is notified of failure, and "mnt-nfy:" is notified of success. Where there are multiple maintainers, only one is needed to successfully authorise the creation, but all the maintainers in the list will be notified.
For example:
inetnum: 192.168.101.0 - 192.168.101.255 . . . mnt-by: EXAMPLE-MNT mnt-lower: ANOTHER-MNT mnt-lower: YET-ANOTHER-MNT
If the successful creation of the more specific inetnum:
inetnum: 192.168.201.0 - 192.168.201.255 . . . mnt-by: SOME-MNT
Is authorised by YET-ANOTHER-MNT in the less specific inetnum, notifications will be sent to the "mnt-nfy:" listed in both ANOTHER-MNT and YET-ANOTHER-MNT.
Motivation:
This is useful for two cases. The first is so that the maintainer of an object will be notified when unauthorised attempts to create objects occur and will receive confirmation when objects are successfully created. The second is for cases where there are multiple maintainers in a position to authorise a creation (as in the example above). The maintainers that did not specificially authorise the creation are still notified (this is how notification for updates works today).
-- Shane Kerr RIPE NCC
On 2003-03-10 15:47:51 +1000, Sanjaya wrote:
1. I just want to point out that the example is not exactly correct? 192.168.201.0/24 is not more specific than 192.168.101.0/24. They don't even overlap ;-)
Yikes! I guess that should be 192.168.0.0/16. :(
2. Just to confirm my understanding: the successful creation of a more specific inetnum will trigger a notification to all mnt-nfy: of the parent block's mnt-lower(s). Is this correct?
That is correct, and a *failed* creation of a more specific inetnum will trigger notification to all "upd-to:" of the same maintainers. -- Shane Kerr RIPE NCC
participants (4)
-
Larry J. Blunk -
Sanjaya -
Shane Kerr -
Tim McGinnis