Vesna Manojlovic wrote:
Dear Brian, list,
On 3/6/10 12:28 AM, The IESG wrote:
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@xxxxxxxx mailing lists by 2010-04-02.
I support the introduction of the new attribute.
At the RIPE NCC, we already see opportunities for its usage for
reachability testing and analysis.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-haberman-rpsl-reachable-test-03.txt
One suggestion: please add that the pingable address MUST be within
the range specified in route(6) object.
It is implicit, and obvious, but for people implementing the IRR code
(RIPE Database server, IRRd) it should be specified explicitly (IMHO),
so that they can program the checks...
I am looking forward to the acceptance of this addition to the RPSL
specs, and I am willing to assist in the implementation & adoption of
the new attribute.
I'm still not entirely convinced that this belongs in RPSL
as opposed to the address registry allocation information.
There are often suballocations of addresses where there is no
change in origin AS and thus only a single route object exits.
It would be useful to be able to indicate pingable addresses in these
suballocations. While one could have multiple pingable attributes in the
route object, I believe it is cleaner and clearer to put the
pingable address in the suballocation information.
I have concerns about these pingable addresses becoming
stale. I'd like to see some caution in the draft about this
issue and the possibility of mis-interpreting a stale address
as a routing issue. One might suggest using the date in the changed:
attribute as a possible indicator of staleness. You could
also add an explicit date field to the pingable attribute itself.
Another possible option would be to make this date an expiration
date set at some point in the future. This would require periodically
re-verifying the address and updating the expiration date.
Pingable addresses with expired dates could be given less
credence than those that have not expired.
-Larry Blunk
Merit
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf