RE: [Gen-art] review of draft-ietf-msec-policy-token-sec-05.txt
"Dondeti, Lakshminath" <ldondeti@qualcomm.com> Thu, 19 January 2006 16:07 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 1EzcKE-0002iP-U2; Thu, 19 Jan 2006 11:07:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzcKB-0002iH-6s for gen-art@megatron.ietf.org; Thu, 19 Jan 2006 11:07:48 -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 LAA03303 for <gen-art@ietf.org>; Thu, 19 Jan 2006 11:06:19 -0500 (EST)
Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzcSh-0004DJ-Pp for gen-art@ietf.org; Thu, 19 Jan 2006 11:16:38 -0500
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k0JG7S5m017647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 19 Jan 2006 08:07:28 -0800
Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k0JG7QF9009225; Thu, 19 Jan 2006 08:07:26 -0800 (PST)
Received: from NAEX05.na.qualcomm.com ([129.46.134.165]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 Jan 2006 08:07:26 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Gen-art] review of draft-ietf-msec-policy-token-sec-05.txt
Date: Thu, 19 Jan 2006 08:07:25 -0800
Message-ID: <992BC8ECDE438E4B8F5789A0FCCC92AD090BE4@NAEX05.na.qualcomm.com>
Thread-Topic: [Gen-art] review of draft-ietf-msec-policy-token-sec-05.txt
Thread-Index: AcYdCtlSQ0P5HTaxSy+0FCYSKub21gABdTqo
X-Priority: 1
Priority: Urgent
Importance: high
References: <43CFAC3D.7060006@cisco.com>
From: "Dondeti, Lakshminath" <ldondeti@qualcomm.com>
To: Scott W Brim <sbrim@cisco.com>, Brian E Carpenter <brc@zurich.ibm.com>
X-OriginalArrivalTime: 19 Jan 2006 16:07:26.0284 (UTC) FILETIME=[70A0C8C0:01C61D12]
X-Spam-Score: 1.3 (+)
X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503
Cc: canetti@watson.ibm.com, umeth@sparta.com, hh@sparta.com, gen-art@ietf.org, acc@sparta.com, housley@vigilsec.com
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>
Content-Type: multipart/mixed; boundary="===============0751375723=="
Sender: gen-art-bounces@ietf.org
Errors-To: gen-art-bounces@ietf.org
Thanks for the review Scott. I am one of the WG chairs of MSEC and I have answers to your questions below. -----Original Message----- From: gen-art-bounces@ietf.org on behalf of Scott W Brim Sent: Thu 1/19/2006 7:11 AM To: Brian E Carpenter Cc: gen-art@ietf.org Subject: [Gen-art] review of draft-ietf-msec-policy-token-sec-05.txt 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. <LD>MSEC group security policy token work is designed to be generic and is applicable to other group security protocols as well. I wish I could provide some existence proof, but there are plans to use the GSPT for GKDP, one of the other protocols being designed in MSEC. </ld> 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. <LD>Editorial change? I think this is ok. </LD> Second, in the last sentence, change "highest" to something like "first listed". Again, avoid ambiguity. Next paragraph, re "rekey": same comment about "highest". <LD>ok</LD> I don't see anywhere where the group owner is indicated in signaling. How is it known? Say so explicitly. <LD>I will ask Hugh et. al. to add a sentence</LD> Finally, someone needs to examine the IANA considerations. Aha, I see Mr Cotton said something along those lines. <LD>I have asked the authors to respond to the IANA concern</LD> <LD>The following are editorial, right? A final question: Is the discuss based on whether the GSPT can be used with other protocols OR to resolve Sam's comments? Please let us know. Note: I will be offline for about the next 1 hr. </LD> 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
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
- [Gen-art] review of draft-ietf-msec-policy-token-… Scott W Brim
- RE: [Gen-art] review of draft-ietf-msec-policy-to… Dondeti, Lakshminath
- Re: [Gen-art] review of draft-ietf-msec-policy-to… Brian E Carpenter
- Re: [Gen-art] review of draft-ietf-msec-policy-to… Brian E Carpenter
- [Gen-art] Re: review of draft-ietf-msec-policy-to… Brian E Carpenter