Re: [NGO] NETCONF Data types

Juergen Schoenwaelder wrote:
> On Tue, Dec 04, 2007 at 07:33:55PM -0500, Sharon Chisholm wrote:
>  
>   
>> 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? 
>>     
>
> 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.
>
>   

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

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