[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-ietf-ipsec-ike-01.txt (long)
>>>>> "Dan" == Dan Harkins <dharkins@network-alchemy.com> writes:
Dan> ...
Dan> So we can mandate the support for negotiating up things like key
Dan> lengths but not require that it be done every single time. If
Dan> someone wants to have a policy that says, "128 bits no more no
Dan> less" then they are free to do that without violating any IETF
Dan> requirements just as Ran (and you, and me) is free to type
Dan> telnet 1.2.3.4 and not violate any IETF requirements.
Sounds good.
What wasn't clear before was whether you were proposing to require a
capability to ask that X be done, or requiring that X be done
(always). The DNS analogy helps.
Dan> As I stated before, the text that is causing so many people
Dan> problems is being rewritten and the word "policy" will not show
Dan> up anywhere. No one is advocating overriding any policy. But the
Dan> text said SHOULD. Some want MUST. So, keeping in mind the
Dan> difference between mandating implementation support versus
Dan> mandating use, what should it be? SHOULD or MUST? Is there a
Dan> reason not to support this capability (again, keeping in mind
Dan> the difference between mandating implementation support versus
Dan> mandating use)?
The rewrite should be useful, because clearly the previous version was
causing confusion.
I'm not entirely sure how you can state what you're proposing without
using the word "policy", or equivalent circumlocutions. So the intent
is:
a. implementations should (must?) provide a way for the user to
specify a policy of the form "128 bits or better".
b. implementations may (should? must??) also provide a way for the
user to specify a policy of the form "exactly 128 bits".
If that's right, then fine -- and I'd prefer "should" and "may"
respectively. And by the way, stating both (a) and (b) -- rather than
only (a) -- would help make the intent clearer.
paul
References: