Subject: RE: [NGO] NETCONF Data types

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 7 Jan 2008 08:47:46 -0500

Hi

My point in this thread is that 30 flavours of integers isn't where the
real value in standardizing on data types comes from. It is from
agreeing on higher level concepts like IP addresses, etc. I'd rather we
spent our time there for NETCONF content (this isn't about SNMP). 

By the way, I chatted with one of my application folks about the 32
versus 64 bit integer question and he indicated that he can't handle 64
bit integers in his application so does want to when they he might
expect them. In that case, a better approach is likely a complex type
which gives length and value. This way if you handle all lengths, you
just need to look at the value field.

Sharon

-----Original Message-----
From: Natale, Bob [mailto:[email-masked]] 
Sent: Friday, December 07, 2007 7:50 PM
To: David Harrington; Chisholm, Sharon (CAR:ZZ00); Andy Bierman
Cc: [email-masked]
Subject: RE: [NGO] NETCONF Data types

Hi,

I don't mean to "pile on" here...I share Dave's surprise and Andy has
already provided a helpful example to illustrate counter vs gauge...and
somehow I feel certain that Sharon does know the difference...but I did
just want to add that developers *must* understand the distinct
semantics of each of those types as a prerequisite for building useful
SNMP management applications...and, of course, these semantics must be
preserved by non-SNMP management applications that intend to integrate
SNMP management data.

Cheers,
BobN

-----Original Message-----
From: David Harrington [mailto:[email-masked]]
Sent: Wednesday, December 05, 2007 1:57 PM
To: 'Sharon Chisholm'; 'Andy Bierman'
Cc: [email-masked]
Subject: RE: [NGO] NETCONF Data types

Hi, 

> -----Original Message-----
> From: Sharon Chisholm [mailto:[email-masked]]
> Sent: Wednesday, December 05, 2007 10:31 AM
> To: Andy Bierman
> Cc: [email-masked]
> Subject: RE: [NGO] NETCONF Data types
> 
> Hi
> 
> 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.

In 15 years of advising MIB writers and NMS developers, I have never had
anybody complain they didn't understand the difference between a counter
and a guage, or thought the distinction was unimportant. I feel sad that
you, as a MIB Doctor, do not understand the difference.

dbh

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

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

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 7 Jan 2008 15:04:37 +0100

> just need to look at the value field.

I don't understand the proposal or how what I understand helps someone
who can't deal with 64 bit numbers.

/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: "Sharon Chisholm" <[email-masked]>
Date: Mon, 7 Jan 2008 09:07:05 -0500

Hi

If it is define with length=64, then you know you can't read it and
ignore it. If it is defined with length=32, the you know you can read it
and do.

Sharon 

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email-masked]] 
Sent: Monday, January 07, 2008 9:05 AM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]
Subject: Re: [NGO] NETCONF Data types

On Mon, Jan 07, 2008 at 08:47:46AM -0500, Sharon Chisholm wrote:
 
> versus 64 bit integer question and he indicated that he can't handle 
> 64 bit integers in his application so does want to when they he might 

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 07 Jan 2008 15:20:20 +0100

Hi Sharon,

64-bit integers are crucial e.g., for applications dealing with precise
timestamps. Of course, an appropriate integer range should be used in
each context. In my opinion, the integer datatypes defined by the W3C
Datatype Library provide a very reasonable selection and I see no point
in reducing this choice.

Lada
 
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 7 Jan 2008 15:25:24 +0100

On Mon, Jan 07, 2008 at 09:07:05AM -0500, Sharon Chisholm wrote:
 
> ignore it. If it is defined with length=32, the you know you can
> read it and do.

I think this "works sometimes" approach is not really a solution.

That said, every decent parser which turns ASCII number strings into
binary data should be able to detect overflows (C standard functions
strtol() and friends do this) even without an explicit "length"
indication - so you can have this "works sometimes" approach already
today.

/js

---

From: Phil Shafer <[email-masked]>
Date: Mon, 07 Jan 2008 12:40:22 -0500

>ignore it. If it is defined with length=32, the you know you can read it

This can't be a run-time thing.  It needs to be more cut-and-dried.
The model should give you the data types, your shouldn't be mixing
metadata into your data.

If the DML says it's a uint64 and you can't handle uint64s, you
can't handle that data module.  You need to let the user know that
up front.  You can't say "at 2am last night we started dropping
your accounting data because your value went beyond 32 bits".  The
real value in standardizing on data types comes from knowing that
things will function correctly.

Thanks,
 Phil

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 7 Jan 2008 12:51:06 -0500

Hi

This was intended as a design time definition.

Sharon 

-----Original Message-----
From: Phil Shafer [mailto:[email-masked]] 
Sent: Monday, January 07, 2008 12:40 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]; [email-masked]
Subject: Re: [NGO] NETCONF Data types

"Sharon Chisholm" writes:
>ignore it. If it is defined with length=32, the you know you can read 
>it and do.

If the DML says it's a uint64 and you can't handle uint64s, you can't
handle that data module.  You need to let the user know that up front.
You can't say "at 2am last night we started dropping your accounting
data because your value went beyond 32 bits".  The real value in
standardizing on data types comes from knowing that things will function
correctly.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Mon, 07 Jan 2008 13:07:38 -0500

Then I'm lost.  You said earlier:

>> In that case, a better approach is likely a complex type

Where is the complex type?  Sounded like you meant to encode both
the length and the value in the transmitted data.  What's the value
of carrying to length if the module definition tells you the max length?
Or am I misreading you completely?

Thanks,
 Phil

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 7 Jan 2008 15:17:45 -0500

Hi

Complex type was a poor choice of words. Sorry about that. My brain is
still in post-holiday mush mode. It's more of an appInfo which specifies
the length for those who are interested and is ignorable for those who
are not. This could potentially be done using existing base integer
types.

Sharon 

-----Original Message-----
From: Phil Shafer [mailto:[email-masked]] 
Sent: Monday, January 07, 2008 1:08 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]; [email-masked]
Subject: Re: [NGO] NETCONF Data types

Then I'm lost.  You said earlier:

>> In that case, a better approach is likely a complex type which gives 
>> length and value. This way if you handle all lengths, you just need 
>> to look at the value field.

Where is the complex type?  Sounded like you meant to encode both the
length and the value in the transmitted data.  What's the value of
carrying to length if the module definition tells you the max length?
Or am I misreading you completely?

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 7 Jan 2008 21:24:38 +0100

> are not. This could potentially be done using existing base integer

So what was wrong with having base types of different common bit
width??

/js