[rohc] Comments on ROHC IKEv2 extensions

[<Pasi.Eronen at nokia.com>]

Comments on draft-ietf-rohc-ikev2-extensions-hcoipsec-02:

1) The document doesn't really describe how the negotiation works. For
example, can CREATE_CHILD_SA request contain multiple ROHC_SUPPORTED
payloads? Is the responder required to pick one of them exactly, or is
it allowed to adjust the parameters somehow? E.g. if initiator sends
MAX_CID of 100, is the responder allowed to lower this to 99? What
about the other fields? What you're supposed to do when you
e.g. receive a suboption you don't recognize?

2) I'd recommend NOT repeating the generic definition of Notify
payload; the description doesn't 100% match RFC 4306, and it's
redundant anyway.

In other words, replace the text by "The Notify Message Type for
ROHC_SUPPORTED is TBD-BY-IANA. The Protocol ID and SPI Size fields are
set to zero.  The RoHC configuration parameters are listed in the
notification data in the following format:"

3) Why does the notification data include ROHC PARAMETERS LENGTH?
(the Notify payload already includes a length field, so this seems
redundant)

4) In section 2, is the intent to define a new suboption space, or
reuse the suboption space from RFC 3241? In the former case, IANA
considerations are needed; in latter case, the text should not
repeat the definitions, but just cite RFC 3241.

5) Section 4 (IANA considerations): There are two kinds of IKEv2
notify messages (error and status); this section should tell IANA
which kind of number to allocate (status is the right one here).

6) In bit diagrams, replace this
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
with this
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

7) In reference [ROHCPROF], the URL doesn't work.

Best regards,
Pasi

_______________________________________________
Rohc mailing list
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc