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

[Juergen Schoenwaelder <[e-mail]>]

On Tue, Oct 21, 2008 at 04:53:32PM -0400, Mark Scott wrote:
  
> 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 XSDFrom [e-mail]  Wed Oct 22 07:05:43 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 1E8F83A6804;
	Wed, 22 Oct 2008 07:05:43 -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 982793A6804
	for <[e-mail]>; Wed, 22 Oct 2008 07:05:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.225
X-Spam-Level: 
X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.024, 
	BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 CZPDs4-TBeWA for <[e-mail]>;
	Wed, 22 Oct 2008 07:05:41 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de
	[212.201.44.23])
	by core3.amsl.com (Postfix) with ESMTP id 653013A677D
	for <[e-mail]>; Wed, 22 Oct 2008 07:05:41 -0700 (PDT)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46])
	by hermes.jacobs-university.de (Postfix) with ESMTP id C020DC0032;
	Wed, 22 Oct 2008 16:06:57 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23])
	by localhost (demetrius1.jacobs-university.de [212.201.44.32])
	(amavisd-new, port 10024)
	with ESMTP id 6oCfWbo47ZNV; Wed, 22 Oct 2008 16:06:50 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133])
	by hermes.jacobs-university.de (Postfix) with ESMTP id D4561C0055;
	Wed, 22 Oct 2008 16:06:50 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501)
	id 69C9A82640D; Wed, 22 Oct 2008 16:06:50 +0200 (CEST)
Date: Wed, 22 Oct 2008 16:06:50 +0200
From: Juergen Schoenwaelder <[e-mail]>
To: Mark Scott <[e-mail]>
Message-ID: <[e-mail]>
Mail-Followup-To: Mark Scott <[e-mail]>, [e-mail]
References: <[e-mail]>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.18 (2008-05-17)
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
Reply-To: [e-mail]
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]

On Tue, Oct 21, 2008 at 04:53:32PM -0400, Mark Scott wrote:
  
> 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 standardiz 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?

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

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: [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


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?

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

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: [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