Re: [NGO] NETCONF Data types

Sharon Chisholm wrote:
> 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.
>   

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

> 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