Hi Pasi, > > > 4) None of the drafts have any RFC 2119 keywords > > > (MUST/SHOULD/etc). They SHOULD use those to make it less > > > ambiguous what is the required behavior (and what is optional) to > > > claim compliance with these drafts. > > > > OK, we will take a run through the IKEv2 and IPsec extensions drafts > > to account for these keywords. Not the framework draft though, since > > the draft is intended to be informational. > > Being "Informational" (vs. Proposed Standard) RFC has nothing to do > with > the question -- many Informational RFCs do use RFC 2119 keywords, and > there's nothing special about that. > > To me, it looks like the framework draft has normative statements > (things implementations are required or recommended to do in order > to get interoperability), too, so 2119 keywords would be appropriate > (and actually, it could be Standards Track, too). OK. I just meant that the framework draft was intended to be guidance for ROHCOIPsec implementers. However, since you think there are benefits to including these keywords, I'll update the draft to include them. > > > 6) ikev2-extensions, Section 2.1.2, says "The key for this > Integrity > > > Algorithm is computed using the same method as is used to compute > > > IPsec's Integrity Algorithm key ([IKEV2], Section 2.17)." I don't > > > think this is sufficient to get interoperable implementations; more > > > details are needed. > > > > Could you clarify why this is not sufficient? > > If it's computed using exactly the same method as the IPsec Integrity > Algorithm Key, it would be the *same* key, and that's certainly not > the intent here. > > Perhaps something like "The keys (one for each direction) for this > Integrity Algorithm are derived from the IKEv2 KEYMAT (see [IKEV2], > Section 2.17). For the purposes of this key derivation, ROHC is > considered to be an IPsec protocol."? Sounds good to me. BR, Emre _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf