Greetings again. We have not come to resolution on this topic, and we should make another attempt before we give up.
RFC 4306 says: Although new payload types may be added in the future and may appear interleaved with the fields defined in this specification, implementations MUST send the payloads defined in this specification in the order shown in the figures in section 2 and implementations SHOULD reject as invalid a message with those payloads in any other order. There are a few problems with this. For one, there are payloads that are only a few figures in section 2; there are many more figures in section 1. Another problem is that there are plenty of payloads that are defined in RFC 4306 that are not shown in any figure in section 2; these are not "future" but current payloads. I see three options: a) Downgrade the MUST to a SHOULD without other changes. b) Remove this altogether because the paragraph is insufficient for implementation and, in part, wrong. c) Do nothing. Both (a) and (b) will cause implementations that follow the MUST and SHOULD in the paragraph to not interoperate with implementations that do not follow the given order. (a) is not completely clear. (c) leaves insufficient and unclear mandates in the document. So far, no one has said that their implementation will fail if it gets payloads that it thinks are not in the order shown in section 2. On the other hand, not all implementers of IKEv2 are reading the drafts or following this list, so that is far from definitive. Thoughts? Other ways forwards? --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
