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

From: "Mark Scott" <[email-masked]>
Date: Tue, 21 Oct 2008 16:53:32 -0400

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 [email-masked]  Tue Oct 21 13:52:35 2008
Content-class: urn:content-classes:message
Date: Tue, 21 Oct 2008 16:53:32 -0400
From: "Mark Scott" <[email-masked]>
To: <[email-masked]>
Subject: [Netconf] [NETCONF] monitoring data type definitions;
	proposed resolution to open item from IETF72
Sender: [email-masked]

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
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 22 Oct 2008 16:06:50 +0200

On Tue, Oct 21, 2008 at 04:53:32PM -0400, Mark Scott wrote:
  
> similiar work in-progress to define standardized XSDFrom [email-masked]  Wed Oct 22 07:05:43 2008
Date: Wed, 22 Oct 2008 16:06:50 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Mark Scott <[email-masked]>
Mail-Followup-To: Mark Scott <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] [NETCONF] monitoring data type definitions;
	proposed	resolution to open item from IETF72
Reply-To: [email-masked]
Sender: [email-masked]

On Tue, Oct 21, 2008 at 04:53:32PM -0400, Mark Scott wrote:
  
> similiar work in-progress to define standardiz data types I am

Do you have a list of work in progress documents where similar XSD
definitions are provided?

> definition in the draft in the next update (-03).

Some questions:

a) What is going to be the final scope of this? Are these definitions
   going to be NETCONF monitoring specific only or are there
   expectations that these definitions are used in the wider context
   of the IETF? (The suggested namespace might imply a much wider
   context.)

b) I see differences in the patterns compared to what we have in
   draft-ietf-netmod-yang-types-00.txt (and the corresponding XSD in
   the appendix). Perhaps this should be synchronized.

c) In the context of the YANG work, we recently discussed the issue of
   types allowing multiple representations for a single value from the
   value space. This leads to the question of normalization. For
   example, IPv6 addresses can be represented in different ways, e.g.,
   ::1 and 0:0:0:0:0:0:0:1 denote the same value. If we assume that a
   NETCONF implementation only maintains the value and not its
   representation, is there a normalized representation you can expect
   to be returned by the NETCONF server? Since you are dealing with
   IPv6 addresses, you might have to deal with the same issue (and not
   surprisingly, I like the NETCONF monitoring document to be
   consistent with the YANG types document about this issue).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

ed XSD data types I am
> still now aware of one suitable for this draft at this time.

Do you have a list of work in progress documents where similar XSD
definitions are provided?

> definition in the draft in the next update (-03).

Some questions:

a) What is going to be the final scope of this? Are these definitions
   going to be NETCONF monitoring specific only or are there
   expectations that these definitions are used in the wider context
   of the IETF? (The suggested namespace might imply a much wider
   context.)

b) I see differences in the patterns compared to what we have in
   draft-ietf-netmod-yang-types-00.txt (and the corresponding XSD in
   the appendix). Perhaps this should be synchronized.

c) In the context of the YANG work, we recently discussed the issue of
   types allowing multiple representations for a single value from the
   value space. This leads to the question of normalization. For
   example, IPv6 addresses can be represented in different ways, e.g.,
   ::1 and 0:0:0:0:0:0:0:1 denote the same value. If we assume that a
   NETCONF implementation only maintains the value and not its
   representation, is there a normalized representation you can expect
   to be returned by the NETCONF server? Since you are dealing with
   IPv6 addresses, you might have to deal with the same issue (and not
   surprisingly, I like the NETCONF monitoring document to be
   consistent with the YANG types document about this issue).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Wed, 22 Oct 2008 18:18:58 +0200

Thanks Juergen for your follow up.

I have responded to Mark (privately) that we actually had a gentlemens agreement at 
the last IETF that he would try to get some interested folk in this space together
to analyze, study the topic and alternatives and that that small group would then
document one or more possile solutions and explain the pros/cons of each.

I hope that that effort will still take place (albeit somewhat later that we wanted)

I also urge those who want to do that work (analyze, document the alternatives,
make some well-documented proposals) to get in tocuh with Mark.
You can copy the WG list (or just the WG chairs) if you want.

Bert
  ----- Original Message ----- 
  From: Juergen Schoenwaelder 
  To: Mark Scott 
  Cc: [email-masked] 
  Sent: Wednesday, October 22, 2008 4:06 PM
  Subject: Re: [Netconf] [NETCONF] monitoring data type definitions;proposed resolution to open item from IETF72

  Some questions:

  /js

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Wed, 22 Oct 2008 18:18:58 +0200

Bert
  ----- Original Message ----- 
  From: Juergen Schoenwaelder 
  To: Mark Scott 
  Cc: [email-masked] 
  Sent: Wednesday, October 22, 2008 4:06 PM
  Subject: Re: [Netconf] [NETCONF] monitoring data type definitions;proposed resolution to open item from IETF72

  Some questions:

  /js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 22 Oct 2008 09:38:10 -0700

> You can copy the WG list (or just the WG chairs) if you want.

Creating multiple data model representations of an address
is not acceptable.  I raised this issue 3 or 4 IETFs ago,
and the 'quick-fix' solution is still not available.

The most basic data structure in the entire IETF is
the InetAddress.  If we can't settle on a typedef for an
InetAddress after all this time, that is pretty sad.

Listen to Juergen.  He is right, and we should use
inet-types.yang typedefs and patterns.  This issue
has already been studied, examined, and delayed long enough.

> Bert

Andy

>     *From:* Juergen Schoenwaelder
>     <mailto:[email-masked]>
>     *To:* Mark Scott <mailto:[email-masked]>
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     *Sent:* Wednesday, October 22, 2008 4:06 PM
>     *Subject:* Re: [Netconf] [NETCONF] monitoring data type
>     definitions;proposed resolution to open item from IETF72
> 
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 22 Oct 2008 09:38:10 -0700

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 22 Oct 2008 20:02:45 +0200

