Subject: Re: [nmrg] SMI types update
From: "David T. Perkins" <[email-masked]>
To: [email-masked]
Date: Fri, 20 Jul 2001 09:53:07 -0700

HI,

Thanks for the review. I thought we had already aligned the type
assignments. I'll go look at RAP. 

Can you be more specific about the discriminated union issue? The
problem that I was showing, and I believe that I solved was how to
deal with using a discriminated union to hold the value of any
object (such as when you want to have a log of notifications,
and you need to save all the varBinds in a trap/inform). Well,
what do you do if the type of the value is a discriminated union.
If you support discriminated union can hold another discriminated
union, then how many levels is enough? So I solved it another way.

Note also that I need another section in the document, but I plan to
make it a separate document. The other section is "transition". That
is, how to use the current SMI (either v1 or v2) to transitionally
support the new data types without changing the SMI. This is where
the sparks fly.

At 11:20 AM 7/20/2001 +0200, Frank Strauss wrote:
>Hi David!
>
>David> I submitted an individual proposal today for updating the data types
>David> in the SMI. Here is the URL for it 
>David> http://www.snmpinfo.com/ftp/temp/draft-perkins-smi-addition-00.txt 
>
>David> I would appreciate some technical feedback.
>David> If I don't hear about any major problems, I plan to put the additions
>David> in SMICng and possibly smiLINT. There are certainly a few controversial 
>David> issues in the proposal. One is adding the new data types (and Counter64)
>David> to SNMPv1. Another might be adding a discriminated union, but not a
>David> union without a discriminator. Can you guys provide any good use
>David> cases for a union without a discriminator?
>
>Sorry for this late response.
>
>Yesterday I read most of the document and took down some notes, which
>are almost all editorial. 
>
>My only technical issues are:
>
>1. Consider adding IEEE quad precision floats.
>   Pro: It's defined by IEEE along with single and double.
>   Con: It's rarely implemented even in all major programming languages.
>   I guess you'd argue the con weighs heavier, and I have to agree. ;-)
>
>2. It would fine to get the ASN.1 application tags aligned with those
>   proposed in draft-ietf-sming-snmp-01.txt. Maybe, since `yours' are
>   already implemented in the NET-SNMP code, the SMING proposal should
>   be changed.
>
>So, technically I'm fine with your proposal at this point in time
>(where I did not yet really understood the discussion on nested
>discunions in the last sections).
>
>Let me know, if you'd like me to send my editorial notes.
>
> -frank

Regards,
/david t. perkins

From: Frank Strauss <[email-masked]>
To: "David T. Perkins" <[email-masked]>
Cc: [email-masked]
Subject: Re: [nmrg] SMI types update
Date: 20 Jul 2001 11:20:19 +0200
Lines: 38
Sender: [email-masked]

Hi David!

David> I submitted an individual proposal today for updating the data types
David> in the SMI. Here is the URL for it 
David> http://www.snmpinfo.com/ftp/temp/draft-perkins-smi-addition-00.txt 

David> I would appreciate some technical feedback.
David> If I don't hear about any major problems, I plan to put the additions
David> in SMICng and possibly smiLINT. There are certainly a few controversial 
David> issues in the proposal. One is adding the new data types (and Counter64)
David> to SNMPv1. Another might be adding a discriminated union, but not a
David> union without a discriminator. Can you guys provide any good use
David> cases for a union without a discriminator?

Sorry for this late response.

Yesterday I read most of the document and took down some notes, which
are almost all editorial. 

My only technical issues are:

1. Consider adding IEEE quad precision floats.
   Pro: It's defined by IEEE along with single and double.
   Con: It's rarely implemented even in all major programming languages.
   I guess you'd argue the con weighs heavier, and I have to agree. ;-)

2. It would fine to get the ASN.1 application tags aligned with those
   proposed in draft-ietf-sming-snmp-01.txt. Maybe, since `yours' are
   already implemented in the NET-SNMP code, the SMING proposal should
   be changed.

So, technically I'm fine with your proposal at this point in time
(where I did not yet really understood the discussion on nested
discunions in the last sections).

Let me know, if you'd like me to send my editorial notes.

 -frank

Date: Fri, 13 Jul 2001 15:05:45 -0700
To: [email-masked]
From: "David T. Perkins" <[email-masked]>
Subject: [nmrg] SMI types update
Sender: [email-masked]

HI,

I submitted an individual proposal today for updating the data types
in the SMI. Here is the URL for it 
http://www.snmpinfo.com/ftp/temp/draft-perkins-smi-addition-00.txt 

I would appreciate some technical feedback.
If I don't hear about any major problems, I plan to put the additions
in SMICng and possibly smiLINT. There are certainly a few controversial 
issues in the proposal. One is adding the new data types (and Counter64)
to SNMPv1. Another might be adding a discriminated union, but not a
union without a discriminator. Can you guys provide any good use
cases for a union without a discriminator?

Feedback welcome.

Regards,
/david t. perkins