_______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
On 11/17/2015 11:52 PM, Gonzalo Camarillo wrote:
> Authors of the following drafts,
>
> could you please let the WG know their status and what needs to happen
> next for each of them in order to be able to WGLC them at some point in
> the future?
>
> https://datatracker.ietf.org/doc/draft-ietf-hip-multihoming/
> http://datatracker.ietf.org/doc/draft-ietf-hip-rfc5206-bis/
There are six open issues on RFC5206-bis, listed here:
https://tools.ietf.org/wg/hip/trac/query?component=rfc5206-bis
One of them (#12) probably should be closed now based on the draft version 09 published in July.
One related to flow bindings (#23) probably can be left for further study, with no action at this time, since it hasn't been pursued for many years.
One (#21) suggests to include HI parameter in the UPDATE, for benefit of middleboxes. Any objection to adding specification text that HI MAY be included in UPDATE?
One (#15) suggests to name UPDATE packets with different names such as UPDATE1, UPDATE2, and UPDATE3, for clarity. I wonder whether this can be handled editorially without requiring code point allocation.
One (#9) suggests to make some mandatory features optional, since at least one implementation does not implement all mandatory features. I think that perhaps this will require a review of both of the open source implementations to see whether any should be relaxed.
One (#8) asks to allow that locator announcement may be decoupled from SA creation. This requires the definition of another example use case and extending the specification.
In summary, I think that we could aim for another draft shortly that closes all of these issues. Perhaps the last one or two listed above represent the most work. Does anyone have further comments on these or other issues?
- Tom
- [Hipsec] RFC5206-bis status Tom Henderson
- [Hipsec] RFC5206-bis status Tom Henderson
- Re: [Hipsec] RFC5206-bis status Miika Komu
