Re: [NGO] NETCONF Data types

Andy Bierman <ietf@andybierman.com> Fri, 07 December 2007 21:01 UTC

Return-path: <ngo-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0kKa-0007OS-Nj; Fri, 07 Dec 2007 16:01:56 -0500
Received: from ngo by megatron.ietf.org with local (Exim 4.43) id 1J0kKZ-0007OM-4d for ngo-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 16:01:55 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0kKY-0007OE-PH for ngo@ietf.org; Fri, 07 Dec 2007 16:01:54 -0500
Received: from smtp119.sbc.mail.sp1.yahoo.com ([69.147.64.92]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J0kKY-0001ys-1D for ngo@ietf.org; Fri, 07 Dec 2007 16:01:54 -0500
Received: (qmail 5330 invoked from network); 7 Dec 2007 21:01:53 -0000
Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.127.172.43 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 7 Dec 2007 21:01:52 -0000
X-YMail-OSG: ueGZVoUVM1l38VvJZYKrXaX0WssljYtDlWqMa2bHhWKoZHb5WDNPXHfXQ53rzf2yzq29Zi2TLODPqA89dGpfLS7M
Message-ID: <4759B4C0.50505@andybierman.com>
Date: Fri, 07 Dec 2007 13:01:52 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: "tom.petch" <cfinss@dial.pipex.com>
Subject: Re: [NGO] NETCONF Data types
References: <713043CE8B8E1348AF3C546DBE02C1B412218939@zcarhxm2.corp.nortel.com><475661FF.7030502@ericsson.com><713043CE8B8E1348AF3C546DBE02C1B41226FBCD@zcarhxm2.corp.nortel.com><4756EA8B.7010006@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B41226FCAB@zcarhxm2.corp.nortel.com> <001001c8390a$5ccaa620$0601a8c0@pc6>
In-Reply-To: <001001c8390a$5ccaa620$0601a8c0@pc6>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21be852dc93f0971708678c18d38c096
Cc: ngo@ietf.org
X-BeenThere: ngo@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF <ngo.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ngo>, <mailto:ngo-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ngo>
List-Post: <mailto:ngo@ietf.org>
List-Help: <mailto:ngo-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ngo>, <mailto:ngo-request@ietf.org?subject=subscribe>
Errors-To: ngo-bounces@ietf.org

tom.petch wrote:
> ----- Original Message -----
> From: "Sharon Chisholm" <schishol@nortel.com>
> To: "Andy Bierman" <ietf@andybierman.com>
> Cc: <ngo@ietf.org>
> Sent: Wednesday, December 05, 2007 7:31 PM
> Subject: RE: [NGO] NETCONF Data types
> 
> 
> My logic is that most of the value in types comes from building up
> complex types, not by redefining base types. I don't understand why you
> are proposing redefining xs:dateTime to map to what we had in SNMP for
> example. I want to make sure we understand the requirements of the space
> we are in now and not just auto-translate data types from where we were
> a few years ago.
> 
> Honestly, I don't know the differences between a counter and a gauge and
> I suspect the a lot  of people who read SNMP MIBs who were in the same
> boat.
> 

Just think your car dash-board.

The temperature indicator is a gauge that pegs when the
actual values are beyond the measurement capability of
the temperature sensor.  It doesn't lose its value and turn
off.

A counter (the odometer) goes around and around.
You don't know if the car has 1,104,000 miles or 104,000 miles.
You just assume the case that is much more likely to occur.


Andy


> <Tom P>
> 
> Just to state the obvious or not obvious, a gauge goes up and down and latches
> at its maximum value; a counter goes up, monotic increasing one might say:-),
> and wraps from its maximum value back to zero (perhaps generating an alarm).
> 
> I think that in management, the distinction is extremely useful.
> 
> On the other hand, it does seem a silly little implementation restriction (now
> that I am not coding an assembler) to have ..16, ..32 and ..64; BER.1 did it
> much better with its any length up to approx 2**127 bits.
> 
> So preserve the semantic distinction but avoid the question to which there is
> never an answer, how big does this have to be to cope with the anticipated life
> of the object.
> 
> Tom Petch
> </>
> 
> 
> Sharon
> 
> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com]
> Sent: Wednesday, December 05, 2007 1:15 PM
> To: Chisholm, Sharon (CAR:ZZ00)
> Cc: balazs.lengyel@ericsson.com; ngo@ietf.org
> Subject: Re: [NGO] NETCONF Data types
> 
> Sharon Chisholm wrote:
>> Hi
>>
>> But just because they are used in programming, doesn't mean we need to
> 
>> distinguish them in the XSD. I'm going to check with some of my apps
>> people to see whether they would find this distinction useful or if a
>> single integer which could be as large as 64 bit is fine at this later
> 
>> point in time. But I was more specifically worried about counter
>> versus gauge versus integer versus unsigned integer versus.
>> Historically these turned into CLRs.
>>
> 
> I totally disagree.
> I remember several times, NMS programmers at Cisco asking for int8,
> int16, uint8, uint16.  It is very useful to have these 'extra' types.
> 
> I also think it has been very useful to distinguish between gauges,
> counters, and simple numbers in SMIv2.
> If one followed your logic to the end, we would only have 'string',
> since that is the only 'real' content in an XML simpleType.
> 
> 
>> An advantage here if we don't limit the length of our integers, we
>> won't need to rewrite our Schema when we need 128bit integers ;-)
>>
>>
> 
> We can add them later if and when somebody has a compelling use case.
> 
>> Sharon
>>
> 
> Andy
> 
>> -----Original Message-----
>> From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com]
>> Sent: Wednesday, December 05, 2007 3:32 AM
>> To: Chisholm, Sharon (CAR:ZZ00)
>> Cc: ngo@ietf.org
>> Subject: Re: [NGO] NETCONF Data types
>>
>> Hello Sharon,
>> The uint32, int64 etc. integer types are not a left-overs from SMI.
> They
>> are the integer types that people normally use in programing. Names
> like
>> uint16, int32 are better then short or long. They tell you exactly
> what
>> you deal with. I see this as an improvement over the XSD types.
>> Balazs
>>
>> Sharon Chisholm wrote:
>>
>>> Hi
>>>
>>> One of the things that people seemed to agree on early in the NETCONF
> 
>>> content discussion was that SNMP & SMI defined too many similar data
>>> types and we didn't want to do that in NETCONF. Do people still agree
> 
>>> that we don't want 30 flavours of integers defined? I prefer focusing
> 
>>> our efforts on defining higher level data types.
>>>
>>> Sharon Chisholm
>>> Nortel
>>> Ottawa, Ontario
>>> Canada
>>>
>>>
>>> _______________________________________________
>>> NGO mailing list
>>> NGO@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/ngo
>>>
>>
>> _______________________________________________
>> NGO mailing list
>> NGO@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ngo
>>
>>
>>
> 
> 
> 
> _______________________________________________
> NGO mailing list
> NGO@ietf.org
> https://www1.ietf.org/mailman/listinfo/ngo
> 
> 
> 
> _______________________________________________
> NGO mailing list
> NGO@ietf.org
> https://www1.ietf.org/mailman/listinfo/ngo
> 
> 



_______________________________________________
NGO mailing list
NGO@ietf.org
https://www1.ietf.org/mailman/listinfo/ngo