I had an review on I-D draft-irtf-hiprg-revocation-00. I think the draft is in good form. 
But in explicit HI revocation something should be more discussed. 

Draft clearly explained explicit HI revocation problems when there is no third party.
Here we consider some potential candidate solutions as third party to address those problems.

DNS server can be potentially adopted to construct a global explicit HI revocation mechanism 
applying a pull model. DNS RR allows a HIP node store its HI(s), HIT(s), domain name of its RVS. 
DNS use pull model for distributing the key revocation information. Certificate Revocation List (CRL)
is an example of this pull model. CRL is a digitally-signed, time-stamped black-list that indicates 
which HIs are no longer valid. 

I think CRL is not good choice for HIP architecture because CRL may growing too large and get long time
to take download CRLs information. Also it needs to periodically update. Therefore to getting better
performance of CRLs we can use extended delta-CRL mechanism that contains only the latest revocation 
updates since a prior CRL was issued. Other purpose solution for CRL is this question that can we have
valid HIs instead of invalid HIs in CRL (like ACL)? 

On-Line Certificate Status Protocol (OCSP) and Simple Certificate Validation Protocol (SCVP) [1] proposed
in PKI can be other candidate solutions. But I am not sure current HIP architecture support them. 
(I supposed the advantages of those mechanisms are obvious)

So, the great question is how to provide customization form of OCSP or SCVP to use in HIP architecture?

An initiator host needs before a Base Exchange a response to a DNS query (FQDN) 
in order to get a the IP, HI and HIT of a responder host. Can DNS provide guaranteeing DNS message security? 
So, how can we replace DNS with DNSSEC to support its security?


One of the fundamental issues with DNS is provide mobility for HIP nodes, but if mobility factor is high 
and end host needs to update the binding between HI and locator, DNS may not be able to update immediately. 
Rendezvous Server (RVS) [RFC5204] (similar to the HA in Mobile IP) is fundamental solution. DNS contains 
the location of the Rendezvous server. Direct mapping between HI and IP addresses of the host will be stored in RVS.

According to [2] HIP resolution and rendezvous mechanisms should address some issues include dependencies on the DNS, 
lack of support for direct communication based on host identities, lack of a reverse lookup mechanism for
host identities,and DNS and node rendezvous.

I believe we can enhance functionality of RVS server to provide its task of connectivity without DNS.
Indeed, how we can eliminate FQDN process from the HIP architecture. Moreover, another
possible enhancement of rendezvous functionality is providing mechanism to communicate by legacy node. 

As another third party to address the key revocation process is middle-boxes [RFC3234]. 
I believe an extension in HIP architecture enables the middle-boxes to provide 
strong security framework (include key revocation mechanism) and rapid mobility support for HIP architecture. 
 
Finally I should mention here we need discus about a mechanism to discover HI revocation conditions 
at presence of risk management policy. 

[1]A.Malpani, P.Hoffman and R.Housley, Simple Certificate 
Validation Protocol (SCVP), draft-ietf-pkix-scvp-04.txt, November 2000

[2]L. Eggert and J. Laganier, HIP Resolution and Rendezvous Problem Description,
 draft-eggert-hiprg-rr-prob-desc-00, October 18, 2004