> I think it is a win to reduce the number of ways to accomplish the same goal. > That is why I was opposed to the publication of RFC 6467. It encourages > having multiple password methods. That is why the scep draft has an intended > status of "historic", even though I would guess that SCEP is more widely > implemented and deployed than both the standards-track protocols combined. > > Moving AH to historic can point implementers and other working groups in a > single direction.
It will also help ending repeated "ESP-NULL versus AH" discussions on various mailing lists. I have not seen a single use case where ESP-NULL cannnot be substituted for AH. Even if there are some scenarios where ESP-NULL will not work, then those folks can continue using AH and I dont see how marking AH as Historic would really affect them. I support this work and i think its time that IETF took a stand on AH (which i personally find quite useless). Ever since 4301 moved AH to a MAY, i know a few vendors that have completely stopped supporting AH. Once again, if there are environments where ESP-NULL will not work (and i guess it probably has to do with the additional header that it inserts) then those environments can continue using AH. If folks dont want to move AH to historic then perhaps this document could be modified to say something in the lines of - "AH should not be preferred when designing new protocols and all attempts must be made to use ESP-NULL" Jack _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
