Subject: [NGO] comments on draft-romascanu-netconf-datatypes-02.txt

From: Andy Bierman <[email-masked]>
Date: Tue, 18 Sep 2007 13:23:44 -0700

Hi,

I have finished implementing draft-romascanu-netconf-datatypes-02,
as the first step of some SMIv2 integration work, and I found
some issues and bugs.

This document should be standardized ASAP.

thanks,
Andy

=============================
* General

This document should not be NETCONF-specific.
It should be as XML-generic as possible, and
any issues specific to a particular protocol
should be identified.  All the NETCONF issues should be
identified and discussed, but it should be clear where
protocol specific issues exist (e.g., RowStatus, StorageType, OIDs).

=============================
* Sec 2:

The document should stress that these data types are not
the only data types allowed in NETCONF.  The data types
from XSD are the allowed types, since the DML is XSD.

This document is just the official XSD translation of
core SMIv2 textual conventions.

=============================
* Sec 2.1

Should be titled
    Considerations for Reusing SNMP Data Types
not
    Considerations for Reusing SNMP Textual Conventions

The sub-sections go through the core data types,
not any TCs.

=============================
* Sec 2.1

The core SMIv2 types need to be defined in a separate module
(see Attachment A below).

=============================
* Sec 2.1.1:

TruthValue is a separate type from boolean.
It is needed for translation of existing MIB objects
which use this data type to XML encoding.

In para 1 it says TruthValue is not needed, and para 2
gives an example of where it is needed.

It is important to note that boolean is an XML enumeration,
which (like an SMIv2 enum) has a textual and numeric value.

The boolean data type (for example) accepts 'true' or '1',
and 'false' or '0'.

See:
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#boolean

=============================
* Sec 2.1.2:

There are 3 forms of an enum: e.g.,

    1) true
    2) 1
    3) true(1)

IMO, the string form should be mandatory, and
the other forms should be optional.

TruthValue should be 'true' or '1', and 'false' or '2'.
(I.e., 'true' is always '1', and 'false' is either '0' or '2')

=============================
* Sec 2.1.3:

I strongly object to the use of the unbounded 'integer',
'positiveInteger, 'negativeInteger', 'nonNegativeInteger',
and 'nonPositiveInteger' data types in XSD, because they
are unbounded numbers, i.e., range is "+ or - infinity".

I don't care it this is called a CLR,
because it is unwarranted complexity, and not implementable.

Only the bounded numeric data types should be used.
The 'int' data type is used for 32 bit signed numbers.
The 'unsignedInt' data type is used for 32 bit unsigned numbers.
The 'long' data type is used for 64 bit signed numbers.
The 'unsignedLong' data type is used for 64 bit unsigned numbers.

=============================
* Sec 2.1.3:

The special case of VlanIdOrAny is not really related to
this section, and should be in a 'special considerations'
section, to explain how this is done in general, so
it does not look so odd when you read the XSD.

=============================
* Sec 2.1.4:

I strongly object to the proposal to translate integer-based
time-related SMIv2 data types to the complex 'duration' datatype
in XSD.  Why make the data encoding as complicated
as possible?  People will make mistakes typing it in.

This draft does not seem to be clear on its higher purpose.
This is not just for writing new data models without giving up
core SMIv2 TCs.  It is also needed to translate existing MIB
modules into NETCONF-compatible data models.

The draft should distinguish between recommendations
for new data models vs. translations of existing data models.

=============================
* Sec 2.1.7:

The BITS data type is just a list of enumerated strings
in XSD.  It does not need a special data type of its own.

=============================
* Sec 2.1.8:

There are 2 separate problems here, again, based
on new data models vs. translations of existing data models.

For translations, I think there are many considerations,
such as the existing SMIv2 mechanisms for expressing an OID.
I prefer 'dot-notation', like 'ifIndex.17'.
Some agents may accept numbers only, or support a subset of
string-based OIDs.

For new data models:

I do not agree that 2 separate forms of OID translation
are needed, just for objects (not including instances).
The first form should be an absolute Xpath expression
that identifies the path from root to the specific
conceptual node being identified.

This format is already defined and self-evident.
An undefined and arbitrary URI, associated with
something like a TransportDomain, is just more
complexity and another registry to maintain.

However, the Xpath expression can only be used
in an XML document, and if some other type of document
needed to identify an OID, then this will not work,
because the namespaces are not specified.
In this case, an algorithmic translation to URI
format should be developed instead of registering every
object URI with IANA.

=============================
* Sec 2.1.9.2:

I do not agree that RowStatus and EntryStatus (obsolete RMON-1!)
should be used in new data models.  They should only be
used for translations, and even then, the interaction
with the management protocol verbs must be considered.

=============================
* Sec 2.1.9.3:

I do not agree that StorageType should be used in new
data models.  It should only be used for translations,
and even then, the interaction with the management protocol
must be considered (e.g., candidate, running, startup
in NETCONF).

=============================
* Sec 2.2:

Rename Section 2.2 to Section 3

Make it clear these are only the SMIv2 translation
data types.  These are NOT all the NETCONF data types.

There should be a warning that this document only
contains TEXTUAL-CONVENTION macros from existing
MIB modules, which DO NOT contain accessible objects.

This is an important issue to consider for future development.
For example, consider a NETCONF agent implementation or new data
modeling language that was capable of importing SMIv2 modules
directly, using a translation algorithm, instead of a
hand-written translation.  In this case, the existing
MIB modules that contain these TCs should be used instead.

=============================
* Sec 2.2: <schema>

Add version="1.0" and xml:lang="en" attributes
to the <schema> element.

=============================
* Sec 2.2: DisplayString

Previous versions had a pattern.
This is a plain string.

  pattern value="((((\p{IsBasicLatin})){0,255})){0,1}"

=============================
* Sec 2.2: TimeStamp and TimeInterval

The TimeTicks data type translates to the 'unsignedInt' data type:

TimeTicks ::=
     [APPLICATION 3]
         IMPLICIT INTEGER (0..4294967295)

The use of the 'duration' data type is totally inappropriate.

Data modelers have the choice of 'duration' when writing new
data models, but the translation for TimeStamp needs to be
the same as SMIv2 for translating existing data models.

=============================
* Sec 2.2: MacAddress

This pattern is just a sequence of HEX numbers.

    pattern value="[0-9a-fA-F]{12}"

The previous draft has a colon-separated list of HEX numbers,

   pattern value="(((([0-9A-Fa-f]{2}):){5,5})([0-9A-Fa-f]{2}))"

IMO, the version with colons is more readable and conventional.

=============================
* Sec 2.2: InetAddressIPv6z

There is a typo in the first child element name.

s/ipv6ddress/ipv6Address/

=============================
* Sec 2.2: InetAddressPrefixLength

The range should be 0..2040, not 1..65535

=============================
* Sec 2.2: InetPortNumber

The range should be 0..65535, not 1..65535

=============================
* Sec 2.2: InetAutonomousSystemNumber

This is just unsignedInt (range is 0..4294967295),
not range 1..65535

The text about providing for 32 bit AS numbers
was cut-and-pasted from RFC 4001, but the range does not match.

=============================
* Sec 2.2: HCPerfValidIntervals

This TC from RFC 3705 is simply an Integer32 (0..96).
Also, it is the number of time intervals, not directly
a time-based data type.

SYNTAX   Integer32 (0..96)

It should not be a 'duration' data type.

=============================
* Sec 2.2: HCPerfTimeElapsed

This TC from RFC 3705 is simply an Integer32,

SYNTAX   Integer32 (0..86399)

It should not be a 'duration' data type.

=============================
* Sec 2.2: HCPerfIntervalThreshold

This TC from RFC 3705 is simply an Integer32,

SYNTAX   Integer32 (0..900)

It should not be a 'duration' data type.

=============================
* Attachment 1:

Here is a machine generated XSD for SMI core data types,
for discussion.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns="http://netconfcentral.org/ietf/types"
  targetNamespace="http://netconfcentral.org/ietf/types"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  elementFormDefault="qualified" attributeFormDefault="unqualified"
  xml:lang="en" version="0.6" xmlns:ncx="http://netconfcentral.org/ncx/1.0">
  <xs:annotation>
   <xs:documentation> Converted from NCX module by ncxdump v0.4

     Module: smi
     Owner: ietf
     Application: types
     Version: 0.6
     Contact Info: Translated by Andy Bierman.
        Send comments to [email-masked].

     Description:
       SMIv2 data types converted from the following source:

         * RFC 2578: Structure of Management Information Version 2 (SMIv2)

     Revision History:

       Revision: 0.6
       Moved some TCs to nctypes.ncx, removed BITS

       Revision: 0.5
       Update based on NGO mailing list comments:
              change BITS back to list, fix bugs.

       Revision: 0.4
       Change BITS from list to ustring

       Revision: 0.3
       Try to align to smidump and draft-romascanu.

       Revision: 0.2
       Refine OID and other tabular data types.

       Revision: 0.1
       Initial version.
