comments on draft-nikander-esp-beet

I have read the draft. Overall, its well written and specified. I do
have a number of comments, however:

o  The fact that you are not doing full tunnel mode semantics limits
    the application of this mode. For instance, in typical VPN setup
    we do need the full semantics but would still perhaps appreciate
    compressed headers.

    Is there a solution that would allow this? I understand the
    role of the BEET in the HIP context and how the inner identifiers
    work, and the architecture. But is tehre something that
    prevents a more general solution that would be better in
    line with the general IPsec user community, including MOBIKE?

o  Without the generalization to full tunnel mode, I think BEET
    is something that can only be with MOBIKE when you use
    either direct connections to the specific peers that you want
    to talk to. This is something that is potentially useful, but
    not as useful as the general solution would be. The limited
    solution would though become more useful if we assume a
    future where BTNS exists and can be used in connection with
    MOBIKE and BEET.

    Question: does BEET prevent usage in a situation where
    a VPN gateway is used but the IPsec SAs are specific to
    the peers that the client communicates with? I.e., not end
    to end usage but inner addresses are fixed per SA pair.

o  I remained unconvinced that the Mobile IP section is matches
    what people would like to do (or even that its correct). I can
    talk about the details off line, but my point is that the integrated
    use of BEET in application X would require further work, and
    might not be something that you want to commit to.

o  If this work comes to MOBIKE, I'd rather not see the PF_KEY
    part in the document.

--Jari