[Gen-art] Re: Resolving the DISCUSS on draft-ietf-msec-policy-token-sec-05.txt (Summary)

[Lakshminath Dondeti <[e-mail]>]

Hi Brian and Scott,

Please review the following notes to see if they address your 
concerns on the MSEC Policy Token draft.  Thanks to Russ for helping 
Andrea and Uri craft some of the responses.

Please look for <Res></Res> below (there is one <LD></LD> below, 
please ignore that for now; it is related to an IANA concern).

thanks and regards,
Lakshminath

At 01:31 PM 1/23/2006, Lakshminath Dondeti wrote:




>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.
>
><Res>
>The EXPORTS statement is to be removed so that any structure def can be
>exported.
>
></Res>
>
>
>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?
>
><Res>
>A Policy Token version indicator is to be added to the TokenID.
>
></Res>
>
><Res>
>Russ provided the following example that we might use:
>   TBSCertificate  ::=  SEQUENCE  {
>      version         [0]  Version DEFAULT v1,
>      ....
>
>   Version  ::=  INTEGER  {  v1(0), v2(1), v3(2)  }
>
>
></Res>
>
><Res>
>"Implementations encountering unknown protocol identifiers MUST handle
>this gracefully by providing indicators that an unknown protocol is among
>the sequence of permissible protocols.  If the unknown protocol is the only
>allowable protocol in the sequence, then the implementation cannot support
>that field and the member cannot join the group.
>It is a matter of local policy whether a join is permitted when
>an unknown protocol exists among other allowable, known protocols."
>
></Res>
>The above will be added to provide
>handling instructions when encountering unknown protocols.
>
>
><Res>
>Under the main token structure it will say that additional protocols
>SHOULD NOT be added unless the MSEC architecture changes.
>
></Res>
>
>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?
>
>
><Res>I understand the issue, but the token's purpose is to tie the 
>abstract MSEC
>architecture to a configurable system.  The MSEC architecture allows for any
>of these protocols for registration, de-registration, etc. and does not
>specify what the mandatory to implement protocols are.  To say that the
>appendix B and appendix C protocols are the mandatory-to-implement protocols
>would mean that the MSEC architecture now requires those protocols.  This is
>one case where I believe a mandatory to implement scheme would be a
>disservice to the community.
>
>Interoperability testing for the token, really becomes system
>interoperability testing vs. protocol interoperability testing.
></Res>
>
>
>4) IANA Comments:
>The IANA Considerations section requests that 13 object identifiers 
>be assigned.
>In which registry should these be assigned?  IANA needs clarification.
>
>
><Res>
>Statement to IANA section will essentially say that the spec is extended
>through specification.  Those specifying new objects will register them with
>IANA.  Those that change the structure of the PT must change the version
>indicator.
>
></Res>
>
><LD>
>The resolution does not address the question on "which registry" 
>should be used.  I think this requires a new registry, right?
></LD>



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