A Dedicated Routing Policy Specification Language Interface Identifier for Operational Testing
draft-haberman-rpsl-reachable-test-05

[Ballot comment]
FORMER DISCUSS (I still have my doubts about whether a NIC Handle truly provides a reliable link to contact information, but we'll find out in running code).

From an operational perspective, the NIC Handle system is no longer supported as widely as it once was; therefore inclusion of the  does not necessarily or even reliably "provide a link to contact information" as claimed in the specification. Is there a reason why the "ping-hdl" attribute does not have a value-type of  (as for the "notify" attribute in RFCs 2622 and 4012)?

[Ballot discuss]
I like this document and idea, and I fully support it going forward.
For what it is worth, I do not believe the document needs to be any
clearer with respect to the security implications or what protocols
are being offered for test. However, I did have one practical concern:

  The presence of one or more pingable attributes signals to network
  operators that the maintainer of the referenced network is providing
  the address(es) for external diagnostic testing.  Tests involving the
  advertised address(es) SHOULD be rate limited to no more than ten
  probes in a five minute window unless prior arrangements are made
  with the maintainer of the attribute.

I think this is overly cautious, and could perhaps apply to some
automatic probing by everyone. But written as above, I would not be
able to launch a regular ping with default options to towards the
site, unless I aborted it within ten seconds. And even then, that would
be it for that five minute period.

I would suggest that the text explictly calls out a conservative
limit (e.g., the above one) on any automatic probing, while allowing
manual testing without any hard limits. The text could perhaps say
something about normal courtesy in tests, such as alerting the
destination before any resource consuming tests are done (flood pings
and the like)

[Ballot discuss]
+1 Sean's and Peter's discuss...

The missing security considerations section should address any controls that are needed
on intermediate systems (e.g., gateways, routers or firewalls) as well as the advertised
reachable host.

[Ballot discuss]
The Gen-ART Review by Vijay Gurbani raised a point that deserves
  a response:

  Is the intent to have the specific IP address be used solely for
  diagnostic tests?  That is, can someone probe for other services on
  this IP address (http, sip, etc.)?  The description is not very clear
  on that, and in fact, if the intent is for the latter to happen, then
  some manner of Security Consideration section should be put in to
  alert of any ramifications.

[Ballot comment]
Please demarcate the rows of the table in Section 2 -- it is confusing to read.

There are no references for the value-types  and , which are apparently meant to be definitional for the "pingable" attribute; these are defined in RFC 4012 and RFC 2622 respectively but references would be helpful. Similarly there is no reference for the value-type , which is apparently meant to be definitional for the "ping-hdl" attribute; this is defined in RFC 2622 but a reference would be helpful.

[Ballot discuss]
The document lacks the required security considerations section.

From an operational perspective, the NIC Handle system is no longer supported as widely as it once was; therefore inclusion of the  does not necessarily or even reliably "provide a link to contact information" as claimed in the specification. Is there a reason why the "ping-hdl" attribute does not have a value-type of  (as for the "notify" attribute in RFCs 2622 and 4012)?

[Ballot comment]
section 2: "can advertise" - should this be a MAY or SHOULD?
section 3: "maintaner of the attribute" - would this be better stated as "operator fo the target network"?