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

[Miika Komu <[e-mail]>]

Hi,

sure thing, thanks Tom for comments!

On 04/08/2014 01:25 PM, Gonzalo Camarillo wrote:
> 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
>>
>>
>
> _______________________________________________
> Hipsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hipsec
>