Hi,
Tom: thanks again for good catches! All comments are fixed in 08 version.
Gonzalo: I think we're good to go for the last call.
On 04/08/2014 01:27 PM, Miika Komu wrote:
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
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
