Re: KINK should referenece to IKEv2?

My point was that I would not be happy that KINK based on 2401bis did not
work on an 2401 base platform due to market issue.  So I suggested that
it would be better to fix the specification based on 2401 first.

But, I change my mind.  I probably confused.  KINK can be based on
2401bis and can support its all feature like IKEv2.  In this case when
KINK runs on 2401, KINK doesn't use of its feature related to 2401bis,
that is all.  In fact, our IKEv2 pre-implementation based works fine
on a 2401 platform.  But it must be too much for KINK requirement
to support all feature of 2401bis.

So As I read Sam's last mail, my current opinion is that:

	- we have to describe the document complying with 2401bis wording
	  and its model.
	- we don't need to make KINK which supports all feature of 2401bis.
	- if above two are true, we don't need to take IKEv2 format by force.
	  just use almost current payloads.
	- however we have to describe how KINK works on 2401bis.
	- we have to also describe what KINK dosen't support the features
	  although it may be unnecessary.

Here is Sam's assumptions:
	1. Making Kink based on 2401bis will not require significant change.
	2. Making Kink based on 2401bis will not create significant
	   confusion for 2401 implementers.
	3. Making kink based on 2401bis will not require significant work
	   for people who have mostly complete kink implementations.

#1 is almost true.  I believe that we don't need significant change of
KINK specification, but we need to work improving the text a lot.
#2 is true.  because we don't need significant change of KINK
specification from #1.
#3 is true. because from #2.

Well, at least for me, there is no reason that we are sticking
to current specification related to 2401.