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. 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) 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. 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." 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. 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. Nits: Abstract: Cryptographic is misspelled in the abstract. Section 1: suggest to remove the adjective "vanilla", as it is colloquial terminology Section 1.2: "Non-routability at the IP layer, by design." By design, or by policy? Section 2: Prefix should be changed from (IANA TBD 2001:11::/28 ?) to perhaps (IANA TBD 2001:?::/28) References: I suppose it should refer back to 4843 as informative; also RFC5201-bis is now updated from draft version 9. _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