</xs:documentation>
  </xs:annotation>

  <xs:import namespace="http://www.w3.org/XML/1998/namespace"
   schemaLocation="http://www.w3.org/2001/xml.xsd"/>

  <xs:simpleType name="INTEGER">
   <xs:annotation>
    <xs:documentation>INTEGER from RFC 2578, page 8 and sec. 7.1.1.
          An enumerated integer is simply the 'enum' data type</xs:documentation>
   </xs:annotation>
   <xs:restriction  xs:base="xs:int"/>
  </xs:simpleType>

  <xs:simpleType name="OctetString">
   <xs:annotation>
    <xs:documentation>OCTET STRING from RFC 2578, page 8.</xs:documentation>
   </xs:annotation>
   <xs:restriction  xs:base="xs:string">
    <xs:maxLength value="65535"/>
   </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="Integer32">
   <xs:annotation>
    <xs:documentation>Integer32 from RFC 2578, sec. 7.1.1</xs:documentation>
   </xs:annotation>
   <xs:restriction  xs:base="xs:int"/>
  </xs:simpleType>

  <xs:simpleType name="IpAddress">
   <xs:annotation>
    <xs:documentation>IpAddress from RFC 2578, page 8.</xs:documentation>
    <xs:appinfo>
     <ncx:status>deprecated</ncx:status>
     <ncx:replaced-by>InetAddress</ncx:replaced-by>
    </xs:appinfo>
   </xs:annotation>
   <xs:restriction  xs:base="xs:string"/>
  </xs:simpleType>

  <xs:simpleType name="Counter32">
   <xs:annotation>
    <xs:documentation>Counter32 from RFC 2578, page 8.</xs:documentation>
   </xs:annotation>
   <xs:restriction  xs:base="xs:unsignedInt"/>
  </xs:simpleType>

  <xs:simpleType name="Gauge32">
   <xs:annotation>
    <xs:documentation>Gauge32 from RFC 2578, page 8.</xs:documentation>
   </xs:annotation>
   <xs:restriction  xs:base="xs:unsignedInt"/>
  </xs:simpleType>

  <xs:simpleType name="Unsigned32">
   <xs:annotation>
    <xs:documentation>Unsigned32 from RFC 2578, page 8.</xs:documentation>
   </xs:annotation>
   <xs:restriction  xs:base="xs:unsignedInt"/>
  </xs:simpleType>

  <xs:simpleType name="TimeTicks">
   <xs:annotation>
    <xs:documentation>TimeTicks from RFC 2578, page 8.</xs:documentation>
   </xs:annotation>
   <xs:restriction  xs:base="xs:unsignedInt"/>
  </xs:simpleType>

  <xs:simpleType name="Opaque">
   <xs:annotation>
    <xs:documentation>Opaque from RFC 2578, page 8.</xs:documentation>
   </xs:annotation>
   <xs:restriction  xs:base="xs:string"/>
  </xs:simpleType>

  <xs:simpleType name="Counter64">
   <xs:annotation>
    <xs:documentation>Counter64 from RFC 2578, page 8.</xs:documentation>
   </xs:annotation>
   <xs:restriction  xs:base="xs:unsignedLong"/>
  </xs:simpleType>

  <xs:simpleType name="Unsigned64">
   <xs:annotation>
    <xs:documentation>Unsigned64 TC (missing) from RFC 2856.</xs:documentation>
   </xs:annotation>
   <xs:restriction  xs:base="xs:unsignedLong"/>
  </xs:simpleType>

  <xs:simpleType name="PhysAddress">
   <xs:annotation>
    <xs:documentation>PhysAddress TC from RFC 2579, page 4.</xs:documentation>
   </xs:annotation>
   <xs:restriction  xs:base="xs:string">
    <xs:pattern value="(((([0-9A-Fa-f]{2}):)*([0-9A-Fa-f]{2}))){0,1}"/>
   </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="TruthValue">
   <xs:annotation>
    <xs:documentation>TruthValue TC from RFC 2579, page 5.</xs:documentation>
   </xs:annotation>
   <xs:restriction  xs:base="xs:string">
    <xs:enumeration value="true"/>
    <xs:enumeration value="false"/>
   </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="ObjectIdentifier">
   <xs:annotation>
    <xs:documentation>OBJECT IDENTIFIER from RFC 2578, page 8.,
                    libsmi v0.4.5 output.</xs:documentation>
   </xs:annotation>
   <xs:restriction  xs:base="xs:string">
    <xs:pattern value="[0-2](\.(0|([1-9]([0-9]*))))*"/>
    <xs:minLength value="2"/>
   </xs:restriction>
  </xs:simpleType>

  <xs:complexType name="AutonomousType">
   <xs:annotation>
    <xs:documentation>AutonomousType TC from RFC 2579, page 5.</xs:documentation>
   </xs:annotation>
   <xs:simpleContent>
    <xs:extension base="ObjectIdentifier"/>
   </xs:simpleContent>
  </xs:complexType>

  <xs:complexType name="InstancePointer">
   <xs:annotation>
    <xs:documentation>
          A pointer to either a specific instance of a MIB object or
          a conceptual row of a MIB table in the managed device.  In
          the latter case, by convention, it is the name of the
          particular instance of the first accessible columnar object
          in the conceptual row.

          The two uses of this textual convention are replaced by
          VariablePointer and RowPointer, respectively.
         </xs:documentation>
    <xs:appinfo>
     <ncx:status>deprecated</ncx:status>
    </xs:appinfo>
   </xs:annotation>
   <xs:simpleContent>
    <xs:extension base="ObjectIdentifier"/>
   </xs:simpleContent>
  </xs:complexType>

  <xs:complexType name="VariablePointer">
   <xs:annotation>
    <xs:documentation>VariablePointer TC from RFC 2579, page 6. smidump v0.4.5,

          A pointer to a specific object instance.  For example,
          sysContact.0 or ifInOctets.3.</xs:documentation>
   </xs:annotation>
   <xs:simpleContent>
    <xs:extension base="ObjectIdentifier"/>
   </xs:simpleContent>
  </xs:complexType>

  <xs:simpleType name="DateAndTime">
   <xs:annotation>
    <xs:documentation>DateAndTime TC from RFC 2579, pages 18 - 19.</xs:documentation>
   </xs:annotation>
   <xs:restriction  xs:base="xs:string">
    <xs:minLength value="8"/>
    <xs:maxLength value="28"/>
   </xs:restriction>
  </xs:simpleType>

  <xs:complexType name="TDomain">
   <xs:annotation>
    <xs:documentation>TDomain TC from RFC 2579, page 20.</xs:documentation>
   </xs:annotation>
   <xs:simpleContent>
    <xs:extension base="ObjectIdentifier"/>
   </xs:simpleContent>
  </xs:complexType>

  <xs:simpleType name="TAddress">
   <xs:annotation>
    <xs:documentation>TAddress TC from RFC 2579, page 20.</xs:documentation>
   </xs:annotation>
   <xs:restriction  xs:base="xs:string">
    <xs:minLength value="1"/>
    <xs:maxLength value="255"/>
   </xs:restriction>
  </xs:simpleType>

