Re: [Hipsec] WGLC: draft-ietf-hip-rfc4423-bis

["Henderson, Thomas R" <[e-mail]>]

> Hi,
> 
> we WGLCed this draft some time ago, but we are WGLCing it again at this
> point to make sure people are happy with the current version:
> 
> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/
> 
> This WGLC will end on April 6th. Please, send your comments to this
> list before then.
> 

I read the revised version again today and believe it is ready to publish once the below nits are taken care of.  I believe that they are mostly editorial but I'd be happy to discuss on the list.

- Tom

Section 1
---------

Old text:

 There is exactly one Host Identifier for each Host Identity.

New text:

 There is exactly one Host Identifier for each Host Identity (although there may be transient periods of time such as key replacement when more than one identifier may be active).

The reference to Section 7 should be to Section 6.

The first use of ESP should be cited (it is later cited in 6.1).

Section 2
---------

Old text:

                                                            Public is  |
   |               | a relative term here, ranging from known to peers |
   |               | only to known to the World.                       |

New text:


                                                            Public is  |
   |               | a relative term here, ranging from "known to      |
   |               | peers only" to "known to the world."              |

Again, the reference to HIP base exchange should be Section 6, not Section 7

Section 3
-----------

Old text:

   o  The names should have a localized abstraction so that it can be
      used in existing protocols and APIs.

New text:

   o  The names should have a localized abstraction so that they can be
      used in existing protocols and APIs.

Section 4
---------

Old text:

   a public-key-based HI can
   authenticate the HIP packets and protect them for man-in-the-middle
   attacks.

New text:

   a public-key-based HI can
   authenticate the HIP packets and protect them from man-in-the-middle
   attacks.

s/HIP BEX/HIP base exchange

Section 4.2
-----------
s/through out/throughout

Section 4.3
-----------
s/HIts/HITs

Section 4.5
-----------
s/types of application/types of applications

Old text:

   For instance,
   Light-weight Directory Access Protocol (LDAP) or in a Public Key
   Infrastructure (PKI) [I-D.ietf-hip-rfc6253-bis].

New text:

   For instance, a directory based on the
   Lightweight Directory Access Protocol (LDAP) or a Public Key
   Infrastructure (PKI) [I-D.ietf-hip-rfc6253-bis] may be used.

s/associate with/associated with

s/a LDAP or DHT/an LDAP-based directory or DHT

Section 5
---------

Old text:

   As discussed above, the IP
   addresses can be seen to be a confounding of routing direction
   vectors and interface names.

New text:

   As discussed above, the IP
   addresses can be seen to be a confounding of computing platform
   names and interface names.

(or else delete this sentence as it is somewhat redundant with other sentences below; I just felt that the "confounding" aspect relates to EIDs and locators instead of routing direction vectors)

Section 8
---------
s/cannot distinguished/cannot be distinguished

Section 9
---------
s/intestigating/investigating

s/Particularly, so called bloom filters/In particular, so-called Bloom filters

(also in section 12.3, 'Bloom' is not capitalized; it should be either be capitalized everywhere (typical usage that I have seen) or lower case everywhere)

s/datastructures/data structures

s/by HIP working group/by the HIP working group

Section 10
----------
s/in a similar vain/similar to how

Old text:
   The implementations should provide for a policy of
   initiator HIT to responder HIT.

New text:
   The implementations should provide for a policy mapping of
   initiator HITs to responder HITs.

Section 11
----------
s/With the exception High-Performance/With the exception of High-Performance

s/As majority of the/As the majority of the

s/More agile IPv6 interoperability as discussed in Section 4.4./More agile IPv6 interoperability can be achieved, as discussed in Section 4.4.

s/An addition, the underlying/Additionally, the underlying

s/halves the size of access control lists/can potentially halve the size of access control lists

the reference [scultz-intermittent] should probably be spelled [schuetz-intermittent]

Section 11.3
------------
s/accomodate/accommodate

s/strictly speaking mandatory/mandatory

Section 12.2
------------
s/credit-based authorization approach Host Mobility/credit-based authorization approach for host mobility

Section 12.3
-------------
s/There has been attempts/There have been attempts

s/the protection of malign data flows/??

s/which the the end-hosts/which the end-hosts

Section 15
----------
s/RFC 4424/RFC 4423