> 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
