Re: [Gen-art] review of draft-ietf-hip-dex-11.txt

[Miika Komu]

Hi Francis,

thanks for you feedback, it will be visible in the next version of the
HIP DEX document.

to, 2019-11-14 kello 15:28 +0100, Francis Dupont kirjoitti:
> 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
> 
> .
> 
> Document: draft-ietf-hip-dex-11.txt
> Reviewer: Francis Dupont
> Review Date: 20191107
> IETF LC End Date: 20191114
> IESG Telechat date: unknown
> 
> Summary: Ready
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits/editorial comments:
>  - 1.2 page 6: highligts -> highlights

fixed thanks!

>  - 3 page 8: RFC 6090 does not fully define ECDH because of the
> "compact"
>   representation. Now it is a detail and if it can have an impact for
>   implementors I think the security directorate will ask for a
> clarification
>   (and in general I rely on the security directorate for all security
>related points, for instance whether DEX has a formal proof of its
>security properties)

we have ongoing discussion on this topic (some disclaimer will be added
to the intro).

>  - 5.3.2 page 23: return-routablility -> return-routability

fixed, thanks

>  - 4.1.1 page 11: I wonder if the puzzle solution check includes the
>   check of the puzzle itself but the remark saying with K=0 the
> puzzle
>   is just a retrun-routability cookie provided an answer... (so
> nothing
>   to change)

I guess no change is needed, but just for clarification:

k=0: return routability cookie
k>0: return routability + DoS prevention

>  - at the exception of the Acknowledgments section you use the
> English
>   spelling (with a 'e'): it is consistent with other HIP documents so
>   I have no problem with this.

I changed Acknowledgments to Acknowledgements

>  - 4.1.3.1 page 14: "and he system" -> "and the system"
> 
>  - 9 page 42: perhaps a SHOULD in "Thus, any signaling
>   that indicates such anonymity should be ignored as explained in
>   Section 1.1." ?
> 
>  - 9 page 43: computated -> computed
> 
>  - B page 50: IEDG -> IESG

fixed.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] review of draft-ietf-hip-dex-06.txt

[Miika Komu]

Hi Francis,

thanks for detailed comments! My comments below.

> Gonzalo Camarillo  Tue, 10 April 2018
> 11:39 UTCShow header
> 
> Bob, Rene, could you please get back to Francis (see below)?
> 
> Gonzalo
> 
> On 05/03/2018 1:14 PM, Gonzalo Camarillo wrote:
> > Bob, Rene,
> > 
> > could you please look into the review below and get back to
> > Francis?
> 
> Thanks!
> > 
> > Cheers,
> > 
> > Gonzalo
> > 
> > On 26/02/2018 7:30 PM, Francis Dupont wrote:
> > > 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
> > > 
> > > ;.
> > > 
> > > Document: draft-ietf-hip-dex-06.txt
> > > Reviewer: Francis Dupont
> > > Review Date: 20180224
> > > IETF LC End Date: 20180226
> > > IESG Telechat date: unknown
> > > 
> > > Summary: Ready
> > > 
> > > Major issues: None
> > > 
> > > Minor issues: None
> > > 
> > > Nits/editorial comments: 
> > >  - ToC page 3: you use the US spelling of Acknowledgments in the
> > > ToC
> > >   and the English one (acknowledgements) in the technical body.
> > >   Even when it is not very consistent I believe this follows RFC
> 
> 7401
> > >   choice so I am fine with this.

changed to U.S. spelling.

> > >  - 2.1 page 6: please add/move to RFC 8174 which updates RFC 2119
> 
> fixing
> > >   the keyword case silly issue.

done

> > >  - 2.2 page 6: perhaps "sort" should be added here?

I replicated the "sort" defition that appears later in the text to here
as well

> > >  - 2.3 page 7 (twice): (c.f.  Section 3)  -> (see Section 3) or
> > >   simply (Section 3)

thanks, fixed using the first expression

> > >  - 4.1.3.2 page 16 (at end of line): e.g. -> e.g.,

fixed

> > >  - 5.3.3 page 25: I don't believe the critical property for
> > >   random value is to be "uniformly distributed" (for instance
> > >   I could have put "unpredictable"). I leave this to the security
> > >   directorate who should propose a better wording if they don't
> > > like
> > >   the current one...

I think this refers to that the probability of each output value from
the random value generator is the same, i.e., no value is "favored"
more than others, which should be a fair assumption for a randomly
generated values

> > >  - 5.3.4 page 26: same comment.

(see above)

> > >  - 6.1 page 27: this section does not really explain what is the
> 
> puzzle
> > >   (it only stands the equation to verify) but I remember the
> 
> explaination
> > >   was before with a reference to 6.1 so I have no concern.

(it was mentioned in section 1.1)

> > >  - 6.2.1 sender 3 page 27: hidden dependency on the sort
> > > definition
> > >   for HOST_g/HOST_l so gl/lg keys. Yes it is in 6.3 but 6.3 is
> 
> after.

Added extra sentence to the third sender step:

3.  Compute the CMAC using either HIP-gl or HIP-lg integrity key
retrieved from KEYMAT as defined in Section 6.3. HIP-gl refers to host
with greater HIT value and HIP-lg refers to the host with smaller HIT
value.

> > >  - 6.3 pages and 30: sort is used page 29 and defined after page
> > > 30,
> > >   this is why IMHO the question to move the definition to 2.2
> 
> notation
> > >   is a good one...

I replicated to section 2.2.

> > >  - 6.3 page 30: / is not associative so ceil(L/RHASH_len/8) is
> > > bad.
> > >   The text shows it must be ceil(L/(RHASH_len/8)) (vs
> 
> ceil((L/RHASH_len)/8))

good catch, now it is:

N   =  ceil(L/(RHASH_len/8))   
   
 

> > >  - 6.5 1. page 31: Otherwise, it must drop the packet. -> MUST

fixed as suggested

> > >  - 6.6 1. page 33: the system should process the R1 packet -> or
> 
> SHOULD
> > >   or (I prefer) the system processes the R1 packet

used the latter expression

> > >  - 6.6 8. page 34: The R1 packet may have the A-bit set -> can
> > >   (not better from a language point of view but clearer and BTW
> > >used for instance in 6.10...)

fixed

> > >  - 6.6 13. page 34: it may either resend an I1 packet -> MAY? (cf
> 
> 11.)

fixed as suggested

> > >  - 6.7 5. page 36: Otherwise, the system should process the
> > > received
> 
> I2 ->
> > >   or SHOULD or (better) processes (and drop -> drops)

used the latter expression

> > >  - 6.7 15. page 37:
> > >  If the A-bit is set, the Initiator's HIT is anonymous and
> 
> should
> > >  not be stored permanently. -> IMHO SHOULD NOT or directly
> > > MUST
> 
> NOT

used the latter wording

> > >  - 6.9 page 39: If a NOTIFY packet is received in state I2-SENT,
> 
> this
> > >packet may be an I2 reception acknowledgement of the optional
> > >-> replace "may be" by "can be" or (better) "is"

used the latter

> > >  - 7 page 40: 

Re: [Gen-art] Genart telechat review of draft-ietf-hip-native-nat-traversal-28

[Miika Komu]

Hi Roni,

On 04/08/2018 10:32 AM, Roni Even wrote:

Reviewer: Roni Even
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 wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document: draft-ietf-hip-native-nat-traversal-??
Reviewer: Roni Even
Review Date: 2018-04-08
IETF LC End Date: 2018-02-26
IESG Telechat date: 2018-05-10

Summary:
The document is ready for publication as a standard track RFC with one nit.

Major issues:

Minor issues:

Nits/editorial comments:

In section 7 - "a new error type  SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED
in Section 5.9." It is in section 5.10


good catch, I'll fix the reference in the next version. Thanks!

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-hip-native-nat-traversal-27

[Miika Komu]

Hi Roni,

sorry, I read your email a bit too late today. I was too trigger happy 
and posted a new version... I thought it would be good to avoid blocking 
IANA with some missing and incorrect details.


On 03/04/2018 09:22 AM, Roni Even (A) wrote:

Hi Miika,
  All your responses are OK with me.

As for posting a new version, I think it will be good to submit one with all 
the changes that came in the IETF LC

Roni

-Original Message-
From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Miika Komu
Sent: Thursday, March 01, 2018 4:13 PM
To: Roni Even; gen-art@ietf.org
Cc: hip...@ietf.org; i...@ietf.org; 
draft-ietf-hip-native-nat-traversal@ietf.org
Subject: Re: [Gen-art] Genart last call review of 
draft-ietf-hip-native-nat-traversal-27

Hi Roni,

thanks for the detailed review! My comments are below.

On 02/26/2018 03:21 PM, Roni Even wrote:

Reviewer: Roni Even
Review result: Almost Ready

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-native-nat-traversal-??
Reviewer: Roni Even
Review Date: 2018-02-26
IETF LC End Date: 2018-02-26
IESG Telechat date: Not scheduled for a telechat

Summary:
The document is almost ready for publication as a standard track RFC

Major issues:

Minor issues:

1. in section 4.2 "Gathering of candidates MAY also be performed by
other means than described in this section.  For example, the candidates could 
be
 gathered as specified in Section 4.2 of [RFC5770] if STUN servers are
 available, or if the host has just a single interface and no STUN orData
 Relay Server are available." I did not see this a different ways since
 section 3 says "The hosts use either Control Relay Servers or Data Relay
 Servers (or other infrastructure including STUN or TURN servers) for
 gathering the candidates." so STUN is mentioned also here.


I suggest to remove the remark in parenthesis (or other infrastructure 
including STUN or TURN servers). Does this solve the issue?

[Roni] Yes


2. In section 4.6.2 "The connectivity check messages MUST be paced by
the Ta value negotiated during the base exchange as described in
Section 4.4.  If neither one of the hosts announced a minimum pacing
value, a value of  20 ms SHOULD be used." in section 4.4 the default value is 
50 ms?


Good catch! I double checked this from the ICE spec, which defaults also to 50 
ms. So, I change the value to 50 ms also in section 4.6.2.
[Roni] OK


3. in section 5.4 what about "ICE-STUN-UDP 2" ;  I assume it is not
relevant but this is also the IANA registeration


I think it makes sense to add the missing one as you suggest, but omit it from 
the IANA registration since it is already registered for RFC5770.
[Roni] OK


4. In section 5.5 "The TRANSACTION_PACING is a new parameter" it is
not new it is in RFC5770


You're right, I'll change this.
[Roni]OK


5. In section 5.10 "SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED  63"
is the only new one. this also relates to section 7 that says that all
error values in section 5.10 are new while the rest are in RFC5770.
Also there is no mention in section 7 of which registry is used for the error 
values.


Good catch, I'll correct these and add the IANA registry.

[Roni]OK


Nits/editorial comments:
1. Expand SPI and LSI when first appear in the document

2. in section 2 "the base of an candidate" should be "a candidate"

3. In section 3 "so it is the Initiator may also have registered to a
Control and/or Data Relay Server" maybe "so  the Initiator may also
need to register to a Control and/or Data Relay Server"

4. In section 4.2 "However, it is RECOMMENDED that a Data Relay Client
registers a new server reflexive candidate for each its peer for the
reasons described" maybe "for each of its..."


Thanks for spotting these, will fix as suggested.


5. In section 4.2 I could not parse the sentence "where Ta is the
value used for Ta is the value used for the"


Should be "where Ta is the value used for the"...


6. in section 4.6 "as defined in section in 6.7 in [RFC7401]:"  change
to "as defined in section 6.7 in [RFC7401]:"


Will fix this too.

Should I post a new version with the suggested changes?


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-hip-native-nat-traversal-27

[Miika Komu]

Hi Roni,

thanks for the detailed review! My comments are below.

On 02/26/2018 03:21 PM, Roni Even wrote:

Reviewer: Roni Even
Review result: Almost Ready

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

.

Document: draft-ietf-hip-native-nat-traversal-??
Reviewer: Roni Even
Review Date: 2018-02-26
IETF LC End Date: 2018-02-26
IESG Telechat date: Not scheduled for a telechat

Summary:
The document is almost ready for publication as a standard track RFC

Major issues:

Minor issues:

1. in section 4.2 "Gathering of candidates MAY also be performed by other means
than described in this section.  For example, the candidates could be
gathered as specified in Section 4.2 of [RFC5770] if STUN servers are
available, or if the host has just a single interface and no STUN orData
Relay Server are available." I did not see this a different ways since
section 3 says "The hosts use either Control Relay Servers or Data Relay
Servers (or other infrastructure including STUN or TURN servers) for
gathering the candidates." so STUN is mentioned also here.


I suggest to remove the remark in parenthesis (or other infrastructure 
including STUN or TURN servers). Does this solve the issue?



2. In section 4.6.2 "The connectivity check messages MUST be paced by the Ta
value negotiated during the base exchange as described in Section 4.4.  If
neither one of the hosts announced a minimum pacing value, a value of  20 ms
SHOULD be used." in section 4.4 the default value is 50 ms?


Good catch! I double checked this from the ICE spec, which defaults also 
to 50 ms. So, I change the value to 50 ms also in section 4.6.2.



3. in section 5.4 what about "ICE-STUN-UDP 2" ;  I assume it is not
relevant but this is also the IANA registeration


I think it makes sense to add the missing one as you suggest, but omit 
it from the IANA registration since it is already registered for RFC5770.



4. In section 5.5 "The TRANSACTION_PACING is a new parameter" it is not new it
is in RFC5770


You're right, I'll change this.


5. In section 5.10 "SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED  63" is the
only new one. this also relates to section 7 that says that all error values in
section 5.10 are new while the rest are in RFC5770. Also there is no mention in
section 7 of which registry is used for the error values.


Good catch, I'll correct these and add the IANA registry.


Nits/editorial comments:
1. Expand SPI and LSI when first appear in the document

2. in section 2 "the base of an candidate" should be "a candidate"

3. In section 3 "so it is the Initiator may also have registered to a Control
and/or Data Relay Server" maybe "so  the Initiator may also need to register to
a Control and/or Data Relay Server"

4. In section 4.2 "However, it is RECOMMENDED that a Data Relay Client
registers a new server reflexive candidate for each its peer for the reasons
described" maybe "for each of its..."


Thanks for spotting these, will fix as suggested.


5. In section 4.2 I could not parse the sentence "where Ta is the value used
for Ta is the value used for the"


Should be "where Ta is the value used for the"...


6. in section 4.6 "as defined in section in 6.7 in [RFC7401]:"  change to "as
defined in section 6.7 in [RFC7401]:"


Will fix this too.

Should I post a new version with the suggested changes?

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-hip-rfc4423-bis-18

[Miika Komu]

Hi Joel,

done! The new version with your suggested changes and diff are here:

https://www.ietf.org/internet-drafts/draft-ietf-hip-rfc4423-bis-19.txt
https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc4423-bis-19

P.S. I took the liberty to fix a small typo from the text:

drop HIP-base connectivity -> drop HIP-based connectivity

On 02/26/2018 04:39 PM, jmh.direct wrote:
These changes very nicely address my concerns.b You should check with 
your chair,and AD before submitting a,revision.


Thank you,
Joel



Sent via the Samsung Galaxy S® 6, an AT 4G LTE smartphone

 Original message 
From: Miika Komu <miika.k...@ericsson.com>
Date: 2/26/18 06:56 (GMT-05:00)
To: Joel Halpern <j...@joelhalpern.com>, gen-art@ietf.org
Cc: draft-ietf-hip-rfc4423-bis@ietf.org, hip...@ietf.org, i...@ietf.org
Subject: Re: Genart last call review of draft-ietf-hip-rfc4423-bis-18

Hi Joel,

thanks for the nice review! My suggested changes for HIP architecture
document are below (in "diff" format).

On 02/18/2018 07: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.

agreed. Suggested change:

     Host Identity Hash  The cryptographic hash used
-  in creating the Host Identity Tag from the Host Identity.
+  in creating the Host Identity Tag from the Host Identifier.
   (I will move the definition of Host Identifier earlier so that the
terms appear in chronological order)

 >  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.


Agree. Suggested rephrasing:

-    The only completely defined structure of the Host Identity
-    is that of a public/private key pair.  In this case, the Host
-    Identity is referred to by its public component, the public
+    An identity is based on public-private key cryptography in HIP.
+    The Host Identity is referred to by its public component, the
public
   key.

 >  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.


yes, you are correct. I would suggest the following changes to make this
more clear:

   A Host Identity Tag is a 128-bit representation for a Host
-    Identity.  It is created from an HIH,
-    an IPv6 prefix [RFC7343] and a hash identifier.
+    Identity. Due to its size, it is suitable to be used in the
existing sockets API in
+    the place of IPv6 addresses (e.g. in sockaddr_in6 structure,
sin6_addr member) without modifying applications.
+    It is created from an HIH, an IPv6 prefix [RFC7343]
+    and a hash identifier.

...and the following:

   An LSI is a 32-bit localized representation for a Host
-    Identity. The purpose of an LSI is to facilitate using Host
+    Identity. Due to its size, it is suitable to be used in the
existing sockets API in
+    the place of IPv4 addresses (e.g. in sockaddr_in structure,
sin_addr member) without modifying applications.
+    The purpose of an LSI is to facilitate using Host
   Identities 

Re: [Gen-art] Genart last call review of draft-ietf-hip-rfc4423-bis-18

[Miika Komu]

Hi Joel,

thanks for the nice review! My suggested changes for HIP architecture 
document are below (in "diff" format).


On 02/18/2018 07: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

.

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.


agreed. Suggested change:

   Host Identity Hash  The cryptographic hash used
-  in creating the Host Identity Tag from the Host Identity.
+  in creating the Host Identity Tag from the Host Identifier.
 (I will move the definition of Host Identifier earlier so that the 
terms appear in chronological order)



 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.


Agree. Suggested rephrasing:

-The only completely defined structure of the Host Identity
-is that of a public/private key pair.  In this case, the Host
-Identity is referred to by its public component, the public
+An identity is based on public-private key cryptography in HIP.
+The Host Identity is referred to by its public component, the 
public

 key.


 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.


yes, you are correct. I would suggest the following changes to make this 
more clear:


 A Host Identity Tag is a 128-bit representation for a Host
-Identity.  It is created from an HIH,
-an IPv6 prefix [RFC7343] and a hash identifier.
+Identity. Due to its size, it is suitable to be used in the 
existing sockets API in
+the place of IPv6 addresses (e.g. in sockaddr_in6 structure, 
sin6_addr member) without modifying applications.

+It is created from an HIH, an IPv6 prefix [RFC7343]
+and a hash identifier.

...and the following:

 An LSI is a 32-bit localized representation for a Host
-Identity. The purpose of an LSI is to facilitate using Host
+Identity. Due to its size, it is suitable to be used in the 
existing sockets API in
+the place of IPv4 addresses (e.g. in sockaddr_in structure, 
sin_addr member) without modifying applications.

+The purpose of an LSI is to facilitate using Host
 Identities in existing APIs for IPv4-based
-applications. Besides facilitating HIP-based connectivity for
+applications.
+LSIs are never transmitted on the wire; when an application
+sends data using a pair of LSIs, the HIP layer (or sockets
+handler) translates the LSIs to the corresponding HITs, and
+vice versa for receiving of data.
+Besides facilitating HIP-based connectivity for
 legacy IPv4 applications, the LSIs are beneficial in two other
 scenarios [RFC6538].

@@ -712,6 +721,14 @@
 to facilitate backward compatibility with existing networking
 APIs and stacks.


 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.


agreed, the