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

[Gonzalo Camarillo <[e-mail]>]

Hi Tom,

thanks for your comments. Authors, could you please look into this?

Thanks,

Gonzalo

On 07/04/2014 12:08 AM, Henderson, Thomas R wrote:
>> 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
> 
>