会议之后的日子
会议以来的这段时间里，我与 Steve Wolfe（UCLA-CCN）、Bill Crowther（BBN）以及 John Heafner 和 Erick Harslem（RAND）进行了交谈。Wolf 的意见将作为 NWG/RFC #38 发表，属于我将在下文评论的一类。
Crowther 提交了以下内容：
“简要描述在 3 月会议上所述主机协议的两种简化思路。这些思路尚未经过仔细推敲。
思路 1. 重连。
“想要重连的 NCP 告诉它的每一个邻居“我想要重连”。它们一直等到没有正在传输中的报文，然后回答“OK”。接着它说“按如下方式重连”，它们照做。在罕见的情况下，NCP 得到的回复是“我想要重连”而不是“OK”，那么一方必须继续、一方必须停止。因此，把来自较高层主机用户等的“reconnect”视为 ok，而把来自较低层的视为“不——等我重连你”，并完成连接。
思路 2
“把连接和链路解耦。仍然建立连接，但报文可以走任何顺手的链路。在收到 RFNM 之前，不要在同一条连接上再发送报文。在报文中包含源和目标套接字号。
“要重连时，对每个邻居说“请按如下方式重连我……”。把该连接保持一小段时间（几秒），并同时把报文和连接消息发往它们的目的地。我还没有想清楚如何让在途报文保持顺序，但如果你在 RFNM 尚未返回时不发出重连，大概一切都能正常工作。”
在我看来，Bill 的第一个思路既说不上决定性地更好，也（经过一番思考后）谈不上有很大不同，我正在考虑它。我对此还没有强烈的看法，但正试图形成一些看法。
Bill 的第二个思路似乎与我关于链路作用的构想相悖。支持把连接和链路解耦的一个论据是，两台主机之间的连接数可能希望超过 255，而且即便不是这样，在设计上把依赖关系隔离开来也是更稳妥的做法。另一方面，新提供的链路停止功能*（即将发布的 BBN 报告 #1822 修订版，1970 年 2 月，第 22 页）就变得无用了。（刚刚加入该功能的 Bill 并不在意。）另一个反对理由是，浪费掉用链路字段携带信息的可能性，直觉上似乎很糟糕。（请注意这种本能层面感受上的矛盾。）
在与 RAND 的 John Haefner 和 Eric Harslem 交谈时，他们指出，当前协议没有为差错检测与报告、状态测试与报告以及扩展与实验作出任何安排。差错检测和状态测试需要经过较长时间的讨论才能确定哪些有用，我预计这类讨论会在实现过程中进行。不过，为协议扩展和实验留出余地，最好现在就做。
我建议保留两个扩展区域。其一是只使用 256 条链路中的一小部分，比如前 32 条。另一个区域是使用从 255 向下递减的命令码，并把固定命令码从在用链路数向下分配到 32。我觉得在相当长一段时间内我们不太可能需要超过 32 个，而且网络大概也无法处理大量链路分配所隐含的流量。（这两件事未必强耦合：可以分配很多条链路，但在任一给定时刻只有少数几条在承载流量。）
Heafner 和 Harslem 的其他一些想法可能会以 NWG/RFC 的形式出现。
即时交互
在接下来的几天里，我仍然会对当前协议中那些可能导致其被否定或被大幅修改的批评意见感兴趣。此后，重点将放在完善、实现、扩展和使用上。可以通过我的秘书 Benita Kristel 女士在 UCLA 与我联系，电话是 (213) 825-2368。另外，欢迎所有人向 NWG/RFC 系列投稿。编号由 Benita 分配。
* 链路停止功能是接收主机修改 RFNM 的一种方式，使其携带抑制流量的含义。另一种做法是使用主机到主机的控制命令。
注: 本 RFC 由 Ron Fitzherbert 于 1/97 转换为机器可读形式，以便录入在线 RFC 档案库。