Hi Brian, Larry and others >From an implementation point of view in the RIPE Database, I have no preference if this is in the ROUTE(6) or INET(6)NUM object. From a practical point of view, it seems to be more related to a route than address information. Even if it is not strictly routing policy. I would suggest changing the name of the "ping-hdl:" attribute to "ping-c:". This then follows the current style of "admin-c:", "tech-c:" and "zone-c:", all of which reference a nic-hdl. Also the RIPE NCC Database Group will be publishing a proposal soon on RIPE Labs about abuse handling and proposing the introduction of an "abuse-c:" attribute. Keeping to the same style for all 'c'ontact information may cause less confusion. I would advise against any coupling with the "changed:" attribute for validity. Because of the loose requirements on the "changed:" attribute it only has any meaning to the maintainer of the object. If you want a validity reference I would suggest either add a specific user set attribute or an auto-generated attribute. But what would this date mean? The maintainer asserts that the IP address(es) were available to ping on that date. Or that they will be available at least until this date. Does it also assert that the ping contact details are still correct? What would be the conditions for this value to be reset or re-verified? If it is auto-generated maybe you just want to modify the object, without changing anything, effectively just 'touching' the object. If it is user set by the maintainer, how far in the future would be a reasonable validity period? Setting expiry dates or requiring periodical re-verification of 'bits' of data might set an interesting precedence. There may be other people who think other 'bits' of data should also expire or require re-verification. Regards Denis Walker Business Analyst RIPE NCC Database Group _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf