RE: comment on draft-ietf-ltans-dssc-01.txt

["Turner, Sean P." <turners@xxxxxxxx>]

>> I like the idea of moving to the later ASN.1. The reason we've been 
>> stopped in the past was the lack of an open source compiler. We 
>> basically have one now with the a2c compiler.
>>   
>I disagree that we were stopped by that. But that's an old story I hope
>> Peter - are you saying you don't want to import code, you'd rather 
>> grow your own? If you do I'd like to see how the current 
>syntax would 
>> break out if I specified an elliptic curve and all it's 
>parameters. It 
>> would be an long sequence of 'stuff' that you'd have to 
>write up some 
>> verbiage about the 1st element of the sequence was this, the next 
>> this, and so on. That seems like an unworkable solution to me.
>>   
>I have made no comment about the structure of the information 
>that this document is proposing. I just mentioned that reusing 
>a particular name 'Algorithm' 
>to define
>another but similar structure as in some other module is not a 
>good idea, and indeed defining another thing like 
>AlgorithmValidityInfo is better.
>
>I think you refer to some older message from me?
>Following your comment: Before really entering into concrete 
>syntax, it would be good to describe what abstract information 
>needs to be encoded and how a validator (an automatic tool!!) 
>is supposed to operate.
>An important requirement to me seems that when adding 
>something to the structure, the core validator doesn't change.
>
>Does that makes sense?
>P

I guess I was reacting to the thoughts of algorithm spec writers have to
have to different formats for representing their algorithms. One which is
used in most ASN.1 based security protocols and another for this. I think
picking another syntax would sink this proposal. Thomas has solved my
concern though.

spt