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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf