RE: comments on data types draft

["Sharon Chisholm" <schishol@nortel.com>]

hi

A couple other points:

- I think creating these type definitions is really important and this
list seems to be at the correct level of abstraction, as appose to 100
flavours of integers.

- In the next update, the XML Schema should be well formed. We are
missing the <?xml ...>, <xs:schema ...> and other fun constructs in this
definition.

Sharon

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Chisholm, Sharon [CAR:5K50:EXCH]
Sent: Friday, July 15, 2005 7:48 AM
To: netconf@ops.ietf.org
Subject: RE: comments on data types draft


hi

I agree that we probably don't want admin/oper status in this list. They
don't seem to belong with the rest of things listed plus, as Juergen
indicated, they may not be generally applicable. I would prefer
something more along the lines of what we did in the Entity State MIB,
but I say we just defer state textual conventions for now.

Sharon

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Juergen Schoenwaelder
Sent: Thursday, July 14, 2005 6:23 PM
To: netconf@ops.ietf.org
Subject: comments on data types draft


I just browsed <draft-romascanu-netconf-datatypes-00.txt> and I have
several comments:

- I think more precise descriptions are needed. 

- There should be some consistent naming convention (e.g. use of
  uppercase/lowercase characters in type names.

- Introducing a data _type_ "MD5" with the explanation "MD5
Message-Digest 
  Algorithm" does not really make sense (unless you can express the
algorithm
  in 32 hex digits ;-). Not sure this is even one of the most important
  types to worry about.

- I am not sure the maxLength of IPAddress is a good thing. In fact,
  I would have expected that the construction is somewhat aligned in
  spirit with RFC 4001 and does not ignore zone indexes.

- EthernetAddress seems to be a misnomer. RFC 2579 calls this a MAC
  address which I think is the correct term. (I don't think you want
  to provide new type definitions for each 802.N technology that
  happens to use MAC addresses.)

- For PORT, take a look at InetPort (RFC 4001). Other RFC 4001 types
  do not seem to be covered.

- I have doubts that AdminStatus and OperStatus are generally
applicable.

- More general: I think some document should explain which of the
  XML standard schema types we use for frequently used SNMP data 
  types, especially string types and date and time related types.

- We need to figure out how to organize definitions in modules, taking
  the IETF process requirements into account. (RFC 4001 for example
  started with a focus on IP addresses but now covers more general
  IP related definitions - and we cycled that document already three
  times to add and clarify things. We might have to follow a similar
  quick recycle period with XML core types as well.

- We should have a plan how we deal with special values often used
  to express some special meaning. In the SNMP world, it has become
  good design practice to plan ahead for such special values. I am
  not really talking about place holders (I think there is little
  need for them in XML land) - I am talking about things like the
  inclusion of 0 in the InetPortNumber TC which might represent
  an ANY port in some situations.

- We should also think about IANA controlled types that is how to
  provide definitions (most likely enumerations) that can be 
  updated and maintained by IANA, perhaps in synchronization
  with corresponding SMIv2 definitions (things like ianaifType).

Just some quick thoughts. 

I do believe it is worthwhile to write up some common XML data types 
and appreciate that someone kicks this off.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen,
Germany

--
to unsubscribe send a message to netconf-request@ops.ietf.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>


--
to unsubscribe send a message to netconf-request@ops.ietf.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>