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

[Brian E Carpenter <[e-mail]>]

Lakshimnath,

Right now (11:15 a.m.) there isn't a DISCUSS at all. I want to hear more
from Sam before I decide whether to follow Scott's advice... Please
wait until after the telechat when I'm sure Russ will contact you.

    Brian

Dondeti, Lakshminath wrote:
> 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: [e-mail] on behalf of Scott W Brim
> Sent: Thu 1/19/2006 7:11 AM
> To: Brian E Carpenter
> Cc: [e-mail]
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/gen-art
> 
> 
> 
> 
> 


_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art