Hi Tom, Thanks for reviewing the document. My comments inline below:
On Mon, Mar 11, 2013 at 2:14 PM, Henderson, Thomas R <[email protected]> wrote: > This is a WGLC review of RFC4843-bis. > > In general, I only found what I regard to be minor issues, listed below. > > Suggested change to abstract > OLD TEXT: > They are designed to appear as application layer entities and at the existing > IPv6 APIs, but they should not appear in actual IPv6 headers. To make them > more like vanilla IPv6 addresses, they are expected to be routable at an > overlay level. > NEW TEXT: > They are designed to appear as application layer entities and at the existing > IPv6 APIs, but they should not appear in actual IPv6 headers on networks that > route based on IPv6 addresses. I'd rather not change the statement that they should not appear in actual IPv6 headers as this could become a red herring to our argument that ORCHID allocation is useful and _harmless_. As per your comment below a will replace vanilla by normal or regular. > Section 2 refers to the OGA ID. In RFC 5201-bis, the term "OGA" is used to > refer to the RFC4843-bis identifier, but in RFC4843-bis, it is called "OGA > ID". Suggest to modify RFC 5201-bis to rename "OGA" to "OGA ID", as > appropriate to align with RFC4843-bis. (Note that this is a proposal to > change RFC5201-bis to align with RFC4843-bis, and no RFC4843-bis action is > necessary) Ok. > I suggest to change Section 3 title from "Routing Considerations" to "Routing > and Forwarding Considerations". Also, I suggest to delete the second > paragraph; we are no longer talking about experimental, and furthermore, the > MUST NOT clause gets into implementation issues. The first paragraph already > recommends to handle this via configuration. While I agree we are no longer talking about experimental, are we sure we want to leave out the recommendation that the ORCHID prefix not be hardcoded into data path? Seems to me it is still valuable. > Perhaps it may also be clearer (in separating routing from forwarding in this > section) to add a paragraph, after the existing first paragraph, dealing with > routing: > > "ORCHIDs are not designed for use in IPv6 routing protocols, since such > routing protocols are based on the architectural definition of IPv6 > addresses. Future non-IPv6 routing systems, such as overlay routing systems, > may be designed based on ORCHIDs. Any such ORCHID-based routing system is > out of scope of this document." Ok. > I would suggest to delete the Section 3.1 entirely, as it still refers to the > RFC4843 experiment and the discussion is out of scope, IMO. Ok. > Section 4: Could this section be moved to an appendix, or just refer back to > RFC 4843? I also do not agree that the probability of collision is > negligible; it can happen trivially if a host's keys are reused (consider a > copied virtual machine). If this section is retained in some fashion, I > recommend to delete the second paragraph, and to provide the caveat that "so > long as keys are not reused" to the first paragraph. I also don't recommend > going into a discussion of a node-wide unified database of ORCHIDs, since it > seems out of scope. Ok. Will move to appendix, and add the key reuse caveat, as well as remove the discussion on the node-wide database. > > Nits: > Abstract: Cryptographic is misspelled in the abstract. Ok. > Section 1: suggest to remove the adjective "vanilla", as it is colloquial > terminology Ok. Will replace by normal or regular. > Section 1.2: > "Non-routability at the IP layer, by design." By design, or by policy? I guess by design, since we are not providing the means to route at the IP layer - they do not have prefix on which longest prefix match can occur... > Section 2: Prefix should be changed from (IANA TBD 2001:11::/28 ?) to > perhaps (IANA TBD 2001:?::/28) Ok. > References: I suppose it should refer back to 4843 as informative; also > RFC5201-bis is now updated from draft version 9. Ok. --julien _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
