Internet X.509 Public Key Infrastructure Repository Locator Service
draft-ietf-pkix-pkixrep-04

[Ballot comment]
I'm clearing Harald's DISCUSS due to my incompetence on DNS issues, and a desire not to 2nd guess the WG, but the Internet ADs need to look.

There are some editorial issues:

OCSP is mentioned but isn't a very well known acronym. It would be
appropriate to give an informative reference for it (and for LDAP and
HTTP for consistency).

The references aren't separated between Normative and Informative, and
aren't cited with [...].

The boilerplate is out of date (and the new boilerplate will be
enforced as of May 6th).

[Ballot comment]
I'm clearing Harald's DISCUSS due to my incompetence on DNS issues, and a desire not to 2nd guess the WG, but the Internet ADs need to look.

There there are some editorial issues:

OCSP is mentioned but isn't a very well known acronym. It would be
appropriate to give an informative reference for it (and for LDAP and
HTTP for consistency).

The references aren't separated between Normative and Informative, and
aren't cited with [...].

The boilerplate is out of date (and the new boilerplate will be
enforced as of May 6th).

[Ballot discuss]
Note: This document asked for experimental publication. It should not be that hard to get an experiment off the ground. But it doesn't say anything about what its success criteria are.

I've dropped the comment about the _LDAP and so on labels; it turns out that we are continuing down a road beaten by IMPP. But still:

If choosing among protocols is by sequentially probing all combinations, that should be stated. The example only shows a single protocol.

[Ballot discuss]
Note: This document asked for experimental publication. It should not be that hard to get an experiment off the ground. But it doesn't say anything about what its success criteria are.

I think this doc needs to justify the choice of inserting _HTTP, _OCSP and _LDAP into the namespace that the original SRV RFC had _TCP and _UDP in.
It would also be interesting to hear the arguments for not using DDDS and NAPTR.

If choosing among protocols is by sequentially probing all combinations, that should be stated. The example only shows a single protocol.

Reviewed by Michael Patton for GEN-ART. Review at:

[Ballot comment]
SMB pointed out that certificates are verifiable, and therefore DNSSEC is
not needed, by contrast with our usual SRV-located resources.  Therefore I've
cleared my Discuss.

[Ballot discuss]
Ted caught the big problem. 
But another one:
There should be a discussion of the risk of attack because
the records can be spoofed, and of the use of DNSSEC to address this risk.
A good way to do this in an advisory manner, since DNSSEC is still
working its way through the IETF, can be found in draft-ietf-enum-sip-01.txt.

[Ballot discuss]
Ted caught the big problem. 
But another one:
There should be a discussion of the risk of attack because
the records can be spoofed, and of the use of DNSSEC to address this risk.
A good way to do this in an advisory manner, since DNSSEC is still
working its way through the IETF, can be found in draft-ietf-enum-sip-01.txt.

[Ballot comment]
The references should be formatted as described in the ID nits document, and cited appropriately within the document.

Section 2: character values are sometimes hard to determine depending on the application used to view the text.  Suggest replacing '"_" character' with '"_" character (value 0x005F)' to be clear about the prepend character used in the RR.

[Ballot discuss]
For draft-ietf-impp-srv-04, we required an IANA maintained registry
that allowed someone to map _im._bip to a specification of how
_bip used SRV records.  Seems very similar, in that PKIXREP will
actually map to different using protocols like OCSP, LDAP, or
HTTP; these aren't just transports, like tcp or udp, they have
different syntax (and frankly the use of HTTP for this means a convention
at a level even SRV can't handle).

If these folks don't want to go the DDDS road, would requiring a similar
registry make sense here?