Any objections?
------------------------------------------------------------------------
Subject:
Re: [Gen-art] Gen-Art LC Review: draft-ietf-kink-kink-11.txt
From:
"KAMADA Ken'ichi" <kamada@xxxxxxxxxx>
Date:
Wed, 14 Dec 2005 20:00:45 +0900
To:
joel@xxxxxxxxxxxxxxxx, mat@xxxxxxxxx
To:
joel@xxxxxxxxxxxxxxxx, mat@xxxxxxxxx
CC:
hartmans-ietf@xxxxxxx, brc@xxxxxxxxxxxxxx,
Shouichi.Sakane@xxxxxxxxxxxxxxx, Ken-ichi.Kamada@xxxxxxxxxxxxxxx,
jtrostle@xxxxxxxxxxxxx, vilhuber@xxxxxxxxx, derek@xxxxxxxxx
Return-Path:
<kamada@xxxxxxxxxx>
Received:
from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus
v2.1.16-IPv6-Debian-2.1.16-10) with LMTP; Wed, 14 Dec 2005 06:03:02 -0500
X-Sieve:
CMU Sieve 2.2
Return-Path:
<kamada@xxxxxxxxxx>
Received:
from south-station-annex.mit.edu (SOUTH-STATION-ANNEX.MIT.EDU
[18.72.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested) by suchdamage.org (Postfix) with ESMTP
id 7EDF5138AA for <hartmans@xxxxxxxxxxxxxx>; Wed, 14 Dec 2005 06:03:01
-0500 (EST)
Received:
from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
[18.7.21.83]) by south-station-annex.mit.edu (8.12.4/8.9.2) with ESMTP
id jBEB2uWI005653 for <hartmans@xxxxxxxxxxxxxx>; Wed, 14 Dec 2005
06:02:58 -0500 (EST)
Received:
from nasten.nanohz.org (220x218x5x242.ap220.ftth.ucom.ne.jp
[220.218.5.242]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with
ESMTP id jBEB0hqA021256 for <hartmans-ietf@xxxxxxx>; Wed, 14 Dec 2005
06:00:43 -0500 (EST)
Received:
from nasten.nanohz.org (localhost [127.0.0.1]) by nasten.nanohz.org
(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
nasten.nanohz.org (smtpsugar 1.1) with ESMTPA id 0MGcs7; Wed, 14 Dec
2005 20:00:41 +0900 (JST)
Message-ID:
<20051214200045JK%kamada@xxxxxxxxxx>
In-Reply-To:
<6.2.1.2.0.20051213194823.03201060@xxxxxxxxxxxxxxxxxxxxx>
References:
<439EF12A.6090809@xxxxxxxxx> <20051214093320JG%kamada@xxxxxxxxxx>
<6.2.1.2.0.20051213194823.03201060@xxxxxxxxxxxxxxxxxxxxx>
User-Agent:
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjò)
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=-1.4 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO
autolearn=ham version=3.0.2
MIME-Version:
1.0
At Tue, 13 Dec 2005 19:49:41 -0500,
"Joel M. Halpern" <joel@xxxxxxxxxxxxxxxx> wrote:
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
sub-values. It does not state what the sub-values are, nor that if used it
should carry all content except the KINK_AP_REQ.
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.
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.