Barry Leiba has entered the following ballot position for draft-ietf-hip-native-nat-traversal-30: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Given this document’s dependency on concepts and terminology from 5770, I think that document has to be a normative reference. Can someone really understand and implement this without any reference to 5770? — Abstract — The main difference from the previously specified modes is the use of HIP messages instead of ICE for all NAT traversal procedures due to its kernel-space dependencies. The antecedent to “its” is unclear: it could be “use of HIP messages”, or “ICE”, or “NAT traversal”. Please rephrase to clarify. — Section 1 — Also, especially NATs usually require the host behind a NAT to create a forwarding state in the NAT before other hosts outside of the NAT can contact the What does “especially” mean in this sentence? It doesn’t make sense to me. Does it add anything? which will be referred as "Legacy ICE-HIP" in this document. Nit: “referred to” HIP poses a unique challenge to using standard ICE, due not only to its kernel-space implementation, but also due to its close Same comment about “its” as in the abstract: please replace “its” with what you’re talking about, as it isn’t clear. _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