> InetAddress after all this time, that is pretty sad.

A single XSD definition of an IP address is not going to happen
anymore and probably this is not really a drama. I think EPP has an
XSD definition in RFCs and I would not be surprised to find more if I
start searching more systematically.

> Listen to Juergen.  He is right, and we should use inet-types.yang
> typedefs and patterns.  This issue has already been studied,
> examined, and delayed long enough.

Since it is too late (and too difficult) to have consistent IETF wide
definitions, having consistent definitions for NETCONF content or even
within IETF management content might be a more realistic goal.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 22 Oct 2008 20:02:45 +0200

/js

---

From: "Mark Scott" <[email-masked]>
Date: Thu, 23 Oct 2008 18:27:55 -0400

Juergen,

Thank you for the comments.  Per earlier response from Bert I'm going to
kick-off further discussion on this amongst the stakeholders identified
at IETF72.  We'll post a proposal back to the mailing list.

To answer the specific questions from your earlier email:

1.  [Juergen] Do you have a list of work in progress documents where
similar XSD definitions are provided?
	- The only IETF reference I could find was
draft-ietf-opsawg-smi-datatypes-in-xsd-03 (SMI specific).
	- I also looked at some proprietary data type defs (including
within my own company) but these are not standards.

2.  [Juergen] a) What is going to be the final scope of this? Are these
definitions
   going to be NETCONF monitoring specific only or are there
   expectations that these definitions are used in the wider context
   of the IETF? (The suggested namespace might imply a much wider
   context.)

[Mark]:  My preference would be wider scope but if we can agree
specifically for NETCONF that would suffice for NETCONF monitoring.  We

---

From: "Mark Scott" <[email-masked]>
Date: Thu, 23 Oct 2008 18:27:55 -0400

Juergen,

[Mark]:  My preference would be wider scope but if we can agree
specifically for NETCONF that would suffice for NETCONF monitoring.  We
can adcan adjust the namespace accordingly.

3.  [Juergen] b) I see differences in the patterns compared to what we
have in
   draft-ietf-netmod-yang-types-00.txt (and the corresponding XSD in
   the appendix). Perhaps this should be synchronized.

[Mark]:  Agreed.  Let's align these.

4.  [Juergen] c) In the context of the YANG work, we recently discussed
the issue of

[Mark]:  I also assume a NETCONF implementation only maintains the
value.  To date (to avoid this issue) we have used normalized
representations for machine-to-machine exchange.  Our presentation
layers (clients) handle multiple representations as needed.

For monitoring I don't think multiple server patterns will be an issue.
I believe YANG has agreed to AND the patterns with multiple typedefs.
This also works in XSD (nested types with restrictions).  So as long as
we do align the definitions we should be fine even in cases where client
and server are using different formats for the monitoring schema.

cheers,
Mark

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 2:03 PM
To: Andy Bierman
Cc: Bert Wijnen (IETF); Scott, Mark (CAR:2Y01); [email-masked]
Subject: Re: [Netconf] [NETCONF] monitoring data type definitions;
proposed resolution to open item from IETF72

On Wed, Oct 22, 2008 at 09:38:10AM -0700, Andy Bierman wrote:

> Creating multiple data model representations of an address is not 
> acceptable.  I raised this issue 3 or 4 IETFs ago, and the 'quick-fix'

> solution is still not available.
>
> The most basic data structure in the entire IETF is the InetAddress.  
> If we can't settle on a typedef for an InetAddress after all this 
> time, that is pretty sad.

A single XSD definition of an IP address is not going to happen anymore
and probably this is not really a drama. I think EPP has an XSD
definition in RFCs and I would not be surprised to find more if I start
searching more systematically.

> typedefs and patterns.  This issue has already been studied, examined,

> and delayed long enough.

/js

just the namespace accordingly.

3.  [Juergen] b) I see differences in the patterns compared to what we
have in
   draft-ietf-netmod-yang-types-00.txt (and the corresponding XSD in
   the appendix). Perhaps this should be synchronized.

[Mark]:  Agreed.  Let's align these.

4.  [Juergen] c) In the context of the YANG work, we recently discussed
the issue of

[Mark]:  I also assume a NETCONF implementation only maintains the
value.  To date (to avoid this issue) we have used normalized
representations for machine-to-machine exchange.  Our presentation
layers (clients) handle multiple representations as needed.

For monitoring I don't think multiple server patterns will be an issue.
I believe YANG has agreed to AND the patterns with multiple typedefs.
This also works in XSD (nested types with restrictions).  So as long as
we do align the definitions we should be fine even in cases where client
and server are using different formats for the monitoring schema.

cheers,
Mark

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 2:03 PM
To: Andy Bierman
Cc: Bert Wijnen (IETF); Scott, Mark (CAR:2Y01); [email-masked]
Subject: Re: [Netconf] [NETCONF] monitoring data type definitions;
proposed resolution to open item from IETF72

On Wed, Oct 22, 2008 at 09:38:10AM -0700, Andy Bierman wrote:

> Creating multiple data model representations of an address is not 
> acceptable.  I raised this issue 3 or 4 IETFs ago, and the 'quick-fix'

> solution is still not available.
>
> The most basic data structure in the entire IETF is the InetAddress.  
> If we can't settle on a typedef for an InetAddress after all this 
> time, that is pretty sad.

A single XSD definition of an IP address is not going to happen anymore
and probably this is not really a drama. I think EPP has an XSD
definition in RFCs and I would not be surprised to find more if I start
searching more systematically.

> typedefs and patterns.  This issue has already been studied, examined,

> and delayed long enough.

/js