[Netconf] [NETCONF] monitoring data type definitions; proposed resolution to open item from IETF72

["Mark Scott" <[e-mail]>]

Hello,
 
An open item discussed at IETF 72 is the definition of data types in the
monitoring draft.  Specifically whether or not data types required in
the model should be explicitly defined in this draft or whether they
should reference other standardized XSD definitions (where they exist).
 
In particular draft-ietf-netconf-monitoring-02 currently contains an
explicit definition for an IP address data type.  This can be found in
sec 5.2 of the draft.  I have also included it below for reference.
 
Rationale at the time of authoring v02 was to explicitly define this
since no other standardized XSD was available.  Although I am aware of
similiar work in-progress to define standardized XSD data types I am
still now aware of one suitable for this draft at this time.
 
The item which looked most promising (which was discussed in Dublin) was
alignment to the definitions in
draft-ietf-opsawg-smi-datatypes-in-xsd-03 (sec 5.4).  That draft focuses
on representing existing SMI datatypes in XSD.  This in insufficient for
the needs of the monitoring draft where we require an enhanced
definition.  In particular one with the ability to handle both IPv4 and
IPv6 addresses.
 
So I would like to seek concencus from the group that the current
explicit definition in draft-ietf-netconf-monitoring-02 is sufficient
for our NETCONF monitoring needs and that we will leave the explicit
definition in the draft in the next update (-03).
 
thank you,
Mark
 
ipAddress.xsd:
<?xml version="1.0" encoding="UTF-8"?>
   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
              targetNamespace="urn:ietf:params:xml:ns:inet-types"
              xmlns:inet="urn:ietf:params:xml:ns:inet-types"
              elementFormDefault="qualified"
              attributeFormDefault="unqualified">
 
     <xs:simpleType name="ipAddress">
       <xs:annotation>
         <xs:documentation>
           The ipAddress type represents an IP address and
           is IP version neutral. The format of the textual
           representations implies the IP version.
         </xs:documentation>
       </xs:annotation>
 
       <xs:union>
         <xs:simpleType>
           <xs:restriction base="inet:ipv4Address">
           </xs:restriction>
         </xs:simpleType>
         <xs:simpleType>
           <xs:restriction base="inet:ipv6Address">
           </xs:restriction>
         </xs:simpleType>
       </xs:union>
     </xs:simpleType>
 
     <xs:simpleType name="ipv4Address">
       <xs:annotation>
         <xs:documentation>
           The ipv4Address type represents an IPv4 address in
           dotted-quad notation. The IPv4 address may include
           a zone index, separated by a % sign.
         </xs:documentation>
       </xs:annotation>
 
       <xs:restriction base="xs:string">
         <xs:pattern value=
                  "(([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}
                   ([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])
                   (%[\p{N}\p{L}]+)?"/>
       </xs:restriction>
     </xs:simpleType>
 
     <xs:simpleType name="ipv6Address">
       <xs:annotation>
         <xs:documentation>
           The ipv6Address type represents an IPv6 address in
           full, mixed, shortened and shortened mixed notation.
           The IPv6 address may include a zone index, separated
           by a % sign.
         </xs:documentation>
       </xs:annotation>
 
       <xs:restriction base="xs:string">
         <xs:pattern value=
                  "((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})
                   (%[\p{N}\p{L}]+)?)
                   |((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\.
                       [0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))
                    (%[\p{N}\p{L}]+)?)
                  |((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)
                    (([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*
                    (%[\p{N}\p{L}]+)?)
                  ((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)
                   (([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*
                   (([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))
                    (%[\p{N}\p{L}]+)?)"/>
       </xs:restriction>
     </xs:simpleType>
 
     <xs:simpleType name="domainName">
       <xs:annotation>
         <xs:documentation>
           The domainName type represents a DNS domain
           name. The name SHOULD be fully qualified
           whenever possible.
 
           The description clause of objects using the
           domainName type MUST describe how (and when)
           these names are resolved to IP addresses.
 
           Note that the resolution of a domainName value
           may require to query multiple DNS records (e.g.,
           A for IPv4 and AAAA for IPv6).  The order of the
           resolution process and which DNS record takes
           precedence depends on the configuration of the
           resolver.
         </xs:documentation>
       </xs:annotation>
 
       <xs:restriction base="xs:string">
         <xs:pattern value="([\p{L}\p{N}]+\.)*[\p{L}\p{N}]"/>
       </xs:restriction>
     </xs:simpleTFrom [e-mail]  Tue Oct 21 13:52:35 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 89E0028C117;
	Tue, 21 Oct 2008 13:52:35 -0700 (PDT)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 4FA4428C117
	for <[e-mail]>; Tue, 21 Oct 2008 13:52:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.998
X-Spam-Level: 
X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6,
	RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id BtEzD4P2Q2zj for <[e-mail]>;
	Tue, 21 Oct 2008 13:52:33 -0700 (PDT)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56])
	by core3.amsl.com (Postfix) with ESMTP id AB0C93A679F
	for <[e-mail]>; Tue, 21 Oct 2008 13:52:32 -0700 (PDT)
Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com
	[47.129.230.95])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	m9LKrfr23147 for <[e-mail]>; Tue, 21 Oct 2008 20:53:42 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C933BF.1755F13C"
Date: Tue, 21 Oct 2008 16:53:32 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: [NETCONF] monitoring data type definitions;
	proposed resolution to open item from IETF72
Thread-Index: AckzvxQeDKpMqDAHR0258usWp1GayA=
From: "Mark Scott" <[e-mail]>
To: <[e-mail]>
Subject: [Netconf] [NETCONF] monitoring data type definitions;
	proposed resolution to open item from IETF72
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/netconf>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>,
	<mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

This is a multi-part message in MIME format.

Hello,
 
An open item discussed at IETF 72 is the definition of data types in the
monitoring draft.  Specifically whether or not data types required in
the model should be explicitly defined in this draft or whether they
should reference other standardized XSD definitions (where they exist).
 
In particular draft-ietf-netconf-monitoring-02 currently contains an
explicit definition for an IP address data type.  This can be found in
sec 5.2 of the draft.  I have also included it below for reference.
 
Rationale at the time of authoring v02 was to explicitly define this
since no other standardized XSD was available.  Although I am aware of
similiar work in-progress to define standardized XSD data types I am
still now aware of one suitable for this draft at this time.
 
The item which looked most promising (which was discussed in Dublin) was
alignment to the definitions in
draft-ietf-opsawg-smi-datatypes-in-xsd-03 (sec 5.4).  That draft focuses
on representing existing SMI datatypes in XSD.  This in insufficient for
the needs of the monitoring drype>
 
     <xs:simpleType name="host">
       <xs:annotation>
         <xs:documentation>
           The host type represents either an IP address
           or a DNS domain name.
         </xs:documentation>
       </xs:annotation>
 
       <xs:union>
         <xs:simpleType>
           <xs:restriction base="inet:ipAddress">
           </xs:restriction>
         </xs:simpleType>
         <xs:simpleType>
           <xs:restriction base="inet:domainName">
           </xs:restriction>
         </xs:simpleType>
       </xs:union>
     </xs:simpleType>
 
   </xs:schema>

_______________________________________________
Netconf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netconf