Subject: [NGO] NETCONF Data types

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 4 Dec 2007 19:33:55 -0500

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 5 Dec 2007 02:15:42 +0100

On Tue, Dec 04, 2007 at 07:33:55PM -0500, Sharon Chisholm wrote:
 
> that we don't want 30 flavours of integers defined? 

In SMI land, we defined many types in an attempt to express
relationships which are otherwise not expressable. The reason we have
things such as InterfaceIndex and InterfaceIndexOrZero is that we
wanted to capture 'hey this number here actually identifies an
interface'. With a different data modeling language, you might not
need to do this anymore via the type system since you might have other
mechanisms to express the information that a value is actually
identifying an interface.

<soap>
  This is actually an nice example demonstrating that the features of
  a data modeling language will influence the way other features of a
  language are used. The INET-ADDRESS-MIB is another example demoing
  how we had to hack around the lack of unions in the SMI. You can of
  course convert all this stuff algorithmically to XSD; whether the
  result is useful in other contexts (say for NETCONF configuration)
  needs to be considered.
</soap>

That said, I take most of the blame for the collection of data types
in the YANG modules contained in the YANG draft. I tries to create a
core collection of reusable types, but I am sure the result is
somewhat biased and I might have simply overlooked something. I like
to encourage people to take a look at the defined types in the YANG
document and if you think something is wrong, missing, or should not
be there, please drop a note so we can work things out.

/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: Andy Bierman <[email-masked]>
Date: Tue, 04 Dec 2007 18:11:07 -0800

> be there, please drop a note so we can work things out.

I like the data types in YANG.
There needs to be a clear distinction between builtin types and
derived types.  IMO, the list of builtin numeric data types is fine
the way it is.  The collection of 'extra' derived types is debatable
and will probably grow over time.

> /js

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 4 Dec 2007 21:29:56 -0500

Hi

It would be helpful if someone could generate some XML Schema describing
the data types that the yang proposal suggests. Then we can come to some
sort of agreement on those independent of the choice of data modelling
language.

My sense that you guys are might be proposing defining the type of data
types I was specifically hoping to avoid in NETCONF. Seeing the XML
Schema definition will allow me and others to get a better sense of what
the actual XML would look like.

Note that I don't think this is the same discussion as the one going on
in the operations and management working group. This is strictly about
getting the best possible content for NETCONF.

Thanks,

Sharon 

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Tuesday, December 04, 2007 9:11 PM
To: [email-masked]
Cc: Chisholm, Sharon (CAR:ZZ00); [email-masked]
Subject: Re: [NGO] NETCONF Data types

I like the data types in YANG.
There needs to be a clear distinction between builtin types and derived
types.  IMO, the list of builtin numeric data types is fine the way it
is.  The collection of 'extra' derived types is debatable and will
probably grow over time.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 04 Dec 2007 18:36:18 -0800

> sort of agreement on those independent of the choice of data modelling

I will work on that (for tomorrow)
However, my ncxdump program may not agree 100% with pyang (yet).

There are lots of fun corner cases, such as range "1 .. 5 | 10 .. 20";

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 5 Dec 2007 08:10:31 +0100

On Tue, Dec 04, 2007 at 09:29:56PM -0500, Sharon Chisholm wrote:

> types I was specifically hoping to avoid in NETCONF.

Such as? (Some types in the YANG modules are included for specific
reasons - but before explaining the reasons, I like to know what you
think should be avoided.)

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 05 Dec 2007 09:02:41 +0100 (CET)

> sort of agreement on those independent of the choice of data modelling

Go to 

http://www.yang-central.org/twiki/bin/view/Main/YangExamples

then click on yang-types.xsd etc.

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 05 Dec 2007 00:31:59 -0800

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

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 5 Dec 2007 12:54:42 -0500

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.

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 ;-)

Sharon 

-----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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 05 Dec 2007 10:14:35 -0800

