Scott G. Kelly wrote: > Hi Ted, > > I'm a little surprised at your assessment of my position on question > #2, so I think I must have been unclear. Here's your summary: > >> Scott G. Kelly > > > 1. SHOULD/MUST (for 3 only) > > 2. MUST NOT > > 3. SHOULD > > Here's what I said for #2: > >> NONE of the above - why even mention this? I doubt there are many >> 100% compliant implementations for the first round of ipsec, and find >> it highly unlikely that this will change. Implementations that don't >> care about fragment security probably don't care about port/protocol >> differentiation. The two seem incompatible and unlikely. I can't >> believe we've wasted so much time/energy on this. > > > I'm sorry that this was unclear. What I meant to say was, why even > mention this in the draft at all - why make it an option? I agree - even mentioning it just confuses things. There are no other cases where packets from a single SPI entering on a single interface with the same addresses and ports are handled by different SPD entries. I can't imagine why anyone would think separating the two would be a good thing, and if the policies are different, a dangerous thing. ... > That's not a clear selection of one of the terms you asked for, but it's > definitely not a MUST NOT. I guess I should have used the RFC2119 > language, in which case I might say "SHOULD NOT", meaning someone that > really knows what they are doing might have justification, but this > should not be casually undertaken. I think the current draft rev gives > cautions for ipv6, but we might want similar cautions for ipv4. Anyone who wants to violate a spec can do so at their own peril. The MUST NOT would be to suggest this is a dangerous thing, with otherwise uncontrolled consequences. IMO, if it's mentioned at all, it is definitely MUST NOT. Joe
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec