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

"Bert Wijnen \(IETF\)" <bertietf@bwijnen.net> Wed, 22 October 2008 16:18 UTC

Return-Path: <netconf-bounces@ietf.org>
X-Original-To: netconf-archive@ietf.org
Delivered-To: ietfarch-netconf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74B9D3A69B8; Wed, 22 Oct 2008 09:18:04 -0700 (PDT)
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A2E23A68AD for <netconf@core3.amsl.com>; Wed, 22 Oct 2008 09:18:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 6uyweXaU+1ZH for <netconf@core3.amsl.com>; Wed, 22 Oct 2008 09:18:01 -0700 (PDT)
Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 9B4EF3A69B8 for <netconf@ietf.org>; Wed, 22 Oct 2008 09:18:00 -0700 (PDT)
Received: (qmail 17945 invoked from network); 22 Oct 2008 16:19:16 -0000
Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 22 Oct 2008 16:19:16 -0000
Message-ID: <DC07D13B06314BDB8915DB561C092F62@BertLaptop>
From: "Bert Wijnen (IETF)" <bertietf@bwijnen.net>
To: j.schoenwaelder@jacobs-university.de, Mark Scott <markscot@nortel.com>
References: <238C6E77EA42504DA038BAEE6D1C11EC4BA87B@zcarhxm0.corp.nortel.com> <20081022140650.GA26069@elstar.local>
In-Reply-To: <20081022140650.GA26069@elstar.local>
Date: Wed, 22 Oct 2008 18:18:58 +0200
Organization: Consultant
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6001.18000
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049
Cc: netconf@ietf.org
Subject: Re: [Netconf] [NETCONF] monitoring data type definitions; proposed resolution to open item from IETF72
X-BeenThere: netconf@ietf.org
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:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1404252889=="
Sender: netconf-bounces@ietf.org
Errors-To: netconf-bounces@ietf.org

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: netconf@ietf.org 
  Sent: Wednesday, October 22, 2008 4:06 PM
  Subject: Re: [Netconf] [NETCONF] monitoring data type definitions;proposed resolution to open item from IETF72


  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 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: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
  Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
  _______________________________________________
  Netconf mailing list
  Netconf@ietf.org
  https://www.ietf.org/mailman/listinfo/netconf

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf