Actually, can you comment quickly on Sam's points:
1) Misuse of ASN.1. The document cites the 1997 ASN.1, but has a
number of choices and structures that seem like they are intended to
be extended in the future. Without extensibility markers, a
conforming implementation will reject a sequence or choice with
elements not permitted by the abstract syntax.
2) There is no extensibility or versioning strategy described in the
document. How do we add fields? What should recipients of a token do
if they do not understand part of it?
3) It's not clear that the GSAKMP document combined with this document
provides enough mandatory to implement features that any two
implementations of this specification will work together. The GSAKMP
document specifies mandatory to implement mechanisms for GSAKMP.
However the policy token allows for a wide variety of combinations of
protocols. For example, a policy token could specify one protocol for
registration, one protocol for rekey, and a completely different
protocol for de-registration. If only one of these is GSAKMP, what
happens? Where is it specified what combinations a GM, a GC/KS etc
must support in terms of policy token contents?
Thanks
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: [EMAIL PROTECTED] on behalf of Scott W Brim
Sent: Thu 1/19/2006 7:11 AM
To: Brian E Carpenter
Cc: [email protected]
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
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
