[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: