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
- [Netconf] [NETCONF] monitoring data type definiti… Mark Scott
- Re: [Netconf] [NETCONF] monitoring data type defi… Juergen Schoenwaelder
- Re: [Netconf] [NETCONF] monitoring data type defi… Bert Wijnen (IETF)
- Re: [Netconf] [NETCONF] monitoring data type defi… Andy Bierman
- Re: [Netconf] [NETCONF] monitoring data type defi… Juergen Schoenwaelder
- Re: [Netconf] [NETCONF] monitoring data type defi… Mark Scott