Mail folder problems. I will be catching up with all of this starting
Friday (Purim tonight and tomorrow).
Bob
On 02/18/2018 12:33 AM, Joel Halpern wrote:
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 ..."
_______________________________________________
Hipsec mailing list
hip...@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
