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

In the end I made Sam's three points into a DISCUSS and I'm awaiting
feedback.

     Brian

Scott W Brim wrote:
> 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