> gauge versus integer versus unsigned integer versus. Historically these

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.

> need to rewrite our Schema when we need 128bit integers ;-)

We can add them later if and when somebody has a compelling use case.

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 5 Dec 2007 13:31:29 -0500

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.

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

> 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 ;-)
>
>   

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 05 Dec 2007 10:46:48 -0800

> to have these 'extra' types.

Moreover, if I remember correctly, they are already available via the
W3C XML Schema Type Library in both XSD and RELAX NG, though under
different names - unsignedByte, unsignedShort, unsignedInt and
unsignedLong, so I think there is nothing to argue about here.

> gauges, counters, and simple numbers in SMIv2.

I do have some reservations here and prefer keeping types without
semantics at the general level.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 05 Dec 2007 19:51:18 +0100 (CET)

> semantics at the general level.

I don't know what you mean with "general level".  But note that the
gauges and counters are not built-in YANG types - they are derived
types defined in the module "yang-types".

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 05 Dec 2007 10:53:52 -0800

> semantics at the general level.

Agreed.
Note that the builtin  types in YANG have very little semantics.
counter32 and gauge32 are derived types in YANG, not builtin types.

One of the most ridiculous decisions made in the SNMP world
was the addition of Counter64 instead of Integer64 and Unsigned64.
There is no way in SNMP to express the difference between 2 Counter64s,
or have a large negative integer.

Andy

---

From: "David Harrington" <[email-masked]>
Date: Wed, 5 Dec 2007 10:56:41 -0800

Hi, 

> 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
> 

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

> > 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

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 05 Dec 2007 11:05:32 -0800

Hi Martin,

> types defined in the module "yang-types".

I meant exactly this. I can decide to import yang-types or write own
derived types if my semantics is different, but there is no such choice
for things that are already in the base library.

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 6 Dec 2007 01:00:29 +0100

On Wed, Dec 05, 2007 at 01:31:29PM -0500, Sharon Chisholm wrote:
 
> 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.

YANG is not redefining xs:dateTime. YANG is defining a type called
date-and-time in the yang-types module which is following RFC 3339, a
Proposed Standard RFC of the IETF. And RFC 3339 is again a profile of
a the ISO 8601 standard. A quote from RFC 3339:

   The following profile of ISO 8601 [ISO8601] dates SHOULD be used in
   new protocols on the Internet.

I am aware that there are some differences between yang:date-time and
xsd:dateTime.

/js

---

From: "tom.petch" <[email-masked]>
Date: Fri, 7 Dec 2007 15:28:23 +0100

----- Original Message -----
From: "Sharon Chisholm" <[email-masked]>
To: "Andy Bierman" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, December 05, 2007 7:31 PM
Subject: RE: [NGO] NETCONF Data types

<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:[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

I totally disagree.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 7 Dec 2007 21:59:18 +0100

On Fri, Dec 07, 2007 at 03:28:23PM +0100, tom.petch wrote:

> 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.

No size limit means that every implementor chooses his own limit (only
very few people will go and implement arbitrary precision arithmetic
on network devices). I think this very much contradicts the very
purpose of a standard.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 07 Dec 2007 13:01:52 -0800

> I suspect the a lot  of people who read SNMP MIBs who were in the same

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 07 Dec 2007 13:59:26 -0800

> on network devices). I think this very much contradicts the very

I strongly agree with Juergen.
Both the agent and manager implementors want fixed sized numbers
to save time and memory, and not have to support more than one
way of encoding a given data type.

Unbounded integers are really not okay for data models.
This is one difference between an info model and a data model,
something Juergen knows all about.  We standardize data models for
NM for SNMP, and we should do the same thing for NETCONF.
The value of a standard is in its deployment, after all.

Andy

---

From: "Natale, Bob" <[email-masked]>
Date: Fri, 7 Dec 2007 19:49:41 -0500

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, 

dbh

SMI.
Names