RE: [NGO] NETCONF Data types

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:ietf@andybierman.com] 
Sent: Tuesday, December 04, 2007 9:11 PM
To: j.schoenwaelder@jacobs-university.de
Cc: Chisholm, Sharon (CAR:ZZ00); ngo@ietf.org
Subject: 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