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 [email protected] https://www.ietf.org/mailman/listinfo/hipsec
