[Gen-art] review of draft-ietf-msec-policy-token-sec-05.txt

Scott W Brim <sbrim@cisco.com> Thu, 19 January 2006 15:12 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzbSP-0006Yf-Pi; Thu, 19 Jan 2006 10:12:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzbSN-0006YY-SI for gen-art@megatron.ietf.org; Thu, 19 Jan 2006 10:12:12 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29847 for <gen-art@ietf.org>; Thu, 19 Jan 2006 10:10:44 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezbav-0002Z2-BP for gen-art@ietf.org; Thu, 19 Jan 2006 10:21:02 -0500
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 19 Jan 2006 07:12:01 -0800
X-IronPort-AV: i="3.99,385,1131350400"; d="scan'208"; a="1768136696:sNHT70787040"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k0JFBuQV004336; Thu, 19 Jan 2006 07:12:01 -0800 (PST)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 Jan 2006 10:11:59 -0500
Received: from [127.0.0.1] ([161.44.11.166]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 Jan 2006 10:11:58 -0500
Message-ID: <43CFAC3D.7060006@cisco.com>
Date: Thu, 19 Jan 2006 16:11:57 +0100
From: Scott W Brim <sbrim@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051201 Thunderbird/1.5 Mnenhy/0.7.3.0
MIME-Version: 1.0
To: Brian E Carpenter <brc@zurich.ibm.com>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Jan 2006 15:11:58.0970 (UTC) FILETIME=[B164F5A0:01C61D0A]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Content-Transfer-Encoding: 7bit
Cc: gen-art@ietf.org
Subject: [Gen-art] review of draft-ietf-msec-policy-token-sec-05.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Sender: gen-art-bounces@ietf.org
Errors-To: gen-art-bounces@ietf.org

Summary: discuss, particularly adopt most of what Sam said.

I am reading Sam's notes and I disagree with the first part of what he
says, on flexibility.  I spent some time with some pioneers of msec so
I may be biased but there are only two flexibility mechanisms, applied
repeatedly.  Also the design is for a very constrained multicast
environment: one-to-many with central registration.  Therefore I don't
believe his comments about flexibility or multicast (as a whole) apply
here.

On the other hand, everything he says in the middle is powerful
and blocks it in my mind.

I don't believe he should have abstained, because I believe everything
listed can be fixed.  Why allow for multiple protocols instead of
GSAKMP?  First, perhaps the WG chairs have a good technical answer;
and if they don't, that can be fixed rather directly.

So it's just a significant discuss, with questions.

Other medium-to-small nits:

  "registration provides a list of acceptable registration and
  deregistration policy and mechanisms that may be used to manage
  member-initiated joins and departures from a group.  A NULL sequence
  indicates that the group does not support registration and
  deregistration of members.  A member MUST be able to support at
  least one set of Registration mechanisms in order to join the group.
  When multiple mechanisms are present, a member MAY use any of the
  listed methods.  The list is ordered in terms of Group Owner
  preference.  A member MUST choose the highest listed mechanism that
  local policy supports."

First, I assume that a NULL sequence contains nothing -- there isn't a
sequence element that is an explicit null.  If true, then when the
list is null a member CANNOT support at least one of the mechanisms --
there aren't any.  Prefix that sentence with "if the list is not null
...", avoid complaints later.

Second, in the last sentence, change "highest" to something like
"first listed".  Again, avoid ambiguity.

Next paragraph, re "rekey": same comment about "highest".

I don't see anywhere where the group owner is indicated in
signaling.  How is it known?  Say so explicitly.

Finally, someone needs to examine the IANA considerations.  Aha, I see
Mr Cotton said something along those lines.


Other smaller nits:

  "Also, the members may want to verify that the access control rules
  are adequate to protect the data that the member is submitting to
  the group."

editorial: "a member may want".

  "tokenInfo provides information about the instance of the Policy
  Token (PT)."

Add something like "see Section 3.1".  This sentence as it is makes me
wonder if that's all they are going to tell me.

swb

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art