[hiprg] 答复: comments on draft-irtf-hiprg-revocation-02.txt

["Dacheng Zhang(Dacheng)" <[e-mail]>]

Thanks a lot, Tom. Please see the inline please.

>>Here are some comments on the latest version of your document.  I think that the draft could be improved by more careful definition of and distinction between the host identity and host identifier (see RFC4423), and to summarize  more >>clearly (in the introduction) the main issues that this draft is concerned with:

>>1) what does it mean for two or more different hosts to have the same host identifier?  Here there are two cases:  1a) there is a trusted third party who can resolve this, and 1b) there is no such arbitrator

>>2) what does it mean for one host to have multiple host identifiers associated with the same host identity; can these be associated together and can they be expired or deprecated similar to how locators are deprecated?

Will update it!

>>I think that the draft has some clear solutions for some of the above questions but less clear for others, so it would be useful to also summarize in section 1 which of the questions are well answered and which will require further study.

>>It is time to start filling in the terminology section more fully (Section 2).
Agree and will do it.

>>Where you say in Section 5:  "Until now, the ID to Locator mapping solution in HIP has not been standardized yet.  We argue that it is desired to integrate the implicit key revocation functionality into such systems."  I would suggest to >>clarify that you are not talking about DNS here but instead about something like the DHT lookup.

DNS is a "Locator to ID " mapping solution. Yes, when I mention "ID to Locator" mapping solution, I indicate the DHT solution.

>>In section 6 paragraph 2, I did not understand how this case could handle the situation when the reason to remove the HI was due to key compromise-- perhaps clarify this point here.

This paragraph introduce the CRL solution in PKI. I just try to indicate that when a HI is removed, the revocation information can be put a trusted third party for other interested hosts to query. Will update it!

>>In section 8, the end of this section ends prematurely.  The paragraph that starts "Because the HI of a HIP host acts as both the identity and the public key of the HIP host at the same time." does not contain complete sentences and has >>some of the terminology problems that I mentioned above.

Will update it!

>>In section 10 (Security considerations), I think you need to start filling it out, rather than the blanket statement that you have there.  Perhaps a way to start is to review this RFC:  http://www.ietf.org/rfc/rfc3552.txt

Will update it!

- Tom