Subject: #42 [-] Wording

From: Shoichi Sakane <[email-masked]>
Date: Wed, 11 May 2005 17:28:58 +0900

Hi, all.
Let's resume discussion of making our draft.

>>#42 [-] Wording
>>(waiting a revision)
>>
>>	Section 4.3, discussing attributes, mixes singular and plural
>>	indications.

If Ken indicated the following sentence;

   The initiator MUST check to see if the optimistic payload was selected by
   comparing all transforms and attributes which MUST be identical from
   the initiator's optimistic proposal with the lone exception of
   LIFE_KILOBYTES and LIFE_SECONDS.

then I think that the original text in the section 4.3 is nearly correct.
because a single proposal can contain multiple transforms, for example,
using both ESP and AH.  and regardless of that, a transform can contain
multiple attributes.

>>                    The word "lone" appears to be popular with the author,
>>	too. :-)  (Ken Raeburn)

kink payloads can logically chain infinitely.  so i guess the author
used the word.  i propose that the section 7.3 should be placed before
the section 4.3.  we can reduce using the word because the seciton 7.3
explains the kink packet structure.

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Wed, 11 May 2005 18:18:12 +0900

# I know such a subtle English matter is beyond me...

At Wed, 11 May 2005 17:28:58 +0900,
> using both ESP and AH.  and regardless of that, a transform can contain

I agree that this is just a wording issue.
How about this:

   The initiator MUST check to see if the optimistic payload was
   selected by comparing all transforms and attributes which MUST be
   identical from those in the initiator's optimistic proposal with the lone
                  ~~~~~~~~
   exception of LIFE_KILOBYTES and LIFE_SECONDS.  Each of these
                                                  ~~~~
   attributes MAY be set to a lower value by the respondent and still
   expect optimistic keying, but MUST NOT be set to a higher value which
   MUST generate an error.

> explains the kink packet structure.

I'm not sure but LIFE_KILOBYTES _and_ LIFE_SECONDS are two,
not "lone"?

-- 
KAMADA Ken'ichi <[email-masked]>

---

From: Michael Thomas <[email-masked]>
Date: Thu, 12 May 2005 14:53:59 -0700

>    expect optimistic keying, but MUST NOT be set to a higher value which

Good except: s/lone exception/exceptions

I'm not sure it's an error though: what does IKE do in this
case?

> > >>                    The word "lone" appears to be popular with the author,

Not any more... I've moved on :-) 

		Mike

---

From: Shoichi Sakane <[email-masked]>
Date: Tue, 17 May 2005 12:54:32 +0900

> I'm not sure it's an error though: what does IKE do in this

rfc2407 defines the exception of the lifetime handling,
a.k.a the RESPONDER-LIFETIME handling.
but it is used in case the responder set a lower value.
If my understanding is correct, it must be error because of the following
description in rfc2409.

5. Exchanges
                                                        Responders MUST
   NOT modify attributes of any offer, attribute encoding excepted (see
   Appendix A).  If the initiator of an exchange notices that attribute
   values have changed or attributes have been added or deleted from an
   offer made, that response MUST be rejected.

my proposal (currently):
	- KINK also must be error.
	- KINK doesn't need the responder-lifetime notify message.
	  it is not meaningful.  it is clear that the attribute was
	  modified by the responder.

IKEv2 does not care the lifetime.  there is no attribute.  It completely
leave the lifetime handling to the local policy.
so we should consider the necessity of the lifetime attribute in KINK.