Subject: [MIB-DOCTORS] How to do an "Unsigned64" data type...

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Thu, 26 Mar 2009 19:07:56 -0700

RFC4181 may be helpfull states:

4.6.1.3.  CounterBasedGauge64

   SMIv2 unfortunately does not provide 64-bit integer base types.  In
   order to make up for this omission, the CounterBasedGauge64 textual
   convention is defined in HCNUM-TC [RFC2856].  This TC uses Counter64
   as a base type, but discards the special counter semantics, which is
   allowed under the generally accepted interpretation of RFC 2579
   Section 3.3.  It does inherit all the syntactic restrictions of that
   type, which means that it MUST NOT be subtyped and that objects
   defined with it MUST NOT appear in an INDEX clause, MUST NOT have a
   DEFVAL clause, and MUST have a MAX-ACCESS of read-only or
   accessible-for-notify.

   This TC SHOULD be used for object definitions that require a 64-bit
   unsigned data type with gauge semantics.  If a 64-bit unsigned data
   type with different semantics is needed, then a different TC based on
   Counter64 MUST be used, since one TC cannot refine another (cf. RFC
   2579 Section 3.5).

But since this type of solution does not allow for read-write, I wonder how we can help
IEEE 802.1 with the below question:

The syntax checking tools bleat if I try to define an Unsigned64 TC or even 
a FqtssUnsigned64 - viz:
       FqtssUnsigned64 ::= TEXTUAL-CONVENTION
           DISPLAY-HINT "d"
           STATUS      current
           DESCRIPTION
               "An unsigned integer in the range
                0..18446744073709551615."
111        SYNTAX INTEGER (0..18446744073709551615)
   (5) warning: use Integer32 instead of INTEGER in SMIv2
   (2) range limits must be `lower-bound .. upper-bound'
Any ideas?
Regards,
Tony

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 27 Mar 2009 07:04:15 +0100

> RFC4181 may be helpfull states:

[...]  

> But since this type of solution does not allow for read-write, I

The APPICATION-MIB (RFC2564) has this TC:

Unsigned64TC ::= TEXTUAL-CONVENTION
    STATUS current
    DESCRIPTION
        "A non-negative 64-bit bit integer, without counter
         semantics."
    SYNTAX Counter64

This work predates the RFC4181 definition. 

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Fri, 27 Mar 2009 09:29:57 -0700

Yep, but as far as I can tell, in all cases it is used (in rfc2564 at least) it is used
for read-only objects. And that was/is the limitation that RFC4181 has put on
this method. And IEEE 802.1 want to have a read-write Unsigned64.

I am not sure I understand why we cannot allow read-write if we state
that the Counter64 semantics are not applicable. Dos anyone remember?

Bert
  ----- Original Message ----- 
  From: Juergen Schoenwaelder 
  To: Bert Wijnen (IETF) 
  Cc: MIB Doctors (E-mail) 
  Sent: Thursday, March 26, 2009 11:04 PM
  Subject: Re: [MIB-DOCTORS] How to do an "Unsigned64" data type...

  [...]  

  /js

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 28 Mar 2009 19:17:29 -0700 (PDT)

RFC 4181 merely summarized what was already spelled out in RFC 2856.  
Look in the latter document for the explanation (or ask the editors, 
if the explanation therein does not answer your question).

Mike Heard
RFC 4181 Editor (retired)

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 29 Mar 2009 21:52:16 -0700

Hi -

> From: "Bert Wijnen (IETF)" <[email-masked]>
> To: "Juergen Schoenwaelder" <[email-masked]>
> Cc: "MIB Doctors (E-mail)" <[email-masked]>
> Sent: Friday, March 27, 2009 9:29 AM
...
> that the Counter64 semantics are not applicable. Dos anyone remember?

The restriction on MAX-ACCESS in this case comes from RFC 2578
clause 7.1.10, and not from the TC definition.

Randy

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Mon, 30 Mar 2009 05:13:37 -0700

Yes, I do/did see that.
I am wondering if anyone remembers WHY we made that
restriction!?

Bert
  ----- Original Message ----- 
  From: Randy Presuhn 
  To: MIB Doctors (E-mail) 
  Sent: Sunday, March 29, 2009 9:52 PM
  Subject: Re: [MIB-DOCTORS] How to do an "Unsigned64" data type...

  Hi -

  ...

  Randy

  _______________________________________________
  MIB-DOCTORS mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: "Bert Wijnen" <[email-masked]>
Date: Mon, 30 Mar 2009 05:49:47 -0700

Reading the RFC2856 sect 2.2... I do see what is siad.
So I guess we must tell IEEE802.1 that the only solution is to use 2 Unsigned32 Objects.
I do not believe that this (IEEE802.1 proposal):

       FqtssUnsigned64    ::= TEXTUAL-CONVENTION
            DISPLAY-HINT  "d"
            STATUS             current
            DESCRIPTION   "An unsigned integer in the range 0..18446744073709551615."
            SYNTAX INTEGER (0..18446744073709551615)

is acceptable, is it?
I would think that some SNMP engine implementations may have trouble with that

Bert

  ----- Original Message ----- 
  From: C. M. Heard 
  To: Bert Wijnen (IETF) 
  Cc: Juergen Schoenwaelder ; MIB Doctors (E-mail) 
  Sent: Saturday, March 28, 2009 7:17 PM
  Subject: Re: [MIB-DOCTORS] How to do an "Unsigned64" data type...

  Mike Heard

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 30 Mar 2009 16:16:16 +0200

On Mon, Mar 30, 2009 at 02:49:47PM +0200, Bert Wijnen wrote:

> Reading the RFC2856 sect 2.2... I do see what is siad.  So I guess
> we must tell IEEE802.1 that the only solution is to use 2 Unsigned32
> Objects.

This is what RFC 2564 has to offer:

This Proposed Standard says "without counter semantics" and this may
conflict (depending on your interpretation) with section 2.2. of RFC
2856 (also a Proposed Standard), which is motived by section 7.1.10 of
RFC 2578, which is about the _counter_ Counter64. Yes, we all agree
that it is a dirty hack to rule away semantics of base types in TCs
but since the SNMP community was unable to create a proper solution
for this, we should probably find a way out which does not make the
usage of SNMP harder than really needed.

The question really is what IEEE needs (do they really need writable
64-bit objects or can this be avoided?) and what can break if they
were to use Unsigned64TC for writable 64-bit objects. Are there SNMP
engines that won't send a PDU that includes Unsigned64TC objects in a
set-request? Or are we "just" talking about MIB compilers generating
warnings or test automated suites generating improper test cases?

While some tools might not have support to send Counter64 objects in
set-requests, I assume this is less likely the case on the API level.
Are there APIs out there which would prevent someone from sending a
Counter64 object in a set-request?

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 30 Mar 2009 16:23:06 +0200

To the question: 

> The question really is what IEEE needs (do they really need 
> writable 64-bit objects or can this be avoided?)

The answer is: yes, they need writable 64-bit objects. 

Now the question remains whether we can recommend them to use the
Unsigned64TC imported from RFC 3564 (they tried to define something
similar of their own, but it would be better I believe if they IMPORT it
from an IETF RFC), or we should just tell them 'no way' and recommend to
use two Unsigned32 objects and mention in the DESCRIPTION clauses that
write operations are allowed only if both objects are included in the
same SetRequest PDU? 

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen 
> Schoenwaelder
> Sent: Monday, March 30, 2009 5:16 PM
> To: Bert Wijnen
> Cc: C. M. Heard; MIB Doctors (E-mail)
> > Reading the RFC2856 sect 2.2... I do see what is siad.  So 
> I guess we 
> > must tell IEEE802.1 that the only solution is to use 2 Unsigned32 
> > Objects.
> 
> This Proposed Standard says "without counter semantics" and 
> this may conflict (depending on your interpretation) with 
> section 2.2. of RFC
> 2856 (also a Proposed Standard), which is motived by section 
> 7.1.10 of RFC 2578, which is about the _counter_ Counter64. 
> Yes, we all agree that it is a dirty hack to rule away 
> semantics of base types in TCs but since the SNMP community 
> was unable to create a proper solution for this, we should 
> probably find a way out which does not make the usage of SNMP 
> harder than really needed.
> 
> The question really is what IEEE needs (do they really need 
> writable 64-bit objects or can this be avoided?) and what can 
> break if they were to use Unsigned64TC for writable 64-bit 
> objects. Are there SNMP engines that won't send a PDU that 
> includes Unsigned64TC objects in a set-request? Or are we 
> "just" talking about MIB compilers generating warnings or 
> test automated suites generating improper test cases?
> 
> While some tools might not have support to send Counter64 
> objects in set-requests, I assume this is less likely the 
> case on the API level.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 30 Mar 2009 18:04:21 +0200

> write operations are allowed only if both objects are included in the

I think it will be helpful to have reasoning why something does not
work. Using two Unsigned32 objects surely will work but it comes with
some extra effort. I see these potential problems with writable
Counter64 tagged objects:

1. compilers generating warnings
   (-> easy, ignore them)

2. generic tools like snmpset do not write Counter64 tagged values 
   (-> might be a deployment hassle)

3. snmp agents rejecting Counter64 tagged values in set-requests
   (can implementors confirm that toolkits do this sort of thing?)

4. snmp management APIs refusing Counter64 values in set-requests 
   (can implementors confirm that APIs do this sort of thing?)

It is too bad that the SNMP community never managed to properly solve
this 64-bit number problem...

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 30 Mar 2009 09:19:16 -0700

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Bert Wijnen" <[email-masked]>
> Cc: "C. M. Heard" <[email-masked]>; "MIB Doctors (E-mail)" <[email-masked]>
> Sent: Monday, March 30, 2009 7:16 AM
...
> Are there SNMP

My recollection (it's been a long time since I worked with the code) is
that the PEER code would be able to generate a set request for an
Unsigned64TC object.  For the command responder side, however,
I'm pretty sure the MIB compiler would not generate the guts of the "set"
method for machines which did not have native 64-bit integer support.
(Indeed I know the compiler strictly enforced the "no settable counters"
CLR.)  I don't recall a hard-coded "reject sets of counter types" test in the
code; I'm pretty sure the code/data structures generated by the MIB
compiler were responsible for enforcing that.

> Counter64 object in a set-request?

My recollection of the API used for BMC PATROL knowledge modules
is that it went to some lengths to prevent applications from sending
illegal requests, and would *probably* prevent such a request from
being sent.  However, someone with more recent experience in that
environment should confirm/deny.

Randy