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

[Lakshminath Dondeti <[e-mail]>]

Just to clarify a bit further, issues 1 and 2 are on the use of ASN 
and the proposed responses for (1) and (2) together address those issues.

Lakshminath

At 01:59 PM 1/23/2006, Lakshminath Dondeti wrote:
>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


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