Re: [KAMADA Ken'ichi] Re: [Gen-art] Gen-Art LC Review: draft-ietf-kink-kink-11.txt

Sam Hartman wrote:
>=20
> Any objections?
>=20
>=20
>=20
> -----------------------------------------------------------------------=
-
>=20
> Subject:
> Re: [Gen-art] Gen-Art LC Review: draft-ietf-kink-kink-11.txt
> From:
> "KAMADA Ken'ichi" <[email protected]>
> Date:
> Wed, 14 Dec 2005 20:00:45 +0900
> To:
> [email protected], [email protected]
>=20
> To:
> [email protected], [email protected]
> CC:
> [email protected], [email protected],=20
> [email protected], [email protected],=20
> [email protected], [email protected], [email protected]
>=20
> Return-Path:
> <[email protected]>
> Received:
> from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus=20
> v2.1.16-IPv6-Debian-2.1.16-10) with LMTP; Wed, 14 Dec 2005 06:03:02 -05=
00
> X-Sieve:
> CMU Sieve 2.2
> Return-Path:
> <[email protected]>
> Received:
> from south-station-annex.mit.edu (SOUTH-STATION-ANNEX.MIT.EDU=20
> [18.72.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)=
)=20
> (No client certificate requested) by suchdamage.org (Postfix) with ESMT=
P=20
> id 7EDF5138AA for <[email protected]>; Wed, 14 Dec 2005 06:03:01=20
> -0500 (EST)
> Received:
> from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU=20
> [18.7.21.83]) by south-station-annex.mit.edu (8.12.4/8.9.2) with ESMTP=20
> id jBEB2uWI005653 for <[email protected]>; Wed, 14 Dec 2005=20
> 06:02:58 -0500 (EST)
> Received:
> from nasten.nanohz.org (220x218x5x242.ap220.ftth.ucom.ne.jp=20
> [220.218.5.242]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with=20
> ESMTP id jBEB0hqA021256 for <[email protected]>; Wed, 14 Dec 2005=20
> 06:00:43 -0500 (EST)
> Received:
> from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org=20
> (Postfix) with ESMTP id 3777D64; Wed, 14 Dec 2005 20:00:38 +0900 (JST)
> Received:
> from mitana.nanohz.org ([2001:240:2:0:202:8aff:fefa:bec0]) by=20
> nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 0MGcs7; Wed, 14 Dec=20
> 2005 20:00:41 +0900 (JST)
> Message-ID:
> <20051214200045JK%[email protected]>
> In-Reply-To:
> <[email protected]>
> References:
> <[email protected]> <20051214093320JG%[email protected]>=20
> <[email protected]>
> User-Agent:
> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanj=F2)=20
> APEL/10.6 Emacs/22.0.50 (i386-unknown-netbsdelf3.99.9) MULE/5.0 (SAKAKI=
)
> X-Scanned-By:
> MIMEDefang 2.42
> X-Spam-Checker-Version:
> SpamAssassin 3.0.2 (2004-11-16) on solipsist-nation.suchdamage.org
> X-Spam-Status:
> No, score=3D-1.4 required=3D5.0 tests=3DBAYES_00,FORGED_RCVD_HELO=20
> autolearn=3Dham version=3D3.0.2
> MIME-Version:
> 1.0
>=20
>=20
> At Tue, 13 Dec 2005 19:49:41 -0500,
> "Joel M. Halpern" <[email protected]> wrote:
>=20
>>But the document never actually states that encapsulation rule.
>>I could tell from the examples that was what you intended.
>>But the words need to actually say it.
>>
>>The current text of KINK_ENCRYPT just states that it carries some=20
>>sub-values.  It does not state what the sub-values are, nor that if use=
d it=20
>>should carry all content except the KINK_AP_REQ.
>=20
>=20
> I see your point.
> I added a paragraph about the content of KINK_ENCRYPT in section 6.
> Some notes:
>  1) As I also think message construction is suitable for section 6
>     (as with Sakane-san), I added the paragraph there.
>  2) DELETE and STATUS messages may also contain a KINK_ENCRYPT
>     payload.  I'd like to add the description in the generic part of
>     section 6 rather than in the subsection of each command/reply.
>=20
> BTW, when clarifying KINK_ENCRYPT, I noticed that section 6.3
> indicates that KINK_ENCRYPT in a CREATE message is optional.
> I suspect this is a mistake.
> Mike, could you confirm this is not intentional?
> If not, I'd like to change that as well.

It was intentional that KINK_ENCRYPT was optional -- for everything.
I don't really feel very strongly about it at this point other than
general nervousness about making big changes in the document at
this point with a good possibility that the document will be
inconsistent.

		Mike