Reviewer: Joel Halpern Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments.
For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-hip-rfc4423-bis-18 Reviewer: Joel Halpern Review Date: 2018-02-17 IETF LC End Date: 2018-02-26 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as an Informational RFCs. The following comments may be useful for the authors to consider. Major issues: N/A Minor issues: In the table in section 2.2 (Terms specific to this and other HIP documents) the Host Identity Hash is defined as "The cryptographic hash used in creating the Host Identity Tag from the Host Identity." I am pretty sure the last word should be Identifier, not Identity,, which matches the meanings and the usage in the following term. In section 4.1 second paragraph, it seems odd to refer to the public-private key pair as the structure of the abstract Host Identity. Given that the earlier text refers to the Public key as the Host Identifier, I am not sure how you want to refer to the public/private key pair. But I do not think it "is" the structure of the Host Identity. In the section 4.4 discussion of locally scoped identifier (LSI), it appears that applications need to be modified to use this. Reading between the lines of the stack architecture, the actual advantage of using HIP with LSIs is that the application changes can be restricted to whatever indication is to be used that the stack is to use HIP, rather than changing the places that use sockaddrs, etc. But this is not clearly stated here. In section 5.1 paragraph 3, the text talks about a connecting client not specifying a responder identifier (HIP Opportunistic mode) in order to enable load balancing. I think the text would be helped by an example of how an initiator might know to do this, rather than just not using HIP. Also, it would be good if the text was explicit as to whether or not there was a way to support load balancing / multi servers without either using a shared identity or sacrificing security by using Opportunistic HIP. Given that section 5 is titled "New Stack Architecture", I think it would be helpful if the section were explicit as to where the HIP logic lives relative to the IP and UDP/TCP portions of the host stack. This would help the reader have the right model for interpreting section 6.2 and 8.1. Nits/editorial comments: Section 4.2 third sentence "It is possible to for ..." should be "It is possible for ..." _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
