[Hipsec] RFC5206-bis and next steps

["Henderson, Thomas R" <[e-mail]>]

Similar to what was started for RFC 4423 and 5201, I posted a new version of RFC 5206 as draft-henderson-hip-rfc5206-bis-00.  Presently it is the same as RFC 5206.  I intend to use the trac issue tracker once I can access it.
http://tools.ietf.org/id/draft-henderson-hip-rfc5206-bis-00.txt

Since RFC5206 was written, we've had a number of developments:

1) NAT traversal draft (soon to be RFC):
http://tools.ietf.org/html/draft-ietf-hip-nat-traversal-09

2) mobility management aspects of NAT traversal:
http://tools.ietf.org/html/draft-melen-hip-nat-mm-00

3) There has been work from a couple of implementation teams on cross-family handovers (which were largely out of scope of RFC 5206; briefly mentioned in Section 3.2.7)

4) shim6 has published RFC 5334 that does failure detection and locator pair exploration for shim6 contexts, but also has applicability to HIP.

5) Mobile router draft
http://tools.ietf.org/html/draft-melen-hip-mr-02

My first question is how to scope the RFC5206 revision to take into account this additional work.  On one hand, Gonzalo has previously requested that, while we can rewrite/reorganize the RFC to improve clarity, we should avoid adding functionality.  On the other, it seems to me to be hard to ignore this additional progress when revising RFC5206bis, because I think we would like to avoid asking the future implementor to guess how one set of mechanisms (for traditional mobility management) interact with another (when NAT traversal is in use).

My recommendation would be to make RFC5206bis be NAT-aware and cross-family capable, but leave out the mobile router work (keep the scope to be end-to-end mechanisms).  I think we should somehow reconcile the similar but slightly different approaches to determining working locator pairs that can be found in RFC5206, ICE, and RFC5534.

My second question is about use cases and document organization.  Use cases are very important to document so that people understand how these mechanisms work, but there are quite a few possibilities (permutations) such as whether rekeying is simultaneously occurring or not, in what order the events occur, whether NAT traversal occurs or not (moving into and from a NATted environment), how mobility events are detected or triggered, etc.  If we keep all of the use cases together with the normative material in the document, the document may get quite large.

Another option to having a single document is to keep RFC5206bis focused on normative material that is necessary to interoperate (e.g. messages, required elements of procedure) and keep in parallel a second informative "use cases" document that can also discuss how platform-specific or implementation-specific policies impact the operation of the protocol.  If we went down this path, we could take Section 3 from RFC5206 as well as the use cases in draft-melen-hip-nat-mm-00 and put them in a new hip-mm-use-cases document.  If this approach were to work out, it would mean that the WG would prepare two documents to replace RFC5206, one normative and one informative.  I would be inclined to at least try this approach.

Any comments or feedback on these choices?

- Tom