Re: #42 [-] Wording

> On Wed, 2005-05-11 at 02:18, KAMADA Ken'ichi wrote:
> > # I know such a subtle English matter is beyond me...
> > 
> > At Wed, 11 May 2005 17:28:58 +0900,
> > Shoichi Sakane <[email protected]> wrote:
> > > 
> > > >>#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.
> > 
> > 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.
> 
> Good except: s/lone exception/exceptions
> 
> I'm not sure it's an error though: what does IKE do in this
> case?

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.