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