> 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
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"