Re: [NGO] NETCONF Data types

["tom.petch" <[e-mail]>]

----- Original Message -----
From: "Sharon Chisholm" <[e-mail]>
To: "Andy Bierman" <[e-mail]>
Cc: <[e-mail]>
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.

<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:[e-mail]]
Sent: Wednesday, December 05, 2007 1:15 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [e-mail]; [e-mail]
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:[e-mail]]
> Sent: Wednesday, December 05, 2007 3:32 AM
> To: Chisholm, Sharon (CAR:ZZ00)
> Cc: [e-mail]
> 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
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/ngo
>>
>
>
> _______________________________________________
> NGO mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ngo
>
>
>



_______________________________________________
NGO mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ngo



_______________________________________________
NGO mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ngo