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

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

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 [e-mail]  Thu Oct 23 15:26:44 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 368723A68F7;
	Thu, 23 Oct 2008 15:26:44 -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 1050C3A6826
	for <[e-mail]>; Thu, 23 Oct 2008 15:26:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 
	BAYES_00=-2.599, 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 xJ9i+Y-9KHx0 for <[e-mail]>;
	Thu, 23 Oct 2008 15:26:42 -0700 (PDT)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56])
	by core3.amsl.com (Postfix) with ESMTP id D5A073A67AF
	for <[e-mail]>; Thu, 23 Oct 2008 15:26:41 -0700 (PDT)
Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com
	[47.129.230.95])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	m9NMP4e21956; Thu, 23 Oct 2008 22:25:04 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 23 Oct 2008 18:27:55 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Netconf] [NETCONF] monitoring data type definitions;
	proposed	resolution to open item from IETF72
Thread-Index: Ack0cGuJrz7RvDWyS7Wp31eJbS9ajgA4d8hA
References: <[e-mail]>
	<[e-mail]>
	<DC07D13B06314BDB8915DB561C092F62@BertLaptop>
	<[e-mail]>
	<[e-mail]>
From: "Mark Scott" <[e-mail]>
To: <[e-mail]>,
	"Andy Bierman" <[e-mail]>
Cc: [e-mail]
Subject: Re: [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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]

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
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
   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).

[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:[e-mail]] 
Sent: Wednesday, October 22, 2008 2:03 PM
To: Andy Bierman
Cc: Bert Wijnen (IETF); Scott, Mark (CAR:2Y01); [e-mail]
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.

> 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

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>
_______________________________________________
Netconf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netconf


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
   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).

[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:[e-mail]] 
Sent: Wednesday, October 22, 2008 2:03 PM
To: Andy Bierman
Cc: Bert Wijnen (IETF); Scott, Mark (CAR:2Y01); [e-mail]
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.

> 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

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>
_______________________________________________
Netconf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netconf