I lean towards (3) because IPsec without IKE or something is unmanageable. I could support MUST or SHOULD, or a conditional statement, and would prefer linking to IKEv2 as part of the package. Thomas hinted at the "chicken and egg" problem with IKEv2 - we'd like to mandate it to encourage implementation, but hesitate to mandate something that hardly exists in the near future...
But I would go along with Brian's sentiment about IETF not dictating use; that has been said a few times in various ways during this discussion. Reality is even if 4294 is not updated, it makes no difference to the actual implementation and use of IPsec; if revision says nothing about IPsec, it makes no difference. If the revision says SHOULD or MUST, probably makes no difference. Implementors will make their own choices as will buyers of products. Brian E Carpenter wrote: > On 2008-02-28 09:34, James Carlson wrote: > >> Dow Street writes: >> >>> 1. the Internet *does not* need a mandatory security mechanism at >>> the IP layer >>> 2. the Internet *does* need a mandatory security mechanism at the IP >>> layer, but IPsec is not the right one because it is too heavyweight >>> 3. the Internet *does* need a mandatory security mechanism at the IP >>> layer, but IPsec *alone* is insufficient (without IKE, key mgmt, etc) >>> 4. I don't care about the architecture of the Internet, because I >>> intend to develop devices that are never connected to the global >>> Internet (and therefore play no role in defining the Internet >>> architecture or adhering to Internet best practices). >>> >> I suppose I'm closest to (1) in your list, but I'd still phrase it >> differently. >> >> 5. IP itself works properly without IPsec -- and demonstrably so. >> It's not a _requirement_; it's not something that without which IP >> simply fails to operate. It's desirable, and likely highly >> desirable, but it's not a fundamental issue. >> > > I'm close to this position too, but even closer to > > 6. As long as the IETF specifies a way of securing the IP layer, > it's an implementation, procurement and operational issue > whether it gets used. Words in an RFC have no control over that. > > And don't forget what Thomas said about keying. > > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