</xs:schema>

_______________________________________________
NGO mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ngo

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 19 Sep 2007 12:25:22 +0200

I guess that we'll see revised versions of this document as well as of
draft-li-mib-convert and draft-li-ngo-access-mib submitted before
Vancouver and discussed at the OPSA WG meeting in Vancouver. 

Dan

> -----Original Message-----
> From: Andy Bierman [mailto:[email-masked]] 
> Sent: Tuesday, September 18, 2007 10:24 PM
> To: NETCONF Goes On; OPSAWG
> Subject: [OPSAWG] comments on draft-romascanu-netconf-datatypes-02.txt
> 
> Hi,
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 19 Sep 2007 12:31:03 +0200

Sorry, ngo-access should be discussed someplace else.

Dan

> From: Romascanu, Dan (Dan) 
> Sent: Wednesday, September 19, 2007 12:25 PM
> To: 'Andy Bierman'; NETCONF Goes On; OPSAWG
> Subject: RE: [OPSAWG] comments on 
> draft-romascanu-netconf-datatypes-02.txt
> 
> 
> I guess that we'll see revised versions of this document as 
> well as of draft-li-mib-convert and draft-li-ngo-access-mib 
> submitted before Vancouver and discussed at the OPSA WG 
> meeting in Vancouver. 
> 
> Dan
> 
>  
>  
> 
> > as the first step of some SMIv2 integration work, and I found some 
> > issues and bugs.
> >