Question

请大家帮忙，翻译。本人英语不好。。

The Host Identity Protocol (HIP) [1] is an experimental effort in the IETF and IRTF to study a new public-key-based name space for use as host identifiers in Internet protocols. Fully deployed, the HIP architecture will permit applications to explicitly request the system to send packets to another named host by expressing a location-independent name of the host when the system call to send packets is performed. However, there will be a transition period during which systems become HIP-enabled but applications are not.
When applications and systems are both HIP-aware, the coordination between the application and the system can be straightforward. For example, using the terminology of the widely used sockets Application Programming Interface (API), the application can issue a system call to send packets to another host by naming it explicitly, and the system can perform the necessary name-to-address mapping to assign appropriate routable addresses to the packets. To enable this, a new address family for hosts could be defined, and additional API extensions could be defined (such as allowing IP addresses to be passed in the system call, along with the host name, as hints of where to initially try to reach the host).
This note does not define a native HIP API such as described above. Rather, this note is concerned with the scenario in which the application is not HIP-aware and a traditional IP-address-based API is used by the application. To use HIP in such a situation, there are a few basic possibilities: i) allow applications to use IP addresses as before, and provide a mapping from IP address to host identifier (and back to IP address) within the system, ii) take advantage of domain name resolution to provide the application with either an alias for the host identifier or (in the case of IPv6) the host identity tag (HIT) itself, and iii) support the use of HITs directly (without prior DNS resolution) in place of IPv6 addresses. This note describes several variations of the above strategies and suggests some pros and cons to each approach.
When HITs are used (rather than IP addresses) as peer names at the system API level, they can provide a type of “channel binding” (Section 1.1.6 of [2]) in that the ESP association formed by HIP is cryptographically bound to the name (HIT) invoked by the calling application.
请大家帮忙了，我的英语本来就不好，翻译起来很头疼，所以求助大家了。我用了翻译工具，发现翻译的不对。
用在线翻译出来的全部都是错的，我看过了，这是一篇科技英语，翻译起来很难。由于小弟英语实在不行，不得不求助于大家了

Answer 1

东道主身份协议（髋部） [ 1 ]是一个实验的努力，在为标准，并irtf研究一种新的公开密钥基础的名字空间使用作为东道主标识符的因特网协议。已全面投入使用，髋关节架构中，将许可证申请，明确要求系统发送数据包到另一个命名为东道国表示位置独立的主机名时，系统调用发送数据包的是演出。不过，有将是一个过渡期，期间系统成为髋关节功能，但应用却没有。
当应用和系统都是髋感知，单位之间的协调应用程序和系统可以直接了当的。举例来说，使用的术语广泛使用的套接字应用程序编程接口（ api ） ，申请程序可发出系统调用发送数据包到另一个主机，它的命名明确，并能履行必要的名字到地址映射到指派适当的路由地址的邮包。为了使一种新的家庭地址为主机可被界定，并实施额外的空气污染指数的扩展可以定义（如允许ip地址，以通过在系统调用，随主机名称，暗示性的情况，以初步尝试，以达到东道主） 。
这说明，没有界定本土髋部短片，例如上文所述。相反，这说明是与设想中的应用，是不是髋感知和传统的ip地址为基础的空气污染指数，是用其申请。利用髋部，在这种情况下，有几个基本的可能性：我） ，让申请使用ip地址跟以前一样，并提供了一个映射从ip地址，以主机标识符（返回ip地址） ，在本系统，二）利用域名决议，以提供应用程序要么是一个别名为东道国标识或（在案件的ipv6 ）东道国的身份标签（热闹） ，和三）支持使用点击直接（未经事先dns的决议）地点ipv6地址。这说明描述了几个变化上述战略，并提出了一些正反意见，以每一种办法。
当点击数都使用（而不是ip地址） ，作为同行的名字，在系统的空气污染指数的水平，他们可以提供一个类型的"通道具有约束力" （第1.1.6 [ 2 ] ） ，在该协会的电除尘器形成髋关节是cryptographically约束以名义（ hit ）的引用调用申请。

Answer 2

主人身分协议(臀部) [ 1 ] 是实验性努力在IETF 和IRTF 学习一个新基于公众钥匙的名空间至于使用当主人标识符在互联网协议。充分地部署,HIP 建筑学将允许应用明确地请求系统寄发小包到其它名为主人由表达主人的一个地点独立名字当系统调用送小包执行。但是, 有将是期间系统成为臀部使能但应用不是的过渡周期在。
当应用和系统是臀部明白, 协调在应用和系统之间可能是直接的。例如, 使用广泛被应用的插口应用程序编程接口的术语(API), 应用可能发布系统调用寄发小包到其它主人由明确地命名它, 并且系统可能执行必要名字对演讲映射分配适当的routable 地址到小包。使能这, 一个新地址家庭为主人能被定义, 并且另外的API 引伸能被定义(譬如允许IP 地址通过在系统调用, 与主机名一起, 作为提示在哪里最初地设法到达主人) 。
这笔记不定义一个当地臀部API 譬如描述上面。相反, 这笔记与应用不是臀部明白的情节有关并且传统基于IP 演讲的API 由应用使用。使用臀部在这样情况, 有几种基本的可能性: i) 允许应用使用IP 地址和前面, 和提供一映射从IP 地址到主人标识符(和回到IP 地址) 在系统之内, ii) 利用域名决议提供应用以或别名为主人标识符或(在IPv6 情况下) 主人身分标记(命中) 本身, 并且iii) 对命中的用途的支持(没有预先的DNS 决议) 在IPv6 位置直接地演讲。这笔记描述上述战略的几变异和建议一些利弊对各种方法。
当命中被使用(而不是IP 地址) 当同辈名字在系统API 水平, 他们能提供型 “渠道捆绑” (部分1.1.6 [ 2 ]) 因为协会特别是形成由HIP cryptographically 一定对名字(命中) 由叫的应用祈求。