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

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

Sorry, I should be clearer. I understand that a Counter64 (with Counter64 semantics) must be read-only.
I wonder why we need to stick to that if we define a TC (based on Counter64) that does annul the
Counter64 semantics and defines new semantics. Why did we decide that that can only
be read-only?

Bert
  ----- Original Message ----- 
  From: Bert Wijnen (IETF) 
  To: Randy Presuhn ; MIB Doctors (E-mail) 
  Sent: Monday, March 30, 2009 5:13 AM
  Subject: Re: [MIB-DOCTORS] How to do an "Unsigned64" data type...

  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 -

    > 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
    > Subject: Re: [MIB-DOCTORS] How to do an "Unsigned64" data type...
    ...
    > 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?

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

    Randy

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

---

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

Hi -

> To: "Randy Presuhn" <[email-masked]>; "MIB Doctors (E-mail)" <[email-masked]>
> Sent: Monday, March 30, 2009 5:16 AM
...
> Counter64 semantics and defines new semantics.
> Why did we decide that that can only be read-only?
...

This goes back to the very earliest days of SNMP.
One of the early (and in my opinion correct) bits of
dogma is that settable counters are a very bad thing.

One of the other very early decisions (with which I
still disagree) was the decision to create distinct
ASN.1 tagged types to correspond to gauges,
counters, integers, and so on.

(When SNMPv2 was under construction, there was
talk of providing full support for integers, i.e., not just
64-bit counters, but that was rejected by the group.)

Thinking in terms of the ASN.1 and BER as a
reflection of the SMI leads to the conclusion
that anything that has one of these counter tags
cannot be writeable.  On the other hand, if one
looks at the choice of tag as just being an SMI
CLR, then one might conclue that permitting one
of these to be writeable would not be such a big deal,
and that the  RFC 2578 clause 7.1.10 restriction
was just a CLR that should under some circumstances
be ignored.  The problem, of course, is that that CLR
is certainly written into at least some MIB compilers.

Randy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 31 Mar 2009 15:28:21 +0200

> The problem, of course, 
> is that that CLR is certainly written into at least some MIB 
> compilers.

... and probably not only compilers, but also in the APIs of SNMP
applications running on entities that play roles of managers and agents
- thus preventing them to send and receive set commands. 

For this reason I do not feel that we can make a recommendation to the
IEEE to use any kind of Unsigned64 TC with write access. 

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Randy Presuhn
> Sent: Monday, March 30, 2009 7:36 PM
> To: MIB Doctors (E-mail)
> One of the early (and in my opinion correct) bits of dogma is 
> that settable counters are a very bad thing.
> 
> One of the other very early decisions (with which I still 
> disagree) was the decision to create distinct
> ASN.1 tagged types to correspond to gauges, counters, 
> integers, and so on.
> 
> (When SNMPv2 was under construction, there was talk of 
> providing full support for integers, i.e., not just 64-bit 
> counters, but that was rejected by the group.)
> 
> Thinking in terms of the ASN.1 and BER as a reflection of the 
> SMI leads to the conclusion that anything that has one of 
> these counter tags cannot be writeable.  On the other hand, 
> if one looks at the choice of tag as just being an SMI CLR, 
> then one might conclue that permitting one of these to be 
> writeable would not be such a big deal, and that the  RFC 
> 2578 clause 7.1.10 restriction was just a CLR that should 
> under some circumstances be ignored.  The problem, of course, 
> is that that CLR is certainly written into at least some MIB 
> compilers.
> 
> Randy
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 31 Mar 2009 10:10:00 -0700

Hi -

> From: "Romascanu, Dan (Dan)" <[email-masked]>
> Sent: Tuesday, March 31, 2009 6:28 AM
> Subject: RE: [MIB-DOCTORS] How to do an "Unsigned64" data type...
...
> - thus preventing them to send and receive set commands. 

It's hard to know for sure about that second statement without
actually looking at code or trying it.  For "PDU-oriented" APIs,
checking for and disallowing the encoding of a 64-bit integer
in a Set-Request would be a bit of special-case extra work,
and would be likely to be overlooked.  In my experience it's easier
to make such tests part of the MIB-oriented logic, rather than
part of the protocol encoding/decoding logic.  But the only way to
really know what the impact would be would be to actually
try out the code.
 
> IEEE to use any kind of Unsigned64 TC with write access. 

Perhaps our recommendation should be "just use netconf"?

Randy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 31 Mar 2009 19:43:33 +0200

> Perhaps our recommendation should be "just use netconf"?

I wish we were at this stage, but unfortunately I think it's too early. 

Dan