|Main Archive Page > Month Archives > ipsec archives|
If that's the case, we'll remove the offending statements in the roadmap.
Just 2 more questions: even if this was a sloppy document, why is there a separate section for IKE Encrypted Payload algorithms, that contains a subset of the Transform Type 1 (encryption) algorithms? Also, is sloppiness enough to account for both NULL encryption and AES-CTR being specified for IKEv2 - and noone from the WG noticing either?
Looking through the archives for the IPsec WG (the predecessor to this one), Tero's interpretation is probably closer to what happened than Sheila's. It is unfortunately that both Sheila and Tero use the word "clearly" when talking about RFC 4307; the archive would strongly indicate that it is inappropriate to use that word when discussion RFC 4307.
We need to remember that the flight of documents coming out of the original WG included both RFC 4305 and RFC 4307. There was some sloppy cross-over of requirements due to a poor split late in the process. However, the WG seems to have wanted to have two different sets of requirements, one for IKEv2 crypto, and one for AH/ESP crypto. This is what makes me think that Tero's interpretation is closer to what happened, regardless of what words were (possibly inappropriately) left in RFC 4307 at the point that the WG became exhausted.
--Paul Hoffman, Director